RBACとは？Azure RBACのスコープ・ロール・継承をインフラエンジニア向けに解説

RBACは一言で言うと、「誰に・どの権限を・どの範囲で与えるか」を管理する仕組みです。
クラウドでは権限＝攻撃範囲になるため、RBACの設計がそのままセキュリティ強度に直結します。

クラウドは非常に便利です。仮想マシンやストレージ、ネットワークなどのリソースを数クリックで作成できます。しかし便利である一方で、クラウドでは権限管理がセキュリティの中心になります。とりあえず管理者権限を付与する、一時対応のつもりで広い権限を付けたままにする、誰がどこまで操作できるのか把握できていない、このような状態では、アカウントが侵害された場合にクラウド環境全体へ被害が拡大する可能性があります。

そこで重要になるのがRBAC（Role Based Access Control）です。本記事ではAzure RBACを例に、クラウドの権限管理の考え方を解説します。

Azure RBAC
Microsoft AzureでリソースへのアクセスをRBACベースで制御する認可機能。AzureはActive Directory・Windows Server・Microsoft 365などMicrosoft製品との親和性が高く、企業環境での採用が増えている。

Azure RBACとは何か
1. IAMとRBACの関係
2. Azure RBACの基本構造
なぜクラウドではRBACが重要なのか
最小権限とRBACの実装
1. 最小権限の原則とRBAC
2. 特権管理の強化（JIT・PIM）
RBAC設計の実務と失敗パターン
1. チーム別の設計例
2. 設計の基本ルール
まとめ

Azure RBACとは何か

IAMとRBACの関係

クラウドのアクセス管理を学んでいると、RBACとIAMという言葉が登場します。これらは似たような文脈で使われますが、意味は少し異なります。

IAM（Identity and Access Management）とは、ユーザーの認証（Authentication）とアクセス権限の制御（Authorization）を含む、アクセス管理の仕組み全体を指します。ユーザー管理、認証（ログイン）、多要素認証（MFA）、アクセス権管理、監査ログといった機能を含む広い概念です。

【参考】Identity and access management – Glossary | CSRC

RBAC（Role Based Access Control）は、役割（Role）をベースにアクセス権を管理する方式です。IAMの中には複数のアクセス制御モデルがあり（RBAC・ABAC・ACLなど）、その中でRBACが多くの環境で広く使われています。

つまりIAMという大きな仕組みの中にRBACが含まれているという関係です。クラウド環境では、IAMでユーザーや認証を管理し、RBACでリソースの操作権限を管理するという形でこれらを組み合わせてセキュリティを実現しています。

IAMの基本（認証と認可の違い）については「IAMとは？認証と認可の違いから学ぶアクセス管理の基本」を参照してください。

MFAの基本については「MFAとは？多要素認証の仕組みと実務での導入・運用ガイド」を参照してください。

Azure RBACの基本構造

Azure RBACは、主に次の3つの要素で構成されています。

要素	内容
セキュリティプリンシパル	権限を付与する対象。ユーザー・グループ・アプリケーションなどが該当する。実務ではユーザー個人ではなくグループに対して権限を付与することが推奨される
ロール	実行できる操作をまとめたもの。代表的なロールはOwner（すべての操作）・Contributor（リソース管理）・Reader（閲覧のみ）
スコープ	権限が適用される範囲。管理グループ→サブスクリプション→リソースグループ→リソースという階層構造になっている

サービスプリンシパル
アプリケーションや自動処理がAzureリソースへアクセスするためのアカウント。CI/CDツールやバッチ処理など、人が直接操作しない自動処理に使用する。

Owner
Azureリソースに対してアクセス権（RBAC）の付与・変更も可能なため、実質的に最も強い権限。

Microsoft Entra ID
MicrosoftのクラウドID管理サービス（旧名称：Azure Active Directory）。Azure RBACロール（リソース管理）とEntra IDロール（ID管理）は別物のため注意が必要。

なおAzureには多数の組み込みロールが用意されています。（参考：Azureのロール一覧 | Microsoft Learn）

スコープについて補足します。

管理グループ（Management Group）
複数のサブスクリプションをまとめて管理するための管理単位。

サブスクリプション
Azureのリソースを管理する課金・管理単位。

リソースグループ
Azureリソースをまとめて管理する論理グループ。

重要な特徴として継承（Inheritance）があります。上位スコープで付与した権限は下位スコープに引き継がれます。例えばサブスクリプションレベルで「Contributor」を付与すると、配下のすべてのリソースグループ・リソースにも適用されます。つまり上位で強い権限を付与するほど影響範囲も広がるため、権限はできるだけ狭いスコープで付与することが重要です。

【参考】Azure RBAC のスコープについて | Microsoft Learn

なぜクラウドではRBACが重要なのか

オンプレミス環境では、ネットワーク境界による防御（境界型防御）が中心でした。社内ネットワークの外側にファイアウォールを配置し、外部からのアクセスを制御するという考え方です。

しかしクラウドでは、インターネット経由で管理操作を行うことが一般的なため、アカウントの権限そのものがセキュリティ境界になります。アカウントが侵害され強い権限が付与されていた場合、その権限の範囲まで攻撃者が操作できてしまいます。

つまりクラウドでは権限＝攻撃者が操作できる範囲（攻撃範囲）になる可能性があるのです。

侵入した攻撃者は横展開・権限昇格という手順で被害を拡大させます。

横展開（Lateral Movement）
侵入した攻撃者が別のシステムやリソースへアクセスを広げる攻撃手法。

権限昇格（Privilege Escalation）
攻撃者がより強い権限を取得して操作範囲を広げる攻撃手法。

これらの攻撃フェーズはMITRE ATT&CKでも整理されています。（参考：ATT&CK Matrix for Enterprise | MITRE ATT&CK）

RBACはこのような攻撃の拡大を防ぐための重要な仕組みです。

【参考】ゼロトラストというのは？ | Microsoft Learn

最小権限とRBACの実装

最小権限の原則とRBAC

RBACは、セキュリティの基本原則である最小権限の原則を実現するための仕組みです。

最小権限の原則
業務に必要な最小限の権限のみを付与するセキュリティ原則。詳しくは「最小権限の原則とは？実務での考え方と設計例」を参照。

例えば次のような設計が考えられます。

設計例	ロール	スコープ
❌ NG例	Owner	サブスクリプション全体
✅ OK例	Contributor	開発用リソースグループのみ

必要な権限だけ・必要な範囲だけ付与することで、セキュリティリスクを大きく下げることができます。

（参考：NIST SP 800-53 Rev.5 – AC-6: Least Privilege | CSRC）

特権管理の強化（JIT・PIM）

RBACはクラウドの権限管理の基本ですが、管理者権限（特権アカウント）の扱いについては追加の対策が必要です。管理者が常にOwner権限を持っている、管理者アカウントが長期間有効になっている、特権操作の監査が行われていない、このような状態では、アカウントが侵害された場合にクラウド環境全体が即座に危険な状態になる可能性があります。

そこで重要になるのがJust-In-Time（JIT）の考え方です。

JIT（Just-In-Time）権限
「必要なときだけ一時的に強い権限を付与する」という仕組み。通常時はReader、メンテナンス時のみOwner（1時間限定）→作業終了後に自動削除、という運用が実現できる。

Azureでは、特権アクセス管理を実現するための機能としてAzure PIM（Privileged Identity Management）が提供されています。

PIM（Privileged Identity Management）
特権アカウントを安全に管理し、承認ワークフロー・期限付き権限付与・MFA強制・監査ログ取得などを実現する仕組み。

PIMを使うと「必要なときだけ管理者」という安全な運用が実現できます。例えば、通常時はContributor（無効状態）、必要時にPIMで有効化→MFA認証→1時間だけContributorとして作業、という流れです。

PIMの設計・設定・監査ログの活用まで詳しくは「PIMとは？Azure特権アクセス管理の実務ガイド」で解説しています。

【参考】Privileged Identity Management とは？ | Microsoft Learn

クラウド環境のセキュリティでは、RBAC（役割ベース権限管理）・最小権限の原則・特権アクセス管理（PIM / JIT）を組み合わせることが重要です。

RBAC設計の実務と失敗パターン

チーム別の設計例

RBACの仕組みを理解しても、実際の環境でどのように設計すればよいのか迷うことも多いでしょう。よくある組織構成を例にRBAC設計のイメージを紹介します。

開発チームは、アプリケーションの開発やテスト環境の構築が役割です。開発環境のリソースを管理できる権限が必要ですが、本番環境にはアクセスできないよう設計します。

対象	ロール	スコープ
開発者グループ	Contributor	開発用リソースグループ

運用チームは、システムの監視や障害対応が役割です。リソースの状態を確認するための閲覧権限が必要で、変更・削除はできない設計にすることで誤操作による障害を防ぎます。

対象	ロール	スコープ
運用チームグループ	Reader	サブスクリプション

セキュリティチームは、監査やセキュリティ設定の管理が役割です。権限管理やセキュリティポリシーを確認できる権限が必要で、強い管理者権限はPIMによって一時的に有効化する運用が望ましいです。

対象	ロール	スコープ
セキュリティチーム	Reader / Security関連ロール	サブスクリプション

役割（Role）と業務内容を対応させて設計することで、誤操作の防止・不正アクセスの影響範囲の制限・権限管理の可視化を実現できます。

設計の基本ルール

RBACを安全に運用するための基本ルールは次の通りです。

個人ではなくグループに権限を付与する：ユーザー単位での直接付与は管理が属人化し、異動・退職時の対応漏れが発生しやすくなる
最小権限の原則を守る：Owner権限は本当に必要な場面に限定し、基本はContributor・Readerで設計する
スコープはできるだけ小さくする：サブスクリプション全体への付与は最後の手段。リソースグループ単位・リソース単位を基本にする
権限の定期レビューを行う：付与した権限は一度で終わりではなく、異動・退職・プロジェクト終了のタイミングで必ず見直す

RBAC設計でよくある具体的な失敗パターン（過剰権限・スコープ過大・個人管理・権限放置・ロール設計の曖昧さ・監査不足）については「Azure RBAC設計でよくある失敗6選と対策」で詳しく解説しています。

まとめ

クラウド環境では権限管理がセキュリティの中心になります。Azure RBACは「誰が・どの権限を・どの範囲で」持つのかを管理する仕組みです。RBACを適切に設計することで、過剰権限の防止・攻撃範囲の制限・権限管理の可視化を実現できます。

RBACを正しく設計するには「スコープ」「ロール」「権限管理」の理解が重要です。そのうえで最小権限の原則と特権管理（JIT・PIM）を組み合わせることが、クラウドセキュリティの基本となります。

あわせてご覧ください：

RBACとは？クラウド権限管理の基本とAzure RBACの仕組みをわかりやすく解説