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

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

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

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

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

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

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

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

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

目标、范围和授权路径共同确定了团队可以评估的内容。下一步则记录团队可以如何执行该评估。

运作边界

运作边界是达成授权任务后指导执行的书面约束条件。它们区分了范围内的内容与被允许的活动：一项生产环境的提现服务可能属于授权路径验证的范围，而真实客户提现、私钥提取、持久化更改和产生负载的攻击则仍被禁止。

这一区分防止了不确定性演变为运作风险。在生产环境测试期间，机构和测试团队需要事先知道哪些技术是被允许的、何时必须停止活动、谁可以做出该决定，以及证据应如何处理。否则，即使是经授权的测试也可能造成本可避免的服务或客户影响。

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

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

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

在执行边界达成一致后，机构便可以准备测试将遇到的已部署系统和运作条件。

运作环境与实时服务保护

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

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

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

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

这一生产基线使机构能够对可能直接影响资金或客户访问的工作流程应用更具针对性的防护措施。

敏感工作流程的边界

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

这些工作流程需要更严格的边界，因为若不加以限制，一次现实性的测试可能从验证控制措施演变为改变客户或财务结果。风险不仅在于技术性中断：它还可能包括未经授权的资金转移、错误的余额、敏感数据的暴露，或将测试活动与真实事件相混淆。当控制失效可能影响资金时，逆转可能十分困难甚至无法实现，因此这些边界必须防止测试产生任何非预期或未经授权的资金转移。

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

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

测试与协调

测试与协调是测试期间的实时运作模式。它们将服务负责人、安全运营团队、事件响应职能和测试负责人联系在一起。

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

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

这一准备工作也增强了运营韧性。香港证券及期货事务监察委员会（SFC）要求虚拟资产交易平台运营商保持全天候监控和有文档记录的升级程序，并与相关第三方进行应急演练和业务连续性演练[3]。这些监管参考仅为示例，并非法律建议；其适用性因司法管辖区而异，应与法律顾问确认。

该图展示了测试进行期间适用的控制回路。其核心要点是：交战规则边界并不止于授权：监控和安全渠道将这些边界转化为恢复、暂停、遏制的决策，或将经证实的发现移交进入补救流程。之所以出现在此处，是因为这些决策属于实时协调的范畴，而非早前范围界定或生产环境准备阶段的内容。

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

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

补救、复测与恢复正常

补救和复测是将已证实的弱点转化为经验证的改进措施的结案流程。恢复正常也是同一流程的一部分：测试访问权限、受控场景和收集的证据不得成为新的长期存在的风险。

这最后一个阶段决定了此次测试是降低了风险，还是仅仅产出了一份报告。一项没有负责人、补救路径和验证条件的发现可能会一直悬而未决，而同样的攻击路径仍然存在于生产环境中。

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

其结果不是一份漏洞清单，而是一套经过测试、修复和复测的控制措施，可支持机构做出下一步运营决策。