云平台过了评估，系统验收还缺什么？

原创

信息安全动态

2026年10月9日 19:19
山东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

平台证明要落到具体控制项；用四列证据表分清可复用材料与租户补验责任。

假设你正在审一份云上系统验收材料：附件有平台评估证明，验收意见写着“云平台已经过评，业务系统可以直接通过”。材料看着齐了，但数据库权限和对象存储日志，究竟由谁验过？

平台证明可以支持范围内的平台控制判断，租户系统的结论还要接上实际服务与配置证据。 验收该省的是重复取证，留下的是那些只有进入你的租户环境才能回答的问题。

01

证明先对上服务，才谈得上复用

先把“这家公司通过了评估”改成一个能核对的对象：哪个云平台、哪些服务、什么适用范围。品牌名称一样，购买的区域、产品或部署形态却可能不同。公司名称对上，只完成了供应商身份核对。

把这个假设项目具体化：采购清单有2台云主机、1个托管数据库实例和1个对象存储桶。先逐项填入区域、产品名、资源标识，再对应证明的适用附件。数据库若在另一处区域，单独标“范围待核实”，别跟着云主机一起勾选。

例如，给供应商的追问可以落到这个实例：“请指出材料中哪一项覆盖该区域的托管数据库，并提供可核验的范围依据。”公司名称相同、销售确认买得到，都解决不了这个问题。

再核对有效状态和适用场景。保留查询时间、证明版本及状态依据；涉及期限的，按该项评估的具体规则核查。续约时尤其要看新增服务、区域迁移和服务形态变化，上一期的对应关系需要重新确认。

这种核对决定了材料能支持多大的结论。若证明涵盖所用基础设施的物理环境控制，就把它放进相应控制项的证据栏；业务接口的越权测试，则另找应用侧记录。

别把“合格”留成空词。验收单应写明对应的要求：合同安全条款、适用测评要求，还是企业上线基线。不同要求可能复用同一份材料，验收结论仍要分别作出。范围待确认的，先标待补证，避免误填“符合”。

02

买的是托管服务，留下的是配置责任

责任跟着实际购买的服务走。同一项目里，云主机和托管数据库会留下不同的工作。云主机的来宾操作系统、补丁和应用通常由租户管理；换成托管数据库，部分底层运维交给平台，数据库账号、网络入口和数据使用权限仍要逐项分清。

沿用这个项目，核实平台材料范围与状态后再查配置。例如，应用只需查询订单，就让1个测试账号绑定应用同款角色，在1张无敏感数据的测试表上验证：查询应成功，插入应因权限不足被拒绝。保存角色绑定、授权策略和两次返回结果。

采购合同写“托管”，还要继续看服务责任说明。供应商维护数据库底层，与租户给应用账号授予管理员权限，是两件不同的事。若把两者合成一项“数据库安全由云厂商负责”，权限检查就在交接处漏掉了。

验收分工要写到控制项，验证记录要落到当前资源。 身份看角色授权，网络看实际入口，数据保护看加密与密钥权限，日志看采集对象和可查询记录。截图要带资源标识。只截一个“已开启”，后续很难证明验的是生产实例还是测试实例。

验证优先用配置导出和只读检查。需要访问测试时，先批准资源范围与测试身份，再用无敏感内容的样本，分别检查允许和拒绝的动作。出现越界访问或异常负载就停止，按预案恢复；测试账号和临时授权用完后清理并复核。

▲ 托管交出部分底层运维，账号与入口仍需逐项分清责任。

03

验收结论要落到一次实际验证

日志最能暴露“平台能力”与“租户事实”的距离。有审计功能，还要有目标事件。你要验的是目标操作有没有被记录、记录能否查询，以及验收要求的保存和导出是否落实。

AWS CloudTrail的跟踪和事件数据存储默认不记录数据事件，这类记录还会额外收费。S3对象读取GetObject属于数据事件，验收时要核对事件选择器是否覆盖目标对象和读取动作。控制台有操作记录，查文件被谁读取时却可能没有证据。

例如，在已审批的测试中，用1个测试账号读取1个测试对象，记下请求时间与请求标识。在日志入口按目标资源和GetObject筛选，核对主体、时间、动作与结果，再导出这条记录。截到其他桶的读取记录，这项仍待补证。

如果找不到记录，沿着采集选择、资源范围、投递状态和查询时间窗口排查。若验收要求包含业务用户身份，还要关联应用日志；云侧只记录服务账号时，追溯到具体人员需要另一段证据。加开采集涉及费用和存储量，也要落实预算与保留策略。

▲ 验收要查到目标对象读取的记录，而不只确认审计功能存在（AI编辑示意）。

下表用于云主机及租户可配置的托管数据服务验收。第一列为待核对的平台覆盖项，以实际证明范围为准；能力材料用于核对功能，租户配置另验。软件即服务等形态按可控配置调整。

“证据归属”说的是谁提供和保存材料，签认责任还需另定。涉及供应商内部、租户无权操作的控制，由供应商给适用证据或安排受控验证，别为了取证扩大租户权限。材料缺失和验证失败也应分开记录，整改路径不同。

04

剩余缺口写进签认，别藏在附件里

验收意见要把缺口写成可复验的任务。仍以这个项目为例：1个存储桶未采集读取事件，团队拟定3个工作日内整改。记录中写明由云运维负责人开启目标事件采集，安全人员以同一测试对象复验，查询与导出成功后关闭该缺口。

这3个工作日是项目拟定期限，是否允许等待由验收条件决定。若日志属于上线硬条件，先整改再验收；若属于允许例外的内部要求，才提交风险接受审批，写明期间限制措施与到期复核人。

采购人员可以核对交付材料，云架构师确认服务和配置，安全人员核验测试覆盖；允许例外的内部要求，再由有授权的风险责任人决定是否接受残余风险。强制要求或合同硬性验收条件，按对应程序整改和复验。

平台控制先核对证明适用性，租户可配置控制再追到当前配置和验证记录。 自己判断时，抽一条要求，先看控制由谁实施。平台负责的查适用材料，租户负责的查配置与验证记录；对应关系完整的，就让同事复用。

你们验收时，日志缺口更多出在采集还是导出？

推荐阅读

▸ 软件包有来源证明，为什么供应链仍可能被投毒？

▸ 数据泄露事件频发，企业数据保护面临哪些挑战？

▸ 30款App被通报，小程序整改怎样才算闭环？

▸ AI Agent接入业务系统前，身份与权限要管住哪6件事

▸ EDR没有告警，边界设备失陷为什么仍可能被漏掉？

— END —

信息安全动态

面向安全管理者与技术团队，解析安全运营、AI安全与系统风险，分享评估方法和治理实践。