保持ポリシーは、ポリシーの衣装を着たエンジニアリング問題だ
「7年間保持する」「90日で削除する」— 保持ポリシーの二つの約束はどちらも証明可能であるべきエンジニアリング上の主張であり、大半のシステムはどちらも証明できない。
すべての保持ポリシーは、ちょうど二つの約束をする。特定の記録を十分長く保管する。特定の記録を長く持ちすぎない。文書はコンプライアンスのフォルダに住んでいるが、どちらの約束もシステムの挙動についての主張だ — そしてシステムの挙動についての主張は、エンジニアリングされ検証可能であるか、さもなければ飾りである。
大半は飾りだ。誰かが嘘をついているからではない。ポリシーが散文として書かれ、システムが強制する性質へと翻訳されなかったからだ。実際の仕事はその翻訳に住んでいて、PDFの見た目よりずっと難しい。
「7年間保持する」は不在についての主張だ
一つ目の約束を守るには、記録が今日存在するだけでは足りない。「早期に消えたものが何もない」ことを示せなければならない。これは削除の不在についての主張であり、不在こそ、普通のストレージが実演できないものの筆頭だ。
IDシーケンスに欠番のないテーブルは、ほとんど何も証明しない。シーケンスは再利用され、マイグレーションは番号を振り直し、削除された行は自分のIDを静かに道連れにする。バックアップが証明するのはバックアップ時点に存在したものであって、バックアップの合間に起きたことではない。その間にも、ありふれた脅威は仕事をする。WHERE句が広すぎた掃除ジョブ、シャードを一つ落としたストレージ移行、ポリシーが生まれる前に設定されたコンパクション。どれも攻撃ではない。どれも、ポリシーが「起きてはならない」と言う削除が、誰も数えていない形で起きたものだ。
削除を可視化する仕組みがアーキテクチャのどこにもないなら — 壊れる連鎖構造、合わなくなる集計、現れない受領証 — 「すべて保管しています」は希望の表明である。そのデータベースに対して今まで走ったすべてのジョブを代弁して行う、希望の表明だ。
「90日で削除する」はコピーについての主張だ
二つ目の約束は逆方向に失敗する。行を消すのは簡単だ。行が問題だったことは一度もない。
問題は、データが生きている間に行った先の全部だ。レプリカ、分析用ウェアハウス、検索インデックス、リクエストボディを丸ごと写したデバッグログ、保持期間より長生きするバックアップのローテーション、データサイエンティストが善意で作ったエクスポート。プライマリコピーを消して五つの影を残す削除はコンプライアンスではない — 片付けだ。
この約束を守るには、コピーの居場所を知っている必要があり、それにはコピーが作られた時点で記録されていた必要がある。伝播を追跡してこなかったシステムにその知識を後付けするのは考古学であり、締め切りに追われた考古学は、プライバシー・インシデントが自分ではなく規制当局に発見される経路である。
監査人が覚えた質問
監査の実務は、単純なアップグレードに収束しつつある。「ポリシーを見せてください」から「この記録の履歴を、ポリシーと突き合わせて見せてください」へ。記録のクラスを一つ選ぶ。時計はいつ始まり、どの規則が適用され、いつ廃棄され、廃棄がコピーにまで届いたことを何が証言するのか?
この質問のために設計されたシステムは、保持をcronジョブの挙動ではなく、記録の性質として扱う。記録クラスごとに時計を持つ。廃棄は証拠を生む — 日付と署名を持つ行為であって、沈黙の不在ではない。その間の連続性は検証可能で、早期削除は不可視の出来事ではなく検出可能なイベントになる。どれも特殊な技術ではない。ただ、どれもデータが到着する前に決めておく必要があり、それこそが滅多に存在しない理由だ。
10秒テスト
ポリシーが「先四半期に削除済み」と言う記録を一つ、「2033年まで生存必須」と言う記録を一つ選ぶ。前者について、いつ、どの規則の下で削除され、コピーも消えたことを示せるか? 後者について、書き込み以降一度も触れられていないことを示せるか?
どちらかの答えに会議が必要なら、ポリシーとシステムはまだ出会っていない。ポリシーは意図を述べる。約束を守れるのは、システムだけだ。
Axowlは記録を書き込み時に封印し、両方の約束を証明可能にする — 検証できる連続性と、受領証を残す廃棄。仕組みを見る