【Zscaler】ZPAでVPNを置き換える！#4 アプリケーションの定義

こんにちは。ネットワールドSEの藤田です。

ZPAでVPNを置き換える！の第四回です。
今回はZPAでどのようにアプリケーションを定義するのか見ていきたいと思います。

免責事項
アプリケーションベースで考える
アプリケーションを定義する方法（アプリケーションセグメント）
アプリケーションを精査する
IPベースのアプリケーションセグメント
まとめ

免責事項

本書は、株式会社ネットワールド（以下弊社）が作成・管理します。
本書の記載内容の一部または全部を弊社に無断で改変・転載することを禁じます。
本書の記載内容は、一部または全部が将来予告無く変更されることがあります。
本書の利用は、利用者様の責任において行われるものとします。
本書の記載内容には、最善の注意を払っておりますが、正確性・完全性を保証するものではありません。従いまして、本書の利用によって生じたあらゆる損害に関して、弊社は一切の責任を負いかねます。

アプリケーションベースで考える

ZPAはVPNと違い、アプリケーションを中心として設計されています。

VPNはネットワークを中心に設計されています。FW機器と一体化している場合もありますが、VPN機器へアクセス後にFW機器でIPアドレスベースのアクセス制御を適用するのが一般的でしょう。VPN機器は接続する条件を定義し、FW機器でアクセスポリシーを定義します。FW機器で意識されるのは、何が通過できるかというネットワークの要件です。この構成でユーザ単位・アプリケーション単位に厳密なアクセス制御を適用するのは複雑な設定が必要になるのではないでしょうか。

しかし、ZPAは違います。

そもそもがネットワークではなく、アプリケーションを中心に設計されています。まず、定義すべきはユーザへ公開するアプリケーションです。このアプリケーションに対し、どのような条件であればアクセスできるのかを要件ごとにきめ細かく定義することができます。どのアプリケーションを公開するのか、明確に定義ができていればユーザは必要のないアプリケーションへそもそもアクセスできず、セキュリティインシデント時にラテラルムーブメントの余地が極小化されます。

これまでVPNでは同じ入口から通過するトラフィックをチェックしていたのを、ZPAでは入口を全部分け、専任の門番を配置した、とイメージしてもいいかもしれません。

アプリケーションを定義する方法（アプリケーションセグメント）

ではそのアプリケーションはどのように定義するのでしょうか？

ZPAでは「アプリケーションセグメント」という設定でアプリケーションを定義します。アプリケーションセグメントは、アクセスポリシーを共有するFQDN/IPアドレス、プロトコル、ポート番号のリストです。

具体例をご紹介します。例えば社内全体へ公開するWebアプリケーション（HTTPS/HTTP）があるとします。その場合、以下のように2つのアプリケーションセグメントを定義します。

Webアプリケーションセグメント①（HTTPS）
- FQDN： www1.sample.test, www2.sample.test, www3.sample.test
- ポート番号/プロトコル： 443/TCP

Webアプリケーションセグメント②（HTTP）
- FQDN： www4.sample.test, www5.sample.test, www6.sample.test
- ポート番号/プロトコル： 80/TCP

ポート番号/プロトコルは複数指定することができますが、その場合はアプリケーションセグメント内の全FQDNでそのポート番号が公開されます。必要な通信のみを許可するため、通信要件を共有するFQDNのみを含めます。上記であればHTTPSとHTTPをホストするFQDNが異なるため、別々にアプリケーションセグメントは作成します。

上記のアプリケーションセグメントは社内全体へ公開する、という点でアクセスポリシーを共有しています。つまり、ルールにすれば一行で処理できるはずです。そのような場合、「セグメントグループ」というアプリケーションセグメントをグループ化する機能があるため、こちらでまとめることができます。
※アプリケーションセグメントは必ずいずれか一つのセグメントグループに所属する必要があります

Webセグメントグループ
- アプリケーションセグメント： Webアプリケーションセグメント①、Webアプリケーションセグメント②

アクセスポリシーを定義する場合は、セグメントグループ単位でルールを定義すれば、ルール数の肥大化を防ぐことができます。また、アプリケーションセグメント単位でアクセスポリシーを定義することもできます。アクセスポリシーに関しては次回ご紹介したいと思います。

このような方法で、ユーザへ公開するアプリケーションの一覧を定義することで必要最小限のアプリケーションのみを公開します。

アプリケーションを精査する

もちろんいきなり社内アプリケーションをすべて定義するというのは難しいですよね？
やはりまずどのようなアプリケーションが存在するのかを確認する必要があるでしょう。その場合、ワイルドカードを用いたアプリケーションセグメントを定義し、どのような通信があるかを可視化します。

ワイルドカードアプリケーションセグメント
- FQDN： *.sample.test
- ポート番号/プロトコル： 1-52,54-65535/TCP、1-52,54-65535/UDP

※ 名前解決のDNS（53/TCP、53/UDP）は、トンネルの向こうのApp Connectorの役割なので除外します

これで「*.sample.test」に含まれる全アプリケーションを定義したことになります。これに含まれる通信はZPAに記録され、どのようなアプリケーションが存在するかを可視化することができます。これをApp Discoveryと言います。そのため、以下のように「*.sample.test」にヒットする通信を検知すれば、それを可視化することができます。

www1.sample.test
www2.sample.test
www3.sample.test......

さらに、ZPAはAIを用いて効率的に精査することができます。以下のURLをご参照下さい。

www.zscaler.com

ワイルドカードによるアプリケーションセグメントはVPNをエミュレートしたものです。あくまでも最小権限の原則を達成するための通過地点と考えましょう。これを用いているうちは、アプリケーションごとのアクセスポリシーを適用できません。ワイルドカードに含まれるアプリケーションは、すべて同じアクセスポリシーしか適用できないことになってしまいます。あくまでも、アクセスポリシーはアプリケーションセグメントに対して定義されます。

また、ワイルドカードで指定しているため、不要なものがすべてオープンな状態です。これは最小権限の原則が適用されているとは言えませんね。そのため、ここからアプリケーションを切り出し、ユーザのアクセス範囲を狭めていくプロセスが必要なのです。

FQDNで指定したアプリケーションセグメントは、図の通り切り出されます。つまり、もうワイルドカードFQDNにはヒットしなくなります。FWのイメージで考えるとオヤ？と思ってしまいますが、ZPAが最小権限の原則に沿って設計されていると考えれば、自然なことですよね。FQDNで定義したということは、そのアプリケーションの要件が確定したということです。それなのに、ワイルドカードFQDNにもヒットしていては、ユーザのアクセス範囲を狭めることができませんよね？

このようにZPAのアプリケーションセグメントの定義を段階的に進めていくことができます。

IPベースのアプリケーションセグメント

これまではFQDNベースのアプリケーションを前提としてご説明してきました。一方、システム管理者視点からすると、管理ネットワークはIPベースでアクセスしたい、というようなご要望があるかもしれません。そういった場合、IPベースでアプリケーションセグメントを定義することができます。FQDNの代わりにIPアドレス、ワイルドカードFQDNの代わりにサブネットを指定すれば動作します。

ただ、あくまでも推奨はFQDNベースだとお考えください。IPベースの場合、接続元のネットワークとサブネットが重複する懸念があります。また、プライベートネットワークの情報がユーザから見えてしまいます。既存のVPNでIPベースで接続しているアプリケーションも、ZPAへの移行タイミングで是非FQDNによる接続への移行をご検討ください。

まとめ

今回はアプリケーションの定義についてご説明しました。私も当初はVPN機器・FW機器のイメージで触っていたのでうまく理解できない部分がありましたが、ZPAがゼロトラストを支援するソリューションと考えると、挙動がストンと腑に落ちました。ZPAはまずアプリケーションが中心にあり、そこに対し必要最小限のアクセスを許可するように設計されています。次回はそのアプリケーションに対して、どのようにアクセスポリシーを適用するのかについて見ていきたいと思います。ありがとうございました。