パッシブ検出

データ損失防止（DLP）ポリシーを作成する前に、トラフィックにどの種類の機密データが現れ、どこへ向かっているかが分からないことがあります。パッシブ検出（Passive Detection）は、その出発点になります。記録やブロックを決める前に、これらの疑問に答えるのに役立ちます。

パッシブ検出は、Gateway の HTTP リクエストとレスポンスの本文をランダムにサンプリングしてスキャンし、検出結果を 1 つのダッシュボードにまとめます。一致した検出エントリ、出現場所、ポリシーが役立つ箇所を確認できます。得た情報をもとに、焦点を絞ったポリシーを作成したり、既存ポリシーの抜けを見直したりできます。

パッシブ検出は、Gateway の DLP ポリシーがなくても動作します。Gateway のトラフィック処理は変わらず、既存ポリシーはそのまま適用されます。

パッシブ検出の結果を収集するには、次が必要です。

• HTTP トラフィックを Cloudflare Gateway 経由でルーティングする
• Gateway HTTP フィルタリング をオンにする
• HTTPS トラフィックで TLS 復号 をオンにする
• スキャンしたい各検出エントリを、アカウント内の少なくとも 1 つの DLP プロファイル で有効にする。パッシブ検出は、ポリシーに選んだプロファイルだけでなく、アカウント内のいずれかのプロファイルで有効なエントリをスキャンします。

アップロードまたはダウンロードしたファイルについては、対応ファイル形式 を参照してください。Gateway を迂回するトラフィック、または Do Not Inspect ポリシーに一致するトラフィックでは、検出結果は出ません。

宛先へ送ったデータを見るには Request、宛先から受け取ったデータを見るには Response を使います。Unknown には、トラフィック方向が記録されていない HTTP 本文が含まれます。フィルターを外すと、すべてのトラフィック方向が含まれます。リクエスト本文とレスポンス本文は別々にカウントされます。

選んだ期間とトラフィック方向は、エントリを開いて調べるときにも適用されます。

まずアカウント概要で全体像を把握します。そこから検出エントリを選び、出現場所、一致したプロファイル、ポリシー適用の有無を確認します。

サマリーカードは、選んだ期間とトラフィック方向の検出を示します。

• Total detections: 各エントリは、HTTP 本文ごとに 1 回カウントされます。
• Unique traffic with detections: 少なくとも 1 件の検出がある HTTP 本文を、1 回ずつカウントします。
• Entries detected: 選んだ範囲で一致した一意の DLP エントリです。

たとえば、2 つの異なるエントリに一致する 1 つのリクエスト本文は、Total detections に 2 件、Unique traffic with detections に 1 本文として加算されます。これらの件数は、本文に含まれる個々の機密値の数を示すものではありません。

どのエントリが検出の大半を占めるかは、Detections by data type で確認します。ポリシーの見直しが必要なエントリは、Policy coverage で探します。

次に、検出テーブルを使って調査対象を決めます。エントリを比較し、プロファイルと宛先を確認します。テーブルには、サンプリングしたトラフィックで見つかった検出エントリごとに 1 行あります。検出のないエントリは表示されません。

次の項目でエントリを比較します。

時刻はすべて UTC で表示されます。

同じ本文が、複数の一致プロファイル経由で信頼度カウントに加算されることがあります。そのため、1 つの信頼度レベル内でも、信頼度カウントの合計が検出本文数を超えることがあります。

エントリを選んだら、開いて出現場所を確認します。詳細ビューには、時系列の検出と信頼度、そのエントリに関連する宛先とアプリケーションが表示されます。

宛先は、ホストと正規化したパスで URL をグループ化します。たとえば、/users/12345 のようなパスは /users/{id} の下にまとめられます。各宛先には、検出件数、信頼度、トラフィック方向、最終検出時刻が含まれます。

宛先を展開すると、一致した URL の一部、検出件数、最終観測時刻を確認できます。想定どおりのアプリケーションか、追加調査が必要な宛先かを判断するために使います。

たとえば、見慣れないファイル共有先に関連する検出は、詳しく確認する価値があります。ポリシーを作成する前に、その宛先が対象データに対して承認されているかを確認します。

ダッシュボードに表示されるのは検出メタデータです。元のリクエスト本文とレスポンス本文は保存されません。

Policy coverage は、詳しく確認すべき検出を見つけるのに役立ちます。HTTP 本文のスキャン時に、一致する DLP プロファイルが少なくとも 1 つポリシー適用対象として選ばれていれば、その検出はカバー済みとしてカウントされます。

カバー済みであっても、Gateway ポリシー全体が一致したことや、Gateway がトラフィックを記録またはブロックしたことは保証されません。ダッシュボードはカバー状況を次の 3 つに分類します。

まず Not covered または Partly covered のエントリから始め、宛先と関連ポリシーを確認します。カバーの抜けは調査のきっかけであり、すべての検出をブロックすべきという推奨ではありません。

検出されたデータとその出現場所が分かったら、トラフィックに合ったポリシーに落とし込みます。すべての検出に同じアクションを適用するのではなく、保護が必要なデータ種別と宛先に焦点を当てます。

既存ポリシーの場合は、検出結果を使って範囲と検出設定を見直します。データセキュリティ分析 には、設定済み DLP ポリシーのアクティビティが表示されます。

• パッシブ検出は、対象となる Gateway HTTP トラフィックのランダムサンプルをスキャンします。すべてのリクエストまたはレスポンス本文は対象ではありません。
• 検出件数が多い場合、分析のサンプリングにより件数が推定になることがあります。件数はサンプリングしたトラフィックを表し、対象となるすべての Gateway トラフィックではありません。
• ダッシュボードは、サンプリングしたトラフィックの総量や検出率は報告しません。
• 宛先は 1 つの検出エントリにスコープされます。パッシブ検出は、アカウント全体の宛先一覧は提供しません。
• 結果にユーザー ID は含まれません。

ダッシュボードが空でも、機密データがないことは保証されません。

結果が表示されない場合は、DLP のトラブルシューティング を参照してください。