ZIAポリシー（実際の事例記事）

2026-01-23 編集

編集 完了 2026-01-22

Zscaler インターネット アクセス (ZIA)は、組織のトラフィックにインラインで実行されるセキュリティおよびトラフィック転送サービスです。 ZIAは、構成が簡単な詳細なポリシーを使用してトラフィックを制御します。

本書では、管理者が利用可能なポリシー構成領域について参照します。 ZIAポリシーの構成方法を理解することは、環境をセキュリティで保護し、ユーザー エクスペリエンスを維持し、生産性をサポートするために非常に重要です。

URLフィルタリングおよびクラウドアプリコントロールは、ユーザーアクセスを許可または制限することで、特定のタイプのWebコンテンツへの露出を抑制します。 適切に構成されたポリシーは、エンド ユーザーまたはそのエクスペリエンスを中断することなく、Webコンテンツのアクセスを制限または許可します。

詳細については、ポリシーの強制適用の理解を参照してください。

概要

次のセクションでは、Zscalerセキュリティ ポリシーの設定における重要な概念の概要を説明します。

Zscalerサービス モジュール

ZIAは、フル機能のインライン プロキシであるZIA パブリック サービス エッジを使用して、あなたの組織に出入りするトラフィックのポリシーを検査および強制適用します。 ZIA Public Service Edgeは、ZIA Public Service EdgeのWebおよびファイアウォール モジュールでトラフィック インスペクションとポリシー実行を処理するシングルスキャン マルチアクション(SSMA)テクノロジーを備えています。

SSMAを使用することで、インスペクションエンジンは1回のパスですべてのコンテンツをスキャンできます。 パケットは、高度に最適化されたカスタムサーバーの共有メモリに配置されます。 ZIA Public Service Edge上のすべてのCPUは、これらのパケットに同時にアクセスします。 各機能に専用のCPUを使用すると、物理アプライアンスまたは仮想アプライアンスのチェーン モデルを使用する代わりに、すべてのエンジンがパケットを同時に検査できます(各セキュリティ サービスがパケットを順番に処理し、レイテンシーが増加します)。 SSMAテクノロジーは、さまざまなセキュリティ エンジンに基づくZscalerサービス ポリシーを最小限のレイテンシーで適用します。

SSMAインスペクション プロセスが完了すると、ZIA パブリック サービス エッジは特定の優先順位を使用してポリシーを実行します。 それぞれのZIA Public Service Edgeには、ポリシーを適用するための2つのメインモジュール(Web モジュールとファイアウォール モジュール)があります。

大まかに言うと、モジュールを通じてトラフィック フローがどのように行われるかは次のとおりです。

• アウトバウンドWebトラフィック。 ZIA Public Service Edgeは、ポリシー評価のために、アウトバウンド インターネットWebトラフィックを組織からファイアウォール モジュールに送信します。 トラフィックがファイアウォール ポリシーに違反している場合、トランザクションはブロックされます。 トラフィックがファイアウォール ポリシーに違反していない場合は、ポリシー評価のためにトラフィックをWebモジュールに送信します。 Webモジュールでは、トラフィックがWebポリシーに違反すると、トランザクションがブロックされます。 トラフィックがどのWebポリシーにも違反しない場合、トランザクションはインターネットに許可されます。
• アウトバウンド非Webトラフィック。 ZIA Public Service Edgeは、ポリシー評価のために、80/443以外のポート(または他のHTTP/HTTPSポート)宛てのアウトバウンド非Webトラフィックを直接ファイアウォール モジュールに送信します。 トラフィックがファイアウォール ポリシーに違反している場合、トランザクションはブロックされます。 トラフィックがファイアウォール ポリシーに違反していない場合は、インターネットへのトラフィックが許可されます。
• インバウンドWebトラフィック。 ZIA Public Service Edgeは、ポリシー評価のためにHTTP GET/POST要求に応答して、インターネットからのインバウンドWeb トラフィック(ポート80/443のHTTP/HTTPSトラフィック)をWebモジュールに送信します。 トラフィックがWebポリシーに違反している場合、トランザクションはブロックされます。 トラフィックがどのWebポリシーにも違反していない場合は、組織へのトラフィックが許可されます。

Webトラフィックがファイアウォール ポリシーに違反した場合、ファイアウォール インサイト ログおよびWebインサイト ログの両方で、トラフィックがブロック済みであることが示されます。 ただし、トラフィックがファイアウォール ポリシーを通過しても、後でWebポリシー違反によりブロックされた場合、ファイアウォール解析ログはトラフィックが許可されていることを示しますが、Web解析ログはブロックされたことを示します。

Webトラフィックは、最初にファイアウォールモジュールで評価され、ブロックされていない場合はWebモジュールに送信されます。 組織のWeb ポリシーでトランザクションが許可されているが、ファイアウォール ポリシーによってブロックされている場合、Zscalerサービスはファイアウォール ポリシーを適用します(つまり、トラフィックがブロックされます)。 たとえば、Webクラウド アプリ コントロールポリシーでアプリケーションのBox.netが許可されていても、ファイアウォール ポリシーでブロックされている場合、Zscalerサービスはトランザクションをブロックします。

ファイアウォール モジュールがユーザーのHTTPまたはHTTPSトランザクションをブロックしない場合、ZIA パブリック サービス エッジはポリシー適用のためにトラフィックをWebモジュールに送信します。

ZIA パブリック サービス エッジがWebトラフィックを受信すると、Webモジュールがトラフィックを検査し、あなたの組織のWebポリシーを適用します。 Webモジュールは、Webトラフィックのタイプ、トラフィックが暗号化されているかどうか、およびSSLインスペクションが有効か無効かに基づいて、特定の順序でポリシーを適用します。 サービスは、ポリシー違反を検出すると、ただちにトランザクションをブロックし、他のWebポリシーを適用しません。

Webモジュール ポリシーは、以下のオペレーション順で強制適用されます。

• ファイアウォール
• SSLインスペクション
• 高度な脅威保護（ATP）
• マルウェア／アンチウイルス（AV）
• クラウドアプリコントロール
• URLコントロール
• ファイル タイプコントロール
• 情報漏洩防止（DLP）
• Cloud Sandbox

画像を表示.

ポリシーの強制適用例

Zscalerサービスがさまざまなシナリオでポリシーを適用する方法を理解することは、特定のポリシーがユーザーのトラフィックでトリガーされる理由とトリガーされない理由を判断するのに役立ちます。 また、組織のトラフィックが期待どおりにセキュリティで保護されることも保証されます。

次の例は、ポリシーがトラフィックに適用される方法を示しています。

例 1

組織Xには、次のポリシーがあります。

• ファイアウォール ポリシーは、クラウド アプリケーションBox.netを許可します。
• Webポリシーは同じアプリケーションをブロックします。

組織のユーザーがブラウザーを開き、アプリケーションBox.netをリクエストすると、そのユーザーはブロック済みとなります。 ファイアウォール モジュールがトラフィックを許可しても、WebモジュールはWebポリシーを検査して適用します(Box.netをブロックするため)。

例2

組織Yには次のポリシーがあります。

• ファイル タイプ コントロール ポリシーは、ユーザーが企業ネットワークからPDFを送信できないようにブロックします。
• DLPポリシーは、米国のソーシャル セキュリティ番号(SSN)を含む文書をブロックし、ZscalerサービスがSSNの送信試行を検出した際に監査役へ通知を送信することを指定します。

組織のユーザーがSSNを含むPDFを送信しようとした場合、ファイル タイプ コントロール ポリシーによりPDFが許可されていないため、サービスはトランザクションをブロックします。 DLPポリシーはトリガーされず、サービスは、ユーザーが組織からSSNを送信しようとしたことを監査役に通知しません。

展開ガイド

できるだけ簡単にあなたのニーズを満たすポリシー戦略を構築します。 ほとんどの組織は、URLフィルタリング機能とクラウド アプリ制御機能を同時に使用しています。

既知の事項のリストを収集する

ポリシーを策定する前に:

• レガシー システム上の既存のフィルター ポリシーを確認します。
• 環境に関して既知の情報を評価してください。
• 利用可能な定義済みURLカテゴリーおよびクラウドアプリカテゴリーをご確認ください。

この確認を使用して、絶対に許可済み、ブロック済み、または制限付きとする必要がある宛先（または宛先のタイプ）のリストを作成してください。

一般的にブロックされる宛先タイプには次のものがあります。

• 法的責任(アダルト コンテンツ、ギャンブル、法律違反/不正コンテンツなど)。
• プライバシー リスク(セキュリティ、その他の暗号化されたコンテンツ、スパイウェア/アドウェア)。
• 潜在的な情報漏洩の宛先（ファイル ホスティング、Webメール、P2P など）、組織によって特定に承認されたものを除く。
• ソーシャル メディアまたはストリーミング メディア サービス。

一般的に許可済みの宛先には次のものが含まれます。

• 組織によって承認され、使用されるアプリケーション。
• ソフトウェアおよびオペレーティング システムの更新サービス。
• 組織に特定のベンダーおよびパートナー。

最適なツールの選定方法

どのトラフィックをコントロールすべきかを把握することは、適切なポリシータイプの選択に大きく寄与します。 既知の知のリストを調べ、ニーズを最も効果的に満たすように適切なポリシー タイプを分類します。 タスクに最良のツールを見つけることで、ポリシーの構築と管理が大幅に容易になります。

Zscalerでは、以下のようなポリシーを導入することを推奨します。

• クラウド アプリコントロール。 アプリケーションの既知のリストへのユーザー アクセスを明示的に許可、ブロック、または制限する必要があるとき、またはユーザー アクセスの側面を制御する必要がある場合(たとえば、ビュー アクセスは許可するがアップロード アクセスは許可しない、メールを受信するが送信しないなど)は、クラウド アプリ制御を使用します。
• URLフィルタリング。 URLフィルタリングは、デフォルトのアクセス制御スペースです。 URLフィルタリングを使用して、ユーザーがURLカテゴリーに到達できないようにするポリシー、または特定の宛先(事前構築済みまたはカスタム定義のカテゴリー)へのアクセスを許可するポリシーを作成します。 URLフィルタリングでは、詳細な基準を使用してアクセスの詳細を微調整できます。
• ファイル タイプ コントロール。 ファイル タイプのコントロールは、許可された宛先でのユーザー ファイル タイプ アクセスを制限するポリシーを作成し、Webブラウジングするのに最適です。 ファイル タイプのコントロールは、ある方向または別の方向で共有できるファイルを制限します。 ファイル タイプのコントロールを使用すると、ユーザーは組織のセキュリティ コントロールを維持しながらWebコンテンツを楽しむことができます。
• ファイアウォール。 ファイアウォール ポリシーは、すべてのWeb以外のトラフィックのアウトバウンド接続を制御するのに最適です。例：DNS、SSH、RDP、さまざまなUnited Communications as a Service(UCaaS)サービスなど。 高度なファイアウォール サブスクリプションでは、ファイアウォールを使用して、特定のネットワーク サービス(ポートとプロトコル)またはDPIアプリケーション識別(ネットワーク アプリケーション)によってトラフィックを制御できます。 高度なファイアウォール サブスクリプションでは、最初はWebとして開始され、他のトラフィック タイプであるトラフィックを識別し、関連するファイアウォール ルールを適用することもできます。

さらに、Web宛先でのトラフィックに関するルールを定義できます（例えば、IPアドレスのブロッキングや、FQDNまたはワイルドカードFQDN宛先へのトラフィックの許可など）。

例

ユーザーがアダルト コンテンツにアクセスできないようにするには、URLフィルタリング ポリシーを使用して、必要なURLカテゴリーをブロックします。

アップロードをブロッキングしながらGitHubへの閲覧アクセスを許可するには、システム開発カテゴリ配下のクラウド アプリのポリシーを使用してください。

PDFおよびMicrosoft文書のアップロードまたはダウンロードをブロッキングしつつ、ユーザーがエンターテイメント サイトを閲覧できるようにするには、エンターテイメントURLカテゴリーのファイル タイプ コントロール ポリシーを使用し、制限するファイル タイプを選択してください。

粒度を決定する

使用するポリシー タイプを特定した後、ルールに一致するトラフィックをさらに絞り込むために、特別な条件が必要かどうかを判断します。 ルールがどこからでも接続するすべてのユーザーに適用されない場合、ポリシーはどのようにしてトラフィックを適切に識別する必要がありますか? 各ポリシー タイプには固有の条件があります。

Zscalerでは、条件の選択に関する次のガイダンスを推奨しています。

• 特定の宛先（アプリまたはカテゴリー）。 適切なポリシー タイプを使用して、選択した宛先を絞り込みます。
• 特定のユーザー。 条件にグループまたは部署を使用すると、ユーザー ディレクトリー スペース内にコントロールが配置されます。 テストまたはアクセスが少数の(4人未満)ユーザー セットに制限されていない限り、特定のユーザーの使用は避けてください。
• 送信元ロケーション。 個々のロケーションのポリシーを作成することも可能ですが、ロケーション グループの方が管理が容易です。 新しいロケーションをロケーション グループに追加すると、該当するすべてのポリシーにロケーションが直ちに追加されます。
• 時間。 データ センターの時間に基づいてアクセスを設定します。 たとえば、時間を使用して、昼食時に特定のことを許可したり、特定の関数が営業時間外や週末に利用できないようにしたりします。
• 特定のデバイス グループ。 ユーザー デバイスでZscaler Client Connectorを活用することで、特定のデバイスのオペレーティング システムをターゲットとしたポリシーを構成できます。 あるいは、Zscaler Client Connector以外の方法でトラフィックをフィルター処理するポリシーを設定することもできます。
• デバイス信頼レベル。 Zscaler Client Connectorは、デバイスのポスチャを継続的に評価し、デバイスのステータスを返します。 ZIAのデバイス信頼レベルは[高]、[中]、[低]で、設定可能な特定のデバイス ポスチャー プロファイルに関連付けられています。
• モバイル管理者。 これらの信頼レベルに基づいて許可およびブロックする明示的なルールを作成できます。

高度なポリシー設定を構成する

ZIA管理ポータルには、複数の高度なポリシー設定が用意されています。 ポリシー>URLとクラウド アプリ制御>高度なポリシー設定。 この設定はすべてのトラフィックに影響します。

設定の説明は以下の通りです。

• 児童インターネット保護法（CIPA）コンプライアンス。 無効に設定します(K-12教育の場合を除く)。 この機能により、K-12教育ベースのお客様は、CIPA準拠の環境を構成できます。
• 疑わしい新規ドメインのルックアップ。 有効に設定します。 この機能は、ライブになってから数時間以内に識別された新規登録および観測されたドメイン、および非アクティブな新しく復活したドメインに対して、ユーザーに高度な保護を提供します。 新しいドメインまたはアイドル状態のドメインは、多くの場合、安全でなく、潜在的に悪意があると見なされます。 これらを(URLポリシー内で)ブロックすると、全体的なセキュリティ ポスチャが改善されます。
• AI/MLベースのコンテンツ分類。 有効に設定します。 この機能により、サービス用AI/MLは、コンテンツに基づいて未分類のWebサイトのトラフィックを分類できます。 これは、トラフィックが一般的にブロックされるURLスーパー カテゴリーに収まるかどうかを識別し、適切なポリシーを適用するのに役立ちます。
• 埋め込みサイトの分類。 有効に設定します。 この機能は、他のサイトに埋め込まれたサイトにURLフィルタリングポリシーを適用します。 これは通常、翻訳サービスを使用してフィルター処理をバイパスしようとするユーザーを停止するために使用されます。
• SafeSearch。 有効に設定します。 この機能は、多くの上位の検索サイトに安全な検索の実施を適用します。 この機能を使用するには、トラフィックのSSLインスペクションを有効にする必要があります。
• アイデンティティーベースのブロックのオーバーライド。 オプションに設定します。 この機能は、別の方法でブロックされた宛先(URLポリシーで構成されている)にアクセスするための認証をユーザーにプロンプトします。 通常は有効になっていません。
• Microsoft推奨のMicrosoft 365クリック実行構成。 有効に設定します。 この機能により、Microsoft 365トラフィック用のSSLインスペクション除外とクラウド アプリおよびファイアウォール ポリシーが自動的に有効になります。 ポリシーの除外をカスタマイズするには、SSLインスペクション、クラウド アプリ制御、ファイアウォール ポリシーを確認して上位のポリシーを作成するか、このオプションを無効のままにしてMicrosoft 365トラフィックを別の方法で管理します。 詳細は、MicrosoftワンクリックOptionsについてを参照してください。
• UCaaSサービス。 環境で使用する場合は、サービスごとに有効にします。 この機能は、それぞれのサービスが動作するためのSSLインスペクションとアクセス制御ポリシーを管理します。

詳細設定を構成

管理 > 詳細設定 に移動して、追加のグローバル構成Optionsを表示します。 次のセクションでは、選択したオプションを確認します。

• URLフィルタリングへのカスケード。 無効に設定します。 この機能により、クラウド アプリ制御によって許可されたトラフィックは、アクションが実行される前にポリシー評価のためにURLフィルタリングにフローできます。 この設定は一般的には使用されず、多くの場合、解決するよりむしろ多くの問題が発生します。 これはグローバル オプションであるため、機能を有効にする前にポリシー構造を考慮してください。 この機能が必要な場合は、まずファイアウォール コントロールを使用してニーズを満たします。
• 未認証トラフィック用ポリシー。 有効に設定します。 条件にユーザーと部署を指定するポリシーの場合、未認証のトラフィックにサービスが適用するルールを指定できます。 この機能を有効にすると、ロケーションが認証を適用したときにトラフィックが認証されなかった理由に基づいて、特定のユーザー名がログ記録されます。 詳細は、「未承認トラフィックのポリシーの設定」を参照してください。
• ドメイン フロンティングをブロックします。 有効に設定します。 ドメインフロンティングを利用することで、クライアントは、リクエストのホストヘッダーに設定されたドメインとは異なるドメインへのTLS接続でリクエストをフロンティングすることにより、HTTPSリクエストの本来の宛先を検閲者やネットワークセキュリティフィルターから隠すことが可能です。これは、両方が同じコンテンツデリバリーネットワーク(CDN)サービスでホスト済みの場合に適用されます。 攻撃者は、ドメイン フロンティングを使用して、不正なサイトへのHTTPSリクエストを、正常なサイトへのTLS接続内に隠します。 この機能を使用し、SSLインスペクションを実施することで、Zscalerはトラフィックに対するドメイン フロンティングを評価し、検出されたものをブロックできます。 詳細については、ドメインフロンティング技術の分析をご参照ください。 CDN経由による悪用および隠蔽。

画像を表示。

ポリシーの構築

ポリシーをステージングする際は、セキュリティの観点から開始し、今後の拡張性と管理を考慮してください。 次のセクションでは、URLフィルタリング、クラウド アプリ制御、ファイル タイプのコントロール、ファイアウォールおよびDNSコントロールのベースライン推奨事項を確認します。

URLフィルタリング ポリシー ベースライン

URLフィルタリング ポリシーは、通常、設定されているポリシーの中で最も単純です。 許可するかブロックするかに関するカテゴリーは一般的に明らかであり、ポリシー ロジックは理にかなっています。 URLフィルタリングの最善のアプローチは、グローバル＞特定＞グローバルの順にポリシーを設定することです。 言い換えれば次の通りです。

1. グローバル ルールから開始します。 通常ブロックされる宛先を許可し、通常許可される宛先をブロックするルールを作成します。
2. 特定のユーザーおよびユーザー グループに適用される送信元ユーザー、グループ、ロケーションおよび宛先に固有のルール（許可またはブロック）を構成します。
3. 全員に適用されるルールを作成し、デフォルトの（記述されていない）すべてを許可するルールの前に不要なトラフィックをブロックします。

次のテーブルは、効果的な開始ポリシー戦略チェックリストを示しています。

ルール #

目的

条件（最小限を記載）

アクション

1

グローバル 特定 許可。
既存の許可リストを完全に移行しないでください。 マイグレーション対象を決定する前に、Zscalerのエンジンをテストします。

カテゴリ： カスタム例外（特定のFQDN宛先を許可するために維持され、それ以外はポリシーによってブロック済み）。

許可

2

グローバル 特定 ブロック。
既存のブロックリストを完全に移行しないでください。 マイグレーション対象を決定する前に、Zscalerのエンジンをテストします。

カテゴリ： カスタムのブロック（通常はポリシーで許可済みとなる宛先に対して適用されます）。

ブロック

3

グローバル セキュリティに基づくブロックです。

カテゴリ： 新規登録および観測されたドメイン、P2Pサイト、アノニマイザー、コンピューターのハッキング、著作権侵害、カスタム暗号化コンテンツ、新しく復活したドメイン、その他のセキュリティ、スパイウェア/アドウェア。

ブロック

4+

ユーザー グループに特定されたポリシー。
必ずしもセキュリティ関連ではありませんが、ポリシーを無効化した状態でステージングし、開始構造を構築することを推奨します。

カテゴリ： 省略可。
ユーザー グループ： 必要に応じて。

許可またはブロック

5+

ロケーション グループに特化したポリシーです。
ユーザー属性を活用してポリシーを構築することが優先されます。 ポリシーはどこでもユーザーに従います。 ロケーションによるポリシーが必要な場合があり、構造が必要です。

カテゴリ： 省略可。
ロケーション: 必要に応じて。
ロケーション グループ： 必要に応じて。

許可またはブロック

6

グローバルカテゴリーブロック。
上記で許可されていないグループにアクセスできない、特定のURLカテゴリーを選択します。

カテゴリ: 望まれた通りに。

ブロック

デフォルト

デフォルト Allow-all。
このルールは書き込まれておらず、URLフィルタリング ポリシーのデフォルト アクションです。 前のポリシーに一致しないものはすべて許可され、次のポリシー モジュールによって評価されます。

書き込まれていない。 条件なし。 構成不可。

許可

ポリシー ルール セットの例を次に示します。

画像を参照してください。

すべての顧客には、特定の環境およびセキュリティ上の懸念に適した一連のポリシーが必要です。 ここでのポリシー設計の例では、次の条件が作成されます。

• 特定は（オーバーライド）を許可します。 Zscalerのブロック済みカテゴリーをオーバーライドするルールを作成します。
• 特定のブロック: いかなる状況下でも許可済みとならないカテゴリーを作成してください。
• 特定のセキュリティブロック: セキュリティ チームの要件に基づき、ユーザー アクセスを制限するブロック ルールを作成します。
• きめ細かなコントロール: 企業固有のきめ細かなアクセス制御要件に対応するため、許可ルールおよびブロックルールを作成します。
• グローバルブロック： 以前に未対応のカテゴリー(または顧客が暗黙的な許可を上書きする場合はすべてのカテゴリー)に対して、ブロック ルールを作成します。

お客様の要件に対応したポリシーの作成についてご相談される場合は、Zscalerアカウントチームまでお問い合わせください。

クラウド アプリ コントロール ポリシー ベースライン

クラウド アプリ コントロールの推奨されるアプローチは、可能な限り戦略的かつ選択的であることです。 明示的に既知のニーズのアプリケーションと条件に一致するルールを構成し、不明なものはURLフィルタリング ポリシーに任せます。 何らかの形式で許可、ブロック、分離または制御する必要がある場合は、クラウド アプリ制御ルールを作成します。 それ以外の場合は、他の場所でアクセスを制御します。

ルールは上から下へ適用されるため、エントリーはより細分化されたものから、特定性の低いものへと移行します。 あるチームが特定のツールにアクセスする必要があり、他のチームをブロックする必要がある場合は、承認された使用グループに固有のアクセス ルールと、他のグループをブロックする別のルールを作成します。

不確かな場合は、URLフィルタリング ポリシーに従ってください。

一般的なガイダンス

リスク プロファイル機能を活用することで、アプリケーションを個別に調査および指定することなく、アプリケーションへのアクセスをコントロールできます。 リスク インデックスが4または5のアプリケーションのリスク プロファイルを未承認ステータスで作成すると、そのプロファイルをさまざまなクラウド アプリケーション カテゴリーに適用し、危険なアプリケーションへのアクセスをブロックまたは制限できます。

詳細はこちら：SaaSセキュリティ インサイトをご参照ください。

以下は、リスク プロファイルの例です。

1. 任意のをクラウド アプリケーション用に選択してください。
2. [クラウド アプリケーション リスク プロファイル]の設定を選択してください。
3. ユーザーまたはロケーション条件を選択してください。

画像を表示。

4. ブロックまたは分離をアクションとして選択してください。

ポリシーの例：

画像を参照してください。

クラウドアプリカテゴリ別の推奨事項

以下は、各クラウドアプリカテゴリに対する推奨事項です。

• コラボレーションとオンラインミーティング: 一般的に含まれるものは、Microsoft、Google、Zoom、および WebEx サービスです。
• DNS Over HTTPSサービス： 特定のブラウザーでデフォルトで利用されているか、エンド ユーザーによって設定されているかに関わらず、共通のDNS Over HTTPS。 環境内でZscalerのDNS制御機能を使用する場合、DNSリクエストが正しくキャプチャおよび処理されるように、これらのサービス(ここで、またはDNS制御内のより粒度の高いセキュリティを使用して)をブロックすることを推奨します。
  • ファイル共有: 多くの一般的およびあまり知られていないファイル共有クラウド アプリケーションが含まれています。 一般的な推奨事項は、クラウド アプリ制御内で組織が選択/承認したファイル共有サービスへのアクセスを許可し、ファイル ホスティング カテゴリーのURLフィルタリング ポリシーを通じて他のサービスをブロックすることです。
  • ファイル共有内で作成されたルールは、表示が許可済みの場合に、アップロードトラフィックを許可またはブロックするための追加のコントロールを提供します。 これは、サードパーティーのサイトからファイルを表示(ダウンロード)するためのユーザー アクセスを許可すると同時に、同じサイトへのファイルのアップロードを防ぐのに役立ちます。 SSLインスペクションは、追加機能を動作させるために必要です。
• ITサービス： 開発、設計、SaaSホスト、IDプロバイダー（IdP）、セキュリティ情報およびイベント管理システム（SIEM）、OSアップデート、その他のサービス、さらにGoogle、Microsoft、WebExのログインサービスのための共通スペースです。 このカテゴリーは、関連するサービスのテナント プロファイルを使用するように構成できます。
• 生産性向上およびCRMツール： 組織内で使用されている生産性ツールが含まれます。 一般的な例としては、Microsoft、Google、Salesforce、ServiceNowなどがあります。 このカテゴリーは、関連するサービスのテナント プロファイルを使用するように構成できます。
• ソーシャル ネットワーキング: 人気のあるソーシャル ネットワーキングおよびメディア アプリケーション（Facebook、Discord、Reddit、TikTokなど）が含まれています。 このカテゴリーでは、サービスへのアクセスと、ユーザーがサービスに投稿する機能をきめ細かく制御できます。 SSLインスペクションは、投稿を制御するために必要です。
• ストリーミング メディア: 一般的なストリーミング プラットフォームが含まれています。 これらのアプリケーションへのアクセスを制御すると、帯域幅の消費と生産性の損失が減少します。 一般的なポリシーでは、YouTube（+テナント プロファイルのオプション）およびその他の承認されたメディア サービスをトレーニング目的で許可した後、URLフィルタリング ポリシーによって音楽＆オーディオ ストリーミングおよびビデオ ストリーミングのカテゴリーをさらに制限します。
• システム開発： 開発に関連する一般的な開発リポジトリ、ツール、およびトレーニングサイトが含まれています。 アップロード権限を制御するルールを構成して、コンテンツをブラウズのに対してコンテンツを共有および保存できるかどうかユーザーをさらに制限することができます。 ここに記載されていないサービスは、ITサービス カテゴリーの下にあります。
  • Webメール: Zscalerの推奨事項は、組織によって選択されたWebメール サービスを明示的に許可し、企業環境内のユーザーおよびデバイスに対して、承認されていないWebメール サービスへのMailの元のインターフェイスですの送信または添付ファイル付きMailの元のインターフェイスですの送信を完全に制限することです。 SSLインスペクションは、許可されたWebメール サービスに強く推奨され、送信を制限するために必要です。

ファイル タイプ コントロール ポリシー ベースライン

インターネット サービスへのユーザー アクセスを許可しながらも、不要なファイルのアップロードおよびダウンロードを防止することで組織のセキュリティを維持するために、ファイル タイプ コントロールを適切に実装する必要があります。

Zscalerでは、想定されるファイル タイプを含まないURLカテゴリーへのファイルの送受信をコントロールするポリシーの設定を推奨します。

例

• Microsoft 365文書がエンターテイメント、ギャンブル、および生産性損失のサイトとの間でアップロードまたはダウンロードされることを禁止します。
• アプリケーションがエンド ユーザー マシンを自動的に更新する信頼されたベンダーからの実行ファイルのダウンロード（例：.exe、.cab、など）を許可します。
• 承認されたサイトを除くすべてのサイトからの実行ファイルのダウンロードを警告またはブロックします。
• 設計チームから無認可の宛先へのファイル（例：ZIP、.cad、.dwg、.stl、検出不能なものなど）のアップロードをブロックします。

アクセスを厳格に制限し、ユーザー エクスペリエンスに重大な影響が生じても問題ない場合を除き、Webサイトで一般的に使用されるファイルはブロックしないでください。

次のテーブルに、ファイル タイプ コントロール ポリシーのセットの例を示します。

ルール #

目的

ユーザー／グループ／部署

ファイル タイプ

URLカテゴリー

アップロード／
ダウンロード

アクション

1+

業務上の例外

特定のグループ

例外で必要とされるファイル タイプのみ（例：PDF、アーカイブ、またはビジネスパートナーからのMicrosoft 365ドキュメント）。
自動更新するアプリケーション(OS、ブラウザーなど)。

特定の信頼済みサイトのカスタム カテゴリー。

ダウンロードおよび／またはアップロード

許可

2以上

IT管理者によるEXEファイルのダウンロードを許可

IT管理者およびヘルプデスク

アーカイブ（.zip、.7z、.bzip、.cab、.gzip、.rar、.tgz など）。
実行ファイル（.sh、.msi、.exe、.dll、.ps1 など）。
その他の文書（.crt、.pcap など）。

特定に承認されたカテゴリー（ビジネス、教育、情報技術）。

ダウンロード

許可

3以上

開発者によるアップロードを許可

開発者

ソースコード、Webコンテンツ、ビデオ、その他のドキュメント、実行ファイルなど

特定の信頼できる開発サイトのカスタム カテゴリー。

アップロード/
ダウンロード

許可

4+

Microsoft 365 の業務用ドキュメントのダウンロードを許可

全員

Microsoft 365、選択したアーカイブ、特定のその他ドキュメント（.cad、CSV、.txt など）を必要に応じて許可します。

特定のビジネスに適したカテゴリ。

ダウンロード

許可

5+

不要なファイルのアップロードおよびダウンロードをブロック

全員

GZIP、音声、画像、特定のビデオおよびWebコンテンツを除くすべて。

すべてのカテゴリー。

アップロード/
ダウンロード

ブロックまたは警告

Cloud Firewall コントロールポリシーベースライン

Zscalerのファイアウォールサービスは、主に3つの機能で構成されています：コアファイアウォール、DNS制御、クラウドIPSコントロール。

コアファイアウォールは、Standardファイアウォールおよび高度なファイアウォールとして利用できます。 標準ファイアウォールは、SWGプロキシーを含むすべてのサービス階層で使用でき、レイヤー3、レイヤー4およびFQDNルールを提供します。 たとえば、送信元または宛先のIPアドレス、FQDN(AND条件を使用)およびネットワーク サービス(ポートとプロトコル、この場合はANDを使用)をブロックするルールを定義できます。 Zscalerの標準ファイアウォールは、すべてのフローの集計ロギングと、ブロック アクションが選択された場合の詳細なロギングを提供します。

Zscalerの高度なファイアウォールは、ユーザーごとの条件（ユーザー、グループ、部署など）、ディープ パケット インスペクション（DPI）によるアプリケーション識別、非標準のWebトラフィックを検出してSWGやその他のモジュールにリダイレクトする機能、DNSコントロール、およびWeb以外のトラフィックに対するIPSコントロールを追加します。 また、高度なファイアウォールは、ポリシーで許可されているかブロックされているかに関係なく、各セッションとフローの詳細なログを追加します。

次のZscalerの推奨事項は、多くの場合、高度なファイアウォールが使用されていることを前提としており、多くの提案ではこれらの機能の1つまたは複数が組み合わされています。

各ロケーションごとにCloud Firewall（およびIPS）を有効化

ファイアウォールのルールは、ファイアウォールが有効化されているロケーションにのみ適用されます。 常にリモート ユーザーに適用されます。 ファイアウォール、DNS、およびIPSコントロールが必要な各ロケーションでCloud FirewallとIPSが有効になっていることを確認してください（管理者 > ロケーション管理）。

画像を参照してください。

ファイアウォール戦略の策定: デフォルトファイアウォールフィルタリングルール

最初に考慮すべきファイアウォールルールは、最後のものです。 ここでの設定によって、すべてのファイアウォール ルールを定義するための戦略的アプローチが決まります。

現在、すべてのZscalerテナントには、ブロック用のデフォルトのファイアウォールフィルタリングルールセットが適用された状態で提供されています。 つまり、上位のルールで許可されていない限り、デフォルトですべてのトラフィックがブロックされます。 この戦略はデフォルト ブロック（すなわち、トラフィックが許可リストに配置されることを意味します）と呼ばれ、インターネットにアクセス可能なトラフィックおよびアプリケーションを1つ以上のルールで明示的に定義する必要があります。 新しいアプリケーションまたは新しく検出されたアプリケーションを巧みに追加する必要があります。

画像を参照してください。

このデフォルトのブロックは非常にセキュアであり、最小特権アプローチを採用してゼロトラスト テナントを導入しています。 ただし、このアプローチでは、ネットワーク運用やセキュリティ運用に知られていないアプリケーション、またはこれらのチームの通常の権限外で購入または実装されたアプリケーションが機能しなくなるため、ビジネス機能の中断を意味する可能性があります。

ステージング済みロールアウトは、中断を軽減するための一般的な手法であり、トラフィックが最初に検査され、すべてのflowがビジネス目標を満たすアプリケーションに帰属されます。 これにより、アプリケーションを事前に識別し、目的のアプリケーションのセットに起因しないセッションがほとんどまたはまったくなくなるまで、許可ルールを段階的に追加できます。

従来、ZIAファイアウォールにはデフォルトの許可ルール設定が付属しており、多くの顧客がこの設定を維持しています。

デフォルトの許可戦略では、ネットワークを利用するすべての望ましくないアプリケーションや悪意のあるアプリケーションをファイアウォール ルールで明確に定義する必要があります。 これはブロックリスト戦略と呼ばれ、セキュアな基盤を確立するためにNetOps/SecOpsによる有効性の検証が必要です。 デフォルトの許可ルールは、少なくとも過度に許容するポリシーのために企業が侵害を受けるまでは、中断の少ないアプローチと見なされることがよくあります。

ファイアウォールの必須ベストプラクティス

次のベスト プラクティスでは、デフォルトのブロック戦略が設定されていることを前提としています。

1. 最も高い優先度は、主要なシステム定義ルールに割り当てられます。 上位のルールが許可に設定されていることを確認してください。 これには、Zscalerプロキシ トラフィック、Microsoft 365、およびUCaaS通信を許可する他のクリック実行ルールの許可が含まれます。 Zscalerプロキシ トラフィック ルールよりも上位に他のルールを配置すると、プロキシが機能しなくなります。 クリック実行ルールより上位のルールは可能ですが、推奨しません。

画像を表示。

2. 推奨ファイアウォールルールに対する優先度：高 推奨ファイアウォール ルールは、特定の既知のトラフィックがレイヤー3およびレイヤー4ファイアウォールを通過し、上位レベルのプロキシ機能によって検査されることを可能にするシステム定義のルールでもあります。 これらの上位レベルのプロキシ機能には、Web(およびその他の)トラフィック用のSWGと標準DNS用のDNS制御が付属します。 このルールは、ネットワーク サービス(ポートとプロトコル)を使用し、特に標準のWeb(HTTPとしてTCP:80、HTTPSとしてTCP:443)とDNS(TCP:53またはUDP:53)を対象としています。

WebおよびDNSのインスペクションが強化されているため、このルールの有効化によって、このトラフィックが未検査かつ安全でない状態で通過することを意味するのではなく、このトラフィックに対するポリシーをこれらの上位レベルのプロキシーエンジンで指定する必要があります。 Zscale では、このルールに他のトラフィックタイプの条件を配置することは推奨しません。 このルールは、特殊なZIA関数専用として予約します。 DNS over HTTPSはWebに分類されるため、指定する必要はありませんが、DoHフローであると判断されると、DNS制御エンジンによって検査されます。

3. QUIC をネットワーク サービスとしてブロッキングする: QUICは、TCPを使用せずにWebコンテンツを転送するための代替手段であり、HTTP/3プロトコル（SWGによってまだ管理されていない）の転送基盤を構成します。 Zscalerは、QUICをブロックし、SWGが完全に管理するHTTP/2またはHTTPSに通信を強制することを推奨しています。 ほとんどのQUICはUDP:443であり、ネットワーク サービスQUICの現在の定義でもあります。 QUICはUDP:80に表示されるため、ネットワーク サービスQUIC(管理>ネットワーク サービス)のデフォルト定義を変更することを検討してください。 ICMPブロックを選択すると、UDPパケットがドロップされ、ICMP経由でタイプ3のエラーメッセージ(Destination Unreachable)およびコード13(Communication Administratively Prohibited)がクライアントに送信されます。 これにより、クライアントは別のWeb転送方法への切り替えが速くなる可能性があり、QUICが機能していないことをクライアントがすばやく学習するため、遅延がほとんどなく、ユーザー エクスペリエンスが向上します。 これにより、デフォルトのブロックルール戦略を使用するかどうかに関係なく、ユーザー エクスペリエンスが向上します。

画像を表示。

4. ルールにおけるネットワーク アプリケーションの利用検討について: DPIは2000年代半ばに次世代ファイアウォールとともにファイアウォールに導入されて以来、アプリケーションが使用するポートに依存せず、アプリケーションの独立した識別が行われています。 DPIの強みは、検出の確実性です。 DPIがトラフィックをアプリケーションxとして識別する場合、それは確かにアプリケーションxです。 DPIファイアウォールの課題は、アプリケーション検出が通常最初のパケットで行われないことです。 つまり、アプリケーション識別が完了する前に複数のパケットが許可される可能性があるため、アクション(許可、ブロック)が実行されます。 このリークは、ベスト プラクティスとしてネットワーク アプリケーションを使用することをできるだけ少ないフローに適用する必要があることを意味します。 これにより、DPIがフローを識別するために開いたままにしておく必要があるルール条件の数が制限されます。 これを行う最善の方法は、ネットワーク アプリケーションを、送信元または宛先のIPアドレス、ユーザー、ネットワーク サービスなど、ルール内の少なくとも1つの他の条件とブレンドすることです。 あるいは、ネットワーク アプリケーションを使用してルールの優先度を下げる(ルール リストのさらに下に配置する)と、ネットワーク サービス、IPアドレス、FQDNなどの条件を使用する最初のパケット ルールが、DPIが残りのフローを検査する直前に関連するフローでトリガーできます。 この実践に従わない場合、短いバーストのみであり、ファイアウォール ポリシーとは無関係に（ネットワーク アプリケーションが識別される前）Allowed due to insufficient app dataとして終了したflowのフロー ログ エントリーが多数記録される可能性があります。

中断のない展開(Standard ファイアウォール)：

1. 前のルールでブロックされていない場合、Allow がすべてのトラフィックに対してデフォルト アクションとして設定されていることを確認してください。
2. 既存のレガシー ファイアウォールにおいて、明示的なBLOCKポリシーが存在するかどうかを確認してください。
3. 必要に応じて、ZIAのAllowポリシーおよびBlockポリシーを一致するように設定します。
   1. ネットワーク サービス ポリシーのみを構築します。
   2. サブロケーション レベルでファイアウォールを有効にします。
4. テスト ロケーションおよびユーザーからZscalerへ非Webトラフィックを転送します。
   1. 選択したトンネルを80/443からすべてのポートおよびプロトコルに変換します。
   2. Zscaler Client Connectorでリモート ユーザーをターゲットにするためのZ-Tunnel 2.0を実装します。
5. あなたのポリシーを向上させます：
   1. トラブルシューティング中にブロック済みトラフィックを特定するため、ファイアウォールNSSフィードをSIEMに活用してください。
   2. ニーズに一致するようにAllow ポリシーの構築を続行し、特定のサブロケーションから必要な宛先またはサービスへのトラフィックを許可します。
   3. 知っている対象をブロックするか、必要に応じてあなたのポリシーで作業してください。
   4. デフォルトのポリシーをブロックに設定します。

中断のない展開(高度なファイアウォール)：

1. 以前のルールでブロックされていない場合、あなたのデフォルト アクションがAllow またはすべてのトラフィックに設定されていることを確認してください。
2. 既存のレガシー ファイアウォールにおいて、明示的なBLOCKポリシーが存在するかどうかを確認してください。
3. ZIAで既知の必要なBlockポリシーを構成します。
4. すべてのロケーションのサブロケーション レベルでファイアウォールを有効にします。
5. 追加の非WebトラフィックをZscalerに転送します。
   1. トンネルおよびポリシーベース ルーティング（PBR）を80/443からすべてのポートおよびプロトコルに変換します。
   2. Zscaler Client Connectorを使用してリモート ユーザー向けにZ-Tunnel 2.0を実装します。
6. ログを定期的に確認して、次のことを行います。
   1. デフォルトのポリシーをトリガーしているトラフィックを特定します。
   2. このトラフィックが許可済みかブロック済みかを特定します。
   3. 一致するようにポリシーを作成し、デフォルトのポリシーよりもリストの上位に配置されていることを確認してください。
   4. デフォルトのポリシー一致が十分低レベルになり、アクションを安全にBlockに設定できるまで繰り返します。

ポリシー構成の例

以下のセクションでは、構成例を提供します。

SSHを信頼できる宛先に制限する

このユース ケースでは、SSH経由のアウトバウンド接続は特定の信頼できる宛先でのみ許可され、それ以外の場合はブロック済みとなります。 このルールの目的は、任意の宛先へSSHを許可すると、潜在的なデータ流出経路がさらされることです。

ルールの構築：

1. 信頼できるSSHを設定します。 詳細は、IPまたはFQDN宛先グループを参照してください。

画像を表示。

2. 特定のサービスを許可するルールを作成します。 SSH。

画像を表示。

3. 宛先グループを選択してください: 信頼されたSSH。

画像を表示。

4. アクションの設定： 許可する。
5. [保存]をクリックします。
6. ブロックするルールを作成します。
7. サービスを選択してください: SSH。
8. セット アクション: ブロック/リセット.
9. [保存]をクリックします。

画像を表示。

特定ユーザーへのRDPの制限

このユース ケースでは、RDP経由のアウトバウンド接続は特定のユーザーにのみ許可され、その他のユーザーにはブロック済みとなります。

このルールの目的は、ユーザーが外部のマシンに対してRDPを開始することで、フィルタリングおよびデータ流出をバイパスできることです。

ルールの構築：

1. カスタム ネットワーク サービスを構築します。
2. TCP宛先ポート: 3389.

画像を表示。

3. を許可するルールを作成します。
4. 目的のユーザー グループを選択します。
5. カスタムサービスを選択してください。
6. アプリケーションを選択してください: リモート デスクトップ。

画像を表示。

7. セットアクション: 許可する。
8. [保存]をクリックします。
9. ブロックするルールを作成します。
10. ネットワーク アプリケーションを選択してください: RDP。

画像を表示。

7. セットアクション: ブロック/リセット。
8. [保存]をクリックします。

アプリケーションを選択するには、高度なファイアウォール サブスクリプションが必要です。 Standardライセンスのユーザーは、ネットワーク サービスを選択できます。

画像を参照してください。

DNS制御ポリシーベースライン

DNS制御は、DNSリクエストおよびレスポンスを分析し、望ましくないドメイン、リスクが高いドメイン、または悪意のあるドメインおよびIPアドレスカテゴリからこれらをセキュアに保護します。 DNS制御は、DNSプロトコル タイプ、DNSレコード タイプ、解決済み国IPなどの分類と組み合わせて使用したり、分類とは別に使用したりできる他の多くのルール条件を提供します。

さらに、DNS制御は、望ましくない通信があなたの環境から外部へ送信されるのを防ぐために不可欠です。 要求の可視性と応答の制御は、接続要求を発行する前に、ユーザーとマシンを危険なサービスの多くから遠ざけることができることを意味します。

DNSトラフィックをZscalerに転送中

DNS制御を有効にするには、DNSトラフィックをZIAに転送する必要があります。 トラフィックはさまざまな方法でZIAに送信できますが、主なオプションは次の通りです。

1. 既存のGREまたはIPSec転送トンネルにDNSを組み込む方法。 これは通常、本社と支店のロケーションに対して行われます。
2. 展開済みZscaler Client ConnectorクライアントでZ-Tunnel 2.0を有効化し、DNSトラフィックを含めます（Zscalerに送信してはならないドメインまたはIP、特にプライベート ソリューションを除外）。
3. DNSサーバーから直接再帰的なDNSリクエストを転送中。 これには、ZIAにトラフィックを送信するDNSサーバーのIPアドレスでロケーションを作成する必要があります。 このメソッドはすべてのエンドユーザーのコンテキストを失いますが、多くの場合、DNSセキュリティ用の最初のステップとして実行されます。

推奨事項

• 防御の最前線として、最もリスクの高い宛先の宛先IPカテゴリーをブロッキングすることで、悪意のあるドメインにユーザーが到達するのを防ぐことができます。 例： アノニマイザー、ボットネット コールバック、悪意のあるコンテンツ、フィッシング。

画像を表示。

• プロトコルによるDNS over HTTPSのリクエストをブロックまたはリダイレクトし、信頼できるパブリックサーバーへ送信することでリクエストの可視化を実現します。 これには、SSLインスペクションを実行する必要があります。

画像を表示。

• 不要な（一般的にブロック済みのDNSトンネル）アプリケーションへのDNSトンネリングのトラフィックをブロックします。 さらに、不明なDNSトンネルのセクションで、ブロックする追加の部分を確認します。

画像を表示。

• 信頼できるサーバー(IP宛先グループ内で定義)へのDNSリクエストを許可します。 次に、最終的なポリシーとして他のDNSリクエストをブロックまたはリダイレクトします。

画像を表示。

• ポリシー ルールのプロパティーがルールの順序リストに表示されている通りに、ポリシー ルールを作成してください。

画像を表示。

展開チェックリスト

以下のチェックリストは、ZIAポリシーの設定を行う際のガイドを提供します。

URLスーパーカテゴリ別URLフィルタリング推奨事項

Zscalerでは、ZIAポリシーの計画および実装を支援するために、URLスーパーカテゴリ別ZIAフィルタリング推奨事項リーディングプラクティスチェックリストのダウンロードを推奨しています。

詳細は、URLカテゴリーについてを参照してください。

URLフィルタリング高度なポリシー設定

Zscaler は、ZIAポリシーの計画および実装を支援するために、ZIA URLフィルタリング高度なポリシー設定リーディングプラクティスチェックリストのダウンロードを推奨します。

詳細については、高度なURLポリシー設定の構成を参照してください。

考慮事項

ZIAポリシーを作成する際には、以下の考慮事項が重要です。

ファイアウォールが有効化されていない非Webトラフィックに関するポリシー

ZIA パブリック サービス エッジが80/443以外のポートへのアウトバウンド非Webトラフィックを受信し、組織がユーザーのロケーションでファイアウォール ポリシーを有効にしている場合。 組織がロケーションに対してファイアウォール ポリシーを有効にしていない場合、ZIA パブリック サービス エッジはトラフィックを検査し、ファイアウォール モジュールのみを使用してポリシーを適用します。 ZIA パブリック サービス エッジは、トラフィックに対してスキャンやポリシーの適用を一切行いません。

認証されていないトラフィックに対するポリシー

適切に設定されたZIAポリシーは、ユーザーに関連付けられたトラフィックを認証する必要がありますが、すべての環境で可能であるとは限りません。 信頼済みネットワーク上でもZscaler Client Connectorを展開して使用すると、認証率とトラフィックへのユーザー属性が大幅に向上します。

あるいは、Zscalerは、管理 > 詳細設定 に移動して、未認証のトラフィック機能のポリシーを有効にすることを推奨します。 この機能は、ポリシーの作成時に選択するさまざまな未認証のトラフィックに固有の追加の部署を提供します。 この機能を有効にすると、ロケーションに対して認証が有効になっている場合でも、認証されていないトラフィックに対してポリシーが適用されます。 詳細については、未承認トラフィックのポリシーの設定を参照してください。