<p><style_prompt: technical_analyst_v2=""> 本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</style_prompt:></p> <h1 class="wp-block-heading">Azure Key Vault、アクセスポリシーを2027年2月に廃止。Azure RBACへの完全移行が必須に</h1> <p>Microsoftは、Azure Key Vaultの従来型権限モデル「アクセスポリシー」を2027年2月に廃止し、Azure RBACへ一本化する方針を決定しました。</p> <h2 class="wp-block-heading">【ニュースの概要】</h2> <p>Microsoftは2024年2月、Azure Key Vaultにおける従来のアクセス制御モデルの廃止スケジュールを公表しました。セキュリティガバナンスの強化と管理モデルの統合を目的としています。</p> <ul class="wp-block-list"> <li><p><strong>廃止予定日：</strong> 2027年2月28日（JST：2027年3月1日未明）</p></li> <li><p><strong>対象機能：</strong> 従来の「コンテナーアクセスポリシー（Vault Access Policies）」モデル。</p></li> <li><p><strong>推奨アクション：</strong> 既存のKey Vaultを「Azureロールベースのアクセス制御（Azure RBAC）」モデルへ移行すること。</p></li> </ul> <h2 class="wp-block-heading">【技術的背景と仕組み】</h2> <p>従来のアクセスポリシーモデルは、Key Vaultごとに独自の権限リストを持つ仕様であり、Azure全体の統合的な権限管理（Azure RBAC）とは分離されていました。これにより、大規模な環境でのガバナンス適用や、きめ細やかな権限分離（特定のシークレットのみへのアクセス許可など）が困難という課題がありました。</p> <p>Azure RBACへの移行により、管理プレーン（リソースの作成・削除）とデータプレーン（シークレットの読み取り・書き込み）がAzure Resource Manager（ARM）の下で統合され、一貫したセキュリティポリシーの適用が可能になります。</p> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> graph TD Identity["ユーザー/サービスプリンシパル"] -->|認証| EntraID["Microsoft Entra ID"] EntraID -->|認可判断| RBAC["Azure RBACモデル"] RBAC -->|統一的な制御| Vault["Azure Key Vault"] Vault -->|個別アクセス許可| Data["シークレット/キー/証明書"] </pre></div> <p>※従来のモデルでは、Vault単位で「アクセスポリシー」という独自のリストを参照していたため、Azureの標準的なロール割り当てフローから外れる仕組みでした。</p> <h2 class="wp-block-heading">【コード・コマンド例】</h2> <p>既存のKey Vaultに対して、Azure RBACを有効化するためのAzure CLIコマンド例です。</p> <div class="codehilite"> <pre data-enlighter-language="generic"># 特定のKey VaultのアクセスモデルをAzure RBACに切り替える az keyvault update \ --name "MySecureVault" \ --resource-group "MyResourceGroup" \ --enable-rbac-authorization true # 特定のユーザーに「Key Vault シークレット ユーザー」ロールを割り当てる例 az role assignment create \ --role "Key Vault Secrets User" \ --assignee "user@example.com" \ --scope "/subscriptions/<sub-id>/resourceGroups/<rg-id>/providers/Microsoft.KeyVault/vaults/MySecureVault" </pre> </div> <h2 class="wp-block-heading">【インパクトと今後の展望】</h2> <p><strong>（事実）</strong> 2027年2月28日以降、従来のアクセスポリシーを使用しているアプリケーションやスクリプトは、Key Vaultへのアクセスに失敗する可能性があります。</p> <p><strong>（考察）</strong> この移行は、企業のセキュリティ担当者にとって「管理の簡素化」という大きなメリットをもたらします。一方で、長年運用されているシステムでは、ARMテンプレートやTerraformコード、デプロイパイプラインに「アクセスポリシー」の定義がハードコードされているケースが多く、修正範囲は広範に及ぶと予測されます。 特に、アクセスポリシーは「最大1024件」という制限がありましたが、RBACへ移行することでサブスクリプション全体のロール割り当て制限（通常4000件）の影響を受けるようになるため、大規模環境ではリソースグループ単位でのロール継承を設計に組み込む必要があります。</p> <h2 class="wp-block-heading">【まとめ】</h2> <ul class="wp-block-list"> <li><p><strong>2027年2月28日</strong>をもって、旧来のKey Vaultアクセスポリシーは完全に廃止される。</p></li> <li><p><strong>Azure RBAC</strong>への移行により、Entra IDと統合された、より高度で一貫した権限管理が可能になる。</p></li> <li><p>既存のIaC（Infrastructure as Code）や自動化スクリプトの改修が必要となるため、早期のインベントリ確認と移行計画の策定が推奨される。</p></li> </ul> <p><strong>参考リンク：</strong></p> <ul class="wp-block-list"> <li><p><a href="https://learn.microsoft.com/ja-jp/azure/key-vault/general/rbac-migration">Azure Key Vault のアクセス ポリシーから Azure RBAC への移行（公式ドキュメント）</a></p></li> <li><p><a href="https://azure.microsoft.com/en-us/updates/vault-access-policy-retirement/">Vault access policy retirement announcement</a></p></li> </ul>

graph TD
Identity["ユーザー/サービスプリンシパル"] -->|認証| EntraID["Microsoft Entra ID"]
EntraID -->|認可判断| RBAC["Azure RBACモデル"]
RBAC -->|統一的な制御| Vault["Azure Key Vault"]
Vault -->|個別アクセス許可| Data["シークレット/キー/証明書"]

# 特定のKey VaultのアクセスモデルをAzure RBACに切り替える

az keyvault update \
    --name "MySecureVault" \
    --resource-group "MyResourceGroup" \
    --enable-rbac-authorization true

# 特定のユーザーに「Key Vault シークレット ユーザー」ロールを割り当てる例

az role assignment create \
    --role "Key Vault Secrets User" \
    --assignee "user@example.com" \
    --scope "/subscriptions/<sub-id>/resourceGroups/<rg-id>/providers/Microsoft.KeyVault/vaults/MySecureVault"