Azureにおけるロールの種類とその影響範囲

はじめに
Azureを活用するうえで避けて通れないのが「アクセス制御」です。Microsoft Azureでは、Entraロール、RBAC(Role-Based Access Control)、Azure Policyという3つの主要なアクセス制御手段を活用します。
本記事では、Azure におけるアクセス制御の全体像と、それぞれのロールの影響範囲・役割を整理します。AWS を使用した経験がある方にとって理解しやすいように、適宜比較を交えて解説していきます。
全体概要
Azureの権限管理を理解するうえではMicrosoftサービスの全体像を一度理解する必要がありますので、まずはそこから説明します。
全体的なイメージとしてはこのような図になります。

まずは主要なリソースとその関係性を整理します。
▶ Microsoft Entra テナントとディレクトリ
- Microsoft Entra テナントは、Microsoftクラウドサービス(AzureやMicrosoft 365)を利用するための組織単位の「契約」または「セキュリティ境界」です。
- Microsoft Entra ディレクトリは、テナント内に存在し、ユーザー・グループ・アプリ管理する「ID管理のデータベース」です。Microsoft Serviceに対するアクセス管理も行います。
- 主な構成要素
ユーザー | サインインやリソース操作を行う個人。Object ID(GUID)で一意に識別される |
---|---|
グループ | 複数ユーザーの集合。アクセス権をまとめて付与できる |
アプリケーション | SSO対象やAPI認証のために登録された外部・内部アプリケーション(例:Teams、Salesforce) |
▶ Microsoft Service
- Microsoft ServiceはMicrosoftが提供するサービスの総称です。Microsoft Azureだけではなく、Microsoft TeamsやMicrosoft Exchangeなども含まれます。
▶ Azure内の構成
- Azure内の構成としては4段階に分かれています。AWSと比較してまとめてますので、対比させて理解するとわかりやすいです。
Azure | AWS |
---|---|
管理グループ | 組織(Organizations) |
サブスクリプション | アカウント |
リソースグループ | (直接の対応なし) |
リソース(VM、Storageなど) | リソース(EC2、S3など) |
この関係性を理解したうえで、権限管理の詳細を読むとスムーズに理解できるはずです!
Azureにおけるロールとアクセス制御の種類
Azure環境では、以下の3つの仕組みでロール(アクセス権)が管理されます。それぞれ影響範囲が異なるので、そこを明確にしながら説明していきます。
Entra ロール(旧Azure ADロール)
- 影響範囲:Entraディレクトリ全体(IDやポリシーなど)
- 用途:ID管理、認証・認可、セキュリティ管理などの権限付与
- 例:
- Azure リソースにアクセスするユーザー、グループ、サービス プリンシパル、マネージド ID を作成・編集・削除する
- 自社アプリや外部アプリが Microsoft Entra ID を使ってユーザー認証できるようにアプリケーションを登録する(App registration)
- サービス プリンシパルやマネージド ID を使用して、アプリやスクリプトから Azure リソースにアクセスできるようにする
- ユーザーがログインする際に MFA(多要素認証)を求めたり、特定の場所や端末からのみアクセスを許可するなどの条件付きアクセスを設定する
- Azure Key Vault など、一部の Azure リソースで ID ベースのアクセス制御(RBAC)を利用できるように構成する
- Azure Key Vault など、一部の Azure リソースでは、Azure RBAC によるアクセス制御を有効にするために、Microsoft Entra ID 上でサービス プリンシパルやマネージド ID を設定・連携する必要があります
- 対象:ユーザー/グループ(Entra内)
最初に示した図から管理対象を抜粋するとこんなイメージです。Entra ロールは、Microsoft サービス全体へのアクセス管理や、ユーザー・グループ・アプリケーションの管理を担う役割です。アプリ登録、サービスプリンシパル、マネージド ID など、Azure 上での認証や認可に関わる構成にも関与するため、特に理解が難しいロールと言えるでしょう。

Azure Policy
- 影響範囲:Azureリソース全体(ポリシー適用スコープ単位)
- 用途:構成ルールやセキュリティ標準の強制適用(例:特定リージョン以外のVM作成禁止)
- 例:タグの必須化、SKU制限、リージョン制限など
- 対象:リソースに対してのみ作用(ユーザー権限ではなく構成管理)
初めに示した図から管理対象を抜粋するとこんなイメージです。サブスクリプション単位で権限を管理をすることができます。アクセス管理できる内容はRBACと大きく変わらないため影響範囲が主に違うと理解してください。AWSのAWS OrganizationのSCPに相当していると考えると良いでしょう。

Azure RBAC(Role-Based Access Control)
- 影響範囲:Azure サブスクリプション/リソースグループ/リソース単位
- 用途:Azureリソースの操作制御(読み取り・書き込み・削除など)
- 例:所有者(Owner)、共同作成者(Contributor)、閲覧者(Reader)など
- 対象:Entra内のユーザー/グループ/アプリ(サービスプリンシパル)
Azure RBAC は、リソースの操作可否に関する権限を細かく管理する仕組みで、実際の運用管理に最も頻繁に使用されます。
初めに示した図から管理対象を抜粋するとこんなイメージです。サブスクリプション内の権限を管理することができます。AWSのIAM Roleに相当していると考えると良いでしょう。

ロールの階層関係
これまで紹介したロールでは種類ごとに適用される階層が異なります。図にするとこのような関係です。

階層構造で上の区分につけられた権限は下位のロールに対して上書きされることになります。そのためこの上下関係を意識して設定すると良いでしょう。
まとめ
Azure では、Microsoft Entra と Azure リソースで異なるロール制御の仕組みが用意されています。各ロールの目的と影響範囲を正しく理解し、適切な権限を付与することで、セキュアかつ効率的なクラウド運用が実現できます。AWSとの違いも把握することで、マルチクラウド環境でも混乱せず適切な設計が行えるようになります。
参考
- Microsoft Entra テナントとは