2026年6月20日に公開・更新された「Azure Firewall explicit proxy Migration Guide」は、Azure Firewall の明示的プロキシを使っている環境、特に PAC ファイルを使っている環境 が早めに確認すべき Notice です。結論から言うと、すぐ全利用者に障害が出る話ではありませんが、PAC ファイルのサイズ上限、プロキシポート構成、PAC の取得方法、Managed Identity と RBAC の準備に影響します。
Azure Firewall を通常の透過型プロキシ、つまり UDR で通信を Azure Firewall に向ける構成だけで使っている場合、影響は限定的です。一方で、Azure Firewall explicit proxy をプレビュー機能として使い、ブラウザーやアプリケーションにプロキシ設定を配布している環境では、GA に向けて設定棚卸しを始めるべきです。
Azure Firewall explicit proxy Migration Guide は何を知らせているのか
Azure Firewall は既定では透過型プロキシとして動作し、UDR を使って通信を Azure Firewall に転送します。これに対して explicit proxy は、ブラウザーやアプリケーション側に Azure Firewall のプライベート IP アドレスをプロキシとして設定し、HTTP/S 通信を Azure Firewall 経由にする方式です。Microsoft Learn では、explicit proxy は現在プレビューであり、PAC ファイルによるプロキシ自動構成にも対応すると説明されています。(Microsoft Learn)
今回の Migration Guide は、この explicit proxy の今後の変更点と、PAC ファイルベースの構成を使っている利用者向けの移行手順を整理したものです。公式ブログでは、対象者を「Azure Firewall explicit proxy をプレビューで利用している顧客」、特に PAC ファイルベースのプロキシ構成を使っている顧客としています。(TECHCOMMUNITY.MICROSOFT.COM)
重要なのは、これは単なる機能紹介ではなく、既存構成の見直しが必要になる可能性がある移行ガイド だという点です。分類が Notice であることからも、今日ただちに全環境が壊れる通知というより、GA や標準化に備えて事前確認を促す内容と考えるのが現実的です。
変更点の全体像
今回確認すべき変更点は、PAC ファイル、ポート構成、Firewall Policy、Managed Identity の4つに集約できます。公式ブログでは、PAC ファイルサイズの 256 KB 制限、HTTP/HTTPS を単一の HTTP プロキシポートで扱う対応、従来の dual-port 構成要件の削除、Firewall Policy 作成時にポータルから explicit proxy を有効化できる点、GA 後に PAC file SAS URL と Managed Identity が必要になる点が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
| 確認項目 | 変更・注意点 | 実務上の影響 |
|---|---|---|
| PAC ファイルサイズ | PAC ファイルは 256 KB までに制限 | 大量の FQDN や複雑な分岐を含む PAC は整理が必要 |
| プロキシポート | HTTP/HTTPS を単一の HTTP プロキシポートで扱う方向 | 旧来の HTTP/HTTPS 別ポート前提の設定を見直す |
| dual-port 構成 | explicit proxy v1 の dual-port 要件が削除 | 監視、NSG、クライアント設定、手順書の修正が必要 |
| ポータル設定 | Firewall Policy 作成時に explicit proxy を有効化可能 | 新規構築時の設定手順が変わる可能性あり |
| PAC 取得方式 | PAC file SAS URL と Managed Identity、適切なロール割り当てが必要 | Storage、ID、RBAC を含む移行作業が必要 |
| 自動化 | PowerShell、Azure CLI での設定も案内 | IaC や運用スクリプトの更新が必要 |
従来の「Azure Firewall 側に PAC を参照させればよい」という理解だけでは不十分になり、今後は PAC ファイルをどこに置くか、誰の権限で取得するか、どのロールを割り当てるか まで設計に含める必要があります。
影響を受ける対象者
最も影響が大きいのは、Azure Firewall explicit proxy をプレビューで利用し、PAC ファイルを使ってクライアントにプロキシ設定を配布している環境です。たとえば、Windows クライアント、VDI、Azure Arc 対象サーバー、業務アプリケーション、オンプレミスから Azure Firewall をプロキシとして使う構成などが該当します。
| 利用状況 | 影響度 | 確認すべきこと |
|---|---|---|
| explicit proxy と PAC ファイルを利用 | 高 | PAC サイズ、PAC URL、Managed Identity、RBAC、ポート設定 |
| explicit proxy を手動プロキシ設定で利用 | 中 | ポート構成、アプリケーションルール、ログ、将来の GA 要件 |
| UDR ベースの透過型プロキシのみ利用 | 低 | 今回の変更対象ではないが、将来 explicit proxy を使う予定があれば把握 |
| Azure Firewall を未利用 | 低 | 直接の影響なし |
| IaC で Firewall Policy を管理 | 中〜高 | explicit proxy 設定と identity 指定の追加・変更 |
特に注意したいのは、「ネットワークチームだけで完結しない変更」になる点です。PAC ファイルはクライアント管理、Storage はプラットフォーム管理、Managed Identity と RBAC は ID 管理、Firewall Policy はネットワーク管理にまたがります。部門ごとの担当が分かれている組織ほど、早めに作業範囲を切り分ける必要があります。
まず確認したい設定チェックリスト
PAC ファイルが 256 KB を超えていないか
最初に確認すべきなのは PAC ファイルのサイズです。今回の変更では PAC ファイルサイズが 256 KB に制限されるため、大量の条件分岐や個別ドメインを列挙している PAC は見直し対象になります。(TECHCOMMUNITY.MICROSOFT.COM)
よくある失敗は、例外サイトを1行ずつ増やし続けた結果、誰も全体を把握していない PAC ファイルになっているケースです。次のような観点で整理すると、サイズ削減と運用性の改善を同時に進められます。
| 見直しポイント | 改善例 |
|---|---|
| 同一ドメイン配下の個別 URL が多い | *.example.com やドメイン単位の条件に整理する |
| 古い例外設定が残っている | アクセスログを確認し、使われていない条件を削除する |
| DIRECT の例外が多すぎる | セキュリティ要件上、本当にプロキシを迂回してよいか再確認する |
| 拠点別・端末別の分岐が複雑 | 可能なら PAC を分割するか、配布対象を整理する |
| コメントが肥大化している | 運用メモは別ドキュメントに移す |
PAC ファイルは「動けばよい」ではなく、セキュリティ経路を決める設定ファイルです。変更前にバックアップを取り、差分管理できるリポジトリで管理することをおすすめします。
PAC file SAS URL と Managed Identity の準備ができているか
Migration Guide では、新しい PAC ファイル取得モデルとして、顧客管理の Azure Storage と Managed Identity 認証を使う手順が案内されています。手順では、Storage コンテナーに PAC ファイルをアップロードし、Managed Identity を作成し、Storage アカウント側で Storage Blob Data Contributor と Storage Blob Data Reader を割り当てる流れが示されています。また、Managed Identity 名には PacFileMSI- のプレフィックスを付ける注意点も記載されています。(TECHCOMMUNITY.MICROSOFT.COM)
ここで失敗しやすいのは、SAS URL だけを更新して Managed Identity を用意していない、または Managed Identity は作ったが Storage 側の IAM にロールを割り当てていないケースです。RBAC は作成直後に反映まで時間がかかる場合もあるため、本番切り替え直前ではなく、検証環境で早めに確認しておくべきです。
現行の Microsoft Learn では、PAC ファイルを使う場合に Storage コンテナーへ PAC をアップロードし、READ 権限を持つ SAS URL を構成する手順が説明されています。また、PAC ファイルを変更した場合は新しい SAS URL を生成し、Azure Firewall 側に再設定する必要があるとされています。(Microsoft Learn)
そのため、旧手順で「PAC ファイルだけ差し替えればよい」としていた運用は、今回の移行を機に見直してください。少なくとも、次の4点は確認が必要です。
- PAC ファイルの保存先 Storage アカウントとコンテナー
- PAC file SAS URL の取得・更新手順
PacFileMSI-プレフィックス付きの Managed Identity- Storage アカウントに対する必要なロール割り当て
HTTP/HTTPS のポート設計を見直す
今回の変更では、HTTP と HTTPS トラフィックを単一の HTTP プロキシポートで扱えるようになる点と、従来の dual-port 構成要件が削除される点が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
この変更は便利ですが、既存環境では注意が必要です。たとえば、古い手順書や構成管理では HTTP 用と HTTPS 用に別ポートを指定している場合があります。端末管理ツール、GPO、MDM、PAC ファイル、アプリケーション固有のプロキシ設定、NSG、監視ルールが別ポート前提になっていると、移行後に一部の通信だけ失敗することがあります。
確認すべき場所は次のとおりです。
| 確認場所 | 見るべき内容 |
|---|---|
| PAC ファイル | PROXY <IP>:<port> のポート指定 |
| ブラウザー設定 | HTTP/HTTPS で別ポートを指定していないか |
| OS・MDM・GPO | 端末配布用のプロキシ設定 |
| NSG・Firewall | クライアントから Azure Firewall の explicit proxy ポートへ到達できるか |
| 監視設定 | 旧ポートだけを監視・許可していないか |
| 運用手順書 | 障害時の確認コマンドが旧構成のままではないか |
アプリケーションルールで許可しているか
Azure Firewall explicit proxy では、通信許可にアプリケーションルールが必要です。Microsoft Learn でも、explicit proxy の通信を許可するには Firewall Policy にアプリケーションルールを作成する必要があり、ネットワークルールでは機能しないと明記されています。(Microsoft Learn)
ここは見落としやすいポイントです。TCP の疎通確認だけを見ると接続できているように見えても、HTTP/S の宛先 FQDN がアプリケーションルールに一致しなければ、最終的な通信は許可されません。
確認では、単にポートが開いているかではなく、次の観点まで見る必要があります。
- クライアントから Azure Firewall の explicit proxy ポートへ接続できるか
- 対象 FQDN がアプリケーションルールで許可されているか
- HTTPS 通信で SNI や FQDN ベースの評価が期待どおりか
- deny ログが出ていないか
- PAC の DIRECT 指定により Azure Firewall を迂回していないか
移行作業の進め方
本番環境でいきなり設定を変えるのではなく、棚卸し、検証、段階展開の順に進めるのが安全です。
| ステップ | 作業内容 | 完了条件 |
|---|---|---|
| 棚卸し | explicit proxy 有効化済みの Firewall Policy、PAC ファイル、配布先端末を洗い出す | 対象環境と担当者が分かっている |
| PAC 確認 | ファイルサイズ、DIRECT 条件、古い例外、ポート指定を確認する | 256 KB 未満で、不要な条件が整理されている |
| Storage 準備 | PAC 用の Storage コンテナーを用意する | PAC ファイルを配置できる |
| ID 準備 | PacFileMSI- 付き Managed Identity を作成する | Storage 側に必要ロールが割り当てられている |
| 検証 | 検証用 Firewall Policy で PAC URL と Managed Identity を設定する | クライアントから期待どおり通信できる |
| 自動化修正 | PowerShell、Azure CLI、IaC の設定を更新する | 再デプロイしても設定が戻らない |
| 本番展開 | 対象を限定して段階的に展開する | 主要アプリの通信確認が完了している |
| 監視 | Azure Firewall ログで許可・拒否を確認する | 予期しない deny や bypass がない |
疎通確認では、クライアント側から明示的にプロキシを指定してテストすると切り分けしやすくなります。
curl -x http://<azure-firewall-private-ip>:<proxy-port> https://www.microsoft.com/Log Analytics を使っている場合は、Azure Firewall のアプリケーションルールログも確認します。AZFWApplicationRule テーブルにはアプリケーションルールに一致したログが記録され、IsExplicitProxyRequest、Action、Fqdn、Protocol、Rule、SourceIp などの列を確認できます。(Microsoft Learn)
AZFWApplicationRule
| where TimeGenerated > ago(1h)
| where IsExplicitProxyRequest == true
| project TimeGenerated, Action, SourceIp, Fqdn, Protocol, DestinationPort, RuleCollection, Rule
| order by TimeGenerated desc移行直後は、許可ログだけでなく拒否ログも確認してください。特定の業務アプリだけ通信できない場合、PAC の条件、アプリケーションルール、プロキシポート、DNS 解決、端末側のキャッシュが原因になりがちです。
運用上の注意点
PAC ファイルのキャッシュを考慮する
PAC ファイルを更新しても、端末やブラウザー側で古い PAC がキャッシュされていることがあります。検証時は、端末の再起動、ブラウザー再起動、プロキシ設定の再読み込みなどを含めて確認してください。
本番展開では、PAC の切り替え時刻と端末反映タイミングにずれが出ます。全端末が一斉に新しい設定へ切り替わる前提で作業すると、障害の切り分けが難しくなります。
Storage 側のセキュリティ設定を厳しくしすぎない
PAC ファイルを置く Storage アカウントでは、アクセス制限やネットワーク制限を適用したくなります。ただし、Azure Firewall が PAC ファイルを取得できなければ、プロキシ自動構成が成立しません。
Storage のパブリックアクセス、Private Endpoint、Firewall 設定、Managed Identity の RBAC を組み合わせる場合は、検証環境で「Azure Firewall が PAC を取得できること」を必ず確認してください。セキュリティを強化するほど、権限不足や経路不備による失敗が起きやすくなります。
最小権限は検証してから調整する
公式手順では Storage Blob Data Contributor と Storage Blob Data Reader の割り当てが案内されています。(TECHCOMMUNITY.MICROSOFT.COM)
組織によっては「読み取りだけなら Reader でよいのでは」と考えるかもしれません。しかし、プレビューから GA に向かう移行期では仕様や実装が変わる可能性があります。まずは公式ガイドどおりに検証し、その後にセキュリティ基準に合わせて最小権限化できるかを確認するのが安全です。
IaC とポータル設定の差分を残さない
今回の Guide では、Azure portal、PowerShell、Azure CLI による構成が案内されています。(TECHCOMMUNITY.MICROSOFT.COM)
ポータルで一時的に修正したあと、Terraform、Bicep、ARM テンプレート、PowerShell スクリプトなどに反映しないままにすると、次回デプロイ時に設定が戻る可能性があります。特に explicit proxy 設定、PAC URL、Managed Identity の関連付けは、構成ドリフトの原因になりやすい項目です。
すぐにやるべきこと
今回の Azure Firewall explicit proxy Migration Guide で最初にやるべきことは、機能の理解よりも 自社環境が対象かどうかの判定 です。
まず、Azure Firewall Policy で explicit proxy を有効にしているか確認します。次に、PAC ファイルを使っている場合は、ファイルサイズ、保存先、URL、配布方法、Managed Identity、RBAC、ポート指定を確認します。最後に、検証環境で新しい PAC 取得方式を試し、Log Analytics の AZFWApplicationRule で通信が期待どおり処理されているか確認してください。
今回の変更は、Azure Firewall の管理画面だけを見て終わる話ではありません。PAC、Storage、Managed Identity、RBAC、クライアント配布、ログ監視まで含めて確認することで、GA 後の仕様変更にも落ち着いて対応できます。
コメント