大規模組織向け Azure Key Vault の RBAC 移行：セキュアかつスケーラブルなシークレット管理の実現

Tech

{ “focus”: “Azure Key Vault RBAC Migration”, “role”: “Senior Cloud Architect”, “compliance”: [“Well-Architected Framework”, “Zero Trust”], “target_audience”: “IT Infrastructure Managers, DevOps Engineers” }

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

大規模組織向け Azure Key Vault の RBAC 移行：セキュアかつスケーラブルなシークレット管理の実現

【導入】

従来のアクセスポリシーの限界を打破し、Azure RBACによる一元管理で大規模環境のガバナンスと運用効率を劇的に向上させます。

【アーキテクチャ設計】

Azure RBAC（ロールベースのアクセス制御）への移行により、従来の「Vault単位」の制限から解放され、シークレット、キー、証明書の個別のリソースレベルで権限を付与できるようになります。これにより、職務分掌（SoD）の徹底と、Microsoft Entra ID（旧 Azure AD）との親和性が最大化されます。

graph TD
    subgraph "Microsoft Entra ID"
        A["Platform Admin"]
        B["App Dev Team"]
        C["Security Auditor"]
    end

    subgraph "Management Scope"
        D["Management Group / Subscription"]
        E["Resource Group"]
    end

    subgraph "Azure Key Vault("RBAC Mode")"
        F["Secret A"]
        G["Key B"]
        H["Certificate C"]
    end

    A -->|Owner/Contributor| D
    B -->|Key Vault Secrets User| F
    C -->|Key Vault Reader| E
    D --> E
    E --> F
    E --> G
    E --> H

この設計では、管理グループやサブスクリプションレベルでの継承を活用し、個別のKey Vault設定作業を最小限に抑えます。

【実装・デプロイ手順】

既存の Key Vault を RBAC 権限モデルへ切り替え、Bicep を用いて標準的なロールを割り当てる手順です。

1. 権限モデルの変更 (Azure CLI)

# 既存の Key Vault を RBAC 許可モデルに更新

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

2. Infrastructure as Code (Bicep) による構成

// Key Vault の定義と RBAC 有効化
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
    enableRbacAuthorization: true // RBACを有効化
    enabledForDeployment: true
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
    publicNetworkAccess: 'Disabled' // 閉域網推奨
  }
}

// 開発チームへの「シークレット参照権限」付与 (Built-in Role: Key Vault Secrets User)
resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(keyVault.id, 'dev-team-id', '4633458b-17de-408a-b874-0445c86b69e6')
  scope: keyVault
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '4633458b-17de-408a-b874-0445c86b69e6')
    principalId: 'SERVICE_PRINCIPAL_OR_GROUP_OBJECT_ID'
    principalType: 'ServicePrincipal'
  }
}

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

  • 最小特権の原則: Key Vault Administrator は管理用（インフラ担当）に限定し、アプリケーションには Key Vault Secrets User のみを付与します。

  • PIM (Privileged Identity Management): 管理者権限（Administrator/Crypto Officer）は常時付与せず、必要時にアクティブ化する運用を徹底します。

  • 条件付きアクセス: Key Vault へのアクセスに対し、マネージドデバイス（合致したデバイス）からのアクセスのみを許可するポリシーを Entra ID 側で構成します。

  • ネットワーク境界: Private Link を使用して、パブリックインターネットからのエンドポイントアクセスを遮断します。

【運用・コスト最適化】

  • 可観測性: Azure Monitor の診断設定を有効化し、AuditEvent を Log Analytics ワークスペースへ送信。誰がどのシークレットにアクセスしたかをリアルタイムで監視します。

  • コスト削減:

    • SKU選択: HSM（ハードウェアセキュリティモジュール）が必要な要件がない限り、コスト効率の高い Standard SKU を選択します。

    • 要求管理: RBAC への移行自体に直接の追加費用はかかりませんが、API リクエスト数に基づく課金であるため、アプリケーション側でのキャッシュ（Azure App Configuration の併用等）を検討してください。

【まとめ】

  1. 移行時の注意点: アクセスポリシーから RBAC への変更時、既存のアクセスポリシーは無視されます。切り替え前に必ず RBAC ロールの割り当てを完了させてください。

  2. 標準化の推進: 独自のカスタムロールを作成せず、可能な限り Azure 組み込みロール（Secrets User, Crypto Service Encryption User 等）を利用することで管理負荷を軽減します。

  3. 削除保護の必須化: RBAC 移行と併せて、Soft Delete（論理削除）と Purge Protection（パージ保護）を有効にし、不慮のデータ消失リスクを排除してください。

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

コメント

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