网络安全等级保护2.0时代，于2019年12月1日正式开始。

各企业需透彻了解等保合规要求，在等保标准的基础上构建覆盖技术和管理的综合防御体系，提升网络安全风险治理意识，做好安全防护基础工作，加强网络安全防御和检测能力，争取顺利通过等保2.0的测评“大考”。

和大家聊聊安全管理部分的高风险项。所谓高风险项，指等保测评师可以一票否决的整改项，如果不改，无论你多少分都会被定为不合格。

今年的7月14日相关部门发布了《网络安全等级保护测评高风险判定指引》，是依据GB/T 22239-2019《信息安全技术网络安全等级保护基本要求》有关条款，对测评过程中所发现的安全性问题进行风险判断的指引性文件。指引内容包括对应要求、判例内容、适用范围、补偿措施、整改建议等要素。

PS：需要指出的是，本指引无法涵盖所有高风险案例，测评机构须根据安全问题所实际面临的风险做出客观判断。本指引适用于网络安全等级保护测评活动、安全检查等工作。信息系统建设单位亦可参考本指引描述的案例编制系统安全需求。

9、安全管理制度

9.1 管理制度

9.1.1 管理制度建设：

对应要求：应对安全管理活动中的各类管理内容建立安全管理制度。

判例内容：未建立任何与安全管理活动相关的管理制度或相关管理制度无法适用于当前被测系统的，可判定为高风险。

适用范围：所有系统。

满足条件（任意条件）：

1、未建立任何与安全管理活动相关的管理制度。

2、相关管理制度无法适用于当前被测系统。

补偿措施：无。

整改建议：建议按照等级保护的相关要求，建立包括总体方针、安全策略在内的各类与安全管理活动相关的管理制度。

10、安全管理机构

10.1 岗位设置

10.1.1 网络安全领导小组建立：

对应要求：应成立指导和管理网络安全工作的委员会或领导小组，其最高领导由单位主管领导担任或授权。

判例内容：未成立指导和管理信息安全工作的委员会或领导小组，或其最高领导不是由单位主管领导委任或授权，可判定为高风险。

适用范围：3级及以上系统。

满足条件（同时）：

1、3级及以上系统；

2、未成立指导和管理信息安全工作的委员会或领导小组，或领导小组最高领导不是由单位主管领导委任或授权。

补偿措施：无。

整改建议：建议成立指导和管理网络安全工作的委员会或领导小组，其最高领导由单位主管领导担任或授权。

11、安全建设管理

11.1 产品采购和使用

11.1.1 网络安全产品采购和使用：

对应要求：应确保网络安全产品采购和使用符合国家的有关规定。

判例内容：网络关键设备和网络安全专用产品的使用违反国家有关规定，可判定为高风险。

适用范围：所有系统。

满足条件：网络关键设备和网络安全专用产品的使用违反国家有关规定。

补偿措施：无。

整改建议：建议依据国家有关规定，采购和使用网络关键设备和网络安全专用产品。（《网络安全法》第二十三条规定网络关键设备和网络安全专用产品应当按照相关国家标准的强制性要求，由具备资格的机构安全认证合格或者安全检测符合要求后，方可销售或者提供。国家网信部门会同国务院有关部门制定、公布网络关键设备和网络安全专用产品目录，并推动安全认证和安全检测结果互认，避免重复认证、检测）。

11.1.2 密码产品与服务采购和使用：

对应要求：应确保密码产品与服务的采购和使用符合国家密码管理主管部门的要求。

判例内容：密码产品与服务的使用违反国家密码管理主管部门的要求，可判定为高风险。

适用范围：所有系统。

满足条件：密码产品与服务的使用违反国家密码管理主管部门的要求。

补偿措施：无。

整改建议：建议依据国家密码管理主管部门的要求，使用密码产品与服务。（如《商用密码产品使用管理规定》等）。

11.2 外包软件开发

11.2.1 外包开发代码审计：

对应要求：应保证开发单位提供软件源代码，并审查软件中可能存在的后门和隐蔽信道。

判例内容：对于涉及金融、民生、基础设施等重要行业的业务核心系统由外包公司开发，上线前未对外包公司开发的系统进行源代码审查，外包商也无法提供相关安全检测证明，可判定为高风险。

适用范围：涉及金融、民生、基础设施等重要核心领域的3级及以上系统。

满足条件（同时）：

1、3级及以上系统；

2、涉及金融、民生、基础设施等重要行业的业务核心系统；

3、被测单位为对外包公司开发的系统进行源代码安全审查；

4、外包公司也无法提供第三方安全检测证明。

补偿措施：

1、开发公司可提供国家认可的第三方机构出具的源代码安全审查报告/证明，可视为等效措施，判符合。

2、可根据系统的用途以及外包开发公司的开发功能的重要性，根据实际情况，酌情提高/减低风险等级。

3、如第三方可提供软件安全性测试证明（非源码审核），可视实际情况，酌情减低风险等级。

4、如被测方通过合同等方式与外包开发公司明确安全责任或采取相关技术手段进行防控的，可视实际情况，酌情降低风险等级。

5、如被测系统建成时间较长，但定期对系统进行安全检测，当前管理制度中明确规定外包开发代码审计的，可根据实际情况，酌情减低风险等级。

整改建议：建议对外包公司开发的核心系统进行源代码审查，检查是否存在后门和隐蔽信道。如没有技术手段进行源码审查的，可聘请第三方专业机构对相关代码进行安全检测。

11.3 测试验收

11.3.1 上线前安全测试：

对应要求：应进行上线前的安全性测试，并出具安全测试报告，安全测试报告应包含密码应用安全性测试相关内容。

判例内容：系统上线前未通过安全性测试，或未对相关高风险问题进行安全评估仍旧“带病”上线的，可判定为高风险。安全检查内容可以包括但不限于扫描渗透测试、安全功能验证、源代码安全审核。

适用范围：3级及以上系统。

满足条件（同时）：

1、3级及以上系统；

2、系统上线前未进行任何安全性测试，或未对相关高风险问题进行安全评估仍旧“带病”上线。

补偿措施：

1、如被测系统建成时间较长，定期对系统进行安全检测，管理制度中相关的上线前安全测试要求，可根据实际情况，酌情减低风险等级。

2、如系统安全性方面是按照技术协议中的约定在开发过程中进行控制，并能提供相关控制的证明，可根据实际情况，酌情减低风险等级。

3、可视系统的重要程度，被测单位的技术实力，根据自检和第三方检测的情况，酌情提高/减低风险等级。

整改建议：建议在新系统上线前，对系统进行安全性评估，及时修补评估过程中发现的问题，确保系统不“带病”上线。

12、安全运维管理

12.1 漏洞和风险管理

12.1.1 安全漏洞和隐患的识别与修补：

对应要求：应采取必要的措施识别安全漏洞和隐患，对发现的安全漏洞和隐患及时进行修补或评估可能的影响后进行修补。

判例内容：未对发现的安全漏洞和隐患及时修补，会导致系统存在较大的安全隐患，黑客有可能利用安全漏洞对系统实施恶意攻击，如果安全漏洞和隐患能够构成高危风险，可判定为高风险。

适用范围：3级及以上系统。

满足条件（同时）：

1、3级及以上系统；

2、通过漏洞扫描，发现存在可被利用的高风险漏洞；

3、未对相关漏洞进行评估或修补，对系统安全构成重大隐患。

补偿措施：如果安全漏洞修补可能会对系统的正常运行造成冲突，应对发现的安全漏洞和隐患进行评估，分析被利用的可能性，判断安全风险的等级，在可接受的范围内进行残余风险评估，明确风险等级，若无高危风险，可酌情降低风险。

整改建议：建议对发现的安全漏洞和隐患进行及时修补评估，对必须修补的安全漏洞和隐患进行加固测试，测试无误后，备份系统数据，再从生产环境进行修补，对于剩余安全漏洞和隐患进行残余风险分析，明确安全风险整改原则。

12.2 网络和系统安全管理

12.2.1 重要运维操作变更管理：

对应要求：应严格控制变更性运维，经过审批后才可改变连接、安装系统组件或调整配置参数，操作过程中应保留不可更改的审计日志，操作结束后应同步更新配置信息库。

判例内容：未对运维过程中改变连接、安装系统组件或调整配置参数进行变更审批，且未进行变更性测试，一旦安装系统组件或调整配置参数对系统造成影响，有可能导致系统无法正常访问，出现异常，可判定为高风险。

适用范围：3级及以上系统。

满足条件（同时）：

1、3级及以上系统；

2、未建立变更管理制度，对于重大变更性运维过程无审批流程；

3、变更过程未保留相关操作日志及备份措施，出现问题不发进行恢复还原。

补偿措施：无。

整改建议：建议对需要作出变更性运维的动作进行审批，并对变更内容进行测试，在测试无误后，备份系统数据和参数配置，再从生产环境进行变更，并明确变更流程以及回退方案，变更完成后进行配置信息库更新。

12.2.2 运维工具的管控：

对应要求：应严格控制运维工具的使用，经过审批后才可接入进行操作，操作过程中应保留不可更改的审计日志，操作结束后应删除工具中的敏感数据。

判例内容：未对各类运维工具（特别是未商业化的运维工具）进行有效性检查，未对运维工具的接入进行严格的控制和审批，运维工具中可能存在漏洞或后门，一旦被黑客利用有可能造成数据泄漏，可判定为高风险。

适用范围：3级及以上系统。

满足条件（同时）：

1、3级及以上系统；

2、未对各类运维工具（特别是未商业化的运维工具）进行有效性检查，如病毒、漏洞扫描等；对运维工具的接入也未进行严格的控制和审批；操作结束后也未要求删除可能临时存放的敏感数据。

补偿措施：

1、如使用官方正版商用化工具，或自行开发的，安全可供的运维工具，可根据实际情况，酌情降低风险等级。

2、如对于运维工具的接入有严格的控制措施，且有审计系统对相关运维操作进行审计，可根据实际情况，酌情降低风险等级。

整改建议：如果必须使用运维工具，建议使用商业化的运维工具，严禁运维人员私自下载第三方未商业化的运维工具。

12.2.3 运维外联的管控：

对应要求：应保证所有与外部的连接均得到授权和批准，应定期检查违反规定无线上网及其他违反网络安全策略的行为。

判例内容：制度上服务器及终端与外部连接的授权和批准制度，也未定期对相关违反网络安全策略的行为进行检查，存在违规外联的安全隐患，一旦内网服务器或终端违规外联，可能造成涉密信息（商密信息）的泄露，同时增加了感染病毒的可能性，可判定为高风险。

适用范围：3级及以上系统。

满足条件（同时）：

1、3级及以上系统；

2、管理制度上无关于外部连接的授权和审批流程，也未定期进行相关的巡检；

3、无技术手段检查违规上网及其他网络安全策略的行为。

补偿措施：在网络部署了相关的准入控制设备，可有效控制、检查、阻断违规无线上网及其他违反网络安全策略行为的情况下，如未建立相关制度，未定期进行巡检，可酌情降低风险等级。

整改建议：建议制度上明确所有与外部连接的授权和批准制度，并定期对相关违反行为进行检查，可采取终端管理系统实现违规外联和违规接入，设置合理的安全策略，在出现违规外联和违规接入时能第一时间进行检测和阻断。

12.3 恶意代码防范管理

12.3.1 外来接入设备恶意代码检查：

对应要求：应提高所有用户的防恶意代码意识，对外来计算机或存储设备接入系统前进行恶意代码检查等。

判例内容：外来计算机或存储设备本身可能已被感染病毒或木马，未对其接入系统前进行恶意代码检查，可能导致系统感染病毒或木马，对信息系统极大的危害，可判定为高风险。

适用范围：所有系统。

满足条件（同时）：

1、未在管理制度或安全培训手册中明确外来计算机或存储设备接入安全操作流程；

2、外来计算机或存储设备接入系统前未进行恶意代码检查。

补偿措施：无。

整改建议：建议制定外来接入设备检查制度，对任何外来计算机或存储设备接入系统前必须经过恶意代码检查，再检查无误后，经过审批，设备方可接入系统。

12.4 变更管理

12.4.1需求变更管理：

对应要求：应明确变更需求，变更前根据变更需求制定变更方案，变更方案经过评审、审批后方可实施。

判例内容：未明确变更管理流程，未对需要变更的内容进行分析与论证，未制定详细的变更方案，无法明确变更的需求与必要性；变更的同时也伴随着可能导致系统无法正常访问的风险，可判定为高风险。

适用范围：3级及以上系统。

满足条件（同时）：

1、3级及以上系统；

2、无变更管理制度，或变更管理制度中无变更管理流程、变更内容分析与论证、变更方案审批流程等相关内容。

补偿措施：无。

整改建议：建议系统的任何变更均需要管理流程，必须组织相关人员（业务部门人员与系统运维人员等）进行分析与论证，在确定必须变更后，制定详细的变更方案，在经过审批后，先对系统进行备份，然后在实施变更。

12.5 备份与恢复管理

12.5.1 数据备份策略：

对应要求：应根据数据的重要性和数据对系统运行的影响，制定数据的备份策略和恢复策略、备份程序和恢复程序等。

判例内容：未明确数据备份策略和数据恢复策略，以及备份程序和恢复程序，无法实现重要数据的定期备份与恢复性测试，一旦系统出现故障，需要恢复数据，存在无数据可恢复的情况，或者备份的数据未经过恢复性测试，无法确保备份的数据可用，可判定为高危风险。此外，如有相关制度，但未实施，视为制度内容未落实，可判定为高风险。

适用范围：3级及以上系统。

满足条件（同时）：

1、3级及以上系统；

2、无备份与恢复等相关的安全管理制度，或未按照相关策略落实数据备份。

补偿措施：

1、未建立相关数据备份制度，但若已实施数据备份措施，且备份机制符合业务需要，可酌情降低风险等级。

2、如系统还未正式上线，则可检查是否制定了相关的管理制度，目前的技术措施（如环境、存储等）是否可以满足制度中规定的备份恢复策略要求，可根据实际情况判断风险等级。

整改建议：建议制定备份与恢复相关的制度，明确数据备份策略和数据恢复策略，以及备份程序和恢复程序，实现重要数据的定期备份与恢复性测试，保证备份数据的高可用性与可恢复性。

12.6 应急预案管理

12.6.1 应急预案制定：

对应要求：应制定重要事件的应急预案，包括应急处理流程、系统恢复流程等内容。

判例内容：未制定重要事件的应急预案，未明确重要事件的应急处理流程、系统恢复流程等内容，一旦出现应急事件，无法合理有序的进行应急事件处置过程，造成应急响应时间增长，导致系统不能在最短的事件内进行恢复，可判定为高风险。

适用范围：所有系统。

满足条件：未制定重要事件的应急预案。

补偿措施：如制定了应急预演，但内容不全，可根据实际情况，酌情降低风险等级。

整改建议：建议制定重要事件的应急预案，明确重要事件的应急处理流程、系统恢复流程等内容，并对应急预案进行演练。

12.6.2 应急预案培训演练：

对应要求：应定期对系统相关的人员进行应急预案培训，并进行应急预案的演练。

判例内容：未定期对相关人员进行应急预案培训，未根据不同的应急预案进行应急演练，无法提供应急预案培训和演练记录，可判定为高风险。

适用范围：3级及以上系统。

满足条件：

1、3级及以上系统；

2、未定期对系统相关的人员进行应急预案培训；

3、未进行过应急预案的演练。

补偿措施：如系统还未正式上线，可根据培训演练制度及相关培训计划，根据实际情况判断风险等级。

整改建议：建议定期对相关人员进行应急预案培训与演练，并保留应急预案培训和演练记录，使参与应急的人员熟练掌握应急的整个过程。

图片来自e安教育文章，版权归原作者

“三分技术,七分管理”一直是网络安全领域的至理名言。等级保护2.0标准中，以三级要求为例，技术部分要求共计84项，管理部分要求共计127项（占比达60%），所以安全管理一定要重视起来！！！