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

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

Important

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

前提条件

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

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

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

Azure portal にサインインする
Azure Enclave エンクレーブまたはコミュニティリソースに移動してください。
左側のナビゲーションメニューで、 Approvalsを選択します。
[承認] ページには、保留中、承認済み、拒否済みのすべての要求が表示されます。
フィルターを使用して、特定の種類の要求を表示します。
- Approval status: Pending、Approved、Rejected
- リクエスター:リクエストを提出した人でフィルタリングしてください
- Requested on: 申請の日付/時刻範囲でフィルター処理する
- Parent Resource: 関心のあるエンクレーブまたはコミュニティにフィルターを適用します。
- Action Type (ポータルエクスペリエンスに表示される場合): 要求された操作でフィルター処理します

承認要求を確認する

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

Approvalsリストで、確認したいリクエストのチェックボックスを選択し、Reviewを選択します。
承認の詳細ページが表示されます。
- Resource: 要求されたリソース
- Enclave または Community:リクエストに関連する親リソースへのリンク
- Requester: 要求を送信したユーザー
- Request date: 要求が送信されたとき
- Ticket Id: 変更追跡システムへのリンクを取るオプションフィールド
- Approvals: このリクエストを承認または拒否できます
- Approval status承認要件を満たしているかどうか。
- Approver details:誰がその要請を承認または拒否したかのリスト。
決定を下す前に、すべての情報を慎重に確認してください。

要求を承認する

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

承認の詳細ページで、 Approveを選択します。
Submitを選択して要求を承認します。
要求の状態が Approved され、リソースの変更が自動的に実装されます。

要求を拒否する

承認基準を満たさない場合は、拒否してください:

承認の詳細ページで、 Rejectを選択します。
Submitを選択して要求を拒否します。
要求の状態が Rejected に変わり、リソースの変更は実装されません。

一般的な承認シナリオ

エンクレーブ作成の承認

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

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

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

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

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

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

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

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

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

エンクレーブ接続の承認

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一括承認操作

承認ページは現在、一度に1つのリクエストに対して対応 すること をサポートしています。単一のリクエストを選択し、承認詳細ページで Approve または Reject をご利用ください。この体験では、マルチセレクトの一括承認・拒否オプションはありません。

承認履歴を表示する

承認済みおよび却下されたリクエストは、保留中のリクエストとともに同じ Approvals リストに残っています。

エンクレーブまたはコミュニティリソースに移動します。
左側のナビゲーションメニューで Approvals を選択します。
リストを以下で絞り込む:
- Approval status: 承認または拒否されたリクエストのみを閲覧。
- Requested on: 特定の期間内の承認を閲覧できます。
- Requester: 特定のユーザーから提出されたリクエストをご覧ください。
- Action Type: リソースタイプまたは操作でフィルタリング。
歴史的なリクエストを選択して詳細をご覧いただけます。

通知の動作

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

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

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

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

迅速に確認する: 正当な操作をブロックしないように、タイムリーに承認要求に応答する
明確なフィードバックを提供する: 要求を拒否する場合は、理由を説明し、再送信のガイダンスを提供します
ドキュメントの決定: 理由を説明する承認にコメントを追加する (特に複雑な意思決定の場合)
一貫性のある基準を使用する: 公平性を確保するために、同様の要求間で同じ承認基準を適用する
必要に応じてエスカレートする: 要求が不明な場合は、上級リーダーまたはセキュリティチームにエスカレートします
定期的な監査: 定期的に承認履歴を確認して、パターンや潜在的な問題を特定する
更新ポリシー: 承認パターンに基づいて、プロセスを改善するためのガバナンスポリシーを更新します
要求者と通信する: 複雑な要求の場合は、決定を下す前に要求者と話し合うことを検討してください

承認機関を委任する

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

エンクレーブまたはコミュニティの場合は、Access control (IAM) に移動します。
エンクレーブ承認者ロールを代理人に割り当てます。
一時的な委任の有効期限を設定します。
永続的な委任の場合は、適切な承認ワークフロー Azure PIM を使用することを検討してください。

ロールの割り当ての詳細

Troubleshooting

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

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

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

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

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

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

承認または拒否できない

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

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

次のステップ

フィードバック

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

Last updated on 2026-09-15