このシリーズの最初の2つの記事では、暗号資産機関がなぜブロックチェーンペネトレーションテストを必要とするのか(第1部)、そしてこの分野が何であるか(第2部)について説明しました。本記事では、機関レベルのエンゲージメントを安全に準備し実施する方法、すなわちRules of Engagement(RoE)、本番環境における安全対策、そして発見事項を修正へとつなげる修復と再テストについて取り上げます。以下に示すのがエンゲージメントのライフサイクルです。
Web3は特有の形で本番テストのリスクを高めます。オンチェーンでのアクションは通常取り消し不可能であり、テスト活動はしばしばオンチェーンで公開され、対象システムは実際の資金を動かすことができます。そのため、以下の安全対策では、通常のエンゲージメントよりも環境の選択、金額の上限、鍵の取り扱い、照合作業をより重視しています。
Blockchain Penetration Testing
コントラクト、ノード、API、クラウドを横断して侵入経路を見つける
運用権限としてのRoE
米国国立標準技術研究所(NIST)によれば、RoEはセキュリティテストのガイドラインと制約を定めるものです[1]。機関レベルのエンゲージメントにおいて、RoEはテストを実施するという決定を、明確な目的、明確な範囲、そして行動する権限を持つ指名された担当者を伴う、正式に承認された指令へと転換します。
この指令が重要である理由は、テストチームが契約書や資産リストから権限を安全に推測することはできないためです。評価対象となるリスク、関与するシステム、そしてそれらに責任を持つ人々について共有された決定がなければ、チームは誤った経路をテストしたり、重要な依存関係を除外したり、重大な発見事項を検証する権限を欠いたりする可能性があります。
出発点となるのは、テストが支援しようとしているビジネス上の決定です。目的はローンチ前の公開範囲に関するものかもしれません。顧客およびアプリケーションプログラミングインターフェース(API)の認可、あるいは特権を持つクラウドおよび運用システムへの到達可能性に焦点を当てる場合もあります。また、署名や引き出しのワークフローをテストしたり、サードパーティ統合を評価したりする場合もあります。この目的により、重要なシステム、低減すべきリスク、そして経営陣が意思決定を行うために必要な結果が特定されます。
この目的は、運用モデルに沿った範囲へと落とし込まれるべきです。暗号資産機関においては、これには一般的に、顧客向けのWeb、モバイル、アプリケーションプログラミングインターフェース(API)サービス、クラウドアカウントおよびアイデンティティ・アクセス管理(IAM)、継続的インテグレーション/継続的デリバリー(CI/CD)システムとシークレット、運用コンソール、ウォレットと承認ワークフロー、署名システム、台帳と引き出しサービス、そしてそれらを接続するベンダーが含まれます。これらのコンポーネントは、顧客および内部チームが資金関連のアクションを開始、承認、署名、リリース、照合する方法をまとめて統制しています。機関とテストチームはまた、関連する視点についても合意する必要があります。外部の攻撃者、一般ユーザー、パートナー、低権限の従業員、あるいは侵害されたと想定されるアイデンティティなどです。
範囲内の各システム、アカウント、インターフェース、活動には、指名されたオーナーと明確な承認経路が必要です。これは、カストディプロバイダー、ウォレットインターフェース、リモートプロシージャコール(RPC)プロバイダー、サービスとしてのソフトウェア(SaaS)プラットフォーム、アイデンティティプロバイダー、コードホスト、マネージドサービスなど、サードパーティの依存関係にも同様に当てはまります。プロバイダーが所有する環境をテストするには、そのプロバイダーからの書面による許可が必要です。機関側の承認のみでは、プロバイダーのシステムに対する活動を承認することにはならない場合があります。
目的、範囲、承認経路が組み合わさることで、チームが評価してよい対象が定まります。次のステップでは、チームがどのようにその評価を実施してよいかを記録します。
運用上の境界
運用上の境界は、指令が合意された後の実施を統制する書面による制約です。これらは、範囲内にあるものと、許可される活動とを区別します。本番の引き出しサービスは、認可経路の検証のために範囲に含まれる場合がありますが、実際の顧客の引き出し、秘密鍵の抽出、永続化の変更、負荷を発生させる攻撃は引き続き禁止されます。
この区別により、不確実性が運用上のリスクへと発展することを防ぎます。本番エンゲージメント中、機関とテストチームは、どの手法が許可されているか、いつ活動を停止すべきか、誰がその決定を下せるか、そして証拠をどのように取り扱ってよいかを事前に把握しておく必要があります。そうでなければ、承認されたテストであっても、回避可能なサービスや顧客への影響を生じさせる可能性があります。
RoEには、テスト開始前にこれらの決定を記録しておくべきです。さらに、この文書は、エンゲージメント中に根本的な問題を再度提起することなく、双方が行動できるほど正確でなければなりません。
以下の表は、上記で確立されたテスト指令を実践的なRoE記録へと落とし込んだものです。これは、テスト前に確定しておくべき決定事項をグループ化しています。何が評価対象か、誰が承認されているか、どの活動と制限が適用されるか、当事者間でどのように調整するか、そして証拠をどのように取り扱うかです。これはそのままコピーする汎用チェックリストではありません。記録される値は、機関の運用モデル、テストの視点、本番リスクを反映したものであるべきです。
| RoEの項目 | テスト前に記録すべき決定事項 |
|---|---|
| 目的と範囲 | ビジネス上の決定、範囲内のシステムおよびインターフェース、オーナー、そしてテストすべき攻撃者の視点。 |
| 承認 | 書面による権限、テスト用アイデンティティ、承認されたアクセス経路、およびサードパーティ環境に対するプロバイダーの承認。 |
| テスト手法と完了条件 | 許可された手法と、アクセスの実証、権限昇格、あるいは制御されたワークフローシミュレーションなど、チームが停止すべき時点。 |
| 運用上の制限 | テストウィンドウ、リクエストレートおよび同時実行数の上限、アカウント操作の制限、データアクセスの境界、変更凍結期間、そして承認されたシナリオでトランザクションを使用する場合の、許可されたネットワーク、テストアドレス、トランザクションの種類、最大テスト金額、ガス予算。 |
| 禁止活動 | サービス拒否(DoS)テスト、ソーシャルエンジニアリング、実際の顧客資産の移動、秘密鍵の書き出し、永続化、承認されていない本番環境の変更などが例として挙げられます。 |
| 機微なワークフロー | 指定されたウォレットおよびアカウント、許可リストに登録された送金先、最大テスト金額、承認参加者、想定されるポリシーの挙動、照合手順、そして検証が到達してよいトランザクション制御チェーンの最も先の地点。 |
| コミュニケーションと一時停止 | 通常時の通知モデル、保護された安全連絡チャネル、エスカレーション連絡先、重大な発見事項の閾値、テストを一時停止または再開する指名された権限者、そして承認された公開トランザクションのブロードキャストに対する想定される可観測性とアラート対応。 |
| 証拠の取り扱い | 必要最小限の証拠、データの最小化とマスキング、暗号化、承認された受信者、保持期間、破棄の確認、そして承認されたテストトランザクションに関する、内部承認および台帳の証拠に紐づいたトランザクションハッシュとネットワークメタデータ。 |
実行範囲の境界が合意されたら、機関はテストで遭遇することになる、展開済みシステムと運用条件を準備することができます。
運用環境と稼働中サービスの保護
運用環境とは、展開されたシステムと、それを取り巻くビジネス活動、すなわち信頼境界、資金フロー、サービス依存関係、運用ワークフロー、そして各コンポーネントに責任を持つ人々のことです。これは、テストの発見事項がその実際の意味を持つ文脈です。
この文脈が重要である理由は、同じ技術的な脆弱性であっても、その結果は大きく異なる場合があるためです。APIの問題、クラウドの権限設定、承認ワークフローの脆弱性は、顧客データ、内部業務、署名権限、残高の変更、あるいは引き出しに影響を及ぼす可能性があります。稼働中の取引所、決済会社、カストディアン、ウォレットプロバイダーにとって、テストは取引、決済、入金、出金、清算、サポート業務と共存できるものでなければなりません。
現状把握には、資産およびサービスのインベントリ、アーキテクチャと統合ポイント、クラウドおよびアイデンティティモデル、運用ワークフロー、サードパーティの依存関係を含めるべきです。計画立案では、関連するビジネス上のウィンドウ、予定されているリリース、変更凍結期間、高負荷期間、ホットウォレットの活動、その他の運用イベントも特定すべきです。テスト中に観測すべきサービス健全性のシグナルには、トランザクション数およびAPI呼び出し数、応答時間、エラー率、キューの深さ、署名サービスの健全性、ウォレットサービスの可用性が含まれるべきです。運用環境には、トランザクションの開始と制御に用いられる本番サービス、アイデンティティ、運用ワークフロー、外部依存関係が含まれます。RoEには、承認されたテスト環境、テスト用アイデンティティ、署名または引き出しワークフロー内で許可される手順、そして制御された検証シナリオに適用される安全対策が記録されます。これらのパラメータにより、評価は機関の統制事項に焦点を当てたものとなり、同時に通常の顧客業務と運用活動が保護されます。
欧州連合(EU)のデジタルオペレーショナルレジリエンス法(DORA)は、高規制業種における有用な参照事例です。脅威主導型ペネトレーションテストの対象として選定された金融事業体については、第26条により、テストは重要または重大な機能を対象とし、関連する外部委託された情報通信技術(ICT)サービスを含め、それらを支える本番システム上で実施することが求められています[2]。これは本番環境でのテストを一般的に承認するものではありません。各機関は依然として自らの権限、安全対策、および適用される法的・契約上の承認を必要とします。
この本番環境の基本方針により、機関は資金や顧客アクセスに直接影響を及ぼし得るワークフローに対して、より具体的な安全対策を適用できるようになります。
機微なワークフローの境界
機微なワークフローとは、その通常の動作が資金、顧客アクセス、または記録の完全性に直接影響を及ぼし得るシステムおよびアクションです。これには、署名および引き出しワークフロー、特権を持つ本番環境へのアクセス、顧客データの取り扱い、台帳操作が含まれます。
これらのワークフローには、より厳格な境界が必要です。なぜなら、現実的なテストは、統制を検証する行為から、顧客や財務上の結果を変更する行為へと逸脱してしまう可能性があるためです。リスクは技術的な混乱にとどまりません。不正な資金移動、誤った残高、機微なデータの露出、あるいはテスト活動と実際のインシデントとの混同も含まれ得ます。統制の失敗が資金に影響を及ぼし得る場合、その取り消しは困難または不可能なことがあるため、これらの境界は、テストが意図しない、あるいは許可されていない資金移動を一切生じさせないようにしなければなりません。
署名および引き出しワークフローには、機関がリクエストをどのように認証し、ポリシーを適用し、承認をルーティングし、結果を照合するかを検証する、制御されたシナリオが必要です。RoEには、指定されたテスト用アカウント、承認された参加者、想定されるポリシーの挙動、シナリオの上限、そしてワークフローを検証するために必要な証拠が特定されています。次に、許可される最も先のワークフロー段階、すなわちリクエストの作成、ポリシー判定、承認表示、署名リクエスト、リリース判定、または照合を記録します。テスト用アイデンティティは、合意されたアクセスプロセスを通じてプロビジョニング、使用、廃止されます。同様の規律が、特権アクセス、顧客データ、台帳操作にも適用されます。アクセスモデル、想定されるシステムの挙動、証拠の境界はテスト開始前に合意され、顧客データは必要な場合にのみアクセスされ、証拠においては最小化・マスキングされ、承認された証拠保管庫内に保持されます。
これらの統制により、機微な経路を通常のアプリケーション機能として扱うことなく、本番環境でテストすることが可能になります。また、これにより運用チームとテストチームは、稼働中の活動を調整するための共通の基盤を得ることができます。
テストと調整
テストと調整は、エンゲージメント中の稼働中の運用モデルです。これらは、テストが進行している間、サービスオーナー、セキュリティ運用チーム、インシデント対応機能、テストリーダーを結びつけます。
このモデルが必要である理由は、想定されるテスト活動と実際のセキュリティインシデントが似たように見える場合があるためです。監視、通知、あるいは一時停止の決定が不明確であると、テストがインシデント対応を遅らせたり、本番環境での対応が必要かどうかについて混乱を生じさせたりする可能性があります。
コミュニケーションモデルは、誰がテスト計画の全体を把握しているか、誰が時間に敏感な通知を受け取るか、そして誰が活動を一時停止または再開できるかを特定します。これは目的によって異なります。機微なシステムに関しては、セキュリティ運用センター(SOC)との緊密な連携を必要とするテストもあれば、限定的な情報開示のテストでは、監視が活動を検知し、エスカレーションが適切な人物に届くかどうかを評価します。制御されたシナリオがトランザクション関連のワークフローを実行する場合、計画には、カストディ、ウォレット、トランザクションスクリーニング、監視の各プロバイダーからの関連する通知や想定されるアラートも含まれます。専用の安全連絡窓口と指名された一時停止権限者は、常時連絡可能な状態を維持します。サービスオーナーとテストチームは、エラーバジェットからの逸脱、95パーセンタイル(p95)の応答時間やキューの深さの予期しない増加、疑わしいアカウントまたはウォレットの活動、重大な照合上の不一致、あるいは予定外のセキュリティアラートなど、測定可能な停止基準について合意します。
この準備は、運用上のレジリエンスを強化することにもつながります。香港証券先物委員会(SFC)は、仮想資産取引プラットフォーム運営者に対し、24時間365日の監視と文書化されたエスカレーション手順を維持すること、そして関連するサードパーティとの緊急時・事業継続訓練を実施することを求めています[3]。これらの規制上の参照は例示であり、法的助言ではありません。適用可能性は管轄区域ごとに異なり、弁護士に確認すべきです。
この図は、テストが進行中に適用される制御ループを示しています。その中心的なポイントは、RoEの境界が承認の時点で終わるわけではないということです。監視と安全連絡チャネルは、これらの境界を、再開、一時停止、封じ込め、あるいは検証済みの発見事項を修復へと引き渡すという決定へと転換します。これがここで取り上げられているのは、これらの決定が、先に定義された範囲や本番環境の準備ではなく、稼働中の調整作業に属するためです。
同じモデルが重大な発見事項にも適用されます。すなわち、不正な資金移動への実証された経路、署名権限や本番環境の制御プレーンの侵害、極めて機微な顧客データの露出、あるいは重要なサービスに対する重大なリスクです。対応経路には、エスカレーションの閾値、発見事項を分類する人物、関連する活動を一時停止する権限、そして封じ込め、修復、検証のプロセスを特定すべきです。ペネトレーションテストチームは問題を実証し報告しますが、本番環境に関する決定、顧客への連絡、修復に関する権限は機関側が保持します。重大な発見事項の通知は、まず保護された安全連絡チャネルを使用し、その後、不必要なエクスプロイトの詳細を露出させない、合意された書面記録を続けるべきです。
発見事項が封じ込められ、担当者に割り当てられたら、そのエンゲージメントの価値は、機関がその結果を検証済みの統制改善へと転換できるかどうかにかかっています。
修復、再テスト、そして通常状態への復帰
修復と再テストは、実証された脆弱性を検証済みの改善へと転換する終結プロセスです。通常状態への復帰は同じプロセスの一部であり、テストアクセス、制御されたシナリオ、収集された証拠が、新たな長期的リスクとなってはなりません。
この最終段階が、エンゲージメントがリスクを低減するのか、それとも単に報告書を生み出すだけに終わるのかを決定づけます。オーナー、修復経路、検証条件のない発見事項は、同じ攻撃経路が本番環境に残存したまま、未対応のままになる可能性があります。
テスト開始前に、発見事項がどのようにエンジニアリング、クラウド、ウォレット運用、あるいはビジネス統制のワークフローに取り込まれるか、誰が修復の責任を持つか、そしてどの発見事項が再テストを必要とするかを特定してください。終結時には、一時的なテスト用アイデンティティ、権限、制御されたシナリオは、意図された構成へと戻され、サービスオーナーは関連する健全性指標が想定される範囲内に留まっていることを確認します。最終的な記録では、各発見事項をその証拠、影響、オーナー、修復計画、再テスト条件に紐づけます。制御されたトランザクション関連シナリオについては、ワークフローの参照情報、テスト用アイデンティティ、タイムスタンプ、承認記録、そして結果として生じた台帳エントリも紐づけられます。シナリオのために作成された一時的なアクセス、承認、テスト構成はすべて廃止されます。証拠は、合意された期間のみ保持され、その後、安全に破棄または返却されます。
その結果は単なる脆弱性リストではなく、機関の次の運用上の意思決定を支えることができる、テスト済み、修復済み、そして再テスト済みの統制の集合です。
結論
ブロックチェーンペネトレーションテストの準備は、機関レベルの取り組みです。機関は目的、運用上の文脈、権限、サービス上の制約、対応モデルを定義し、テストチームはその準備された環境に対して敵対的な検証を適用します。
これらの要素が整うことで、ペネトレーションテストのエンゲージメントは単なる技術的な演習を超えたものになります。それは、機関が展開しているシステム、人々、プロセスが攻撃にどれだけ耐えられるかを理解するための、制御された手段となります。
BlockSecは、機関がこのプロセスを準備し実施することを支援します。範囲の定義、運用環境のマッピング、RoEおよび本番環境における安全対策の策定、そして発見事項を修復済み・再テスト済みの統制へと転換することです。次回のテストに向けたRules of Engagementと本番環境における安全対策を計画するには、スコーピングに関する相談を依頼してください。詳細情報はご要望に応じて提供いたします。
シリーズの続き:
また、本シリーズでは近日中に以下も公開予定です:
- 第5部: Authorization and Signing Security: Web, dApps, and Mobile
- 第6部: Cloud and CI/CD Security: Automated Operations Attack Surfaces
- 第7部: Treasury Control-Plane Security: Signing and Withdrawal Approvals
- 第8部: Exchange Ledger Security: Theft Paths and Data-Plane Logic
Blockchain Penetration Testingピラーページでは、エンゲージメント全体の視点を提供しています。
Best Security Auditor for Web3
ローンチ前に設計、コード、ビジネスロジックを検証する
参考文献
初出順に番号を付与。
- 米国国立標準技術研究所, Rules of Engagement (ROE), CSRC Glossary.
- 欧州連合, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Article 26.
- 香港証券先物委員会, Circular to Licensed Virtual Asset Trading Platform Operators on Custody of Virtual Assets (2025年8月15日).
