Microsoft Entraの公式ドキュメント更新「[APIM] Update api-management-howto-use-managed-service-identity, api-management-key-vault-network」でまず確認すべき結論は、Key Vaultファイアウォールを有効にしているAzure API Management環境では、Key Vaultアクセスにユーザー割り当てマネージドIDを使えない点が明確化されたことです。該当する企業IT部門、セキュリティ管理者、コンプライアンス担当者は、APIMのID設定、Key Vaultのネットワーク制御、RBACまたはアクセスポリシー、NSGのアウトバウンド許可をセットで見直す必要があります。今回の更新は機能追加というより、既存構成の誤解を防ぐための仕様確認として重要です。(GitHub)
Microsoft Entraの公式ドキュメント更新「[APIM] Update api-management-howto-use-managed-service-identity, api-management-key-vault-network」で何が変わったか
今回確認対象となるMicrosoftDocs/azure-docsのコミットでは、includes/api-management-key-vault-network.mdの更新日が2026年4月30日に変更され、Key Vaultファイアウォール利用時の要件として「API Managementインスタンスのシステム割り当てマネージドIDを使用する必要がある。API Managementからのアクセスにユーザー割り当てIDは使用できない」という記述が追加・強調されています。差分自体は2行追加・2行削除の小さな更新ですが、運用上の意味は小さくありません。(GitHub)
ポイントは、Microsoft EntraのマネージドIDそのものが変わったというより、APIMからKey Vaultへアクセスする構成条件がより明確になったことです。Azure API Managementでは、Microsoft Entra IDによって生成されるマネージドIDを使い、Key VaultなどMicrosoft Entraで保護されたリソースへ安全にアクセスできます。これにより、アプリケーション側で資格情報を発行・保管・ローテーションする必要を減らせます。(Microsoft Learn)
今回の更新で最も重要な確認ポイント
今回の公式更新で見るべき点は、単に「システム割り当てIDを使う」と覚えることではありません。実務では、次の4点をセットで確認する必要があります。
| 確認項目 | 見るべき設定 | 問題になりやすい例 |
|---|---|---|
| APIMのマネージドID | system-assigned identityが有効か | ユーザー割り当てIDだけを付与している |
| Key Vaultファイアウォール | Trusted Microsoft Servicesの例外設定 | Key Vault側でネットワーク拒否される |
| Key Vault権限 | Azure RBACまたはアクセスポリシー | IDはあるが証明書・シークレットを取得できない |
| VNet/NSG | AzureKeyVaultとAzureActiveDirectoryへのアウトバウンド | ネットワーク制御でEntra認証やKey Vault到達が失敗する |
特に、APIMをVNetに配置している環境では、Key Vaultへのサービスエンドポイント有効化に加え、NSGでAzureKeyVaultとAzureActiveDirectoryのサービスタグ宛てアウトバウンド通信を許可する必要があります。Microsoft LearnのVNet構成リファレンスでも、APIMが正常に動作するには必要なポートやサービスタグをNSGで制御するよう説明されています。(GitHub)
システム割り当てIDとユーザー割り当てIDの違いを整理する
APIMでは、システム割り当てマネージドIDとユーザー割り当てマネージドIDの両方を利用できます。システム割り当てIDはAPIMサービスにひも付き、サービスを削除するとIDも削除されます。一方、ユーザー割り当てIDは独立したAzureリソースとして作成され、複数のサービスに割り当てられます。(Microsoft Learn)
この違いだけを見ると、ユーザー割り当てIDのほうが再利用しやすく、運用しやすいように見えます。しかし、今回の更新では、Key Vaultファイアウォールを有効にしたAPIMからのKey Vaultアクセスでは、ユーザー割り当てIDを使えないことが明確にされています。したがって、設計判断は次のように分けるのが現実的です。
| 利用シーン | 推奨される考え方 |
|---|---|
| Key Vaultファイアウォールを有効にしたAPIMの証明書取得 | システム割り当てIDを前提に設計する |
| Key Vaultファイアウォールを有効にした名前付き値の参照 | システム割り当てIDで権限を確認する |
| バックエンド認証でマネージドIDを使う | 利用ポリシー、トークン転送先、権限範囲を個別に確認する |
| 複数リソースでIDを再利用したい | Key Vaultファイアウォール要件に抵触しない範囲でユーザー割り当てIDを検討する |
つまり、「ユーザー割り当てIDは使えない」と一般化するのではなく、Key Vaultファイアウォールが有効なAPIMからKey Vaultへアクセスする場面では使えないと理解するのが正確です。
影響を受けやすい構成
今回の更新で特に確認すべきなのは、次のような環境です。
| 構成 | 影響度 | 確認すべきこと |
|---|---|---|
| APIMのカスタムドメイン証明書をKey Vaultから取得している | 高 | 証明書参照がシステム割り当てIDで動作しているか |
| APIMの名前付き値でKey Vaultシークレットを参照している | 高 | Key Vaultファイアウォール有効時にユーザー割り当てIDを使っていないか |
| Key Vaultで「選択したネットワーク」だけを許可している | 高 | Trusted Microsoft Services例外、VNet、IPルールの整合性 |
| APIMをVNet内にデプロイしている | 中〜高 | NSG、サービスエンドポイント、Entra ID向け通信 |
| 監査目的でマネージドIDを細かく分離している | 中 | ID分離方針とKey Vault要件が矛盾していないか |
Key Vaultのファイアウォールを有効にすると、「Allow trusted Microsoft services to bypass this firewall」を設定できます。ただし、Microsoftの説明では、このTrusted Servicesの一覧はすべてのAzureサービスを網羅するものではなく、サービスが一覧にある場合でもすべてのシナリオで許可されるとは限りません。(Microsoft Learn)
実務での確認手順
まずは、APIM、Key Vault、ネットワークの3層に分けて確認します。いきなり設定変更するのではなく、現在の依存関係を棚卸しすることが重要です。
APIMのID設定を確認する
Azure CLIを使う場合は、APIMサービスインスタンスの詳細を取得し、identityの内容を確認します。az apim showはAPIMサービスインスタンスの詳細表示に使えるコマンドです。(Microsoft Learn)
az apim show \
--resource-group <resource-group-name> \
--name <apim-name> \
--query identity確認する値は、主に次の3つです。
| 項目 | 意味 | 判断ポイント |
|---|---|---|
type | IDの種類 | SystemAssignedが含まれているか |
principalId | システム割り当てIDのオブジェクトID | Key Vault側の権限付与先と一致するか |
userAssignedIdentities | ユーザー割り当てID | Key Vaultファイアウォール環境で依存していないか |
APIMでは、システム割り当てIDとユーザー割り当てIDを同時に持つこともできます。そのため、「ユーザー割り当てIDが存在するか」だけでは判断できません。Key VaultアクセスにどちらのIDが使われているかを、証明書設定、名前付き値、ポリシー、権限付与先から確認してください。(Microsoft Learn)
Key Vaultのネットワーク設定を確認する
Key Vaultファイアウォールが有効な場合、APIMからのアクセスはID権限だけでは完結しません。ネットワーク側で許可されているかも確認が必要です。
az keyvault network-rule list \
--resource-group <resource-group-name> \
--name <key-vault-name>az keyvault network-rule listは、Key VaultまたはManaged HSMのネットワークACLからネットワークルールを一覧表示するためのコマンドです。(Microsoft Learn)
確認すべき設定は次のとおりです。
| 設定 | 確認内容 |
|---|---|
| ファイアウォールの有効化状態 | すべてのネットワーク許可か、選択したネットワークのみか |
| Trusted Microsoft Services例外 | APIMの制御プレーン操作で必要な例外が有効か |
| VNetルール | APIMサブネットが許可対象か |
| 一時的なクライアントIP許可 | 証明書やシークレット選択時に管理者端末がブロックされていないか |
| Private Endpoint利用 | パブリックアクセス無効化とAPIM側到達性が矛盾していないか |
Microsoft Learnでは、Key Vaultファイアウォールが有効な場合、Azure portalからKey Vaultを閲覧できても、クライアント端末が許可されたネットワーク内にないとキー、シークレット、証明書を一覧できない場合があると説明されています。管理者が「ポータルで見えているのに選択できない」と混乱しやすいポイントです。(Microsoft Learn)
Key Vaultの権限モデルを確認する
APIMからKey Vaultへアクセスするには、ネットワーク許可に加えて、Key Vault側で権限を付与する必要があります。Microsoft Learnでは、Key Vaultのアクセス構成で使用している権限モデルに応じて、アクセスポリシーまたはAzure RBACを構成するよう説明されています。Azure RBACの場合は、APIMのマネージドIDに対してKey Vault関連ロールを割り当てる流れです。(Microsoft Learn)
実務では、次のように確認します。
| 権限モデル | 確認ポイント |
|---|---|
| Key Vaultアクセスポリシー | APIMのシステム割り当てIDにGetやListなど必要な権限があるか |
| Azure RBAC | Key Vaultスコープで適切なロールが付与されているか |
| サブスクリプションやリソースグループ単位の広い権限 | 最小権限の原則に反していないか |
| 古いユーザー割り当てIDへの権限 | 不要になった権限が残っていないか |
セキュリティ監査では、「接続できるか」だけでなく、「不要なIDに権限が残っていないか」まで確認してください。特に本番環境では、過去の検証用ユーザー割り当てIDにKey Vault権限が残っているケースがあります。
March 2026以降のTrusted Servicesの扱いにも注意する
今回の更新とあわせて見落としたくないのが、APIMゲートウェイからAzureサービスへアクセスするTrusted Service Connectivityの扱いです。Microsoft Learnでは、2026年3月以降、APIMゲートウェイからAzureサービスへTrusted Microsoft Servicesのファイアウォールバイパス設定を使って接続する方法はサポートされなくなり、制御プレーン操作では引き続きTrusted Service Connectivityを使用できると説明されています。(Microsoft Learn)
このため、設計上は次のように分けて考える必要があります。
| 対象 | 考え方 |
|---|---|
| APIMの設定・証明書取得など制御プレーン寄りの操作 | 公式ドキュメントのKey Vault要件に沿って確認する |
| APIMゲートウェイからバックエンドやAzureサービスへ到達する処理 | Trusted Services前提ではなく、別のサポート済みネットワーク経路を検討する |
| ファイアウォールで保護されたKey Vault | ID、RBAC、ネットワーク例外、VNet構成を一体で確認する |
ここを混同すると、「Key VaultではTrusted Servicesを有効にしているから、APIMのすべての通信が問題なく通る」と誤解しがちです。今回の記事テーマはKey Vaultアクセスですが、APIM全体のネットワーク設計では、制御プレーンとゲートウェイ実行時通信を分けてレビューすることが重要です。
移行・修正が必要な場合の進め方
既存環境でユーザー割り当てIDを使ってKey Vaultにアクセスしている場合、すぐに本番設定を変更するのではなく、次の順序で移行します。
| 手順 | 作業 | 失敗しやすいポイント |
|---|---|---|
| 事前調査 | APIMが参照しているKey Vault証明書、名前付き値、ポリシーを洗い出す | カスタムドメイン証明書だけ見て、名前付き値を見落とす |
| ID有効化 | APIMのシステム割り当てIDを有効にする | 有効化後のprincipalIdをKey Vault側に反映し忘れる |
| 権限付与 | Key Vaultで必要最小限の権限を付ける | サブスクリプション全体に広い権限を付ける |
| ネットワーク確認 | Trusted Services、VNet、NSG、サービスエンドポイントを確認する | ID設定だけ直してネットワーク拒否で失敗する |
| 検証 | 証明書更新、名前付き値参照、APIM再起動影響を確認する | 手動参照は成功しても自動更新で失敗する |
| 権限整理 | 旧ユーザー割り当てIDの不要権限を削除する | 監査上の過剰権限が残る |
APIMでシステム割り当てIDを有効化する方法として、Microsoft LearnではAzure portal、PowerShell、ARMテンプレートの例が示されています。PowerShellでは既存インスタンスを取得したうえで、Set-AzApiManagementに-SystemAssignedIdentityを指定する例が掲載されています。(Microsoft Learn)
$apimService = Get-AzApiManagement -ResourceGroupName <resource-group-name> -Name <apim-name>
Set-AzApiManagement -InputObject $apimService -SystemAssignedIdentity変更後は、Key Vault側の権限付与先が新しいシステム割り当てIDのprincipalIdになっているか確認します。ユーザー割り当てIDに付与していた権限を残したままにすると、実害がなくても監査で「不要なアクセス権」と判断される可能性があります。
セキュリティ管理者とコンプライアンス担当者が見るべき監査観点
今回の更新は、構成担当者だけでなく、セキュリティ管理者やコンプライアンスチームにとっても重要です。理由は、Microsoft EntraのマネージドIDが「人間の資格情報を使わない安全な仕組み」である一方、割り当てる権限やポリシー編集権限を誤ると、間接的なアクセス経路になり得るためです。
Microsoft Learnでは、APIMポリシーを編集できるユーザーがauthentication-managed-identityポリシーを使って、サービスのマネージドIDとして認証する構成を変更できる点をセキュリティ上の注意として説明しています。対策として、マネージドIDへのロール割り当てを最小権限にし、APIM Contributorやポリシー編集権限を信頼できるユーザーに限定し、定期的に監査することが推奨されています。(Microsoft Learn)
監査チェックリストとしては、次を確認すると実務で使いやすくなります。
| 監査項目 | 確認内容 |
|---|---|
| APIMのID | システム割り当てIDが有効か、不要なユーザー割り当てIDが残っていないか |
| Key Vault権限 | APIMのシステム割り当てIDに必要最小限の権限だけがあるか |
| Key Vaultネットワーク | ファイアウォール、Trusted Services、VNet、Private Endpointの設計が文書化されているか |
| APIMポリシー編集者 | ポリシー編集権限を持つユーザー・グループが妥当か |
| ログと変更履歴 | Key Vault権限変更、APIMポリシー変更、ID変更が追跡可能か |
| 退役ID | 旧ユーザー割り当てIDや検証用IDの権限が削除されているか |
特にグローバル企業では、リージョン別、テナント別、サブスクリプション別にAPIMとKey Vaultの組み合わせが分散していることがあります。1つの環境だけを見て判断せず、テンプレート、Terraform、Bicep、ARM、Azure Policy、運用手順書まで横断的に確認してください。
よくある誤解と対処法
ユーザー割り当てIDは全面的に使えなくなったのか
全面的に使えなくなったわけではありません。今回の要点は、Key Vaultファイアウォールが有効な場合のAPIMからKey Vaultへのアクセスでは、ユーザー割り当てIDを使えないという点です。APIMの他の用途でユーザー割り当てIDを使う可能性はありますが、Key Vaultファイアウォールを組み合わせる設計では慎重に確認してください。(Microsoft Learn)
Key VaultでTrusted Microsoft Servicesを許可すれば十分か
十分とは限りません。Trusted ServicesはすべてのAzureサービスやすべてのシナリオを網羅するものではありません。さらに、APIMをVNetに配置している場合は、Key VaultサービスエンドポイントやNSGのアウトバウンド許可も確認が必要です。(Microsoft Learn)
ポータルでKey Vaultが見えるなら問題ないのか
問題ないとは限りません。Key Vaultのファイアウォール設定では、Azure portal上でKey Vault自体を表示できても、管理者端末が許可ネットワーク内にない場合、シークレットや証明書の一覧・選択ができないことがあります。証明書登録や更新作業では、一時的に管理者のクライアントIPを許可し、作業後に削除する運用が必要になる場合があります。(Microsoft Learn)
まず取るべき次のアクション
今回のMicrosoft Entra関連の公式ドキュメント更新は、差分としては小さいものの、APIMとKey Vaultを安全に連携させるうえで重要な確認ポイントです。特に、Key Vaultファイアウォールを有効にしている環境では、APIMのKey Vaultアクセスがシステム割り当てマネージドIDで構成されているかを優先して確認してください。
最初に行うべきことは、次の3つです。
- APIMインスタンスの
identityを確認し、システム割り当てIDが有効かを見る。 - Key Vaultのネットワーク設定と権限付与先を確認し、ユーザー割り当てID依存がないか洗い出す。
- VNet、NSG、Trusted Services、Key Vault権限を変更管理の対象として記録する。
この確認を終えれば、単なるドキュメント更新の把握にとどまらず、証明書更新失敗、Key Vault接続エラー、過剰権限、監査指摘といった実務上のリスクを先回りして減らせます。
コメント