VPNログは閲覧履歴を証明できるのか？証拠が示すもの
セッションログ、リゾルバへの問い合わせ、フローレコードが証明するものはそれぞれ異なります。問いを選び、身元と時刻を結びつけ、示されたことだけを述べてください。
監査の二つの問いは似て聞こえるが、必要な証拠の種類が違う。どのセッションがこのアドレスに接続したかは、接続記録とフローレコードから答えられる。どの個人がこのページを開いたかは通常は答えられない。少なくともそれらの記録からは答えられない。問いを選ぶ前に収集手段を選ぶと、ネットワークチームはホスト名を閲覧履歴として提示する結果になる。
監査が立証すべき出来事から始める
問いを、主語・述語・時刻を備えた文として書く。この規律だけで セッション記録とページ閲覧のあいだの隔たり が露呈する。セッションログは、ある身元が一定の区間、記録された方針のもとで割り当てられたアドレスとともに受け入れられたことを立証する。しかし要求を一度も見ていないため、誰がどのページを読んだかは立証できない。
収集を設計する前に、観測に名前を付ける。訪問先のサイトにちなんで名付けられながら、実際には解決済みの名前を保存している項目は、便利さではなく将来の誤りである。項目名はそれを選んだ人より長く生き残る。だから結論ではなく証拠を記述する名前を選ぶ。
各記録が支えられること、支えられないこと
ほとんどすべての監査設計に四種類の記録が現れ、それぞれが異なる問いに答える。報告書でもパイプラインでもこれらを分けておく。混ぜ合わせることこそ、防御可能な所見を恥ずかしいものに変える道である。
| The question being asked | Record that can answer it | What that record proves | What still needs a join |
|---|---|---|---|
| Was this address contacted? | Flow record | The connection five-tuple and when it was seen | Which session held the address at that moment |
| Which account held that address? | Session log | Which identity authenticated and the tunnel address it received | Which device or person used that account |
| Was this name looked up? | Resolver query | That this resolver was asked for this name | Whether a page was fetched, and by whom |
| Was this page viewed? | Proxy or application transaction | The request and identity recorded inside that application's scope | Traffic outside that application's visibility |
| Who was the person? | None of the four on its own | An account in use, at best | A named human, whenever accounts are shared |
最後の列を中央の列と同じ注意深さで読む。フローレコードはアドレスとポートを記述し、アドレスの逆引きはブラウザが使った名前を再構成しない。一つのアドレスが多数の無関係なサイトを収容しうるからである。リゾルバへの問い合わせは問いが発せられたことを証明するが、ページが表示されたことは証明しない。TLS交渉中に見えるホスト名も、暗号化された要求経路ではない。
いずれも実際の観測であり、どれも人々が想定する観測ではない。独自の暗号化リゾルバに固執するブラウザは監視範囲の外にあり、記録が一度も見なかったものを分析で取り戻すことはできない。その隔たりは脚注ではなく、明示された限界として報告書に属する。
先読みの問い合わせとキャッシュされた応答
ブラウザは名前を先読みして解決し、ときには何も読み込まずに済ませる。監視しているリゾルバへ新しい問い合わせを送らずにキャッシュから答えることもあり、問い合わせがないことは訪問がないことを意味しない。どちらの挙動も、DNSログと閲覧履歴のあいだの素朴な等式を壊す。
HTTPS上のDNSは第二の境界を加える。独自のリゾルバを持つブラウザやゲストアプリは、組織の記録装置に何も尋ねない。正確な取引は、アプリ自身のイベントか、記録を明示的に支えているプロキシからしか得られない。通常のHTTPS CONNECTトンネルでは、プロキシは内部のページ経路をまったく見えない。ネットワークを所有することは、アプリの信頼モデルを黙って差し替える許可ではない。
アドレスはセッションに属し、個人には属さない
トンネル範囲のアドレスを持つフローレコードは答えではなく出発点である。そのアドレスと時刻を、その瞬間に有効だったセッション割り当てに結びつける。一時間後には別のセッションに割り当てられうるからである。静的アドレス指定はこの対応を保つ一つの方法であり、唯一の方法ではない。
翻訳の段階が複数の機器をセンサーより上流の一つの送信元アドレスにまとめる場合、結合は共有ゲートウェイのセッションしか名指せない。共有アカウントや複数人が使う証明書は、ネットワークデータがどれほど完全に見えても帰属を制限する。どちらも後日の留保ではなく、限界として報告書に属する。
時間帯、時計の出所、観測点、そしてその間のすべての翻訳境界を記録する。不在は存在と同じ配慮に値する。記録がないことは、フロー項目が失効したこと、センサーがパケットを一度も見なかったこと、アプリのログが切られていたことを意味しうる。
宣言した目的のために設計し、その後パイプラインを証明する
問いが固まったら、どの項目が必要か、誰が読めるか、どれだけ保持するかを定める。保存が安いからと多く集めることは、調査より長く残る負債を生む。RFC 6973 のプライバシーモデルは、相関、誤帰属、不要な収集を後付けの配慮ではなく設計上の問題として位置づけている。
対応表と記録を一つの対象として守る。どちらか単独では、組になった場合よりはるかに機微でない。次に、生成を許されていてすでに理解している活動に対して、報告書が依拠する最小の問い合わせで設計を検証する。既知の出来事を再現できないパイプラインは、未知の出来事も再現しない。証拠が支える出来事を、証拠が許す言葉で報告し、より大きな結論に達するのは読み手に委ねる。
所見の隣に限界を書く。何を結合し、何を翻訳し、どのログが沈黙したままだったか。自らの境界を明示する所見は、自信に満ちた要約が耐えられない査読に耐える。それが証拠と、証拠についての物語との違いである。