等保三级系统建设实践指南

一、为什么要按等保三级建设

网络安全等级保护，简称“等保”，是我国网络安全领域的一项基础制度。按照 GB/T 22240—2020《信息安全技术 网络安全等级保护定级指南》，如果一个系统遭到破坏后会对社会秩序、公共利益造成严重损害，或者对国家安全造成一般损害，通常应定为第三级。

三级系统常见于重要行业的核心业务系统、面向公众的重要服务平台，以及承载较大规模用户数据或重要业务数据的系统。但需要注意：

• 等保等级由系统遭到破坏后的影响对象和损害程度决定，不是由服务器数量、用户数量或预算决定；
• “参考三级标准建设”不等于系统已经通过等保三级；
• 正式的三级系统还需要完成定级、专家评审、主管部门核准（如有）、公安备案、建设整改和等级测评；
• 购买防火墙、堡垒机或日志审计产品，只是落实部分控制措施，不能替代完整的安全治理。

本文以传统信息系统和常见云上业务系统为主要场景，介绍按等保三级通用要求进行建设的思路。具体项目还应结合属地公安机关、行业主管部门、测评机构以及云计算、移动互联、物联网、工业控制等扩展要求进行调整。

二、主要标准与基本义务

等保三级建设主要参考以下标准：

根据现行《中华人民共和国网络安全法》，网络运营者应建立安全管理制度，落实网络安全负责人，采取攻击和入侵防范措施，监测并记录网络运行状态与安全事件，相关网络日志留存不少于六个月，同时落实数据分类、重要数据备份、加密和应急处置等要求。

对于三级系统，还应至少每年开展一次等级测评和一次安全自查，并对发现的问题进行整改。等保不是一次性的验收项目，而是一个持续运行的安全管理体系。

三、总体建设框架

等保 2.0 的通用要求分为五个安全技术域和五个安全管理域：

技术架构通常概括为“一个中心、三重防护”：

• 一个中心：安全管理中心；
• 三重防护：安全通信网络、安全区域边界、安全计算环境；
• 安全物理环境作为基础，为整个系统提供机房、设备和供电保障。

flowchart TB
    U[互联网用户 / 内部用户 / 运维人员]
    B[安全区域边界
访问控制、WAF、入侵防护、边界审计]
    N[安全通信网络
网络分区、链路保护、加密传输、冗余设计]
    C[安全计算环境
主机、容器、数据库、应用和数据安全]
    M[安全管理中心
集中审计、监测告警、统一运维、安全分析]
    P[安全物理环境
机房、供电、消防、防水、防盗]
    G[安全管理体系
制度、机构、人员、建设和运维]

    U --> B --> N --> C
    M -.统一管理与审计.-> B
    M -.统一管理与审计.-> N
    M -.统一管理与审计.-> C
    P --> N
    P --> C
    G -.制度与流程约束.-> P
    G -.制度与流程约束.-> M
    G -.制度与流程约束.-> C

这套架构并不要求每个能力都必须由独立设备实现。例如，云防火墙、负载均衡、WAF 和云安全中心可能共同承担区域边界防护；集中日志平台和安全运营平台也可能共同承担安全管理中心的职责。关键在于控制措施是否有效、责任边界是否明确，并且能够提供可验证的证据。

四、五个安全技术域如何建设

4.1 安全物理环境

自建机房应重点落实：

• 机房选址避开水灾、火灾、强电磁干扰等高风险区域；
• 对出入口实施电子门禁，记录并审计人员进出情况；
• 关键设备固定安装，通信线缆采取保护措施；
• 配置防雷、防静电、温湿度监控、防水和消防设施；
• 关键设备采用 UPS、备用供电或其他电力保障措施；
• 对机房环境、供电和消防状态进行持续监控和定期巡检。

如果系统部署在公有云或托管机房，物理安全通常由云服务商或 IDC 承担，但系统运营单位仍应：

• 选择能够支撑相应等级的云平台或数据中心；
• 在合同和安全协议中明确双方责任；
• 保存云平台等级保护证明、服务协议、责任边界说明等材料；
• 确认业务系统自身的账号、网络、应用、数据和运维责任没有被错误地转移给云服务商。

4.2 安全通信网络

通信网络建设关注网络架构、通信传输和可用性：

• 根据业务、管理和安全需求划分互联网接入区、DMZ、应用区、数据区、管理区等安全区域；
• 不同安全区域之间通过防火墙、安全组或其他访问控制措施隔离；
• 核心网络设备、关键链路和重要出口避免单点故障；
• 对跨公网、跨区域和远程管理流量采用 TLS、IPsec VPN、SSH 等安全协议；
• 禁止使用 Telnet、FTP、HTTP 明文管理等不安全协议；
• 限制网络设备管理地址、管理来源和管理协议；
• 定期备份交换机、路由器、防火墙等设备配置；
• 网络拓扑图、IP 地址表、路由策略和区域边界应与实际环境保持一致。

网络隔离的目标不是简单地“多划几个网段”，而是根据业务流量建立最小通信关系。例如，互联网用户只能访问反向代理或负载均衡，应用服务器只能访问必要的数据库端口，数据库原则上不应直接暴露给互联网。

4.3 安全区域边界

区域边界是等保三级整改中最容易产生设备堆叠的部分。实际建设应围绕流量控制、攻击检测和审计展开：

• 在互联网出口、不同安全区域以及重要业务边界实施访问控制；
• 采用默认拒绝、按需放行原则维护访问控制策略；
• 定期检查长期未命中、重复、过期或过于宽泛的策略；
• 对 Web 业务部署 WAF 或具备相应能力的防护措施；
• 对扫描、暴力破解、漏洞利用、恶意文件上传等攻击进行检测和阻断；
• 对异常外联、未授权接入、非法设备和违规无线网络进行监测；
• 对边界访问、安全事件和管理员操作形成审计记录；
• 对邮件、文件交换等入口实施恶意代码检测；
• 根据业务需要配置抗 DDoS、流量清洗、API 防护和机器人防护能力。

所有安全设备都应接入统一时间源。否则不同设备日志时间不一致，会导致事件关联和测评取证困难。

4.4 安全计算环境

安全计算环境覆盖网络设备、安全设备、服务器、终端、数据库、中间件、容器平台、业务应用和数据，是工作量最大的安全域。

身份鉴别

• 为每名管理员分配独立账号，禁止多人共用管理员账号；
• 删除或禁用默认账号、测试账号、离职人员账号和长期未使用账号；
• 对密码长度、复杂度、失败锁定和凭据保管建立统一策略；
• 对远程运维、特权账号和重要业务操作采用多因素认证；
• 禁止在代码、镜像、脚本和配置文件中明文保存口令、令牌和密钥；
• 服务账号应限制登录方式、来源地址、权限范围和凭据有效期。

访问控制

• 按最小权限原则分配操作系统、数据库、应用和云平台权限；
• 区分系统管理员、安全管理员、审计管理员等角色；
• 高风险操作应经过审批，并保留申请、授权和执行记录；
• 应用系统应在服务端执行权限校验，不能只依赖前端隐藏按钮；
• 定期复核角色、账号、接口权限、数据库授权和云资源 IAM 策略；
• 对敏感数据实施字段级、行级或业务范围级授权。

安全审计

• 记录登录、退出、认证失败、权限变更、配置变更和管理员操作；
• 记录重要数据的查询、导出、修改和删除行为；
• Web 和 API 日志至少包含时间、来源、目标、用户或客户端标识、请求结果等信息；
• 数据库、操作系统、网络设备和云平台日志统一采集；
• 审计日志应防止未授权访问、篡改和删除；
• 按法规要求将相关网络日志保存不少于六个月；行业有更长要求的，从其规定；
• 对大量失败登录、越权访问、异常导出和高危命令设置告警。

记录日志时应避免直接写入口令、完整令牌、身份证号、银行卡号等敏感信息。安全审计不能以制造新的数据泄露风险为代价。

入侵与恶意代码防范

• 建立操作系统、数据库、中间件、容器和网络设备的安全基线；
• 关闭不必要的端口、服务、组件、默认页面和调试接口；
• 定期执行漏洞扫描，跟踪高危漏洞修复情况；
• 对服务器和终端部署恶意代码防护或主机安全检测能力；
• 对暴力破解、提权、反弹 Shell、异常进程和异常外联进行监测；
• 建立补丁评估、测试、发布、验证和回退流程；
• 对无法及时修复的漏洞采取访问限制、虚拟补丁、隔离等缓解措施。

应用安全

• 在需求和设计阶段识别认证、授权、数据保护和审计要求；
• 对输入进行类型、长度、格式和范围校验，防范注入、路径遍历、SSRF 等问题；
• 采用参数化查询，避免拼接 SQL；
• 正确配置 Cookie 的 Secure、HttpOnly、SameSite 等属性；
• 对文件上传实施扩展名、内容、大小、存储位置和执行权限限制；
• 对登录、验证码、短信、导出和高成本接口进行频率限制；
• 对敏感操作进行二次确认、身份校验或审批；
• 依赖组件应维护软件物料清单，并持续跟踪漏洞和生命周期状态；
• 上线前开展代码审查、安全测试和漏洞扫描，重大变更后重新验证。

数据安全与备份恢复

• 梳理数据资产，并按敏感程度和业务重要性分类分级；
• 对敏感数据在传输和存储过程中实施加密；
• 密钥与密文分离管理，限制密钥的读取、导出和使用权限；
• 展示、日志、测试、开发和数据分析场景按需进行脱敏；
• 对批量查询、下载、导出和共享建立审批与审计机制；
• 确定不同数据和系统的恢复点目标 RPO、恢复时间目标 RTO；
• 建立本地备份、异地备份或跨可用区副本，避免备份与生产系统同时失效；
• 定期执行恢复演练，并保存恢复结果、耗时和问题整改记录；
• 备份账号和备份介质应与生产环境隔离，降低勒索软件同时加密生产与备份的风险。

4.5 安全管理中心

安全管理中心用于把分散的安全能力统一起来，三级系统应重点建设：

• 系统管理：通过堡垒机或统一运维入口管理重要设备和服务器，记录管理员操作；
• 审计管理：集中采集网络、主机、数据库、应用和安全设备日志；
• 安全管理：统一维护安全策略、告警规则、资产信息和处置流程；
• 集中管控：对设备状态、攻击事件、漏洞、恶意代码和异常行为进行监测；
• 关联分析：将不同来源的日志和告警关联为可处置的安全事件；
• 时间同步：所有测评对象使用可靠且统一的时间源。

常见实现由堡垒机、日志审计或 SIEM、数据库审计、终端或主机安全、漏洞管理平台、监控告警平台等共同组成。产品名称不重要，重要的是覆盖范围、策略有效性、日志完整性以及是否形成处置闭环。

五、五个安全管理域如何建设

5.1 安全管理制度

应建立覆盖安全工作的制度体系，而不是在测评前临时编写一批互相矛盾的文档。制度通常包括：

• 网络安全总体方针和管理制度；
• 账号权限、密码和特权访问管理；
• 机房、网络、主机、数据库和终端管理；
• 日志审计、数据安全、备份恢复管理；
• 漏洞、补丁、恶意代码和安全事件管理；
• 变更、发布、配置和资产管理；
• 开发测试、供应商和外包人员管理；
• 应急响应、业务连续性和灾难恢复管理。

每项制度应明确责任人、执行频率、审批要求、操作记录和检查方式，并定期评审更新。

5.2 安全管理机构

• 明确网络安全领导责任、主管部门和具体负责人；
• 设立或明确安全管理岗位，划分系统、安全和审计职责；
• 建立跨部门安全协调机制；
• 重要安全事项采用审批或集体决策；
• 定期检查制度执行情况，跟踪问题整改；
• 明确开发、运维、安全、业务和供应商之间的责任边界。

5.3 安全管理人员

• 对安全岗位和关键岗位人员进行录用审查；
• 与员工和外部人员签署保密及安全责任文件；
• 人员入职、调岗、离职时及时调整或回收权限；
• 定期开展安全意识培训和岗位技能培训；
• 对管理员、开发人员和外包人员分别设置有针对性的培训内容；
• 对违反安全规定的行为建立处理和改进机制。

5.4 安全建设管理

• 在立项和需求阶段同步确定安全目标与等级保护要求；
• 明确定级对象边界，完成定级报告、专家评审、主管部门核准和备案；
• 在总体设计中包含安全架构、产品选型和密码应用方案；
• 对开发过程实施代码管理、测试环境隔离、数据脱敏和安全测试；
• 上线前完成安全验收，遗留风险需要评估、审批和跟踪；
• 对外包开发、云服务和安全服务供应商进行能力评估；
• 合同中明确数据归属、安全责任、事件报告、审计权和退出要求；
• 保存设计、实施、测试、验收、交付和培训材料。

5.5 安全运维管理

• 建立并持续更新硬件、软件、账号、数据和云资源资产台账；
• 对配置变更、发布和网络策略调整执行申请、审批、测试和回退；
• 定期开展漏洞扫描、基线检查、日志审查和权限复核；
• 通过受控终端、VPN、堡垒机等方式进行远程运维；
• 对第三方运维限制时间、来源、权限和操作范围；
• 监测容量、性能、可用性和安全状态；
• 定期进行备份恢复测试和网络安全应急演练；
• 对安全事件执行发现、研判、遏制、清除、恢复、报告和复盘；
• 系统发生重大架构、业务或数据变化时，重新评估保护对象边界和等级。

六、分阶段实施三级建设

阶段一：确定边界与完成定级

首先明确“测评对象到底是什么”，包括：

• 业务功能和用户范围；
• 应用、数据库、中间件和服务器；
• 网络区域、出口和安全设备；
• 云资源、容器平台及外部依赖；
• 重要数据、个人信息及数据流向；
• 开发、运维和安全责任主体。

边界过大会显著增加整改和测评成本，边界过小则可能遗漏关键组件。云上系统还要区分云平台与云上业务系统的责任边界。

阶段二：开展差距分析

根据三级基本要求逐项检查现状，将问题分为：

• 缺少控制措施；
• 已有措施但配置无效；
• 已执行但缺少制度或记录；
• 有制度但实际没有执行；
• 存在高风险漏洞、弱口令、暴露端口或不安全架构。

输出差距清单时，应为每个问题明确责任人、整改方案、计划时间、验证方法和遗留风险处理方式。

阶段三：建设与整改

整改顺序建议按风险和依赖关系安排：

1. 先处理互联网暴露、高危漏洞、弱口令、越权和数据泄露等高风险问题；
2. 再完善网络分区、访问控制、身份权限和安全审计；
3. 建设集中日志、统一运维、监测告警和备份恢复能力；
4. 完善应用安全、数据安全和安全开发流程；
5. 补齐制度、台账、审批记录和运行证据。

阶段四：预评估与正式测评

正式测评前应进行内部预检查：

• 测评范围与备案范围是否一致；
• 网络拓扑、资产台账、端口和实际环境是否一致；
• 安全策略是否已经启用并产生有效日志；
• 制度中规定的巡检、审计、培训和演练是否真实执行；
• 是否完成备份恢复测试，而不只是看到备份任务显示成功；
• 是否仍存在默认口令、共用账号、高危漏洞和未授权互联网暴露；
• 测评访谈人员是否了解自己的安全职责和实际流程。

测评过程中通常会采用访谈、文档审查、配置检查、现场核查和工具测试等方法。发现问题后，应根据测评结果整改并验证，形成闭环。

阶段五：进入持续运营

通过测评只是新的起点。系统后续还需要：

• 每年至少开展一次等级测评和安全自查；
• 持续开展漏洞、补丁、日志、权限和资产管理；
• 定期执行应急演练与备份恢复演练；
• 重大变更后重新开展风险评估和安全验证；
• 定期向管理层报告安全状态、事件、风险和整改进度；
• 定级对象撤销、合并或发生重大变化时，按要求办理备案变更。

七、测评前需要准备的材料

材料的核心作用是证明控制措施长期有效运行。一次性补写大量巡检记录不仅无法改善安全，也很容易在访谈、日志和配置核查时出现矛盾。

八、常见误区

误区一：三级就是购买一套安全产品

等保三级同时包含技术和管理要求。安全产品没有正确配置、无人运营或没有处置流程，仍然不能形成有效控制。

误区二：系统部署在云上就不需要做等保

云服务商负责云平台基础设施安全，业务运营者仍负责云上业务系统、账号权限、应用、数据和安全配置。云平台通过等保不能代替云上业务系统完成等保。

误区三：日志保存六个月就足够了

除了保存时间，日志还要覆盖关键对象和安全事件，保证时间准确、内容完整、能够查询，并防止被未授权删除或篡改。

误区四：有备份就满足要求

没有执行过恢复测试的备份不能证明可以恢复。还应考虑备份隔离、异地保存、恢复顺序、RPO、RTO 和勒索软件风险。

误区五：通过一次测评后不再维护

账号、资产、漏洞、组件和网络策略每天都可能发生变化。三级系统要求持续保护，并至少每年开展一次等级测评和自查。

误区六：把所有系统都定成三级最稳妥

定级过高会增加建设、测评和持续运营成本；定级过低则无法充分控制风险。正确做法是根据影响对象和损害程度准确划分保护对象、合理定级。

九、三级建设自查清单

正式测评前，可以先完成以下检查：

• 定级对象边界清晰，备案范围与实际系统一致；
• 网络拓扑、资产、账号、端口和数据台账保持最新；
• 网络合理分区，区域之间遵循最小通信原则；
• 互联网入口和重要边界具备访问控制、攻击防护和审计能力；
• 管理员使用独立账号，远程运维和特权访问采用多因素认证；
• 重要运维操作通过受控入口执行并可以审计回放；
• 主机、数据库、中间件、容器和网络设备完成安全基线加固；
• 漏洞扫描、补丁修复和遗留风险形成闭环；
• 应用完成身份认证、权限控制、输入校验和安全测试；
• 敏感数据完成分类、授权、加密、脱敏和访问审计；
• 关键日志集中采集，时间同步，留存不少于六个月；
• 高风险事件能够告警，并有真实的分析和处置记录；
• 备份与生产环境适当隔离，并完成恢复测试；
• 制度、职责、操作流程和实际执行情况一致；
• 已开展安全培训、权限复核、自查和应急演练；
• 云服务商、开发商和运维供应商的安全责任已经写入合同；
• 正式测评前不存在未处置的弱口令、高危漏洞和未授权暴露。

十、总结

按等保三级建设系统，核心不是堆叠安全设备，而是建立覆盖物理环境、网络、边界、主机、应用、数据、人员和流程的完整防护体系。

技术上，应围绕“一个中心、三重防护”完成网络分区、身份鉴别、访问控制、集中审计、入侵防范、数据保护、备份恢复和安全运营；管理上，应让制度、岗位、审批、培训、运维和应急机制真正运行，并留下可验证的证据。

如果把三级建设压缩成一句话，就是：先准确确定保护对象，再用最小权限、纵深防御、集中审计和持续运营的方式控制风险，最后通过测评发现差距并持续整改。