拿下一台服务器的渗透控制权，往往不是测试因为对方用了多高深的漏洞，而是范围因为他们忘了给测试环境加访问限制。去年某银行的渗透外包系统，开发人员把后台管理页面挂在公网，测试密码是范围admin/admin。我花五分钟进去，渗透数据库明文存着几百万客户资料。测试这不是范围电影桥段，是渗透渗透测试最常见的开场。

渗透测试的测试服务范围，说白了就三层：网络层、范围应用层、渗透人为因素。测试网络层看防火墙规则、范围端口暴露、内网横向移动的可能性；应用层查SQL注入、越权访问、上传漏洞这些老毛病；人为因素最麻烦，得看员工会不会把密码贴在显示器上，或者点开钓鱼邮件里的附件。

具体到一次完整的测试，从信息收集开始。域名、子域名、IP段、邮箱格式，甚至招聘广告里泄露的技术栈都是线索。有人觉得扫端口就够了，但真正有效的测试会翻公司财报，看他们最近并购了哪家小公司——那往往是最薄弱的入口。等摸清资产边界，才轮到漏洞扫描和手工验证。

这里有个常被误解的点：不是所有漏洞都要利用到底。比如发现一个RCE（远程代码执行），服务商会先尝试弹个计算器证明危害，而不是直接拖库。为什么？因为测试合同里通常写明“禁止造成业务中断”。前阵子某电商平台测试，测试人员没控制好扫描频率，把生产环境的支付网关打崩了，赔了三天流量。所以服务范围必须白纸黑字写清楚：允许测到哪一步，哪些操作需要提前报备。

再说内网测试。很多人以为外网打不进去就完事大吉，忽略最危险的场景——假设攻击者已经拿到一台普通员工电脑。从内网到域控的距离，往往比从外网到内网更短。我见过一家制造企业，车间工控机装了个老版本向日葵远程控制，弱口令直接连上内网。渗透测试服务里如果包含内网横向移动，那才算真正模拟了勒索软件的传播路径。

云环境是另一块灰色地带。容器逃逸、OSS桶权限配置错误、K8s的API Server暴露，这些和传统机房完全不同。有次测试发现客户把云数据库的公网地址写在了GitHub上的配置文件里，而且没开白名单。这种问题用传统扫描器根本发现不了，得靠人工审查代码仓库和云控制台配置。

最后说说报告。服务范围里最容易忽略的是“交付物边界”。一份好的渗透测试报告，应该精确到每个漏洞的复现步骤、影响范围、修复建议，甚至要画出攻击路径图。如果只给个“高风险3个、中风险7个”的汇总表，那这钱花得冤。真正的行家会要求报告里附上日志时间线，证明每一步操作都有据可查——这既保护客户，也保护测试方自己。

说到底，渗透测试不是拿工具跑一遍就完事。范围定得越细，越能逼着双方把安全假设都摆到台面上。那些说“你们看着测吧”的客户，往往最后会收到一堆无法落地的漏洞列表，然后互相扯皮。规矩立在前面，后面才省心。