2026.07.04 2026.07.05

【SSE】[Zscaler] [ZIA] [設計] [個別] [インライン] Cloud App Control

buffoon

はじめに

前回の記事では、SSL Inspectionについて紹介しました。

SSL Inspectionによって通信内容を確認できる状態になった通信は、次にCloud App Controlで処理されます。

Cloud App Controlは単純なURL制御ではありません。

クラウドアプリケーションを識別し、閲覧やアップロードといった操作単位や、企業テナント・個人テナントといった利用形態まで考慮して制御できる機能です。

また、インラインプロセスにおいてURL Filteringより先に評価されるため、設計によってはURL Filteringを実行せずに後続の処理へ進むこともあります。

本記事では、以下の要素について解説します。

Cloud App Controlの役割
利用できるクライテリア
利用できるアクション
URL Filteringとの違い
設計時の考え方

※図中でCloud App ControlとCloud App Controlという表記ブレがありますが、Cloud App Controlと読み替えお願いします。

Cloud App Controlとは

Cloud App Controlは、URLではなくクラウドアプリケーションを識別して制御する機能です。

例えばMicrosoft 365であれば、以下のようにそれぞれ異なるクラウドアプリケーションとして識別されます。

Outlook
OneDrive
SharePoint
Teams 等

さらに、閲覧 / アップロード / ダウンロード /ファイル共有 /編集など、アプリケーション内で実行される操作も識別できます。

これは、Zscalerが主要なSaaSについて、HTTPメソッドやURI、API、リクエストパターン、ペイロードなどを解析し、

「どのアプリケーションの、どの操作なのか」をシグネチャとして管理しているためです。

Cloud App Controlは、URLを見る機能ではなく、アプリケーションの挙動を見る機能と言えます。

SSL Inspectionとの関係

Cloud App Controlは、SSL Inspectionによって復号された情報を利用することで、高精度な識別を行います。

そのため、SSL Inspectionを実施していない通信では、アップロードや共有などの細かな操作までは識別できません。

一方で、SNIなど復号しなくても取得できる情報だけで識別できるアプリケーションについては、

SSL Inspectionを行わなくてもCloud App Controlによる制御が適用される場合があります。

Cloud App Controlで利用できる主なクライテリア

Cloud App Controlでは、様々な条件を組み合わせてポリシーを作成できます。

実際の設計では、Cloud Applications、Users、Locationsを中心に利用するケースが多くなります。

また、Cloud Applicationは個別アプリケーションだけでなく、Application Category単位でも管理できます。

例えば、

Collaboration
File Sharing
Social Networking
AI / Generative AI など、

用途ごとにクラウドサービスをまとめて制御できます。

利用するSaaSがまだ定まっていない場合はApplication Categoryで制御し、

業務で利用するサービスが明確になったらCloud Application単位で制御するといった設計も有効です。

Cloud App Controlで利用できるアクション

Cloud App Controlでは、以下の基本アクションを利用できます。

Allow
Block
Continue
Caution
さらに、Box、Dropbox、OneDrive、OneDrive Business、Google Driveなど、一部のSaaSでは操作単位で制御することも可能です。
Download
Sharing
Editing
Inviting
Renaming
Creating
Deleting
Form Sharing 等。

上記操作ごとに、AllowまたはBlockを設定できます。

例えば、Microsoft 365は閲覧・編集を許可し、社外共有は禁止

社用Boxは閲覧・アップロードを許可し、個人Boxは閲覧のみ許可
Google Driveは閲覧のみ許可し、新規作成や共有は禁止といった細かな制御も可能です。

テナント単位の制御

Cloud App Controlの大きな特徴が、企業テナント単位で制御できることです。

例えばMicrosoft 365では、Tenant Profileへ企業のDirectory IDを登録し、

Cloud App Controlのクライテリアとして利用できます。

これにより、社内テナントへのログインだけを許可し、

個人Microsoftアカウントや他社テナントへのログインを拒否するといった制御が可能です。

また、BoxなどではApplication Instanceを利用することで、

企業が契約しているBoxだけアップロードを許可し、

個人Boxは閲覧のみ許可するといった運用も実現できます。

現在、多くのビジネス向けSaaSについて、このようなテナント単位の制御がサポートされています。

URL Filteringとの違い

Cloud App Controlは、URL Filteringより先に実行されます。

そのため、Cloud App ControlでAllowされた通信は、

デフォルトではURL Filteringをスキップし、そのままFile Type Controlへ進みます。

つまり、Cloud App ControlはSaaSに対してURL Filteringより優先度の高い制御を行う機能と言えます。

一方、Cloud App Controlで一致するルールが存在しない場合は、そのままURL Filteringへ処理が引き継がれます。

また、近年追加されたAllow Cascading to URL Filteringを利用すると、

Cloud App ControlでAllowした通信に対しても、URL Filteringを適用できます。

ただし、利用するSaaSや制御内容が明確になっているのであれば、Cloud App Controlで制御を完結させ、

URL Filteringでは重複したポリシーを持たせない方が運用しやすいケースが多いでしょう。

設計で重要なのは役割を分けること

Cloud App Controlは、業務で利用するクラウドサービスを制御するための機能です。

例えば、

Microsoft 365
Google Workspace
Box
Salesforce

など、

企業が利用を認めているSaaSについては、Cloud App Controlで制御することをおすすめします。

一方、利用しているか分からないWebサービスについては、URL Filteringで

URLカテゴリ（ギャンブル等）単位で制御する方が管理しやすくなります。

また、ファイル共有サイト全般についてアップロードを禁止したい場合は、App Categoryを利用した制御も有効です。

Cloud App ControlとURL Filteringは競合する機能ではなく、役割を分担して利用することで、それぞれの強みを活かせます。

おわりに

本記事では、Cloud App Controlの役割と設計時の考え方について紹介しました。

以下まとめます。

Cloud App ControlはURLではなくアプリケーションの挙動を識別すること

SSL Inspectionを実施することで、より詳細な制御が可能になること
Application Category、Cloud Application、Tenant Profile、Application Instanceを組み合わせて柔軟な制御ができること
Cloud App ControlはURL Filteringより先に評価され、デフォルトではAllowした通信はURL Filteringをスキップすること
利用するSaaSはCloud App Control、未知のWebサービスはURL Filteringというように役割を分けて設計すること