Azure エンクレーブで承認を構成する

この記事では、Azure エンクレーブで承認機能を構成して、重要なインフラストラクチャ操作のガバナンスと監視を適用する方法について説明します。

Important

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

前提条件

承認を構成する前に、次の要件を満たしていることを確認してください。

  • 有効な Azure サブスクリプション
  • 承認プレビューへのアクセス
  • 次のいずれかのロール:
    • コミュニティ所有者
    • コミュニティ貢献者
    • サブスクリプション所有者/共同作成者
  • 環境内に作成された少なくとも 1 つのコミュニティ
  • 承認者として指定されたユーザーまたはグループ

承認範囲

承認設定は、さまざまなスコープで構成できます。

Scope 適用対象
Community コミュニティ エンドポイントやトランジット ハブなどのコミュニティ レベルのリソース。
隔離領域 エンクレーブ レベルのリソース (エンクレーブ エンドポイントやエンクレーブ接続など)。

コミュニティ リソースの承認設定は、コミュニティを作成または更新するときに構成されます。 エンクレーブ リソースの承認設定は、コミュニティの作成時とエンクレーブの作成時に構成できます。 両方のスコープで同じエンクレーブ リソースの種類の要件が定義されている場合、エンクレーブAzureは、より高いレベルの適用要件を適用します。 リソースまたは操作の種類に基づいて、さまざまな承認要件を構成できます。

コミュニティ所有者は、リソースの種類に対してコミュニティ レベルの承認設定を定義しないことを選択することもできます。 コミュニティ レベルの構成を空白のままにすると、そのリソースの種類のコミュニティ レベルの要件を継承せずにエンクレーブ レベルの承認設定を使用できます。

最小承認者と必要な承認者

承認構成には、次の 2 つの関連概念が含まれています。

  • Minimum approvers: エンクレーブAzure変更を適用する前に要求を承認する必要がある承認者の数。
  • Required approvers: リソースの種類の要求を確認するために許可または必要なユーザーまたはグループ。

たとえば、リソースの種類に少なくとも 2 つの承認が必要で、特定のセキュリティ操作グループからの承認が 1 つ必要な場合があります。 その場合は、カウントの Minimum approvers を構成し、承認者 ID またはグループの Required approvers を構成します。

Tip

必要な承認者を追加する場合は、組織を離れる個人がリソースのデプロイをブロックしないように、セキュリティ グループを選択する必要があります。

コミュニティ承認設定は下位に継承されます

コミュニティの承認設定がエンクレーブの作成、コミュニティ エンドポイントの更新、コミュニティ メンテナンス モードの変更にどのように影響するかを示す図。

コミュニティ レベルの承認設定は、エンクレーブの作成、コミュニティ エンドポイントの更新、またはメンテナンス モードへの変更に影響を与える唯一の承認設定です。 各承認の種類が有効になっている場合、最小限の承認者の数と必要な承認者の一覧を満たす必要があります。その後、それらのリソースの変更を行う必要があります。

エンクレーブの承認設定は下位へ継承されます

コミュニティとエンクレーブの承認設定がエンクレーブ接続の作成または更新、エンクレーブ接続の更新、またはメンテナンス モードへの変更にどのように影響するかを示す図。

コミュニティ レベルとエンクレーブ レベルでの承認設定は、エンクレーブ接続の作成または更新、エンクレーブ接続の更新、またはメンテナンス モードへの変更に影響します。 各承認の種類が有効になっている場合、最小限の承認者の数と必要な承認者の一覧を満たす必要があります。その後、それらのリソースの変更を行う必要があります。

コミュニティの承認を設定する

承認はコミュニティ レベルで構成されます。 承認が必要なリソース アクションを決定した後、それらの設定はコミュニティ内でその種類のすべてのリソースに適用されます。

コミュニティを作成するときに承認設定を構成するには:

  1. Azure ポータルで、コミュニティ作成ワークフローを開始します。
  2. [ Approvals 構成] タブに移動します。
  3. サポートされているコミュニティまたはエンクレーブ リソースの種類ごとに、承認が必要かどうかを構成します。
  • Community endpoint updates: コミュニティ エンドポイントを変更するときに承認が必要です。
  • Enclave endpoint updates: エンクレーブ エンドポイントを変更するときに承認が必要です。
  • Enclave creation: 新しいエンクレーブが作成される前に承認が必要です。
  • Enclave connection creation: エンクレーブ接続を作成するときに承認が必要です。
  • Enclave connection updates: エンクレーブ接続を変更するときに承認が必要です。
  • Maintenance mode changes: エンクレーブでメンテナンス モードを変更する前に承認が必要です (オンまたはオフの切り替えなど)。
  1. Minimum approvers値を設定します。
  2. Required approversのユーザーまたはグループを選択します。
  3. 構成を確認し、コミュニティを作成します。

コミュニティ レベルの承認設定は、コミュニティ リソースに使用されます。 また、コミュニティ レベルの構成でそのリソースの種類が空白のままでない限り、エンクレーブ リソースの種類に対して継承された要件を提供することもできます。

エンクレーブの承認を設定する

エンクレーブを作成するときに承認設定を構成するには:

  1. Azure ポータルで、エンクレーブ作成ワークフローを開始します。
  2. [ Approvals 構成] タブに移動します。
  3. コミュニティから継承された承認要件を確認します。
  4. サポートされているエンクレーブ リソースの種類ごとに、承認が必要かどうかを構成します。
  • Enclave endpoint updates: エンクレーブ エンドポイントを変更するときに承認が必要です。
  • Enclave connection creation: エンクレーブ接続を作成するときに承認が必要です。
  • Enclave connection updates: エンクレーブ接続を変更するときに承認が必要です。
  • Maintenance mode changes: エンクレーブでメンテナンス モードを変更する前に承認が必要です (オンまたはオフの切り替えなど)。
  1. Minimum approvers値を設定します。
  2. Required approversのユーザーまたはグループを選択します。
  3. 構成を確認し、エンクレーブを作成します。

コミュニティとエンクレーブの両方でエンクレーブ リソースの種類の要件が定義されている場合は、最大 Minimum approvers が使用され、コミュニティとエンクレーブの両方の Required approvers が一連の Required approversに結合されます。

承認設定を更新する

コミュニティ所有者は、リソースの作成後に承認設定を更新できます。 環境で使用可能な Azure ポータルまたは CLI のサポートを使用して、コミュニティまたはエンクレーブ リソースの種類の承認設定を更新します。

承認設定を変更する前に、次の項目を確認します。

  • どのリソースの種類が影響を受けているかを確認し、その種類について保留中の承認がないかを確認します。
  • 設定がコミュニティ スコープ、エンクレーブ スコープ、またはその両方で定義されているかどうか。
  • 変更によって継承された要件が追加または削除されるかどうか。
  • 必要な承認者として表示されるユーザーまたはグループ。

エンクレーブ承認者ロールを割り当てる

承認を有効にした後、 Enclave Approver Role をリクエストをレビューし承認するユーザーやグループに割り当てます。

  1. 承認者を割り当てるサブスクリプションまたはリソース グループに移動します。

  2. 左側のナビゲーション メニューで、 Access control (IAM)を選択します。

  3. + Add > Add role assignment を選択します。

  4. [ Role ] タブで、 Enclave Approver Roleを検索して選択します。

  5. Next を選択します。

  6. [Members] タブで [+ Select members] を選択します。

  7. 承認者として指定するユーザー、グループ、またはサービス プリンシパルを検索して選択します。

  8. Nextを選択し、Review + assignします。

通知の動作

承認要求の通知が必要な場合は、Azureアクティビティ ログと組織のアラート ツールを使用して、独自の監視ワークフローを作成します。

Microsoft Entra Privileged Identity Management (PIM) との統合

セキュリティを強化するには、承認と PIM を組み合わせて、承認者に時間制限付きのアクセス許可を付与します。

エンクレーブ承認者ロール用の PIM を設定する

  1. Azure ポータルでMicrosoft Entra Privileged Identity Managementに移動します。

  2. Azure resources > Discover resources を選択します。

  3. コミュニティを含むサブスクリプションまたはリソース グループを選択します。

  4. [ロール] に移動し、[エンクレーブ承認者ロール] を検索します。

  5. [ Enclave Approver Role>Role settings>Edit] を選択します。

  6. ロールの設定を構成します。

    • Require approval to activate: この設定を有効にします。
    • Select approvers: 承認者アクセスの要求を承認できるユーザーを選択します。
    • Maximum activation duration:8 時間以下に設定します。
    • Require multifactor authentication: セキュリティを有効にします。
  7. Updateを選択して設定を保存します。

  8. 永続的に割り当てるのではなく、エンクレーブ承認者ロールの 対象 としてユーザーを割り当てます。

MICROSOFT ENTRA PIM 統合の詳細を確認する

承認構成のベスト プラクティス

環境内で承認を構成する場合:

  1. リスクの高い運用から始める: コミュニティ エンドポイントやトランジット ハブの変更など、最も重要な操作の承認を要求することから始めます

  2. 明確な承認ポリシーを定義する: 承認が必要な操作と承認の決定基準を文書化する

  3. 複数の承認者を割り当てる: 承認者が使用できない場合の遅延を防ぐために、少なくとも 2 人のユーザーにエンクレーブ承認者ロールがあることを確認します

  4. 承認者アクセスに Azure PIM を使用する: 機密性の高い環境に対して Just-In-Time ベースで承認者のアクセス許可を付与する

  5. 承認者ワークフローを計画する: 承認者が保留中の要求をすぐに確認できるように運用プロセスを定義する

  6. 定期的なレビュー: 承認が必要な操作を定期的に確認し、運用エクスペリエンスに基づいて設定を調整する

  7. ワークフローをテストする: 運用環境にロールアウトする前に、開発環境で承認ワークフローをテストします

承認の構成を確認する

承認を構成した後、セットアップが正しく動作していることを確認します。

  1. エンクレーブ共同作成者のアクセス許可を持つユーザーとして、承認を必要とするエンクレーブ接続の作成を試みます

  2. 接続が Pending 状態であることを確認します。

  3. エンクレーブ承認者のアクセス許可を持つユーザーは、左側のエンクレーブで Approvals を選択します。

  4. 保留中の要求が承認キューに表示されることを確認する

  5. 要求を承認し、接続がアクティブになったことを確認します

承認を無効にする

承認機能を無効にする必要がある場合:

Warning

承認を無効にすると、新しい承認要求を作成せずに新しい操作を続行できます。 既存の承認待ちリクエストはキューに残ります。 移行の問題を回避するには、変更プロセスの一環として、保留中の要求を確認して解決または取り消します。

  1. Azure ポータルでコミュニティ リソースに移動します。

  2. 左側のナビゲーション メニューで Configuration または Governance を選択します。

  3. Enable Approvals設定をOffに切り替えます。

  4. Saveを選択して変更を適用します。

Troubleshooting

承認者は保留中のリクエストを確認できない

原因: ユーザーがエンクレーブ承認者ロールを持っていないか、ロールが間違ったスコープで割り当てられています。

解決策: ユーザーがエンクレーブまたはコミュニティ レベルで割り当てられたエンクレーブ承認者ロールを持っていることを確認します。

承認された要求が実装されていない

原因: リソースの競合や、変更を実装するためのアクセス許可が不十分である可能性があります。

解決策: Azure アクティビティ ログでエラー メッセージを確認し、承認された変更を実装するために必要なアクセス許可がシステムにあることを確認します。

次のステップ