【SSE】[Zscaler] [ZIA] [設計] [個別] [インライン] SSL Inspection

はじめに

Firewall Controlを通過した通信は、次にSSL Inspectionで処理されます。

現在のWeb通信の大部分はHTTPSによって暗号化されているため、通信を復号しなければ、その後のセキュリティ機能は十分な情報を取得できません。

そのためSSL Inspectionは、「通信を復号する機能」というよりも、

「後続のセキュリティ機能が十分な情報を取得できる状態を作る機能」という考え方が重要になります。

本記事では、

SSL Inspectionの役割

• 利用できるクライテリア
• 利用できるアクション
• 初期状態で用意されている定義済みルール
• 設計時の考え方

について解説します。

SSL Inspectionとは

SSL Inspectionでは、HTTPSなどSSL/TLS通信を復号するかどうかを判断します。

しかし、役割は単純な復号だけではありません。

SSL Inspectionの結果によって、後続のセキュリティ機能がどこまで通信内容を確認できるかが決まります。

例えば、復号しない通信では、SNIや証明書情報など暗号化されていない情報を利用した制御は可能ですが、

URLパスやHTTPメソッド、アップロードファイルなどは確認できません。

つまり、SSL Inspectionは後続のセキュリティ機能へ「どこまで情報を渡せるか」を決める機能と言えます。

SSL Inspectionで利用できる主なクライテリア

SSL Inspectionでは、Firewall Controlと同様に様々な条件を組み合わせてポリシーを作成できます。

複数のクライテリア（以下参照）がありますが、URL CategoriesとCloud Applicationsは他のクライテリアと組み合わせて利用するケースがほとんどだと考えます。

• URL Categories
• Cloud Applications
• Destination Groups
• User
• Group
• Department
• Location
• Device Group
• Device Trust Level
• Source IP Group
• CONNECT User-Agent

SSL Inspectionで利用できるアクション

SSL Inspectionでは、主に以下のアクションを利用します。

• Inspect
• Do Not Inspect（Evaluate Other Policies）
• Do Not Inspect（Bypass Other Policies）
• Block

この4つの違いを理解することが、SSL Inspection設計でもっとも重要になります。

Inspect

Inspectは、SSL/TLS通信を復号し、後続のインラインプロセスへ渡すアクションです。

Cloud App ControlやDLPなど、通信内容まで確認する必要がある機能は、このアクションによって初めて十分な検査が可能になります。

また、証明書エラーが発生した場合に、通信を拒否するか、そのまま後続へ進めるかも設定できます。

Do Not Inspect（Evaluate Other Policies）

通信は復号しません。

しかし、インラインプロセスは継続します。

そのため、SNIや証明書情報など、暗号化されていない情報を利用して、Cloud App ControlやURL Filteringなどの評価を継続できます。

Do Not Inspect（Bypass Other Policies）

通信を復号しないだけではなく、SSL Inspection以降、Cloud App ControlやURL Filteringのインラインプロセスも実施しません。

以降のFile Type ControlやDLPなどはルール上適用されます。ただし中身が複合化されていないので、実質的には制御が効かず、通信はそのままインターネットへ転送されます。

証明書ピンニングなど、SSL Inspectionが成立しないアプリケーションでは、このアクションを利用することがあります。

Block

SSL Inspectionの段階で通信を拒否するアクションです。

例えば、復号対象としているにもかかわらず、証明書の状態に問題がある通信などに対して利用できます。

初期状態で用意されている定義済みルール

SSL Inspectionには、Firewall control同様、初期状態から定義済みルール（Predefined Rules）が用意されています。

代表的なものとして、以下があります。

• Zscaler Recommended Exemptions
• Office 365 One Click

Zscaler Recommended Exemptions

証明書ピンニングなど、技術的な理由によりSSL Inspectionが適用できない通信やZscalerが推奨する除外先をまとめたルールです。

導入初期から有効になっており、通常はそのまま利用することが推奨されています。

Office 365 One Click

Microsoft 365向け通信を最適化するための定義済みルールです。

Firewall Control同様、Microsoft 365は変更頻度が高いため、One Click機能を利用することで、Zscalerが管理する推奨設定を利用できます。

設計で重要なこと① 「復号しない通信」を決めること

SSL Inspectionでは、「何を復号するか」よりも、「何を復号しないか」を先に決めることが重要です。

例えば、以下のような通信は、SSL Inspectionの例外として先に定義します。

• 証明書ピンニングを利用するアプリケーション
• 復号すると正常動作しない業務システム
• 法令や社内ポリシーにより復号対象外とする通信

これらは、業務システムの追加やSaaSの利用開始などに応じて、運用の中で見直されることがあります。

そのため、例外ルールだけを先に定義し、最後に**「それ以外はすべてInspect」**というルールを配置する構成が、Zscalerでも推奨されるベストプラクティスです。

この構成により、例外だけを明確に管理しながら、可能な限り多くの暗号化通信を保護できます。

設計で重要なこと② 「ルール」を増やさないこと

実際の運用では、SSL Inspectionのルールを増やし続ける設計はおすすめできません。

インターネットの利用状況は日々変化しており、新しいSaaSやWebサービスの利用開始、既存サービスの廃止などに合わせてルールを追加・削除していく運用は、管理負荷が大きくなるだけでなく、ルールの優先順位や影響範囲の把握も難しくなります。

そこで重要になるのが、ルールではなく、URLカテゴリやCloud Appなどの条件を管理するという考え方です。

例えば、新たに利用するSaaSをSSL Inspectionの例外対象としたい場合でも、新しいルールを追加するのではなく、既存ルールで参照しているURLカテゴリやCloud Appグループへ対象を追加するだけで対応できます。

このような設計にすることで、

• ルール数を増やさずに運用できる
• 設定変更時の影響範囲を限定しやすい
• Cloud App ControlやURL Filteringなど、後続のポリシーとの整合性を維持しやすい

といったメリットがあります。

「ルールを増やして対応する」のではなく、「カテゴリやグループを育てて運用する」

この考え方は、SSL Inspectionだけでなく、ZIA全体のポリシー設計に共通する重要なポイントです。

SSL Inspectionは後続のセキュリティ機能を活かすための機能

SSL Inspectionの目的は、通信を復号することではありません。通信を復号することで、

Cloud App Control、

URL Filtering、

File Type Control、

Malware Protection、

DLPなどが、

通信内容まで確認できるようになります。

つまり、SSL Inspectionは、後続のセキュリティ機能の性能を最大限発揮させるための基盤機能と考えると理解しやすいでしょう。

➡【次の記事へ】【SSE】[Zscaler] [ZIA] [設計] [個別] [インライン] SSL Inspection

管理人

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