DORA 渗透测试：普通测试、TLPT 与范围界定

DORA 带来了两种实质不同的采购决策。一种是数字运营韧性计划中的普通风险导向测试；另一种是由主管机构监督、规模大得多的威胁导向渗透测试（TLPT）。两者可能使用部分相同的技术，但目的、范围、治理、周期和证据完全不同。因此，在明确所需项目之前，供应商无法负责任地为“DORA 渗透测试”报价。

本文为金融实体及其支持团队提供教育性质的采购指导。它不判断 DORA 是否适用于某个组织，也不判断该实体是否已被指定实施 TLPT。实体应向主管机构和合格法律顾问确认这些问题。常规渗透测试可以支持 DORA 测试计划，但它本身不能满足 DORA 的全部义务，更不能被当作合规认证。

先确定测试轨道，再讨论供应商标签

DORA 设有两个相互关联的测试层级。根据第 24 条，除微型企业外，金融实体应建立、维护并审查风险导向的数字运营韧性测试计划。对于支持关键或重要职能的所有 ICT 系统和应用，实体至少每年要实施适当测试。第 25 条列举了多种可用方法，包括漏洞评估和扫描、源代码审查、场景测试、端到端测试以及渗透测试。条文并没有要求每个系统每年都做一次渗透测试。

TLPT 是第 26 条和第 27 条规定的高级测试层。它适用于相关主管机构依据监管标准确定的金融实体。强制 TLPT 对象不包括微型企业以及第 16(1) 条第一款所述实体。被指定的实体通常至少每三年实施一次 TLPT；主管机构可根据实体风险状况和运营情形缩短或延长周期。测试覆盖若干或全部关键或重要职能，并利用定向威胁情报驱动红队，在支持这些职能的真实生产系统上开展行动。

因此，采购流程的第一个产物应是一份简短的适用性备忘录：写明法律实体、监管者、关键或重要职能、已确认的 TLPT 指定状态，以及测试必须支持的具体决策。这样可以避免一种常见失败：同时请多家供应商为“DORA 渗透测试”报价，但每家理解的服务完全不同。

从关键或重要职能推导测试范围

IP 地址清单是范围分析的结果，不是起点。首先识别那些一旦中断，可能严重损害财务表现、服务连续性或持续满足授权条件的职能。对每项职能，映射业务服务、流程负责人、用户旅程、支撑应用、身份和权限、基础设施、数据流、恢复依赖以及 ICT 第三方。记录每项依赖运行在哪里，以及谁有权批准测试。

对于常规风险导向测试，这张地图帮助实体作出可辩护的方法选择。面向互联网的客户门户可能需要使用授权账户的应用测试；身份平台可能需要配置审查与攻击路径测试结合；结算流程可能需要场景和端到端检查。为了让年度覆盖要求可以核查，计划应记录本周期中每个系统由哪种方法覆盖、发生了什么变化，以及存在哪些允许的限制。强制覆盖缺口应被升级处理；记录风险接受不能免除该项要求。

在 TLPT 中，职能地图会转化为正式范围说明。实体提出应纳入的关键或重要职能，并识别支撑它们的 ICT 系统、流程、技术和服务。TLPT 主管机构验证精确范围。被排除的职能要说明理由；纳入的系统要设定与机密性、完整性、真实性或可用性相关的初步目标，也就是“旗标”。采购方不应允许供应商把这项工作降格为边界资产盘点。真正目标是把可信攻击者的路径连接到对职能具有实际意义的结果。

同一张地图在审计前也有价值。有关以渗透测试支持审计准备的指南说明了如何连接控制措施、系统与测试证据，同时避免把审计结论错误地归功于一次技术测试。

把生产测试当作受控的运营变更

TLPT 有意在支持关键或重要职能的真实生产系统上实施。这样可以获得预发布环境无法提供的信息，但也带来真实运营风险：服务中断、系统损坏、数据被破坏或披露、误触发事件升级，以及对交易对手的影响。“请小心操作”不能算作风险控制。

控制团队应维护动态风险登记册和决策日志。测试前要约定允许与禁止的策略、社会工程边界、目标时间窗、测试账号和数据、恢复检查、证据处理、升级路径以及紧急联系人。停止条件应可测量，例如生产错误率超过阈值、发生意外数据写入、出现人身安全问题、第三方发出警报，或者实体无法可靠区分测试活动与真实事件。还要明确谁有权暂停测试，以及如何通知主管机构和提供方。

保密本身也是控制措施。只有一个小型控制团队知道测试存在并负责管理；蓝队通常事先不知情，这样才能观察其真实的预防、检测和响应行为。控制团队负责人必须有足够资历并了解系统，才能在真实性与安全之间作出决定。测试人员和控制团队之间应有带外通信渠道，主动测试开始前还要演练停止流程。

即使 TLPT 规则不适用，常规生产环境渗透测试也应根据风险采用同类纪律。书面授权、测试规则、数据处理和恢复证据，既能降低测试风险，也能让结果更适合作为可依赖的证据。

采购能力和独立性，而不是“DORA”徽章

DORA 对 TLPT 测试人员提出了明确标准：高度适任且信誉良好；具备技术和组织能力；在威胁情报、渗透测试和红队测试方面具有专门经验；获得成员国认可机构的认证，或遵守正式行为准则或伦理框架；就测试风险管理提供独立保证或审计报告；并拥有覆盖不当行为和过失风险的专业责任保险。与外部测试人员签订的合同还必须控制测试数据的创建、存储、汇总、起草、报告、传输和销毁。

这些是尽职调查事项，不是营销口号。要求供应商列出实际交付人员和角色；如果威胁情报与红队来自同一家公司，说明团队如何隔离；提供保险证明、质量控制、利益冲突检查、分包商、数据位置和安全删除方案。还要问清在凌晨三点的主动场景中，谁有权作出运营决策。应核实声明，而不是接受“DORA 认可供应商”这样的徽章。熟悉的渗透测试供应商不一定具备 TLPT 所需的治理能力和情报驱动红队能力。

内部测试人员只能在适用的批准、资源和独立性条件下使用。威胁情报提供方须独立于该金融实体及其集团内部 ICT 提供方；重要信贷机构必须使用外部测试人员；使用内部测试人员的实体每三次 TLPT 中至少有一次要使用外部测试人员。内部与外部人员混合的测试团队，就该轮换规则而言仍按内部团队处理。普通第 24 条测试也要求内部或外部测试方保持独立；使用内部人员时，实体应提供足够资源并控制利益冲突。

选择供应商前，应把匿名化报告样本与验收标准比较。渗透测试报告样本可以帮助判断一份常规技术报告是否清楚解释证据、影响与修复。TLPT 采购还需要更多交付物：定向威胁情报、攻击场景、红队与蓝队报告、重演材料、测试摘要和修复计划。

尽早把 ICT 第三方纳入设计

一项关键职能往往跨越云、SaaS、托管安全服务和集团内部服务边界。DORA 不允许金融实体简单地从范围中抹掉这些依赖。实体必须识别支持关键或重要职能的外包系统和 ICT 服务，采取措施和保障让相关第三方参与，并始终保留合规责任。

应从合同入手。检查测试权利、通知期、可接受使用限制、分包商依赖、证据共享限制、事件报告路径和数据地点约束。如果供应商无法支持生产环境测试，这应成为向主管机构明确说明的范围决策，而不是悄悄排除。开展第三方风险安全评估有助于准备这些证据，但问卷本身不能证明共享控制措施在攻击过程中如何工作。

集合式 TLPT 是一种条件严格的机制，不是把供应商排除在测试之外的通用手段。若第三方直接参与被合理预期会损害向 DORA 范围外客户提供的服务质量或安全，或损害这些服务相关数据的机密性，DORA 才允许采用集合式测试。在取得所需书面协议后，ICT 提供商可直接与外部测试方签约，由一个指定金融实体指导集合式测试，并控制参加实体数量以保持测试质量。每个金融实体仍承担自己的义务和风险管理责任。集团实体共享 ICT 系统或集团内部提供商时，还可能考虑联合 TLPT。

把 TLPT 规划成端到端项目

按照 TLPT 监管技术标准，主动红队测试阶段至少跨越十二周。这是阶段的最低持续时间，不表示持续不断的实操活动，不等于固定人周，也不意味着整个项目只需十二周。准备、范围验证、威胁情报、关闭和修复都会增加大量时间。主管机构通知实体后，启动信息应在三个月内提交。因此，采购工作应在时间变得紧迫前开始，同时遵循正式启动点和主管机构流程。

1. 启动与定范围组建控制团队，确定提供方、风险控制、职能、系统和旗标，并取得所需的主管机构验证
2. 形成威胁场景使用定向情报，为约定范围选择可信的攻击者、攻击路径和目标
3. 测试生产系统以受控方式开展跨越至少十二周的主动红队阶段，每周报告进展并记录变更
4. 重演与学习完成红队和蓝队报告，重建攻防双方的行动，再开展紫队协作
5. 修复与证明提交摘要和修复计划，跟踪负责人和日期，并保存主管机构证明以支持相互承认

该流程测试的不只是“能不能利用”。控制团队负责人结合定向威胁情报和规定的专家意见，选择至少三个场景。红队测试进入、横向或纵向移动以及达成目标；蓝队证据则说明哪些动作被发现、如何响应。“助推”可在测试人员无法继续时帮助推进路径，但必须事先约定并记录，因为它会改变结果的解释方式。

主动测试结束后，红队出具报告，蓝队把检测和证据映射到攻击动作，双方再共同重演完整过程。随后，紫队协作探索替代路径或未完成路径。这样，即使入侵没有成功，也可能暴露薄弱的遥测；成功入侵也可能说明某项控制虽然有效，但生效得太晚。最终成果是学习记录，而不是“通过/不通过”的徽章。

验收能够推动修复的证据

签约前就要定义验收标准。对于常规渗透测试，要求提供确认后的范围、日期和环境、方法和限制、可复现证据、受影响职能、业务后果、修复建议以及复测约定。发现项应能追溯到系统和关键职能地图，不能把所有信息压缩成一列严重性分数。

TLPT 的证据链更广。红队报告应区分已达到和未达到的旗标、成功和失败的攻击路径、使用的战术技术、计划偏差以及任何助推。蓝队报告要把检测和日志对应到每个攻击步骤，包括自己的成功攻击根因分析，并列出紫队主题。测试摘要再把经验证的范围、场景、行动、检测、风险控制和经验教训连接起来。

修复计划应为每项发现记录缺陷、优先行动、预计完成时间、根本原因、负责人员或职能，以及延迟修复或实施修复本身带来的风险。按照监管时间表，提交测试摘要和修复计划的八周期限，从 TLPT 主管机构通知控制团队负责人、确认红队和蓝队报告包含所需信息时开始计算，而不是从测试启动或主动阶段结束时计算。

复测让技术声明转化为闭环证据。在安全允许的情况下，应重现原始条件，检查相关相邻路径，并记录环境、日期和结果。有关渗透测试修复验证的指南解释了“已修补”和“已验证”的区别。主管机构证明可支持对正确实施的 TLPT 进行相互承认，但它不是实体整体安全状态的认证，也不是对每项控制措施的监管背书。

一个假设性的采购决策

设想一家假设的支付机构，其关键支付职能依赖客户 API、云身份平台、托管检测服务和外包交易处理商。它已与主管机构和法律团队确认适用性及指定状态，目前没有被指定实施 TLPT。年度测试计划表明，API 发生过重大改动，身份权限有所扩大，而处理商合同限制侵入性测试。

合理采购并不必然是完整 TLPT。该实体可以采购使用授权账户的 API 测试和身份攻击路径测试，审查处理商证据与合同限制，并对事件交接开展场景演练。范围备忘录记录为何这些方法适合本年度，以及计划如何覆盖全部支撑系统。如果主管机构随后指定该实体实施 TLPT，现有的职能地图和第三方准备会成为另一个由主管机构治理的项目输入；此前的渗透测试不会追溯性地变成 TLPT。

对于常规技术项目，Pentest.red 可以帮助把这个决策转化为约定明确的渗透测试服务范围，包括获准目标、访问级别、生产保护措施、证据和复测条款。范围规划器可在报价前记录这些边界。Pentest.red 不认证 DORA 合规性，也不声称普通渗透测试可以替代 TLPT。请先与主管机构和法律团队确认监管适用性及任何 TLPT 安排，再采购能够回答剩余明确技术问题的工作。