入国者フォローアップシステム（ERFS：エルフス）
事故内容：2021年11月25日午前9時から、53社から申請のあった約170人分のデータのうち、28社が申請した34人分のパスポート情報などの添付ファイルを、他の受け入れ企業などが閲覧したりダウンロードしたりできたりする状態になっていた。
委託会社：日本エマージェンシーアシスタンス
開発担当者の説明：
不具合の原因は添付ファイルをアップロードするプログラムのバグ。同じタイミングで複数のユーザーがログインすると、別のユーザーがアップロードしたファイルを閲覧したりダウンロードできたりした。
デジタル庁の説明：
サービスの提供開始と同時に、複数人が同じタイミングでログインしたことにより、ウェブ上に登録したデータが混在して保存されたことが原因
考察：正直何をいってるかわからない。一般的なwebサーバとwebブラウザで利用するシステムだったとすれば、cookieが実装されてるしその仕組みをあえてサーバ側でhttpヘッダを書き換えるような（悪意の）実装があるわけがない。だからAさんのリクエストをBさんのリクエストであるとwebサーバが勘違いすることはありえない。
「同じタイミングでログイン」とあることから、ログイン時刻でユーザを特定するうんこシステムだったとすれば合点がいくか。同じ時刻にログインしたAさんとBさんは、プログラム上では見分けがつかない仕組みだったんだ。本来は、全ユーザで一意となるユーザIDで永続化（あるいは一時的にはセッションID）で見分けるのが常套手段だが、なぜかそれがログイン時刻になっていたと。Aさんは自分のパスポート情報を見ようと思ったら、同じ時刻にログインしたBさんのパスポート情報が開けてしまった。。。うーん、やっぱりプログラマの悪意の実装か？
DBの設計が素人で、PGがその制約の中で実装した感じなのかもしれない。最近自分も思うが、DBを素人が考えるとその後のことは取り返しがつかない。今回の（推測の域をでないが）一意性をどう担保するかは当然のことながら、正規化、リレーションとか、RDMSの考え方はOJTだけではなくある意味学問的に学ぶことには一定の価値があると思う。また、できる限りPGとセットで考えるほうが変更耐性も強いと思う。インピーダンスミスマッチが起きないし、開発過程で見直ししながら進めることもできるから。
DB（ER図）だけ考えてあとは外注するとか、そういう役割分担が現場では結構あるんだが、ビジネスロジックを書きながら「これでいいんだろうか」って思うPGさんは、結構いると思うんだよな。でも下請けにとってみればあえて自ら作業を増やすような提案はしないだろうし、言われたとおりにやる。で上流側の受入試験では中身の実装を見ずに力任せにSTで終わらせるから、表面上の品質をクリアしてしまうと。ここまで書くとよくある話だよなと納得する。
ま、想像なんだけど、委託を受けてる会社さんはシステム屋さんじゃないし、丸投げだった可能性は高いと思う。
入国者フォローアップシステム、34人分のパスポート情報が漏洩
