Skip to content

MS_RBAC

Jump to bottom
nishi_74322014 edited this page Aug 4, 2026 · 1 revision

Role Based Access Control (RBAC)

概要

  • アクセス権は、

    • 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

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally