1463件の漏えいが示す、チケット払い戻しデータの「寿命」問題

漏えいしたのは「本番の決済」ではなく「払い戻しの控え」だった

イープラスが9月29日に公表した不正アクセスの被害は、利用者1463件の個人情報が漏えいし、うち751件については振込先の口座番号まで含まれていた。電子チケット「スマチケ」の払い戻し情報を管理するシステムが標的になった。

この数字を「1463件」という規模だけで読むと、大規模漏えいが日常化した昨今では小さく見える。しかし注目すべきは件数ではなく、漏れたデータの種類と、それがシステム上に存在し続けていた理由だ。攻撃者が狙ったのはチケット販売の決済基盤ではない。公演が中止・延期になった際に、購入者へ代金を返すための口座情報——いわば「イベントが終わったあとにしか使わないデータ」である。

払い戻しデータは、なぜ「終わったあとも」残るのか

払い戻し処理は、チケット販売のワークフローの中でも例外的な工程だ。通常の購入ではクレジットカード決済で完結するが、公演中止となれば話は別で、主催者は購入者一人ひとりに現金を返す必要がある。そのためには振込先の銀行口座を预かりし、実際に送金するまで保持しなければならない。

問題は、この保持期間が業務上都合よく決まらない点にある。返金処理が終わっても、問い合わせ対応や会計監査、二重払いの検証のために、データは「しばらく」残される。その「しばらく」が数年単位に伸びることは珍しくない。今回のシステムがいつから稼働し、いつまでデータを保持する設計だったかは公表されていないが、本番の決済情報より長く生き残るデータが、結果として攻撃対象になったという構図は想像に難くない。

企業の情報セキュリティは「今使っているデータ」を守る方向に予算がつきやすい。しかし実際に漏えいリスクが高いのは、役割を終えて管理の優先度が下がった「過去のデータ」だ。アクセス権限の棚卸しも、暗号化の適用も、新規システムほど丁寧には行われない。

預ける側から見た「消えないデータ」のコスト

利用者側の視点でも、この事件は示唆的だ。私たちは銀行口座や住所を、チケットサイト、通販、サブスクリプション、各種会員登録のたびに預けている。そして多くのサービスは、そのデータを「サービスが続く限り」保持する。クラウドのストレージ費用は従量課金であり、使わないデータを抱え続けるほどコストがかかる。にもかかわらず削除しないのは、削除する判断をする人がいないからだ。

ここで、データを「預けて終わり」にする発想と、「自分で保管する」発想の違いが効いてくる。たとえば請求書や契約書、身分証明の控え、家族の写真といった、一度手元に置いておきたい記録は、特定のサービスのアカウントに紐づけておく限り、そのサービスの管理品質と寿命に運命を共にする。逆に、自分で暗号化して分散型ストレージに置くなら、保管の責任は自分の鍵に移る。Arweaveのようなブロックチェーン基盤の永続ストレージは、事前に支払った料金でデータを半永久的に保持する設計で、Long Driveもこの仕組みの上で、クライアント側のAES-256-GCM暗号化を選べるようにしている。パスワードを知るのは利用者だけであり、プラットフォーム側から中身は読めない。

重要なのは、どちらが優れているかという話ではない。「誰が、いつまで、何のために持つのか」を決めずに預けたデータは、役割を終えたあとも静かに残り続け、ある日まとめて漏えいするという共通の構造を、今回の751件は可視化している。

削除は設計であり、保存も設計である

イープラスの対応が適切だったかどうかを外から断じることはできない。だが、払い戻しという一時的な目的のために集めた口座情報が、目的を終えたあともシステム上に存在していた可能性は、多くの企業に共通する宿題だ。データは「取ったとき」より「手放すとき」の設計が難しい。

一方で、長期保存が本質的に必要なデータもある。契約書、研究記録、創作の原盤、家族史。それらは削除の対象ではなく、世代を超えて残す対象だ。問題は、消すべきデータと残すべきデータを同じ場所、同じ管理ポリシーで扱っていることにある。漏えい1463件という数字は、その混在が生んだ結果の一つと言える。データの寿命を意識して預け先を選ぶことは、もはや企業だけでなく個人にも求められている。