ログをどれだけ残すかは、すでに下したプライバシーの判断である

小さなチームにログの保存期間を尋ねると、たいてい 2 つの答えのどちらかが返ります。「プラットフォームの既定」か「小さいのでずっと残している」です。どちらも判断であり、後者は多くのプロジェクトが持つ最大の「宣言されていない個人データ収集」です。

1. 1 行に実際に入っているもの

標準的なアクセスログには、クライアント IP、時刻、メソッドとパス、ステータス、バイト数、リファラ、User-Agent が入ります。訪問者の少ないサイトでは、これだけで個人を特定できる場合があります。IP 1 つ、時刻 1 つ、パス 1 つは、名前より識別力が高いことがあるのです。

2. 保持する正当な理由は 3 つ

• 障害調査。14:32 に何かが壊れ、原因のリクエストを見たい。必要なのは年ではなく日単位で、有用な部分は通常ステータス、パス、タイミングであり、IP 全体ではありません。
• 濫用と容量。急増、スクレイピング、クレデンシャルスタッフィング。多くの場合に必要なのは週単位です。パターンは時間をかけて初めて現れます。
• 法的義務。特定の目的で接続データの短期保存を求める法域があります。固定の下限を正当化できる唯一の理由で、条件が付きます。

どれも IP 全体を永久に必要とはしません。切り詰めたアドレスや鍵付きハッシュで目的を満たせるなら、生の値を残すのは選択であって必然ではありません。

3. 削除時ではなく書き込み時に最小化する

ログパイプラインで最も安上がりなプライバシー改善は取り込み時です。IPv4 の最後のオクテット、IPv6 の最後の 80 ビットを落とします。都市レベルの調査は残り、個人の識別性はほぼ消えます。セッションを関連付けたいなら、月次でローテーションするソルトでハッシュ化します。同日の関連付けは機能し、月をまたぐ関連付けは切れ、ソルトはログ基盤に入りません。

不要なクエリ文字列は捨てます。典型的なアクセスログの個人データの半分はクエリにあります。URL 内のトークン、リセットリンク内のメールアドレス、検索語です。完全な URL ではなくパステンプレートを記録すれば、ルーティングの調査能力を失わずに大半を除去できます。

4. 削除は見た目より難しい

「30 日」と書きながらバックアップを 1 年残す方針は、方針が存在しないのと同じです。バージョニング付きのオブジェクトストレージに落ちているなら、削除はバージョンも消すことを意味します。ダッシュボード用に表計算へ書き出しているなら、そのコピーには独自の保存期間があります。派生した集計は通常そのまま保持して構いません。時間・ルート別の件数は個人データではなく、生の行を残さず集計を作る理由になります。

5. 正直に約束できること

1 行が消えるのを自分の目で見ていない限り、「ログは 30 日保持」と書かないでください。ライフサイクルルールで強制できる期間を選び、古い行を 1 度問い合わせて消えていることを確認し、その数値をポリシーに書きます。検証済みの 14 日は、願望の 90 日より良い約束です。

同じ論理は第三者にも当てはまります。CDN もエラートラッカーも、それぞれの周期でコピーを保持します。どの事業者が何をいつまで見るのかを書き出してください。それが利用者が実際に受け取る保存期間です。

ipbox.one は訪問者単位のアーカイブを持ちません。保存されるのは約 90 秒で失効するレート制限カウンターだけで、ポリシーにもそう書いています。検証できるからです。