MS_RBAC

Role Based Access Control (RBAC)

戻る（Azure（MS_Azure.md）、Azureのアクセス制御と権限、Azure Resource Manager (ARM)）
- Role Based Access Control (RBAC)
- リソースアクセスストラテジ
- PMI（権限管理基盤）

概要

アクセス権は、
- Azure ポータル、
- Azure コマンドラインツール、
- および Azure 管理 API
を使用して割り当てる。
Azure ポータルで RBAC を設定する場合、
Access Control（IAM: Identity and Access Management）から行う。
スコープに対する特定アクションにアクセスできるユーザを
ロールベースのアクセス制御 (RBAC: Role Based Access Control) で制御できる。
アクセス権を付与するには、
- ユーザ、グループ、サービスにロールを割り当て、
- それを、特定のスコープに関連付ける。

補足: Azure には紛らわしい 2 種類のロールがある。混同しやすい。

Azure RBAC Microsoft Entra ロール

対象 Azure リソース（VM、ストレージ等） ディレクトリ（ユーザ、アプリ登録等）

スコープ管理グループ／サブスクリプション／RG／リソーステナント（一部は管理単位）

例共同作業者、閲覧者グローバル管理者、ユーザー管理者

本ページは前者（Azure RBAC）の話である。「共同作業者を付けたのにユーザを作れない」といった混乱は、この 2 系統を取り違えていることが原因である。

ロール

ロールの定義

アクセス権は、

操作（主）
データ操作（副）

のアクセス許可セット的なもの。

操作（主）

Actions、NotActions を定義して、AssignableScopes のスコープに関連付ける。
操作のアクセス権は、Actions の操作から NotActions の操作を
差し引くことで算出される。

データ操作（副）

DataActions、NotDataActions を定義して、
AssignableScopes のスコープに関連付ける。
データ操作のアクセス権は、DataActions の操作から
NotDataActions の操作を差し引くことで算出される。

※ ただし、対応リソースが少ない（通常データ・ストアに依存した機能を使用する）ため、
あまり使用しない。

補足: この「操作」と「データ操作」の分離は重要である。例えばストレージアカウントの場合、

Actions — ストレージアカウント自体の管理（作成、キーの取得）

DataActions — 中の Blob の読み書き

が別物である。「所有者ロールを付けたのに Blob が読めない」のはこのためで、データ面のアクセスには「ストレージ BLOB データ共同作成者」のような DataActions を持つロールが別途必要になる。

なお、NotActions は拒否ではない。単に許可集合からの差し引きであり、別のロール割り当てで許可されていれば、そちらが効く。明示的な拒否は「拒否割り当て」という別機能である。

定義の例

{
  "Name":  "Storage Blob Data Reader",
  "Id":  "2a2b9908-6ea1-4ae2-8e65-a410df84e7d1",
  "IsCustom":  false,
  "Description":  "Allows for read access to Azure Storage blob containers and data",
  "Actions":  [
    "Microsoft.Storage/storageAccounts/blobServices/containers/read"
  ],
  "NotActions":  [],
  "DataActions":  [
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotDataActions":  [],
  "AssignableScopes":  [
    "/"
  ]
}

ロールの種類

ロールの種類には、組み込みロールとカスタム・ロールがある。

組み込みロール

ユーザ、グループ、サービスに割り当てられる組み込みのロールが用意されている。
ただし、説明文は的確ではない表現も多いため、必ず中身をしっかり確認すること。

4 つのプラットフォームロール

ロール	内容
所有者（Owner）	「アクセス権の割当」を含め、全てを管理できる
共同作業者（Contributor）	「アクセス権の割当」以外の、全てを管理できる
閲覧者（Reader）	すべてを閲覧できるが、変更はできない
ユーザ・アクセス管理者（User Access Administrator）	Azure リソースへのユーザアクセスを管理できる

リソース固有ロール

ネットワークの共同作業者
他の「リソース固有ロール」に含まれないネットワーク系の設定変更が可能となっている。
- すべてのネットワークリソースを管理できるが、
- ネットワークリソースのアクセス許可は設定できない。
仮想マシンの共同作業者（Virtual Machine Contributor）
- 仮想マシンを管理できるが、
- 仮想マシンのアクセス許可は設定できない。
- 接続先の仮想ネットワークまたはストレージ・アカウントの管理はできない。
ストレージ・アカウントの共同作業者
- ストレージ・アカウントを管理できるが、
- ストレージ・アカウントのアクセス許可は設定できない。
SQL Server の共同作業者（SQL Server Contributor）
- SQL サーバーおよびデータベースを管理できるが、
- そのセキュリティ関連ポリシーは設定できない。
Web サイトの共同作業者（Web Site Contributor）
- Web サイトを管理できるが、
- 接続されている Web プランは設定できない。
, etc.（多数ある）

カスタム・ロール

組み込みのロールの中にアクセス権に関する特定の要件を満たすものがない場合、
Azure のロールベースのアクセス制御 (RBAC) でカスタム・ロールを作成する。

ただし、極力、カスタム・ロールは作らないようにする。
スコープをリソース・グループやリソース単位に絞って、
共同作業者（Contributor）ロールを設定することで対応可能。

補足: この方針は妥当である。カスタムロールは、Azure 側にリソースプロバイダの操作が追加されるたびに 追随してメンテナンスする必要がある（新機能が使えない、という形で顕在化する）。組み込みロール＋スコープの絞り込みで足りるなら、そちらを選ぶこと。

スコープ

ロールに関連付けるスコープ。

指定できるスコープ

サブスクリプション
リソース・グループ
または単独のリソース

補足（最新化）: 現在は最上位に 管理グループ（Management Group） が追加されており、スコープは 4 階層である。
管理グループ → サブスクリプション → リソース・グループ → リソース
複数サブスクリプションに横断的にロールを割り当てるには、管理グループのスコープを使う。

アクセス権の継承

各スコープは、以下のように RBAC を継承する。

サブスクリプション ← リソース・グループ ← リソース

親スコープでロールが関連付けられると、
その親に含まれる子へのアクセス権も付与される。
例えば、リソース・グループへのアクセス権を持つユーザは、
Web サイト、仮想マシン、サブネットなど、
リソース・グループに含まれるすべてのリソースを管理できる。

アクセス権の割当

サブスクリプションの所有者は

他のユーザ・グループに詳細なロールを割り当て、
上記をスコープに関連付け

ると、当該リソースを管理できるようになる。

操作	内容
割り当て	ロール ←→（ユーザ ←→ グループ）
関連付け	ロール ←→（ユーザ ←→ グループ）←→ スコープ

設定例

カスタム・ロール（作業者用）

「DevTest Labs User」組込ロールを更に絞った、
「仮想マシンの起動と停止」カスタム・ロールを作成する。

$role = Get-AzRoleDefinition "Virtual Machine Contributor"

$role.Id = $Null
$role.Name = "仮想マシンの起動と停止"
$role.Description = "仮想マシンの起動と停止、再起動ができます"

$role.Actions.Clear()
$role.Actions.Add("Microsoft.Compute/VirtualMachines/start/action")
$role.Actions.Add("Microsoft.Compute/VirtualMachines/restart/action")
$role.Actions.Add("Microsoft.Compute/VirtualMachines/deallocate/action")
$role.Actions.Add("Microsoft.Storage/*/read")
$role.Actions.Add("Microsoft.Network/*/read")
$role.Actions.Add("Microsoft.Compute/*/read")
$role.Actions.Add("Microsoft.Authorization/*/read")
$role.Actions.Add("Microsoft.Resources/subscriptions/resourceGroups/read")
$role.Actions.Add("Microsoft.ResourceHealth/availabilityStatuses/read")
$role.Actions.Add("Microsoft.Insights/alertRules/*")
$role.Actions.Add("Microsoft.Support/*")

$role.AssignableScopes.Clear()
$role.AssignableScopes.Add("/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx")

New-AzRoleDefinition -Role $role

ロールをサブスクリプション・スコープに適用する。

New-AzRoleAssignment `
  -SignInName <emailOrUserprincipalname> `
  -RoleDefinitionName "仮想マシンの起動と停止" `
  -Scope /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

ロールの更新は、JSON を使った GET ＆ SET で行う。

Get-AzRoleDefinition -Name "仮想マシンの起動と停止" `
  | ConvertTo-Json `
  | Out-File -FilePath "D:\custom_role.json"

# JSON をメンテナンスした後
Set-AzRoleDefinition -InputFile "D:\custom_role.json"

設定の反映には、アカウントのサインアウト → サインインが必要。

補足: 「サインアウト → サインインが必要」なのは、ロール情報がアクセストークンにキャッシュされるためである。トークンの有効期限（既定 1 時間）が切れるまで古い権限のまま動くことがある。権限を剥奪した場合も同様に即時反映されない点は、インシデント対応時に注意すること。

管理者用カスタム・ロールの例

特定のリソース・グループに、
仮想マシンの共同作業者（Virtual Machine Contributor）の権限だけ付与する。

New-AzRoleAssignment `
  -SignInName <emailOrUserprincipalname> `
  -RoleDefinitionName "Virtual Machine Contributor" `
  -ResourceGroupName [既存のRG名]

VM 作成には上記では権限が足りないため、
実際には以下のような権限の追加が必要になる。

"Microsoft.Network/networkSecurityGroups/read",
"Microsoft.Network/networkSecurityGroups/write",
"Microsoft.Network/publicIpAddresses/write",
"Microsoft.Network/publicIpAddresses/read",

ロール作成と付与のポイント

付与

「サブスクリプション → リソース・グループ → リソース」のスコープがある。
上位に付与した権限を下位で拒否できないので、
最小限、許可するものダケを積み重ねていく。
- 上位スコープには最小限の参照系の権限を付与し、
- 下位スコープには具体的作業に必要な更新系の権限を付与する。

補足: 「上位の権限を下位で拒否できない」は Azure RBAC の加算（allow のみ）モデルによるもので、正しい。例外として 拒否割り当て（Deny Assignment） があるが、これは Azure Blueprints や Managed Application が内部的に作るもので、利用者が直接作成することはできない。

なお、権限の抑制には RBAC ではなく Azure Policy を使う手もある。 RBAC が「誰が何をできるか」を制御するのに対し、 Azure Policy は「どんなリソースが作れるか」を制御する。目的が違うので使い分けること。

作成

カスタムロールに含めるロール・アクションの探し方。

trial and error 的で非効率的だが、error からたどるのが一番確実。
ドキュメント系は、まだ、完全に書かれたものは少ない。

補足: Get-AzProviderOperation "Microsoft.Compute/*" でリソースプロバイダの操作を列挙できるほか、 アクティビティログの失敗レコードに不足している操作名が記録されるため、そこから拾うのが確実である。

その他

サービスの場合

補足: 人ではなくアプリ／サービスに権限を与える場合、 マネージド ID を第一候補にすること。サービスプリンシパル＋クライアントシークレットはシークレットの配置・ローテーションが必要になるが、マネージド ID はその管理が不要である（WebAPIの認証の補足も参照）。

参考

Tags: セキュリティ, アカウント, クラウド, 認証基盤, Azure, Active Directory

このWikiは「Open棟梁Project」,「OSSコンソーシアム開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki

Open 棟梁 Wiki

（未着手）

TOP

開発基盤部会 Wiki

移行管理: DONE ／ TODO

	Azure RBAC	Microsoft Entra ロール
対象	Azure リソース（VM、ストレージ等）	ディレクトリ（ユーザ、アプリ登録等）
スコープ	管理グループ／サブスクリプション／RG／リソース	テナント（一部は管理単位）
例	共同作業者、閲覧者	グローバル管理者、ユーザー管理者

Uh oh!

MS_RBAC

Role Based Access Control (RBAC)

概要

ロール

ロールの定義

操作（主）

データ操作（副）

定義の例

ロールの種類

組み込みロール

カスタム・ロール

スコープ

指定できるスコープ

アクセス権の継承

アクセス権の割当

設定例

カスタム・ロール（作業者用）

管理者用カスタム・ロールの例

ロール作成と付与のポイント

付与

作成

その他

サービスの場合

参考

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!