IDCFクラウドの不正アクセスとランサムウェア被害｜利用者の初動と別基盤への復旧手順

IDCフロンティアは2026年10月7日、クラウドサービス「IDCFクラウド」の一部システムが第三者の不正アクセスを受け、東日本リージョン1で障害が起きたと公表しました。同日の第2報で原因はランサムウェア攻撃と判明し、影響は495の企業や自治体に及んでいます。10月8日の第3報では、一部ゾーンのデータは取り出しや復元が困難な見通しで、復元は利用者自身のバックアップからのみ可能と示されました。本記事では三つの報の差分を整理し、契約書面上の責任の線、影響を受けた利用者の初動、別の事業者へバックアップを逃がす手順と復元訓練を、実行できるコマンドで示します。

まとめ：IDCFクラウドの不正アクセスで確定した事実と利用者がいま取る行動

確定しているのは、10月7日午前3時40分頃に東日本リージョン1で障害が始まったこと、原因が第三者によるランサムウェア攻撃であること、影響が495の企業や自治体に及ぶことです。第3報では、teslaゾーン、henryゾーン、pascalゾーン、jouleゾーンに保管されたデータは取り出しや復元が困難な見通しとされました。侵入経路と情報漏えいの有無は、10月9日時点の公式発表では示されていません。

影響ゾーンの利用者が取れる道は、手元か別の事業者に置いたバックアップから別環境へ再構築することです。影響外のゾーンやリージョンの利用者も、事業者からバックアップの取得を案内されています。今回の事案から引き出せる教訓は一つです。同じ事業者の中に置いたバックアップは、事業者側が侵害されたときに頼りになりません。

公表内容を三つの報で確認する｜10月7日の障害発生から復元困難の見通しまで

第1報と第2報で判明した障害の範囲とランサムウェア攻撃という原因

10月7日の第1報は、一部システムへの不正アクセスにより東日本第1リージョンでサービスの一部に障害が出ていると伝える内容でした。同日夜の第2報で、原因が第三者からのランサムウェア攻撃であることと、影響が495の企業や自治体に及ぶことが加わっています。

第2報の時点で、同社は東日本リージョン1をネットワークから遮断したうえでシステムを停止しました。ほかのリージョンについても、利用者が外部からアクセスできる管理コンソールを安全確認のため止めています。被害の拡大を防ぐ措置ですが、利用者側から見れば、影響を受けていないリージョンでも仮想マシンの操作がしばらくできなくなったことを意味します。

第3報で示された4ゾーンのデータ復元困難と利用者のバックアップ頼み

10月8日の第3報は、対象を東日本リージョン1のteslaゾーン、henryゾーン、pascalゾーン、jouleゾーンと特定し、発生事象を仮想サーバーの停止と再起動不可と記しています。これらのゾーンのデータについては、取り出しや復元が困難な見通しで、復元は利用者自身が保持しているバックアップデータからのみ可能というのが同社の見解です。

同じリージョンのradianゾーンとnewtonゾーン、東日本リージョン2と3、西日本リージョン1では、不正アクセスは確認されていません。それでも同社はこれらの利用者にもバックアップの取得を案内しています。管理コンソールの停止中は、利用者の要望に応じて仮想サーバーの起動や停止を同社が代行する形です。なお、IDCFクラウド TypeSとIDCF プライベートクラウドは対象外とされています。

侵入経路と漏えいの有無について公表文から読み取れることと書けないこと

第3報によると、同社は外部のセキュリティ専門企業と連携し、東日本と西日本の両リージョンを構成するネットワーク、サーバー、ストレージを調べています。監督省庁と警視庁への報告も済ませています。侵入経路は調査中で、情報が外部へ持ち出されたかどうかには触れていません。

そのため本記事では、特定の脆弱性や製品、攻撃者グループに結び付けた推測は書きません。公表文から確実に言えるのは、利用者ごとの仮想マシンではなく、複数ゾーンにまたがる事業者側の基盤が被害を受けたという構図です。利用者のOSやアプリケーションの設定が原因ではない点は、後で触れる責任の線を考えるうえで押さえておく必要があります。

責任共有の線を契約書面で確かめる｜データ保管は利用者・SLA免責は外部攻撃

サービス提供条件に書かれた利用者データの帰属とバックアップの責任

IaaSの責任共有モデルでは、事業者が物理設備と仮想化基盤を、利用者がOSより上とデータを受け持つのが一般的な分け方です。整理の詳細はIaaSの責任共有モデルで扱っています。今回は事業者が受け持つ側の基盤が侵害されましたが、データが戻らない結果を引き受けるのは利用者です。

その根拠は契約書面にあります。IDCFクラウドのサービス提供条件は、構築したアプリケーション等のデータは利用者に帰属し、その保管は利用者の責任でバックアップなどを行うと定めています。免責事項には、利用者が登録したデータの改ざん、削除、滅失、消去等で生じた損害について同社は賠償責任を負わないとの記載です。他社のIaaSを使っている場合も、契約書面の同じ箇所を一度読んでおくと、自社が受け持つ範囲がはっきりします。

稼働率99.999%のSLAが外部からの攻撃を減額の対象外にしている意味

IDCFクラウドのSLAは、仮想マシンの月間稼働率99.999%以上を保証し、下回った場合は該当する仮想マシン費用の月額の10%を上限に減額します。ただし品質保証の対象外となる事由に「外部からの攻撃、妨害などによる場合」が含まれています。

SLAは稼働率に対する料金減額の約束で、データの損失を補う制度ではありません。仮に減額の対象になったとしても上限は月額の10%です。業務が止まった損失や、データを作り直す費用とは桁が違います。発注者が稼働率の数字だけで事業者を選ぶと、この差に気付けません。クラウド上の守りの分担はクラウドセキュリティと責任共有モデルでも整理しています。

同じ事業者の中に置いたスナップショットが今回は頼りにならない理由

多くの利用者は、同じクラウドのスナップショット機能やバックアップサービスで世代を残しています。ディスク装置の故障や利用者自身の誤操作には、これで十分な備えが可能です。ところが事業者の基盤そのものが侵害された場合、同じ管理基盤の下にあるバックアップも同時に使えなくなるおそれがあります。

第3報が影響外のゾーンの利用者にまでバックアップの取得を勧めたのは、この構図を事業者自身が認めた形です。事業者の管理基盤を経由した侵害として、さくらインターネットの不正アクセスも比較の材料になります。

影響を受けた利用者の初動｜別環境への再構築とAPIキー・連携の差し替え

手元のバックアップの時点と保管場所を最初に確かめる理由と順番

影響ゾーンの利用者が最初にやるのは、使えるバックアップがどこに、いつの時点で残っているかの確認です。同じIDCFクラウド内のスナップショットしかなければ、事業者の復旧を待つしかありません。別の事業者や社内に置いたものがあれば、そこが再構築の起点になります。

1. バックアップの保管先と最終取得時刻を一覧にする
2. 最終取得から障害までに失われた更新の範囲を業務側と突き合わせる
3. 再構築先の環境と、変わるIPアドレスの影響を受ける接続先を洗い出す
4. DNSの切替と取引先への連絡の順番を決める

二つ目の作業を飛ばすと、復旧後に「注文が数時間分消えている」といった問題が後から見つかります。失われた範囲は、取引先からのメールや決済代行の管理画面など、外部に残る記録から埋め戻せる場合があります。

別の事業者へ逃がしたバックアップで移行したシックス・アパートの例

Movable Type クラウド版を提供するシックス・アパートは、10月8日の第2報で、IDCFクラウド上の31台が影響を受けたと公表しました。同社は全サーバーの7世代分のデイリーバックアップを、IDCFクラウドとは別のIaaS基盤であるGoogle Cloudに保管していました。31台は10月7日午前1時時点のバックアップを使い、さくらのクラウドへの移行と復旧を順次進めています。

障害発生の約2時間40分前の時点まで戻せる位置にいたのは、保管先を事業者の外に分けていたからです。一方で、移行にはIPアドレスの変更が伴い、スペックが同条件にならない場合があるとも書かれています。バックアップがあっても、切替先の準備には時間がかかります。

周辺サービスのAPIキーやアカウント連携を差し替えて二次被害を防ぐ

影響は仮想マシンの外にも広がります。サーバー監視のMackerelは、10月7日17時30分ごろから、IDCF FreeプランとIDCF Free+プランのオーガニゼーションで発行済みのAPIキーによるアクセスと、IDCFクラウドアカウントによるログインを予防的に止めました。監視を続けるには新しいAPIキーを発行し、mackerel-agentの設定を差し替える必要があります。

同じ考え方は自社の構成にも当てはまります。IDCFクラウドのAPIキーを外部のCIや監視、バックアップの仕組みに渡していた場合は、管理コンソールの再開を待って再発行し、古いキーは無効にしてください。逆に、IDCFクラウド上のサーバーに置いていた他サービスの鍵やトークンも、漏えいの有無が公表されるまでは発行元で作り直すのが安全です。

別の事業者へバックアップを逃がす｜resticでS3互換ストレージへ取得する手順

バックアップ専用の保管先を事業者の外に置くときに決める三つの条件

保管先を選ぶときは、次の三点を満たしているかで判断します。本番と異なる事業者であること、本番サーバーの認証情報では消せないこと、定期的に戻せることを確かめていること。本番と同じ事業者の別リージョンでは、管理基盤が共通なら今回のような侵害の巻き添えを避けきれません。

二つ目の条件は、ランサムウェアがバックアップ自体を狙うことへの備えです。S3のObject Lockで削除を禁じる設定は佐賀大学のランサムウェア被害の記事で、仮想化基盤ごと暗号化された事例とバックアップ保管庫の守り方は大阪公立大学の事例で扱っています。本記事では、保管先の事業者を問わず使えるresticで取得側の手順を示します。

resticでリポジトリを作りファイルとデータベースを取得するコマンド

restic公式ドキュメントのリポジトリ準備に沿って、S3互換ストレージを保管先にする例です。resticの版はGitHub Releasesで2026年10月時点の最新が0.19.1で、0.19系を前提にしています。

# 保管先は本番と別の事業者のS3互換ストレージにする
export AWS_ACCESS_KEY_ID=<バックアップ専用のアクセスキー>
export AWS_SECRET_ACCESS_KEY=<シークレットキー>
export RESTIC_REPOSITORY=s3:https://s3.example-storage.jp/app-backup
export RESTIC_PASSWORD_FILE=/etc/restic/password

# 初回だけリポジトリを作る
restic init

# アプリケーションの設定とアップロード済みファイルを取得する
restic backup --tag app /etc/nginx /srv/app/shared

# データベースはダンプの終了コードで成否を判定させる
restic backup --tag db --stdin-filename production.sql \
  --stdin-from-command -- mysqldump --single-transaction appdb

# 日次7世代・週次4世代を残して古いものを削除する
restic forget --keep-daily 7 --keep-weekly 4 --prune

データベースの取得で--stdin-from-commandを使うのは、公式ドキュメントのバックアップの章が示すとおり、ダンプのコマンドが失敗したときにスナップショットを作らずに止めるためです。パイプで--stdinに渡す書き方では、ダンプが途中で失敗しても空のバックアップができてしまうことがあります。世代の残し方はforgetの章にある--keep-dailyなどで決めます。

本番サーバーに置く認証情報から削除権限を外しておく設計と見送る場面

上の例では、本番サーバーに保管先のアクセスキーが置かれます。サーバーが乗っ取られれば、攻撃者は同じキーでバックアップを消せます。保管先側でObject Lockなどの削除禁止を有効にするか、追記だけを許すrestic専用のサーバーを挟み、本番から渡すキーに削除権限を持たせない構成にしてください。forgetと--pruneは、本番とは別の管理用の端末から実行します。

この分離を入れるかどうかの線引きは、止まったときの損失で決めます。受注や予約など、失うと取引先に説明が必要なデータを扱うなら、別事業者への保管と削除権限の分離まで入れる価値があります。社内向けの情報共有サイトのように、数日止まっても紙や電話で回せる用途なら、そこまでは過剰です。その場合は別事業者への週次の取得だけを先に整えます。

復元訓練と切替の段取り｜restic restoreの実行とDNSのTTLを下げておく作業

リポジトリの整合性を確かめて実際に戻すまでのコマンドと所要時間

バックアップは、戻せることを確かめて初めて当てにできます。リポジトリ操作の章にあるcheckで中身を検証し、復元の章のrestoreで別のサーバーへ実際に戻します。

# 取得済みのスナップショットを確かめる
restic snapshots --tag db

# 保管データの10%を実際に読み出して壊れていないか検証する
restic check --read-data-subset=10%

# 本番とは別の検証サーバーへ最新を戻し、かかった時間を記録する
time restic restore latest --tag app --target /srv/restore-test

# データベースのダンプを取り出して検証用のDBへ流し込む
restic dump --path /production.sql latest production.sql | mysql restore_test

checkは既定では保管データの中身までは読みません。--read-data-subsetで一部を読み出すと、通信量を抑えながら壊れた部分を見つけられます。timeで測った所要時間は、そのまま復旧目標時間の見積もりの根拠になります。月1回、別事業者の検証サーバーで回し、数値を記録しておく運用が現実的です。復旧目標の決め方はDR対策の構成とRPO・RTOの目安で扱っています。

切替先へ向けるDNSレコードのTTLを確認して下げておく手順

別環境で再構築しても、利用者の接続先がすぐ切り替わるとは限りません。IPアドレスが変わる移行では、DNSのキャッシュが残る時間、つまりTTLの分だけ旧環境へ向かう利用者が出ます。現在の値は次のコマンドで確かめられます。

# 応答の2列目がTTL（秒）。86400なら最長1日は旧IPが参照される
dig www.example.co.jp A +noall +answer

TTLを短くしておくのは平時の作業です。障害が起きてから下げても、すでに長いTTLでキャッシュされた分は残ります。業務の入口になるレコードは300秒程度にしておくと、切替の判断から数分で利用者の向き先を変えられます。DNSの管理画面が障害を受けた事業者の中にある場合は、ドメインの管理自体を別の事業者へ分けておく判断も含めて検討してください。

本番の事業者を二つに分けるマルチクラウドを採るべき場面と採らない場面

事業者の侵害に備える最も強い手は、本番を二つの事業者で並行稼働させる構成です。ただし運用の手間と費用はおおむね倍になり、データの同期という新しい障害点も生まれます。数時間の停止が直接の売上損失や人命に関わる業務でなければ、並行稼働までは過剰です。

多くの企業にとって現実的なのは、本番は一つの事業者に置き、バックアップと再構築の手順だけを別の事業者に用意しておく形です。今回のシックス・アパートの対応は、この構成の具体例です。クラウドとオンプレミスの組み合わせも含めた判断はBCP対策の置き場所と責任分界が参考になります。別事業者での再構築手順やバックアップの設計を外部に任せたい場合は、AWS・Google Cloud・Azureのインフラ構築で切替先の設計から相談できます。

委託先や取引先の基盤が止まった企業の確認範囲｜報告と取引先への説明

自社が直接契約していなくても委託先の基盤経由で影響を受ける構図

今回の影響は、IDCFクラウドと直接契約している企業だけにとどまりません。ニッスイは10月7日の第1報で、日水物流が利用する委託先のデータセンターへの不正アクセスとみられる障害により、取り扱う商品の入出荷ができない状況だと公表しました。事業者名は示していません。

自社のシステムを外部の会社に保守してもらっている場合、どのクラウドで動いているかを発注側が把握していないことは珍しくありません。まず委託先に、稼働しているクラウド事業者とリージョン、バックアップの保管先を問い合わせて一覧にしてください。委託先を経由して被害が及ぶ構図はサプライチェーン攻撃の起点別の類型で、物流が止まった先例はニチレイのサイバー攻撃で整理しています。

個人データを預けていた場合の報告要否の判断と取引先へ伝える内容

現時点で漏えいの有無は公表されていません。ただ、顧客の個人データを保存したサーバーが影響ゾーンにあった場合、利用者である企業も報告の要否を判断する立場に置かれます。対象となる類型と、速報3〜5日・確報30日の期限は個人情報保護委員会への報告義務で確認できます。判断に迷う場合は、委員会の相談窓口や専門家に確かめてから動いてください。

取引先や利用者への説明では、止まっている機能、失われた可能性のあるデータの期間、復旧の見通しの三点を分けて伝えます。見通しが立たないなら、立たないと書き、次に知らせる日時を約束するほうが信頼を損ねません。被害の届出や相談先は、警察庁のランサムウェア被害防止対策のページにまとめられています。

よくある質問

IDCFクラウドの不正アクセスについて、利用者と発注者から出やすい質問をまとめました。

IDCFクラウドの影響を受けていないゾーンの利用者も対応が必要ですか？

必要です。第3報で不正アクセスが確認されていないとされた東日本リージョン1のradianゾーンとnewtonゾーン、東日本リージョン2と3、西日本リージョン1の利用者にも、同社はバックアップの取得を案内しています。管理コンソールが止まっている間は、仮想サーバーの起動や停止の代行を同社に依頼できます。取得したバックアップは別の事業者か社内に保管してください。

IDCFクラウドの障害で失われたデータは事業者に補償してもらえますか？

契約書面上は期待できません。サービス提供条件は、データの保管とバックアップは利用者の責任で行うと定め、データの滅失等による損害について同社は賠償責任を負わないとしています。SLAも外部からの攻撃による場合を減額の対象外にしており、減額があっても上限は月額の10%です。個別の対応は今後の発表と契約内容を確かめてください。

今回の不正アクセスで情報漏えいは起きていますか？

10月9日時点の公式発表では、情報漏えいの有無は示されていません。侵入経路も調査中です。同社は外部のセキュリティ専門企業と連携して調査を続けており、新たに公表すべき事実が判明した場合は速やかに知らせるとしています。自社のサーバーに置いていた鍵やトークンは、発表を待たずに発行元で作り直すのが安全です。

クラウドのスナップショットだけではバックアップとして足りませんか？

ディスク故障や誤操作への備えとしては有効です。ただし今回のように事業者の基盤そのものが侵害されると、同じ管理基盤の下にあるスナップショットも使えなくなるおそれがあります。最低でも一つの世代は、本番と別の事業者か社内に置き、本番サーバーの認証情報では消せない状態にしておくことを勧めます。

別のクラウドへ移行するとき最初に何を準備すればよいですか？

最初に用意するのは、別事業者に置いたバックアップと、それを実際に戻した記録です。戻すのにかかる時間が分かれば、移行の計画が立ちます。次に、変わるIPアドレスの影響を受ける接続先の一覧と、DNSのTTLを短くしておく作業です。シックス・アパートの例のように、スペックが同条件にならない場合もあるため、切替先の構成は平時に決めておきます。

関連記事

• さくらインターネットの不正アクセスと最大136万件｜管理基盤経由の侵害と利用者の点検手順：事業者側の基盤が起点になった同系統の事例
• 大阪公立大学のランサムウェア被害と仮想化基盤の停止｜全授業休講に至った経緯とバックアップを守る設定：仮想化基盤ごと止まったときのバックアップの守り方
• DR対策とは？構成4パターンのRPO・RTO目安とDR計画の作り方：別事業者への切替を計画に落とすときの土台
• システムバックアップとは？フル・差分・増分の違いと取得手順・方式の選び方を解説：取得方式と世代管理の基本
• サプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位：委託先の基盤から被害が及ぶ構図の整理