アイデンティティとセキュリティ

コンプライアンスのみでなく、今日のクラウド中心の世界に合わせて DLP を再考

cloud dlp.jpg

※この投稿は米国時間 2020 年 7 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。


データ損失防止(DLP)技術はその名前が示すとおり、データの漏洩と損失につながる可能性のある攻撃やその他のイベントを組織がモニタリング、検出し、最終的には防止できるように設計されています。DLP 技術エコシステムはネットワーク DLP、エンドポイント DLP、データ検出 DLP に対応していて、約 20 年もの長い歴史があります。データの損失と漏洩による影響が消えることはないため、組織にとって重要なセキュリティ管理の一つであり続けます。

このブログでは、まず DLP の歴史を振り返り、次にコンプライアンス、セキュリティ、プライバシーのユースケースなど、DLP が今日の環境でどのように役立つかについて説明します。

DLP の歴史

とはいえ、これまで DLP 技術は組織にとって克服困難ないくつかの問題を提起してきました。以下に例を挙げます。

  • ビジネス部門と IT 部門の間の溝
  • 想定の不一致
  • 導入の逆風
  • DLP アラートの優先順位付けが困難


また、DLP ソリューションが登場したのは、セキュリティ技術が主としてハードウェア アプライアンスやデプロイ可能なソフトウェアの時代でした。しかし、クラウドがコンセプトとしてはほとんど存在せず、大半の組織は境界セキュリティに重点を置いていました。つまり、DLP はデータがネットワークの境界を通過する際のブロックや検出に焦点を合わせていました。クラウドやその他の進歩とともに、このやり方は現実にそぐわなくなっていて、ユーザーもアプリケーションもたいていは境界の外側に存在しています。

こうした新しい現実により、次のような今までなかった課題の解決を余儀なくされています。

  • コンテナ、マイクロサービス、スマートフォン、スケーラブルなクラウド ストレージが従来の PC やメインフレームと共存する今日の世界に合わせて DLP をどのように変革するか?
  • 以前のコンプライアンス義務が最新の脅威や進化するプライバシー要件と共存する世界で DLP をどのように適用するか?
  • DLP はセキュリティ専門家の間で評判を落としているいくつかの問題を避け、どのように進化するのか?

DLP の現在

では、DLP のユースケースにまつわる混乱の原因から説明します。DLP 技術は今日、規制管理として挙げられることはまれですが(例をこちらに示します)、数年間は主にコンプライアンス ソリューションとして広く認められていました。そうしたコンプライアンスの焦点にもかかわらず、DLP 技術を利用して脅威検出のミッションに対応し、意図的なデータの盗難や危険なデータの過失を検出する組織もありました。今日、DLP はプライバシー イニシアチブをサポートするために採用され、ストレージ内や使用中の個人データのモニタリング(およびリスク最小化)に使用されます。

逆説的に言えば、これらの DLP ドメインが、一部の組織では互いに競合する場合があります。たとえば、内部脅威を検出するための従業員の詳細なモニタリングが間違って実装された場合、プライバシー ポリシーと競合する可能性があります。

今日の DLP の最適な利用法はセキュリティ、プライバシー、コンプライアンスの 3 つを満たしています。3 つのドメインのユースケースに対応し、運用するチームに過度な負担をかけないようにする必要があります。最新の DLP はパフォーマンス プロファイルにより、クラウド移行にうってつけの候補でもあります。実際、膨大なエンタープライズ データがクラウドに迅速に移行されているというだけの理由で、DLP もクラウドに移行する必要があります。

この新たなクラウドの世界で DLP がコンプライアンス、セキュリティ、プライバシーにどのように役立つかを示すために、各ドメインの Cloud DLP ユースケースを分類し、ヒントとベスト プラクティスをいくつかご紹介します。

コンプライアンス

多くの規制は、支払いデータや個人の健康情報など、特定の種類のデータを保護することに主眼を置いています。これにより、どのように特定の種類のデータを見つけて未然に保護できるようにするかなどの問題が生じる可能性があります。もちろん、すべての組織は適切に管理されたデータを保持し簡単に特定できるようにしようと努めています。また、今日の世界では複数のリポジトリに大量のデータが保存されていて、これは口で言うほど簡単ではありません。

支払いカードデータを対象とした業界の義務である Payment Card Industry Data Security Standard(PCI DSS)の例を見てみましょう(Google Cloud での PCI DSS の詳細については、こちらをご覧ください)。10 年以上前は多くの場合、PCI DSS の対象範囲だったデータ(支払いカード番号)がカード会員データ環境(CDE)と見なされたもの以外で見つかりました。このため、クラウド環境が普及する前でもデータ検出が注目されていました。

現在、「有害な」データ(支払いカード番号など、コンプライアンスで手間のかかる可能性のあるデータ)を検出する必要性はさらに強くなっていて、データ検出 DLP は、あちこちに移動する支払いデータを見つけるための一般的な方法です。クラウドに移行する際も同じロジックが適用されます。カードデータをクラウド リソースでスキャンし、処理するように指定されたシステムやコンポーネント以外に規制対象データがないことを確認する必要があります。

このユースケースは評価時のアクティビティではなく、PCI DSS で現在「BAU」(通常の業務)と呼ばれているものに含まれます。多くの場所を定期的に広範囲スキャンしてから、そのようなデータが誤って表示されることがわかっている「リスクの高い」場所を詳細にスキャンすることをおすすめします。これは、四半期ごとでも一年ごとでも、各監査や評価の前の詳細な広範囲スキャンと組み合わせることができます。

このユースケースで Google Cloud DLP を最適に構成する方法に関する具体的なアドバイスについては、こちらのページをご確認ください

セキュリティ

DLP 技術はセキュリティ リスク削減プロジェクトにも役立ちます。たとえば、データの検出では明白なセキュリティ ユースケースとして、一般公開すべきではないときに公開されている機密データの検出や、公開されたコードでのアクセス認証情報の検出などがあります。

データ変換機能を搭載した DLP は、機密データの機密性を低下させることを主な目的とするさまざまなユースケースにも対応できます。これにより、保持するリスクが減少し、サイバー犯罪者にとっての魅力が低下します。これらのユースケースは銀行口座番号のトークン化などの日常的なものをはじめ、意図的に破損したデータから AI トレーニング データ パイプラインを保護するような難解なものまで多岐にわたります。「盗難に値する」貴重なデータを無害にするこのアプローチは、最近のデータ セキュリティ業務では十分に活用されていません。1 つには、いわばデータ アクセス コントロールを使用するだけの場合と比較して手軽で簡単なツールがないためです。

この方法の具体的な適用先としては、アカウント番号やアクセス認証情報などの機密情報、さらには特定の従業員に見せたくないデータ(顧客データなど)が有力な候補です。場合によっては、外部の攻撃者にとって魅力がないデータを作成することではなく、簡単に達成できるものを探している内部の攻撃者が誘惑されにくくなることを重視しています。

プライバシー

プライバシーに DLP を使用することに関しては、当初は課題を含んでいました。これは、エージェントベースのエンドポイント DLP をはじめ一部の種類の DLP は、エージェントがインストールされたシステムを使用しているユーザーについて多くの情報を収集するためです。実際、DLP はプライバシー保護の技術ではなく、プライバシーのリスクと見なされることがよくありました。ただし、Google Cloud DLP はセキュリティ技術になる以前から、プライバシー保護の技術として誕生していました。

ところが、データを検出、変換、匿名化できるタイプの DLP は、ストレージ内か(ストリームとして)移動中かを問わず、プライバシー重視のプロジェクトに明確な価値をもたらします。プライバシー リスクであるデータの変換を伴うユースケースの範囲は広く、名前、住所、年齢(少人数のグループを分析すると年齢から個人の身元が明らかになる可能性もあります)、電話番号などが含まれます。

たとえば、マーケティング目的(傾向分析など)でデータが使用されているものの、本番環境のデータストアが照会される場合を見てみましょう。この場合、タスクの値を手元に保持し(引き続き正しい傾向を確認できます)、不正使用されるリスクを破壊する(人の識別につながる可能性があるビットを削除するなど)方法でデータを変換した方が賢明です。

また、プライバシーのリスクが低い 2 つのデータセットを組み合わせて、リスクが大幅に高いデータセットを作成するユースケースでも、プライバシー DLP が役立ちます。たとえば、小売企業が顧客のショッピング履歴とロケーション履歴(店舗への訪問など)をマージする場合などです。意図しない露出のリスクを減らすために、再識別のリスクを測定し、マージの前後にデータセットを変換することは理にかなっています。

次のステップ

ここまでご紹介した例により、最新のクラウド ネイティブ DLP が今日のいくつかのデータ課題に対する強力なソリューションになると示すことができれば幸いです。Google Cloud DLP の詳細や、どのように組織に役立つかにご興味をもたれた場合は、次のことをお試しください。

  • まず、購入してスタンドアロンで使用するものではなく、データ セキュリティ、コンプライアンス、プライバシー プログラムの不可欠な要素として DLP を取り入れます。
  • 次に、保護する必要がある機密データの種類など、ニーズとユースケースを確認します。
  • 3 番目に、Google Cloud DLP の資料として、こちらの動画ブログなどを確認します。プライバシー プロジェクトについては、特に個人データの匿名化に関するガイダンスをご確認ください。
  • 4 番目に、特定環境に DLP を適用する具体的なレッスンを学ぶために、1 つまたはごく少数のユースケースを実装します。たとえば、多くの組織にとって最初のユースケースは、特定のリポジトリで 1 種類のデータを検出するためにスキャンする可能性があります。
  • Google は、この新しい時代、特定のユースケース、クラウド ネイティブ テクノロジーのために Google Cloud DLP を構築しました。ご利用開始に関するその他のリソースについては、Cloud Data Loss Prevention のページをご覧ください。


- Google Cloud プロダクト マネージャー Scott Ellis、ソリューション戦略担当責任者 Anton Chuvakin