# お名前.com デスクトップクラウド不正アクセス（2026年10月）の技術解説 — 26,739件は「侵害数」ではない。クラウド型RDP環境の信頼境界と、取引口座への波及を止める設計

> GMOインターネットの「お名前.com デスクトップクラウド」不正アクセスを、公式発表の第1報〜第16報で整理。26,739件の読み方、取引口座へ波及しうる条件、原因仮説ごとの必要証拠、利用者と提供者の責任分界、AWSで確かめられる設定まで。

- 公開日: 2026-11-01
- 著者: 友田 陽大
- タグ: セキュリティ, インフラ, アーキテクチャ設計, 認証・認可, AWS, 信頼性
- URL: https://tomodahinata.com/blog/gmo-desktop-cloud-hack-2026-security-analysis
- カテゴリ: セキュリティ事件の技術解説

## 要点

- GMOインターネットは、2026年10月20日に「お名前.com デスクトップクラウド」の一部のお客様のサーバー環境で不正なプログラムの設置を確認し、全プランを停止した。公表された26,739件は『影響の対象となり得るサーバー数』で、侵害が確認された件数ではない
- 10月24日の第4報で、同社は『システムにセキュリティ上の問題が存在し、お客様の情報が外部に持ち出された事実を確認した』と認めた。約80億円（5,000万ドル）は攻撃者の要求額で、損害額ではない。侵入経路・侵入日・持ち出された件数は公表されていない
- 取引口座にまで被害が広がりうるのは、サーバー内に取引ツール（MT4/MT5等）や口座のログイン情報が保存されていたため。サーバーを乗っ取った者は、そこに保存された鍵をそのまま使える。パスワードの強さでは防げない
- 『安全なクラウドか』は、パスワード強度ではなく、管理権限・資格情報の置き場所・顧客環境の分離・セッション失効・監査ログ・外部サービスとの信頼境界で決まる。本記事は、原因仮説ごとに必要な証拠と、利用者・提供者それぞれの確認項目を整理する
- 図・表・チェックリストは一般化した参照モデルで、GMOの内部構成を復元したものではない

---

2026年10月、GMOインターネットが提供する「お名前.com デスクトップクラウド」で不正アクセスが発覚しました。クラウド上に置いた「自分専用のWindowsパソコン」を使うサービスで、FX取引ツールを24時間動かす用途にも使われています。

この記事は、事件の事実を整理したうえで、報道だけでは見えにくい次の点を扱います。

- 「26,739件」と「約80億円」を、どう読むのが正確か
- なぜ**クラウドの侵害が、証券・FX会社の取引口座の被害にまで届きうる**のか
- 公表されていない原因について、**何が分かれば何が言えるのか**（原因仮説ごとの必要証拠）
- 利用者と提供者の責任の分け目と、自社で確かめられる設定

> **情報の時点と扱い**: 本記事は2026年11月1日（日本時間）までに確認できたGMOの公式発表（第1報〜第16報と、10月23日・28日の開示）に基づきます。公式の最新情報は10月30日付です。以下では、**公式発表で確認できる事実**、**攻撃者の主張・報道**、**筆者の推論**を書き分けます。図・表・設定例は一般化した参照モデルで、**GMOの内部構成を復元したものではありません**。公式の引用は読みやすさのために要約しており、数字や日付を引用するときは必ず元の発表を確認してください。

## 30秒で分かる要点

- **何が起きたか**: 2026年10月19日の顧客からの問い合わせを受けて調査を開始し、10月20日に、一部のお客様のサーバー環境に第三者の不正なプログラムが設置されているのを確認。新規申し込みとコントロールパネルを停止し、10月21日午前4時から全プランのサーバーを順次停止した。
- **「26,739件」の意味**: 対象となり得るサーバー数。侵害が確認された件数ではない。
- **GMOが認めたこと（第4報）**: 本サービスのシステムにセキュリティ上の問題があり、環境への不正アクセスと、お客様の情報が外部に持ち出された事実を確認している。
- **お金の話**: 攻撃者は約80億円（5,000万ドル）を要求した。GMOは「永久に応じない」とし、損害額は算定できていない。補償は一律5,000円の見舞金のほか、不正と判断した取引の実損を対象にする。
- **分かっていないこと**: 侵入日、侵入経路、不正プログラムの正体、侵害されたサーバーの数、持ち出された・公開された件数、不正取引の件数と金額。

## 公式発表で確認できる事実と時系列

時刻はすべて日本時間で、各発表に記された時点です。

| 日時 | 出来事 | 出典と分類 |
| --- | --- | --- |
| 10/19 | お客様からの問い合わせを受けて調査を開始 | 10/23 開示（確認済み）。**攻撃が始まった日ではない** |
| 10/20 | 一部のお客様のサーバー環境に不正なプログラムの設置を確認。新規申し込みとコントロールパネルを停止 | 10/23 開示（確認済み） |
| 10/21 4:00 | 被害拡大防止のため、全プランのサーバーを順次停止 | 第1報・10/23 開示（確認済み） |
| 10/21〜 | お客様から取引口座の身に覚えのない操作の報告を受け付け | 第2報・第4報（確認済み。件数は未公表） |
| 10/22 | 警察に相談 | 10/23 開示（確認済み） |
| 10/22 16:59 | 第2報。取引ツール（MT4/MT5等）と口座の認証情報が閲覧された可能性 | 第2報（確認済み。可能性として） |
| 10/24 11:50 | 第4報。お客様の情報が外部に持ち出された事実を確認。攻撃者から金銭要求。見舞金・損失補償を発表 | 第4報（確認済み） |
| 10/26 23:10 | 第7報。攻撃者が10/27 12:00 に情報公開とランサムウェア攻撃を行うと予告 | 第7報（予告を受けたという事実） |
| 10/27 12:30 | 攻撃者による情報公開を確認。内容は未検証で、虚偽の可能性もある | 第10報（確認済み） |
| 10/27 13:55 | ランサムウェア攻撃は確認されていない | 第10報（確認済み。後述の限定つき） |
| 10/28 4:00ごろ | 攻撃者のサイトのドメインが停止 | 第13報（確認済み。ミラーの可能性は監視中） |
| 10/28 | 攻撃者の要求に「永久に応じません」。懸賞金は最大100万ドル | 10/28 開示（確認済み） |
| 10/30 | 情報提供は428件。有力な情報を警察に提出。契約者への個別連絡を開始。サービスは停止継続で再開日は未発表 | 第15〜16報ほか（確認済み） |

### 数字の読み方: 4つの数字を混ぜない

事件を報じる記事で、特に混同されやすい数字を並べます。

| 数字 | 正しい意味 | よくある誤読 |
| --- | --- | --- |
| 26,739件 | 影響の対象となり得るサーバー数 | 侵害されたサーバー数 |
| 約80億円（5,000万ドル） | 攻撃者が**要求した**金額 | 被害額・損失額 |
| 70超の証券・FX会社 | 攻撃者の**脅迫文での主張**（口座の不正操作を続けるという脅し） | 被害を受けた会社の数 |
| 5,000円／1万・1.5万・2.5万円 | GMOが払う**見舞金**（一律5,000円。情報が公開された方への特別見舞金は区分ごとの金額を合算し、上限300万円） | 不正取引の損失補償額 |

さらに、次の限定にも注意が要ります。

- 「解析した端末からマルウェアは確認されていない」という発表は、**お客様のPC（調査のためにお預かりしたもの）**についての話で、クラウド側のサーバーが無事だという意味ではありません。GMO自身が「すべての端末の安全を確認したものではない」と述べています。
- 「ランサムウェア攻撃は確認されていない」は、10月27日13:55時点の確認結果です。

### まだ分かっていないこと

- 侵入が**いつ**起きたのか（10/19は調査開始の日）
- 侵入**経路**と、第4報の言う「セキュリティ上の問題」の中身
- 不正プログラムが**何をするもの**で、何台に置かれたのか
- 侵害が**確認された**サーバーの数
- 持ち出された・公開された情報の種類と件数
- 不正取引の件数と金額。ここには、金融庁の発言として「5社が顧客被害を報告」という報道がありますが、筆者は一次資料を確認できていません
- ネット上で語られる「ドライブ共有が経路」「Active Directory」といった推測は、**専門家の推論と攻撃者の主張であり、GMOは確認していません**

なお、グループ代表は10月30日のブログで、社内のホワイトハッカーから課題が事前に指摘されていたが、対応の深度とスピードが十分でなく攻撃者に隙を突かれた、と述べています。これは「既知の弱点があった」という認識の表明であり、その弱点が今回の侵入経路だとは書かれていません。

## 基礎知識: 「クラウドのデスクトップ」は何を預けているのか

### 貸しオフィスのたとえ

クラウド型デスクトップは、**ビルの管理会社が貸す、鍵つきの個室**に似ています。

- 利用者は、自分の部屋（仮想マシン＝VM）に入って、自分のパソコンのように作業する
- 部屋の鍵（ログイン情報）は、利用者ごとに違う
- ビル全体の合鍵・防犯カメラ・入退室の記録は、管理会社が持つ

安全かどうかは、**部屋の鍵の強さ**だけでは決まりません。管理会社の合鍵が盗まれていないか、隣の部屋と壁が分かれているか、部屋の中に置いた貴重品（口座のパスワード）をどう扱うかも効きます。

### 専門用語を二つだけ

- **コントロールプレーン（管理側）**: 部屋を作る・止める・再起動する・設定を変える、管理会社の側の仕組み。
- **データプレーン（利用側）**: 利用者が実際に作業する部屋の中身そのもの。

この二つを分けて考えると、事件の読み解きがうまくいきます。管理側が破られると、**ほかの部屋にも手が届く**可能性があります。一方、利用側の一部屋だけが破られた場合は、その部屋の中の物が被害を受けます。今回の発表は、どちらなのかをまだ明らかにしていません。

## 信頼境界: 参照アーキテクチャで考える

> **注意**: 下の図は、クラウド型リモートデスクトップ環境の一般的な参照モデルです。**GMOの内部構成を復元したものではなく**、各境界が「破られたら何が起きるか」を考えるための道具です。

```text
[利用者の端末] ──RDP(3389)/ゲートウェイ──▶ ┌─ 境界A: 入口（認証・接続制御）
                                              │
        ┌─────────────────────────────────────┘
        ▼
  ┌── 境界B: 顧客VM（データプレーン）─────────────┐
  │  Windows / 取引ツール(MT4/MT5) / 保存された認証情報  │
  │  顧客ごとに隔離（別VM・別ネットワーク）            │
  └───────────────▲─────────────────────────────┘
                  │ 作成・起動・停止・設定変更・スナップショット
  ┌── 境界C: 管理基盤（コントロールプレーン）──────┐
  │  管理者権限 / 管理コンソール / ハイパーバイザ     │
  │  全顧客VMに届く強い権限をもつ                   │
  └───────────────┬─────────────────────────────┘
                  ▼
        境界D: 外へ出る通信（Egress）── 証券会社・FX会社のサーバー
```

見るべき境界は四つです。

| 境界 | 守るもの | 破られたとき |
| --- | --- | --- |
| A 入口 | 誰が部屋に入れるか | なりすましで部屋に入られる |
| B 顧客VM間 | 部屋と部屋の壁 | 一部屋の侵害が隣に広がる（横展開） |
| C 管理基盤 | 全部屋を操作できる権限 | **一度に多数の部屋が影響を受ける**。公表された26,739件という規模は、この境界の関与を疑わせるが、**そう確認されたわけではない** |
| D 外向き通信 | 部屋から外へ出ていく通信 | 盗んだ情報を外へ送られる／証券会社へ不正ログインされる |

「26,739件が一度に対象になった」という事実から、筆者は**境界Cまたは共通の仕組み（共通イメージ、共通の管理ツール）が関与した可能性を、仮説の一つとして考えます**。ただしこれは筆者の推論で、公式発表には書かれていません。個別のパスワードを一台ずつ破った場合でも、多数の台数に達することはありえます。

## なぜ取引口座にまで被害が広がりうるのか

今回の事件で最も重要なのは、**クラウドの侵害が、別の会社（証券・FX会社）の口座の被害に変わる条件**です。

### 部屋の中に「他の金庫の鍵」を置いていた

GMOの第2報は、サーバー内に保存されていた取引ツール（MT4/MT5等）と口座の認証情報が閲覧された可能性を述べています。たとえるなら、**貸し部屋の中に、銀行の貸金庫の鍵を置いていた**状態です。部屋に侵入した者は、その鍵を使って、別の建物（証券会社）の金庫を開けられます。

この場合、証券・FX会社から見ると「正しいIDとパスワードでのログイン」です。会社側のシステムが破られたわけではなく、**正規の鍵が盗まれて使われた**という形になります。

### 波及する条件（成立条件と、止められる場所）

| 段階 | 起きること | この段階で止められる設計 |
| --- | --- | --- |
| 1. 部屋に入られる | VM上で攻撃者のコードが動く | 入口の認証強化、管理権限の分離（提供者側） |
| 2. 鍵を見つける | 保存されたパスワード・設定ファイルを読まれる | **鍵を部屋に置かない**、保存しない（利用者側） |
| 3. 鍵を使う | 攻撃者のPCから、証券会社へログインする | 取引側のIP制限・二段階認証・新規端末の通知（取引会社側／利用者側） |
| 4. 不正な注文をする | 口座残高が毀損される | 出金・注文の限度額、約定通知、緊急停止（取引会社側／利用者側） |

「パスワードを強くしておけば安全」とは言えない理由が、ここにあります。**盗まれる鍵は、強くても使えます**。止められるのは、鍵を置かない、使える場所を限る、使われたら早く気づく、の三つです。

### 筆者の見解: ゼロトラストは「具体的な制御」に変換して初めて意味がある

「ゼロトラスト」は標語になりがちです。NIST SP 800-207が示す核心は、**ネットワーク上の位置（社内かどうか）で信頼せず、リクエストごとに、主体・端末・状況を確認して、最小の権限だけを与える**ことです。これを今回の構図に当てはめると、次の制御になります。

1. 管理基盤への操作は、**個人に紐づく一時的な権限**にし、常時の共有管理者アカウントを置かない
2. 顧客VMは、管理基盤から**読み取れる情報を最小**にし、顧客の認証情報を管理側のログや設定に残さない
3. 外向き通信は、**行き先を許可制**にして、想定外の宛先への通信を止める・記録する
4. セッションは**失効できる**ようにしておく（侵害の疑いが出たとき、全員を一括で切れる）

これは、筆者がAWSのマルチアカウントや放送事業者向けの認証基盤を設計する際に重視してきた考え方でもあります。ただし、**GMOがこれらを満たしていたかどうかは、公表されていません**。

## 原因仮説ごとに「何が分かれば何が言えるか」

公式に原因が出ていない以上、記事は原因を断定できません。そのかわり、**どの証拠が出れば、どの仮説が支持または否定されるか**を整理します。これは、続報を読むときの物差しになります。

> 以下の仮説は一般的なものです。**どれもGMOの発表では確認されていません**。

| 仮説 | その場合に出てくる証拠 | 公表状況 |
| --- | --- | --- |
| H1 管理基盤（管理コンソール・管理者アカウント）の侵害 | 管理操作の監査ログに、見慣れない操作・時間帯・接続元。多数のVMに**同じ操作**が短時間に行われた痕跡 | 未公表 |
| H2 ハイパーバイザや共通基盤の脆弱性 | 顧客VMの内側にログが残らないのに、複数VMに同じ変更がある。基盤ソフトのパッチ状況 | 未公表 |
| H3 共通のイメージ・テンプレート・展開ツールの汚染 | 新規作成したVMにも同じ不正プログラムがある。イメージの署名・ハッシュの不一致 | 未公表 |
| H4 顧客VMごとの認証突破（漏えいした認証情報・総当たり・使い回し） | 台ごとのログイン失敗・成功の履歴。**台によって侵入時刻がばらける** | 未公表 |
| H5 外部の取引ツール・ソフトウェアのサプライチェーン | 影響が特定のソフトを入れた台に集中。そのソフトの配布元の改ざん | 未公表 |

使い方の例を挙げます。もし続報で「不正プログラムが**全て同一のファイル**で、**ほぼ同時刻**に設置された」と出れば、H1〜H3（共通の仕組み）が強まり、H4（個別突破）は弱まります。逆に「侵入時刻が台ごとに数週間ばらけている」なら、H4が強まります。

### 攻撃手法の参照モデル（MITRE ATT&CK）

一般的なクラウド型RDP環境への攻撃を、ATT&CKの技術に対応づけます。**GMOで観測された手法ではなく、考え方の整理**です。

| 段階 | ATT&CK技術 | この事件に当てはめた論点 |
| --- | --- | --- |
| 初期侵入・永続化 | T1078 Valid Accounts | 正規アカウントの悪用か。管理側・顧客側のどちらか |
| 横展開 | T1021.001 RDP | VM間・VM→顧客PCの接続。共有ドライブが経路だという推測は未確認 |
| 資格情報の入手 | T1555 Credentials from Password Stores | 取引ツールや保存パスワードの読み取り。第2報の「閲覧された可能性」に対応 |
| 収集・持ち出し | T1005 / T1048 | 「情報が外部に持ち出された事実」（第4報） |
| 影響 | T1486 Data Encrypted for Impact | 予告されたが**確認されていない**（10/27時点） |

### STRIDEでの整理

STRIDE（なりすまし・改ざん・否認・情報漏えい・サービス拒否・権限昇格）で、この事件を構造化します。

| STRIDE | 今回の事件での現れ方 | 公表状況 |
| --- | --- | --- |
| Spoofing（なりすまし） | 盗まれた口座認証情報での証券会社へのログイン | 不正操作の報告あり（件数未公表） |
| Tampering（改ざん） | サーバーへの不正プログラム設置 | 確認済み |
| Repudiation（否認） | 誰がいつ何をしたかが追えるか | 不明（ログの状況は未公表） |
| Information disclosure（情報漏えい） | 顧客情報の持ち出しと公開 | 確認済み（件数未公表） |
| Denial of service（サービス拒否） | 全プランの停止（被害拡大防止のための自発的な停止） | 確認済み |
| Elevation of privilege（権限昇格） | 管理側への到達があったか | 不明 |

## 経営層へ: 取引ツールをクラウドで動かすとき、どこまでが自社のリスクか

### 責任分界は「どこまで契約に書いてあるか」で決まる

クラウド事業者のサービスは、通常、**事業者が基盤の安全に責任を持ち、利用者が中身（データ・認証情報・設定）に責任を持つ**という分担です。ただし、この線引きは、サービスと契約ごとに違います。今回のように「基盤側の問題」が疑われる場面でも、**利用者が中に置いた認証情報の扱いは、利用者の判断**です。

| 項目 | 提供者の責任（一般論） | 利用者の責任（一般論） |
| --- | --- | --- |
| 基盤の更新・脆弱性対応 | ○ | — |
| 管理者権限の管理と監査ログ | ○ | 開示を求める |
| 顧客環境の分離 | ○ | 契約・仕様で確認 |
| VM内のOS・ソフトの更新 | サービスによる | ○（多くの場合） |
| VMに保存する認証情報 | — | ○ |
| 取引口座側の防御（2FA・IP制限・通知） | — | ○ |
| 停止時の代替手段 | — | ○ |

### 意思決定の問い三つ

1. **書面で確認できるか**: 管理者権限、顧客環境の分離、ログの保存期間と開示、事故時の通知時間、補償範囲が、契約と仕様書に書いてあるか。口頭の説明は根拠になりません。
2. **止まったとき、続けられるか**: 今回は全プランが10月21日から停止し、11月1日時点で再開日が示されていません。取引を止められない業務なら、**別の事業者・別の方式で動かせる手順**を、停止の前に用意しておく必要があります。
3. **侵害を前提に、被害を閉じ込められるか**: 一つの口座の侵害が、全口座・全資産に及ばない構え（口座ごとの権限・限度額・通知）にできているか。

補償の範囲にも注意が要ります。GMOの補償は、不正と判断した取引の**実現した損失**が対象で、相場変動による損失・得られたはずの利益・間接損害は含まれません。補償は、損害の全額を保証するものとは限りません。

## エンジニアへ: どの境界を、どの設定・ログ・テストで確かめるか

ここからは、自己所有のAWS環境で実行できる、**読み取り専用の確認**を示します。自分のアカウント以外では実行しないでください。また、出力には識別子が含まれるので、共有する前に必ず確認してください。

### 1. 入口: RDPを不特定多数に開けていないか

```bash
# 3389番ポートを 0.0.0.0/0 に開けているセキュリティグループを列挙（読み取りのみ）
aws ec2 describe-security-groups \
  --filters Name=ip-permission.from-port,Values=3389 \
            Name=ip-permission.cidr,Values=0.0.0.0/0 \
  --query 'SecurityGroups[].{id:GroupId,name:GroupName}' --output table
```

結果が空でなければ、インターネットから直接RDPを受けています。公開しない構成（Systems Manager Session ManagerやFleet Manager、VPN、ゲートウェイ経由）への切り替えを検討してください。

**結果が空でも、安全とは限りません。** このフィルタは、3389番を単独で指定したIPv4のルールだけを拾います。全トラフィックを許可するルール（プロトコル `-1`）、`3000-4000` のような範囲指定、IPv6の `::/0`（`ip-permission.ipv6-cidr` で別に調べます）、ほかのリージョンやアカウントは見ていません。

### 2. 管理側の権限: 長期の認証情報とMFAの欠落

```bash
# 認証情報レポートを取得する（読み取りのみ）
aws iam generate-credential-report >/dev/null
report=$(aws iam get-credential-report --query Content --output text | base64 -d)

# (a) コンソールのパスワードがあるのに、MFAが無いユーザー
#     列: user, password_enabled, mfa_active
echo "$report" | awk -F, 'NR==1 || ($4=="true" && $8=="false") {print $1","$4","$8}'

# (b) 有効なアクセスキー1と、その最終ローテーション日（古いものを探す）
#     列: user, access_key_1_active, access_key_1_last_rotated
echo "$report" | awk -F, 'NR==1 || $9=="true" {print $1","$9","$10}'
```

(a) にユーザーが出る、または (b) に長く更新されていないアクセスキーが出れば、**境界C（管理側）の入口**が弱いということです。**出力が空でも、安全とは言えません。** ルートアカウントの行は `password_enabled` が `not_supported` なので (a) に出ません（ルートのMFAは別に確認します）。2本目のアクセスキー（`access_key_2_*` 列）やIAM Identity Centerのユーザーも、このコマンドは見ていません。今回の件で「管理側の権限と資格情報」が論点になるのは、一つの管理権限が多数の環境に届くからです。

### 3. セッションの失効: 今動いている接続を把握できるか

```bash
# 有効なSession Managerのセッション一覧（誰が、どのインスタンスに）
aws ssm describe-sessions --state Active \
  --query 'Sessions[].{owner:Owner,target:Target,start:StartDate}' --output table
```

侵害の疑いが出たときに、**全セッションを一括で切れる**か、切る手順があるかを、平時のうちに試しておきます。利用者向けのGMOの案内にも「ログイン中の全セッションを切断」があります。

### 4. 監査ログ: 管理操作を後から追えるか

```bash
# 直近のコンソールログインを確認（読み取りのみ）。見慣れない接続元がないか
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=ConsoleLogin \
  --max-results 20 \
  --query 'Events[].{time:EventTime,user:Username}' --output table
```

CloudTrailが全リージョン・全アカウントで有効か、ログが**改ざんされにくい別アカウント**に保存されているか、保存期間は十分かを確認します。原因仮説の表の「管理操作の監査ログ」は、これが無いと**誰も検証できません**。

### 5. 検知と外向き通信（Egress）

- **EDR**は、VM内の不審な子プロセス・認証情報の読み取り・見慣れない外向き通信を検知します。ただし、**管理基盤そのものの侵害**は、VM内のEDRでは見えません。管理操作のログと、別系統の監視が要ります。
- **Egress制御**は、顧客VMから**許可した宛先だけ**に出られるようにします。取引ツールの用途なら、証券・FX会社のサーバーと更新用の宛先に限定できます。これは、盗んだ情報を外へ送る・攻撃者が口座へ入るための中継にされる、の両方を難しくします。
- **異常な管理操作**（短時間に多数のVMを操作、深夜の権限変更）は、しきい値ではなく**ベースラインからのずれ**で警報にします。

## インシデント対応: 何を、どの順で

NIST SP 800-61 Rev.3は、事前の準備から事後の改善までを一つの循環として扱います。今回のような事案での要点は次のとおりです。

1. **証拠の保全を、封じ込めより先に（または同時に）**: 停止・再起動・削除の前に、メモリ・ディスクのスナップショット・ログを確保する。GMOが全サーバーを停止したのは被害拡大防止の判断で、証拠保全の手順と両立させる難しさがあります。
2. **封じ込め**: 影響範囲が確定しない間は、**広めに止める**。今回、GMOは全プランを停止しました。
3. **資格情報の総入れ替え**: 侵害された可能性のある環境にあった認証情報は、**すべて漏えいしたものとして**扱い、別の端末から変更する（GMOの案内も同じ）。
4. **復旧**: 元のイメージをそのまま戻さない。侵入経路が不明なうちに再開すると、再侵害されます。
5. **再発防止と公表**: 原因・影響・対策・補償を、確認済みと未確認を分けて公開する。

## チェックリスト

### 利用者（クラウドで取引ツールを使う個人・事業者）

- [ ] サーバーに保存している口座・ツールの認証情報を洗い出し、不要なものは消した
- [ ] 取引口座で二段階認証・IP制限・約定通知・出金制限を使っている
- [ ] パスワードを他のサービスと使い回していない
- [ ] 接続に使うPC・スマートフォンのフルスキャンを定期的に行っている
- [ ] 提供者が停止したときの代替手段と手順がある
- [ ] 取引履歴と残高を、サーバーとは別の端末から定期確認している

### 提供者・インフラ担当者

- [ ] 管理基盤への操作は個人に紐づく一時権限で、共有の常時管理者がない
- [ ] 管理操作の監査ログが、改ざんされにくい別の場所に、十分な期間残る
- [ ] 顧客VM間・顧客VMと管理基盤の間の通信が、既定で拒否されている
- [ ] 共通イメージ・展開ツールの完全性を検証している（署名・ハッシュ）
- [ ] 全セッションを一括で失効させる手順を、訓練で試している
- [ ] 顧客VMからの外向き通信を、許可制で記録している
- [ ] 社内の指摘（脆弱性診断・レッドチーム）の対応に、期限と責任者がある

## 現時点の結論と、今後の確認事項

- **事実として言えること**: 不正プログラムの設置、顧客情報の持ち出し、攻撃者による公開、全プランの停止、取引口座への不正操作の報告があった。
- **まだ言えないこと**: 侵入経路、侵害された台数、被害額。「26,739件が侵害された」「約80億円の被害」はいずれも誤りです。
- **技術的な教訓**: 安全かどうかは、パスワード強度よりも、**管理権限・資格情報の置き場所・顧客環境の分離・セッション失効・監査ログ・外部サービスとの信頼境界**で決まります。保存した鍵は、強くても使われます。

次の続報で確認すべき点は、GMOの技術的な調査結果（侵入経路と「セキュリティ上の問題」の中身）、侵害確認数、再開の条件と日付、監督官庁への報告です。

## 自社のクラウド・認証・権限境界を点検したい方へ

筆者は、AWSのマルチアカウント設計、認証ハブ、最小権限のIAM、監査ログと検知の設計・実装を担当してきました。この記事のような視点で、**貴社のクラウドや認証基盤の「信頼境界」と「権限」を設計レビュー**することができます。

対応できること、できないことを先に書きます。

- **できること**: 構成図と設定をもとにした、管理権限・資格情報・環境分離・ログ・外向き通信の設計レビューと、優先順位つきの改善案
- **できないこと**: 今回のGMO事案のようなインシデントの**フォレンジック調査**。侵害の疑いがある場合は、まず専門のインシデント対応事業者に連絡してください
- 「完全に安全になる」とはお約束できません。見つかったことと見つからなかった範囲を、そのまま報告します

ご相談は、下のボタンの先から範囲と料金をご確認ください。