承認により、重大なAzureエンクレーブ アクションに監視が追加されます。 承認を有効にすると、エンクレーブ キュー Azure、エンクレーブ承認者ロールを持つユーザーが要求を承認または拒否するまで、新しいリソースの作成または既存のリソースの変更を要求します。
承認の概要
Azure エンクレーブの承認により、リソースの作成と変更のためのガバナンス レイヤーが提供されます。 組織が承認されていない変更のリスクを軽減し、誤った構成を防ぎ、機密性の高い操作の監査証跡を保持するのに役立ちます。 承認ワークフローではロールベースのアクセス制御 (RBAC) Azure使用されるため、指定された承認者のみが要求を承認または拒否できます。
承認が必要になる可能性があるリソース アクションはどれですか
これらのリソース アクションにコミュニティの承認が必要かどうかを決定します。
- エンクレーブ の作成
- エンクレーブ エンドポイント の変更
- コミュニティ エンドポイント の変更
- エンクレーブ接続 の作成と更新
- エンクレーブの メンテナンス モード を有効にする
リソースの承認設定を設定する方法
承認設定は、コミュニティ レベルで対象となるリソースに対して設定できます。 コミュニティ所有者は、コミュニティの作成時に承認が必要なリソースを設定でき、ガバナンス要件の進化に合わせて後でこれらの設定を更新できます。
Azure エンクレーブで要求を承認できるユーザー
Azureエンクレーブの承認ワークフローでは、承認された個人またはグループのみが要求を承認できるように、Azure RBAC が使用されます。 承認者は、責任と組織の承認要件に基づいて明示的に割り当てられます。
一般的な承認者には、管理者、テナント所有者、指定されたセキュリティまたはサイバー担当者、部署の利害関係者、カスタム承認者グループ、または承認担当者が含まれます。
要件に基づいて承認者を柔軟に定義できます。 適切な権限とコンテキストを持つユーザーのみが要求を検証できることを確認し、Azure エンクレーブでのデプロイと構成に対する厳密な制御を維持できます。
承認者を指定する方法
- 承認者ロールを付与するリソースに移動し、左側のウィンドウで
Access Control (IAM)を選択します。 - [
Add] を選択し、[Add role assignment] を選択します。 -
Enclave Approver Roleを検索して選択し、Nextを選択します。 -
Select Members選択し、承認者にするユーザーまたはグループを検索して選択し、Nextを選択します。 - 最後の画面で、
Review + Assignを選択します。 選択したメンバーが承認者ロールを取得します。
承認に関する FAQ
承認に関してよく寄せられる質問 (FAQ) の一部を次に示します。
1. 承認要求を表示するにはどうすればよいですか?
承認ビューは、[ 監視 ] の下の 3 つの場所から使用できます。
- Azure エンクレーブ ホーム ページ
- [コミュニティ] ページ
- エンクレーブ ページ
これらのいずれかの場所で Approvals を選択すると、承認者ロールを持っていれば、対象範囲が限定された承認リクエストを表示できます。 承認の状態、展開の状態、要求者など、承認要求の詳細を表示することもできます。 ページの上部にあるフィルターを使用して、要求一覧を調整します。
2. 承認要求を確認する方法
承認ページに移動し、承認待ちのリクエストと以前のリクエストを確認します。 一度に確認できる要求は 1 つだけであることに注意してください。 要求はすべてのユーザーに表示されますが、承認者ロールを持つユーザーのみが承認または拒否できます。
要求を確認するには:
- 承認要求を選択します。
- ヘッダーの
Reviewを選択して、承認の詳細ウィンドウを開きます。 - 詳細ウィンドウで、承認要求の対象となるリソースを確認します。 基になる変更を表示するには、リソース名を選択し、特定の変更を確認します。
- 前の画面に戻り、
ApprovedまたはDeniedを選択し、Submitを選択します。 - 選択した承認アクションに基づいてデプロイが開始されます。
3. 自分の要求を承認できますか?
No. 独自の要求の承認は許可されません。 承認者であっても、他のユーザーからの承認が必要です。 自己承認は許可されないため、各変更は複数のユーザーからレビューを受け取ります。
4. 誤って発生した要求を削除できますか?
削除できるのは、保留中の状態の要求のみです。 既に承認または拒否されている要求は削除できません。 削除された要求のメタデータは、監査目的でログに残ります。
5. 承認要求にチケット ID を添付するにはどうすればよいですか?
- 承認要求に移動し、
Reviewを選択します。 -
Ticket IDというフィールドを表示します。 -
Add Ticket IDを選択します。 - フィールドにチケット ID を入力し、
Saveを選択します。 - チケット ID を更新するには、
Editを選択します。
Important
[チケット ID] フィールドに個人データや個人情報を入力しないでください。
6. 承認はテンプレートやその他のコードとしてのインフラストラクチャ (IaC) で機能しますか?
Yes. エンクレーブの作成、メンテナンス モードの変更、エンクレーブ接続の作成と更新、エンクレーブ エンドポイントの更新、コミュニティ エンドポイントの更新に対して承認を有効にすることができます。 保留中のリソース (エンクレーブ エンドポイントなど) に依存する子リソースは、保留中のリソースの構成情報が使用できないため、デプロイに失敗する可能性があります。 この状況では、子リソースをデプロイする前に、承認者が保留中のリソースのデプロイを確認して完了できるように、リソースのデプロイを調整します。 この方法では、必要な承認が完了した後に開始される複数の手順またはスクリプトにデプロイを分割することが必要になる場合があります。
7. 承認設定を変更した場合、既存の保留中の承認要求はどうなりますか?
承認設定は、要求の作成時に承認要求に適用されます。 承認設定の変更は、今後の承認要求にのみ適用されます。 新しい承認設定を適用するには、既存の保留中の承認リクエストをキャンセルまたは却下できます。
たとえば、新しいエンクレーブに対して 1 人の承認者を必要とする承認設定を持つコミュニティを考えてみましょう。 新しいエンクレーブを作成して承認要求を作成すると、承認設定が適用され、その要求には 1 人の承認者が必要です。 コミュニティまたはエンクレーブの承認設定が変更され、2 番目に必要な承認者が追加された場合、既存のエンクレーブ承認要求では、新しい承認者は必要ありません。 まだ元の承認者1名が必要です。
