「退会したのに、なぜ情報が残っている？」 開発者が見落としがちなデータ管理の盲点：セキュリティ担当者の耳が痛いはなし（2/2 ページ）

退会者のデータや削除済みの画像が、なぜ漏えいするのでしょうか。背景には、再登録への対応や分析などを理由に、データを残し続けるシステム設計があります。業務部門から「データを残してほしい」と頼まれたとき、開発者は何を考慮すべきなのか。保存する項目の絞り込みから、データの分離、保存期限の設定まで、情報漏えいのリスクを抑えるための設計のポイントを解説します。

[伊藤秀明，＠IT]

「残しておいて」を受けた開発者が設計すべき3つのこと

　退会者のデータを残す必要があるかどうかは、業務部門や法務などと連携して判断しなければなりません。開発者が設計で担えるのは、保存目的に応じてデータを絞り、アクセス範囲や保存期間を制御し、不要になったデータを確実に利用できない状態にすることです。

1．何のために残すのかを決め、項目を絞る

　業務部門からデータの保存を求められたら、まず何のために、どの項目を、いつまで使うのかを確認します。その上で、目的ごとに残すデータの項目と形式を決めます。例えば、次のような設計が考えられます。

• 再登録の防止や再入会時の照合：メールアドレスや電話番号をHMACなどで変換し、元の値を直接保持せずに照合できる形にします。鍵はデータベースと分離して管理し、照合機能へのアクセスも制限します
• 再入会時の引き継ぎ：会員IDやポイント残高、購入履歴など、実際に引き継ぐ必要がある項目に絞って保存します。
• 退会理由の分析：退会理由や利用期間、プランなど、分析に必要な項目を残します。氏名や連絡先を除外し、会員IDも分析用の別IDに置き換えます。元のIDとの対応表がある場合は分離して管理します
• 法令に基づく保存：対象となる帳簿や本人確認記録など、法令で求められる記録と保存期間を特定し、必要な範囲で管理します

　ここで注意したいのは、ハッシュ化やIDの置き換えだけで、必ずしも個人を識別できなくなるわけではないことです。元の情報と照合できる仕組みが残っていれば、引き続き個人情報として管理すべき場合があります。

　目的を説明できない項目は残さないことを基本にします。保存する項目と期間を要件として明文化しておけば、後から追加の要望が出たときにも、目的に照らして判断できます。

2．現役会員のデータと分離し、複製先も管理する

　残すと決めたデータは、現役会員のデータと論理的・権限的に分離します。別のテーブルやデータベースに移すだけでなく、参照できるアプリケーションや担当者、認証経路なども見直します。同じ認証情報や過剰な権限で双方にアクセスできるなら、テーブルを分けても十分な防御にはなりません。

　退会者のデータ専用の暗号鍵を使う方法も考えられます。保存期限がそろうデータ群ごとに鍵を分ければ、期限を迎えたデータ群の鍵だけを破棄する設計にできます。ただし、鍵を破棄すれば必ずデータを消去できるわけではありません。鍵の複製や復旧手段、暗号化されていないデータが残っていないかどうかを確認する必要があります。

　さらに会員テーブル以外の複製先も管理対象にします。メール配信や顧客管理のSaaSでは、退会時にAPIを呼び出してデータを削除します。分析基盤に取り込んだデータについても、氏名や連絡先などの不要な項目を除外し、保存期限に応じて削除する仕組みを設けます。

　退会をイベントとして発行し、各システムがそのイベントを受け取って削除や更新を実行する設計にすれば、複製先が増えた場合にも処理を統一しやすくなります。ただしイベント処理の失敗や連携先の停止によって削除が漏れる可能性もあるため、処理結果を記録し、失敗を検知して再実行できるようにすることが重要です。

　委託先に渡したデータについても、契約上の削除方法や時期、削除完了の確認方法を決めておきましょう。

3．保存期限と保有件数を可視化する

　退会者のデータにも、保存目的に応じた期限を設定します。退会日時だけで一律に削除するのではなく、法令上の保存義務や返金対応などの必要性を踏まえ、項目ごとに期限を管理します。

　期限が来たら削除や鍵の破棄を実行するバッチ処理を設計に含め、処理が失敗した場合には検知できるようにします。バックアップについても保持期間と削除のタイミングを定義し、復元後に削除済みデータが再び有効にならない仕組みを用意します。

　同時に、現役会員と退会者のデータを状態ごとに集計し、保有件数を把握できるようにします。例えば現役会員が70万人、退会者のデータが30万人分あれば、合計100万人分のデータを保有していることになります。これは漏えい時の法的な通知対象者数と必ずしも一致するわけではありませんが、影響を受け得るデータの規模を把握する目安になります。

　件数や保存期限をダッシュボードで可視化すれば、開発者だけでなく、保存を求めた業務部門や経営層も、どれだけのデータを抱えているのかを確認できます。保存期限の延長を求められた場合も、目的と必要な項目を再確認した上で更新します。延長が自動的に繰り返される仕組みにはしないことが重要です。

　まずは現在保有している退会者のデータについて、保存目的や保存項目、保存期限の3つを一覧にするところから始めてみてはいかがでしょうか。

データを残すなら、削除するところまで設計する

　退会者のデータを残すと決まっても、開発者ができる対策は多くあります。目的に必要のない項目を減らし、現役会員のデータと分離し、複製先まで含めて保存期限を管理します。こうした設計は、暗号化やアクセス制御と同じく、漏えい時の影響を小さくするための対策になります。

　押さえておきたいのは、何のために残すのかを決めること、現役会員のデータと分離して複製先まで管理すること、保存期限と保有件数を可視化することの3点です。

　「退会者のデータは残しておいて」と頼まれたとき、開発者が最初に確認すべきなのは、保存方法だけではありません。「何のために、どの項目を、いつまで残しますか」。その問いから、データを残す責任と、不要になったときに削除する仕組みの両方を設計に組み込んでいきましょう。