2. 授权流程与法律文书实战

渗透测试的合法性不来自技术能力,而来自“可被证明的授权”。在真实项目中,一次测试是否合规,往往取决于四份文件是否形成闭环:授权书(Authorization Letter)界定“谁授权、授什么权、授到哪一天”;SOW(Statement of Work,工作说明书)界定“做什么、交付什么、按什么标准验收”;NDA(保密协议)约束双方对测试中获知的信息如何保密;ROE(Rules of Engagement,交战规则)规定“怎么打、何时打、打到什么程度、出事找谁”。四者缺一,都会在争议或事故中留下无法解释的空白。

一、四份文书的分工与依赖关系

很多团队把四份文件当成“签字流程”,实际上它们承担不同法律与技术职能。授权书解决权利来源问题,是证明“非未授权访问”的第一证据;SOW 解决范围与商务问题,明确资产清单、时间窗口、人天与交付物;NDA 解决信息流向问题,约束漏洞细节、拓扑、账号口令的披露边界;ROE 解决操作边界问题,规定允许的技术手段、禁止动作、紧急停止条件与联络链。四者的关系是:授权书提供合法性基础,SOW 划定业务范围,NDA 保护过程信息,ROE 约束具体动作。ROE 中任何超出 SOW 范围的测试目标,都必须回到 SOW 或授权书补充确认,否则即为越权。

四份文书的分工与依赖闭环 授权书 权利来源 · 合法性基础 授权主体 / 资产范围 有效期限 / 签字盖章 SOW 工作说明书 范围 · 交付 · 验收 资产清单 / 时间窗口 人天 / 报告 / 复测 NDA 保密协议 信息流向 · 披露边界 漏洞细节 / 拓扑数据 账号口令 / 留存销毁 ROE 交战规则 操作边界 · 动作约束 允许/禁止手段 紧急停止 / 联络链 测试时段 / 速率限制 授权范围 信息保护 范围约束 越界需补充授权 闭环原则 授权书提供合法性 → SOW 划定范围 → NDA 保护信息 → ROE 约束动作 → 越界回到授权书补充确认

二、授权书:写清“谁、授什么、到何时”

授权书的核心不是格式,而是可验证的授权要素。一份可用的授权书至少包含:授权方全称与统一社会信用代码、被授权方全称、授权测试的资产范围(域名、IP 段、系统名称、办公地点)、授权起止日期、授权事项(是否允许漏洞利用、是否允许社会工程、是否允许物理接入)、签字人姓名与职务、签字日期与公章。实践中常见的问题是授权范围写成“公司所有系统”,这种表述在争议时无法界定边界。更稳妥的写法是附一份资产清单作为附件,并在正文中写明“以附件一清单为准”。

授权书的签署人必须是资产所有者或有权处置该资产的管理者。如果目标系统由第三方托管,还需要托管方出具同意测试的书面确认,否则测试行为可能同时侵犯托管方权益。授权书应约定授权期限,并在到期后自动失效;若测试延期,必须重新签署或出具补充授权。授权书还应写明“测试过程中产生的数据仅用于本次测试目的”,为后续 NDA 和数据处理提供依据。

三、SOW:把范围、交付与验收写成可执行条款

SOW 是项目管理的基准文件。它需要明确:测试目标与资产清单、测试类型(黑盒/灰盒/白盒)、测试方法(外部渗透、内网渗透、Web 应用、API、无线、社会工程等)、时间窗口(起止日期、每日可测试时段)、人天投入、交付物(测试报告、漏洞清单、修复建议、复测报告)、验收标准(漏洞等级定义、复测通过条件)、双方联系人。SOW 中应避免“全面测试”这类模糊表述,而应写成“对附件一列出的 12 个域名、3 个 IP 段、2 个移动应用进行外部渗透测试”。

时间窗口的约定尤其重要。例如约定“测试仅可在工作日 22:00 至次日 06:00 进行”,是为了避开业务高峰;若测试需要白天进行,则应在 SOW 中单独说明并取得书面同意。SOW 还应约定变更控制:任何新增测试目标、延长测试时间、扩大测试手段,都必须通过书面变更单确认,不能由测试人员在现场口头决定。

四、NDA:约束信息流向与留存销毁

NDA 的重点是“测试过程中获知的信息如何被保护”。它应覆盖:保密信息范围(漏洞详情、网络拓扑、账号口令、业务数据、源代码片段)、保密义务主体(双方及其员工、分包方)、使用限制(仅用于本次测试)、披露限制(未经书面同意不得向第三方披露)、留存与销毁(测试结束后多少天内销毁或归还数据)、违约责任。对于渗透测试而言,NDA 还应特别约定:测试人员不得将漏洞细节用于演示、培训或公开演讲,除非获得书面许可并完成脱敏。

五、ROE:把“怎么打”写成可执行规则

ROE 是四份文件中最贴近技术操作的一份。它应明确:允许的测试手段(如是否允许 SQL 注入、口令爆破、钓鱼邮件、物理尾随)、禁止的动作(如禁止 DoS、禁止删除数据、禁止修改业务配置、禁止横向移动到非授权网段)、速率与并发限制(如口令爆破不超过 5 次/分钟)、紧急停止条件(如发现生产系统异常、发现真实攻击痕迹、触发客户告警)、联络链(测试负责人、客户应急联系人、备用联系人及电话)、证据留存要求(截图、时间戳、请求响应记录)。

ROE 中应约定“发现真实攻击痕迹时的处理流程”:测试人员若在目标系统中发现非本方留下的后门、异常账号或可疑流量,应立即停止测试并通知客户,而不是继续深入。这一条在实战中经常被忽略,但它决定了测试团队是“协助发现风险”还是“破坏现场”。

六、签署流程与版本管理

四份文件的签署顺序建议为:先签 NDA,再签授权书与 SOW,最后确认 ROE。原因是 NDA 是信息交换的前提,授权书和 SOW 需要基于 NDA 保护下的信息来细化范围,ROE 则依赖 SOW 确定的目标清单。签署方式可采用纸质盖章或可靠电子签名;无论哪种方式,都应保留签署版本、签署日期与签署人信息。项目执行期间,任何变更都应形成书面补充文件,并与原文件一并归档。测试结束后,应按 NDA 约定销毁或归还数据,并保留销毁记录。

实操建议:在项目启动会上,由测试负责人逐条宣读 ROE 中的禁止动作与紧急停止条件,并让客户方项目负责人确认。这一步看似繁琐,但能在现场避免大量“以为可以、其实不行”的争议。

七、可直接参考的 ROE 关键字段示例

字段 示例内容 作用
测试目标 附件一:12 个域名、3 个 C 段、2 个移动应用 界定范围,防止越界
允许手段 Web 漏洞验证、弱口令探测、API 越权测试 明确可执行动作
禁止动作 DoS、删除数据、修改业务配置、横向到非授权网段 避免生产事故
速率限制 口令爆破 ≤ 5 次/分钟,扫描并发 ≤ 10 降低业务影响
测试时段 工作日 22:00–06:00,周末全天 避开业务高峰
紧急停止 发现生产异常、真实攻击痕迹、客户告警 控制风险升级
联络链 测试负责人 138****、客户应急 139****、备用 137**** 保证及时沟通
证据留存 请求响应截图、时间戳、工具日志 支撑报告与争议处理

四份文书不是形式主义,而是把“信任”转化为“可验证的约定”。授权书证明你有权测试,SOW 证明你测了什么,NDA 证明你如何保护信息,ROE 证明你如何控制动作。四者一致、版本清晰、签署完整,渗透测试才能在合法、可控、可交付的轨道上运行。