カテゴリー別アーカイブ: ガイダンス

日本の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 デスクトップクラウド

以上

お名前.com デスクトップクラウド ~ クラウドサービスとしての位置づけと責任分界の整理

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

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

本ブログの位置づけ

2026年10月、GMOが提供する「お名前.com デスクトップクラウド」(以下「本サービス」)において、不正アクセスが公表された[10]。「クラウド」という名称を付けていることもあり、クラウドセキュリティの観点からそもそもどのようなサービスモデルなのか、また、責任範囲は事業者と利用者でどうなるのかを考えてみたい。そこで、公開されている告知等をもとに、本サービスの構造とセキュリティ上の責任分界を技術面から整理してみる(2026年10月27日時点の公開情報にもとづく)。なお、利用規約の条文は確認しておらず、契約上の責任を確定するものではない。このため、本ブログでいう「責任」「管理範囲」は、各層を誰が設定・運用・保護する立場にあるかという技術面での分担を指し、契約上の義務や法的な賠償責任を意味しない。

本ブログで用いる用語と表記は次のとおりとする。

  • 共通管理基盤:事業者が全VMに対して特権的に操作できる仕組みと、全VMに共通して配布・適用される要素の総称。本ブログでは、マネジメントプレーン、コントロールプレーン、ハイパーバイザー、全VM共通のVMイメージ、管理エージェント(存在する場合)を含む(3章)。
  • 利用者:本サービスの契約者。
  • 根拠の表記:本文中の[番号]は巻末の出典に対応する。番号のない記述は一般論または本書の想定である。

要点

  • 位置づけ:本サービスは、確認できる範囲では1利用者に1台のWindows Server VMを割り当て、リモートデスクトップで操作する形態であり、「仮想デスクトップ用途向けのWindows VPSに近いサービス」と整理できる(1章)。
  • 責任分界:物理基盤と共通管理基盤は事業者、ゲストOSやMT4の更新の適用、EA、保存した認証情報、データは利用者が担うと整理できる。このうち緊急のセキュリティ更新の適用とOS提供終了時の再インストールは、告知で利用者に求められている(2章)。
  • 前提:この分担は、事業者が共通管理基盤を適切に管理していることを前提とする。共通管理基盤が侵害されるとVM内の対策は迂回されうるため、この前提が成り立たなくなり、被害を抑える手段は取引口座側の対策が中心になる(3章)。

1. 「お名前.com デスクトップクラウド」のクラウドサービスとしての位置づけ

「お名前.com デスクトップクラウド」はGMOの商品名であり、VDIやDaaSのような技術・提供形態の分類用語ではない。分類を検討する際は名称だけでなく、提供機能、管理機能、利用者が管理する範囲を確認する必要がある。

確認できる範囲では、本サービスは1利用者に1台のWindows Server VMを割り当て、利用者がリモートデスクトップで接続して操作する[1][3]。GMOは料金改定の告知で本サービスを「FX専用VPS」と表記しており[3]、緊急のセキュリティ更新の適用[8]やOS提供終了時の再インストール[9]は利用者に求められている(詳細は2.1、2.2)。本ブログでは、これらの特徴をもとに、本サービスがクラウドのサービスモデルの中でどこに位置づけられるかを整理する。

1.1 用語の整理

用語意味
VDIデスクトップ環境をサーバー上の仮想マシンで動かし、手元の端末から画面を操作する技術・仕組み。オンプレミスでも構築でき、それ自体はクラウドとは限らない
DaaSVDIを事業者がサービスとして提供する形態(Azure Virtual Desktop、Windows 365、Amazon WorkSpacesなど)
VPS事業者の物理サーバー上の仮想マシンを1台単位で貸すサービス。用途は利用者次第
IaaS仮想マシン、ネットワーク、ストレージなどのインフラをサービスとして提供する形態(AWS、Azure、GCPなど)
SaaSアプリケーションの機能をサービスとして提供する形態。利用者はOSに触れない

1.2 VDI・DaaSとSaaSの関係

VDIはデスクトップ環境を仮想化して利用する技術・仕組みであり、それ自体がSaaSを意味するわけではない。クラウドでデスクトップ環境をサービス提供する形態は一般にDaaSと呼ばれる。IaaS・DaaS・SaaSの一般的な責任分界は下表のとおりである。ただし、責任分界はサービスごとに異なり、DaaSだからOS管理を一律に利用者が担う、または事業者が担うとは限らない。利用する際に、責任範囲を明確にすることが必要である。

層IaaSDaaS(典型的)SaaS
物理基盤・仮想化基盤事業者事業者事業者
接続の仲介・認証ゲートウェイ利用者が構成(部品は事業者が提供)事業者事業者
デスクトップのOS・パッチ利用者製品により事業者か利用者事業者
アプリ・データ・アカウント管理利用者利用者利用者(データとアカウント)

1.3 VPSとDaaSの違い

DaaSには一般に、接続仲介、利用者・セッション管理、イメージ管理、コピー&ペーストや印刷等の制御機能が含まれることがある。ただし、機能の有無は製品・サービスによって異なる。Windows VPSにRDPで接続する形態は見た目がデスクトップサービスに似ていても、管理機能や責任分界が同一とは限らない。

1.4 VPSとIaaSの関係

VPSとIaaSは、仮想マシンを借りて利用者がOSから上を管理する点で共通する。IaaSではAPI、仮想ネットワーク、ロードバランサー、マネージドDB、IAM、監査ログ、鍵管理等の機能が提供されることが多い。これらは一般的な傾向であり、VPSとIaaSの境界は事業者およびサービスによって異なる。

1.5 「お名前.com デスクトップクラウド」はクラウドか(NISTの定義との照合)

NIST SP 800-145[11]はクラウドの必須の特徴を5つ挙げている。公開情報で確認できる範囲で本サービスを当てはめると次のようになる。

NISTの特徴内容本サービス(公開情報上)
オンデマンド・セルフサービス事業者とやりとりせず、利用者が自分でリソースを用意できる一部確認できる(OS再インストールを利用者がコントロールパネルから行える[9]。申し込み、起動・停止は未確認)
幅広いネットワークアクセスネットワーク経由で様々な端末から使える満たす(PC・タブレット・スマートフォンから接続できる[3])
リソースプール複数の利用者で物理リソースを共有し、動的に割り当てる共有はうかがえる(サーバーの収容効率に触れた告知がある[2])が、動的な割り当ては未確認
迅速な弾力性必要に応じて素早く拡大・縮小できる。場合によっては自動で未確認(プラン変更の可否、即時性、自動化の有無を確認していない)
計測可能なサービスリソースの使用量を計測し、管理・報告できる未確認(料金は契約期間ごとの定額[5]。使用量の計測・報告機能は確認できない)

未確認の項目があるため、公開情報だけでは本サービスがNISTの定義を満たすかどうかは判定できない。ただし、迅速な弾力性は自動であることを必須とせず、計測可能なサービスも従量課金そのものを求めていないため、仮にこれらが限定的であっても、それだけで直ちに定義から外れるわけではない。VPSとクラウドの関係はグレーゾーンにあり、実務上の区別は、定義から外れるかどうかより、弾力性・API・周辺サービスの充実度の差によるところが大きい。

1.6 本サービスの位置づけ

  • GMO自身が料金改定の告知で「FX専用VPS」と表記している[3]。
  • DaaSに一般にみられる管理機能(接続の仲介、組織アカウントとの連携、イメージの一括管理等)は、公開情報からは確認できない。緊急のセキュリティ更新の適用[8]や、OS提供終了時の再インストール[9]は利用者に求められている。
  • 以上から、本ブログでは「お名前.com デスクトップクラウド」は「仮想デスクトップ用途向けのWindows VPSに近いサービス」と整理する。

2. 「お名前.com デスクトップクラウド」の責任分界

2.1 サービスのアーキテクチャ

  • 提供形態:GMOインターネットが保有するデータセンター内のサーバー上に仮想のWindowsデスクトップを構築し、PC・タブレット・スマートフォンからリモートデスクトップで接続する[3]。
  • 割り当て方式:1VMを1利用者に割り当てる[1]。複数の利用者で1台のOSを共有する形態ではない。
  • OS・ストレージ:2019年のリニューアルで全プランがSSD、OSはWindows Server 2019となった[2]。その後、2020年3月に「for MT4 ver2.0」、2021年8月に「デスクトップクラウド」が提供開始され[4]、2024年5月には新プランに改められた[5]。現行プランのOSは本ブログでは確認できていない。
  • プラン:2019年のリニューアルでFX自動売買向けの「for MT4」が設けられた[2]。ビジネス向けの「for Biz」は2020年3月5日以降の申込分からグローバルIPが標準となった[3][12]。for MT4とfor Bizはいずれも新規受付を終了しており[6][12]、2024年5月30日以降はメモリ容量別の新プラン(StartUp・Standard・Premium)が提供されている[5]。2024年10月にはオプションの「高負荷通知サービス」にMT4/MT5の稼働監視機能が追加されており[7]、MT4/MT5での利用が想定されている。
  • 管理系:契約管理のお名前.com Naviと、VMを操作するコントロールパネル。利用者がコントロールパネルからOSを再インストールできることは告知で確認できる[9]。起動・停止などその他の機能は本ブログでは確認できていない。
  • 接続方法:リモートデスクトップ(RDP)で接続する。接続時のドライブ共有等の既定設定は公開情報からは確認できない。

注意:提供形態と割り当て方式の根拠は2012年〜2020年の記事・告知であり、2024年5月の新プラン以降も同じ形態かは確認できていない。ハイパーバイザーの種類、ネットワーク分離方式、ディスク暗号化の有無など、内部構成の詳細は公開されていない。

2.2 セキュリティの責任分界

下表の「根拠」列は、告知等で確認できるものを「告知あり」、一般的な考え方から本ブログが想定したものを「想定」、想定のうち一部の場面だけ告知で確認できるものを「想定(一部告知あり)」とする。対象が2019年版のプランに限られる行は、項目名にその旨を記した。

レイヤー主な管理範囲根拠補足
物理DC・ハードウェア・ネットワークGMO告知ありGMOインターネットが保有するデータセンターで運用[3]
共通管理基盤(3章)GMO想定利用者からは直接管理・監視できない層
VMの初期イメージ(共通テンプレート)GMO想定全VM共通の初期設定(初期アカウント、接続設定等)。不備があれば全VMに影響しうる
ゲストOS(Windows Server)の緊急のセキュリティ更新の適用利用者告知あり2019年8月の告知で、緊急度の高い脆弱性について、利用者にWindows Updateによる早急な適用を求めている[8]
ゲストOSの通常の更新利用者想定通常時の更新について告知は確認していない。管理者権限を持つ利用者がVM内で行う運用と想定
OSの提供終了への対応利用者(一部は事業者)告知あり2022年12月の告知で、提供終了までに利用者自身がコントロールパネルからOSを再インストールするよう求めている。別途、事業者側でサーバー移行を行う場合もある[9]
MT4のプリインストール(2019年版for MT4)GMO告知あり主要FX会社4社のMT4をプリインストールして提供[2]。新プランでの扱いは未確認
MT4本体の脆弱性修正・更新版の提供FX会社・MetaQuotes社想定MT4はMetaQuotes社が開発[2]。各FX会社が自社向けに配布する形が一般的
VM上のMT4への更新の適用利用者想定更新版をVM上で適用・再起動する運用は利用者が管理すると想定(プリインストール版を含む)
EAの選択・導入・設定・運用利用者想定EAは利用者が自分で導入する
取引口座のログイン情報の保存・管理利用者想定無人で自動再開させる運用では、VM内に保存せざるを得ないことが多い
データのバックアップ利用者想定(一部告知あり)OS再インストール時は、必要なデータを利用者が事前に保存するよう求められている[9]
接続元の端末(PC・スマートフォン)利用者想定端末自体の保護は利用者。ただし、事業者が提供した接続設定を通じて端末に被害が及んだ場合は、この整理がそのまま当てはまらない可能性がある

注意:2019年版のライトプランは、ブラウザや他のアプリのインストール機能を省き、MT4の稼働に機能を絞っていた[2]。これは製品仕様であり、上表には含めていない。

2.3 VPSとIaaSのセキュリティ上の違い

責任分界の基本はどちらも同じで、違いは利用者が使える防御の道具の多さと、事業者の透明性に出てくる。下表は一般的な傾向であり、本サービスの実装を確認したものではない。VPSでも二段階認証やパケットフィルターを備えるものはある。

観点VPS(一般的な傾向)IaaS(AWS・Azure・GCPなど)
管理画面へのログインID・パスワードのみ、または簡易的な二段階認証MFAを強制できる、SSO連携、細かい権限設定(IAM)
権限の分割契約者アカウント1つでほぼ全権限人・用途ごとに最小権限を付与できる
ネットワーク制御簡易なファイアウォール、またはなし。RDP/SSHが直接公開されがちVPC、セキュリティグループ、プライベートサブネット、踏み台・VPN経由
監査ログ利用者が見られる操作ログはないか限定的利用者側の管理操作ログ(CloudTrailなど)、フローログ
暗号化・鍵管理事業者任せで利用者から見えないことが多いディスク暗号化、利用者管理の鍵(KMS)
秘密情報の保管専用サービスは標準で付かず、VM内のファイルに置く運用になりがち(外部の秘密情報管理サービスをAPIで呼ぶ構成は可能)Secrets Managerなどの専用サービス
物理的な分離共有ホストが中心専有ホスト・専有インスタンスを選べる
事業者の透明性内部構成や第三者認証の情報が少ない責任共有モデル、SOC 2・ISO認証、文書を公開

注意:

  • IaaSが常に安全というわけではない。機能が多いぶん設定ミス(ストレージの誤公開、アクセスキーの流出など)が起きやすい。
  • 事業者側の共通管理基盤が侵害されることは、VPSでもIaaSでも起こりうる。ただし、発生の確率や影響範囲が同じとは限らない。
  • IaaSの監査ログに残るのは主に利用者側の操作であり、事業者内部の管理基盤やハイパーバイザーの侵害は利用者のログに残らないことが多い。共通管理基盤の侵害については、VPSでもIaaSでも、事業者の調査と公表に頼る部分が大きい。

3. 共通管理基盤の構造と、侵害されたときに起きること

2章の責任分界は、事業者が共通管理基盤を適切に管理していることを前提に成り立つ。本章では、共通管理基盤の構造と、それが侵害されたときに何が起きるかを整理する。

本ブログでは、ネットワーク機器の3プレーンの考え方を借りて共通管理基盤を整理する。なお、ここでの定義は、SDNでの定義(RFC 7426)とは一致せず、クラウド事業者の用法に近い。以下はGMOの実際の内部構成を示すものではなく、各要素の存在・配置は公開情報から確認できない。

3.1 本ブログでのプレーンの定義

プレーン本書での定義本サービスでの例(一般論、実構成未確認)範囲
マネジメントプレーン事業者の運用者が、設定・監視・保守のために基盤へアクセスする経路運用者用管理画面、保守用ログイン、監視基盤、運用アカウント全体共通
コントロールプレーン利用者や管理画面からの指示を受け、VMの作成・停止・再インストール等を実行する仕組みコントロールパネルの裏側で動くAPIやオーケストレーション全体共通(画面は利用者ごと)
データプレーン実際の処理や通信各VM、Windows、MT4、RDPの通信利用者ごとに分離

マネジメントプレーンとコントロールプレーンの違いは、誰の操作を受け付ける経路かにある。前者は事業者の運用者、後者は利用者(およびその指示を受ける管理画面)の操作を受け付ける。クラウド事業者の用語は揺れており、AWSはリソース操作API群を「コントロールプレーン」と呼び、Azureは「管理レイヤー」とも説明するが、本書では上記の定義で用いる。

3.2 プレーン以外の共通要素

  • ハイパーバイザー:VMを実行する基盤層。プレーンではないが、全VMに対して特権を持つため、共通管理基盤に含める。
  • VMの初期イメージ:全VMに共通して配布される初期設定(初期アカウント、接続設定、導入済みソフトウェア)。操作する仕組みではないが、不備があれば全VMに同じ弱点が及ぶため、共通管理基盤に含める。
  • 管理エージェント(存在する場合):VM内で動き、管理側からの指示を受ける仕組み。VM内にあっても事業者側の要素とみなす。なお、本サービスでの存在は確認できていない。

3.3 共通管理基盤が侵害される典型的なパターン

  • コントロールプレーンの不具合:利用者向けAPI等の認可不備により、ある利用者が他人のVMを操作できるケース。外部の利用者の立場から攻撃されうる。主な対策は認可設計とAPIの検証。
  • マネジメントプレーンの侵害:運用者アカウントや保守経路が侵害され、VMに特権でアクセスされるケース。主な対策は運用アカウントの多要素認証、保守経路の分離、操作の監査。
  • 共通要素の不備:VMイメージに共通のアカウントや管理エージェントの脆弱性などにより、全VMに同じ弱点が及ぶケース。主な対策はVMごとの認証情報の個別化と、エージェントの更新管理。

いずれも全VMに影響が及びうる点は同じだが、主な対策の方向が異なるため、区別して考える必要がある。

3.4 共通管理基盤が侵害されたときに起きること

共通管理基盤が侵害されると、攻撃者はVMの外側からディスクを読んだり、VM内でプログラムを動かしたりできる場合がある。このとき、VMにログインするためのWindowsパスワード(認証)は迂回される。データを読まれずに済むか(秘匿)は、ディスク暗号化の有無、鍵の置き場所、VMが稼働中かどうかで変わる。鍵を事業者が管理している場合や、稼働中のVMに入り込まれた場合は、暗号化があっても防げないことがある。本サービスのディスク暗号化の状況は公開されていない。

自動売買に使う取引口座のログイン情報は、無人で自動再開させる運用ではVM内に保存せざるを得ないことが多く、侵害時のリスクになる。

「VM内は利用者の責任」という一般的な分担は、事業者が共通管理基盤を適切に管理することを前提とする。共通管理基盤が侵害されると、利用者がVM内で行える対策だけでは防ぎきれない場合がある。また、RDP接続時にドライブやクリップボードを共有していると、VMが侵害された場合に接続元端末へ影響が及ぶ経路になりうる。

3.5 利用者への注意事項

共通管理基盤が侵害されうることを踏まえ、本サービス(および同種のWindows VPS)を利用する際の注意事項を整理する。

3.5.1 管理者としての認識

  • 管理する立場であることを認識する:GMOは告知のサービス説明で、本サービスを「面倒な設定などは不要」で「ハイスペックなセカンドパソコン」として使えると案内している[3]。一方で、緊急のセキュリティ更新の適用やOS提供終了時の再インストールは利用者に求められており[8][9]、利用者はWindowsサーバーを管理する立場にある。通常の更新、MT4・EAの更新の適用、保存した認証情報、データのバックアップも、利用者の管理範囲と想定される(2.2)。
  • 事業者の告知を確認する:脆弱性への対応やOSの提供終了など、利用者の作業を求める告知が出されることがある[8][9]。登録メールアドレスへの連絡や公式サイトの告知を確認する。
  • VMに置くものを絞る:共通管理基盤が侵害されるとVM内の対策は迂回されうるため、「VMに置いたものは読まれうる」と考え、VMに置く認証情報やファイルを必要最小限にする。

3.5.2 取引口座の対策(FX会社が提供している場合)

注意:以下は各FX会社の提供機能に左右される。二段階認証、IP制限、取引用と出金用の認証の分離を提供していない会社もある。

  • 口座の保護機能を使う:二段階認証、ログイン元IPの制限、ログイン通知、出金先の固定を設定する。
  • 権限を分ける:取引用と出金用で認証を分けられる場合は、出金用の認証をVMに置かない。
  • 資金を絞る:自動売買口座には必要な証拠金だけを入れる。
  • 異常に早く気づく:約定通知やログイン通知をVMとは別の端末で受け取る。
  • Web画面のセッションも切る:FX会社の会員ページ・口座管理画面では、パスワードを変えても既存のログインセッションが残る場合がある。パスワード変更時は全セッションの切断も行う(MT4自体のログインとは別)。

3.5.3 メール・Webアカウントの対策

  • 使い回さない:VMに置いたパスワードを他のサービスで使わない。
  • 連携・転送設定を点検する:心当たりのない連携アプリ、メール転送設定、ブラウザ拡張機能、登録端末がないか定期的に確認する。

3.5.4 接続元端末の対策

  • 共有を絞る:RDP接続ではドライブ・クリップボード等の共有を必要なときだけ有効にする。
  • 端末を分ける:可能であれば、取引・出金に使う端末とVPS接続用の端末を分ける。

3.5.5 異常の検知と契約条件の確認

  • 自分で異常に気づく:共通管理基盤の侵害は、利用者が見られるログには残らないことが多い(2.3)。異常に気づく手段は、取引口座の通知や取引履歴・残高の確認が中心になるため、定期的に確認する。
  • 契約条件を確認する:免責の範囲、補償の条件、データの扱い(解約後のデータ消去を含む)は利用規約で確認する。なお、本ブログは利用規約を確認できていない。別のサービスへ移る場合も、申し込み前に責任分界と条件を確認する。
  • 事故の際は公式の案内で動く:事故が起きた場合は、事業者の公式サイトや登録メールアドレスへの連絡で状況を確認する。パスワードや認証コードを尋ねる連絡、「被害金を取り戻す」などの名目で費用を求める連絡には応じない。

4. まとめ

サービスの位置づけ:公開情報からは「仮想デスクトップ用途向けのWindows VPSに近いサービス」と評価できる。VPSがクラウドにあたるかはNIST SP 800-145の定義に照らしてもグレーゾーンにあり、個々のサービス機能で判断する必要がある。

責任分界:物理基盤と共通管理基盤は事業者、ゲストOSの更新、EAの運用、保存した認証情報、データ等は利用者が担うと整理できる。2019年版for MT4ではMT4のプリインストールにGMOが関与し、MT4の更新版の提供はFX会社・MetaQuotes社、VM上での適用は利用者が担う。

共通管理基盤の侵害:「VM内は利用者の責任」という分担は、事業者が共通管理基盤を適切に管理することを前提とする。共通管理基盤が侵害されるとVM内の対策は迂回されうるため、利用者の管理範囲で防ぐという前提そのものが成り立たなくなる。このとき被害を左右するのは、責任分界ではなく、事業者による共通管理基盤の管理と、取引口座側で被害を抑える対策である。

教訓:利用者は、取引口座の保護機能、権限の分離、資金の限定、別端末での通知確認、接続設定の見直しなどで被害を抑えられる。サービスを選ぶ際は、名称ではなく提供機能、責任分界の明確さ、監査ログの有無、事業者の説明と透明性を確認することが重要である。

出典

  • [1]@IT 2012年10月10日の記事(仮想デスクトップ市場とお名前.com デスクトップクラウドの紹介) https://atmarkit.itmedia.co.jp/ait/spv/1210/10/news008.html
  • [2]お名前.com「お名前.com デスクトップクラウド」フルリニューアルのお知らせ(2019年1月23日) https://www.onamae.com/news/article/10792
  • [3]お名前.com FX専用VPS「お名前.com デスクトップクラウド(for Biz/for MT4)」料金改定のお知らせ(2020年3月5日) https://www.onamae.com/news/article/10780
  • [4]お名前.com デスクトップクラウド 価格改定のお知らせ(2024年3月ご利用分から。対象プランとして「for MT4 ver2.0(2020/3/5提供開始)」「デスクトップクラウド(2021/8/24提供開始)」を記載) https://www.onamae.com/news/article/10738
  • [5]お名前.com デスクトップクラウド 新プラン提供開始のお知らせ(2024年5月30日) https://www.onamae.com/news/article/10734
  • [6]お名前.com 新規受付終了サービス:デスクトップクラウド for MT4 https://www.onamae.com/server/closed/dc2-mt4/
  • [7]お名前.com デスクトップクラウド 高負荷通知サービス機能アップデート(MT4/MT5の稼働監視、2024年10月17日) https://www.onamae.com/news/article/10724
  • [8]お名前.com「Windows Server OSにおける緊急度の高い脆弱性に関するお知らせ」(2019年8月28日) https://www.onamae.com/news/article/11007
  • [9]お名前.com「Windows Server 2008 R2 / 2012 R2 をご利用のお客様へ」(2022年12月22日) https://www.onamae.com/news/article/6293
  • [10]GMOインターネット「第三者による不正アクセスに関するお詫びとお知らせ」(第1報、2026年10月21日) https://www.onamae.com/news/article/11584
  • [11]NIST SP 800-145 The NIST Definition of Cloud Computing https://csrc.nist.gov/pubs/sp/800/145/final
  • [12]お名前.com 新規受付終了サービス:デスクトップクラウド for Biz https://www.onamae.com/server/closed/dc2-biz/

以上

クラウドサービスにおけるバックアップの責任分担と復旧可能性 ~ IDCフロンティアのセキュリティ事故とAWSの契約条件を踏まえた考察

2026年10月28日更新
2026年10月15日更新
2026年10月11日
ガイダンスWGリーダー 諸角昌宏

【第7報反映】IDCフロンティアが公表した第7報では、IDCFクラウドポータルの認証システムで使用されていたオープンソースソフトウェアの脆弱性が悪用され、仮想化基盤の管理者権限が不正取得されたことなど、事故の経緯が明らかにされた。また、バックアップデータを取り出すことが可能とされた利用者数は206に更新された。しかしながら、本ブログの主題であるバックアップの責任分担と復旧可能性という観点では、バックアップデータを取り出せることと、個々の顧客のシステムが正常に復元できたことは区別する必要がある。第7報だけでは、個別の復元結果や、契約上の責任が履行されたかどうかを一律に判断することはできない。このため、第7報は事故に関する事実関係を更新するものではあるが、本ブログの基本的な論旨を変更するものではない。

【第5報反映】改訂箇所の表示:赤色マーカーおよび「【第5報反映】」は、2026年10月14日付第5報を受けた追記・修正を示す。

要旨

【第5報反映】IDCフロンティアの事故では、当初はデータの取り出し・復元が困難とされたが、10月14日付第5報により、影響を受けた495の企業・自治体のうち、スナップショット機能を利用する194の利用者についてバックアップデータを取り出せることが確認された。ただし、復元の可否は引き続き確認中である。

背景

2026年10月、IDCフロンティアが提供するクラウドサービス「IDCFクラウド」において、ランサムウェアによる被害が発生し、一部の顧客の仮想マシンやデータの利用に影響が生じた。この事故は、クラウドサービスにおけるデータ保護やバックアップのあり方、特にクラウドサービスプロバイダ(CSP)とクラウドサービスカスタマ(CSC)の責任分担について、改めて考える契機となる。

クラウドサービスでは、一般に責任共有モデルに基づき、CSPとCSCがそれぞれの責任を負う。しかし、バックアップについては、「クラウドに保存したデータはCSCが自らバックアップしなければならない」という理解がある一方、CSPがバックアップ機能を提供し、その取得・保存・復元処理を実施するサービスも存在する。このため、CSPが提供するバックアップ機能を利用している場合にも、CSCが独立したバックアップを取得する必要があるのか、また、バックアップの取得・保存・復元に関して、CSPとCSCはそれぞれどのような責任を負うのかという点を整理する必要がある。

本ブログでは、IDCフロンティアの事故を検討の契機として、ISO/IEC 27017における責任分担の考え方、IDCフロンティアおよびAWSの公開資料、データ耐久性とバックアップの違いなどを整理し、CSCがバックアップをどのように確保すべきかを考察する。

なお、本ブログは、IDCフロンティアの事故原因、同社のセキュリティ対策の適否、契約違反の有無、法的責任の所在を判断するものではない。事故に関する記述は公開情報に基づくものであり、今後の調査結果によって変更される可能性がある。

注)本ブログでは、ISO/IEC 27017で用いられている用語に従い、クラウドサービスプロバイダを「CSP(Cloud Service Provider)」、クラウドサービスカスタマを「CSC(Cloud Service Customer)」と表記する。なお、契約条件や公表資料からの引用については、原文の表記を維持する。

要旨

CSCが、必ず自らバックアップを取得しなければならないとは言い切れない。CSCは必要なデータ保護要件を定義し、それが満たされるように確保・確認する責任を負う。一方、バックアップ取得・保持・復元の実行は、契約と設定に応じてCSPが担い得る。IDCフロンティアの事故では、複数ゾーンの顧客データの取り出し・復元が困難とされた点が重大であるが、独立した有料バックアップサービスの保存データが失われたか、契約どおりに復元できたかは現時点では未確定である。

1.基本概念:責任と作業の区別

「CSCにバックアップ確保責任がある」ことは「CSCが独自の別システムを構築してバックアップを実行する義務がある」ことと同義ではない。また、CSPにバックアップ処理を委ねても、CSCによる要件定義・契約評価・設定確認の責任が当然に消滅するわけではない。整理すると以下の表になる。

区分意味典型的な担当
要求事項の定義・確保責任保護対象、RPO、RTO、保存期間、攻撃耐性を定め、充足を確認CSC
取得・保存の実施責任設定された計画に基づきバックアップを取得・保持契約・サービス仕様に応じてCSPまたはCSCが実施
バックアップの保護責任削除・改ざん・権限侵害からの保護契約・サービス仕様に応じてCSPとCSCが分担
復旧と検証復元手順、定期試験、代替環境への復旧契約・設定による分担

2. ISO/IEC 27017の要件

ISO/IEC 27017では、CSCに対して以下の2点を要求している(なお、ここの記述はISO/IEC 27017の手引きの記載内容を意訳したものである):

  1. CSPがバックアップ機能を提供している場合、CSCはその仕様を要求することが望ましい。CSCはその仕様が自らの要求事項を満たすことを検証する。
  2. CSPのバックアップ機能がCSCの要求事項を満たさない場合、CSCがバックアップ機能の導入に責任を負う。

これらはCSPによるバックアップ機能の提供を想定し、機能が提供されないあるいは機能が要求事項を満たさない場合のCSCの責任を明確化している。一方、「CSPが機能を提供すればCSPが全責任を負う」と結論することはできない。機能の有無、実際の有効化・取得、保存・復元条件、契約上の役割分担を確認する必要がある。

3.クラウドバックアップの技術要件

クラウドバックアップの技術的な要件は以下のようになる。

観点検証ポイント
保護対象仮想ディスクだけでなく、アプリケーション、データベース、設定、鍵、復元に必要なメタデータを含んでいるか
独立性本番とは別の障害領域、管理権限、可能なら別アカウント・別拠点に分離されているか
耐改ざん性イミュータブル保管、削除防止、保持期間、特権ID侵害時の防御があるか
復旧可能性実際に復元できるか、整合性・RPO・RTOを満たすか、定期試験があるか
責任と透明性バックアップ機能の仕様、除外範囲、前提設定、障害時の制約がCSCに明示されているか

したがって、スナップショットは迅速な復旧に有効だが、管理基盤の侵害から独立していなければ、ランサムウェアに対する十分な復旧手段とは限らない。保存先の物理的分離と、削除・改ざん権限の分離は別の要件である。

4.IDCフロンティアの公開仕様・契約条件

IDCフロンティアの公開情報には、標準IaaSで顧客の責任の下にバックアップ等を行う旨のサービス提供条件がある。また、スナップショット機能と、別拠点のストレージを利用する「IDCFクラウド バックアップ」を区別して提供している。公開FAQでは、スナップショットにはランサムウェア対策がない一方、バックアップサービスにはイミュータブルストレージがあると説明している。

このため、標準IaaSでの顧客のバックアップ確保責任は確認できるが、バックアップサービスを別途契約・設定していた顧客に対するCSPの個別の履行責任は、サービス仕様書・約款・個別契約を併せて検討しなければならない。

なお、IDCフロンティアの契約には、顧客データの消失などによる損害について、同社が賠償責任を負わない旨の免責条項がある。しかし、免責条項が存在するからといって、すべての事故について同社が責任を免れるとは限らない。実際に免責が認められるかどうかは、事故原因、同社の過失の有無や程度、適用される契約条件などによって判断される。特に、故意または重大な過失があった場合には、免責条項の効力が制限される可能性がある。

5.AWSの契約・サービスとの比較

AWS Customer Agreement 第2.3条(Your Security and Backup)は、顧客がサービスを適切に設定・利用し、アカウントと顧客コンテンツの保護・バックアップのため適切な措置を講じる責任を定めている。AWS Backupでは顧客がバックアップ計画・対象等を設定し、AWSがマネージドサービスとして取得・保存・復元機能を提供する。Vault Lock、クロスアカウント・クロスリージョンコピー、復元テスト等の機能もある。

論点IDCフロンティアAWS
標準IaaSのバックアップ確保責任原則として顧客原則として顧客
CSP提供のバックアップスナップショット、別拠点バックアップEBSスナップショット、AWS Backup等
保護機能別拠点・イミュータブル機能(サービス別)Vault Lock等(構成・サービス別)
CSPのサービス履行責任個別仕様・約款の検証が必要契約・サービス条件の検証が必要

AWSであっても顧客による適切な設定や復元試験は重要であり、AWSの機能があること自体は、いかなる事故でもデータが失われないという保証ではない。

6.IDCフロンティア事故:確認事項と未解明事項

公開情報から確認されている事項

【第5報反映】2026年10月7日からの不正アクセスによる障害は、東日本リージョン1のtesla、henry、pascal、jouleの4ゾーンに影響した。当初IDCフロンティアは、対象データの取り出し・復元が困難との見通しを示していた。しかし10月14日付第5報では、影響を受けた495の企業・自治体のうち、スナップショット機能を利用していた194の利用者について、バックアップデータの取り出しが可能と確認したと公表した。取り出したデータの復元可否と提供方法は引き続き確認中である。これは本番環境の停止に加え、事故後のデータ回収・復元能力がCSCの事業継続に直結することを示している。

【第5報反映】第5報による情報流出の調査結果:IDCフロンティアは、対象4ゾーンの仮想サーバー内データについて、外部持ち出しを示す痕跡等は確認されず、流出はなかったと判断した。一方、クラウドポータルでは48社の登録情報への不正な照会を確認しており、仮想サーバー内データとポータル登録情報を区別して評価する必要がある。

未解明であり、断定してはならない事項

【第5報反映】第5報時点で、スナップショットデータの「取り出し可能」と「実際に正常復元できる」は同義ではない。また、194という数字はスナップショット利用者についての公表値であり、残る301の利用者にバックアップがない、または復元できないと断定できない。スナップショットと別サービスの「IDCFクラウドバックアップ」も区別する。侵入経路の全容、攻撃者の破壊主張の真偽、バックアップサービスの個別契約に対する履行状況については、追加の証拠が必要である。

未解明の論点評価に必要な証拠
4ゾーンに被害が及んだ経路侵入経路、共通管理プレーン、特権ID、ゾーン間の権限・障害分離
スナップショットの被害194利用者分のスナップショットデータは取り出し可能。復元可否は確認中
別拠点バックアップの健全性別サービスの「IDCFクラウド バックアップ」の状況は区別して確認
有料バックアップ利用顧客の復元実績契約・設定状況、RPO/RTO、復元成功率・所要時間
責任分担と契約履行事故当時の適用約款、サービス仕様書、個別契約、保証・免責条件

【第5報反映】第5報により、一部のスナップショットデータを取り出せる可能性が具体的に確認された点は、当初の復旧見通しを更新する重要な事実である。一方、復元成功、RPO・RTOの達成、別途契約されたバックアップサービスの履行状況は、この発表だけでは確定できない。したがって、CSP提供バックアップが一律に機能しなかったとも、十分に機能したとも断定できない。

なお、攻撃者が主張した破壊件数や容量は、事業者が裏付けた確定事実とは扱わない。また、4ゾーンに影響が出たことだけから、テナント分離の破綻やバックアップ基盤の共通障害を断定することはできない。

まとめ

  1. 「CSCは自らバックアップを取得しなければならない」との一律の表現は不正確である。
  2. 「CSCが必要なバックアップを確保・確認する責任を負う」は一般的なIaaS契約と整合する。
  3. CSPが提供するバックアップ機能がCSCの要求事項を満たし、適切に契約・設定され、バックアップの取得・保存・復元が可能であれば、CSCが別途、独立したバックアップを取得することは必ずしも必要ではない。
  4. この場合、CSCは必要なバックアップの要件を定め、実際に復元できることを確認する責任を負い、CSPは契約に従ってバックアップサービスを提供する責任を負う。また、CSPには、バックアップサービスの提供に加えて、クラウド基盤そのものを適切に保護する責任もある。

IDCフロンティアについては、4ゾーンの本番データが復元困難となったこと自体が重大である。一方、CSPが提供した独立バックアップが契約どおり機能しなかったと断定するには、バックアップ利用顧客の復元実績と事故時点の適用契約の確認が不可欠である。

8.クラウドサービスカスタマへのバックアップ推奨事項

基本原則:CSPのバックアップ機能がCSCの要求事項を満たし、適切に契約・設定され、必要なバックアップが実際に取得・保持され、復元可能であることが検証されているなら、CSCが独立したバックアップを必ず追加する必要はない。これは「独立したバックアップは不要」という一般論ではなく、リスク評価に基づく条件付きの判断である。

CSCは、バックアップ処理を自ら実施することと、必要なデータ保護・復旧能力を確保する責任を区別する。CSPに実施を委ねる場合でも、要件定義、契約・設定確認、復元可能性の検証は必要である。

推奨する確認事項

以下の確認事項は、CSCが独立したバックアップを取得することを前提とするものではなく、CSPが提供するバックアップ機能によってCSCの要求事項を満たせるかを確認するためのものである。要求事項が満たされ、残余リスクも許容できる場合には、CSCが独立したバックアップを追加することは必須ではない。

  • 保護対象:仮想マシン、ディスク、データベース、設定、暗号鍵、認証情報など、復旧に必要な要素を漏れなく特定する。
  • 復旧目標:許容データ損失(RPO)、目標復旧時間(RTO)、保存期間、世代数、データ整合性を明確にする。
  • 契約・仕様:CSPが取得・保持・保護・復元のどこまでを担うか、除外事項、SLA、免責、障害時の支援を確認する。
  • 設定・運用:バックアップ対象の割当て、スケジュール、保持設定、失敗通知、アクセス権限を点検する。
  • 攻撃耐性:本番環境との管理権限の分離、削除・改ざん防止(イミュータビリティ)、別拠点・別アカウント等の必要性をリスクに応じて評価する。
  • 復元検証:バックアップの存在確認だけでなく、定期的な復元試験でデータ整合性、復元時間、代替環境への復旧を検証する。
  • 残余リスク:CSPの管理基盤への不正アクセス、リージョン全体の障害、契約終了時のデータ移行、特定事業者への依存などのリスクを評価する。その結果、CSPが提供するバックアップ機能だけではCSCの要求事項を満たせない場合や、追加の保護が必要と判断される場合には、CSPから独立したバックアップの導入を検討する。

独立した追加バックアップの要否を判断する基準

追加が必須とは限らない例:CSP提供機能で必要なRPO・RTO、保持、改ざん防止、管理権限分離、復元試験が満たされ、想定脅威に対する残余リスクを組織が受容できる場合。

追加を検討すべき例:CSP提供機能が本番環境と同じ侵害経路に依存する場合、復元試験ができない場合、リージョン全体の喪失やCSP管理基盤の侵害を想定する場合、法令・契約上の独立保管要件がある場合。

【第5報反映】IDCフロンティア事故への適用:第5報ではスナップショット利用者194のバックアップデータについて取り出し可能と確認されたが、復元の可否は確認中である。CSCの要件設定・検証責任と、CSPの基盤保護・契約サービス提供責任を区別する。別サービスの「IDCFクラウド バックアップ」の個別復元実績を、このスナップショットの報告からはわからない。

IDCフロンティア事故への適用:標準IaaSのバックアップ確保責任と、契約済みバックアップサービスの履行責任を分けて評価する。バックアップサービス利用顧客の復元実績、保存データの健全性、管理権限分離が未公表である限り、サービス自体の失敗も成功も断定しない。

参考:AWS Backupの公式資料では、クラウドサービスカスタマがバックアップ計画と対象リソースを適切に設定し、定期的に復元可能性を検証する責任を負うことが明記されている。一方、バックアップの取得・保持や復元テストの実行については、AWS Backupの自動化機能を利用できる。したがって、カスタマがすべてのバックアップ処理や復元テストを自ら実施する必要はない。ただし、バックアップの対象、保持期間、復旧目標、復元結果などが組織の要求事項を満たしていることを確認する責任はカスタマに残る。
https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/rel_backing_up_data_secured_backups_data.html

9.データ耐久性(11ナイン)とバックアップの関係

AWSがAmazon S3 Standardについて公表する99.999999999%(イレブンナイン)は、年間のオブジェクト耐久性に関する設計上の数値である。これはサービスの可用性、バックアップの取得状況、過去の正常な状態への復元可能性、または損害賠償を保証する数値ではない。

耐久性は、保存済みデータがストレージ障害等によって失われにくい性質を指している。一方、バックアップは、誤削除、論理的な破損、悪意ある変更、ランサムウェア攻撃などを想定し、必要な過去時点のデータを保持して復元するための手段である。複数のアベイラビリティゾーン(AZ)にデータを分散して保存していても、誤削除やランサムウェア攻撃によって変更されたデータが他のAZにも反映される場合がある。そのため、複数AZへの冗長配置だけでは、障害や攻撃が発生する前の正常なデータに復元できるとは限らない。

CSCへの推奨事項

CSCは、CSPが公表する耐久性の数値のみを根拠に、バックアップが不要と判断してはならない。データの重要度、誤削除・改ざん・管理権限侵害・リージョン障害等の想定事象、必要な保存世代、RPO・RTOを定義し、提供されるバックアップ機能の保護範囲と復元手段を評価する必要がある。

一方、CSPのバックアップ機能がCSCの要求事項を満たし、適切に契約・設定され、バックアップが実際に取得・保持され、想定する障害・攻撃に対して復元可能であることを検証できる場合、CSCがCSPとは独立したバックアップを必ず追加する必要はない。追加バックアップの要否は、共通管理権限への依存、削除・改ざん耐性、別アカウント・別リージョンでの保管、復元試験の結果、リスク許容度に応じて判断する。

【第5報反映】第5報は、ストレージの耐久性、バックアップデータの取り出し可能性、業務システムの復元成功が別々の評価項目であることを示している。スナップショット利用者194のデータが取り出せると確認された一方、復元の可否は確認中である。CSPのバックアップ機能が要求事項を満たすかは、正常な復元の実績、RPO・RTO、保護設定、管理権限の独立性などで評価する。

IDCフロンティア事故との関係

今回の事故の評価では、ストレージの耐久性に関する数値と、侵害後に正常なバックアップから復元できるかを混同すべきではない。重要なのは、各バックアップ方式が本番環境や管理プレーンの侵害からどの程度独立し、契約・仕様に沿って復元可能だったかである。事故におけるバックアップデータの実際の被害範囲と復元実績は、公開情報だけでは確定できない。

10. 免責事項

本ブログは、公開時点で入手可能な公表資料、契約条件、技術文書および関連規格に基づき、クラウドサービスにおけるバックアップの責任分担とデータ保護の考え方を整理したものである。

特定のクラウドサービスプロバイダの事故原因、セキュリティ対策の適否、契約違反の有無、法的責任の所在などについて、断定的な評価を行うことを目的とするものではない。

本ブログに記載した事実関係は公開時点の情報に基づいており、今後の調査結果や新たな情報の公表によって変更される可能性がある。また、ISO/IEC規格や各種ガイドラインに関する記述は、筆者による解釈・考察を含むものであり、規格制定機関等の公式見解を示すものではない。

本ブログは一般的な技術情報および制度上の考察を提供するものであり、個別の契約に関する法的助言や、特定のシステムに対するセキュリティ対策の有効性を保証するものではない。具体的な判断にあたっては、適用される契約条件、サービス仕様および組織の要求事項を確認し、必要に応じて専門家に相談すること。

11. 参考資料

以上