Azure Key VaultにおけるアクセスポリシーからAzure RBACへの移行：大規模ガバナンス設計ガイド

Tech

{“status”: “architected”, “target”: “Enterprise Cloud Infrastructure”, “technology”: [“Azure Key Vault”, “Azure RBAC”, “Microsoft Entra ID”, “Bicep”], “author”: “Senior Cloud Architect”}

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

Azure Key VaultにおけるアクセスポリシーからAzure RBACへの移行：大規模ガバナンス設計ガイド

【導入】

従来型の複雑なアクセスポリシーを廃し、Azure RBACによる一元管理と最小特権の原則を実現する大規模環境向けの構成案を提示します。

【アーキテクチャ設計】

大規模環境において、従来の「アクセスポリシー（コンテナー単位の最大1024件制限）」は、管理の複雑化と監査の困難さを招きます。本設計では、Microsoft Entra ID（旧Azure AD）と統合されたAzure RBACを採用し、管理グループやサブスクリプションレベルからの権限継承を可能にします。これにより、運用チーム、開発チーム、アプリケーション（マネージドID）の権限分離を明確化します。

graph TD
    subgraph "Governance Layer"
        MG["Management Group"]
        SUB[Subscription]
    end

    subgraph "Identity & Access"
        EID["Microsoft Entra ID"]
        PIM["Privileged Identity Management"]
    end

    subgraph "Resource Layer"
        RG["Resource Group"]
        KV["Azure Key Vault"]
        enableRBAC["enableRbacAuthorization: true"]
    end

    subgraph "Consumers"
        App["Managed Identity / App Service"]
        Dev["Developer Team"]
        Admin["Cloud Ops Team"]
    end

    EID --> PIM
    PIM -->|JIT Access| Admin
    MG --> SUB
    SUB --> RG
    RG --> KV
    KV --- enableRBAC

    Admin -->|Key Vault Administrator| KV
    Dev -->|Key Vault Secrets User| KV
    App -->|Key Vault Secrets User| KV

【実装・デプロイ手順】

既存のKey VaultをRBACモデルへ移行、または新規構築する際のBicepコードとCLI操作手順です。

1. Key VaultのRBAC有効化（Bicep）

既存の accessPolicies プロパティを空にし、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
    // RBACを有効化
    enableRbacAuthorization: true 
    // アクセスポリシーを無効化（既存分がある場合は削除）
    accessPolicies: []
    networkAcls: {
      defaultAction: 'Deny'
      bypass: 'AzureServices'
    }
  }
}

2. Azure CLIによる移行コマンド

一括で設定を変更する場合のCLI手順です。

# 1. 既存のKey VaultのRBACを有効化

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

# 2. 開発者チームに「シークレット参照権限」を付与

az role assignment create \
  --role "Key Vault Secrets User" \
  --assignee-object-id "<Developer-Group-ID>" \
  --scope "/subscriptions/<Sub-ID>/resourceGroups/rg-shared-services/providers/Microsoft.KeyVault/vaults/kv-prod-shared-001" \
  --assignee-principal-type Group

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

Azure RBACへの移行により、以下の高度なセキュリティ制御を実装します。

  • 役割の分離 (SoD):

    • Key Vault Administrator: 証明書・キー・シークレットの管理権限。

    • Key Vault Secrets Officer: シークレットの作成・更新権限。

    • Key Vault Secrets User: シークレットの読み取り専用権限（アプリケーション用）。

  • 特権アクセスの保護: 管理者権限（Administrator/Officer）の付与には Microsoft Entra PIM を利用し、ジャストインタイム (JIT) での承認ワークフローを必須とします。

  • 条件付きアクセス (Conditional Access): Key Vaultへの管理操作に対し、多要素認証 (MFA) と信頼されたデバイス（コンプライアンス済みデバイス）からのアクセスを強制します。

【運用・コスト最適化】

  • 可観測性の強化: Azure Monitor Diagnostic Settingsを使用して、すべてのRBAC操作（誰が、いつ、どのシークレットにアクセスしたか）をLog Analyticsへ転送。Kusto (KQL) を用いた監査ダッシュボードを作成します。

  • SKU選択の基準:

    • Standard: 通常のシークレット管理、ソフトウェア保護のキー。

    • Premium: FIPS 140-2 Level 2/3 準拠のHSM（ハードウェアセキュリティモジュール）が必要な場合。大規模環境でもまずはStandardでコストを抑え、コンプライアンス要件に応じてPremiumを選択します。

【まとめ】

導入にあたっての重要な3要点は以下の通りです。

  1. 移行のダウンタイム回避: RBACを有効にすると、既存のアクセスポリシーは即座に無視されます。必ず「RBACのロール付与」を先行させてから、設定を切り替えてください。

  2. 最小特権の徹底: アプリケーションのマネージドIDには「Key Vault Secrets User」のみを付与し、管理権限を与えないよう設計してください。

  3. 伝播遅延の考慮: RBACのロール割り当ては最大10分程度の反映遅延が発生する可能性があるため、CI/CDパイプラインでの構築直後のアクセスにはリトライ処理を検討してください。

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

コメント

タイトルとURLをコピーしました