简介面向企业安全、网络运维及等保咨询人员围绕等级保护2.0三级基本要求逐项梳理与1.0相比的关键条款变化重点解读安全通信网络、安全区域边界、安全计算环境等结构调整并针对结构安全、访问控制、安全审计、身份鉴别、入侵防范、恶意代码防范、集中管控等模块给出企业、安全厂家和系统集成商侧的落地建议。资源为docx格式共1个文件约3.39MB内容覆盖关键条款变化、条款对比详解、新增条款详解等模块适合需要快速理解等保2.0考核要点、规划整改方案或评估安全产品的读者。已有833人学习下载可作为等保建设、测评准备和方案设计的实用参考资料。1. 等保2.0基本要求解读先看清这套标准到底约束谁等保2.0基本要求是当前国内绝大多数单位做网络安全合规绕不开的一份文件核心标准就是 GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》。很多团队拿到这份文档翻到安全物理环境、安全通信网络、安全计算环境、安全管理中心这一串章节就犯晕不知道哪个要求对应自己的哪台设备、哪份记录。这篇解读不讲空话直接从定级备案、技术指标、三级系统整改、测评避坑到自查清单把等保2.0基本要求拆成一条能照做的落地路径。适合三类人第一次接触等保的甲方安全岗、做等保整改交付的乙方工程师、以及想搞清楚二级和三级到底差在哪里的测评新人。2. 定级与备案做在前面等保2.0落地的四个关键动作等保2.0的流程起点不是买防火墙、也不是部署日志审计而是把系统的级别定对、把备案材料交上去。级别定错后面所有的整改投入都会跑偏定低了过不了测评定高了平白增加双因素认证、异地备份、集中管控这些硬成本。这个环节的核心动作可以拆成四步。2.1 定级对象别画错一个系统一个边界别把多套业务捆成一个定级对象在等保2.0里指的是具有明确边界的信息系统、通信网络设施和数据资源。实际项目里最常见的翻车方式是两种把一整套业务链路里的 OA、ERP、数据库、文件服务器全捆成一个系统定一个级别反过来又把一个业务系统按功能模块拆成十几个系统每个都去定级备案。前者导致测评范围过大、整改成本失控后者导致备案材料堆成山、公安受理时被打回要求合并。我一般这样划边界一台业务服务器加它依赖的数据库、中间件、所在网段的安全设备构成一个定级对象如果 OA 和 ERP 各自有独立的域名、独立的服务器集群、独立的数据存储就是两个定级对象。云上部署的系统还要注意等保2.0对云计算有单独的扩展要求定级对象要按云上业务系统来划不能把整个云平台当成一个系统来报。2.2 定级要素与级别判定一张矩阵表定出二级还是三级定级的基本方法是分析两个要素系统受侵害时影响的客体以及客体受到的损害程度。客体分为公民法人合法权益、社会秩序公共利益、国家安全三类损害程度分为一般损害、严重损害、特别严重损害。把这两个维度放进矩阵对照下来就是等级。受侵害的客体一般损害严重损害特别严重损害公民、法人和其他组织的合法权益第一级第二级第二级社会秩序、公共利益第二级第三级第四级国家安全第三级第四级第五级实际操作里二级和三级是最常见的两个档位。一个系统存储了患者诊疗数据、学生个人信息、政务业务数据一旦泄露会对公共利益造成严重损害一般会定到第三级只影响单位内部办公效率、不涉及大量敏感个人信息的系统通常定第二级。注意一点不要为了“显得重要”盲目往三级定三级要求每年测评一次、双因素认证、集中管控、应急演练全部到位成本比二级高一大截。2.3 备案材料清单提交前对照公安受理要求逐项核对级别定好之后第二级以上系统需要到属地公安网安部门备案。备案材料在不同地区受理细节略有差异但核心的几样是固定的定级备案表、定级报告、系统拓扑图、安全产品清单。三级以上还要附专家评审意见涉及重要行业和关键信息基础设施的还要有上级主管部门的审核意见。备案被退回的高频原因有三个定级报告里业务描述含糊看不出系统到底干什么的、服务对象是谁备案表上的单位名称和公章不一致或系统名称和拓扑图里的名称对不上缺少专家评审意见或评审意见没有专家签字。我在交付项目里习惯把备案材料做成一个文件夹按“定级报告、备案表、评审意见、拓扑图、产品清单”五个子目录归档提交前让商务和运维各核对一遍能避免大部分低级退回。2.4 专家评审和主管部门审核哪些单位绕不开这一步三级及以上系统定级必须有专家评审评审专家一般不少于三位来源要覆盖网络安全技术、业务管理和行业主管部门。专家评审不是走形式评审意见里要明确写出“同意该系统定级为第三级”这样的结论并附上专家签名和单位。如果是医疗卫生、教育、金融、能源这类行业属性明显的单位定级报告还需要先报上级主管单位审核拿到批复意见再去公安备案。这个顺序不能倒先行业内审、后公安备案。我见过有医院跳过主管卫健委的审核直接去公安备案结果被退回重新走流程前后耽误了一个多月。定级备案整个周期预留一个半月到两个月比较稳妥其中专家评审的组织协调往往是最不可控的一环。3. 安全通用要求逐项拆解从物理环境到运维管理的落地要点等保2.0的安全通用要求覆盖十个方面其中技术部分包括安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心管理部分包括安全管理制度、安全管理机构、安全管理人员、安全建设管理、安全运维管理。测评时每一项都有对应的检查项和证据要求不是凭空打分。3.1 安全物理环境与通信网络机房、网络架构和边界防护的落地形态安全物理环境听起来像“机房检查”但它占的权重不低而且很多单位一查一处一个准。核心检查项包括机房选址是否避开顶层、地下室和潮湿区域机房门禁是否有专人值守或电子门禁是否安装视频监控和防盗报警是否有防雷接地设施和火灾自动检测报警装置是否配备防水防潮措施和温湿度自动调节设施是否有 UPS 和备用供电线路机房线缆是否有明确标识。网络和边界部分重点在网络架构的合理性核心设备、汇聚设备、接入设备是否分层部署业务网段和办公网段是否做了 VLAN 隔离跨边界访问是否必须经过防火墙等受控接口无线网络是否单独划分区域并做接入认证。三级系统的通信网络还要求对通信设备进行可信验证并保证通信过程中重要数据的传输完整性。这里有个容易被忽略的细节很多单位的安全设备部署位置不对防火墙串在业务链路中间但策略全是放通交换机做了 VLAN 但没有写 ACL等于把边界防护做成了摆设。物理环境整改起来成本高但恰恰是最早要动手的因为机房改造的周期远大于配置一台防火墙。3.2 安全计算环境身份鉴别、访问控制和安全审计的量化参数安全计算环境是测评里扣分占比最高的部分主要检查服务器、数据库、中间件、终端的身份鉴别、访问控制、安全审计、入侵防范和恶意代码防范。身份鉴别这块二级系统要求账户有密码复杂度策略、有登录失败处理功能三级系统在这基础上加了两条硬性要求采用两种或以上鉴别技术组合通常是密码加动态令牌、USB-key 或生物识别对重要系统的用户进行鉴别信息防窃听保护也就是通过 SSH、HTTPS、加密数据库连接来传输登录凭据不能用明文 Telnet 或 HTTP。访问控制的常见检查点包括是否按最小权限原则分配账户默认账户如 Administrator、root 是否被重命名或禁用是否清理了多余和过期的账户匿名账户、默认共享是否被限制管理用户、审计用户权限是否分离。安全审计则要看系统是否开启了审计功能、审计记录是否覆盖到每个用户、记录里是否包含日期时间、操作人和事件结果以及审计记录是否做了保护防止被删改覆盖。密码策略的具体参数在测评实践中一般按这个口径密码长度最小值 8 位、必须包含大小写字母数字和特殊字符中的至少三类、最长使用期限 90 天、强制密码历史 5 次以上。这些不是我在标准原文里逐字抠出来的硬性数值而是测评机构最常采用的判定口径整改时按这个配置不会出错。3.3 安全管理中心三权分立与集中管控的最小实现安全管理中心是等保2.0相对老等保新增的重点方向也是很多单位前期完全没概念的部分。它要求从系统管理、安全管理和审计管理三个维度建立账号权限分离并把分散在各设备上的日志和安全策略集中起来管控。三权分立的最小实现是系统管理员负责日常运维配置安全管理员负责安全策略制定审计管理员负责日志审计三个角色不能由同一个人兼任账号体系要分开。集中管控的最小实现不需要上多贵的平台一台堡垒机做运维入口和操作审计一台日志审计系统或自己搭的日志收集服务做集中日志安全设备的策略在各自的管理平台上统一配置、统一展示就能满足三级系统的绝大多数检查项。很多单位在这块翻车是因为理解偏差以为买了 Logstash 加 Elasticsearch 就是集中管控结果日志是集中了但没有做审计管理员的独立账号也没有形成审计报表。测评组要看的是一个闭环日志从设备收集上来有人定期查看、有异常有告警、有处置有记录。3.4 管理制度、人员与建设运行等保里的管理面怎么不流于纸面管理部分的检查逻辑是制度、机构、人员、建设、运维五个层面逐项确认测评方式主要是访谈和查记录。制度层面要有一套完整的网络安全管理制度文件至少覆盖机房管理、账号管理、变更管理、备份恢复、外包管理、应急预案这些场景。安全管理机构层面要有成立网络安全领导小组的文件、安全主管和安全管理员任命文件、以及定期考核记录。运维管理中有一块特别容易在现场被问住环境管理、资产管理和设备维护管理。环境管理不单指机房温度湿度还包括进出机房的审批记录、外部人员来访登记、机房清洁和防鼠防虫措施的执行记录资产管理要求有完整的资产清单每台设备要标明所属系统、部署位置、责任人、软件版本和启用时间设备维护管理要求有专人负责设备维护、设备保养记录和故障处理记录。这部分没有技术难点难在记录要能对应上制度。制度里写了“每月进行一次机房巡检”就要有对应的巡检记录表有日期、有检查项、有签字。测评组最反感的就是制度文件写了一整套但记录一张都拿不出来口头答复全是“我们平时都做就是没记”。4. 三级系统的量化指标与整改优先级测评项先看哪些、整改先做哪样三级系统是等保2.0落地里最常见的“硬骨头”。很多单位拿到三级整改项清单后一脸懵问题列了六七十条不知道从哪里下手。这一章把三级比二级多出来的硬性要求、常用测评指标对照和整改优先级排序讲清楚。4.1 三级比二级多了哪些硬性要求二级系统满足基本的安全防护要求即可三级系统在技术和管理上都有明显加码。技术侧最明显的是身份鉴别双因素、集中管控、异地数据备份和可信验证。二级系统用户名加口令就够了三级必须有两种以上鉴别技术二级的日志分散在各设备上也算过三级要有安全管理中心做集中收集和集中管控二级做本地备份即可三级的关键数据处理系统要有异地实时备份三级还要求服务器和通信设备在启动和运行过程中基于可信根进行可信验证这在国产化改造项目中尤其要提前规划。管理侧三级要求新建系统上线前必须完成等级测评安全方案要经过评审漏洞扫描和风险评估要按固定周期执行应急预案每年至少演练一次并留存演练记录。二级的应急演练没有明确的年度频率要求。4.2 常用测评指标对照一张表看清二三级差异检查维度二级典型要求三级典型要求身份鉴别方式用户名口令有复杂度策略口令令牌/证书等两种以上组合密码更换周期有定期更换策略测评常用口径 90 天内更换登录失败处理多次失败后锁定锁定阈值、锁定时间、解锁机制齐全访问控制按角色分配权限最小权限默认账户清理权限分离审计范围覆盖到各用户覆盖到每个用户且审计记录受保护日志留存不少于 6 个月不少于 6 个月集中收集并做防删改数据备份本地备份本地备份异地实时备份重要系统安全管理中心无强制要求系统管理/安全管理/审计管理三权分立应急演练有预案即可每年演练一次并有完整记录测评频率两年一次每年一次这张表的“典型要求”不是标准原文逐字抄写而是测评实践里的通行口径。不同测评机构在细节判定上会有差异但大方向不会偏。4.3 整改优先级排序先从高风险项下手等保测评报告的结论判定规则决定了整改顺序只要存在一个高风险项测评结论就直接记为不符合或差中低风险项再多也不会单独导致一票否决。所以第一优先级永远是根治高风险项而不是把几十条中风险全部整改完。常见的高风险项包括系统没有边界防护设备或边界策略全部放通三级系统没有双因素认证重要数据明文存储和明文传输没有任何数据备份措施机房无防火设施安全审计功能未开启或审计记录完全缺失。这些项每个都会直接卡死测评结论必须限期整改并留好整改证据。中风险项按“被攻击可能性 × 影响范围”排序。密码策略不达标、账户权限过大、日志未集中管理这类问题整改成本低、覆盖范围大建议第一批做。低风险项和测评报告里的“建议改进”类问题可以纳入下一年度整改计划不必要在测评前把自己逼疯。这个排序逻辑可以沉淀成一张整改计划表每项问题列上风险等级、整改措施、责任人和计划完成时间测评机构复核时直接按表逐项销号。5. 等保2.0整改避坑指南5个容易翻车的高频问题我在等保整改项目里反复见到同一批问题每次写整改报告都要解释一遍。这里挑出最容易翻车的 5 个直接按“现象、原因、解决”说透能少走很多弯路。5.1 日志留存六个月留的不是默认系统日志现象测评组要求提供六个月以上的日志运维打开服务器一看系统日志只保留七天之前的全没了。原因只依赖操作系统的默认日志设置没有做集中归档。Windows 默认事件日志和 Linux 的 syslog 轮转策略都不会保留那么久更别说还有大量网络设备和安全设备的日志根本没地方落盘。解决部署日志集中收集服务把所有服务器、数据库、防火墙的日志统一接收配置存储保留期不少于 180 天同时开启 NTP 时间同步避免各设备日志时间对不上。另外审计记录要防删改日志存储目录权限收紧、集中日志平台的管理账号单独设置这些在三级测评里会一并检查。5.2 密码策略改了不生效用户照样设弱口令现象域控或服务器上明明配置了密码复杂度和最长使用期限测试新建用户时依然能设置 123456 这种弱口令。原因三类情况最常见本地安全策略和域策略冲突本地配置被域策略覆盖只改了密码长度和复杂度没开“强制密码历史”和“用户下次登录时须更改密码”存量账户的旧密码全部继续有效应用系统自带一套账号体系根本不读操作系统密码策略。解决先确认所有服务器是否加域域内统一在组策略里配置密码策略并执行 gpupdate /force 刷新非域服务器逐台配置本地策略对已有账户批量勾选下次登录强制改密自建应用系统通过 LDAP 对接统一认证或将密码策略配置到应用层。改完后再新建一个测试账号验证一遍不要等到测评当天才测。5.3 边界访问控制被判定不符合防火墙规则全是放通现象测评报告里写“边界访问控制不符合”运维不服气明明在内外网之间部署了两台防火墙。原因防火墙策略长期无人梳理源地址是 any、目的地址是 any、端口是 any等于没有策略或者为了调试方便临时放通后忘了回收。测评组看的是策略表不是看设备型号策略放空跟没装防火墙没有区别。解决按业务端口最小化原则重写防火墙策略默认 deny逐条放行明确的服务端口和源目的 IP。办公网和业务网之间加 VLAN 隔离或 VLAN 间 ACL跨部门访问全部走审批流程。另外把防火墙策略变更纳入变更管理每次变更留审批记录测评时策略表和变更记录都能对上。5.4 环境管理、资产管理和设备维护管理记录补不齐的典型现场现象测评访谈时问机房进出有没有审批、设备保养怎么做、资产清单能不能看一下现场翻遍文件柜只有几张开业时的照片资产台账还是三年前的 Excel设备责任人早就离职了。原因这三个管理项在日常运维里被当成行政杂活没有明确的负责人和执行表单。制度文件里写了要管但没人规定记录谁填、填什么、存哪。解决资产清单做成一张完整的台账字段至少包括设备名称、型号、IP 地址、所在机柜、所属系统、责任人、启用日期、软件版本机房管理采用出入登记表加门禁记录双轨外部人员进入必须有审批签字设备维护记录按季度做一次巡检内容包括设备指示灯状态、温湿度数值、UPS 负载、线缆标签完好情况巡检人和日期签字。记录和制度条目之间能一一对应这项就不会再被扣分。5.5 测评报告里的“要求”和“建议”分不清整改成本翻三倍现象整改单上列了一百多条问题项目负责人把每一条都当成必须整改项预算和工期全部失控。原因不熟悉测评结论的判定机制把测评报告里的“不符合项”“部分符合项”和“建议改进项”混为一谈。解决拿到报告先看风险判定表高风险项必须立即整改并配合复核中风险项纳入近期整改计划给出明确责任人和完成时间低风险项和“建议改进”类问题排进下一年度安全建设计划。跟测评机构确认哪些项需要书面整改证明、哪些项复测时口头确认即可能省掉大量无效工作。记住一个经验报告里出现“建议”两个字的问题通常不阻塞测评结论别自己吓自己。6. 用一张Excel自查表做合规预检把等保2.0基本要求变成可勾选清单与其等测评机构来查不如自己先把要求过一遍。我最常用的工具不是安全产品而是一张 Excel 自查表针对的就是等保2.0基本要求里的几百个测评项。表头按这样的结构建标准章节、测评项编号、要求描述摘要、适用级别、当前状态、证据文件路径、责任人、整改期限。当前状态一列用下拉框填“符合”“部分符合”“不符合”“不适用”。从 GB/T 22239-2019 的正文和附录里把测评项一条条拆进表格一条一行不要嫌多拆完以后你对标准的理解会比翻三遍文档都深。建表之后做一次全员差距扫描技术类交给网络和运维管理类交给行政和安全第一周把状态全部标完。然后用筛选功能把“不符合”的项全部拉出来按高风险优先原则排在前面每一项对应一条整改措施和一个责任人。整改完成后把证据文件路径回填到表格里测评机构要什么直接定位到文件。我会在系统重大变更、人员大范围调整、测评前一个月这三个节点各跑一遍这张表。每次跑完都能从里面捞出几个平时没注意的问题比如某台服务器的审计功能被关掉了、某份应急预案已经过期没有更新。用这张表避免临时抱佛脚是我做等保这几年最值得养成的习惯希望帮到你。本文还有配套的精品资源点击获取