DLPのメール通知の環境を構築します、といったときに皆さんどういう構成を思い浮かべるでしょうか
インシデント処理を行うためのフローを考慮する上では、データ保護にまつわるインシデント利用者への通知や教育をどのように行うかが必ず課題となり優先すべき設計項目となります
監査フローと通知フローを考える
よいフローを構築し組織全体や外部への連携のため共有化することでセキュリティ教育と共にスピードや生産性を高めることを考えていきます
運用者側でチェックを行うとしてもエンドユーザへの確認は不可欠です
フローを構築しインシデント発生時に素早く対応でき、適切な許可を行うような教育も可能な通知フローを考えていきます
ゼットスケーラーの水本です。プロフェッショナルサービスのコンサルタントをしています
DLPの持つメリットと組織の目的とをうまくソリューション化できればということで、この記事はZscaler Advent Calendar 2024の7日目向けに作成しました
他の記事はこちら→Appendix
概要
この記事では、DLP違反のインシデントを引き起こしたエンドユーザに自動的にメール通知を送信するMicrosoft Power Automateワークフローを設定するための手順を示します
この記事は、顧客のニーズに応じて拡張または変更できる基本的なインシデントの発生、解決を可能にするフレームワークを提供することも目的としています
前提条件
このフレームワークを使用するためには、環境で次の前提条件を満たしている必要があります:
-
ZIA管理コンソールへの管理者アクセス権を持ち、DLPポリシーとDLP通知テンプレートを編集できること
-
Microsoft Power Automateツールセットにアクセスできること ー Power Automateのライセンスには異なるレベルがありますが、基本レベルで十分です
エンタープライズアカウントは、フローの保存や共有などの機能を有効にし、管理者が会社を離れた場合のビジネス継続性も提供します -
DLPポリシーからの通知を受け取ることができるクラウドベースのメール受信ボックス
GmailとOutlookのウェブメールサービスはPower Automateによってサポートされています
この設定で使用する受信ボックスは、個々のアカウントではなく共有メールアカウントであることが理想的です
メールアドレスを個人用にした場合、ユーザが会社を離れ、そのアカウントが無効化された場合などPower Automateフローは機能しなくなります
よってビジネス継続性を考えた場合はのためには専用のメールアドレスが推奨されます
高レベルの設計
次の図は、この通知フレームワークのエンドユーザへのデータフローを示しています:
DLPインシデント発生時のメール通知のテンプレートに少し手を入れて、監査用のメールからインシデントIDなどエンドユーザ宛のメールに必要十分な値を取り出し、エンドユーザ用のテンプレートで本文を組み立ててDLP違反内容のメールを再配送するという仕組みです
構成手順(Zscaler DLPメールテンプレート)
-
ZIA管理ポータルにログインします
-
このテンプレートの「HTMLのメッセージ」を変更し、Zscaler変数の前後に区切り文字として "|" を組み込みます。
変更前:
変更後:
理由は、あとで設定するMS Power Automateによる文字のパースが正確に行われるよう、各変数の前後に区切り文字を追加することで容易に値をとりだすという意図があります -
選択したDLPポリシーの「通知」見出しの下で、「外部」を監査者タイプとして選択し、DLPメール通知の宛先メールボックスを入力します
通知テンプレートにはステップ5で作成したDLP通知テンプレートを選択します -
DLPルールを保存し、変更を有効化します
この時点で、DLP違反を発生させると監査役宛のメールがステップ4で追加した区切り文字付きにフォーマットされていることを確認できます
監査用の通知をユーザへのメール通知に
-
Power Automateに接続します
-
フローに名前を付け、このフローのトリガーを選択します。
この場合、Gmail の「新しいメールが届いたとき」のフローをトリガーします。このフローをトリガーするには、適切なメールベンダー (Outlook、Gmail など) を検索する必要があることに注意してください。
-
この例では、フローは「DLP End User Notification」の件名のメールが届いたときにのみトリガーされます。
多くの場合、このトリガーに送信元メールアドレスの条件も追加することを選択します。
-
これにより課題となる監査用メールの全てのHTMLデータがテキストに変換され、以降のフローで文章を解析できるようになります
-
Composeのアクションを追加します
作成した「Compose」関数を編集して、式を組み込みます。この場合、次の式を使用して、「|」区切り文字に基づいて「Html to Text」の出力を個別のデータ チャンクに分割します。
使用する式は次のとおりです:
split(outputs('Html_to_text')?['body'],'|')
-
次にアクションを追加し、インシデント発生となったエンドユーザを宛先とするための変数の初期化(Initialize variable)を行います
文字列型のUser_emailパラメータに使用する式は次のとおりです:
outputs('Compose')[3]
-
元の違反を生成したエンド ユーザーのメールアドレスを取得します。作成アクションは、HTML to Textでの操作のテキストを、"|" 記号で区切られた番号付き変数に分割し、"0" から変数値が開始されます。変数に名前 ("User_Email") を付けます。変数タイプには文字列を選択します。"値" には式により上記の内容が追加されます
-
さらにアクションを追加し、インシデントのIDとURL値を含むための変数の初期化(Initialize variable)を行います
インシデントのID値:
インシデントURL値:
文字列型のIncidentIdパラメータに使用する式は次のとおりです:
outputs('Compose')[1]
文字列型のIncidentUrlパラメータに使用する式は次のとおりです:
outputs('Compose')[5]
これで本文からエンドユーザへのメール作成に必要なパラメータの取り出しが完了しました
「+アクションの追加」をクリックし、(Gmail用)「メールの送信 v2」ステップを追加します
メール送信用のアクション
-
エンドユーザ用メール送信のSend email(V2)アクションを編集します。「宛先」フィールド内に、作成された変数「User_Email」を追加します
-
ここから、顧客は自社のポリシーに従って、エンドユーザーに送信するメールの件名と本文をカスタマイズする必要があります
これには、会社の利用規約へのリンクや例外処理へのリクエスト フォームが含まれる場合があります
-
「保存」をクリックして、このフローを確定します。
これで、フローをテストして、すべてのステップが期待どおりに動作していることを確認する準備が整いました。フローの右上隅にある「テスト」ボタンをクリックします。
フローの動作を確認するには、このGmailの受信トレイに指定した件名と通知内容でメールを送信する DLP 違反を生成する必要があります。
仕組みが確認できたら他のDLPポリシーでも同様の変更やメールテンプレートを構成し、フレームワーク全体に適用していきます
DLP環境の前提
Zscaler環境であればインシデントが発生した際には監査担当の方にメールを送信することに加え、既存のDLP環境がある場合にはICAPサーバを利用したり、オンプレミスのVMware環境、AzureやAWSなどにインシデントレシーバー(ZIR)の標準的な構成を組むということになるかと思います
ですが実際には目的とするインシデントの用途やコスト、サイジング、運用モデルを考慮する必要があり、本番導入に合わせたDLPのテストの段階であれば良いですが、テスト目的でデプロイするには若干ハードルも高いと思います
まずは今回示した簡易的なメール対応でできることを確認し、インシデントの発生状況などの確認とともに運用設計を行なっていくのかと考えられます
以降のインシデントとDLP管理に向けて
この記事の執筆時点では、DLPエンドユーザ通知はZscaler Client Connectorを通じて完全には利用できません
一般的に、顧客はDLPポリシーがトラフィックをブロックしたときにエンドユーザに通知する必要があり、そのユーザが適切なツールを使用して業務を続けられるようにする必要があります
今回はPower Automateにて簡単にユーザ教育のための通知を送付する手順を示しましたが、インシデントレシーバーに送信されたインシデントファイルのチェックなど運用フローと統合化した設計をこの例を通して検討ください
Appendix
他の記事など:
- 分離ブラウザの通知 12/6
- DLPのメール通知(この記事) 12/7
ブラウザ分離をDLPと効果的に併用することでファイル送信などのデータの制御と保護を多層的なセキュリティにより実現できます