不正アクセス後に暗号資産交換所をどう再開するか｜再開の判断と機能を戻す順番

ある暗号資産交換所で不正アクセスが起き、出庫を含むサービスを止めました。原因と思われる脆弱性は塞ぎ、発生から24時間が経ちます。経営陣は「そろそろ再開できないか」と聞いてきます。CISOとSREは、再開してよいかの判断を任されます。

ここで時間の経過だけを理由に全機能を戻すと、次のような事態が起こりえます。

• 失効させ忘れたログインの状態（セッション）が残っていて、攻撃者がそのまま出庫できてしまう。
• 画面は閉じていたのに、APIや裏で動く処理が止まっておらず、出庫が進んでいた。
• 改ざんされたバックアップから戻したため、台帳の残高が正しくない。

どれも「塞いだ」「時間が経った」だけでは見つかりません。だから再開は、時間ではなく、確認がそろったかで決めます。侵入の経路を封じ、資産と台帳を確かめたうえで、機能ごとに判断します。残高の参照、入庫、取引、出庫と、取り返しのつきやすいものから順に戻します。異常を見つけたら、その機能だけを再び止められる作りにしておきます。

以下では、このCISOとSREが再開の判断を組み立てる順に見ていきます。ログインや本人確認の見直し、顧客への見せ方は、認証基盤やプロダクトの責任者が関わる部分です。

この記事でわかること

• 再開の前にそろえる6つの確認と、機能を戻す順番
• ログインの失効と再確認のしかた、台帳の突き合わせ方
• 再び止める条件の決め方と、演習で試すこと

再開は、時間ではなく確認がそろったかで決める

金融庁の金融分野におけるサイバーセキュリティに関するガイドラインは、復旧計画で扱うべきことを示しています。

• 復旧を判断する人と、判断の要素を整理する
• 被害を受けた機器の初期化と、正常に動くことの確認
• バックアップが改ざんされている可能性、復旧の手順
• 復旧した後の原因分析と、対応の評価

このガイドラインは、暗号資産交換業者も対象です。これを見ると、「発生から24時間経過した」「原因と思われる脆弱性を塞いだ」だけでは、再開の条件として足りないことが分かります。

そこで再開の判定は、インシデント管理ツールの「解決済み」ではなく、機械で確かめられる証拠に結びつけます。再開を承認するときは、そのとき確かめた証拠一式を1つの記録にまとめて残します。

• 攻撃の痕跡（IoC）が見つからないこと、署名済みのビルドのハッシュ値
• 台帳の突き合わせの結果、失効させたセッションの件数、顧客の再確認の状態
• 監視ルールの版、承認者

あとで「なぜ開けたのか」を説明できるようにするためです。証拠が後から更新されても、過去の承認は書き換えません。新しい記録を作ります。

再開の前に必ずそろえる6つの確認

どの機能を戻すときも、次の6つがそろっていなければ開けません。

NIST SP 800-61 Rev.3は、インシデント対応を、検知・対応・復旧を含む継続的なサイバーリスク管理に組み込む指針です（NIST公式）。この考え方に立つと、復旧はインシデントの終わりではありません。監視の結果によっては、再び封じ込めへ戻る輪として設計します。

どの機能から、どの順で戻すか

戻す順番は、画面の単位では決めません。その操作が資産や権限にどれだけ影響するか、失敗したときに取り消せるかで決めます。次は標準的な最初の案です。侵害の範囲によって、順番を入れ替えます。

• 段階0 切り離し：ステータスページ、サポート、顧客からの緊急凍結の受付を開ける。
  • 開ける前に：連絡の経路が、侵害された系統から切り離されている
  • 止める・巻き戻す条件：告知の改ざん、問い合わせの本人確認が成り立たない
• 段階1 参照：残高・履歴の読み取り、通知設定の確認を開ける。
  • 開ける前に：読み取り専用の複製と顧客元帳が合っている。キャッシュに誤ったデータが紛れ込んでいない
  • 止める・巻き戻す条件：表示した残高の差、ほかの顧客のデータが見える、認証の異常
• 段階2 入庫：対象のネットワーク・資産の入庫の検知を開ける。
  • 開ける前に：ノードとインデクサー（ブロックを読んで入出金を取り込む部品）が同期している。必要な承認数と確定、入庫先のウォレットの管理
  • 止める・巻き戻す条件：取りこぼし、二重計上、チェーンの再編についていけない
• 段階3 取引：取消のみから始め、指値、成行へと段階的に開ける。
  • 開ける前に：板・残高の予約・約定・手数料・清算の突き合わせ、上限
  • 止める・巻き戻す条件：残高がマイナス、約定の食い違い、待ち行列や約束した対応時間（SLA）からの外れ
• 段階4 出庫：知っているアドレス・少額・低リスクから開ける。
  • 開ける前に：再認証、顧客ごとのリスク、ウォレットの署名ルール、二者承認、送信の冪等性
  • 止める・巻き戻す条件：出どころの分からない署名、残高の差、不正利用のアラートの急増、監視の欠け
• 段階5 通常へ：上限・対象の資産・顧客のグループを広げる。
  • 開ける前に：決めた観測の期間、誤検知・顧客への影響・運用の負担が許せる範囲
  • 止める・巻き戻す条件：事前に決めた閾値を超えたら、直前の段階へ戻す

資産やネットワークは、まとめて開けません。機能・顧客のグループ・資産・ネットワークの組み合わせごとに、オン／オフを切り替えられるようにします。出庫を開けるときも、知っている端末・知っている送付先・少額の顧客のグループから始めます。対象の額と1日の累計は、ウォレットの署名ルールでも制限します。

冒頭の2つめの事態のように、「画面を閉じた」だけでは、APIや裏で動く処理は動き続けます。そのため、入口、待ち行列を処理する仕組み、署名の仕組みの3か所で止められるようにします。

ログインの状態をどう切り、誰に何を確かめ直すか

認証の仕組みが影響を受けた場合は、ログインの状態をすべて洗い出し、サーバー側で失効させます。ブラウザのCookieだけでは足りません。

• 更新トークン、モバイルのセッション
• OAuthの認可、APIキー
• サポート担当者が代わりに操作するためのセッション

OWASPも、リスクの高い出来事の後の再認証と、期限切れ・ログアウトのときにサーバー側でセッションを無効にすることを勧めています（OWASP Session Management）。失効の処理は、対象の件数、成功・失敗、再試行、残ったセッションを突き合わせられるようにします。冒頭の1つめの事態を防ぐためです。

本人の再確認で求める証拠は、顧客によって違います。たとえば次の顧客では、必要なものが違います。

• 侵害の兆しがなく、残高を見るだけの顧客
• 認証情報の変更があった顧客、乗っ取りの通報がある顧客
• 出庫を再開する顧客

本人確認書類の出し直しを全員に一律に求めると、それを装った偽のサポートや、情報を集める機会を攻撃者に与えることにもなります。そこで、侵害の確からしさと操作のリスクで顧客を分けます。すでに信頼している連絡経路、過去に確かめた証拠、追加の認証器、必要に応じた再確認を組み合わせます。復旧の手順そのものも、不正利用の監視の対象にします。

NIST SP 800-63B-4は、侵害された認証器をすぐに止めて無効にし、アカウントを回復するときは独立した通知を送ることを示しています。また、手で入力するOTPはフィッシングに強くないと説明しています。WebAuthnは、確かめる側の名前に結びつける仕組み（verifier name binding）によって、フィッシングに強い例です（NIST SP 800-63B-4）。

そのため、Passkeyはフィッシングに強い再認証に役立ちます。ただし、漏れたセッション、改ざんされた台帳、侵害された署名の経路までは直しません。既存のセッションを残したまま新しい認証器を登録させたり、弱い回復の手順からPasskeyを足せたりすれば、効果は落ちます。

W3C WebAuthn Level 3も、1台の端末だけの認証資格情報（credential）は端末をなくしたときに弱いため、追加の認証器かアカウント回復の手順を用意するよう示しています（W3C WebAuthn Level 3）。再開の確認では、次のものを管理します。

• 登録する前の本人の確かさ、追加・削除の通知
• 複数の認証器、回復の手順
• 出庫の前の追加の認証（ステップアップ認証）

WebAuthnの仕様と導入の範囲は、PasskeyとWebAuthnの実装解説で扱っています。

資産と台帳は、差をなくすより、差を説明できるようにする

交換所には、確定するタイミングの違うお金の記録がいくつもあります。顧客元帳、注文で押さえた残高、入出庫の待ち行列、ホット・ウォーム・コールドウォレット、未確定のチェーン上の取引、法定通貨の口座などです。そのため、全部の残高を単純に足して合わなくても、それだけで異常とは限りません。

差は、原因ごとに分けます。比べた時点、為替・手数料、未確定の取引、社内の振替、チェーンの再編、保留・凍結です。差ごとに、担当者と解消の期限を持たせます。

再開の判定の記録には、少なくとも次のものを残します。

• データを取り出した時刻、ブロック高と確定の状態、ウォレットのアドレスの一覧
• 保留中の取引、二重に実行された疑いのあるもの、顧客元帳の総額
• 差の理由、突き合わせのスクリプトのコミットとハッシュ値、承認者

突き合わせの後に入庫の取り込みや注文の処理を動かすと、記録は古くなります。そのため、各段階を開ける直前に、差を計算し直します。鍵と承認の責任の分け方は、マルチシグの利点とリスクも参考にしてください。

再開・停止の操作を、記録に残る形で行う

担当者が管理画面でフィーチャーフラグを直接切り替えるだけでは、根拠、対象、期限、承認が残りません。そこで再開の要求を記録として保存し、許された切り替えだけを実行します。記録の形は後半に載せています。

実行する側は、古い記録、期限切れの承認、対象外の資産、上限の超過を拒否します。緊急停止は「全部止める」だけでなく、細かく止められるようにします。

• 出庫だけを止める、対象のネットワークだけを止める
• 新しい注文を止めて、取消のみに戻す
• 特定の顧客のグループを、本人の再確認へ戻す

停止の操作の権限が乗っ取られることにも備えます。再開には二者承認を求め、緊急停止は1人ですぐ実行できるようにして、両者を分けます。

G7サイバー・エキスパート・グループは2026年7月28日に、再接続枠組みのベストプラクティスに関する技術的付属文書を公表しました。金融庁は8月4日に、その仮訳を載せています。侵害された環境を信頼できる系統につなぎ直す判断は、単なる稼働の再開ではなく、独立した統制の課題です。

交換所に当てはめると、つなぎ直す順番そのものを計画することになります。顧客API、市場データ、台帳、ウォレット、委託先の依存関係を図にし、どの順でつなぎ直すか、どこまでを信頼するかを記録します。

いつ再び止めるかを、前もって決めておく

「異常があれば止める」と書いておくだけでは、何を見て、どこで止めるかが決まりません。そこで段階ごとに、平常時の基準値と、今回の攻撃の仮説から指標を選びます。そのうえで、閾値、評価する時間の幅、データが欠けたときの扱い、止め方、判断する人を決めます。決まった数値は、自社のデータで過去を検証して（バックテスト）決めます。

• 認証：新しい端末の率、回復の申請の率、認証器の追加・削除、失敗の率、サポート経由の変更、失効させ残したセッションの数
• 台帳・取引：残高の差、押さえた残高のマイナス、注文・約定の食い違い、冪等キーの重複、待ち行列の滞留時間
• 入出庫：インデクサーの遅れ、突き合わせの済んでいない入庫、署名の要求数と送信数の差、知らないアドレスへの出庫、ウォレットの残高
• 基盤：IoCの再検出、特権の操作、秘密情報の利用、外への通信、設定の差、ログの欠け
• 顧客への影響：ログインできない、誤った凍結、問い合わせの滞留、異議申し立て、告知と実際の状態の食い違い

アラートの通知の経路が欠けたときは、「異常なし」とは受け取りません。安全かどうか分からないので、安全側の段階へ戻します。ただし、全部を止めることだけを安全側とはしません。影響を受ける機能だけを絞って止める作りにします。

出庫だけを申請ごとに止め、根拠を確かめて解除する仕組みは暗号資産交換所の出庫制限設計で扱っています。セキュリティ全般の脅威の整理は、Web3セキュリティの基礎も参考にしてください。

顧客の回復も、再開の一部として進める

技術的に戻っても、次のような状態なら、サービスは回復していません。

• 正当な顧客が凍結されたままになっている
• 問い合わせの本人確認が成り立っていない
• 補償や異議申し立ての窓口が分からない

顧客の画面には、次のことを出します。使える機能、制限の理由の種類、次に確かめること、最後の更新時刻、正規の連絡手段、身に覚えがないときの緊急凍結です。

サポート担当者には、本人確認を飛ばして認証器や送付先を変えられない権限の作りと、ケースごとの監査ログが要ります。認証の回復、残高の訂正、取引の取消、出庫の回収、補償、当局・捜査機関との連携は、それぞれ別の判断です。顧客の回復の期限と責任者は、技術的な復旧の指標と並べて管理します。

演習では、再開より巻き戻しを試す

金融庁は2026年4月3日に、暗号資産交換業等におけるサイバーセキュリティ強化に向けた取組方針を公表しました。インシデント対応計画・コンティンジェンシープランと、暗号資産交換業者向けのシナリオを含む演習を重視しています。演習では「全サービスが戻った」で終えず、次の失敗をわざと起こします。

• 復旧の後に同じIoCを再び見つけ、対象のネットワークだけを止められるか
• セッションの失効が一部失敗し、残ったトークンを特定できるか
• 台帳の突き合わせの後に遅れた入庫が届き、差を計算し直せるか
• 署名の要求がタイムアウトし、送り直さずに今の要求を照会できるか
• Passkeyの登録の直後にアカウント回復の通報が届き、出庫を止められるか
• 外部の監視サービスが欠け、直前の段階へ自動・手動で戻せるか
• 顧客への告知とフィーチャーフラグが食い違ったとき、誰が直すか

合格の条件には、止めるまでの時間だけでなく、次のことも入れます。誤って止めた顧客の数、解除までの時間、判断の記録がそろっているか、当番以外の担当者でも運用手順書どおりに実行できるかです。

実装する人向けの詳細

ここからは、この交換所で再開の仕組みを作るSREと開発者向けです。

再開判定のスナップショット

再開の証拠一式は、1つの再開判定スナップショット（recovery_snapshot_id）に固定します。後から証拠が更新された場合は過去の承認を書き換えず、新しいスナップショットを発行します。

再開要求のレコード

フィーチャーフラグは、機能（capability）×顧客群（customer cohort）×資産（asset）×ネットワーク（network）に分けます。再開要求は次のようなレコードとして保存し、許された遷移だけを実行します。evidenceは検証した証拠を表します。

{
  "recovery_snapshot_id": "rec_...",
  "capability": "withdrawal",
  "scope": {"cohort": "verified_low_risk", "asset": "...", "network": "..."},
  "from": "DISABLED",
  "to": "LIMITED",
  "evidence": ["ledger_check_...", "session_revoke_...", "monitor_test_..."],
  "limits": {"per_request": "...", "daily_total": "..."},
  "stop_conditions_version": "stop-v4",
  "approved_by": ["security", "operations"],
  "expires_at": "..."
}

関連する記事

• 申請ごとの出庫の止め方と、解除の根拠：暗号資産交換所の出庫制限設計
• 業者間の疑わしいアドレスの共有：暗号資産AMLの情報共有とトラベルルール実装
• ハードフォーク時の入出庫の停止と段階的な再開：ハードフォーク時の取引所対応
• 制度改正に合わせたシステムの準備：暗号資産の金商法改正と事業者の実装準備

XTELAができること

私たちは、交換所の依存関係と脅威の整理から、再開の関門、機能別のフィーチャーフラグと緊急停止、セッション失効、台帳照合、ウォレットの署名ルール、監視と監査ログまでを、障害注入を含むPoCとして設計・開発します。貴社の再開判断を「証拠で開ける」形にするため、再開判定スナップショットと停止条件を一緒に定義し、演習で巻き戻しまで確かめます。当局報告や補償の法的な判断は弁護士と連携して進めます。再開設計を相談したい場合はお問い合わせください。

主要参考資料

• 金融庁：金融分野におけるサイバーセキュリティに関するガイドライン（2026年8月12日確認）
• 金融庁：暗号資産交換業等におけるサイバーセキュリティ強化に向けた取組方針（2026年4月3日公表、英語版を2026年7月23日に掲載。2026年9月24日確認）
• 金融庁：G7再接続枠組みのベストプラクティスに関する技術的付属文書（G7公表2026年7月28日、金融庁の仮訳掲載2026年8月4日。2026年9月24日確認）
• NIST SP 800-61 Rev.3：Incident Response Recommendations and Considerations（2025年4月）
• NIST SP 800-63B-4：Authentication and Lifecycle Management（2025年7月）
• W3C：Web Authentication Level 3（2026年5月 Candidate Recommendation Snapshot）
• OWASP：Session Management Cheat Sheet（2026年8月12日確認）

資料の確認日と注意

一次資料は2026年8月12日に確認しました。金融庁の取組方針とG7の付属文書は、2026年9月24日に確かめ直しています。ここに書いたのは、その資料にもとづく技術・業務の設計の整理です。補償、届出、凍結・解除などの判断は、侵害の範囲や個別の事情で違います。最新の公式資料をもとに、社内のコンプライアンス担当者や弁護士と確かめてください。