[Azure] Azure ADにおけるアクセス制御

RBAC ロールベースのアクセス制御

Azureでは、サブスクリプションやリソースグループなどの一部分だけを管理するためのアクセス制御が行えます。このように細かくロールを区切って運用管理を行うアクセス制御を、ロールベースのアクセス制御(RBAC)と呼びます。

RBACのしくみ

RBACのアクセス制御モデルは、スコープとロールの組み合わせによって管理できることを決定する。

スコープ

管理が可能な範囲を示す。以下のレベルのいずれかを指定する。

  1. 管理グループ
  2. サブスクリプション
  3. リソースグループ
  4. 各リソース

ロール

ロールには実行できるアクション(読み取り、書き込み、削除など)を登録する。あらかじめいくつかのアクションを組み合わせて事前に用意されている組み込みロールと、管理者が作成するカスタムロールがある。

  • カスタム RBAC ロールを管理する機能は、ユーザーアクセス管理者ロールで行うことができる。(最小限の特権の原則)
組み込みロール
主な組み込みロール
所有者
(Owner)
スコープの範囲内における、すべての管理作業が可能
共同作成者
(Contributor)
スコープの範囲内における、アクセス許可設定を除くすべての管理作業が可能
閲覧者
(Reader)
Azureリソースの設定の閲覧が可能
仮想マシン共同作成者
(Virtual Machin Contributer)
Azure仮想マシンの管理作業が可能
ロール定義

ロールに定義した内容は、内部的にはjsonデータとして保存される。主な要素は以下の通り。

  • id
    ロールの一意のID、組み込みロールの場合はAzure全体で同じIDを持つ
  • roleName
    ロールの名前
  • assignableScopes[]
    このロールで使用できるスコープを指定する文字列の配列
  • acsions[]
    ロールに対して許可するアクションの配列
  • notActions[]
    acsionsから除外するアクション(拒否するアクション)の配列
  • dataActions[]
    対象のオブジェクト内のデータに対して、ロールで実行できるコントロールプレーンアクションを指定する文字列の配列
  • notDataActions[]
    dataAcsionsから除外するコントロールプレーンアクション(拒否するアクション)の配列
閲覧者(Reader)のロール定義例

スコープ範囲内でできる作業(actions)として、読み取りのみが許可されている。

{
  "id": "/providers/Microsoft.Authorization/roleDefinitions/xxxxx-xxxxx",
  "properties": {
    "roleName": "Reader",
    "assignableScopes": [
      "/"
    ],
    "permissions": [
      {
        "actions": [
          "*/read"
        ],
        "notActions": [],
        "dataActions": [],
        "notDataActions": []
      }
    ]
  }
}
共同作成者(Contributor)のロール定義例

スコープ範囲内でできる作業(actions)がすべて許可されているが、アクセス制御の変更が除外(notActions)されている。

{
  "id": "/providers/Microsoft.Authorization/roleDefinitions/yyyyy-yyyyy",
  "properties": {
    "roleName": "Contributor",
    "assignableScopes": [
      "/"
    ],
    "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",
          "Microsoft.Purview/consents/write",
          "Microsoft.Purview/consents/delete"
        ],
        "dataActions": [],
        "notDataActions": []
      }
    ]
  }
}

Azureポリシー

RBACでユーザーの作業を制限するのに対して、Azure PolicyではAzureリソースの構成にたいして制限をおこないます。例えば、仮想マシンを作成する際、特定のリージョンのみに制限して作成が可能、といったような制御が可能になります。

Azure Policyのしくみ

Azure Policyでポリシーを作成し、作成したポリシーを特定の管理単位(管理グループ、サブスクリプション、リソースグループ、特定のリソース)に紐づけることにより、ポリシーが動作する。

ポリシーで定義した内容は、内部的にはjsonデータとして保存される。

ポリシー

ポリシー定義
  • displayName
    ポリシーの表示名
  • mode
    ポリシー定義に対して評価されるリソースの種類が決定する。ほとんどの場合、すべてのリソースを示すallでよい。
  • parameters
    policyRule内のデプロイ関数によって使用される値を定義する。
    使用例:{
        "field": "location",
        "in": "[parameters('allowedLocations')]"
    }
  • policyRule
    論理演算子を使用してポリシールールを定義する。
ポリシールール

ポリシールールはifブロック内に論理演算子を使って記述する。条件を満たしたときにthenブロックの処理が実行される。

  • allOf
    配列内のすべての条件を満たしたときにTrueを返す。
  • anyOf
    配列内のいずれかの条件を満たしたときにTrueを返す。
効果

then.effectブロックで、条件を満たしたときに実行する処理を記述する。

  • append
    作成中または更新中に要求されたリソースに、さらにフィールドを追加する。
  • audit
    アクティビティログに警告イベントを作成する。処理は停止しない。
  • auditIfNotExists
    if条件に一致するリソースに関連するリソースで監査を有効にする。
  • deny
    ポリシーを通して定義された基準に一致していないため要求を拒否する。
  • deployIfNotExists
    条件が満たされたときにテンプレートのデプロイを実行する。 DeployIfNotExistsとして設定された有効なポリシー割り当てには、修復を行うための マネージド ID が必要になる。
ポリシールール例

以下の例では、ifブロックで3つの条件全てを満たしたときに警告イベントがトリガーされる。

"policyRule": {
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.DocumentDB/databaseAccounts"
      },
      {
        "field": "Microsoft.DocumentDB/databaseAccounts/enableAutomaticFailover",
        "equals": "false"
      },
      {
        "field": "Microsoft.DocumentDB/databaseAccounts/enableMultipleWriteLocations",
        "equals": "false"
      }
    ]
  },
  "then": {
    "effect": "audit"
  }
}

イニシアティブ定義

割り当てるポリシーが複数あると管理が煩雑になるため、複数のAzure Policyを組み合わせてイニシアティブ定義としてまとめて運用することができる。組み込みのイニシアティブ定義がいくつか用意されている。

  • ISO 27001:2013
    国際標準化機構 (ISO) 27001 規格に基づく、情報セキュリティ管理システム (ISMS) を確立、実装、維持、継続的に改善するための要件を提供する。
  • NIST SP 800-53 Rev. 5
    情報セキュリティ リスクを管理するためのクラウド コンピューティング製品とサービスを評価、監視、認証するための標準化された手法を提供する。

Azure ブループリント

[作成中]

コメント

このブログの人気の投稿

docker-compose up で proxyconnect tcp: dial tcp: lookup proxy.example.com: no such host

docker-compose で起動したweb、MySQLに接続できない事象

【PHP】PHP_CodeSnifferを使う(コーディングルールのカスタマイズ)