企业选择云服务时，经常拿到包含加密、防攻击和安全认证的介绍材料，但业务上线后，仍可能遇到数据被意外公开、操作记录无法追溯的问题。核对云计算服务安全能力要求，要把这些承诺落到所购买的服务、实际配置和双方负责的事项上。

采购材料中的承诺覆盖哪些服务

同一家服务商提供的云主机与托管数据库，管理责任可能不同。使用云主机时，操作系统补丁往往由客户处理；托管数据库的部分维护工作则由服务商承担，具体范围以产品说明和合同为准。采购文件若只写“提供安全防护”，出现漏洞后仍可能找不到负责修复的一方。

将责任写到具体对象上：底层平台的隔离与维护由谁负责，业务账号和数据访问权限由谁管理。对于服务商管理的组件，核对漏洞修复安排和通知渠道；对于企业自行安装的软件，落实内部维护人员。责任未覆盖的部分，会在上线后留下空档。

安全认证材料有参考作用，但要核对其覆盖的产品、地域及有效范围。平台通过某项认证，不能证明企业新建的存储空间已经关闭公共访问。传输加密、存储加密也各有作用，数据加密后，获得合法读取权限的账号仍可能访问内容。

上线检查发现存储空间可被公开访问

假设一家企业准备把内部报表放入对象存储，上线检查时发现，未登录的浏览器也能打开某个文件链接。服务商介绍中列有访问控制功能，企业管理员也给员工分配了账号，但存储空间仍保留着公共读取策略。

此时先限制公共访问，再检查存储空间策略与文件权限之间的关系。仅修改员工账号权限，可能无法关闭匿名读取入口。修改完成后，用未登录状态重新访问原链接，并确认内部业务仍能按授权读取，避免只看到控制台显示“已关闭”就结束处理。

企业随后向服务商询问此前的读取记录。如果该服务的访问日志需要客户主动开启，而上线前没有启用，就可能缺少判断实际访问情况的证据。文件能够公开打开，只能确认存在暴露路径；缺少完整记录时，无法据此认定数据已经被第三方下载，也无法确认从未被访问。

在这一假设场景中，企业保留了发现问题时的配置记录，补开访问日志，并把检查公共访问策略纳入后续上线验收。日志保存会占用存储资源，保存期限和费用尚待双方确认；此前缺失的访问记录，也不会因现在开启日志而自动补齐。

验收时把功能名称变成测试结果

访问控制验收可以从普通业务账号入手：用它尝试读取未授权资源，记录操作结果；再核对权限变更后，原有访问凭据何时失效。权限名称、控制台截图只能证明配置存在，实际请求结果才能验证限制是否生效。

审计能力则要核对一条关键操作能否留下可查询记录，以及记录能否导出到企业自己的保存位置。合同中写清日志覆盖范围和保存安排，避免事故发生后才发现所需记录未被采集。

备份与恢复保留一项独立测试。平台有备份功能，不代表业务能在可接受的时间内恢复。用测试数据执行恢复，记录实际耗时和恢复内容，再与业务可承受的中断时间核对。

最终采购或验收文件中，补齐所选服务的责任划分、权限测试结果及日志交付安排。尚未完成的恢复测试单独列明负责人和测试条件，不把未验证的能力写成已经通过的结论。