Azure RBAC（ロールベースのアクセス制御）完全ガイド！設計のベストプラクティスと注意点

Azure RBAC（ロールベースのアクセス制御）は、ユーザーやグループ（セキュリティプリンシパル）に対し、許可する操作（ロールの定義）と適用範囲（スコープ）を組み合わせてAzureリソースへのアクセス権を管理する機能です。業務に必要な最小限の権限のみを付与し、個人ではなくMicrosoft Entraグループ単位でリソースグループなどの上位スコープに割り当てることで、誤操作を防ぎつつ管理負荷を軽減できます。設定手順から設計の基準、上限数などの制限事項までを整理しました。

Azure RBAC（ロールベースのアクセス制御）とは

Azure RBAC（Role-Based Access Control：ロールベースのアクセス制御）は、Microsoftの公式ドキュメントで定義されているとおり、Azureのリソースに対するアクセス権限をきめ細かく管理するための承認システムです。組織内のユーザーやアプリケーションに対して誰がどのリソースに対してどのような操作を実行できるかを制御する仕組みを提供します。

たとえば、開発チームのメンバーには仮想マシンの作成や起動を許可し、経理チームのメンバーには請求データやコストの閲覧のみを許可するといった業務の役割（ロール）に応じた権限の分離を、単一の管理基盤上で実現できます。

Azureにおけるアクセス管理の重要性

パブリッククラウドであるAzureの運用において、適切なアクセス管理はセキュリティリスクの低減と運用事故の防止に直結します。インターネット経由でどこからでも管理画面へアクセスできる特性上、すべての担当者に無制限の権限を与えていると、悪意のある第三者にアカウントを乗っ取られた際や、担当者が操作を誤った際に被害が環境全体へ拡大するためです。

アクセス管理を徹底していない環境では、具体的に以下のような問題が発生するリスクがあります。

Azure RBACを導入して業務に必要な最小限の操作のみを許可することで、ヒューマンエラーによるシステム停止や情報漏洩をシステムレベルで未然に防ぐことができます。

IAM（IDおよびアクセス管理）との関係性

Azureにおけるアクセス制御の全体像を把握するには、上位概念であるIAM（Identity and Access Management：IDおよびアクセス管理）とAzure RBACの関係性を整理する必要があります。IAMは「認証（Authentication）」と「承認（Authorization）」の2つのプロセスで構成されており、Azure RBACはこのうちの「承認」を担う機能です。

なお、Azure Portalの各リソース画面には「アクセス制御（IAM）」という名称のメニューが表示されており、管理者はこのメニューからAzure RBACの設定を行います。

ユーザーがAzure環境にサインインする際、まずはMicrosoft Entra IDによってIDの正当性が検証（認証）されます。その後、ユーザーが仮想マシンの停止や設定変更などの具体的なアクションを起こそうとした段階で、Azure RBACが割り当てられたロールを参照し、その操作を実行してよいかを判断（承認）します。このように、ID管理基盤による認証とAzure RBACによる承認が連携することで、セキュアなクラウド運用が成り立っています。

Azure RBACを構成する3つの基本要素

Azure RBACにおけるアクセス制御は、「セキュリティプリンシパル」「ロールの定義」「スコープ」の3つの要素を組み合わせることで成り立っています。この3要素を紐づける作業を「ロールの割り当て（Role Assignment）」と呼び、誰が、どの範囲のAzureリソースに対して、どのような操作を行えるかを決定します。

セキュリティプリンシパル（誰に権限を付与するか）

セキュリティプリンシパルとは、Azureリソースへのアクセスを要求するオブジェクトのことです。公式ドキュメントでは、ユーザー、グループ、サービスプリンシパル、マネージドIDが対象とされています。人間のユーザーだけでなく、アプリケーションなどのシステムも含まれます。

ユーザーとグループ

「ユーザー」は、Microsoft Entra IDに登録された個々のアカウントを指します。社員や外部のゲストアカウントなど、実在する個人に対して直接アクセス権を割り当てる際に指定します。

「グループ」は、複数のユーザーをまとめた単位です。開発チームや運用部門といった組織単位でグループを作成し、そのグループに対してロールを割り当てます。グループに付与された権限は、所属するすべてのメンバーに自動的に適用されるため、人事異動やメンバーの増減が発生した際も、グループの所属メンバーを変更するだけで権限の付与や剥奪が完了します。

サービスプリンシパルとマネージドID

「サービスプリンシパル」は、自動化ツールや外部アプリケーション、CI/CDパイプライン（GitHub ActionsやAzure DevOpsなど）がAzureリソースにアクセスする際に使用するセキュリティIDです。人間を介さずにプログラムがリソースを操作する場合、このサービスプリンシパルに対してロールを割り当てます。

「マネージドID」は、Azureが自動的に認証情報を管理する特殊なサービスプリンシパルです。通常のサービスプリンシパルでは、管理者がクライアントシークレット（パスワード）や証明書の有効期限を管理し、定期的な更新作業を行う必要があります。一方、マネージドIDを利用すると、認証情報はAzureが管理し、利用者はその認証情報にアクセスできないため、コード内で資格情報を管理する必要がありません（公式ドキュメント）。

マネージドIDには、以下の2種類が存在します。

ロールの定義（どのような操作を許可するか）

ロールの定義（または単にロール）は、リソースに対して実行できる操作の許可リストをまとめたものです。リソースの読み取り、作成、更新、削除といったアクションがJSON形式で定義されています。Azureには、あらかじめ用意されている「組み込みロール」と、独自の権限セットを作成できる「カスタムロール」があります。

また、ロールが定義する操作対象は大きく2つのプレーン（領域）に分かれています。

所有者や共同作成者などの基本ロール

組み込みロールの中で、代表的なロールは以下の4つです。公式ドキュメントでは、所有者・共同作成者・ユーザー アクセス管理者・ロールベースのアクセス制御管理者が「特権管理者ロール」とされ、閲覧者は含まれません。

注意点として、「所有者」や「共同作成者」はコントロールプレーンに対する強力な権限を持ちますが、データプレーンの操作には、データプレーン用のロール（DataActions）が必要になる場合があります。たとえばKey Vaultでは、公式ドキュメントに「Key Vault Contributorは管理プレーン専用で、キー、シークレット、証明書にはアクセスできない」と記載されています。サブスクリプションの所有者がRBACモデルのKey Vaultでシークレット値を読めるかどうかは、確認できた公式ページに記載がなく要確認です。ただし、所有者はロールを割り当てる権限を持つため、データプレーン用のロールを自分自身に付与できる点に注意が必要です。

リソース固有の組み込みロール

基本ロールだけでは権限の範囲が広すぎる場合、特定のサービスや操作に限定された「リソース固有の組み込みロール」を使用します。Azureには多数の組み込みロールが用意されており（正確な数は公式の一覧で確認してください）、業務の役割に応じた細かな権限付与が可能です。代表的な例は以下の通りです。

スコープ（どの範囲のリソースに適用するか）

スコープとは、ロールの割り当てが有効になる境界（範囲）のことです。Azureではリソースが4つの階層構造で管理されており、上位のスコープで割り当てた権限は下位のスコープへ自動的に継承される仕組みになっています。

管理グループとサブスクリプション

「管理グループ」は、複数のサブスクリプションを束ねて一元管理するための最上位スコープです。企業全体や事業部単位で複数のサブスクリプションを保有している場合、管理グループに対してロールを割り当てることで、配下のすべてのサブスクリプションに共通のアクセス権を適用できます。全社共通のセキュリティ監査担当者に対して「閲覧者」ロールを付与するといった用途に適しています。

「サブスクリプション」は、Azureの利用料金の請求単位であり、リソースを作成するための論理的な器となるスコープです。サブスクリプション単位でロールを割り当てると、そのサブスクリプション内に存在するすべてのリソースグループおよび個別リソースに対して権限が継承されます。インフラ管理部門のリーダーなど、特定の契約環境全体を管理する担当者に権限を付与する際に指定します。

リソースグループと個別リソース

「リソースグループ」は、同じライフサイクルを持つリソース（特定のWebシステムを構成する仮想マシン、データベース、ネットワークなど）をまとめた論理的なグループです。プロジェクト単位やシステムの環境単位（本番環境、検証環境など）でリソースグループを分け、それぞれの担当チームに対してこのスコープでロールを割り当てるのが一般的です。

「個別リソース」は、単一の仮想マシンやストレージアカウント、データベースそのものを指す最下位のスコープです。特定のリソースにのみアクセスを許可したい場合に指定します。例えば、リソースグループ全体への変更権限は与えず、特定のストレージアカウントに対するデータ読み取り権限だけをアプリケーションのマネージドIDに付与するといった限定的な制御に用います。

Azure RBACの具体的な設定手順と権限の割り当て方法

Azure RBACでアクセス権を付与（ロールの割り当て）するには、対象のリソースに対して操作を実行するユーザー自身が「ロールの割り当てを書き込む権限（Microsoft.Authorization/roleAssignments/write）」を保持している必要があります。具体的には、設定対象のスコープにおいて「所有者」「ユーザー アクセス管理者」「ロールベースのアクセス制御管理者」などの組み込みロールが割り当てられていなければなりません。ここでは、事前条件を満たした状態から実際に権限を割り当てる手順と、設定後の確認方法を解説します。

Azure Portalを使用したGUIでのロール割り当て手順

Webブラウザ上のAzure Portal（GUI）からは、各スコープの「アクセス制御 (IAM)」メニューを通じて直感的にロールを割り当てることができます。以下の手順に沿って操作を進めます。

しばらくすると指定したスコープに対するロールの割り当てが有効化されます。反映には最大10分かかる場合があります（公式ドキュメント）。

Azure CLIやPowerShellを用いたコマンドでの設定

複数の環境へ同一の権限設定を展開する場合や、CI/CDパイプラインに権限付与の処理を組み込む場合は、コマンドラインツール（Azure CLIまたはAzure PowerShell）を使用します。コマンドによる設定では、誰に（プリンシパル）・どの権限を（ロール）・どこに（スコープ）付与するかをパラメータで明示的に指定して実行します。

例えば、特定のサブスクリプション内のリソースグループ（sample-rg）に対して、ユーザー（user@example.com）に「閲覧者（Reader）」ロールを割り当てる場合、それぞれのツールで以下のようにコマンドを実行します。

【Azure CLIの実行例】

az role assignment create --assignee "user@example.com" \
  --role "Reader" \
  --scope "/subscriptions/{subscriptionId}/resourceGroups/sample-rg"

【Azure PowerShellの実行例】

New-AzRoleAssignment -SignInName "user@example.com" `
  -RoleDefinitionName "Reader" `
  -Scope "/subscriptions/{subscriptionId}/resourceGroups/sample-rg"

公式ドキュメントでは、サービスプリンシパルにはアプリケーションIDではなくオブジェクトIDを使い、--assignee-object-idと--assignee-principal-typeを指定することが案内されています（作成直後のサービスプリンシパルへの割り当てが失敗する場合があるため）。また、スクリプトではロール名ではなく一意のロールIDを使うことが推奨されています（ロール名が変更されても動作しやすいため）。各種コマンドの詳細なオプションについては、Microsoft公式ドキュメントのAzure CLIを用いたロール割り当て手順もあわせて参照してください。

現在のアクセス権を確認する方法

権限を付与した後や、運用中に「特定のユーザーがどのリソースにアクセスできるか」を監査・調査する際には、用途に応じて以下の確認方法を使い分けます。

コマンドラインから特定のリソースグループ（sample-rg）に割り当てられているロール一覧を取得する場合の実行例は以下のとおりです。

【Azure CLIでの確認例】

【Azure PowerShellでの確認例】

なお、上位スコープから継承された権限も含めてコマンドラインで一覧出力したい場合は、Azure CLIでは--include-inheritedオプションを追加することで、親スコープから継承された割り当ても含めて一覧を取得できます（公式ドキュメントで案内されているオプションです）。

Azure RBAC設計のベストプラクティス

Azure環境のセキュリティを維持しつつ運用負荷を抑えるには、リソースの増加や組織変更を見据えた初期設計が不可欠です。Microsoftが公式ドキュメントで推奨しているAzure RBACの設計指針に基づき、実務で適用すべきベストプラクティスを4つに絞って解説します。公式ドキュメントには、このほかにも、サブスクリプションの所有者を最大3人に限定すること、特権管理者ロールの割り当てを絞ること、PIMを使うこと、ロール名ではなくロールIDを使うこと、カスタムロールでワイルドカードを避けることなどが挙げられています。

最小特権の原則に基づいた権限付与

権限を付与する際は、業務の遂行に必要最小限のロールとスコープのみを選択する「最小特権の原則」を徹底します。必要以上に広い権限を与えると、オペレーションミスによるリソースの誤削除や、アカウント侵害時の被害拡大につながるためです。

具体的には、「所有者」や「共同作成者」といった広範な権限を持つ基本ロールの割り当てを制限し、担当業務に直結するリソース固有の組み込みロールを選択します。例えば、仮想マシンの運用担当者にはサブスクリプション全体の「共同作成者」ではなく、対象のリソースグループに限定した「仮想マシンの共同作成者」を割り当てます。

また、権限を絞り込む際は以下の3つの軸で妥当性を検証します。

個人ユーザーではなくMicrosoft Entraグループへの割り当て

ロールの割り当て対象（セキュリティプリンシパル）には、個別のユーザーアカウントではなくMicrosoft Entraグループを指定する設計が基本です。

個人単位で直接ロールを割り当てると、人事異動や退職のたびに複数のリソースグループやサブスクリプションの設定を個別に変更する必要があり、設定漏れや不要な権限の残存（権限の形骸化）を招きます。職務やプロジェクト単位でMicrosoft Entraグループを作成し、そのグループに対してAzure RBACのロールを割り当てておけば、メンバーの追加や削除をグループ管理画面だけで完結できます。

さらに、サブスクリプションあたりのロール割り当て数には上限が存在するため、グループ単位で割り当てを集約することは、上限到達を回避する観点からも有効です。個人への直接割り当てとグループへの割り当ての違いは以下の通りです。

リソースの継承関係を考慮した上位スコープの設計

Azure RBACでは、上位のスコープ（管理グループやサブスクリプション）で付与された権限が、下位のスコープ（リソースグループや個別リソース）へ自動的に継承されます。この仕様を踏まえ、リソースのライフサイクルと管理責任の境界に合わせて階層構造を設計することが求められます。

個別リソース単位でのロール割り当てが多発すると、どこにどの権限が付与されているかの全体像が把握できなくなります。基本的には「リソースグループ」を日常的な権限付与の最小単位とし、同じアクセス制御ポリシーを共有するリソース群を1つのリソースグループにまとめる設計にします。

一方で、組織全体の監査担当者やセキュリティ管理者など、全環境を横断して確認する必要がある役割に対しては、管理グループやサブスクリプションといった上位スコープで「閲覧者」などのロールを割り当てます。逆に、上位スコープで「共同作成者」などの強い権限を付与してしまうと、下位のすべてのリソースに対して変更が可能になるため、上位スコープでの権限付与は必要最小限の対象者に絞ります。

組み込みロールの優先利用とカスタムロールの適切な管理

ロールを選択する際は、まずAzureが標準で提供している「組み込みロール」のなかで要件を満たせるものがないかを検討し、既存の組み込みロールでは権限が過剰または不足する場合にのみカスタムロールを作成します。

組み込みロールは、Azureの新機能追加や仕様変更に合わせてMicrosoft側で自動的にメンテナンスされます。一方、カスタムロールは定義したアクション（Actions / NotActions）を管理者自身で維持・更新しなければならず、乱立すると運用負荷が増大します。

業務要件上、どうしてもカスタムロールを作成する必要がある場合は、以下の手順とルールに従って管理します。

このように、標準機能の活用を第一としつつ、独自定義を行う場合は管理ルールを明確化することで、長期的に破綻しないアクセス制御基盤を構築できます。

Azure RBACを運用する際の注意点とトラブルシューティング

Azure RBACの本番運用では、システム仕様上の制限や権限評価の優先順位、キャッシュの仕組みに起因するトラブルが発生することがあります。運用開始後に業務を止めないためにも、代表的な3つの事象とその具体的な対処法を把握しておくことが重要です。

サブスクリプションあたりのロール割り当て上限数への対策

Azure RBACには、ロール割り当ての数に上限が設けられています。Microsoftの公式ドキュメント（Azure RBAC の制限のトラブルシューティング）では、1つのサブスクリプションにつき最大5,000件（管理グループスコープでは1つの管理グループにつき最大500件）とされています。サブスクリプションの5,000件には、サブスクリプション、リソースグループ、リソースの各スコープの割り当てが含まれ、管理グループスコープの割り当ては含まれません。資格あり（Eligible）の割り当てと、将来に予定された割り当ても、この上限に含まれません。どちらの上限も固定で、引き上げはできません。

この上限に達すると、Azure PortalやCLIから新規の権限付与を実行した際にRoleAssignmentLimitExceededというエラーコードが返され、それ以上のロール割り当てが一切できなくなります。CI/CDパイプラインでリソースとサービスプリンシパルの権限を自動生成している環境や、多数のマイクロサービスを単一サブスクリプションで運用している環境では、上限に到達する可能性があります。

現在のロール割り当て数は、Azure Portalの「サブスクリプション」画面から対象のサブスクリプションを選択し、「アクセス制御（IAM）」メニュー内の「ロールの割り当て」タブにあるグラフで確認できます。上限に近づいている場合や到達してしまった場合は、以下の対策を実施して割り当て数を削減します。

拒否の割り当て（Deny Assignments）が優先される仕組みの理解

「サブスクリプションの所有者ロールを持っているにもかかわらず、特定のリソースを削除・変更できない」というトラブルが発生した場合、最も疑うべき原因が「拒否の割り当て（Deny Assignments）」です。

Azure RBACの権限評価プロセスでは、拒否の割り当てはすべての許可ロール（所有者や共同作成者を含む）よりも常に優先して適用されるという仕様になっています。公式ドキュメントでは、拒否の割り当てを利用者が直接作成することはできず、Azureが作成・管理するとされています（顧客管理の拒否の割り当ては非公開プレビュー）。拒否の割り当てが作られる主な機能は以下の通りです。

操作エラーの原因が拒否の割り当てであるかどうかは、対象リソースの「アクセス制御（IAM）」画面にある「拒否の割り当て」タブから確認できます。ここにエントリが存在する場合、IAM画面から直接その拒否設定を削除することはできないため、生成元の機能（デプロイメントスタックやマネージド アプリケーションなど）側の設定で見直してください。なお、Azure Blueprints（プレビュー）は2027年1月31日にリタイア予定（2026年7月31日から段階的）で、公式の移行先はDeployment StacksとTemplate Specsです。

権限変更がシステムに反映されるまでのタイムラグ

ロールの割り当てを追加・削除した直後に「まだリソースにアクセスできない」「外したはずの権限で操作できてしまう」といった事象は、Azure内部のキャッシュ機構によるタイムラグが原因であるケースが大半です。

公式ドキュメントでは、ロールの割り当てを追加・削除してから変更が有効になるまで、最大10分かかることがあるとされています。管理グループスコープで、DataActionsを持つ組み込みロールの割り当てを追加・削除した場合は、データプレーンのアクセスが更新されるまで数時間かかることがあります。

権限変更を即座に反映させたい場合や、時間をおいても権限エラーが解消されない場合は、以下の手順を実行します。

これらの手順を実行し、10分以上経過しても意図したアクセス制御が機能しない場合は、操作対象が「コントロールプレーン（リソース自体の管理操作）」ではなく「データプレーン（ストレージ内のデータ読み書きやKey Vaultのシークレット取得など）」であり、割り当てたロールのDataActionsに該当権限が含まれていない可能性があります。その場合は、対象リソースのIAM画面で「アクセスの確認」機能を使用し、該当ユーザーに目的の操作権限が正しく付与されているかを再確認してください。

よくある質問（FAQ）

Azure RBACとMicrosoft Entraロールの違いは何ですか？

Azure RBACとMicrosoft Entraロール（旧Azure ADロール）は、管理対象となるリソースの種類とアクセス制御が適用される範囲が異なります。Azure RBACは仮想マシンやストレージなどのAzureリソースを管理し、Microsoft EntraロールはユーザーやグループなどのIDおよびディレクトリリソースを管理するために使用します。

両者の主な違いは以下のとおりです。

原則としてこれら2つのロール体系は独立していますが、例外的にMicrosoft Entra IDの「グローバル管理者」は、Azure portalの「Azureリソースのアクセス管理」スイッチで、テナント内のすべてのサブスクリプションに対するユーザー アクセス管理者ロールを自身に付与できる仕組み（サブスクリプションへのアクセスを取り戻すのに役立つと公式に説明されています）を備えています。双方のアーキテクチャや連携に関する詳細は、Microsoft Learnの公式ドキュメントで確認できます。

Azure RBACの利用に追加料金はかかりますか？

Azure RBACの基本機能は、Azureサブスクリプションに標準で含まれており無料で利用できます。組み込みロールの割り当てやカスタムロールの作成・管理自体に対して、追加の課金は発生しません。

ただし、Azure RBACと組み合わせて高度なIDガバナンス機能を利用する場合は、別途Microsoft Entraのライセンス（Microsoft Entra ID P2またはMicrosoft Entra ID Governance）が必要になります。追加コストが発生する主なケースは以下のとおりです。

複数のロールが割り当てられた場合、権限はどうなりますか？

1つのセキュリティプリンシパルに対して複数のロールが割り当てられた場合、付与されたすべてのロールの権限が合算（加算）される仕組みになっています。上位スコープから継承されたロールと、下位スコープで直接割り当てられたロールがある場合も同様に、双方の許可アクションが組み合わされます。

例えば、あるユーザーにサブスクリプションのスコープで「閲覧者」ロールが割り当てられ、特定のリソースグループのスコープで「仮想マシンの共同作成者」ロールが割り当てられたとします。このユーザーは、サブスクリプション内のすべてのリソースを閲覧できると同時に、対象のリソースグループ内では仮想マシンの作成や起動・停止などの操作も実行可能です。

なお、前章で触れた「拒否の割り当て（Deny Assignments）」が存在する場合に限り、合算された許可設定よりも拒否設定が優先され、該当する操作はブロックされます。

リソースの「所有者」と「共同作成者」の決定的な違いは何ですか？

「所有者（Owner）」と「共同作成者（Contributor）」の決定的な違いは、他のユーザーやグループに対してアクセス権（ロール）を付与・変更・削除できるかどうかにあります。リソース自体の作成や変更、削除といった操作に関しては、どちらのロールも同等の権限を持っています。

システム内部のロール定義において、両者は拒否アクション（NotActions）の指定内容によって明確に区別されています。

共同作成者のNotActionsには、このほかにも、アクセス権の昇格（elevateAccess）やデプロイメントスタックの拒否設定の管理、サブスクリプションの取り消しなどが含まれます（公式の組み込みロール一覧）。日常的なインフラ構築やアプリケーションのデプロイ作業を行うエンジニアには「共同作成者」を割り当て、プロジェクトの管理者やセキュリティ担当者のみに「所有者」を割り当てることで、権限の不正な拡散を防げます。

一時的に特権を付与する仕組みはありますか？

一時的に特権を付与する仕組みとして、Microsoft Entra Privileged Identity Management（PIM）が提供されています。PIMを導入すると、常時権限を付与する「アクティブな割り当て」ではなく、必要な時だけ権限を有効化する「資格のある割り当て（Eligible）」が可能になり、Just-In-Time（JIT）アクセスを実現できます。

たとえば、普段は「閲覧者」権限のみを持つ運用担当者に対し、緊急のトラブルシューティングや定期メンテナンスの作業時間帯だけ「所有者」や「共同作成者」のロールを付与するといった運用が可能です。PIMによる一時的な権限昇格では、主に以下の制御を組み込めます。

これにより、特権アカウントの放置や権限の消し忘れによるセキュリティリスクを低減できます。

まとめ

本記事では、Azure RBAC（ロールベースのアクセス制御）の基本構造と設計・運用の要点を解説しました。

まずは現在のリソースのアクセス権を確認し、自社のAzure環境で安全な権限設計を実践してみましょう。