← RECON トップへ戻る ・ 記事一覧

GMOグループ連続侵害(3)——補償の読み方と、責任の線引き

・ 最終更新:

2026年10月27日 15時更新:公式の第10報(13:55時点)・第11報(14:55時点)を反映した。公開情報に含まれた顧客への追加の見舞金、攻撃者に支払わない方針、新たに加わった利用者への注意を追記している。

被害の中身が見えてくると、次に問われるのは「誰が何を負担するのか」だ。第4報で示された補償を読み、事業者・利用者・取引先の責任がどこで分かれるかを整理する。最後に、設計上の対策を筆者の提案として示す。

第4報の補償を条件ごとに読む

項目 第4報の記述
お見舞金 現在のサービス利用者全員に、金銭的被害の有無を問わず一律5,000円。受け取り手続きは10月30日(金)23:59までにメールで案内
公開情報に含まれた顧客への追加の見舞金(第10報) 公開された情報に自分の情報が含まれると同社が確認した顧客に、5,000円とは別に、緊急会議で検討を開始した段階。金額・条件・時期は示されていない
不正取引の損失補償 同社が本件の不正アクセスによると認めた不正取引の実現損失(差損・手数料等)が対象
補償の対象外 市場の変動による損失、得られたはずの利益、その他の間接的な損害
取引所の返金との関係 返金があればその額を差し引いて支払う。返金に応じない場合も、対象損失を支払う。同じ損失について双方から受け取った場合は、返還を求めることがある
申請方法 申請方法、必要書類、受付期間、支払い時期は11月6日(金)までに案内
サービスの今後 現行基盤は再開しない。代替サービスは乗り換え後6か月無償
ランサムウェア被害者(第9報) 問い合わせ窓口で被害を確認のうえ、同等性能の新しいPCを提供

読み方のポイントは3つある。

  1. 「本件によると認めた」が起点:対象の判断は、GMOが取引記録を個別に確認して行う。利用者が「不正だった」と申告するだけでは決まらない
  2. 「全額補償」ではない:対象は実現損失(差損・手数料等)だ。市場の変動による損失は含まれない
  3. 二重取りの防止:取引所の返金と併せて、同じ損失を重ねて受け取れない設計だ

条件の細部は、11月6日までに示される予定の申請案内で決まる。追加の見舞金は、公開された情報に自分の情報が含まれていると同社が確認することが前提になる。対象になるときは、GMOから個別に連絡が来る(第10・11報)。

補償とは別に、第11報はGMOの対応方針を示した。攻撃者の要求には応じない。理由として、応じても情報の削除や不正利用の防止が保証されないこと、犯罪者への資金提供になって新たな攻撃を助長することを挙げている。警察等の関係機関とは連携して対応しているという。

第10・11報で加わった利用者への注意

第10報と第11報で、公式が利用者に求めた点を整理する。

この連載も、公開先の名称やリンクを載せない。

責任の線引き

この事案の責任は、少なくとも3層に分かれて見える。

3層の間には隙間がある。事業者は「サーバー内の情報」、取引先は「口座の認証」、利用者は「端末の管理」に責任を持つ。そのどこにも属さない領域、つまりサーバー上に置かれた認証情報と、ログイン済みのまま維持されるセッションを、誰が失効させるのかが明確でなかったと読める。第5報が利用者に「全セッションの切断」を求めているのは、その作業が利用者側に委ねられているということだ(筆者の見方)。

能動的サイバー防御の要請をどう読むか

第4報でGMOは、本件を「能動的サイバー防御の『発動第1号』事案」と位置づけ、政府関係機関への緊急要請を進めると述べた。10月25日には、グループ代表のブログ「今こそ官民連携で日本を守ろう」の公開が告知されている。

ここで書けるのは「GMOが要請した」までだ。政府が措置を発動したとも、受理したとも、公表情報にはない。「発動第1号」はGMO自身が使った表現であり、制度上の発動が確認された記述と読んではいけない。

設計への示唆(筆者の提案)

以下は公式の見解ではない。今回の構造から、一般に導ける対策だ。

利用者側 - 取引口座の認証情報を、リモートの環境に保存しない運用にできないか検討する。保存せざるをえない場合は、パスワードを取引専用にして使い回さない - 自動売買に必要な権限と、資金移動・出金に近い権限を切り分ける。取引ツールには、閲覧専用のパスワードを持つものがある(EAの稼働には発注権限が要るので、全面的な代替にはならない) - 接続元のPCは、取引専用の端末にして、日常の閲覧や仕事と分ける - RDPの接続設定は、ドライブやクリップボードのリダイレクトを既定どおり無効にする(Microsoftの既定は、ドライブのリダイレクトをしない)

事業者側 - 侵害の検知から、利用者側のセッションや認証情報を事業者が止められる手段を用意する - 公表を更新するときは、前の報の表現がどう変わったかを明示する(初報の「閲覧された可能性」→第4報の「持ち出しを確認」の経路が追えるようにする) - ConoHa WINGの13日のような検知の遅れを、公表のたびに説明できる形で記録する

まとめ

公式が新しい報を出したら、この連載は報と時刻を添えて更新する。

出典