クラウドの仮想サーバーを更新し、ウイルス対策もしている。それでも、サービス提供者の管理基盤が侵害されれば、自分のサーバーが停止・暗号化される可能性があります。
IDCFクラウドの事例で確認したいのは、「利用するサーバーの安全」と「そのサーバーを管理する仕組みの安全」は別だという点です。利用者側で管理するアカウントを保護するとともに、事業者側の管理基盤が停止した場合に、どこからデータを戻すかまで確認する必要があります。
まず、自組織のクラウドについて、管理者アカウント、バックアップの保存先、復元を依頼する窓口を一枚に整理してください。普段の管理画面に入れなくても復旧作業を始められるかが、点検の出発点です。
2026年11月3日までに確認した公表資料に基づく技術解説です。一般的な対策例は、当該組織の未公表構成を示すものではありません。
何が起きた？ 顧客サーバーの手前にある管理基盤への侵入
IDCフロンティアの10月27日付第7報によると、IDCFクラウドポータルの認証に使うOSSの脆弱性から侵入されました。攻撃者は管理コンソールを経由して仮想化基盤の管理者権限を取得し、顧客の仮想サーバーを停止・暗号化しました。影響は495の企業・自治体です。［1］
一方、同社は仮想サーバー内データの外部流出はなかったと判断しています。登録情報の不正照会とは区別して読む必要があります。206の顧客でスナップショットのバックアップデータを取り出せるとしていますが、全顧客が復旧済みという発表ではありません。［1］
この事件で利用されたOSSの製品名やCVE番号は、今回確認した発表では分かりません。特定の製品や、利用者側の設定ミスを原因と決めつけることはできません。
「管理基盤」は、たくさんのサーバーを動かす操作室
仮想サーバーは、一台の物理機器の中などで動く、ソフトウェアで作られたサーバーです。利用者はその中のOSや業務アプリを使います。これに対し、管理基盤は仮想サーバーの作成、停止、ディスクの割り当てなどを扱います。
建物で考えるなら、利用者のサーバーは各部屋、管理基盤は各部屋の電源や設備を操作する管理室です。部屋の鍵を守ることに加えて、管理室に入れる人と操作できる範囲も守らなければなりません。
自社運用でも、仮想化基盤、NASの管理画面、バックアップ管理サーバーなどに同じ視点を当てられます。「一般職員は使わないから安全」ではなく、侵害されたときに何台へ影響するかで重要性を考えます。
以下は一般的な点検例です。IDCFでこれらの不備がすべて存在していたという説明ではありません。
| 点検対象 | 確認すること |
|---|---|
| 管理画面 | インターネット全体から接続可能か。接続元を限定できるか。 |
| 管理者 | 通常業務と別のアカウントか。多要素認証を使えるか。 |
| 権限 | 閲覧だけの担当者にも削除・停止の権限を与えていないか。 |
| 保守業者 | 使うアカウント、接続元、利用期限が把握できているか。 |
| 記録 | 管理者の追加、認証設定の変更、削除操作を追えるか。 |
OSSは「無料だから危険」ではなく、使っている部品を把握する
OSSはソースコードが公開されたソフトウェアです。有償製品にも組み込まれており、OSSであること自体が今回のような被害の説明になるわけではありません。
管理者として困るのは、脆弱性が公表されたときに「自分の環境で使っているか分からない」状態です。製品名だけでなく、内部のライブラリーや認証部品まで情報をたどれるよう、ベンダーへの確認経路を作ります。
たとえば、資産台帳には製品・バージョン・保守窓口・更新担当を記録します。自社開発があれば、部品一覧であるSBOMを調達先へ確認することも考えられます。ただし、一覧を受け取るだけでは対策になりません。脆弱性が見つかった際、対象判定、更新、確認まで誰が進めるかを決めておきます。
IPAも、外部公開アプリや利用サービスを把握し、未適用の更新やログの異常を確認するよう求めています。［2］
スナップショットがあれば、別のバックアップは不要？
スナップショットは、ある時点のディスクなどの状態を記録する仕組みです。短時間で状態を戻す用途に便利ですが、保存方法や本番環境への依存はサービスによって違います。
「スナップショット」という名前だけで安全性を判断せず、保存場所、管理権限、削除の制限、取り出す方法を確認してください。同じ管理者が本番と保存済みコピーを両方削除できるなら、そのアカウントの侵害にも備えが必要です。
ここでいう分離は、別のフォルダーに置くことだけではありません。同じ障害や同じ資格情報で、まとめて使えなくならないかを考えることです。保存先を変えても管理権限が共通なら、削除のリスクが残る場合があります。
バックアップを選ぶ際は、「削除不能な期間を設定できるか」「本番用アカウントから書き換えられないか」「管理画面が停止していても取り出せるか」を事業者に質問します。これらは一般的な選定項目で、必要な機能は扱うデータと復旧目標によって変わります。
復旧できるかは、ファイルが存在するだけでは分からない
復旧時には、データだけでなく、アプリの設定、ライセンス、DNS、証明書、接続先情報なども必要になることがあります。データベースなら、整合性を保った状態で戻せるかも確認します。
担当者が明日実施するなら、小さな検証環境で一つの業務を戻す練習が現実的です。「取得成功」の通知を見る作業と、復元したデータをアプリで開く作業は分けて実施します。個人情報を含むデータの扱いは、通常の権限管理や保管ルールに従います。
| 決める項目 | 業務担当と相談する内容 |
|---|---|
| どこまで戻すか | 何時間・何日前の状態までなら業務を再開できるか。 |
| いつまでに戻すか | 停止できる時間と、代替手段で耐えられる時間。 |
| 何から戻すか | 認証、ファイル、業務アプリなどの依存関係。 |
| 誰が判断するか | 再開の承認者、事業者への連絡担当、代行者。 |
バックアップ担当へ、そのまま確認できる三つの質問
一つ目は「普段の管理者アカウントを使えなくした場合、復元できますか」です。強い権限のアカウントを停止すると、バックアップ管理にも入れなくなる構成なら、緊急時のアクセス方法と保管場所を整理しておきます。復旧用のアカウントを作る場合も、必要な人だけが使えるよう管理し、通常業務へ流用しません。
二つ目は「保存先を削除する操作を、誰が実行できますか」です。別の保存装置でも、普段の端末から管理者として操作できるなら、その端末の侵害を想定した確認が必要です。バックアップの実行に必要な権限と、保存済みデータを削除する権限を分けられるか尋ねます。
三つ目は「別の環境へ持ち出して戻す手順はありますか」です。サーバーの形式が違うと、そのまま起動できないこともあります。ネットワークやアプリの設定を含めた復旧手順を、契約中のサービス仕様に合わせて確かめてください。
検証した結果は、「できた・できなかった」だけでなく、復元に使ったデータの日付、作業時間、必要だった権限、手順に不足していた情報まで残します。担当交代があっても、次の人が同じ作業を始められる記録にします。
停止時の連絡先も、クラウドの外へ置いておく
障害が起きたサービスの中にだけ連絡先や復旧手順を保存していると、それを取り出すところから困る場合があります。正規のサポート窓口、契約番号、連絡担当、承認者を、権限を管理した別の場所でも参照できるようにしておきます。パスワードを無制限に紙へ書き出すのではなく、復旧のために必要な情報を安全に取り出せる状態を目指してください。
よくある疑問
クラウドなら、バックアップも事業者任せでよい？
契約とサービス仕様を確認してください。設備の冗長化、障害復旧、利用者の誤削除からの復元は、同じ意味ではありません。何が標準で、何が追加契約かを確認します。
MFAだけで管理基盤は守れる？
MFAは認証情報の不正利用への対策ですが、ソフトウェアの脆弱性を修正するものではありません。更新、権限、接続制限、監視も組み合わせます。
IDCFの事件は全リージョンのデータが暗号化された？
今回確認した発表の被害範囲は東日本リージョン1の一部です。調査のための管理画面停止と、実際に暗号化された範囲を混同しないでください。［1］
自分の環境では「管理画面に入れない日」を想定する
まず、管理者権限と復旧用のデータがどこにあるかを把握します。そのうえで、管理画面が停止した場合の連絡先と復元方法を確認してください。クラウドへ移した後も、業務を再開できることの確認は利用者側の大切な仕事です。
