HOME
MENU
Zscaler

【SSE】[Zscaler] [ZIA] [設計] [個別] [インライン] Data Loss Prevention（DLP）

buffoon

はじめに

前回の記事では、File Type Controlについて紹介しました。

File Type Controlでは、ファイル形式やMIME Typeを利用してアップロード・ダウンロードを制御しました。

しかし、PDFだからといってすべて機密情報が含まれているわけではありません。

逆に、WordやExcelだけでなく、テキストファイルや生成AIへの入力に重要な情報が含まれることもあります。

そこで利用されるのがData Loss Prevention（DLP）です。

DLPは、送信しようとしているデータそのものを解析し、機密情報や個人情報の持ち出しを防止する機能です。

本記事では、以下を取り上げて紹介します。

  • DLPの役割
  • 利用できる主なクライテリア
  • 利用できるアクション
  • DLP Dictionaryの考え方
  • EDM・IDMの違い
  • Microsoft Information Protection（MIP）との連携
  • 設計で意識したいポイント

Data Loss Preventionとは

DLP（Data Loss Prevention）は、情報漏えいを防止するためのセキュリティ機能です。

DLPは、送信しようとしているデータの中身を検査します。

例えば、

  • マイナンバー
  • クレジットカード番号
  • 個人情報
  • 顧客情報
  • 設計書
  • 契約書

などが含まれている場合、アップロードや送信をブロックできます。

DLPで利用できる主なクライテリア

DLPでは、他のインラインポリシーと同様に複数条件を組み合わせてポリシーを作成できます。

代表的なものとして、以下があります。

  • Users / Groups / Departments
  • Location Groups / Locations
  • URL Categories
  • Cloud Applications
  • Time
  • Device Trust Level
  • User Agent
  • 実際の設計では、

Cloud Application

URL Category

Users / Groups / Departments

を組み合わせて、「どこへ」「誰が」データを送るかを条件とするケースが多くなります。

DLPで利用できるアクション

  • Allow
  • Block
  • Caution

Allowは通信を許可します。

Blockは通信を拒否します。

Cautionはユーザへ警告を表示したうえで通信を継続させるため、段階的な導入や注意喚起に利用できます。

DLPではインシデント連携も重要

DLPでは、通信を許可・拒否するだけでなく、検知した情報を管理者や外部システムへ通知・連携することもできます。

例えば、

  • Incident Receiverへの転送
  • ICAPを利用したサードパーティDLPとの連携
  • Auditorへのメール通知
  • Cloud-to-Cloud Incident Forwarding

などを組み合わせることで、ブロックだけでなく、「誰が・何を・どこへ送ろうとしたか」

という情報をSOCやSIEMへ連携し、インシデント対応へつなげることができます。

DLP Dictionaryとは

DLPでは、何を機密情報として判断するかをDictionary（辞書）として定義します。

例えば、

  • マイナンバー
  • クレジットカード番号
  • パスポート番号
  • メールアドレス

など、あらかじめ用意されている辞書を利用できます。

また、企業独自の辞書も作成できます。

  • 社員番号
  • 製品名
  • プロジェクト名

などを登録して、独自の情報漏えい対策を行うことも可能です。

EDMとIDMの違い

Zscaler DLPでは、代表的な検知方式として

EDM（Exact Data Match）とIDM（Indexed Document Match）があります。

EDM

EDMは、顧客名簿や社員台帳など、構造化されたデータベース情報を保護するための機能です。

例えば、

社員番号

氏名

メールアドレス

などを登録しておくことで、

登録済みデータと一致した情報が送信されると検知できます。

つまり、「データベースを守る仕組み」です。

IDM

IDMは、文書そのものを保護する機能です。

契約書

設計書

提案書

など。

登録した文書をフィンガープリント化し、その内容がアップロードされた場合に検知できます。

つまり、「文書を守る仕組み」になります。

Microsoft Information Protection（MIP）との連携

近年では、Microsoft Purview Information Protection（MIP）との連携も重要になっています。

Microsoft 365では、ファイルに

  • 社外秘
  • Confidential
  • Highly Confidential

などのラベルを付与できます。

ZIAでは、これらのラベルをDictionaryとして利用し、

「社外秘ラベルが付いたファイルはDropboxへのアップロードを禁止」

「Highly Confidentialは生成AIへの入力を禁止」

といった制御も可能です。

データの内容だけでなく、企業が付与したラベルを利用して制御できる点は、近年利用が増えている機能の一つです。

Cloud Application Control・File Type Controlとの違い

Cloud Application Controlでは、どのクラウドアプリケーションを利用するかを制御します。

例えば、Dropboxへのアップロードは禁止という制御です。

File Type Controlでは、どの種類のファイルかを制御します。

例えば、PDFは禁止という制御です。

一方、DLPでは、そのファイルに何が書かれているかを判断します。

例えば、

設計書PDFだけ禁止

マイナンバーを含むExcelだけ禁止

という制御になります。

それぞれ役割が異なるため、競合する機能ではなく、組み合わせて利用することが重要です。

設計で重要なのは「最後の砦」と考えること

DLPは、他のセキュリティ機能を置き換えるものではありません。

Cloud Application Controlで、アップロード先を制御し、

File Type Controlで、ファイル形式を制御し、

それでも送信されるデータを、最後にDLPで検査します。

つまり、

Cloud Application Controlは「どこへ送るか」を見る。

File Type Controlは「何のファイルか」を見る。

DLPは「何を送ろうとしているか」を見る。

という役割分担になります。

設計では、DLPだけに頼るのではなく、各インライン機能と組み合わせることで多層防御を実現することが重要です。

おわりに

DLPは、インラインプロセスの最後で実行される情報漏えい対策の中核となる機能です。

近年では、Microsoft Information Protectionとの連携やEDM・IDMなどの高度な検知方式も利用できるようになり、

従来よりも柔軟な設計が可能になっています。

重要なのは、DLP単体で考えるのではなく、Cloud Application ControlやFile Type Controlと役割を分担し、

「最後の砦」として設計することです。

➡【次の記事へ】【SSE】[Zscaler] [ZIA] [設計] [個別] [インライン] Malware Protection / Sandbox

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

管理人
管理人

自称SASEエンジニアです。 2児の父親をやりながら、日々エンタープライズ向けの次世代ネットワークインフラと格闘しています。一日一投稿を目標に投稿頑張りますので、是非読んでください！
Recommend
こんな記事も読まれています
記事URLをコピーしました