{ “version”: “1.1”, “status”: “production”, “design_pattern”: “modern-architecture-blueprint”, “technical_stack”: [“Azure Key Vault”, “Azure RBAC”, “Bicep”, “Entra ID”], “context”: “Enterprise secret management migration” }

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

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

【導入】アクセスポリシーの限界を突破し、Entra IDベースの高度なガバナンスと最小特権の原則を実現する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を用いて最小特権のロールを割り当てる手順です。

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

# 既存のKey VaultをRBAC認可モードにアップグレード

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

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

// 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と信頼されたサービス（Trusted Services）経由の通信のみに制限します。

【運用・コスト最適化】

可観測性: Log Analyticsで「誰が・いつ・どのシークレットにアクセスしたか」を監視します。KQLを用いて、未使用のシークレットを特定することで、ガバナンスを向上させます。
コスト設計:
- Standard SKU: 一般的なアプリケーションのシークレット・証明書管理。
- Premium SKU: HSM（ハードウェア・セキュリティ・モジュール）保護が必要な暗号化キーを扱う場合に選択。
パージ保護の有効化: 誤削除によるデータ消失を防ぐため、物理削除を猶予する「論理削除（Soft Delete）」と「パージ保護」を必ず有効化します。

【まとめ】

移行時の注意: RBACを有効にすると、既存のアクセスポリシーは即座に無効化されます。移行前に必ずロール割り当てを完了させてください。
スコープの最適化: ロール割り当ては可能な限り「Key Vault個別のリソース」または「シークレット単位」で行い、広範な権限付与を避けます。
自動化の推奨: 手動設定はヒューマンエラーの温床です。TerraformやBicepといったIaCによる宣言的な管理を標準化してください。

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

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

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

いいね:

コメント

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

共有:

いいね:

コメント