日本のIaaS/PaaS事業者への問題提起　～　重大脅威の傾向は国内インフラ事業者にも当てはまるか ― IDCFクラウドとお名前.com デスクトップクラウドの事案から

コメントをどうぞ

2026年10月29日
ガイダンスWGリーダー　諸角昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のないご意見をいただければ幸いである。

要旨

2026年10月の2件の事案は、事業者起因の脅威が重大脅威の上位から外れたという傾向が、日本の国内IaaS/PaaS事業者にはそのまま当てはまらない可能性を示した。どちらも、利用者の設定ミスではなく、事業者側のシステムに起因する侵害である。

  • CSAの重大脅威調査では、2019年以降、事業者の責任範囲の脅威は順位を下げ、設定ミスやIAMなど利用者側の脅威が上位を占めている。また、主戦場はSaaSに移っている。
  • IDCFクラウドでは、顧客向けポータルの認証システム（OSS）の脆弱性から管理コンソールを経て仮想化基盤の管理者権限が奪われ、495の企業・自治体の仮想サーバーが暗号化された。事業者が管理する共通管理基盤が破られた事案である。
  • お名前.com デスクトップクラウドでは、GMOが自社システムのセキュリティ上の問題を認め、顧客情報の外部持ち出しを確認したと公表した。不正プログラムが確認されたのは一部の顧客の環境で、全プランの停止は被害拡大防止のための措置である。侵入経路と破られた層は公表されていない。
  • クラウド環境における責任範囲として「ゲストOSから上は利用者」とする分担は、事業者が共通管理基盤を守り切ることを前提とする。その前提が崩れると、利用者側の対策では防ぎきれない。

このブログが扱う事案はIaaSとVPSだが、PaaSも事業者の管理基盤の上で提供されるため、管理基盤に関する論点は同様に当てはまる。このブログは、管理プレーンの到達性と分離、特権の持ち方、外部部品の脆弱性管理、共通要素の個別化、復旧手段の分離と既定値、透明性と第三者保証の範囲、下流への説明責任の7点を、国内インフラ事業者への問いとして整理する。

1. 前提：CSA重大脅威の推移

CSAの重大脅威調査は、2019年版以降「事業者起因の脅威は重要度を下げ、利用者起因の脅威が中心になった」という傾向を一貫して示している。CSAジャパンの日本語資料集の14「重大脅威関連資料」に、各版の日本語訳が掲載されている。

版上位の脅威事業者起因の脅威の扱い
2019年版（11の悪質な脅威）1位 データ侵害、2位 設定ミスDoS、共有技術の脆弱性、事業者によるデータ消失などが順位を下げた
2022年版（パンデミックイレブン）1位 IAM同じ傾向が継続
2024年版1位 設定ミスと不十分な変更管理、2位 IAM、3位 安全でないインターフェースとAPICSAは事業者に関わる従来型の課題が引き続き重要度を下げていると説明

あわせてCSAジャパンの資料集では、SaaSセキュリティの調査やガバナンス資料が続けて公開され、関心の重心はSaaSに移っている。

ただし、この調査は専門家へのアンケートに基づく世界的な傾向である。国内の中堅インフラ事業者にもそのまま当てはまるかどうかは、この傾向からは分からない。

2. 逆行する2つの事案

2件とも、利用者の設定ではなく事業者側のシステムの問題が原因であり、多数の利用者がサービスを使えなくなった。

項目IDCFクラウド（IDCフロンティア）お名前.com デスクトップクラウド（GMOインターネット）
サービスの性格汎用IaaS（仮想サーバー、RDB等）Windows ServerのVMを1利用者1台割り当てるWindows VPS相当
侵入経路顧客向け「IDCFクラウドポータル」の認証システムで使うOSSの脆弱性 → 管理コンソール経由で仮想化基盤の管理者権限を取得（第7報）未公表。GMOは「システムにセキュリティ上の問題が存在」したとする（第4報）。攻撃者は「全VM共通の管理者アカウント」などを突いたと主張（未確認）
破られた層顧客向けの入口から管理コンソールを経て、ハイパーバイザー管理へ未公表
確認された被害東日本リージョン1の4ゾーン、495の企業・自治体の仮想サーバーが停止・暗号化。最大71社の登録情報への不正照会一部の顧客のサーバー環境で不正プログラムの設置を確認（第1報）。顧客情報の外部持ち出しを確認（第4報。情報の種類と件数は未公表）
予防的な措置全リージョンのポータルを停止し、外部とのネットワークを遮断被害拡大防止のため全プランを停止（第1報）。影響の可能性があるサーバーは26,739件（第2報）
下流への波及メール配信事業者等を経由し、JR各社、自治体、物流など利用者のその先の顧客まで停止や漏えい可能性の公表が相次いだVM内に保存されたFX口座のログイン情報が不正利用された可能性
復旧従来環境での復旧は困難。スナップショット機能の利用者194顧客のバックアップ取り出しが可能と判明し（第5報）、その後206顧客に増えた（第7報）現行基盤をそのまま再開せず、独立したクラウド基盤上の代替サービスへの移行を案内（第4報）
事業者の認識自社開発部分には脆弱性診断ツールを使っていたが、外部のソフトウェアには適用していなかった（NHK報道）社内のホワイトハッカーが事前に課題を指摘していたが、対応の深さと速さが十分でなかったとGMOグループ代表が説明（代表ブログ、報道経由）

IDCFの第7報は、再開に向けてポータルへの接続を顧客IPアドレスに制限し、多要素認証を必須化し、認証システムを外部IdPに刷新するとしている。裏返せば、事案前のポータルはインターネットの任意の送信元から到達でき、多要素認証も必須ではなかったと読める。

出典：IDCFは第5報、第7報、piyologのまとめ。GMOは第1報、第2報、第4報、週刊アスキーの報道。

3. 共通管理基盤が破られるとき

IDCFでは、顧客向けの入口から全利用者に届く特権まで攻撃経路がつながっており、経路の上で分離が実効力を失っていた。分離の欠落がネットワーク、認証、権限のどこにあったかは公表されていない。

利用者向けの入口を破った攻撃者が、事業者の管理系を経て、全VMに外側から届く権限に達した。点線は、本来そこで経路が断たれるべき境界である。

このブログでは共通管理基盤を、次の3つのプレーンと共通要素で捉える。

層誰の操作を受け付けるか範囲侵害されたとき
コントロールプレーン（顧客ポータル、API）利用者画面は利用者ごと、裏の仕組みは全体共通認可不備で他人のリソースを操作される
マネジメントプレーン（運用者の管理系）事業者の運用者全体共通特権で全VMに届く
ハイパーバイザー・共通テンプレート—全体共通VMの外側からディスクや実行に届く
データプレーン（各VM）利用者利用者ごとに分離その利用者だけ

IDCFでは、利用者向けの入口（コントロールプレーン側）を突破した攻撃者が、管理コンソールを経てハイパーバイザーの管理者権限に到達した。つまり、利用者向けの入口から運用者級の特権まで、一続きの経路が存在していた。第7報はこの「管理コンソール」が運用者用かどうか、どのネットワークに置かれていたかを明示していない。

GMOでは、破られたのがどの層かは公表されていない。全プランの停止は被害拡大を防ぐための措置で、不正プログラムが確認されたのは一部の顧客の環境である。共通管理基盤や共通要素が使われたかどうかは、現時点では分からない。

IDCFでは「各利用者の環境は分離されているが、それを束ねる管理層は一つ」という構造が、そのまま影響範囲（blast radius）になった。管理層への到達経路を絞り、権限をゾーンやセル単位に分けることが、事業者にしかできない対策である。

4. 責任共有モデルの前提が崩れるとき

なお、ここでは責任共有モデルを、事業者と利用者がどこまでを担うかという責任境界の観点から扱う。責任共有モデルには、事業者が機能や情報を公開し、利用者がそれを使って検証するという面もある。この面については、第5章の論点6（透明性と第三者保証の範囲）と第6章の調達時の確認で取り上げる。

「VM内は利用者の責任」という分担は、事業者が共通管理基盤を適切に管理することを前提とする。共通管理基盤が侵害されると、利用者がVM内で行える対策だけでは防ぎきれない場合がある。

  • IDCF： 攻撃者はハイパーバイザー側から仮想サーバーを停止し、仮想サーバー自体を暗号化した。ゲストOSのパッチ、EDR、パスワード管理をどれだけ徹底しても、VMの外側からの暗号化は防げない。
  • GMO： 自動売買を無人で動かすには、口座のログイン情報をVM内に保存せざるを得ない。事業者側のシステムが破られれば、この情報を利用者が守る手段はほぼない。

利用者にできるのは、侵入を防ぐことではなく、被害を小さくすることである。管理基盤から独立したバックアップ、別の基盤での再構築手順、口座側の多要素認証や出金制限がこれに当たる。IDCFの事案では、シックス・アパートが別基盤（Google Cloud）に置いていたバックアップで翌日中に暫定移行を終え（同社第3報）、サイバー大学も独自に取得していたバックアップで別基盤に再構築した（同大学第3報）。

ここから導かれるのは、責任共有モデルを「利用者はここから上」という線引きだけで説明することの限界である。線の下を事業者がどう守っているかが示されなければ、利用者は自分の分担を果たしても安全を評価できない。

5. 日本のIaaS/PaaS事業者への問題提起

世界の調査では事業者起因の脅威が重大脅威の上位から外れ、利用者起因の脅威が重大になっている一方で、国内では事業者側のシステムに起因する侵害が1か月に2件起きた。この差を個別の事業者の問題として扱うのではなく、業界全体の課題として次の問いを検証すべきである。

#論点事案で見えたこと事業者への問い
1管理プレーンの到達性と分離IDCF：インターネットに面した顧客ポータルの認証から、ハイパーバイザー管理者権限まで到達できた顧客向けの入口と運用者の管理系は、ネットワークと認証の両方で分離されているか。運用者の管理系はインターネットから到達できないか
2特権の持ち方IDCF：仮想化基盤の管理者権限を奪われた結果、1リージョンの4ゾーンが同時に停止・暗号化された特権はゾーンやセル単位に分け、必要なときだけ付与し、フィッシング耐性のある多要素認証と操作監査をかけているか
3外部部品の脆弱性管理IDCF：診断の対象は自社開発部分で、OSSは対象外だった。再発防止策でSBOM化を挙げた管理基盤を構成するOSSや商用製品を含め、部品を把握して脆弱性情報と突合できているか。公開から悪用までが短くなるAI時代の速度に間に合うか
4共通要素の個別化GMO：攻撃者は全VM共通の管理者アカウントを突いたと主張（未確認）VMイメージの初期アカウント、管理エージェント、接続設定をVMごとに個別化しているか
5復旧手段の分離と既定値IDCF：バックアップの取り出しが可能と判明したのは206顧客。有償バックアップのイミュータブル機能は申請制で、初期状態では無効管理基盤が破られても残る復旧手段を、既定で提供しているか。その分離の程度を利用者に説明しているか
6透明性と第三者保証の範囲両社とも、管理基盤の統制は事案後まで利用者から見えなかった管理プレーンの統制をCAIQやSTAR、ISMAPなどで開示し、監査の範囲に含めているか
7下流への説明責任IDCF：利用者の公表が事業者の第1報より先行した。利用者のその先の顧客まで漏えい可能性の公表を強いられた利用者が自らの顧客へ説明できる速さと粒度で、情報を出せる体制があるか

ここで問うべきは、個別の対策の有無よりも、事業者起因の脅威を「重大ではない」水準に抑えていると、国内事業者が利用者に示せるかどうかである。IDCFは自社サイトでIDCFクラウドを「ソブリンクラウド」として打ち出している。国内事業者の価値が「国内にあること」にあるなら、その信頼は管理基盤の統制で裏付けられている必要がある。

6. 利用者・調達側への示唆

第5章で見たように、事業者起因の脅威が「重大ではない」水準に抑えられているかどうかは、現状では利用者から確かめにくい。事業者がそれを示せるようになるまでは、利用者は、事業者の管理基盤が破られる事態を「想定外」ではなく、設計上の前提として扱う必要がある。あわせて、事業者が示す情報を調達時に確かめることが、利用者の側からできる働きかけになる。

  1. 管理基盤から独立した復旧手段を持つ。 事業者のバックアップサービスでも、別拠点への保管、イミュータブル機能の有効化、論理的な分離といった条件を満たし、本番環境の管理系が破られても消されないものであればよい。条件を満たせない場合は、別の事業者に保管する。いずれの場合も、別基盤での再構築を訓練しておく。
  2. 調達時に管理プレーンを尋ねる。 CAIQでは、IVS-06（区分と分離）、IAM-09・IAM-10（特権の分離と期限付き付与）、IAM-14（強固な認証）が事業者の担当とされているか、実装の説明が記入されているかを確認する。CAIQは自己評価なので、第三者監査の報告書で、監査の範囲に顧客ポータルや運用者の管理系などの管理基盤が含まれているかも確認する。第5章の問いは、CAIQで足りない部分を補う追加質問として使える。
  3. 委託先のその先を把握する。 IDCFの事案では、メール配信などの委託先がIDCFを使っていたことを、多くの利用企業が事案後に知ったとみられる。
  4. 認証情報はできるだけVMに保存しない。 パスワード、APIキー、外部サービスや取引口座のログイン情報などは、VM内に保存しないことが望ましい。管理基盤が破られると、VM内の情報は外側から読み取られうるためである。自動売買のように保存せざるを得ない場合は、その情報が盗まれてもできることを、接続先のサービス側で絞っておく（権限の分離、接続元IPの制限、出金先の固定など）。

SaaSが主戦場であることに変わりはない。ただし国内SaaSには国内IaaSの上で動くものも少なくなく、IaaSの管理基盤の侵害はそのままSaaSの停止として現れる。今回のIDCFの事案がその実例である。

7. まとめ

CSAの重大脅威調査が示すのは、事業者起因の脅威がなくなったことではない。脅威としては残っているが重大度の上位から外れ、相対的に利用者起因の脅威が重大になった、ということである。2026年10月のIDCFクラウドとお名前.com デスクトップクラウドの事案は、この傾向が日本の国内IaaS/PaaS事業者にもそのまま当てはまるかを問い直している。

2件に共通するのは、利用者の設定ではなく事業者側のシステムの問題が原因だったことである。IDCFでは、利用者ごとに分離された環境を束ねる共通管理基盤が破られ、多数の利用者に一斉に影響が及んだ。共通管理基盤が侵害されると、利用者がVM内で行える対策だけでは防ぎきれない。クラウド環境における責任範囲として「VM内は利用者の責任」とする分担は、事業者が共通管理基盤を適切に管理することを前提としている。

国内事業者に求められるのは、この前提が成り立っていることを利用者に示すことである。具体的には、管理プレーンの分離と到達経路の制限、特権の分割、外部部品を含む脆弱性管理、共通要素の個別化、管理基盤から独立した復旧手段、そして管理基盤の統制の開示である。

利用者と調達側は、事業者の管理基盤が破られる事態を設計上の前提として扱い、復旧手段の独立性と管理基盤の統制を調達時に確認する必要がある。主戦場がSaaSに移った今も、その足元にあるインフラの管理基盤は、事業者と利用者の双方が改めて点検すべき対象である。

付録：事実関係の確度

このブログの記述区分根拠
ポータル認証システム（OSS）の脆弱性 → 管理コンソール → 仮想化基盤の管理者権限公式に確認済みIDCF第7報
IDCFがOSSを脆弱性診断の対象にしていなかった報道NHK（piyolog経由）。第7報の再発防止策（診断対象をOSSに拡大）と整合
IDCFでバックアップの取り出しが可能と判明したのは206顧客公式に確認済みIDCF第5報（194顧客）、第7報（206顧客）。取り出し可能と判明した数で、復旧が完了した数ではない
GMOで不正プログラムが確認されたのは一部の顧客の環境。全プラン停止は被害拡大防止の措置公式に確認済みGMO第1報
GMOで顧客情報の外部持ち出しを確認公式に確認済みGMO第4報。情報の種類と件数は未公表
GMOが独立したクラウド基盤上の代替サービスへの移行を案内公式に確認済みGMO第4報
GMOで社内から事前に課題が指摘されていた代表の説明熊谷代表のブログ（10月25日）。週刊アスキーの報道経由で確認
GMOの侵入経路、破られた層未公表GMOは「システムにセキュリティ上の問題が存在」とするのみ
攻撃者の主張（IDCF：7分で暗号化、239台のハイパーバイザー等。GMO：全VM共通の管理者アカウント等）未確認いずれも事業者は裏付けていない。本文では数字を根拠に使っていない
IDCFバックアップのイミュータブル機能は申請制で初期無効公式文書筆者が以前に確認したサービス範囲記述書。今回は再確認していない
重大脅威の傾向が国内事業者にもそのまま当てはまるとは限らない仮説2件の事案からの問題提起。業界全体を比較したデータはない

出典

CSA・CCM/CAIQ

IDCFクラウド

お名前.com デスクトップクラウド

以上

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です