【初心者向け】Azure RBACとは？ロール割り当ての3要素と組み込みロールを実務目線で解説

Azureを触っていると、遅かれ早かれ必ずぶつかるのが「誰に、どのリソースを、どこまで触らせるか」という問題です。開発メンバーには仮想マシンを作らせたいけれど、課金設定はいじってほしくない。監査担当には全部を「見る」だけ許可したい。こうした要望に応えるためのAzure標準の仕組みが、Azure RBAC（Role-Based Access Control：ロールベースのアクセス制御）です。

ところが、いざMicrosoft Learnの公式ドキュメント（RBACの概要）を開くと、「プリンシパル」「ロール定義」「スコープ」「コントロールプレーン」といった用語がいきなり並んでいて、初見だと頭に入ってきません。私自身、Azureを学びはじめた頃、ここで「なんとなく分かった気」のまま先に進んでしまい、あとで権限周りの事故を起こしかけました。

「RBACって聞くけど、結局どういう仕組みなの？ロールとかスコープとか、なんとなくで使ってて自信がない…」

この記事は、Azure RBACの全体像をつかむためのハブ記事です。RBACとは何かから始めて、その核心であるロール割り当ての3要素、実務で毎日出会う組み込みロール、初心者が必ず混同するEntraロールとの違い、そして意外と落とし穴になるコントロールプレーンとデータプレーンの区別まで、公式の正確さは押さえつつ日本語で噛み砕いて解説します。読み終わるころには、Azureの権限管理を「なんとなく」ではなく「仕組みとして」語れるようになります。

なお、Entra ID側の文脈でのアクセス制御（Entraロールの割り当てやサインインログ・監査ログ）については、Microsoft Entra IDのアクセス制御とログを実務目線で解説で扱っています。本記事は視点が違い、「Azure全体のリソース権限基盤としてのRBACそのもの」を主役に据えて深掘りします。両者は後半の「EntraロールとRBACの違い」でつながるので、あわせて読むと立体的に理解できます。

Azure RBACとは：権限を「役割」で配る仕組み
RBACの核：ロール割り当ての「3要素」
まず覚える組み込みロール：Owner / Contributor / Reader / UAA
【重要】Azure RBACとEntraロールの違い
見落としがちな落とし穴：コントロールプレーンとデータプレーン
まとめ
さらに深く学ぶ：Azure RBAC 実務シリーズ

Azure RBACとは：権限を「役割」で配る仕組み

まず一番大事な考え方から。Azure RBACとは、ひとことで言えば「誰か」に「役割」を割り当てて、「どの範囲」のリソースを触れるかを制御する仕組みです。

ここでポイントなのが、権限を個人に一つひとつ直接付けるのではなく、「役割（ロール）」という束にして配るという発想です。会社にたとえるなら、「田中さんは棚Aを開けていい、棚Bも開けていい、金庫は禁止…」と一つずつ許可を出すのではなく、「田中さんは経理担当」という役割を渡す。役割の中身（何ができるか）はあらかじめ決まっているので、人が増えても「その役割を渡す」だけで済みます。これがRBACの根っこにある考え方です。

Azureでは、この「役割を割り当てる」という行為をロール割り当て（Role Assignment）と呼びます。そしてこのロール割り当てこそが、RBACの正体です。Azureポータルでリソースを開くと「アクセス制御（IAM）」というメニューがありますが、そこでやっているのはまさにこのロール割り当てです。

RBACのありがたさは、権限が細かく分けられることにあります。「作れるけど消せない」「見えるけど変更できない」といった、業務にちょうど合った権限を渡せる。全員に管理者権限を配ってしまうような雑な運用から卒業するための、Azureの標準装備だと思ってください。

RBACの核：ロール割り当ての「3要素」

ここがこの記事でいちばん理解してほしいところです。Azureのロール割り当ては、必ず3つの要素の組み合わせでできています。この3つさえ押さえれば、RBACの8割は理解したと言っていいくらい重要です。

その3要素とは、プリンシパル（誰に）・ロール定義（何を）・スコープ（どこで）です。日本語にすると「誰に・何を・どこで」。ロール割り当てとは、この3つを1本の線でつなぐ行為だと考えてください。

① プリンシパル（誰に）

プリンシパルは「権限を渡す相手」です。人間だけとは限らないのがポイントで、Azureでは次のようなものがプリンシパルになれます。

まずユーザー（田中さん、佐藤さんといった個人アカウント）。次にグループ（Entra IDのセキュリティグループ）。そして人間以外では、アプリケーションが自動で使うサービスプリンシパルや、Azureリソース自身に付与できるマネージドIDがあります。たとえば「このWebアプリからストレージを読み取らせたい」というとき、アプリのマネージドIDをプリンシパルにしてロールを割り当てます。

実務でのコツは、できるだけ個人ではなくグループをプリンシパルにすることです。田中さん個人にロールを直付けすると、異動・退職のたびに手で外すことになりますが、「開発チーム」グループに割り当てておけば、メンバーを出し入れするだけで権限管理が回ります。この「権限はグループに付ける」という原則は、Entra IDのユーザー・グループ管理で詳しく触れているので、そちらもあわせてどうぞ。

② ロール定義（何を）

ロール定義は「何ができるか」を決める、権限の中身そのものです。「仮想マシンを起動できる」「ストレージを読み取れる」といった許可された操作の一覧が、ロール定義の中に書かれています。

ロール定義の中身は、実はActions（許可する操作）やNotActions（そこから除外する操作）などのリストでできています。たとえば後述するContributorロールは、「ほぼ全部の操作を許可、ただし権限付与に関わる操作だけ除外」という形で定義されています。ふだんは中身を意識しなくても組み込みロールを選ぶだけで使えますが、「なぜこのロールはこれができてこれができないのか」を突き詰めると、最後はこのAction／NotActionのリストに行き着きます。

Azureには数百種類の組み込みロールが最初から用意されていて、たいていの用途はこれで足ります。組み込みでは足りない特殊な権限が必要なときだけ、自分でロール定義を作る「カスタムロール」の出番になります（これは実務シリーズの子記事で扱います）。

③ スコープ（どこで）

スコープは「その権限が効く範囲」です。同じ「Reader（閲覧者）」ロールでも、サブスクリプション全体に割り当てるのか、特定のリソースグループだけに割り当てるのかで、見える範囲がまったく変わります。

Azureのスコープは階層構造になっていて、上から順に管理グループ → サブスクリプション → リソースグループ → 個別リソースという入れ子です。マンションにたとえると、管理グループが「建物全体」、サブスクリプションが「フロア」、リソースグループが「部屋」、個別リソースが「部屋の中の家具」といったイメージです。

ここで大事なルールがひとつ。上位スコープで割り当てた権限は、下位にすべて継承されるということです。サブスクリプションにReaderを割り当てれば、その中のすべてのリソースグループとリソースが見られるようになります。逆に、特定のリソースグループだけにContributorを割り当てれば、権限はその部屋の中だけに閉じ込められます。

この「継承」を意識せずに上のほうへ気軽に強い権限を割り当てると、意図せず広範囲に権限がばらまかれます。必要な範囲まで下げてから割り当てる——これが後半で触れる「最小権限」の第一歩です。

3要素をまとめると、ロール割り当てはこう読めます。ツリーで整理してみましょう。

ロール割り当て（例）
├─ プリンシパル ： 開発チーム（グループ）
├─ ロール定義　 ： 共同作成者（Contributor）
└─ スコープ　　 ： リソースグループ "rg-dev"

→ 意味：開発チームは、rg-dev の中のリソースを
　　　　（権限付与以外は）自由に管理できる

迷ったら「誰に・何を・どこで」を口に出す。これがRBACの合言葉です。

まず覚える組み込みロール：Owner / Contributor / Reader / UAA

組み込みロールは数百ありますが、初心者がまず押さえるべきは4つだけです。この4つは「基本ロール」と呼ばれ、あらゆるリソースに共通して使える汎用的なものです。ここを取り違えると事故につながるので、丁寧にいきます。

Reader（閲覧者）：見るだけ

いちばん弱いのがReaderです。リソースの閲覧だけができて、作成・変更・削除は一切できません。監査担当や、状況を確認したいだけの人に渡すのに向いています。「とりあえず全体を見せたいが触らせたくない」というときの定番です。

Contributor（共同作成者）：管理できる、ただし…

Contributorは、リソースの作成・変更・削除ができる、実務でいちばんよく使う「働き者」のロールです。仮想マシンを立てたり、ストレージを作ったり、日々の運用作業はほぼこれで足ります。

ただし、Contributorにはたった一つだけ、決定的にできないことがあります。それは他人への権限付与（ロールの割り当て）です。「リソースは何でも作れるけれど、『誰かに権限を配る』ことだけはできない」——ここがContributor最大の勘所です。

これは地味に見えて、とても重要なセキュリティ設計です。もしContributorが権限付与までできてしまうと、Contributorを渡された人が自分に勝手にOwner権限を付け足せてしまい、権限管理が破綻します。「管理はできるが、権限の配布はできない」という線引きによって、”作業する人”と”権限を管理する人”を分けられるわけです。私も最初は「なんで作れるのに割り当てだけできないの？」と不思議でしたが、この理由を知って腹落ちしました。

Owner（所有者）：全部できる

Ownerはすべての操作＋権限付与までできる、最強のロールです。Contributorができなかった「他人への権限割り当て」も含めて、そのスコープ内では何でもできます。

強力なだけに、Ownerは配りすぎないのが鉄則です。とくにサブスクリプションのスコープでOwnerを気軽に配ると、その人たちが好き放題に権限を組み替えられる状態になります。Ownerは本当に必要な少数だけに限定し、日々の作業者にはContributorを渡す——これが基本の形です。

User Access Administrator（UAA）：権限付与の専任

4つ目のUser Access Administrator（ユーザーアクセス管理者、以下UAA）は、少し毛色が違います。UAAができるのはロールの割り当て（＝権限付与）だけで、リソースそのものの作成・変更はできません。

ここでContributorと対にして覚えると一気にスッキリします。

Contributor：リソースは作れる。でも権限は配れない。＝「作業の人」
UAA：リソースは作れない。でも権限は配れる。＝「権限管理の人」

ちょうど鏡写しの関係になっているのが分かるでしょうか。Ownerは「この両方を1人に持たせたロール」だと考えると、4つの関係が頭の中で整理できます。実務では、Ownerを乱発する代わりに「作業はContributor、権限管理はUAA」と役割を分けることで、それぞれの権限を最小限に抑えつつ運用できます。「権限を配れる人」を絞りたいけれど、その人にリソース全権まで渡すのはやりすぎ——そんなときにUAAがちょうどよくハマります。

【重要】Azure RBACとEntraロールの違い

ここは初心者がほぼ全員つまずくところです。Azureには「ロール」と名の付くものが2種類あって、これを混同すると「権限を付けたはずなのに効かない」という事故が起きます。しっかり区別しておきましょう。

その2種類とは、Azure RBACのロールとEntraロール（ディレクトリロール）です。名前は似ていますが、管理している対象がまったく別物です。

Azure RBACのロール（Owner、Contributorなど）は、サブスクリプション配下のAzureリソースを操作する権限です。仮想マシン、ストレージ、ネットワークといった「モノ」を作ったり触ったりするための権限。この記事でずっと話してきたのがこちらです。

一方のEntraロール（全体管理者、ユーザー管理者など）は、ディレクトリ、つまりID（ユーザー・グループ）そのものを管理する権限です。「新しいユーザーを作る」「グループのメンバーを変える」「ドメインを追加する」といった、ID基盤側の操作を扱います。

マンションのたとえを続けるなら、Entraロールは「住民名簿を管理する管理人」、Azure RBACは「実際の部屋や設備を操作する権限」です。名簿をいじれる人と、部屋を改装できる人は、役割が別ですよね。だから、Entraの「全体管理者」を持っていても、それだけでは自動的にAzureリソースを触れるわけではありません（逆も同様）。この非対称性が、混乱のいちばんの原因です。

両者の関係を整理すると、こうなります。

Entraロール ： ID（ユーザー/グループ/ドメイン）を管理
　　例）全体管理者、ユーザー管理者
　　範囲）Entra ID（ディレクトリ）全体

Azure RBAC ： リソース（VM/ストレージ等）を操作
　　例）所有者、共同作成者、閲覧者
　　範囲）管理グループ〜サブスク〜リソース

実務でよく効くのが、全体管理者（Entra）は「サブスクリプション管理へのアクセスを昇格」という設定をオンにしない限り、Azureリソースには手を出せないという点です。この分離があるおかげで、ID管理者とリソース管理者を別々に立てられます。

なお、Entraロール側からの視点（Entraロールの割り当て手順や、最小特権として全体管理者を乱発しない話）は、Microsoft Entra IDのアクセス制御とログで詳しく扱っています。本記事はAzure RBAC（リソース側）が主役、あちらはEntra ID（ID側）が主役、という棲み分けです。両方を読むと、Azureの権限の全体像が上下ふたつの層としてつながります。

見落としがちな落とし穴：コントロールプレーンとデータプレーン

最後に、RBACの理解を一段深くする概念を紹介します。それがコントロールプレーンとデータプレーンの区別です。ここを知らないと、「Owner権限を持っているのに、なぜかストレージの中のファイルが読めない」といった、一見あり得ない事態にハマります。

ざっくり言うと、こうです。

コントロールプレーン：リソースそのものを管理する操作（作成・削除・設定変更）
データプレーン：リソースの中のデータを操作する操作（中身の読み書き）

ホテルにたとえると分かりやすいです。コントロールプレーンは「ホテルという建物を建てる・改装する権限」、データプレーンは「客室の中に入って荷物を出し入れする権限」。建物を建てられる人が、必ずしも全部の客室に入れるわけではない、というのが直感的なイメージです。

Key Vaultとストレージで起きる「あるある」

この違いがハッキリ表れるのがAzure Key Vaultやストレージです。

たとえばストレージアカウントで、あなたにContributor（コントロールプレーンの権限）が割り当てられているとします。あなたはストレージアカウントを作れるし、設定も変えられる。でも、その中に入っているBlob（ファイル）の中身を読もうとすると弾かれることがあります。なぜなら、データの読み書きはデータプレーン用の別ロール——たとえばStorage Blob Data ReaderやStorage Blob Data Contributor——が必要だからです。Contributorはあくまで「箱を管理する」権限で、「中身を読む」権限とは別枠なのです。

Key Vaultも同じ構図です。Key Vaultという入れ物の設定を変えるのはコントロールプレーン、中に保管したシークレットや証明書を実際に読み出すのはデータプレーン。だから「Key VaultにOwnerを持っているのにシークレットが取り出せない」という相談は、たいていこのデータプレーン用のロール（Key Vault Secrets Userなど）が付いていないのが原因です。

「管理者なのにデータが読めない！」の9割は、コントロールプレーンとデータプレーンの取り違えです。これを知っているだけでトラブル対応が速くなります。

覚えておくべき教訓はシンプルです。「リソースを管理する権限」と「データを操作する権限」は別物。データにアクセスさせたいなら、コントロールプレーンのロールとは別に、データプレーン用のロールも割り当てる必要がある——これを頭に入れておけば、権限のハマりどころをほとんど回避できます。

まとめ

Azure RBACの全体像を、実務でつまずく順に見てきました。要点を振り返っておきます。

RBACとは：プリンシパルに「役割」を割り当てて、リソースへのアクセスを制御する仕組み。権限は個人ではなくグループへ。
3要素：ロール割り当てはプリンシパル（誰に）・ロール定義（何を）・スコープ（どこで）の組み合わせ。上位スコープの権限は下位に継承される。
組み込みロール：まずはReader（見るだけ）／Contributor（管理はできるが権限付与は不可）／Owner（全部）／UAA（権限付与の専任）の4つ。ContributorとUAAは鏡写し。
EntraロールとRBACの違い：EntraロールはID管理、Azure RBACはリソース操作。対象がまったく別物。
コントロール／データプレーン：リソースの管理権限とデータ操作権限は別枠。Key Vaultやストレージで要注意。

ここまで理解できれば、「なぜこの権限では足りないのか」「どこに何を割り当てればいいのか」を自分の頭で判断できる土台ができました。あとは実際に手を動かして、割り当てや設計の勘所を身につけていく段階です。