IDCFクラウドのランサムウェア被害に学ぶバックアップ設計

こんにちは、ひろかずです。

IDCフロンティアの「IDCFクラウド」で発生した障害についてまとめてみましたので共有します。

忙しい人向けの要約

• 2026年10月7日午前3時40分頃、IDCフロンティアの「IDCFクラウド」東日本リージョン1で障害が発生し、同社は第2報で原因を第三者からのランサムウェア攻撃、影響範囲を契約する495の企業・自治体と公表しました。
• クラウド基盤側の侵害のため、利用企業が基盤そのものを直すことはできません。復旧の明暗を分けたのはバックアップの配置で、本番と同一基盤にバックアップサーバーを置いていたサービスは、復旧手段ごと使えなくなりました。IDCフロンティア自身も当初はデータの取り出し・復元を困難と見込んでおり、スナップショット機能を利用していた194社分の取り出しが可能と公表されたのは1週間後の第5報です。別事業者のクラウドにバックアップを保管していたサービスは、翌日には第三のクラウドへの移行を終えています。
• 警察庁の令和7年統計では、ランサムウェア被害組織へのアンケートで有効回答の9割がバックアップを取得していた一方、復元できたのは約2割にとどまると報告されています（統計編「バックアップ」・後述）。「取得しているか」ではなく「侵害時にアクセスできるか」が実効性を決めます。
• 組織として今やるべきことは、(1) 利用中のSaaS・委託先が依存するIaaS/データセンターの棚卸し、(2) バックアップの管理境界（同一基盤・同一権限で破壊可能か）の点検、(3) 復旧先を事前に決めておく出口設計、の3点です。
• 本記事は2026年10月19日時点の公表情報に基づきます。IDCフロンティアは第5報で、影響を受けた仮想サーバー内のデータについて外部への流出はなかったと判断しました。一方、利用者ポータルでは48社の登録情報への不正な照会が確認されています。侵入経路は公表されておらず、未確定事項は断定しません。

何が起きているの？

2026年10月7日午前3時40分頃、IDCフロンティアのクラウドサービス「IDCFクラウド」の東日本第1リージョンで障害が発生しました。同社は同日の第1報で原因を「第三者からの不正アクセス」と公表し、同日夜の第2報で第三者からのランサムウェア攻撃によるものと特定、影響範囲を「IDCFクラウドを契約している495の企業や自治体」と発表しました。二次被害やデータ漏えいを防ぐため東日本リージョン1をネットワークから遮断してシステムを停止し、侵入経路の特定と他リージョンの安全性確認を進めています。他リージョンについても、外部からアクセス可能な管理コンソールを安全確認のため一時停止しました。翌8日の第3報では、対象を東日本リージョン1の一部（tesla／henry／pascal／jouleの4ゾーン）とし、保管データの取り出しや復元は困難な見通しで「データの復元はお客さま自身が保持しているバックアップデータからのみ可能」との見解を示しました。

日本経済新聞は、影響を受けたのは福島県白河市のデータセンターで、茨城県庁などでホームページが閲覧できなくなったと報じています。piyologの整理によれば、IDCフロンティアの第1報は7日13時52分、ランサムウェア攻撃と公表した第2報は20時18分で、利用者側ではUDトークが9時32分の時点でIDCFクラウドを名指しして障害を公表していました。ベンダーの公表より利用者の公表が先行した形です。

SNS上では攻撃者側とみられる犯行声明画像が拡散していますが、そこに記載された被害規模の数値はIDCフロンティアが公表したものではないため、本記事では扱いません。10月14日の第5報では、外部のセキュリティ専門企業と連携した調査の結果、影響を受けた4ゾーンの仮想サーバー内データについて照会や外部への持ち出しの痕跡は確認されず、外部へのデータの流出はなかったと判断したと公表しました。一方、利用者が請求情報の確認などに使う「IDCFクラウドポータル」では、48社の登録情報に不正な照会が行われたことを確認しています（外部への持ち出しの痕跡は確認されず）。同報ではバックアップデータの安全性も確認され、スナップショット機能を利用していた194社についてバックアップデータの取り出しが可能になりました。ただし、194社すべての復元完了を発表したものではなく、復元の可否と提供方法は対象の顧客に個別に連絡するとしています。10月18日の第6報では、稼働を続けているゾーン・リージョンの利用者がバックアップを取得し、IDCFクラウド以外の環境へも復元できるよう「IDCFクラウド バックアップ」の提供を再開しました。被害を受けた4ゾーンの復旧完了を告知したものではなく、スナップショット機能は引き続き停止しています。侵入経路は10月19日時点で公表されていません。

情シスだけでなく、組織全体で取り組む必要がある

今回の事案の本質は、利用企業側に落ち度がなくてもサービスが止まり、しかも利用企業の側では基盤を直せないという点にあります。影響はIaaSを直接契約していた企業にとどまりません。IDCFクラウド上で提供されていたSaaSの利用者にも波及しました。シックス・アパートの「Movable Type クラウド版」では東日本第1リージョンのサーバー31台で管理画面と公開Webサイトが利用できなくなり、ソリトンシステムズのリモートアクセスサービス「Soliton SecureDesktop」も一部環境が停止しました。

自社が契約しているのはSaaSでも、その下にはIaaSがあり、データセンターがあります。契約書に書かれた相手の、さらに下のレイヤーが落ちたとき、自社の業務は止まるのか。止まるなら何日耐えられるのか。この問いに即答することは難しいです。

これはシステム部門だけの課題ではありません。やるべきことを役割ごとに分けて整理しておくと動きやすくなります。

組織として決めること（経営・事業部門が主導）

• どの業務が何時間止まったら事業として致命的か、という許容停止時間（RTO）の線引き
• 止まっている間の代替業務フロー（手作業・紙・代替サービス）を誰がどう回すか
• 利用クラウドやSaaSとの契約における責任分界点の確認と、委託先管理のルール整備
• 顧客・取引先・社内への説明窓口と、情報公開のタイミングの決め方
• 復旧性を高めるための投資（バックアップの分散、冗長構成、訓練の工数）の予算判断

業務・サービスを持つ部門と担当エンジニアチームが担うこと

• 自分たちの業務・サービスが依存しているクラウドやSaaSの把握と申告
• そのシステムのバックアップ構成と復旧先の設計・実装（管理境界をどこに置くかの判断を含む）
• 外形監視やベンダーの障害情報の収集と、関係部門への共有
• リストア手順の整備と訓練の実施、基盤が長期間戻らない場合の縮退運用の決定

情シス・セキュリティ部門が補佐すること

• 各部門からの申告を集約した全社の依存関係台帳の整備と可視化
• バックアップの管理境界や権限分離について、全社で満たすべき基準とチェック観点の提示
• 新規契約・委託先審査時のレビューと、設計内容へのリスク面の助言
• 訓練の企画支援と結果のレビュー、経営・監査への報告

バックアップと復旧の設計の当事者は業務とサービスを持つ側です。情シス・セキュリティ部門は横断的な基準と可視化を提供する立場に置き、三者が同じ地図を見ながら優先順位を決める必要があります。

よくある誤解

「クラウドだからバックアップは事業者がやってくれる」

バックアップの取得・保管・復元を誰が担うかは、サービスの仕様と契約によって異なります。今回のシックス・アパートのように提供側が別基盤にバックアップを持つ例もあれば、IDCFクラウドの第3報のように「お客さま自身が保持しているバックアップデータ」からの復元を求められる例もあります。事業者が提供する保護範囲と、自社で補うべき復旧手段を確認しておく必要があります。

「バックアップを取っているから戻せる」

警察庁サイバー警察局「サイバー空間をめぐる脅威の情勢等について（令和7年）」統計編の「バックアップ」によれば、バックアップの取得状況に有効回答した116件のうち105件（90.5%）がバックアップを取得していた一方、復元結果に有効回答した99件のうち復元できたのは20件（20.2%）にとどまります（件数は統計編の図表値、割合は件数から算出。同特集は「復旧を妨害するため、バックアップも一緒に暗号化される場合が多い」とも記しています）。取得と復元可能性は別物です。

「別リージョンに置けば安全」

条件付きでしか正しくありません。今回、IDCフロンティアは被害拡大防止のため、障害が発生していないリージョンの管理コンソールも一時停止しました。事業者の管理プレーン全体が防御的に停止される局面では、同一事業者内の冗長化だけでは復旧操作そのものができない時間帯が生じます。

実務で問題になりやすいポイント

今回の事案で復旧対応の明暗を分けたのは、バックアップの「場所」と「管理境界」

ソリトンシステムズは、本番サービスと同一基盤上で運用していたバックアップサーバーも利用できなくなったと公表し、安全性を確認した別基盤でのサービス再構築を準備しています。その後、同社が以前から運用している既設の環境へ移行して利用を再開する方法も案内しています。

• バックアップデータの消失が確認されたという発表ではありません

対照的に、シックス・アパートはすべてのサーバーのバックアップをIDCFクラウドとは異なるGoogle Cloudに7世代分保管しており、10月7日午前1時時点のバックアップデータを使って「さくらのクラウド」への移行を始め、第3報では、暫定対応として10月8日21時までに対象の全31台の移行を完了したと公表しています。

• 被害を受けたクラウドでも、バックアップ元のクラウドでもない、第三のクラウドで再開する判断です。

バックアップの実効性は、本番環境と「同じ障害で同時に失われない距離」があるかで決まる

同一基盤・同一管理者権限で削除や暗号化が可能なバックアップは、基盤侵害型のランサムウェアに対しては復旧手段として機能しない場合があります。実務では、スナップショットを「バックアップ」として扱っている構成、バックアップ削除権限が本番管理者と分離されていない構成が、監査や有事の際に問題になりやすいポイントです。今回、IDCフロンティアのスナップショットは事後の調査で194社分の取り出しが可能になりましたが、それが公表されたのは発生から1週間後の10月14日で、それまでは「取り出しや復元が困難な見通し」とされていました。復旧の初動で問われるのは、最終的に戻るかどうかより、すぐに使えるかどうかです。

もう一つの論点は検知

今回、利用者側の障害公表がベンダーの第1報より数時間先行しました。依存先の障害を「ベンダーからの連絡待ち」にしていると、自社の顧客への説明が後手に回ります。外形監視と、依存先ベンダーのステータス情報を能動的に確認する体制は、この種の事案では初動の速さに直結します。

技術的・運用的な確認ポイント

今回の事案を鑑みますと、次の順序で点検します。

1. まず依存関係の可視化

自社で利用中のSaaS・業務委託先ごとに、その稼働基盤（IaaS事業者・リージョン・データセンター）を確認します。ベンダーが公表していない場合は、セキュリティチェックシートや質問票で「利用IaaSと冗長構成」「バックアップの保管先が同一基盤か別基盤か」を確認しましょう。

2. 次にバックアップの管理境界

確認すべきは次の点です。

• バックアップが本番と同一のクラウド事業者・同一リージョン・同一管理基盤に閉じていないか
• 本番の管理者アカウントと同じ権限でバックアップを削除・変更できる構成になっていないか
• イミュータブル（変更不可）設定やオフラインコピーがあるか
• 別基盤のバックアップから実際にリストアする訓練を実施した実績があるか
• 復旧時に必要なDNS・証明書・構成情報・認証設定が、本番基盤の外からも取り出せるか

3. 最後に出口設計

シックス・アパートは、IDCFクラウドとは異なるIaaS基盤（Google Cloud）に全サーバーのデイリーバックアップを7世代分保管していました。IDCFクラウド上で復旧できる見込みがないと判断した上で、「さくらのクラウド」への移行に着手し、翌8日21時までに暫定対応として全31台の移行を完了したと公表しています。

復旧先を事前に決めていたかどうかは公表されていませんが、バックアップの保存場所は、どこへ復旧するかを前提に選ぶものです。復旧先を決めないまま保存場所を選ぶと、いざというときに戻せない組み合わせになりかねません。以下を平時に文書化しておく必要があるでしょう。

• 復旧先の候補環境
• IPアドレス変更やスペック差異の許容範囲
• 切り替え手順

移行にはIPアドレスの変更が伴い、仕様が従前と同一にならない場合があると同社も案内しています。完全復元ではなく「縮退して再開する」ことを前提に置くべきです。

対応方針の比較表

見直し時のチェックリスト（情シス・セキュリティ担当者向け）

• 利用中のSaaS・委託先サービスの稼働基盤（IaaS・リージョン・DC）を台帳化したか
• 各サービスが止まった場合の業務影響と許容停止時間（RTO）の定義を確認したか
• バックアップの保管先が本番と別のクラウド事業者・別の管理境界にあるか
• バックアップ削除権限が本番管理者権限と分離されているか
• イミュータブル設定またはオフラインコピーを少なくとも1系統持っているか
• 別基盤からのリストア訓練を年1回以上実施しているか
• 復旧先環境の候補と切り替え手順（DNS切り替え・証明書・IP変更）を文書化したか
• 依存先ベンダーの障害を自社で検知する外形監視・ステータス確認体制があるか
• ベンダー公表前でも顧客・社内へ第一報を出す基準を決めているか

経営層・監査部門への説明ポイント

経営層への説明ポイント

「ウチは大丈夫なのか？」に答える

経営層が知りたいのは、自社で同じことが起きたら事業がどれだけ止まるのかです。最初に伝えるのは、依存先の基盤への侵害は、自社のセキュリティ投資だけでは防ぎ切れない種類のリスクだという事実です。一方で、バックアップや代替環境への備えがあれば、停止期間やデータ損失は小さくできます。クラウド基盤1リージョンの一部ゾーンの侵害で495の企業・自治体に影響が及び、自治体のWebサイト閲覧不能や物流業務への支障が報じられました。

次に、自社の現状を重要業務ごとに以下2点を示します。この2点が分かっていない段階では、大丈夫とも危険とも答えられません。

• 依存しているクラウド・SaaSを把握できているか
• バックアップが本番と別の管理境界にあるか

その上で、経営層に決めてもらうことを明示する

許容停止時間（RTO）の線引き

ここは「何時間まで許容できますか」と聞くだけでは答えられません。重要業務ごとに「1日、1週間止まった場合の売上・受注の欠損、違約金や追加コスト、代替手段でいつまでしのげるか」を業務部門と概算で試算して添え、その数字を見ながら判断してもらいます。

依存先とバックアップ配置の棚卸し

情シスではやりきれない範囲なので、「対象は業務システムとSaaS全件、報告期限は1か月後、様式はこの台帳フォーマット」まで決めて持ち込み、経営層には期限の承認と、各部門へ回答を業務として指示することを依頼するのがいいでしょう。

別基盤へのバックアップ追加とリストア訓練にかかる費用・工数の承認

多くのケースで費用と工数の算出では、バックアップデータの保存期間に基づくデータ保管料やバックアップのリストア先環境を維持しておくことで生じるコストは見落とされがちです。リストア訓練にかかる費用なども見積もっておきましょう。

「対策済みです」と言って不安をいったん消すのではなく、これらの投資判断を支える説明をすることが求められます。

監査部門への説明ポイント

バックアップの「復元可能性の検証実績」を証跡として示せるか

警察庁統計で復元成功が約2割にとどまると報告されている以上、バックアップを「取得している」という回答だけではリスク低減の根拠になりません。別基盤リストア訓練の記録を残すことを推奨します。

実務担当者が次に取るべき対応ステップ

1. 【今週】利用中のSaaS・委託先に今回の事案の影響がないか確認する。影響がある場合は、復旧見通しと情報流出調査の状況を記録し、社内報告する。
2. 【今週】自社のバックアップ構成を確認する。本番と同一基盤・同一権限で破壊可能なバックアップしかない場合は、経営層にリスクとして即時報告する。
3. 【1か月以内】SaaS・委託先の依存基盤の棚卸しを開始する。新規契約時のチェックシートに「稼働IaaS」「バックアップ保管先の分離」を追加する。
4. 【3か月以内】別事業者クラウドまたはイミュータブル保管へのバックアップ系統追加を設計・予算化する。
5. 【6か月以内】別基盤からのリストア訓練と、依存先クラウド障害を想定した机上演習を実施する。

まとめ

IDCFクラウド事案は現在も調査中で、侵入経路はまだ公表されていません。確定を待つ必要がないのは自社側の点検です。まず、自社のバックアップが「本番と同じ障害で同時に失われる場所」にないかを今週中に確認してください。

次に、利用SaaSの依存基盤を棚卸しし、復旧先の出口設計に着手してください。バックアップは、基盤ごと失われた日にアクセスできるかで評価してください。

この記事が誰かの役に立てば嬉しいです。

FAQ

Q1. IDCFクラウドの障害の原因は何ですか？

A. IDCフロンティアは2026年10月7日の第2報で、第三者からのランサムウェア攻撃が原因と公表しました。侵入経路や手口の詳細は、2026年10月19日時点で公表されていません。

Q2. 影響範囲はどのくらいですか？

A. IDCフロンティアは、IDCFクラウドを契約している495の企業や自治体に影響が及んでいると公表しています。これは契約者数であり、情報漏えいの件数ではありません。

Q3. 個人情報は流出したのですか？

A. IDCフロンティアは10月14日の第5報で、影響を受けた仮想サーバー内のデータについて外部への持ち出しの痕跡は確認されず、外部へのデータの流出はなかったと判断したと公表しました。ただし、IDCFクラウドポータルでは48社の登録情報に不正な照会があり、うち2社では担当者の個人名を含む可能性があるメールアドレス（各1件）が対象でした（外部への持ち出しの痕跡は確認されず）。利用サービス側のデータについては、各サービスの公式発表を確認してください。

Q4. バックアップがあれば復旧できるのではないですか？

A. バックアップデータの配置場所次第です。本番と同一基盤上のバックアップは基盤侵害時に一緒に利用不能になり得ます。今回も同一基盤のバックアップサーバーが利用できなくなった事例と、別クラウド保管のバックアップで翌日までに移行を終えた事例の両方が公表されています。IDCフロンティアのスナップショットは、取り出し可能と公表されるまで1週間かかりました。

Q5. 自社はIDCFクラウドを使っていません。関係ありますか？

A. 利用中のSaaSや委託先がどのIaaS・データセンターに依存しているかを把握していなければ、同種の事案で同じ立場になり得ます。依存先の棚卸しは全社共通の課題です。

Q6. クラウド事業者の侵害に備えて何から始めるべきですか？

A. 今週中に着手するのは (1) バックアップの管理境界の確認です。続いて (2) SaaS・委託先の依存基盤の棚卸し、(3) 復旧先の出口設計と訓練へ進めます。全社的に点検する際の手順は、本文「技術的・運用的な確認ポイント」を参照してください。

Q7. 3-2-1ルールはクラウド時代でも有効ですか？

A. 有効ですが解釈の更新が必要です。「1つはオフサイト」を「本番と異なるクラウド事業者・異なる管理権限の下」と読み替え、イミュータブル保管を組み合わせることを推奨します。