ユーザーデータの保存と削除
1)保持および廃棄ポリシーの理由
目的は、必要なデータだけを正確に保存し、処理目標の終わりに安全に削除することです。これにより、法的リスク、攻撃面、インフラストラクチャコストが削減され、監査(ライセンス、PSPパートナー、規制当局)が簡素化されます。
主な原則:- 目的/基礎(契約、法律、正当な利益、同意)。
- 最小化と分離(PII ↔仮名↔匿名)。
- 予測可能なタイミングと実証可能な除去手順。
- 継続的な監視(ログ、レポート、メトリクス)。
2)データゾーンおよび建築サポート
ゾーンA-PII/センシティブ: KYC、支払トークン、生体認証(許容される場合)。At-rest暗号化、厳格なRBAC/ABAC、 JITアクセス。
ゾーンB-仮名化:アナリティクス/MLの安定したトークン;直接識別解除の禁止。
ゾーンC-匿名集計:レポート/リサーチ;長い保存性は許可されます。
- データカタログ/RoPA(操作レジスタ)、保持サービス(ルール)、削除オーケストレーター(エンドツーエンド削除)、WORMアーカイブ(監査/インシデント)。
3)保持行列: 構成する方法
ステップ:1.処理ターゲット↔法的根拠↔データカテゴリ↔期限を一致させる。
2.起点のトリガー(イベント:アカウントの作成、最後のログイン、アカウントの閉鎖、契約の終了、最終取引)を説明します。
3.最後にメソッドを修正:削除、匿名化、ブロック(「フリーズ」が必要な場合)。
4.所有者と例外(AML/税金/紛争/詐欺)を指定します。
例(wikiの場合):4)保持ポリシー(スケルトン)
1.範囲、役割(データ所有者、DPO、セキュリティ、操作)。
2.定義(PDカテゴリ、ゾーン、アーカイブ、バックアップ、匿名化/匿名化)。
3.データを目標/ベースと期限にリンクする(保存行列を参照)。
4.例外(法的保持、調査、規制要求)を管理します。
5.アクセス制御、暗号化、監査のアップロード。
6.改訂手順(四半期ごと/目標/プロバイダが変更された場合)。
5)パイプラインの取り外しおよび匿名化
ステージ:- Mark-for-Deletion:レコードと依存関係をマーキングする。「ホールド」をチェックします。
- Grace Period:バッファ(例:7-30日)エラーでキャンセルします。
- Soft Delete:本番サービスからの論理的な非表示;郵送/処置を停止して下さい。
- Hard Delete/Anonymize:プライマリストレージの物理的なクリーンアップ/不可逆的な匿名化。
- カスケード&ファンアウト:デリバティブ(キャッシュ、検索インデックス、phichestore、 DWH、 MLレイヤー)にカスケードします。
- バックアップ:バックアップポリシーによる遅延クリーニング(以下を参照)。
- 証拠:削除行為(ID、分類器、時間、システム)、WORMでのログイン。
- 系統別にトレースされた件名キーで削除します。
- Idempotentタスク、リトレイ、コマンド重複除外。
- SLA:ほとんどの削除≤要求から30日です(該当する場合)。
- 「取り外し不可」フィールドを制御:トークン/マスクに置き換えます。
6)バックアップとレプリカ: コピーをどうするか
不変バックアップ(ランサムウェア抵抗)は別のポリシーで保存されます。直接編集はできません。
バックアップの期限が切れた後にサブジェクトがバックアップから削除され、戦闘環境へのリカバリが禁止されます。
ドキュメント:バックアップを保存するためのウィンドウ(例えば、30/60/90日)、回復スクリプトと回復中の「消毒」プロセス(マークされたレコードを再削除するためのポストスクリプト)。
7)例外と「法的保持」
すぐに削除できない場合があります(例:AML、税務監査、訴訟)。プロシージャ:- 理由、期間、所有者の表示で法的保持を置きます。
- 指定された目的以外のデータへのアクセスをブロックします。
- 定期的にホールドを確認し、ベースが落ちたらすぐに削除します。
8)ドキュメントとアーティファクト
保持行列(バージョン管理済み)。
削除手順(SOP)-ステップ、役割、SLA、エスカレーション。
削除証拠ログ(WORM): who/what/when/result。
バックアップポリシー:タイムライン、ストレージクラス、リカバリテスト。
Data Lineage Map:プライマリテーブルから派生レイヤーまで。
例外/法的保持登録。
9)指標と品質管理
保持スケジュールに基づいて削除されたレコードのAdherence%。
削除SLA: request/trigger以降の平均/95パーセンタイル。
「カスケード完了率」(Cascade Completion Rate)-削除が完了したシステムの割合。
[バックアップ]ウィンドウのコンプライアンス:日付ごとに削除されたバックアップの割合。
アクセス/エクスポート違反:不正な読み取り/アップロード。
DSR SLA(該当する場合):応答≤期限。
Incident Rateは、削除/ミスアライメントの失敗数です。
10)チェックリスト(操作)
機能を起動する前に
- ターゲット/治療ベースとストレージエリア(A/B/C)が定義されています。
- 保持行列(term、 trigger、 method)に行を追加しました。
- 削除オーケストレータ(キー、カスケード、idempotency)が設定されます。
- 監査可能(WORMログ)、RoPAを更新しました。
デイリー/ウィークリー
- タスクスケジューラの削除がスムーズに実行されました。
- 新しい法的保持登録、期限切れ-撤回。
- バックアップレポートをチェック(作成/期限切れ)。
四半期ごと
- 保持行列と例外のレビュー。
- バックアップからのリカバリをテストする+スクリプトの「サニタイズ」。
- 指標の調整(SLA、カスケード、違反)、改善計画。
11)頻繁な間違いとそれらを回避する方法
貯蔵の→ターゲットへの堅い結合を予約して下さい;カテゴリ別の自動TTL。
cascade→caches/indexes/fichestoreにデータが残ります。ユニバーサルオーケストレーターを実装します。
PDと開発/ステージ→合成セット/マスキングを使用します。ダンプの自動切断。
ポリシー外のバックアップ→ウィンドウを定義し、不正な復元、消毒テストを禁止します。
証拠の欠如→WORMログ、除去行為、定期的な報告。
混合された地面→別のマーケティング/保証/契約;「念のために」締め切りを遅らせないでください。
12)カスタム削除の例(エンドツーエンドのシナリオ)
1.ユーザーはアカウントを閉鎖するか、削除のためにDSRを送信します。
2.例外をチェック(AML、紛争)→もしあれば-限られた目標を持つリーガルホールド。
3.ホールドがない場合:Mark-for-Deletion→Grace 14日→Soft Delete。
4.ハードトランザクションレイヤーで削除/匿名化し、キャッシュ、インデックス、DWH、 MLフィーチャーストアにカスケードします。
5.証拠ログにログインし、プロフィール/メールのステータスを更新します。
6.ストレージ・ウィンドウが終了した後のバックアップからのクリーニング。
13)役割と責任(RACI)
データ所有者/ドメインリード-期限と目標;保持行列を更新します。
DPO/プライバシー-コンプライアンス、例外に関するアドバイス。
セキュリティ/CISO-暗号化、アクセス、監査、バックアップ/リカバリ。
データエンジニアリング-削除オーケストレータ、系譜、-------------------------------------------
サポート/オペレーション-DSR通信、ステータス、SLA。
法的-法的保有物、規制当局/裁判所との相互作用。
14)あなたのWikiのテンプレート
リテンション・マトリックス。xlsx/MD (category→purpose→basis→term→method)。
Deletion-SOP。md(エスカレーションによるステップバイステップの規制)。
Backups-Policy:md (Windows、ストレージクラス、リカバリテスト計画)。
法的保持-登録。md(テスト/除去フォーム)。
Data-Lineage-Diagram(テーブルからデリバティブへのリンク)。
毎月のプライバシー-Ops-Report。md(メトリクス、インシデント、改善)。
15)実装ロードマップ(6ステップ)
1.在庫:データ/フローのマップ、目標と理由の比較。
2.保持マトリックス:ドラフト締め切り+所有者;法的/DPOとの整列。
3.削除オーケストレータ:キー、カスケード、バックアップの消毒、WORMログ。
4.ポリシー/プロシージャ:保持ポリシー、削除SOP、バックアップポリシー、法的保持。
5.自動化と監視:スケジュール、アラート、ダッシュボードメトリック。
6.監査とトレーニング:四半期ごとの改訂、証明書テンプレート、回復トレーニング。
[結果]
効果的なデータ保持と廃棄は、管理可能なサイクルです:目的→期間→制御→安全な処分/匿名化→証明。ゾーンの分離、保持マトリックス、カスケード削除(バックアップを含む)、理解可能な例外と指標は、プライバシーとコンプライアンスをリスクから競争上の優位性に変えます。