<p>[META] { “style”: “Senior Cloud Architect / Professional / Technical”, “topic”: “Azure Key Vault RBAC Transition”, “version”: “1.0”, “compliance”: “Well-Architected Framework” } [/META] 本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p> <h1 class="wp-block-heading">Azure Key VaultをアクセスポリシーからRBACへ：大規模・複数チーム運用の最適解</h1> <p>【導入】 従来のアクセスポリシーが抱える1,024件の制限と管理の煩雑さを解消し、Entra IDと統合した高度な権限分離とガバナンスを実現します。</p> <p>【アーキテクチャ設計】 従来の「Vault単位のアクセスポリシー」から、「Azure RBAC（ロールベースのアクセス制御）」へ移行することで、コントロールプレーンとデータプレーンの管理を統合します。これにより、シークレット、キー、証明書の個別のリソース単位での権限付与や、Microsoft Entra IDのPIM（Privileged Identity Management）を利用した一時的なアクセス許可が可能になります。</p> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> 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] </pre></div> <p>【実装・デプロイ手順】 既存のKey VaultをRBAC認可モードへ切り替え、Bicepを用いて最小特権の原則に基づいたロール割り当てを行います。</p> <h3 class="wp-block-heading">1. 認可モードの切り替え (Azure CLI)</h3> <div class="codehilite"> <pre data-enlighter-language="generic"># 既存のKey VaultをRBAC認可モードに変更 az keyvault update \ --name "kv-prod-backend-001" \ --resource-group "rg-shared-infra" \ --enable-rbac-authorization true </pre> </div> <h3 class="wp-block-heading">2. Bicepによるロール割り当ての自動化</h3> <pre data-enlighter-language="generic">// 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' } } </pre> <p>【アイデンティティとセキュリティ】</p> <ul class="wp-block-list"> <li><p><strong>最小特権の原則</strong>: <code>Key Vault Administrator</code> は管理用（IaC実行等）に限定し、アプリケーションには <code>Key Vault Secrets User</code> のみ付与します。</p></li> <li><p><strong>条件付きアクセス</strong>: Key Vaultへのアクセスに対し、多要素認証（MFA）や信頼されたデバイスからのアクセスを強制します。</p></li> <li><p><strong>Microsoft Defender for Key Vault</strong>: 異常なアクセスパターン（通常とは異なる場所からのシークレット取得など）を検知し、自動アラートを有効化します。</p></li> </ul> <p>【運用・コスト最適化】</p> <ul class="wp-block-list"> <li><p><strong>可観測性</strong>: Azure Monitorの「診断設定」を有効にし、KeyVaultFullAccess等すべてのログをLog Analyticsワークスペースへ転送。Kustoクエリ（KQL）で「誰がいつどのシークレットにアクセスしたか」を可視化します。</p></li> <li><p><strong>SKU選択</strong>: 通常の運用では <strong>Standard SKU</strong> で十分ですが、FIPS 140-2 Level 3準拠のHSM保護が必要なキーを扱う場合のみ <strong>Premium SKU</strong> を選択し、コストを最適化します。</p></li> <li><p><strong>削除保護</strong>: <code>enableSoftDelete</code> と <code>enablePurgeProtection</code> を必ず有効にし、誤操作によるデータ消失を防止します。</p></li> </ul> <p>【まとめ】</p> <ol class="wp-block-list"> <li><p><strong>既存ポリシーの確認</strong>: RBACへ移行すると既存のアクセスポリシーは無視されます。移行前に現在の権限をすべてRBACロールにマッピングしたか再確認してください。</p></li> <li><p><strong>グループベースの管理</strong>: 個別のユーザーではなく、Entra IDグループに対してロールを割り当てることで、チーム移動や退職時の権限剥奪を自動化します。</p></li> <li><p><strong>PIMの活用</strong>: 特権操作（証明書の更新など）が必要な場合のみ、PIMを通じて時限付きの <code>Key Vault Certificates Officer</code> 権限を承認制で付与する設計を推奨します。</p></li> </ol>

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認可モードに変更

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

// 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'
  }
}