はじめに

本記事はゼットスケーラー株式会社としては初のAdvent Calender 2023の2日目の記事として投稿しています。私が入社当時に感じたネットワークの観点から見るとZPAの動きがなかなか理解しにくかったところを記事にしました。
以下の免責事項をご理解の上、記事を読んで頂けると幸いです。

免責事項

本記事のコンテンツや情報において、可能な限り正確な情報を掲載するよう努めておりますが、誤情報が入り込んだり、情報が古くなったりすることもあり、必ずしもその内容の正確性および完全性を保証するものではございません。そのため、本記事をエビデンスとしたゼットスケーラーへの問い合わせなどはご対応致しかねることをご理解頂けると幸いです。掲載内容はあくまで個人の意見であり、ゼットスケーラーの立場、戦略、意見を代表するものではありません。当該情報に基づいて被ったいかなる損害について、一切責任を負うものではございませんのであらかじめご了承ください。

自己紹介

ゼットスケーラーのSEマネージャーです。
15年以上プリセールスエンジニアとしてネットワークの会社を渡り歩いて、2019年にゼットスケーラーにSEとしてJoinしました。現在はSEマネージャーですが、もっとゼットスケーラーの良さを伝えたく寄稿を決意。

ZPA(Zscaler Private Access)とは

ゼットスケーラーのサービスの一つで、リモート環境からでもプライベートアプリケーションへのアクセスを実現します。
いわゆる脱VPNを実現し、ゼロトラストネットワークアクセスを提供するサービスです。
特に昨今VPN機器の脆弱性を狙った攻撃が多く発生しており、多くの企業や団体でゼロトラストネットワークアクセスへの移行が検討されています。
ZPAについてはこちらのYouTube 3分で分かるZPA も御覧ください。

ZPAは主に以下のようなユースケースで利用されます。zscaler.jpより抜粋。
既存のVPNの代替だけではなく、アプリケーションの保護、Isolation、Deceptionなどの機能も統合されて、より安全なサービスとして提供されています。また、脆弱性の管理といった観点でも、攻撃表面を削減するので、これまでの課題であった脆弱性によるセキュリティリスクや、パッチ当てなどのメンテナンスのコストを削減することが可能となります。

さあ本題に入ってゆきます。
ここでゼットスケーラーに入社したての当時の私は思考を停止しました。
ネットワークではなくアプリに直接接続？？

これが、弊社の強みの一つであるアプリのIPの重複があってもアクセスできる所以なのですが、アプリケーションのネットワークにアクセスしないで、アプリケーションにアクセスすることに非常に違和感を感じました。しかもTCP/UDPのフルポートのアプリケーションをサポートするというのに。

一般的なリモートアクセスは、社内のLANのネットワークをPCに延伸することで、DC内になるアプリケーションにエンドツーエンドでアクセスを実現しています。NATなどされていてもIPの到達性はあるのです。
実際にゼロトラストネットワークアクセスを実現すると言われている、他社様の製品でもこの考え方を根底から覆すものは多くはありません。

ZPAの謎を解き明かす

それでは一体どうやって、これを実現しているか解説します。

1. 端末上ではIPを意識しない
ZPAではユーザ端末上でアプリケーションのIPやNATされたIPを端末上で取得しないで、通信することを可能にします。もちろんIPアドレスやレンジ、サブネットでのアクセスも可能ですが今回は割愛します。
利用者から見ると、体感的には社内と同じように社内のアプリケーションのURLやBookマークをクリックすることで、ZPA経由でのアプリケーションのアクセスが可能となっています。

これを具体的な動作として掘り下げてゆきます。
端末からURLへアクセスする際に必要な宛先となるFQDNや社内ドメインをZPAのApp Segmentに登録してZCCに渡しています。
以下、App Segmentの設定イメージ。
ここでは、赤い四角で囲った社内アプリケーションのドメインと、青い四角で囲った特定のアプリケーションのFQDNなどをイメージします。

こうしたApp Segmentのリストは、Client Forwaring Policy にて、IDPと連携してユーザの属性ベースでZCCに落とすことが可能となります。
このとき、ZCCでZPAモジュールを有効にしていると、仮想のIP（100.64.0.1）を端末上で立ち上げて、ここにDNSクエリを引き込みます。

端末上で、当該のURLにアクセスすると、

nslookup fw.thezerotrustexchange.com
Server:		100.64.0.1
Address:	100.64.0.1#53

Non-authoritative answer:
Name:	fw.thezerotrustexchange.com
Address: 100.64.1.2

実際にアクセスした順番に100.64.1.1からZPAの対象となるFQDNにIPをアサインしてゆきます。
上記の例は当該FQDNへアクセスした順番がApp Segment記載のアプリの2つ目だったので100.64.1.2となっています。

100.64.0.0/16のアドレスレンジは、ZPAのサービス内で利用され synthetic IP addressと呼んでいます(参考、以下抜粋)。

Zscaler Client Connector also uses carrier-grade NAT range 100.64.0.0/16 as part of internal health checking and for the ZPA service.

ちなみに、これに含まれる 100.64.0.0/10 のレンジはCGNAT(RFC6598) の共有アドレススペースとなっています。これは主にサービス提供者が利用するアドレス帯なので、基本的にはRFC1918のプライベートIPとは重複せず、かつZPAのサービスに閉じた形での利用となります。

こうして、このレンジの宛先の通信はZCC(100.64.0.1)経由で、ZPAのクラウドへRoutingされます。

netstat -r | grep 100.64/16
100.64/16          100.64.0.1         UGSc                utun0

上記の一連の仕組みはHelpドキュメントに簡単に記載がありますのでご参考頂けると幸いです。(以下抜粋)

To facilitate secure private connections that are abstracted from the physical network, Zscaler Client Connector associates permitted internal applications with a set of synthetic IP addresses. So, when a client application (i.e., a web browser or SSH client) sends out a DNS request, Zscaler Client Connector is able to recognize the domain as an internal application being protected by ZPA. Zscaler Client Connector then intercepts the DNS request and delivers a DNS response to the client application that uses the synthetic IP address associated with the internal application.

そして、ZCC-ZPA Cloudと、ZPA Cloud-App Connectorの間の通信ですが、Microtunnel(M-Tunnel)と呼ばれるアプリケーションセッションのトンネルが、Zscaler Tunnel(Z-Tunnel)と呼ばれるZCCとZPACloud間、ZPA CloudとApp Connector間のTLPトンネル内に作成され、ZPAのサービス内で、いわゆるLabel Switchingのようなことが行われます。
そしてZPA Cloud内でポリシーを施行しアクセスを実施します。しかしながら、あまり細かくご紹介できる公開情報がないので公開できる内容はこちらのドキュメントに記載がありますので割愛します。

2. 実際のアプリケーションへどのようにアクセスしているのか？
ここまで、端末からZPAのクラウドまでどのような仕組みで、FQDN/DomainベースでのZPAクラウドまでのアクセスを実現しているのかを解説しましたが、ここからはApp Connectorから先のアクセス方法について説明します。

ZPA対象のアプリケーション通信は、Access-policyに従い当該のアプリケーションがApp Segmentの設定で指定されたApp Connector Group内のApp Connectorに転送されます。
動作のイメージとしては、App ConnectorがProxyとして動作をし、社内アプリケーションにアクセスを行うような形となります。
App Connectorが、DC内のDNSを引き、ここで始めてアプリケーションのIPを取得して、それをIPヘッダの宛先にセット、送信元はApp ConnectorのIPをセットして、アプリケーションへのアクセスを行います。

そして全体のイメージとしては以下の図のような流れとなります。

よくZPAのPOCを実施する際に、社内のDNSを端末から通すことを前提としてお客様がイメージされることが多いのですが、こうした理由により社内のDNSは端末上で許可する必要がないのです。
よって、端末からはお客様のDCのネットワークにアクセスする概念を持たずに、アプリケーションへのアクセスを可能としています。

ZPAは究極のゼトロラストネットワークアクセス

ここで特筆すべきポイントは、ただのProxyChainingや、Reverse Proxyとして動作しているのではなく、App ConnectorとZPA CloudがTLSでOutBoundのトンネルを貼っていることにより、攻撃表面を削減しつつ、TCP/UDPのフルポートでのアプリケーションのアクセスを実現している ところです。
Zscalerと同じように、Proxyベースのアーキテクチャでプライベートアプリケーションへのアクセスを実現する競合他社様もいくつかありますが、対応するアプリケーションが制限されており、なかなかZPAのような自由度を併せ持つものは多くないのが現状です。

一般的には、ゼロトラストの概念としてアプリケーションアクセスをIDやデバイスの態勢ベースで評価を行うだけで良いと読み取っている競合他社様もありますが、実際に世の中で起こっている課題を加味すると、IPすらもTrustしないアーキテクチャが求められていると感じています。

例えば、従来のIPを制御する考え方だと、IDベースでのアプリケーションをアクセス許可したとしても、認証したユーザのアクセス元とアクセス先のIPベースでのACLに落とし込み、通信を許可する事によって結果的にこれまでと何ら変わりない実装に落ちてゆくのです。

リモートから働く環境が当たり前になっている昨今で、接続元や先のIPを気にしなければならないのは全く意味をなさないですし、ましてや複数のDCにまたがるアプリケーションのアクセスを行うに当たり、それぞれのDCのIP重複を回避するために、DC側で膨大なNATの設計を行うなど、ビジネスのアジリティを損なう大きな原因の一つとなっていると感じています。
また、セキュリティ的な観点でもラテラルムーブメントに対して、境界型のセキュリティを使って対応しているため、ゼロトラストの目指す姿とは異なっているように見えます。ましてや、IPアドレスがコロコロ変わってしまう世の中で、IPを信じて追い続けるのはそろそろ限界があるのではないでしょうか。
NIST SP800-207にてゼロトラストネットワークの概念がまとめられておりますが、そのうちの一つである、ネットワークの場所に関係なくすべての通信を保護する 点においては、そもそもネットワークを意識しないのがベストではないかと考えています。

まとめ

ゼットスケーラーのZPAは、ネットワークにアクセスするではなくてアプリケーションへのアクセスを実現する。
この中身を紐解くと、FQDNやドメインベースでZPAへのサービスへ誘導し、DCの中だけで実際のIPでの通信を行う。
結果として、ユーザ端末上からはアプリケーションのIPを意識しないで通信が可能となる。
また、攻撃表面の削減やIP重複の課題を同時に解決する。
これにより、ZPAは昨今求められている現実的なゼロトラストを実現するための最適解となっている。と思う。