{“status”: “architected”, “target”: “Enterprise Cloud Infrastructure”, “technology”: [“Azure Key Vault”, “Azure RBAC”, “Microsoft Entra ID”, “Bicep”], “author”: “Senior Cloud Architect”}
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Azure Key VaultにおけるアクセスポリシーからAzure RBACへの移行：大規模ガバナンス設計ガイド
【導入】
従来型の複雑なアクセスポリシーを廃し、Azure RBACによる一元管理と最小特権の原則を実現する大規模環境向けの構成案を提示します。
【アーキテクチャ設計】
大規模環境において、従来の「アクセスポリシー（コンテナー単位の最大1024件制限）」は、管理の複雑化と監査の困難さを招きます。本設計では、Microsoft Entra ID（旧Azure AD）と統合されたAzure RBACを採用し、管理グループやサブスクリプションレベルからの権限継承を可能にします。これにより、運用チーム、開発チーム、アプリケーション（マネージドID）の権限分離を明確化します。
graph TD
subgraph "Governance Layer"
MG["Management Group"]
SUB[Subscription]
end
subgraph "Identity & Access"
EID["Microsoft Entra ID"]
PIM["Privileged Identity Management"]
end
subgraph "Resource Layer"
RG["Resource Group"]
KV["Azure Key Vault"]
enableRBAC["enableRbacAuthorization: true"]
end
subgraph "Consumers"
App["Managed Identity / App Service"]
Dev["Developer Team"]
Admin["Cloud Ops Team"]
end
EID --> PIM
PIM -->|JIT Access| Admin
MG --> SUB
SUB --> RG
RG --> KV
KV --- enableRBAC
Admin -->|Key Vault Administrator| KV
Dev -->|Key Vault Secrets User| KV
App -->|Key Vault Secrets User| KV
【実装・デプロイ手順】
既存のKey VaultをRBACモデルへ移行、または新規構築する際のBicepコードとCLI操作手順です。
1. Key VaultのRBAC有効化（Bicep）
既存の accessPolicies プロパティを空にし、enableRbacAuthorization を true に設定します。
resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' = {
name: 'kv-prod-shared-001'
location: resourceGroup().location
properties: {
sku: {
family: 'A'
name: 'standard'
}
tenantId: subscription().tenantId
// RBACを有効化
enableRbacAuthorization: true
// アクセスポリシーを無効化（既存分がある場合は削除）
accessPolicies: []
networkAcls: {
defaultAction: 'Deny'
bypass: 'AzureServices'
}
}
}
2. Azure CLIによる移行コマンド
一括で設定を変更する場合のCLI手順です。
# 1. 既存のKey VaultのRBACを有効化 az keyvault update \ --name "kv-prod-shared-001" \ --resource-group "rg-shared-services" \ --enable-rbac-authorization true # 2. 開発者チームに「シークレット参照権限」を付与 az role assignment create \ --role "Key Vault Secrets User" \ --assignee-object-id "<Developer-Group-ID>" \ --scope "/subscriptions/<Sub-ID>/resourceGroups/rg-shared-services/providers/Microsoft.KeyVault/vaults/kv-prod-shared-001" \ --assignee-principal-type Group
【アイデンティティとセキュリティ】
Azure RBACへの移行により、以下の高度なセキュリティ制御を実装します。
役割の分離 (SoD):
Key Vault Administrator: 証明書・キー・シークレットの管理権限。
Key Vault Secrets Officer: シークレットの作成・更新権限。
Key Vault Secrets User: シークレットの読み取り専用権限（アプリケーション用）。
特権アクセスの保護: 管理者権限（Administrator/Officer）の付与には Microsoft Entra PIM を利用し、ジャストインタイム (JIT) での承認ワークフローを必須とします。
条件付きアクセス (Conditional Access): Key Vaultへの管理操作に対し、多要素認証 (MFA) と信頼されたデバイス（コンプライアンス済みデバイス）からのアクセスを強制します。
【運用・コスト最適化】
可観測性の強化: Azure Monitor Diagnostic Settingsを使用して、すべてのRBAC操作（誰が、いつ、どのシークレットにアクセスしたか）をLog Analyticsへ転送。Kusto (KQL) を用いた監査ダッシュボードを作成します。
SKU選択の基準:
Standard: 通常のシークレット管理、ソフトウェア保護のキー。
Premium: FIPS 140-2 Level 2/3 準拠のHSM（ハードウェアセキュリティモジュール）が必要な場合。大規模環境でもまずはStandardでコストを抑え、コンプライアンス要件に応じてPremiumを選択します。
【まとめ】
導入にあたっての重要な3要点は以下の通りです。
移行のダウンタイム回避: RBACを有効にすると、既存のアクセスポリシーは即座に無視されます。必ず「RBACのロール付与」を先行させてから、設定を切り替えてください。
最小特権の徹底: アプリケーションのマネージドIDには「Key Vault Secrets User」のみを付与し、管理権限を与えないよう設計してください。
伝播遅延の考慮: RBACのロール割り当ては最大10分程度の反映遅延が発生する可能性があるため、CI/CDパイプラインでの構築直後のアクセスにはリトライ処理を検討してください。
