相次ぐ不正アクセスから考える、エンジニアが今日見直すべきセキュリティ

Last updated at 2026-10-06Posted at 2026-10-02

2026年9月、タイムズカーの約660万アカウントをはじめ、国内で不正アクセスや情報漏えいの公表が相次ぎました。ニュースを見て「また漏えいか」と感じた方も多いのではないでしょうか。

ただ、各社の公表資料を読み比べてみると、被害につながっていたのは高度な攻撃というより、既知の脆弱性の放置や侵入に長期間気づけなかったことでした。この記事では、公表された事実だけをもとに、エンジニアが今日見直せることを整理します。

9月に公表された事案の一覧は、次のまとめが参考になります。

マイナビニュース「2026年9月のサイバー攻撃・不正アクセスまとめ」
セキュリティ対策Lab「2026年9月サイバー攻撃の被害事例まとめ」（国内外の事例と、悪用された脆弱性）
イープライズ「2026年9月不正アクセス・情報漏洩の主な被害状況まとめ（16事例）」

アジェンダ

不正アクセスは日本だけでなく、世界で増えている
9月に公表された主な事案
公表資料に共通する4つのパターン
AIで変わったのは、攻撃の「量と速さ」
大企業ほど、修正に時間がかかる
エンジニアが今日見直せる5つのこと
まとめ
参考文献

不正アクセスは日本だけでなく、世界で増えている

これは日本だけの動きではありません。2026年5月に公開された Verizon の「データ漏えい／侵害調査報告書（DBIR）2026」では、確認された侵害の件数が過去最多になりました。

指標	DBIR 2026 の数値
確認された侵害（データ漏えい）の件数	2万2,000件超。前年の1万2,195件からほぼ倍増し、過去最多
対象の国・地域	145か国
侵入経路の1位	脆弱性の悪用（31%）。前年1位だった認証情報の悪用は13%
委託先など第三者が関わる侵害	全体の48%（前年比60%増）

DBIR は、各国の捜査機関やセキュリティ企業などから提供されたデータの分析で、世界のすべての事案を数えたものではありません。それでも、分析対象となった侵害は1年でほぼ倍になり、過去最多を更新しました。

海外の事例では、ドイツ・ベルリン州政府のネットワークから8月に持ち出されたデータが、9月4日にダークネット上で公開されています。

9月に公表された主な事案

本記事で取り上げる4件だけで、計約880万件にのぼります。

公表日	事業者	影響規模	公表されている経緯
9月29日	セイコーマート	約57万アカウント（閲覧の可能性）	アプリのサーバー経由で会員サーバーへ不正アクセス。詳細は調査中
9月25日〜	タイムズカー	約660万アカウント（うち本人確認書類画像約160万件）	フォレンジック調査中。原因は未公表
9月11日	デジタル庁 GSS	約24.6万件（漏えいの可能性）	保守運用用VPN機器の既知の脆弱性を突かれ、保守運用アカウントが悪用された
9月10日	さくらインターネット	最大約136万アカウント（影響対象の可能性）	2023年4月〜2026年3月の長期にわたり不正アクセス

このほか9月には、Gyazo（ユーザー関連データ約2,362万件）、ムラウチドットコム（約772万件）、東京メトロ、京王電鉄なども公表しています。原因が調査中の事案については、侵入経路に触れません。

公表資料に共通する4つのパターン

侵入の手口そのものより、「入られた後」に被害が広がる条件に共通点があります。

1. 既知の脆弱性が、修正の順番待ちの間に突かれた
デジタル庁は、悪用された VPN 機器の脆弱性を事前に把握していました。CVSS 評価が「中」程度だったため、緊急度の高いものから順に対応している最中に悪用されています。CVSS のスコアだけで優先度を決めると、こうした「中程度だが実際に悪用されている」脆弱性を後回しにしてしまいます。

2. 乗っ取られた正規アカウントは、正規の作業と見分けにくい
GSS では、保守運用アカウントによる大量のファイルアクセスを検知してから、不正アクセスと判明するまで約2週間かかりました。大臣会見では、検知時点では正規業務か不正利用かを直ちに判断できなかったと説明されています。

日付	GSS の経緯
2026年5月下旬ごろ	VPN 機器の脆弱性を悪用した侵入が始まったとみられる
6月25日	保守運用アカウントによる大量ファイルアクセスを検知
7月9日	第三者による不正アクセスと判明。アカウント停止と通信遮断
9月11日	漏えいの可能性を公表

3. 侵入に長期間気づけなかった
さくらインターネットでは、不正アクセスが2023年4月から2026年3月まで約3年続いていました。GSS でも、侵入の開始から検知まで約1か月かかっています。

4. 価値の高いデータを、長く・広く持っていた
タイムズカーの影響対象には、退会済みの人や入会手続きを完了していない人も含まれていました。そのうち約160万件で、免許証などの本人確認書類の画像が漏えいしています。

AIで変わったのは、攻撃の「量と速さ」

Google の脅威分析チーム（GTIG）は2026年1月のレポートで、攻撃者がAIによって革命的な新手法を生み出したわけではないと結論づけています。変わったのは、既存の手口を回す量と速さです。

Anthropic が2025年11月に公表した事例では、攻撃グループが Claude Code を攻撃の自動化に悪用し、約30の企業・政府機関を同時に狙いました。作業の80〜90%をAIが実行し、人間が判断したのは1回の作業あたり4〜6か所だけです。標的の選定と攻撃の承認は人間が担い、ピーク時には数千件のリクエストを送っていました。判断できる攻撃者がいて、その手足をAIが増やしたという構図です。

防御側に残された時間も短くなっています。Check Point は、脆弱性の公開からAIが実用的な攻撃コードを作るまでが「数日」から「数時間」に短縮したと指摘しています。CrowdStrike によると、2026年上半期に確認された PoC（概念実証）による悪用の88%が、公開から48時間以内に発生しました。

なお、9月の各事案でAIが使われたかどうかは公表されていません。

大企業ほど、修正に時間がかかる

経済産業省・デジタル庁の資料（2026年2月）によると、レガシーシステムを保有する事業会社は61%で、大企業に限ると74%にのぼります。ここでいうレガシーシステムは、保守や改修が難しく高コストになっているシステムのことで、同資料は大規模な刷新が数年がかりの計画になると指摘しています。

大企業の情シス担当者528名への調査（テックタッチ、2024年）では、レガシーシステムが原因の問題として次が挙がりました。

問題	割合
機能や詳細がブラックボックス化している	47.2%
肥大化し、改修や機能追加が難しい	38.6%
他のシステムと連携できず、DX が遅れる	31.8%

Verizon DBIR 2026 では、パッチ適用までの中央値が32日から43日に延び、脆弱性の悪用が侵入経路の1位になりました。攻撃は2日以内に始まるのに、修正には中央値で43日かかる。この差の中で、システムの刷新を待たずにできることを次にまとめます。

エンジニアが今日見直せる5つのこと

ここまでの事実を、点検項目に置き換えました。

見直すこと	確認すること	見落としやすい点
脆弱性の優先順位	外部公開機器まで資産台帳に載っているか KEV・EPSS で優先度を判断しているか	評価は公開後に引き上げられることがある
保守・特権アカウント	MFA が必須か作業のときだけ権限を付与しているか（JIT）接続元を制限しているか	委託先・退職者のアカウントが残る VPN 機器自体の脆弱性で MFA を回避される
機微データの保存	そもそも保存が必要か期限が来たら自動で削除されるか分けて保管し、暗号化しているか	退会者・手続き未完了者のデータバックアップや分析用コピーに残る
パスワードの保存	Argon2id や bcrypt など専用の方式かユーザーごとにソルトを付けているか	古い管理画面や連携システムに旧方式が残る
侵入後の検知	大量読み出し・時間外・普段と違う接続元を検知できるか侵入の開始時点までさかのぼれる期間、ログを残しているか	ログイン失敗の監視だけでは、乗っ取りに気づけない

KEV は米 CISA が公開している「実際に悪用が確認された脆弱性」の一覧、EPSS は FIRST が公開している「今後30日に悪用される確率」の予測値です。CVSS と組み合わせると、パターン1のような後回しを防げます。

機微データについては、「どう守るか」より先に「持たずに済まないか」を考えるのが効果的です。オンライン本人確認（eKYC）を外部事業者に任せ、自社は「確認済み」という結果と日時だけを持つ設計にすれば、漏れて困る画像そのものがなくなります。

まとめ

9月の公表資料から見えたのは、既知の脆弱性・強すぎる権限・気づけない仕組み・持ちすぎたデータという4つの条件でした。一方で、不正アクセスによる侵害は世界的に増え、AIによって悪用までの時間も短くなっています。システムの刷新を待つ余裕はないので、まずは今のシステムのままで5つの点検から始めてみてください。

セキュリティは、セキュリティ担当者だけの仕事ではありません。設計で「このデータは本当に必要か」と問うこと、実装で古いやり方に気づいたら声を上げること、運用で放置されたアカウントやパッチに気づくこと。日々の判断の一つひとつが、そのまま守りの強さになります。

1人のエンジニアとして、私自身も、そして読んでくださったみなさんも、これからもセキュリティの観点を強く持って仕事をしていきましょう。