【第7報】IDCFクラウド不正アクセスの調査完了｜原因はOSSの脆弱性、データ流出は確認されず

IDCフロンティアは2026年10月27日、クラウドサービス「IDCFクラウド」への不正アクセスについて第7報を出し、一連の調査が完了したと公表しました。原因は、利用者向けの管理画面「IDCFクラウドポータル」の認証システムで使っていたオープンソースソフトウェアの脆弱性です。

ランサムウェア攻撃で、東日本リージョン1の一部を使う495の企業・自治体の仮想サーバーが停止し、暗号化されました。一方で、仮想サーバー内のデータが外部へ流出した事実は確認されなかったとしています。この記事では、第7報で分かったことを整理します。

第7報のポイント
認証システムへの侵入から、仮想サーバーの暗号化まで
データの流出はなし、ポータルの登録情報は最大71社が不正に照会された
10月7日未明に発生、20日間で調査完了
ポータルは3段階で再開、当面は操作をIDCFが代行
再発防止策：セキュリティの独立組織とSBOMによる一元管理
公表内容から読み取れること（考察）
問い合わせ先
まとめ
関連記事

第7報のポイント

原因は、IDCFクラウドポータルの認証システムで使っていたオープンソースソフトウェアの脆弱性
攻撃を受けたのは東日本リージョン1の4ゾーンで、対象は495の企業・自治体
仮想サーバー内のデータの外部流出は確認されず、二次被害も現時点で確認されていない
ポータルの登録情報への不正な照会は最大71社に拡大（第5報では48社）。うち最大31社（31件）に個人名などを含む
ログインパスワードが最大4件、不正に変更されていた（リセット済み）
バックアップデータを取り出せる利用者は206に増えた（第5報では194）
攻撃者とは接触しておらず、身代金の支払いや交渉は一切していない

IDCFクラウド TypeS（旧：ホワイトクラウド ASPIRE）とIDCF プライベートクラウドは、今回の対象外です。

認証システムへの侵入から、仮想サーバーの暗号化まで

IDCFクラウドポータルは、利用者が仮想サーバーの起動や請求情報の確認などに使う管理画面です。第7報によると、攻撃は次の流れで進みました。

ポータルの認証システムで使っていたオープンソースソフトウェアの脆弱性を突き、認証システムに侵入
管理コンソールを経由して、仮想化基盤の管理者権限を不正に取得
利用者の仮想サーバーを停止し、仮想サーバーそのものを暗号化

攻撃を受けたのは、東日本リージョン1のteslaゾーン・henryゾーン・pascalゾーン・jouleゾーンです。脆弱性があったソフトウェアの名前は書かれていません。

データの流出はなし、ポータルの登録情報は最大71社が不正に照会された

第7報では、仮想サーバー内のデータと、ポータルに登録された情報を分けて説明しています。

対象	調査結果
攻撃を受けた4ゾーンの仮想サーバー内のデータ	外部への持ち出しを示す痕跡や、それを裏付ける事実は確認されていない
影響を受けていないゾーン・他のリージョン	安全性の調査を実施し、データの外部流出を示す事実は確認されていない
IDCFクラウドポータルの登録情報	最大71社の登録情報に不正な照会。うち最大31社（31件）に、個人名や個人名を含む可能性があるメールアドレスなどが含まれる。外部への持ち出しを示す痕跡は確認されていない
ログインパスワード	最大4件が不正に変更されていた。すでにリセットし、対象の利用者に個別に連絡済み

第7報では、不正な照会の対象を、IDCFクラウドを利用する「お客さま」（契約企業）の登録情報と説明しています。情報の不正利用などの二次被害も、現時点では確認されていないとしています。

10月7日未明に発生、20日間で調査完了

日時	主なできごと
10月7日 3時40分ごろ	仮想サーバーの停止・再起動ができない障害が発生し、検知
10月7日 6時48分〜7時	東日本リージョン1のポータルを停止し、影響のある4ゾーンのストレージ機器を切り離し
10月7日 11時42分	原因を第三者からのランサムウェア攻撃と特定
10月7日 12時15分〜14時5分	他リージョンのポータルも停止し、全リージョンのポータルと外部をつなぐネットワークを遮断
10月8日〜10日	緊急対応窓口を設置。代替環境と移行手順の案内を開始
10月14日	仮想サーバー内のデータの外部流出はなかったと判断。48社の登録情報への不正な照会が判明
10月17日〜18日	バックアップデータの引き渡しを開始。バックアップサービスの提供を再開
10月20日	206の利用者のバックアップデータを取り出せることが判明
10月27日	不正な照会が最大71社に及ぶことが判明。一連の調査が完了

ポータルは3段階で再開、当面は操作をIDCFが代行

IDCFクラウドポータルは、安全性を確保できるまで停止を続けます。再開に向けて、新しい環境での再構築、すべてのサーバーの認証情報の変更、認証システムの外部IdP（Identity Provider：認証を専門に担う事業者）への切り替え、接続元IPアドレスの制限と多要素認証の必須化を進めています。

段階	内容
第1段階（実施中）	主要な機能の操作をIDCFが代行。仮想サーバーの起動・停止、セキュリティ設定やネットワーク設定の変更、データベースの起動・停止など
第2段階	すべての機能の操作をIDCFが代行。仮想サーバーの作成・削除や性能の変更、スナップショット機能の利用など
第3段階	ポータルの全機能を、利用者が自分で操作できる状態で再開

各段階に移る時期は示されていません。

再発防止策：セキュリティの独立組織とSBOMによる一元管理

外部の専門家と社内のセキュリティ人材を集め、セキュリティを専門に管理する独立組織を設置（対応済み）
脆弱性診断の計画と頻度を規程で定め、ソフトバンクの「Patching as a Service（PaaS）」なども使って、診断の対象をオープンソースソフトウェアにも広げる
部署ごとに管理していたソフトウェアの構成情報を全社で一元管理し（SBOM化）、脆弱性情報との突き合わせを自動化する

SBOMは、ソフトウェアを構成する部品やバージョンを一覧にしたものです。どの製品にどの部品が入っているかを把握しておけば、脆弱性が公表されたときに影響を受ける箇所をすぐに特定できます。

公表内容から読み取れること（考察）

ここからは、公式発表をもとにした筆者の考察です。

今回の攻撃は、利用者が使う管理画面の入り口から侵入し、仮想化基盤の管理者権限まで到達しています。個々の仮想サーバーの設定ではなく、基盤側で仮想サーバーごと暗号化されたため、利用者側の対策では防ぎにくい被害だったといえます。再発防止策に、ポータルへの接続元の制限と多要素認証の必須化が入っているのは、入り口そのものを絞る狙いだと考えます。

一方、バックアップデータを取り出せるのは495のうち206の利用者にとどまります。第5報の時点では、取り出せるのはスナップショット機能を使っていた194の利用者と説明されていました。残りの利用者は、代替環境でシステムを作り直す必要があるとみられます。クラウド上のシステムでも、サービスの外にバックアップを持っておく重要性があらためて示されたと考えます。