HOME
MENU
Zscaler

【SSE】[Zscaler] Zscalerアーキテクチャ

buffoon

はじめに

前回の記事では、Zscalerの主力ソリューションである

ZIA（Zscaler Internet Access）

  • ZPA（Zscaler Private Access）

について紹介しました。

ZIAはインターネット向け通信を保護するソリューションであり、ZPAは社内システムへのアクセスを保護するソリューションです。

本記事では、Zscalerを構成する主要コンポーネントと、それぞれがどのような役割を担っているのかを解説します。

Zscalerアーキテクチャの全体像

実際の構成はさらに複雑ですが、概念的にはこのような形になります。

ここで重要なのは、

業務通信を成立させるためのコンポーネント

と

管理・運用するためのコンポーネント

に分けて考えることです。

業務通信を成立させるコンポーネント

まずは利用者の通信に直接関係するコンポーネントから見ていきます。

利用者端末

通信の起点となるのが利用者端末です。

WindowsやmacOSのPCだけでなく、iOS、Android、VDI環境、LinuxOS なども対象となります。

どの端末からどのような通信を行うのかを整理することが重要になります。

ZCC（Zscaler Client Connector）

ZCCは利用者端末へインストールするクライアントソフトです。

単なるエージェントソフトと思われがちですが、実際にはZscaler全体の動作を支える重要なコンポーネントです。

主な役割としては、

  • ユーザ認証
  • 通信転送
  • 端末識別
  • ポリシー適用
  • ロケーション判定

などがあります。

ZCCは通信の入口を制御する

ZIAやZPAは基本的に設定した通りに動作します。

しかし実際の導入では、

  • 社内プロキシ
  • VPN
  • VDI
  • セキュリティ製品
  • PACファイル

など既存環境との共存を考慮する必要があります。

そのためZCCには、

  • App Profile
  • Forwarding Profile
  • Trusted Network

など様々な制御機能が用意されています。

ZCCを制する者はZscalerを制する

実際の運用では、

「どのような通信を転送するのか」

「どの環境で転送を停止するのか」

「既存システムとどのように共存するのか」

といった設計が重要になります。

つまりZIAやZPAが

何を実施するか（守るか）

を決めるソリューションであるのに対し、

ZCCは

どのようにそこへ到達させるか

を決めるソリューションと言えます。

少し大げさかもしれませんが、

「ZCCを制する者はZscalerを制する」

と言っても過言ではありません。

本シリーズでも別途詳しく解説していく予定です。

IdP（Identity Provider）

近年のSSE環境では、IdPとの連携はほぼ必須となっています。

代表的な製品としては、

  • Microsoft Entra ID
  • Okta

などがあります。

IdPの役割

主な役割は、

  • ユーザ認証
  • グループ管理
  • 属性連携

です。

利用者はIdPを通じて認証され、その結果に応じてZIAやZPAのポリシーが適用されます。

例えば、

  • ネットワーク管理者
  • 一般社員
  • 派遣社員

などのグループによって異なるポリシーを適用できます。

ZIA・ZPA・ZCCをつなぐ存在

実際には、Zscalerの多くの制御がユーザ属性やグループ情報に依存しています。

そのためIdPはZscaler製品そのものではありませんが、

Zscaler環境を支える重要な基盤コンポーネント

と言えるでしょう。

Public Service Edge

Public Service EdgeはZscalerクラウド上で動作する中核コンポーネントです。

利用者の通信はまずPublic Service Edgeへ到達し、その後に各種処理が実施されます。

ZIAにおけるPublic Service Edge

ZIAではインターネット向け通信を検査します。

例えば、

  • Firewall Control
  • DNS Control
  • URL Filtering
  • SSL Inspection
  • Advanced Threat Protection
  • Data Loss Prevention

などの機能がここで実行されます。

つまりZIAのPublic Service Edgeは、クラウド型セキュリティゲートウェイとして動作します。

ZPAにおけるPublic Service Edge

一方のZPAでは役割が異なります。

ZPAでは、

  • ユーザ認証
  • アクセス制御
  • セッション仲介

などが実施されます。

ZIAのように通信を検査するというより、利用者とアプリケーションを安全につなぐための仲介役として動作します。

同じPublic Service Edgeという名前ですが、役割は大きく異なります。

Public Service Edgeへの転送方式

ここまで紹介してきたように、利用者の通信は最終的にPublic Service Edgeへ到達します。

しかし、Public Service Edgeへ到達する方法は一つではありません。

Zscalerでは利用環境や要件に応じて複数の転送方式を選択できます。

代表的なものとして、

  • TLS / DTLS（ZCC Tunnel）
  • GRE Tunnel
  • IPSec Tunnel
  • Explicit Proxy

などがあります。

実際の設計では「どの機能を利用するか」だけでなく、「どのようにPublic Service Edgeへ通信を届けるか」

も重要な検討項目となります。

TLS / DTLS

TLS / DTLSは主にZCCを利用する際に使用される転送方式です。

利用者単位の制御や端末情報を活用したポリシー適用との相性が良く、現在のZscaler環境では最も一般的な構成と言えるでしょう。

また、利用者が社外へ持ち出した端末からでも同様のセキュリティポリシーを適用できるため、リモートワークとの親和性も高い方式です。

GRE / IPSec Tunnel（ZIAのみ）

GREやIPSecは、ネットワーク機器からPublic Service Edgeへ接続する際に利用される転送方式です。

  • 拠点通信
  • データセンター通信
  • サーバ通信

などで利用されます。

近年ではSD-WAN製品やファイアウォール製品から直接ZscalerへGREやIPSec接続を行う構成も一般的になっています。

GRE / IPSecとZCCは併用できる

GREやIPSecは、「ZCCを利用しない場合の接続方式」と考えられることがあります。

しかし実際には、ZCCとGRE / IPSecを組み合わせて利用する構成も珍しくありません。

ZCCによるユーザ単位の制御

  • GRE / IPSecによるロケーション単位の制御

を組み合わせることができるため、実際Zscalerでもベストプラクティスの一つとして紹介されています。

通信オーバーヘッドやMTUなど考慮すべき要素は増えますが、柔軟なポリシー制御を実現できるため、実際の導入環境でも採用されるケースがあります。

転送方式の選択も設計の重要な要素

ZIAやZPAの機能に注目しがちですが、実際の導入プロジェクトでは、「どの転送方式を選択するか」も非常に重要です。

利用者の働き方や既存ネットワーク構成によって最適な構成は異なるためです。

そのため実際の設計では、

  • 利用者端末の種類
  • 拠点構成
  • 既存プロキシの有無
  • SD-WANとの連携
  • MTUや通信品質

なども考慮しながら転送方式を決定します。

App Connector

App ConnectorはZPAで利用するコンポーネントです。

企業のデータセンターやクラウド環境へ配置します。

管理・運用のためのコンポーネント

ここまで紹介したコンポーネントは業務通信を成立させるためのものです。

一方で、実際の運用では管理者向けのコンポーネントも存在します。

管理ポータル

管理者は各種ポータルを利用して設定や運用を行います。

ZIA Admin Portal

  • ZPA Admin Portal
  • ZCC Portal

初めて触る方は、「同じZscalerなのに管理画面が分かれている」と感じるかもしれません。

これは前回紹介した通り、ZIAとZPAが密接に連携しながらも独立したソリューションとして設計されているためです。

おわりに

本記事ではZscalerを構成する主要コンポーネントについて紹介しました。

重要なのは、

  • 利用者端末
  • ZCC
  • IdP
  • Public Service Edge
  • App Connector

が連携することで、利用者の通信が成立しているということです。

また管理者は、ZIA、ZPA、ZCCそれぞれの管理ポータルを利用して運用を行います。

実際の設計や運用を考える上では、「どの機能が存在するのか」よりも「通信がどのような順番で処理されるのか」を理解することが重要ですので次回以降取り上げていきたいと思います。

➡【次の記事へ】【SSE】[Zscaler] [ZIA] 設計の考え方

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

管理人
管理人

自称SASEエンジニアです。 2児の父親をやりながら、日々エンタープライズ向けの次世代ネットワークインフラと格闘しています。一日一投稿を目標に投稿頑張りますので、是非読んでください！
Recommend
こんな記事も読まれています
記事URLをコピーしました