クラウドがランサムウェアで停止したら？IDCF事案に学ぶバックアップと復旧

何が起きたか：IDCFクラウドのランサムウェア被害を時系列で整理

「社内のサーバーはやめてクラウドに移したから、データは安全なはず」。そう考えている経営者や情報システム担当の方は多いと思います。しかし2026年10月、その前提を見直すきっかけになる事案が起きました。IDCフロンティアが提供する「IDCFクラウド」がランサムウェア(データを暗号化して使えなくし、復旧と引き換えに金銭を要求する攻撃)の被害を受けたのです。

公表された情報を整理した事案まとめや影響サービスの整理記事によると、経緯の概要は次のとおりです。

• 2026年10月7日：被害が公表される。東日本リージョン1の4つのゾーン(データセンター内の区画)が停止
• 影響範囲：物流サービスや自治体のWebサイトなど、495の企業・自治体に影響
• データの扱い：事業者は、対象ゾーンのデータは取り出しや復元が難しい見通しで、復元できるのは利用者自身のバックアップからのみと説明
• 10月27日(第7報)：侵入口がクラウドポータルの認証システムで使っていたオープンソースソフトの脆弱性であり、仮想化基盤の管理者権限を奪われたと報告

2026年は、9月の京王電鉄グループの被害をはじめ、ランサムウェアの事案が続いています(2026年のセキュリティ事案一覧、2026年のランサムウェア被害事例)。この記事では、攻撃を「防ぐ」話ではなく、止まった後にどう戻すかに絞って、中小〜中堅企業が自分の責任でやるべきことを整理します。

侵入口はオープンソースソフトの脆弱性：クラウド事業者もサプライチェーンの一部

今回の侵入口は、認証システムに組み込まれていたオープンソースソフト(誰でも利用・改変できる形で公開されているソフト)の脆弱性(セキュリティ上の弱点)だったと報告されています。そこから仮想化基盤(多数の仮想サーバーをまとめて動かす土台)の管理者権限が奪われたため、個々の利用者がどれだけ自分のサーバーを守っていても、影響を避けにくい構造でした。

これは「サプライチェーン攻撃」の考え方で捉えると理解しやすくなります。サプライチェーン攻撃とは、直接の標的ではなく、取引先や利用しているサービス・部品の弱点を突いて被害を広げる攻撃です。自社のシステムは、クラウド事業者、その事業者が使うソフト、さらにそのソフトの開発元という連鎖の上に成り立っています。どこか一つが破られると、自社の業務も止まる可能性があります。

大切なのは、特定の事業者を責めることではなく、「どんな事業者でも止まる可能性はある」という前提で自社の備えを組み立てることです。

『データはクラウドにあるから安心』は誤解：事業者と利用者の責任の分かれ目

クラウドには一般に「責任共有モデル」という考え方があります。基盤の運用は事業者、その上に置くデータや設定、バックアップは利用者、というように責任を分ける考え方です。今回、事業者が「復元できるのは利用者自身のバックアップからのみ」と説明したことは、この分かれ目を具体的に示したものと言えます。

よくある誤解を整理しておきます。

• 「冗長化されているから大丈夫」：冗長化(機器を二重化して故障に備えること)は故障対策であり、管理者権限を奪われて暗号化されれば、複製先も同時に影響を受けることがあります
• 「同じクラウド内でバックアップを取っている」：同じ基盤・同じ管理権限の中にあるバックアップは、基盤ごと被害を受けると使えない場合があります
• 「契約で守られている」：補償の範囲と、データそのものが戻るかどうかは別の問題です。契約内容を一度確認しておくことをおすすめします

利用者が持つべきバックアップ：別の事業者・別の場所に置き、書き換えられない形で保管する

止まった後に戻すための土台はバックアップです。押さえたいポイントは3つあります。

1. 別の事業者・別の場所に置く

メインのクラウドとは別の事業者、あるいは少なくとも別の地域・別のアカウントにバックアップを置きます。一般に「3-2-1ルール」(データを3つ持ち、2種類の媒体に保存し、1つは離れた場所に置く)と呼ばれる考え方が参考になります。

2. 書き換えられない形で保管する

ランサムウェアはバックアップも狙います。一定期間は削除・変更ができない「イミュータブル(書き換え不可)」な保存方法や、ネットワークから切り離した保管を組み合わせると、バックアップまで暗号化される危険を下げられます。

3. 権限を分ける

本番環境の管理者と、バックアップの管理者を同じアカウントにしないことも重要です。片方が奪われても、もう片方が残る形にしておきます。

対象はデータベースだけではありません。ファイル、設定情報、ドメインやDNS(Webサイトの住所を管理する仕組み)の設定、証明書など、作り直しに必要なものを一覧にしておきましょう。

どこまで戻せば業務が回るか(RTO/RPO)を決めて、実際に戻す練習をする

バックアップがあっても、戻し方が決まっていなければ復旧に時間がかかります。BCP(事業継続計画)の一部として、次の2つの指標を決めます。

• RTO(目標復旧時間)：止まってから何時間・何日以内に再開すべきか
• RPO(目標復旧時点)：どの時点のデータまで戻れれば許容できるか(例：前日の夜の状態まで)

すべてのシステムを同じ水準にする必要はありません。たとえば次のように優先度を分けると、費用と手間のバランスが取りやすくなります。

そして最も大事なのが実際に戻す練習です。バックアップを取っていても、いざ戻そうとすると「手順がわからない」「必要な設定が抜けていた」「想定の何倍も時間がかかった」ということは珍しくありません。年に1回でも、別環境に復元して業務が回るかを確かめると、RTOが現実的かどうかがわかります。

作り直せるシステムにする：構成をコードで残す、手順書を整える、AI駆動開発で手早く再構築する

今回のように基盤ごと使えなくなった場合、データだけでなくシステムそのものを別の場所で作り直す必要があります。そのための備えは次のとおりです。

1. 構成をコードで残す：サーバーやネットワークの設定を手作業ではなく、IaC(Infrastructure as Code：インフラ構成をコードで記述する方法)で管理すると、別の環境でも同じ構成を再現しやすくなります
2. ソースコードを別の場所にも保管する：アプリケーションのコードや設定ファイルも、本番環境とは別の場所で管理します
3. 手順書を整える：誰が、どの順番で、どこに連絡し、何を立ち上げるかを文書化します。担当者が不在でも動ける内容にしておくことが大切です

axflowでは、AI駆動開発(AIを活用して設計・実装・テストを効率化する開発手法)によってシステムを手早く作り直すという考え方を提案しています。日頃から仕様や構成を整理された形で残しておけば、万一のときにAIの支援を受けながら別の基盤で再構築する選択肢が生まれます。「元に戻す」だけでなく「早く作り直す」ことも、復旧の手段の一つになります。

クラウド事業者・開発会社を選ぶときに確認したいチェックリスト

最後に、事業者や開発会社を選ぶとき、または今の契約を見直すときに確認したい項目をまとめます。

• 障害や侵害が起きた際の公表方法と連絡体制が示されているか
• 事業者側のバックアップの範囲と、利用者が自分で取るべき範囲が明確か
• データを別の事業者・別の場所へ書き出す手段があるか
• 書き換え不可の保存や、権限の分離に対応できるか
• 脆弱性情報への対応方針(更新の頻度や手順)が説明されているか
• 開発会社が構成のコード化や手順書の作成まで対応してくれるか
• 復旧訓練の実施や、RTO・RPOの設計を一緒に検討してくれるか

まとめ：止まる前提で「戻せる・作り直せる」備えを

IDCFクラウドの事案は、クラウドに置いていても止まること、そして最後に頼れるのは自社のバックアップであることを示しました。やるべきことは、別の事業者・別の場所への書き換えられないバックアップ、RTO・RPOの設定と復旧訓練、そして作り直せるシステムづくりです。

axflowでは、現在のシステム構成とバックアップ状況の棚卸し、RTO・RPOの整理、構成のコード化や手順書の整備、AI駆動開発による再構築を見据えたシステム設計まで、実務に沿ってご支援します。「うちのバックアップで本当に戻せるのか」と少しでも不安を感じたら、お気軽にご相談ください。