プレス発表 ITパスポート試験における個人情報等の漏えいについてに記載のあるとおり、IPAから個人情報の漏洩事件が発生しました。
上記リンク先には漏洩事件の概要程度しか記載されていませんが、日経XTECH IPAのITパスポート試験申し込みシステムで個人情報が漏洩、原因は排他制御の欠落の記事によると、排他制御の欠落が原因であるということです。
しかし、この事件の本質的な原因は排他制御の欠落ではなく、tempファイルの取り扱いにあるといえます。
原因は排他制御ではない
日経XTECH IPAのITパスポート試験申し込みシステムで個人情報が漏洩、原因は排他制御の欠落には、原因として以下の文章が掲載されています。
IPA広報によると、原因は複数のユーザーが同時にアクセスした際の排他制御がシステムから抜け落ちていたことだという。CSVファイル生成のリクエストがあった際には単一のファイルしか生成しないため、二つの団体申込者の両方の情報が記載されたファイルが生成され、それぞれの団体申込者がダウンロードできる状態になった。
ファイルに随時書き出すという処理はメモリ等の問題（巨大なデータを扱う場合など）からも考えられる手法ですが、「単一のファイルしか生成しない」ということが今回の本質的な原因であると見て取れます。
もちろん、記事にあるように排他制御を正しく入れることでも表面的には解決可能ですが、排他制御とはつまり、「その処理を行っている間は他の処理を待たせる」ということですから、ユーザビリティが激しく損なわれることは疑いようもありません。
出力先を共有してはならない
今回の悲劇は、出力先が単一のファイルであったことから、追記処理が並行で行われたときにファイルの内容が２つのリソースから混合して作成されたことです。これはログファイルなどの処理においては全く問題になりませんが、今回のようにセンシティブな情報を扱う場合、普通のプログラマであれば考え付かないレベルの設計です。
「同時並行で実行されるから問題なんだから、排他制御をすればいいじゃないか」というスタンスも、本来的なシステムの設計からはズレています。顧客情報を扱うようなリソースには、他のセッションやリクエストから生成されたスレッドがアクセスできるようになることは絶対にあってはならないのです。
本件の最適解とは？
例えば、メモリが潤沢に扱えるような状況であれば、メモリ上でCSVを作成し、そのまま返す方法が挙げられます。この場合、メモリは関数スコープで完結するため、他のスレッド（あるいは処理）から読み取ることはありません。
どうしてもディスク上に一時保存しなければならない場合は、ユーザー名+ユニークIDなどで一意なファイルを作成することや、UUID関数を使用する方法など、方法はいくらでもあります。
ファイルさえ適切に分けられていれば、いくらスレッドが競合しようが、情報が漏洩する余地は無かったはずです。
まとめ
今回の件は、このような稚拙な設計が世間に知れ渡ってしまったことこそ最大のダメージのように思えます。
情報処理推進機構は数々の資格を認定している機関であるだけに、その内部（あるいは委託先）の不祥事は、資格の価値すら揺るがす事態になりかねません。
今後、技術的な面も含め、信用回復に期待したいと思います。