未来を形作るテクノロジーの深掘り記事。

取引所のセキュリティ、失敗の原因は暗号ではなく速度

Binanceの63億ドル流出は20分で完了した。取引所セキュリティは暗号技術ではなく速度で破綻する。速い窃盗を本当に止める方法を解説。

小さな金庫の扉から、光る価値の流れが溢れ出している。遠くに立つ人影は、気づくのが遅すぎた様子で見ている。
この強奪は金庫の扉を破ったものではない。認可された正規の出金が、誰も反応できない速さで流れ出たのだ。

20分。報道によれば、攻撃者がBinanceから63億ドルを引き出すのにかかった時間だ。多くのインシデント対応チームがビデオ通話を招集するより短い。この件から一つだけ教訓を持ち帰るなら、こう覚えてほしい。暗号取引所のセキュリティは数学では破綻しない。署名はおそらく正しかった。鍵は鍵として正しく動いた。失敗の本質は速度だ。現代の取引所は、侵害された一つの認証情報を、人間が「ちょっと待って」と言うより速く、数十億ドル分の取り消し不能な決済に変えてしまう。

初期の報道では、侵入口は侵害された従業員のデバイスだとされている。取引所は損失を補填し、法執行機関と協力すると表明した。ただ、それで安心してはいけない。攻撃者と63億ドルの間に立っているのがノートPC一台だというのは、セキュリティアーキテクチャではなく、いずれ起きる事故の予告編にすぎない。この10年、私たちはこのスタックの間違った層を固めてきた。今回の強奪は、そのツケが回ってきた出来事だ。

20分という時間は、運が悪かった一日ではなく設計上の欠陥だ

記事の興奮を誘う部分、つまり「20分!」は、実は最も意外性の少ない部分だ。主要な取引所の窃盗はほぼすべて同じ形をとる。数か月、ときには数年にわたる静かな準備があり、その後に数分という実行の時間が訪れる。2016年のバングラデシュ銀行強盗も同じ構図だった。攻撃者は数か月間銀行のネットワーク内に潜伏し、その後一気に不正なSWIFTメッセージを送信した。狙っていたのは10億ドルだったが、実際に奪えたのは8,100万ドルだけだった。それも、コルレス銀行の一人の鋭い従業員が違和感に気づき、残りを止めたからにすぎない。たまたま運が味方しただけだ。運は統制ではない。

暗号取引所が特別で、かつ脆弱なのは、伝統的金融ではほとんど同時に成立しない三つの性質が重なっているからだ。決済は最終的で、取り消しボタンは存在しない。決済は高速で、確認のための猶予もない。そして決済はベアラー型で、署名能力を持つ者が資金を持つ。電信送金なら、コルレス銀行への一本の電話で凍結できる。しかし署名済みのブロックチェーン取引は、署名を取り消すことができない。攻撃者が取引所の署名経路に入り込んだとき、彼らは金を盗んでいるのではない。金を瞬間移動させているのだ。

つまり、20分という数字がスキャンダルなのではない。スキャンダルは、システムの設計がそもそも20分で十分な構造になっていることだ。アーキテクチャが、昼休みより短い時間で数十億ドルをビルの外に出せるなら、攻撃者が速くある必要はない。速さを用意したのはあなたの側だ。

より良い暗号技術があっても、取引所は救えなかった

数十億ドル規模の窃盗が報じられるたびに、反射的な反応は決まっている。鍵管理がずさんだったに違いない、HSMを使うべきだった、MPCを使うべきだった、マルチシグの定足数をもっと増やすべきだった、と。業界はこの教訓をよく吸収した。今では主要な取引所の多くが本当にHSMやMPCを使っている。それでも窃盗は続いている。前提が間違っているからだ。暗号技術が答えられるのは「このリクエストは本物か」という一つの問いだけだ。強奪の最中に本当に重要な問い、「この本物のリクエストは実行されるべきか」には答えられない。

侵入口が侵害された従業員のノートPCだとしよう。有効な認証情報、有効なMFAトークン、出金オーケストレーション層への正当なアクセスを持つセッションだ。その場合、システムが生成するすべての署名は暗号的には完璧だ。HSMは、それを操作している人間が遠隔操作されていることを知らない。攻撃者が参加者の十分な数のエンドポイントを侵害すると、MPCも役に立たない。6億2,500万ドルのRoninブリッジ窃盗がまさにそうだった。9つのバリデーター鍵のうち5つが、数学を破られたのではなく、侵害されたマシンを通じて奪われたのだ。ビットコイン自体が「ハッキング」されたという話でさえ、精査すれば崩れる傾向がある。私たちも話題になったPHPのBitcoinエクスプロイトを検証したとき、暗号技術がそもそも弱点ではないとわかった。弱点はいつも、信頼されたシステムが、運転すべきでない人物によって設計どおりに使われる瞬間だ。

暗号技術が守るのは鍵だ。鍵が設計どおりに使われる瞬間を守る数学は、どこにもない。

監視では20分のクロックに勝てない

二つ目の反射的な対策は検知だ。より良い監視、異常検知、取引を見張るAI。取引所にはこれらが実際にあり、そしてそれは発火する。だからこそ、今回の強奪が20分かかったとわかるのだ。しかし検知と防止は、レイテンシの予算が異なる別物だ。成熟したSOCでも、高精度のアラートから出金を止める権限を持つ人間に届くまでの時間は、良い日でも数十分単位になる。オンコールを呼び出し、誤検知でないか確認し、大きなレバーを引ける人にエスカレーションし、承認を得て、ようやくレバーを引く。攻撃者の作戦全体は、そのループの中に十分収まる余裕がある。

これは誰も価格に織り込みたがらない非対称性だ。防御側は営業時間に合わせて人員を配置する。一方で攻撃者は、まさに対応時間が落ちる週末や祝日を狙う。アラートが即座に鳴ったとしても、アラートはキルスイッチではない。キルスイッチは人間だ。暗号以外の世界でも同じ映画を見てきた。バングラデシュ銀行の窃盗を止めたのはシステムではなく人間であり、しかもその人間がほとんどいなかった。最後の砦が「ダッシュボードを誰かが見ていてくれるだろう」なら、最後の砦は存在しない。この推論は取引所の枠を超えて当てはまる。私たちは自律型エージェントにとって監視よりも封じ込めが優れている理由について似た議論をした。介入する能力のない観測は、ただ自分の失敗を記録しているにすぎない。

夜、赤いアラートを点滅させるモニターの壁の前に、ぽつんと置かれた無人の椅子。
検知は時間通りに発火した。問題は、アラートと介入の間に起こるべきすべての出来事にある。

損失の補填は解決ではなく、問題の認めにすぎない

Binanceは全損失を補填すると表明している。そしてこの会社は、以前にもそれを実行している。2019年に7,000BTCがハッキングされた後も、SAFU保険基金によって利用者は全額補償された。当時も市場はほとんど動じず、今回も同様だろう。だが、「補填する」というのがアーキテクチャ的に何を意味するか、率直に言おう。何も意味しない。保険は失敗を吸収するためのバランスシート上の仕組みであって、失敗を防ぐためのエンジニアリングの仕組みではない。破局を経費の一行に変えるので、取引所にとっては合理的だが、次の攻撃者にはまったく無関係だ。彼らは、まったく同じ20分の窓に直面しているのだから。

業界が公言したがらない規模の問題もある。63億ドルの損失は、暗号資産セクター全体で利用可能な保険能力を何倍も超える。地球上でこれほどの損失を自己保険できる取引所は、ほんの一握りしかない。それより小さな取引所、つまり意味のある顧客資金を保有する会社が数百もあるが、それらは暗黙のうちに「自分は狙われないだろう」と賭けている。これこそ、銀行業では預金保険と健全性規制が埋めるために存在するギャップだ。「Binanceは過失によるセキュリティ不備で起訴されるべきでは?」という直感は、粗削りではあっても、本物の何かを指している。一世紀前、私たちは他人の金を預かる機関が自分でリスク許容度を選んでよいわけではないと決めた。暗号業界は15年かけて、その決定を一件一件の強奪を通じて蒸し返してきた。

サーキットブレーカー:市場がすでに発明した解決策

もどかしいのはこの点だ。金融業界はこの問題を数十年前に解決している。ただ、別の方向からだ。1987年の大暴落の後、株式取引所は、価格が急激に動きすぎたときに取引を停止するサーキットブレーカーを導入した。停止によって詐欺や暴落がなくなると主張する人はいない。狙いは、暴走するプロセスを監督されたプロセスに変え、人間の判断のための時間を稼ぐことだ。同じ論理は出金にも当てはまる。そしてそれは、呆れるほど単純だ。署名がどれほど正しくても、どの取引所も短い時間枠で保有資産のごく一部以上を外に出せてはならない。

出金サーキットブレーカーは、署名経路に置かれたポリシーエンジンであり、速度そのものを異常として扱う。重要なのは、リクエストが正当かどうかを問わないことだ。すべてのリクエストは正当かもしれないし、悪意があるかもしれないと仮定し、それでも影響範囲を上限で抑える。

from dataclasses import dataclass
from datetime import datetime, timedelta
@dataclass
class WithdrawalPolicy:
window: timedelta = timedelta(minutes=30)
max_outflow_pct: float = 2.0      # of hot-wallet balance per window
hard_freeze_pct: float = 5.0      # trip the breaker entirely
large_threshold_usd: float = 1_000_000
large_delay: timedelta = timedelta(hours=24)
class CircuitBreaker:
def __init__(self, policy: WithdrawalPolicy):
self.policy = policy
self.recent: list[tuple[datetime, float]] = []
self.tripped = False
def authorize(self, amount_usd: float, hot_balance_usd: float) -> str:
if self.tripped:
return "REJECT: breaker tripped, manual review required"
now = datetime.utcnow()
cutoff = now - self.policy.window
self.recent = [(t, a) for t, a in self.recent if t > cutoff]
outflow_pct = 100 * (sum(a for _, a in self.recent) + amount_usd) / hot_balance_usd
if outflow_pct > self.policy.hard_freeze_pct:
self.tripped = True
return "HALT: outflow exceeded safety threshold, withdrawals frozen"
if outflow_pct > self.policy.max_outflow_pct:
return "QUEUE: velocity limit reached, withdrawal delayed"
if amount_usd > self.policy.large_threshold_usd:
return f"DELAY: held {self.policy.large_delay} for review"
self.recent.append((now, amount_usd))
return "APPROVE"

今回の強奪の数字で、これが何をもたらすかを確認してほしい。ホットウォレットが63億ドルの10%だけを保有していたとしても、ホット残高の5%でハードフリーズをかければ、自動的な損失は約3,100万ドルに抑えられる。大変な一日ではあるが、存亡の危機ではない。さらに重要なのは、攻撃者の20分間のダッシュは、数日にわたる這うような進行に変わることだ。そうなれば、監視チームがようやく活躍できる。全体の目的は攻撃者を出し抜くことではない。人間が到着するまで時間を引き延ばすことだ。これは古典的な意味での防御的エンジニアリングだ。最悪の失敗が退屈なものになるようにシステムを設計する。

巨大な産業用ブレーカーのスイッチが落とされ、その背後の光るケーブル群が暗くなっている。
速度サーキットブレーカーは窃盗を止めるわけではない。窃盗を、人間が止められるほど遅くするのだ。

出金の遅延と、退屈な銀行業務の意義

サーキットブレーカーは速度を扱い、遅延は規模を扱う。従来の金融システムの秘密兵器は洗練さではなく、摩擦だ。電信送金は取り消せる。ACHには数日かかる。大口の移動は保留期間を発動し、別経路で既知の連絡先へのコールバックを行う。暗号資産は、即時の最終決済こそが製品だとして、そのすべてを取り払ってきた。しかし摩擦は、利用者が本当に気にしている取引体験に触れることなく、出金の境界で選択的に再導入できる。

  • 大口出金の時間ロック。 閾値を超えるものは、可視化されたキューで24時間待機させる。利用者はそれを見越して計画を立てられるが、攻撃者にはできない。遅延の1時間ごとに、侵害が発見されるまでの猶予が増える。
  • ホットウォレットの厳格な上限。 通常の出金で24時間に必要な分だけをオンラインに置く。多くの取引所では、資産の一桁%台の割合だ。コールドストレージの移動には、複数当事者・複数日にわたる手続きを必要とし、どの認証情報でも加速させることはできない。
  • 遅延を伴う送金先アドレスのホワイトリスト。 新しい出金先アドレスは、帯域外の確認を経て遅延後に有効化される。侵入中に送金先を入れ替えるという定番の手口を封じる。
  • 署名権限の分割。 どのエンドポイント、ロール、セッションも、どれほど認証されていようと、上限を超える金額は動かせない。影響範囲が小さければ、侵入口の重要性は下がる。これはLiteLLMのサプライチェーン事件が、開発者のマシンこそ最も脆い標的だとPythonエコシステムに教えた教訓でもある。
  • 負債を含めた準備金の公開証明。 窃盗対策そのものではないが、隠蔽という選択肢を早い段階で排除する、支払能力の警報装置だ。

これらのどれも、新しい暗号技術、新しいハードウェア、新しい科学を必要としないことに注目してほしい。必要なのはポリシーだ。そして、どれも人気はない。摩擦、遅延、上限はどれもプロダクトマネージャーにとっての悪夢であり、取引所の経済性はスループットと即時性を報酬として与えるからだ。このトレードオフは現実であり、これまで業界の答えは、スナッピーなUXと引き換えに壊滅的なテールリスクを受け入れることだった。63億ドル、20分の強奪とは、そのトレードの代償が回ってきた姿だ。

速度は選択であり、だからこそ意図的に選ぶべきだ

インシデント対応には次のような格言がある。秒が重要なときは、パッチは数日から数週間かけて当てる。今回の強奪はそれを逆転させた。秒が重要なとき、お金は分単位で動き、防御側のプロセスははるかに遅い世界のために作られている。より賢いアラートや強い鍵では解決できない。攻撃者は鍵を破っているわけでも、アラートから隠れているわけでもない。彼らは、設計どおりに、あなたがシステムを動かすよう設計した速度で、あなたのシステムを使っているのだ。

だからこそ、すべての取引所のエンジニア、そして正直に言えば価値を動かすシステムを作るすべてのエンジニアに、率直な問いを投げかけたい。「攻撃者を永遠に締め出すにはどうするか」ではない。それは不可能だ。ノートPCは侵害される。人はフィッシングされる。サプライチェーンは汚染される。問うべきは、誰かが侵入したとき、あなたのアーキテクチャは速く失敗するのか、遅く失敗するのか、ということだ。今のところ、業界の答えは速く、最終的で、テレビ中継される失敗だ。速度上限、時間ロックされた出金、ホットウォレットの厳格な上限こそが、その答えを変える手段だ。技術は簡単だ。少しの摩擦を受け入れる意志こそが難しい。そして業界が自ら摩擦を選ばないなら、コーヒーを淹れ直すほどの間に63億ドルが失われるのを目の当たりにした規制当局が、いずれ代わりにそれを選ぶだろう。