Azure Enclave の承認とは何ですか?

Azure エンクレーブでの承認により、重要なインフラストラクチャ運用に対するガバナンスと監視のもう 1 つの層が提供されます。この機能を使用すると、管理者は、新しいリソースを作成したり、既存のリソースを変更したりするための要求をキューに入れながら、変更を実装する前に明示的な承認を要求できます。これにより、変更権限を持つユーザーに追加のコントロールが提供されます。変更を行う前に追加の承認が必要です。

次の承認シナリオを検討してください。

あなたはコミュニティサイバーエキスパートであり、管理者チームが新しいエンクレーブを作成することを望んでいますが、エンクレーブの作成を承認する必要があります。新しいエンクレーブの必須承認者として自分を追加する。
コミュニティサイバーチームは、コミュニティのセキュリティと分離を維持するために、新しいエンクレーブ接続を確認する必要があります。エンクレーブ接続の作成と更新に必要な承認者として、コミュニティサイバーチームのセキュリティグループを追加します。
共有 Web アプリをホストするエンクレーブ所有者です。 Web アプリに接続するための他のエンクレーブ用のエンクレーブエンドポイントを作成しました。可用性とセキュリティについて、3 人のユーザーがそのエンドポイントに対する変更を確認することを信頼します。エンクレーブエンドポイントへの接続に必要な承認者としてセキュリティグループを追加します。

Important

承認機能は現在 プレビュー段階です。この機能はテストに推奨されますが、プレビュー段階の運用環境のワークロードには使用しないでください。

前提条件

承認を設定したり使用したりする前に、以下の前提条件を満たしてください:

ユーザーやグループを Enclave承認者ロール に割り当て、リクエストをレビューできるようにします。
必要に応じて、 Enclave承認ロール付きのユーザーやグループを各承認設定の必須承認者に追加してください。どの行動に必須承認が必要かはあなたが判断します。
変更を提出する予定ユーザーと、変更を承認するユーザーが異なるかを確認してください。
承認者がコミュニティや要求が作成されるエンクレーブスコープにアクセスできるようにしてください。

この役割割り当てを先に完了しなければ、申請は利用可能な承認者がいない州に入る可能性があります。

承認を使用する理由

承認は、次の方法で機密性の高い環境に対して厳格なガバナンスとセキュリティ標準を維持するのに役立ちます。

職務分離の強制:変更を申請する人が承認者と同一でないことを確実にすること。
不正な変更の防止:重要なインフラ変更が施行される前に明確な承認を求めること。
監査トレイルの強化:誰が変更を要求し、誰が承認したか、いつかを包括的に記録すること。
リスクの低減:展開前に潜在的な誤設定や不正な変更を発見すること。
コンプライアンス要件の支援:変更管理および監督のための規制要件を満たすこと。
制御された展開を可能にする:実行前に管理監督を必要としながら、チームが変更を準備できるようにします。

承認のしくみ

Azure エンクレーブの承認ワークフローは、次の主要な手順に従います。

提出リクエスト:適切な権限を持つユーザーが、エンクレーブ接続の作成やエンドポイントの変更など、承認が必要なアクションを開始します。
保留状態:要求された変更は保留中の状態に入り、レビュー待ちキューに入ります。
承認審査: Enclave Approver Role のユーザーは、保留中の承認申請を確認できます。
決定:承認者は任意のコメントを付けて申請を承認または拒否します。
実装:承認決定後、承認されたリクエストは実装に進むことができますが、却下されたリクエストは進行しません。

役割と権限

承認機能は、Azureエンクレーブロールベースのアクセス制御 (RBAC) と統合されます。

エンクレーブ承認者の役割

エンクレイブ承認者の役割は、承認申請を管理します:

読み取り専用アクセス : すべての Azure Enclave リソースの種類へのアクセス
明示的な権限で保留中の承認リクエストを承認または拒否する
変更の開始ができない:この役割は監督と承認のみを目的としています
監査の可視性: 承認要求と決定の完全な履歴を表示できます

その他の関連ロール

エンクレーブ所有者/共同作成者: 承認を必要とするが自己承認できない要求を送信できます
コミュニティ所有者/共同作成者: 承認を必要とするコミュニティレベルの要求を送信できます
エンクレーブ閲覧者: 保留中の承認を表示できますが、承認または拒否することはできません

Azure Enclave RBAC ロールの詳細を確認する

Azure Privileged Identity Managementとの統合

承認とAzure Privileged Identity Management(PIM)を組み合わせてセキュリティを強化する:

即時承認者アクセス:PIMを通じてエンクレイブ承認者の役割を期限内に付与
多要素認証: 承認アクションに MFA を要求する
承認者権限の承認: 承認者権限を付与する前に、二次承認を必須にする
包括的な監査ログ: Azure エンクレーブと PIM の両方にわたるすべての承認アクティビティを追跡する

ジャストインタイムアクセスについて詳しくはこちらをご覧ください。

監視と監査

すべての承認活動をログアップし監査することができます:

Azureアクティビティログ:すべての承認および拒否アクションはAzureアクティビティログに記録されます。
Log Analytics:承認パターンや傾向をクエリ・分析できます。
Microsoft Sentinel:承認ログをセキュリティ監視と統合できます。

承認対象となるリソースアクション

リソースアクションの承認機能を有効にすると、そのアクションには承認が必要です:

地域社会の行動

コミュニティエンドポイントの更新:コミュニティ外の信頼できるリソースへのアクセスを制御するコミュニティエンドポイントの設定を変更すること。
エンクレーブエンドポイントの更新:エンクレーブ内のワークロードへのアクセスを制御するエンドポイント構成を変更すること。
エンクレイブ作成:新しいエンクレイブの作成。
接続の作成:エンクレーブ間や外部資源との新たな接続の作成。
接続更新:エンクレーブ間や外部リソース間の既存接続を変更すること。
エンクレイブメンテナンスモード:エンクレイブのメンテナンスモードを変更すること(メンテナンスモードのオン・オフを含む)。

エンクレイブの行動

エンクレイブのエンドポイント更新:エンクレーブ内のワークロードへのアクセスを制御するエンドポイント設定を変更すること。
接続作成:エンクレイブから他のエンクレイブや外部リソースへの新しい接続を作成すること。
接続更新:エンクレーブから他のエンクレーブや外部リソースへの既存接続の変更。
エンクレイブメンテナンスモード:エンクレイブのメンテナンスモードを変更し、メンテナンスモードのオンオフを切り替えること。

承認が必要な特定の運用は、組織のガバナンス要件に基づいてコミュニティ構成で設定できます。

承認状態

承認申請は以下の状態を持つことができます:

状態	説明
承認	申請は承認されました。
拒否された	その要請は却下されます。
保留中	申請は提出され、現在承認待ちです。
削除済み	承認リクエストは削除されます。
期限切れ	承認申請は完了する前に期限切れとなります。

ベストプラクティス

Azure エンクレーブ環境で承認を実装する場合:

専任の承認者を割り当てる:職務分離を維持するために、特定の個人やチームを承認者に指定します。
承認ポリシーを定義する:承認が必要な変更点と承認基準を明確に文書化しましょう。
承認のためのSLAを設定する:導入遅延を防ぐために承認決定の期間を設定します。
説明的な正当化を用いましょう:依頼者に変更要求の詳細な正当化を求めます。
定期的な監査レビュー:定期的に承認ログを確認し、パターンを特定しプロセスを改善すること。
PIMと組み合わせる:機密環境には期限付きの承認者アクセスを活用しましょう。
拒否理由の文書化:リクエストを拒否する際は、依頼者が理由を理解できるように明確なフィードバックを提供しましょう。
チケットID:変更管理ツールを使用している場合は、承認リクエストに変更管理IDを含めてください。

エンクレーブ作成フローの比較

次の図は、承認が無効になっている場合と有効になっている場合のエンクレーブの作成の違いを示しています。

Flow	説明
承認なし	エンクレーブの作成は、要求の送信時に直ちに続行されます。作成アクセス許可を持つユーザーは、より多くの監視なしでエンクレーブを作成します。
承認あり	エンクレーブの作成が保留中の状態に入り、プロビジョニングを開始する前に明示的な承認が必要になります。拒否された要求は、リソースの作成なしで記録されます。

Note

この例では、そのチェックが Azure の一般的なフローの一部であるため、ユーザーがリソースを作成するアクセス許可を持っていることを前提としています。承認機能は、ユーザーがリソースを作成するアクセス許可を既に持っている場合に、ガバナンスの別のレイヤーを追加します。

次のステップ

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-08-14