IDCFクラウドのランサムウェア被害で「自社のバックアップから再構築」に。クラウドの外にデータの写しを置いているか確認する

こんにちは、インフラエンジニアのryuです。

2026年10月7日、IDCフロンティアのクラウドサービス「IDCFクラウド」で大きな障害が起きました。原因はランサムウェア攻撃と発表されています。

影響を受けた企業や自治体は495にのぼると報じられていて、自治体のWebサイトが見られなくなるなど、ニュースで目にした方も多いと思います。

今回の事案で特に注目されたのは、対象ゾーンの顧客データが取り出しや復元が困難な見通しとされ、利用者が自分で持っているバックアップから、別の環境で再構築するよう案内されたことです。

みなさんが担当しているシステムは、使っているクラウドが丸ごと使えなくなったとき、どこから戻せるでしょうか？

この記事では、公式発表と報道で分かっている範囲を整理したうえで、インフラエンジニアが自分の環境について確認しておきたいことをまとめます。

IDCFクラウドで何が起きたのか？¶

まずは、公式発表と報道で確認できる事実を並べておきます。この記事は、10月8日に出た第3報までの内容をもとにしています。

第3報の時点では、同じ東日本リージョン1のradian・newtonの2ゾーン、東日本リージョン2・3、西日本リージョン1では不正アクセスは確認されていないとされています。

一方で、利用者向けの管理コンソールは止められていて、ふだんのように自分で操作することはできない状態が続いていると報じられています。

侵入経路や情報漏えいの有無は、記事執筆時点では調査中とされています。ここに書いた内容も続報で変わる可能性があるので、最新の状況はIDCフロンティアの公式発表で確認してください。

復旧できたところと、できていないところ¶

報道を見ると、利用者側の状況は大きく分かれています。

たとえば、Movable Typeのクラウド版は、障害の前に取得したデータをGoogle Cloudに保管していて、そのデータを使ってさくらのクラウドへ移行すると報じられました。IDCFクラウドとは別の事業者にデータの写しがあったので、移行先を決めて作り直すことができたわけです。

一方で、どの時点まで戻せたかは利用者ごとにかなり差があるようです。障害の数時間前まで戻せたところもあれば、1か月以上前の時点にしか戻れなかったところもあると報じられています。

違いを生んだのは、バックアップを取っていたかどうかだけではありません。バックアップを本番と一緒に壊れない場所に置いていたか、そしてどのくらいの間隔で取っていたかが分かれ目になりました。

なぜクラウドの中のバックアップでは足りなかったのか？¶

クラウドを使っていると、スナップショットや事業者が用意しているバックアップの機能で十分だと考えがちです。

ふだんの障害なら、それで困ることはあまりありません。ディスクが1台壊れたり、操作ミスでファイルを消したりした場合は、同じクラウドの中にあるスナップショットから戻せます。

ただ、今回のようにクラウドの基盤そのものが攻撃を受けると話が変わります。本番のサーバーと、そのバックアップが同じ基盤の上にあれば、両方が同時に使えなくなります。

「どこまで一緒に壊れるか」で置き場所を考える¶

バックアップの置き場所は、何が起きたときに一緒に失われるかで考えると整理しやすくなります。

下に行くほど、今回のような事態に強くなります。そのかわり、転送の手間やコストが増えていきます。

全部のシステムでいちばん下までそろえる必要はありません。止まったときの影響が大きいシステムから順番に、どこまで用意するかを決めていくのが現実的です。

バックアップの基本的な考え方（3-2-1ルールや、冗長化との違い）については『冗長化とバックアップの違い』で詳しく書いています。今回の事案は、そこで説明している「1つは別の場所に置く」の別の場所を、どこまで離すかという話になります。

自分の環境で確認しておきたいこと¶

ここからは、今回のニュースを見て、自分の担当システムについて確認しておきたいことを順番に挙げます。

バックアップは、本番と同じ事業者の中だけにないか¶

最初に確認したいのは、バックアップの置き場所です。

本番のサーバー、スナップショット、バックアップ用のストレージが、すべて同じ事業者の同じリージョンにあるなら、今回と同じことが起きたときに戻す手段がありません。

もう1つ見ておきたいのが、バックアップを消せる権限です。本番を操作するアカウントで、バックアップも削除できる状態になっていないでしょうか。攻撃者が本番の管理者権限を取ったら、バックアップもまとめて消せてしまいます。

AWSのWell-Architectedフレームワークでも、ランサムウェアのような脅威からバックアップを守るために、バックアップを別のアカウントに分けたり、変更や削除ができない設定にしたりする考え方が紹介されています。

具体的には、本番とは別のアカウントをバックアップの保管専用にして、S3のオブジェクトロックのように一度書いたデータを決められた期間は消せない設定を使う方法です。AWS以外のクラウドでも、同じような機能が用意されていることが多いので、自分の使っているサービスで確認してみてください。

どの時点まで戻せるかを数字で言えるか¶

次に、バックアップの間隔です。

1日1回の夜間バックアップなら、最悪で1日分のデータが失われます。週1回なら1週間分です。今回、戻せた時点に差が出たのは、この間隔の違いによるところが大きいと考えられます。

どの時点まで戻せればよいかの目標をRPO（目標復旧時点）、どのくらいの時間で戻せばよいかの目標をRTO（目標復旧時間）と呼びます。

担当しているシステムについて、「最悪でも何時間前のデータには戻せる」と数字で答えられるか、一度確認してみてください。答えられない場合は、まずバックアップのジョブの設定と、実際に成功しているかどうかを見るところから始めます。

# 例：バックアップ先にあるファイルの日時を新しい順に表示して、最後に取れた日時を確認する
ls -lt /backup/db/ | head -5

# 例：cronで動かしているバックアップの設定を確認する
crontab -l

ジョブが動いているつもりでも、実は数週間前から失敗していた、ということは珍しくありません。最後に成功した日時を、決まったタイミングで確認する運用にしておくと安心です。

データだけでなく、環境を作り直す手順があるか¶

今回の案内は、データを戻すだけでなく別の環境で再構築するという内容でした。ここが見落とされやすいところです。

データのバックアップがあっても、サーバーのOS、ミドルウェアの設定、ネットワークやファイアウォールの設定、DNSの設定を作り直せなければ、サービスは再開できません。

特にDNSは、移行先のサーバーに向け直すときに必ず触ることになります。ドメインを同じ事業者で管理していると、その管理画面に入れなくなるおそれもあるので、どこで管理しているかを確認しておきましょう。

設定ファイルの写しは、たとえば次のようにまとめて取っておけます。

# 例：/etc の設定をまとめて保存し、別の事業者のストレージへ転送する前のファイルを作る
sudo tar czf /tmp/etc-$(hostname)-$(date +%F).tar.gz /etc

# 作ったファイルの中身を一覧表示して、読めることを確かめる
tar tzf /tmp/etc-$(hostname)-$(date +%F).tar.gz | head

もちろん、手順書やIaCのコード自体も、本番と同じクラウドの中にしか無いと意味がありません。Gitのリポジトリや手順書の置き場所も、あわせて確認しておく必要があります。

移行先の候補を決めておく¶

別の環境で再構築すると言っても、障害が起きてから移行先のクラウドを契約して、アカウントを作って、ネットワークを設計していると、それだけで何日もかかります。

今回の報道でも、早く復旧できた利用者は、移行先がすぐに決まっていたり、別のクラウドにすでにデータがあったりしたケースが目立ちます。

全部を事前に作っておく必要はありませんが、少なくとも次のことは決めておくと動きが早くなります。

• 移行先の候補になるクラウドやサーバーと、そのアカウント
• 再構築の作業をだれが担当し、だれが判断するか
• 利用者や取引先への連絡の手順

ランサムウェアに対して、利用者側でできることは何か？¶

今回はクラウド事業者の基盤が攻撃を受けた事案なので、利用者側で攻撃そのものを防ぐことはできません。

クラウドでは、基盤の部分は事業者が、その上に載せるOSやデータの部分は利用者が責任を持つという分担になっています。基盤が攻撃されたこと自体は利用者の落ち度ではありません。

それでも、自分のデータを戻せるようにしておくのは利用者側の役割です。今回の事案は、その部分を改めて見直すきっかけになったと思います。

ランサムウェアそのものの仕組みや感染経路については『ランサムウェアとは？』で解説しています。AWSを使っている方は、EBSスナップショットを使ったバックアップの取り方を『EC2のバックアップと復旧の方法』にまとめているので、あわせて確認してみてください。

訓練で「戻せるか」を確かめる¶

バックアップの置き場所と手順書がそろったら、最後は実際に戻せるかを確かめます。

検証用の環境に、バックアップからデータを戻してサービスが動くところまでやってみると、手順書に書いていなかった作業が必ず見つかります。証明書の再発行、外部サービスへのIPアドレスの登録、監視の設定などは、抜けやすい作業の代表です。

障害対応の訓練の進め方については、『障害対応の訓練の進め方』で、新人インフラエンジニアも参加できる形で紹介しています。

まとめ¶

最後に、この記事のポイントを振り返ります。

• 2026年10月7日、IDCFクラウドの東日本リージョン1がランサムウェア攻撃で停止し、4ゾーンの顧客データは取り出しや復元が困難な見通しと発表された
• 利用者は、自分で持っているバックアップから別環境で再構築するよう案内された
• 戻せた時点に差が出たのは、バックアップの置き場所と取得間隔の違いによるところが大きい
• 本番と同じ事業者の中だけにバックアップを置いていないか、削除できる権限が分かれているかを確認する
• データだけでなく、サーバー・設定・DNSを作り直す手順と、移行先の候補を用意しておく

クラウドを使っていても、バックアップを戻して環境を作り直す作業はインフラエンジニアの仕事です。Linuxのファイル操作やネットワークの設定、クラウドの基本を体系的に身につけておくと、こうした場面で落ち着いて手を動かせます。

InfraAcademyでは、『AWSロードマップ』でクラウドの基本から順番に学べるほか、『Linuxロードマップ』でサーバー構築の基礎を手を動かしながら確認できます。チームでまとめて学びたい場合は『法人プラン』も用意しています。

今回のニュースを、自分のシステムのバックアップを見直すきっかけにしてみてください。

参考¶

• 【第3報】当社サービスの一部システムへの不正アクセスによる障害について（IDCフロンティア）
• IDCFクラウド障害、顧客データは「取り出しや復元困難な見通し」 第3報発表（マイナビニュース TECH+）
• 「IDCFクラウド」障害で止まった「MTクラウド版」、「Googleクラウド」のバックアップで「さくらのクラウド」に移行へ（ITmedia NEWS）
• IDCFクラウド障害、別環境での再構築を案内 問われるクラウド停止への備え（日経クロステック）
• ベストプラクティス 8.3 - データ復旧メカニズムを確保して、脅威から保護する（AWS Well-Architected SAP Lens）