はじめに

前回の記事では、Data Loss Prevention（DLP）について紹介しました。

インラインプロセスでは、Malware ProtectionとSandboxも重要な役割を担っています。

ただし、この2つはFirewall ControlやURL Filteringのように一直線で処理されるポリシーではありません。

通信内容やファイルの種類に応じて、必要なタイミングで検査が実行されるセキュリティエンジンです。

本記事では、以下について紹介します。

• Malware Protectionとは
• Sandboxとは
• 検査が実行されるタイミング
• 設計・運用で意識したいポイント

Malware Protectionとは

Malware Protectionは、既知のマルウェアを検知・遮断する機能です。

例えば、

• ウイルス
• トロイの木馬
• ランサムウェア
• ワーム

など、既知の脅威シグネチャを利用して高速に判定します。

ファイルが既知のマルウェアと判断された場合は、その場で通信をブロックします。

シグネチャによる高速な判定が中心となるため、一般的な脅威に対して非常に高い効果を発揮します。

Sandboxとは

Sandboxは、未知のファイルを安全な仮想環境で実行し、悪意ある挙動がないかを解析する機能です。

例えば、

• Microsoft Officeファイル
• PDF
• ZIPファイル
• 実行ファイル
• スクリプト

などを仮想環境で実行し、

• プロセス生成
• ネットワーク通信
• ファイル操作
• レジストリ変更

などの振る舞いを解析します。

シグネチャでは判定できない未知のマルウェアに対しても検知できる点が特徴です。

※OfficeファイルやPDFなどの検査にはAdvanced Cloud Sandboxライセンスが必要です。

インラインプロセスでは「検査エンジン」と考える

以前紹介したインラインプロセスでは、Malware ProtectionとSandboxを一つのブロックとして紹介しました。

しかし実際には、Firewall Controlのように「ここで必ず処理される」というものではありません。

通信内容やHTTPメソッド、ファイル転送などに応じて、必要なタイミングで検査エンジンが動作します。

内部では複数のタイミングで検査が実行されるため、詳細な処理順序は公式ドキュメントを参照することをおすすめします。

設計者としては、「必要な通信に対して動作する検査エンジン」という理解で十分でしょう。

SSL Inspectionが大前提

Malware ProtectionやSandboxによるファイル検査を期待する場合、SSL Inspectionは非常に重要な前提条件になります。

現在、多くのWeb通信はHTTPSで暗号化されています。

SSL Inspectionを行わない場合、暗号化された通信からファイルを取り出して検査することができません。

つまり、SSL Inspectionで「Do Not Inspect」とした通信については、Malware ProtectionやSandboxによるファイル検査も適用されないケースがあります。

SSL Inspectionの記事でも紹介したように、復号除外を設計することは、その後のセキュリティ機能を適用しないことにもつながります。

Sandboxの例外を検討する前に、SSL復号除外が本当に必要かを慎重に判断することが重要です。

Standard Cloud SandboxとAdvanced Cloud Sandbox

Cloud Sandboxには大きく2種類のライセンスがあります。

Standard Cloud Sandbox

• EXE
• DLL

などの実行ファイルを中心とした検査を行います。

また、検査できるファイルサイズにも制限があります。

Advanced Cloud Sandbox

Standardの機能に加え、

• Microsoft Office
• PDF
• ZIP
• RAR
• スクリプト

など、多くのファイル形式を検査できます。

一般的な企業でやり取りされるOfficeファイルやPDFを保護したい場合は、Advanced Cloud Sandboxを前提として設計するケースがほとんどです。

Sandboxの解析方式

Sandboxでは、未知のファイルを検知した際の動作を選択できます。

代表的な方式として、

• Quarantine
• Allow and Scan

があります。

Quarantineでは、解析が完了するまでダウンロードを保留し、問題がないことを確認してからユーザーへファイルを提供します。

一方、Allow and Scanでは、ユーザーへのダウンロードは許可し、バックグラウンドでSandbox解析を実施します。

そのため、Sandboxを利用するだけで必ず通信遅延が発生するわけではありません。

解析方式や運用方針によって、ユーザーへの影響は大きく変わります。

設計で重要なのは「例外」をどう扱うか

Malware ProtectionやSandboxは、基本的にはすべての対象通信を検査することが推奨されます。

しかし、業務システムやソフトウェア配布サーバなど、十分に信頼できる通信については例外を設計することもあります。

ここでいう例外には、

• Zscalerを経由させないトラフィックバイパス（Client ConnectorやPACファイルなど）
• Zscalerは経由するが、Sandboxポリシーで検査対象外とする例外

という2つの考え方があります。

例えば、大量の更新プログラムを配布するような通信では、要件によってはトラフィック自体をZscalerへ送らない構成を採用することもあります。

一方で、安易に例外を増やすことは推奨できません。

まずは検査を基本とし、業務影響や性能要件を十分に確認したうえで、必要最小限の例外だけを設計することが重要です

設計で重要なのは「制御」ではなく「検査」

Firewall Controlでは、通信を許可するかを判断します。

Cloud Application Controlでは、どのアプリケーションをどのように利用するかを判断します。

DLPでは、送信しようとしているデータそのものを検査します。

一方、Malware ProtectionとSandboxは、通信の中に脅威が含まれていないかを検査するエンジンです。

つまり、「どのように制御するか」というよりも、「どこまで検査するか」「どこを例外とするか」を設計する機能

と考える方が実態に近いでしょう。

おわりに

Malware ProtectionとSandboxは、ZIAのインラインプロセスを支える重要な脅威検査エンジンです。

通信内容に応じて必要なタイミングで検査が実行されるため、Firewall ControlやURL Filteringのようなポリシー処理とは少し性質が異なります。

設計者として重要なのは、

• SSL Inspectionがファイル検査の前提となること
• StandardとAdvanced Cloud Sandboxで検査対象が異なること
• QuarantineとAllow and Scanで運用方針を選択できること
• 基本は検査を行い、例外は必要最小限に留めること

です。

Malware ProtectionやSandboxは、細かなルールを設計する機能というより、「信頼して利用する検査エンジン」です。

その役割を理解したうえで、SSL Inspectionや例外設計と組み合わせて利用することが、効果的なセキュリティ設計につながります。

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

管理人

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