我给公司做等保三级整改，连续加班一个月，踩了12个坑

一个多月前，领导把我叫进会议室，桌上放着一份测评机构发来的差距分析报告。

第一页看着还算正常，往后翻了几页，我心里就开始发凉：

高风险问题十几个，中风险问题几十个，涉及网络边界、身份鉴别、访问控制、安全审计、入侵防范、数据备份和管理制度。报告最后还附了一张整改清单，密密麻麻十几页。

领导只说了一句话：

“这个系统今年必须过等保三级，整改你来牵头，时间只有一个月。”

我原本以为，等保整改无非就是改改密码策略、补几个漏洞、把日志接到平台，再整理一套制度文件。真正开始干才发现，等保三级整改最难的从来不是买设备，也不是改某一条配置，而是把多年积累下来的安全债一次性翻出来。

资产没人说得清，防火墙规则不敢动，业务账号不知道谁在用，堡垒机部署了却没人走，日志接入了但查不到，备份每天显示成功却从来没恢复过。

下面把这一个月的整改过程完整复盘一下，包括我踩过的12个坑，希望正在做等保整改的同行能少熬几个夜。

需要说明的是，目前等级保护相关工作仍以现行的《信息安全技术 网络安全等级保护基本要求》GB/T 22239—2019和《信息安全技术 网络安全等级保护定级指南》GB/T 22240—2020等标准为重要依据。

01）拿到测评报告后，先别急着买设备

很多公司拿到差距分析报告，第一反应是找供应商报价：

• 缺日志审计，买。
• 缺数据库审计，买。
• 缺入侵检测，买。
• 缺堡垒机，再买。

设备买回来往机房一放，领导觉得安全能力补齐了，供应商觉得项目完成了，真正开始测评时才发现：设备虽然有，但没有覆盖全部资产；日志虽然接了，但字段不完整；堡垒机虽然上线了，管理员还是直接SSH登录。

等保整改不是一张安全产品采购清单。

我拿到报告后，没有马上联系厂商，而是先把问题拆成了四类：

• 第一类是技术配置问题，例如弱口令、端口暴露、日志未开启和补丁缺失。
• 第二类是架构问题，例如网络区域划分不清、访问路径不受控和安全设备部署位置不合理。
• 第三类是管理问题，例如账号审批缺失、人员离职未销权和漏洞整改没有闭环。
• 第四类是材料问题，例如制度写了但没有记录，记录有了却和实际操作对不上。

然后再给每个问题标注：

• 责任部门
• 责任人
• 整改方式
• 验证方法
• 计划完成时间
• 是否影响业务
• 是否需要停机
• 是否需要采购

这张表后来成了整个项目最重要的东西。

因为到了整改后半段，你会发现真正卡进度的通常不是技术问题，而是“这件事到底归谁负责”。

02）项目启动：看起来是安全部门的事，实际上谁都跑不了

我们成立了一个临时整改群，里面有安全、运维、网络、研发、数据库、行政和供应商。

刚开始大家都觉得：

等保是安全部门的工作。

开完第一次整改会，这个想法就没了。

网络区域要调整，网络组得改。

服务器基线要加固，运维得改。

应用登录策略不符合要求，研发得改。

数据库账号权限过大，DBA得改。

人员入离职流程缺记录，行政和人事得补。

安全制度需要审批和发布，管理层得签字。

所以，等保整改不是安全部门自己关起门来就能完成的事情，而是一次跨部门的安全治理。

我当时犯的第一个管理错误，就是把所有问题都揽在自己身上。结果前三天群里看起来很热闹，真正落实到人的任务几乎没有。

后来我把每一项问题都写成明确任务：

谁负责、改什么、什么时候完成、拿什么证明完成。

进度才真正动起来• • •

坑一：资产清单看着很全，实际漏了一大片

测评整改的第一步是确认保护对象和资产范围。

我们原来有一份资产表，打开一看，服务器名称、IP地址、操作系统、负责人都有，我还以为基础不错。

结果拿防火墙策略、虚拟化平台、云平台和监控系统的数据一对，问题马上出来了：

• 资产表里有已经下线半年的服务器；
• 监控平台里有资产表没有的IP；
• 同一个系统存在两个不同版本的资产清单；
• 有几台测试服务器直接暴露在办公网；
• 两台数据库服务器写着“负责人待确认”；
• 一台临时搭建的文件服务器已经稳定运行了三年。

最麻烦的是，一些所谓的“临时系统”没人敢下线，也没人愿意认领。

我最后从多个来源交叉盘点：

# 查看当前主机IP和监听端口
ip addr
ss -lntup

# 查看系统版本
cat /etc/os-release
uname -r

# 查看运行中的服务
systemctl list-units --type=service --state=running

# 查看最近登录记录
last -a | head -30

# 查看计划任务
crontab -l
ls -al /etc/cron.d/

网络侧再导出防火墙对象、交换机ARP表、负载均衡后端和云平台实例列表，统一去重。

最后原资产表里只有46台服务器，实际确认需要纳入管理的有61台。

整整漏了15台。

教训：资产清单不能靠人工记忆维护。至少要拿虚拟化平台、云平台、监控系统、防火墙和终端安全平台的数据做一次交叉验证。连资产都说不清，后面的访问控制、日志审计和漏洞管理全是空中楼阁。

坑二：系统边界画得很漂亮，实际流量根本不按图走

整改材料里有一张网络拓扑图，画得非常标准：

互联网区、DMZ区、应用区、数据库区、管理区，不同区域之间都有防火墙。

但我拿着图去机房核对时发现，实际网络和图上完全不是一回事。

有些服务器虽然名字叫“应用区服务器”，实际和数据库在同一个网段；有些管理流量没有经过管理区，而是从办公电脑直接访问生产服务器；还有一个历史遗留系统，为了方便接口调用，在防火墙上开了一个范围很大的双向策略。

图上的网络分区属于“逻辑上存在，流量上不存在”。

我们先通过防火墙日志和交换机配置确认实际访问关系，再重新梳理：

调整时没有一次性改完，而是先开启日志观察，再收紧策略。

因为有些访问关系没有文档，直接阻断很可能把业务一起干掉。

教训：拓扑图不是美术作品。图上每一条访问路径，都应该能在防火墙策略、路由配置和实际流量里找到对应关系。只改图不改网络，测评时迟早露馅。

坑三：防火墙规则不敢删，最后只能一条条认领

我们边界防火墙上有两千多条策略。

其中不少策略的备注是：

临时开放
测试使用
业务需要
某某项目
先放通

但没有申请人，没有到期时间，也没有具体用途。

最夸张的一条规则，是办公网到生产区多个服务器开放全部TCP端口。问了一圈，没人知道是谁开的，也没人敢直接删。

因为所有人都担心：

“万一删了业务出问题怎么办？”

我最后采用了一个比较笨但安全的方法：

• 导出全部策略；
• 按源地址、目标地址、端口和命中次数分类；
• 找业务部门逐条认领；
• 对长期无命中的规则先禁用，不立即删除；
• 观察一周无异常后再清理；
• 给保留策略补充申请人、业务用途和有效期。

整改后的规则原则很简单：

源地址明确
目标地址明确
端口范围最小
业务用途明确
责任人员明确
临时策略设置到期时间

教训：防火墙不是规则越多越安全。大量没人负责、没人解释、没人清理的策略，本身就是风险。所有“临时开放”如果没有到期机制，最后都会变成永久开放。

坑四：密码策略一改，三个业务系统同时出故障

身份鉴别是整改重点之一。

我们检查后发现，部分服务器存在弱口令、长期不改密码、多人共用管理员账号等问题。于是按整改计划统一调整了密码复杂度和有效期。

Linux服务器配置大致如下：

# 查看密码有效期策略
cat /etc/login.defs | grep PASS_

# 查看指定账号密码策略
chage -l username

# 设置密码最长使用时间
chage -M 90 username

# 设置密码到期前提醒
chage -W 7 username

策略改完第二天，监控开始连续告警。

三个业务系统无法连接数据库。

排查后发现，这些系统使用的数据库账号也被纳入了密码到期策略。密码到期后，应用没有交互式修改密码的能力，连接直接失败。

更麻烦的是，有一个账号写在应用配置文件里，另一个写在启动脚本里，还有一个藏在定时任务中。

最后只能先恢复业务，再重新区分人员账号和服务账号：

• 人员账号执行密码复杂度、有效期和登录失败处理策略；
• 服务账号禁止交互式登录；
• 服务账号权限最小化；
• 密码变更前先排查所有调用关系；
• 条件允许时改用密钥、凭据管理平台或动态凭据。

教训：密码策略不能一刀切。人员账号、应用账号、数据库账号和设备接口账号的使用方式完全不同。直接批量改策略，最先被整改掉的可能不是风险，而是业务。

坑五：管理员账号名义上独立，实际上密码都一样

我们的服务器已经给不同运维人员建立了独立账号，看起来符合要求。

但实际检查时发现：

虽然用户名不同，密码却是统一设置的。

更离谱的是，有人登录自己的普通账号后，直接执行：

sudo su -

进入root环境，后续所有操作记录里只剩下root，根本无法区分是谁做的。

我们重新调整了权限：

# 检查具有登录Shell的用户
awk -F: '$7 !~ /(nologin|false)$/ {print $1,$3,$7}' /etc/passwd

# 检查sudo权限
grep -R "ALL=" /etc/sudoers /etc/sudoers.d/

# 检查UID为0的账号
awk -F: '$3==0 {print $1}' /etc/passwd

# 查看近期sudo记录
journalctl _COMM=sudo --since "7 days ago"

随后按岗位拆分权限，不再给普通运维人员完整root权限：

Web运维：管理Nginx和应用服务
数据库管理员：管理数据库相关服务
系统管理员：管理系统和补丁
安全管理员：查看审计和安全告警

教训：独立用户名不等于独立身份。如果大家使用相同密码、共享密钥或者进入root后再操作，账号看起来分开了，责任仍然无法追溯。

坑六：堡垒机已经买了，但所有人都在绕过它

公司两年前就采购了堡垒机。

我原以为这一项应该最好整改，结果登录堡垒机一看，最近一个月只有几条操作记录。

再去查服务器日志，管理员仍然从办公电脑直接SSH连接生产服务器。

原因也很现实：

• 堡垒机资产没有及时同步；
• 部分账号登录失败；
• 文件传输不方便；
• 运维人员觉得多跳一次麻烦；
• 网络上仍然允许绕过堡垒机直连。

这就是典型的“设备上线了，管理没上线”。

我们先补全资产和账号，再调整网络策略，只允许堡垒机和指定自动化平台访问服务器管理端口。

同时保留应急通道，但应急账号由专人保管，使用后必须修改密码并提交记录。

教训：只部署堡垒机，不限制绕行路径，等于在正门装了门禁，却把后门一直开着。安全产品能不能发挥作用，关键不在于有没有，而在于能不能被强制使用。

坑七：日志接了几十台设备，真正出问题时却查不到

我们的日志平台上已经接入了防火墙、服务器、数据库和部分安全设备。

界面看起来很热闹，每秒都有日志进来。

但抽查一个管理员登录事件时，问题出现了：

知道谁登录，但不知道操作了什么；

知道某个IP被拦截，但不知道对应哪台资产；

服务器时间和防火墙时间差了几分钟；

部分日志只有设备名，没有资产负责人；

日志保存了，但没有配置有效的关联分析和告警规则。

日志“接进来”只是第一步。

我们重新检查了几个关键点：

# 检查时间同步
timedatectl
chronyc tracking
chronyc sources -v

# 检查SSH登录日志
journalctl -u sshd
grep -E "Accepted|Failed" /var/log/secure

# 检查审计服务
systemctl status auditd
auditctl -s

# 检查远程日志配置
grep -R "@" /etc/rsyslog.conf /etc/rsyslog.d/

然后给资产补充统一标识，把用户名、源IP、目标资产、事件时间和操作结果关联起来。

重点告警规则也重新梳理：

• 管理员异常时间登录；
• 同一账号多地登录；
• 连续登录失败；
• 新增高权限账号；
• 审计服务停止；
• 日志源长时间中断；
• 防火墙策略异常变更；
• 关键文件被修改。

教训：日志平台不是把日志接进来就结束了。日志能不能查、能不能关联、能不能告警、出了事能不能定位到人，才是它真正的价值。

坑八：漏洞扫描报告每月都有，漏洞数量却越来越多

公司每个月都会做漏洞扫描，报告按时生成，也会发送给各部门。

但整改时一看，高危漏洞有不少已经存在了半年。

问题不是没扫描，而是没人负责闭环。

原来的流程是：

报告发出去就算完成任务，至于修没修、为什么没修、什么时候修，没有人继续跟踪。

我们重新建立了漏洞台账：

对于不能立即修复的问题，不再简单写“业务原因暂不整改”，而是要求给出临时措施，例如：

• 限制访问源；
• 关闭不必要端口；
• 增加WAF或IPS规则；
• 下线高风险组件；
• 加强日志监控；
• 制定明确升级时间。

教训：扫描工具只能发现问题，不能替你解决问题。没有责任人、完成时间和复测结果的漏洞报告，最后只会变成一份越来越厚的风险清单。

坑九：系统补丁装上了，业务却启动不起来了

为了处理高危漏洞，我们安排了一批服务器统一升级补丁。

测试环境验证时没有问题，上生产后却有一个老Java应用启动失败。

日志里报的是加密算法和证书兼容问题。

原因是系统组件升级后，默认禁用了部分老旧算法，而这个应用连接的外部接口还在使用旧协议。

补丁本身没有错，错的是我们只验证了“系统能不能启动”，没有验证“业务全链路能不能工作”。

后来我们把补丁流程改成：

• 确认漏洞影响范围；
• 备份配置和关键数据；
• 在同版本测试环境验证；
• 执行系统和应用兼容性测试；
• 制定回退方案；
• 在变更窗口实施；
• 验证应用、接口、定时任务和监控；
• 重新扫描确认漏洞关闭。

教训：补丁管理不是执行一条更新命令。操作系统、中间件、数据库和应用之间存在依赖，补丁装成功不代表整改成功，业务验证通过才算。

坑十：安全基线照着模板改，差点把SSH彻底封死

整改过程中，我们需要对Linux服务器进行安全基线加固。

其中包括：

• 禁止root远程登录；
• 禁止空密码；
• 调整登录失败锁定策略；
• 设置会话超时；
• 限制高风险服务；
• 设置文件权限；
• 开启安全审计。

这些要求本身没有问题，但执行时不能照着模板批量复制。

有一次我们同时修改了SSH访问、账号锁定和sudo配置。配置重载后，新会话无法登录，而原来的会话又因为超时断开，差点只能进机房处理。

从那以后，所有远程访问相关配置都采用以下步骤：

# 修改前备份
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

# 检查SSH配置语法
sshd -t

# 不关闭当前会话，另开窗口测试新登录
systemctl reload sshd

# 确认普通账号可以登录并正常sudo
sudo -l

批量加固也不再直接全量执行，而是先选一台低风险服务器试点。

教训：安全加固不是配置越严越好，而是在业务可用的前提下把风险降到合理范围。任何涉及远程登录、账号锁定和网络访问的调整，都必须保留验证和回退通道。

坑十一：备份任务每天都显示成功，但一次也恢复不出来

测评报告里有一项是备份和恢复。

运维同事很有信心地说：

“我们每天都备份，任务从来没失败过。”

我随机抽了一份数据库备份做恢复测试，结果恢复失败。

继续检查，又发现几个问题：

• 备份文件大小异常；
• 备份账号权限不足，部分表没有导出；
• 备份文件和生产数据放在同一个存储；
• 没有异地副本；
• 备份文件没有加密；
• 没有人做过完整恢复演练；
• 业务不知道恢复需要多长时间。

原来所谓的“备份成功”，只是脚本执行返回了0。

我们重新调整了备份策略：

并且不再只检查任务状态，而是验证：

• 文件是否真实生成；
• 文件大小是否合理；
• 备份内容是否完整；
• 是否可以解压或读取；
• 是否能够在隔离环境恢复；
• 恢复后业务数据是否可用。

教训：没有经过恢复验证的备份，只能叫“可能存在的数据副本”。真正可靠的不是备份任务成功，而是发生故障后能在规定时间内把业务恢复出来。

坑十二：制度文件写得很完整，现场人员却完全不知道

技术问题处理得差不多后，我们开始整理管理制度。

账号管理制度、漏洞管理制度、日志管理制度、备份管理制度、应急响应制度，一份不少。

测评老师现场问运维人员：

“高权限账号怎么申请？”

对方回答：

“在群里跟领导说一下。”

又问：

“发生安全事件后向谁报告？”

对方想了半天：

“应该先找我们主管吧。”

这时候我才意识到，制度虽然写了，但根本没有进入实际工作。

我们后来没有继续堆文件，而是把关键流程做成真正能执行的表单和记录：

制度里写“定期检查”，就必须能拿出检查记录。

制度里写“经过审批”，就必须能拿出审批证据。

制度里写“开展演练”，就必须有时间、人员、过程、问题和改进结果。

教训：等保管理要求最怕制度和实际操作两张皮。制度不是写给测评老师看的，而是要让每个相关人员知道什么时候做、由谁做、做完留下什么记录。

03）整改完成后，我用了三轮检查

第一个月最后一周，我们没有继续增加新的整改项，而是开始做内部复查。

第一轮：技术人员自查

各责任人按照整改台账逐项确认，提交配置截图、日志记录、扫描结果和测试结论。

第二轮：交叉检查

网络人员检查服务器整改结果，运维人员检查网络访问路径，安全人员检查账号、日志和漏洞闭环。

交叉检查能发现很多“自己看不出来”的问题。

第三轮：模拟测评

找一个没有参与整改的同事，按照测评思路随机提问和抽查。

不提前通知检查哪台服务器，不提前指定检查哪个账号，也不提前准备某一份记录。

结果又发现了几个遗漏：

• 一台备用服务器没有接入日志平台；
• 一个离职人员账号还在数据库里；
• 两条临时防火墙策略没有设置到期时间；
• 一份应急预案里的联系人已经离职；
• 一台设备时间同步异常。

如果没有这轮模拟检查，这些问题很可能直接留到正式测评现场。

04）等保三级整改检查清单

每个系统情况不同，但下面这份清单可以作为整改复查时的基础版本。

资产与边界

• 资产清单与实际环境一致
• 服务器、网络设备、安全设备和应用责任人明确
• 系统边界和网络拓扑准确
• 互联网暴露资产已经确认
• 测试环境和生产环境合理隔离
• 管理流量通过受控管理区访问

网络与访问控制

• 防火墙策略遵循最小开放原则
• 不存在无业务依据的全端口开放
• 临时策略具有负责人和到期时间
• 管理端口禁止互联网直接访问
• 高权限操作通过堡垒机或受控平台执行
• 应急访问通道有审批和使用记录

主机与账号

• 不存在默认账号、无用账号和异常高权限账号
• 人员账号独立使用，不共享密码
• 离职和转岗人员权限已及时处理
• 密码策略符合要求并完成业务兼容验证
• root或管理员直接远程登录受到限制
• sudo权限按照岗位最小化分配
• SSH、审计和系统关键配置已完成检查

日志与审计

• 关键服务器和设备已接入日志平台
• 各系统时间同步正常
• 登录、操作、策略变更和安全事件可以追溯
• 日志保存周期符合项目要求
• 日志中断能够告警
• 关键安全事件已配置检测规则
• 管理员操作能够关联到具体人员

漏洞与恶意代码防范

• 漏洞扫描覆盖全部资产
• 高危漏洞具有负责人和整改计划
• 已整改漏洞完成复测
• 暂不能整改的问题具有缓解措施和审批记录
• 操作系统和中间件补丁经过兼容性测试
• 终端防护或恶意代码防范措施运行正常
• 病毒库、规则库和检测引擎保持更新

数据与备份

• 关键数据已识别和分类
• 备份任务执行状态正常
• 备份内容完整且可以读取
• 关键备份与生产环境隔离
• 敏感备份采取访问控制和加密措施
• 已进行真实恢复测试
• 恢复时间和恢复结果有记录

管理与制度

• 安全责任人和岗位职责明确
• 账号申请、变更和注销流程可以执行
• 变更操作有申请、审批、实施和验证记录
• 漏洞管理形成发现、整改、复测闭环
• 应急预案中的人员和联系方式有效
• 已开展安全培训和应急演练
• 制度内容与实际操作一致
• 各类安全记录能够现场调取

05）一个月整改后的12条避坑经验

1. 先确定资产和系统边界，再谈整改。资产不清，所有安全措施都会漏。
2. 拿到报告后先拆责任，不要先买设备。很多问题靠流程和配置就能解决。
3. 网络拓扑必须和实际流量一致。图画得再标准，也代替不了真实隔离。
4. 防火墙策略要有人认领。没人说得清用途的策略，迟早会成为风险。
5. 密码策略不能直接批量下发。先区分人员账号和服务账号，再评估业务影响。
6. 独立账号必须配合独立凭据和操作审计。只分用户名、不分密码，没有实际意义。
7. 堡垒机必须配合网络限制。允许绕过，就一定会有人绕过。
8. 日志接入不等于日志可用。能查询、能关联、能告警、能追溯才算完成。
9. 漏洞管理必须形成闭环。报告发出去不是终点，复测通过才是。
10. 安全基线不要照模板无脑执行。先试点、再推广，每一步都要保留回退方案。
11. 备份一定要做恢复测试。恢复不了的备份，数量再多也没用。
12. 制度必须落实成流程和记录。文件写得再完整，现场执行不了还是零分。

• • •

一个月下来，差距分析报告上的问题基本完成整改，我也连续加了将近一个月的班。

回头看，等保三级整改真正困难的并不是某条安全命令不会执行，也不是某台设备不会配置，而是要把技术、管理、人员和流程真正串起来。

资产清单写着一套，实际环境是另一套；

制度文件要求走审批，实际工作还是在微信群里说一声；

堡垒机已经上线，管理员仍然直接登录服务器；

日志每天产生几百万条，真正发生问题时却定位不到责任人。

这些长期被忽略的小问题，才是整改过程中最耗时间的地方。

等保测评也不是拿到一份报告或者通过一次检查就结束了。真正有价值的整改，是测评结束以后，账号审批还在执行，漏洞仍然有人跟踪，防火墙临时策略到期后会被清理，备份依然按计划进行恢复测试。

否则今年整改掉的问题，明年还会原样回来。

希望这篇文章能帮到正在做或者准备做等保三级整改的安全和运维同行。

正在整改的朋友也可以在留言区说说，你们遇到过最难处理的问题是什么？