画面が一度撮影またはスクリーンショットされ外部に共有されると、データは出ていってしまいます。残る唯一の意味ある問いはこれです：誰がこれを生んだのか？ この答えがなければ、インシデントは解けない謎に変わります — そして結果が出ないことが、次の漏洩へのそれ自体の誘因になります。
従来の答え — ユーザーの名前が画面に表示される可視ウォーターマーク — は抑止として機能します。しかし画像をウォーターマークのない部分でトリミングするか、そう撮影することでそれを取り除けます。ユーザーはそれを知っており、抑止効果は時間とともに薄れます。
最新の発生源特定には2つの層が必要です。ユーザーに自分が識別可能だと感じさせる可視マークと、可視のものへの明白な攻撃に耐えるよう実際のピクセルデータに埋め込まれた不可視の痕跡です。ZeroLeakは両方を追加します：可視マークが容易な漏洩を抑止し、不可視の痕跡が注意深い者を捕捉します。
両方のウォーターマーク層は同じ場所で適用されます：ユーザーのブラウザが受け取るnoVNCビューアです。いずれの層も保護対象WebアプリケーションのDOMには存在しないため、いかなるWebサイトもそれらに干渉できず、いかなるフロントエンドポリシーもそれらを取り除けません。可視層は保護対象サービスごとに構成されます。不可視の痕跡識別子はセッションごとに生成されます。
ユーザー名、セッションID、またはカスタムテキストが、生成されたページの上にmix-blend-modeを使って配置されます — そのため明るいコンテンツでも暗いコンテンツでも見えたままになります。ユーザーは見るあらゆる画面で自分が個人的に識別可能であることを知ります — 容易なスクリーンショットに対する継続的で強力な抑止です。
ユーザーが見るすべてのフレームの実際のピクセルデータに、セッション固有のパターンが書き込まれます。このパターンはトリミング、スケーリング、JPEG再圧縮、再撮影に耐えるよう設計されています。後にスクリーンショットが現れたとき、埋め込まれた識別子はそれを生んだセッションを特定します — 可視ウォーターマークがトリミングで取り除かれていても。
可視ウォーターマークは最大3つの独立した層をサポートし、それぞれが自身のテキスト、位置、回転、フォント、不透明度、タイルサイズを持ちます。斜めのユーザー名、中央のセッションID、隅のタイムスタンプを併用すると、有用な画面領域を失わずに可視マークをトリミングで取り除くことがはるかに困難になります。
可視ウォーターマークをトリミングで取り除く、画像をメッセージングアプリ向けに縮小する、モニターを電話で撮影する — 不可視の痕跡識別子はこれらすべてに耐えます。なぜならそれはオーバーレイではなくピクセルデータそのものの一部だからです。復元された画像から痕跡識別子を解読するとセッションが特定されます。
以下の各項目は保護対象サービスごとに独立して構成可能です。抑止で十分な低機密のコンテンツには可視層のみ。発生源特定が可能であるべき高機密のコンテンツには2つの層を併用してください。
可視ウォーターマークのテキストは、セッション開始時に認証されたユーザーID、セッションID、タイムスタンプ、またはポリシーで選択された任意の組み合わせから構成されます。画面上のウォーターマークは汎用ロゴではなく、閲覧している特定の個人を反映します。
ウォーターマークは背景色に応じて自身を反転させるmix-blend-modeを使います。通常は黒または白のページで見えなくなるウォーターマークが、どこでも読めたままになります — 目は、下のページが何を表示していようと一貫したマークを見ます。
併せて最大3つの可視層まで構成できます。各層は自身のテキスト、色、不透明度、フォント、回転、タイルサイズ、位置を持ちます。層は斜めに繰り返したり、中央に配置したり、隅に固定したりできます — ある層を取り除くようスクリーンショットをトリミングしても、他の層は依然として残ります。
ユーザーが見る生成されたフレームに、セッション固有の痕跡パターンが埋め込まれます。埋め込み処理は一般的な画面漏洩攻撃に耐えるよう設計されています — トリミング、メッセージングアプリ向けの縮小、JPEG再圧縮、モニターを電話のカメラで再撮影すること。いずれもセッションIDを復元するのに十分なパターンを残します。
漏洩した画像が見つかったとき、オペレーターはそれをデコーダーに通します。デコーダーは埋め込まれた痕跡パターンを読み取り、それを生んだセッションIDを返します。オペレーターは監査記録からそのセッションを検索し、ユーザーID、タイムスタンプ、関連する保護対象サービスを見つけます。
両方のウォーターマーク層はユーザーのブラウザが受け取るnoVNCビューアで適用されます — 保護対象アプリケーションのDOMではありません。保護対象アプリケーションはウォーターマークを認識せず、それに干渉できません。フロントエンドフレームワーク、trusted-HTMLポリシー、保護対象アプリケーション内のブラウザ拡張機能 — いずれもマークにアクセスできません。
異なる漏洩チャネルは漏洩画像を異なる方法で劣化させます。不可視の痕跡識別子は現実的な攻撃に対して設計されており、何を復元でき何を復元できないかについて正直です。
攻撃者がスクリーンショットを望むデータ領域までトリミングし、すべての可視ウォーターマークテキストを取り除きます。不可視の痕跡識別子はフレーム全体に分散されておりトリミングに耐えます — 元のフレームの妥当な大きさの領域を復元すれば識別子を解読するのに十分です。
ほとんどのメッセージングアプリは共有された画像を縮小しJPEGとして再圧縮します。痕跡パターンは一般的な縮小率とJPEG圧縮アーティファクトに耐えるよう冗長に設計されています。
ファイルシステムの痕跡を残したくない攻撃者が画面に電話を向けて写真を撮ります。痕跡パターンは光学キャプチャに耐えるよう設計されています — 電話カメラの写真は、デコーダーが依然としてセッションIDを見つけられるよう十分な空間周波数情報を保持します。
画面のごく一部だけを漏洩させる攻撃者 — 1つの文、1つの数字 — は利用可能な痕跡パターンの量を減らします。デコーダーは小さな領域については低い信頼度を報告します。極端な場合、痕跡は解読不能になります。正直な境界です — すべての漏洩が特定可能なわけではありません。
漏洩画像を重いガウシアンブラー、生成AIの画像フィルタに通す、あるいは可視コンテンツを手で描き直す攻撃者は、元の情報の大部分とともに痕跡パターンも破壊し得ます。この時点で漏洩画像はもはや画面上のものの忠実なコピーではありません — 失われるのは発生源特定だけではありません。
IPO前の文書、M&A資料、投資ポジション — 公表前に多数の人が読む高価値情報。報道で漏洩が出たとき、どのセッションから来たかを特定することが、解決不能なインシデントと実行可能な調査の違いになります。
医療スタッフは患者データを正当に画面で読みます。漏洩した患者記録が外部に出たとき、可視ウォーターマークは容易な漏洩を抑止し、不可視の痕跡識別子は漏洩が起きた場合にセッションを特定します — 閲覧権限のみを持つロールについてHIPAAの説明責任を支えます。
同じ機密分類コンテンツを複数の人が見るアナリストデスク。ユーザー別マークは個人の説明責任を具体化します。不可視の痕跡識別子は、漏洩がオープンソースインテリジェンスに浮上したときに調査を可能にします。
お客様の環境に閲覧権限のみを与えられた外部の当事者。見るあらゆる画面上のユーザー別の可視マークは、彼らが識別可能であることを思い出させます。不可視のマークは、漏洩が彼ら自身のサブネットワークで現れたときに状況を証明可能にします。
ZeroLeakのフォレンジックウォーターマークをライブデモでご覧ください。セッションを開き、スクリーンショットを取り、トリミングし、縮小し、モニターから撮影します — そして毎回、痕跡識別子をセッションに解読し直します。