eng-docs

データ保持ポリシー

11 min read

データ保持ポリシー

GDPR 第5条・第17条の条文と、NIST SP 800-88 Rev.1(媒体のサニタイズ)を 取得して読み、理解した内容を自分の言葉で書いたもの。本文の引用はしていない。

どのデータを、どの目的で、いつまで持つかを決めて、期限が来たら消すこと。

データの完全性とリストアが失わないための話なら、 こちらは持ち続けないための話。この2つは逆を向いているので、後で調停する。

保持期間は目的から導く

GDPR の第5条が置いている原則のうち、保持に効くのは3つ。

原則中身
目的の限定(b)特定され、明示された、正当な目的のために集める。目的と相容れない形でさらに処理しない
データの最小化(c)目的に照らして、適切で、関連があり、必要な範囲に限る
保存の制限(e)処理の目的に必要な期間を超えて、データ主体を識別できる形で保持しない

「保持期間を何日にするか」を単独では決められない構造になっている。 目的が先にあり、期間はそこから出てくる。

だから実務上いちばん効くのは、「念のため取っておく」は目的ではないという一点。 目的が言えないデータは、期間も決められないので、そもそも持てない。

例外は、公共の利益のためのアーカイブ、科学的・歴史的研究、統計の目的に 限って処理する場合。この場合はより長く保持できる。

第5条2項が説明責任を課している。 管理者は原則の順守について責任を負い、 それを実証できなければならない。 つまり方針を頭の中に持っているだけでは足りず、書いて残す必要がある。

消す義務

第17条(消去の権利)。不当に遅れることなく消さなければならない場合が挙がっている。

(a) 集めた目的、または処理された目的に照らして、もう必要ない
(b) 同意が撤回され、他に法的根拠がない
(c) 第21条に基づく異議申立てがあり、優越する正当な根拠がない
(d) 違法に処理された
(e) 法的義務の順守のために消去が求められる
(f) 子どもへの情報社会サービスに関して集められた

(a) が要点。 利用者が求めなくても、目的に照らして不要になった時点で消す義務がある。 「削除依頼が来たら消す」だけでは足りない。

公開してしまったデータについては、 他の管理者に対して、リンクや複製の消去を求められていることを伝えるための、 技術的措置を含む合理的な措置を取る。

全部消せるわけでもない

第17条3項の例外があり、次の場合には消去義務が及ばない。

表現の自由
法的義務の順守、公共の任務の遂行
公衆衛生上の利益
アーカイブ・研究・統計の目的
法的請求の主張、行使、防御

最後の「法的請求の主張・行使・防御」が実務では効く。 係争中の取引記録を、削除依頼に応じて消してよいわけではない。

つまり方針は「何日で消す」の一行では書けず、 データの種類ごとに、目的・期間・消せない条件を並べたものになる。

どう消すか

論理削除は「消した」ことにならない。 NIST の分類が3段階。

方法何をするか防げる相手使う場面
ClearOS の標準的な機能で上書きする通常の手段での復元機微でないデータ。媒体を組織内で再利用する
Purge復元が実験室的手法でも現実的でなくなるように処理するフォレンジック解析機微なデータ。媒体を組織内で再利用する
Destroy媒体を物理的に破壊するすべて機密性が非常に高い。媒体が組織の管理を離れる

判断の軸は2つだけ。 データの機密性と、媒体が組織の管理下に留まるかどうか。 外に出るなら破壊、が基本線になる。

暗号消去とその限界

暗号消去(CE) は、データを上書きする代わりに鍵を破棄して読めなくする方法。

大量のデータを一瞬で処理できるので魅力的だが、限界が明確にある。

ライフサイクル全体を通じて暗号化されていた場合にのみ有効。

平文で保存された時期があったり、暗号化の実装が不完全だったりすると、効かない。

これは暗号と鍵の管理の 鍵とデータの分離が、削除の側でも効いてくるということ。 鍵を確実に消せる場所に置いていなければ、暗号消去は成立しない。

記録を残す

サニタイズ証明書を残す。監査の証跡になる。

適用した方法
日時
使用した装置
残留データの検証結果

第5条2項の説明責任は、消したことについても求められる。

「失わない」と「持ち続けない」を調停する

データの完全性とリストアとここは、素直に読むと矛盾する。

完全性の側   ソフト削除で 15/30/45/60日 は保持する
             バックアップは 30〜90日
             失っても戻せる状態を保つ

保持の側     目的に必要な期間を超えて保持しない
             不要になった時点で消す義務がある

矛盾ではなく、目的が違うだけと整理できる。

ソフト削除の保持期間には 「誤った削除から利用者を守る」という目的があるので、 その期間の保持は目的に照らして必要な保持になる。 期間の根拠が「大半の問題は60日以内に検知される」という実績である点も、 説明責任を果たす形になっている。

説明できない保持だけが問題で、期間そのものが問題なのではない。

だから方針に書くべきは日数ではなく、日数の根拠。

書けていないこと

バックアップの中のデータをどう消すかは、ここでは扱っていない。

消去の義務は「不当に遅れることなく」だが、 過去のバックアップは通常、書き換えられないものとして運用される。 両立のさせ方(復元時に再度消すのか、バックアップ自体を期限で失効させるのか)は 条文からは決まらず、取得した資料の範囲外だった。

このリポジトリの他の場所との関係

ここでの話対応する場所
持たないデータは漏れない暗号と鍵の管理 — 機微なデータの保存自体を最小にする
鍵を消せる場所に置く秘密情報の管理
個人情報を API の境界でどう扱うかDB と API の境界
誰がどのデータに触れるか認証と認可 — 最小権限
消したことの記録可観測性 — ログの保持期間もこの方針の対象

ログ自体もこの方針の対象になる点は見落としやすい。 セッション管理で 「ログに生のセッションIDを書かない」としたのは、 ログの保持期間が資格情報の有効期間を超えてしまう問題への対処でもある。

関連

バックリンク