Web システムの情報漏洩は本当に増えているのか?
(タイトルは釣りです)
先月末に,カーシェアリングサービス「タイムズカー」の Web サイトが不正アクセスを受け大量の個人情報が漏洩した可能性があると報じられた件は大きな波紋を呼んだ。
660万件(サービスの会員数より多いw)という規模もさることながら,いわゆる「本人確認書類(運転免許証等の券面画像)」を流出させたことが大きな問題となり,メディアにも大きく取り上げられた。 ここまでのものは滅多にないだろうが1,こういったことが起きるとネット上で本人確認や年齢確認を要求するサービスには躊躇してしまうよねぇ。
それはともかく,このような事例が現れると便乗・模倣する輩も増えるし,メディアもわざわざ似たような事例を探し出して連呼するので,もの凄く増えたように見える。 しかし,実際のところはどうなんだろう。 どっかに統計情報を公開しているところはないかな,と思ったらありました。
というわけで,今回はこの記事を紹介がてら覚え書きを残しておこう。
Web システムの情報漏洩は本当に増えているのか?
まずは最初の疑問「Web システムの情報漏洩は本当に増えているのか?」であるが,どうも情報漏洩の件数が増えたのは7月頃かららしい。 件の記事をみると,それまでは概ね月10件以下のペースだったのが7月に15件となり,8月は26件,9月も27件と確かに増加している。
7月といえば OpenAI 社の AI モデルが自社サンドボックスと他社のセキュリティを突破して不正アクセスを行ったことを「AI の暴走」などと自慢しくさった件が思い起こされるが,これが影響しているかどうかは分からない。
注意しないといけないのは,件の記事にある統計は公表されているもので,時期もおそらく公表時点でカウントされているだろうということだ。 最近見かける報道では1年前からの未公表インシデントをここぞとばかりに公表するケースもあるようだ。 他にも未公表インシデントはあるだろうし,そもそも不正アクセスに気づいてないケースもあり得る。 ただ,傾向としては7月以降,情報漏洩の件数が増えているのは間違いないと思われる。
とするなら「タイムズカー」の件やその後の情報漏洩祭りは,以前から起こっていることの一部に過ぎないということになる。
一連の不正アクセスに AI は関与しているか?
一連の不正アクセスに AI が関与しているか否かはみんな関心があることだろう。 件の記事では以下のように述べている。
一連の事案でAIが使われたと断定できるログや痕跡は確認されていません。しかしながら、本事案以外の各種サイバー攻撃におけるAI活用は以前より当たり前に行われている状況にありますし、AIを組み込んだ、もしくはAIを用いて作られた攻撃・犯罪用ツールも多数流通しています。OpenAIやAnthropic、GoogleなどのAI事業者からは、非常に詳細な攻撃者のAI利用に関するレポートが公開されています。
また、今回確認した攻撃には前述の通りサイトごとに機能や不備を調べる動きが含まれています。こうした調査を広い範囲で繰り返すうえで、人間が手作業で調査を行うのは現実的ではなく、AIの活用を否定する方が難しい状況であると考えています。
明確に AI がやりました! と言える痕跡はないけど今どき使ってないわけないよね,といった感じだろうか。 まぁ,私等エンジニアも設計やコードを AI に書かすし,レビューもテストもやらせるからなぁ2。 犯罪者側が使わないわけないか。
今回の一連のケースは結構な「畜生働き」みたいで
不正アクセス前後の挙動には、システムに高い負荷をかけたり顧客に通知を発生させたりするなど、様々な痕跡を残したりする、ある意味で荒っぽいやり口も見られます。こうした動きが被害の発覚につながり、大小様々な規模の組織・運営元から公表が相次ぐ一因になっている可能性も考えられます。
などと,いかにも AI に雑な指示をしましたって感じではある(という意味で script kiddie か? と見えなくもない)。 派手に動き回ってる方がデコイの可能性もあるけど。
【2026-10-10 追記】AI エージェントによる攻撃の可能性に関するレポート
AI 支援攻撃の可能性についてレポートが上がっている。
サマリー部分を引用しておこう。
- 公開されたIPアドレスを起点に当社の観測データを調査した結果、SQLインジェクションによる認証回避の試行から、攻撃者自身のアカウントでのログイン、他の利用者のポイント窃取の探索へと段階的に進む攻撃を確認しました。
- 攻撃者は約40分間で326のIPアドレスを使い分けていました。同一の識別子が使い回されていたことから、同一の攻撃者によるものと判断しています。
- これらのIPアドレスから、約40分間に1,200件を超えるアクセスが行われる攻撃が複数回確認されました。
- このサイトへの攻撃に関してのアクセス量は人手とは考えにくい一方、ツール特有の機械的な規則性はなく、応答を見ながら手を変えていました。こうした特徴から、応答に応じて判断できる仕組み、たとえばAIなどが使われている可能性があります。
- 攻撃の痕跡を見つけるには、通常と異なるHTTPレスポンスコードやレスポンスサイズの偏りに注目したログ調査が有効です。
また,推奨する対策として以下を挙げている(詳しくはリンク元を参照のこと)
- 通常と異なるHTTPレスポンスコードの偏りを確認する
- レスポンスサイズの違いに注目する
- 公開された指標とログを照合する
- API・認証機能のアクセス制御と回数制限を点検する
- 脆弱性の解消とWAFによる防御を組み合わせる
参考にどうぞ。
犯行の目的は?
一連の不正アクセスの目的については,はっきりしたことは分からないようだ。
まず,対象となるサービスについて,以前はECサイトが多かったが「会員向けサービスや業務用システム、顧客対応など、さまざまな用途に分散してきている」らしい。
最近の被害における印象的な例としては、図書館の蔵書検索、観光列車の座席予約、大学のセミナーハウス施設予約、公演チケットの払戻し管理といったものがあります。こうした従来は標的になりづらかったようなシステムでも、情報漏洩やその可能性が公表されています。業種やサイトの規模もさまざまです。
こうした状況から、特定企業のサイトを標的にした活動ではなく、公開されたWEBシステム、特に個人情報を扱うサイトに手当たり次第、無差別的に攻撃を仕掛ける、さらには、攻撃に成功した場合同種の技術を使っているサイトを探し出して同様の手法が成功するか試して、脆弱なサイトから取得できる情報を盗む活動を繰り返している可能性が高いと考えています。
本当に「手当たり次第」という感じ。 「タイムズカー」サービスも,まさか自分のところがECサイトみたいに狙われるとは思わなかったのかもしれない。
件の記事では仮説として「次の詐欺やサイバー犯罪に使うための情報集めである可能性が高い」と考えているようだ。 「これからがほんとうの地獄だ」という感じだろうか。
一方で、違った捉え方もあります。攻撃者はまずセキュリティ上の不備があるWEBシステムを広く探索・侵害しており、その中で個人情報の被害が公表されるため、情報漏洩が特に目立って見えている、という見方です。
実際に7月以降の各組織からの公表情報を調査すると、個人情報漏洩の具体的な懸念を示さず、WEBサイトの改ざんや不正利用などを公表した事例も、少なくとも25件確認できました。 […] 個人情報の被害公表に注目する一方で、こうした被害も生じている点は注視が必要です。
攻撃手法と対策・確認
ここからは件の記事のほうを熟読してほしいが,ここでは項目だけ挙げておく。
今回の一連の不正アクセスについては公表情報が少なく,攻撃手法について特徴を語れるようなものはないらしい。 一般的な手法として以下の3つを挙げている。
- 共通ソフトウェア(製品・CMS・プラグイン・分析ツール等)の脆弱性を突くもの
- 認証情報の悪用やパスワード攻撃
- 個別のサイトの構造やAPIの機能やアクセス権設定の欠陥を突くもの
ここで3番目については
今回、確認された攻撃では、手法3)にあたる個別のサイトやAPIの不備を探る動きが具体的に見えてきています。特定の脆弱性だけを探すのではなく、サイト全体を広く調べ、画面やAPIを通常通り動かしながら、情報を取得できる不備を探る動きが見られています。スマホアプリを解析してAPIキーを取り出し、正規のアクセスに見える形でAPIを呼び出すケースもあります。
だそうだ。
1番目について,攻撃側による未知の脆弱性の発見・悪用は見られない模様。 でも,状況が分からないものが多すぎるからなぁ。
【2026-10-11 追記】
JPCERT/CC は観測された手法として
- さまざまなソフトウェアの既知の脆弱性を探索し攻撃試行するもの
- API経由での不正な操作
- 他のシステムの侵害で窃取したAPIキーを使用する
- 公開Webサーバーからアクセス可能なアプリケーションサーバー上にWebシェル(WARファイル)設置
を挙げている。 参考にするとよいだろう。
一方,対策・確認の観点として以下の3つを挙げている。
- 直近1か月を目安に、アクセスログを点検
- 未適用のパッチを確認し,適用を進める。管理者アカウントの認証強度の確認・改善を行う。多要素認証の勧め
- 重要なシステムでは,アクセスログやエラーログ,サーバーリソースの負荷を継続して監視することを検討する
クリティカルなシステムやECサイトなんかでは既にやってるだろうけど,前節で紹介したように手当たり次第に侵入を試す動きがあるため「うちは関係ない」と思ってたサービスでも運用の再確認を行う必要があるかもしれない。 面倒な話ではあるが。
先日書いた記事でも紹介したけど,たとえば Microsoft は今 AI の支援を借りて物凄い勢いで脆弱性の修正を行っている。 攻守いずれもスピード重視で大変なのである。
【2026-10-11 追記】
JPCERT/CC は対策としてより具体的に
API経由のアクセスへの対策:
- APIへのアクセスには単位時間あたりのリクエスト件数を制限し、短時間に繰り返されるアクセスや大量実行を防止する
- ログイン、パスワードリセット、SMS送信、検索処理などの負荷や悪用のリスクが高い機能には個別にレート制限や利用回数制限を設定する
- 非公開APIを含む各APIエンドポイントでアクセス制御を実施し、許可された利用者やHTTPメソッドからのアクセスのみを受け付ける
- API利用者やAPIトークンには必要最小限の権限のみを付与する
- APIトークンには適切な有効期限を設定し、長期間有効なトークンの使用を避ける
- 不要となった、または漏えいが疑われるAPIトークンは速やかに無効化できるようにする
上記の他、汎用的な対策:
- サービスの利用地域が限定される場合は、アクセス元の地域を制限する
- 既知の脆弱性の影響を受けるバージョンで運用している場合は、修正済みのアップデートを適用する
- Webサーバー等が侵害された後の横展開対策を見直す
- 不正アクセス検知体制の点検と検知時の初動対応を見直す
- 漏えい発生時を想定した、平時からの顧客への二次被害防止等の呼びかけ(多要素認証など)
- 業務上必要のないサービスや機能(管理機能など)がインターネットに公開されている場合、公開を停止する
- 法令や契約等で定められた保存期間を過ぎたデータや利用目的を終えたデータを残さない
と挙げている。 参考にするとよいだろう。
ブックマーク
- 直近で相次いでいる国内組織における不正アクセスに関する注意喚起 : 2026-10-09 に追記あり
- 不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構 : アプリケーションやサービスを提供している企業・組織向けの対策
- 自分の個人情報等が漏えいした際の「対処」と「日頃の対策」 | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構 : 個人向けの対策
- 国内で相次ぐ不正アクセスに対する注意喚起についてまとめてみた - piyolog : よいまとめ
- バックエンドAPIの脆弱性とAPI仕様ファースト開発|柴田 芳樹
参考
- 体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 | SBクリエイティブ
- 2011年3月刊行 「体系的に学ぶ 安全なWebアプリケーションの作り方」の改訂版。 Webアプリケーションに
- 評価
[Comment] 通称「徳丸本」。 Web アプリケーションを作成する際にはまず読んでおきたい一冊。近々第3版が出るらしい。
Powered by linkcard
- ハッキング思考 強者はいかにしてルールを歪めるのか、それを正すにはどうしたらいいのか
- 富裕層、権力者、急成長企業はシステムをハッキングして成功した。AI時代にルールを味方につけるには、「正しいハッキングの考え方」が必要だ。
- Release 2023-10-16
- 評価
[Comment] Kindle 版あり
Powered by linkcard
- セキュリティはなぜやぶられたのか
- ブルース・シュナイアー (著), 井口 耕二 (翻訳)
- 日経BP 2007-02-15
- 単行本
- 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN)
- 評価
[Comment] 原書のタイトルが “Beyond Fear: Thinking Sensibly About Security in an Uncertain World” なのに対して日本語タイトルがどうしようもなくヘボいが中身は名著。とりあえず読んどきなはれ。ゼロ年代当時 9.11 およびその後の米国のセキュリティ政策と深く関連している内容なので,そのへんを加味して読むとよい。

