何が起きたか
2026年10月7日の未明、ソフトバンク子会社 IDCフロンティアの「IDCFクラウド」東日本第1リージョンに第三者が侵入し、ランサムウェアで基盤が止まった。利用者向けの通知(第7報)で、事業者はこう書いた。対象環境のデータと仮想マシンの復旧は極めて困難、スナップショットからの復元も困難、他リージョンでの再構築も安全性が確認できるまで推奨しない、データの復元は利用者自身が持つバックアップからのみ可能。
このクラウドの上には、電話サービス、EC の在庫管理、セキュリティ製品の管理画面、音声認識アプリが載っていた。利用者 → SaaS → 基盤という三段の委託で、それぞれの利用者にまで止まった。侵入経路、被害の正確な範囲、攻撃者の声明の真偽は、本稿を書いた時点では確認できていない。
事例の細部は、知りたい人が AI に調べさせればよい。ここに残すのは教訓だけである。
五つの教訓
- スナップショットはバックアップではない。 本体と同じ基盤に載った控えは、基盤ごと消える。控えは、本体とは別の機械・別の場所・別の権限に置く。
- リージョンを分けても、管理面が一つなら障害領域は一つ。 事業者自身が「他リージョンも当面推奨しない」と言った。地理の分散と、権限の分散は別のものである。
- 委託の鎖の上にいる人ほど、契約を読んでいない。 クラウドの契約は昔から、データの控えを利用者の責任としている。SaaS に載せた会社も、その SaaS の利用者も、下の段が控えを持っていると思っていた。
- 守る側の人数が、守れる範囲を決める。 24時間監視をうたう基盤でも、見る人がいなければ看板にすぎない。自分の一台なら、管理面を握るのは自分一人で、障害領域もその一台で閉じる。
- 自社でやれるようにする。 控えを取る・戻す・一台を立て直す、を自社の人が自社の機械でやった経験を持つ。委託先に「やっておいて」と言った瞬間、三段の鎖に戻る。手順は サーバー編に置き、最初の二つは 第10章の 3-2-1 ルールに書き足した。
関連
- Claudeと一緒に育てるDebian サーバー 第10章 データを守る ── 3-2-1 ルール、restic、復元の演習
- 同 第5章 守りの基本 ── 入りも出も既定拒否のファイアウォール
- AI ネイティブなソフトウェア開発 2-11 Web を公開する ── 自分の一台か、借りた窓か
出どころ
- ITmedia NEWS「IDCFクラウドに不正アクセス 東日本の第1リージョンで障害」(2026年10月7日) ── https://www.itmedia.co.jp/news/article/2610/07/2000002087/
- IDCフロンティア「【障害連絡】IDCFクラウド障害発生のご連絡(第7報)」(2026年10月、利用者向け通知)
- 影響を受けたサービスの一覧(セキュリティ対策Lab、2026年10月7日) ── https://rocket-boys.co.jp/security-measures-lab/idcf-cloud-outage-affected-services-2026/