去年帮一家制造企业做等保 2.0，最耗时间的不是技术整改，是前面那两张纸：定级备案的定级结论写错，后面整套测评都白做；差距分析只打勾不算成本，整改预算报到老板桌上就被打回。这篇文章把定级、备案、差距分析、整改排期四段拆开，每一段给可套用的表、可判定的规则、可直接跑的脚本。
先说一个反直觉的结论：等保 2.0 项目里真正会返工的，八成集中在定级和备案阶段，不在技术整改阶段。技术整改再难，它是"花钱能解决"的问题；定级错了，是"钱花了还得重来"的问题。
一、先搞清顺序：定级、备案、整改、测评、监督，顺序错了全白干
《网络安全等级保护条例》的法定流程是五步，但实际项目里的依赖关系比条文更紧：
- 定级——确定定级对象和等级，输出《定级报告》
- 备案——到属地公安机关网安部门备案，拿到备案证明
- 建设整改——按对应等级的基本要求做差距分析并整改
- 等级测评——委托测评机构测评，出具测评报告
- 监督检查——公安机关定期检查，运营单位自检
关键的耦合点是：定级结论决定适用哪一套基本要求（第二级还是第三级，差 60 多项控制点），差距分析的输入必须是定级结论加系统现状，测评的判定标准又是差距分析的那套控制项。所以定级一旦改，后面三份文档全部重做。
现实里最常见的翻车方式是：系统先上了线，安全部门事后补材料，定级报告按"感觉"写了个二级，等测评机构进场发现这套系统承载的是生产调度数据、一旦中断影响整个厂区，被要求重新定级为三级。结果差距分析要按三级重做，扩展要求（云计算、移动互联、物联网、工业控制、大数据）也得补，项目延期两个月。
顺序上的第一条建议：定级前先做一次定级对象梳理，把所有系统列全，别漏。
很多人只给"核心业务系统"定级，漏掉了 OA、邮件、堡垒机、日志平台、虚拟化管理平台、备份系统。这些系统单独看是二级，但它们能横向触达三级系统——测评机构会问一句"这套系统的管理员账号能不能登录生产域"，回答"能"，那它就得按三级的口径管。
二、定级：三个要素定死等级，别拍脑袋写二级
定级的依据是 GB/T 22240《网络安全等级保护定级指南》，逻辑是"受侵害的客体×对客体的侵害程度"两个维度交叉。落到具体系统，要分别判定两个属性：
- 业务信息安全（S）——数据被破坏后，对客体的侵害程度
- 系统服务安全（A）——服务中断后，对客体的侵害程度
两个属性各定一个等级，取高者作为系统等级。这是最容易被简化掉的一步——很多人直接写"该系统的安全保护等级为第二级"，不写 S/A 分别怎么判的，备案时被退回。
| 受侵害客体 | 一般损害 | 严重损害 | 特别严重损害 |
|---|---|---|---|
| 公民、法人和其他组织的合法权益 | 第一级 | 第二级 | 第二级 |
| 社会秩序、公共利益 | 第二级 | 第三级 | 第四级 |
| 国家安全 | 第三级 | 第四级 | 第五级 |
判定"侵害程度"没有绝对量化标准，但有三个可操作的抓手，写定级报告时把这三个写上，说服力会强很多：
- 影响范围——影响单个部门、单个厂区、整个集团，还是跨行业。范围越大往严重判。
- 持续时间——中断 2 小时能恢复，还是 24 小时以上无法恢复。
- 可替代性——有没有手工兜底流程。纯线上业务、无纸质备份的，往严重判。
拿一个典型场景举例：某制造企业的 MES 系统，承载生产工单和工艺参数。数据泄露，影响的是企业自身商业利益，属于"公民、法人合法权益的严重损害"，S 定为二级；服务中断，整条产线停摆、影响上下游交付，属于"社会秩序和公共利益的严重损害"，A 定为三级。取高者，系统定为第三级。
这个结论和"老板觉得就是个内部系统"的直觉是相反的，但它是可辩护的——因为产线停机影响交付这件事，能拿出实际案例和订单损失数据。
定级报告里建议固定写清五件事：定级对象边界（含哪些子系统、哪些不包含）、S/A 分别判定的理由、判定依据的具体条款、定级结论、以及业务主管部门意见。第五项经常被忽略，但备案时是必查项。
三、二级和三级到底差在哪（这一节决定你的预算）
被问得最多的一句话是"二级和三级差多少"。不是多几台设备的事，是三件事的量级差：
| 维度 | 第二级 | 第三级 |
|---|---|---|
| 备案 | 必须 | 必须 |
| 专家评审 | 内部评审即可 | 需外部专家评审 |
| 测评周期 | 建议两年一次 | 每年至少一次 |
| 测评机构 | 有资质即可 | 需省级以上推荐目录内机构 |
| 集中管控 | 不强制 | 强制（安全管理中心） |
| 审计留存 | 6 个月 | 6 个月 + 集中审计平台 |
| 入侵防范 | 边界防护 | 入侵检测/防御 + 恶意代码防范 |
| 数据完整性/保密性 | 校验或加密其一 | 两者都要 |
| 备份 | 本地备份 | 本地 + 异地（或云上跨区） |
| 制度要求 | 制度齐全 | 制度 + 执行记录 + 定期评审 |
差别最大的三项，也是花钱最多的三项：集中管控（安全管理中心）、每年一次测评、异地备份。集中管控意味着要建统一日志、统一运维审计（堡垒机）、统一恶意代码防范，这三套东西对中小规模系统来说，采购加工时通常占整个项目预算的一半以上。异地备份在有分支机构的单位好办，单点部署的企业只能是云上跨区或租用机房价。
所以如果定级时还在二级和三级之间犹豫，先算清楚三级的这三笔钱，再回去看定级理由能不能站得住。反过来也一样：如果一个系统确实该定三级，别为了省钱写二级——测评、监管检查、上级审计，三处都会重新审视这个结论，只是时间问题。
云上系统的定级是个特殊点，值得单独说。租用公有云的系统，定级对象是"云上的业务系统"，不是云平台本身（云平台由云服务商定级备案）。但有两件事必须写进材料：一是云服务商通过的等级保护级别（要索取对方的备案证明和测评报告结论），二是责任划分——基础设施层由云商承担，从虚拟网络往上由租户承担。测评时这条边界划不清，会被判"责任不明"。
工控系统的定级，边界按"工控系统整体"划，不能只划 IT 侧。很多单位只给 ERP 定级，把 DCS/SCADA 排除在外，这在实际检查里站不住——一旦工控网络和办公网有连通，边界就是连通的整体。
四、备案：材料清单和最容易被打回的 6 个点
备案在属地公安机关网安部门办理，第二级以上必须备案。材料清单各地略有差异，但核心这几样跑不掉：
| 材料 | 关键要求 | 常见错误 |
|---|---|---|
| 定级报告 | 含 S/A 判定过程与结论 | 只有结论没有过程 |
| 备案表 | 系统名称、等级、责任人、拓扑 | 系统名称与定级报告不一致 |
| 系统拓扑图 | 标清区域边界、设备型号、数据流向 | 只画了个框，没有边界设备 |
| 安全管理制度目录 | 覆盖物理、网络、主机、应用、数据 | 只有目录没有正文 |
| 专家评审意见 | 三级及以上需专家评审 | 评审专家与项目方有利益关系 |
| 上级主管部门意见 | 跨行业系统需提供 | 事后补，时间对不上 |
真正会被打回的点，往往不是材料缺，是材料之间对不上：
- 系统名称三个地方三个写法——定级报告叫"MES 制造执行系统"，备案表叫"生产管理系统"，拓扑图叫"MES"。要求完全一致，包括括号和版本号。
- 定级对象边界写成了"全公司"——边界必须落到具体系统，能画出机房、能列出 IP 段。写"公司信息系统"必被打回。
- 数量对不上——定级报告说 3 个子系统，拓扑图画了 5 个。
- 责任人是 IT 经理——必须是本单位的分管领导或主要负责人，写具体姓名和职务，不能写"安全部"。
- 三级系统没有专家评审——二级可以内部评审，三级及以上要求外部专家评审并出具意见。
- 拓扑图里没有边界防护设备——防火墙、WAF、堡垒机这些不画上去，等于告诉对方"你没做边界隔离"。
备案周期各地不同，常见 10~20 个工作日。建议在整改开始前就递材料，因为备案证明是测评受理的前置条件，卡在这上面等项目排期很亏。
五、差距分析：不是"对照条款打勾"，是算清整改成本
差距分析的产物通常有两种，只有第二种有用：
- 打勾版：把 GB/T 22239 的控制项抄一遍，逐条打"符合/不符合"。做完 200 多行，老板看不懂，运维也不知道从哪开始。
- 成本版：每条不符合项写清"现状是什么、要改成什么、需要谁配合、大概多少人天、有没有替代方案"。这才是能拿去申请预算的东西。
每条不符合项建议按六列写：
| 控制点 | 条款要求 | 现状（带证据） | 结论 | 整改动作 | 工作量 |
|---|---|---|---|---|---|
| 8.1.4.2 访问控制 | 应对登录用户分配账户和权限，禁用默认账户 | 应用存在 admin/root 默认账户 3 个，未改密 | 不符合 | 删除默认账户，建立账号申请流程 | 3 人天 |
| 8.1.4.4 入侵防范 | 应能发现可能存在的已知漏洞 | 有漏扫工具但季度一跑，无闭环台账 | 部分符合 | 改为月度扫描 + 整改台账 | 5 人天 + 工具授权 |
| 8.1.4.3 安全审计 | 审计记录留存不少于六个月 | 日志平台留存 30 天，磁盘已用 85% | 不符合 | 扩容 + 调整保留策略 | 8 人天 + 硬件 |
四个结论选项要用准，别一律写"部分符合"糊过去：
- 符合——有措施，且有证据能证明它在生效。只有制度没有执行记录的，不算。
- 部分符合——有措施但覆盖不全，或者有措施但没有验证记录。
- 不符合——措施不存在。
- 不适用——该条款对这套系统确实不适用（比如纯内网系统不涉及互联网访问控制），必须在报告里写明不适用的理由，且理由要经得起问。滥用"不适用"是测评时被重点挑的地方。
证据这件事值得单独说。差距分析里"现状"这一列，写"已配置密码策略"是没用的，要写"域控组策略已启用：最小长度 8 位、90 天更换、锁定阈值 5 次，截图见附件 3-12"。测评机构现场核查就是查这个，你写清楚，现场就快；你写含糊，现场就一条条找你要。
六、差距分析的打分与结论判定（含统计脚本）
测评报告最后要给一个总分和结论，判定规则大致是：
| 得分率 | 结论 |
|---|---|
| ≥ 90% | 优 |
| 80% ~ 90% | 良 |
| 70% ~ 80% | 中 |
| < 70% | 差 |
但不是总分够了就过。还有一条硬规则：存在高危风险项且未整改的，即使总分达标也判定为不通过。高危项通常是这几类：弱口令、未授权访问、SQL 注入、越权、敏感数据明文传输、日志缺失导致无法追溯。
所以差距分析做完，第一件事不是算总分，是把高危项单独拉一张表，先解决它——这张表决定项目能不能过，总分只决定过得好不好看。
条目多的时候，手工汇总容易错。可以把差距分析表导成 CSV，用下面这段脚本算：
# -*- coding: utf-8 -*- """汇总等保差距分析结果：按控制点统计得分率，并单列高危未闭环项。""" import csv from collections import defaultdict # CSV 列：控制点,条款,结论,权重,高危,整改状态 # 结论取值：符合 / 部分符合 / 不符合 / 不适用 SCORE = {"符合": 1.0, "部分符合": 0.5, "不符合": 0.0} def analyze(path): by_point = defaultdict(lambda: [0.0, 0.0]) high_risk = [] with open(path, encoding="utf-8-sig") as f: for row in csv.DictReader(f): verdict = (row.get("结论") or "").strip() if verdict == "不适用": continue w = float(row.get("权重") or 1) s = SCORE.get(verdict, 0.0) key = row["控制点"] by_point[key][0] += s * w by_point[key][1] += w if (row.get("高危") or "").strip() in ("是", "Y", "1") and verdict != "符合": high_risk.append((key, row["条款"][:30], row.get("整改状态", ""))) total = sum(v[0] for v in by_point.values()) weight = sum(v[1] for v in by_point.values()) rate = total / weight * 100 if weight else 0 print("控制点得分率：") for k, (s, w) in sorted(by_point.items()): print(" %-14s %5.1f%% (%d 项)" % (k, s / w * 100 if w else 0, int(w))) if rate >= 90: level = "优" elif rate >= 80: level = "良" elif rate >= 70: level = "中" else: level = "差" print("\n总体得分率 %.1f%% -> 结论：%s" % (rate, level)) if high_risk: print("\n!! 高危项未闭环 %d 条，测评将判定不通过：" % len(high_risk)) for k, clause, st in high_risk: print(" [%s] %s | 整改状态：%s" % (k, clause, st)) else: print("\n高危项已全部闭环") if __name__ == "__main__": import sys analyze(sys.argv[1])这段脚本做三件事：剔除"不适用"项不参与计分、按控制点给加权得分率、把高危未闭环单独打出来。第三个输出是最关键的——它直接告诉你这次测评能不能过。
七、整改优先级：按"高危 → 通用要求 → 扩展要求"排，别平均用力
预算有限的时候，整改顺序错了，钱就白花了。建议按这个顺序：
- 高危风险项——弱口令、未授权访问、明文传输、日志缺失。这几项不解决，测评直接不通过，做完它们才轮到谈分数。
- 通用要求的核心控制点——身份鉴别、访问控制、安全审计、入侵防范、数据备份恢复。这五块占了得分的大头，而且整改相对标准化。
- 扩展要求——云计算、移动互联、物联网、工业控制、大数据。这块最容易超预算，因为要动架构（比如云上要划分安全区域、工控要串接工业防火墙）。
- 管理类要求——制度、机构、人员、建设、运维。这类整改成本低（主要是写文档和组织培训），但权重不低，性价比最高，建议穿插做，别放到最后。
有个反直觉的建议：管理类要求先做。理由是它几乎不花钱，却能拿到 20%~30% 的分数，而技术整改往往要采购、要停机窗口、要排期。先拿便宜的分，再集中资源啃硬骨头。
工作量估算上，给一个粗糙但好用的量级参考（三级系统、中等规模）：
| 整改类别 | 典型工作量 | 是否需采购 |
|---|---|---|
| 账户与口令治理 | 5~10 人天 | 否 |
| 日志集中与留存 6 个月 | 10~20 人天 | 是（存储） |
| 堡垒机 / 运维审计 | 10~15 人天 | 是 |
| 边界访问控制梳理 | 8~15 人天 | 部分 |
| 数据备份与恢复演练 | 10~20 人天 | 部分 |
| 管理制度体系编写 | 15~25 人天 | 否 |
| 云上安全区域划分 | 15~30 人天 | 是 |
八、时间与人力排期（附模板）
一个三级系统的完整周期，实际经验是 3~5 个月，卡点主要在采购和测评机构排期：
| 阶段 | 周期 | 主要产出 | 卡点 |
|---|---|---|---|
| 定级对象梳理 | 1~2 周 | 系统清单、边界说明 | 漏系统 |
| 定级 + 专家评审 | 2~3 周 | 定级报告、评审意见 | 专家档期 |
| 备案 | 2~4 周 | 备案证明 | 材料对不上 |
| 差距分析 | 2~3 周 | 差距分析表、整改方案 | 现状证据不全 |
| 整改实施 | 6~10 周 | 整改记录、验证截图 | 采购、停机窗口 |
| 等级测评 | 2~4 周 | 测评报告 | 机构排期 |
| 问题整改复测 | 2~4 周 | 复测报告 | 高危项反复 |
人力上，一个三级系统项目至少需要三种角色：安全负责人（对接监管和测评机构、拍板整改范围）、系统管理员（提供现状、执行整改）、文档责任人（写材料、收证据）。很多项目失败不是因为技术不行，是因为没人专职收证据——测评机构进场前一周才开始翻截图，一定来不及。
九、几个从测评现场总结的坑
- 定级报告和实际部署对不上。报告里写"部署在本单位机房"，实际已经在公有云上。云上系统要走云平台备案 + 云租户侧的定级，两套材料都要。
- "不适用"用太多。一个三级系统里挂了 40 多条"不适用"，测评机构会逐条质疑。每条"不适用"都必须有技术理由，且要能现场演示。
- 制度和执行两张皮。制度写了"每月做一次漏洞扫描"，但拿不出扫描报告。这种在管理类测评里一律判"部分符合"。
- 日志留存时间算错。"不少于六个月"是按自然月算的，很多单位配了 180 天，但磁盘满了一轮转就把老日志覆盖了，实际只留了 20 天。要看实际可查询的时间跨度，不是配置值。
- 测评前临时改配置。测评现场改配置是大忌，一改时间戳、二改出问题说不清。所有变更都应该在测评前完成并留下记录。
十、写在最后
等保 2.0 这件事，技术上没有多少新东西，难的是把一件合规工作做成一件工程工作：定级要有可辩护的理由，备案要有对得上的材料，差距分析要有能算成本的口径，整改要有优先级。
把这几件事固化成模板，第二套系统再做的时候，工作量能压到第一次的三分之一。我这边常用的六份模板是：定级对象清单、定级报告骨架、备案材料对照表、差距分析六列表、高危项跟踪表、整改排期表——核心结构都在上面几节里。
配套的几篇可以一起看：整改推动不下去的沟通方法在漏洞整改这篇里；等保里的主机加固条目可以直接套安全基线那套三层清单；如果系统已经出了事，处置顺序看应急响应复盘。
你那边定级时遇到过 S/A 判定扯不清的情况吗？尤其是云上系统和工控系统，评论区说说具体场景，我挑典型的补一份判定示例。
