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

Azure Key VaultのRBAC移行：大規模環境・複数チーム運用を支えるアクセス制御基盤の構築

【導入】

従来のアクセス制御ポリシーからAzure RBACへ移行し、複数チーム・大規模環境における最小権限の原則と統合管理を実現します。

【アーキテクチャ設計】

Azure Key Vaultのアクセスモデルを従来の「保管庫アクセス ポリシー（Vault-level Access Policies）」から「Azure RBAC（Role-Based Access Control）」へ移行することで、Microsoft Entra IDに基づく一元的なIdentity and Access Management（IAM）統制が可能になります。

従来のアクセスポリシーでは保管庫全体（Vaultレベル）に対してしか権限を付与できず、シークレットごとの個別制御や管理権限の委任が困難でした。Azure RBACモデルを採用することにより、管理プレーンとデータプレーンの権限分離を明確化し、リソースグループ、個別Key Vault、さらには特定のシークレット/キー/証明書単位（オブジェクトレベル）での細粒度なアクセス制御が実現します。

graph TD
    subgraph EntraID["Microsoft Entra ID (Identity Platform)"]
        UserGroup["App Dev Team (Group)"]
        WorkloadID["App Managed Identity"]
        AdminGroup["Security Admin (Group)"]
    end

    subgraph Scope["Azure Resource Management Scope"]
        subgraph RG["Resource Group: rg-app-prod"]
            KV["Azure Key Vault('RBAC Enabled')"]
            subgraph DataPlane["Data Plane Objects"]
                Sec1["Secret: DB-Conn-String"]
                Sec2["Secret: API-Key"]
            end
        end
    end

    AdminGroup -->|"Key Vault Administrator"| KV
    UserGroup -->|"Key Vault Secrets Officer"| Sec2
    WorkloadID -->|"Key Vault Secrets User"| Sec1
    KV --- DataPlane

構成要素の役割と相互作用は以下の通りです。

• Microsoft Entra ID: ユーザー、グループ、マネージドアイデンティティ（Workload ID）の認証基盤。PIM（Privileged Identity Management）と連携したジャストインタイムアクセスを提供します。

• 管理プレーン（Management Plane）: Key Vaultリソース自体の作成、更新、削除、ネットワークルールの変更を行います（Microsoft.KeyVault/vaults/*）。

• データプレーン（Data Plane）: Vault内部のキー、シークレット、証明書の読み取り、書き込み、暗号化処理を実行します（Microsoft.KeyVault/vaults/secrets/* 等）。

【実装・デプロイ手順】

移行手順は「既存アクセス権の調査」「RBAC有効化とロール割り当て（IaC）」「動作確認」の順で進めます。

1. BicepによるKey VaultのRBAC移行構成

Key Vaultのプロパティ enableRbacAuthorization を true に設定してデプロイします。

@description('デプロイ先のロケーション')
param location string = resourceGroup().location

@description('Key Vault名')
param keyVaultName string = 'kv-app-prod-eastasia-01'

@description('開発チームグループのPrincipal ID')
param devGroupPrincipalId string

// Key Vaultの定義（RBAC有効化）
resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: keyVaultName
  location: location
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: subscription().tenantId
    enableRbacAuthorization: true // Azure RBACを有効化
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
    publicNetworkAccess: 'Disabled'
  }
}

// 組み込みロール定義ID: Key Vault Secrets User
var secretsUserRoleId = '46330053-77cd-44a1-b563-f83d37468945'

// 特定のシークレットに対するロール割り当て（スコープの限定）
resource secret 'Microsoft.KeyVault/vaults/secrets@2023-07-01' = {
  parent: keyVault
  name: 'DatabaseConnectionString'
  properties: {
    value: 'Server=tcp:sql.database.windows.net;Database=appdb;'
  }
}

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(keyVault.id, devGroupPrincipalId, secretsUserRoleId)
  scope: secret
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', secretsUserRoleId)
    principalId: devGroupPrincipalId
    principalType: 'Group'
  }
}

2. Azure CLIによる移行コマンド

既存のKey Vaultのアクセスポリシーを無効化し、RBACモデルへ切り替えます。

#!/bin/bash

RESOURCE_GROUP="rg-app-prod"
VAULT_NAME="kv-app-prod-eastasia-01"
DEV_GROUP_ID="<Entra-ID-Group-ObjectID>"

# 1. Key VaultのアクセスモデルをAzure RBACに変更

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

# 2. 開発チームグループへ「Key Vault Secrets User」ロールをキーバルト全体に付与

az role assignment create \
  --assignee-object-id $DEV_GROUP_ID \
  --assignee-principal-type Group \
  --role "Key Vault Secrets User" \
  --scope "/subscriptions/$(az account show --query id -o tsv)/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.KeyVault/vaults/$VAULT_NAME"

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

Azure RBAC移行に伴い、適切な組み込みロールの選定とアクセス境界の強化を実施します。

1. 組み込みRBACロールの設計原則

用途に応じて最小権限の組み込みロールを選択します。カスタムロールの作成はメンテナンスコストが増加するため、極力組み込みロールを利用します。

2. アクセス境界と多層防御

• Entra ID PIM (Privileged Identity Management): 「Key Vault Administrator」等の上位権限は常時割り当て（Active Assignment）を行わず、申請・承認ベースでの「対象可能（Eligible）」割り当てにします。

• 条件付きアクセス（Conditional Access）: Key Vaultへのデータプレーンアクセスに対し、特権アクセスワークステーション（PAW）やMFA、合致したネットワークIPからの要求のみを許可するポリシーを適用します。

• ネットワークセキュリティ: publicNetworkAccess: Disabled を設定し、プライベートエンドポイント（Private Link）経由でのみVNet内部からアクセスを許可します。

【運用・コスト最適化】

1. 可観測性（Log Analytics連携）

データプレーンのアクセスログおよびRBAC拒否イベントを検出するため、診断設定（Diagnostic Settings）を構成します。

# Log Analyticsワークスペースへの診断設定追加

WORKSPACE_ID=$(az monitor log-analytics workspace show --resource-group rg-ops --workspace-name law-prod --query id -o tsv)
KV_ID=$(az keyvault show --name kv-app-prod-eastasia-01 --query id -o tsv)

az monitor diagnostic-settings create \
  --name "ds-keyvault-audit" \
  --resource $KV_ID \
  --workspace $WORKSPACE_ID \
  --logs '[{"categoryGroup": "allLogs", "enabled": true}]' \
  --metrics '[{"category": "AllMetrics", "enabled": true}]'

Log AnalyticsでのRBACアクセス拒否（HTTP 403）監視クエリ：

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where ResultSignature == "Forbidden"
| project TimeGenerated, Resource, OperationName, identity_claim_oid_s, clientInfo_s

2. コスト最適化（SKU選定）

• Standard SKU: 大部分のシークレット、ソフトウェア保護キー、証明書の管理に最適です（APIリクエスト1万回あたり約0.03 USD）。

• Premium SKU: HSM（ハードウェアセキュリティモジュール）保護キー（HSM-protected keys）が必要な場合のみ使用します。HSM保護キーは追加の月額コストが発生するため、要件に応じて厳格に使い分けます。

• APIトランザクション最適化: アプリケーション側でシークレットのインメモリキャッシュ（例: Azure SDKの自動キャッシュ機構）を有効化し、不要なKey Vaultへのリクエスト頻度を抑えます。

【まとめ】

1. アクセスモデル切替に伴う「既存アクセス瞬断」の注意点 enableRbacAuthorization: true へ変更した瞬間、既存のアクセスポリシーは即座に無効化されます。移行時は事前に対象のユーザーやManaged IdentityへRBACロールを割り当ててからモードを変更してください。

2. スコープを限定した細粒度な権限管理の徹底 Key Vault全体への権限付与（Vault Scope）ではなく、特定のシークレットやキーに対する個別ロール割り当て（Object Scope）を活用し、複数チーム間でのセキュリティ境界を確保してください。

3. 監査ログの常時監視とPIMの活用 RBAC移行後はLog Analyticsへ監査ログを出力し、403エラーの監視を行うとともに、管理権限にはEntra ID PIMによるJIT（Just-In-Time）アクセスを導入して特権リスクを低減させてください。