[Azure] Azure ADにおけるアクセス制御
RBAC ロールベースのアクセス制御
Azureでは、サブスクリプションやリソースグループなどの一部分だけを管理するためのアクセス制御が行えます。このように細かくロールを区切って運用管理を行うアクセス制御を、ロールベースのアクセス制御(RBAC)と呼びます。
RBACのしくみ
RBACのアクセス制御モデルは、スコープとロールの組み合わせによって管理できることを決定する。
スコープ
管理が可能な範囲を示す。以下のレベルのいずれかを指定する。
- 管理グループ
- サブスクリプション
- リソースグループ
- 各リソース
ロール
ロールには実行できるアクション(読み取り、書き込み、削除など)を登録する。あらかじめいくつかのアクションを組み合わせて事前に用意されている組み込みロールと、管理者が作成するカスタムロールがある。
- カスタム 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 ブループリント
[作成中]
コメント
コメントを投稿