{ “focus”: “Azure Key Vault RBAC Migration”, “persona”: “Senior Cloud Architect”, “architecture_pattern”: “RBAC-based Secret Management”, “compliance”: “Well-Architected Framework – Security” }

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

Azure Key Vault RBAC移行：大規模組織向けアクセス管理のモダン化とガバナンス強化

【導入】従来のアクセスポリシーからAzure RBACへ移行し、Entra ID統合による細粒度な権限管理と組織横断的な運用効率化を実現します。

【アーキテクチャ設計】本構成では、従来のVaultレベルでの「一括管理」から、Entra IDのプリンシパルに基づいた「リソース単位の権限付与」へシフトします。管理プレーンとデータプレーンの両方に一貫したRBACモデルを適用することで、最小特権の原則（PoLP）を徹底します。

graph TD
    subgraph "Identity & Governance"
        ID["Entra ID Groups/Identities"]
        PIM["Privileged Identity Management"]
    end

    subgraph "Azure Subscription"
        subgraph "Resource Group"
            AKV["Azure Key Vault"]
            subgraph "Data Plane (RBAC)"
                S1["Secret A"]
                S2["Secret B"]
                K1["Key X"]
            end
        end
    end

    ID -->|1. Authenticate| AKV
    PIM -->|2. JIT Access| ID
    AKV -->|3. RBAC Check| S1
    AKV -->|3. RBAC Check| S2

    style AKV fill:#0072C6,color:#fff
    style ID fill:#5E5E5E,color:#fff

アーキテクチャの核心は、権限の分離にあります。従来のアクセスポリシーではVault内の全てのシークレットが見えてしまうリスクがありましたが、Azure RBACでは「特定のシークレットのみ」へのアクセス許可を、特定のユーザーやマネージドIDに対してスコープを絞って定義可能です。

【実装・デプロイ手順】

既存VaultのRBAC有効化（Azure CLI） 既存のアクセスポリシーモデルからAzure RBAC許可モデルへ切り替えます。

# Key Vaultの許可モデルをAzure RBACに変更

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

Bicepによる細粒度なロール割り当て 特定のシークレットに対して「Key Vault Secrets User」ロールを割り当てるコード例です。

// 特定のシークレットに対するロール割り当て
resource secretRoleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(vault.id, principalId, 'Key Vault Secrets User')
  scope: keyVault::secret // シークレット単位のスコープ
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '4633458b-17de-408a-b874-0445c86b69e6')
    principalId: principalId
    principalType: 'ServicePrincipal'
  }
}

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

組み込みロールの活用: 独自のカスタムロールを作成する前に、Key Vault Administrator、Key Vault Certificates Officer、Key Vault Secrets User などの標準ロールを優先して使用します。
マネージドIDの強制: アプリケーションからのアクセスには、Client Secretの発行が不要な「マネージドID（System-assigned/User-assigned）」を必須とします。
条件付きアクセス: Key Vaultへのアクセスに対し、MFA（多要素認証）や信頼済みデバイスからのアクセスのみを許可するポリシーをEntra ID側で構成します。

【運用・コスト最適化】

可観測性: Azure Monitorの診断設定を有効化し、AuditEvent をLog Analyticsに転送します。「誰が・いつ・どのシークレットに」アクセスしたかをKustoクエリ（KQL）で即座に追跡可能です。
SKU選択: 通常の運用では「Standard」で十分ですが、FIPS 140-2 Level 3準拠のHSM保護が必要な場合や、高度なキー管理が必要な場合のみ「Premium」を選択し、コストを最適化します。
Defender for Key Vault: 異常なアクセスパターン（例：通常と異なる場所からの大量のシークレット取得）を検知するため、Microsoft Defender for Cloudの有効化を推奨します。

【まとめ】

移行の非可逆性への注意: RBACを有効にするとアクセスポリシーは無視されます。移行前に既存のポリシーを棚卸しし、RBACロールへ完全にマッピングしておく必要があります。
伝搬遅延の考慮: RBACのロール割り当てには最大10分程度の反映遅延が生じる場合があるため、CI/CDパイプラインでのリソース作成直後のアクセスにはリトライ処理を検討してください。
最小特権の徹底: Vault単位ではなく、可能な限りシークレット/キー単位でのスコープ定義を行うことで、大規模環境における爆発半径（Blast Radius）を最小化できます。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシーもご参照ください。