机构级区块链渗透测试的交战规则与生产安全

本系列的前两篇文章阐述了加密机构为何需要区块链渗透测试（第一部分）以及该学科的内容是什么（第二部分）。本文将转向探讨如何安全地准备和开展机构级测试：交战规则（rules of engagement）、生产安全保障措施，以及将发现的问题转化为修复方案的补救与复测——下图展示了整个测试生命周期。

Web3 以一种特殊的方式提高了生产环境测试的风险：链上操作通常是不可逆的，测试活动往往在链上公开可见，且测试范围内的系统可能涉及真实资金的转移。因此，下文的保障措施在环境选择、价值限额、密钥管理和对账方面，比传统测试更为重视。

交战规则（RoE）作为操作权限依据

根据美国国家标准与技术研究院（NIST）的定义，交战规则（RoE）为安全测试设定了指导原则和约束条件 [1]。对于机构级测试而言，它将“进行测试”这一决定转化为一项经授权的正式任务：明确的目标、明确的范围，以及被指定拥有行动权限的人员。

这种正式授权之所以重要，是因为测试团队不能仅凭一份合同或资产清单来安全地推断其权限。如果对所评估的风险、涉及的系统以及负责这些系统的人员没有达成共识，测试团队可能会测试错误的路径、遗漏某个关键依赖项，或缺乏验证重大发现所需的权限。

测试的起点是该测试旨在支持的业务决策。目标可能涉及上线前的公开暴露面评估，也可能聚焦于客户和应用程序接口（API）的授权机制，或特权云系统和运营系统的可达性。它还可能针对签名或提现工作流进行测试，或评估第三方集成。该目标明确了哪些系统至关重要、需要降低哪些风险，以及管理层做出决策所需要的结果。

该目标应转化为与运营模式相匹配的测试范围。在加密机构中，这通常包括面向客户的网页、移动端和应用程序接口（API）服务；云账户和身份与访问管理（IAM）；持续集成和持续交付（CI/CD）系统及其密钥；运营控制台；钱包和审批工作流；签名系统；账本和提现服务；以及连接这些系统的供应商。这些组成部分共同决定了客户和内部团队如何发起、批准、签署、执行和对账与资金相关的操作。机构和测试团队还应就相关测试视角达成一致：外部攻击者、普通用户、合作伙伴、低权限员工，或假定已被入侵的身份。

测试范围内的每一个系统、账户、接口和活动都应有指定的负责人和明确的授权路径。这同样适用于第三方依赖方，包括托管服务提供商、钱包接口、远程过程调用（RPC）提供商、软件即服务（SaaS）平台、身份提供商、代码托管服务和托管服务提供商。测试由供应商拥有的环境需要获得该供应商的书面许可；仅凭机构自身的授权可能不足以授权针对供应商系统的测试活动。

目标、范围和授权路径共同确定了测试团队可以评估的内容。下一步则要记录团队可以以何种方式开展这项评估。

操作边界

操作边界是在达成正式授权后，用以规范执行过程的书面约束条件。它们区分了“在测试范围内”与“允许开展的活动”：例如，生产环境中的提现服务可能被纳入授权路径验证的测试范围，但真实的客户提现、私钥提取、持久化更改以及产生负载的攻击行为仍然是被禁止的。

这种区分可防止不确定性演变为操作风险。在生产环境测试过程中，机构和测试团队需要事先明确：允许使用哪些技术、何时必须停止活动、谁有权做出这一决定，以及如何处理证据。否则，即便是获得授权的测试，也可能造成本可避免的服务或客户影响。

交战规则（RoE）应在测试开始前记录这些决定。此外，该文件应足够精确，使双方在测试过程中无需重新讨论基本问题即可采取行动。

下表将上文所确立的测试授权任务转化为可操作的交战规则记录。它将测试开始前必须敲定的各项决定进行了分组：评估内容是什么、谁获得了授权、适用哪些活动和限制、双方如何协调，以及如何处理证据。这并非一份可原样照搬的通用清单；所记录的具体数值应反映该机构的运营模式、测试视角和生产环境风险。

交战规则主题	测试前需记录的决定
目标与范围	业务决策、测试范围内的系统和接口、负责人，以及需要测试的攻击者视角。
授权	书面授权、测试身份、已批准的访问路径，以及针对第三方环境的供应商批准。
测试方法与完成标准	允许使用的技术，以及团队必须停止的时点，例如已证明的访问权限、权限提升，或受控的工作流模拟。
操作限制	测试窗口、请求速率和并发限制、账户操作限制、数据访问边界、变更冻结期，以及在批准的场景中使用交易时，允许使用的网络、测试地址、交易类型、最大测试价值和 gas 预算。
禁止活动	示例包括拒绝服务测试、社会工程、真实客户资产转移、私钥导出、持久化，或未经批准的生产环境变更。
敏感工作流	指定的钱包和账户、白名单目标地址、最大测试价值、审批参与人员、预期的策略行为、对账步骤，以及验证可到达的交易控制链最远节点。
沟通与暂停机制	常规通知模式、受保护的安全沟通渠道、升级联系人、重大发现的判定阈值、有权暂停或恢复测试的指定人员，以及针对已批准的公开交易广播所预期的可观测性和告警处理方式。
证据处理	最小必要证据、数据最小化和脱敏处理、加密、经批准的接收方、保留期限、销毁确认，以及与批准的测试交易相关联的交易哈希和网络元数据，需与内部审批记录及账本证据相关联。

在达成执行边界的一致意见后，机构就可以着手准备测试将涉及的已部署系统和运营条件。

操作环境与实时服务保护

操作环境是指已部署的系统及其周边的业务活动：信任边界、资金流动、服务依赖关系、运营工作流，以及负责每个组成部分的人员。这正是测试发现获得其真实意义的背景所在。

这一背景之所以重要，是因为同一个技术弱点可能带来截然不同的后果。API 问题、云权限问题或审批工作流的弱点，可能影响客户数据、内部运营、签名权限、余额变动或提现操作。对于正在运营的交易所、支付公司、托管机构或钱包提供商而言，测试还必须与交易、支付、存款、提现、结算和客服支持等业务同时并存。

当前视图应涵盖资产和服务清单、架构和集成点、云和身份模型、运营工作流以及第三方依赖关系。规划阶段还应识别相关的业务窗口期、计划中的发布、变更冻结期、高峰业务时段、热钱包活动以及其他运营事件。测试期间应观察的服务健康信号包括交易和 API 流量、响应时间、错误率、队列深度、签名服务健康状况以及钱包服务可用性。操作环境包括用于发起和控制交易的生产服务、身份、运营工作流以及外部依赖项。交战规则（RoE）记录了经批准的测试环境、测试身份、签名或提现工作流中允许执行的步骤，以及适用于任何受控验证场景的保障措施。这些参数使评估工作能够聚焦于机构的控制措施，同时保护正常的客户和运营活动。

欧盟的《数字运营韧性法案》（Digital Operational Resilience Act，DORA）为高监管环境提供了一个有用的参考点。对于被选定进行威胁引导型渗透测试的金融实体，其第26条要求测试须覆盖关键或重要职能，并须在支持这些职能的生产系统上进行，包括相关的外包信息与通信技术（ICT）服务 [2]。这并非对生产环境测试的一般性授权；每家机构仍需获得自身的授权、保障措施以及适用的法律和合同批准。

这一生产环境基线使机构能够对可能直接影响资金或客户访问的工作流应用更具体的保障措施。

敏感工作流的边界

敏感工作流是指其正常运行可能直接影响资金、客户访问或记录完整性的系统和操作。这类工作流包括签名和提现工作流、特权生产环境访问、客户数据处理以及账本操作。

这些工作流需要更严格的边界，因为如果不加以约束，一次真实的测试可能会从验证某项控制措施演变为改变客户结果或财务结果。这里的风险不仅仅是技术层面的中断：它还可能包括未经授权的资金转移、余额错误、敏感数据暴露，或将测试活动与真实事件相混淆。当某项控制失效可能影响资金时，其后果往往难以甚至无法逆转，因此这些边界必须防止测试产生任何意外或未经授权的资金转移。

签名和提现工作流需要采用受控场景，以验证机构如何对请求进行身份验证、执行策略、路由审批以及对结果进行对账。交战规则（RoE）明确指定测试账户、经授权的参与人员、预期的策略行为、该场景的上限值，以及验证该工作流所需的证据。随后，它记录了允许测试到达的最远工作流步骤：请求创建、策略决策、审批展示、签名请求、放行决策或对账。测试身份通过约定的访问流程进行配置、使用和注销。同样的规范也适用于特权访问、客户数据和账本操作：访问模型、预期系统行为和证据边界须在测试开始前商定一致；客户数据仅在必要时才被访问，并在证据中进行最小化处理和脱敏，且始终保存在经批准的证据存储库内。

这些控制措施使得在生产环境中测试敏感路径成为可能，而不必将其视为普通的应用功能。它们还为运营团队和测试团队协调实时活动提供了共同的基础。

测试与协调

测试与协调是整个测试期间的实时运营模式。它将服务负责人、安全运营团队、事件响应职能部门和测试负责人联系在一起，共同支撑测试的开展。

这一模式之所以必要，是因为预期的测试活动与真实的安全事件可能看起来非常相似。如果监控、通知或暂停决策不明确，测试活动可能会延误事件响应，或造成是否需要采取生产环境行动的不确定性。

沟通模式明确了谁掌握完整的测试计划、谁接收时效性通知，以及谁有权暂停或恢复活动。这因测试目标而异：某些测试需要围绕敏感系统与安全运营中心（SOC）密切协调，而有限披露型测试则评估监控系统能否检测到活动、告警升级是否能触达正确人员。当受控场景涉及与交易相关的工作流时，该计划还需涵盖来自托管、钱包、交易筛查和监控提供商的相关通知及预期告警。专门的安全联系人和指定的暂停授权人员应始终保持可联系状态。服务负责人和测试团队须共同商定可衡量的停止标准，例如偏离错误预算、第95百分位（p95）响应时间或队列深度出现异常上升、可疑的账户或钱包活动、重大对账差异，或计划外的安全告警。

这种前期准备工作也增强了运营韧性。香港证券及期货事务监察委员会（SFC）要求虚拟资产交易平台运营商维持全天候（24/7）监控和有文档记录的升级流程，并与相关第三方共同开展应急和业务连续性演练 [3]。上述监管参考仅供说明之用，并非法律建议；其适用性因司法管辖区而异，应与法律顾问确认。

该图展示了测试进行过程中适用的控制回路。其核心要点在于：交战规则（RoE）所设定的边界并不会在授权完成后就止步——监控机制和安全沟通渠道将这些边界转化为具体的决策：恢复、暂停、遏制，或将已验证的发现移交进入补救流程。之所以在此处呈现，是因为这些决策属于实时协调的范畴，而非前文关于范围界定或生产环境准备的内容。

同样的模式也适用于重大发现的处理：例如已证实存在通向未经授权资金转移的路径、签名权限或生产控制平面被攻破、高度敏感客户数据暴露，或对关键服务构成重大风险。响应路径应明确升级阈值、负责对发现进行分类的人员、暂停相关活动的授权人员，以及遏制、补救和验证的流程。渗透测试团队负责验证并报告问题；机构则保留对生产环境决策、客户沟通和补救措施的最终决定权。重大发现的通知应首先通过受保护的安全沟通渠道发出，随后再提供一份经双方约定的书面记录，且该记录不应暴露不必要的漏洞利用细节。

一旦某项发现被遏制并分配责任人，此次测试的价值就取决于机构能否将该结果转化为经验证的控制改进措施。

补救、复测与恢复正常运营

补救和复测是将已证实的弱点转化为经验证的改进措施的收尾流程。恢复正常运营也是这一流程的一部分：测试访问权限、受控场景和已收集的证据都不应成为新的长期风险来源。

这一最终阶段决定了此次测试究竟能降低风险，还是仅仅停留于产出一份报告。一项没有明确负责人、补救路径和验证条件的发现，可能会一直处于未解决状态，而同样的攻击路径却依然存在于生产环境中。

在测试开始之前，应确定各项发现如何进入工程、云、钱包运营或业务控制工作流；谁负责相应的补救工作；以及哪些发现需要进行复测。测试结束时，临时测试身份、权限和受控场景应恢复至其预定配置，服务负责人须确认相关健康指标仍处于预期范围之内。最终记录将每项发现与其证据、影响、负责人、补救计划和复测条件相关联。对于受控的、与交易相关的场景，该记录还需关联工作流参考编号、测试身份、时间戳、审批记录以及最终生成的账本条目；为该场景创建的任何临时访问权限、审批或测试配置均须予以注销。证据仅在约定的期限内保留，之后须被安全销毁或归还。

最终产出的并非一份漏洞清单，而是一套经过测试、补救和复测的控制体系，可为机构下一步的运营决策提供支持。