Azure Key Vault RBAC 移行ガイド：大規模マルチチーム運用のための最小権限設計

Tech
{ “role”: “Senior Cloud Architect”, “focus”: “Azure Key Vault RBAC Migration & Governance”, “status”: “Ready”, “context”: “Enterprise multi-team environment”, “tools”: [“Azure CLI”, “Bicep”, “Microsoft Entra ID”] }

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

Azure Key Vault RBAC 移行ガイド：大規模マルチチーム運用のための最小権限設計

【導入】 従来のアクセスポリシーによる制約を解消し、Azure RBACへの移行によって大規模環境でのガバナンスと最小権限原則を徹底する手法を解説します。

【アーキテクチャ設計】 本構成では、従来のVaultレベルでの一括制御（アクセスポリシー）から、リソース、カタログ、シークレット個別のレベルで権限を分離できるAzure RBACモデルを採用します。これにより、開発チームと運用チームの職責分離（SoD）を明確化します。

graph TD
    subgraph "Identity Layer("Microsoft Entra ID")"
        AdminGroup["Key Vault Admins Group"]
        AppIdentity["Managed Identity"]
        PIM["Privileged Identity Management"]
    end

    subgraph "Governance Layer"
        RBAC["Azure RBAC Roles"]
        AzurePolicy["Azure Policy"]
    end

    subgraph "Resource Layer("Key Vault")"
        KV["Key Vault Instance"]
        KV --- Secrets[Secrets]
        KV --- Keys[Keys]
        KV --- Certs[Certificates]
    end

    AdminGroup -->|Eligible Assignment| PIM
    PIM -->|Active Assignment| RBAC
    RBAC -->|Control Plane / Data Plane| KV
    AppIdentity -->|Key Vault Secrets User| Secrets
    AzurePolicy -->|Deny Non-RBAC| KV

構成のポイント:

  • データプレーンのRBAC統合: 従来のコントロールプレーンだけでなく、シークレットの読み取り等のデータ操作もAzure RBACで一元管理。

  • 階層的スコープ: サブスクリプション、リソースグループ、リソース単位に加え、個別のシークレット単位での権限付与が可能。

  • PIMの活用: 管理者権限を「常時保持」から「申請ベース（JIT）」に変更し、侵害リスクを低減。

【実装・デプロイ手順】 既存のKey VaultをRBAC認可モデルへ切り替える手順を示します。

1. RBAC認可の有効化 (Azure CLI)

既存のアクセスポリシーを維持したままRBACを有効化することは可能ですが、最終的にアクセスポリシーは削除します。

# 変数定義

RESOURCE_GROUP="rg-shared-infra"
KV_NAME="kv-prod-app-001"

# RBAC認可を有効化

az keyvault update --name $KV_NAME \
    --resource-group $RESOURCE_GROUP \
    --enable-rbac-authorization true

2. IaCによる定義 (Bicep)

新規構築時にRBACモデルを強制するBicep定義です。

resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: 'kv-prod-core-001'
  location: resourceGroup().location
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: subscription().tenantId
    enableRbacAuthorization: true // RBACを有効化
    enabledForDeployment: false
    enabledForDiskEncryption: false
    enabledForTemplateDeployment: false
    networkAcls: {
      bypass: 'AzureServices'
      defaultAction: 'Deny'
    }
  }
}

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

  • 推奨ロールの適用:

    • 開発者：Key Vault Secrets User（読み取りのみ）

    • セキュリティ管理者：Key Vault Administrator（フルコントロール）

    • CI/CDパイプライン：Key Vault Secrets Officer（書き込み・更新）

  • 条件付きアクセス: Key Vaultへのアクセスに対し、MFA（多要素認証）と「信頼されたデバイス」からのアクセスを強制。

  • Microsoft Defender for Key Vault: 異常な場所からのアクセスや、シークレットの一括流出の兆候を検知・アラート。

【運用・コスト最適化】

  • 可観測性: Diagnostic Settingsを有効化し、AuditEventをLog Analyticsに送信。誰がどのシークレットにアクセスしたかをKQLで追跡可能にします。

  • コスト最適化:

    • 通常のシークレット管理には「Standard SKU」を選択。

    • HSM（ハードウェアセキュリティモジュール）による厳格な保護が必要なFIPS 140-2 Level 3要件がある場合のみ「Premium SKU」を選択。

  • SKUのクォータ監視: 大規模環境ではスロットリング回避のため、リクエスト数のモニタリングが必須です。

【まとめ】

  1. 既存ポリシーの棚卸し: 移行前に、現在のアクセスポリシーが誰に何を許可しているかを完全に可視化すること（移行漏れはサービスダウンに直結します）。

  2. デフォルト拒否の徹底: ネットワークレベルでのアクセス制限（プライベートエンドポイント）を併用し、認可だけでなく通信経路も保護すること。

  3. PIMによるJIT運用の導入: 永続的な特権（Secrets Officer等）を排除し、作業時のみ権限をアクティブ化するフローへ移行すること。

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

コメント

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