Azure Firewall Explicit Proxyを実機検証してわかった、ドキュメントに書いていない挙動まとめ

Last updated at 2026-10-06Posted at 2026-10-06

はじめに

2026年8月、Azure更新情報にて Azure Firewall の Explicit Proxy 機能が GA(一般提供開始)されました。

Azure Firewallは既定では「透過型プロキシ」として動作します。UDR(ユーザー定義ルート)でトラフィックを強制的にAzure Firewallへ誘導する方式です。Explicit Proxyでは、クライアント側のプロキシ設定(手動設定またはPACファイル)でAzure FirewallのプライベートIPを明示的に指定する、従来とは異なる方式が使えるようになりました。

本記事では、Terraformを使ってExplicit Proxyの検証環境を実際に構築し、公式ドキュメントの記載内容を実機で確認した結果をまとめます。特に、ドキュメントだけでは分からなかった実際の挙動・落とし穴を中心に紹介します。

本記事の内容は2026年9月時点のAzure環境で検証した結果に基づきます。最新の仕様は公式ドキュメントをご確認ください。

前提条件

検証環境はAzure Firewall Standard SKU(Explicit ProxyはStandard/Premiumのみ対応、Basic非対応)
検証環境はTerraformで構築(IaC)。デプロイの都合上、PACファイルの取り扱いに関する重大な制約が判明したため2段階デプロイを採用(後述)
検証環境は、UDR(0.0.0.0/0 → None)とNSG(Azure Firewall宛のみ許可)により、Explicit Proxy経由以外での直接インターネットアクセスができないことを前提としています。これらはAzureの標準的なネットワーク制御機能であり、Explicit Proxy固有の検証対象ではないため、本記事の「検証項目と結果」には含めていません

対象読者

Azure Firewallの運用・設計に携わるAzure技術者
Explicit Proxy機能の導入を検討している方
プロキシ経由のアウトバウンド通信制御を設計する方

Azure Firewall Explicit Proxyとは

透過型プロキシとの違い

	透過型プロキシ(従来方式)	Explicit Proxy(新方式)
誘導方法	UDRでトラフィックを強制的にAzure Firewallへ誘導	クライアントのプロキシ設定(手動 or PACファイル)で明示的に送信
クライアント側の設定	不要	必要(プロキシアドレス:ポートを指定)
UDRの要否	必須	不要(VNet内アドレス宛の通信として成立)
ポート運用	-	HTTP/HTTPS共通ポート、または個別ポートを選択可能

Explicit Proxyでは、クライアント(ブラウザ等)側でAzure FirewallのプライベートIPを明示的にプロキシ指定します。通信はVNet内アドレス宛の通常のTCP接続として成立するため、UDRで経路を強制する必要がありません。

PACファイルの役割

PAC(Proxy Auto-Configuration)ファイルは、FindProxyForURL(url, host) というJavaScript関数でプロキシの振り分けルールを定義するファイルです。Explicit ProxyではAzure FirewallがStorageアカウント上のPACファイルをホストし、クライアントへ配信できます。これにより、クライアント側で手動プロキシ設定を行わなくても、PACファイル URLを1つ指定するだけで集中管理が可能になります。

ただし重要な注意点として、PACファイルはAzureが自動生成するものではありません。利用者自身がPACファイルの中身を作成し、Storageアカウントへアップロードする必要があります。

一般的なプロキシサーバーとの違い

一般的なプロキシサーバー(Squid等)と比較すると、Explicit Proxyは以下の点が特徴的です。

プロキシサーバー自体の構築・パッチ適用・スケーリングの運用が不要(マネージドサービス)
アプリケーションルール(FQDNフィルタリング)や脅威インテリジェンスなど、Azure Firewallの既存機能をそのまま活用できる
一方で、PACファイルのホスティングにはマネージドID + Storageアカウントという追加リソースが必要になる
Squid等の一般的なプロキシサーバーが備えるようなコンテンツキャッシュ機能は持たないと考えられる(公式ドキュメントに明記はないが、機能説明上そうした記載も見当たらない)。Explicit Proxyはあくまで通信の中継・フィルタリングを行うものであり、レスポンス内容のキャッシュによる帯域削減・応答高速化は期待できない
Squidが備えるようなBasic/NTLM/Kerberos等のクライアント単位の認証プロキシ機能も持たないとみられる(同様に公式ドキュメントに明記はない)。制御はソースIP・FQDNベースのネットワークルール単位(似た名称の別製品Microsoft Entra Global Secure Access「Explicit Proxy」と混同注意)

SKU制約

Explicit Proxyは Standard / Premium SKU でのみ利用可能で、Basic SKUは非対応です。また、設定は Firewallポリシー単位 で行い、Azure Firewallリソース単体には設定できません。

検証環境

構成図

Explicit Proxyの設定はAzure Firewallリソース単体ではなく、Firewallポリシー側で行う点に注意(上図の通り、Policy → Azure Firewall という適用関係)
Azure Firewallの診断設定(Diagnostic Settings)により、AZFWApplicationRule等のログがLog Analytics Workspaceへ出力される(検証項目5で使用)
VMサブネットは defaultOutboundAccess を無効化し、Explicit Proxy経由以外での暗黙的なインターネットアクセスを排除
UDR(0.0.0.0/0 → None)とNSG(Azure Firewall宛のみ許可)で、プロキシ未設定時の直接アクセスを遮断(前提条件)
Log Analytics WorkspaceにAzure Firewall診断ログ・Storageアカウント診断ログを集約し、可観測性を検証

Terraformで構築したリソース一覧

カテゴリ	リソース	主な設定
ネットワーク	VNet / サブネット	`AzureFirewallSubnet` + VM用サブネット
ネットワーク	UDR	`0.0.0.0/0 → Next hop なし`
ネットワーク	NSG	Azure Firewall Private IP:Proxyポート/PACファイル用ポート宛のみ許可
Firewall	Azure Firewall + Policy	Standard SKU、Explicit Proxy有効(単一ポート運用)
Firewall	Public IP	Standard SKU稼働に必須
PAC配布	Storage Account + Container	Public網有効/アカウントキー認証無効/RBACのみ許可
PAC配布	Managed Identity	`PacFileMSI-` プレフィックス、Azure Firewall Policyに紐付け
VM	Windows Server 2025 VM	Gen2 / smalldisk / Trusted Launch、パブリックIPなし
接続	Bastion (Developer)	踏み台/専用パブリックIP不要
監視	Log Analytics Workspace	Azure Firewall診断ログ + Storageアカウント診断ログを収集

使用したTerraform関連のバージョンは次のとおりです。

項目	バージョン
Terraform	v1.15.9
azurermプロバイダー	5.5.0

記事が長くなりすぎるため、Terraformコード全体はここでは記載しませんが、Explicit Proxyの設定自体はazurerm_firewall_policyリソースのexplicit_proxyブロックで行うため、その部分のみ抜粋します。

resource "azurerm_firewall_policy" "main" {
  ...

  explicit_proxy {
    enabled         = true
    http_port       = <explicit_proxy_http_port>
    enable_pac_file = true
    pac_file_port   = <pac_file_port>
    pac_file        = <blob_storage_container_pac_file_url>
  }
}

書式の詳細はazurerm_firewall_policy | Terraform Registryを参照してください。

つまずいたポイント: PACファイル未存在時は設定自体が失敗する

検証環境をTerraformで構築する過程で、次の挙動に遭遇しました。

PACファイルをStorageアカウントへアップロードする前にExplicit ProxyのPACファイル設定(enable_pac_file + pac_file + マネージドID)を有効化しようとしたところ、InternalServerError で失敗しました。その後、PACファイルをアップロード済みの状態で同じ設定を行うと成功しました。この挙動から、Azure FirewallはマネージドID経由で指定URLのPACファイルへアクセスできるかを内部的に確認していると考えられます。

このエラーメッセージからは原因が全く分からず、Azure CLI・Azure Portalの両方で同一の失敗を繰り返し再現させることで特定しました。そのため、Terraformのコードは以下の2段階デプロイ構成にしています。

第1段階: terraform apply(is_deploy_firewall=false、既定値)で、VNet・NSG・UDR・Storageアカウント・マネージドID・VM・Bastion等の基盤リソースのみを作成
手動作業: 利用者自身がPACファイルを作成し、az storage blob upload --auth-mode login でStorageアカウントのコンテナへアップロード
第2段階: terraform apply -var="is_deploy_firewall=true" で、Firewallポリシー(Explicit Proxy設定込み)・Azure Firewall本体・診断設定を作成

この順序を守ることで、誰でもInternalServerErrorを踏まずに環境を再現できます。

検証項目と結果

項目1: 基本疎通

手順

プロキシ未設定の状態で任意のWebサイト(https://www.microsoft.com等)へアクセス
Windowsの設定でプロキシ手動設定(アドレス: Azure Firewall Private IP、ポート: 8080)を行い、許可FQDNへアクセス

結果

手順1(プロキシ未設定): サブネットのdefaultOutboundAccess無効化とUDR(0.0.0.0/0 → None)により、既定のインターネット向けルート自体が存在しません。実際にブラウザでアクセスを試みたところ接続に失敗し、Azure Firewallの透過型プロキシへの暗黙的なフォールバックも発生していないことを確認できました。
手順2(プロキシ設定後): 手動プロキシ設定時、www.microsoft.com / learn.microsoft.com へのアクセスが成功し、Azure Firewallログでも以下のように記録されました。
```
Action_s = Allow
IsExplicitProxyRequest_b = True
```

項目2: PACファイル配布

手順

Windowsの設定 →「ネットワークとインターネット」→「プロキシ」→「セットアップスクリプトを使う」からPACファイル URLを指定します。

結果

PACファイル URLはファイル名まで含めて指定します。

http://10.0.0.4:8081/proxy.pac

正しいURLを設定し手動プロキシをOffにした状態で、両FQDNへのアクセスが成功しました。Azure Firewallログでも Action_s = Allow / IsExplicitProxyRequest_b = True として記録されており、PACファイルによる自動プロキシ構成が正しく機能していることが分かります。

項目3: マネージドIDの権限境界

Explicit ProxyのPACファイル配布用マネージドIDには、Microsoft公式ドキュメント上 Storage Blob Data Contributor と Storage Blob Data Reader の両方が必須とされています。読み取り専用の用途なのに、なぜ書き込み権限を含むStorage Blob Data Contributorまで必要なのか疑問に思い、実際に検証しました。

手順

Storage Blob Data Contributor ロールを一時的に削除し、Storage Blob Data Reader のみの状態にする
Explicit ProxyのPAC設定を無効化→再有効化し、失敗するか確認する

結果

Storage Blob Data Readerのみの状態でExplicit ProxyのPAC設定を再有効化しようとしたところ、InternalServerError で失敗しました。PACファイルが存在しない場合と全く同じエラーパターンです。これにより、本検証では、Storage Blob Data Contributorが必要であることを実機で確認し、最小権限に関する疑問は解消しました。

さらに、この過程で副次的な発見がありました。

Storage Blob Data Contributorロールを復元した直後に同じ再有効化を試みたところ、ロール自体は存在するにもかかわらず再度InternalServerErrorで失敗しました。今回は75秒待って再実行したところ成功しました。

ロール割り当て(RBAC)の反映には数十秒〜1分程度のタイムラグがあり、付与直後にExplicit Proxy設定を有効化しようとすると、ロールが実在していても失敗しうるということです。実運用でロールを新規付与する場合は、反映を待ってからPAC設定を有効化することを推奨します。

さらにもう一つ、Storageアカウントの詳細な診断ログ(StorageBlobLogs)を調べたところ興味深い挙動が見つかりました。Storage Blob Data Contributorが未割当(Readerのみ)の状態でも、AuthenticationType: TrustedAccessによるコンテナ/サービスレベルのメタデータ確認(GetContainerProperties等)は成功していました。一方、PACファイル本体の読み取り(GetBlob、データプレーンの操作)は記録されておらず、Contributorロール復旧後に初めてAuthenticationType: OAuthのGetBlobが記録されました。つまり、Explicit Proxyのバックエンドはコンテナの存在確認等の予備チェックと、PACファイル本体の読み取りとで異なる認証経路を使い分けている可能性があり、InternalServerErrorはStorageアカウントへの失敗リクエストとしてはログに残らず、Azure Firewall側の内部検証(認可レベル)で早期に失敗しているとみられます。

項目4: アプリケーションルール

手順

Azure Firewall Policyのアプリケーションルールで、許可するFQDNを絞って定義しています。この定義に対して、次の2つを確認します。

許可FQDN(www.microsoft.com等)へアクセスする
許可FQDN以外(example.com)へアクセスする

結果

許可FQDNは成功、許可外FQDNは ERR_TUNNEL_CONNECTION_FAILED で明確にブロックされました。ログでも Action_s = Deny(ActionReason_s: No rule matched. Proceeding with default action)として記録されており、期待通りの動作を確認しました。

項目5: ログ・可観測性

Azure Firewallの構造化ログ(AZFWApplicationRule)には IsExplicitProxyRequest というカラムがあり、Proxy経由のリクエストかどうかを直接判定できます。

AzureDiagnostics
| where Category == "AZFWApplicationRule"
| where IsExplicitProxyRequest_b == true
| project TimeGenerated, Fqdn_s, Action_s, IsExplicitProxyRequest_b, SourceIP, TargetUrl_s
| order by TimeGenerated desc

結果

Proxy経由のリクエストが IsExplicitProxyRequest_b = True として明確に記録されることを確認しました。

ここでも一つ、実装上の落とし穴を発見しました。

azurerm_monitor_diagnostic_setting は log_analytics_destination_type を明示的に "Dedicated" にしない限り、既定値(レガシーの AzureDiagnostics テーブル形式)で送信されます。

本検証環境ではこの設定を入れ忘れたため、意図していた構造化ログ専用テーブル(AZFWApplicationRule)ではなく、レガシーの AzureDiagnostics テーブルに、Category == "AZFWApplicationRule" として、列名も IsExplicitProxyRequest_b のように _b/_s サフィックス付きで記録されていました(上記のKQLクエリはこの実挙動に合わせています)。構造化ログを使いたい場合は、log_analytics_destination_type = "Dedicated" の明示指定が必要です。

項目6: Azure Firewallからのソースアクセス確認

Azure Firewallのバックエンドサービスが、実際にどのような認証方式・ソースIPでPACファイルを取得しているかを確認しました。

StorageBlobLogs
| where ObjectKey has "proxy.pac"
| project TimeGenerated, OperationName, CallerIpAddress, AuthenticationType, RequesterObjectId
| order by TimeGenerated desc

結果

GetBlob ログが以下のように記録されていました(項目3でPAC設定を無効化→再有効化した際の再取得)。

時刻(UTC)	CallerIpAddress	AuthenticationType
2026-09-17T14:41:09	10.1.1.7	OAuth

別日に実施した際には、以下のように約35分〜1時間間隔で複数回のGetBlobが観測されており、後述の通り定期的な再取得が行われていることも確認しています。

時刻(UTC)	CallerIpAddress	AuthenticationType
2026-09-16T01:40:51	10.1.1.10	OAuth
2026-09-16T02:15:43	10.1.1.5	OAuth
2026-09-16T03:12:00	10.1.1.8	OAuth
2026-09-16T05:11:28	10.1.1.5	OAuth

ここから2つの重要な事実が分かりました。

1. PACファイルは無期限キャッシュされていない可能性

GetBlob は約35分〜1時間間隔で複数回発生していました。本検証環境では、Azure FirewallがPACファイルを永続的にキャッシュするのではなく、定期的に再取得(リフレッシュ)しているように見受けられました。ただし公式ドキュメントにキャッシュ間隔の明記はなく、観測できたのは限られた時間・回数のログのみのため、常にこの間隔で再取得される保証があるとは言い切れない点にご留意ください。

2. ソースIPによるアクセス制限は難しいと考えられる

CallerIpAddress(10.1.1.x系)は、本検証環境で観測した限りではパブリックIPでも、顧客VNet(10.0.0.0/16)の範囲内でもありませんでした。Azure Firewallバックエンドサービス専用の、Microsoft管理下と見られる内部ネットワークセグメントからのアクセスと考えられます。

Storageアカウントのネットワークファイアウォールは、

IPアドレス範囲ルール: パブリックIPしか登録できない
VNetルール/プライベートエンドポイント: 顧客VNet発信のトラフィックのみが対象

という制約があるため、今回観測されたようなソースIPに対しては、ネットワークレベルでの許可・制限を行うことは難しいと考えられます。本検証で確認できたこととしては、Explicit ProxyのPACファイル配布アーキテクチャにおいて、ネットワーク境界(IP/VNet)よりも Microsoft Entra ID/RBAC(特定マネージドIDへのロール割り当て)がアクセス制御において比較的重要な役割を果たしている、という点です(ソースIPの範囲が今後変更・拡大される可能性もあり、あくまで今回の観測に基づくものです)。

この制約のため、本検証で確認した構成では、PACファイルを配布するStorageアカウントは publicNetworkAccess を有効にする必要がありました。その代わりに、アカウントキー/SAS認証の無効化やTLS最小バージョンの引き上げなど、RBAC以外の経路を塞ぐ追加のハードニングを行うことを推奨します。

publicNetworkAccessの有効化自体が許容できない場合は、代替案として次のいずれかを検討します。

Azure FirewallのPACファイル配布機能を使わず、クライアント側の手動プロキシ設定に統一する
PACファイル配布専用に、プライベートエンドポイントのみで構成した別のStorageアカウントを用意し、運用を分離する

まとめ

Explicit Proxyは、UDR不要でクライアント側の明示設定/PACファイルにより柔軟なプロキシ運用を実現する新機能
PACファイル配布はマネージドID経由のRBACで保護されており、ネットワーク境界ではなくID境界での制御が前提の設計
公式ドキュメントだけでは分からない、以下の実運用上の注意点を実機検証で確認できた
- PACファイルが存在しない状態でExplicit Proxy設定を有効化すると InternalServerError で失敗する
- RBACロールの反映には数十秒〜1分のタイムラグがあり、付与直後の設定変更は失敗しうる
- Terraformの診断設定は明示しない限りレガシーログ形式で送信される
- 本検証環境では、PACファイルは定期的に再取得されており、無期限キャッシュされていない可能性が見受けられた
- 本検証環境では、PACファイル配布のソースIPはパブリックIPでも顧客VNet内でもなく、IPベースのアクセス制限は難しいと考えられた

新機能ゆえにドキュメントやコミュニティの知見がまだ少ない分野ですが、実機で丁寧に検証することで、設計・運用に活かせる具体的な知見が得られました。この記事がExplicit Proxyの導入を検討する方の参考になれば幸いです。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up