AzureのRBACとAzure Policyで権限を設計する方法|ロール割り当てとガバナンスの実践

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Azure > AzureのRBACとAzure Policyで権限を設計する方法|ロール割り当てとガバナンスの実践
「Azureで開発チームに仮想マシンの操作権限を渡したいが、誰にどのスコープで何を与えればいいのかわからない。」
「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を組み合わせることでゼロトラスト型のガバナンスを実現できる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

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データへの読み書き・削除 データ処理アプリのサービスアカウント
「共同作成者を全員に与えればいいか」という判断は危険だ。共同作成者はロール割り当てができない点でOwnerとは異なるが、リソースの削除やネットワークの変更など、本番環境を壊せる権限は全部持っている。最小権限の原則(Principle of Least Privilege)に従い、必要な操作だけを絞り込んだロールを使うことが現場での鉄則だ。

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

サービスプリンシパルに割り当てる場合は `--assignee-principal-type ServicePrincipal` を明示すると、ユーザーとサービスプリンシパルが同じオブジェクトIDを持つ場合の誤解決を防げる。

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

`AssignableScopes` でカスタムロールを使えるサブスクリプションを限定できる。複数のサブスクリプションをまたぐ場合は管理グループのリソースIDを指定するとよい。カスタムロールはサブスクリプションあたり5,000個まで作成できるが、実務では用途別に絞り込み、不要になったものは削除する運用にしておくと管理しやすい。

現場で通用する安全な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)で拒否
監査・レポート アクティビティログ コンプライアンスダッシュボード
重要な点として、RBACでリソースの作成権限を持っていても、Azure Policyが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 リソースのプロパティ・タグを自動変更 タグの自動付与・標準化
新しいポリシーを本番環境に一気に適用するのは危険だ。まず effect: Audit でコンプライアンス状況を把握し、違反リソースを修正してから effect: Deny に切り替えるのが現場での定石だ。特に長く運用しているサブスクリプションにDenyポリシーを追加すると、既存の自動化スクリプトが突然失敗するケースがある。必ず段階的に導入すること。

まとめとよくあるトラブル・失敗パターン

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実践講座をご覧ください。ロール割り当てからガバナンス設計まで、現役エンジニアの実務視点で一気に習得できます。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。