ロールを使用したリソース アクセスの制御
Azure リソースの組み込みロール (PowerShell を使用)
Azure には、最も一般的なセキュリティ シナリオに対応するために、いくつかの "組み込みロール" が用意されています。 ロールがどのように機能するかを理解するために、すべてのリソースの種類に適用される次の 3 つのロールを確認しましょう。
- 所有者: 他のユーザーにアクセス許可を委任する権限を含め、すべてのリソースへのフル アクセス権を持ちます。
- 共同作成者: すべての種類の Azure リソースを作成および管理できますが、他のユーザーにアクセス許可を付与することはできません。
- 閲覧者: 既存の Azure リソースを表示できます。
ロールの定義
各ロールは、JavaScript Object Notation (JSON) ファイルに定義されるプロパティのセットです。 このロールの定義には、名前、ID、説明が含まれます。 また、許可される権限 (Actions)、拒否される権限 (NotActions)、およびロールのスコープ (読み取りアクセスなど) も含まれます。
所有者ロールには、すべてのアクションを意味するアスタリスク (*) が示され、拒否されるアクションはありません。すべてのスコープであるスラッシュ (/) が示されます。
この情報は、PowerShell の Get-AzRoleDefinition Owner
コマンドレットを使用して取得できます。
Get-AzRoleDefinition Owner
このコードにより、次の出力が生成されます。
Name : Owner
Id : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
IsCustom : False
Description : Lets you manage everything, including access to resources.
Actions : {*}
NotActions : {}
DataActions : {}
NotDataActions : {}
AssignableScopes : {/}
共同作成者ロールと閲覧者ロールにも同じ操作を実行し、許可および拒否されるアクションを確認します。
組み込みロールを確認する
次に、他の組み込みロールをいくつか確認しましょう。
Azure portal を開きます。
Azure ホーム ページの左側のメニューで [リソース グループ] を選択してください。
リソース グループを選択します。 [リソース グループ] ペインが表示されます。
左側のメニュー ペインで、[アクセス制御 (IAM)] を選択します。 リソース グループの [アクセス制御 (IAM)] ペインが表示されます。
内部メニュー バーで、次のように [ロール] タブを選択して、使用可能なロールの一覧を表示します。
ロールの定義とは
ロールの定義はアクセス許可のコレクションです。 ロール定義には、ロールが実行できる読み取り、書き込み、削除などのアクセス許可が一覧表示されます。 実行できない操作または基となるデータに関連する操作を列挙することもできます。
前述のとおり、ロールの定義は次のような構造になっています。
名前 | 説明 |
---|---|
Id |
Azure によって割り当てられた、ロールの一意識別子。 |
IsCustom |
カスタム ロールの場合は True、組み込みロールの場合は False です |
Description |
ロールの理解しやすい説明 |
Actions [] |
許可されるアクセス許可。* はすべてを示します |
NotActions [] |
拒否されるアクセス許可 |
DataActions [] |
特定の許可されるアクセス許可で、データに適用されます (たとえば、Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read ) |
NotDataActions [] |
特定の拒否されるアクセス許可で、データに適用されます。 |
AssignableScopes [] |
このロールで適用するスコープ。/ はグローバルを示しますが、階層ツリーに適用できます |
この構造は、ロールベースのアクセス制御 (RBAC) または基になる API で使用される場合、JSON で表されます。 たとえば、JSON 形式の共同作成者ロールの定義を次に示します。
{
"Name": "Contributor",
"Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",
"IsCustom": false,
"Description": "Lets you manage everything except access to resources.",
"Actions": [
"*"
],
"NotActions": [
"Microsoft.Authorization/*/Delete",
"Microsoft.Authorization/*/Write",
"Microsoft.Authorization/elevateAccess/Action"
],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/"
]
}
Actions と NotActions
Actions
プロパティと NotActions
プロパティを調整して、必要なアクセス許可を付与および拒否することができます。 これらのプロパティは常に {Company}.{ProviderName}/{resourceType}/{action}
の形式になります。
例として、先ほど確認した 3 つのロールのアクションを次に示します。
組み込みロール | Actions | NotActions |
---|---|---|
所有者 (すべてのアクションを許可) | * |
- |
共同作成者 (ロールの割り当ての書き込みまたは削除を除くすべての操作を許可) | * |
Microsoft.Authorization/*/Delete, Microsoft.Authorization/*/Write, Microsoft.Authorization/elevateAccess/Action |
閲覧者 (すべての読み取り操作を許可) | */read |
- |
Actions
の下のワイルドカード (*
) 操作は、このロールに割り当てられたプリンシパルがすべてのアクションを実行できることを示しています。つまり、このロールは、Azure で新しいリソースの種類を追加する際、今後定義されるアクションを含め、すべてを管理できます。 閲覧者ロールの場合は、read
アクションのみが許可されます。
NotActions
以下の操作は、Actions
から除かれます。 共同作成者ロールの場合は、NotActions
によって、このロールはリソースへのアクセスの管理ができなくなり、リソースへのアクセス割り当ても削除されます。
DataActions と NotDataActions
データ操作は DataActions
プロパティおよび NotDataActions
プロパティで指定されます。 データ操作は、管理操作とは別に指定できます。 この結果、ワイルドカード (*
) を使用した現在のロールの割り当てによって、データに思いがけなくアクセスする動作が防止されます。 DataActions
と NotDataActions
で指定できるデータ操作には次のものがあります。
- コンテナーの BLOB の一覧の読み取り
- コンテナーのストレージ BLOB の書き込み
- キュー内のメッセージの削除
データ操作は、DataActions
と NotDataActions
プロパティにのみ追加できます。 リソース プロバイダーでは、isDataAction
プロパティを true
に設定して、どの操作がデータ操作であるかを指定します。 データ操作のないロールでは、ロールの定義からこれらのプロパティを省略できます。
これらのアクションの動作は、管理の従兄弟にそっくりです。 許可するアクション (すべての場合は *
) を指定し、NotDataActions
コレクション内で削除する特定のアクションの一覧を指定できます。 いくつかの例を次に示します。リソース プロバイダーのドキュメントでアクションとデータ アクションの完全な一覧を確認できます。
データ操作 | 説明 |
---|---|
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete |
BLOB データを削除する |
Microsoft.Compute/virtualMachines/login/action |
通常のユーザーとして VM にログインする |
Microsoft.EventHub/namespaces/messages/send/action |
イベント ハブでメッセージを送信する |
Microsoft.Storage/storageAccounts/fileServices/fileshares/files/read |
ファイル/フォルダーまたはファイル/フォルダーの一覧を返す |
Microsoft.Storage/storageAccounts/queueServices/queues/messages/read |
キューからメッセージを読み取る |
割り当て可能なスコープ
ロールを完全に実装するには、Actions プロパティと NotActions プロパティを定義するだけでは不十分です。 さらに、ロールのスコープを適切に指定する必要があります。
ロールの AssignableScopes プロパティで、ロールが割り当てに使用できるスコープ (サブスクリプション、リソース グループ、またはリソース) を指定します。 カスタム ロールは、それを必要とするサブスクリプションまたはリソース グループに割り当てを限定することにより、それ以外のサブスクリプションまたはリソース グループについては元のユーザー エクスペリエンスを保ち、不要な混乱を避けることができます。
次に例をいくつか示します。
目的 | スコープの使用 |
---|---|
サブスクリプションに制限する | "/subscriptions/{sub-id}" |
特定のサブスクリプションで特定のリソース グループに制限する | "/subscriptions/{sub-id}/resourceGroups/{rg-name}" |
特定のリソースに制限する | "/subscriptions/{sub-id}/resourceGroups/{rg-name}/{resource-name}" |
2 つのサブスクリプションの割り当てにロールを使用可能にする | "/subscriptions/{sub-id}", "/subscriptions/{sub-id}" |
ロールを作成する
Microsoft Entra ID には組み込みロールが用意されており、お客様が実行したいことの 99% は網羅されているはずです。 可能な場合、組み込みロールを使用することをお勧めします。 しかしながら、必要に応じてカスタム ロールを作成することもできます。
Note
カスタム役割の作成には、Microsoft Entra ID P1 または P2 が必要であり、Free レベルでカスタム役割を作成することはできません。
いくつかのメカニズムを利用して新しいロールを作成できます。
Azure portal:Azure portal を使用してカスタム ロールを作成するには、[Microsoft Entra ID]>[ロールと管理者]>[新しいカスタム ロール] の順に選択します。
Azure PowerShell:
New-AzRoleDefinition
コマンドレットを使用して新しいロールを定義できます。Azure Graph API: プログラムで Graph API の REST 呼び出しを使用して新しいロールを作成できます。
このモジュールの「まとめ」セクションに、3 つのすべての方法に関するドキュメントへのリンクがあります。