Azure built-in roles for Security – Azure RBAC の更新で最初に確認すべきことは、「自社のAzure環境で誰がどのセキュリティ系組み込みロールを持っているか」と「そのロールを前提にした運用・自動化が、過剰権限または権限不足になっていないか」です。
この公式リファレンスは、Microsoft AzureのAzure RBACに用意されているSecurityカテゴリの組み込みロールを、Actions、NotActions、DataActions、NotDataActionsの単位で確認するための資料です。単なるロール一覧ではなく、Defender for Cloud、Key Vault、Microsoft Sentinel、Managed HSMなどの運用権限に直結します。2026年6月3日時点の情報として確認するなら、管理者は「割り当て済みロールの棚卸し」「Key Vaultの権限モデル」「Security AdminやSecurity Readerの影響範囲」「IaCやCI/CDで使っているロール名・ロールID」を優先して点検すべきです。(Microsoft Learn)
Microsoft Azureのセキュリティ更新でまず押さえるべき結論
Azure built-in roles for Securityの確認は、すぐに全環境で移行作業が必要になるタイプの更新ではありません。ただし、組み込みロールはMicrosoft側の定義変更により、既存のロール割り当ての実効権限に影響する可能性があります。
特に注意すべきなのは、次のような環境です。
| 確認対象 | 影響が出やすいケース | 最初に見るポイント |
|---|---|---|
| Security Admin / Security Reader | Defender for Cloudの推奨事項、アラート、ポリシー管理を運用している | 閲覧だけでよい担当者に更新権限まで与えていないか |
| Key Vault関連ロール | シークレット、証明書、暗号鍵をアプリやCI/CDから利用している | 管理プレーンとデータプレーンの権限を混同していないか |
| Microsoft Sentinel関連ロール | SOC運用、インシデント対応、プレイブック自動化を行っている | Sentinel ContributorやResponderで足りるか、追加権限が必要か |
| App Compliance Automation関連ロール | コンプライアンス自動化を利用している | */read を含む広い読み取り権限を許容できるか |
| カスタムロール | 組み込みロールをコピーして独自ロールを作っている | 最新の組み込みロールとの差分を放置していないか |
| IaC・CI/CD | Terraform、Bicep、ARMテンプレート、Azure CLIでロールを割り当てている | ロール名依存ではなくロールIDを使っているか |
対応の基本方針は、「広い権限を急いで付け足す」ことではありません。まず現状の割り当てを可視化し、最小権限の原則に沿って、必要な範囲・必要なロール・必要なスコープに絞ることが重要です。MicrosoftもAzure RBACのベストプラクティスとして、ユーザーに必要なアクセスだけを付与し、広いスコープで強い権限を与えすぎないことを推奨しています。(Microsoft Learn)
Azure built-in roles for Securityとは
Azure built-in roles for Securityは、Azure RBACで利用できる組み込みロールのうち、Securityカテゴリに分類されるロール群です。たとえば、Security Admin、Security Reader、Key Vault Administrator、Key Vault Secrets User、Microsoft Sentinel Contributorなどが含まれます。
Azure RBACのロール定義は、主に次の要素で構成されます。
| 項目 | 意味 | 実務での見方 |
|---|---|---|
| Actions | Azureリソースの管理操作を許可する項目 | リソース作成、設定変更、読み取りなどの管理プレーン操作 |
| NotActions | Actionsから除外する管理操作 | ただし「拒否」ではないため、別ロールで許可される可能性がある |
| DataActions | データそのものへの操作を許可する項目 | Key Vaultのシークレット取得、キーによる暗号化・復号など |
| NotDataActions | DataActionsから除外するデータ操作 | データプレーンの権限調整に使われる |
| AssignableScopes | そのロールを割り当て可能なスコープ | サブスクリプション、リソースグループ、個別リソースなど |
ここで重要なのは、Azureの権限には「管理プレーン」と「データプレーン」があることです。管理プレーンの権限があるからといって、必ずしもデータそのものにアクセスできるわけではありません。逆に、データプレーン権限を付けると、アプリケーションがシークレットやキーを利用できるようになるため、情報漏えいや不正利用の影響が大きくなります。Microsoftのロール定義ドキュメントでも、ActionsとDataActionsは分けて扱われ、管理プレーンのアクセスがデータプレーンへ自動的に継承されない考え方が説明されています。(Microsoft Learn)
今回の更新で管理者が注目すべき変更点
今回確認すべきポイントは、「Securityカテゴリのロール一覧がある」こと自体ではなく、各ロールの実効権限を最新の定義で確認できることです。特に、以下のロール群は実運用への影響が大きいため、割り当て状況と用途を見直す価値があります。
Security AdminはDefender for Cloud運用の強い権限を持つ
Security Adminは、Microsoft Defender for Cloudの推奨事項やアラート、セキュリティポリシーなどを扱うための強いロールです。現行の定義では、Microsoft.Security/* に加えて、IoT SecurityやIoT Firmware Defense関連の操作も含まれています。Security Readerは閲覧向けですが、Security Adminはポリシー変更やセキュリティ運用上の更新操作に関わります。(GitHub)
Defender for Cloudの運用では、Security Adminによりセキュリティポリシーの編集、Defenderプランの有効化・無効化、アラートの却下、推奨事項の除外などが可能になります。これは便利な一方で、監視結果を変更できる権限でもあります。SOC担当者、クラウド管理者、監査担当者を同じロールでまとめると、職務分掌が崩れる可能性があります。(Microsoft Learn)
判断基準はシンプルです。
| 担当者の役割 | 推奨される考え方 |
|---|---|
| 監査・確認だけを行う | Security Readerを優先する |
| Defender for Cloudの設定やポリシーを変更する | Security Adminを検討する |
| すべてのAzure管理も必要 | OwnerやContributorが本当に必要か個別に判断する |
| 自動修復やポリシー適用を行う | マネージドIDや追加ロールの影響も確認する |
Security Adminを付与する前に、「その人はアラートや推奨事項を変更してよいのか」「ポリシー例外を作成してよいのか」を確認してください。閲覧だけでよい担当者にSecurity Adminを与えるのは、典型的な過剰権限です。
Security Manager (Legacy) は新規採用しない
Securityカテゴリには、Security Manager (Legacy) というレガシーロールも掲載されています。公式リファレンスでは、このロールはレガシー扱いであり、代わりにSecurity Adminを使用するよう示されています。(Microsoft Learn)
既存環境でSecurity Manager (Legacy) が割り当てられている場合、すぐ削除するのではなく、次の順番で確認します。
| 手順 | 確認内容 |
|---|---|
| 現状把握 | どのユーザー、グループ、サービスプリンシパルに割り当てられているか |
| 用途確認 | Defender for Cloud、古い自動化、監査スクリプトで使われていないか |
| 代替検討 | Security Admin、Security Reader、より限定的なカスタムロールで代替できるか |
| 検証 | 非本番環境でロール変更後の操作可否を確認する |
| 切り替え | 変更日、影響範囲、ロールバック手順を残して本番反映する |
「Legacy」とあるから即削除、ではなく、依存関係を確認してから段階的に置き換えるのが安全です。
Key Vault関連ロールは管理プレーンとデータプレーンを分けて確認する
Key Vault関連ロールは、今回の確認で最も見落としやすい領域です。Key Vaultには、Key Vault自体を作成・変更する管理プレーンと、シークレット・キー・証明書にアクセスするデータプレーンがあります。
たとえば、Key Vault ContributorはKey Vaultリソースの管理には使えますが、シークレット、キー、証明書の中身にはアクセスできません。一方、Key Vault AdministratorはKey Vault内のデータプレーン操作を広く実行できますが、Key Vaultリソースそのものの管理やロール割り当て管理までは含まれません。(Microsoft Learn)
Key Vaultの代表的なロールは、次のように使い分けます。
| ロール | 主な用途 | 注意点 |
|---|---|---|
| Key Vault Contributor | Key Vaultリソースの作成・設定管理 | シークレットやキーの中身にはアクセスできない |
| Key Vault Reader | Key Vaultの設定やメタデータ確認 | シークレット値を取得する用途には使わない |
| Key Vault Secrets User | アプリがシークレット値を取得する | 人間の管理者ではなく、マネージドID向きのケースが多い |
| Key Vault Administrator | Key Vault内のキー、シークレット、証明書を広く管理 | 権限が強いため常時付与は避ける |
| Key Vault Data Access Administrator | Key Vaultデータアクセス用ロールの割り当て管理 | ABAC条件により、特定のKey Vaultデータプレーンロールに限定される |
Key Vaultで特に危険なのは、「Contributorだから中身は見えないはず」とだけ考えてしまうことです。Key Vaultをアクセスポリシーモデルで運用している場合、Key Vaultに対するContributor相当の権限を持つユーザーがアクセスポリシーを変更し、自分にデータプレーンアクセスを付与できる可能性があります。Microsoftは、Key VaultのAzure RBAC権限モデル利用や、Contributor権限の厳格な管理を推奨しています。(Microsoft Learn)
Microsoft Sentinel関連ロールは「できない操作」も確認する
Microsoft Sentinel関連のロールでは、Contributor、Reader、Responder、Automation Contributor、Playbook Operatorなどの使い分けが重要です。Sentinel Contributorは多くのSentinel操作を実行できますが、Confidential Watchlists関連など、一部の操作はNotActionsで除外されています。Sentinel Responderもインシデント対応向けですが、削除操作や機密ウォッチリスト関連の操作は制限されています。(GitHub)
現場でよく起きるのは、「Sentinel Contributorを付けたのに一部の操作ができない」という混乱です。この場合、ロールのActionsだけでなくNotActionsを確認してください。
| 症状 | 確認すること |
|---|---|
| インシデントは見えるが削除できない | ResponderやContributorのNotActionsに該当していないか |
| プレイブックを実行できない | Sentinelロールとは別にLogic Apps側の権限が足りているか |
| Watchlistの一部が扱えない | Confidential Watchlists関連が除外されていないか |
| クエリ実行に失敗する | Log Analyticsワークスペース側の権限も確認する |
SentinelはAzure RBACだけで完結しない場面があります。Log Analyticsワークスペース、Logic Apps、マネージドID、接続先サービスの権限まで含めて確認することが重要です。
App Compliance Automation関連ロールは広い読み取り権限を理解する
App Compliance Automation AdministratorとApp Compliance Automation Readerは、名前だけを見るとコンプライアンス機能に限定されたロールに見えます。しかし、公式リファレンスでは、Azureリソースのコントロールプレーン情報を読み取るための広い */read が含まれることが示されています。(Microsoft Learn)
これは、設定情報やリソース構成を横断的に確認する必要があるためです。一方で、監査・委託・外部ベンダー向けに付与する場合は、「読み取りだけだから安全」と安易に判断しないほうがよいでしょう。リソース名、構成、ネットワーク情報、セキュリティ設定などの読み取りが、組織にとって機微情報になることがあります。
影響範囲：誰が何を確認すべきか
Azure built-in roles for Securityの更新確認は、クラウド管理者だけの作業ではありません。セキュリティチーム、開発チーム、運用自動化を担当するSREやDevOpsチームにも関係します。
| 立場 | 確認すべきこと | 放置した場合のリスク |
|---|---|---|
| Azure管理者 | Securityカテゴリのロール割り当て一覧 | 退職者、異動者、不要なグループに強い権限が残る |
| セキュリティ担当者 | Security AdminとSecurity Readerの使い分け | 監査担当者が設定変更できてしまう |
| 開発者 | アプリのマネージドIDに付与されたKey Vaultロール | 本番シークレットに過剰アクセスできる |
| DevOps担当者 | CI/CDで使用するサービスプリンシパルのロール | デプロイ失敗、または過剰権限のまま運用される |
| SOC担当者 | Sentinel、Defender for Cloud、Log Analyticsの権限 | インシデント対応時に必要な操作ができない |
| 監査担当者 | カスタムロールと組み込みロールの差分 | 古い権限定義が残り、説明責任を果たせない |
特に本番環境では、人間ユーザーよりもサービスプリンシパルやマネージドIDの権限が見落とされがちです。GitHub Actions、Azure DevOps、Terraform Cloud、社内ジョブサーバーなどからAzureを操作している場合は、実行主体ごとのロール割り当てを必ず確認してください。
管理者が確認すべき設定と具体的な手順
最初に行うべき作業は、Securityカテゴリの組み込みロールをすべて覚えることではありません。実際に自社環境で割り当てられているロールを洗い出し、業務上必要な権限かどうかを判断することです。
ロール割り当てを棚卸しする
Azure CLIを使う場合、まず対象スコープでロール割り当てを確認します。
az role assignment list \
--scope "/subscriptions/<subscription-id>" \
--include-inherited \
--output table特定のロールだけ確認したい場合は、jqなどで絞り込みます。
az role assignment list \
--scope "/subscriptions/<subscription-id>" \
--include-inherited \
--output json \
| jq '.[] | select(.roleDefinitionName=="Security Admin" or .roleDefinitionName=="Security Reader")'Key Vaultの割り当てを確認する場合は、Key Vaultリソースのスコープで確認します。
az role assignment list \
--scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>" \
--include-inherited \
--output table確認時の判断基準は次の通りです。
| 確認項目 | 判断基準 | 対応例 |
|---|---|---|
| 個人ユーザーに強いロールが付いている | 常時必要か、緊急時だけでよいか | グループ管理やPIM利用を検討する |
| サブスクリプション全体に割り当てられている | リソースグループや個別リソースに絞れないか | スコープを縮小する |
| 使途不明のサービスプリンシパルがある | CI/CD、監視、外部連携で使われているか | 所有者と用途を特定する |
| Legacyロールがある | 代替ロールで運用可能か | 検証後に段階的に置き換える |
| カスタムロールがある | 最新の組み込みロールとの差分があるか | 必要に応じて定義を更新する |
ロール定義の中身を確認する
ロール名だけでは、実際に何ができるか判断できません。Actions、NotActions、DataActions、NotDataActionsを確認します。
az role definition list \
--name "Security Admin" \
--output jsonPowerShellを使う場合は、次のように確認できます。
Get-AzRoleDefinition -Name "Security Admin" | ConvertTo-Json -Depth 10確認するときは、Actionsだけで判断しないでください。NotActionsはActionsから除外される操作を示します。ただし、NotActionsは明示的な拒否ルールではありません。別のロール割り当てで同じ操作が許可されている場合、そのユーザーは操作できる可能性があります。(Microsoft Learn)
つまり、「このロールでは除外されているから安全」と考えるのではなく、そのユーザーやグループに付いている全ロールを合算して評価する必要があります。
Key Vaultの権限モデルを確認する
Key Vaultでは、Azure RBAC権限モデルを使っているか、従来のアクセスポリシーモデルを使っているかで確認ポイントが変わります。
az keyvault show \
--name <vault-name> \
--query properties.enableRbacAuthorization \
--output tsvtrue の場合はAzure RBAC権限モデル、false の場合はアクセスポリシーモデルです。
アクセスポリシーモデルからAzure RBAC権限モデルへ切り替える場合は、必ず事前に同等のロール割り当てを用意してください。Microsoftのドキュメントでは、RBAC権限モデルへ変更すると既存のアクセスポリシーが無効化され、適切なロール割り当てがないと障害につながる可能性があると説明されています。(Microsoft Learn)
切り替え前には、少なくとも次の確認が必要です。
| 確認項目 | 具体例 |
|---|---|
| アプリが使うシークレット | App Service、Functions、AKS、VMのマネージドIDがSecrets User相当の権限を持つか |
| 証明書更新処理 | 証明書の読み取り、更新、インポートに必要なロールがあるか |
| 暗号化処理 | Key Vault Crypto Userなど、暗号化・復号に必要なDataActionsがあるか |
| 運用管理者 | Key Vault AdministratorやData Access Administratorが過剰に広く付いていないか |
| ロール反映時間 | 変更直後に失敗しても、権限伝播待ちの可能性を考慮しているか |
移行・展開時に失敗しやすいポイント
ロール名だけに依存したスクリプトを使っている
Azure RBACの自動化では、ロール名ではなくロールIDを使うほうが安全です。Microsoftのドキュメントでも、ロール名が変更されてもスクリプトが壊れないよう、ロールIDの利用が推奨されています。(Microsoft Learn)
たとえば、Bicep、Terraform、ARMテンプレート、Azure CLIのスクリプトで次のような実装をしている場合は注意が必要です。
az role assignment create \
--assignee <principal-id> \
--role "Security Reader" \
--scope "/subscriptions/<subscription-id>"短期的には動作しますが、長期運用ではロールIDを使うほうが変更に強くなります。特に複数テナント、複数サブスクリプションに展開する基盤コードでは、ロール名依存を減らしてください。
組み込みロールをコピーしたカスタムロールが古い
過去にSecurity AdminやKey Vault関連ロールを参考にしてカスタムロールを作った場合、そのカスタムロールは自動更新されません。組み込みロール側に新しいリソースプロバイダーやアクションが追加されても、カスタムロールには反映されないため、次のような問題が起きます。
| 問題 | 例 |
|---|---|
| 操作できない | 新しいDefender for Cloud機能のアクションがカスタムロールに含まれていない |
| 権限が広すぎる | 過去に暫定追加した */read や Microsoft.Security/* が残っている |
| 監査で説明できない | なぜそのActionを許可しているのか記録がない |
| 自動化が失敗する | 新しいAPI操作に必要な権限が不足する |
カスタムロールは「一度作ったら終わり」ではありません。公式の組み込みロール定義と定期的に比較し、差分をレビューする運用が必要です。
Defender for Cloudの自動修復で追加権限を見落とす
Defender for Cloudでは、推奨事項の修復やエージェント・拡張機能の自動構成に、ポリシー修復やマネージドIDが関わることがあります。Microsoftの説明では、Security Adminによる自動構成では、サブスクリプションレベルのロールを持つマネージドIDが作成される場合があります。(Microsoft Learn)
そのため、Defender for Cloudの設定変更時は、画面上の操作権限だけでなく、裏側で作成・利用されるIDの権限も確認してください。
確認するポイントは次の通りです。
| 確認対象 | 理由 |
|---|---|
| システム割り当てマネージドID | 自動修復やポリシー適用で利用される可能性がある |
| ユーザー割り当てマネージドID | 複数リソースで使い回されると影響範囲が広がる |
| サブスクリプションスコープのロール | 影響範囲が大きく、侵害時の被害が広がりやすい |
| ポリシー割り当て | Security Adminの操作がAzure Policy側に波及することがある |
本番環境でいきなりロールを削除する
過剰権限を見つけたとき、すぐに削除したくなりますが、本番環境では危険です。特にKey Vault、Sentinel、Defender for Cloud、CI/CDのロールは、見た目以上に依存関係があります。
安全な進め方は次の順番です。
| フェーズ | 作業内容 |
|---|---|
| 調査 | ロール割り当て、利用者、対象スコープを一覧化する |
| 分類 | 人間ユーザー、グループ、サービスプリンシパル、マネージドIDに分ける |
| 影響確認 | 直近のサインイン、監査ログ、CI/CD実行履歴を確認する |
| 代替設計 | より狭いロール、狭いスコープ、PIM運用を検討する |
| 検証 | 非本番環境または限定スコープで操作テストを行う |
| 反映 | 変更日時、担当者、ロールバック手順を記録して適用する |
特にKey Vaultの権限変更では、アプリケーションの起動、証明書更新、シークレット取得、暗号化・復号処理を実際にテストしてください。設定画面で権限が正しく見えていても、実行主体が違えば失敗することがあります。
開発者が確認すべきポイント
開発者にとって重要なのは、「自分がAzure Portalで見えるか」ではなく、「アプリケーションやデプロイパイプラインが必要な操作を最小権限で実行できるか」です。
マネージドIDに人間向けの強いロールを付けない
アプリケーションがKey Vaultからシークレットを読むだけなら、Key Vault Administratorは不要です。多くの場合、Key Vault Secrets Userなど、目的に合ったデータプレーンロールを個別リソースのスコープで付与するほうが安全です。
悪い例は、動作確認を急ぐためにサブスクリプション全体へContributorやKey Vault Administratorを付与することです。最初は便利ですが、後から削るのが難しくなります。
良い設計は次のような形です。
| 用途 | 推奨される設計例 |
|---|---|
| WebアプリがDB接続文字列を取得する | App ServiceのマネージドIDに、対象Key VaultだけでKey Vault Secrets Userを付与 |
| バッチ処理が暗号化キーを使う | 対象Key Vaultのキーに必要なCrypto系ロールを付与 |
| CI/CDがKey Vaultを作成する | デプロイ用IDにリソースグループ単位で必要な管理プレーン権限を付与 |
| 証明書更新ジョブが証明書を操作する | 証明書操作に必要なKey Vaultロールを限定付与 |
CI/CDのロール変更はデプロイ単位で検証する
Azure RBACの変更は、アプリケーションコードの変更よりも見落とされやすい障害原因です。たとえば、Key Vault Readerのような読み取り系ロールだけでデプロイ処理を組んでいる場合、実際にはテンプレート展開、ロール割り当て、Key Vault設定変更など別の権限が必要になることがあります。
CI/CDでは、次の操作ごとに必要権限を分けて確認します。
| デプロイ処理 | 必要になりやすい権限 |
|---|---|
| リソース作成・更新 | 対象リソースプロバイダーのwrite権限 |
| ロール割り当て | Microsoft.Authorization/roleAssignments/write |
| Key Vaultの作成・設定変更 | Key Vaultの管理プレーン権限 |
| シークレット値の取得 | Key Vaultのデータプレーン権限 |
| Sentinelプレイブック展開 | Logic Appsや接続先リソースの権限 |
| Defender for Cloud設定 | Security Admin相当の権限やAzure Policy関連権限 |
「デプロイ用IDだからContributorでよい」とせず、デプロイ内容を分解して必要な権限を割り当てることが重要です。
運用ルールとして決めておきたいこと
Azure built-in roles for Securityの更新確認は、単発の作業ではなく、運用ルールに組み込むと効果が出ます。
| ルール | 実施頻度 | 目的 |
|---|---|---|
| Securityカテゴリのロール割り当て棚卸し | 月次または四半期 | 不要な権限の残留を防ぐ |
| 強いロールの申請・承認 | 都度 | Security AdminやKey Vault Administratorの乱用を防ぐ |
| カスタムロール差分レビュー | 四半期または公式更新時 | 古い権限定義を放置しない |
| Key Vault権限モデルの確認 | 新規構築時・移行時 | アクセスポリシーとAzure RBACの混在リスクを減らす |
| CI/CDサービスプリンシパルの権限確認 | リリース前・構成変更時 | デプロイ失敗と過剰権限を防ぐ |
| Sentinel/Defender運用権限の見直し | SOC体制変更時 | 監視、対応、管理の職務分掌を保つ |
実務では、すべてのロールを完璧に暗記するよりも、変更時に確認するチェックリストを作るほうが有効です。特に、Key Vault、Defender for Cloud、Microsoft Sentinelは、権限不足が障害に直結し、過剰権限がセキュリティ事故に直結しやすい領域です。
まとめ：次に行うべきこと
Azure built-in roles for Security – Azure RBACの更新情報を確認する目的は、ロール名を把握することではありません。実際に割り当てられている権限が、現在の組み込みロール定義と業務要件に合っているかを確認することです。
まずは、次の順番で対応してください。
- サブスクリプション、リソースグループ、Key Vault、Sentinelワークスペースでロール割り当てを棚卸しする
- Security Admin、Key Vault Administrator、Key Vault Data Access Administratorなどの強いロールを優先して確認する
- Security Readerで足りる担当者にSecurity Adminを付けていないか見直す
- Key Vaultの権限モデルとデータプレーンロールを確認する
- IaCやCI/CDでロール名依存になっている箇所をロールID利用へ見直す
- カスタムロールを使っている場合は、最新の組み込みロールとの差分をレビューする
最小権限は、一度設定して終わりではありません。Azureの組み込みロールはサービス追加や権限定義の更新に合わせて変わるため、公式リファレンスの更新をきっかけに、実際の割り当て、スコープ、運用手順まで見直すことが大切です。特にセキュリティ系ロールは、閲覧、検知、対応、管理、データアクセスの境界を明確に分けることで、障害時の混乱とセキュリティリスクを同時に減らせます。
コメント