本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Azure Key VaultをアクセスポリシーからAzure RBACへ：大規模運用のための移行戦略
【導入】 従来のアクセスポリシーの限界を突破し、Entra IDによる一元管理と最小特権の原則を大規模・複数チーム環境で実現します。
【アーキテクチャ設計】 従来の「アクセスポリシー」はKey Vault単位のフラットな権限付与でしたが、Azure RBAC（ロールベースのアクセス制御）へ移行することで、管理プレーンとデータプレーンをEntra IDで統合管理します。これにより、サブスクリプションやリソースグループ単位での権限継承や、Privileged Identity Management (PIM) による時限付き権限付与が可能になります。
graph TD
subgraph "Identity Provider"
Entra["Microsoft Entra ID"]
end
subgraph "Scope Hierarchy"
Sub["Subscription / MG"]
RG["Resource Group"]
AKV["Azure Key Vault"]
end
Admin["Security Admin"] -->|Assign Roles| Entra
User["Dev / App Service"] -->|Request Access| Entra
Entra -->|Access Token| AKV
AKV -.->|Audit Logs| LA["Log Analytics"]
subgraph "Built-in Roles"
R1["Key Vault Administrator"]
R2["Key Vault Secrets Officer"]
R3["Key Vault Secrets User"]
end
【実装・デプロイ手順】
既存のKey VaultをRBAC認可モデルへ切り替える際は、enableRbacAuthorization プロパティを true に設定します。移行前に、必要なユーザー/サービスプリンシパルに適切なRBACロール（例: Key Vault Secrets User）が割り当てられていることを確認してください。
1. Azure CLI による認可モデルの変更
# 既存のKey VaultをRBAC認可に切り替え az keyvault update \ --name "kv-prod-backend-001" \ --resource-group "rg-prod-shared" \ --enable-rbac-authorization true
2. Bicep によるコードベースの定義
// Key Vaultの定義
resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' = {
name: 'kv-prod-backend-001'
location: resourceGroup().location
properties: {
sku: {
family: 'A'
name: 'standard'
}
tenantId: subscription().tenantId
enableRbacAuthorization: true // RBACを有効化
enabledForDeployment: true
enabledForTemplateDeployment: true
}
}
// 参照用：Key Vault Secrets User (b86a8fe4-44ce-4919-9750-73856b4b3041)
resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
name: guid(keyVault.id, 'app-service-id', 'Key Vault Secrets User')
scope: keyVault
properties: {
roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', 'b86a8fe4-44ce-4919-9750-73856b4b3041')
principalId: 'app-service-principal-object-id'
principalType: 'ServicePrincipal'
}
}
【アイデンティティとセキュリティ】
最小特権の原則 (PoLP): アプリケーションには「Key Vault Secrets User」を割り当て、シークレットの読み取りのみを許可します。管理作業には「Key Vault Administrator」を使用しますが、これは PIM を通じたアクティブ化を必須とすべきです。
条件付きアクセス: Key Vaultへのアクセスに対し、多要素認証 (MFA) や信頼済みデバイスからのアクセスのみを許可するポリシーを適用します。
Microsoft Defender for Key Vault: RBAC移行後も、異常なアクセスパターン（例: 短時間の大量シークレット取得）を検知するために有効化を推奨します。
【運用・コスト最適化】
可観測性: Azure Monitor の診断設定で
AuditEventを Log Analytics に送信します。RBACに移行することで、ログ内のprincipalIdと Entra ID のユーザーが直接紐付き、監査の透明性が向上します。コスト最適化:
SKU選択: HSM（ハードウェアセキュリティモジュール）が必要ない場合は「Standard」を選択し、コストを抑えます。
一元化 vs 分散: チームごとにVaultを分けることで爆発半径を抑えられますが、管理オーバーヘッドとのトレードオフになります。RBACなら「リソースグループ単位の権限付与」でこのバランスを最適化できます。
【まとめ】
移行の順序: RBACを有効化する前にロールを割り当てないと、全ユーザーが即座にアクセス不能になる「ロックアウト」が発生するため注意が必要です。
管理の統合: 個別のアクセスポリシー管理から解放され、Azure Lighthouse等を用いたマルチテナント環境の統制にも対応可能になります。
互換性の確認: 極めて古いアプリケーションSDKではRBAC認可に対応していない場合があるため、移行前にSDKバージョンの確認を推奨します。
コメント