Azure エンクレーブで承認要求を管理する

この記事では、Azure エンクレーブで承認要求を確認、承認、拒否する方法について説明します。 エンクレーブ承認者ロールを持つユーザーは、承認要求を管理して、重要なインフラストラクチャの変更を適切に監視できます。

前提条件

承認要求を管理するには、次のものが必要です。

• エンクレーブまたはコミュニティ レベルで割り当てられたエンクレーブ承認者ロール
• Azure portal または Azure CLI へのアクセス
• 承認要求に関連するリソースを表示するためのアクセス許可

承認待ちの要求を表示する

1. Azure portal にサインインする

2. Azure Enclave エンクレーブまたはコミュニティ リソースに移動してください。

3. 左側のナビゲーション メニューで、 Approvalsを選択します。

4. [承認] ページには、保留中、承認済み、拒否済みのすべての要求が表示されます。

5. フィルターを使用して、特定の種類の要求を表示します。

   • Approval status: Pending、Approved、Rejected
   • Requestor: 要求を送信したユーザーでフィルター処理します
   • Requested on: 申請の日付/時刻範囲でフィルター処理する
   • Parent Resource: 関心のあるエンクレーブまたはコミュニティにフィルターを適用します。
   • Action Type (ポータル エクスペリエンスに表示される場合): 要求された操作でフィルター処理します

承認要求を確認する

要求を承認または拒否する前に、詳細を慎重に確認してください。

1. Approvalsの一覧で、確認する要求を選択します。

2. 承認の詳細ページが表示されます。

   • Request type: リソースまたは操作の種類 (たとえば、 Enclave Connection)
   • Requested by: 要求を送信したユーザー
   • Request date: 要求が送信されたとき
   • Resource details: 作成または変更されるリソースに関する情報
   • Justification: 要求元によって提供された理由 (使用可能な場合)
   • Impact assessment: 要求を承認した場合の潜在的な影響
   • Security considerations: 変更によるセキュリティへの影響

3. 決定を下す前に、すべての情報を慎重に確認してください。

要求を承認する

要求を確認したら、それを承認して変更を続行できるようにします。

1. 承認の詳細ページで、 Approveを選択します。

2. 承認ダイアログで、次の手順を実行します。

   • Add comments (省略可能): 承認のコンテキストまたは条件を指定します

3. Confirmを選択して要求を承認します。

4. 要求の状態が Approved され、リソースの変更が自動的に実装されます。

要求を拒否する

要求が承認基準を満たしていない場合は、明確な説明で拒否します。

1. 承認の詳細ページで、 Rejectを選択します。

2. 拒否ダイアログで、次の手順を実行します。

   • Reason for rejection (必須): 要求が拒否される理由を説明する
   • Suggestions (省略可能): 要求を再送信する方法に関するガイダンスを提供する

3. Confirmを選択して要求を拒否します。

4. 要求の状態が Rejected に変わり、リソースの変更は実装されません。

一般的な承認シナリオ

エンクレーブ作成の承認

エンクレーブ作成要求を確認する場合:

1. 目的と所有権を検証する: エンクレーブに明確なビジネス目的と責任ある所有者があることを確認する
2. 配置とスコープを確認する: 適切なコミュニティとスコープでエンクレーブが作成されていることを確認します
3. ベースラインのセキュリティの期待を確認する: 必要なガバナンスとセキュリティ制御が計画されていることを確認する
4. 名前付けとライフサイクルの標準を確認する: 名前付け、タグ付け、ライフサイクルの要件との整合性を検証する

承認の例: "承認済み。 新しいエンクレーブは、承認済みのワークロード オンボード 計画をサポートし、所有権とガバナンスの要件を満たしています。"

拒否の例: "Rejected. エンクレーブの目的と所有権が不完全です。 再提出する前に、説明責任を負う所有者と更新されたデプロイの正当な理由を提供してください。」

メンテナンス モードの変更の承認

メンテナンス モード要求を確認する場合:

1. メンテナンス期間の確認: 承認されたメンテナンス期間に合わせて変更を確認する
2. 影響のコミュニケーションを検証する: 影響を受ける関係者に情報を提供する
3. ロールバック/準備計画を確認する: 明確なロールバックまたは完了計画があることを確認する
4. 運用リスクの評価: 承認前にサービスと依存関係の影響を確認する

承認の例: "承認済み。 メンテナンス モードは、文書化されたロールバック 計画を使用して、承認済みの変更ウィンドウでスケジュールされます。"

拒否の例: "Rejected. メンテナンス期間とサービス効果プランがありません。 運用準備の詳細を追加して再送信します。"

エンクレーブ接続の承認

エンクレーブ接続要求を確認する場合:

1. ソースと宛先を確認する: 承認されたエンクレーブまたは外部エンドポイント間の接続であることを確認します
2. ネットワーク規則の確認: ファイアウォール規則とネットワーク セキュリティ グループの構成を確認する
3. ビジネス上の正当な理由を検証する: 接続に正当なビジネス ニーズがあることを確認する
4. セキュリティへの影響を評価する: 接続によってセキュリティ リスクが発生するかどうかを評価する
5. コンプライアンス要件を確認する: 接続が組織のコンプライアンス標準を満たしていることを確認する

承認の例: "承認済み。 ログの集約を一元化するには、運用とログ エンクレーブの間の接続が必要です。 セキュリティ チームがファイアウォール規則を検証しました。"

拒否の例: "Rejected. 外部エンドポイントへの接続には、より多くのセキュリティ レビューが必要です。 再提出する前に、詳細なセキュリティ評価を送信し、InfoSec の承認を得る。

エンクレーブ エンドポイントの承認

エンクレーブ エンドポイント要求を確認する場合:

1. エンドポイント ルールを確認する: 追加または変更されているネットワーク ルールを確認する
2. 許可/拒否されたトラフィックを確認する: エンドポイントの制御がセキュリティ ポリシーと一致していることを確認する
3. 過度に制限の緩い規則を確認する: 過剰なアクセスを許可する可能性がある規則を探します
4. コンプライアンスの検証: エンドポイント構成がコンプライアンス要件を満たしていることを確認する

承認の例: "承認済み。 エンドポイントの構成は最小特権の原則に従い、ネットワーク セキュリティ チームはこの要求を確認しました。"

拒否の例: "Rejected. エンドポイントは、セキュリティ ポリシーに違反する 0.0.0.0/0 からのトラフィックを許可します。 特定の IP 範囲に制限し、再送信してください。

コミュニティ エンドポイントの承認

コミュニティ エンドポイント要求を確認する場合:

1. 外部接続を評価する: 外部の宛先が信頼されており、必要であることを確認する
2. トランジット ハブの構成を確認する: VPN または ExpressRoute が関係している場合は、適切な構成を確認します
3. ファイアウォール規則の確認: Azure Firewall規則が適切に制限されていることを確認する
4. サード パーティのアクセスを検証する: 外部パーティへのアクセスを許可する場合は、適切な承認を確認します

承認の例: "承認済み。 パートナーシップ契約で指定されているデータ交換には、パートナー ネットワークへの VPN 接続が必要です。 接続は IPsec で適切にセキュリティ保護されています。"

拒否の例: "Rejected. 外部接続には、最高情報セキュリティ責任者 (CISO) からの承認が必要です。 書面による承認を得て、要求に添付してください。

一括承認操作

複数の関連する要求に対して、一括操作を実行できます。

承認履歴を表示する

コンプライアンスと監査証跡を維持するために、すべての承認決定の履歴を確認できます。

通知の動作

承認機能では、現在、承認要求に組み込みの電子メール通知オプションは提供されていません。

組織の監視および運用プロセスを活用して、保留中の承認を追跡し、優先順位を付けて対応します。

承認管理のベスト プラクティス

承認要求を管理する場合:

1. 迅速に確認する: 正当な操作をブロックしないように、タイムリーに承認要求に応答する

2. 明確なフィードバックを提供する: 要求を拒否する場合は、理由を説明し、再送信のガイダンスを提供します

3. ドキュメントの決定: 理由を説明する承認にコメントを追加する (特に複雑な意思決定の場合)

4. 一貫性のある基準を使用する: 公平性を確保するために、同様の要求間で同じ承認基準を適用する

5. 必要に応じてエスカレートする: 要求が不明な場合は、上級リーダーまたはセキュリティ チームにエスカレートします

6. 定期的な監査: 定期的に承認履歴を確認して、パターンや潜在的な問題を特定する

7. 更新ポリシー: 承認パターンに基づいて、プロセスを改善するためのガバナンス ポリシーを更新します

8. 要求者と通信する: 複雑な要求の場合は、決定を下す前に要求者と話し合うことを検討してください

承認機関を委任する

場合によっては、承認機関を一時的に委任することが必要になる場合があります。

1. エンクレーブまたはコミュニティの場合は、Access control (IAM) に移動します。

2. エンクレーブ承認者ロールを代理人に割り当てます。

3. 一時的な委任の有効期限を設定します。

4. 永続的な委任の場合は、適切な承認ワークフロー Azure PIM を使用することを検討してください。

ロールの割り当ての詳細

Troubleshooting

承認待ちのリクエストが表示されない

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

解決策: 適切なレベル (エンクレーブまたはコミュニティ) でエンクレーブ承認者ロールが割り当てられていることを管理者に確認します。

承認された要求が実装されていません

原因: リソースに競合があるか、デプロイを完了するためのアクセス許可が不十分である可能性があります。

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

承認または拒否できない

原因: 別の承認者が要求を既に処理したかどうか、またはアクセス許可の問題があるかどうかを確認します。

解決策: ページを更新して現在の状態を確認します。 問題が解決しない場合は、ロールの割り当てを確認します。

次のステップ

• 承認の設定
• 承認機能について説明します
• Azure Enclave RBAC を理解する
• Just-In-Time アクセスを構成する
• エンクレーブ接続を作成する