システム情報の削除について

ある日、システムを管理している部門の方から、

「システム上の一部の情報を個人情報漏洩への懸念から削除してほしい」との依頼がきた。

「簡単に言ってくれるねぇ。」

その情報は、リアルタイムでデータ新規挿入および更新処理が行われるもの。

かつ、システム上では複数のエンティティと関連してデータを保持している。

作業の手順としては、対象のエンティティ全てに対し、

その情報を特定するキーとなる項目を指定し、対処を実施することが考えられる。

こう書くと「簡単」に思われるかもしれないが、思っているほど簡単ではない。

また、お客様データを対象としているので、当然リスクは大きい。

この件について、その後、依頼元と話し合った結果、

個人情報に関連する主要な項目だけを無機質なデータに更新(マスキング)することで落ち着き、対処実施した。

ヘタレと思われるかもしれないが、この判断は正しかったと考えている。

下手にデータ削除で対処するより、データ更新の方で対処した方がリスクは少ないと考えている。

せっかくなので、まとめてみた。

  (a).作業妥当性の確認について

       データの更新作業を実施する場合、当然作業後にその妥当性を確認する。

       データ削除で対処の場合、その作業の妥当性を

       作業前、作業後での対象データの件数で比較して確認する方法が考えられるが、

       リアルタイムにデータ登録されるテーブルの場合、

       データ削除作業した後、確認するために作業後に件数を取得する前のタイミングにおいて、

       別の業務処理によりそのテーブルにデータが挿入され、意図した件数より多く計上されるケースがある。

       その結果、「対象データのみ削除を実施した。」ということを担保するのが少々困難となる。

       その分、データ更新で対処した場合では、

       その作業前、作業後で更新したデータのみを対象とすればいいので、件数での比較は容易。

       ただし、データ更新で対処した場合は、件数の比較よりも、

       作業前、作業後でそれぞれ対象のデータを取得し、更新内容を確認する方が望ましい。

       でも、その作業自体は容易に行える。

  (b).リカバリ作業の容易性

       今回は求められなかったが「やっぱ、戻してくれない?」となるケースがある。

       その際のリカバリが、データ更新で対処した場合の方が、データ削除で対処したときよりリスクが少ない。

       データ削除で対処した場合の戻しは、そのデータを新規挿入することだが、

       データ削除 → そのデータを新規挿入(戻し)の間で、

       システム側で対象のキー項目が利用されることがあり、完全に元に戻せないケースが発生することがある。 

       そもそも、「その情報が必要なんだったら、削除を依頼すんじゃないよ。」という話である。

       それに比べ、データ更新で対応した場合は、元々キー項目に影響しない対処としているため、

       既に対象のキーが存在しており、情報が容易に行える。

       また、万一その対象データの選定に過不足があり、作業失敗した場合、

       データ削除での対処より、データ更新で対処した場合の方がリカバリが容易だし、

       「誤って必要なデータを削除した」となってしまったら、信用を一気に失うだろう。     

データ削除用のツールとか作ればいいとは思うのだが、当然ただではやらないよ。

そのツール作成する費用プラス利潤分お金くれよな。