#はじめに
Azure RBAC (ロールベースのアクセス制御) は、できることがとても多いので 1 つの記事ですべての RBAC の内容を網羅することは到底不可能な為、今回はタイトルに記載の動作に的を絞って検証をしてみました。

そもそも RBAC って何？っていう話もあるかと思いますが、RBAC に関する基本的な内容を押さえるには下記 Microsoft Learn の内容が非常によく出来ているので、ぜひ一度学んでみていただけると良いかと思います。

-Microsoft Learn
ロールベースのアクセス制御 (RBAC) を使用して Azure リソースのカスタムロールを作成する

この Microsoft Learn で学べること

RBAC と Azure AD の管理者ロールの違い
RBAC 組み込みロールとカスタムロールの違い
RBAC カスタムロール作成 (Cloud Shell / Power Shell / Azure ポータル)

割と最近までは Azure ポータルを利用してカスタムロールを作成するのは Public Preview でありましたが、2020 年 5 月から一般提供 (GA) されているので、今回はシンプルに Azure ポータル上ですべてカスタムロールを作成して検証しています。

-参考情報
Azure portal での Azure カスタムロール作成の一般提供を開始

また、今回の記事作成に参考にした Microsoft の公開情報は下記になります。

-参考情報
Azure ロールベースのアクセス制御 (Azure RBAC) とは
 Azure カスタムロール
 Azure 組み込みロール
 Azure ロールの定義について
 Azure portal を使用して Azure カスタムロールを作成または更新する
 Azure リソースプロバイダーの操作

カスタムロールも Azure リソースの元締め的な立ち位置である Azure Resrouce Manager (ARM / アーム) が管理しており、ARM テンプレートを利用してカスタムロールが作成できるように、カスタムロールの定義フォーマットは JSON フォーマットになります。



{
  "Name": "",
  "Id": "",
  "IsCustom": true,
  "Description": "",
  "Actions": [],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": []
}

上記プロパティ値の意味については以下のとおりになります。
(参照元：カスタムロールのプロパティ)

プロパティ	必須	Type	説明
Name / roleName	はい	String	カスタムロールの表示名。ロールの定義は、管理グループまたはサブスクリプションレベルのリソースですが、同じ Azure AD ディレクトリを共有する複数のサブスクリプションで使用できます。この表示名は、Azure AD ディレクトリ範囲で一意である必要があります。英字、数字、スペース、特殊文字を含めることができます。最大文字数は 128 文字です。
Id / Name	はい	String	カスタムロールの一意の ID。 Azure PowerShell と Azure CLI では、新しいロールを作成するときに自動的にこの ID が生成されます。
IsCustom / roleType	はい	String	これがカスタムロールであるかどうかを示します。カスタムロールの場合は true または CustomRole に設定します。組み込みロールの場合は false または BuiltInRole に設定します。
Description / description	はい	String	カスタムロールの説明。英字、数字、スペース、特殊文字を含めることができます。最大文字数は 1024 文字です。
Actions / actions	はい	String[]	ロールで実行できる管理操作を指定する文字列の配列。
NotActions / notActions	いいえ	String[]	許可された Actions から除外される管理操作を指定する文字列の配列。
DataActions / dataActions	いいえ	String[]	対象のオブジェクト内のデータに対して、ロールで実行できるデータ操作を指定する文字列の配列。 DataActions が含まれるカスタムロールを作成する場合、そのロールは管理グループのスコープで割り当てることができません。
NotDataActions / notDataActions	いいえ	String[]	許可された DataActions から除外されるデータ操作を指定する文字列の配列。
AssignableScopes / assignableScopes	はい	String[]	割り当てにカスタムロールを使用できるスコープを指定する文字列の配列。カスタムロールの AssignableScopes に定義できる管理グループは 1 つだけです。 AssignableScopes への管理グループの追加は、現在プレビューの段階です。

この JSON ファイルを Azure ポータルで作るのか、PowerShell で作るのか、Azure CLI で作るのかはたまた REST API を使うのか、という違いがあるだけで、実行先は同じ ARM になります。

Azure Resource Manager とは

上記カスタムロールのプロパティにあるとおり、Actions は実行させたい操作内容を記載し、NotActions は Actions の中で定義している操作内容の中から実行させたくない操作 を記載します。

この文章だけで理解できた人は充分に RBAC を理解いただいていると思いますので、これ以降の内容は読んでいただかなくても大丈夫です。
今回は Actions と NotActions に全く同じ操作内容を記載した場合の動作と同一の操作内容を定義した別のカスタムロールを同じユーザーに対して割り当てた場合の動作を確認してみます。

#先に結論

カスタムロールは組み込みロールという Microsoft があらかじめ各 Azure サービス向けに用意している RBAC 以外にユーザー自身がオリジナルで作成できるロールになります。
なんでもかんでもカスタムロールを作成して管理するというよりかは、組み込みロールの中に自分が使いたいロールがない場合に用意するものになります。

まず先に結論だけを書きます。結論だけ知りたい方はこちらの一覧表をご覧ください。

No.	パターン	動作結果
1	同一リソースに対して Actions と NotActions に同一アクションを定義	NotActions に記載されているので定義したアクションは実行できなくなる
2	同一リソースに対して Actions に定義したアクションのうち、NotActions に別のアクションを定義	NotActions に記載されているアクションのみ実行できなくなる
3	No.2 で定義したカスタムロールに NotActions を省いた別のカスタムロール (No.3) を同一ユーザーに対して割り当て	No.3 のロールの権限が実行できる (No.2 の NotActions は効果を発揮しない)

また、アクションを含む操作の書式は以下のとおりです。

{Company}.{ProviderName}/{resourceType}/{action}

上記 actions の部分に各リソースに対して何をさせる (GET / PUT or PATCH / POST / DELETE / 全て) かを定義します。

(参照元：操作の形式)

アクションの部分文字列	説明
*	ワイルドカード文字は、文字列と一致するすべての操作に対するアクセスを許可します。
read	読み取り操作 (GET) を有効にします。
write	書き込み操作 (PUT または PATCH) を有効にします。
action	仮想マシンの再起動 (POST) などのカスタム操作を有効にします。
delete	削除操作 (DELETE) を有効にします。

#やってみる
###No.1 の動作検証
では、まず No.1 の「同一リソースに対して Actions と NotActions に同一アクションを定義」を検証してみます。

まず、おおもとのカスタムロールの JSON テンプレートは下記となります。
(引用元：カスタムロールの例)

{
  "Name": "Virtual Machine Operator",
  "Id": "88888888-8888-8888-8888-888888888888",
  "IsCustom": true,
  "Description": "Can monitor and restart virtual machines.",
  "Actions": [
    "Microsoft.Storage/*/read",
    "Microsoft.Network/*/read",
    "Microsoft.Compute/*/read",
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Authorization/*/read",
    "Microsoft.ResourceHealth/availabilityStatuses/read",
    "Microsoft.Resources/subscriptions/resourceGroups/read",
    "Microsoft.Insights/alertRules/*",
    "Microsoft.Insights/diagnosticSettings/*",
    "Microsoft.Support/*"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId1}",
    "/subscriptions/{subscriptionId2}",
    "/providers/Microsoft.Management/managementGroups/{groupId1}"
  ]
}

このカスタムロールで何ができるかというと、端的にいうと Azure VM の監視と再起動 (起動含む) ができます。
Azure ポータルから上記 JSON フォーマットをベースにカスタムロールを作成すると、以下のようにアクセス制御 (IAM) の一覧に表示されます。
(種類を CustomeRole)に選択するとカスタムロールだけが表示されます。

今時点ではユーザー、グループ、サービスプリンシパルに作成したカスタムロールを割り当てていないので、それぞれ数字が 0 になっています。
一度この状態で test001 ユーザーに割り当ててみます。

この状態では NotActions には何も定義していないので、 Actions に定義されている操作が実行可能になります。
具体的には、定義したサブスクリプション配下にいる Azure VM を下記画面ショットのように「再起動」をクリックして再起動させることが可能です。

再起動されました。

これは定義しているとおりの Action ができたということで RBAC のごくごく一般的な動作になります。
ここにカスタムロールの定義として、 NotActions に "Microsoft.Compute/virtualMachines/restart/action" を追加して実行してみましょう。

画面右の「…」より「編集」をクリックします。

変更前)

 "actions": [
                    "Microsoft.Storage/*/read",
                    "Microsoft.Network/*/read",
                    "Microsoft.Compute/*/read",
                    "Microsoft.Compute/virtualMachines/start/action",
                    "Microsoft.Compute/virtualMachines/restart/action",
                    "Microsoft.Authorization/*/read",
                    "Microsoft.ResourceHealth/availabilityStatuses/read",
                    "Microsoft.Resources/subscriptions/resourceGroups/read",
                    "Microsoft.Insights/alertRules/*",
                    "Microsoft.Insights/diagnosticSettings/*",
                    "Microsoft.Support/*"
                ],
                "notActions": [],

変更後)

                "actions": [
                    "Microsoft.Storage/*/read",
                    "Microsoft.Network/*/read",
                    "Microsoft.Compute/*/read",
                    "Microsoft.Compute/virtualMachines/start/action",
                    "Microsoft.Compute/virtualMachines/restart/action",
                    "Microsoft.Authorization/*/read",
                    "Microsoft.ResourceHealth/availabilityStatuses/read",
                    "Microsoft.Resources/subscriptions/resourceGroups/read",
                    "Microsoft.Insights/alertRules/*",
                    "Microsoft.Insights/diagnosticSettings/*",
                    "Microsoft.Support/*"
                ],
                "notActions": [
                    "Microsoft.Compute/virtualMachines/restart/action"
                ],

「確認と更新」をクリックします。

「OK」をクリックして設定を反映させます。

これで定義が変更されたので、test001 で同じ Azure VM が再起動できるのか、できないのか試してみます。
同じように「再起動」→「OK」の順にクリックします。

実行できませんでした。対象の VM に対して "Microsoft.Compute/virtualMachines/restart/action" を実行する権限がない、と書かれていますね。

つまりどういうことかといいますと、カスタムロール名「Virtual Machine Operator」で定義したアクションのうち、 "Microsoft.Compute/virtualMachines/restart/action" のみが NotActions として定義されているので、このアクションのみが除外される、つまり差し引かれる動作になる、ということになります。

最初から Actions に定義しなければ良いじゃん、と言われればそれまでなのですが、例えばあらかじめ作成済みのカスタムロールに対してやっぱりこのアクションの権限を与えるのをやめよう、となった場合に NotActions に一行書いてあげれば NotActions に書かれたアクションだけが実行権限から除外できる、という運用の方法が考えられます。

###No.2 の動作検証
次に「同一リソースに対して Actions に定義したアクションのうち、NotActions に別のアクションを定義」した場合の動作を検証してみます。
このパターンが NotActions の正しい使い方だと思いますが、例えば Azure VM の新規作成や変更は許可させるが、削除だけは実行させたくない、というユーザーがいた場合のカスタムロールを考えてみます。

ベースとして組み込みロールである「Virtual Machine Contributor」をもとにカスタムロールを作成してみます。
Azure ポータルの「カスタムロールを作成する」より「ロールを複製します」を選んだ後に複製するロールのテンプレートとして「仮想マシン共同作成者 (Virtual Machine Contributor)」を選択します。

設定内容)

NotActions に "Microsoft.Compute/virtualMachines/delete" を追記します。

            {
                "actions": [
                    "Microsoft.Authorization/*/read",
                    "Microsoft.Compute/availabilitySets/*",
                    "Microsoft.Compute/locations/*",
                    "Microsoft.Compute/virtualMachines/*",
                    "Microsoft.Compute/virtualMachineScaleSets/*",
                    "Microsoft.Compute/disks/write",
                    "Microsoft.Compute/disks/read",
                    "Microsoft.Compute/disks/delete",
                    "Microsoft.DevTestLab/schedules/*",
                    "Microsoft.Insights/alertRules/*",
                    "Microsoft.Network/applicationGateways/backendAddressPools/join/action",
                    "Microsoft.Network/loadBalancers/backendAddressPools/join/action",
                    "Microsoft.Network/loadBalancers/inboundNatPools/join/action",
                    "Microsoft.Network/loadBalancers/inboundNatRules/join/action",
                    "Microsoft.Network/loadBalancers/probes/join/action",
                    "Microsoft.Network/loadBalancers/read",
                    "Microsoft.Network/locations/*",
                    "Microsoft.Network/networkInterfaces/*",
                    "Microsoft.Network/networkSecurityGroups/join/action",
                    "Microsoft.Network/networkSecurityGroups/read",
                    "Microsoft.Network/publicIPAddresses/join/action",
                    "Microsoft.Network/publicIPAddresses/read",
                    "Microsoft.Network/virtualNetworks/read",
                    "Microsoft.Network/virtualNetworks/subnets/join/action",
                    "Microsoft.RecoveryServices/locations/*",
                    "Microsoft.RecoveryServices/Vaults/backupFabrics/backupProtectionIntent/write",
                    "Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/*/read",
                    "Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/read",
                    "Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/write",
                    "Microsoft.RecoveryServices/Vaults/backupPolicies/read",
                    "Microsoft.RecoveryServices/Vaults/backupPolicies/write",
                    "Microsoft.RecoveryServices/Vaults/read",
                    "Microsoft.RecoveryServices/Vaults/usages/read",
                    "Microsoft.RecoveryServices/Vaults/write",
                    "Microsoft.ResourceHealth/availabilityStatuses/read",
                    "Microsoft.Resources/deployments/*",
                    "Microsoft.Resources/subscriptions/resourceGroups/read",
                    "Microsoft.SqlVirtualMachine/*",
                    "Microsoft.Storage/storageAccounts/listKeys/action",
                    "Microsoft.Storage/storageAccounts/read",
                    "Microsoft.Support/*"
                ],
                "notActions": [
                     "Microsoft.Compute/virtualMachines/delete"
                ],

"Microsoft.Compute/virtualMachines/" というワイルドカード「*」なのでこのカスタムロールを割り当てたサブスクリプション内にいる Azure VM 上の操作を自由にできますが、 NotActions に "Microsoft.Compute/virtualMachines/delete" と定義しているので削除だけはできないという動作が期待されます。

このカスタムロール名「Virtual Machine Operator-002」を test002 ユーザーに割り当てました。

この状態で test002 ユーザーで Azure VM を一台作成してみます。
検証に成功しましたので、「作成」をクリックして Windows10-002 を作成します。

作成、できませんね…権限が足りないようです。
エラー内容を整理すると、下記権限が不足していました。

'Microsoft.Network/networkSecurityGroups/write' を行うアクセス許可がありません。
'Microsoft.Network/publicIpAddresses/write' を行うアクセス許可がありません。

※仮想マシン共同作成者 (Virtual Machine Contributor)は上記リソースに対して Read 権限しかないので、これは想定される動作でした。

作成したカスタムロールに追加しましょう。

一度サインインしなおしてリトライしてみます。
今度は上手く行ってそうですね、エラー後に追加した networkSecurityGroups と publicIpAddresses に対する書き込み権限を付与したことで、NSG とパブリック IP アドレスが test002 に付与したカスタムロールの権限で実行できていることが分かります。

無事 Windows10-002 が作成、起動しました。ではこのユーザー権限で Azure VM を削除できないことを確認します。

「削除」→「はい」をクリックしてみます。

削除に失敗しました。期待していた動きになりました。
これは、 NotActions に "Microsoft.Compute/virtualMachines/delete" が定義されているため、削除するアクションのみ実行が許可されていないためです。

これが本来の NotActions の使い方と言えるのではないでしょうか。
Microsoft の公開情報にも書いているとおり、NotActions を定義すると、Actions で定義している操作から、操作をさせたくないアクションが差し引かれる動作になります。

-参考情報
NotActions

NotActions アクセス許可には、許可された Actions から除外される管理操作を指定します。制限対象の操作を除外する方が、許可する操作セットを容易に定義できる場合は、NotActions アクセス許可を使用します。ロール (有効なアクセス許可) によって付与されたアクセスは、Actions 操作から NotActions 操作を引くことによって計算されます。

###No.3 の動作検証
最後に No.3 として「No.2 で定義したカスタムロールに NotActions を省いた別のカスタムロール (No.3) を同一ユーザーに対して割り当て」を試してみます。

これは先に結論の部分でも書いたとおり、
NotActions を記載していない新たなカスタムロールが同一ユーザーである test002 に追加されたことで、加算方式的に追加された分のカスタムロールの権限が利用できる動作になります。

-参考情報
複数のロールの割り当て

複数のロールの割り当てが重複しているとどうなるでしょうか。 Azure RBAC は加算方式のモデルであるため、自分で行ったロール割り当ての合計が自分の実際のアクセス許可になります。ここで、ユーザーにサブスクリプションスコープの共同作成者ロールとリソースグループの閲覧者ロールが付与されている例を考えてみましょう。共同作成者アクセス許可と閲覧者アクセス許可を足すと、実質的にリソースグループの共同作成者ロールになります。そのため、この場合、閲覧者ロールの割り当ては効果がありません。

さきほど見ていただいた NotActions に関する公開情報にも次のように書かれています。
-参考情報
NotActions

NotActions で特定の操作を除外したロールをユーザーに割り当てたうえで、同じユーザーにその操作へのアクセス権を付与する別のロールを割り当てた場合、ユーザーはその操作の実行が許可されます。 NotActions は拒否ルールとは異なり、特定の操作を除外する必要があるときに、許可の対象となる一連の操作を指定しやすくすることを目的としたものに過ぎません。

つまり、NotActions はあくまで定義されたカスタムロール内でのみ効力を発揮し、その他のカスタムロールが同じユーザーに割り当てられてしまうと、加算方式により効果がなくなってしまう、ということになります。

実際にそうなるか確認してみましょう。
カスタムロール名「Virtual Machine Operator-002」をコピーして「Virtual Machine Operator-003」を作成します。

NotAction の Microsoft.Compute/virtualMachines/delete の右の「ゴミ箱」アイコンをクリックして削除します。

NotAction が定義されていないことを確認し、「作成」をクリックします。

作成した「Virtual Machine Operator-003」を test002 に割り当てます。

これで、Azure VM が削除できない NotActions の Microsoft.Compute/virtualMachines/delete が定義されている「Virtual Machine Operator-002」と NotActions に Microsoft.Compute/virtualMachines/delete が定義されていない、つまり Azure VM が削除可能な「Virtual Machine Operator-003」の両方のカスタムロールが test002 に割り当たりました。

この状態で test002 でサインインし Azure VM が削除できるかどうか試してみます。
さきほど作成した Windows10-002 を「削除」→「はい」にて削除を試みます。

削除が始まりました。

削除が完了しました。

Windows10-002 が一覧から消えていることが確認できました。
これで Azure VM が削除可能なカスタムロールが追加で同じユーザーに割り当たると、NotActions で Azure VM の削除ができないように定義していても実行が可能になる、という動作が確認できました。

#おわりに
今回は Azure RBAC のカスタムロールにおける Actions と NotActions に関する動作を 3 パターン確認してみました。
NotActions は実行をさせたくない権限を定義したい時に有効な設定方法であることが分かったのと同時に、複数のカスタムロールが同じユーザーにかぶさった状態になった場合には、その効力がなくなり、加算方式的に権限が追加される動作になることが分かりました。

今回の動作を押さえていただくことで、定義した RBAC と想定外の動きをしているな、と分かった時に定義内容の切り分けのポイントとして使えるのではないかと思います。

今回の記事が少しでもお役に立てれば幸いです。