Azure Key VaultのAzure RBAC移行：大規模複数チーム環境における統制と最小特権アクセスの実現

Tech

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

Azure Key VaultのAzure RBAC移行：大規模複数チーム環境における統制と最小特権アクセスの実現

【導入】

アクセスポリシーからAzure RBACへの移行により、大規模マルチチーム環境での権限管理の破綻とガバナンス低下の課題を解決します。

【アーキテクチャ設計】

従来の「アクセスポリシー」モデルは、Key Vaultインスタンス単位での大雑把なアクセス制御しか行えず、かつAzureの標準的なIAM（Identity and Access Management）管理画面から独立しているため、統制の形骸化を招きやすい課題がありました。

新設計となる「Azure RBAC」モデルでは、コントロールプレーンとデータプレーンのアクセス制御をMicrosoft Entra ID（旧Azure AD）へ完全に統合します。これにより、Key Vault全体だけでなく、個々のシークレットやキー、証明書といった「オブジェクト単位（スコープ）」での最小特権の割り当てが可能になります。

graph TD
    subgraph EntraID["Microsoft Entra ID"]
        AdminGroup["プラットフォーム管理者グループ"]
        AppID["アプリ用マネージドID"]
    end

    subgraph AzureSub["Azure Subscription"]
        subgraph RG["リソースグループ"]
            AKV["Azure Key Vault 
※Azure RBAC認可モデル"]
            SecA["シークレット A 
スコープ: 個別"]
            SecB["シークレット B 
スコープ: 個別"]
        end
    end

    AdminGroup -->|Key Vault管理者| AKV
    AppID -->|Key Vaultシークレットユーザー| SecA
    style AKV fill:#0072C6,stroke:#333,stroke-width:2px,color:#fff

【実装・デプロイ手順】

移行および構築は以下のプロセスで実施します。既存のアクセスポリシーを残したままRBACの権限を付与し、動作確認が完了した段階でRBAC認可フラグをオンに切り替えます。

1. Azure CLIによる認可モデルの切り替え

既存のKey Vaultに対してAzure RBACを有効化します。

# 変数の定義

RESOURCE_GROUP="rg-enterprise-prod"
KEY_VAULT_NAME="kv-shared-prod-001"

# Azure RBAC認可モデルへの強制切り替え（一時的な並行期間後に実行推奨）

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

2. BicepによるInfrastructure as Code（IaC）構成

IaCデプロイにおいて、Azure RBAC認可を強制しつつ、アプリケーションのマネージドIDに対して個別のシークレットへのアクセス権のみを付与する定義例です。

param location string = resourceGroup().location
param keyVaultName string = 'kv-shared-prod-001'
param appManagedIdentityObjectId string = '00000000-0000-0000-0000-000000000000' // アプリのプリンシパルID

// 1. Key Vault の作成（Azure RBAC認可を有効化、パブリック接続は拒否）
resource kv 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: keyVaultName
  location: location
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: subscription().tenantId
    enableRbacAuthorization: true // RBAC認可の有効化
    enablePurgeProtection: true   // パージ保護の有効化（ランサムウェア対策）
    softDeleteRetentionInDays: 90
    networkAcls: {
      bypass: 'AzureServices'
      defaultAction: 'Deny'        // デフォルトでパブリックアクセスを拒否
    }
  }
}

// 2. テスト用シークレットの作成
resource secret 'Microsoft.KeyVault/vaults/secrets@2023-07-01' = {
  parent: kv
  name: 'DatabaseConnectionString'
  properties: {
    value: 'Server=tcp:sql-prod.database.windows.net...'
  }
}

// 3. ビルトインロール「Key Vault シークレット ユーザー」のID定義
var secretUserRoleId = '46330157-13e5-4dfc-8298-757538279067'

// 4. アプリケーションのマネージドIDに対して、特定シークレットのみの権限を付与（スコープ制限）
resource roleAssignmentToSecret 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(secret.id, appManagedIdentityObjectId, secretUserRoleId)
  scope: secret // スコープをKey Vault全体ではなくシークレット単位に制限
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', secretUserRoleId)
    principalId: appManagedIdentityObjectId
    principalType: 'ServicePrincipal'
  }
}

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

1. 最小特権に基づくロール設計

標準の組み込みロールを使い分け、データプレーン（シークレットの読み書き）とコントロールプレーン（Key Vaultの設定変更）の権限を厳密に分離します。

  • プラットフォーム管理者: Key Vault Administrator（PIM: Privileged Identity Management経由でのみ一時昇格可能にする）

  • アプリケーション・システム: Key Vault Secrets User または Key Vault Reader（データプレーンの読み取りのみ許可）

2. セキュリティガードレールの構築

  • 条件付きアクセス（Conditional Access）: Key Vaultを含む「Azure管理ポータル」および「Microsoft Azureサブスクリプション」へのアクセスに対し、Microsoft Entra IDにて多要素認証（MFA）と、Intuneで管理された「準拠済みデバイス」からの接続を必須化します。

  • プライベートエンドポイントの導入: インターネット経由のデータプレーンアクセスを排除するため、Private Link経由でのみアクセスを許可する閉域ネットワーク構造を採用します。

  • Microsoft Defender for Key Vault: 「Microsoft Defender for Cloud」のキーバルトプランを有効化。これにより、異常なIPアドレスからのシークレットの一括取得など、認証情報漏洩の予兆を機械学習で検知・即時ブロックします。

【運用・コスト最適化】

可観測性の確保（監査ログ分析）

Key Vaultに対するすべてのデータ操作（SecretGet、KeySign など）をAzure Log Analyticsワークスペースへ転送し、監査ログを保管します。以下は、不正アクセスの兆候（シークレットの取得失敗）を監視するためのKQL（Kusto Query Language）クエリ例です。

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where OperationName in ("SecretGet", "SecretList")
| where ResultSignature != "OK"
| summarize Count = count() by bin(TimeGenerated, 5m), Resource, OperationName, ResultSignature, CallerIPAddress
| order by Count desc

コスト削減のポイント

  • SKUの適切な選択: 一般的なシークレット管理や証明書のホスティング用途であれば、追加コストを抑えるために Standard SKU（トランザクション数課金）を採用します。FIPS 140-2 Level 3準拠のHSM（ハードウェアセキュリティモジュール）による強力な保護を伴う非対称鍵管理が必要な場合のみ、Premium SKUを選択します。

  • 無駄なトランザクションの削減: アプリケーションコード側でシークレットをメモリ上に適度にキャッシュ（例: 5〜10分程度）する設計とし、Key Vaultへの過剰なAPIポーリングによるトランザクション課金およびスロットリング（HTTP 429エラー）の発生を抑制します。

【まとめ】

  1. 段階的な移行ステップの順守: 既存環境を移行する際は、まずRBACロールを付与した後に認可フラグを有効（enableRbacAuthorization: true）にしてください。フラグ有効化と同時に、既存のアクセスポリシーは即時無視されるため、事前定義なしでの実行はアプリケーション停止の引き金（落とし穴）となります。

  2. グループベースの管理徹底: ユーザー個別へのロール割り当ては管理上限（サブスクリプションあたり4,000割り当て）に達するリスクがあるため、必ず「Microsoft Entra ID グループ」またはアプリケーションごとの「マネージドID（Managed Identity）」に割り当ててください。

  3. 削除保護のデフォルト化: 不慮の管理者操作によるデータ喪失を防ぐため、enablePurgeProtection（パージ保護）と softDeleteRetentionInDays（ソフト削除保持期間）の設定をすべての開発環境・本番環境に適用し、ガバナンスを標準化してください。

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

コメント

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