Azure Key VaultをアクセスポリシーからAzure RBACへ：大規模運用のための移行戦略

Tech

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

Azure Key VaultをアクセスポリシーからAzure RBACへ：大規模運用のための移行戦略

【導入】 従来のアクセスポリシーの限界を突破し、Entra IDによる一元管理と最小特権の原則を大規模・複数チーム環境で実現します。

【アーキテクチャ設計】 従来の「アクセスポリシー」はKey Vault単位のフラットな権限付与でしたが、Azure RBAC（ロールベースのアクセス制御）へ移行することで、管理プレーンとデータプレーンをEntra IDで統合管理します。これにより、サブスクリプションやリソースグループ単位での権限継承や、Privileged Identity Management (PIM) による時限付き権限付与が可能になります。

graph TD
    subgraph "Identity Provider"
        Entra["Microsoft Entra ID"]
    end

    subgraph "Scope Hierarchy"
        Sub["Subscription / MG"]
        RG["Resource Group"]
        AKV["Azure Key Vault"]
    end

    Admin["Security Admin"] -->|Assign Roles| Entra
    User["Dev / App Service"] -->|Request Access| Entra
    Entra -->|Access Token| AKV

    AKV -.->|Audit Logs| LA["Log Analytics"]

    subgraph "Built-in Roles"
        R1["Key Vault Administrator"]
        R2["Key Vault Secrets Officer"]
        R3["Key Vault Secrets User"]
    end

【実装・デプロイ手順】 既存のKey VaultをRBAC認可モデルへ切り替える際は、enableRbacAuthorization プロパティを true に設定します。移行前に、必要なユーザー/サービスプリンシパルに適切なRBACロール（例: Key Vault Secrets User）が割り当てられていることを確認してください。

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

# 既存のKey VaultをRBAC認可に切り替え

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

2. Bicep によるコードベースの定義

// Key Vaultの定義
resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: 'kv-prod-backend-001'
  location: resourceGroup().location
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: subscription().tenantId
    enableRbacAuthorization: true // RBACを有効化
    enabledForDeployment: true
    enabledForTemplateDeployment: true
  }
}

// 参照用：Key Vault Secrets User (b86a8fe4-44ce-4919-9750-73856b4b3041)
resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(keyVault.id, 'app-service-id', 'Key Vault Secrets User')
  scope: keyVault
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', 'b86a8fe4-44ce-4919-9750-73856b4b3041')
    principalId: 'app-service-principal-object-id'
    principalType: 'ServicePrincipal'
  }
}

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

  • 最小特権の原則 (PoLP): アプリケーションには「Key Vault Secrets User」を割り当て、シークレットの読み取りのみを許可します。管理作業には「Key Vault Administrator」を使用しますが、これは PIM を通じたアクティブ化を必須とすべきです。

  • 条件付きアクセス: Key Vaultへのアクセスに対し、多要素認証 (MFA) や信頼済みデバイスからのアクセスのみを許可するポリシーを適用します。

  • Microsoft Defender for Key Vault: RBAC移行後も、異常なアクセスパターン（例: 短時間の大量シークレット取得）を検知するために有効化を推奨します。

【運用・コスト最適化】

  • 可観測性: Azure Monitor の診断設定で AuditEvent を Log Analytics に送信します。RBACに移行することで、ログ内の principalId と Entra ID のユーザーが直接紐付き、監査の透明性が向上します。

  • コスト最適化:

    • SKU選択: HSM（ハードウェアセキュリティモジュール）が必要ない場合は「Standard」を選択し、コストを抑えます。

    • 一元化 vs 分散: チームごとにVaultを分けることで爆発半径を抑えられますが、管理オーバーヘッドとのトレードオフになります。RBACなら「リソースグループ単位の権限付与」でこのバランスを最適化できます。

【まとめ】

  1. 移行の順序: RBACを有効化する前にロールを割り当てないと、全ユーザーが即座にアクセス不能になる「ロックアウト」が発生するため注意が必要です。

  2. 管理の統合: 個別のアクセスポリシー管理から解放され、Azure Lighthouse等を用いたマルチテナント環境の統制にも対応可能になります。

  3. 互換性の確認: 極めて古いアプリケーションSDKではRBAC認可に対応していない場合があるため、移行前にSDKバージョンの確認を推奨します。

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

コメント

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