0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@blinkgroup_jp(ブリンクグループ)

Azure RBAC設計における過剰権限防止の実践ガイド：カスタムロール定義とスコープ制限の手順

0
Posted at

読者が抱える課題

Azure環境の運用において、セキュリティの観点から「最小特権の原則（Least Privilege）」を適用することは重要です。しかし、実務では以下のような課題が頻繁に発生します。

  • 利便性を優先し、開発者や運用者に「共同作成者（Contributor）」などの広範な組み込みロールを安易に割り当ててしまう。
  • リソースグループやサブスクリプション単位での大雑把な権限付与により、特定の仮想マシンやストレージアカウントのみを操作させたいユーザーに不要なリソースの閲覧・変更権限が渡ってしまう。
  • どのリソースにどのロールを割り当てるべきかの明確な判断基準や、設計・運用のチェックリストがない。

この記事では、これらの課題を解決するために、Azure RBAC（役割ベースのアクセス制御）の設計基準、カスタムロールの定義方法、および過剰権限を防ぐための具体的な実装手順とチェックリストを解説します。

この記事で分かること

  • Azure RBAC設計における「スコープ」と「ロール」の適切な組み合わせ方
  • 組み込みロールの限界と、JSONを用いたカスタムロールの定義・作成手順
  • 実務でそのまま使える「RBAC設計・割り当てチェックリスト」

対象読者・前提条件

  • Azure環境の設計・構築・運用に携わるインフラエンジニア、セキュリティ担当者
  • Azure Portal、Azure CLI、またはBicep/Terraformを用いた基本的なリソース操作の経験があること

1. Azure RBAC設計の基本原則

Azure RBACは、「誰が（セキュリティプリンシパル）」「何を（ロール定義）」「どこに対して（スコープ）」実行できるかを定義します。過剰権限を防ぐためには、この3つの要素を最小化することが基本です。

[セキュリティプリンシパル] ──(ロール割り当て)──> [ロール定義] ──(適用)──> [スコープ]
(ユーザー/グループ/SPN)                             (許可するアクション)             (管理グループ/サブスクリプション/RG/リソース)

1.1. スコープの最小化

権限を付与する際は、可能な限り狭いスコープを選択します。サブスクリプション全体への権限付与は避け、リソースグループ単位、あるいは特定のリソース単位での割り当てを検討してください。

1.2. グループによる割り当ての原則

個々のユーザーアカウントに対して直接ロールを割り当てるのではなく、Microsoft Entra ID（旧Azure AD）のセキュリティグループを作成し、グループに対してロールを割り当てます。これにより、メンバーの追加・削除だけで権限管理が完結し、設定の形骸化を防げます。

2. 組み込みロールとカスタムロールの使い分け

Azureには多数の組み込みロールが用意されていますが、実務ではこれらだけでは要件を満たせない場合があります。以下の比較表を参考に、カスタムロールの導入を検討してください。

ロールタイプ メリット デメリット 主なユースケース
組み込みロール
(所有者, 共同作成者, 閲覧者など)		 ・Microsoftによるメンテナンスが不要
・即座に利用可能		 ・権限が広すぎる場合がある
・特定のアクションのみを除外することが難しい		 ・管理者や監査用アカウント
・開発環境での一時的な検証
カスタムロール ・必要なアクションのみを厳密に定義可能
・過剰権限を確実に排除できる		 ・定義ファイルの管理が必要
・AzureのAPI更新に伴うメンテナンスコストが発生		 ・本番環境の運用オペレーター
・特定のデータ操作のみを許可するサービスプリンシパル

3. カスタムロールの実装手順

ここでは、例として「仮想マシンの起動・停止・再起動のみが可能で、削除や新規作成はできない運用担当者向けロール」をカスタム作成する手順を示します。

3.1. カスタムロール定義のJSON作成

以下の内容で vm-operator-role.json ファイルを作成します。AssignableScopes には、このロールを適用可能とするサブスクリプションIDを指定してください。

{
  "Name": "Virtual Machine Operator Custom",
  "IsCustom": true,
  "Description": "Allows starting, stopping, and restarting virtual machines without permission to delete or create them.",
  "Actions": [
    "Microsoft.Compute/virtualMachines/read",
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/powerOff/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Resources/subscriptions/resourceGroups/read"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/00000000-0000-0000-0000-000000000000"
  ]
}

※ 00000000-0000-0000-0000-000000000000 部分は、実際の環境のサブスクリプションIDに置き換えてください。

3.2. Azure CLIによるロールの作成

作成したJSONファイルを指定して、Azure CLIからカスタムロールを登録します。

# Azureへのログイン（必要に応じて実行）
az login

# カスタムロールの作成
az role definition create --role-definition @vm-operator-role.json

3.3. 特定のリソースグループへの割り当て

作成したカスタムロールを、特定のリソースグループ（例: rg-production-web）に対して、特定のセキュリティグループ（例: sg-ops-team）宛てに割り当てます。

# リソースグループのIDを取得
RG_ID=$(az group show --name rg-production-web --query id --output tsv)

# ロールの割り当て
az role assignment create \
  --assignee "sg-ops-team@yourdomain.onmicrosoft.com" \
  --role "Virtual Machine Operator Custom" \
  --scope "$RG_ID"

4. 実務用：RBAC設計・割り当てチェックリスト

ロールの設計や割り当てを行う際、過剰権限になっていないかを検証するためのチェックリストです。設計レビューや定期監査の際にご活用ください。

  • スコープの妥当性
    • サブスクリプションレベルでの割り当てが本当に必要か？（リソースグループ単位で代替できないか）
    • 一時的な作業のために広範なスコープを付与していないか？
  • ロールの最小化
    • 「共同作成者（Contributor）」を付与する際、リソースの削除権限まで本当に必要か？
    • データの読み取りだけであれば、「閲覧者（Reader）」やデータプレーン専用ロール（例: 「ストレージ BLOB データ閲覧者」）で十分ではないか？
  • 割り当て対象の適切性
    • 個人アカウントに直接ロールを割り当てていないか？（セキュリティグループを経由しているか）
    • サービスプリンシパルやマネージドIDに対して、不要な管理権限が付与されていないか？
  • ライフサイクル管理
    • 外部ベンダーや一時的なプロジェクトメンバーへの権限付与に、有効期限を設定しているか？（Microsoft Entra PIMの利用検討など）
    • 不要になったカスタムロールや、メンバーが退職したグループの整理プロセスがあるか？

5. 運用上の注意点とよくある失敗

5.1. ワイルドカード（*）の多用による意図しない権限付与

カスタムロールを定義する際、Actions に Microsoft.Compute/* のようにワイルドカードを使用すると、将来的にそのリソースプロバイダーに追加される新しいAPI（リソースの削除やセキュリティ設定の変更など）に対しても自動的に権限が付与されてしまいます。可能な限り、具体的なアクションを個別に指定することを推奨します。

5.2. コントロールプレーンとデータプレーンの混同

Azure RBACには、リソース自体を管理する「コントロールプレーン（Actions）」と、リソース内のデータにアクセスする「データプレーン（DataActions）」があります。例えば、「共同作成者」ロールを持っていても、ストレージアカウント内のBlobデータを読み取るには「ストレージ BLOB データ閲覧者」などのデータプレーン権限が別途必要になる場合があります。これらを混同すると、不要な管理権限を付与する原因になります。

5.3. 最新仕様の確認

Azureの仕様やリソースプロバイダーのアクション名は、アップデートにより変更または追加されることがあります。カスタムロールを本番環境に適用する前には、必ず最新の公式ドキュメント（Azureリソースプロバイダー操作一覧など）を参照し、指定したアクションが最新の仕様に準拠しているか確認してください。

まとめ

Azure環境における過剰権限の防止は、セキュリティインシデントのリスクを低減するための基本です。組み込みロールの安易な割り当てを避け、スコープを最小限に抑えたカスタムロールの設計とグループベースの運用を徹底することで、安全で管理しやすいAzure環境を構築できます。本記事のテンプレートやチェックリストを、日々の設計・運用業務に役立ててください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?