去年有个客户拿着等保测评的整改通知找过来，问我们运维监控这块到底要做到什么程度。

我当时翻了一遍整改条款，发现一个问题：条款写的都是"应具备集中监控能力"“应对审计记录进行保护”"应能对安全事件进行识别、报警和分析"之类的标准化表述。

每条都对。但每条都没告诉你，具体要在监控系统里怎么配。

后来我把 GB/T 22239-2019（网络安全等级保护基本要求）里跟运维监控相关的条款全部过了一遍，逐条对照到监控系统的具体配置项。加起来有 21 条直接相关的。

这篇就是那次整理的产物。每条给出条款原文、落地配置要求、验证方法，最后附一份自查清单。

---

一、先搞清楚一件事：等保三级到底在查什么

很多技术人员觉得等保测评就是查"有没有装防火墙、有没有上日志审计"。

不完全是。

等保三级测评的逻辑是分层检查。它不是按产品分类的，是按安全能力分层的：

• 安全物理环境：机房、电力、门禁（跟监控系统关系不大）
• 安全通信网络：网络架构、通信加密
• 安全区域边界：防火墙、入侵检测、边界防护
• 安全计算环境：主机安全、审计、恶意代码防范
• 安全管理中心：集中监控、集中审计、安全态势感知
• 安全管理制度/机构/人员：文档和组织层面
• 安全运维管理：漏洞管理、变更管理、事件处置

跟运维监控系统直接相关的，主要集中在安全计算环境、安全管理中心、安全运维管理这三个层面。

---

二、等保三级里和运维监控相关的条款

下面按三个层面逐条拆解。条款编号参照 GB/T 22239-2019。

安全计算环境相关（8条）

条款1：身份鉴别（8.1.4.1）

原文要求：应对登录的用户进行身份标识和鉴别，身份标识具有唯一性。

对监控系统的要求：

• 监控平台必须有独立的用户账号体系，不能共用账号
• 每个运维人员独立账号，禁止 admin 共用
• 密码策略：至少 8 位，含大小写+数字+特殊字符
• 登录失败锁定：连续 5 次失败锁定 30 分钟

验证方法：测评时会让你展示用户列表，确认无共用账号；尝试弱密码注册；尝试暴力登录触发锁定。

条款2：访问控制（8.1.4.2）

原文要求：应对登录的用户分配账户和权限，实现最小权限原则。

对监控系统的要求：

• 基于角色的权限控制（RBAC），至少区分：管理员、运维工程师、只读用户
• 不同用户看到的设备范围不同（按门店/客户隔离）
• 默认账户（如 admin/guest）必须禁用或改密码

验证方法：登录不同角色账号，验证能否越权访问其他门店数据。

条款3：安全审计（8.1.4.3）

原文要求：应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计。

对监控系统的要求：

• 用户登录、登出记录
• 配置变更记录（谁改了告警规则、谁修改了监控项）
• 告警确认、关闭操作记录
• 审计日志保留至少 180 天
• 审计日志不可被操作人员删除或篡改

验证方法：测评人员会查审计日志功能，确认日志内容完整且保留时间达标。这是等保三级的高频扣分项。

条款4：入侵防范（8.1.4.4）

原文要求：应能检测到对重要节点的入侵行为，并在检测到入侵事件时提供报警。

对监控系统的要求：

• 监控系统自身所在服务器需部署 HIDS（主机入侵检测）
• 能检测到异常登录（非常用 IP、非工作时间）
• 检测到暴力破解时产生告警

验证方法：从异常 IP 尝试登录，检查是否产生告警和日志。

条款5：恶意代码防范（8.1.4.5）

原文要求：应安装防恶意代码软件，并及时更新。

对监控系统的要求：

• 监控服务器安装杀毒软件（Linux 环境常用 ClamAV）
• 病毒库定期更新（至少每周）
• 如果监控 Agent 部署在业务服务器上，Agent 安装包需通过安全扫描

验证方法：检查杀毒软件安装状态和病毒库更新时间。

条款6：数据完整性（8.1.4.7）

原文要求：应采用校验技术保证重要数据在传输和存储过程中的完整性。

对监控系统的要求：

• 监控数据传输使用加密通道（Agent 到 Server 走 TLS）
• 审计日志存储有完整性校验（哈希校验或数据库完整性约束）

验证方法：检查 Agent 通信是否使用加密协议，审计日志是否有防篡改机制。

条款7：数据备份恢复（8.1.4.9）

原文要求：应提供重要数据的本地数据备份与恢复功能。

对监控系统的要求：

• 监控配置数据定期备份（告警规则、监控模板、用户权限）
• 监控数据库定期备份
• 具备恢复验证记录（不是备份了就完，要定期做恢复演练）

验证方法：检查备份策略、最近一次备份时间、是否有恢复演练记录。

条款8：剩余信息保护（8.1.4.8）

原文要求：应保证鉴别信息所在的存储空间被释放或重新分配前得到完全清除。

对监控系统的要求：

• 用户删除后，其会话 token 立即失效
• 密码不以明文存储

验证方法：检查数据库中密码字段是否加密存储；删除测试用户后尝试用旧 token 访问。

---

安全管理中心相关（7条）

条款9：系统管理（8.1.5.1）

原文要求：应对系统管理员进行身份鉴别，只允许其通过特定的命令或操作界面进行系统管理操作。

对监控系统的要求：

• 管理操作（数据库维护、系统配置修改）必须通过系统提供的管理界面或指定命令
• 禁止直接操作数据库修改配置
• 管理操作需二次确认或审批

条款10：集中监控（8.1.5.2）

原文要求：应对网络链路、安全设备、网络设备、服务器等的运行状况进行集中监控。

对监控系统的要求：

• 必须有统一平台展示所有被管设备的运行状态
• 监控范围覆盖：网络设备、安全设备（防火墙、IDS/IPS）、服务器、数据库
• 监控内容至少包含：设备在线状态、CPU/内存/磁盘、网络流量、关键服务状态
• 异常时能产生告警

验证方法：这是测评中最直观的检查项。测评人员会要求你打开监控平台，逐项展示监控覆盖范围。

这条是高频不达标项。 很多企业的监控只覆盖了服务器和网络设备，但安全设备（防火墙、IDS）的运行状态没有纳入统一监控。

条款11：集中审计（8.1.5.3）

原文要求：应对分散在各个设备上的审计数据进行收集汇总和集中分析。

对监控系统的要求：

• 需要部署日志集中管理平台（SIEM 或 ELK/Graylog 等）
• 收集范围：网络设备 syslog、服务器系统日志、安全设备日志、应用日志、数据库审计日志
• 日志保留期限：至少 180 天
• 具备日志查询和分析能力

验证方法：展示日志平台，演示从多个设备源收集的日志，现场查询指定时间段的日志。

注意：这条要求的是"集中"。如果各设备的日志只在本地存储，没有汇总到统一平台，即使每台设备都开了日志也不达标。

条款12：安全态势感知（8.1.5.4）

原文要求：应能对网络中发生的各类安全事件进行识别、报警和分析。

对监控系统的要求：

• 安全事件自动识别（异常登录、端口扫描、暴力破解等）
• 安全事件告警通知
• 安全事件统计分析（趋势图、TOP N 分析）

验证方法：展示安全事件告警记录和统计分析报表。

条款13：审计管理（8.1.5.3 补充）

原文要求：审计管理员应能对审计记录进行分析，并根据分析结果进行处理。

对监控系统的要求：

• 日志平台提供分析工具（关键词搜索、关联分析、异常检测）
• 定期出具审计分析报告

条款14：通信完整性（安全管理中心通信）

原文要求：安全管理中心与被管设备之间的通信应保证完整性。

对监控系统的要求：

• 监控 Agent/Proxy 到中心 Server 的通信加密（TLS/SSL）
• SNMP 采集建议使用 v3（支持认证和加密）

条款15：集中管控（8.1.5.2 补充）

原文要求：应能够建立一条安全的信息传输路径，对网络中的安全设备或安全组件进行集中管控。

对监控系统的要求：

• 安全设备（防火墙、IDS/IPS 等）纳入统一管理平台
• 管理通道使用加密传输

---

安全运维管理相关（6条）

条款16：漏洞和风险管理（8.1.10.2）

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

对监控系统的要求：

• 定期对被管设备进行漏洞扫描（或接入漏洞扫描平台的结果）
• 漏洞修复跟踪记录
• 监控系统自身的安全补丁及时更新

验证方法：展示漏洞扫描报告和修复记录。

条款17：网络和系统安全管理（8.1.10.3）

原文要求：应对运维人员的操作进行记录和审计。

对监控系统的要求：

• 运维操作（配置变更、设备上下线、告警处理）全部有日志记录
• 运维操作审计日志不可被运维人员自行删除

条款18：变更管理（8.1.10.6）

原文要求：应对系统的变更进行管控。

对监控系统的要求：

• 监控配置变更需有审批或记录（谁改了什么、什么时候改的）
• 重大变更（监控策略调整、告警规则批量修改）需有变更单

条款19：安全事件处置（8.1.10.8）

原文要求：应制定安全事件报告和处置管理制度，明确安全事件的类型、报告和处置流程。

对监控系统的要求：

• 安全事件分级分类（P1/P2/P3 或对应的安全等级）
• 事件处置流程有工单记录
• 事件从发现到处置到关闭的全流程可追溯

验证方法：展示安全事件工单记录，从告警到处置到关闭的完整流程。

条款20：应急预案管理（8.1.10.9）

原文要求：应制定重要事件的应急预案。

对监控系统的要求：

• 监控平台需配置应急预案关联（P1 事件触发时能关联到对应的应急处置预案）
• 每年至少一次应急演练并记录

条款21：外包运维管理（8.1.10.10）

原文要求：应确保外包运维服务商的技术人员的接入遵循最小权限原则。

对监控系统的要求：

• 外包人员使用独立账号，权限范围明确
• 外包人员的操作全部有审计日志
• 项目结束后及时回收账号

---

三、测评高频扣分项 TOP 5

根据我参与过的几次等保测评，以下是运维监控相关最容易被扣分的 5 个点：

排名	扣分项	原因	出现频率
1	审计日志保留不足 180 天	日志存储空间不够，自动清理了	非常高
2	安全设备未纳入集中监控	防火墙、IDS 各管各的，没接入统一平台	很高
3	日志没有集中收集	各设备日志留在本地，没有 SIEM/日志平台	很高
4	共用管理员账号	整个运维团队用同一个 admin 账号	高
5	配置变更无记录	改了告警规则但没有变更日志	高

第 1 条特别典型。很多企业装了日志平台，但存储空间只给了 100GB。跑了三四个月磁盘满了，自动清理了旧日志。测评的时候让你查 180 天前的日志，查不到。

解决方案很简单：日志按天归档到对象存储或 NAS，热数据保留 30 天在线查询，冷数据归档保留 180 天以上。

---

四、21 条自查清单

下表可以直接用于等保测评前的自查。最后一列标注了用开源工具能否满足。

#	条款简述	监控系统配置要求	开源可满足
1	身份鉴别	独立账号 + 密码策略 + 登录锁定	✅ Zabbix/Grafana 均支持
2	访问控制	RBAC + 最小权限 + 默认账号处理	✅ Zabbix 支持较好
3	安全审计	操作日志 + 180天保留 + 防篡改	⚠️ 需额外配置日志归档
4	入侵防范	HIDS + 异常登录检测	⚠️ 需加装 OSSEC/Wazuh
5	恶意代码防范	杀毒软件 + 病毒库更新	✅ ClamAV
6	数据完整性	TLS 传输 + 存储校验	✅ Zabbix Agent TLS
7	数据备份	定期备份 + 恢复演练	✅ 脚本 + cron
8	剩余信息保护	密码加密存储 + token 失效	✅ 主流系统默认支持
9	系统管理	管理操作通过指定界面	✅
10	集中监控	统一平台覆盖所有设备类型	⚠️ 安全设备接入需调试
11	集中审计	日志统一收集平台	⚠️ 需部署 ELK/Graylog
12	安全态势感知	安全事件识别和统计分析	❌ 开源组合较难满足
13	审计分析	日志分析工具和报告	⚠️ ELK 可做，但需定制
14	通信完整性	管理通道加密	✅ TLS 配置
15	集中管控	安全设备纳入统一管理	❌ 开源难以统一管控安全设备
16	漏洞管理	漏洞扫描 + 修复跟踪	⚠️ OpenVAS 可扫描，跟踪需手工
17	操作审计	运维操作全记录	⚠️ 需配置审计插件
18	变更管理	配置变更审批和记录	❌ 开源工具无内置变更管理
19	事件处置	事件分级 + 工单闭环	⚠️ 需对接工单系统
20	应急预案	预案关联 + 演练记录	❌ 需文档管理，系统不涉及
21	外包管理	独立账号 + 审计 + 回收	✅ 账号管理功能

统计：✅ 完全满足 8 条 / ⚠️ 需额外配置 9 条 / ❌ 难以满足 4 条

---

五、开源工具能覆盖多少？

很多企业的第一反应是"用开源组合能不能过等保"。

答案是：能过，但成本不低。

一套常见的开源等保合规组合：

组件	覆盖能力	等保相关条款
Zabbix	集中监控、告警	条款 10、14
ELK（Elasticsearch + Logstash + Kibana）	日志集中收集和分析	条款 11、13
OSSEC / Wazuh	主机入侵检测	条款 4、12
OpenVAS	漏洞扫描	条款 16
ClamAV	恶意代码防范	条款 5

这套组合能覆盖大概 60-70% 的条款要求。

剩下的 30-40% 主要卡在这几个地方：

1. 集中管控。 等保要求安全设备（防火墙、IDS/IPS）纳入统一管理平台。开源工具之间是松散组合，没有统一的管控界面。测评人员要看的是"一个平台管所有"，不是"五个平台各管一块"。

2. 变更管理。 等保要求配置变更有审批和记录。Zabbix 有操作日志，但没有内置的变更审批流程。这个要么对接 ITSM 工单系统，要么手工记录。

3. 安全态势感知。 要求对安全事件做统计分析、趋势展示、关联分析。ELK 理论上能做，但需要大量定制（Dashboard、告警规则、关联分析脚本）。

4. 事件处置闭环。 从安全事件发现 → 告警 → 工单 → 处置 → 关闭 → 复盘，这条链路用开源工具串起来需要自己写对接逻辑。

我的建议是：如果企业运维团队有 3 人以上且具备 ELK 运维能力，开源组合可以考虑。如果团队不到 3 人，维护五六个开源系统的精力可能比上一套商业平台的成本还高。

---

六、等保测评前的准备节奏

时间节点	要做的事	涉及条款
测评前 3 个月	确认监控覆盖范围，补接安全设备	10、15
测评前 2 个月	部署/完善日志集中平台，确认保留 180 天	3、11、13
测评前 2 个月	清理共用账号，配置 RBAC 权限	1、2、21
测评前 1 个月	补齐操作审计日志、变更记录	3、17、18
测评前 2 周	做一次完整自查，按 21 条清单逐项过	全部
测评前 1 周	准备截图和演示材料	全部

最后一条特别重要。测评现场是要演示的，不是交文档就完。测评人员会让你现场登录监控平台，现场查日志，现场展示告警。如果平时没用起来，临时是做不了的。

---

七、一个容易被忽略的点

等保测评不只看系统功能，还看制度文档。

跟运维监控相关的文档至少要有：

• 运维管理制度（含监控管理、告警处理、变更管理流程）
• 安全事件应急预案
• 日志管理制度（含保留周期、归档方式、销毁规定）
• 安全事件处置记录（最近 12 个月）
• 应急演练记录（最近 12 个月至少 1 次）
• 漏洞扫描报告和修复记录

系统配好了但没有配套文档，测评一样会扣分。

这些文档不需要写得多复杂，但必须有，而且要和系统实际配置对得上。比如制度里写"日志保留 180 天"，系统里实际只保留 90 天，这种不一致会被重点标注。