SC Audit Studio JP-Translated

DeFiプロジェクトのOpSec実践ガイド2026：ガバナンス・Timelock・マルチシグで守る運用セキュリティ

コードを監査しても、ガバナンスや鍵の運用がずさんならプロトコルは攻撃されます。実際の事例から学ぶ、DeFiの運用セキュリティの守り方を解説します。

きなこ

きなこ

— 9 min read
DeFiプロジェクトのOpSec実践ガイド2026：ガバナンス・Timelock・マルチシグで守る運用セキュリティ
Photo by Pesce Huang on Unsplash

私が所属するフィンランドの監査企業SC Audit Studio（以下SCAS）のブログ記事「OpSec Best Practices in DeFi 2026」（@oot2k1さん著）を和訳しました。SCASのセキュリティリサーチャーが、実際のインシデントや事後検証から学ぶ、運用セキュリティの実践ガイドです。
読みやすさを優先し、日本語記事として意訳・再構成しています。

🦖
OpSec（オプセック）＝Operational Security（運用セキュリティ）

コードそのものではなく、そのコードを「誰が」「どう動かすか」という運用面の守りを指します。鍵の管理、権限の設計、人的なプロセスまで含めた、プロトコル運用全体のセキュリティのことです。

はじめに

Web3プロトコルがハッキングされるとき、その原因はSolidityのバグだけとは限りません。むしろ多くの場合、ガバナンス権限、アップグレード用の鍵、トレジャリーの管理がずさんだったために資金を失う状態に陥ります。

実際、2025年は、生のコードのバグよりも、ガバナンス設計の甘さ、脆弱なタイムロック、侵害されたマルチシグを原因とするエクスプロイト（脆弱性の悪用）のほうが多く見られました。つまり、複数回の監査を経てスマートコントラクトのセキュリティは堅牢そうに見えても、最終的にはOpSecの強度で決まるということです。

なぜガバナンス・タイムロック・マルチシグが重要なのか

  • ガバナンスは、アップグレード、トレジャリー、プロトコルのパラメータを制御します。ガバナンスの乗っ取りは、そのままプロトコルの乗っ取りを意味します。
  • タイムロックは、可決された投票と、その実行との間に強制的な待機期間を設けます。これにより、コミュニティやセキュリティチームが反応する時間が生まれます。
  • マルチシグ（複数署名）は、鍵の管理を複数の署名者に分散させ、単一障害点（一点が壊れると全体が壊れる箇所）を減らします。

セキュリティ企業のTrail of Bitsが指摘するように、特権ロール（強い権限を持つ役割）こそが最大の攻撃対象領域です。強固なOpSecがない場合、攻撃者はコードのバグを見つける必要すらありません。ガバナンス用の鍵さえ手に入れればいいのです。

ガバナンスにおける典型的な攻撃ベクトル

Dacianさんの「DAO Governance Attacks」やSigma Primeによれば、よくある落とし穴は次のとおりです。

  • フラッシュローン投票
    攻撃者がガバナンストークンを借り入れ、悪意ある提案を可決させ、その後トークンを売り抜ける。
  • 提案の密輸（proposal smuggling）
    提案の中に隠されたロジック（例：アップグレード用のペイロード）を仕込む。
  • 委任の悪用（delegation abuse）
    ガバナンスへの無関心が、少数のクジラ（大口保有者）に権力を集中させてしまう。
  • チェックされないveto／ガーディアン権限
    「守り手」であるはずのガーディアン自身が、単一障害点になってしまう。

Vitalik Buterin氏が論じたように、トークン保有量に応じた投票だけでは、堅牢なガバナンスとは言えません。追加の安全策が必要なのです。

🦖
フラッシュローンとは、1つのトランザクション内で「借りて・使って・返す」を完結させることを条件に、無担保で巨額の資金を借りられるDeFi特有の仕組みです。

タイムロック：プロトコルを救う「遅延」

タイムロックは、最も過小評価されているOpSecツールです。実例を見てみましょう。

  • MakerDAOのGSMは、ガバナンスアクションが実行される前に24時間の遅延を設けています。
  • Compoundのタイムロックは、多くのDeFiプロトコルの雛形となったテンプレートを生み出しました。
  • eBTCは、異なる遅延時間を持つ複数のタイムロックを運用しています（コア部分には長め、運用オペレーションには短め）。

短いタイムロックは柔軟性を守り、長いタイムロックはセキュリティを守ります。成熟したプロトコルほど、この2つを組み合わせた階層化されたタイムロックを採用しています。実装上のポイントは、次の2点に尽きます。

  • プロトコルを変更しうる特権機能には、例外なくタイムロックをかけること
  • タイムロックの設定変更そのものにもタイムロックをかけること。さもなければ、攻撃者は遅延をゼロに縮めてしまうだけです。

主要なアップグレードには最低でも24時間を確保しましょう。それ未満では、人々が気づいて動き出すころには手遅れになってしまいます。

マルチシグ：分散した鍵がもたらす強さ

マルチシグは、トレジャリー、アップグレード、緊急時のコントロールを守ります。実例からの教訓は次のとおりです。

  • Optimismのマルチシグポリシー
    7名中4名の署名（4/7）を閾値とし、署名者の選定は透明で、ローテーションポリシーも整備されています。
  • HowToMultisig.com
    署名者の多様性（地理的・組織的な分散）とハードウェアウォレットの利用を重視しています。

閾値は、署名者を数名失っても持ちこたえられる水準にすべきです。小規模プロジェクトなら2/3でも足りますが、まとまった資金を扱うなら最低でも3/5、できれば4/7が望ましいでしょう。また、署名者のローテーション計画は必ず文書として残しましょう。弊社では、創業者が去ったあと「誰が鍵を持っているのか、もう誰も覚えていない」というプロトコルを見てきました。マルチシグは、単なる技術的なツールではなく、組織的な規律そのものなのです。

ケーススタディ：現場での良い例・悪い例

良い例

  • MakerDAO GSM
    効果的なタイムロックで拙速なガバナンス攻撃を防止
  • Aave Safety Module
    ステーキング、ガバナンス、そして遅延実行の組み合わせ
  • Marinade Finance
    信頼ベースのマルチシグから、分散型ガバナンスへと段階的に移行

悪い例

技術実装ガイド

堅牢なタイムロックのセットアップ

// 例：階層化されたタイムロックの実装
contract LayeredTimelock {
    uint256 public constant ROUTINE_DELAY = 1 days;
    uint256 public constant MAJOR_DELAY = 3 days;
    uint256 public constant CRITICAL_DELAY = 7 days;
  
    mapping(bytes32 => uint256) public queuedTxs;
  
    function queueTransaction(
        address target,
        uint256 value,
        bytes memory data,
        uint256 delay
    ) external onlyGovernance {
        require(delay >= getMinDelay(target, data), "Insufficient delay");
        bytes32 txHash = keccak256(abi.encode(target, value, data, block.timestamp + delay));
        queuedTxs[txHash] = block.timestamp + delay;
    }
}

緊急停止（Emergency Pause）の仕組み

// 時間制限付きの権限を持つサーキットブレーカー・パターン
contract EmergencyPause {
    uint256 public constant PAUSE_DURATION = 72 hours;
    uint256 public pauseDeadline;
  
    modifier whenNotPaused() {
        require(!isPaused(), "Contract is paused");
        _;
    }
  
    function emergencyPause() external onlyGuardian {
        require(block.timestamp < pauseDeadline, "Pause authority expired");
        _pause();
    }
}

高度なOpSec戦略

Proof of Humanity（人間性の証明）の統合

ボットによるガバナンス投票は、広く見られる問題です。弊社が観測したなかには、「投票者」の40%が自動化されたスクリプトだったプロトコルもありました。Proof of Humanity、BrightID、WorldCoinといった本人確認の仕組みを統合しましょう。投票だけでなく、提案の作成にも人間による検証を必須とするのがポイントです。

コンビクション投票（Conviction Voting）

標準的なガバナンスでは、投票直前のトークン購入ですら有効です。コンビクション投票は、トークンを保有していた期間の長さに応じて投票権を増やす仕組みです（voting_power = tokens * sqrt(holding_time)）。1HiveやCommons Stackは、この方式によってフラッシュローン攻撃が大幅に減ることを実証しています。

ゼロ知識ガバナンス（Zero-Knowledge Governance）

票の買収や強要は、現実の脅威です。zk-SNARKsを用いたZKガバナンスなら、投票の中身を明かすことなく、投票資格があることだけを証明できます。MACI（Minimal Anti-Collusion Infrastructure：最小限の共謀防止インフラ）は、投票が締め切られるまで票を暗号化しておくことで、操作を防ぎます。

🦖
ゼロ知識証明（Zero-Knowledge Proof）とは、「ある事実が正しいこと」を、その中身を一切明かさずに証明する暗号技術です。ここでは「私は投票する資格がある」という事実だけを示し、「誰に投票したか」は隠したまま検証できるようにしています。

モニタリングとアラートの仕組み

監視すべき重要なオンチェーンイベント

大口のガバナンストークン移動（総供給量の1%超）、参加率が低く締め切りが短い提案、キューに入ったマルチシグのトランザクション、そして不自然な投票パターンを監視しましょう。攻撃者は、注意が手薄になる週末や祝日を狙ってきます。

有効なツールとしては、リアルタイムのトランザクション監視にTenderly、自動対応にOpenZeppelin Defender、カスタムの脅威検知にForta、時間ベースのトリガーにChainlink Keepersが挙げられます。

ソーシャルモニタリング

オンチェーンのデータが語るのは、物語の半分にすぎません。ガバナンス関連のキーワードを拾うため、DiscordやTelegramのボットを設定しましょう。Twitterのセンチメント分析（世論の傾向分析）や、プロトコル提案が議論されるForum上での委任者による投票理由の説明も監視します。ガバナンストークン周りでのMEVボットの動きにも注意してください。これはフラッシュローン攻撃の前兆であることが少なくありません。

推奨OpSecプレイブック

多くのプロトコルは、監査をパスしたから安全だと思い込んでいます。しかしセキュリティとは、スマートコントラクトのコードだけではなく、そのコードを制御するすべてです。OpenZeppelin、SEAL、Gauntletのベストプラクティスと数々のポストモーテムを踏まえた、実践的なチェックリストがこちらです。

  1. すべての特権機能を、ガバナンス＋タイムロックを経由させる
    プロトコルを変更しうるものであれば、例外なくタイムロックをかけます。
  2. 階層化されたタイムロックを実装する
    日常オペレーションは24時間、コアのアップグレードは72時間以上
  3. マルチシグの署名者を多様化する
    ハードウェアウォレット、異なる組織、地理的な分散。閾値は3/5以上、できれば4/7を。
  4. 署名者のローテーションポリシーを文書化し、遵守する
  5. マルチシグのトランザクションキューをリアルタイムで公開する
    透明性は内部脅威を減らします。
  6. ガーディアン/veto権限にも、時間制限を設ける
    取り消し不能な権限は、うっかり「独裁者」を生み出します。
  7. 提案と実行キューを、オンチェーンのアラートで継続的に監視する
    スナップショットベースの投票とクォーラム（定足数）要件がなければ、フラッシュローンでの乗っ取りは今なお成立します。Beanstalkは、1.82億ドルの損失という手痛い代償を払って、これを学びました。

クライシスマネジメント

ガバナンス攻撃への対応

シナリオ：アラートが殺到し、悪意ある提案が支持を集めつつある。これは重大なセキュリティインシデントです。

最初の15分： 脅威の範囲を見極めます。投票はすでに動いているのか、それともまだ準備段階か。すべてのマルチシグ署名者に、グループチャットで連絡します（個別のDMは避けること）。使えるなら、ガーディアン/停止権限を直ちに発動します。すべてを記録しましょう。スクリーンショット、ハッシュ、タイムスタンプを残します。

その後の数時間： コミュニティに対して、透明性をもって発信します。防衛的な投票に向けて、ガバナンストークン保有者を結集させます。主要なステークホルダーには、直接連絡を取ります。

復旧フェーズ： 根本にある脆弱性を修正しますが、新たなリスクを生むような拙速なパッチは避けます。包括的な事後ドキュメント（ポストモーテム）を書き上げます。資金が失われた場合は、補償の方針を検討します。そして最も重要なのは、そこで得た教訓を、更新版のOpSec手順に組み込むことです。

マルチシグ侵害への対応

マルチシグ署名者の侵害は、最悪の悪夢とも言えるシナリオです。

即座に取るべき行動： 侵害された署名者を、直ちに除外します。これは一時的にセキュリティの閾値を下げてしまいますが、侵害されたと分かっている当事者を残しておくほうが、はるかに危険です。共有されているすべての認証情報（ウォレット、取引所、コミュニケーションプラットフォーム、コードリポジトリ）を無効化します。直近30日間のトランザクションを監査し、異常な動きがないか確認します。そして、体制を立て直すあいだは、一時的に署名の閾値を引き上げます。

最も難しいのは、悪意ある内部関係者の行為なのか、それとも外部からの侵害なのかを見分けることです。ただし、どちらであっても対応は同じです。最悪を想定し、すべてを固めましょう。

おわりに

最速でRekt（資金を失うこと）する道は、コントラクトのバグではありません。ガバナンスと特権ロールをめぐる、ずさんなOpSecです。

もしあなたのプロトコルにタイムロックがなく、中央集権的なマルチシグを抱え、フラッシュローンへの防御策のないガバナンスを回しているなら、時限爆弾を抱えているのと同じです。

でも、良い知らせもあります。プレイブックは、すでに存在するのです。MakerDAO GSMからOptimismのマルチシグまで、レジリエントなOpSecの築き方を示してくれたプロトコルたちがいます。攻撃者にあなたのトレジャリーを盗られる前に、彼らのパターンを模倣しましょう。

SC Audit Studioについて

SC Audit Studioは、プロトコルのセキュリティ評価を専門としています。

私たちの専門家チームは、プロジェクトの安全性と信頼性の確保に力を入れています。安心してプロダクトを世に送り出せるよう、一緒にセキュリティを高めていきましょう。

セキュリティ監査やお問い合わせは、こちらからご連絡ください。

SC Audit Studio情報

Webサイト：https://scauditstudio.com/
X（旧Twitter）：https://x.com/SCAuditStudio

FAQ

  • タイムロックは常に必須ですか？
    はい、特権機能については必須です。議論の余地があるのは「どのくらいの長さにするか」だけです（一般的には24〜72時間）。
  • マルチシグは、内部の共謀に対して安全ですか？
    署名者が独立していて、多様で、透明性が保たれている場合に限ります。7名全員が同じ会社の人間である4/7のマルチシグは、実質的に単一の鍵と変わりません。
  • フラッシュローン投票は、いまだにガバナンスを壊せますか？
    はい。スナップショットとクォーラムのルール（その投票を有効と認めるために最低限必要な参加票の量）を使っていない限りは。Beanstalkのハッキング事件を参照してください。
  • ガーディアンに緊急権限を持たせるべきですか？
    はい、ただしその権限は取り消し可能でなければならず、悪用を防ぐため、理想的にはタイムロックもかけるべきです。
  • DAOがマルチシグを卒業することはありますか？
    はい。通常の道筋は、信頼ベースのマルチシグ → タイムロック付きの分散型ガバナンスです。Marinade Financeが良い例です。

付録：ツールとリソース

ガバナンスフレームワーク

OpenZeppelin Governorが、弊社の一番のおすすめです。実戦で鍛えられ、監査担当者にとって扱いやすく、タイムロックとの統合もシームレスです。Aragonは包括的なDAOインフラを提供しますが、その分だけ複雑さも増します。Compound Governorは、多くのプロトコルが模倣した元祖テンプレートで、シンプルかつ実績十分です。Snapshotは、オフチェーン投票の効率と、オンチェーン実行とを橋渡しします。

マルチシグのソリューション

Safe（旧Gnosis Safe）は、70%超の市場シェアを誇りますが、それには理由があります。セキュリティ、使いやすさ、エコシステム統合のバランスが最も優れているのです。Fireblocksは、保険やコンプライアンスを必要とする機関投資家向けプロトコルをターゲットにしています。Coinbase Custodyは、規制対応を備えた機関投資家グレードの鍵管理を提供します。Qredoは、より新しいMPC（マルチパーティ計算）技術を採用していますが、実戦での検証はまだ浅めです。

セキュリティモニタリング

OpenZeppelin Defenderは、自動化された監視と対応に優れています。Tenderlyは、複雑な攻撃シナリオに向けたトランザクションのシミュレーションとデバッグを提供します。Fortaは、分散型の脅威検知として機能し、カバー範囲を着々と広げています。Chainalysisは、コンプライアンスと規制リスクの監視に注力しています。

もっと読む