流出

http://www.creation.gr.jp/個人情報流出の話。
一応、法的な「個人情報」の定義は個人情報 - Wikipediaを参照のこと。

個人情報

実際のところ、住所・氏名くらいまでは比較的容易に調べることが出来る。しかし、住所・氏名はただの基礎データにすぎない。用途と言えばダイレクトメールを送るくらいか。
その基礎データにどのような属性情報が紐付けられているかが個人情報の「価値」を決める。
例えば、学校の卒業生名簿だ。年齢・性別も特定できる場合、より範囲を絞ったダイレクトメールを送ることができる。小学校高学年になると学習塾や通信教育のものが届いたり、二十歳になると成人式の衣装のものが届いたり、就職活動期にリクルートスーツのものが届いたり、……、といったところ。

今回の名簿

この名簿の肝は同人誌即売会に参加した際の名義が載っていることだ。趣味趣向というものはきわめて「価値」の高い情報である。それも同人誌を作っているということなら趣味趣向の方向性に加えて強度まで判る。どれだけコストをかけることが出来るのか、とかね。
また、同人誌自体と照合すれば著作権侵害やその他の法律違反の明確な証拠となりえる。実際に訴えられるかどうかは別として、同人誌即売会潜在的なリスクが表面化したと言える。

紐付

他の住所・氏名・年齢・性別といった情報は、それ自体にも意味があるものの、手に入れようと思えば手に入る情報である。この情報はむしろ他の情報と紐付けるためのインデックスとして活用されるのではないか。
例えば、学校や会社といった所属先を調べることも可能だ。法律に違反したものを売っていたという情報を騒ぎ立てられたら相当困ったことになるだろう。

対策

正直、流出してしまった情報を回復するのは難しいので、こういった問題が起こりにくいシステムを考えてみる。

流出を防ぐ
流出の大半は人災。流出しかねない環境にデータを渡すこと自体がシステム側から見れば流出である。機能制限済みシンクライアントや孤立ネットワークなど、ホワイトリスト方式の環境を作ると良い。
紐付を防ぐ
項目の大半は不要。作業ごとに必要な項目を設定しておき、名簿の元データから生成した作業用データを利用する。RDBMSに格納した元データに対するビューとして作業用データを定義すると良い。