DeFi安全ガイドライン:AI時代における効果的なハッカー攻撃防御法は?

原文タイトル:DeFiハッキングによる損失を防ぐ方法
原文著者:sysls、openforage
原文翻訳:AididiaoJP、Foresight News

はじめに

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

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

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

AIは今回本当に違うことを意味している

(出典:https://defillama.com/hacks)

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

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

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

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

(出典:https://defillama.com/hacks)

ハッキングの表面積は実際には三つに集約できる:プロトコルチーム、スマートコントラクトとインフラ、ユーザーの信頼境界(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)を用いた攻撃(フラッシュローンサンドイッチ、オラクル支援の清算グリーフ、関数間の資金流出)も、関数終了時の不変条件チェックで捕捉できる。

良いテスト

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

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

オラクルと依存関係

複雑さは安全の敵だ。外部依存は攻撃面を拡大する。原語を設計する際は、誰を信頼し何を信頼するかの選択をユーザーに委ねる。依存を排除できない場合は、多元化を図り、単一故障点がプロトコルを破壊しないようにする。

監査範囲を拡大し、シミュレートされたオラクルや依存関係の失敗例に対しても対策を講じ、失敗時の災害リスクにレートリミットを設定。

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

表面攻撃

DeFiにおける表面攻撃のほとんどは既に列挙済みだ。それぞれのカテゴリを一つずつ確認し、自分のプロトコルに該当するかどうかを問い、その攻撃ベクトルに対するコントロールを実施せよ。レッドチームのスキルを育成し、AIインテリジェンスに自らのプロトコルの脆弱性を積極的に探させることは、今や基本的な要件だ。

原生的な救援能力を持つ

投票に基づくガバナンスでは、権力は最初、多署名のチームに集中し、拡散には時間がかかる。たとえトークンが広く分散していても、委任はしばしば少数のウォレット(時にはn=1)に権威を集中させる。これらのウォレットが侵害されたとき、ゲームは終わる。

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

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

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

多署名ウォレットは最低4/7の要件。すべての7つの鍵を一人が制御しない。署名者は頻繁に交代させ、静かに行う。

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

複数の多署名を持ち、それぞれ異なる用途に使う。少なくとも一つの完全な多署名が侵害されることを想定し、そこから計画を立てる。単一の個人が十分な制御権を持ち、極端なシナリオ(誘拐、拷問等)でもプロトコルを破壊できないように。

賞金を考える

リソースがあれば、プロトコルのTVLに対して高額な脆弱性賞金を設定する価値は非常に高い。たとえ規模が小さくても、賞金はできるだけ寛大に(例:最低7-8桁)設定すべきだ。

国家行為体の攻撃に直面している場合、交渉は難しいかもしれないが、「ホワイトハットセキュリティホール」プログラムに参加し、ホワイトハッカーに資金保護のための行動を委任し、漏洩した脆弱性の一定割合を手数料として受け取ることも可能(実質的には預金者が賞金を支払う形)。

良い監査人を見つける

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

まず、良い監査人は最先端を行く。新しいことに取り組む場合、そのコードや脆弱性は訓練データに含まれていない可能性が高い。Token数を増やすだけでは、新型の脆弱性を見つける効果は証明されていない。特異な脆弱性の最初のサンプルになりたくない。

次に、あまり評価されていない利点は:監査人に依頼することは、彼らの評判を担保にしていることだ。彼らが署名して承認し、あなたが攻撃された場合、彼らは強いインセンティブを持つ。安全専門家と関係を築くことは大きなアドバンテージだ。

運用安全を実践

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

緩和策

退出経路は損失の上限

価値をプロトコルから移し出す経路の最大理論損失額は、その経路が悪用されたときの最大損失額だ。簡単に言えば:上限のないミント関数は、無限ミントの脆弱性に対して空白の小切手を切ることになる。上限のない償還関数も同様、資産残高の破損に対して空白の小切手を発行する。

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

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

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

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

取り戻す

アルゴリズム監視

誰も監視しなければ、殺開スイッチは役に立たない。オフチェーンの監視者は不変条件を継続的に監視し、問題があれば自動的にアラートを上げる仕組みを持つべきだ。最終的には、ガバナンス多署名の人間に情報を渡し、数分以内に意思決定できる十分なコンテキストを提供する。

リセットと再調整

攻撃を受けたら、まず止血を行う。倒れる前に。これが殺開スイッチ(UIにも反映させるべき)だ:一つのボタンで全ての価値移動経路を一時停止できる。すべて一括で停止させる補助スクリプトを準備。

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

戦情室を立ち上げる

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

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

全員が役割を理解しリハーサルを済ませていれば、最悪の事態でも冷静に対応できる。

連鎖反応を考慮

攻撃者が非常に巧妙だと仮定しよう。最初の脆弱性はおとりかもしれず、後続攻撃の伏線かもしれない。攻撃は、あなたに完全に誤った行動を取らせ、真の脆弱性を引き出すためのものだ。

一時停止は十分に調査され、完全にコントロールされ、かつ悪用されてはならない。全プロトコルの凍結を目指す:特定のコンポーネントだけを停止させる誘導を避け、逆に別の脆弱性を生むことがあってはならない。根本原因と攻撃ベクトルを見つけたら、隣接する表面や連鎖反応も調査し、一気に修復。

事前に承諾した後継者のローテーション

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

重要な役割ごとに後継者アドレスを登録。緊急時に唯一実行可能なローテーション原語は、「役割Xを後継者に置き換える」だけ。これにより、平時に後継者の評価やデューデリを行い、面会もできる。

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

根本原因と影響範囲を特定したら、アップグレードをリリースする必要がある。これは最も危険なコードになる可能性が高い:プレッシャー下で書かれ、すでにあなたのプロトコルを理解し脆弱性を見つけた攻撃者向けに。

十分なテストなしでのリリース遅延は避ける。監査の時間がない場合は、ホワイトハットとの関係を頼りにするか、48時間の対抗審査期間を設けて新たな対抗的レビューを受ける。

復旧

迅速な行動

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

また、取引所のコンプライアンス部門、クロスチェーンブリッジの管理者、ホスティング管理者、その他の管理権限を持つ第三者のリストも事前に用意しておく。

交渉

はい、痛いことだが、それでも攻撃者と対話を試みるべきだ。多くのことは交渉で解決できる。期限付きのホワイトハット賞金を提供し、期限前に資金を全額返還すれば法的措置は取らないと公表する。

国家行為体に直面している場合は運が悪いかもしれないが、未熟な攻撃者もいる。彼らはあなたの脆弱性を見つけ、低コストで抜け出そうとしている。

その前に、必ず法律顧問を同席させること。

結論

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

原文リンク

律動BlockBeatsの求人情報はこちらをクリック

律動BlockBeats公式コミュニティにぜひご参加ください:

Telegram購読グループ:https://t.me/theblockbeats

Telegram交流グループ:https://t.me/BlockBeats_App

Twitter公式アカウント:https://twitter.com/BlockBeatsAsia

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