等保2.0安全通用要求第二级别之安全建设管理

文章正式开始前我们要知道等保2.0中安全通用要求的十个方面包括物理环境、通信网络、区域边界、计算环境、管理中心、管理制度、管理机构、管理人员、建设管理、运维管理。

本文来了解一下等保2.0中安全通用要求中对于第二级别的安全建设管理要求，首先我们出示一张对比表格，看看安全区域边界要求中第二级别和第一级别的区别。

我们可以看到第二级别“安全建设管理””共包含10个控制点。相比第一级，新增了3个控制点，分别是自行软件开发、外包软件开发和等级测评。同时对于其他控制点都有增强，我们将会对新增部分进行讲解，至于第二级别安全建设管理的详细全部要求将体现在汇总表格上。

首先是控制点定级和备案，要求增强新增专家论证+部门批准+公安备案。第一级只要求“书面说明”；第二级增加专家论证、部门批准、公安机关备案

简单说就是不能自己拍脑袋定级。要把定级的理由写清楚，请专家评审，经过单位领导批准，再到公安机关正式备案。

这是因为第一级系统只影响个人，自己定级没问题。第二级系统可能影响企业或社会，定级不准可能导致保护措施不足或成本浪费。专家论证保合理性，公安备案合法化是等保制度的法定程序。

要求建立规范的定级与备案流程，确保定级结果的合理性和合法性。定级不是“自己说了算”，必须经过专家论证、部门批准、公安备案三道关口。

最低底线是1. 书面定级报告，说明定级方法和理由；2. 组织专家论证（有记录）；3. 定级结果经部门批准；4. 向主管部门和公安机关提交备案材料。

第二点是安全方案设计，要求增强的是书面方案+专家论证审定。第一级只要求“选基本措施”；第二级要求方案要论证、批准才能干。

简单说就是要求制定书面的安全方案，将安全保护等级要求转化为具体的技术实现措施，并通过专家论证确保方案的合理性和可行性。

这因为没有设计图就施工，安全措施容易“东一榔头西一棒子”。第二级系统必须有系统性、规范化的安全设计方案，且经专家把关，确保安全措施与风险水平匹配。

要求是制定书面的安全方案，将安全保护等级要求转化为具体的技术实现措施，并通过专家论证确保方案的合理性和可行性。

最低底线是1. 有书面的安全方案；2. 方案内容符合定级要求；3. 组织专家论证审定；4. 方案经批准后方可实施。

第三点是产品采购和使用，要求增强的是密码产品合规要求。第一级只要求“安全产品合规”；第二级明确要求密码产品要通过国密认证。

简单说就是买防火墙、VPN等安全产品，不仅要买正规的，如果涉及密码产品（如加密机、VPN中的国密算法模块），还必须符合国家密码管理局的要求。

这是因为密码技术是网络安全的根基。第二级系统涉及的数据安全要求提高，若密码产品不合规，整个加密体系可能形同虚设。国家密码管理局的认证就是为了确保密码技术安全可控。

要求是明确网络安全产品须符合国家有关法规标准，特别是密码产品必须采用国家密码管理主管部门批准的算法和产品，确保密码技术的合规性和自主可控。

最低底线是1. 采购的网络安全产品符合国家有关规定；2. 采购的密码产品符合国家密码管理主管部门要求（有相关认证证书）

第四点是自行软件开发，这是新增的控制点，原文是a) 应将开发环境与实际运行环境物理分开，测试数据和测试结果受到控制；b) 应在软件开发过程中对安全性进行测试，在软件安装前对可能存在的恶意代码进行检测。

简单说就是如果你们公司自己开发软件（如自研OA），必须：① 开发环境和生产环境物理分开（不能连到同一台服务器）；② 测试数据和结果受控（不能用真实用户数据）；③ 开发过程中就要做安全测试；④ 上线前还要做恶意代码检测。

这是因为自研软件的安全漏洞是攻击者的主要入口。如果开发过程不规范，可能引入SQL注入、后门等严重漏洞。第二级系统必须从源头控制软件质量——开发环境隔离（防代码外泄/污染），上线前检测（防带毒上线）。这是从“买成品”到“管过程”的拓展。

要求是建立安全的软件开发流程，包括开发与生产环境的隔离、测试数据的保护、开发过程中的安全性测试和上线前的恶意代码检测。

最低底线是1. 开发环境与生产环境物理隔离；2. 测试数据和结果受控管理；3. 开发过程中进行安全性测试；4. 软件安装前检测恶意代码。

第五点是外包软件开发，这也是新增的控制点。原文是a) 应在软件交付前检测其中可能存在的恶意代码；b) 应保证开发单位提供软件设计文档和使用指南。

简单说就是如果软件是外包给第三方开发的，必须在交付前检查有没有恶意代码，并且要求开发方提供设计文档（逻辑结构）和使用指南。

这是因为第三方开发可能存在供应链安全风险：开发方可能在代码中预留后门，或者提供了不安全的组件。要求提供设计文档，防止系统成为“没人敢动的黑盒”；上线前检测恶意代码，防止外包代码“携毒入场”。

要求是对外包开发的软件进行安全检测和文档管理，防止第三方引入恶意代码或留下隐蔽后门，并确保系统可维护性。

最低底线是1. 软件交付前检测恶意代码；2. 开发单位提供软件设计文档和使用指南。

第六点是工程实施，要求增强的是“制定实施方案”。第一级只要求“指定专人”；第二级要求有计划、有方案地实施。

简单说就是要求对安全工程实施过程进行规范化管理，通过制定实施方案明确施工步骤、责任人、时间节点和质量标准，确保工程按计划、高质量完成。

这是因为没有方案，实施过程就可能“按感觉做”，导致安全措施遗漏或质量不达标。第二级系统的安全要求更复杂，必须有规范的实施方案作为执行的“施工蓝图”。

要求是对安全工程实施过程进行规范化管理，通过制定实施方案明确施工步骤、责任人、时间节点和质量标准，确保工程按计划、高质量完成。

最低底线是1. 指定专人负责工程实施管理；2. 制定安全工程实施方案（含步骤、责任、时间节点）。

第七点是测试验收，要求增强的是“制订方案+形成报告+安全性测试”。第一级只要求“安全性测试验收”；第二级要求有方案、有报告、有专门的安全测试。

简单说就是系统上线前不能直接开干。要有测试验收方案，按方案测，出报告。特别是还要专门做安全性测试（如渗透测试、漏洞扫描），出安全测试报告。

这是因为第一级系统小、影响小，“测没测”很难追溯。第二级系统上线前必须有据可查——方案规定了测什么，报告记录了测的结果，安全性测试验证了系统“没有明显的安全漏洞”。这是工程质量的“可追溯化”升级。

要求是建立标准化的测试验收流程，不仅测试功能，还要测试安全性，并形成书面报告作为系统上线的依据。

最低底线是1. 制订测试验收方案；2. 按方案实施测试验收，形成报告；3. 上线前进行安全性测试，出具安全测试报告。

第八点是系统交付，要求增强的是“提供建设文档+运维文档”。第一级只要求“交付清单+培训”；第二级要求文档齐全。

简单说就是系统建好了，不是口头说一声就行。要清点设备、软件、文档，培训运维人员，还要提供整个建设过程的所有文档和运行维护需要的文档。

这是因为“黑盒”系统交给运维，以后出问题谁都搞不清楚。第二级系统要求建设文档和运维文档齐全，确保后续可维护性——知道怎么搭的，才知道怎么修、怎么改。

要求是规范系统交付过程，确保交付内容的完整性和可运维性，特别是建设文档和运维文档的提供，为系统后续运行维护提供技术依据。

最低底线是1. 制定交付清单，清点设备、软件、文档；2. 对运维人员进行技能培训；3. 提供建设过程文档和运行维护文档。

第九点是等级测评，这也是新增的控制点。原文是a) 应定期进行等级测评，发现不符合相应等级保护标准要求的及时整改；b) 应在发生重大变更或级别发生变化时进行等级测评；c) 应确保测评机构的选择符合国家有关规定。

简单说就是系统上线后不能不管。要定期找有资质的第三方测评机构做等级测评，发现问题及时整改；如果系统有重大变更（如升级架构）或定级变化，也要马上重新测评。

这是因为第一级系统“不强制测评”，是否合规无人验证。第二级系统必须由独立的第三方来验证安全措施是否到位，这是等保制度的核心监督机制——通过测评发现差距，推动整改，形成“建设-测评-整改”闭环。

要求是第三方测评机构定期开展等级测评，验证系统是否满足相应等级的安全要求，并推动闭环整改；测评机构须具备国家认可的资质。

最低底线是1. 定期进行等级测评；2. 测评发现问题及时整改；3. 重大变更或级别变化时重新测评；4. 测评机构符合国家规定（有资质）。

第十点是服务供应商选择，要求增强的是“覆盖供应链各方”。第一级只要求“签协议明确责任”；第二级要求把责任传递到整个供应链。

简单说就是找外包公司做安全服务，必须选合规的服务商，并且协议中要明确整个供应链各方的安全义务——不仅仅是直接签合同的那家公司，还包括它的下游分包商。

这是因为第二级系统可能涉及多层外包（如A公司总包、B公司分包）。如果只约束直接签约的A，B出了问题仍然可能波及系统。要求协议覆盖供应链各方，防止“责任断层”。

要求是对服务供应商进行全供应链安全管理，确保安全责任不因外包而稀释。最低底线是1. 服务商选择符合国家规定；2. 签订的协议中明确服务供应链各方的网络安全义务。

汇总要求表格如下

总结：如果说第一级是“有流程、有人管、有记录”（重在“流程闭环”），那么第二级就是在第一级基础上，扩展到软件开发领域、强化等级测评管理——从“如何买”延伸到“如何做”，从“上线就行”升级到“上线前必须测评、上线后定期测评”。

一句话，第一级：安全建设靠自觉。第二级：定级要专家评审、备案要公安机关、建设要方案、软件要检测、上线要测评——外部监督机制全面介入。