【SSE】[Zscaler] [ZIA] [設計] [個別] [インライン補助] Application Instance
Application Instanceとは
Application Instanceとは、Cloud Application内の特定の企業テナントを識別するための機能です。
例えばBoxやZoomなどのSaaSでは、企業ごとに専用のテナントが払い出されます。
Application Instanceへ企業テナントの識別情報を登録することで、Cloud App ControlやDLPなどのポリシーから
そのテナントだけを対象とした制御が可能になります。
例えば、以下のような制御を実現可能です。
自社のBoxのみアップロードを許可する
- 外部企業のBoxはアップロードを禁止する
Cloud App Controlとの関係
Application Instance単体では通信を許可・拒否することはできません。
Application Instanceは、Cloud App Controlが参照するための識別情報として利用されます。
例えば、Cloud App Controlで「Upload」「Download」などの操作を制御する際に、
「どの企業テナントなのか」を判定するためにApplication Instanceが利用されます。
つまり、Application InstanceはCloud App Controlの制御精度を高めるための補助機能と言えます。
Tenant Profileとの違い
Tenant Profileも企業テナントを識別する機能ですが、Application Instanceとは仕組みが異なります。
Tenant Profileは、SaaS側が提供するテナント識別機能を利用するため、対応しているSaaSのみ利用できます。
一方、Application Instanceは、Zscalerが通信内容を解析して企業テナントを識別する仕組みです。
どちらも企業テナントを識別するという目的は同じですが、利用できるSaaSや識別方法が異なります。
設計で重要なこと①
企業テナントを識別するための機能として利用する
Application Instanceは、「このSaaSを利用する」ための機能ではありません。
「この企業テナントを利用する」ことを識別するための機能です。
そのため、Cloud App Controlと組み合わせることで、
自社テナントのみ利用を許可する
- 外部テナントへのアップロードを禁止する
など、企業単位でのアクセス制御を実現できます。
設計で重要なこと②
事前検証と継続的な動作確認を行う
Application Instanceは、SaaSの通信内容や識別情報をもとに企業テナントを判定します。
そのため、識別方法は対象SaaSの通信仕様に依存します。
SaaSは継続的にアップデートされるため、仕様変更によってApplication Instanceが期待どおり
動作しなくなる可能性があります。
筆者の環境でも、GitHubを対象にApplication Instanceを利用した際、
期待した制御が行えない事象がありました。
Zscalerへ問い合わせた結果、対象SaaSの仕様変更に対して、
Zscaler側の識別処理が追従できていないことが原因でした。
もちろん、このような事象は頻繁に発生するものではありません。
しかし、Application InstanceはSaaSの通信仕様に依存する機能である以上、
「設定できたこと」「ポリシーへ適用できたこと」だけで安心するのではなく、
「実際に期待した制御が行われること」「SaaSのアップデート後も継続して動作すること」
まで確認できる運用を設計することをおすすめします。
まとめ
Application Instanceは、企業テナントを識別し、Cloud App Controlなどのポリシーで
利用するための重要な機能です。
一方で、その識別方法はSaaSの通信仕様に依存するため、
SaaSのアップデートによって動作が変化する可能性があります。
そのため、設計時は
- Cloud App Controlと組み合わせて利用する
- 導入時に実際の動作を検証する
- 導入後も継続的に動作確認できる運用を考慮する
ことが重要です。

➡【次の記事へ】【SSE】[Zscaler] [ZIA] [設計] [個別] [インライン補助] Tenant Profiles

