Azure Key VaultのRBAC移行：大規模環境・複数チームにおけるセキュアなシークレット管理の最適解

Azure Key Vaultのアクセス制御において、従来の「アクセスポリシー」から「Azure RBAC（ロールベースアクセス制御）」への移行は、大規模環境や複数チームによる安全なシークレット管理を実現するための必須アプローチです。

本記事では、アクセスポリシーの限界を突破し、Entra IDベースの高度なガバナンスと最小特権の原則を実現するRBAC移行の具体的な手順と設計のポイントを解説します。

Azure Key VaultのRBAC移行におけるアーキテクチャ設計

従来の「アクセスポリシー」はコンソール全体へのフラットな権限付与になりがちでしたが、Azure RBACへの移行により、管理プレーン（IAM）とデータプレーン（秘密情報へのアクセス）を分離・統合管理できます。

大規模環境では、管理グループやサブスクリプション単位での継承を利用し、チームごとの職務分掌（SoD）を明確化します。

graph TD
    subgraph "Entra ID Tenant"
        A["Admin Group/PIM"] -->|Grant Role| B("Azure RBAC Engine")
        C["App Service MSI"] -->|Identity| B
    end

    subgraph "Azure Resource Hierarchy"
        B -->|Authorize| D["Key Vault: RBAC Mode"]
        D --> E{Secret/Key/Cert}
    end

    subgraph "Monitoring & Security"
        D -->|Logs| F["Log Analytics"]
        G["Microsoft Defender for Key Vault"] -.->|Scanning| D
    end

    E --- E1["Secrets User"]
    E --- E2["Secrets Officer"]

実装・デプロイ手順

既存のKey VaultをRBAC認可へ切り替え、Bicepを用いて最小特権のロールを割り当てる手順を確認します。

1. 認可モデルの変更 (Azure CLI)

既存のKey VaultをRBAC認可モードにアップグレードします。この操作を行うと、既存のアクセスポリシーは無効化されるため注意してください。

# 既存のKey VaultをRBAC認可モードにアップグレード
az keyvault update \
  --name "kv-prod-shared-001" \
  --resource-group "rg-shared-infrastructure" \
  --enable-rbac-authorization true

2. IaCによるロール割り当て (Bicep)

Bicepテンプレートを使用して、マネージドアイデンティティに対して最小特権のロール（例: Key Vault Secrets User）を割り当てます。

// Key Vault Secrets User ロールの定義 (最小特権)
resource kvRoleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(keyVault.id, managedIdentityPrincipalId, '4633458b-17de-408a-b874-0445c86b69e6')
  scope: keyVault
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '4633458b-17de-408a-b874-0445c86b69e6') // Key Vault Secrets User
    principalId: managedIdentityPrincipalId
    principalType: 'ServicePrincipal'
  }
}

アイデンティティとセキュリティのベストプラクティス

• 職務分掌の徹底: Key Vault Administrator（管理のみ）、Key Vault Secrets Officer（値の操作）、Key Vault Secrets User（読み取りのみ）を厳格に使い分けます。
• PIM (Privileged Identity Management): 管理者権限は常時付与せず、承認ベースの「JIT (Just-In-Time) アクセス」を構成します。
• ネットワーク境界: パブリックアクセスを拒否し、Private Linkと信頼されたサービス経由の通信のみに制限します。

運用・コスト最適化

• 可観測性: Log Analyticsで監査ログを収集し、KQLを活用して未使用のシークレットを特定・削除します。
• コスト設計: 標準的なアプリケーションにはStandard SKUを、HSM保護が必要な要件にはPremium SKUを選択します。
• パージ保護の有効化: 誤削除によるデータ消失を防ぐため、「論理削除（Soft Delete）」と「パージ保護」を必ず有効化します。

まとめ

Azure Key VaultのRBAC移行により、きめ細やかなアクセス制御とスケーラブルな権限管理が可能になります。移行時は既存ポリシーへの影響を十分に検証し、IaCによる宣言的な管理を徹底してください。