退会者の免許証画像が660万件も漏洩。あなたの会社にも「消されていないデータ」がないか？

Last updated at 2026-09-29Posted at 2026-09-29

2026年9月の情報漏洩から見る「持たないデータは漏れない」

TL;DR

2026年9月、タイムズカー（約660万件）・Gyazo（約2,362万件）・デジタル庁など大規模漏洩が続いた
原因は3つに集約できる。既知の脆弱性の放置、本番DB以外からの流出、使っていないデータの保持
監視体制のある大企業でも、気づくまで1か月〜3年かかっている。監視のない中小は「気づけていない」可能性が高い
侵入は防げない前提に立つなら、漏れる量を決めるのは「持っているデータの量」だ
最後に自社チェックリストを置く。まず退会者のデータがどこに残っているかを確認してほしい

8月記事の答え合わせ

8月に「ニチレイ・KDDIの夏は序章だった」という記事を書いた。要旨はこうだった。

AIで攻撃の「人件費」が消え、攻撃者1人が扱える標的数が桁違いになった
予想1：大企業の大規模漏洩はしばらく続く。迂回路は基盤サービスとサプライチェーン
予想2：次の本命市場は中小・下請け

それから1か月半。予想1は、残念ながらそのとおりになった。9月だけでタイムズカー、Gyazo、さくらインターネット、デジタル庁と、数十万〜数千万件規模の事案が並んだ。

予想2はどうか。ニュースを見る限り、中小の大規模被害は表に出てきていない。ただしこれは「起きていない」ではなく「見えていない」可能性が高い。理由は後半で書く。

そして今月の事案を並べて気づいたことがある。侵入経路より先に目を向けるべきは、なぜそのデータがそこにあったのかだ。

9月に何が起きたか

8月末〜9月末に公表された国内の主な事案。件数は各社の公表値で、「最大」「可能性」を含む。

公表日	組織	規模	侵入経路・原因	発覚のきっかけ
9/28	タイムズカー	約660万件（免許証画像を含む）	未公表	9/25 不正アクセスを検知
9/16	Gyazo	ユーザー情報約2,362万件	画像アップロードサーバーの脆弱性	9/11 発生、翌日までに遮断
9/10	さくらインターネット	最大約136万アカウント	未公表。2023年4月〜2026年3月まで侵入が継続	調査で判明
9/29	セイコーマート	約57万アカウント	アプリ用サーバー経由で会員情報サーバーへ	9/24 不正な退会処理が1件
9/15	LEAN BODY	約44万アカウント（退会者を含む）	分析ツールMetabaseの脆弱性。8/11から侵入	9/8 異常を検知
9/11	デジタル庁 GSS	約24.6万件	VPN機器の既知の脆弱性	6/25 保守アカウントの大量アクセスを検知
9/27	東京メトロ	メールアドレス約5.9万件	委託先サーバーへ国外から不正アクセス	9/20 メール配信の不具合
9/9	ApplyNow	調査中（個人番号・口座情報を含む）	データ分析ツールの脆弱性。8/9〜9/7	9/7 異常なアクセスログ
9/26	京王グループ	調査中	ランサムウェア。経路は調査中	9/26 未明システム障害

「発覚のきっかけ」の列は、後で効いてくる。

原因① 既知の脆弱性の放置

今月いちばんはっきりしている原因だ。

デジタル庁GSS：CVSS「Medium」が入口だった

侵入口はVPN機器の脆弱性。攻撃前に公表されていた既知のものだった
デジタル庁のQ&Aによると、当初公表されていたCVSS評価は「Medium」
侵入後は保守運用担当者のアカウントを使い、サーバー上の大量のファイルにアクセスされた
製品名とCVE番号は非公表。piyologはPalo Alto GlobalProtectの認証回避（CVE-2026-0257）の可能性を推測している

「Mediumだから後回し」は、多くの現場で普通に起きている判断だ。それが政府共通基盤の侵入口になった。

Metabase：KEV登録の当日から入られている

BIツールMetabaseに、認証不要のエンドポイントからSQLインジェクションで管理者権限を取れるCVSS 10.0の脆弱性が公表された
CISAは8月11日に悪用確認済み脆弱性リスト（KEV）へ登録
LEAN BODYへの不正アクセスは、同じ8月11日から始まっていた。同社は脆弱性情報の定期確認と更新ができていなかったことを要因として挙げている
ApplyNowも「データ分析ツールの脆弱性」経由で、8月9日から侵入されていた（ツール名は非公表）

論点：CVSSの数字で優先度を決めていないか

GSSはMediumで刺され、Metabaseは10.0でも当日に刺された。CVSSの高低は攻撃者の行動を予測しない。見るべきは「実際に悪用されているか（KEV）」と「自社がその機能を使っているか（到達可能性）」の2つだ。毎日137件公開されるCVEを全部追うのは無理でも、この2軸で機械的に絞れば数は激減する。

タイムズカー：EOLから10年のフレームワーク

タイムズカーの侵入経路は未公表だ。ただ、公開ページのHTMLから、2016年9月26日にサポートが終了したJavaフレームワークSeasar2（Teeda）が使われていたことが、エンジニアの間で指摘されている。不正アクセスの検知は2026年9月25日。EOLからほぼちょうど10年だ。

これが侵入口だったかはわからない。しかしEOLのフレームワークには、新たな脆弱性が見つかってもパッチが一切出ない。KEVで優先度を決めようが、到達可能性で絞ろうが、最後の「直す」ができない。直せない既知の脆弱性を抱えたまま運用している状態だ。

EOLのまま使い続ける理由は想像がつく。移行には費用がかかる。当時の担当者はもういない。動いているものは触りたくない。どれも現場では筋の通った理由だが、攻撃側にとっては関係がない。

原因② 本番DB以外から漏れている

今月の事案の多くは、本番の会員DBそのものではなく、その周辺から漏れている。

事案	漏れた場所	本番DBとの関係
LEAN BODY	分析ツール（Metabase）	分析用に接続された写し・接続情報
ApplyNow	データ分析ツール	同上
東京メトロ	委託先のメール配信サーバー	配信用に渡したメールアドレス
セイコーマート	アプリ用サーバー	会員情報サーバーへの踏み台
Gyazo	画像アップロードサーバー	コマンド実行からユーザー情報へ

BIツールは「データを見るための道具」だが、構造的には複数のDBへの接続情報を1か所に集約する箱だ。ここが破られると、本番DBを直接破られたのと同じ範囲が漏れる。しかも分析環境は本番と違って、監視もパッチも後回しにされやすい。

「分析用に本番データを丸ごとコピーしたMetabase環境」が、社内のどこかに立っていないだろうか。

委託先も同じ構造だ。東京メトロの件は、社名の出ていない委託先のサーバーから漏れた。契約書にセキュリティ条項があっても、渡したデータがどこに保存され、いつ消されるかまで把握している会社は少ない。

原因③ 使っていないデータを持っている

この記事でいちばん言いたいのはここだ。

東京メトロ：「使っていないデータ」だけが漏れた

不正アクセスを受けたサーバーに入っていたのは、メールが届かなくなって配信を停止していたアドレスだった。業務上もう使っていないデータだ。それだけが約5.9万件漏れた。

タイムズカー：退会者・入会未完了者の免許証画像

対象は現会員だけでなく、退会済みの人、申し込んだが入会を完了しなかった人まで含む約660万件
漏れた項目には運転免許情報と免許証画像、本人確認書類の画像が含まれる
検知から遮断まで1日かからなかった。防御の速さは十分だった

つまり被害規模を決めたのは防御の速さではなく、そもそも持っていたデータの量だ。免許証画像は本人確認を突破するなりすましに直結する。パスワードよりよほど価値が高い。

同じパターンは他にもある。LEAN BODYの約44万件は退会者を含む。セイコーマートの漏洩項目には「退会年月日」が入っていて、退会者のデータも残っていたことがわかる。

なぜ消されないのか

意図的に溜めているというより、「消す理由がないから残っている」会社が大半だと思う。

法律上は努力義務止まり。個人情報保護法第22条は「利用する必要がなくなったときは、当該個人データを遅滞なく消去するよう努めなければならない」と定めるが、これは努力義務で罰則はない。EUのGDPRは保存期間の制限が原則で、違反には制裁金がある
消すことにコストとリスクがある。外部キーで他テーブルとつながっている、集計に影響する、「消して壊れたら怒られる、消しても誰も褒めない」という非対称
論理削除が標準になっている。deleted_at を立てるだけの退会処理は、ユーザーから見れば退会でも、DB上は全部残っている
途中離脱データは誰も管理していない。申込フォームの途中で離脱した人のデータは、業務では使われないのに削除担当もいない
「いつか使うかも」。問い合わせ対応、不正調査、マーケ再利用。残す理由はいくらでも作れる

論点：データ最小化は「お金のかからない対策」

攻撃コストが下がって侵入が避けられない前提になると、漏れる量を決めるのは防御の強さより保持データ量になる。EDRやパッチ管理と違って、データ最小化は追加投資なしで被害の上限を下げられる数少ない手段だ。効果が見えにくいから後回しにされるだけで、優先度は高い。

どうやって気づいたのか

一覧表の「発覚のきっかけ」を分類すると、2種類しかない。

監視で気づいた

デジタル庁GSS：保守アカウントによる大量ファイルアクセスを検知
ApplyNow：システム内部の異常なアクセスログを検知
LEAN BODY：異常を検知。ただし侵入自体は約1か月前から続いていた

壊れて気づいた

セイコーマート：不正な退会処理が1件見つかった
東京メトロ：メール配信の不具合を調べていたら見つかった
京王：ランサムウェアでシステムが止まった

ログ監視やSOCを持つ組織でさえ、気づくまで1か月（LEAN BODY、ApplyNow）、長いと3年（さくらインターネット）かかっている。セイコーマートや東京メトロは、攻撃者が余計な操作をしたり、たまたま不具合が起きたりしたから見つかったとも言える。

静かに抜くだけの攻撃者なら、どちらも発覚していなかった可能性がある。

中小は「見えていない」

8月記事の予想2「中小が本命市場になる」は、9月のニュースには出てこなかった。ここからは推論として書く。

気づけない

監視の仕組みがない中小には、「監視で気づく」ルートが存在しない。残るのは「壊れて気づく」ルートだけだ。

ランサムウェア：業務が止まるので気づく
Webサイト改ざん：見ればわかる
顧客からの「変なメールが来た」という指摘

裏返せば、データを静かに抜かれて何も壊れていなければ、まず発覚しない。警察庁の統計ではランサムウェア被害の半数以上が中小企業だが、これは「気づける種類の被害」だから数字に出ているとも読める。IPAの調査でも、不正アクセスを受けた中小企業の約5割が脆弱性を突かれたと答えており、手口そのものは大企業と変わらない。

気づいても表に出ない

報告と公表は別物。2022年4月から個人情報保護委員会への報告と本人通知は義務になったが、プレスリリースでの公表は義務ではない。ニュースになるのは自主的に公表した会社だけだ
統計も公表ベース。東京商工リサーチの漏洩件数調査は上場企業とその子会社の自主開示を集計したもので、中小はそもそも対象外
委託先の被害は委託元の名前で出る。受託者は委託元に通知すれば自身の報告義務を免れる。東京メトロの件も「委託先のサーバー」とだけ書かれ、社名は出ていない
報告しない動機。義務を知らない、取引停止が怖い、信用を失いたくない

「被害が多い」ではなく「観測できていない」

中小の被害がどれだけあるかを直接示すデータはない。言えるのは、大企業ですら気づくのに1か月〜3年かかり、監視のない中小は壊れない限り気づけず、気づいても公表義務がない、という構造があることだ。

だから問いはこうなる。自社は、抜かれていても気づける状態か。

背景：攻撃の速度が上がっている

8月記事で書いた「攻撃の人件費が消えた」の具体例が、Anthropicの2026年9月脅威インテリジェンスレポートに出ている。

ShinyHunters系とみられる攻撃者が、認証情報の探索から権限奪取、データ窃取、恐喝までの工程にClaudeを使っていた
クラウド環境の侵害を2〜3時間で完了させた事例がある
侵入先で被害者のAIのAPIキーを手に入れると、自分たちの攻撃処理をそのキーに乗り換えていた。「living off the land」のAI版だ
別の事例では、約180万件のAndroidアプリを一括取得・逆コンパイルし、ハードコードされた秘密情報を自動スキャンするパイプラインが動いていた

AIが新しい脆弱性を作ったわけではない。入口は相変わらず既知の脆弱性と認証情報だ。変わったのは、その後の偵察・権限拡大・データ探索を回す速度と、並列で扱える標的の数だ。

人間が月次でパッチ判断をしている間に、攻撃側は公開当日に自動で刺しにくる。Metabaseの件はまさにそれだった。

対策：月曜の朝からできること

順番が大事だ。お金のかからないものから並べる。

1. 持っているデータの棚卸し（原因③）

退会者、入会未完了者、配信停止者、休眠アカウントのデータが、どのテーブル・どのサーバー・どのバックアップに残っているかを一覧にする
本人確認書類の画像は特に。審査が終わったら消す設計になっているか
保持期限を決める。「退会後○日で物理削除または匿名化」を仕様として書き、バッチで回す
論理削除しか実装していないなら、それは「削除していない」と認識する

2. データの写しの棚卸し（原因②）

BIツール、分析用DB、検証環境、委託先に渡したデータ。本番の写しがどこにあるかを一覧にする
Metabaseを自前で動かしているなら、今日アップデートする。加えて接続先DBの認証情報をローテーションする。パッチだけでは、すでに取られた接続情報は無効にならない
分析環境を本番と同じ厳しさで守れないなら、入れるデータを絞る（匿名化・カラム削除）

3. パッチ判断の基準を変える（原因①）

CVSSではなくCISA KEVと到達可能性で優先度を決める
VPN・ファイアウォールなど外部に露出している機器は、CVSSがMediumでも「悪用確認済み」なら即日対応
自社アプリの依存ライブラリはquiet-cveのような仕組みで機械的に仕分ける

4. 抜かれたときに気づける仕組み

1アカウントからの短時間・大量取得を検知して止める（GSS、アフラックの教訓）
特権アカウント・保守アカウントの利用を監視する
ログの保存期間。30日では、1か月前からの侵入を追えない
中小でSOCが持てないなら、EDR＋MDR（運用の外部委託）か、IPAのサイバーセキュリティお助け隊。詳細は8月記事を参照

5. 委託先の確認

渡したデータの保存場所、削除時期、削除証明を契約と運用の両方で確認する
「セキュリティチェックシートを書いてもらった」は確認したことにならない

自社チェックリスト

「はい」と即答できない項目が、今月の事案で刺された場所だ。所要時間は1時間程度。技術者と、データの持ち主（事業側）が一緒に埋めることを勧める。

A. 持っているデータ（原因③）

退会者のデータは物理削除または匿名化されている（論理削除は「いいえ」）
申込途中で離脱した人のデータに保持期限がある
配信停止・休眠アカウントのデータに保持期限がある
本人確認書類（免許証・保険証などの画像）は審査完了後に削除している
各個人情報の項目について「何のために・いつまで持つか」を書いた一覧がある
バックアップにも保持期限があり、期限切れの本番データが残り続けていない

B. データの写し（原因②）

BIツール・分析用DB・検証環境に本番データの写しがあるか把握している
その写しは本番と同じ水準でパッチ・アクセス制御・監視がされている
写しに入れるデータは必要最小限に絞っている（不要カラムの除外、匿名化）
Metabase等の自前ホストのBIツールは最新版で、接続先DBの認証情報を最近ローテーションした
委託先に渡したデータの保存場所と削除時期を、契約と運用の両方で確認している

C. 既知の脆弱性（原因①）

外部に露出しているホスト・ポート・機器の一覧がある
VPN・ファイアウォールのファームウェアが最新で、更新の担当者と頻度が決まっている
パッチの優先度をCVSSではなくCISA KEV（悪用確認）と自社での到達可能性で決めている
依存ライブラリの脆弱性を機械的にチェックする仕組みがある
サポート終了（EOL）したフレームワーク・ミドルウェア・OSを使っていない。使っているなら移行計画がある
「悪用確認済み」の脆弱性は、月次ではなく即日で判断・対応できる体制がある

D. 気づける仕組み

1アカウントからの短時間・大量データ取得を検知できる
特権アカウント・保守アカウントの利用がログに残り、誰かが見ている
ログを90日以上保存している
APIキー・アクセストークンの一覧があり、漏洩時に即時失効できる
EDR（振る舞い検知）が入っている。運用できないならMDRに委託している

E. 漏れたときの備え

個人情報保護委員会への報告義務（概ね3〜5日以内の速報）と本人通知の手順を知っている
「侵入された。最初の1時間で何をするか」の手順書がある
変更・削除できないバックアップがあり、復旧までの日数を把握している

結果の見方

Aで「いいえ」が3つ以上：侵入されたときの被害規模が、今の防御レベルと無関係に決まっている状態。最初にここを潰す
Dで「いいえ」が3つ以上：すでに抜かれていても気づけない状態。「被害がない」と「気づいていない」の区別がつかない
Cで「いいえ」が3つ以上：公開当日に自動スキャンで刺される候補に入っている

まとめ

9月の大規模漏洩は、8月記事の予想1のとおりだった。ただし本当に見るべきは侵入経路より「なぜそのデータがそこにあったのか」
原因は3つ。既知の脆弱性の放置、本番DB以外からの流出、使っていないデータの保持
東京メトロは使っていないデータだけが漏れ、タイムズカーは退会者の免許証画像まで漏れた。被害規模を決めたのは防御の速さではなく保持データ量
大企業でも気づくまで1か月〜3年。監視のない中小は「気づけていない」可能性が高く、気づいても公表義務はない
侵入は防げない前提に立つ。なら、漏れる量を先に減らす。データ最小化はお金のかからない対策だ

自社は、抜かれていても気づける状態か。そして、抜かれたときに何が漏れるか。チェックリストのAとDから始めてほしい。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up