「RBACでアクセスを許可したのに、Azure Policyが原因でリソースが作れなかった。両者はどう違うのか。」
こうした疑問は、Azureを実務で使い始めたエンジニアが必ずぶつかる壁だ。AzureのRBAC(Role-Based Access Control)とAzure Policyは、どちらも「制御する仕組み」だが、守備範囲がまったく異なる。この2つを混同すると、権限設計が崩れたり、ガバナンスの穴が生まれたりする。
この記事では、Azure RBACの概念から組み込みロールの一覧、Azure CLIによるロール割り当て手順、カスタムロールの作成、そしてAzure Policyとの組み合わせによるガバナンス設計まで、現場で即使える実践手順をステップバイステップで解説する。実行環境はAzure CLI 2.60以降、サブスクリプション管理者権限を持つアカウントでの操作を前提とする。
この記事のポイント
・RBACは「誰が何をできるか」、Azure Policyは「どんなリソースを作れるか」を制御する
・az role assignment create でロール割り当てをCLIから即時実施できる
・カスタムロールはJSON定義で細粒度の権限セットを作成できる
・RBACとPolicyを組み合わせることでゼロトラスト型のガバナンスを実現できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
AzureのRBACとは何か(概念・仕組み)
RBAC(Role-Based Access Control)は、ユーザー・グループ・サービスプリンシパルに対して「ロール(役割)」を割り当て、Azureリソースへのアクセスを制御する仕組みだ。AWSのIAMに相当するが、Azureでは「スコープ(範囲)」の概念が特に重要な位置を占める。RBACを構成する3要素は以下の通りだ。
・セキュリティプリンシパル:アクセスをリクエストする主体。ユーザー・グループ・サービスプリンシパル・マネージドIDが該当する
・ロール定義:許可するアクション(読み取り・書き込み・削除など)のセット。組み込みロールとカスタムロールがある
・スコープ:ロールが適用される範囲。管理グループ>サブスクリプション>リソースグループ>リソースの4階層がある
この3要素を組み合わせた「ロール割り当て(Role Assignment)」が、RBACの最小単位だ。たとえば「Aさん(セキュリティプリンシパル)に、特定のリソースグループ(スコープ)の仮想マシン共同作成者(ロール定義)を割り当てる」という形で権限を付与する。
スコープの継承がポイントになる。上位スコープに割り当てたロールは下位スコープに継承される。サブスクリプション全体に共同作成者を付与すると、そのサブスクリプション配下のすべてのリソースグループ・リソースでも同じ権限が効く。これを意識せずに「サブスクリプション単位で権限を配る」運用をすると、意図しないリソースへのアクセスを許すことになる。リソースグループ単位でスコープを切るのが現場での基本だ。
RBACの主要な組み込みロール一覧
Azureには300以上の組み込みロールがあるが、実務で頻繁に使うのは次の5種類だ。| ロール名 | 概要 | 主な用途 |
|---|---|---|
| 所有者(Owner) | すべての操作+ロール割り当て権限 | サブスクリプション管理者 |
| 共同作成者(Contributor) | すべての操作(ロール割り当ては不可) | 開発チームリーダー |
| 閲覧者(Reader) | すべてのリソースの読み取りのみ | 監査担当・経営層ダッシュボード |
| 仮想マシン共同作成者 | VM作成・管理・削除(ネットワーク・ストレージ割り当ては別途必要) | インフラエンジニア |
| ストレージBLOBデータ共同作成者 | Blobデータへの読み書き・削除 | データ処理アプリのサービスアカウント |
Azure CLIでロール割り当てを実施する手順
ここからは実際のCLI操作を見ていこう。Azure CLIがインストール済みで `az login` が完了している前提で進める。1. 現在のロール割り当て一覧を確認する
まず対象スコープに何が割り当たっているか確認する。# リソースグループ「rg-prod」の割り当て一覧を表示 az role assignment list \ --resource-group rg-prod \ --output table # 出力例 # Principal Role Scope # -------------------- -------------------- ---------------------------------------- # alice@example.com Contributor /subscriptions/xxxx/resourceGroups/rg-prod # sp-appservice Storage Blob Data... /subscriptions/xxxx/resourceGroups/rg-prod
2. ユーザーにロールを割り当てる
ロール割り当ての中心コマンドが `az role assignment create` だ。assignee にメールアドレスまたはオブジェクトIDを指定する。# ユーザー「bob@example.com」にリソースグループ「rg-dev」の # 「仮想マシン共同作成者」を割り当てる az role assignment create \ --assignee "bob@example.com" \ --role "Virtual Machine Contributor" \ --resource-group rg-dev # サービスプリンシパル(オブジェクトID)に割り当てる場合 # --assignee-principal-type を明示するとユーザーとの混在を防げる az role assignment create \ --assignee-object-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \ --assignee-principal-type ServicePrincipal \ --role "Storage Blob Data Contributor" \ --resource-group rg-dev
3. ロール割り当てを削除する
# ロール割り当てを削除 # assignee・ロール名・スコープの3つを正確に指定する必要がある az role assignment delete \ --assignee "bob@example.com" \ --role "Virtual Machine Contributor" \ --resource-group rg-dev # 削除後に残存していないか確認 az role assignment list \ --assignee "bob@example.com" \ --output table
カスタムロールの作成方法
組み込みロールで「権限が広すぎる」または「権限が足りない」場合は、カスタムロールを作成する。カスタムロールはJSON形式の定義ファイルで管理する。1. カスタムロール定義JSONを作成する
以下はVMの起動・停止・再起動のみを許可するカスタムロールの定義例だ。# custom-role-vm-start-stop.json { "Name": "VM Start Stop Operator", "IsCustom": true, "Description": "VMの起動・停止・再起動のみを許可するカスタムロール", "Actions": [ "Microsoft.Compute/virtualMachines/start/action", "Microsoft.Compute/virtualMachines/deallocate/action", "Microsoft.Compute/virtualMachines/restart/action", "Microsoft.Compute/virtualMachines/read" ], "NotActions": [], "DataActions": [], "NotDataActions": [], "AssignableScopes": [ "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" ] }
2. カスタムロールを作成・更新する
# カスタムロールを作成 az role definition create \ --role-definition custom-role-vm-start-stop.json # 定義JSONを修正した後、既存のカスタムロールを更新 az role definition update \ --role-definition custom-role-vm-start-stop.json # 利用可能なアクション名をリソースプロバイダーごとに調べる az provider operation show \ --namespace Microsoft.Compute \ --output table | grep -i virtual
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、AzureのRBAC・権限設計を体系的に学びたいなら、Azure実践講座をご覧ください。ロール割り当てからガバナンス設計まで、現役エンジニアの実務視点で一気に習得できます。
Azure Policyとは何か(RBACとの違い)
Azure PolicyはRBACとは全く別の制御レイヤーだ。RBACが「誰が何をできるか」を制御するのに対して、Azure Policyは「どんなリソースを作れるか・どんな設定が必須か」を強制する。たとえば以下のような制御がAzure Policyで実現できる。
・特定のリージョン(例:japaneast)以外へのリソース作成を禁止する
・タグ(例:Environment=prod)が付いていないリソースの作成を拒否する
・ストレージアカウントでHTTPS転送のみ許可(既存リソースへの強制有効化)
・VMのSKUを特定のシリーズに限定する(コスト制御)
RBACとAzure Policyの役割の違いを整理すると次のようになる。
| 比較軸 | RBAC | Azure Policy |
|---|---|---|
| 制御の目的 | アクセス許可・拒否 | リソース設定の準拠・強制 |
| 主な質問 | 誰が何をできるか? | どんなリソースを作れるか? |
| 拒否の仕組み | ロール未割り当て=拒否 | ポリシーの効果(effect: Deny)で拒否 |
| 監査・レポート | アクティビティログ | コンプライアンスダッシュボード |
Azure Policyの定義・割り当て手順
1. 組み込みポリシーを確認する
まず利用できる組み込みポリシーを検索しよう。Azureには数百の組み込みポリシーが用意されており、多くのケースでカスタム作成は不要だ。# タグ関連の組み込みポリシーを検索 az policy definition list \ --query "[?contains(displayName, 'tag')].{Name:displayName, Id:name}" \ --output table | head -20 # 出力例(抜粋) # Name Id # ------------------------------------------------- ------------------------------------ # Require a tag and its value on resources 1e30110a-5ceb-460c-a204-c1c3969c6d62 # Add a tag to resources 4f9dc7db-30c1-420c-b61a-e1d640128d26
2. カスタムポリシー定義を作成する
組み込みポリシーで対応できない場合はカスタムポリシーを作成する。以下はリソースグループにEnvironmentタグが付いていない場合に作成を拒否するポリシー定義の例だ。# policy-require-env-tag.json { "mode": "Indexed", "displayName": "Require Environment tag on resource groups", "description": "リソースグループにEnvironmentタグを必須化するポリシー", "policyRule": { "if": { "allOf": [ { "field": "type", "equals": "Microsoft.Resources/resourceGroups" }, { "field": "tags['Environment']", "exists": "false" } ] }, "then": { "effect": "Deny" } } }
3. ポリシーを定義し割り当てる
# ポリシー定義を作成 az policy definition create \ --name "require-environment-tag" \ --display-name "Require Environment tag on resource groups" \ --description "Environmentタグが必須" \ --rules policy-require-env-tag.json \ --mode Indexed # サブスクリプションIDを変数に取得 SUBSCRIPTION_ID=$(az account show --query id -o tsv) # サブスクリプションにポリシーを割り当てる az policy assignment create \ --name "enforce-env-tag" \ --display-name "Environmentタグ必須化" \ --policy "require-environment-tag" \ --scope "/subscriptions/${SUBSCRIPTION_ID}" # 割り当て一覧を確認 az policy assignment list \ --scope "/subscriptions/${SUBSCRIPTION_ID}" \ --output table
RBACとAzure Policyを組み合わせたガバナンス設計
実務では、RBACとAzure Policyを組み合わせてガバナンスを多層防御にする。以下は実際の設計パターンの一例だ。RBACによる権限設計例:
・開発者:リソースグループスコープで「共同作成者」を付与
・セキュリティ担当:サブスクリプションスコープで「セキュリティ管理者」を付与
・CI/CDサービスプリンシパル:対象リソースグループのみでカスタムロール「デプロイオペレーター」を付与
Azure Policyによる制約:
・デプロイ先リージョン:japaneast / japanwest のみ許可(Deny)
・VMのSKU:Standard_B・Standard_D シリーズのみ許可(Deny)
・ストレージ:HTTPS転送のみ強制(DeployIfNotExists)
・タグ:CostCenter・Environment の2タグ必須(Deny)
ポリシーの効果(effect)は目的に応じて使い分ける。
| effect | 動作 | 使いどころ |
|---|---|---|
| Deny | ポリシー違反のリソース作成・変更を即時拒否 | リージョン制限・SKU制限 |
| Audit | 違反を検出してコンプライアンスログに記録(作成は許可) | 移行期間中の監視・段階的導入 |
| AuditIfNotExists | 関連リソースが存在しない場合に違反として記録 | 診断設定の有効化確認 |
| DeployIfNotExists | 指定設定が存在しない場合に自動デプロイ | Azure Monitor Agentの自動インストール |
| Modify | リソースのプロパティ・タグを自動変更 | タグの自動付与・標準化 |
まとめとよくあるトラブル・失敗パターン
RBACとAzure Policyを組み合わせた権限設計のポイントをコマンドと合わせてまとめる。| やりたいこと | 使うべき仕組み |
|---|---|
| ユーザーにVM操作を許可する | az role assignment create --role "Virtual Machine Contributor" |
| CI/CDサービスアカウントに最小権限を付与する | az role definition createでカスタムロールを定義 |
| 特定リージョン以外へのデプロイを禁止する | az policy assignment createでAllowedLocationsポリシーを割り当て |
| タグなしリソースを拒否する | az policy definition createでDenyポリシーを定義・割り当て |
| 診断設定の有無を監査する | AuditIfNotExistsポリシーを割り当て |
・サブスクリプション全体に共同作成者を付与する:スコープを絞らない権限付与は、誤操作や侵害時の影響範囲を最大化する。必ずリソースグループ以下のスコープに絞ること
・カスタムロールのAssignableScopesを「/」(全テナント)にする:意図せず他のサブスクリプションでも使えるロールが生まれる。スコープは必要なサブスクリプションのみに限定すること
・ポリシーをいきなりDenyで適用する:既存リソースへの影響を確認せずにDenyで適用すると、既存の自動化スクリプトや運用処理が止まる。必ずAuditで影響範囲を確認してから切り替えること
・RBACとAzure Policyの両方がDenyになる:RBACで権限があってもAzure PolicyでDenyになっていれば操作は失敗する。トラブル時はAzure Portalの「アクティビティログ」でエラー詳細を確認し、どちらが原因か切り分けること
AzureのRBACは設計当初から「最小権限」を意識することが重要だ。後から絞り込もうとすると、既存の運用に影響が出てトラブルになることが多い。権限設計はシステム構成と同じタイミングで考えておくことを強くすすめる。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、AzureのRBAC・権限設計を体系的に学びたいなら、Azure実践講座をご覧ください。ロール割り当てからガバナンス設計まで、現役エンジニアの実務視点で一気に習得できます。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒/合わなければ解除3秒 / 詳細はこちら
- 次のページへ:Azure Load BalancerとApplication Gatewayの使い分け|L4・L7ロードバランサー選定の判断軸
- 前のページへ:Azureのコスト管理入門|Cost Managementと予算アラートでクラウド料金の想定外を防ぐ方法
- この記事の属するカテゴリ:Azureへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます