タイムズカー160万件免許流出が突きつけるデータ保持と廃棄の技術的負債

• 事実と背景：タイムズカーのWeb不正アクセスで会員660万件の漏えいに加え160万件の免許証画像流出が判明。
• 技術的変革：法的義務を背景とした退会者データの7年保持が、攻撃表面（アタックサーフェス）を巨大化させていた。
• 現場への影響：KYC画像等の超機微データは平文保存を脱し、KMS暗号化や自動破棄パイプラインの組み込みが急務。

深夜の障害アラートが鳴り響き、データベースのCPU使用率が100%に張り付く——そんな修羅場を何度も経験してきた我々シニアエンジニアにとっても、今回のニュースは背筋が凍る思いがしたはずだ。パーク24グループのタイムズモビリティが運営するカーシェアリングサービス「タイムズカー」において、第三者による不正アクセスが発生。会員情報約660万件の流出が確認された第2報に続き、第3報では実に約160万件におよぶ「運転免許証画像」や「現住所確認書類画像（公共料金請求書等）」、「学生証画像」が漏えいしていたと発表された。

単なるテキスト形式のパスワードハッシュやメールアドレスの漏洩とは異なり、高解像度の本人確認書類画像（KYCデータ）が外部に流出したインパクトは計り知れない。漏洩直後から、被害を恐れたユーザーによる信用情報機関（CICやJICC）への「本人申告」手続きが殺到し、システム処理が大幅に遅延するという深刻な二次被害まで引き起こされている。株価も一時5%安と大幅続落を余儀なくされたが、これは単なる一企業の不祥事ではない。我々開発現場が日常的に扱っている『ユーザーから預かった身分証明書データ』が、ひとたびWebの脆弱性（SQLインジェクションや認証プロキシの破綻、権限昇格バグなど）によって奪われた際の破壊力を痛烈に示す事件だ。

漏洩したデータの分類と影響規模を整理すると、以下の通りとなる。

私自身、過去のプロジェクトで「免許証画像をS3バケットに放り込んで終わり」という簡易的なKYC機能を実装したコードを目にしたことがあるが、今回の件を見て冷や汗が出た。我々は、一度侵入されたらすべての画像が抜かれてしまうような「平文ストレージのデッドロック状態」にシステムを放置していないだろうか。まずはその現実を直視しなければならない。

今回の事件でエンジニアコミュニティが最も紛糾したのは、「すでに退会したユーザーの免許証画像まで漏洩していた」という事実だ。なぜ退会して何年も経つユーザーの極めてセンシティブな画像データが、依然として攻撃者から手が届くWebシステム側に存在していたのか？パーク24側の説明によれば、自家用自動車有償貸渡事業（レンタカー・カーシェア）に関わる法令順守や、貸渡原簿の記録保持の観点から「退会後も7年間は保存する規定」になっていたという。

ビジネスサイドやコンプライアンス部門からの「法的に7年間は保持せよ」という要件を、そのままインフラやデータベースのデータ保持ポリシー（Data Retention Policy）に落とし込んだ結果、過去7年分のアタックサーフェス（攻撃対象領域）が膨れ上がり続けていたのだ。これは技術的に見れば、極めて巨大な『負債の累積』である。コードの可読性が悪いといったレベルの話ではない。データがデータベースやオブジェクトストレージに滞留し続ける「ストレージの無限ループ」が起きていたと言える。

法的要請があるからといって、サービス利用中のアクティブユーザーと同じオンラインのホットストレージ（あるいは同一の権限境界内）に、退会者の高解像度画像を7年間置く必要があったのだろうか？と私は強い技術的懸念を抱かざるを得ない。本来であれば、以下のような階層化アーキテクチャが検討されるべきだった。

• アクティブ層（Hot Store）：審査中および利用中のユーザーデータ。API経由でアクセス可能だが、暗号化と厳格なIAMロールで保護。
• アーカイブ層（Cold Store）：退会済みのデータ。プライベートネットワークから遮断された隔離環境（AWS Glacierやオフラインバケットなど）へ移送。復元には数時間の非同期申請プロセスを要する構成にする。
• トークナイズ・ハッシュ化：画像そのものを破棄し、法的に必要な「確認済フラグ」と「監査用ハッシュ値」のみを残す匿名化処理。

ビジネスの利便性を優先し、古いデータをホットなデータベースと紐づけたまま運用を続けることは、セキュリティの担保を放棄するに等しい。ビジネス要件とセキュリティアーキテクチャの乖離が生み出した悲劇だと私は分析している。

では、我々エンジニアが明日からのシステム開発で同様の惨劇を防ぐためには、どのような処方箋を書くべきなのか。単に「ファイアウォールを強固にする」「WAFを入れる」といった表面的な対策は気休めに過ぎない。根本的な解決策は、アプリケーションおよびインフラの「データハンドリングの構造改革」にある。

まず第一に徹底すべきは、**ストレージレベルでのエンベロープ暗号化とアクセストークン化（Pre-signed URL等）の徹底**だ。免許証などの画像ファイルをオブジェクトストレージ（AWS S3やGCSなど）に保存する際、単に「バケットを非公開にする」だけでは不十分である。Webアプリケーションサーバーが侵害されれば、アプリケーションが持つIAM権限を使ってバケット内の全画像がスクレイピングされてしまうからだ。個別オブジェクトごとのKMS鍵による暗号化、そして特定ユーザーの審査時のみ1分間限定の署名付きURL（Pre-signed URL）を発行し、アプリケーションサーバーを経由させずにクライアントに一時ブラウジングさせるような、最小権限の原則（Least Privilege）を徹底しなければならない。

第二に、**「ライフサイクルポリシー」の自動化パイプラインの構築**だ。退会フラグが立ったユーザーの画像データは、人間の手動運用に頼るのではなく、CronジョブやEventBridgeをトリガーとしたサーバーレスパイプライン（AWS Lambda等）で即座にメインDBから隔離・暗号化アーカイブされる仕組みをコード（IaC）として宣言しておくべきだ。コード化されていない運用ルールは、スパゲッティコード同様にいつか必ず破綻する。

我々が実装すべきKYCデータの安全対策チェックリストを以下に挙げる。

• 画像保存時にKMS等のCMK（カスタマー管理鍵）で個別に暗号化しているか？
• Webサーバーのアプリケーション権限で、ストレージ内の全件取得（ListObjects / Select All）が不可能な構造になっているか？
• 退会完了イベントと連動して、画像データの「マスキング」「隔離」「自動消去」がプログラムレベルで自動実行されるか？
• 万が一データが流出しても、個人特定が困難なように画像内の不要な情報（顔写真以外、あるいは番号以外）をOCR処理後にマスキングして保存しているか？

「データを安全に抱え込む」ことには限界がある。保持するデータそのものの価値を減衰させる技術（不可逆マスキングやトークナイズ）をアーキテクチャの初期段階から組み込むことこそが、我々エンジニアに課された真の役割である。

今回のタイムズカーの事故は、日本のIT業界全体に対し、「中央集権的に個人情報の生の画像を溜め込むビジネスモデル」そのものの限界を告げていると私は考える。コンプライアンスを守るために7年間データを保存した結果、ハッカーの絶好の標的となり、最終的に何億円もの損害賠償リスクとブランド失墜を招くという本末転倒な構造。我々はこの不条理なサイクルをそろそろ断ち切らなければならない。

技術的には、マイナンバーカードの公的個人認証サービス（JPKI）の活用や、分散型ID（DID / Verifiable Credentials）といった「ゼロ知識証明」アプローチへの移行が急務だ。サービス事業者が身分証明書の画像データを自社のDBに保存するのではなく、「ユーザーが有効な免許証を所有している」という数学的な証明結果のみを受け取る仕組みへシフトすれば、万が一データベースが漏洩しても、そこには流出すべき身分証画像が存在しない。これこそが最強のセキュリティ対策（非保持化）である。

最後に、画面の向こうにいるすべての開発者、アーキテクトに問いかけたい。

「あなたが今開発しているそのシステムは、本当にユーザーの免許証画像をDBに保存し続ける必要がありますか？」
「仕様書に書いてあるからと、無批判に『生データ』をストレージに溜め込むコードを書き続けていませんか？」

法的な要求とセキュリティリスクの板挟みになった時、技術によってその矛盾を解き明かすのがエンジニアの価値だ。便利さとトレードオフに危険なデータを抱え込む時代は終わった。我々は明日から、自らの手で「持たない設計」への第一歩を踏み出さなければならない。