网络安全等级保护测评中心 • 2020年6月7日 pm2:14 • 政策解读

等级保护2.0发布后，市场上铺天盖地的出现了众多解读文章，但大部分文章只停留在总体变化的描述，缺少对等级保护2.0具体条款与等级保护1.0具体基本技术要求的区别分析。

本文以帮助企业理解等级保护2.0基本要求为导向，对等级保护2.0和1.0在基本技术要求存在的区别进行具体分析。在等级保护2.0合规要求下，满足基本符合等级保护要求从1.0的60分提高到了2.0的75分，这无疑对企业、系统集成商和安全厂家提出了更高的要求和挑战：

● 采用何种安全技术手段、何种安全防护体系能够满足等级保护2.0基本要求？

● 如何为企业提供既能解决用户切实的需求，又合法、合规的安全解决方案？

● 如何帮助企业既能合理规划网络安全的费用投入，又能提高自身网络安全防护能力，达到相关等级保护级别测评要求？

下面将结合等级保护1.0（三级）的具体条款和等级保护2.0（三级）的关键条款变化进行详细的解读。（本文主要针对网络安全部分进行详细解读分析）

1、网络安全-关键条款变化

由于等级保护2.0中将整体结构进行调整，从物理安全、网络安全、主机安全、应用安全、数据安全变成安全物理环境、安全通信网络、安全区域边界、安全计算环境和安全管理中心，所以原等级保护1.0中的“网络安全”变成“安全通信网络”。

结构安全-详解

 

在等级保护2.0中，在这一小节没有明显的变化，主要是将一些过于老旧的条款进行了删除，将原等级保护1.0中的c）d）g）删除。同时增加了“应提供通信线路、关键网络设备和关键计算设备的硬件冗余，保证系统的可用性”的条款，并将这一小节中的“子网、网段”都统一更换成了“网络区域”。

 对企业、安全厂家、系统集成商提出的要求

1) 企业或集成商进行网络基础建设时，必须要对通信线路、关键网络设备和关键计算设备进行冗余配置，例如关键网络设备应采用主备或负载均衡的部署方式；

2) 安全厂家在进行安全解决方案设计时，也应采用主备或负载均衡的方式进行设计、部署；

3) 强调、突出了网络区域的概念，无论在网络基础建设，还是安全网络规划，都应该根据系统应用的实际情况进行区域划分。

访问控制-详解

 

 

   

在等级保护2.0中，对于访问控制这一节变化较大，首先将等级保护1.0访问控制这一小节从原来网络安全中的条款变更到安全区域边界这一节中，其次删除了等级保护1.0中大部分条款，如上图，将c）d）e）f）g）h）全部删除。同时在上一节网络架构提出网络区域的基础上，进一步强调区域的概念，强调应在网络边界或区域之间部署访问控制设备，并强调了“应对进、出网络的数据流实现基于应用协议和应用内容的访问控制”，对应用协议、数据内容的深度解析提出了更高的要求。

 对企业、安全厂家、系统集成商提出的要求

1)  要着重考虑网络边界的访问控制手段，但网络边界不仅仅是业务系统对其他系统的网络边界，还应该包括在业务系统内不同工艺区域的网络边界；

2)  访问控制的颗粒度要进一步的强化，不仅仅要停留在对于HTTP,FTP,TELNET,SMTP等通用协议的命令级控制程度，而是要对进出网络数据流的所有应用协议和应用内容都要进行深度解析；

3）企业用户在进行网络安全防护项目招标时一定要考虑参与投标的安全厂家所采用的边界访问控制设备是否具备对应用协议深度解析的能力，例如在工业控制系统，除了能够对比较常见的OPC、ModBus TCP、DNP3、S7等协议进行深度解析外，还需要根据现场业务实际情况，对业务系统中使用的私有协议进行自定义深度解析，否则很难达到测评要求。

安全审计-详解

 

在等级保护2.0中，将等级保护1.0安全审计这一小节从原来网络安全中的条款变更安全区域边界这一节中，将原条款的c）去掉，并对其他三条都进行了强化，尤其是a）条款，同时增加了“应能对远程访问的用户行为、访问互联网用户行为等都进行行为审计和数据分析”。

 对企业、安全厂家、系统集成商提出的要求

1) 重点强调了需要在网络边界、重要网络节点处进行网络行为审计，要求企业在进行网络安全防护项目时要充分考虑网络边界和重要网络节点的行为审计能力，例如在城市轨道交通信号系统中，车站分为一级集中站、二级集中站和非集中站，结合等级保护2.0的要求，需要在一级和二级集中站都要考虑部署具备网络行为审计能力的安全产品。而仅仅在一级集中站内部署具有网络行为审计能力的产品是不够的。

2) 重点强调网络行为审计，即对网络流量进行审计，而这仅仅靠原有的日志审计类产品是不够的，无法满足等级保护2.0的要求。

边界完整性&入侵防范&恶意代码防范-详解

 

将这三点放到一起是因为彼此之间具备一定的连带关系，将等级保护1.0中的边界完整性检查、入侵防范和恶意代码防范这3节都变更到等级保护2.0中的安全区域边界中。在边界完整性检查的这一节中，原等级保护1.0中要求必须准确定位并有效阻断非法外联、内联的行为，但在等级保护2.0中要求中，提出了“防止或限制”的要求，取消了原等级保护1.0中的“定位”要求；入侵防范这一节中，主要提出了对于网络行为的分析，并且能够实现“已知”和“未知”的攻击行为检测能力。

 对企业、安全厂家、系统集成商提出的要求

1) 对于企业和系统集成商，在进行网络安全防护项目招标时要充分考虑对于在等级保护2.0中所提出的对于“已知”和“未知”的检测要求。尤其在进行安全厂家选择时，要重点考虑安全厂家对于“未知”攻击的检测能力；

2) 对于安全厂家，网络安全审计或入侵检测产品不应仅仅局限在采用“特征库”的形式进行攻击检测，因为采用以“特征库”为模板的形式无法对“未知”攻击进行检测；

3) 对于安全厂家，入侵防范的范围变化，需要在网络安全解决方案设计时充分考虑，不应仅仅在网络边界处进行入侵防范，还需要在网络中的关键节点处均需要进行入侵防范。

网络设备防护-详解

 

 

该小节在等级保护2.0全部被删除，并整合到“安全计算环境”中。

以下内容以等级保护三级为基础，针对等级保护2.0中安全计算环境部分进行解读。

再次回顾等级保护2.0的整体变化，整体结构从物理安全、网络安全、主机安全、应用安全、数据安全变成安全物理环境、安全通信网络、安全区域边界、安全计算环境和安全管理中心，其中原等级保护1.0中的“主机安全”部分整合到“安全计算环境”中。

2条款对比详解

身份鉴别

在身份鉴别这一小节中首先弱化了系统的概念，提出标识的唯一性，将原等级保护1.0中老旧条款的e）删除。同时对双因子认证进行了加强，强调“口令、密码技术、生物技术的组合鉴别，要求其中一种至少应使用密码技术来实现”。

>>> 

高风险强调

在身份鉴别这部分要求中，设备存在弱口令，远程管理无防护和缺少双因子认证均是高危风险项。

对企业、安全厂家、系统集成商提出的要求：

1)  集成商进行业务应用软件设计时，应考虑业务应用系统在“用户名”+“口令”的基础上进一步实现通过密码技术对登录用户的身份进行鉴别，同时应避免业务应用系统的弱口令问题；

2)  集成商进行业务应用软件设计时，应充分考虑用户权限的控制以及用户在登录失败后的处理机制；

3)  企业在业务运营期间不可通过不可控的网络环境进行远程管理，容易被监听，造成数据的泄露，甚至篡改；

4)  安全厂家在进行安全产品选用时，应采用具有两种或以上的组合鉴别方式的安全防护软件对登录系统的管理用户进行身份鉴别。满足本地身份认证和第三方远程身份认证双因子验证要求。

访问控制

在访问控制这一小节中，主要是将原等级保护1.0中的条款进行了完善，强调“强制访问控制”，明确授权主体可以通过配置策略规定对客体的访问规则，控制粒度等。

>>> 

高风险强调

要求项中，未重命名或删除默认账户，未修改默认账户的默认口令属于高风险项。

对企业、安全厂家、系统集成商提出的要求：

1)  集成商进行业务应用软件设计时，应充分考虑用户权限的控制以及用户在登录失败后的处理机制，确保业务应用系统不存在访问控制失效的情况；

2)  企业或集成商在进行系统配置时，应为用户分配账户和权限，删除或重命名默认账户及默认口令，删除过期、多余和共享的账户；

3)  安全厂家在进行安全产品选用时，应采用符合强制访问控制要求的安全防护软件对主机、系统进行防护，可以有效的降低高风险项的风险等级。

安全审计

在安全审计这一小节中，主要是将一些过于老旧的条款进行了删除，将原等级保护1.0中的a）b）d）条款删除，整合为“启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计”。审计记录中删除“主体标识、客体标识和结果等”并改为“事件是否成功及其他与审计相关的信息”，增加对审计记录的“定期备份”。

>>> 

高风险强调

要求项中，未启用安全审计功能，审计覆盖到每个用户，未对重要的用户行为和重要安全事件未进行审计属于高风险项。

对企业、安全厂家、系统集成商提出的要求：

1)  对集成商而言，业务应用系统软件的安全审计能力至关重要，需要能够对重要用户操作、行为进行日志审计，并且审计的范围不仅仅是针对前端用户，也要针对后端用户；

2)  对企业来说，在基础建设时应该在重要核心设备、操作系统、数据库性能允许的前提下，开启用户操作类和安全事件的审计策略，并在安全运营的过程中对策略的开启定期检查；

3)  安全厂家在进行安全审计产品选用时，应采用可以覆盖到每个用户并可对重要的用户行为和重要安全事件进行审计的产品。可利用日志审计系统实现对日志的审计分析并生产报表，通过堡垒机来实现对第三方运维操作的审计。

剩余信息保护

在剩余信息保护这一小节没有明显的变化，主要是将“操作系统和数据库系统用户”和“无论这些信息是存放在硬盘上还是在内存中”等限制性条件进行了删除，将“系统内的文件、目录和数据库记录等资源所在的存储空间”改为“存有敏感数据的存储空间”。

>>> 

高风险强调

应保证鉴别信息所在的存储空间被释放或重新分配前得到完全清除，该项为高风险项。如果身份鉴别信息释放或清除机制存在缺陷，如在清除身份鉴别信息后，仍能进行访问资源的操作，属于高风险。

对企业、安全厂家、系统集成商提出的要求：

企业或集成商在服务器上启用基于操作系统本身的剩余信息保护功能。

入侵防范

在入侵防范这一小节中，将a）和b）进行了整合，“重要服务器”改为“重要节点”，新增d）和e），要求系统可以对数据进行有效性检验，同时可以发现系统存在的已知漏洞，在验证后可以进行修补。

>>>  

高风险强调

不必要的服务、端口未关闭；管理终端管控无措施均属于高危风险项目。

对企业、安全厂家、系统集成商提出的要求：

1)  企业或集成商在进行系统安装时，遵循最小安装原则，仅安装业务应用程序及相关的组件；

2)  企业或集成商进行应用软件开发时，需要考虑应用软件本身对数据的符合性进行检验，确保通过人机接口或通信接口收到的数据内容符合系统应用的要求；

3)  企业或集成商在选择主机安全防护软件时除了要考虑主机安全防护软件的安全功能以外，还要考虑与实际业务场景结合的问题，能够有效的帮助业主解决实际痛点。工业现场大部分现场运维人员对安全知之甚少，很难严格按照等级保护要求将安全配置一一完善，所以选择的主机安全防护软件应可以通过最简单的配置来满足等级保护的要求；

4)  解决安全漏洞最直接的办法是更新补丁，但对于工业控制系统而言，打补丁的动作越谨慎越好，避免由于更新补丁而影响到生产业务。该条款需要企业委托第三方工控安全厂家对系统进行漏洞的扫描，发现可能存在的已知漏洞，根据不同的风险等级形成报告，企业或集成商根据报告在离线环境经过测试评估无误后对漏洞进行修补。

恶意代码防范

在恶意代码防范这一小节将a)、b）、c）进行了整合，同时提出了主动免疫可信验证机制，即“文件加载执行控制”的“白名单”技术。

>>> 

高风险强调

未安装防恶意代码软件，并进行统一管理，无法防止来自于外部的病毒、恶意代码入侵，为高风险项。

对企业、安全厂家、系统集成商提出的要求：

工业现场恶意代码防范一直是用户的痛点，受制于工业现场环境，杀毒软件无法在工业环境内发挥作用。误杀、漏杀、占用资源、无法升级等问题一直被诟病。所以在工业场景中应该选择采用白名单机制的安全防护软件。

资源控制

 

资源控制这一小节整体进行了删减，将部分内容整合到集中管控章节。

3、整合内容详解

将原等级保护1.0数据安全内容整合到安全计算环境中，如下图所示：

 

 

>>> 

高风险强调

数据传输完整性保护和保密性保护，针对不同的业务场景，如业务场景对数据传输的完整性要求高，未采取相应措施，则为高风险；如业务场景对数据传输保密性要求高，未采取相应措施，则为高风险。

数据存储完整性保护和保密性保护，针对不同的业务场景，如业务场景对数据存储的完整性要求高，未采取相应措施，则为高风险；如业务场景对数据存储保密性要求高，未采取相应措施，则为高风险。

对企业、安全厂家、系统集成商提出的要求：

在工业现场大部分的场景对于数据传输、存储完整性要求要高于数据传输、存储保密性要求。对于系统集成商在应用通过密码技术来保证传输数据的完整性，并在服务器端对数据有效性进行验证。

在工业现场关键服务器、工作站内存储的业务软件及配置文件的完整性和可用性是至关重要的，一旦其完整性遭到破坏，直接影响现场生产任务。所以对于安全厂家提出的要求就是其安全防护软件应可以通过访问控制功能，对存储的数据、配置文件进行完整性保护，避免遭到非法破坏。

企业应建立异地备份中心，同时形成数据备份制度，定期进行现场的关键数据、配置文件的备份。

以下内容将以等级保护三级为基础，针对等级保护2.0中安全管理中心部分进行解读。

在原等保1.0中技术要求部分没有单独设立章节对安全管理中心进行要求，只在“管理要求→系统运维管理下→监控管理和安全管理中心”一节中提到“应建立安全管理中心，对设备状态、恶意代码、补丁升级、安全审计等安全相关事项进行集中管理”。在等级保护2.0的整体变化中，单独设立“安全管理中心”章节，强化安全管理中心的概念，突出安全管理中心在信息安全等级保护建设中的重要性。

 

 

4、新增条款详解

在等级保护2.0“安全管理中心”章节中，“系统管理”、“审计管理”和“安全管理”三小节中对分别对系统管理员、审计管理员和安全管理员的管理主体、权限控制和管控过程提出明确要求，同时要求安全管理中心内的管理系统符合“三权分立”权限管理模式，并在“集中管控”小节中对管理系统需要符合的集中管控功能进行了规定。

系统管理

在“系统管理”这一小节中，要求安全管理中心内的管理系统应具备对系统管理员的身份鉴别、特定命令和操作界面控制和操作审计等功能，并要求系统管理员作为系统资源和运行配置的唯一主体。

>>> 

对企业、安全厂家、系统集成商提出的要求：

1) 集成商进行整体架构设计时，应合理设置安全管理中心，且安全管理中心内的管理系统应具备系统管理员配置和管控的相应功能；

2) 企业或集成商在系统配置时，应确保系统管理员作为唯一主体通过安全管理中心进行系统配置；

3) 安全厂家在进行产品选用和开发时，应采用管理权限模块化设计且符合系统管理要求的管理系统对管理主体、权限和对象进行控制，确保系统管理安全性。

审计管理

在“审计管理”这一小节中，要求安全管理中心内的管理系统应具备对审计管理员的身份鉴别、特定命令和操作界面控制和操作审计等功能，并要求审计管理员作为审计记录分析和管控的唯一主体。

>>>  

对企业、安全厂家、系统集成商提出的要求：

1) 集成商进行整体架构设计时，应合理设置安全管理中心，且安全管理中心内的管理系统应具备审计管理员配置和管控的相应功能；

2) 企业或集成商在进行审计记录分析和管控时，应确保审计管理员作为唯一主体进行分析和管控，设定安全审计策略；

3) 安全厂家在进行产品选用和开发时，应采用管理权限模块化设计且符合审计管理要求的管理系统对审计记录和审计策略等进行控制，确保系统审计管控过程安全性。

安全管理

在“安全管理”这一小节中，要求安全管理中心内的管理系统应具备对安全管理员的身份鉴别、特定命令和操作界面控制和操作审计等功能，并要求安全管理员作为系统安全参数设定、主客体标记、授权和可信验证策略配置的唯一主体。

>>> 

对企业、安全厂家、系统集成商提出的要求：

1) 集成商进行整体架构设计时，应合理设置安全管理中心，且安全管理中心内的管理系统应具备安全管理员配置和管控的相应功能；

2) 企业或集成商在进行系统安全参数设定、主客体安全标记和安全策略配置时，应确保安全管理员作为唯一主体进行配置；

3) 安全厂家在进行产品选用和开发时，应采用管理权限模块化设计且符合安全管理要求的管理系统对安全管理员管控过程、系统安全策略配置等进行控制，确保系统安全管理过程安全性。

集中管控

“集中管控”这一小节中，在原等级保护1.0“应建立安全管理中心，对设备状态、恶意代码、补丁升级、安全审计等安全相关事项进行集中管理”要求的基础上增加“a)应划分出特定的管理区域，对分布在网络中的安全设备或安全组件进行管控”、“b)应能够建立一条安全的信息传输路径，对网络中的安全设备或安全组件进行管理”、“f)应能对网络中发生的各类安全事件进行识别、报警和分析”三个要求，明确安全管理中心在系统网络架构上的独立地位，对管理传输链路通信安全性提出要求，同时要求具备对网络安全事件的分析和告警能力。

>>> 

高风险强调：

要求项中，对各类设备运行状况的集中监测、各类设备审计数据汇总分析和留存时间要求属于高风险项。

>>>