[連載]いきなりは絶対に無理。ゼロトラストのデータの柱。DLPをうるさい装置にしない前提条件とは。[第5回]

恐縮です。

ゼロトラストの話も、ここまで来るとかなり本質っぽくなってきます。
アイデンティティを整える。
デバイスを見る。
ネットワークの到達経路を引き直す。
ワークロードの実行環境を可視化する。

前回はこちら。

ここまでやって、ようやくこの問いに来ます。
結局、何を守りたいのか。

答えはデータです。

そして、ここで一番やってはいけないのが、DLP導入そのものをゴールにしてしまうことです。
DLPを入れることが目的になると、必ず現場とズレます。
本来見るべきは「製品を入れたか」ではなく、守るべきデータを定義し、そのデータの動きを業務に耐える形で制御できているかです。
ここを間違えると、導入プロジェクトは完了しても、データ保護は前に進みません。

どれだけ認証を強くしても、端末を監視しても、SASEで経路を整えても、クラウド設定を見ても、最後に守るべきデータが分かっていなければ、制御はかなり雑になります。
何が機密なのか。
どこにあるのか。
誰が触っているのか。
どこへ出ていくのか。
どの操作は許してよくて、どの操作は止めるべきなのか。

ここが曖昧なままDLPを入れると、だいたい失敗します。
止めすぎる。通知が多すぎる。例外だらけになる。現場から嫌われる。
そして最後は、ルールが緩くなって形骸化する。
これはかなりよくある流れです。

だから先に言い切ります。
データの柱は、DLPを入れる柱ではありません。
DLP導入を目的化せず、何を守るべきかを決め、データの状態と動きを制御に変える柱です。

DLPは大事です。
でも、DLPだけでは足りません。
データ分類、ラベル、暗号化、アクセス権、共有制御、持ち出し制御、ログ、例外管理。
これらがつながって、はじめてデータの柱になります。

ここを飛ばすと、DLPは守りの要ではなく、ただの「うるさい装置」になります。
これは避けたい。
かなり避けたいです。

参考URL

データの柱は、何を守るのかを決める柱

データの柱で最初に考えるべきことは、DLP製品ではありません。
最初に考えるべきは、守るべきデータは何かです。

顧客情報。
個人情報。
認証情報。
ソースコード。
契約書。
設計情報。
営業資料。
経営情報。
ログ。
研究開発データ。

全部大事です。
でも、全部を同じ強さで守ることはできません。
ここが現場の難しさです。

何でも止めると業務が止まる。
何でも許すと漏えいする。
だから、データの性質を見て、扱いを変える必要があります。
公開してよいもの。
社内限定のもの。
部門限定のもの。
厳格に管理すべきもの。
持ち出しを止めるべきもの。
暗号化すべきもの。
監査対象にすべきもの。

この整理がないままDLPを入れると、ルールがかなり雑になります。
「個人情報っぽいものは止める」
「機密っぽいファイルは警告する」
これだけだと、現場ではすぐ詰まります。
誤検知も出る。抜けも出る。例外も増える。
結果として、みんなDLPを避け始めます。

だから、データの柱はまず分類です。
そして分類を、制御に使える形にすることです。

データを見つける。分類する。ラベルを付ける。権限を整える。動きを見る。必要なところで止める。
この流れがあって、初めてDLPが効きます。

参考URL

DLP導入をゴールにすると、かなり危ない

ここはかなり強く言いたいです。
DLPを入れればデータ保護ができる、という考え方は危ないです。

DLPは重要です。
ただし、DLPは目的ではなく手段です。
ここを間違えると、「入れたのに使われない」「止めすぎて嫌われる」「例外だらけになる」という流れに入りやすい。
DLPを成功させたいなら、製品導入より先に前提を整える必要があります。
何が機密かが分かっていること。
どこにあるかが分かっていること。
誰が触るべきかが決まっていること。
どの経路で出ていくと危ないかが分かっていること。
例外をどう扱うかが決まっていること。

これがないままDLPを入れると、かなり高い確率で揉めます。
現場からすると、急に送れない。急にアップロードできない。急に警告が出る。
でも、なぜ止まったのか分からない。
解除申請も面倒。
業務影響が出る。
そして、セキュリティ部門は「現場が守ってくれない」と感じる。
現場は「セキュリティが業務を分かっていない」と感じる。
この構図はかなり危ないです。

DLPは、ルールを強くすればするほど効くわけではありません。
むしろ、最初から強くしすぎると現場は回らなくなります。
大事なのは、データ分類と業務フローを見たうえで、段階的に制御を強めることです。

最初は監査モードで見る。
次に警告する。
その次に一部をブロックする。
最後に厳格な制御へ寄せる。
この順番の方が、かなり現実的です。

ゼロトラストは、何でも止める設計ではありません。
必要なアクセスを許し、危ない動きを止める設計です。
データの柱でも同じです。
DLPは刃物です。
切れ味は必要です。
でも、何を切るかを決めずに振り回すと、業務を傷つけます。

参考URL

データ分類、DLP、DSPMをどう分けて見るか

ここも混ざりやすいです。
データ保護の話になると、データ分類、DLP、DSPM、暗号化、IRM、CASBあたりが一気に出てきます。
全部大事です。
でも、役割は分けて見た方がかなり分かりやすいです。

データ分類は、何を守るべきかを決める側です。
このファイルは公開情報なのか、社内情報なのか、機密情報なのか、個人情報なのか。
分類やラベルがあるから、後続の制御が書けます。
分類がないDLPは、かなり雑になりやすいです。

DLPは、危ない動きを止める側です。
メール送信、ファイル共有、SaaSアップロード、USB持ち出し、印刷、コピー。
こうしたデータの移動や持ち出しを見て、警告したり、記録したり、止めたりします。
つまり、データの動きを制御する役目です。

DSPMは、データがどこにあり、どんなリスクを持っているかを見る側です。
クラウド上のストレージ、DB、SaaS、データレイクに、どんな機密データがあり、誰がアクセスでき、どこが露出しているかを可視化する。
つまり、データの所在とリスクを見る役目です。

雑に言うなら、
分類は、何を守るかを決める。
DLPは、どう動くかを制御する。
DSPMは、どこにあって危ないかを見る。
です。

ここを分けて考えると、データの柱はかなり見えやすくなります。
分類がないなら、まずラベル設計が必要です。
持ち出しが痛いなら、DLPが効きます。
クラウドやSaaSに散ったデータが見えないなら、DSPMの価値が出ます。

一つの製品ですべて解決、というより、何が見えていないのか、何を止めたいのかを切り分ける。
ここが大事です。

参考URL

現場で最低限そろえたいもの

データ編で最初に揃えたいのは、いきなり強いブロックルールではありません。
まず土台です。
ここを飛ばすと、かなりの確率であとで揉めます。

一つ目は、守るべきデータの定義です。
何を機密情報と呼ぶのか。
個人情報、認証情報、契約情報、ソースコード、経営情報、設計情報。
どれをどのレベルで守るのか。
ここが曖昧だと、ルールは必ず揺れます。

二つ目は、データの所在把握です。
ファイルサーバー、SaaS、クラウドストレージ、DB、端末、メール、チャット、バックアップ。
どこにデータがあるのかを見ないと、守りようがありません。
見えていないデータは、だいたい守れません。

三つ目は、分類とラベルの設計です。
ラベルが多すぎると現場は使いません。
少なすぎると制御に使えません。
ここはかなりバランスが必要です。
最初はシンプルでいいです。
でも、制御に使える粒度で作る必要があります。

四つ目は、アクセス権と共有状態の棚卸しです。
誰が見られるのか。
外部共有されていないか。
リンク共有が広すぎないか。
退職者や異動者の権限が残っていないか。
データ漏えいは、攻撃だけでなく、広すぎる共有からも普通に起きます。

五つ目は、DLPの段階導入です。
最初から止めすぎない。
監査、警告、教育、限定ブロック、強制ブロック。
この順番で進めた方が、かなり現実的です。
最初から全力で止めると、現場から強い反発が来ます。

六つ目は、例外管理です。
役員、法務、営業、開発、委託先、海外拠点、特定SaaS。
例外は必ず出ます。
問題は、例外があることではありません。
例外が見えず、期限もなく、誰も見直さないことです。
これはかなり危ないです。

代表的な製品はこの3つから見れば外しにくい

データの柱で代表例を3つ挙げるなら、まずは
Microsoft Purview
Forcepoint DLP
Broadcom Symantec DLP
でよいと思います。

ここでも言いたいのは、どれが絶対に一番かではありません。
現場で比較対象に上がりやすく、考え方の違いを見やすい3つ、という意味です。

Microsoft Purviewは、Microsoft 365、SharePoint、OneDrive、Teams、Endpoint、Defender系とつなげて、分類・ラベル・DLPをまとめて見やすいです。
Microsoft 365中心の環境では、かなり自然に候補に上がります。
既に業務データがM365に寄っているなら、かなり見やすい選択肢です。

Forcepoint DLPは、長くDLP領域で比較対象になってきた製品です。
メール、Web、エンドポイント、ネットワークなど、持ち出し制御を幅広く見たいときに候補に上がりやすいです。
DLPをしっかり設計したい現場では比較しやすいです。

Broadcom Symantec DLPも、DLPの代表的な選択肢として長く使われてきました。
エンタープライズ環境で、既存のセキュリティ運用やデータ持ち出し制御をしっかり見たいときに比較対象になりやすいです。

最近のデータ保護では、これに加えてDSPM系の製品も見ておいた方がいいです。
たとえば、クラウドやSaaSに散った機密データの所在や露出を見たいなら、DSPMの観点がかなり重要になります。
DLPだけで「動き」を見るのではなく、どこに危ないデータがあるかも見る。
この組み合わせが大事です。

参考URL

現場でよくある失敗は、だいたい同じ

一番多いのは、DLPを入れて終わった気になることです。
これは本当によくあります。
製品は入った。ルールも作った。アラートも出る。
でも、分類が弱い。所有者が曖昧。例外が多い。現場が意味を分かっていない。
これでは柱になりません。

次に多いのが、止めすぎて現場から嫌われることです。
最初から強いブロックを入れる。
業務メールが止まる。資料共有が止まる。営業活動が止まる。
そして、例外申請が山のように来る。
最後はルールを緩める。
これはかなり苦しいです。

さらに多いのが、分類ラベルが複雑すぎて使われないことです。
ラベルが多い。意味が分かりにくい。現場が毎回迷う。
そうなると、結局みんな適当に付けるか、付けなくなります。
分類は細かければ良いわけではありません。
使われる粒度が大事です。

もう一つは、外部共有とリンク共有を見ていないことです。
データ漏えいは、マルウェアだけで起きるわけではありません。
広すぎる共有リンク、退職者の残存権限、外部ゲスト、個人アカウントへの共有。
このあたりから普通に漏れます。
ここを見ないDLPはかなり弱いです。

最後に、例外が永続化することです。
この部門だけ。
この役員だけ。
この業務だけ。
このSaaSだけ。
最初は暫定だったはずの例外が残り続ける。
これが積み上がると、DLPは簡単に穴だらけになります。
例外は悪ではありません。
でも、期限のない例外、所有者のいない例外、見直されない例外はかなり危ないです。

この柱が整うと、可視化と分析の柱が回り始める

データの柱が整うと、次は可視化と分析の柱がかなり現実的になります。
ここから先は、各柱から出るログや信号を集めて、判断に変える段階です。

なぜか。
データの柱が弱いと、ログを見ても意味づけが難しいからです。
このファイルは機密なのか。
この共有は危ないのか。
このアップロードは普通なのか。
この外部送信は止めるべきなのか。
ここが分からないと、分析しても優先度がつきません。

逆に、データ分類やラベルが整うと、ログの価値が一気に上がります。
機密データが外部共有された。
個人情報を含むファイルが未承認SaaSにアップロードされた。
ソースコードが個人ストレージに同期された。
こういうイベントに意味が乗ります。

つまり、データの柱は単なるDLPの話ではありません。
次の可視化と分析の精度を上げる前提でもあります。
ここが見えると、データの柱を先に整える意味がかなり腹落ちしやすくなります。

まとめ

データの柱は、DLPを入れる柱ではありません。
何を守るべきかを決め、データの状態と動きを制御に変える柱です。

分類は、何を守るかを決める。
DLPは、危ない動きを止める。
DSPMは、どこにあって危ないかを見る。
この役割の違いを押さえながら、所在、権限、共有、ラベル、例外管理をつないでいく。
すると、データの柱はかなり強くなります。

最初に全部完璧である必要はありません。
でも、守るデータの定義、所在把握、分類、共有状態、段階導入、このあたりを曖昧にしたまま進めると、だいたいあとで揉めます。
ここはかなりの確率で揉めます。
だから先に手を打つ。これが大事です。

DLP導入をゴールにするのか。
それとも、守るべきデータを守るための制御点としてDLPを使うのか。
ここで結果は大きく変わります。

DLPをうるさい装置にするのか。
それとも、データ保護の本当の制御点にするのか。
差がつくのは、導入前の設計です。
そう思います。

恐縮でした。

次回はこちら