2026.07.02 2026.07.03

【SSE】[Zscaler] [ZIA] [設計] [個別] [インライン] Firewall Control

buffoon

はじめに

ZIAのインラインプロセスにおいて、Firewall Controlが最初に実行されます。

Firewall Controlは、IPアドレス・ポート・プロトコルを中心としたL3/L4制御に加え、ユーザ・グループ・ロケーション・ネットワークアプリケーションなどの条件も利用できる制御機能です。

しかし後続のSSL InspectionやCloud App Control、URL Filteringなどのセキュリティ機能へ通信を渡すかどうかを判断する、インラインプロセス全体の入口となる重要な機能でもあります。

Firewall Controlとは

Firewall Controlでは、

IPアドレス
ポート番号
プロトコル
ユーザ
グループ
ロケーション

などのクライテリアを利用して通信を評価します。

インラインプロセスの最初に実行されるため、ここで拒否された通信はSSL Inspection以降の処理は実施されません。

Tunnel2.0では非Web通信も対象となる

Firewall Controlが特に重要になるのは、

Z-Tunnel2.0
GREトンネル
IPsecトンネル

などを利用している構成です。

これらの転送方式では、HTTPやHTTPSだけではなく、DNSやSMTPなどの非Web通信もFirewall Controlによる制御対象となります。

一方で、SSL Inspection以降はWeb通信を中心としたセキュリティ機能が多く、一部機能のみがメールなどの非Web通信へ対応しています。

そのため、非Web通信に対するセキュリティ制御の中心となるのがFirewall Controlです。

Firewall Controlで利用できる主なクライテリア

Firewall Controlでは様々な条件を組み合わせてポリシーを作成できます。

代表的なものとして、以下があります。上位ライセンスを買わないと設定が不可能なクライテリアも存在します。

送信元IPアドレス
宛先IPアドレス
ポート番号
プロトコル（TCP / UDP / ICMPなど）
ユーザ
グループ
ロケーション

実際の設計では、これらを組み合わせながら、どの通信を後続処理へ渡すのかを設計していきます。

なお、送信元IPアドレスを利用した制御については、LocationやSub Locationの設計とも密接に関係するため、別記事として詳しく紹介します。

初期状態で用意されている推奨ルール

Firewall Controlには、初期状態からいくつかの推奨ルール（Predefined Firewall Filtering Rules）が用意されています。

Zscaler Proxy Traffic
Office 365 One Click Rule
Block Malicious IPs and Domains
Block All IPv6

これらは多くの環境で利用される代表的な通信を考慮したテンプレートとなっており、設計時のベースラインとして利用できます。

Zscaler Proxy Traffic

Zscaler Proxy Trafficはデフォルトで最上位に配置されている非常に重要なシステムルールです。

HTTP CONNECTなどのプロキシトラフィックが、L3/L4のファイアウォールエンジンで誤って遮断されずに、ZscalerのWebプロキシエンジンへ安全に引き渡されるように自動で許可（Allow）する役割を持っています。

Office 365 One Click Rule

Zscalerの管理画面でワンクリック設定を有効にすることで自動生成される、Microsoft 365の通信を最適化・高速化するための専用ルールです。

Microsoftが公式に推奨する「ネットワークセキュリティ機器は、M365の通信を中身の検査（SSL復号）をせずに透過的に通すべき」というガイドラインに準拠するために用意されており、Firewall controlだけでなく他のセキュリティ機能においても、一貫して用意されているでZscaler定義済みのルールです。

設計で重要なのは「通す通信」を決めること

Firewall Controlという名前から、「何をブロックするか」に注目しがちですが、

実際の設計では、何を後続のインラインプロセスへ渡すかを考えることの方が重要です。

例えば、Webアクセスを実現するためには最低限、HTTP、HTTPS を許可しなければ、後続のSSL InspectionやURL Filteringまで通信が到達できません。

また、SMTP通信に対してDLPを利用する構成であれば、SMTPも許可対象となります。

一方で、Zscalerを介したDNSを許可するとしても、すべてのDNSサーバを許可する必要はありません。

例えば、Zscaler DNSのみを許可し、企業で管理していないDNSサーバへの通信を拒否するといった設計も一般的です。

Firewall Controlは、単純な通信許可ではなく、企業が利用を認める通信だけを後続のセキュリティ機能へ渡す

という考え方が重要になります。

QUIC（HTTP/3）の扱い

設計時に見落としやすいのが、QUIC（HTTP/3）の扱いです。

QUICはUDPベースで動作するHTTP/3の通信方式であり、何も設定しない場合、ブラウザはHTTPS通信よりも優先してQUICを利用することがあります。

しかし、UDP通信も扱える「Z-Tunnel2.0」「GREトンネル」「IPsecトンネル」を利用する環境で、ZscalerはFire wall controlで QUICをBlockで拒否することが推奨されています。

その理由について解説します。

Zscalerによる「中身の検査」ができなくなる

QUICは最初から暗号化されている：従来のWeb通信（HTTPS）は、TCPという通り道を作った後に暗号化（TLS）のやり取りを始めるため、Zscalerは「これから暗号化通信が始まるな」と検知して、割り込んで中身を復号・スキャン（SSLインスペクション）できます。
QUICはUDPベース：QUICはUDP（通常ポート443）を使い、通信の接続確立（ハンドシェイク）と暗号化を同時に行います。さらに、パケットのヘッダー部分まで一部暗号化されているため、Zscalerがインラインで通信に割り込んで復号することが技術的に非常に困難です。
結果：QUICを通してしまうと、後続のSSL Inspectionが効かないのでZscalerのWebプロキシ機能で一切スキャンできない「セキュリティの盲点」が生まれてしまいます。

ブラウザの「TCPフォールバック」という性質を利用する

「QUICをブロックしたら、YouTubeやGoogle、Microsoft 365などのWebサイトに繋がらなくなるのでは？」という心配が生じますが、その心配はありません。

Google ChromeやEdgeなどの主要ブラウザは、「QUICで通信を試みて、遮断されたら即座に従来のTCP（HTTPS）に切り替えて接続し直す」という自動フォールバック機能を備えています。
そのため、Firewall controlでQUIC（UDP/443）をブロックしても、ユーザーは一切気づくことなく、自動的に従来のTCP/443（HTTPS）で通信が行われます。
TCPに切り替わってくれれば、Zscalerはいつも通りSSLインスペクションを適用し、中身を可視化して保護できるようになります。