Azure Key VaultにおけるRBAC移行と大規模ガバナンスの最適化設計

【導入】

アクセスポリシーからAzure RBACへの移行により、大規模組織での権限管理をEntra IDへ統合し、高度なセキュリティガバナンスを実現します。

【アーキテクチャ設計】

従来の「アクセスポリシー（Vault単位の全権限）」から「Azure RBAC（リソース単位の細分化された権限）」へシフトします。これにより、特定の秘密情報のみを参照させる「最小権限の原則」を、個別のシークレット・キー・証明書レベルで適用可能です。

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

    subgraph mermaid_group_5["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 -.- MASK["Deny by default"| K1

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

【実装・デプロイ手順】

既存のKey VaultをAzure RBAC許可モデルへ変更し、権限を割り当てる手順です。

1. Key VaultのRBAC許可モードへの切り替え (Azure CLI)

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

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

2. Bicepによる宣言的定義

IaCで管理する場合、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
    enableRbacAuthorization: true // RBACを有効化
    enabledForDeployment: false
    enabledForDiskEncryption: false
    enabledForTemplateDeployment: false
    accessPolicies: [] // RBAC有効時は空にする
  }
}

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

• 権限分離（RBAC Roles）:

  • Key Vault Secrets Officer: 秘密情報の管理（作成・更新）が必要な管理者/CI/CD用。

  • Key Vault Secrets User: アプリケーション実行環境（Managed Identity）用。読み取り権限のみ。

• 条件付きアクセス（CA）:

  • Key Vaultの管理操作に対して多要素認証（MFA）を強制。

• ネットワーク境界:

  • パブリックアクセスを無効化し、Private Link を通じた閉域接続を徹底。

• Microsoft Defender for Key Vault:

  • 異常なIPからのアクセスや、シークレットの大量取得などの振る舞い検知を有効化。

【運用・コスト最適化】

• 可観測性:

  • Diagnostic Settings を構成し、AuditEvent を Log Analytics ワークスペースへ転送。誰がいつ、どのシークレットにアクセスしたかをクエリ可能にする。

• SKU選択:

  • 通常のシークレット管理であれば Standard で十分。FIPS 140-2 Level 3 準拠のハードウェア保護（HSM）が必要な場合にのみ Premium を選択。

• パージ保護 (Purge Protection):

  • 誤削除やランサムウェア対策として必ず有効化する（RBAC移行と併せて設定推奨）。

【まとめ】

1. 移行の非可逆性: Azure RBACを有効にすると、既存のアクセスポリシーは無視されます。移行前に現在の権限セットをRBACロールへマッピングする作業が必須です。

2. スコープの最小化: Vault全体ではなく、可能な限り「特定のシークレット」単位で権限を割り当てることで、侵害時の爆発半径（Blast Radius）を最小化してください。

3. 管理の統合: ユーザーへの直接割り当ては避け、Entra ID グループまたは Managed Identity を利用して、ライフサイクル管理を自動化することが大規模運用の成功の鍵です。