💣

そのデータ、いつになったら削除しますか

2021/05/28に公開2

きっかけ

Omiaiで保管されていた運転免許等の本人確認画像が流出した件で触発されました。
本人確認のためだけに使うなら、確認後は不要なはずなので即破棄という運用でも問題ないはず。
ただ実際には内部事情の都合で、スマートに破棄できないのが実情だったのではないでしょうか。
https://www.net-marketing.co.jp/news/5873/

証跡のために残されるデータ

こういった実質もう使わなくなったけど、後でユーザーから依頼だったり事件があったときのために証拠を提出したいから残してほしいという要件はままあります。

特に昨今はクラウドネイティブなインフラが増えてきたのもあって、保存できるデータ量にほぼ制限がなくなってきました。
それに伴って画像ファイルのような少々重いデータでも、証跡としてずっと残していてほしいというクライアントは少なくないです。

個人的な印象ではログのローテーションの間隔もかなり長くとりたがる傾向にありますね。

またデータベースのレコード削除も、論理削除で対応する案件が多いです。
理由としては一律して なにかあったときにすぐ戻したいから。

とにかく今のITサービスの運営者は何でも残したがる病なんですよね。

なぜ何でも残したがる病になるのか?

  • 業務運用上で問い合わせがあったときに対応するため
  • 削除より保存を優先しがち
  • 厳重なデータほど保管する傾向にある、保身のため

このくらいになりますね。
偏見を承知で申しますと、意思決定権のある人間が保身的な決定をするあまり、保管という方を優先してしまういう社内事情があるように感じます。
セキュリティを担当する人間にデータ取り扱いの決定権がないことが、どうしても保身的な方向に偏る結果になってしまうんですよね。

ただ情報漏えいしたらセキュリティ担当の責任にもなりますからね。
なんとかして説得したいところです。そこで対話材料を考えてみました。

個人情報保護法から見るデータの取扱い

まずはじめに、正当な手段で入手した個人情報はたとえ本人から削除要請があったとしても削除の義務はありません。
しかし一方で消去の努力義務という項があり、

事業者は、仮名加工情報である個人データ及び削除情報等を利用する必要がなくなったときは、当該個人データ及び削除情報等を遅滞なく消去するよう努めなければなりません

ということで、必要がなくなった場合は削除することを推奨しています。
なので理由がなければ削除した方が良い、という理屈になるわけですね。

ところが実際にサービス運用を見据えるとユーザー退会によってユーザーが(見かけ上)削除されても、実際には論理削除しか行っておらずDBにはきっちり中身が残っているということが少なくありません。

でもこれって変な話なんです。
ユーザーが退会を行った=個人情報の削除を要請したのに、運営者はそれに従わずに残したとも言えるわけですから。
もちろん義務ではないですし、運用上残さざるを得ないこともありますからそれ自体は問題ありません。

ただサービス側はリスクを承知であえてデータを残しているのだということを理解した上で行うべきですね。そこまで考えてユーザー情報を残す、という決定にしたのなら良いのではと。

データは残すのが是なのか?

下記記事は業務上使わなくなった個人情報は捨てるべき?というアンケートに対しての調査結果になります。
https://xtech.nikkei.com/it/free/ITPro/OPINION/20040612/145747/

結果としては 一定期間保持後、削除すべきが1位です。
この一定期間というのには大きな溝があるようで、1〜2年だったり、民法を反映して5~10年、などなど様々意見があるようです。
ただ現実的にサービスを運営したとき、そもそも10年も持つサービス自体が非常に稀ですし、定期的にローテーションで削除かローカルな環境に退避させたほうがいざというときの被害を抑えられます。

民法などを考慮するのはおよそ現実的ではないんですよね。
あくまで保存しているのはWebサービスなので、お役所の書類とは違ってどうしてもハッキング・不正アクセスの可能性に常に晒されているわけです。
それを考えればとりあえず保存、というのは推奨できないですね。
むしろ積極的に削除を優先でいつまで残すか、という尺で見るほうが望ましいです。

最初に挙げたOmiaiの件も利用用途は本人確認のためだけなわけですから、それが完了しだい速やかに削除しても問題はないわけです。 そうしていたなら100万人規模の流出には繋がらなかったでしょう。きっとこればかりは上の意向というやつが原因な気がしますが...。

以上踏まえて、どう落とし所を作るか

扱うデータの特性に応じて、どのくらい残す必要があるのかきっちり定義してください。
例えばToCのSNSサービスなんかでユーザー情報を扱う場合、

とりあえず2年ぐらい保存してほしい

誤って退会したユーザーから問い合わせがあるかもしれないので論理削除で

と言われて1年に1回も参照しないデータのために論理削除でデータを残すことになりかねません。
どうしても復元したいならDBからバックアップすれば良いだけです。
もちろんバックアップのファイルは普通のDBとは異なるセキュリティの環境に置きますが。
わざわざ稼働中のDBで明示的に残す必要はないでしょう。
そんなにユーザーが間違えて退会するのだとしたら、UIに問題があります。

一方ToB、例えば電子カルテのような法的に保存期間が定められているデータの場合、それに従うしかないです。この場合はデータの匿名化を行うことも難しいでしょうし、せいぜいネットワークから分断するなどのセキュリティ対策で対応になります。

要は思考停止で何でも残しておこう、というのが間違いです。
データ特性をきちんと定義して、それにあった保管期間・セキュリティを施した上で保持したり破棄したりする運用心がけるというのが正解ではないでしょうか。

Discussion

Masaya HayashiMasaya Hayashi

異性紹介事業の届けを出している事業の場合は速やかに警察対応に応じるために直近3ヶ月のデータは残しておくことが義務付けられていた気がするので、そのあたりを基準に保持期間を決めるのもアリかもしれませんね。
あと本人確認については、ユーザが提出した書類が否認されたときにユーザの問い合わせなどに適切に対応するために、即時削除ではなく一定期間は残しておいたほうが良い場合もあるかもしれません。

タカヤタカヤ

そうですね〜。
電子カルテの例で挙げてみましたが、法律や運用上どうしても長期保存しないといけないものは何しかしら工夫して保存するのが良さそうです。(匿名化だったり、ネットワークから遮断した場所に移行するなり)

即時削除ではなく一定期間は残しておいたほうが良い場合もあるかもしれません。

これも程度問題ってところですが、Omiai
の場合は退会済みのユーザや本人確認完了後も残していたみたいなので、このへんは1ヶ月後とか短期間で消してしまったほうが良かったんでしょうね〜