攻击者究竟能走多远？

从互联网发起的测试，与使用常规内部账户进行的检测，回答的是不同的问题。我们会共同确定要考察的场景，以及一开始所具备的权限。允许的测试范围，由这一初始状况推导得出。系统、地址和身份会被记录在案；共用的服务和第三方系统则需要格外关注。这样一来，规划就能防止检测因职责不清而无意中超出已获得的审批范围。

运行条件同样是准备工作的一部分：联系人、时间窗口和中止标准都会事先确定。对系统的更改、负载测试或其他更深入的措施，并不会默认包含在每一次渗透测试之中，而必须明确符合约定的流程。随后，测试结果会说明实际的起始位置和检测的版本，这有助于对结果作出准确解读：在已具备管理员权限的前提下观察到的漏洞，与从无特权起点获得的验证，二者的结论意义并不相同。

仅靠网络分段，并不能描述所有可能的访问方式。用户账户、服务账户和管理路径，都可能在系统之间建立起其他连接。因此，在获准的范围内，检测会考察技术边界和角色权限是否真正落实了预定的模型。个别配置错误会结合其实际影响来评估。一项检测发现，应当说明它为何与您的环境相关，以及所验证的访问需要满足哪些前提条件。

在 IaaS 环境中，还需要考虑与服务商之间的边界划分。由客户负责的资源和配置可以成为检测对象，但这并不会自动将共用的平台服务一并纳入授权范围。检测开始前，需要先明确必要的权限和相关要求。与之相连的站点和应用程序也可能受到影响。因此，规划工作会让云和基础设施的负责人共同参与，以确保测试全程可追溯，并使其影响能够被控制在约定的范围之内。

结果会将已确认的检测发现、提示信息和未检测的领域区分开来。验证材料描述了所需的前提条件和观察到的影响，目的是支持评估工作，同时避免收集不必要的敏感数据。管理层和技术团队会分别获得与之相适应的呈现方式；特别重要的观察结果，会通过约定的报告路径进行传达。这样，一次渗透测试就不再只是导出一份技术问题清单，而是让负责人能够决定应优先落实哪些措施。

在修复过程中，可能会有多个团队参与，例如身份管理、网络运维和应用运维团队。因此，相关建议会连同其依赖关系一并讨论。复测聚焦于约定的变更版本，并记录具体的验证是否仍然可以复现。对于合适且边界清晰的目标，可以通过 Result as a Service 商定按成果付费的报酬模式。在此过程中，允许的测试范围始终具有约束力，不会因经济激励而被扩大。