【SSE】[Zscaler] [ZIA] [設計] [個別] [インライン] Source IP Anchoring
はじめに
これまでの記事では、ZIAのインラインプロセスで実行されるセキュリティ機能について紹介してきました。
今回は、その中でも少し特殊な機能である Source IP Anchoring(SIPA) を紹介します。
SIPAは通信を許可・拒否する機能ではなく、特定の通信だけ送信元グローバルIPアドレスを固定するためのルーティング機能です。
本記事では、以下について紹介します。
- Source IP Anchoringとは
- 仕組み
- 設定方法
- 設計上の注意点
- ENATとの違い
Source IP Anchoringとは
Source IP Anchoring(SIPA)は、特定のSaaSやWebサービスへアクセスする際に、送信元グローバルIPアドレスを固定する機能です。
- Microsoft 365
- Salesforce
- ServiceNow
- IPアドレス制限を行っているSaaS
などでは、送信元IPアドレスによるアクセス制御を利用しているケースがあります。
通常、ZIAを経由した通信は、Zscalerが提供する共有の送信元グローバルIPアドレス(Egress IP)からインターネットへ送信されます。
そのため、送信元IPアドレスによるアクセス制御を行っている上記SaaSやWebサービスでは、企業専用の固定グローバルIPアドレスを利用した接続ができません。
SIPAでは、ZIAで許可された通信のうち、指定した通信だけをZPAのApp Connector経由へ転送することで、
App Connectorが配置されている拠点やクラウド環境の固定グローバルIPアドレスから通信を送信できます。
SIPAの仕組み
通常の通信は、
ユーザ → ZIA Public Service Edge → インターネット
という経路で通信します。
一方、SIPA対象として定義された通信だけは、
ユーザ → ZIA Public Service Edge → ZPA Public Service Edge → App Connector → インターネット
という経路へ切り替わります。
つまり、通信経路そのものを変更することで送信元IPアドレスを固定する仕組みです。
SIPAは単純なNAT機能ではなく、ZPAのApp Connectorを利用したルーティング機能と考える方が理解しやすいでしょう。
SIPAの設定
SIPAは、ZIA単独では設定できません。
ZPA管理画面で、
- App Connector / App Connector Group
- Application Segment 等
- を作成します。
Application Segment設定で「Source IP Anchoring」を有効にすると、その情報がZIA管理画面へ同期されます。
その後、ZIA側のForwarding設定で対象アプリケーションを選択することで、特定の通信を転送できるようになります。
App Connectorの導入方法やZPAとの連携については、ZPA編で詳しく紹介します。
Web通信と非Web通信では動作が異なる
SIPAは、Web通信・非Web通信の両方で利用できます。
ただし、宛先判定の方法が異なります。
Web通信
HTTP/HTTPS通信では、「HTTP Host Header」「TLS SNI」などから、ZIAが宛先FQDNを判定できます。
そのため、特別なDNS設定を意識しなくてもSIPAを適用できます。
非Web通信
「SSH」「RDP」「独自TCP通信」などでは、通信にはIPアドレスしか含まれません。
そのため、ZIAは事前のDNS問い合わせを利用して、
example.com = 203.0.113.10 (Aレコード)
という対応関係を保持し、後から到着するIP通信をSIPA対象として判定しています。
つまり、非Web通信をSIPAへ転送する場合は、DNS Control PolicyによるDNS連携が重要になります。
ZPA Resolver for Road Warrior とは
ZPA Resolver for Road Warrior、ZPA Resolver for Locationsは、ZIAのDNS Control Policyに用意されている定義済みルールです。
このルールは、SIPAで非Web通信を利用する場合に有効化が必要となります。
SIPAでは、SSHやRDPなどの非Web通信を転送する際、HTTP HostヘッダーやTLS SNIのようなドメイン情報を取得できません。
そのため、通信を開始する前段階であるDNSクエリの時点で、SIPA対象通信かどうかを判定する必要があります。
このルールを有効にすると、SIPA対象となるドメインに対するDNS問い合わせをZIAが検知し、ZPAの仕組みと連動して 「ZPA Resolver IP(ダミーIP)」 を応答として返します。
一方、SIPA対象ではないドメインについては、このルールには一致せず、通常どおり宛先サーバのグローバルIPアドレスが返されるため、通常のインターネット通信には影響を与えません。
その後、クライアントは返却されたZPA Resolver IPへ通信を開始します。
この通信は、利用しているネットワーク環境(Z-Tunnel 2.0 または拠点のGRE/IPsecトンネル)を通じて確実にZIAクラウドへ届けられます。
ZIAは、宛先がこのZPA Resolver IP(ダミーIP)であることを見て、対象の非Web通信をSIPAトラフィックとして確実に識別し、適切なApp Connectorへ転送することができます。
つまり、非Web通信におけるSIPAは、実際の通信が始まる前のDNS問い合わせの段階から特別な制御が行われているということです。
Z-Tunnel 1.0・PAC利用時の注意点
Z-Tunnel 1.0やPACファイルを利用するRoad Warrior環境では、
Web通信は通常、Forwarding ControlやFirewall Controlを経由しません。
しかし、SIPAやENATはForwarding Controlを利用して転送を判断します。
そのため、以下の設定を有効にする必要があります。
Administration > Advanced Settings > Enable Firewall for Z-Tunnel 1.0 and PAC Road Warriors
この設定を有効にすることで、Web通信もForwarding Controlを経由するようになり、SIPAやENATが正しく動作します。
Z-Tunnel 2.0では不要ですが、Z-Tunnel 1.0やPAC運用では見落としやすいポイントです。
App Connector側の注意点
SIPAでは、App Connectorがインターネットへの出口となります。
そのため、App Connectorを配置する環境では、送信元グローバルIPアドレスが固定されるよう、
Static NATやNAT Gatewayなどを構成しておく必要があります。
また、SIPA通信量が多い場合は、通常のZPA用App Connectorとは分離し、
SIPA専用のApp Connector Groupを構成することも推奨されています。
ENATとの違い
近年では、ZIA単体で送信元グローバルIPアドレスを固定できる
Egress NAT(ENAT)が利用できるようになりました。
ENATでは、App ConnectorやZPAを利用せず、ZIAだけで送信元IPアドレスを固定できます。
そのため、App Connectorの管理や運用が不要になり、構成もシンプルになります。
今後は、SIPAだけではなく、ENATを選択するケースも増えていくでしょう。
ENATについては別記事で詳しく紹介します。
設計で重要なのは「通信経路を理解すること」
SIPAは、単純に送信元IPアドレスを書き換える機能ではありません。
ZIAからZPAのApp Connectorへ通信経路を変更し、その出口となる固定グローバルIPアドレスを利用することで、
IPアドレス制限のあるSaaSなどへ安全に接続します。
そのため、設計では、
- App Connectorの配置場所
- NAT構成
- Web通信と非Web通信の違い
- DNS Control Policy
- Z-Tunnel 1.0利用時のAdvanced Settings
など、通信経路全体を理解したうえで設計することが重要です。
おわりに
Source IP Anchoringは、ZIAのインラインプロセスの中でも少し特殊な機能です。
通信を許可・拒否するのではなく、特定の通信だけ経路を変更し、送信元グローバルIPアドレスを固定するという役割を担います。
近年ではENATという新しい選択肢も登場しており、今後はよりシンプルな構成で送信元IP固定を実現できるケースも増えていくでしょう。
一方で、SIPAはZPAとの連携やApp Connectorを活用した柔軟なルーティングが可能という特徴があり、現在でも有効な選択肢の一つです。
それぞれの特徴を理解し、要件に応じて適切な方式を選択することが重要です。

➡【次の記事へ】【SSE】[Zscaler] [ZIA] [設計] [個別] [インライン] [+α] NAT control / DNS control

