ブロックチェーンペネトレーションテストとは?定義と境界

前回の記事、インシデントから規制へ:暗号資産機関がブロックチェーンペネトレーションテストを必要とする理由では、ブロックチェーンペネトレーションテストがなぜ必要であるかを述べました。本記事では、それが何であるかに焦点を移し、ブロックチェーンペネトレーションテストの定義と範囲についてより詳しく検証します。

ブロックチェーンペネトレーションテストについて広く受け入れられている正式な定義は存在せず、提案されている多くの定義がそれを他の対策と混同しているため、監査(audit)、スキャン(scan)、バグバウンティ(bug bounty)といったラベルが、それぞれ異なる目的を持つにもかかわらず、ペネトレーションテストの一部として含まれてしまうことがあります。これにより、ある実施内容が実際に何を検証したのかを把握することが難しくなります。私たちの出発点は、学術界と業界双方の実践に基づいたもので、意図的に単純です:ブロックチェーンペネトレーションテストとは、その名前が示す通り、数十年にわたって定義されてきた規律であるペネトレーションテストをweb3エコシステムに適用したものであり、稼働中のweb3環境に対して敵対的な、システム全体の評価として実施されるものです。まずこの馴染みのある規律から出発し、その上でweb3が脅威モデルとテスターに求められる判断にどのような要素を追加するのかを問います。

**ブロックチェーンペネトレーションテストとは、合意された環境とルールオブエンゲージメント(rules of engagement)の下で行われる、稼働中のシステムに対する敵対的かつ実践的な評価であり、悪用可能な経路と制御チェーンを検証するものです。**これはコードレベルのセキュリティ監査を補完するものであり、独立して依頼することも可能です[1]。

これは孤立した弱点ではなく経路を探し出すものであり、明示的な許可、範囲、アクセスに関する前提、および安全上の制約の下で運用されます。本記事では次の3つの問いに答えます:ブロックチェーンペネトレーションテストとは何か、それが何を検証できるか(特に監査が通常提供する証拠を超えて)、そして機関がどのように高いレベルで開始できるか。

web3が追加するもの:資金を扱う脅威モデル

web3は従来のペネトレーションテストの対象領域、すなわちクラウドインフラ、ウェブサイト、API、アイデンティティ、特権アクセス、ベンダー、運用ツールを引き続き保持しています。web3はこの脅威モデルをブロックチェーン専用のものに置き換えるのではなく、同じ足がかりが承認、記録、または価値の移動を直接引き起こすアクションへと直結しうるシステムへと拡張しています。

この拡張を形作る3つの特徴があります。

第一に、デジタル資産は直接的に移転可能です。適切なトランザクションや引き出し経路に到達した攻撃者は、従来の決済で使用されているような取り消しや照合の仕組みを経由せずに価値を移動できる可能性があります。
第二に、署名はしばしば資金を移動させるアクションそのものです。暗号学的に有効な署名は、あるキーがペイロードを承認したことを証明しますが、それ単体では、オペレーターが正しい送金先を確認したこと、トランザクションを理解していたこと、あるいは意図された承認ポリシーに従っていたことを証明するものではありません。
第三に、機関が独自のコントラクトをデプロイする場合(製品がより豊富なオンチェーン機能を追加するにつれてますます一般的になっています)、それらのコントラクトは公開され呼び出し可能かつ組み合わせ可能です。外部ユーザーや他のコントラクトは、機関が制御できない順序でそれらを呼び出すことができます。したがって、セキュリティは各コンポーネント単独ではなく、アイデンティティ、アプリケーション、ポリシー、署名システム、会計ロジック、コントラクトがどのように相互作用するかにも依存します。

私たちはこの結果として生じるリスクを**資金を扱うチェーン(money-handling chain)**としてモデル化します。これは、オンチェーンのトランザクション(そして、ますます一般的になっている機関自身がデプロイしたコントラクト)へとつながるオフチェーンの署名意図、承認、資金ロジックの制御であり、これらのステップを支えるクラウド、ウェブ、API、アイデンティティの各層と併せて考慮されます[1]。攻撃者は普通の足がかりから始め、複数の制御を経て段階的に進行することがあります:署名のために提示される内容を操作し、特権のあるワークフローに到達し、承認の隙を悪用し、または資金ロジックに意図しない状態遷移を受け入れさせることです。

決定的な構成上のギャップはオフチェーンとオンチェーンの間の受け渡しです。すなわち、アイデンティティ、インターフェース、承認、署名、資金ロジックの各制御が、それがオンチェーンのトランザクションになった際に意図されたアクションを保持できるかどうかです。すべての攻撃がチェーン全体を横断するわけではありません。重要なのは、保証の対象がレイヤーを横断するものであるということです:単独では健全に見える制御であっても、稼働中の資金を扱うシステムを通じて悪用可能な経路に組み合わされてしまうことがあります。

ブロックチェーンペネトレーションテストが行うこと

ブロックチェーンペネトレーションテストは、この構成上のギャップを証拠に変えます。許可された範囲と合意されたルールの中で、テスターはレイヤーを横断する前提を攻撃シナリオへと変換し、稼働中の環境に対してそれらのシナリオを実行し、それらが再現可能な経路と具体的な影響を生み出すかどうかを判定します。その出力は、経路を裏付けとなる証拠、深刻度、修復ガイダンス、そして合意された修正の再テストへと結び付けるものであり、単に関連性のない弱点の一覧に留まるものではありません。

その差別化要因はweb3専門のセキュリティに関する判断力であり、独自のツールボックスではありません。テスターは、カストディ、トランザクションの意図、承認ポリシー、引き出しフロー、資金会計、およびオンチェーンのトランザクション動作(デプロイされたコントラクトを含む)を解釈しながら、従来のクラウド、ウェブ、API、アイデンティティ、特権アクセスの各対象領域からの証拠を結び付ける必要があります。ツールは発見や検証を支援することがありますが、観測された状況が信頼できる資金移動の経路を形成しているかどうかを確立するのは専門家の判断です。

この評価は方法論的で、証拠に基づいたものであり、時点的なものです。その結論は、テストされたシステム、バージョン、設定、アクセスに関する前提、および条件に適用されます。潜在的な経路は検討されますが、確認された悪用可能な経路は再現可能な証拠と共に文書化されます。

合意された対象領域全体にわたる体系的な作業であっても、すべての弱点や攻撃経路が発見されることを保証することはできず、責任ある実施であっても、テスターが侵害を達成することを保証するものではないことにご注意ください。

機関のweb3環境において、そのシナリオから証拠への一連のプロセスは、5つの相互に関連する能力—同じ資金を扱うチェーンのテスト可能な対象領域を横断して実行されます。これらは、そのチェーンを支えるインフラ、その3つのオフチェーン制御、そしてそれが受け渡すオンチェーンのトランザクションにわたっています。単一の経路が複数の領域を横断しうるため、これらは相互に関連しています:

本番環境と自動化された運用: テスターは、アクセス、デプロイメント、シークレット、または運用上の制御が資金を扱うアクションへと連鎖しうるかどうかを検証し、運用上の足がかりを到達可能な影響と結び付ける証拠を生成します。
ウェブおよびdAppのフロントエンド、承認、署名の意図: テスターは、ユーザーやオペレーターに提示されるトランザクションが最終的に承認されるアクションと異なる可能性があるかどうかを検証し、操作されたフローと結果として生じる署名または送信された動作を記録します。
署名、承認、および引き出し承認チェーン: テスターは、アイデンティティ、ロール、ポリシーチェック、または承認ステップが回避されたり組み合わされたりする可能性があるかどうかを検証し、その手順とそれによって可能となる不正なアクションを文書化します。
資金業務ロジック: テスターは、残高、上限、照合、引き出しルール、または状態遷移が意図しない条件を受け入れるかどうかを検証し、単なる技術的な欠陥ではなく、再現可能な業務への影響の経路を捉えます。
オンチェーンのトランザクションとデプロイされたコントラクト: テスターは、機関のオンチェーンでの相互作用が敵対的な実行時条件下でどのように振る舞うかを検証します。機関が独自のコントラクトをデプロイしている場合には、それらのコントラクトの実行時の動作を検証し、観測された結果のトランザクションレベルの証拠を保持します。コードレベルの保証は、対応するCode Auditの役割のままです。

第4回:web3の攻撃対象領域:ペネトレーションテストの概要では、これらの対象領域とその関連性をマッピングしていますが、中核となる目的は変わりません:合意された稼働中の環境全体にわたる条件が再現可能な影響へと連鎖するかどうかを確立することです。

他の保証手段の中での位置付け

最も明確な比較は保証の目的によるものです。すなわち、その作業が支援することを意図した意思決定と、それが生み出すことが期待される証拠です。以下の図に示されているように、手法は重複することがあり、規律は協力することができ、あるチームが完全に静的であり別のチームが完全に動的であると仮定することに依存する有用な境界線は存在しません。同じ対象——デプロイされたコントラクト、クラウドやRPCの対象領域、署名システム——であっても、これらの複数の規律に該当することがあります。異なるのは、それぞれが重視する保証の目的であり、そのシステムに対する排他的な主張ではありません。

図3. ブロックチェーンペネトレーションテスト、Code Audit、Blockchain Security Testingを2軸で表したもの。

ペネトレーションテストとコードレベルの監査

Code Audit——コードレベルの監査を指す固有の名称——は、主にコード(設計、アーキテクチャ、プロトコルの前提を含む)における保証を構築します。専門家によるレビューと検出ツールを組み合わせ、動的な手法を含むこともあり、合意された監査範囲に対する署名付きレポートを作成します。コントラクト、チェーン、ブリッジ、ロールアップ、ウォレット、またはその他の実装について、監査はその設計とコードが意図されたセキュリティ特性を満たしているかどうかを問います。

ペネトレーションテストは主に、合意された稼働中の機関環境全体にわたる実際の条件が再現可能な影響へと連鎖しうるかどうかを確立します。これは、デプロイされたアプリケーション、アイデンティティ、設定、ワークフロー、業務ロジック、署名システム、コントラクト呼び出しの間の相互作用を追跡し、その経路を再現し修復するために必要な証拠を記録します。

これは目的と証拠における違いであり、能力上の制限ではありません。監査人はテストを実行し、コンポーネントをファジングし、実行時の動作を調査することがあります。ペネトレーションテスターは、経路を理解するために設定��アプリケーションロジック、実装の詳細をレビューすることがあります。手法は重複することがあり、チームは協力して作業することがあります。これらのサービスは代替ではなく相互補完的です:監査単独では通常、この機関全体にわたる実行時の悪用可能性に関する証拠は提供されません。一方、ペネトレーションテストは、監査で対象となる実装やプロトコルの特性に関するコードレベルの保証に代わるものではありません。

したがって、実際の機関の経路におけるコントラクトの敵対的な振る舞いはペネトレーションテストの範囲に含まれる一方で、コントラクトのコード自体に関する保証は対応するCode Auditに委ねられます。

スキャン、バグバウンティ、専門的なテスト

脆弱性スキャンは、既知のシグネチャ、公開されているサービス、未適用のパッチ、および一般的な設定の問題に対する自動化された幅広いカバレッジを提供します。これは再現可能な可視性を支援し、偵察に貢献することができますが、ペネトレーションテストは専門家主導の深さを追加し、条件が意味のある経路へと連鎖しうるかどうかを判定します。

バグバウンティは、公開されたルールの下で対象となる発見事項を報告するよう独立した研究者を招くものです。その継続的でクラウドソース型のモデルは、長期的に残る問題を浮かび上がらせることができますが、ペネトレーションテストの実施では、合意された環境を体系的に検証し、統合された証拠、深刻度、修復ガイダンス、および再テストを提供するチームが割り当てられます。この2つのモデルは相互補完的であり、どちらも完全な発見を保証するものではありません。

例えば、BlockSecのBlockchain Security Testingは、ペネトレーションテストの親でも部分集合でもない、姉妹プログラムです。これは、差分テスト、ファジング、プライベートデプロイメント、大規模なRPCサービス拒否テスト、ノードまたはクラスターインフラのテストを含む専門的なエンジンを使用して、カスタマイズされたインフラの実装の正確性と耐性を検証します[2]。ブロックチェーンペネトレーションテストは、稼働中の資金を扱うシステムを通じた機関レベルの、レイヤーを横断する経路を中心としています。アプリケーションホスティングとアプリケーションのCI/CDはペネトレーションテストの対象領域に振り分けられ、ノードとクラスターインフラおよび大規模なRPCの耐性はBlockchain Security Testingに振り分けられます。アーキテクチャによっては両方が必要になることがあります。

近接する目的についても、正確な振り分けが必要です。コントラクトのコードレベルの保証は、対応するCode Auditに振り分けられます。MPC、TSS、TEEの設計を含む鍵カストディ実装の暗号学的正確性は、Wallet Security Auditに振り分けられます。決済側のエージェント型システムは、Agentic Payment Securityに振り分けられます[1]。ペネトレーションテストは、それが合意された機関の範囲の一部を構成する場合には、周辺の署名ワークフロー、運用エージェント、またはアプリケーションの経路を検証することもあります。

保証の目的	対応するアプローチ
稼働中の機関のアプリケーション、アイデンティティ、承認制御、資金ロジック、およびオンチェーンのトランザクション(デプロイされたコントラクトを含む)を横断する悪用可能な経路が存在するかどうかを検証する	Blockchain Penetration Testing
コード、設計、アーキテクチャ、またはプロトコルの前提を評価する	Code Audit
MPC、TSS、TEE、または鍵カストディ実装における暗号学的正確性を評価する	Wallet Security Audit
カスタマイズされたノード、クラスター、EVM、データベース、MPT、または大規模なRPCインフラの実装の正確性と耐性を検証する	Blockchain Security Testing
既知のシグネチャと設定の問題に対する幅広い自動化された可視性を維持する	Vulnerability Scanning
公開された対象範囲全体にわたる継続的でインセンティブ主導の研究を招く	Bug Bounty
決済側のエージェント型システムとそのセキュリティ上の前提を評価する	Agentic Payment Security

これは順序ではなく、振り分けのガイドです。単一のシステムが複数の保証目的を生み出すことがあり、それゆえ協調した一連の評価が正当化されることがあります。これらのラベルは相互排他的ではありません。

管轄区域と機関の分類によっては、テストが規制上の要件または監督上の期待事項であることがあり、一部の規制体制では独立した第三者を要求しています。第1回ではこれらの違いについて説明しています[3]。規制上の適用可能性については、法律顧問に確認する必要があります。

始め方

決定を行う前に、次の3つの問いから始めることができます:**どのシステムが資金を移動させているか?すでに存在する保証の証拠は何か?どの制御チェーンがまだ敵対的に検証されていないか?**これらの答えは、名前によって早まってサービスを選ぶことなく、保証のギャップを特定します。

その後、スコーピングの対話を通じて、対象、アクセスに関する前提、保護措置、および期待される成果物を整合させることができます。第3回:機関向けブロックチェーンペネトレーションテストにおけるルールオブエンゲージメントと本番環境の安全性では、実施を運用可能にするために必要な許可、安全性、および調整について取り上げています[4]。

これに基づいて行動する準備ができたら、BlockSecと共に保証のギャップをスコープすることで、テスト開始前に対象、証拠、保護措置を整合させてください。

攻撃対象領域に関するガイドを引き続きご覧ください: