安全设备最尴尬的状态，不是没买，是买了、通电了、在保、但策略是全通的。
我在一次评估里见过这样的现场：防火墙有 40 多条策略，第一条就是 any-any 全放通；WAF 部署成透明模式，只记录不拦截，一年的日志里存了 37 万次 SQL 注入尝试，一次都没拦；EDR 装了 80% 的终端，但高危策略组是空的；堡垒机上了，可运维习惯用跳板机直连，堡垒机上只有三个人在用。
这套设备清单看起来很漂亮，等保也能过，但实际防护能力接近于零。
这篇给一份体检清单：七类设备各查哪三件事、查到什么算合格、不合格怎么改。你可以拿着它一个下午把自家设备过一遍。检查项都是具体的，能落到界面上的某个位置或某条命令。
主机侧的基线核查不在这篇范围内，那个看 安全基线落不了地。
一、体检表：七类设备，每类三查
先看总表，后面逐类展开。
| 设备 | 查什么 | 合格标准 |
|---|---|---|
| 防火墙 | 有无 any-any 策略、策略命中率、规则数量 | 无全通策略；零命中规则 <10%；规则 <200 条 |
| WAF | 工作模式、拦截率、误拦率 | 拦截模式；拦截动作占比 >0；误拦 <0.1% |
| EDR | 覆盖率、策略组、隔离能力 | 服务器覆盖率 100%；策略组非空；能一键隔离 |
| IDS/IPS | 部署位置、告警量、规则更新 | 双向部署；日均有效告警 <100；规则周更 |
| 堡垒机 | 覆盖率、绕行检测、录屏留存 | 运维流量 100% 过堡垒机；无直连；留存 180 天 |
| 日志/SIEM | 采集源数量、保留期、可用性 | 覆盖关键系统；≥90 天；查询响应 <10 秒 |
| 全部 | 台账、固件版本、配置备份 | 有台账；固件无已知高危；有备份且可恢复 |
七类里最容易不合格的是防火墙（全通策略）和堡垒机（绕行），这两项也是最容易被攻击利用的。
二、防火墙策略：先看第一条是不是全通
防火墙的问题九成出在同一处：为了"先让业务通"，加了一条 any-any 放在最前面，然后就再也没动过。
原因很好理解——新系统上线，业务说"连不上"，运维图快加一条全通，业务通了，问题"解决"了。这条策略从此躺在第一条，后面新增的所有精细化策略都变成摆设。
查三件事：
第一，有没有全通策略。按顺序看策略列表的前 10 条，找源/目的为 any、服务为 any 的。有的话，先别急着删，做一件事：把这条策略的命中日志导出来，看过去一周它实际放通了哪些流量。这些流量就是"真实需要"，按它们生成精确策略，然后再删全通。
这个顺序很重要。直接删全通，业务立刻中断；先看命中再生成策略，能做到不断服。
第二，零命中规则占比。很多防火墙有几百条规则，其中一半是历史遗留、早已无人使用。这些规则不产生风险，但会让人无法判断策略全貌，也让"临时开通"永远没人回收。
查法：看每条规则的命中计数（大部分防火墙在策略列表里就有这一列）。连续 90 天零命中的规则，标记为待清理，走变更流程删掉。
第三，规则数量与收敛度。超过 300 条规则的防火墙，基本已经没人能说清每条为什么存在。这时候应该做一次策略重构——按业务域分组、用地址簿代替散落的 IP、用策略组代替重复条目。重构的目标不是"规则少"，是"任何一条规则都能说出为什么"。
有个实用技巧：给策略加"申请单号"和"到期日"两个字段（多数防火墙的备注字段够用），到期自动提醒。这一条能让"临时开通"不再变成永久。
三、WAF：透明模式等于没装
WAF 部署成透明/旁路模式，只做日志，是甲方最普遍的自欺欺人。它满足了"我们有 WAF"这个合规要求，但对攻击零拦截。
为什么大家不敢开拦截模式？因为怕误拦业务。这个担心是合理的，但解法不是不拦，是分阶段：
| 阶段 | 时长 | 动作 | 判断标准 |
|---|---|---|---|
| 观察 | 2 周 | 只记录，统计将被拦截的请求 | 逐条看被拦的请求，标记误报 |
| 灰度 | 2~4 周 | 只对非核心业务开拦截 | 业务无投诉，误拦率 <0.1% |
| 全量 | 持续 | 核心业务也开拦截 | 保留一键回滚开关 |
关键是"一键回滚"这个能力必须先验证可用。如果开了拦截发现业务挂了、却不知道怎么快速关掉，那谁也不敢开。开之前先演练一次：模拟误拦、走一遍回滚流程、记录耗时。
误报治理的三个动作（和 DevSecOps 里的思路一样）：一是把常见业务的正常请求加白名单（比如后台富文本编辑器的提交）；二是关掉不适用的规则集（很多 WAF 默认开了几千条规则，其中大半和你的业务无关）；三是定期看"拦截 Top 规则"，如果某条规则拦的全是误报，直接关掉。
还有一件事常被忽略：WAF 要放在所有入口前面。有企业主站走 WAF，但新上的小程序 API 直连后端，绕过了 WAF——攻击者只需要找到这个入口。
四、EDR：不是装了就行
EDR 的价值全在策略和响应能力上。装了就完事的 EDR，和一个杀毒软件没区别。
查三件事：
第一，服务器覆盖率。很多企业 EDR 只覆盖了办公终端，服务器一台没装——而服务器才是攻击者的目标。查法：拿资产台账里的服务器清单，和 EDR 控制台的在线终端列表做差集。
差集里的机器分两种：一种是装不上（老系统、不支持的操作系统），这类要用其他手段兜底（主机防火墙 + 日志采集）；另一种是没人管的机器——这才是最危险的，因为它既没有检测也没有人维护。
第二，策略组是不是空的。打开策略管理，看有没有启用了实际规则。见过不少现场是"策略组已创建，但里面一条规则都没启用"，因为实施时只做了安装，没做策略配置。
至少要启用这几类：可疑进程启动、凭据窃取行为、横向移动工具、勒索行为特征、异常外联。这些是默认规则集里就有的，启用即可，不需要自己写。
第三，能不能一键隔离。这个能力决定了出事时的处置速度。测试方法：找一台测试机，从控制台点隔离，看是否在 30 秒内断开网络且不影响管理通道。做不到的话，出事时你只能跑机房拔网线。
五、IDS/IPS：从告警洪水到有效告警
IDS 的典型状态是"开着，但没人看"。因为日均几十万条告警，看了也没用。
治理思路是先降噪，再谈检测。三步：
第一步，关掉不适用于你的规则集。默认规则集里有大量针对老旧系统（Windows 2003、IIS 6）的攻击特征，你的环境里没有这些系统，这些规则只会产生噪音。
第二步，把告警按"是否成功"分级。大部分 IPS 能区分"检测到攻击尝试"和"攻击成功"，前者数量大但价值低，后者才是要立刻处理的。
第三步，只为高价值目标保留全量检测。核心业务区全开，办公区只保留高危类别。
做完这三步，日均有效告警通常能从几万降到几十。这个量级才可能有人真的去看。
六、堡垒机：查绕行比查功能重要
堡垒机的价值只有一个：所有运维操作都经过它，并留下记录。所以核心指标不是"功能有多少"，是"覆盖率"和"有没有绕行"。
查绕行的方法：从网络侧看，运维网段到服务器网段的流量，是不是只允许到堡垒机。如果运维人员能直接从自己电脑 SSH 到服务器，堡垒机就形同虚设。
具体检查：
# 从一台运维终端上试：直接连服务器应该不通，连堡垒机应该通 ssh -o ConnectTimeout=3 user@10.20.1.31 # 目标服务器，应超时/拒绝 ssh -o ConnectTimeout=3 user@10.10.5.20 # 堡垒机，应能登录 # 在服务器侧看：当前登录来源是不是只有堡垒机 IP who | awk '{print $5}' | tr -d '()' | sort -u # 或 ss -tn state established '( sport = :22 )' | awk '{print $5}'如果服务器的 SSH 来源里出现了运维人员的办公 IP，就是绕行。解决办法是网络层收敛：运维网段到服务器网段只放通堡垒机 IP。
这个改动会有阻力（"我这样操作快"），但它是堡垒机有没有意义的分界线。做之前先跟运维负责人对齐，别让安全团队单独去封。
另外两个检查项：录屏留存够不够（等保要求 6 个月，实际建议 180 天以上）、账号是不是一人一号（共享账号等于没有审计）。
七、日志与 SIEM：能查到才算有
日志这块的常见误区是"采了很多，但查不到想查的"。
三个检查项：
第一，关键系统的日志有没有进来。列一份"出事时一定要查的日志"清单，逐条核对是否已接入：认证日志（AD/VPN/堡垒机）、主机安全日志（EDR/auditd）、网络日志（防火墙/WAF/DNS）、应用日志（网关 access）、数据日志（数据库审计/对象存储）。缺哪一类，就是哪一类事件查不清。
第二，保留期够不够。90 天是底线。数据泄露类事件往往在两三个月后才被发现，日志只留 30 天等于没有。成本上用冷热分层：近 30 天热存储可查，30~180 天冷存储，超过 180 天归档。
第三，查询能不能在 10 秒内出结果。这一条很实际：如果查一次要等 5 分钟，没人会用，最后所有人还是去登服务器 grep。查询慢通常是索引设计问题，需要和实施方一起调。
8.1 变更流程：策略为什么会越加越乱
前面说的全通策略、零命中规则，都不是某个人失误造成的，是变更流程缺两个环节：申请时要写清"为什么"，下线时没人负责。
正常的变更单通常只写"源地址、目的地址、端口"，这三样足够开通，但不足以维护。要再加三列：
| 字段 | 用途 | 不加的后果 |
|---|---|---|
| 申请单号/工单链接 | 追溯这条策略为谁开的 | 半年后没人知道来源 |
| 到期日 | 临时策略到期自动提醒 | 临时变永久 |
| 对应业务 | 按业务域做策略分组 | 无法批量清理 |
有这三列，防火墙的策略列表就从"一堆规则"变成"一份可维护的清单"。清理时按"业务已下线"或"已到期"筛，一次能清掉几十条。
还有一个组织上的动作比流程更有效：每季度做一次策略评审，让运维和业务一起看。评审只问一个问题："这条策略现在还有业务在用吗？"没人能答上来的，就进待删清单。
这个会通常只要一小时，但它能把"策略堆积"这件事变成周期性动作，而不是等到出事才想起来。
八、设备台账与变更：安全设备运营的地基
上面七类查完，你会发现一个共同点：所有问题的根源都是"没人管"。而"没人管"的具体表现，是没有台账、没有变更记录、没有责任人。
设备台账的字段不多，但必须有这几列：
| 字段 | 为什么必须有 |
|---|---|
| 设备名与型号 | 判断固件漏洞的前提 |
| 管理 IP 与带外地址 | 出事时能连上去 |
| 固件/系统版本 | 对应已知漏洞 |
| 策略备份路径与最近备份时间 | 设备坏了能恢复 |
| 管理员账号（不含口令） | 知道谁能改 |
| 维保到期日 | 到期前要评估续费或替换 |
| 责任人 | 出问题找谁 |
配置备份这一项最容易被忽略，代价也最大。防火墙坏了要重建几百条策略，没有备份就是几天的事故。做法很简单：每周自动备份到内网文件服务器，保留最近 12 份，且每季度做一次"从备份恢复"的演练——没演练过的备份不算备份。
固件版本这一列，配合厂商的安全公告，能提前发现"我们有一台设备在受影响版本里"。这一步不需要工具，订阅厂商公告 + 每月核对一次就够。
九、安全设备运营的五个指标
设备运营要能证明有效，五个数就够，都不难算：
| 指标 | 算法 | 参考目标 |
|---|---|---|
| 策略收敛度 | 有效策略数 / 总策略数 | >90% |
| WAF 拦截率 | 拦截动作数 / 总命中数 | >0 且逐季上升 |
| 安全设备在线率 | 在线时长 / 应在线时长 | ≥99% |
| 日志覆盖率 | 已接入的关键系统 / 关键系统总数 | 100% |
| 平均处置时长 | 从告警产生到处置完成 | 高危 ≤30 分钟 |
第一个指标（策略收敛度）最能反映运营水平。它低说明规则在堆积没人清理；它接近 100% 说明有人在持续维护。
这五个数都不需要额外买工具，从设备控制台和现有台账就能算出来。建议每月出一张表，和上个月对比——趋势比绝对值重要，因为设备运营是长期活，一次达标不代表下个月还达标。
十、中小团队的精简版
三个人以下的团队，上面全做不现实。按优先级砍到四件事：
- 防火墙删全通策略（一周内能做完，风险最高）
- WAF 从透明转拦截（分阶段，两个月）
- 堡垒机堵绕行（一次网络变更）
- 每周备份设备配置（脚本自动化）
这四件做完，你的设备从"合规摆件"变成"真的在工作"。剩下的等有精力再补。
设备运营这件事没有终点，也不需要一次做完。关键是每年都比上一年少一条全通策略、少一台没人管的老设备。