DeFi セキュリティガイド:AI時代における効果的なハッカー攻撃防御法は?

撰文:sysls

翻訳:AididiaoJP、Foresight News

原文リンク:

声明:本文は転載です。読者は原文リンクから詳細情報を得ることができます。著者が転載に異議を唱える場合はご連絡ください。著者の要望に従い修正します。転載は情報共有のみを目的とし、投資助言や立場表明を意図するものではありません。

はじめに

多くのDeFiプロトコルのハッキング事件を理解する中で、「国家行為体」に対して恐怖を抱くようになった。彼らは技術に長け、資源も豊富で、極めて長期的なゲームをプレイしている。これらのスーパー悪役は、あなたのプロトコルやインフラの隅々まで漏洞を探し続ける一方、普通のプロトコルチームの注意は六七つの異なる事業に分散している。

私は自称安全の専門家ではないが、高リスク環境でチームを率いた経験(軍隊や巨額資金の金融分野を含む)があり、緊急対応策の思考と計画には自信がある。

私は心から信じている。偏執的な者だけが生き残れると。どのチームも最初から「安全に対していい加減でいいや」と考えるわけではないが、ハッキングは起こる。私たちはもっと良くなる必要がある。

AIが意味するのは、今回の状況は本当に違うということだ

(出典:

ハッキングは珍しくないが、その頻度は明らかに増加している。2026年第1四半期は記録上最も多いDeFiハッキングの四半期であり、第2四半期は始まったばかりだが、すでに前四半期の記録を破る見込みだ。

私の核心仮説は:AIは漏洞探索のコストを大幅に下げ、攻撃面を飛躍的に拡大していることだ。人間は100のプロトコルの設定を整理し誤設定を探すのに数週間かかるが、最新の基盤モデルなら数時間で完了できる。

これにより、私たちのハッキングへの思考と対応方法は根本的に変わるはずだ。AIが強力になる前の安全策に慣れた古いプロトコルは、「秒殺」のリスクに直面しつつある。

表面と階層的思考を用いる

(出典:

ハッキングの表面積は実際には三つに集約できる:プロトコルチーム、スマートコントラクトとインフラ、ユーザ信頼の境界(DSN、ソーシャルメディア等)。

これらの表面を特定したら、防御層を重ねる:

予防:厳格に実行すれば、利用される確率を最大限に低減できる。

緩和:予防失敗時に被害を制限。

停止:誰も巨大なプレッシャー下で最良の判断を下せるわけではない。攻撃が確認されたら即座に全停止スイッチを起動。凍結はさらなる損失を防ぎ、思考の余裕を得るために……

奪還:有毒または侵害されたコンポーネントの制御を失ったら、それらを放棄し交換。

復旧:失ったものを取り戻す。資金凍結や取引取消、調査支援を行う機関と事前に連携しておく。

原則

これらの原則は、各層の防御を具体的に実施する指針となる。

最先端AIの積極的利用

最先端モデルのAIを大量に使い、コードベースや設定をスキャンして漏洞を探し、広範な表面に対してレッドチームテストを行う:フロントエンドで漏洞を探し、それがバックエンドに到達できるか試す。攻撃者もそうする。防御的なスキャンで見つかるものは、攻撃的なスキャンですでに見つかっている。

pashov、nemesisなどのスキルや、Cantina(Apex)、Zellic(V12)などのAIプラットフォームを使い、完全な監査前に素早くコードをスキャン。

時間と摩擦は良い防御

損害をもたらす可能性のある操作には、多段階の手順とタイムロックを追加。異常を発見したら介入し凍結できる十分な時間を確保。

過去はタイムロックや多段階設定に反対していた理由は、プロトコルチームに摩擦をもたらすからだった。今はそれほど気にしなくて良い:AIは裏でこれらの摩擦を簡単に通過させる。

不変条件

スマートコントラクトは、不変の「事実」を書き出すことで防御的に構築できる:これらの事実が破られたら、プロトコルのロジックは崩壊する。

通常、少数の不変条件しか持たない。それらをコードレベルに慎重に昇格させ、各関数で複数の不変条件を強制実行するのは管理が難しくなる。

権力のバランス

多くのハッキングは、攻撃されたウォレットに起因する。こうした設定が必要だ:多署名が攻撃されても、損害を迅速に抑え、プロトコルをガバナンス可能な状態に戻せる。

これには、ガバナンス(すべてを決定)と救援(復旧可能な安定性を取り戻す能力、ただしガバナンス自体を置き換えたり覆したりはできない)のバランスを取る必要がある。

常に問題は起こる

最初から想定すべき:どれだけ賢くても、あなたはハッカーに攻撃される。あなたのスマートコントラクトや依存関係は失敗する可能性がある。社会工学攻撃を受けることもあり、新しいアップグレードが予期しない漏洞をもたらすことも。

こう考えると、損害を制限するレートリミットや断路器は最良の味方となる。損害を5-10%に抑え、凍結し、対応策を計画。誰も最悪の状況で最良の判断を下せるわけではない。

今こそ最良の計画時間

ハッキング前に対応策を考える。できるだけプロセスをコード化し、チームと演習を重ねる。そうすれば、衝撃時に慌てることはない。AI時代では、大量の情報をできるだけ早く提示できるスキルとアルゴリズムを持ち、要約や長文でコアメンバーに共有する。

完璧を求める必要はないが、生き延びることは絶対に必要だ。システムは最初から完璧ではない。何度も改善し、教訓を吸収して「脆弱性に対して反脆弱」になる。

被害を受けていない証拠は、攻撃されない証拠ではない。最大の安心点は、最も危険なポイントでもある。

予防策

スマートコントラクト設計

不変条件を特定したら、それをランタイムチェックに昇格させる。どの不変条件を実際に強制すべきか慎重に検討。

これがFREI-PI(Function Requirements, Effects, Interactions, Protocol Invariants)モデルだ:価値に関わる各関数の終了時に、その関数が約束した王冠の不変条件を再検証する。CEI(Checks-Effects-Interactions)による抽干攻撃(フラッシュローン・サンドイッチ、オラクルを用いた清算grief、関数間の支払い能力の抽干)も、関数終了時の不変条件チェックで捕捉できる。

良いテスト

状態化模擬テスト(Stateful fuzzing)は、プロトコルの公開された表面に対してランダムな呼び出しシーケンスを生成し、各ステップで不変条件を断言する。多くの本番環境の脆弱性は複数取引にまたがるため、状態化模擬テストは攻撃者より先にこれらのパスを見つける唯一の信頼できる方法に近い。

不変条件を用いたテストで、生成されるすべての呼び出しシーケンスにおいて属性が成立することを断言。形式検証と併用すれば、すべての到達可能な状態で属性が成立することを証明できる。あなたの王冠の不変条件は、こうした処理を受け入れるべきだ。

オラクルと依存関係

複雑さは安全の敵だ。外部依存は攻撃面を拡大させる。設計原則として、信頼する相手と信頼する内容はユーザに委ねる。依存を排除できない場合は、多元化し、単一故障点があなたのプロトコルを破壊しないようにする。

監査範囲をシミュレートされたオラクルや依存関係の失敗パターンに拡大し、それらの失敗による災害の可能性にレートリミットを設ける。

最近のKelpDAOの脆弱性は一例だ:LayerZeroのデフォルト設定requiredDVNCount=1を継承したが、この設定は監査範囲外だった。最終的に攻撃されたのは、監査範囲外のオフチェーンインフラだった。

表面攻撃

DeFiの表面攻撃の多くは既に列挙済み。各カテゴリを一つずつ確認し、自分のプロトコルに該当するかどうかを判断し、その攻撃ベクトルに対するコントロールを実施。レッドチームスキルを育成し、AIインテリジェンスに自らのプロトコルの漏洞を探させることも、今や基本的な要件だ。

ネイティブな救援能力を持つ

投票ベースのガバナンスでは、権力は最初はチームのマルチシグに集中し、拡散には時間がかかる。トークン分布が広くても、委任によって権威が少数のウォレットに集中しやすい(時にはn=1)。これらのウォレットが攻撃されたら、ゲームオーバーだ。

「ガーディアンウォレット」を導入し、厳格な権限制限を付与:それらはプロトコルの一時停止のみ可能で、かつ>=4/7の閾値で、被害を受けた委任を事前定義の代替ウォレットに切り替えられる。ガーディアンはガバナンス提案を実行できない。

こうすれば、常にガバナンスの安定性を回復できる救援層を持ちつつ、ガバナンスの覆す権限は持たない。>=4/7のガーディアンを失う確率は非常に低い(所有者の多様性を考慮)。ガバナンスが成熟し分散すれば、この層は段階的に廃止できる。

ウォレットと鍵のトポロジー

マルチシグウォレットは最低4/7が基本。すべての7つの鍵を一人で管理しない。頻繁に署名者を交代し、静かに行う。

鍵は常に日常使用のデバイスと連携させてはならない。署名デバイスでインターネット閲覧やメール送受信、Slackの起動を行えば、その署名者は既に攻撃されたとみなす。

複数のマルチシグを持ち、それぞれ異なる用途に使う。少なくとも一つの完全なマルチシグが攻撃されることを想定し、そこから計画を始める。どの個人も、極端な状況(誘拐、拷問など)でも、十分な制御権を持つことは避ける。

賞金を考慮

資源があれば、プロトコルのTVLに対して高額な漏洞賞金を設定する価値は非常に高い。たとえ規模が小さくても、最低7〜8桁の賞金を設定すべきだ。

国家行為体の攻撃に直面した場合、交渉は難しいかもしれないが、「ホワイトハットセーフハーバー」プログラムに参加し、ホワイトハットに資金保護を委ね、漏洩した漏洞の一定割合を報酬として支払うことも可能だ(実質的に預金者が賞金を支払う形になる)。

良い監査人を見つける

以前も述べたが、大規模言語モデルが賢くなるにつれ、監査人の限界価値は低下している。私の見解は変わらないが、少し考え方が変わった。

まず、良い監査人は最先端を行く。新しいことに取り組む場合、そのコードや漏洞は訓練データに含まれていない可能性が高い。トークン数を増やすだけでは、新型漏洞の発見には十分ではない。最も重要なのは、彼らが署名し承認した場合、彼らの評判がかかっていることだ。彼らが承認した以上、攻撃された場合は彼らも責任を取る。

次に、過小評価されているメリットは:監査人に依頼することは、彼らの名誉を担保にしていることだ。彼らが署名し承認すれば、あなたが攻撃されたときに彼らは積極的に支援してくれる。安全の専門家と関係を築くことは大きなアドバンテージだ。

運用安全を実践

運用安全は成功の指標とみなす。フィッシング演習を行い、(信頼できる)レッドチームに社会工学攻撃を仕掛けさせる。予備のハードウェアウォレットやデバイスを準備し、必要に応じてマルチシグ全体を置き換えられるようにしておく。D-dayに慌てて購入しないように。

緩和策

退出経路の損失上限

価値をプロトコルから引き出す経路の最大損失額を設定。これが漏洩時の最大理論損失となる。簡単に言えば:上限のないミント関数は、無限ミント漏洞に対して白紙の小切手を切ることになる。上限のない引き出し関数も同様だ。

退出経路の明確な数値を慎重に検討。最大損害とユーザの最極端なUXニーズの間でバランスを取る必要がある。問題が起きた場合、これがあなたを破滅から守るものだ。

ホワイトリスト(とブラックリスト)

ほとんどのプロトコルには呼び出し、取引、受信可能なリストと、絶対にできないリストがある。暗黙のものも含め、これらは信頼境界であり、正式に定義すべきだ。

これを正式化することで、二段階のセッターを設定し、意味のある摩擦を生み出せる。攻撃者はまずホワイトリストに追加(またはブラックリストから除外)し、その後行動を起こす。両方を持つことで、攻撃者が新たなベクトルを密かに導入しようとした場合、二つのプロセスを同時に突破しなければならなくなる:市場に登録(上場/流通)されている必要があり、その行動は安全審査を通過しなければならない。

奪還

アルゴリズム監視

誰も監視しなければ、殺開スイッチは役に立たない。オフチェーンの監視者は、不変条件を継続的に監視し、問題があれば自動的にアラートを上げる。最終的には、ガーディアンのマルチシグを管理する人間に情報を渡し、数分以内に判断できるように十分なコンテキストを提供。

リセットと再調整

攻撃を受けたら、まず止血。倒れる前に対処することが重要だ。これが殺開スイッチ(UIにも反映させるべき)だ:一つのボタンで全ての価値移動経路を一時停止できる。すべて停止させる補助スクリプトを用意し、すべての停止可能なコンポーネントを原子化して停止。

ガバナンスだけが停止解除を許可できるため、殺開スイッチはガバナンスコントラクト自体を停止できない。もし守護者層がガバナンスコントラクトを停止できるなら、攻撃された守護者層は永遠に復旧を妨害できる。

戦情室の立ち上げ

凍結と止血を行い、信頼できる関係者(事前に合意した少人数)をチャットに招集。情報漏洩を防ぐため、表面上は少人数に。

チームの役割を想定し、演習を行う:意思決定者、攻撃防御スクリプトの熟練操作者、脆弱性の再構築と根本原因の特定者、関係者との連絡役、観察・記録・意思決定のタイムライン管理者。

全員が役割を理解し、演習を重ねていれば、最悪の状況でも冷静に対応できる。

連鎖反応を考慮

攻撃者が非常に巧妙だと仮定。最初の漏洞はおとりか、次の攻撃の伏線かもしれない。攻撃は、あなたに完全に誤った行動を取らせ、真の漏洞を引き起こすためのものだ。

停止は十分に調査され、完全にコントロールされた状態で行う。全プロトコルの凍結を目指す:一つのコンポーネントだけ停止させて、別のコンポーネントを開放することは避ける。根本原因と攻撃ベクトルを見つけたら、隣接する表面や連鎖反応も調査し、一度にすべて修復。

事前に承認された後任者のローテーション

後任者を事前に知っていることが安全なローテーションの前提だ。私は「事前承認された後任者登録リスト」のアイデアが好きだ:これにより、攻撃者は健全な守護者やガバナンスウォレットを攻撃されたものに置き換えるのが難しくなる。これは「ホワイトリスト/ブラックリスト」の考え方と一致。

重要な役割ごとに後任者アドレスを登録。緊急時に唯一実行できるのは、「役割Xを後任者に置き換える」ことだけ。これにより、平時に後任者を評価し、デューデリを行い、候補者と面会できる。

アップグレード前の慎重なテスト

根本原因と影響範囲を特定したら、アップグレードを実施。これは最も危険なコードになる可能性がある。プレッシャー下で書き、すでにあなたのプロトコルを理解し、漏洞を見つけた攻撃者向けに作る。

十分なテストと監査ができない場合は、遅らせる。ホワイトハットとの関係を頼るか、デプロイ前に48時間のコンテストを設けて、対抗的なレビューを受ける。

復旧

迅速な行動

盗まれた資金には半減期がある。漏洞が実現すると、すぐにマネーロンダリングに流れる。Chainalysisなどのオンチェーン分析ツールを事前に準備し、攻撃者のアドレスクラスターをリアルタイムでマークし、クロスチェーンの跳躍時に取引所に通知して追跡。

事前に取引所のコンプライアンス部門、クロスチェーンブリッジ管理者、ホルダー管理者、その他の管理権限を持つ第三者のリストを用意。

交渉

確かに痛みを伴うが、攻撃者と対話を試みる価値はある。多くの事柄は交渉で解決できる。期限付きのホワイトハット賞金を提供し、期限までに全額返還された場合は法的措置を取らないと公表。

国家行為体に直面している場合は運が悪いかもしれないが、未熟な攻撃者なら、あなたの資産を狙う方法を見つけ、低コストで逃げることも可能だ。

その前に、必ず法的助言を得ること。

結論

ハッキングは止まらない。AIが賢くなるにつれ、攻撃は増える一方だ。防御側が「敏感になる」だけでは不十分だ。攻撃者と同じツールを使い、レッドチームテストを行い、継続的に監視し、被害に対して硬い制限を設けることで、最悪の事態でも生き残ることができる。

ZRO-0.13%
原文表示
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • コメント
  • リポスト
  • 共有
コメント
コメントを追加
コメントを追加
コメントなし
  • ピン