ブロックチェーンペネトレーションテストとは？定義と範囲

前回の記事「From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing」では、なぜブロックチェーンペネトレーションテストが必要なのかを説明しました。本記事ではそれが何であるかに焦点を移し、ブロックチェーンペネトレーションテストの定義と境界についてより詳細に検討します。

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

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

これは孤立した脆弱性ではなく経路を探るものであり、明示的な承認、スコープ、アクセスの前提条件、安全上の制約のもとで運用されます。本記事では以下の3つの問いに答えます。ブロックチェーンペネトレーションテストとは何か、それが何を検証できるのか——特に監査が通常提供する証拠を超えて——そして、機関がどのように高いレベルで着手できるのか、です。

web3が加えるもの:資金取り扱いの脅威モデル

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

この拡張には3つの特徴があります。

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

私たちはこの結果生じるエクスポージャーを資金取り扱いチェーン——オンチェーントランザクション(そしてますます、機関自身がデプロイしたコントラクト)へとつながるオフチェーンの署名意図、承認、資金ロジック制御——として、それらのステップを支えるクラウド、ウェブ、API、アイデンティティの各層とあわせてモデル化します [1]。攻撃者は通常の足がかりから始め、複数の制御を横断して進行する可能性があります。署名のために提示される内容を操作する、特権的なワークフローに到達する、認可のギャップを悪用する、あるいは資金ロジックに意図しない状態遷移を受け入れさせる、といった具合です。

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

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

ブロックチェーンペネトレーションテストは、その合成上のギャップを証拠へと変えます。承認されたスコープと合意されたルールのもとで、テスターはレイヤーをまたぐ前提を攻撃シナリオへと落とし込み、それらのシナリオを稼働中の環境に対して実行し、再現可能な経路と具体的な影響を生み出すかどうかを判断します。その成果物は、経路を裏付ける証拠、深刻度、修復ガイダンス、合意された修正の再テストへとつなげるものであり、単に脈絡のない脆弱性のリストで終わるものではありません。

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

この評価は体系的で、証拠主導であり、ある時点における評価です。その結論は、テストされたシステム、バージョン、設定、アクセスの前提条件、条件に適用されます。潜在的な経路は調査され、確認された悪用可能な経路は再現可能な証拠とともに文書化されます。

なお、合意された範囲にわたる体系的な作業であっても、すべての脆弱性や攻撃経路が発見されることを保証するものではなく、責任あるエンゲージメントであってもテスターが侵害を達成することを保証するものではありません。

機関のweb3環境において、このシナリオから証拠へのプロセスは、同じ資金取り扱いチェーンのテスト可能な対象範囲である5つの連結された能力にわたって実行されます。これらは、チェーンを支えるインフラ、その3つのオフチェーン制御、そしてそれが引き渡すオンチェーントランザクションにまたがっています。1つの経路が複数の能力を横断し得るため、これらは互いに連結しています。

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

Part 4: Web3 Attack Surfaces: A Penetration Testing Overviewでは、中心となる目的——合意された稼働環境全体にわたる条件が再現可能な影響へと連鎖するかどうかを確立すること——を変えることなく、これらの対象範囲とその連結を図式化しています。

他の保証手段との位置づけ

最も明確な比較軸は保証の目的——その業務が支援することを意図した意思決定と、それが生み出すことが期待される証拠——によるものです。以下の図に示すように、手法は重なり合うことがあり、規律は協働することができ、あるチームが完全に静的で別のチームが完全に動的であると見なすことに依存する有用な境界線は存在しません。同じ対象——デプロイされたコントラクト、クラウドや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

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

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

始め方

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

その後、スコーピングの会話によって、対象、アクセスの前提条件、保護策、期待される成果物を整合させることができます。Part 3: Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testingでは、エンゲージメントを実行に移すために必要な承認、安全性、調整について取り上げています [4]。

これを実行に移す準備ができたら、BlockSecとともに保証上のギャップをスコーピングし、テスト開始前に対象、証拠、保護策を整合させてください。

攻撃対象範囲ガイドを引き続きご覧ください: