みなさん、こんにちは。
ネットワールドSEの黒瀬です。
初回はZIAの概要説明、前回はURLフィルタリングについてご紹介しました。
今回は「アプリケーション制御(アプリケーションコントロール)」と「アプリケーションのコントロールポリシー」についてご紹介していきます。
「そもそもアプリケーション制御ってなに？」、「なにがいいの？」といったことを、前回と同じように実際の検証画面を交えながらわかりやすく説明していきます！
- アプリケーション制御(アプリケーションコントロール)とは？
- クラウドアプリケーションコントロールの画面
- クラウドアプリケーションコントロールの魅力（何故アプリケーション制御なのか）
- 実際に設定してみた
- まとめ
* 免責事項
- 本書は、株式会社ネットワールド（以下 弊社）が作成・管理します。
- 本書の記載内容の一部または全部を弊社に無断で改変・転載することを禁じます。
- 本書の記載内容は、一部または全部が将来予告無く変更されることがあります。
- 本書の利用は、利用者様の責任において行われるものとします。
- 本書の記載内容には、最善の注意を払っておりますが、正確性・完全性を保証するものではありません。従いまして、本書の利用によって生じたあらゆる損害に関して、弊社は一切の責任を負いかねます。
アプリケーション制御(アプリケーションコントロール)とは？
アプリケーション制御とは、ユーザーがアクセスしようとする一般的なWebサイトやアプリケーションを高い精度で制御できる仕組みです。(ZIAではクラウドアプリケーションコントロールという機能)
大雑把でなく、アプリケーションレベルで細かく識別して、ポリシー適用などを行います。そのため、前回「ZIA基本のキ #2」で紹介したURLフィルタリングよりも詳細な制御ができ、業務上でよく使われるアプリケーションへのポリシーの適用に適しています。
アプリケーション制御を行うためには、アプリケーションのコントロールポリシーを設定する必要があります。
どんな設定項目があるのか実際の検証画面を見ながら、設定項目を確認していきましょう。
クラウドアプリケーションコントロールの画面
それでは、実際のクラウドアプリケーションコントロールのポリシー設定画面とその設定項目を確認していきます。
今回はWebメールに関する設定画面を確認していきます。
クラウドアプリケーションコントロールのポリシー作成画面が下図になります。
クラウドアプリケーションコントロールのポリシー作成画面は、最初に大きな分類分けをしたのち、次の４区分に分けられています。
- ルール情報
- 条件(CRITERIA)
- ルールの有効期限
- アクション
アクションはアプリケーションによっても設定項目が異なり、上図はWebメール全般のポリシーの場合の設定項目となっています。
ここからは、ZIAのクラウドアプリケーションコントロールの魅力についてご紹介していこうと思います。
クラウドアプリケーションコントロールの魅力（何故アプリケーション制御なのか）
ZIAのクラウドアプリケーションコントロールは、SaaSやクラウドサービスを「アプリケーション」として扱い、業務に即した粒度で制御できるのが最大の強みです。設定項目は多岐にわたりますが、ここでは前回と同様に私が特に魅力だと感じるポイントに絞ってご紹介していきます。
アプリを”機能”で制御できる細粒度ポリシー
アプリケーションの全面禁止、全面許可といった極端なポリシー制御ではなく、業務上必要な機能だけを許可するといった高い精度で制御できます。
想定リスクが高いアプリケーションを全面禁止にすることなどはURLフィルタリングで十分に対応できます。
しかし、見落としがちなのが日常的に使うアプリケーションからのデータ漏えいです。使用頻度が高いほど、誤操作や意図せぬ持ち出しの機会は増えます。だからこそ、よく使うアプリケーションを機能レベルで細かく制御できることが、クラウドアプリケーションコントロールの魅力となります。
他にも
・企業テナントのみ許可することでの個人アカウントの禁止
・リスクプロファイル設定による脆弱性に応じたアプリの制限
上記のように、他にも業務には影響を出さず、データ漏えいや業務に関係のない機能だけ制限できるような仕組みがあります。
では、実際にアプリケーションコントロールのポリシーを設定して、動作を確認してみましょう。
実際に設定してみた
アプリケーションコントロールのポリシーは設定項目が多岐にわたります。
今回は複雑な設定にせず、簡単な設定として
【私のアカウント「Yoshiaki Kurose」に対してGmailを送信する際の添付ファイルのみブロック】
というポリシーを作成していきつつ、内容を紹介していきたいと思います。
最初は制御したいアプリケーションに合致するジャンルを選択して始めます。
今回はGmailの設定を行うので、Webメールを選択します。
下図に表示されているもの以外にも生成AIやファイル転送などのジャンルが選択できます。
次にルール情報を入力していきます。
・ルールの順序：1
・ルール名: mailTEST_ky
・ルールのステータス：有効
・ルールラベル：なし
ルールはURLフィルタリングなどと同様に上位のルールから適用されるため、今回はルールの順序を1にしています。デフォルトでは一番大きい数になるため、設定時には注意してください。
ここからは条件(CRITERIA)の設定です。
ここでは、適用するアプリケーションやユーザーなどルールを適用する様々な設定項目を指定できます。
まず適用するクラウドアプリケーションについて設定していきます。
今回はGmailについての制御なので、CRITERIAのクラウドアプリケーションからGmailを選択します。
選択したものは、右に表示されます。今回はGmailのみを選択しているので、右側に選択されたアイテムはGmailのみとなっています。
次に、ユーザーは適用させたいユーザーである「Yoshiaki Kurose」を選択します。
今回はユーザー１人を選択していますが、複数の場合はグループを作成したり、部署のタグをつけることで簡単に適用することができます。
他はすべてdefault値のままです。
今回はルールの有効期限は設定しないので省略し、アクションの設定に進みます。
アクションはアプリケーションに対して、許可・ブロック・警告表示・Isolate(ブラウザ分離)するのかを設定します。
URLフィルタリングとは異なり、単純な許可やブロックではなく、アプリによってどの操作を許可する・ブロックするといった細かい指定をすることが可能です。
今回はメールの閲覧・送信は許可しますが、添付ファイルを送信しようとした場合ブロックしたいので、閲覧は「許可」、添付ファイルを送信は「ブロック」、メールを送信は「許可」を選択します。
またCascade to URL Filteringを有効にすると、ポリシーが適用され、許可されたのちにURLフィルタリングも通して、二重にポリシーチェックすることも可能です。
設定後は必ずアクティブ化します。
私自身アクティブ化をし忘れて検証し、「何か間違えたか？」となったりしたので注意してみてください。
設定できたので、実際に確認してみましょう。
ということで、実際にユーザー「Yoshiaki Kurose」のPCからGmailの添付ファイルを送信を試みました。
このように「ファイルの添付中にエラーが発生しました。」と表示され添付できないことが確認できました。
この状態だとZscalerによるブロックなのか確認できないので、Zscalerの管理画面(experience center)の方からもログでブロックされているか確認してみます。
同じく、ファイル添付の禁止によりブロックされていることが確認できました。
まとめ
よく使うアプリケーションだからこそ、データ漏えいの機会は増えてしまいます。
だからこそ、そのアプリケーションを機能レベルで制御できるアプリケーションコントロールはこれからのセキュリティで重宝される仕組みとなっています。
今回はアプリケーションコントロールについてご紹介しました。
アプリケーションコントロールは今回ご紹介した内容以外にも、テナント制御やリスクプロファイル設定など、他にも機能がたくさんあるので、機会があればこちらもご紹介していきます。
よければ次回もご覧ください！
