【SSE】[Zscaler] [ZIA] [設計] [全体] トラフィックフロー解説

はじめに

PSEでは、複数のセキュリティ機能が決められた順番で実行され、通信を許可するか、拒否するかが判断されます。

本記事では、その全体像を整理するために、ZIAのインラインプロセス（トラフィックフロー）を解説します。

なお、この後の説明は各セキュリティ制御で主にどういうクライテリア（基準）を設定し、許可・拒否ができるかについて概要レベルで説明します。

さらに詳細な情報や設定が推奨されるべき内容については各機能ごとに説明していきますのでここでは割愛とさせていただきます。

Firewall Control

最初に実行されるのがFirewall Controlです。

ここでは、IPアドレス / ポート番号 / プロトコルなどをクライテリアに通信を評価します。

• 拒否された場合、その時点で通信は終了し、後続の処理は実行されません。
• 許可された場合、後続のSSL Inspectionの処理へ移ります。

Firewall controlはTunnel2.0やGRE/IPSECトンネルを経由した通信であれば 非WEB通信も対象とすることができます。

後続の処理はWeb通信を中心とした制御が多く、一部機能はメールやその他のプロトコルにも対応しています。

SSL Inspection

Firewallを通過した通信はSSL Inspectionへ進みます。

ここではSSL/TLS通信を復号するかどうか、および証明書エラー時の動作を判断します。

SSL Inspectionには大きく3つの動作があり、基本的にはインスペクションするか、しないかというアクションだけで後続であるCloud App Controlの処理へ移ります。

• Not Inspect（Evaluate other policy）
• Not Inspect（Bypass other policy）
• Inspect

この違いは設計で非常に重要になります。例えば、

Not Inspect（Evaluate other policy）では暗号化部分は復号しませんが、SNI（FQDN）など取得できる情報を利用して後続のポリシー評価を継続します。

Not Inspect（Bypass other policy）を選択すると、SSL Inspection以降の処理を実施せず、そのまま通信を許可します。

またInspectとした場合でも、Inspectした結果 利用されている証明書が公的に登録されていないものであれば、その場で通信拒否し、後続に回さない設計も可能です。

この違いについては別記事で詳しく解説します。

Cloud App Control

Cloud App Controlでは、Web経由のクラウドアプリ（SaaS）利用を可視化し、閲覧は許可するがファイル送信は禁止するといったアクション単位や、企業公式テナントか個人アカウントかといったテナント単位で細かく制御が可能です。

Cloud App Controlでは、

• 拒否された場合、その時点で通信は終了し、後続の処理は実行されません。

• 許可された場合、後続のURL FilteringをスキップしてFile Type Controlへ処理がスキップされます。

• 特段、Cloud App Controlで制御指示がなかったアプリケーションは、後続のURL Filiteringへ処理が移ります。

URL Filtering

URL Filteringでは、URLカテゴリやカスタムURLリストを利用してアクセスを制御します。

ここでは、URLカテゴリやURLに対して以下のアクションを選択します。

• 許可
• 拒否
• 注意

ルールの最後にデフォルト許可のポリシーが配置されるため、指定をしない場合は許可されます。

• 拒否された場合、その時点で通信は終了し、後続の処理は実行されません。

• 許可された場合は、後続のFile Type Controlへ処理が移ります。

• 注意の場合、基本的に許可と同様の動きをしますが、ユーザ画面で注意警告文が表示されます。ただし、注意警告文が出たことにより、通信が不成立になるものについては拒否と同じ動作となります。

File Type Control

File Type Controlでは、MIME Typeや拡張子などを利用してファイル種別を判定します。

Zscalerが検知可能な拡張子のファイルについては、ダウンロードとアップロードの両方が制御可能です。

またURL Filteringでも利用されるURLカテゴリ単位やCloud App単位で制御も可能なため、通信の宛先ベースで内部情報のアップロードや不審なファイルのダウンロードを止めることができます。

• 拒否された場合、その時点で通信は終了し、後続の処理は実行されません。

• 許可された場合は、後続のDLPへ処理が移ります。

• 特段、File Type Controlで制御指示がなかった通信は、後続のDLPへ処理が移ります。

Data Loss Prevention（DLP）

DLPは社外への機密情報や個人情報の漏洩を防ぐ機能です。

Web送信やメール（一部の非Web通信についても、DLPの検査対象となります）、生成AI等への入力データをインラインで検査し、マイナンバーやクレジットカード番号などの重要データが含まれる場合にブロックや警告を行います。

File Type Controlと同様URLカテゴリやCloud App等、宛先ベースで処理を実行することも可能です。

• 拒否された場合、その時点で通信は終了し、後続の処理は実行されません。

• 許可された場合は、インターネット側へ通信が転送されます。

• 注意の場合、基本的に許可と同様の動きをしますが、ユーザ画面で注意警告文が表示されます。ただし、注意警告文が出たことにより、通信が不成立になるものについては拒否と同じ動作となります。

• 特段、DLPで制御指示がなかった通信は、インターネット側へ通信が転送されます。

Malware Protection / Sandbox

Malware ProtectionとSandboxは、図では一つのブロックとして表現しています。

実際には、処理の途中で対象となった通信やファイルに対して実行される検査エンジンです。

そのため、FirewallやURL Filteringのように一直線で並ぶ処理というより、

• 必要に応じて実行される検査エンジンとして考える方が実態に近いです。

詳細な処理順序は公式ドキュメントにも記載されています。詳細が気になる方は確認いただけると幸いです。（複数回処理されていることがわかります。）

脅威が検知された場合は通信を即座にブロックします。

Bypass設定によって検査対象外とすることもできます。

Source IP Anchoring（SIPA)

Zscaler経由の通信であっても、特定のグローバルIPアドレスからアクセスしているように送信元グローバルIPアドレスを固定する機能です。IP制限のある社内システムやSaaSへの安全な接続に用います

• ZIAでの各種制御が実行後、SIPA対象の通信のみ ZPA Public Service EdgeとApp Connectorを経由してインターネット側へ通信を転送します。

特定の宛先をFQDNで指定して、必要最低限の通信のみが転送されるよう設定するのが一般的です。

ただし設定方法によっては、特定のFQDNだけでなく、URLカテゴリやCloud Appを条件に指定してSIPAへトラフィックを迂回させることも可能です。

※近年はENAT（Egress NAT）によって、ZIA単体で送信元グローバルIPを固定できる構成も選択できるようになっています。

この図は「最低限理解すべき流れ」

ここまで紹介した内容を見ると、「ZIAにはこれだけしか機能がないのか」と思われるかもしれません。

実際には、DNS ControlやNAT Control（Firewall controlとSSL Inspectionの間で処理）、Browser Isolation（URL FilteringやDLPのアクションとして存在）等、他の機能も存在します。

しかし、設計を学び始める段階では、まずこの図にある機能だけ理解できれば十分です。

これらの処理順序を理解することで、「なぜこの通信がブロックされたのか」「どのポリシーが優先されるのか」といった設計・運用上の考え方が身につきます。

重要なのは、「通信は決められた順番で評価されること」「インラインプロセス上でブロックされた通信は、原則として後続の処理へ進まないこと」です。

次回からは、このフローに沿って各機能を一つずつ詳しく見ていきます。

（↓AI図が少し違うところありますが、上記の文書と最初のスライドで読み解いてもらえると幸甚です。）

➡【次の記事へ】【SSE】[Zscaler] [ZIA] [設計] [個別] [インライン] Firewall control

管理人

自称SASEエンジニアです。 2児の父親をやりながら、日々エンタープライズ向けの次世代ネットワークインフラと格闘しています。一日一投稿を目標に投稿頑張りますので、是非読んでください！