## 現代のDLPの盲点 機密データの損失防止は、歴史的にエンドポイントまたはネットワークの問題として扱われてきました。エージェントをデプロイし、ファイルを検査し、トラフィックを監視すれば、カバレッジが得られる――そう思っていたかもしれません。 当社の最近の分析によると、Webアプリケーションへの機密ファイルアップロードの46%が、承認されていないアカウントに送信されており、組織がデジタルエコシステム全体を流れるデータの監視と制御の方法に大きなギャップがあることが明らかになりました。 セキュリティチームは、DLPカバレッジが十分にあると考えていますが、実際には、データが現在どこに移動しているのかについての可視性と制御が欠如しています。それはブラウザ内です。 ## DLPが失敗する理由：ブラウザでの作業が隠されている エンタープライズワークフローは、エンドポイント上のソフトウェアからブラウザベースのアプリケーションへと移行しました。今日、従業員は一般的に**Google Workspace**、**Microsoft 365**、または**Salesforce**を使用しています。開発者は**GitHub**、**Jira**、および社内Webアプリケーションを利用しています。多くの部門が現在、**ChatGPT**やコパイロットのようなAIツールを採用しています。 ファイルをダウンロード、変更、そして承認されたWebアプリケーションに再アップロードする代わりに、ユーザーはアプリケーション間またはアプリケーション内からデータをコピーしたり、さまざまなツールにファイルをアップロードしたり、WebフォームやAIプロンプトにデータを入力したりすることで、ブラウザ内で直接データとやり取りしています。 これらのアクティビティのリスクを増大させているのは、従業員が制限なしに個人アカウントや承認されていないインスタンスを頻繁に使用するという単純な事実です。 言い換えれば、チームが依存している従来のDLPコントロールは、現代の活動の多くが発生している場所でインストルメントされていません。 ## 機密データがブラウザから実際に流出する仕組み 既存のDLP実装がなぜ不十分なのかを理解するには、現代の環境でデータ漏洩が実際にどのように発生するのかを見る必要があります。ブラウザセッション内では、ユーザーはWebページやアプリケーション（承認されたものもそうでないものも）にデータを入力、貼り付け、アップロードできます。 **コピー＆ペースト:** ユーザーは日常的に、顧客レコード、認証情報、ソースコードなどの機密データを社内システムからコピーし、個人のメール、SaaSアプリ、AIツールに貼り付けます。クリップボードは、ほとんどの従来のDLPソリューションがコンテキストを付けて検査または制御できない高リスクチャネルになっています。 **フォーム入力とAIプロンプト:** 機密データは、必ずしもファイルとして移動したり、クリップボードの内容から貼り付けられたりするわけではありません。Webフォーム、SaaSアプリケーション、さらにはAIプロンプトに直接入力されることがよくあります。 ブラウザセッション内でのみ動作するため、エンドポイントおよびネットワークDLPコントロールはトリガーされません。  *Keep Awareのコンソールに表示されたペーストイベントは、ユーザーが組織に関連付けられたChatGPTアカウントにコードを貼り付けたことを示しています。* **SaaSおよびAIツールへのファイルアップロード:** ファイルアップロードは依然として主要なデータ損失ベクトルであり、表面上は通常の活動のように見えます。従業員はソースコード、財務データ、顧客レコードをアップロードします。しかし前述のように、これらのアップロードの半分近くが、個人アカウントや承認されていないツールを含む、承認されていない宛先に送信されている可能性があります。 **シャドーアカウントとインスタンス:** 承認されたドメインやアプリケーション内でも、リスクと可視性のギャップは残ります。ユーザーは、法人アカウントではなく、個人アカウントを使用してAIプロンプトにPHIレコードをアップロードしたり、機密ファイルを個人の**Google Drive**やその他のSaaSツールに保存したりする可能性があります。 従来のDLPの観点からは、このアクティビティは、そのドメインでの通常の利用と区別がつかないことがよくあります。  *Keep Awareのコンソールに表示されたアップロードイベントは、従業員が個人用ChatGPTアカウントに機密性の高い可能性のあるドキュメントをアップロードしたことを示しています。* ブラウザでのデータ損失は、多くの場合、通常のユーザー行動のように見えますが、間違ったコンテキストで行われています。 ## ブラウザでの機密データ漏洩の実際の例 一般的なワークフローを考えてみましょう。開発者が会社のプライベート**GitHub**リポジトリにアクセスし、独自のソースコードのブロックをコピーし、次に問題のトラブルシューティングのために個人の**ChatGPT**セッションを開きます。そのコードをAIプロンプトに貼り付けると、機密データは効果的に組織から流出しました。 ファイルはダウンロードもアップロードもされませんでした。会社は**ChatGPT**へのトラフィックを許可しているため、ネットワークベースの保護はトリガーされませんでした。従来のDLPコントロールはペーストアクションをフラグ付けしませんでした。この一連のイベントはすべて、会社の機密データに実際のリスクをもたらしているにもかかわらず、無害なユーザーおよびブラウザのアクティビティとして表示されます。 ブラウザネイティブDLPを使用すると、このインタラクションは完全に可視化され、強制可能になります。**Keep Aware**のようなブラウザベースのDLPソリューションは、機密データを検出し、それが承認されたアプリから発生したことを理解し、個人アカウントに関連付けられた承認されていないAIツールに送信されていることを認識します。 その後、ポリシーによってユーザーのアクションをブロックしたり、セキュリティチームにアクションを警告したり、イベントの完全なタイムラインをキャプチャしたりできます。これにより、そうでなければ見えないものが、明確で実行可能なセキュリティシグナルに変わります。  *開発者がプライベートリポジトリから個人のChatGPTアカウントに独自のコードをコピー＆ペーストするタイムライン。* ## ブラウザにおける従来のDLPのギャップ 従来のDLPソリューションは、エンドポイント、ネットワーク、さらにはクラウド環境からのデータ漏洩を防ぐことに焦点を当てた、異なるリスクモデルのために設計されました。 エンドポイントDLPは、ブラウザ内でのコピー＆ペーストデータ、Webアプリケーション自体、および使用されているユーザーアカウントの種類に対する可視性を欠いています。これらはすべて、機密データを効果的に管理するために必要な重要なコンテキストデータポイントです。 同様に、ネットワークDLPは、プロキシソリューションが暗号化されたブラウザトラフィックの検査を可能にする場合でも、同じ重要なコンテキストを欠いています。リモートおよび分散されたワークフォースは、根本的な可視性の問題にさらに拍車をかける可能性があります。 クラウドDLPは、エンドポイントおよびネットワークDLPソリューションの組み合わせのようなものですが、ITセキュリティによって既に承認および管理されている特定のSaaSインスタンスまたはクラウド環境に対する可視性と制御を提供します。 従来のDLPは、保存されているファイルと移動中のデータを調べますが、今日のワークフォースで最も広く使用されているアプリケーション内でのユーザーアクティビティとセッションコンテキストを検査するように設計されていませんでした。ましてや制御するようには設計されていませんでした。 ## ブラウザネイティブDLP：最新のデータ保護におけるギャップを埋める ブラウザネイティブDLPは、ユーザーのブラウジングセッション内で直接動作し、組織が以下を可能にする可視性を備えています。 * **リアルタイムでのデータ検査**（コピー＆ペーストアクティビティ、フォームおよびプロンプト入力、ファイルアップロード） * **コンテキストの理解**（使用中のアプリケーション、アカウントまたはインスタンスが法人か個人か、どのような種類のデータが扱われているか） * **インラインコントロールの強制**（リスクのあるアクションのブロックまたは警告、コンテキストに基づいた条件付きポリシーの適用、生産性を妨げることなく安全なワークフローの許可） このアプローチは、組織の既存のDLPスタックを置き換えるものではありません。それはそれを補完し、ネットワークレベルおよびエンドポイントツールでは対処できるように設計されていなかった、明白な可視性のギャップを埋めます。 **Keep Aware**は、この機能をブラウザ自体に直接もたらします。ファイル移動シグナルやネットワークトラフィックに依存するのではなく、ユーザーインタラクションのポイントで動作し、アプリケーション、インスタンス、および関与するアカウントのコンテキストとともに、入力されたテキスト、コピー＆ペーストアクティビティ、およびアップロード全体でリアルタイムにデータを分析します。インライン強制ポリシーは、セキュリティを強化します。