<p><!-- style_prompt: analyst_tech_news_v1 --> 本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p> <h1 class="wp-block-heading">Azure Key Vaultのアクセス制御がAzure RBACへ完全移行、旧アクセスポリシーは2027年2月に廃止へ</h1> <p>MicrosoftはAzure Key Vaultのアクセス制御モデルをAzure RBACへ統一し、従来のVaultアクセスポリシーを2027年2月に廃止します。</p> <h2 class="wp-block-heading">【ニュースの概要】</h2> <p>Microsoftは2024年2月29日（米国時間）、Azure Key Vaultにおける従来のアクセス制御モデル「Vault アクセス ポリシー（Vault Access Policy）」を2027年2月28日をもって廃止することを発表しました。今後は「Azure RBAC（ロールベースアクセス制御）」が標準かつ既定のアクセス制御モデルとして位置付けられます。</p> <ul class="wp-block-list"> <li><p><strong>発表組織・日付</strong>：Microsoft（2024年2月29日発表 / 日本時間2024年3月1日）</p></li> <li><p><strong>【事実】2027年2月28日の旧モデル廃止</strong>：従来のVault アクセス ポリシー APIおよび制御画面が完全に廃止されます。</p></li> <li><p><strong>【事実】デフォルトモデルの統合</strong>：新規作成されるKey VaultではAzure RBACが標準の認可モデルとなり、IAM（Identity and Access Management）による一元管理へ移行します。</p></li> <li><p><strong>【事実】移行期間の設定</strong>：廃止日までの約3年間（現在移行期間中）、既存リソースのRBACモデルへの切り替えが強く推奨されています。</p></li> </ul> <h2 class="wp-block-heading">【技術的背景と仕組み】</h2> <p>従来型の「Vault アクセス ポリシー」は、Key Vault個別のリソース設定として提供されていました。このモデルでは、Azure全体のIAM権限とKey Vault内部のデータプレーン（秘密情報・鍵・証明書の操作）権限が分離しており、大規模環境において権限管理の煩雑化や一元的な監査の難しさが課題となっていました。</p> <p>Azure RBACモデルへ統一することで、サブスクリプションやリソースグループ単位での細かいロール割り当て（例：「Key Vault Secrets User」など）が可能になり、Azure環境全体のセキュリティガバナンスと管理効率が大幅に向上します。</p> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> graph TD User["ユーザー / サービスプリンシパル"] -->|1. 認証| EntraID["Microsoft Entra ID"] User -->|2. アクセス要求| ARM["Azure Control / Data Plane"] ARM -->|3. RBAC評価| RBAC["Azure RBAC ロール割り当て"] RBAC -->|4. 認可完了| KeyVault["Azure Key Vault リソース"] </pre></div> <p>（上記図解の説明：ユーザーやシステムはMicrosoft Entra IDで認証後、Azure RBACのロール定義に基づいてKey Vault内の秘密情報や鍵へのデータ操作アクセスが一括制御されます。）</p> <h2 class="wp-block-heading">【コード・コマンド例】</h2> <p>Azure CLIを使用して、Azure RBAC認可が有効なKey Vaultを作成し、ロールを割り当てる手順例です。</p> <div class="codehilite"> <pre data-enlighter-language="generic"># 1. Azure RBACを有効化したKey Vaultの作成 az keyvault create \ --name "kv-prod-app-01" \ --resource-group "rg-prod-sec" \ --location "japaneast" \ --enable-rbac-authorization true # 2. サービスプリンシパルまたはユーザーに「Key Vault Secrets User」ロールを割り当て az role assignment create \ --role "Key Vault Secrets User" \ --assignee "sp-or-user-object-id" \ --scope "/subscriptions/{subscription-id}/resourceGroups/rg-prod-sec/providers/Microsoft.KeyVault/vaults/kv-prod-app-01" </pre> </div> <h2 class="wp-block-heading">【インパクトと今後の展望】</h2> <ul class="wp-block-list"> <li><p><strong>開発・運用への影響【事実】</strong>: 既存のTerraform、ARMテンプレート、BicepなどのIaCコードで <code>access_policies</code> ブロックを使用している場合、2027年2月までに定義をAzure RBAC（<code>azurerm_role_assignment</code> 等）に書き換える必要があります。</p></li> <li><p><strong>セキュリティガバナンスの向上【考察】</strong>: 権限の最小化（Principle of Least Privilege）をリソースグループ単位や個別秘密情報単位で柔軟に適用できるようになるため、企業のセキュリティ標準遵守が容易になると考えられます。</p></li> <li><p><strong>運用の自動化・一元化【考察】</strong>: Microsoft Entra Privileged Identity Management (PIM) との連携がスムーズになるため、ジャストインタイム（JIT）での鍵アクセス申請フローの構築が標準化していくと推測されます。</p></li> </ul> <h2 class="wp-block-heading">【まとめ】</h2> <p>読者が覚えておくべき3つのポイント：</p> <ol class="wp-block-list"> <li><p><strong>2027年2月28日に旧Vaultアクセスポリシーは廃止</strong>されるため、順次リファクタリングが必要。</p></li> <li><p><strong>新規Key VaultではAzure RBACモデルを必須選択</strong>とし、IAMでの権限一元管理へ移行する。</p></li> <li><p><strong>IaCテンプレートやCI/CDパイプラインの設定更新</strong>を早期計画に組み込むことが推奨される。</p></li> </ol> <hr/> <p><strong>参考リンク</strong></p> <ul class="wp-block-list"> <li><p><a href="https://azure.microsoft.com/en-us/updates/vault-access-policies-in-azure-key-vault-will-be-retired-on-28-february-2027/">Microsoft Learn: Vault access policies in Azure Key Vault will be retired on 28 February 2027</a></p></li> <li><p><a href="https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide">Microsoft Learn: Provide access to Key Vault keys, certificates, and secrets with an Azure role-based access control</a></p></li> </ul>

graph TD
    User["ユーザー / サービスプリンシパル"] -->|1. 認証| EntraID["Microsoft Entra ID"]
    User -->|2. アクセス要求| ARM["Azure Control / Data Plane"]
    ARM -->|3. RBAC評価| RBAC["Azure RBAC ロール割り当て"]
    RBAC -->|4. 認可完了| KeyVault["Azure Key Vault リソース"]

# 1. Azure RBACを有効化したKey Vaultの作成

az keyvault create \
  --name "kv-prod-app-01" \
  --resource-group "rg-prod-sec" \
  --location "japaneast" \
  --enable-rbac-authorization true

# 2. サービスプリンシパルまたはユーザーに「Key Vault Secrets User」ロールを割り当て

az role assignment create \
  --role "Key Vault Secrets User" \
  --assignee "sp-or-user-object-id" \
  --scope "/subscriptions/{subscription-id}/resourceGroups/rg-prod-sec/providers/Microsoft.KeyVault/vaults/kv-prod-app-01"