3. 渗透测试项目启动与范围界定
授权渗透测试与“随手扫一扫”最大的区别，在于它是一次有边界、有授权、有记录、有回退方案的工程活动。项目启动阶段如果没有把范围、目标和沟通方式钉死，后续所有技术动作都会失去合法性依据，甚至可能因为误伤生产系统而演变成事故。本节围绕四个必须落地的要素展开：资产梳理、目标确认、时间窗口和沟通机制。
一、资产梳理：先知道“有什么”，再决定“测什么”
资产梳理不是简单地把域名列出来，而是建立一份可核对的资产清单，明确每个资产的归属、类型、暴露面和重要性。实践中通常从三个来源交叉获取：客户提供的资产台账、公开信息（备案、DNS、证书透明度日志）、以及授权范围内的主动探测。三者比对后形成的差异项，往往就是最需要确认的部分。
资产清单至少应包含以下字段，便于后续逐项确认授权：
| 字段 | 说明 | 示例 |
|---|---|---|
| 资产标识 | 域名、IP 段或应用名称 | app.example.com |
| 类型 | Web、API、移动端、主机、网络设备 | Web 应用 |
| 归属 | 责任部门或系统负责人 | 电商事业部 |
| 环境 | 生产、预发、测试 | 生产 |
| 重要性 | 核心、重要、一般 | 核心 |
| 授权状态 | 已授权、待确认、排除 | 已授权 |
需要特别注意的是“边界资产”。例如客户只授权了 app.example.com，但该域名解析到云厂商共享 IP，同一 IP 上还托管着其他租户的业务。此时若直接对该 IP 做端口扫描或漏洞探测，就可能越界。正确做法是把测试目标锁定在域名和指定路径上，并在授权书中写明“不针对共享基础设施进行扫描”。
二、目标确认：把“测什么”写成可验收的句子
目标确认的核心是把模糊需求转成可执行、可验收的测试目标。常见的目标类型包括：验证某类漏洞是否存在、评估某系统在真实攻击下的防护能力、满足合规检查要求、以及为修复提供优先级依据。不同目标决定了测试深度和手法差异。
例如，客户说“帮我们看看系统安不安全”，这无法直接执行。经过确认后可以写成：“在授权范围内，对 app.example.com 的登录、订单查询、支付回调三个接口进行黑盒测试，重点验证越权访问、SQL 注入和敏感信息泄露，测试深度为手工验证，不进行拒绝服务类测试。”这样的目标才具备可执行性和可验收性。
目标确认还应明确“不做什么”。以下内容通常需要单独确认是否纳入范围：
- 社会工程学与钓鱼测试；
- 物理入侵与办公网接入；
- 拒绝服务与压力测试；
- 对第三方托管系统、云平台管理后台的测试；
- 数据导出、删除或篡改类验证。
三、时间窗口：把测试安排进业务节奏
时间窗口解决的是“什么时候能测、测多久、出问题找谁”。它需要与业务方共同确定，而不是测试方单方面决定。关键参数包括：测试起止日期、每日可测试时段、业务高峰禁测时段、变更冻结期、以及应急回退联系人。
以电商系统为例，大促期间通常禁止任何可能影响稳定性的测试；财务系统在月末结账期间也应避开。对于必须在线验证的高风险操作，建议安排在业务低峰期，并提前准备好回退方案。时间窗口还应当预留“发现高危问题后的暂停与上报”机制，而不是等到测试结束才汇总。
四、沟通机制：让信息在正确的人之间流动
沟通机制包括三个层面：日常沟通、异常上报和变更通知。日常沟通确定双方接口人、沟通渠道和日报/周报节奏；异常上报规定发现高危漏洞或误伤业务时的第一时间联系人和响应时限；变更通知则用于应对测试期间目标系统发生上线、扩容或配置调整的情况。
一个可用的沟通矩阵如下：
| 场景 | 发起方 | 接收方 | 时限 |
|---|---|---|---|
| 每日测试进展 | 测试负责人 | 客户接口人 | 当日结束前 |
| 发现高危漏洞 | 测试工程师 | 客户接口人+安全负责人 | 30 分钟内 |
| 疑似影响业务 | 测试工程师 | 客户接口人 | 立即暂停并上报 |
| 目标系统变更 | 客户接口人 | 测试负责人 | 变更前通知 |
下面这张图把项目启动阶段四个要素之间的关系和流转过程集中呈现出来，便于在启动会上逐项核对。
五、启动会与授权确认
四个要素梳理完成后，应通过一次启动会完成最终确认。启动会的产出不是会议纪要，而是一份可执行的授权范围说明书，至少包含：授权测试的资产清单、测试目标与深度、时间窗口、禁止事项、沟通矩阵、以及双方签字确认。只有这份文件生效后，才应进入信息收集与漏洞探测阶段。
在实际项目中，范围界定往往不是一次完成的，而是随着资产梳理的深入不断收敛。例如最初客户提供了 30 个域名，经过确认后只有 12 个在授权范围内，其中 3 个属于第三方托管需要单独协调。这个过程本身就是项目启动阶段最有价值的产出，它把“不确定”变成了“可执行”。