深色模式
等保 2.0 概览：等级保护要求与运维落地清单
摘要：本文是等级保护制度的通用科普与运维落地指引，介绍定级思路、核心框架"一个中心三重防护"和运维最常被打回的整改项。文中不引用具体法规条文编号，实际要求请以现行有效标准文本与属地主管部门解释为准。
适用环境
bash
cat /etc/os-release
hostname && hostname -I # 明确被测对象范围
ss -lntup # 定级需要业务系统边界信息
command -v lynis && lynis --version1
2
3
4
2
3
4
操作步骤
1. 先弄清楚：等保测评的对象是"系统"，不是"单机"
定级对象是业务系统（如某个对外 Web 系统），而不是一台服务器。运维要配合提供：
- 系统边界：涉及哪些主机、数据库、中间件、网络区域。
- 业务信息：用户规模、数据敏感程度、服务时段。
- 拓扑图：网络区域划分与互联关系。
2. 五个等级（通用理解）
| 等级 | 适用场景（大意） | 监督强度 |
|---|---|---|
| 第一级 | 一般系统，受破坏后影响很小 | 自主保护 |
| 第二级 | 受破坏后对公民/组织权益造成损害 | 指导 |
| 第三级 | 受破坏后对社会秩序、公共利益造成严重损害 | 监督检查 |
| 第四级 | 受破坏后造成特别严重损害 | 强制监督检查 |
| 第五级 | 极端重要，特殊保护 | 特殊监督 |
多数互联网业务系统常见为第二级或第三级，具体以专家评审与主管部门审核结论为准。
3. 记住主框架："一个中心，三重防护"
- 一个中心：安全管理中心（集中管控、审计、运维审计堡垒机）。
- 三重防护：
- 安全通信网络（网络架构、传输加密、可信接入）
- 安全区域边界（访问控制、入侵防范、恶意代码防范）
- 安全计算环境（身份鉴别、访问控制、安全审计、数据完整性/保密性）
运维的工作重心落在"安全计算环境"和"安全管理中心"两块。
4. 运维侧交付清单（按主题落地）
bash
# 身份鉴别：口令复杂度、登录失败处理、双因子
chage -l opsuser | grep -E 'Maximum|Warning'
grep -i "pam_pwquality\|pam_tally2\|pam_faillock" /etc/pam.d/system-auth 2>/dev/null
# 访问控制：权限分离、默认账号处理
awk -F: '$3==0 {print $1}' /etc/passwd
grep -R "NOPASSWD:.*ALL" /etc/sudoers /etc/sudoers.d/ 2>/dev/null
# 安全审计：审计覆盖每个用户与重要事件
systemctl is-active auditd rsyslog
auditctl -l | wc -l
# 入侵防范：最小安装、补丁、关闭高危端口
ss -lntup | grep -E ':(21|23|135|445|3389)\s'
rpm -qa | wc -l # Debian 系用 dpkg -l | wc -l
# 数据完整性与备份
ls -l /var/log/ && crontab -l | grep -i backup1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
5. 常见"必查项"速查
| 检查项 | 自查命令 | 达标表现 |
|---|---|---|
| 口令复杂度 | grep minlen /etc/security/pwquality.conf | 长度与字符种类有要求 |
| 登录失败锁定 | grep faillock /etc/pam.d/system-auth | 失败 N 次锁定 |
| 审计日志留存 | ls -l /var/log/audit/audit.log | 留存周期满足要求 |
| 默认账号清理 | awk -F: '$3<1000' /etc/passwd | 无用账号已锁定 |
| 时间同步 | chronyc sources | 与统一时钟源同步 |
| 高危端口 | ss -lntup | 无明文协议对外 |
6. 整改闭环：留证据而不是口头说做了
- 每条整改项对应：配置截图 + 命令输出 + 变更单号 + 生效时间。
- 用基线脚本定期跑，输出报告作为持续符合性证据。
验证
bash
# 自查报告：一次性生成证据包
mkdir -p /tmp/evidence-$(date +%F)
cd /tmp/evidence-$(date +%F)
{ ss -lntup; auditctl -l; chage -l root; chronyc sources; systemctl list-unit-files --state=enabled; } \
> 00-baseline.txt 2>&1
tar czf /tmp/evidence-$(date +%F).tar.gz /tmp/evidence-$(date +%F)1
2
3
4
5
6
2
3
4
5
6
判定标准：所有整改项有证据文件；基线脚本能重复生成同类报告；安全管理员与审计管理员账号分离。
常见坑
把"测评通过"当终点
测评是时间点快照。配置漂移会让半年后的状态完全不同，必须靠自动化基线巡检维持。
只改操作系统，忽略应用与数据层
等保对象覆盖网络、设备、应用、数据。Web 中间件的默认页面、目录遍历、管理后台暴露同样会被提。
为了"过检"伪造配置或截图
属于严重失信行为，会带来法律与声誉风险。真实做不到就走例外审批 + 补偿控制 + 整改计划。
三权分立只写在纸面
系统管理员、安全管理员、审计管理员应是不同账号且权限互斥，审计员不能拥有配置修改权限。
日志留存周期不足
临时清理脚本、logrotate 保留份数过小都会导致留存不达标。先算容量再定轮转策略。