<p><meta/> { “focus”: “Azure Key Vault RBAC Migration & Governance”, “role”: “Senior Cloud Architect”, “architectural_pattern”: “Identity-Centric Security / RBAC for Key Vault”, “version”: “1.1.0” } </p> <p>本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p> <h1 class="wp-block-heading">Azure Key VaultにおけるRBAC移行と大規模ガバナンスの最適化設計</h1> <h2 class="wp-block-heading">【導入】</h2> <p>アクセスポリシーからAzure RBACへの移行により、大規模組織での権限管理をEntra IDへ統合し、高度なセキュリティガバナンスを実現します。</p> <h2 class="wp-block-heading">【アーキテクチャ設計】</h2> <p>従来の「アクセスポリシー（Vault単位の全権限）」から「Azure RBAC（リソース単位の細分化された権限）」へシフトします。これにより、特定の秘密情報のみを参照させる「最小権限の原則」を、個別のシークレット・キー・証明書レベルで適用可能です。</p> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> graph TD subgraph "Entra ID("Identity Plane")" ID["Managed Identity / User / Group"] end subgraph "Azure Key Vault("Data Plane")" KV["Key Vault Resource"] KV --- S1["Secret A"] KV --- S2["Secret B"] KV --- K1["Key X"] end ID -->|RBAC Assignment: Secrets User| S1 ID -->|RBAC Assignment: Secrets Officer| S2 ID -.->|Deny by default| K1 subgraph "Governance & Monitoring" POL["Azure Policy"] -->|Enforce RBAC| KV LOG["Log Analytics"] <--|Audit Logs| KV end </pre></div> <h2 class="wp-block-heading">【実装・デプロイ手順】</h2> <p>既存のKey VaultをAzure RBAC許可モデルへ変更し、権限を割り当てる手順です。</p> <h3 class="wp-block-heading">1. Key VaultのRBAC許可モードへの切り替え (Azure CLI)</h3> <div class="codehilite"> <pre data-enlighter-language="generic"># 既存のKey VaultをRBAC許可モデルに更新 az keyvault update \ --name "kv-prod-shared-001" \ --resource-group "rg-shared-infrastructure" \ --enable-rbac-authorization true </pre> </div> <h3 class="wp-block-heading">2. Bicepによる宣言的定義</h3> <p>IaCで管理する場合、<code>enableRbacAuthorization</code> プロパティを <code>true</code> に設定します。</p> <pre data-enlighter-language="generic">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 enableRbacAuthorization: true // RBACを有効化 enabledForDeployment: false enabledForDiskEncryption: false enabledForTemplateDeployment: false accessPolicies: [] // RBAC有効時は空にする } } </pre> <h2 class="wp-block-heading">【アイデンティティとセキュリティ】</h2> <ul class="wp-block-list"> <li><p><strong>権限分離（RBAC Roles）</strong>:</p> <ul> <li><p><strong>Key Vault Secrets Officer</strong>: 秘密情報の管理（作成・更新）が必要な管理者/CI/CD用。</p></li> <li><p><strong>Key Vault Secrets User</strong>: アプリケーション実行環境（Managed Identity）用。読み取り権限のみ。</p></li> </ul></li> <li><p><strong>条件付きアクセス（CA）</strong>:</p> <ul> <li>Key Vaultの管理操作に対して多要素認証（MFA）を強制。</li> </ul></li> <li><p><strong>ネットワーク境界</strong>:</p> <ul> <li>パブリックアクセスを無効化し、<strong>Private Link</strong> を通じた閉域接続を徹底。</li> </ul></li> <li><p><strong>Microsoft Defender for Key Vault</strong>:</p> <ul> <li>異常なIPからのアクセスや、シークレットの大量取得などの振る舞い検知を有効化。</li> </ul></li> </ul> <h2 class="wp-block-heading">【運用・コスト最適化】</h2> <ul class="wp-block-list"> <li><p><strong>可観測性</strong>:</p> <ul> <li><code>Diagnostic Settings</code> を構成し、<code>AuditEvent</code> を Log Analytics ワークスペースへ転送。誰がいつ、どのシークレットにアクセスしたかをクエリ可能にする。</li> </ul></li> <li><p><strong>SKU選択</strong>:</p> <ul> <li>通常のシークレット管理であれば <strong>Standard</strong> で十分。FIPS 140-2 Level 3 準拠のハードウェア保護（HSM）が必要な場合にのみ <strong>Premium</strong> を選択。</li> </ul></li> <li><p><strong>パージ保護 (Purge Protection)</strong>:</p> <ul> <li>誤削除やランサムウェア対策として必ず有効化する（RBAC移行と併せて設定推奨）。</li> </ul></li> </ul> <h2 class="wp-block-heading">【まとめ】</h2> <ol class="wp-block-list"> <li><p><strong>移行の非可逆性</strong>: Azure RBACを有効にすると、既存のアクセスポリシーは無視されます。移行前に現在の権限セットをRBACロールへマッピングする作業が必須です。</p></li> <li><p><strong>スコープの最小化</strong>: Vault全体ではなく、可能な限り「特定のシークレット」単位で権限を割り当てることで、侵害時の爆発半径（Blast Radius）を最小化してください。</p></li> <li><p><strong>管理の統合</strong>: ユーザーへの直接割り当ては避け、Entra ID グループまたは Managed Identity を利用して、ライフサイクル管理を自動化することが大規模運用の成功の鍵です。</p></li> </ol>

graph TD
    subgraph "Entra ID("Identity Plane")"
        ID["Managed Identity / User / Group"]
    end

    subgraph "Azure Key Vault("Data Plane")"
        KV["Key Vault Resource"]
        KV --- S1["Secret A"]
        KV --- S2["Secret B"]
        KV --- K1["Key X"]
    end

    ID -->|RBAC Assignment: Secrets User| S1
    ID -->|RBAC Assignment: Secrets Officer| S2
    ID -.->|Deny by default| K1

    subgraph "Governance & Monitoring"
        POL["Azure Policy"] -->|Enforce RBAC| KV
        LOG["Log Analytics"] <--|Audit Logs| KV
    end

# 既存のKey VaultをRBAC許可モデルに更新

az keyvault update \
    --name "kv-prod-shared-001" \
    --resource-group "rg-shared-infrastructure" \
    --enable-rbac-authorization 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
    enableRbacAuthorization: true // RBACを有効化
    enabledForDeployment: false
    enabledForDiskEncryption: false
    enabledForTemplateDeployment: false
    accessPolicies: [] // RBAC有効時は空にする
  }
}