本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Azure Key Vaultの「コンテナーアクセスポリシー」が2027年に廃止。Azure RBACへの完全移行が必須に
マイクロソフトはAzure Key Vaultの旧来のアクセス制御モデルを2027年2月に廃止し、より高度な管理が可能なAzure RBACへの移行を義務付けます。
【ニュースの概要】
マイクロソフト（Microsoft Corporation）は、Azure Key Vaultにおける従来の「コンテナーのアクセスポリシー（Vault Access Policy）」モデルの廃止を正式に発表しました。
廃止期日： 2027年2月28日（日本時間：2027年3月1日予定）
移行先： Azure ロールベースのアクセス制御（Azure RBAC）
影響範囲： 既存のアクセスポリシーを使用しているすべてのKey Vaultリソース。廃止日以降、旧モデルによるアクセス制御は機能しなくなり、Azure RBACへの構成変更が必要となります。
【技術的背景と仕組み】
従来の「アクセスポリシー」モデルは、Key Vault固有の管理プレーンに依存しており、Azureの他のリソース（StorageやSQL等）で採用されている統合的な管理体系（Azure RBAC）とは独立していました。これにより、権限の継承ができない、細かいスコープ設定が困難、監査の複雑化といった課題がありました。
Azure RBACへの移行により、Microsoft Entra ID（旧Azure AD）に基づいた統一的なガバナンスが実現されます。
graph TD
A["管理者/アプリケーション"] -->|ロール割り当て| B{"Azure RBAC"}
B -->|リソースグループ単位| C["Key Vault A"]
B -->|Vault単位| D["Key Vault B"]
B -->|個別シークレット単位| E["シークレット X"]
C --- F["(鍵・証明書)"]
D --- G["(シークレット)"]
E --- H["(特定シークレット)"]
この図が示す通り、Azure RBACでは管理グループやサブスクリプションレベルからの権限継承に加え、個別のシークレット単位での極めて細かな権限設定が可能になります。
【コード・コマンド例】
既存のKey VaultをAzure RBACモデルへ切り替え、特定のサービスプリンシパルに「シークレットの読み取り」権限を付与するAzure CLIの例です。
1. アクセス構成をAzure RBACに変更する
# Azure RBACを有効化（既存のアクセスポリシーは無視されるようになります） az keyvault update \ --name "MyKeyVaultName" \ --resource-group "MyResourceGroup" \ --enable-rbac-authorization true
2. ロールを割り当てる（Key Vault シークレット ユーザー）
# サービスプリンシパル等に対して「参照」権限を付与 az role assignment create \ --role "Key Vault Secrets User" \ --assignee "<Object-ID>" \ --scope "/subscriptions/<Sub-ID>/resourceGroups/<RG-Name>/providers/Microsoft.KeyVault/vaults/MyKeyVaultName"
【インパクトと今後の展望】
事実（Fact）： マイクロソフトは、新規に作成されるKey Vaultにおいて、既にAzure RBACを既定の推奨オプションとして提示しています。また、2027年の廃止に向けて、Azure Portal上での警告表示や移行ツールの提供を開始しています。
考察（Opinion）： この変更は、単なるAPIの更新ではなく「Azureにおけるセキュリティモデルの完全な統一」を意味します。開発者にとっては、TerraformやBicepなどのIaC（Infrastructure as Code）定義を大幅に修正する必要があるため、早期の着手が必要です。特に、アクセスポリシーでは不可能だった「特定のシークレットのみ参照可能にする」といった最小権限の原則（PoLP）が容易に実現できるようになるため、セキュリティ強度は格段に向上するでしょう。
【まとめ】
2027年2月28日までに「コンテナーアクセスポリシー」から「Azure RBAC」への移行を完了させる必要がある。
Azure RBACへの移行により、シークレット単位の細かい制御と、Azureリソース全体での一元的な権限管理が可能になる。
既存のIaCテンプレート（Terraform, ARM, Bicep）にアクセスポリシーの定義が含まれている場合、早期のコード修正とテストが推奨される。
参考リンク：
