前几天一个做外包的老哥半夜给我发消息："客户合同里写了'验收前提是通过等保二级测评'，这是个啥？要钱吗？会不会把我房子搭进去？"
我盯着屏幕想了想，发现这个问题还真不是三句话能说清的。于是就有了这篇——不整虚的，用开发者的视角把"等保 2.0"这四个字拆开揉碎了讲一遍。看完你至少能分清楚：哪些是吓唬人的，哪些是真能让你项目黄掉的。
先纠一个最常见的误解：等保 2.0 ≠ 二级
很多人第一眼看到"等保 2.0"，会以为系统是"第二级"。错得离谱。
"2.0"是标准版本号。现行标准叫《信息安全技术 网络安全等级保护基本要求》，编号 GB/T 22239-2019，2019 年 12 月 1 日正式实施，取代了老版本，所以大家口头叫它"等保 2.0"。而"二级""三级"说的是你系统被定的安全等级，一共五级，绝大多数公司挂心的是二级和三级。
一句话总结：等保 2.0 是考纲版本，二级三级是你的考场座位。两码事。
顺便说下法律依据：《网络安全法》第二十一条白纸黑字要求"国家实行网络安全等级保护制度"。所以这不是某些售前顾问发明的收费项目，是法定义务，跑不掉。
系统怎么定级？先搞清楚你坐哪个位置
五个等级怎么分？核心看一条：系统被破坏之后，伤害到谁、伤害多深。
- 一级：伤的是你自己和用户的合法权益，基本没人定这个级，定了一级反而显得心虚；
- 二级：对社会秩序和公共利益有危害——市面上大部分面向公众提供服务的系统（带用户注册、存个人信息的）常见的落点就是这里；
- 三级：对社会秩序、公共利益造成严重危害，甚至危害国家安全——金融、政务、教育、医疗这些行业里跑核心业务的系统，甲方一般会直接在合同里要求"过等保三级"；
- 四级五级：那是银行核心系统和国家关键基础设施的领域，普通开发者这辈子大概率用不上，知道就行。
定级也不是自己拍脑袋写个表交上去就完事。等保 2.0 有个新要求：二级及以上系统要经过专家评审和主管部门审核，然后才到公安机关备案。流程上就是老生常谈的五步：定级 → 备案 → 建设整改 → 等级测评 → 监督检查。
再说测评频率，这也是合同纠纷高发区：二级系统一般每两年做一次测评，三级系统每年一次。甲方合同里要是写"通过等保三级"，那意味着人家每年都得掏测评的钱，这笔账签合同前就得算明白。
云上最容易踩的坑：平台过了等保，不等于你过了
这是我今天最想敲黑板的部分。
很多开发者会说："我用阿里云，阿里云自己都通过等保测评了，我是不是躺着就合规了？"
想得美。等保 2.0 国标附录 D 专门讲了云上场景的责任分担：云平台和云租户（也就是你）按照 IaaS / PaaS / SaaS 的模式各自承担一块安全责任，原则是"谁运营谁负责、谁使用谁负责"。
用人话翻译一下：
- 阿里云负责的是机房、物理设备、虚拟化层、平台自身那一摊——这部分人家确实做过测评，备案资质齐全；
- 而你云主机上的操作系统加固、应用安全、访问控制、数据保护、日志审计，全是你的事。你的 ECS 裸奔着弱口令 root 直接登录，出了事跟云平台半毛钱关系没有。
这就好比租房：房东把小区门禁、楼道监控装好了，但你屋里锁不锁门、快递单上的名字撕不撕，是你自己的责任。测评机构上门的时候，查的是"你这套系统整体"，平台合规报告只能覆盖你责任范围那一部分，剩下的坑得你自己填。
开发者落地自查清单：测评机构最爱抠的几个点
既然责任在自己身上，那就聊聊整改阶段开发者实际要干什么。我按测评里扣分最狠的几项给你列个清单，都是动手就能改的：
1. 日志留存至少 6 个月。 这是《网络安全法》的硬要求，也是测评里出镜率最高的扣分项。好多团队的登录日志、操作日志存两周就滚动覆盖了，测评老师一问"三个月前谁改过这条数据"，全场安静。云上可以用日志服务把日志集中收起来，留存周期直接配到 180 天以上，省心。
2. 身份鉴别和访问控制。 弱口令、root 直接远程登录、所有人共用一个管理员账号，这三样凑齐了基本是"送分变送命"。改起来不难：密码策略上强度、SSH 换密钥登录、按岗位拆账号分权限，最小权限原则老生常谈但真有用。
3. 安全审计。 不光要有日志，还得有人看、有告警。测评的时候会问"出现异常操作你怎么发现的"，答"等用户投诉才发现的"，那画面我不忍描述。
4. 边界防护。 安全组规则里 0.0.0.0/0 全放通这种操作，自查阶段就把它掐了。该内网的内网，该白名单的白名单。
5. 集中管控。 三级系统要求有统一的安全管理中心——服务器多了以后，一台台登上去查状态是不现实的，这也是为什么整改清单里经常出现堡垒机和态势感知类产品的影子。堡垒机把运维入口收拢到一处，操作全程录像审计，等保三级场景里几乎是标配，感兴趣的可以看看阿里云的堡垒机，先把产品文档过一遍再决定买不买，别上来就掏钱。
先自查再花钱：等保合规检查项可以自己先跑一遍
等保这事儿最贵的从来不是安全产品，是测评费和整改返工。所以我的建议一直是：测评之前，先把技术项自查跑一遍。
以阿里云为例，云安全中心的基线检查里带等保合规检查项（注意要用标准策略，默认策略不含这个），能对着等保的指标体系把你服务器的弱口令、配置缺陷、审计缺失这些项扫出来，哪些不满足直接给你列成清单，一部分还支持一键修复。相当于测评前先来一次模拟考，哪里不会补哪里。版本怎么选、多少钱，各档功能差异不小，直接看官方页面实时展示的为准，我就不复制粘贴价格了——毕竟这种东西今天抄下来明天就可能过时，被打脸的又是我。
写在最后
等保 2.0 说白了就是一件事：国家给所有信息系统划了条及格线，你的系统几斤几两，定个级，按级别补齐该有的防护，定期找机构来验一次。
它不是洪水猛兽，但对开发者来说，最大的风险是把"平台合规"当成"我合规"。责任共担矩阵里属于你的那半边，跑不掉，也躲不开。与其测评前一周抱佛脚，不如现在就把日志留存和访问控制这两件最基础的先落了——这两项做好了，你的系统安全性就已经超过了很大一批同行，这话我说的，测评老师会替我作证的。
