クラウド・インフラ

箱の価値ではなく、箱が繋がっている先の価値で守る。実行環境を預かる構成の攻撃面

自分のサーバーを守る話と、他人の実行環境を預かる話は、別物です。後者では、守る対象が「自社のデータ」ではなく顧客がそこに置いたものとそこから繋がっている先になります。2026年10月のGMO「お名前.com デスクトップクラウド」の事案は、この構造がどう効くのかを示す例になりました。攻撃手法の詳細は公表されていないため、ここでは公表された事実の形から、設計上の論点だけを取り出します。

事案の「形」

公表されている事実のうち、設計の議論に効く部分だけを抜き出します。

• サービスの性質／FX自動売買用のWindowsデスクトップ環境（VPS）。MetaTrader等を常時動かす用途
• 影響の可能性がある範囲／26,739件。ただしこれは「対象となり得るサーバー数」であり、不正アクセスや情報取得が確認された件数ではない
• 確認されたこと／一部顧客のサーバー環境で不正なプログラムの設置。その後、顧客情報が外部に持ち出された事実を確認
• 下流への波及／顧客から取引口座での不正操作の報告。主要な取引所・証券会社へ、本サービス経由のアクセス遮断と全アクティブセッションの強制切断を要請
• 利用者側への依頼／接続に使ったPC・スマートフォンのフルスキャン、ネットワークから切り離したバックアップ、アカウントの見直し

「2万6千台」という数字より重要なのは、影響範囲がサービスの外側に出たことです。取引所、証券会社、そして顧客自身の手元のPC。箱の中で完結していません。

なぜ外側に出るのか

顧客の実行環境を預かるサービスには、普通のWebサービスにない性質が3つあります。

1. 顧客が自分で何を置いたかを、事業者が把握していない。GMOも「クレジットカード等の決済情報は本サービスのサーバーに保有していない」一方で「顧客が自ら保存した情報は影響範囲に含まれる」と説明している。預かっているものの中身が、事故が起きるまで分からない
2. 生きたセッションが常駐する。自動売買のように「ログインしたまま動かし続ける」用途では、環境そのものが認証済みの状態を保持している。環境を取られることが、そのまま下流の操作権限を取られることになる
3. 顧客の端末と双方向に繋がっている。リモートデスクトップ接続は、クリップボード、ドライブ、プリンタなどを既定で橋渡しする。接続元の端末は「見ているだけ」ではない

3つ目が、利用者にフルスキャンを依頼する理由です。預けた先が侵害されると、接続していた自分の端末も疑わしくなる。これは一般的なSaaSの事故では発生しない波及の形です。

設計側で詰めておく論点

攻撃手法が分からなくても、構成から決まる論点はあります。

• 管理基盤の共通化／多数のテナントを1つのコントロールパネル・ディレクトリ・デプロイ経路で管理していれば、そこが単一障害点になる。「何件に影響し得るか」は、攻撃の巧拙ではなく管理基盤の設計で決まる
• テナント間の分離／ハイパーバイザ・ネットワーク・ストレージ・認証のどこで分離しているか。認証だけで分けている構成は、認証が破られた時点で分離がなくなる
• リモート接続のチャネル／クリップボード・ドライブ・デバイスのリダイレクトを既定で有効にしているか。利便性の既定値が、そのまま双方向の経路になる
• セッションの寿命／顧客環境が保持しているセッションを、事業者側から一括で切れるか。切れなければ、遮断の次の手が「下流の事業者に頼む」しかなくなる
• 顧客データの可視性／何が置かれているか把握していないなら、「把握していない」こと自体を事故時の説明に含められるようにしておく

どれも派手な対策ではありません。ただ、事故後に説明を求められるのはこの5つです。

セッションは、パスワード変更では止まらない

今回の対応で特に実務的だったのが、第3報の注意喚起です。パスワードを変更しても、既存のセッションが一定期間残る場合がある——だからログイン中の全セッションを切断してほしい、という依頼でした。

これは実装上、きわめて普通の挙動です。セッショントークンやリフレッシュトークンをパスワードのハッシュと紐付けていない設計では、パスワード変更はトークンを無効化しません。JWTのように自己完結型のトークンを使い、失効リストを持っていなければ、有効期限が切れるまで使えてしまう。

事故対応の文脈で言い換えると、「パスワードを変えてください」という案内は、多くの実装で初動として機能しません。必要なのは全セッションの強制失効で、それを管理画面から即座に実行できるかどうかは、平時の設計で決まっています。

1. パスワード変更・権限変更・退会の各イベントで、発行済みトークンを失効させる経路があるか
2. 全ユーザー分を一括で失効させる操作が、管理機能として用意されているか
3. 失効後、どのくらいの時間で全ノードに伝播するか
4. 下流の連携先に「このユーザーのセッションを切って」と伝える手段があるか

テナント分離は、どの層でやっているか

「影響の可能性がある範囲が26,739件」という数字は、攻撃の巧拙ではなく管理基盤の設計から出てきます。多数のテナントを1つのコントロールパネル、1つのディレクトリ、1つのデプロイ経路で管理していれば、そこが単一障害点になる。

分離をどの層でやっているかを整理しておきます。

• ハイパーバイザ／カーネル／最も強い分離。VMごとに独立。ただし管理面（コントロールプレーン）は共通になりがちで、そこを取られると全テナントに手が届く
• ネットワーク／テナント間の通信を遮断しているか。同一セグメントに並んでいると、1台から横展開できる
• ストレージ／論理的に分けているのか、物理的に分けているのか。スナップショットやバックアップの経路が共通だと、そこが抜け道になる
• 認証・ディレクトリ／共通のディレクトリでテナントを分けている構成は、認証が破られた時点で分離がなくなる
• 運用／保守用の共通アカウント、踏み台、デプロイ経路。技術的には分離されていても、運用経路が1本なら同じこと

「何件に影響し得るか」を見積もるときは、この5層のうち最も弱い層で数えるのが正解です。ハイパーバイザで分けていても、運用の踏み台が1台なら、影響範囲は全テナントです。

逆に言えば、公表時に「対象となり得る件数」として大きな数字を出さざるを得ないかどうかは、事故の前に決まっています。

リモートデスクトップは、見ているだけではない

預けた環境が侵害されたとき、なぜ利用者の手元の端末までフルスキャンを求められるのか。これはリモートデスクトップ接続の性質によります。

RDPは既定で、接続元と接続先の間に複数のチャネルを張ります。

• クリップボード／双方向。接続先から接続元へ、ファイルを含む内容を渡せる
• ドライブリダイレクト／接続元のローカルドライブが、接続先からネットワークドライブとして見える
• プリンタ・ポート／同様にリダイレクトされる
• デバイス／スマートカードやUSBデバイスを共有する設定もある

つまり接続先が攻撃者の手にあるとき、接続元は「見られている」だけでなく「触られている」可能性がある。GMOが利用者にフルスキャンとオフラインでのバックアップを依頼したのは、この経路を前提にしたものと読めます。

設計側でできることは明快です。

1. クリップボードとドライブのリダイレクトを既定で無効にする。必要な利用者だけが明示的に有効化する
2. 接続元の制限（IP、証明書、デバイス登録）をかける
3. 接続セッションの記録を取り、異常な時間帯・頻度を検知する
4. 利用者向けの案内に、リダイレクトの意味を書いておく。「便利な機能」としか説明していないと、事故時に理解されない

利用側でできることも、裏返しで同じです。預けた環境への接続に使う端末を、日常業務の端末と分ける。これだけで、事故時の影響範囲が切り分けられます。

預ける側のエンジニアができること

提供側ではなく利用側に立つ場合の論点も挙げておきます。

• 接続元を分ける／預けた環境への接続に使う端末を、日常業務の端末と分ける。今回のように「接続に使った端末をスキャンしてください」となったとき、影響範囲が切り分けられる
• リダイレクトを切る／クリップボード・ドライブの共有を既定で無効にしておく
• 下流の権限を絞る／預けた環境から操作する先のアカウントに、出金や設定変更の権限まで与えていないか
• 資格情報を置かない／環境内に保存した認証情報は、環境ごと取られる前提で考える
• 切り戻し先を持つ／サービスが停止した場合に、別環境で業務を継続できるかを事前に確認しておく

GMOは現行基盤を再開せず、セキュリティアーキテクチャを刷新する方針を公表しました。利用者から見れば、移行は自分で選ぶものではなく、事業者の判断で発生しうるということでもあります。

止めたあとに、何が残るか

サービスを停止すれば攻撃は止まります。ただし、停止したあとに残る仕事のほうが長い。GMOの対応から、順序を読み取っておきます。

1. 遮断：影響を受けたシステムのネットワーク接続を停止し、外部からの不正アクセス経路を断つ
2. 下流への要請：主要な取引所・証券会社に対し、本サービス経由のアクセス遮断、全アクティブセッションの強制切断、不正取引の緊急監視を要請
3. 利用者への依頼：接続に使ったPC・スマートフォンのフルスキャン、ネットワークから切り離したバックアップ、アカウントの見直し
4. 証拠保全：通信記録等を捜査機関に提出
5. 端末の解析：10月25日に顧客端末の調査協力を依頼し、26日から預かった端末の解析を開始
6. 作り直し：現行基盤は再開せず、セキュリティアーキテクチャを刷新。代替サービスへの移行者は6か月間無償

2番目が、このサービス特有の対応です。自社で止められるのは自社の環境までで、すでに下流で生きているセッションは、下流にしか切れない。だから取引所や証券会社に頼むしかない。

ここから逆算できる設計上の要件は2つです。

• 連絡先の整備／下流の事業者の、緊急時に届く連絡先を平時から持っているか。営業窓口ではなく、セキュリティ窓口
• 要請内容の定型化／何を頼むのかを事前に文書化しておく。「アクセス遮断」「全アクティブセッションの強制切断」「不正取引の緊急監視」——この3つを即座に伝えられるかで初動の速度が変わる

6番目の「作り直し」も示唆的です。直して戻すのではなく、基盤そのものを作り直す判断をした。これは、事前に出ていた指摘が「直せば済む不具合」ではなく「構成そのものの問題」だったことを意味します。利用側から見れば、移行は自分で選ぶものではなく、事業者の判断で発生しうるということでもあります。

出典

• GMOインターネットグループ／「お名前.com デスクトップクラウドサービスに対するサイバー攻撃について」第4報（2026年10月24日）・第7報（2026年10月26日）
• piyolog（2026年10月23日作成・24日更新）／お名前.com デスクトップクラウドへの不正アクセスについてまとめてみた／26,739件の位置づけ、第3報のセッションに関する注意喚起、下流事業者への要請、利用者への依頼事項
• INTERNET Watch／FX自動売買専用VPS「お名前.com デスクトップクラウド」、不正アクセス受けサーバー停止

本記事は2026年10月27日時点で公開されている情報に基づいています。攻撃の経路や手口の詳細は公表されていないため、本記事では構成上の一般的な論点のみを扱い、特定の脆弱性や原因を推定していません。