Azure RBACとは？ロールベースアクセス制御をやさしく解説

「新しく入った人に、どの権限を渡せばいい?」
「所有者と共同作成者は、何が違うの?」
「Azure Policyと、役割がかぶってない?」

新メンバーにAzureを触ってもらうとき、あなたが最初に決めるのが「どこまで触れるか」です。

Azure RBACとは、ユーザーやグループに役割（ロール）を割り当て、どのリソースに何ができるかを範囲付きで管理する認可の仕組みです。全員に強い権限を配れば事故のもと、絞りすぎれば仕事が止まる。その線引きを、人ごとではなく役割の単位でまとめて渡すのが要です。

この記事では、ロール割り当てを構成する3要素を押さえ、スコープが下へ継承される構造を図で開き、代表的な組み込みロールを表で見分けます。最後にAzure Policyとの役割の違いまで進みます。AZ-900の管理とガバナンス対策に効きます。

1. 割り当ては「誰・役割・範囲」で決まる

RBACの中心にあるのがロール割り当てです。これは3つの要素の組み合わせで、1つでも欠けると成り立ちません。

• プリンシパル（誰に）：ユーザー・グループ・サービスプリンシパル・マネージドID
• ロール定義（どの役割を）：許可される操作をまとめたもの（例：読み取り、書き込み）
• スコープ（どの範囲で）：権限が効く範囲

権限を渡す相手は人だけではありません。アプリやサービスにも割り当てられます。プログラムからAzureを操作するときは、サービスプリンシパルやマネージドIDにロールを与えます。「誰に」を支えるID基盤は Microsoft Entra IDとは で土台がつかめます。

2. スコープは上から下へ継承される

3要素のうち、試験でも実務でも取り違えやすいのがスコープです。スコープには4つの階層があり、上の階層で割り当てた権限は、その配下へ丸ごと引き継がれます。この継承が図で見えると、事故の理由まで腑に落ちます。

継承があるから、サブスクリプション全体に「所有者」を渡すと、その中のリソースグループとリソースまで丸ごと所有者になってしまいます。逆に言えば、権限は「効かせたい一番狭い範囲」に付けるのが基本です。あるプロジェクトだけ任せたいなら、そのリソースグループのスコープで役割を渡す。あなたはこの一手で、渡しすぎを未然に防げます。範囲を区切る器そのものは Azure リソースグループとは で押さえられます。

3. 組み込みロールを表で見分ける

ロールは自作もできますが、まずは用意された組み込みロールを押さえれば足ります。試験で問われる4つを、できることの差で並べました。

見分けの軸は「他人に権限を割り当てられるか」の一点です。所有者と共同作成者は、どちらもリソースを広く操作できます。違うのは、アクセス権そのものを配る力を持つのが所有者だけ、という点。ここが両者を分ける決定打です。

4. 渡しすぎない——最小権限という守り方

RBACを安全に使う土台が最小権限の原則です。「その仕事に要る分だけを、要る範囲にだけ」渡します。確認するだけの人には閲覧者を、プロジェクトを任せる人にはそのリソースグループで共同作成者を。最初から所有者を配ると、意図しない削除や権限の配り直しが起きやすくなります。

もう1つ、実務で効くコツがあります。人ではなくグループにロールを割り当てることです。個人に直付けすると、異動や退職のたびに外し忘れが起き、不要な権限が居残ります。グループに付けておけば、人の出入りはメンバーの出し入れだけで済み、あなたの権限の棚卸しも楽になります。なお複数のロールが重なると権限は足し算で合算されるので、「気づいたら強くなりすぎ」を避ける意味でも、単位はグループに寄せると管理が締まります。

5. Azure Policyとは見ているものが違う

最後に、混同の定番RBACとAzure Policyを切り分けます。どちらも管理・統制の機能ですが、見ている対象がまるで別です。

次のステップ

RBACがAZ-900のどこに置かれるかを地図で確かめたいなら、Azure Fundamentals（AZ-900）試験全体概要で分野の並びを見ておくと、学習の順番に迷いません。

所有者と共同作成者の切り分けが本番で効くかは、AZ-900 管理とガバナンスの問題集で権限まわりの設問を解いて確かめられます。