Zscaler のアーキテクチャを理解する

ZscalerのZero Trust Exchangeは、「クラウドでスケールするセキュリティ基盤」と説明されることが多く、小規模な拠点から数万ユーザー規模まで柔軟に対応可能です。しかし、なぜここまで大規模にスケールできるのか、その内部構造まで理解している方は意外と少ないかもしれません。

内部構造を理解することで、トラブルシューティングや設計判断、最適な導入計画の策定に役立てることができます。

本記事では、Zero Trust Exchange（ZIAを中心とした構成）を Control Plane / Enforcement Plane（Public Service Edge）/ Logging Plane の3つのレイヤに分け、ユーザー通信がどのように処理されるのかを整理して解説します。

Zero Trust Exchangeの全体像
Control Plane（頭脳）
Enforcement Plane（Public Service Edge）
Logging Plane（記録と可視化）
まとめ

Zero Trust Exchangeの全体像

従来のオンプレミス型セキュリティでは、以下の機能が1つの装置や限られた経路に集中していました。

ポリシー管理
認証
通信検査
ログ保存

Zscaler Zero Trust Exchangeでは、各機能を役割ごとに完全に分離しています。

Control Plane：ポリシー・認証・管理
Enforcement Plane：通信の検査・制御
Logging Plane：ログの保存・配信

この分離構造こそが、グローバル規模でのスケーラビリティを実現しています。

Control Plane（頭脳）

Control Planeは、Zero Trust Exchangeの頭脳に当たります。

Control Planeの主な役割は、以下の通りです。

ポリシー管理
認証（IdP連携）
管理コンソール
API（設定変更・自動化）

認証はすべてControl Planeで行われ、ユーザーや管理者は認証後に「セキュリティトークン（Identity Token）」を取得します。このControl Planeは複数のデータセンターに分散配置されており、高可用性を前提に設計されています。

Enforcement Plane（Public Service Edge）

ユーザー通信が実際に接続するのが Public Service Edge（PSE）であります。ここがいわゆる Zero Trust Exchangeの接続ポイントとなります。

PSEの主な特徴は以下の通りです。

実通信を受ける
ポリシーを適用
ユーザーや企業の情報は保持しない

ユーザーはControl Planeで認証後、取得したセキュリティトークンを提示してPublic Service Edgeに接続します。Public Service EdgeはそのトークンをもとにControl Planeへ「このトランザクションにはどのポリシーを適用すべきか？」という形で問い合わせします。

取得したポリシーはキャッシュされ、以降の通信ではユーザーやデバイスの詳細を知らなくてもポリシーを適用できます。