自社は破られていない。それでも漏れた企業が並んだ

IDCフロンティア、Commune、委託先のPC。2026年秋は経路が共通していました。

この記事の結論

  1. 起点が自社ではない公表が目立った
  2. クラウド基盤、コミュニティ基盤、委託先のPCの3種類
  3. 契約した時点で経路は増えている
  • 起点が自社ではない公表が目立った
  • クラウド基盤、コミュニティ基盤、委託先のPCの3種類
  • 契約した時点で経路は増えている

2026年秋に公表された不正アクセスを並べると、ひとつの傾向が出る。自社のサーバーが直接破られた話より、他社を経由して波及した例が多い。経路ごとに整理する。

経路1 — クラウド基盤

IDCフロンティアの事例だ。

  • 同社は10月7日午前3時40分頃、一部システムが不正アクセスを受けたと発表した
  • 対象は東日本第1リージョン
  • ランサムウェア攻撃
  • 495の企業・自治体に影響したと日経xTECHが報じている

利用していた側は、自社のコードも設定も変えていない。基盤が止まれば、その上の全部が止まる。

SPONSORED

利用側に出た影響

JR東日本とピーチ・アビエーションの例を見る。

  • JR東日本は、IDCフロンティアへの不正アクセスに伴い自社システムへの不正侵入があったと発表した
  • えきねっと会員 約167万件、大人の休日倶楽部会員 約39万件、ビューカード会員 約403万件のメールアドレスなどが対象
  • ピーチは旅程表メールが一時届かなくなり、代替サーバーに切り替えて8日から順次再開した

片方は情報、片方は業務だ。同じ起点から、違う形で影響が出ている。

経路2 — コミュニティ基盤

Communeの事例は手口まで公表されている。

  • 10月5日18時頃から不正アクセス、6日に検知
  • 約30.7万人分の会員情報が漏えい
  • プライベートコミュニティの招待リンクを不正に取得し、一般会員として登録した
  • 複数の不備を突いて管理者になりすまし、会員情報を閲覧・取得したと説明されている

侵入に特別な技術は要らない。正規の入口から入って、権限の確認の穴を通った形だ。

Commune経由で公表した企業

  • Sansan
  • LINEヤフー(DS.LAB、1,750名)
  • LIXIL
  • スズキ
  • 森永乳業(マウントカフェ部)
  • VALX(FUN、2,950名)

業種に共通点はない。共通していたのは使っていたサービスだけだ。

経路3 — 委託先のPC

第一興商の事例だ。

  • 10月8日に公表、約872万件が漏えいしたおそれ
  • 内訳はビッグエコーなどの顧客情報が約863万件、従業員情報が約9万件
  • 発端は業務委託先のPCのマルウェア感染と報じられている
  • 委託先の日本コロムビアグループが1〜2日に不正アクセスを受けたとされる

サーバーでもクラウドでもない。1台のPCが起点になっている。

3つの経路の共通点

経路自社でできること
クラウド基盤ほぼ無い。復旧を待つ
外部サービス預けるデータを減らす
委託先渡すデータと範囲を決める

1つ目に対して技術的な打ち手はほぼ無い。残る打ち手は、預ける量を減らすことだ。

IPAが挙げた対策も同じ方向

IPAは10月9日の注意喚起で、次を挙げている。

  • 利用しているサービスの網羅的な洗い出し
  • サービス単位のログの異常確認
  • アカウントの異常確認
  • 保有情報の再点検と、不要な情報の削除

「守りを固める」ではなく「どこに何を置いているか把握する」が先に来ている。

洗い出しが難しい理由

やってみると分かる。

  • 契約した部署と使っている部署が違う
  • 無料枠で始めたものが台帳に無い
  • 連携して使っているサービスが数えられていない
  • 退職者が作ったアカウントが残っている

3つ目が盲点になる。Aに預けたデータがBに渡っていることがある。

台帳に書く項目

これだけあれば判断できる。

  • サービス名と用途
  • 預けているデータの種類
  • 件数の規模
  • 管理者が誰か
  • 止まったときの代替

5つ目を書くと、止まったときの判断が速くなる。代替が無いものが分かる。

預ける量を減らす

これが唯一の確実な打ち手だ。

  • 目的が終わったデータを消す
  • 本人確認の書類は確認後に消す運用にする
  • 退会者のデータを残さない
  • 連携で渡す項目を最小限にする

今回の公表でも、退会者や入会未完了者が対象に含まれた例がある。

委託先に対して決めること

契約の話になる。

  • 渡すデータの範囲
  • 保管する期間
  • 再委託の可否
  • 事故が起きたときの連絡の期限

4つ目が抜けやすい。委託先が気づいてから自社に届くまでの時間が、公表の遅れになる。

止まる前提で考える

クラウドが止まった場合に備える。

  • 止まったときに何が止まるかを書き出す
  • 利用者に伝える手段を別系統で持つ
  • 復旧を待つ間の代替手順を決める

ピーチは代替サーバーに切り替えて翌日から再開している。切り替え先を持っていたかどうかが差になる。

自分のサイトに当てはめる

個人や小規模でも同じ構造だ。

  • レンタルサーバー、CDN、フォーム、解析、メール配信
  • どれも外部サービス
  • 止まれば自分のサイトも止まる
  • 預けている個人情報の量を把握しているか

フォームの送信先に何年分の問い合わせが溜まっているか、数えたことがあるだろうか。

今日できること

  1. 使っている外部サービスを全部書き出す
  2. それぞれに何を預けているか書く
  3. 消せるデータを消す
  4. 管理者アカウントの一覧を確認する

1つ目で止まることが多い。数が分からないなら、それが最初の問題だ。

まとめ

  1. 起点が自社でない公表が目立った
  2. クラウド基盤・外部サービス・委託先のPCの3種類
  3. クラウドが止まった場合、技術的な打ち手はほぼ無い
  4. 残る打ち手は預ける量を減らすこと
  5. まず洗い出す。数が分からないなら、それが問題

契約した時点で経路は増えている。増えた分を把握しているかどうかが今回の分かれ目になった。

SPONSORED

出典

いずれも発表および報道の時点の内容だ。調査中の事案は後から変わる。

AUTHOR

北海道のWEB屋

北海道を拠点に、Web業界14年・サポート実績1,000件以上。WordPressの復旧、サーバー移転、独自ドメインとメールの設定、PHP・JavaScriptの修正まで対応します。相談と見積もりは無料です。

SPONSORED

関連記事

RELATED