この記事の由来は a16zcryptoこの記事の由来は

、原著者：Andy Beal、Nassim Eddequouaq、Riyaz Faizullabhoi、Christian Seifert、Odaily 翻訳者の Katie Ku が編集。

多くの場合、ハッカーはソフトウェア開発プロセスのチェーン全体 (設計から展開、メンテナンスまで) の欠陥を見つけて悪用し、ブロックチェーン プロジェクトのセキュリティ障壁を突破します。事前に経験を積むことができれば、安全事故はかなり減ると思います。。

この記事では、Web3 開発者とセキュリティ チームがスマート コントラクトを設計、開発、維持する際に考慮する必要があるセキュリティ要素について概説し、脅威のモデリングから緊急対応の準備までのサイクル全体をカバーします。

1. 安全なソフトウェアの開発は、次の 5 つのフェーズで構成されます。

2. 設計: 開発者は、重要なベンチマークや固定プロパティなど、システムに必要な機能と操作について説明します。

3. 開発: 開発者はシステム コードを作成します。

4. テストとレビュー: 開発者はすべてのモジュールをテスト環境に収集し、正確性、規模、その他の要素について評価します。

5. 導入: 開発者はシステムを運用環境に導入します。

メンテナンス: 開発者はシステムを評価および変更して、意図したとおりに動作することを確認します。

以下の図は、考慮する必要があるセキュリティ要素を上記のフェーズにマッピングしています。

上で説明したソフトウェア ライフサイクルの手順とそれに対応するセキュリティの考慮事項は、スマート コントラクトのセキュリティを促進するための基礎を提供します。以下では、3 つの問題についてさらに詳細な調査を行っていきます。

副題

• 1. 設計段階でのスマート コントラクトのセキュリティに関する考慮事項 - 脅威のモデリングとセキュリティ設計を検討する

• 内容: プロジェクト開発ライフサイクルの早い段階から、システムに対する潜在的な脅威を明確に特定し、優先順位を付けることが重要です。スマート コントラクトの開発者は、開発中に実装するすべてのセキュリティ制御と、テスト、監査、監視中にチェックする必要がある脅威を特定する必要があります。攻撃者の予想される巧妙さと経済的手段を含むすべてのセキュリティの前提条件は、設計段階で明確に定義され、明確に表現される必要があります。

• 理由: 開発者は、スマート コントラクトやプロトコルの使用目的のみに焦点を当てたくなりますが、このことだけに焦点を当てると、攻撃者に悪用される可能性のある「盲点」が残る可能性があります。「攻撃者」の考え方でシステムを設計し、あらゆる個人、マシン、サービスが攻撃される可能性があることを前提とします。

副題

• 2. 開発段階でのセキュリティに関する考慮事項 - 管理上の考慮事項とアクセス制御内容: 特権アカウントの機能と、コントラクトのアップグレードや特別なパラメーターの設定などの管理タスクを実行する特別な機能へのスマート コントラクト呼び出しの機能を制限するアクセス制御を実装します。

• 「最小特権の原則」に従ってください。各参加者は、必要な最小限のアクセスのみを持つ必要があります。

• アプローチ: マルチシグネチャ ウォレットまたは DAO コントラクトを構築して、コミュニティに代わって変更を透過的に管理します。変更は徹底的なレビュープロセスを経て、ガバナンス攻撃が発生した場合にその正しさを検証してロールバックできるように、タイムロック（規制の制定を意図的に遅らせて取り消す機能）を設ける必要があります。特権キーが安全に保管され、自己保管ウォレットまたは保管サービスにアクセスできるようにしてください。

副題

• 3. 再利用可能で実証済みのテンプレートと統合を検討する

• 内容: 可能な限り既存のスマート コントラクト標準 (OpenZeppelin Contracts など) を活用し、既存のプロトコルとのプロトコル統合に必要なセキュリティの前提条件を評価します。

• 理由: 実戦でテストされ、コミュニティによって監査された既存の標準を使用し、セキュリティ リスクを軽減するための措置を実装することは、非常に役立ちます。プロトコル統合のリスクを評価することは、オラクル操作などの外部コンポーネントへの攻撃を防ぐためのセキュリティ チェックを開発するのに役立ちます。リスクにさらされている状況を把握し、サプライ チェーン攻撃を監視します。外部プロトコルを呼び出すには公式インターフェイスを使用し、潜在的な統合リスクを必ず考慮してください。再利用された契約の更新とセキュリティ開示を監視します。

副題

• 4. テストおよびレビュー段階でのセキュリティに関する考慮事項 - テストと文書化を考慮する

• 内容: 明確で包括的なコード ドキュメントを作成し、迅速かつ徹底的で簡単に実行できるテスト スイートを構築します。可能であれば、テスト ネットワーク上にテスト環境を確立するか、メイン ネットワークをシミュレートして、より詳細な実験を実施します。理由：コードベースの予想される動作に関する仮定を書き出すことは、脅威モデルのリスクに確実に対処し、ユーザーと外部監査人が開発チームの意図を理解するのに役立ちます。

• アプローチ: Hardhat、Mythril、Slither、Truffle などの既知のテスト フレームワークとセキュリティ チェッカーを実装します。これらは、ファジング、プロパティ チェック、さらには正式な検証などのさまざまなテスト手法を提供します。 NatSpec コメントを使用してコードを詳細に文書化し、予想される副作用、パラメーター、戻り値を指定します。ドキュメント生成ツールと高レベルの設計指示を使用して、リアルタイムのドキュメントを生成します。

副題

• 5. 内部レビューとセキュリティ監査を考慮する

• 内容: 内部および外部のコード検査を通じて、時間をかけて脆弱性を発見します。理由: 機能開発からセキュリティ問題に焦点を移すことで、開発者は潜在的に不明瞭な問題を発見する時間が得られます。

• 外部監査は、開発チームが持っていない外部の視点や専門知識をもたらすことができるため、ここでは特に役立ちます。

ConsenSys、Nassent、OpenZeppelin、および Trail of Bits のガイドを確認してください。監査の準備をしている開発者向けに、タイミングを含む考慮事項のチェックリストが提供されています。また、特にソフトウェアをアップグレードする場合は、デプロイメント トランザクションをチェックして、監査済みのコード バージョンが使用されていることと、適切なパラメータが設定されていることを確認してください。

副題

• 6. 導入および保守フェーズにおけるセキュリティの考慮事項 - ホワイトハット コミュニティの参加を動機付ける

• 内容: オープン ソース コード ベースのセキュリティ向上へのコミュニティの参加を奨励するプログラムを作成します。これを行う 1 つの方法は、バグ報奨金を作成することです。もう 1 つのアプローチは、ボットを監視および検出するためのプロトコルの開発をコミュニティに奨励することです。

• 理由: 開発チームは幅広い知識と経験から恩恵を受けることができます (これは暗号化の分野におけるオープンソースの役割でもあります)。このようなプログラムは、プロジェクトへの熱意を刺激するのに役立ち、本質的にコミュニティとホワイト ハッカーをエバンジェリストに変えることができます。また、ハッカーに防御者になる方法を提供することで、攻撃者を目指す者を安全な資産に変えるのにも役立ちます。

注: この記事の著者の一部は、高品質のセキュリティ監視ロボットの分散作成のためのトークン化されたインセンティブ構造を提供するネットワークを所有する Forta Corporation で働いています。開発チームは、プロトコル コミュニティが従来のアプローチと Web3 ネイティブのアプローチの両方を活用することを奨励して、バグ報奨金を奨励し、セキュリティの強化を通じて参加者に利益をもたらす可能性があり、双方に利益をもたらすことができます。

副題

• 7. リアルタイム監視のセキュリティに関する考慮事項

• 内容: スマート コントラクトと、オラクルやクロスチェーン ブリッジなどの主要な運用コンポーネントを監視し、既知の脅威モデルに基づいて不審なアクティビティを開発チームやコミュニティに報告するシステムを実装します。

• 方法: 監視プラットフォームまたは分散ノードを使用してロボットを実行し、スマート コントラクト イベントをリアルタイムで監視します。必要に応じて、データ ダッシュボードをプラグインし、開発チームやより広範なコミュニティにアラート通知を送信します。

副題

• 8. 事故および緊急対応業務における安全への配慮

• 内容: セキュリティ問題が発生したときに即座に対応できるツールとプロセスを使用します。

• 理由: 導入前の最善の保護策を講じたとしても、スマート コントラクトや、オラクルやクロスチェーン ブリッジなどの主要コンポーネントでリアルタイムの問題が発生する可能性は依然としてあります。専任の担当者、明確なプロセス、適切な自動化により、インシデントを迅速に調査し、できるだけ早く解決できるようになります。

アプローチ: 最悪のシナリオに備え、インシデントや緊急事態への対応方法を計画し、可能な限り対応機能を自動化します。これには、調査と対応の責任者の割り当てが含まれます。分散型セキュリティ メーリング リスト、コード リポジトリの指示、またはスマート コントラクト レジストリを介してセキュリティ上の懸念について公的に連絡できる担当者に連絡できます。協定の脅威モデルに基づいて、シナリオのリハーサルや緊急対応に必要な予想応答時間を含む一連のプロセスを開発し、緊急インシデント対応への自動化の統合を検討できます。セキュリティに関する考慮事項は、単なる後付けや追加ではなく、開発を成功させるために不可欠な部分である必要があります。

このフレームワークは、開発プロセス全体を通じてセキュリティを促進する Web3 プロトコルとアプリケーションを構築するためのいくつかの簡単なガイドラインを共有していますが、スマート コントラクトのセキュリティ全体について説明できる短い概要はありません。社内にセキュリティの専門知識が不足しているチームは、特定の状況への適用を指導し支援できる資格のある Web3 セキュリティの専門家に連絡する必要があります。