Summary

  • IDCFは10月7日からのランサムウェア攻撃で、東日本リージョン1の4ゾーンにある仮想マシンが停止し、再起動できなくなったと発表した。影響先は495の企業・自治体。攻撃者や侵入経路、IDCF Cloud Backupの状態は公表資料から確認できない。
  • 製品資料には別サイトへのバックアップとイミュータブルストレージの選択肢が記載されている。ただし、IDCFの管理画面が停止した状態で顧客がバックアップカタログへアクセスできるか、別環境に復旧先の計算資源があるかまでは示していない。
  • Six ApartはGoogle Cloud上のバックアップから31台をSakura Cloudへ移行し、Future Shopは二つの任意メールサービスを別データセンターで再構築した。いずれもIDCF Cloud Backupを使ったとは述べていない。

バックアップがあることと、業務を再開できることの間には、管理画面という運用上の関門がある。IDCFは10月8日の報告で、対象顧客に別環境の準備と顧客自身のバックアップからの再構築を案内した。一方、IDCF Cloud Storageの利用者には、IDCF Cloud Consoleが停止中でも、紐づくGoogleアカウントとプロジェクト情報があればGoogle Cloud Consoleから直接アクセスできるとFAQで説明している。

この案内はGCSベースのストレージについてのものだ。IDCF Cloud Backupとは別のサービスであり、FAQの「バックアップサービス停止」という一般的な記述がVeeamとWasabiを組み合わせたBaaSまで指すのか、どの顧客が対象なのか、影響顧客が契約していたのかは確認できない。GCSへの直接経路を、IDCF Cloud Backupの保管庫も使えた証拠に読み替えることはできない。

IDCFの第3報によると、事象は日本時間10月7日午前3時40分ごろに始まった。東日本リージョン1のtesla、henry、pascal、joule各ゾーンでは仮想マシンが停止し、再起動できなかった。同社はデータの取り出しや復元が難しい見通しとし、その時点では顧客が保有するバックアップからのみ復旧できると説明した。二次被害を防ぐため、対象リージョンのネットワークを遮断し管理コンソールを停止。ほかのリージョンでも安全性確認のため外部向けコンソールを止めた。

10月9日の第4報は、親会社SoftBankとの緊急対応体制、バックアップ・移行先に関する顧客案内、外部の専門家と進める技術調査を伝えたが、復旧結果は示していない。対応体制が立ち上がったことと、顧客のシステムが戻ったことは別の事実である。

IDCFは2025年3月、Veeamのサービスプロバイダー向けバックアップとWasabi Hot Cloud Storageを組み合わせたサービスを発表した。当時の料金は保護対象サーバー1台あたり月3,500円、保存量1GBあたり月5円。現在の製品ページはOSエージェント、増分バックアップ、別サイトへの保存、イミュータブル保存の選択肢、別サーバーへの復元を説明する。インターネット接続が必要で、ストレージは当時、東日本エリアで提供されていると記載されている。

利用ガイドではIDCF Cloud Consoleからサービスを始め、Veeam Service Provider Consoleへ進む。サービス範囲の資料には、IDCF Cloudユーザーと連携しないローカルのバックアップコンソール利用者も作成できるとある。IDCF側の利用者と別のIDを持てるのは有用な分離策になり得る。ただし、IDCFのポータル停止中にローカルユーザーが直接URLからログインできるのか、被災顧客のうち誰が設定済みだったのかは公開資料にない。「別サイト」も障害範囲の独立性を保証しない。サイト、リージョン、ゾーン、認証基盤、管理コンソール、復元先は、それぞれ別の条件だからだ。東日本エリアという表記だけで被災ゾーンとの重複も隔離も断定できない。

顧客の事例は、バックアップ料金に含まれない作業を具体化する。Six Apartは、10月7日午前1時時点のGoogle Cloud Storage上のバックアップを使い、31台のMovable Type Cloudサーバーを10月8日21時までにSakura Cloudへ移したと報告した。日次7世代を保持するサービスだった。選んだ復元点は、IDCFが公表した障害開始の2時間40分前だが、その間にどれほどの変更があったのか、別のログ等で差分を埋めたのかは公開されていない。Sakura Cloudは6月にすでに移行先プランとして発表されていた。それでも移行ではIPアドレスが変わり、仕様差や待ち時間が生じる可能性があった。この顧客固有の結果をIDCFの全利用者に当てはめることはできない。

Future Shopの場合、IDCFに置かれていたのは二つの任意メールサービスのMTAサーバーだけで、ECサイト本体と管理画面は別基盤だった。同社は別のデータセンターに新しい配信環境を構築し、10月9日12時20分にfuture Scenario Cast、12時30分にfutureCartRecoveryの配信を再開した。停止期間に予定されていたメールは自動再送されない。サーバーには宛先やメール本文の一部があり、氏名・誕生日・会員IDを含む可能性があった。保管時に暗号化され、14日で自動削除される仕組みだった一方、侵入開始時期と影響した可能性のある期間は未確定だった。メール配信の再開は、情報流出調査の完了を意味しない。

保護サーバー数と保存量で算定する料金は、守る容量を価格にする。だが復旧には、代替先の計算資源、データ転送、ネットワークやアドレスの変更、IDの回復、アプリの検証、再送できない顧客通知までかかる。実効性を確かめる演習は通常のポータルを止めるところから始めたい。独立した認証でカタログを開き、既知の復元点を選び、認証・課金・計算資源が停止中の画面に依存しない環境へ代表的なシステムを戻す。時間を測るのはコピーの完了までではなく、利用者にアプリを提供できるまでだ。

IDCF Cloud Backupが今回使われたのか、管理画面に入れたのか、影響顧客がそこにコピーを持っていたのかは、公開資料から分からない。従って本件を同サービスの失敗と結論づけることはできない。一方で、データのコピー、カタログへのアクセス、代替計算環境は別々の条件だと分かる。バックアップの市場価値は、購入者が備えようとした障害の中でも、その接続が保たれるかに左右される。

出典