渗透测试检查清单

要解决什么问题

渗透测试往往不是「买一台扫描器跑一晚」就结束。范围没写清会导致测试蔓延或漏测关键资产；生产环境误操作可能触发 DoS；云厂商（AWS/Azure/GCP）对未报备的测试有政策风险；测试期间若持续部署，结论很快与现场不一致；报告格式与风险评级不统一时，修复优先级很难对齐。本技能把规划、执行与跟进拆成可勾选的检查项，减少遗漏与扯皮。

技能如何组织工作流

内容按五个阶段展开，每阶段用 [ ] 清单驱动落地：

• 范围定义：澄清测试目的与成功标准；对照外部/内部/Web/社工/红队等类型选方法；映射高风险资产与数据敏感度；明确范围内外系统、技术边界与排除项；结合资产价值与复杂度做预算现实核查。
• 环境准备：决定生产 vs 预发、测试窗口与账户权限；先做漏洞扫描并修掉明显问题；核对合规（如 GDPR、PCI-DSS）与书面授权；向托管/云服务商提交渗透测试授权；测试窗口内冻结部署并记录版本。
• 人员与交付约定：资质（如 OSCP、GPEN）、方法论（OWASP、PTES）与黑盒/灰盒/白盒访问级别；报告章节、机器可读输出（CSV/XML）与 CVSS 等评级口径。
• 监控：IDS/IPS、集中日志与 SIEM；让运维能区分「授权测试」与真实攻击；记录基线，关注 WAF、端点防护告警。
• 修复与收尾：备份与恢复验证、预留修复与复测时间；清理测试账户与后门；规划下一轮测试频率（发布节奏、合规、既往发现严重度）。

文末还提供测试前/后快速参考，以及范围蔓延、生产影响、争议发现、预算超支等故障排查对照表。

适用边界与注意点

清单是流程与治理框架，不替代具体 exploit 手法或自动化工具链；生产测试仍有固有风险，预算与时间会直接限制覆盖深度；不同测试人员方法论差异大，需用样例报告与范围文档提前对齐。发现会随补丁与架构变更过时，应把「持续测试 / 变更后复测」写进计划，而不是一次性验收心态。