Azure Key Vault アクセス構成のモダン化：コンプライアンスと運用効率を両立する RBAC 移行ガイド

Tech

{ “role”: “Senior Cloud Architect”, “focus”: “Azure Key Vault Security & Governance”, “framework”: “Azure Well-Architected Framework (Security)”, “vibe”: “Professional, Technical, Strategic” }

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

Azure Key Vault アクセス構成のモダン化：コンプライアンスと運用効率を両立する RBAC 移行ガイド

【導入】 アクセスポリシーの限界を克服し、Azure RBAC によるきめ細かな権限管理と大規模組織でのガバナンス強化を実現します。

【アーキテクチャ設計】 従来型の「アクセスポリシー」は、Vault 単位でしか権限を付与できず、かつ最大 1024 件の制限がありました。Azure RBAC（ロールベースのアクセス制御）へ移行することで、シークレットやキーといった個別リソース単位での権限管理が可能になり、Microsoft Entra ID と完全に統合された最小特権の原則を適用できます。

graph TD
    subgraph "Microsoft Entra ID"
        User[Admin/Developer]
        AppID["Managed Identity"]
    end

    subgraph "Azure RBAC Control Plane"
        RBAC["Azure RBAC Roles"]
    end

    subgraph "Key Vault("RBAC Mode")"
        KV["Key Vault Instance"]
        subgraph "Individual Objects"
            Secret1["Secret A"]
            Key1["Key B"]
        end
    end

    User -->|Assign Role| RBAC
    AppID -->|Assign Role| RBAC
    RBAC -->|Scope: Resource Group/KV/Object| KV
    KV -->|Authorize| Secret1
    KV -->|Authorize| Key1

この構成では、プラットフォーム管理者が Vault 全体の管理権限を持ちつつ、各アプリケーションチームには特定のシークレットのみを参照できる「Key Vault Secrets User」権限を個別に割り当てることが可能です。

【実装・デプロイ手順】 既存の Key Vault を Azure RBAC 許可モデルへ変更し、Bicep を用いて権限を定義する手順を以下に示します。

1. Azure CLI による許可モデルの変更

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

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

2. Bicep による権限の宣言的定義（マネージド ID への参照権限付与）

// 組み込みロール定義ID (Key Vault Secrets User)
var secretUserRoleId = '46334563-8a78-411e-8dca-53e51337e20a'

resource kv 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
  name: 'kv-prod-backend-001'
}

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(kv.id, 'app-identity', secretUserRoleId)
  scope: kv
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', secretUserRoleId)
    principalId: 'YOUR_MANAGED_IDENTITY_OBJECT_ID'
    principalType: 'ServicePrincipal'
  }
}

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

  • 分離の原則: 「Key Vault Administrator（管理）」と「Key Vault Secrets Officer（内容更新）」、「Key Vault Secrets User（読み取り）」を明確に分離します。

  • 条件付きアクセス: 管理者ユーザーに対しては、Entra ID の条件付きアクセスで MFA 強制および信頼されたデバイスからのアクセスのみを許可します。

  • プライベート リンク: インターネット経由のアクセスを遮断し、Private Link 経由の VNet 内部通信に限定します。

【運用・コスト最適化】

  • 可観測性: Azure Monitor の診断設定で AuditEvent を有効化し、Log Analytics へ転送。誰がいつどのシークレットにアクセスしたかを KQL で即座にクエリ可能にします。

  • SKU 選択:

    • Standard: 汎用的なシークレット・証明書管理（ソフトウェア保護）。

    • Premium: HSM（ハードウェア・セキュリティ・モジュール）保護が必要な FIPS 140-2 Level 3 準拠の鍵が必要な場合に選択。

  • コスト: RBAC への移行自体にコストはかかりませんが、API リクエスト数に応じた課金が発生するため、アプリケーション側でのキャッシュ（Azure SDK の機能等）の活用を推奨します。

【まとめ】

  1. 移行のタイミング: 許可モデルを RBAC に変更した瞬間、既存のアクセスポリシーは無効化されます。事前に RBAC ロールの割り当てを完了させてから切り替えてください。

  2. スコープの最小化: サブスクリプション単位での権限付与を避け、可能な限りリソースグループまたは Key Vault インスタンス単位での割り当てを徹底します。

  3. ガバナンス: Azure Policy を使用して、新規作成されるすべての Key Vault で enableRbacAuthorization が true であることを強制することを推奨します。

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

コメント

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