云渗透测试的合规要点是什么?

说到云渗透测试，很多人第一反应是“这不就是对着云上的网站打一打嘛”，可真要动手才发现，光合规这一关就能卡住大半人。大家熟悉的 Web 渗透测试，范围画个 IP 段、写个域名就能开工；云环境完全不是这么回事，资源是 API 创建的，身份是策略定义的，连“你到底在测什么”都要先掰扯清楚。合规不是走流程，是保护测试方自己的。

合规的头一件事，就是授权范围必须白纸黑字写明白。不是签个字就完事，要具体到测哪个账号、哪个服务、允许用什么手法，尤其要把“不碰什么”写清楚——生产数据不碰、破坏性操作不做、压测不做。这份书面确认既是合规依据，也是万一出了争议时的护身符。很多人觉得这是形式主义，真出了事才知道这份文件多值钱。

第二件事是摸清云厂商的测试规则。AWS、Azure 这些平台对渗透测试各有各的说法，有的服务随便测，有的得先提交申请等批准，而且规则还会更新。别凭去年的经验判断今年的政策，动手之前去查最新的官方说明。违反供应商政策的后果，轻则告警，重则账号受限，责任全在测试方，这个锅甩不出去。

第三件事是搞清楚共享责任模型的边界。云安全的分工是厂商管平台、用户管自己部署的东西。渗透测试的授权范围，天然落在用户责任这一侧——自己的应用、配置、身份管理随便测，但别去碰厂商的基础设施，那不是你的地盘，也不在任何供应商允许的测试范围内。

授权搞定了，测试过程本身也得合规。建议用独立的测试账号，别拿生产管理员账号直接操作；测试中产生的临时凭证、密钥要加密保存，结束之后彻底清理。还有一个容易被忽略的点：确认审计日志已经开启。云平台默认不一定开了完整日志，不提前打开，测试操作就没留下痕迹，报告里连证据都拿不出来。

最后是报告。云渗透测试的报告要能支撑合规审计，不只是列漏洞清单，还得说明测试覆盖了哪些范围、用了什么方法、结论是什么。审计员看的是测试是否系统完整、证据是否充分。另外有个常见误区得提醒大家：配置扫描工具跑一遍，输出一份风险清单，这不叫渗透测试，缺了“验证可利用性”这个关键环节。真正的云渗透至少要打通一条攻击链，证明配置问题确实能被利用，而不只是理论上存在风险。

说到底，云渗透的合规要点就三条：授权清楚、边界守好、证据留全。把这三点做到位，测试结果才站得住脚，报告才经得起审计推敲。