「バックアップは取っています」。はい、それで椅子に深く座るのは、まだ少し早い。次に聞くべきは、そのバックアップを消せる鍵が、本番環境の鍵と同じかどうかです。

IDCフロンティアの東日本リージョン1がランサムウェア攻撃を受け、企業や地方自治体495組織が影響範囲に入りました。ただし、495組織すべてがデータを失ったと確認されたわけではありません。今回考えたいのは、コピーが存在しても、本番と同じ管理者IDや制御画面から触れれば、なぜ攻撃時に共倒れしうるのか、という一点です。

IDCFクラウドへのランサム攻撃、495の企業・自治体に影響　一部には「復元難しい」との通達も
IDCFクラウドへのランサム攻撃、495の企業・自治体に影響　一部には「復元難しい」との通達も

ソフトバンク子会社のIDCフロンティアは10月7日、法人向けクラウドサービス「IDCFクラウド」で起きている障害について、第三者によるランサムウェア攻撃が原因だったと明かし、影響範囲は495の企業・自治体に及ぶと発表した。これを受け、同日朝から利用企業によるサービス停止や一部機能の不具合の公表が相次いでいる。

今回の登場人物 ​

  • IDCフロンティア（IDCF）: 企業や自治体にサーバー、ストレージ、ネットワークなどのクラウド基盤を提供する事業者です。本文では略してIDCFと表記します。
  • 東日本リージョン1: IDCFがクラウドサービスを提供する区域の一つです。一台のサーバー名でも、日本の東半分全体という意味でもありません。
  • ランサムウェア: データやシステムを使えなくし、復旧などと引き換えに金銭を求める攻撃です。ファイルだけでなく、管理者の認証情報やバックアップも狙われます。
  • 管理境界: 同じ認証情報、管理者権限、管理画面、プログラムから操作するための接続口（API）などで触れられる範囲です。物理的な距離より、「同じ鍵で触れるか」が問題になります。
  • バックアップ／レプリカ: バックアップは過去へ戻すための独立した控え。レプリカは現在の状態を別設備へ追従させる複製です。似ていますが、担当する仕事が違います。
  • イミュータブル／オフライン: 一定期間は変更・削除できない保存と、通常時は本番から接続できない保存です。最後の控えを攻撃経路から遠ざけます。

何が起きたか ​

ITmedia NEWSによると、IDCフロンティアの東日本リージョン1で、2026年10月7日午前3時40分ごろから障害が発生しました。IDCFは当初、不正アクセスと発表し、その後、第三者によるランサムウェア攻撃だったと公表しました。

公式発表で影響範囲とされたのは、東日本リージョン1を利用する契約企業・地方自治体495組織です。IDCFは二次被害や情報流出を防ぐため、同リージョンのネットワークを切断し、システムを停止しました。他リージョンでも、安全を確認するため外部向け管理コンソールを止めています。

ここは、いったん数字を机の上に並べて、丁寧に分けましょう。サービスが使えない理由には、攻撃による暗号化や破壊だけでなく、被害を広げないための予防停止も含まれます。495は「影響範囲の契約組織数」であり、495件のデータ消失を意味しません。数字は同じでも、意味まで同じとは限らないんです。侵入経路も、公表時点では特定と遮断の作業中です。

個別には、UDトークの公開会話や管理機能などが停止しました。一方、端末単体の音声認識は利用可能でした。UDトーク側は、IDCFから「データの復元は難しい」と連絡を受けたと説明していますが、これは同サービスへの個別連絡です。東日本リージョン1の全利用者について、復元が難しいとIDCFが公式発表したわけではありません。

Six ApartのMovable Typeクラウド版では31サーバーが利用不能になりましたが、同社は障害前のバックアップを別のクラウド基盤に保管しており、そのデータを使った復旧準備を進めると発表しました。

別の場所より、別の鍵 ​

さて、本題です。いや、ここがミソなんですよ。ランサムウェアに強いバックアップを分けるのは、サーバー同士の距離だけではありません。本番を操作する認証情報や管理画面から、バックアップを削除できないことが大切です。

たとえば、本番データを東京、バックアップを大阪に置いたとします。地震や火災、設備故障への備えとしては、とても意味があります。でも、ちょっと待って。東京も大阪も同じ管理者IDで操作でき、そのIDに削除権限まであったらどうでしょう。攻撃者がそのIDを奪えば、画面を切り替えるだけで両方へ手が届きます。

離れた二つの金庫でも、同じマスターキーで開くなら、攻撃者には一つの鍵束に見える。これが管理境界の問題です。

共有されうるのはIDだけではありません。会社全体の認証基盤、クラウドの管理コンソール、バックアップ製品の管理画面、プログラムから操作するAPI、暗号鍵、復旧を承認する手順。どれか一つを突破すると本番とバックアップの両方を変更できるなら、物理的に離れていても論理的には同じ部屋です。

米国のサイバーセキュリティ当局CISAも、ランサムウェア攻撃者がアクセス可能なバックアップを探して削除・暗号化し、バックアップシステムへ入るための認証情報を狙うと注意しています。復旧手段を先に壊せば、被害側の選択肢を減らせるからです。嫌なところをよく見ています。攻撃者に感心している場合ではありませんが、防御側も同じ目線で経路を洗う必要があります。

ただし、今回のIDCF利用者のバックアップが、実際にどの管理境界へ置かれていたかは公表されていません。全495組織のバックアップが同じ権限で消された、とは書けません。この障害は「共倒れが起きた証明」ではなく、「共倒れを防ぐ設計を考える必要がある」と突きつけた出来事として読むのが正確です。

コピーの数だけでは守れない ​

ここで、よく似た三つを整理します。名前が似ているので、玄関に同じ色の傘が三本並んでいるようなものです。役目まで同じだと思うと、取り違えます。同期レプリカは、本番の最新状態を別設備へ素早く写します。機器が一台壊れたときに切り替えるには頼もしい。でも、本番で大量のファイルが暗号化された状態まで同期すれば、壊れた最新状態が二つできることがあります。

スナップショットは、ある時点の状態を保存する機能です。過去へ戻れるので便利ですが、同じ管理者権限で削除できるなら、攻撃者にもまとめて消されます。バックアップも、同じネットワークへ常時接続され、同じ特権IDで変更できれば同様です。データが二つあることと、復元手段が二つあることは、似ているようで別なんですね。

基本になるのが「3-2-1」です。データを合計3部持ち、2種類の媒体へ置き、そのうち1部を別の場所へ保管する。ただし、合鍵を三つ作って全部同じキーボックスに入れたら、箱ごと持っていかれます。ランサム対策では、数と場所に加えて、管理の鍵も分けなければなりません。

そこで登場するのが、イミュータブルとオフラインです。イミュータブルは、決めた保持期間中は通常の管理操作でも変更・削除しにくくします。オフラインは、バックアップするとき以外は本番のネットワークから切り離します。独立したアカウント、多要素認証、必要最小限の権限、別管理の暗号鍵と組み合わせて、攻撃者が一つの足場から全部へ届く道を断ちます。

IDCF自身も、通常のクラウド基盤とは別ロケーションのストレージへ保存し、任意でイミュータブル設定を使える専用バックアップサービスを提供しています。ただ、今回影響を受けた利用者がこのサービスを使っていたか、このサービス自体に影響があったかは発表されていません。「IDCFのバックアップ製品も突破された」と想像で埋めてはいけないところです。

復元できて初めてバックアップ ​

もう一つ、見落としやすい話があります。ここで「データが残った、では復旧完了」と席を立つのは早いんです。バックアップファイルが残っていても、サービスがすぐ戻るとは限りません。

業務システムはデータだけで動いていません。コンピューターの土台になる基本ソフト（OS）、アプリの設定、利用者情報、暗号鍵、他サービスとの接続、起動する順番がそろって初めて動きます。バックアップが壊れていないか、どの時点まで戻せるか、何時間や何日で復旧できるかも確かめる必要があります。

だから日本の情報処理推進機構（IPA）や米国のCISA、英国のサイバーセキュリティ当局NCSCは、バックアップの保管と一緒に復元テストを勧めています。非常口の札が立派でも、本番の日に扉が開かなければ困りますよね。定期的に実データを戻し、担当者が手順を実行できるかまで試して、ようやく「使えるバックアップ」です。

Six Apartが別のクラウド基盤にバックアップを置いていたことは、元の基盤が止まった後にも復旧経路を残した具体例です。ただし、発表時点では復旧準備中でした。別基盤へ置けば一瞬で全サービスが戻る、という話でもありません。

責任分界という宿題 ​

ここで話は、誰がどこを守るのかに移ります。クラウドでは、どこまでを事業者が守り、どこからを利用者が管理するかという「責任分界」があります。IDCFの説明では、データセンター、バックボーン、クラウド基盤はIDCF側。仮想マシンを起動した後のOS、アプリ、データは利用者側の管理範囲です。

重要事項説明書でも、利用者が同じデータをバックアップとして保存し、復旧手順を決め、訓練やテストをする必要性を示しています。「クラウドに置いたから、誰かが全部戻してくれるはず」ではないわけです。

ただし、これを今回の責任判定へ直結させてはいけません。責任分界は日常の役割表であって、事故の法的責任や過失割合を一枚で決める表ではありません。侵入経路も、事業者側と利用者側の具体的な設定も分からない段階です。被害を受けた組織へ「備えが足りなかった」と石を投げるのは、調査ではなく早押しクイズになってしまいます。

それで何が変わるのか ​

では、自社の備えを見直すなら何を聞くか。最初の質問は「バックアップは何個あるか」だけではありません。本番管理者のIDでバックアップを消せるか。会社の認証基盤が止まった後もバックアップ管理画面へ入れるか。暗号鍵は別に守られているか。削除や保持期間の変更には、別の人や別の経路による承認が必要か。ここを確かめます。

そのうえで、オフラインまたはイミュータブルな世代を残し、異常な削除を別経路で通知し、定期的に復元する。障害時に普段の社内メールが使えない場合に備え、連絡先や手順も別に持つ。製品を買って終わりではなく、攻撃された状態を想定して道具を並べ直す作業です。

個人にも無関係ではありません。パソコンのフォルダをクラウドへ同期していても、誤削除や暗号化がそのまま同期されることがあります。世代履歴があるか、別媒体の控えがあるか、その控えを普段は切り離せるか。一度見ておくと、写真や文書を守る力が変わります。

まとめ ​

バックアップは、コピーが存在するだけでは十分ではありません。本番を乗っ取った攻撃者が、同じID、管理画面、API、暗号鍵でバックアップも削除できるなら、一緒に失う可能性があります。大切なのは、場所だけでなく管理の鍵を分けることです。

今回の495組織は影響範囲であり、すべてがデータを失ったという意味ではありません。それでも、自分たちの最後の控えが本番と同じ鍵束にぶら下がっていないかを確かめる理由にはなります。バックアップの値打ちは、何個あるかだけでなく、本番の鍵を奪われても最後の一個が残るかで決まるんです。

Sources ​