azure-role-selector

Azure ロールセレクター（RBAC 最小権限）

Azure RBAC は ロールの割り当て（セキュリティプリンシパル＋ロール定義＋ スコープ）を通じてアクセスを許可します。目標は 最小権限 です。ニーズを満たす最小限のロールを最も狭いスコープで適切な種類のプリンシパル（人にはグループ、ワークロードにはマネージド ID）に割り当て、特権ロールの場合は PIM を通じて有効期間を限定します。

使用する場面

ユーザー、グループ、サービスプリンシパル、マネージド ID に適切なロールを選ぶ場合、または既存の割り当てに過剰な権限がないか確認する場合に使用します。

このスキルは次の用途には使用しないでください：

• Entra ID の ディレクトリ ロール（Global Admin、User Admin など）（entra-id を使用）
• Microsoft 365 管理者ロール（m365-govern-manage を使用）
• 特権ロールのアクティブ化やアクセスレビューの設計（azure-pim を使用）
• マルチクラウドのエンタイトルメント管理（entra-permissions-management を使用）

適切なロールファミリーを選ぶ

呼び出し元のニーズ	確認するロール	避けるロール
ストレージ アカウントのプロパティ を読み取る	コントロールプレーン：Reader ／ Storage Account Contributor	Owner
Blob の内容 を読み取る	データプレーン：Storage Blob Data Reader	Reader のみ（データにはアクセスできません）
Blob の内容 を書き込む	データプレーン：Storage Blob Data Contributor	Owner ／ Contributor
Key Vault のシークレット を読み取る（RBAC モード）	データプレーン：Key Vault Secrets User	Key Vault Administrator
Key Vault 自体を管理する	コントロールプレーン：Key Vault Contributor	Owner
マネージド ID を使って Azure Function を実行する	対象リソースのデータロールのみ	Subscription Contributor
他のユーザーへのロール割り当てを委任する	狭いスコープでの User Access Administrator	Owner
サブスクリプション内のすべてを読み取る	サブスクリプションスコープの Reader	Owner ／ Contributor
1 つのリソースグループのみを管理する	リソースグループスコープの Contributor	Subscription Contributor

経験則： コントロールプレーンのロールでデータプレーンへのアクセスが自動的に許可されることはありません。 Reader を使うとストレージアカウントの存在は確認できますが、Blob を読み取ることはできません。適切なプレーンを明示的に選択してください。これは RBAC で最もよくある間違いです。

アプローチ

1. 必要な操作を正確に定義する - プリンシパルが実行する必要のある操作を正確に列挙します。リソースを管理するコントロールプレーン（作成、削除、一覧表示、構成）と、リソース内のデータを読み書きするデータプレーン（BLOB、シークレット、キューメッセージ、行）を区別します。 確認：要件を動詞とリソースの種類で記述します。たとえば、「ストレージにアクセスする」ではなく、「コンテナー X の BLOB の内容を読み取る」とします。
2. 最も具体的な組み込みロールを選ぶ - 要件を満たす Actions と DataActions を持つ、最も具体的な組み込みロールを優先します。組み込みロールは Microsoft が管理しており、サービスの機能追加に応じて進化します。本当に必要な場合を除き、広範なロール（Owner、Contributor）は避けてください。 確認：選択した組み込みロールの Actions／DataActions が必要なすべての操作をカバーし、不要な操作を含まないことを確認します（az role definition show を使用）。
3. カスタムロールか組み込みロールかを判断する - 要件に合う組み込みロールがない場合に限り、カスタムロールを作成します。最小限の Actions／DataActions と NotActions を定義し、JSON をソース管理でバージョン管理して、割り当て可能なスコープを固定します。 確認：要件を満たす組み込みロールがないことを確認してからカスタムロールを作成します。JSON がリポジトリにあり、変更履歴が残っていることを確認します。
4. スコープを最小限にする - 最も小さい有効なスコープで割り当てます。リソース ＞ リソースグループ ＞ サブスクリプション ＞ 管理グループの順です。1 つのコンテナーに対する Storage Blob Data Reader は、ストレージアカウントへの割り当てより安全であり、サブスクリプションへの割り当てよりも安全です。 確認：割り当てのスコープが要件を満たす最小の範囲であることを確認します。単一リソースに対するサブスクリプション全体への付与にはフラグを立てます。
5. ID とグループを優先する - ユーザーにはEntra グループ（ユーザーへの直接割り当てではなく）、ワークロードにはマネージド ID（可能な限り、シークレットを持つサービスプリンシパルではなく）を割り当てます。グループベースの割り当ては拡張性がありますが、ユーザーごとの割り当てにはありません。 確認：サブスクリプションスコープでユーザーへの直接割り当てがゼロであること、ワークロードがユーザーアカウントではなくマネージド ID を使用していることを確認します。
6. 特権ロールには PIM を組み合わせる - 広範なスコープでの Owner、User Access Administrator、Contributor、およびサブスクリプションスコープで書き込み権限を持つカスタムロールには、PIM による有効化を必須とします（適時有効化、MFA、適切な場合は承認、時間制限付き）。 確認：特権ロールの割り当てが Active ではなく Eligible であること、有効化に MFA が必要で、監査ログが生成されることを確認します。
7. 継続的にガバナンスを行う - 特権スコープで四半期ごとにアクセスレビューを実施し、Entra Permissions Management または PIM のアクティビティレポートで検出された未使用の割り当てを削除します。また、所有者が変わった際にはベースラインを再設定します。 確認：アクセスレビューの実施頻度が文書化されていること、未使用の割り当てレポートが確認され、対応されていることを確認します。

ガードレール

• Owner にはアクセスを付与する権限も含まれます - 厳しく制限し、委任が実際に必要な場合に限り User Access Administrator を優先します。Owner が適切な答えとなることはほとんどありません。
• コントロールプレーンのロール（Reader／Contributor）では、データプレーンへのアクセスは自動的に付与されません - データロールを明示的に選択します。「アカウントを確認し、BLOB を読み取る」には、Reader と Storage Blob Data Reader の組み合わせが適切です。
• 未使用の割り当てを確認して削除し、権限の高いロールには PIM とアクセスレビューを組み合わせます。恒常的な特権は、時間とともに攻撃対象領域を拡大させます。
• カスタムロールには保守の負担が伴います - Microsoft によるアクションカタログの変更で、カスタムロールが機能しなくなる可能性があります。本当に必要な場合を除き、組み込みロールを選んでください。
• ユーザー単位ではなく、グループベースで。 ユーザーへの直接割り当ては拡張性がなく、入社・異動・退職に対応できず、孤立した権限になります。
• 対象サービスがサポートしている場合は、シークレットを持つサービスプリンシパルよりもマネージド ID を優先します。ローテーションするシークレットも、漏えいするシークレットもありません。
• 要件を満たす最小単位のスコープで割り当てます。 「簡単だから」という理由でサブスクリプションにロールを割り当てるのは、来年のインシデントにつながる安易な対応です。

よくあるアンチパターン

• 「Blob データでは Reader が機能しないので、Owner が必要です。」 いいえ。必要なのは Storage Blob Data Reader（データプレーン）です。Owner を追加しても、問題の解決にはなりません。
• 組み込みロールをほぼそのまま複製したカスタムロールにアクションを 1 つ追加すること。組み込みロールをフォークして永続的に管理するのではなく、そのアクションだけを追加する割り当てを別途作成してください。
• サブスクリプションスコープでのユーザーごとの割り当て。 入社・異動・退職により孤立した割り当てが残り、後日監査を行う際には、その整理がプロジェクトになってしまいます。
• 自動化用サービスプリンシパルにサブスクリプション単位で Owner または Contributor を付与すること。 影響範囲がサブスクリプション全体に及びます。対象のリソースグループと、対象リソースに対するデータロールだけにスコープを限定してください。
• 恒常的な Owner ロール。 ロールが恒久的に本当に必要なら、通常は Owner ではなく、より限定的なロールで対応できます。Owner が本当に必要な場合は、PIM に含める必要があります。
• アクセスレビューの頻度を決めないこと。 見直しを促す仕組みがなければ、権限が縮小されることはありません。

プロンプトの例

• Which built-in Azure role gives least-privilege access to read blob data?
• Should I use a built-in or custom role for this scenario?
• Pick the minimal role for a managed identity to access a specific Key Vault secret.
• How do I scope a role assignment correctly for least privilege?
• Move privileged Owner assignments into PIM.

Microsoft Learn

• RBAC の概要：https://learn.microsoft.com/azure/role-based-access-control/overview
• 組み込みロール：https://learn.microsoft.com/azure/role-based-access-control/built-in-roles
• カスタムロール：https://learn.microsoft.com/azure/role-based-access-control/custom-roles
• RBAC のベストプラクティス：https://learn.microsoft.com/azure/role-based-access-control/best-practices
• ロールの割り当てについて：https://learn.microsoft.com/azure/role-based-access-control/role-assignments
• Storage のデータプレーンロール：https://learn.microsoft.com/azure/storage/blobs/authorize-access-azure-active-directory