Zscaler導入では、理想の構成図を描く前にやることがあります。
それがAs-Is（現状）の把握です。
既存のProxy、VPN、Firewall、Identity Provider、端末管理、DNS、Application配置。
これらを十分に確認せず、「これからはZIAとZPAを使う」とTo-Beだけを描いてしまうと、移行時に思わぬ影響が出ることがあります。
たとえば、長年利用されているPACファイルに、特定の業務システムだけプロキシを経由しない設定が残っている場合があります。
また、VPNに接続しなければ社内のDNSサーバーへ問い合わせられないアプリケーションや、既存プロキシの動作を前提としたソフトウェアが存在するかもしれません。
こうした依存関係を把握せずに通信経路を変更すると、移行後に一部の業務システムが利用できなくなる可能性があります。
今回は、なぜ現状調査が設計の土台になるのかを整理します。
まず結論。As-Isは「古い構成を残すため」ではなく「変えてよいものを判断するため」に調べる
一言でいうと、
As-Isを把握する目的は、現状をそのまま再現することではなく、To-Beへ移るときに何を変え、何を残し、何を先に解決すべきかを判断するためです。
Zscalerの各Deployment Guideには、導入前に確認すべきPrerequisiteやInteroperabilityの条件が用意されています。
たとえばClient Connectorでは、OSのSystem Requirementだけでなく、既存VPN ClientやVPN-like ApplicationとのInteroperability、IdP向けAuthentication Traffic、Endpoint Firewall / Antivirusとの関係などが考慮事項になります。
ZPAのApp Connectorでも、DNS Resolution、ApplicationへのNetwork Access、Zscaler ServiceへのOutbound通信などが前提になります。
つまり導入対象のZscalerだけを見ても、設計は完結しません。
Zscalerが接続される既存環境の条件を知る必要があります。
Networkを見るのは「回線図を作るため」だけではない
Networkの現状調査では、拠点回線やInternet出口だけでなく、通信がどこを通っているかを知ることが重要です。
たとえばWeb Accessが、
端末 → PAC / Proxy → Data Center → Internet
なのか、
拠点 → Firewall → Internet
なのかで、ZIAへのTraffic Forwardingを考える前提が変わります。
また、在宅勤務ではVPN Clientが使われているか、Split Tunnelがあるか、Authentication Trafficがどこを通るかも影響します。
Zscaler Client Connectorの公式Deployment Guideでも、既存VPN ClientとのInteroperabilityや、IdP向けTrafficが意図しないInspectionを受けないようにする考慮が示されています。
つまりNetwork調査は、「線を描くこと」ではなく、通信の依存関係を見つけることが目的です。
Identity・端末・Applicationも同じくらい重要
Zero TrustではNetworkだけ分かっていても足りません。
Identityについては、
- どのIdPを使っているか
- User / Groupをどう管理しているか
- MFAはどこで実施しているか
- 異動や退職時のAccount Lifecycleはどうなっているか
端末については、
- 対象OSやVersion
- 会社管理端末と管理外端末の割合
- MDM / EDR / Antivirus
- 既存VPN ClientやProxy Agent
Applicationについては、
- Internet / SaaSかPrivate Appか
- FQDN / IP / Port
- DNS
- 接続元の制約
- 業務Criticality
などが設計材料になります。
これらは後続のZIA、ZPA、Identity、Client Connector設計に直接つながります。
「使われている理由」が分からないものを、すぐ消さない
現状調査でよくある落とし穴は、古く見えるRuleやBypassを「不要そう」と判断してしまうことです。
長年残っている設定には、現在も必要な業務依存が隠れている場合があります。
逆に、すでに不要なのに誰も理由を説明できず残っている設定もあります。
そのため現状調査では、設定を一覧化するだけでなく、「何のために存在するのか」「変更・削除すると誰に影響するのか」まで確認することが重要です。
実際の導入プロジェクトでは、調査結果を次のような資料として整理します。
- 通信経路一覧：どの端末から、どの経路を通って通信しているか
- アプリケーション一覧：接続先、利用者、必要なポート、名前解決の方法
- 既存設定・例外一覧：プロキシ、VPN、ファイアウォールなどの設定と、その設定が必要な理由
- 移行時の確認事項：変更による影響が想定される業務や、追加検証が必要な通信
これらを整理しておくことで、既存設定を残すべきか、変更すべきか、廃止できるかを判断しやすくなります。
次回からは、このAs-Isを前提に、ZIA設計で何を決めるのかを具体的に見ていきます。
今回のポイント
- 現状調査は既存環境をそのまま再現するためではなく、何を残し、何を変えるか判断するために行う
- ネットワークだけでなく、認証、端末、アプリケーション、既存設定との依存関係も確認する
- 設定の存在だけでなく、その理由と変更時の影響を把握することが安全な移行につながる
参考情報
- Zscaler公式：Zscaler Client Connector Deployment and Operations Guide
- Zscaler公式：App Connector Deployment Prerequisites
- Zscaler公式：Authentication Deployment and Operations Guide
本記事の制作について
本記事では、一部図版の制作支援に生成AIを利用しています。技術内容については執筆者および0-WANエンジニアが確認・編集しています。
