Back to Blog

機関向けブロックチェーンペネトレーションテストにおける交戦規定と本番環境の安全性

Code Auditing
2026年9月3日
16 min read
Key Insights
  • 有効なペナトレーションテスト業務は実施前に準備されるもので、明確な目的、合意されたスコープ、責任を負うオーナー、認可されたアクセスが必要であり、業務全体を通じて通常運用を維持する計画を伴う—この準備は、当該機関が価値をどのように動かし、管理しているかを反映するものである。

  • **ルールオブエンゲージメント(RoE)**文書は、権限、活動範囲の制限、コミュニケーション、エスカレーション、証拠の取り扱いを定めることで、業務を実行可能にする。

  • 本番環境でのテストには、サービス保護策、測定可能な停止基準、モニタリング、変更調整、および一時停止権限が必要であり、業務においては是正措置と再テストも定義し、発見された問題が検証済みの改善につながるようにすべきである。

このシリーズの最初の2本の記事では、暗号資産関連機関がなぜブロックチェーンペネトレーションテストを必要とするのか(Part 1)、そしてその分野が何であるか(Part 2)について説明しました。本記事では、機関向けエンゲージメントがどのように準備され、安全に実施されるかに焦点を当てます。エンゲージメントのルール(RoE)、本番環境における安全対策、そして発見事項を修正へとつなげる是正措置と再テスト——以下に示すエンゲージメントのライフサイクルです。

Figure 1. Institutional penetration testing engagement lifecycle.
Figure 1. Institutional penetration testing engagement lifecycle.

Web3は本番環境テストのリスクを特有の形で高めます。オンチェーンのアクションは通常不可逆的であり、テスト活動はしばしばオンチェーン上で公開され、対象となるシステムは実際の資金を動かす可能性があります。そのため以下の安全対策では、従来のエンゲージメントよりも、環境の選定、金額の上限、鍵の取り扱い、そして照合作業をより重視しています。

運用権限としてのRoE

米国国立標準技術研究所(NIST)によれば、RoEはセキュリティテストのガイドラインと制約を定めるものです[1]。機関向けエンゲージメントにおいて、RoEはテストを実施するという決定を、正式な権限を伴う任務——明確な目的、明確な範囲、そして行動する権限を持つ指名された担当者——へと転換します。

この任務が重要なのは、テストチームが契約書や資産リストから権限を安全に推測することができないためです。評価対象となるリスク、関連するシステム、そしてそれらに責任を持つ担当者について共通の合意がなければ、チームは誤った経路をテストしたり、重要な依存関係を除外したり、重大な発見事項を検証する権限を欠いたりする可能性があります。

出発点は、テストが支援することを意図しているビジネス上の意思決定です。目的は、ローンチ前の公開時のリスク露出に関するものかもしれません。顧客およびアプリケーションプログラミングインターフェース(API)の認可、あるいは特権的なクラウドおよび運用システムへの到達可能性に焦点を当てる場合もあります。また、署名や引き出しのワークフローをテストしたり、サードパーティ統合を評価したりする場合もあります。この目的によって、重要なシステム、低減すべきリスク、そして経営陣が意思決定を行うために必要な結果が特定されます。

目的は、運用モデルに沿った範囲へと落とし込まれるべきです。暗号資産関連機関では、これには一般的に、顧客向けのウェブ、モバイル、アプリケーションプログラミングインターフェース(API)サービス、クラウドアカウントおよびアイデンティティ・アクセス管理(IAM)、継続的インテグレーション・継続的デリバリー(CI/CD)システムとシークレット、運用コンソール、ウォレットと承認ワークフロー、署名システム、台帳と引き出しサービス、そしてそれらを接続するベンダーが含まれます。これらの構成要素が一体となって、顧客および社内チームが資金関連のアクションを開始、承認、署名、実行、照合する方法を規定しています。機関とテストチームはまた、関連する視点——外部攻撃者、通常のユーザー、パートナー、低権限の従業員、または侵害されたと想定されるアイデンティティ——についても合意すべきです。

対象範囲内の各システム、アカウント、インターフェース、活動には、指名された所有者と明確な承認経路が必要です。これはカストディプロバイダー、ウォレットインターフェース、リモートプロシージャコール(RPC)プロバイダー、サービスとしてのソフトウェア(SaaS)プラットフォーム、アイデンティティプロバイダー、コードホスト、マネージドサービスなど、サードパーティの依存関係にも当てはまります。プロバイダーが所有する環境をテストするには、そのプロバイダーからの書面による許可が必要です。機関による認可のみでは、プロバイダーのシステムに対する活動を認可したことにはならない場合があります。

目的、範囲、承認経路が組み合わさることで、チームが評価できる内容が確立されます。次のステップでは、チームがその評価をどのように実施できるかを記録します。

運用上の制約

運用上の制約とは、任務が合意された後に実行を統制する書面による制約です。これらは、対象範囲内にあるものと許可される活動を区別します。例えば、本番環境の引き出しサービスは認可経路の検証のために対象範囲に含まれる場合がありますが、実際の顧客の引き出し、秘密鍵の抽出、永続化の変更、負荷を発生させる攻撃は禁止されたままです。

この区別は、不確実性が運用上のリスクとなることを防ぎます。本番環境でのエンゲージメント中、機関とテストチームは、どの手法が許可されているか、いつ活動を停止すべきか、誰がその決定を下せるか、証拠がどのように扱われるべきかを事前に把握しておく必要があります。そうでなければ、認可されたテストであっても、回避可能なサービスや顧客への影響を生じさせる可能性があります。

RoEは、テスト開始前にこれらの決定を記録すべきです。さらに、この文書は、エンゲージメント中に根本的な問題を再度議論することなく、両当事者が行動できるほど正確であるべきです。

以下の表は、上記で確立されたテスト任務を実用的なRoE記録へと落とし込んだものです。テスト前に確定すべき決定事項——何が評価されるか、誰が認可されているか、どの活動と制限が適用されるか、当事者間でどのように調整するか、証拠がどのように扱われるか——をグループ化しています。これはそのままコピーする汎用的なチェックリストではありません。記録される値は、機関の運用モデル、テストの視点、本番環境のリスクを反映すべきです。

RoEトピック テスト前に記録すべき決定事項
目的と範囲 ビジネス上の意思決定、対象範囲内のシステムとインターフェース、所有者、テストされる攻撃者の視点。
認可 書面による権限、テスト用アイデンティティ、承認されたアクセス経路、サードパーティ環境に対するプロバイダーの承認。
テスト方法と完了条件 許可された手法、およびアクセスの実証、権限昇格、統制されたワークフローシミュレーションなど、チームが停止すべき時点。
運用上の制限 テストウィンドウ、リクエストレートおよび同時実行数の制限、アカウント操作の制限、データアクセスの境界、変更凍結期間、そして承認されたシナリオがトランザクションを使用する場合には、許可されたネットワーク、テスト用アドレス、トランザクション種別、最大テスト金額、ガス予算。
禁止される活動 例としては、サービス拒否(DoS)テスト、ソーシャルエンジニアリング、実際の顧客資産の移動、秘密鍵のエクスポート、永続化、未承認の本番環境変更などが挙げられます。
機密性の高いワークフロー 指定されたウォレットおよびアカウント、許可リストに登録された送金先、最大テスト金額、承認参加者、想定されるポリシー動作、照合手順、および検証が到達しうるトランザクション制御チェーンの最遠点。
コミュニケーションと一時停止 通常の通知モデル、保護された安全連絡チャネル、エスカレーション連絡先、重大な発見事項の判断基準、テストの一時停止・再開の権限を持つ指名された担当者、承認された公開トランザクションブロードキャストに対する想定される可観測性とアラート対応。
証拠の取り扱い 必要最小限の証拠、データの最小化と編集、暗号化、承認された受領者、保持期間、破棄の確認、そして承認されたテストトランザクションについて、内部承認および台帳証拠に紐づけられたトランザクションハッシュとネットワークメタデータ。

実行境界が合意されると、機関はテストが遭遇するであろう展開済みシステムと運用条件を準備することができます。

運用環境と稼働中サービスの保護

運用環境とは、展開済みシステムとそれを取り巻くビジネス活動——信頼境界、資金フロー、サービス依存関係、運用ワークフロー、および各構成要素に責任を持つ担当者——のことです。これは、テストの発見事項が実際の意味を持つようになる文脈です。

この文脈が重要なのは、同じ技術的な弱点であっても、その結果が大きく異なる可能性があるためです。APIの問題、クラウドの権限設定、承認ワークフローの弱点は、顧客データ、社内業務、署名権限、残高変更、あるいは引き出しに影響を及ぼす可能性があります。稼働中の取引所、決済会社、カストディアン、ウォレットプロバイダーの場合、テストは取引、決済、入金、引き出し、決済処理、サポート業務と共存する必要もあります。

現状の把握は、資産およびサービスのインベントリ、アーキテクチャと統合ポイント、クラウドおよびアイデンティティモデル、運用ワークフロー、サードパーティの依存関係をカバーすべきです。計画にはまた、関連するビジネス上の重要な時期、予定されているリリース、変更凍結期間、高負荷期間、ホットウォレットの活動、その他の運用イベントの特定も含まれるべきです。テスト中に観察されるべきサービスヘルスシグナルには、トランザクションおよびAPIの量、応答時間、エラー率、キューの深さ、署名サービスの健全性、ウォレットサービスの可用性が含まれます。運用環境には、トランザクションの開始と制御に使用される本番サービス、アイデンティティ、運用ワークフロー、外部依存関係が含まれます。RoEは、承認されたテスト環境、テスト用アイデンティティ、署名または引き出しワークフロー内で許可されるステップ、および統制された検証シナリオに適用される安全対策を記録します。これらのパラメータにより、通常の顧客活動および運用活動を保護しながら、評価が機関の統制に焦点を当て続けることができます。

欧州連合のデジタル・オペレーショナル・レジリエンス法(DORA)は、高規制環境における有用な参照基準を提供します。脅威主導型ペネトレーションテストの対象として選定された金融事業者に対し、第26条は、重要または枢要な機能を対象とし、関連する外部委託された情報通信技術(ICT)サービスを含め、それらを支える本番システム上でテストを実施することを求めています[2]。これは本番環境テストに対する一般的な認可を与えるものではなく、各機関はそれぞれ独自の権限、安全対策、および適用される法的・契約上の承認を依然として必要とします。

この本番環境の基準によって、機関は資金や顧客アクセスに直接影響を及ぼしうるワークフローに対して、より具体的な安全対策を適用できるようになります。

機密性の高いワークフローの境界

機密性の高いワークフローとは、その通常の運用が資金、顧客アクセス、または記録の完全性に直接影響を及ぼしうるシステムおよびアクションのことです。これには、署名および引き出しワークフロー、特権的な本番環境アクセス、顧客データの取り扱い、台帳操作が含まれます。

これらのワークフローにはより厳格な境界が必要です。なぜなら、そうでなければ現実的なテストが、統制の検証から顧客や財務上の結果を変更してしまう領域へと逸脱する可能性があるためです。リスクは技術的な混乱だけにとどまりません。未承認の資金移動、誤った残高、機密データの露出、テスト活動と実際のインシデントとの混同などが含まれる可能性があります。統制の失敗が資金に影響を及ぼしうる場合、その取り消しは困難または不可能な場合があるため、これらの境界は、テストが意図しない、または未承認の資金移動を一切生じさせないようにする必要があります。

署名および引き出しワークフローには、機関がリクエストをどのように認証し、ポリシーを適用し、承認をルーティングし、結果を照合するかを検証する統制されたシナリオが必要です。RoEは、指定されたテストアカウント、承認された参加者、想定されるポリシー動作、シナリオの上限、そしてワークフローを検証するために必要な証拠を特定します。そして、許可される最遠のワークフローステップ——リクエスト作成、ポリシー判定、承認表示、署名リクエスト、実行決定、または照合——を記録します。テスト用アイデンティティは、合意されたアクセスプロセスを通じてプロビジョニング、使用、廃止されます。同様の規律が特権アクセス、顧客データ、台帳操作にも適用されます。アクセスモデル、想定されるシステム動作、証拠の境界は、テスト開始前に合意されます。顧客データは必要な場合にのみアクセスされ、証拠として最小化・編集され、承認された証拠保管庫内に保管されます。

これらの統制により、機密性の高い経路を通常のアプリケーション機能として扱うことなく、本番環境でテストすることが可能になります。また、運用チームとテストチームが稼働中の活動を調整するための共通の基盤も提供します。

テストと調整

テストと調整とは、エンゲージメントのための稼働中の運用モデルです。テストが進行している間、サービス所有者、セキュリティ運用チーム、インシデント対応機能、テストリーダーを結びつけます。

このモデルが必要なのは、想定されるテスト活動と実際のセキュリティ事象が似て見える可能性があるためです。監視、通知、あるいは一時停止の判断基準が明確でない場合、テストがインシデント対応を遅らせたり、本番環境での対応が必要かどうかについて不確実性を生じさせたりする可能性があります。

コミュニケーションモデルは、誰がテスト計画の全体を把握しているか、誰が時間的制約のある通知を受け取るか、誰が活動を一時停止または再開できるかを特定します。これは目的によって異なります。機密性の高いシステムを対象とした一部のテストでは、セキュリティ運用センター(SOC)との緊密な調整が必要となる一方、限定開示型のテストでは、監視が活動を検知できるか、エスカレーションが適切な担当者に届くかを評価します。統制されたシナリオがトランザクション関連のワークフローを実行する場合、計画にはカストディ、ウォレット、トランザクションスクリーニング、監視の各プロバイダーからの関連通知および想定されるアラートも含まれます。専用の安全連絡先と指名された一時停止権限者は、常時連絡が取れる状態を維持します。サービス所有者とテストチームは、エラーバジェットからの逸脱、95パーセンタイル(p95)応答時間やキューの深さの予期しない増加、疑わしいアカウントやウォレットの活動、重大な照合の不一致、あるいは計画外のセキュリティアラートなど、測定可能な停止基準について合意します。

この準備はまた、運用上のレジリエンスを強化します。香港証券先物委員会(SFC)は、仮想資産取引プラットフォーム運営者に対し、24時間365日の監視と文書化されたエスカレーション手順を維持すること、および関連するサードパーティと緊急時・事業継続の演習を実施することを求めています[3]。これらの規制に関する参照は例示であり、法的助言ではありません。適用可能性は法域ごとに異なるため、弁護士に確認する必要があります。

Figure 2. Testing and coordination control loop.
Figure 2. Testing and coordination control loop.

この図は、テストが進行している間に適用される制御ループを示しています。その核心は、RoEの境界が認可の時点で終わるわけではないということです。監視と安全連絡チャネルによって、これらの境界は、再開、一時停止、封じ込め、あるいは検証済みの発見事項を是正措置へと引き渡すといった判断へと転換されます。この図がここに登場するのは、これらの判断が範囲の初期定義や本番環境準備ではなく、稼働中の調整に属するためです。

重大な発見事項も同じモデルによって統制されます。未承認の資金移動につながる実証済みの経路、署名権限または本番環境の制御プレーンの侵害、極めて機密性の高い顧客データの露出、あるいは重要なサービスに対する重大なリスクなどです。対応経路は、エスカレーションの閾値、発見事項を分類する担当者、関連活動を一時停止する権限、そして封じ込め、是正措置、検証のプロセスを特定すべきです。ペネトレーションテストチームは問題を実証し報告しますが、本番環境に関する決定、顧客への連絡、是正措置に関する権限は機関が保持します。重大な発見事項の通知は、まず保護された安全連絡チャネルを使用し、その後、不要な悪用の詳細を露出させない合意された書面記録が続くべきです。

発見事項が封じ込められ、担当者に割り当てられた後、エンゲージメントの価値は、機関がその結果を検証済みの統制改善へと転換できるかどうかにかかっています。

是正措置、再テスト、通常運用への復帰

是正措置と再テストは、実証された弱点を検証済みの改善へと転換する完了プロセスです。通常運用への復帰も同じプロセスの一部です。テスト用アクセス、統制されたシナリオ、収集された証拠が新たな長期的リスクとなってはなりません。

この最終段階が、エンゲージメントがリスクを低減するのか、それとも単なる報告書の作成に終わるのかを決定します。所有者、是正経路、検証条件のない発見事項は、同じ攻撃経路が本番環境に存在し続けたまま、未解決のまま残る可能性があります。

テスト開始前に、発見事項がエンジニアリング、クラウド、ウォレット運用、あるいはビジネス統制のワークフローにどのように取り込まれるか、誰が是正措置の責任を負うか、そしてどの発見事項が再テストを必要とするかを特定してください。終了時には、一時的なテスト用アイデンティティ、権限、統制されたシナリオを意図した構成に戻し、サービス所有者は関連するヘルス指標が想定される範囲内にとどまっていることを確認します。最終記録は、各発見事項をその証拠、影響、所有者、是正計画、再テスト条件に紐づけます。統制されたトランザクション関連のシナリオについては、ワークフロー参照、テスト用アイデンティティ、タイムスタンプ、承認記録、結果として生じた台帳エントリも紐づけられます。シナリオのために作成された一時的なアクセス、承認、テスト構成は廃止されます。証拠は合意された期間のみ保持され、その後安全に破棄または返却されます。

その結果得られるのは脆弱性のリストではなく、テスト済み、是正済み、再テスト済みの統制セットであり、これが機関の次の運用上の意思決定を支えることができます。

結論

ブロックチェーンペネトレーションテストの準備は、機関にとっての任務です。機関は目的、運用上の文脈、権限、サービス上の制約、対応モデルを定義し、テストチームはその準備された環境に対して敵対的な検証を適用します。

これらの要素が整えば、ペネトレーションテストのエンゲージメントは単なる技術的な演習以上のものとなります。それは、機関の展開済みシステム、人材、プロセスが攻撃に対してどのように持ちこたえるかを理解するための統制された手段となります。

BlockSecは、機関がこのプロセスを準備し実施することを支援します。範囲の定義、運用環境のマッピング、RoEおよび本番環境の安全対策の確立、そして発見事項を是正・再テスト済みの統制へと転換することです。次回のテストのためのエンゲージメントのルールと本番環境の安全性統制を計画するには、スコーピングに関する相談を依頼してください。詳細情報はご要望に応じて提供いたします。

シリーズの続き:

本シリーズでは、以下も近日公開予定です:

  • Part 5: Authorization and Signing Security: Web, dApps, and
  • Part 6: Cloud and CI/CD Security: Automated Operations Attack Surfaces
  • Part 7: Treasury Control-Plane Security: Signing and Withdrawal Approvals
  • Part 8: Exchange Ledger Security: Theft Paths and Data-Plane Logic

Blockchain Penetration Testing pillar pageでは、エンゲージメント全体のレベルでの概観を提供しています。

参考文献

初出順に番号付け。

  1. National Institute of Standards and Technology, Rules of Engagement (ROE), CSRC Glossary.
  2. European Union, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Article 26.
  3. Hong Kong Securities and Futures Commission, Circular to Licensed Virtual Asset Trading Platform Operators on Custody of Virtual Assets (15 August 2025).
Sign up for the latest updates
ニュースレター - 2026年8月
Security Insights

ニュースレター - 2026年8月

2026年8月、DeFiセキュリティ事件が3件発生し、大きな損失をもたらした。Cosmos EVMモジュールの残高同期脆弱性が6つのチェーンで悪用され約1480万ドルの被害。BaseのMoonwellは低流動性のMAMOトークンを狙ったオラクル価格操作で約910万ドルを失った。EthereumのTerm Financeは投票参加率がほぼゼロの状態でガバナンスを乗っ取られ約847万ドルの被害を受けた。

インシデントから規制へ:暗号資産機関にブロックチェーン侵入テストが必要な理由

インシデントから規制へ:暗号資産機関にブロックチェーン侵入テストが必要な理由

取引所、決済会社、カストディアン、ウォレット提供者は今、スマートコントラクトを超えた署名・カストディ・鍵・人・サプライチェーンで最大の損失を被っている。コード監査とトランザクション監視だけでは隙間が残り、従来のペネトレーションテストは暗号資産特有の署名や資金の意味論を見落としがちだ。本記事はブロックチェーンペネトレーションテスト連載の第一弾として、対象機関にとっての論点—リスクの実際の所在と、NYDFS、DORA、VARA、SFC、MASが5法域で敵対的テストをどう扱うか—を解説する。

インシデントから規制へ:暗号資産機関がブロックチェーンペネトレーションテストを必要とする理由

インシデントから規制へ:暗号資産機関がブロックチェーンペネトレーションテストを必要とする理由

取引所、決済事業者、カストディアン、ウォレット提供者は今、スマートコントラクトを超え、署名・カストディ・鍵・人・サプライチェーンで最大の損失を被っている。コード監査とトランザクション監視には隙間があり、従来の侵入テストは暗号資産の署名・資金の意味論を見落としがちだ。本稿はブロックチェーン侵入テストシリーズの第一弾として、リスクの所在と、NYDFS・DORA・VARA・SFC・MASの5法域が敵対的テストをどう扱うかを取り上げる。

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit
機関向けブロックチェーンペネトレーションテストにおける交戦規定と本番環境の安全性