【SSE】[Zscaler] [ZIA] 設計の考え方

はじめに

前回までの記事では、「Zscalerとは何か」「ZIAとZPAの違い」「Zscalerアーキテクチャ」について解説してきました。

ここからはZIAの設計について詳しく見ていきます。

ZIAには以下のような数多くの機能が存在します。

• しかし、実際の設計や運用では、「どの機能があるのか」よりも「通信がどのような順番で処理されるのか」を理解することの方が重要です。

本記事では、個別機能の詳細ではなく、ZIAがどのような考え方で通信を処理しているのかを解説します。

多くの人はZIAを機能一覧で理解しようとする

初めてZIAに触れると、多くの人は機能一覧から理解しようとします。

例えば、「URL Filtering」「Firewall Control」「DLP」「Sandbox」などです。

もちろん各機能を理解することは製品を選定する上で重要です。

しかし実際の設計では、「URL Filteringをどう設定するか」よりも「通信がどの順番で評価されるのか」を理解する方が重要になります。

なぜなら、ZIAは機能の集合体ではなく、通信を順番に評価していくクラウドセキュリティプラットフォームだからです。

ZIAは通信を順番に処理している

利用者の通信はPublic Service Edgeへ到達すると、様々なセキュリティ機能によって評価されます。

概念的には以下のような流れになります。（※一例です）

利用者通信 → Firewall Control → DNS Control → SSL Inspection → Cloud Apllication制御 → URL Filtering → Advanced Threat Protection → Data Loss Prevention  → Sandbox→ 通信許可

※実際には通信種別や利用するポリシーによって処理順序や適用有無が変化する場合があります。

重要なのは、すべての機能が同時に動いているわけではないということです。

通信は順番に評価され、途中でブロックされることもありますし、特定の通信については強制的に後続のチェックを行わない設定も可能です。

なぜ処理順序を理解する必要があるのか

設計者目線では、この処理順序の理解が非常に重要になります。

例えば、Firewall Controlでブロックされた通信は、その後のURL Filteringまで到達しません。

同様に、SSL Inspectionを実施していない通信は、後続のセキュリティ機能で通信内容を十分に確認できず、FQDNレベルでの制御は可能でもURLレベルでのチェックができません。

つまり、後段の機能は前段の機能の結果に依存しているということです。

そのため、各機能を個別に設計するのではなく、全体の流れの中で考える必要があります。

ZIA設計で最初に考えるべきこと

実際の導入プロジェクトでは、いきなり個別機能の設定から始まるわけではありません。

まずは以下のような設計方針を決める必要があります。

どのようにPublic Service Edgeへ通信を転送するか

例えば、以下選択肢があります。

• ZCC（TLS / DTLS）
• GRE Tunnel（拠点からのみ）
• IPSec Tunnel（拠点からのみ）
• Explicit Proxy

利用者の働き方や既存ネットワークによって適切な方式は異なります。

利用者をどのように認証するか

ZIAでは、Entra IDやOktaなどのIdPと連携することが一般的です。

また適用するポリシーを属性や所属グループで分類させるためのID設計も重要な要素になります。

SSL Inspectionをどこまで適用するか

ZIAの多くのセキュリティ機能は通信内容を確認することで効果を発揮します。

一方で、アプリケーション影響も考慮しなければなりません。

そのためSSL InspectionはZIA設計の中でも特に重要なテーマになります。

本シリーズで解説していく内容

本シリーズでは、これらの設計要素を順番に解説していきます。

全体設計

ZIAへの接続・通信方式の選択肢や特徴 と 代表的な機能についてどの順序で処理されるかトラフィックフローという形で紹介します。

インライン機能

ユーザの通信に影響を及ぼす代表的な機能（Firewall control、URL　Filtering等）について、ポリシーの適用順番に従って解説します。

非インライン機能

ユーザを認証するための仕組み等 と セキュリティログを残す・連携する方法、外部（SOC等）でセキュリティ問題等があった場合、自動でZIAの設定にフィードバックする機能等、直接のインライン通信とは関係のない運用系の機能を紹介します。

インライン補助

インライン系の機能を補助するための設定を紹介します。運用シーンで設定の頻度が高くなるであろう設定になりますのでインライン機能と合わせてご理解いただくとよいです。

おわりに

本記事では、ZIAを理解するための考え方について解説しました。

重要なのは、ZIAを機能一覧として理解するのではなく、通信処理フローとして理解することです。

設計者は、「どの機能を有効にするか」だけでなく、「通信がどの順番で処理されるのか」を理解する必要があります。

➡【次の記事へ】【SSE】[Zscaler] [ZIA] [設計] [全体] 通信経路とトラフィックフロー

管理人

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