【SSE】[Zscaler] [ZIA] [設計] [全体] PSEへのトラフィック転送方法の選択肢と解説
buffoon
SASEナビ
【SSE】[Zscaler] [ZIA] [設計] [個別] [インライン] URL Filtering
buffoon
はじめに
前回の記事では、Cloud App Controlについて紹介しました。
Cloud App Controlで制御されなかった通信は、次にURL Filteringで評価されます。
URL Filteringは、その名のとおりURLを条件にアクセスを制御する機能です。
一見するとシンプルな機能ですが、Zscalerが提供するURLカテゴリや独自のURLカテゴリを組み合わせることで、柔軟かつ運用しやすいアクセス制御を実現できます。
本記事では、以下についてに解説します。
- URL Filteringの役割
- 利用できるクライテリア
- 利用できるアクション
- URLカテゴリの考え方
- 設計時に意識したいポイント
URL Filteringとは
URL Filteringは、URLやURLカテゴリを利用してアクセス制御を行う機能です。
Cloud App Controlが「どのクラウドアプリケーションで何をしようとしているか」を判断するのに対し、URL Filteringは「どのURLへアクセスしようとしているか」を基準に評価します。
Cloud App Controlで制御されなかった通信は、そのままURL Filteringへ引き継がれ、許可・拒否・注意などのアクションが実行されます。
業務利用するSaaSはCloud App Controlで制御し、それ以外の一般的なWebサイトや未知のサービスはURL Filteringで制御するという役割分担が基本となります。
URL Filteringで利用できる主なクライテリア
URL Filteringでは、複数の条件を組み合わせてポリシーを作成できます。
代表的なクライテリアは以下のとおりです。
- URL Categories
- Users / Groups / Departments
- Location Groups / Locations
- Time
- Request Methods
- Protocols
- Device Groups / Devices
- Device Trust Level
- User Agent
- User Risk Profile
実際の設計では、URL Categories、Users / Groups / Departments、Locationsを中心に利用するケースが多くなります。
URL Filteringで利用できるアクション
URL Filteringでは、主に以下のアクションを利用できます。
- Allow
- Block
- Caution
Allowは通信を許可します。
Blockは通信を拒否し、必要に応じてユーザへブロック画面を表示できます。
Cautionは警告画面を表示し、ユーザへ注意喚起を行ったうえで通信を継続させるアクションです。
利用シーンに応じて、業務への影響を抑えながら段階的な運用を行うこともできます。
URL Filteringは最後に「暗黙の許可」が存在する
URL Filteringでは、どのルールにも一致しなかった通信は、最後に暗黙的にAllowされます。
そのため、「定義済みカテゴリ以外はすべて拒否したい」という設計を行う場合は、最後にBlockルールを配置する必要があります。
許可したいカテゴリだけを定義しても、それ以外が自動的に拒否されるわけではありません。
この動作は設計時に理解しておきたいポイントです。
SSL Inspectionとの関係
URL FilteringはURLを利用して制御する機能ですが、SSL Inspectionを実施していない場合は取得できる情報が制限されます。
- SNI
- 接続先ホスト名
などは取得できますが、
- URLパス
- HTTPメソッド
- リクエスト内容
などは取得できません。
そのため、URLパス単位での制御や詳細なURL判定を行いたい場合は、SSL Inspectionが必要になります。
Cloud Application Controlと同様、SSL Inspectionによって取得できる情報が増えることで、より精度の高い制御が可能になります。
URLカテゴリを利用した制御
URL Filteringでは、大きく2種類のURLカテゴリを利用できます。
- Zscalerが提供する標準URLカテゴリ
- ユーザが作成するカスタムURLカテゴリ
標準URLカテゴリでは、
- Social Networking
- Gambling
- Shopping
- Streaming Media
など、Zscalerが分類したカテゴリをそのまま利用できます。
例えば、「SNSは業務時間中だけ禁止」、「ギャンブルサイトは常時拒否」といった設計が容易に実現できます。
一方、企業独自の要件についてはカスタムURLカテゴリを利用します。
カスタムURLカテゴリでは、
- URL（前方一致）
- キーワード（部分一致）
などを利用して独自のカテゴリを作成できます。
社内で利用する特定サイトや、業務アプリケーションなどをまとめて管理したい場合に有効です。
Parent Categoryは理解しておきたい
カスタムURLカテゴリには、登録したURLをZscalerの標準カテゴリにも所属させるかどうかを制御する設定（Parent Category）があります。
例えば、「facebook.com」を独自カテゴリへ登録した場合でも、Parent Categoryを維持するとSocial Networkingカテゴリにも所属したままになります。
この状態で、以下のようなルールを書いた場合、ルールの順番によってはSocial NetworkingのAllowが先に一致し、期待したBlockにならないことがあります。
- Social Networking：Allow
Custom Category：Block
そのため、Parent Categoryへ残すか、独自カテゴリへ移動するかを理解したうえで設計する必要があります。
この考え方については、URLカテゴリの記事でさらに詳しく解説します。
設計で重要なのは「カテゴリ」を育てること
URL Filteringでは、SSL Inspection同様ルールを増やしていく設計はおすすめできません。
例えば、新しいWebサイトを許可するたびにルールを追加していくと、ルール数が増え、優先順位や影響範囲の管理が難しくなります。
おすすめしたいのは、ルールは固定し、URLカテゴリを育てていく（設定していく）運用です。
例えば、
- Custom URL Category – Allow
- Custom URL Category – Caution
- Custom URL Category – Block
- Zscaler URL Category – Allow
- Zscaler URL Category – Caution
- Zscaler URL Category – Block
というように、最低限のルールをあらかじめ用意しておけば、運用時はURLカテゴリの追加・削除だけで対応できます。
この構成であれば、Parent Categoryを過度に意識する必要もなく、ルール数を増やさずに長期間運用できます。
SSL Inspectionの記事でも紹介したように、「ルールを増やす」のではなく、「カテゴリを育てる」という考え方は、URL Filteringでも非常に重要です。
おわりに
URL Filteringは、URLを条件にアクセスを制御する基本的なセキュリティ機能です。
しかし、実際の設計では単純にURLを並べるのではなく、URLカテゴリやカスタムURLカテゴリを活用することで、保守性の高いポリシーを構築できます。
- SSL Inspectionとの連携
- Parent Categoryの考え方
- ルールではなくカテゴリを育てる運用
を理解することで、長期的に管理しやすい設計が実現できます。
➡【次の記事へ】【SSE】[Zscaler] [ZIA] [設計] [個別] [インライン] File Type control
自称SASEエンジニアです。 2児の父親をやりながら、日々エンタープライズ向けの次世代ネットワークインフラと格闘しています。一日一投稿を目標に投稿頑張りますので、是非読んでください！
