データ保持とコンプライアンス設計

翻訳についての注記: 本ドキュメントは英語原文 20-production-readiness/05-data-retention-and-compliance-engineering.md を日本語に翻訳したものです。コードブロックおよびMermaidダイアグラムは原文のまま維持しています。

TL;DR

削除はモダンなシステムで最も難しい書き込みだ。事実のすべてのコピーに届く必要があり、そこには変更不能になるよう設計されたものまで含まれるから。作成の一文が及ぶのは、自社で所有するコードを経由する数か所だけだ。一方の削除は、一次テーブル、読み取りレプリカ、古いレコードが独自の保持クロックを持つログエントリになっている変更データキャプチャトピック、検索インデックス、キャッシュ、スナップショットコピーを保持するアナリティクスのレイク、フィーチャストア、前四半期に凍結された学習データセット、そこから導出した埋め込みベクトル、顧客へメールを送るベンダー、そして90日分のバックアップに届かねばならない。文書化済み: 消去義務が機構ではなく方針文書で満たされることがこれほど多い理由がここにある。規制当局は分散プロトコルを要求しなかった。権利を要求し、多くの組織はチケットキューとインターンで答えた。

保持を法務の問題ではなくアーキテクチャの関心事にする性質は2つある。第一に、保持は書き込み経路の機能だ。削除が可能かどうかを決める判断は、データモデル・イベントスキーマ・ストレージレイアウトを選ぶ瞬間になされ、後から安価に後付けできない。第二に、保持には上下2つの境界があり、どちらも高コストで失敗する。上限が高すぎれば規制上の露出と発見対象とストレージコストを生み、下限が低すぎれば、デバッグし、チャージバックに反論し、顧客との会話を再現し、監査人に答える能力そのものを破壊する。推論: 現実世界で最も多い失敗は、すべてを過剰に保持することではない。コピーごとに保持が不揃いになることだ。各ストアが、自分のエンジンがたまたま簡単にできる方法を採る。

参照設計: すべてのフィールドが、スキーマの隣に宣言された分類と保持クラスを持つ。時間パーティションかキー単位で鍵を破棄するストレージ構成が一括失効を安価にする。削除は冪等で観測可能なファンアウトであり、伝播サービスレベルと受領台帳を伴う。バックアップは自分のクロックで失効し、リストア後は消去ログを再適用する。データ所在はアカウント作成時に選ばれるルーティング制約として表現する。そして統制はスクリーンショットではなく自動生成の証拠にマップする。本章は、監査とインシデントで実際に見つかる失敗モードと、全体が「約束した」ではなく「動いている」と見えるようにする指標で終わる。

削除が最も難しい書き込みである理由

作成は局所的な野心だが、削除は全社の帳簿作業だ。非対称性は4つの源から来ており、それぞれが自分なりの答えを必要とする。

難しさの源	なぜ削除に抵抗するのか	デザインに強制するもの
物理的なストレージレイアウト	行単位の削除はトームストーンかデッドタプルを残す。領域も、時としては可視性も、意図に遅れる	時間ベースのパーティショニング、コンパクションの理解、失効に優しいレイアウト
変更不能・追記専用のコピー	イベントログ、レイクのスナップショット、監査証跡、バックアップは履歴を変えられないよう作られている	コピークラスごとの個別の消去機構。通常は再処理かキー破壊
導出アーティファクト	集計、埋め込み、インデックス、特徴量、モデル重みはすべて元データの関数	再計算するか、導出が非識別であることを証明する
サードパーティのコピー	ベンダーはコンパイルできない契約の下でデータを保持する	削除API、契約上のSLA、テストの代わりに定期的なアテステーション

推論: それらのコピーはすべて独立した所有者とクロックを持つため、「ユーザ削除」はトランザクションにできない。これはワークフローだ。永続的な意図、コピー単位の冪等な適用、受領記録、隔離付きのリトライ、そして誰も登録しなかったコピーを発見する照合スイープ。これを単一のデータベース呼び出しとしてモデル化するシステムが生む結果は2つだけ。黙ったまま削除されないか、今日たまたま遅かったベンダーへの同期ファンアウトが原因の障害か、だ。

反対側にも正しさの罠がある。攻撃的に削除すると、運用コードが依存する参照整合性を壊す。削除済みユーザを参照する請求書、5年前に操作を実行した行為者が必要な監査証跡、顧客が消えてほしいと頼んだメッセージを引用するサポートチケット。標準的な解決策は仮名化とトームストーンの組み合わせだ。識別可能な属性を不可逆なローカル識別子に置き換え、構造的な事実とそのタイムスタンプは保ち、どのフィールドをいつ消したかを記録する。これは多くの消去義務を満たしつつ、請求・会計・監査証跡を生かす結合キーを守り、物理削除よりたいてい安価だ。

書き込む前にデータを分類する

保持はクエリごとに決められない。だからスキーマ作成時にフィールド単位で宣言しなければならない。実用的なスキームは小さい。4クラスで多くのシステムを覆える。

クラス	例	既定の扱い
一時的	リクエストボディ、デバッグトレース、使い捨てトークン、短命セッション	永続化しない。またはマスキングフィルタと時間単位のTTLで永続化
運用	注文、メッセージ、セッション、デバイス記録	業務オブジェクトの有用期間に紛争対応ウィンドウを足した保持
規制対象	本人属性、決済アーティファクト、保健・通信データ、対象となるIPアドレス	宣言された上限、早めの仮名化、受け手すべてとの削除契約
法令により永続	請求書、税務記録、安全の証拠、契約	法的保留のセマンティクスを持つ下限、可変な一次データと分離した変更不能な監査コピー

実装の選択は2つあり、どちらも分類そのものより重要だ。コードの中で宣言する。列の隣に置く。リンタが読めるアノテーションかスキーマディレクティブであれば、クラスのない新しいフィールドがチェックで落ちる。締切を生き延びる唯一の強制力がこれだ。ウィキに置かれた保持方針は意図の表明にすぎない。失効ジョブと監査クエリを生成する方針が機構だ。クエリ時ではなく取り込み時に分類する。後から計算するものはすべて全スキャンを必要とし、プロジェクトが死ぬのはそこでだからだ。

二次的な利点は発見可能性だ。機械可読な分類があれば、「規制対象フィールドXをどのストアが保持しているか」を四半期分のヒアリングではなく数分で答えられる。この問いは脅威モデリングが尋ねるものとまったく同じで、同じインベントリが両方に答える。

ストレージエンジンごとのTTLの仕組み

すべてのエンジンで削除の作法が違い、その違いは文書の誤りではなくインシデントとして現れる運用上の帰結を持つ。

ストア	削除の機構	運用上の帰結
LSM-tree型のキーバリューストア	トームストーンを書き、コンパクション時に領域を回収	大量失効はトームストーンの雪崩を起こす。コンパクションが追いつくまで読み取りが遅くなるため、一括削除は計画的に実行し、読み増幅を見張る
B-tree型リレーショナルストア	行削除はバキュームまでデッドタプルとして残る	長時間トランザクションが開いたままだとクリーンアップが止まり、保持ジョブがテーブルの肥大化になる。削除はバルクに分割する
時間パーティションテーブルまたはインデックス	パーティションを落とす	追記専用のイベントデータに対する最安で正しい設計。失効はO(1)のメタデータ操作で、バキュームもコンパクションの嵐も起きない
オブジェクトストレージ	ライフサイクルルールによる遷移と失効	非現在バージョンと未完了のマルチパートアップロードもルールに含める。さもなくば請求され続けたまま黙って保持される
検索インデックス	ドキュメントIDで削除、または再構築	クエリ可能なインデックスはコピーである。自分専用の削除経路と、信頼できる情報源に対する整合性チェックが必要
キャッシュ	失効のみ、正統な削除なし	削除の正しさは無効化に依存する。ネガティブキャッシュはTTLのあいだ「削除済み」を復活させうる
ログ構造のイベントトピック	時間またはサイズに基づくセグメント失効	個人データを含む過去イベントはトピックのクロックで失効する。そのクロックは、中に含まれるフィールドの上限より長いことがある
被験者ごとのキーで保存時暗号化	キーを破壊する(鍵破棄による消去)	変更不能なコピーに対する唯一のO(1)削除。保持の問題を鍵管理のインベントリ問題に変える

推論: 必要な保持が安い操作になるようなストレージレイアウトを選べ。大量のイベントデータなら、時間パーティションとライフサイクル失効が、どんなに賢い削除ツールより勝る。本当に変更不能なデータ(監査証跡、レイクのスナップショット)では、被験者単位またはアカウント単位の暗号化キーこそ、コストが履歴と共に増えない唯一の機構だ。ただし正直な注意が2つある。キー破壊は設計上不可逆であり、そして平文が他所に存在しないと証明できたときだけ効く。その証明には前の節のインベントリが必要だ。

伝播の問題

被験者が消去を請求したとき、または保持上限が切れたとき、システムは永続的で冪等、観測可能、かつ照合可能なファンアウトを必要とする。

erasure intent (durable, per subject + scope, append-only ledger)
        |
        v
  deletion orchestrator -----> receipt ledger (copy -> status -> timestamp)
        |
        +--> primary store      : pseudonymize + tombstone          [minutes]
        +--> CDC topic          : publish delete event              [seconds]
        +--> search index       : delete by id, verify count        [minutes]
        +--> cache tier         : invalidate + short TTL            [seconds]
        +--> analytics lake     : rewrite/expire rows or partitions [hours]
        +--> feature store      : recompute or drop keyed features  [hours]
        +--> ML datasets        : mark dataset, schedule retrain    [weeks]
        +--> vendor APIs        : contractual deletion + attestation[days]
        +--> backups            : expire on backup clock; re-apply
                                   the erasure log after any restore [n/a]

reconciliation sweep: sample subjects per copy class -> assert absence

荷の大半は3つの設計規則が支える。適用を冪等にする。リトライ、再配送、リプレイは確実に起きるため、2回目の削除はエラーでも連鎖でもなく何もしないでなければならない。受領記録を残す。「レイクで実際に起きたのか」が議論ではなくクエリになる。コピー・状態・タイムスタンプからなる受領台帳は、監査をレポートに変える。伝播のサービスレベルを設定して計測する。たとえば、コピーの99パーセントを24時間以内に収束させる、ベンダーなど最悪のコピーは30日以内、契約を満たせないコピーはアーキテクチャから外すか、決定記録で許容済みリスクとして文書化する。

バックアップは独立した規則に値する。正しいシステムが黙って保持を破る場所がそこだからだ。バックアップの編集を試みてはならない(完全性の保証を壊すし、たいてい不可能だ)。代わりに、最大の上限より短いクロックでバックアップを失効させ、すべてのリストアを、バックアップ時点以降の消去ログを再適用すべきイベントとして扱う。推論: 消去台帳が永続で完全でなければ、リストアは削除済みデータを黙って復活させる。つまり保持の機構と災害復旧の設計は1つのシステムであり、2つではない。

バックアップ、法的保留、リストアの正しさ

法的保留は逆方向の統制だ。調査・紛争・義務が終わるまで、名指ししたスコープの削除を一時停止する。本物の機構が必要だ。Jiraチケット式の保留は忘れられ、失効を全部止める保留は全アセットを無期限保持に変えるから。

最小限の実用設計は次の通り。スコープ(被験者、テナント、日付範囲)、理由クラス、請求者のロール、開始日、必須のレビュー間隔を名前として書く保留台帳。対象内の何かを削除する前に台帳を参照する失効エンジン。保留が有効なあいだに取られる変更不能なスナップショット(通常の書き込みが保留中の状態を変えられないようにする)。そして同じ冪等なファンアウトで追い越し削除を実行する解除パス。優先順位はレビュー可能な場所に書く。保留が上限に勝ち、上限が利便性に勝ち、手動のオーバーライドはすべて所有者付きの監査イベントを出す。

明示的に設計すべき失敗クラスが2つある。データがすでに失効した後に当てられた保留は執行不能で、これは高リスク領域で「失効対象」と「物理削除」のあいだに短い猶予を置く論拠になる。そして決して解除されない保留は、誰も法的に削除できないデータの集団を育てる。この滞留の年齢を指標として公開すれば、発見前の問題になる前に見える化する。

データ所在、主権、ルーティング

データ所在は保持を配置の問題に変える。あるデータセットは名指しされた法域にのみ保存・処理が許され、そのメタデータも対象に含まれることが多い。推論: 領域を、アカウント作成時に決まるテナントの変更不能な性質として扱え。既存のグローバルデータセットに所在要件を後付けするのは、トラフィックをさばき而行を移す作業、つまり規制上の締切が付いた移行プロジェクトになる。

耐える仕組みは次の通り。

• 最初から法域でパーティションする。領域はルーティングキーの一部になる。制御プレーンの参照がグローバルなままでいいのは、グローバルに置けるデータだけだ。テナントID、プラン、領域タグ。
• 何が持ち出しとみなされるかを列挙する。レプリケーション、リージョンをまたぐ読み取りレプリカ、ログ転送、ユーザ識別子を含むテレメトリ、サポートツールのアクセス、ベンダーのサブプロセッサは、いずれも多くの解釈で持ち出しに該当する。それぞれ領域内インスタンスか、文書化された適法な移転機構が必要だ。
• セカンダリインデックスとキャッシュを見る。領域内のデータから作ったグローバル検索インデックスは、スキーマレビューでは捕まらない所在違反だ。インデックス層とキャッシュ層も自分専用の配置制約とテストを持つ。
• 容量への影響を見込む。領域ごとのプールは領域ごとの余力を意味し、ある地域では専用インスタンスタイプが必要で、グローバルな余裕を前提にできないフェイルオーバ計画になる。セル単位の分離はより小さい被害範囲で同じ性質を与える。
• 配置をポリシーとしてコード化する。規制対象データを領域外バケットへ書き込むデプロイやスキーマ移行は、18か月後の監査ではなくチェックで失敗すべきだ。

テスト可能な性質としてのコンプライアンス

監査可能な統制は工学の成果物だ。統制とはシステムの挙動に関する主張であり、挙動に関する主張は自動的に検証できる。対応付けは短く、その見返りは永続的だ。

統制の意図	手動の版	自動の版
アクセス最小化	誰が何を持つのかの四半期ごとのスプレッドシートレビュー	アイデンティティブローダのグループメンバシップとリソースポリシーを差分し、指摘はデプロイを止める
通信中と保存時の暗号化	コンソール設定のスクリーンショット	Terraformまたはコントローラレベルのアサーション、逸脱で失敗するドリフトスキャン
監査ログの完全性	信頼	すべての変更ハンドラが行為者・操作・対象を伴う監査イベントを出すと断言するテスト
ログの変更不能性	方針文書	書き込み一回限りのストレージ設定と、ハッシュチェーンの定期検証
保持上限	文書化されたスケジュール	スキーマアノテーションから生成した失効ジョブと、クラス上限を超える記録がないことを断言するスイープ
削除の実効性	チケットが閉じたという事実	被験者をコピー単位でサンプリングし不在を断言する照合スイープ
サブプロセッサのインベントリ	セキュリティレビューのスライド	エグレス設定から生成した外部連携のレジストリと、許可リストに対するテスト

この種の会話を支配する標準は2つあり、こう表現すればどちらも扱いやすくなる。SOC 2タイプIIは期間にわたる証拠なので、四半期ごとの慌てふためきより継続的な生成が勝る。ISO/IEC 27001の附属書Aの統制は、上の自動チェックへほぼ一対一でマップされる。その下の法的義務にも固有の工学的な形がある。消去とアクセス請求はサービスレベルとテストを備えたAPIになり(データ主体アクセス請求はすべてのコピークラスにまたがるクエリであり、まさにインベントリの問題)、保存制限はクラスごとの上限になり、処理者の義務は契約条件と検証済み削除APIになり、移転制限はルーティング制約になる。

推論: コンプライアンスをテストスイートとして扱うチームは、書類仕事として扱うチームより良いエンジニアリングを持つ。統制が本物だからだ。逆のアプローチの失敗モードは監査に落ちることではない。システムが別のことを行っているのに監査を通ってしまうことだ。

導出データとモデルの保持

導出アーティファクトは、保持プログラムが黙って失敗する場所だ。ライフサイクルの所有者が誰にも属さないから。表面を管理可能に保つ規則は3つ。

• 集計: 現在のカードラリティで個人へ遡れなくなったときに保持する。たいていは最小セルサイズと希少カテゴリの抑制を意味する。匿名性が将来の結合でも保たれると仮定せず、閾値を文書化せよ。
• フィーチャストアとインデックス: 元データから導出し、キー付きの削除パスを持って消去が伝播するようにする。そして鮮度の契約を記録し、古い特徴量が生きた特徴量と取り違えられないようにする。
• データセット、埋め込み、モデル重み: データセットは明示的なスナップショット日と分類付きで凍結し、削除は再学習の入力として扱う。凍結したスナップショットを編集できるとふりはしない。学習済み重みの中の厳密な忘却はまだ高価で不正確だ。正直な工学的な答えは、有界の学習ウィンドウ、同意と削除シグナルを次の学習実行まで届けること、そしてその間のリスク許容を文書化することだ。

ログとテレメトリの保持は独立した注意に値する。多くの環境で最大の体量だからだ。後からフィルタするのではなく送信時にマスキングし、識別子のカードラリティに上限を置き、短い高解像度ウィンドウと長い低解像度ウィンドウを分離する。ここの保持判断は同時にコストの判断でもある。コンプライアンスの上限と予算の上限が同じ方向を向く、めずらしい例だ。

保持設計の失敗モード

失敗モード	症状	対処
バックアップから復活するソフトデリート	リストアやレプリカ昇格後に削除済みアカウントが戻る	あらゆるリストア・昇格で再適用される永続的な消去ログ
コピーごとのTTLの不一致	レイクが一次データより何年も前に捨てた行を保持し続ける	保持クラスを一度だけ宣言し、そこからコピーごとの失効ジョブを生成
ログとトレースに入る規制対象フィールド	識別子を含むデバッグペイロードが30日保持のテレメトリストアに到達	送信時のマスキングと、ログスキーマ・トレース属性に対するCIチェック
削除増幅の嵐	一括失効がクラスタ全体の読み取りを劣化させる	削除を分割し、オフピークに実行し、トームストーンとバキュームの指標を見る
無制限な導出データの保持	2021年の学習スナップショットが消去済み被験者を含んだまま残る	スナップショットの分類と、閾値に基づく再学習方針
上限が下限より下	チャージバックや安全調査で使える証拠が存在しない	運用データから分離した法令永続クラスと保留セマンティクス
鍵インベントリのない鍵破棄による消去	キーは破壊されたが平文が他所で読める。または復元不能なデータを失う	クラスごとのキー階層を文書化し、頼る前に鍵破棄を実地で検証する
削除APIを持たないベンダー	チケットが閉じたので消去請求も終わったことになる	契約に削除SLAを入れるか、そのデータ経路からベンダーを外す
タイムゾーンと境界のバグ	取り込み時刻とイベント時刻の差異で記録が1日早く、または遅く失効する	クラスごとに一つのクロック規約を決め、境界を明示的にテストする

主要な要点

• 保持は書き込み経路の機能だ。スキーマ・ストレージレイアウト・イベントスキーマが削除の安さを決める、どれも移行なしに遡って変更できない。
• 失効を簡単操作にするレイアウト(時間パーティション、ライフサイクルルール)を選び、鍵破棄による消去はキー適用範囲を証明できる本当に変更不能なコピーだけに残せ。
• 削除は受領記録・伝播サービスレベル・照合スイープを備えた冪等な分散ワークフローだ。それ未満では黙ったまま削除されない。
• バックアップを編集してはならない。自分のクロックで失効させ、あらゆるリストアとレプリカ昇格の後に消去ログを再適用する。
• 参照整合性、会計、監査証跡が結合キーを必要とする場所では、物理削除ではなく仮名化とトームストーンを使う。
• 法的保留には台帳・優先順位・変更不能なスナップショット・必須のレビュー間隔・解除パスが必要だ。さもなくばうっかり無期限保持になる。
• データ所在はアカウント作成時に決まるルーティング制約で、セカンダリインデックス、キャッシュ、テレメトリ、サポートツールはすべて自分専用のテストを要する持ち出しだ。
• すべての統制を自動チェックへマップする。継続的な証拠はスクリーンショットに勝ち、同じチェックがシステムを実際に安全にする。監査を通すだけではない。
• 導出データ(集計、特徴量、スナップショット、埋め込み、重み)は明示的な規則を必要とする。厳密な忘却は非現実的で、正直な設計とは有界の学習ウィンドウと文書化されたリスク許容だからだ。
• 上下両方の境界が重要だ。高すぎる上限は露出とコストを生み、低すぎる下限はデバッグし防御し法令永続の義務を守る能力を奪う。

参考文献

• Regulation (EU) 2016/679 (GDPR)、第5条1項(e)の保存制限、第17条の消去される権利、第28条の処理者の義務、第30条の処理の記録、第44条以下の移転。多くの保持・所在設計の法的な前提
• カリフォルニア州消費者プライバシー法(CPRAによる改正後)。削除の権利と収集時の通知義務を含む。同じ工学的表面に対して別の機構を持つ第二の法域
• PCI Security Standards Council. PCI DSS v4.x、保存する口座データの保護と最小化に関する要求3。不要になったデータの削除を命じる標準として最も明快な例
• ISO/IEC 27001附属書Aの統制と、論理・物理アクセスに関するSOC 2信頼サービス基準のCC6カテゴリ。たいていの監査依頼が実際にはこの管理番号で書かれる2つの枠組み
• NIST SP 800-88 Rev. 1, Guidelines for Media Sanitization, NIST, 2014 — clear、purge、destroyの最も明快な公開分類と、その違いが設計判断である理由
• van Oorschot, P. C. and Wiener, M. K., "On Streaming Encryption and Key Management," Selected Areas in Cryptography, 1998。Rosenzweig, P., "Skipjack, Key Escrow, and Split-Key Cryptography," IEEE Annals of the History of Computing, 1997 — データが見つからないならキーを破壊するという鍵破棄による消去の学術的基礎
• HIPAAセキュリティ規則、45 CFR 164.316(b)(2)(i)。6年間の文書保存を求める項目。注意して読む価値がある。法令永続の義務は患者データそのものではなく、自社統制に関する文書にかかる