云计算安全扩展要求：等保二级11项、三级46项，差在哪
同一套业务系统，从二级调整到三级，云上那部分要求项会从 11 条一下变成 46 条。多数人的第一反应是"又要多买设备"，其实真正的变化在举证：二级问的是云平台合不合规，三级问的是你在这朵云上到底做了什么。
下面按 GB/T 22239-2019 条文逐层对照，数字是逐条数出来的。
先把关系摆正：扩展要求是叠加，不是替代
云上系统要同时满足两套要求：通用要求，加云计算安全扩展要求。扩展要求不覆盖通用要求，只在云环境特有的地方补条款。所以云上三级系统的测评清单，是"通用 211 项 + 云扩展 46 项"两段拼起来的。
反过来，扩展要求也顶不了通用要求："虚拟机与虚拟机之间的异常流量检测"这类条款，通用要求里没有对应项。
二级的 11 项：只问平台合规、隔离够不够、数据在不在境内
二级的云计算扩展要求只有 7 个控制点、11 项，而且大半是对云服务商提的：
| 层面 | 控制点 | 项数 | 实质 |
|---|---|---|---|
| 安全物理环境 | 基础设施位置 | 1 | 云基础设施在境内 |
| 安全通信网络 | 网络架构 | 2 | 平台不承载更高等级系统；客户虚拟网络隔离 |
| 安全区域边界 | 访问控制 | 1 | 虚拟化网络边界要有访问控制 |
| 安全计算环境 | 访问控制 | 2 | 虚拟机迁移策略随迁；客户可设虚拟机间策略 |
| 安全计算环境 | 数据完整性和保密性 | 1 | 客户数据、个人信息存境内 |
| 安全建设管理 | 云服务商选择、供应链管理 | 4 | 选合规云商、SLA 写清责任 |
二级里没有区域边界入侵防范、安全审计、身份鉴别和集中管控。系统放在云上，租户侧要自己做的技术动作确实不多，主要是把等保通用要求框架里那套账号、权限、日志、备份做扎实。
三级的 46 项：多出来的 35 项，几乎都在"看得见、查得到"
三级扩到 16 个控制点 46 项。新增的 9 个控制点，全部能在测评现场被要求演示：
| 新增控制点 | 项数 | 查什么 |
|---|---|---|
| 区域边界·入侵防范 | 4 | 客户侧攻击、虚拟网络节点攻击、虚拟机与宿主机之间异常流量、告警 |
| 区域边界·安全审计 | 2 | 远程管理特权命令审计（至少含虚拟机删除、重启）；平台操作可被客户审计 |
| 计算环境·身份鉴别 | 1 | 远程管理设备时，管理终端与平台双向身份验证 |
| 计算环境·入侵防范 | 3 | 虚拟机间隔离失效告警、非授权新建或重启虚拟机告警、恶意代码在虚拟机间蔓延告警 |
| 计算环境·镜像和快照保护 | 3 | 加固镜像、镜像与快照完整性校验、敏感资源防非法访问 |
| 计算环境·数据备份恢复 | 4 | 本地留备份、可查备份位置、多副本一致、可迁出 |
| 计算环境·剩余信息保护 | 2 | 内存与存储回收时清除、删数据时副本一并删 |
| 安全管理中心·集中管控 | 4 | 虚拟资源统一调度、管理流量与业务流量分离、按职责分别集中审计与监测 |
| 安全运维管理·云计算环境管理 | 1 | 运维地点在境内 |
原有控制点里也各加了条款：网络架构多三条，要求平台提供通信传输、边界防护、入侵防范能力，客户能自主定义访问路径、选安全组件、配安全策略，平台还要开放接口接入第三方安全产品；区域边界访问控制多一条"不同等级网络区域边界分别部署"；云服务商选择加了保密协议与到期交还数据，供应链管理加了安全事件与变更告知。
这三条网络架构要求，说白了是防止云平台把租户锁死：安全组要能自己配，WAF、堡垒机、日志审计要能自己接，出问题能迁走。
46 项里，谁是举证方
这是云上最容易扯皮的地方，按条款指向分三类：
- 云服务商举证：基础设施位置、虚拟网络隔离、虚拟机与宿主机异常流量检测、镜像与副本一致性、虚拟机迁移时的数据完整性。
- 租户举证：子网与安全组划分、账号权限与最小授权、日志留存、业务数据本地备份、密钥与加密配置、运维操作记录。
- 双方各举一半：安全审计（平台记特权命令，租户记自己的操作）、集中管控（按职责划分各自那部分）。
错位的典型场景：被问"虚拟机之间的异常流量怎么检测"，租户拿出一摞主机杀毒软件截图。这条问的是虚拟化层的流量可见性，多数公有云由平台安全中心提供，租户要做的是开启能力并留记录。
三处最容易判错
第一处：云平台过了三级，我的系统就不用做了。 平台等级只说明底座够格，承载的业务系统仍要单独定级、单独备案、单独测评。条款原话是"云计算平台不承载高于其安全保护等级的业务应用系统"——这是上限约束，不是豁免。
第二处：把物理环境整层判不适用。 租户碰不到机房，这一层可以判不适用，但要在报告里写清继承关系：哪一层由云服务商承担、依据哪份平台测评结论。只写"不适用"三个字，复测会被打回。
第三处：把 35 项当成 35 台设备。 46 项里真正要采购的并不多，大头是配置和流程：安全组规则、子网分级、日志留存、镜像基线、变更审批。先把整改方案按"配置类优先"排，比直接上设备划算。
现场举证：备三类材料
- 平台侧：云服务商的三级测评结论或合规说明、SLA 中关于权限与责任的条款、数据存储地说明。
- 配置类：VPC 与子网划分图、安全组规则导出、账号与权限清单、日志留存配置（三级不少于六个月）。
- 流程类：变更与发布记录、特权操作审批、备份恢复演练记录、镜像制作与校验记录。
配置类最费工，也最容易在测评前一天才发现不达标。
什么时候该按三级做
定级不看是否上云，看业务受侵害的客体和侵害程度。同样是电商前台，只做展示的和带交易的，等级可能差一级。上云改变的是实现方式，改不了定级结论。
有一条硬约束：平台等级不能低于承载系统的等级。三级系统不能放在只过二级的云平台上；反过来，二级系统放在三级平台上完全合规，还能继承平台不少能力。
费用和周期上，云上三级比自建机房省的是物理环境与硬件冗余，省不掉测评、整改和运维的人力。二级到三级的整体投入通常在两倍上下，周期视整改量在三到六个月，以属地要求为准。