GMOのVPS不正アクセスから考える「個人のゼロトラスト」

2026年10月26日 17:47

最初にこのニュースを見たとき私は正直「これは起こるべくして起きた事故なのではないか」と思った。

ただしこれは現時点で判明していない侵入原因を断定する意味ではない。原因はまだ公表されていないし私が知っているわけでもない。「事業者の過失だから起きた」と言いたいわけでもない。私がこの言葉を向けているのは、複数の「ここは大丈夫だろう」という信頼が連鎖する構造そのものだ。

そう感じたのは、PCがある。そのPCからVPSへ接続する。VPS上では取引ツールが動く。そこには金融サービスへアクセスするための認証情報がある。クラウド事業者がその環境を管理している。そしてユーザーはそれらを一つの便利なサービスとして使っている。そんな「つながり」の構造そのものを見たからだ。

一つ一つだけを見れば特別に異常なものではない。むしろ現在のITサービスとしては普通だ。けれどもそれらが全部つながった瞬間、本当にそれを「安全」と呼べるのだろうか。

今回のGMOインターネット「お名前.com デスクトップクラウド」へのサイバー攻撃を見ながら、私はそんなことを考えていた。

この記事は事件の犯人探しでも企業批判でもない。公表されている事実を確認したうえで、同じような構造を持つ環境でどこに防御を置けば被害を小さくできるのか、そして一般の個人が今日から何をすればいいのかを整理したい。

まず分かっていることだけを整理する

こういう事件では情報が錯綜する。攻撃者を名乗る人物の発言、SNS上の報告、技術者による分析、利用者の証言。さまざまな情報が一気に流れるため、つい「原因はこれだ」と考えたくなる。

私自身最初はそうだった。

だが公開する文章にする以上、確認されている事実と推測は分けなければならない。以下は2026年10月26日時点でGMOインターネットの公式発表から確認できることだ。

公式に確認されていること

10月20日、一部の顧客サーバー環境で、第三者による不正なプログラムの設置を確認した。翌21日未明から全プランのサーバーを順次停止した（第1報）。
影響の可能性があるサーバーは26,739件。ただしGMOはこれは「対象となり得るサーバー数であり不正アクセスまたは情報取得が確認された件数ではありません」と明記している（第3報）。
サーバー内に保存されていた情報（取引ツール等に保存された取引口座のログイン情報等を含む）が第三者に取得され、不正に利用された可能性がある（第2報・第3報）。
「本サービスのシステムにセキュリティ上の問題が存在し」、不正なアクセスと顧客情報が外部に持ち出された事実を確認した。取引口座で身に覚えのない取引があったという報告も受けている（第4報、10月24日）。
攻撃者を名乗る者から金銭の要求と情報公開の脅迫があったが、GMOは応じない方針で警察に資料を提出している。また攻撃者が公開する情報には「事実と異なる内容が含まれるおそれがあります」と注意を呼びかけている（第4報）。
現行の基盤は再開せず継続を希望する顧客には別のクラウド基盤への移行を案内するとしている（第4報）。

公式にはまだ確認されていないこと

どこが最初の侵入口だったのか（侵入経路は「調査を進めております」とされている）
RDP（Windowsのリモートデスクトップ）が直接の侵入原因だったのか
利用者のPCにまで実際に到達したのか（GMOは「お客様の端末への影響を含め調査を進めております」としている）
管理基盤から多数のVPSへ一斉に広がったのか
解約済みの環境がどう管理されていたのか

ネット上ではこれらについてさまざまな説や、攻撃者を名乗る人物の主張が出回っている。しかし10月26日時点でそれを裏付ける公式発表は確認できていない。だからこの記事ではそれらを事実としては扱わない。

なおGMOは利用者に対して端末のウイルス対策ソフトでのフルスキャンとバックアップ、取引口座や取引ツールのパスワードを、FX取引に使っていない端末から変更すること、ログイン中の全セッションの切断、2段階認証の有効化などを求めている（第5報）。バックアップについてはGMO自身が「バックアップしたファイルの取り扱いには十分ご注意ください」とも書いている。これは調査中の段階での念のための依頼であり「利用者PCが侵害された」と確認したという意味ではない。

ただしもしPCが侵害されていた場合のファイルのバックアップにはいろいろなリスクが考えられるので推奨はできない。

では何が怖いのか

私が今回気になったのは、一つの場所に入るための鍵が別の場所へ入るための鍵にもなり得たという構造だ。

公表されている範囲だけでもVPS内の取引ツール等に取引口座のログイン情報が保存されており、それが取得・不正利用された可能性があることが分かっている。

VPSという一つのシステムの中に、取引口座という別のシステムへ入るための「鍵」がある。つまり一つの境界が破られたとき、その中にある資格情報によってさらに別の境界へ進める可能性が生まれる。

セキュリティではこうした信頼の切れ目を**Trust Boundary（信頼境界）**と呼ぶ。「ここから先は別の主体・別の権限・別の管理者の領域になる」という線のことだ。PCとVPSの間、VPSと証券会社の間、利用者と事業者の間。それぞれに線がある。

そして攻撃者から見た「ここに入れたら、次にどこへ行けるか」という道筋が**Attack Path（攻撃経路）**になる。問題は「侵入された」という一つの出来事だけではない。侵入されたあとどこまで行ける設計だったのか。そこまで考えなければならない。

ここで強調しておきたいのは、自動売買のためにVPSにログイン情報を保存するのは、そのサービスの使い方として自然だということだ。利用者の不注意を責める話ではない。ただ「事業者が管理しているから」「自分のサーバーだから」という理由でそこを安全な場所だと前提にしてはいけない。それだけだ。

「侵入されないシステム」を作るだけでは足りない

セキュリティの話になると「どうやって侵入を防ぐか」に集中しがちだ。ソフトウェアを更新する。管理画面を外部へ無制限に公開しない。多要素認証を使う。不要なサービスを閉じる。全部必要だ。

でも本当に重要なのは、それでも侵入されるかもしれない
という前提を持つことだと思う。

一台のサーバーが破られた。それでも他の環境へは行けない。
一つのパスワードが盗まれた。それでも重要な操作はできない。
一つのセッションが奪われた。それでも短時間で失効する。
一つのPCが侵害された。それでも金融口座やクラウドまで自動的には到達できない。

こうして被害の爆発半径＝Blast Radiusを小さくする。実際の防御では、こちらの方が重要になる。

ではどこに防御を置くのか

ここは慎重に書きたい。

今回の侵入原因がまだ公表されていない以上「これをしていればGMO事件は防げた」とは言えない。

しかし同じような構造（PC → リモート環境 → 保存された資格情報 → 外部の金融サービス）を持つシステムでどこに防御を置くべきかは考えることができる。以下は今回の原因の特定ではなく、同種の構造に一般的に有効な防御の整理だ。

私は大きく4つの層があると思っている。

1．PREVENT：まず侵入口を減らす

OSやアプリケーションを更新する。管理用のリモートアクセスを必要な場所・必要な時間だけに限定する。強い認証を使う。

たとえばMicrosoftは、自社の仮想デスクトップサービス向けのセキュリティ推奨で、全ユーザーと管理者への多要素認証、セッションホストへの直接のRDPアクセスを避け、必要なときだけ一時的に開く「Just-In-Time」アクセスを使うことなどを挙げている。

ここは「入られないため」の防御だ。しかし未知の脆弱性もあれば人間のミスもある。フィッシングも認証情報の漏えいもある。だから次の層が必要になる。

2．CONTAIN：入られても横へ進めない

一台のVPSへ侵入されたとしても、そこから別のVPS、管理システム、利用者PC、外部サービス、金融口座へ自由に移動できなけれ被害はそこで止まる。攻撃者が侵入後に別の場所へ移動していくことを**横展開（ラテラルムーブメント）**と呼ぶ。これを止めるのが、

権限分離（一つの管理者アカウントで全部に入れないようにする）
ネットワーク分離・セグメンテーション（環境同士が直接つながらないようにする）
最小権限（必要な操作に必要な権限だけを与える）

といった考え方だ。Microsoftも同じ推奨の中で利用者に管理者権限を与えないこと、ネットワークを分割してフィルタすることを挙げている。私なりに言い換えれば通常の利用と管理のための操作を分け、管理者権限を常に持たせておかないということだ。企業環境では管理アクセスそのものを分離・段階化する設計も一般に使われている。

つまり「中に入ったから自由」という構造をなくす。

3．CREDENTIAL：鍵を持たせすぎない

今回の話で私はここが特に重要だと思う。

パスワード、APIキー、Cookie、ログイン済みのセッション、OAuthトークン（アプリ連携の許可証）、秘密鍵。こうしたものは便利だ。毎回入力しなくて済むし自動化もできる。

でも同時に別のサービスへ移動するための鍵でもある。

だから、

鍵をいろいろな場所に置かない（保存場所が増えるほど、どこか一か所の侵害で持ち出される）
一つの鍵に大きな権限を持たせない（可能なら、取引はできても出金はできない、など権限を絞る。ただし、取引権限自体が残る以上、不正な取引による損失は起こり得る）
長く有効な鍵を残さない（不要になったセッションは切る）
漏れた可能性があればすぐ変える・失効させる

GMOが利用者に「全セッションの切断」と「パスワード変更」を求めているのはまさにこの層の対応だ。盗まれた鍵の有効期間をこちらから短くする。

そしてパスワードだけに頼らず使えるサービスではパスキー（Passkey）へ移行する。FIDO Allianceはパスキーはフィッシング耐性がありサービスごとに一意で、サーバー側に共有の秘密情報を置かない設計だと説明している。

もちろんパスキーで全部が解決するわけではない。ログイン後のセッションが盗まれれば、それは別の問題として残る。でも「パスワードを盗めば終わり」という状態からは一段離れることができる。

ただし自動売買ツールなどに保存され、ツール自身が利用する資格情報や、すでに確立されたセッションについては、利用者が行うMFAやパスキーでは守れない場合がある。だから認証方式だけではなく保存する資格情報そのものを減らし、保存する場合も権限を最小化する必要がある。

4．DETECT-RESPOND：侵害されたらすぐ気付いて止める

最後が検知と対応だ。異常なログイン、見覚えのない取引、短時間の大量操作、権限の変更。こうした異常に気付き、セッションを切る、アカウントを止める、ネットワークから隔離する、資格情報を失効させる。

GMOが不正プログラムの確認翌日に全プランのサーバーを順次停止したのも、この層の対応にあたる。

個人にとってログイン通知・取引通知を有効にして、取引履歴と残高をこまめに見ることがいちばん現実的な「検知」になる。気付くのが遅れるほど、被害が拡大する余地は大きくなるからだ。

セキュリティは絶対に破られない壁を作ることではなく、破られたときに被害が広がらない構造を作ることなのだと思う。

RDPも「便利だから全部つなぐ」をやめる

ここからは一般論だ。今回の直接原因がRDPだったとは公式には確認されていない。

ただ、RDP（リモートデスクトップ）そのものについては、Trust Boundaryの観点から考えておく価値がある。

RDPにはリダイレクトという機能がある。Microsoftの公式ドキュメントによれば、クリップボード、ローカルのドライブやUSBストレージ、プリンタ、スマートカード、カメラなどを、手元の端末とリモート環境の間で共有するための仕組みだ。そしてローカルドライブとクリップボードは、データの流れが双方向だとされている。

便利だ。手元のファイルをリモートに持っていける。

しかし裏返すと、リモート側から手元のPCのドライブが見え、書き込める状態にもなる。リモート環境が安全なうちは問題にならない。でもリモート環境が侵害されたとき、その接続は手元のPCへ伸びる一本の道になり得る。

これは理論上の話ではない。Microsoftは2024年10月、ある攻撃グループが悪意のある .rdp ファイル（接続設定ファイル）を送りつけ、受信者が開くと、全ドライブ、クリップボード、プリンタ、接続機器などが攻撃者側のサーバーへ公開され得たという事例を報告している。そこからローカルドライブへマルウェアを置くことも可能だったという。今回の事件とは別の話だが、「リダイレクトは境界を一つつなぐ行為だ」ということがよく分かる例だ。

Microsoftの企業向けセキュリティ推奨でもデバイスリダイレクトの制限が挙げられている。また、ドライブのリダイレクトはWindows OS側の既定ではブロックされていない一方、Windows 365などのサービスでは既定で無効になっている、とも書かれている。つまりどのサービスで、どういう設定で使っているかによって状態が違う。自分の環境を一度確認する価値がある。

個人でできることは単純だ。

「リモートデスクトップ接続」の接続設定にある「ローカルリソース」で、必要のないドライブ・クリップボード・プリンタの共有をオフにする
手元の全ドライブをまとめてリモート環境へ見せない
出所の分からない .rdp ファイルや接続の誘いは開かない

Microsoftのドキュメントには、手元のWindows側でドライブのリダイレクトを無効にするレジストリ設定や、最も制限の強い設定が優先されるという仕組みも書かれている。

これは非常に単純だが、境界をまたぐ経路を一つ減らすという意味では大きい。

ただしリモート環境そのものが侵害されている場合、その環境内で入力したパスワード、表示した情報、保存した資格情報までリダイレクト設定が守ってくれるわけではない。リダイレクトの制限は主として被害がリモート環境から手元のPCへ伸びる経路を減らすための対策であり、リモート環境の侵害そのものを防ぐものではない。

Zero Trustとは何か ——「何も信用しない」ではない

ここまで書くと「じゃあ自分のPCもZero Trustにすればいい」と思うかもしれない。

ただここには少し誤解がある。

Zero Trustは「何も信用しない」という精神論ではない。米国立標準技術研究所（NIST）の文書 SP 800-207 は、Zero Trustを物理的な場所やネットワーク上の位置だけを理由に、端末やユーザーアカウントへ暗黙の信頼を与えない考え方として定義している。そして、ユーザーと端末の認証・認可は、リソースへの接続（セッション）が確立される前に、それぞれ行われるべきだとする。

もう少し噛み砕くと、

「社内ネットワークの中にいるから」
「自社の端末だから」
「一度ログインしたから」

という理由だけでアクセスを許さない。代わりに、**誰が（Identity）、どの端末で（Device）、どのリソースに（Resource）、どんな条件で（Policy）**アクセスしようとしているのかを、そのつど評価する。NISTは守る対象を「ネットワークの区画」ではなく「リソース」そのものだとも書いている。アクセスは接続ごとに判断され、一つのリソースへの認証が、別のリソースへの扉を自動的に開くべきではない。

これは前半で書いた「一つの鍵が別の場所の鍵にもなり得る」構造への、設計としての答えでもある。

企業と同じZero Trustを個人が作るのは重い

では企業が本格的にZero Trustを構築するとどうなるか。

米CISA（サイバーセキュリティ・社会基盤安全保障庁）の成熟度モデル（Zero Trust Maturity Model Version 2.0。2023年公開。参照ページは2026年10月26日時点でArchived表示）は、Identity（ID）、Devices（端末）、Networks（ネットワーク）、Applications and Workloads（アプリ）、Data（データ）の5つの柱と、それを横断する可視化と分析、自動化とオーケストレーション、ガバナンスを定め、それぞれを4段階（Traditional → Initial → Advanced → Optimal）で成熟させていく枠組みになっている。

NIST SP 800-207が示しているのは、特定の製品ではなく原則と論理的な構成だ。ただ実際の企業のZero Trust環境では、ID基盤（IdP）、端末管理、EDR（端末の侵害検知と対応）、ネットワーク分割、アクセス可否を判断するポリシーエンジン、集中ログ、SIEM（ログ分析基盤）、ZTNA（ゼロトラスト型リモートアクセス）などを組み合わせて実装することが多い。

個人がこれを丸ごと構築するのは正直かなり重い。費用がかかるし設定も難しい。何より運用し続ける担当者が自分一人しかいない。

でも「個人版Zero Trust」なら作れる

企業と同じものを作る必要はない。

ここで言う「個人版Zero Trust」はNISTが定義する企業向けZero Trust Architectureを実装したという意味ではない。Zero Trustの原則——場所や所有だけで信用しない、権限を最小にする、信用を期限付きにする、異常に気付ける状態にする——を個人が現実的に実行できる範囲へ落としたこの記事なりの実践の呼び方だ。

重要度ごとに分けると私はこう考えている。（難易度／費用の目安つき）

MUST：今日やる

金融・メール・クラウドなど重要アカウントのパスワードを使い回さない。パスワードマネージャで管理する（低／無料〜低額）
重要アカウントで多要素認証を有効にする。使えるところはパスキーへ（低／無料）
心当たりがあるときはパスワード変更と「全セッションからログアウト」をセットで行う。変更は侵害の疑いがない別の端末から（低／無料）
ログイン通知・取引通知・出金通知を有効にし履歴を見る（低／無料）
OS・ブラウザ・取引ツール・リモート接続ソフトを更新する（低／無料）
不審なメールやメッセージのURL・添付は開かない。事件に便乗した連絡は特に（低／無料）

SHOULD：今月中にやる

認証情報を保存する場所を減らす。VPSやツールやブラウザに散らばった保存パスワードを棚卸しし不要なものは消す（中／無料）
自動化に使う資格情報はサービスが対応していれば権限を絞る（取引のみ、出金不可、閲覧のみなど）。ただし取引権限が残る以上、不正な取引による損失は起こり得る（中／無料）
リモート接続ではドライブ・クリップボード・プリンタの共有を必要最小限にする（低〜中／無料）
金融や重要作業を普段のブラウザから分ける。ブラウザプロファイル → OSのユーザー → 別端末の順に分離は強くなる（低〜中／無料〜中）
普段は管理者ではない標準ユーザーで使う（中／無料）
「連携中のアプリ」「ログイン中の端末」を見直し、使っていないものは取り消す。使い終わったTrustは消す（低／無料）
重要データのバックアップを、別の場所に取る。これは主に復旧（Recovery）のための対策だ（中／低額）

ADVANCED：余力があれば

家庭内のWi-Fiを、IoT機器・来客用と分ける
スクリプトやAIツールに渡す秘密情報を専用の保管場所に置き、期限の短いトークンを使う

それぞれ残るリスクもある。パスワードマネージャは端末自体が侵害されれば守りきれない。MFAやパスキーはログイン後のセッション窃取や、ツールに保存された資格情報までは守れない場合がある。ブラウザの分離は、同じOSの中では強い境界ではない。ウイルス対策ソフトのフルスキャンで何も検出されなかったとしても、それだけで端末の安全が証明されたことにはならない。バックアップ自体はSecurity Boundaryではなく、侵害済みのファイルを含んでいる可能性もある。だから一つに頼らず、層を重ねる。

そしてAIエージェント時代にはこれがさらに重要になる

AIエージェントは、メールを読み、Google Driveを見て、GitHubへアクセスし、ブラウザを操作し、クラウドを操作し、外部APIを使う。場合によっては、購入や送信まで行う。

つまり、人間が一つずつ越えていたTrust Boundaryを、AIが自動的に越えるようになる。

AIに与えたAPIキー、OAuth、ログイン済みセッション、ファイルアクセス、メールアクセス、クラウドアクセス。これらはすべて、次の境界へ進むための「鍵」だ。

私には今回のVPSと構造的には同じ設計上の問題に見える。一つの信頼が、次の信頼への通行証になる。一つの場所（エージェント）に、別の場所へ入るための鍵がまとめて置かれている。一つのエージェントに全部を渡せば、そのAIが侵害されたり、紛れ込んだ悪意ある指示を実行したりしたときのBlast Radiusも大きくなる。

だからAIにもZero Trustの原則が必要になる。

必要な仕事に必要な権限だけを渡す（最初は読み取り専用から）
権限に期限を切る
一つのAIに全部を渡さない
外部送信、削除、課金、公開、金融取引のような取り消しにくい操作には、最後に人間の承認を置く

AIが高度になるほど、AIそのものを信用するかどうかではなく、たとえ間違えてもどこまでしか動けない設計にするかが重要になる。

「何も信用しない」ではなく「信用を固定しない」

Zero Trustという言葉を聞くと「何も信用しない世界」のように聞こえる。でもNISTの定義を読んでも、私はやはり少し違うと思っている。

必要なときには信用する。ただし、

永遠には信用しない。
場所だけでは信用しない。
一度ログインしたからといって、その後ずっとは信用しない。
大手企業だからという理由だけで信用しない。
自分のPCだからという理由だけで信用しない。
AIだから信用しないでもない。人間だから信用するでもない。

その都度誰なのか。何をしようとしているのか。どこまで必要なのか。その権限はまだ必要なのか。それを確認する。それがZero Trustの本質に近いのだと思う。

今回の事件から私が一番考えさせられたこと

今回の最終的な侵入原因や経路については、まだ調査が続いている。だから私は「この設定が悪かった」「この管理が原因だった」と断定するつもりはない。

だが今回の公表内容だけでも一つ考えられることがある。

セキュリティ事故は一つの巨大な穴だけから起こるとは限らない。

便利だから接続する。便利だから認証情報を保存する。便利だからセッションを残す。便利だからドライブを共有する。便利だから外部サービスをつなぐ。便利だからAIに権限を渡す。

一つ一つは小さな「大丈夫」だ。でもそれらが直列につながれば一つの穴が次の場所へ進む道になる。

だから必要なのは「絶対に安全なシステム」を探すことではない。そんなものを前提にしないことだ。

侵入されるかもしれない。認証情報は漏れるかもしれない。PCもクラウドも破られるかもしれない。AIも間違えるかもしれない。

それでも一つ破られたときに全部を持っていかれないようにする。
私は今回の事件からそこを一番考えさせられている。「安全なものなど何もない」と怯える必要はない。

ただ、安全であることを前提にしてよいものは、何もない。

そしてもう一歩進めるなら、

信用するな、ではない。
信用を固定するな。

ということなのかもしれない。

参照した主な資料（2026年10月26日確認）

GMOインターネット第1報（2026年10月21日）https://www.onamae.com/news/article/11584
GMOインターネット第2報（10月22日）https://group.gmo/info/alert/20261022/
GMOインターネット第3報（10月23日）https://group.gmo/info/alert/20261023/
GMOインターネット第4報（10月24日）https://group.gmo/info/alert/20261024/
GMOインターネット第5報（10月24日）https://group.gmo/info/alert/2026102402/
NIST SP 800-207 Zero Trust Architecture https://csrc.nist.gov/pubs/sp/800/207/final
CISA Zero Trust Maturity Model Version 2.0（2023年公開。2026年10月26日時点でArchived表示）https://www.cisa.gov/zero-trust-maturity-model
Microsoft Learn: Peripheral and resource redirection over the Remote Desktop Protocol https://learn.microsoft.com/en-us/azure/virtual-desktop/redirection-remote-desktop-protocol
Microsoft Learn: Configure drive redirection over RDP https://learn.microsoft.com/en-us/azure/virtual-desktop/redirection-configure-drives-storage
Microsoft Learn: Security recommendations for Azure Virtual Desktop https://learn.microsoft.com/en-us/azure/virtual-desktop/security-recommendations
Microsoft Security Blog: Midnight Blizzard conducts large-scale spear-phishing campaign using RDP files（2024年10月29日）https://www.microsoft.com/en-us/security/blog/2024/10/29/midnight-blizzard-conducts-large-scale-spear-phishing-campaign-using-rdp-files/
FIDO Alliance: Passkeys https://fidoalliance.org/passkeys/

※本記事の対策は、今回の事件の原因に対する対策として示したものではなく、同種の構造に一般的に有効な防御の整理です。事件の状況は今後の公式発表で更新される可能性があります。

注目の記事

前回の記事