[META] { “style”: “Senior Cloud Architect / Professional / Technical”, “topic”: “Azure Key Vault RBAC Transition”, “version”: “1.0”, “compliance”: “Well-Architected Framework” } [/META] 本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

Azure Key VaultをアクセスポリシーからRBACへ：大規模・複数チーム運用の最適解

【導入】 従来のアクセスポリシーが抱える1,024件の制限と管理の煩雑さを解消し、Entra IDと統合した高度な権限分離とガバナンスを実現します。

【アーキテクチャ設計】 従来の「Vault単位のアクセスポリシー」から、「Azure RBAC（ロールベースのアクセス制御）」へ移行することで、コントロールプレーンとデータプレーンの管理を統合します。これにより、シークレット、キー、証明書の個別のリソース単位での権限付与や、Microsoft Entra IDのPIM（Privileged Identity Management）を利用した一時的なアクセス許可が可能になります。

graph TD
    subgraph "Identity Provider"
        ID["Microsoft Entra ID"]
        PIM["Privileged Identity Management"]
    end

    subgraph "Governance Layer"
        AG["Entra ID Groups: App-Dev / Sec-Ops"]
        ID --> AG
        PIM --> AG
    end

    subgraph "Azure Resource"
        KV["Azure Key Vault: RBAC Authorization Mode"]
        subgraph "Data Plane Roles"
            SR["Key Vault Secrets User"]
            CR["Key Vault Certificates Officer"]
            KR["Key Vault Crypto User"]
        end
    end

    AG -->|Role Assignment| SR
    AG -->|Role Assignment| CR
    SR -->|Access| Sec[Secrets]
    CR -->|Access| Cert[Certificates]
    KR -->|Access| Key[Keys]

【実装・デプロイ手順】 既存のKey VaultをRBAC認可モードへ切り替え、Bicepを用いて最小特権の原則に基づいたロール割り当てを行います。

1. 認可モードの切り替え (Azure CLI)

# 既存のKey VaultをRBAC認可モードに変更

az keyvault update \
  --name "kv-prod-backend-001" \
  --resource-group "rg-shared-infra" \
  --enable-rbac-authorization true

2. Bicepによるロール割り当ての自動化

// Key Vault Secrets User ロールの定義 ID
var secretsUserRoleId = '4633458b-17de-408a-b874-0445c86b69e6'

resource kv 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
  name: 'kv-prod-backend-001'
}

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(kv.id, 'app-service-principal', secretsUserRoleId)
  scope: kv
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', secretsUserRoleId)
    principalId: 'SERVICE_PRINCIPAL_OBJECT_ID' // アプリケーションのサービスプリンシパルID
    principalType: 'ServicePrincipal'
  }
}

【アイデンティティとセキュリティ】

• 最小特権の原則: Key Vault Administrator は管理用（IaC実行等）に限定し、アプリケーションには Key Vault Secrets User のみ付与します。

• 条件付きアクセス: Key Vaultへのアクセスに対し、多要素認証（MFA）や信頼されたデバイスからのアクセスを強制します。

• Microsoft Defender for Key Vault: 異常なアクセスパターン（通常とは異なる場所からのシークレット取得など）を検知し、自動アラートを有効化します。

【運用・コスト最適化】

• 可観測性: Azure Monitorの「診断設定」を有効にし、KeyVaultFullAccess等すべてのログをLog Analyticsワークスペースへ転送。Kustoクエリ（KQL）で「誰がいつどのシークレットにアクセスしたか」を可視化します。

• SKU選択: 通常の運用では Standard SKU で十分ですが、FIPS 140-2 Level 3準拠のHSM保護が必要なキーを扱う場合のみ Premium SKU を選択し、コストを最適化します。

• 削除保護: enableSoftDelete と enablePurgeProtection を必ず有効にし、誤操作によるデータ消失を防止します。

【まとめ】

1. 既存ポリシーの確認: RBACへ移行すると既存のアクセスポリシーは無視されます。移行前に現在の権限をすべてRBACロールにマッピングしたか再確認してください。

2. グループベースの管理: 個別のユーザーではなく、Entra IDグループに対してロールを割り当てることで、チーム移動や退職時の権限剥奪を自動化します。

3. PIMの活用: 特権操作（証明書の更新など）が必要な場合のみ、PIMを通じて時限付きの Key Vault Certificates Officer 権限を承認制で付与する設計を推奨します。