IDCフロンティアのIDCFクラウド、4ゾーンの顧客情報「取り出し・復元困難」―自社バックアップから別環境へ再構築、495の企業・自治体に影響

株式会社IDCフロンティアは2026年10月8日、ランサムウェア攻撃によって障害が続く「IDCFクラウド」について、第3報を公表しました。影響を受けた東日本リージョン1の4ゾーンに保管された顧客データは、取り出しや復元が困難な見通しと説明しています。同社の現時点の見解では、データの復元は利用企業自身が保持しているバックアップから行う必要があります。

障害は10月7日午前3時40分頃から発生し、同社が影響範囲として公表したのはIDCFクラウドを利用する495の企業・自治体です。IDCフロンティアは対象利用者に、被害を受けた環境を再利用するのではなく、安全な別環境を用意して再構築するよう案内しています。

IDCFクラウドの障害・復元方針のサマリー

• 2026年10月7日午前3時40分頃、IDCFクラウドでシステム障害が発生。
• 10月7日付の第2報で、第三者によるランサムウェア攻撃と公表。
• 10月8日付の第3報で、対象を東日本リージョン1のtesla、henry、pascal、jouleの4ゾーンと明示。
• 影響範囲は契約する495の企業・自治体。全495組織のデータが消失したと確認されたものではない。
• 対象ゾーンでは仮想サーバーが停止し、再起動できない状態。
• 対象ゾーンにある顧客データは、取り出しや復元が困難な見通し。
• 同社は利用者自身が保持するバックアップデータからの復元と、別環境での再構築を案内。
• 他のゾーン・リージョンの利用者にもバックアップの取得を要請。
• 安全性確認のため他リージョンの管理コンソールを停止し、利用者の依頼に応じて仮想サーバー操作を代行。
• 侵入経路と詳細な影響範囲については外部専門家と調査を継続。

東日本リージョン1の4ゾーン、仮想サーバーが停止・再起動不可

IDCフロンティアは10月7日の第2報で、東日本リージョン1で発生した障害の原因がランサムウェア攻撃だったと明らかにしました。二次被害やデータ漏えいを防ぐため、同リージョンをネットワークから遮断し、システムを停止しました。

翌8日の第3報では、影響対象としてtesla、henry、pascal、jouleの4ゾーンを明示しています。対象環境ではクラウド上の仮想サーバーが停止し、再起動できません。

一方、東日本リージョン1内のradian、newtonと、東日本リージョン2・3、西日本リージョン1については、同社は第3報時点で不正アクセスを確認していないと説明しています。ただし、安全性を確保するため、これらの環境でも外部から利用する管理コンソールを停止しています。

顧客データは「取り出し・復元困難」―事業者側の復元を前提にできない

今回の第3報で大きく状況が変わったのは、IDCフロンティアが顧客データの復元見通しに踏み込んだことです。

同社は対象4ゾーンに保管されたデータの取り出し・復元は困難との見通しを示し、現時点では顧客が自ら保持するバックアップデータからのみ復元可能と判断しています。このため、対象企業には別の環境を準備したうえで、バックアップを用いてサービスを再構築するよう案内しています。

これは「495組織のデータ消失が確定した」という発表ではありません。4ゾーンのデータを従来のクラウド基盤から回収する見通しと、利用企業が外部に保存したバックアップを使って業務を再開できるかは別の問題です。また、保存データの暗号化状況や第三者への持ち出しの有無など、攻撃の詳細については調査が続いています。

通常の仮想サーバー再起動による回復が期待できない局面では、バックアップがどの場所・管理権限で保管され、別クラウドやオンプレミスなどへ実際に復元できるかが、事業継続を左右します。

他リージョンにもバックアップ取得を要請、管理コンソールは停止中

IDCフロンティアは、直接の侵害が確認されていないradian、newton、東日本リージョン2・3、西日本リージョン1の利用企業にも、自社データのバックアップを取得するよう案内しています。取得方法についても順次案内するとしています。

現在、利用者向け管理コンソールは安全性の確認のため停止しています。仮想サーバーの起動・停止などが必要な場合は、IDCフロンティアが利用者の要望に沿って操作を代行する対応です。管理画面が使えない状況で、利用者側が自由にインスタンス操作できるわけではありません。

同社は外部のセキュリティ専門企業と連携し、東西リージョンを構成するネットワーク、サーバー、ストレージを調査しています。監督省庁と警視庁への報告も実施しました。なお、「IDCFクラウド TypeS（旧ホワイトクラウド ASPIRE）」と「IDCFプライベートクラウド」は、今回の事象の対象外としています。

利用企業にも影響、同一クラウド上のバックアップが使えない事例

IDCFクラウドの障害は、利用企業のサービス停止へ波及しています。たとえば、ソリトンシステムズの「Soliton SecureDesktop」では、サービス基盤と同じ基盤で運用していたバックアップサーバーも利用できないことが公表されました。同社は安全性を確認した別の環境にサービスを再構築する方針です。

セキュリティ対策Labでは、Soliton SecureDesktopの停止と同一基盤上のバックアップが利用できない問題を個別に整理しています。また、電話、EC在庫管理、セキュリティ関連サービスなどへの波及状況は、IDCFクラウド障害による影響企業・サービス一覧にまとめています。

バックアップが存在していても、本番と同じ障害領域に置かれ、復元に必要な管理基盤まで停止すれば、すぐには業務を再開できません。一方、別の環境に復元可能なデータと構成情報を保管していた事業者は、元の基盤の復旧を待たず再構築を検討できます。

情報システム部門が確認したい復旧手順とデータ保護

今回の第3報を受け、対象企業では次の順序で復旧方針を具体化できます。

1. 対象環境を特定する。 使用リージョン・ゾーン、停止中のVM、ディスク、連携サービスと復旧優先順位を一覧化する。
2. 復元元を確認する。 バックアップがIDCF障害環境の外にあり、アクセス可能で、どの時点のデータまで戻せるかを確認する。業務上のRPO（許容できるデータ損失時間）を算出する。
3. 安全な再構築先を準備する。 侵害された構成をそのまま持ち込まず、OS、ミドルウェア、ネットワーク、IAM、証明書、DNSなどを再設計する。
4. バックアップの安全性を検査する。 復元元の取得時点、改ざん・マルウェア混入、漏れた可能性のある認証情報を調べ、必要な鍵・パスワードを更新する。
5. 復元と整合性確認を行う。 データベースと関連システムの整合、バックアップ取得以後の取引・受注データとの差分、外部連携先の再接続を検証する。
6. 代替手段と顧客連絡を整える。 復旧までの手動運用、停止サービスの告知、復旧見込みの更新、顧客データの影響調査を担当者ごとに割り当てる。

これらは企業側で検討できる一般的な復旧判断であり、IDCフロンティアがすべての利用者に同一手順を指示したものではありません。個別に通知された作業条件やフォレンジック調査上の注意事項がある場合は、そちらを優先します。

バックアップの安全性確認から別環境での復元までの進め方は、セキュリティ対策Labのランサムウェア感染時の初動対応・隔離・復旧手順でも整理しています。

出典

• 【第3報】当社サービスの一部システムへの不正アクセスによる障害について（2026年10月8日） – IDCフロンティア
• 【第2報】当社サービスの一部システムに対する不正アクセスについて（2026年10月7日） – IDCフロンティア
• IDCFクラウド バックアップサービスの仕様 – IDCフロンティア