VPNログが閲覧について証明できることとできないこと

ログ収集ツールを選ぶ前に、監査が立証すべき事象を決めてください。どのVPNセッションが宛先アドレスに接続したかを問うことと、どの人物が特定のページを開いたかを問うことは別の問いです。両者は異なる記録、異なる結合、異なる信頼水準を必要とします。OpenVPN の接続ログは前者に答え、後者には答えられません。

収集ツールを選ぶ前に事象を名づける

セッション記録は、受け入れられた身元、開始と終了の時刻、サーバーが独自のポリシーに従って割り当てたアドレスを示します。リゾルバのログは、そのリゾルバで名前が問い合わせられたことを示します。フロー記録はアドレス、ポート、プロトコル、時刻を示し、アプリケーションのログはそのアプリケーションが実際に処理したトランザクションを示します。この四つのどれも他の代わりにはなりません。

それぞれが一つの事象を立証し、他は開いたままにします。問いを先に書き留めれば、データが支えられない物語を組み立てることを防げます。

journalctl -u [email protected] --since today | grep -i 'peer info\|assigned'
cat /etc/openvpn/server/openvpn-status.log | head -20
conntrack -L -p tcp --dport 443 2>/dev/null | head -20

最初のコマンドはサービスのジャーナルからセッションの事象を示します。二つ目は割り当て済みアドレスを含む現在のクライアント一覧を出力し、これが監査の結合が依存する対応表です。三つ目はライブのフロー状態を示し、接続が存在する間だけ役に立ちます。

検索は訪問ではない

ブラウザは名前を投機的に解決し、応答をキャッシュし、監視対象のリゾルバに再び問い合わせることなく再利用します。したがってリゾルバのログにある名前は検索を証明し、訪問を証明しません。HTTPS上のDNSは、そのために設定されたブラウザが通常のロガーには決して見えない場所へ問い合わせを送るため、この隙間をさらに広げます。

宛先アドレスだけでは十分ではありません。一つのアドレスが無関係な多くのサイトをホストでき、逆引きDNSは再構成ではなく推測であり、TLSハンドシェイク中に見えるホスト名は暗号化されたセッション内のリクエスト経路ではありません。

正確なトランザクションには、アプリケーション自身の事象記録か、記録用として明示的にサポートされたプロキシ設計が必要です。CONNECTトンネルはプロキシに宛先と量を与えますが、内部のページ経路は与えません。ネットワークへの管理アクセスは、アプリケーションの信頼モデルを黙って置き換える許可ではありません。

人物を特定する前に身元と時刻を結合する

内部の送信元アドレスを持つフロー記録は、そのアドレスが同じ時刻にセッションと結合されるまで何も意味しません。アドレスは再利用され、同じアドレスが一時間前には別のセッションのものだった可能性があります。静的割り当ては関連を保つ一つの方法であり、唯一の方法ではありません。

翻訳の境界は結合をさらに弱めます。複数の端末が観測点より前にすでに一つの送信元アドレスを共有していたなら、特定できる最善のものは単一の端末ではなく共有ゲートウェイのセッションです。複数の人が使う証明書やアカウントも同じ効果を持ちます。

時間帯、時計の出所、観測点、そして翻訳の各段階を記録してください。記録の欠落は、フローの項目が期限切れになった、センサーが迂回された、アプリケーションのログが切られていたことを意味する場合があります。不在は何も起きなかった証拠ではありません。

次に、宣言した目的に対する最小の項目、許可された閲覧者、保存期間を定めてください。相関と誤帰属は後付けではなく設計の課題であり、人を特定するメタデータはそれが依存する身元の対応表と同じ保護に値します。

自分が制御する活動で監査を試す

セッションとアプリケーションをあらかじめ知っている許可済みの通信を生成し、各記録が実際に何を捉えたかを確認してください。ページを読み込まずに検索し、キャッシュからページを読み込み、プロキシ経由で接続を開いて、どの事象が現れるかを見ます。

証拠が支える事象を報告し、何を覆わないかを述べてください。範囲を明示した控えめな記録はレビューに耐えますが、推測から組み立てた野心的な閲覧履歴は耐えません。