Azure Key Vault、アクセス制御モデルをAzure RBACへ完全移行—レガシーAPIは2027年2月に廃止へ

Tech

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

Azure Key Vault、アクセス制御モデルをAzure RBACへ完全移行—レガシーAPIは2027年2月に廃止へ

MicrosoftはAzure Key Vaultの既定アクセス制御をAzure RBACへ統一し、旧来のボールトアクセスポリシーモデルを2027年2月28日に完全廃止します。

【ニュースの概要】

  • 発表組織と移行スケジュール: Microsoftは、秘密情報・暗号化キー・証明書の管理サービス「Azure Key Vault」において、新規作成時の既定アクセス制御モデルを「Azure RBAC（ロールベースアクセス制御）」へと切り替え、旧仕様である「ボールトアクセスポリシー（Vault Access Policy）」を2027年2月28日（協定世界時）に退役（Retire）させるとアナウンスしました。

  • レガシーAPIの廃止: 2025年2月28日以降、ボールトアクセスポリシーを構成・操作するためのコントロールプレーンAPI（2015-06-01から2024-04-01-previewまでのバージョン）が非推奨（Deprecated）となり、3年間の猶予期間を経て2027年2月に完全終了します。

  • 既存リソースへの影響: 既存のKey Vaultリソースでボールトアクセスポリシーを利用している環境は、廃止日までにRBACモデルへの移行とIaC（Terraform、Bicep、ARMテンプレート）定義の更新が必要となります。

【技術的背景と仕組み】

従来の「ボールトアクセスポリシー」は、Key Vault専用の権限管理モデルであり、ボールト単位でしかアクセス権を付与できませんでした。そのため、特定のシークレットやキー単位での細粒度な権限分割（最小権限の原則の適用）が難しく、Azure全体の統一的なIDガバナンス（Microsoft Entra ID / Azure RBAC）とも分離されていました。

Azure RBACモデルへの移行により、以下が実現されます。

  • 粒度の細かいアクセス制御: ボールト全体だけでなく、個別シークレット・キー・証明書単位でのスコープ指定が可能。

  • 集中管理と監査: 特権ID管理（PIM）によるジャストインタイム（JIT）アクセスや、Azureリソース全体で共通のロール割り当てパイプラインの統合。

  • 運用モデルの一元化: 他のAzure PaaSリソースと同様に、ARM/Bicep/Terraformで同一のRBAC構文を用いた定義が可能。

graph TD
    User["開発者 / アプリケーション"] --> Entra["Microsoft Entra ID"]
    Entra -->|RBACロール割り当て| Scope

    subgraph Azure Key Vault
        Scope{"認可スコープ"}
        Scope -->|Vaultレベル| VaultRole["Key Vault Secrets Officer等"]
        Scope -->|個別シークレットレベル| SecretRole["Key Vault Secrets User"]
        VaultRole --> SecretA["Secret A"]
        VaultRole --> SecretB["Secret B"]
        SecretRole --> SecretB
    end

上記の図に示す通り、Azure RBACではボールト全体への権限付与に加え、個々のシークレットやキーをスコープとしたピンポイントなロール割り当てが可能となります。

【コード・コマンド例】

1. Azure CLIによるRBACロールの割り当て

特定のシークレットに対して「Key Vault Secrets User（キー コンテナー シークレット ユーザー）」ロールを付与する例です。

# 対象のKey VaultとシークレットのリソースIDを取得

VAULT_NAME="kv-production-app"
SECRET_NAME="DatabaseConnectionString"
SECRET_ID=$(az keyvault secret show --vault-name $VAULT_NAME --name $SECRET_NAME --query id -o tsv)

# 対象のサービスプリンシパルまたはユーザーにシークレット単位でロールを付与

ASSIGNEE_OBJECT_ID="00000000-0000-0000-0000-000000000000"

az role assignment create \
    --role "Key Vault Secrets User" \
    --assignee-object-id $ASSIGNEE_OBJECT_ID \
    --assignee-principal-type "ServicePrincipal" \
    --scope "$SECRET_ID"

2. BicepでのRBAC有効化

新規作成するKey VaultでRBAC認可を強制する場合、enableRbacAuthorization: true を明示します。

resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: 'kv-prod-eastus-01'
  location: resourceGroup().location
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: subscription().tenantId
    enableRbacAuthorization: true // Azure RBACを有効化
    accessPolicies: [] // アクセスポリシーは空配列または定義しない
  }
}

【インパクトと今後の展望】

事実（Fact）に基づく影響

  • CI/CD・IaCコードの書き換え: Terraformの azurerm_key_vault_access_policy リソースや、Bicepの accessPolicies プロパティを使用した既存の構成は、廃止日までに azurerm_role_assignment や Microsoft.Authorization/roleAssignments に置き換える必要があります。

  • データプレーンのロール標準化: 「Key Vault Administrator」「Key Vault Secrets Officer」「Key Vault Crypto User」などのビルトインロールを適切に選択する設計標準の策定が求められます。

考察（Opinion）

この決定は、Azure全体の権限管理をEntra IDベースの統一RBACプレーンへ統合するMicrosoftのロードマップの一環とみられます。ボールトアクセスポリシーは長年親しまれてきた一方、マルチテナント環境や大規模エンタープライズでの権限過剰付与の原因となっていました。RBACへの強制移行によってセキュリティポスチャは大幅に強化される反面、RBACの伝播遅延（数分程度のロール反映待ち時間）を考慮したデプロイパイプラインの設計見直しが運用上の課題になると考えられます。

【まとめ】

  1. 廃止期日: 旧ボールトアクセスポリシーおよび関連APIは2027年2月28日に完全廃止されます。

  2. 移行メリット: Azure RBACにより、シークレット個別の最小権限付与やPIM連携などセキュリティガバナンスが向上します。

  3. 推奨アクション: 新規リソースではRBACを即時標準化し、既存のIaCテンプレートやデプロイスクリプトの棚卸しとRBACリソースへの書き換えを計画的に進める必要があります。

参考リンク:

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

コメント

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