🙆‍♀️

AzureロールではDenyが出来ない

2022/01/18に公開

はじめに

Azureを利用していて困ることの一つに、「ユーザーにこの操作をさせたくない」という時に、権限をはく奪する方法が(基本的に)無い、というのがあります。(Blueprints、というサービスでやれなくもないのですが...)

今回説明するのは、Azureロール(サブスクリプションに対する権限)の効果の発揮の仕方です。AWS経験者の方、特にご注意下さい。考え方が違うので、ここを勘違いして使おうとすると痛い目を見ます。

なお、Azureロールってなんぞ?という方はまずこちらをご覧ください。
https://zenn.dev/tomot/articles/6528bccdfbe546

Azureロールの考え方

基本的な考え方

Azureロールの定義は、下記のように構成されています。

(引用元)
https://docs.microsoft.com/ja-jp/azure/role-based-access-control/overview

やれること全体をまず「actions」に記載し、そこからやれないことを「notActions」に記載します。上の例だと、actionsが「アスタリスク」、notActionsに「Authorization」関連の権限が書かれます。
すなわちこの「共同作成者ロール」は「全操作を許可するけど、一部分の権限操作関連だけは許可しないよ」というロールになっているわけですね。
包含関係は↓の図のような感じになりますね。

ココまでだと、イイ感じに「この権限を与えない」ということが実現できそうです。

※最新の「共同作成者」ロールはblueprintsの権限も除外されていますので、最新の定義を貼っておきます。

{
  "assignableScopes": [
    "/"
  ],
  "description": "Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.",
  "id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
  "name": "b24988ac-6180-42a0-ab88-20f7382dd24c",
  "permissions": [
    {
      "actions": [
        "*"
      ],
      "notActions": [
        "Microsoft.Authorization/*/Delete",
        "Microsoft.Authorization/*/Write",
        "Microsoft.Authorization/elevateAccess/Action",
        "Microsoft.Blueprint/blueprintAssignments/write",
        "Microsoft.Blueprint/blueprintAssignments/delete",
        "Microsoft.Compute/galleries/share/action"
      ],
      "dataActions": [],
      "notDataActions": []
    }
  ],
  "roleName": "Contributor",
  "roleType": "BuiltInRole",
  "type": "Microsoft.Authorization/roleDefinitions"
}

複合問題


ではもう1つのロールの付与を考えてます。
こちらは「User Access Administrator」です。文字通り「ユーザーアクセスの管理者」ですから、権限を操作することができます。

{
  "assignableScopes": [
    "/"
  ],
  "description": "Lets you manage user access to Azure resources.",
  "id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/18d7d88d-d35e-4fb5-a5c3-7773c20a72d9",
  "name": "18d7d88d-d35e-4fb5-a5c3-7773c20a72d9",
  "permissions": [
    {
      "actions": [
        "*/read",
        "Microsoft.Authorization/*",
        "Microsoft.Support/*"
      ],
      "notActions": [],
      "dataActions": [],
      "notDataActions": []
    }
  ],
  "roleName": "User Access Administrator",
  "roleType": "BuiltInRole",
  "type": "Microsoft.Authorization/roleDefinitions"
}

Actionsでは「全てに対する参照権限、Authorizationに対する権限、サポートの権限」を付与されており、notActionsには何も記載されていません。
何も除外されていませんので、包含関係は↓のようになります。

問題設定

さて、あるユーザーにこの2つのロールを同時に与えたとき、どうなるでしょうか?包含関係は下記のようになります。なお、ベルギーっぽくなったのはたまたまです!

「Role1でnotActions」∧「Role2でActions」で記載された権限。すなわち例題で言うと「Microsoft.Authorizations」の権限はどうなるでしょうか?

答え

検証するまでもなく、ドキュメントに記載があり

(引用)
https://docs.microsoft.com/ja-jp/azure/role-based-access-control/role-definitions

あくまでnotActionsに書かれた内容は「権限を付与されなかった」だけであって「拒否」では無いんですね。
ですので、イメージとしては下のようになります。

今回の例題だと、Blueprintsの操作はできませんが、Authorizationsの操作はできてしまうってことですね!

Azure×拒否の実現には

Azureで実現するには「Blueprints」を使った「拒否割り当て」という機能を使うことになりますが、「原則拒否」+「許可する権限を列挙」+「対象外ユーザーを列挙」というような仕組みになっているため、「このユーザーから、この権限だけは奪いたいんだよね~」という場面には向きません。全体的なガードレールを敷く場面には良いんですが、残念ながら…。

おわりに

Azureロールでは権限の「拒否」はできませんよ!というお話でした。AWSに詳しい方は面食らうと思いますので、こちらご注意ください。

Discussion