クラウドのデータは誰が守る?｜IDCF障害で見る責任共有モデル

「クラウドに置いてあるから、データは事業者がちゃんと守ってくれるはず」。そう思っていませんか。担当システムが止まったとき、データをどこから戻すのかを言えるでしょうか。

この記事では、IDCFクラウドの障害を例に、クラウドで「誰が何を守るのか」という責任共有モデルの考え方がわかります。結論から言うと、クラウドの基盤は事業者が守りますが、データのバックアップは利用者の仕事です。別の場所に自分のバックアップを持っているかが、復旧できるかどうかを分けます。

IDCFクラウドの障害で何が起きたのか

IDCフロンティアのクラウドが不正アクセスを受け、一部ゾーンのデータは取り出しや復元が難しい見通しになりました。

同社が2026年10月8日に出した第3報によると、障害は2026年10月7日の午前3時40分ごろに始まり、第3報の時点でも続いていました。原因は第三者からの不正アクセス(ランサムウェア攻撃)で、詳しい影響範囲や侵入経路は調査中とされています。ランサムウェアは、データを勝手に暗号化して使えなくし、元に戻す代わりにお金を求める不正なプログラムです。

影響を受けたのは、東日本リージョン1の4つのゾーン(tesla・henry・pascal・joule)です。仮想サーバーが止まって再起動できず、IDCFクラウドを使う495の企業や自治体に影響が出ています。なお、IDCFクラウド TypeS とIDCF プライベートクラウドは対象外です。ゾーンとは、同じ地域の中で分けられたデータセンターの区画のことです。

運用の目線で大事なのは、同社が現時点での見解として、データの復元は「お客さま自身が保持しているバックアップデータからのみ可能」と示した点です。対象ゾーンの利用者には、別の環境を準備しての再構築が案内されています。

つまり今回は、クラウドの中にあったデータを事業者の側からは戻せない見通し、という状況が現実に起きたということです。

責任共有モデルとは?クラウドの守備範囲の分け方

責任共有モデルとは、クラウドの安全を事業者と利用者で分けて受け持つという考え方です。

AWSの責任共有モデルの説明では、事業者が守るのは「クラウドのセキュリティ」、利用者が守るのは「クラウドにおけるセキュリティ」と分けています。事業者はハードウェアやソフトウェア、ネットワーク、サービスを動かす施設を守ります。利用者は、自分で入れたOSやアプリ、設定、そしてデータを管理します。

たとえるなら、クラウドは貸し倉庫のようなものです。建物の鍵や警備は倉庫会社が受け持ちます。でも、預けた荷物の写しを別の場所にとっておくのは、借りた人の判断です。

どこまでが利用者の担当かは、使うサービスで変わります。AWSの説明では、仮想サーバーを借りるIaaS(インフラを借りる形のサービス)の例としてAmazon EC2を挙げ、OSの更新やセキュリティの設定を利用者の担当としています。なお、これはAWSの考え方で、細かな分担は事業者ごとの規約や説明で確かめる必要があります。

まとめると、クラウドに置いても「データを守る責任」までは手放せない、というのが責任共有モデルの基本です。

責任共有モデルで見落としやすい「同じクラウド内のバックアップ」

見落としやすいのは、バックアップを同じクラウドの中にだけ置いているケースです。

同じ事業者の同じ地域にバックアップを置いていると、基盤ごと止まったときに一緒に使えなくなるおそれがあります。今回もIDCフロンティアは、不正アクセスが確認されていないゾーンやリージョンの利用者にも、データのバックアップを自分で取るよう案内しています。また、二次被害や被害の拡大を防ぐために、利用者向けの管理コンソールも止められました。管理コンソールは、サーバーの起動や設定をブラウザから操作する画面です。止めている間は、利用者の要望に応じて同社が仮想サーバーの起動や停止を代行しているそうです。

家のたとえでいえば、合鍵を同じ家の引き出しに入れているようなものです。家に入れなくなると、合鍵も取り出せません。

「バックアップを取っている」だけで安心せず、「事業者ごと止まっても取り出せる場所か」まで確かめる必要があります。

JPCERTの注意喚起から見る、利用者側の責任共有モデルの宿題

データの保全とあわせて、侵入されにくくする対策も利用者側の担当です。

JPCERT/CCは10月8日に、国内で相次ぐ不正アクセスへの注意喚起を出しました。ふだんから起きているランサムウェア攻撃などとは別に、2026年9月前後に相次いだ大量の個人情報の漏えいにつながる攻撃を取り上げたもので、IDCFの件を扱ったものではありません。既知の脆弱性をねらう攻撃や、APIへの不正なリクエストなどが報告されています。APIは、プログラム同士がデータをやり取りするための窓口です。

注意喚起では、推奨する対策として次のような点が挙げられています(一部を抜粋)。

• 既知の脆弱性がある版を使っていれば、修正済みの版へ更新する
• 業務に要らない管理機能がインターネットに出ていれば、公開をやめる
• 不正アクセスに気づく仕組みと、気づいたときの初動を見直す

クラウドの上で動かしている場合、どれも責任共有モデルでいう「利用者の担当」にあたります。BIツールや社内向けの管理画面も、同じように点検するよう勧められています。

筆者の考察:責任共有モデルを運用の現場で使う3つの確認

運用・監視の担当にとって大切なのは、自分のシステムで「事業者が止まったら何が残るか」を言えることです。

今回の障害は、ふだんの手順書では想定しにくい「事業者側が丸ごと使えない」状況でした。そこで筆者の見立てで、担当システムを3つの問いで見直す方法をまとめました。公式の手順ではないので、目安として使ってください。

確認すること	答えが「いいえ」のときの危うさ
バックアップの写しが、別の事業者か別の地域にあるか	基盤ごと止まると、写しも取り出せない
管理コンソールが使えなくても、データを取り出す手段があるか	画面が止まった時点で手が出せなくなる
別の環境に作り直す手順が、書き出されているか	設定がサーバーの中にしかなく、再構築に時間がかかる

1〜3年目の担当でも、手順書や設定画面を読めば3つとも調べられます。答えが「わからない」なら、それ自体が先輩に聞く理由になります。

とくに3つ目は見落とされがちです。サーバーの設定を手で変えてきた環境ほど、作り直すときに「元の形」がわからなくなります。手順を書き出しておくと、事業者を変えるときにも役立ちます。

バックアップの置き場所の考え方は、ランサムウェアはバックアップも狙うで詳しくまとめています。被害に気づいた直後の動き方は、インシデント初動で新人がやる5つのことも読んでみてください。

まとめ:責任共有モデルでデータを守るのは利用者

• IDCFクラウドの障害では、一部ゾーンのデータは利用者のバックアップからのみ戻せると案内された
• 責任共有モデルでは、基盤は事業者が、データや設定は利用者が守る
• バックアップは「事業者ごと止まっても取り出せる場所」にあるかまで確かめる

まずは担当システムのバックアップが、どの事業者のどの地域にあるのかを調べてみましょう。

参考リンク

• 【第3報】当社サービスの一部システムへの不正アクセスによる障害について(IDCフロンティア) ― 2026年10月8日
• 直近で相次いでいる国内組織における不正アクセスに関する注意喚起(JPCERT/CC) ― 2026年10月8日
• 責任共有モデル(AWS)
• IDCFクラウドの障害、データは「取り出しや復元が困難な見通し」(Impress Watch) ― 2026年10月8日