等保评测常用的安全设备，说句实在话，这几年我见过太多单位在这上面花冤枉钱：机房角落里堆着没拆封的设备，采购清单写得满满当当，测评现场一核对，该配的策略没配、该留的日志没留、该开的审计没开，照样扣分。这篇东西不打算给你念产品手册，而是按我实际跟过的项目，把等保评测里那些真正会被点名核对的常用安全设备，从选型、摆放位置、参数计算到上架配置、测评现场被问到的问题，一条线捋清楚。适合正在做等保整改的技术负责人、刚接手运维的工程师，也适合预算有限、想用最少设备把关键项补齐的中小单位。看完你至少能自己拉出一份清单，知道每台设备为什么买、买多大规格、放在哪一跳、上线以后要开哪些功能。

1. 先想清楚测评现场到底在核对什么

1.1 设备清单只是入场券，核对的是功能有没有真开

很多人对等保评测有个误会，以为买齐了设备就算完成整改。实际测评的时候，测评老师坐下来第一件事不是数你有几台机器，而是让你登录设备，看功能模块开没开、策略配没配、日志有没有数据。我印象最深的一次，某单位的入侵防御设备采购合同、验收报告全都齐全，结果登进去一看，特征库停在两年前，策略是出厂默认的“全部放行”，测评老师在核查表上直接写了不通过。

这个逻辑其实很好理解：等级保护评的是“能力”，不是“资产”。设备是能力的载体，但载体不等于能力本身。一台开启了策略、定期升级特征库、日志正常上报的防火墙，价值远高于三台摆着不用的高配机器。所以我在做整改方案的时候，通常先画一张能力对照表，把需要覆盖的检测能力、防护能力、审计能力、备份恢复能力列出来，再去匹配设备，而不是反过来先定设备再想它能干什么。

具体到核对动作，测评现场常见的操作有这么几类：登录管理界面截取功能开启状态、导出最近一段时间的日志样本、查看策略列表、验证双因子登录、抽查某台主机的补丁基线、核对备份任务的执行记录。这些动作意味着，设备必须真正接入业务流并且持续运行一段时间，日志才有东西可导。临时抱佛脚装一台设备，日志是空的，反而更扎眼。

注意：整改期新上的设备，日志至少要有连续一个月以上的记录，测评时导出的样本才有说服力。上架时间和测评时间之间要留出余量。

1.2 为什么“堆设备”反而容易丢分

设备越多，攻击面越大，配置越难统一，这是常识。但在等保整改里，堆设备还有一个更隐蔽的问题：它会稀释你的管理精力，导致每台设备都停留在半成品状态。我见过一个机房，边界上串了防火墙、入侵防御、防毒墙、上网行为管理四台设备，结果整个出口的实际吞吐掉到标称值的四分之一，业务部门天天投诉慢，运维为了保业务，把其中三台的策略全改成放行，只剩防火墙在做最基础的地址转换。

这种局面在测评时是双输：性能问题归到“设备可用性”上，策略放行归到“防护有效性”上，两头都不好看。我的建议是，先按业务的实际规模和安全级别确定最小可用集合，把这套集合里的设备配到位、跑稳定，再考虑横向扩展。

做取舍的时候可以问自己三个问题：这台设备拦的是什么风险，这个风险在我的业务场景里发生概率有多高，如果它不存在，我用现有设备的某个模块能不能替代。比如很多边界防火墙本身带有入侵防御和应用识别模块，中小规模的场景下，授权开满就够用，不必单独再串一台入侵防御。反过来，运维审计、日志留存这类东西，防火墙替代不了，该单独上就得单独上。

1.3 预算怎么分：优先保审计和边界

预算永远不够，这是常态。如果只能分两批采购，我会把第一批的钱压在两个地方：网络边界和运维审计。原因很直接，这两块是测评里核查密度最高、也最容易拿出证据的部分。

边界设备的价值在于它是所有流量的必经之路，一台配置得当的防火墙加上访问控制策略，能同时覆盖网络访问控制、边界防护、入侵防范等多个核查点，投入产出比最高。运维审计则是另一个逻辑：它记录的是“人”的操作，测评里关于身份鉴别、访问控制、安全审计的很多项，都要靠它出证据。而且这类设备对业务侵入性小，旁路部署，上线风险低，落地周期短。

相对可以往后放的，是那些需要长期运营才见效的东西，比如态势感知平台、全流量回溯分析。这类系统价值确实高，但它们依赖数据积累和分析人员，如果单位本身没有安全运营团队，买回来就是一个大屏，测评时也很难拿它作为某项要求的直接证据。先把基础设备配齐跑顺，等有了运营能力再上，顺序不会错。

2. 网络边界层：防火墙、入侵防御与流量清洗

2.1 下一代防火墙的规格怎么算才不浪费

防火墙是清单里的常客，也是最容易买错规格的设备。销售报价单上通常给三个数：网络层吞吐、应用层吞吐、并发连接数。很多人只看第一个，结果买回来一开应用识别和入侵防御，性能直接腰斩。

我一般按这个顺序算：先确认互联网出口的实际带宽，比如一条 200Mbps 的专线；然后看内部东西向流量需不需要过防火墙，如果需要，把这部分估算进去；最后按“应用层吞吐 ≥ 出口带宽 × 1.5”来定规格。为什么要 1.5 倍余量？因为安全设备开启深度检测后，小包转发效率会明显下降，而且业务流量有峰谷，采购时按峰值算比较稳妥。200Mbps 出口，选应用层吞吐 300Mbps 以上的型号，基本不会成为瓶颈。

并发连接数按在线终端数估：假设内网 500 台终端，每台平均维持 200 个并发连接，就是 10 万，再乘 2 到 3 的余量，20 万到 30 万的并发规格足够。新建连接速率这个参数容易被忽略，但它决定了短时间内大量终端同时发起请求时会不会丢包，办公场景下建议不低于每秒 2 万。

真正决定这台设备好不好用的，其实是策略规划。上架前先在纸上把安全域划出来：互联网区、DMZ 区、办公区、服务器区、运维管理区，然后明确域间允许的访问关系和白名单。策略写的时候遵循最小化原则，一条一条按业务需求开，别图省事写 any-any。我见过太多单位的防火墙策略几百条，前十条全是全通，后面几百条形同虚设。

提示：策略上线前一定要开日志并观察一周，把命中数为零的策略挑出来复核，很多是历史遗留的临时放行，可以清掉，策略精简后设备的转发效率也会提升。

2.2 入侵防御和流量探针该摆在哪一跳

入侵防御这类设备的核心价值是“能看见东西向流量”。很多单位把它串在互联网出口，只能防外部攻击，内部横向移动完全看不见，这在测评里是比较吃亏的。我的常规做法是：互联网出口串一台做边界防护，核心交换机上做流量镜像接一台旁路设备做内部检测，两者分工明确。

旁路部署的好处是不影响业务链路，坏处是只能告警不能阻断。对于内部检测这个场景，告警其实够用了，因为内部流量的处置更多依赖人工研判和主机侧响应，硬阻断反而容易误伤业务。串接部署则要考虑 bypass 能力，设备掉电或者进程挂掉的时候能不能自动直通，这个功能在选型时要明确写进技术参数里。我经历过一次串接设备升级，固件刷到一半卡死，整个出口断了四十分钟，从那以后凡是串接的设备，我都要求支持硬件 bypass。

特征库授权年限是另一个容易踩的点。设备本身是一次性采购，但特征库是订阅制，很多单位买设备时只带一年授权，第二年到期没人续，特征库就停了。测评的时候看到特征库版本是两年前的，这一项很难圆过去。采购时我一般直接谈到三年授权，跟设备的生命周期对齐，省得后面走续费流程。

2.3 抗DDoS：本地清洗还是云侧牵引

抗 DDoS 这件事要看业务暴露面。如果对外只开了一个官网和几个 API 接口，带宽也不大，本地买一台清洗设备其实是浪费，多数时候云侧的清洗服务更划算，按攻击流量计费，平时不占成本。真正需要本地设备的，是那些对外服务带宽大、或者有专线接入、对时延敏感的场景。

如果决定上本地清洗设备，要确认两个参数：清洗能力和回注方式。清洗能力按对外带宽的 3 到 5 倍估，比如对外 100Mbps，选 500Mbps 清洗能力的设备，应付常见的小规模流量攻击够用。回注方式上，清洗后干净的流量怎么回给源站，主流有策略路由回注和 GRE 回注，前者配置简单但依赖路由设备配合，后者灵活度高但会增加封装开销，选型时让厂商把拓扑图画清楚，别等上线了才发现和现有网络架构冲突。

顺带说一句，流量清洗这类设备在测评里更多是作为“入侵防范”的加分项，不是必查项。如果预算紧张，优先级可以往后放，把出口防火墙的访问控制策略和异常流量告警做扎实，同样能覆盖大部分核查要求。

3. 运维审计与日志：最容易被忽略却最好拿分

3.1 堡垒机的核心不是录像，是账号纳管

运维审计系统，也就是大家常说的堡垒机，是等保整改里性价比极高的设备。它解决的是一个很实际的问题：服务器的 root 密码到底有几个人知道，谁在什么时候登录过，改了什么配置。测评时关于身份鉴别、访问控制、安全审计的一大堆核查点，都能从它这里出证据。

但很多单位买了堡垒机之后只用了三分之一的功能，把运维人员的登录入口切过去，录像功能开着，就完事了。真正能拿分的部分是账号纳管和密码托管：把所有服务器的本地账号统一托管到堡垒机，运维人员不再持有服务器密码，登录时由堡垒机代填；定期自动改密，改密记录留痕；高危命令设置拦截或二次审批。

配置顺序上，我建议先做资产纳管，把服务器、网络设备、数据库的 IP 和账号清单导进去，然后按人员角色划分访问权限，最后再开命令审计和录像。为什么先做资产？因为资产清单不准，后面的权限划分全是空中楼阁。我见过资产列表里混进了一堆已经下线的机器，还有一些重复录入的，登录上去全是连接失败，审计日志里全是噪音。

协议支持也要提前确认。除了常规的 SSH、RDP，很多单位还有通过串口登录的网络设备、通过特定客户端登录的数据库，这些协议堡垒机支不支持，支不支持字符命令解析，直接决定了审计的完整度。图形协议的录像很占存储，一台机器一天录十小时，一个月下来就是几十个 G，容量规划时要算进去。

注意：双人复核（也就是高危操作需要第二个人审批）这个功能，很多单位嫌麻烦不开。但从测评角度看，这是一个很直接的“访问控制”证据，建议至少对删库、改配置这类操作开启。

3.2 日志留存容量：把账算清楚再下单

日志审计系统是另一台必备设备，也是最容易在容量上翻车的地方。核查要求日志留存不少于六个月，很多单位买设备时只按“能存多少天”粗略估算，上线三个月就满了，只能覆盖旧日志，测评时导出的时间范围不够。

算容量其实不难，我一般按这个思路：先统计需要接日志的设备数量，比如 200 台服务器加网络设备；再估算每台的日均日志量，服务器按 100MB 到 300MB 算，网络设备按 50MB 算；乘起来得到日均总量。假设 200 台设备日均 200MB，就是 40GB 每天。六个月按 180 天算，原始日志 7.2TB。这里还没完，日志入库要建索引，索引本身占的空间通常是原始数据的 30% 到 50%，加上去大概 10TB。再留 20% 的余量应对突发日志量，最终配 12TB 以上的裸容量比较稳妥。

裸容量和可用容量还要区分开。做 RAID 之后可用容量会打折，RAID5 大概能用到 75%，RAID10 只有 50%。所以如果需要的可用空间是 12TB，RAID5 配置下至少得配 16TB 的物理磁盘。

采集方式也要提前想好。syslog 是最通用的，但网络设备发 syslog 不保证送达，UDP 丢包很常见；Windows 事件日志一般走 agent 采集；数据库审计日志有的走 API 拉取。混合采集的情况下，设备的 EPS（每秒事件数）指标要按峰值估，我通常按平均值的 3 倍来配，避免业务高峰时日志被丢弃。

3.3 数据库审计：旁路镜像的坑比想象中多

数据库审计设备一般旁路部署，从交换机镜像口拿流量。听起来简单，实操里问题不少。

第一个坑是镜像口配置。核心交换机的镜像口带宽如果和业务口不匹配，高峰时段会丢包，审计记录就不完整。我的做法是把数据库服务器的流量单独镜像到一个万兆口，而不是从汇聚口整体镜像，减少无关流量干扰。

第二个坑是加密流量。现在不少应用和数据库之间的连接是加密的，旁路拿到的流量解不开，审计设备只能看到连接元数据，看不到具体 SQL。遇到这种情况，要么在应用侧配置解密，要么改用 agent 方式采集。选型时一定要问清楚设备对加密协议的支持情况，别买回来发现只能看个连接数。

第三个坑是审计规则的配置。设备默认规则往往只记录登录和 DDL 操作，对敏感表的查询、大批量数据导出这些高风险行为不记录。上线后要结合业务梳理一遍敏感数据清单，把针对这些表的 select、导出、批量删除操作都加进审计策略，否则日志里全是无关的常规查询，真出事的时候翻不出来。

4. 应用与主机层：WAF、漏扫、终端

4.1 WAF的三种部署模式，选错等于白买

Web 应用防火墙在等保整改里的定位比较明确，但部署模式选错的情况很普遍。三种主流模式各有利弊：反向代理模式功能最全，能改包能做语义分析，但需要改 DNS 或者调整网络路径，上线有业务中断风险；透明桥模式串在链路中间，不改 IP，部署相对平滑，但性能受链路影响；旁路镜像模式只做检测告警，不能阻断。

我的选择逻辑是：对外提供服务的站点，优先反向代理，因为外部攻击面大，需要真实阻断能力；内部系统或者上线窗口很紧的场景，用透明桥过渡；旁路模式基本只用于自查和观察期，不作为长期方案。

上线反代模式最怕的是误拦截。我的经验是先跑一段观察模式，把所有规则设为告警不阻断，收集一到两周的误报情况，把业务正常请求里被误判的特征整理出来加白名单，然后再切换到阻断模式。切换的时候挑业务低峰期，并且准备好一键回切的方案，把 DNS 或者负载均衡的配置提前改好，出问题五分钟内能切回去。

规则库的更新策略也要定。WAF 的防护效果高度依赖规则库，但规则库更新太频繁也会引入新的误报。我一般设置成自动更新但延迟一周生效，让厂商先当小白鼠，社区里没大面积反馈误杀再跟进。

4.2 漏洞扫描：授权数和扫描窗口是两个硬约束

漏洞扫描系统在测评里主要对应“漏洞发现与修复”这条线。选型时最关键的不是扫描引擎多强，而是授权 IP 数够不够。很多单位买的时候按当前资产数量买，结果半年后新增了二十台虚拟机，授权不够，扫描任务跑不全，报告里缺了一大块。

我的建议是按现有资产数的 1.3 倍买授权，留出增长空间。如果预算实在紧张，可以分层：核心资产买全量授权，测试环境和办公终端用开源工具补充扫描，报告里注明扫描范围和方法，也能说得过去。

扫描窗口是另一个现实约束。全量扫描对业务有影响，尤其是带爬虫的 Web 扫描，会产生大量请求。我的常规做法是把扫描分三类排期：主机漏洞扫描放在周末凌晨，Web 扫描放在业务低峰期并限制并发，基线核查类的扫描（比如配置检查）可以随时跑，因为这类扫描对业务影响很小。

扫描报告出来之后的修复闭环，才是测评真正看的东西。测评老师会问：上次扫出来的高危漏洞修了没有，修复记录在哪。所以扫描系统要和工单或者变更管理打通，每个高危漏洞有对应的修复单号和验证记录。这一套流程跑通了，比买多贵的扫描器都有用。

4.3 终端安全：别只装个杀毒软件就交差

终端侧的要求这几年在收紧，光装个单机版杀毒软件已经很难覆盖核查点。现在更常见的做法是部署终端安全管理平台，统一做病毒防护、补丁管理、外设管控、违规软件发现。

落地的时候，补丁管理是最容易出成绩也最容易出问题的模块。出成绩是因为它直接对应“漏洞修复”的核查点，出问题是因为盲目推补丁会打挂业务系统。我的做法是先做资产盘点，把终端按业务重要性和系统版本分组，补丁先推测试组，观察三天，再分批推生产组，每批之间留两天观察窗口。遇到关键业务系统，补丁推送前先在测试环境验证，验证记录留档。

外设管控这块，很多单位一刀切全禁，结果业务部门怨声载道，最后偷偷装破解工具绕过管控。更务实的做法是按部门申请制，U 盘做注册制管理，只有注册过的加密 U 盘能用，使用记录留痕。这样既满足了管控要求，又不至于影响正常办公。

终端 agent 的资源占用也要关注。有些平台的功能模块全开后，CPU 和内存占用明显，老机器上会卡。上线前先在小范围试跑一周，看资源占用曲线，必要时把非核心模块关掉，只保留病毒防护和补丁管理。

5. 部署实操：从清单到拓扑的落地过程

5.1 一个典型三级系统的设备清单

拿一个中等规模的三级系统举例，大概是这么个配置：出口防火墙两台做双机热备，互联网区和 DMZ 区各一台；核心交换机旁路接一台入侵检测；Web 应用前面串一台 WAF；运维区部署一台堡垒机，纳管全部服务器和网络设备；日志审计一台，集中采集各类设备日志；数据库审计一台，镜像核心数据库流量；漏洞扫描一台，按季度做全量扫描；终端安全管理平台一套，覆盖办公终端和部分服务器。

这套清单不算豪华，但基本能把常见核查点覆盖住。设备数量控制在八台左右，运维压力可控。如果预算紧张，入侵检测可以先用防火墙自带的入侵防御模块顶替，等有余力再补；WAF 如果对外站点不多，可以先上云侧的防护服务。

清单确定之后，下一步是画拓扑。拓扑图上要标清楚每台设备的部署模式（串接还是旁路）、接口地址、镜像源、日志外发地址。这张图不只是给自己看的，测评时老师会要，运维交接时也要用，画得清楚能省很多沟通成本。

5.2 上架顺序和割接注意事项

设备上架有先后，我的习惯是先上旁路设备，再上串接设备。旁路设备不影响业务，先部署先采集数据，等日志攒起来了，再去动串接的部分。

串接设备的割接，一定要有回退方案。具体做法是：提前和网络组确认 bypass 状态正常，准备好回退用的配置备份，割接窗口选在业务低峰期，割接后盯半小时监控，看丢包率和时延有没有异常。有一次我在割接 WAF 的时候，忘了确认后端的健康检查地址，导致负载均衡一直判后端不可用，业务全挂，那次教训之后，我在割接检查清单里加了一条：所有健康检查路径必须人工验证一遍。

旁路设备的镜像配置也有讲究。镜像口要配置成只发不收，避免镜像流量回灌影响生产口；镜像源要精确到具体的业务口，不要图省事镜像整个 VLAN。日志外发走独立的管理网段，别和生产流量混在一起，否则高峰期日志会丢。

另外提醒一句，设备上架之后的管理地址规划要提前做。很多单位的安全设备管理口随手配个地址就上线了，后来发现和业务网段冲突，或者管理口暴露在互联网侧，只能再改，改一次就是一次割接。

6. 常见问题与排查实录

6.1 高频问题速查表

6.2 几条踩出来的经验

第一，任何串接设备上线前，必须确认 bypass 可用。别信说明书上写的“支持”，自己动手拔一次电，看业务断没断，这个动作花五分钟，能救一次事故。

第二，设备的管理账号不要用默认密码，也不要多人共用一个账号。这一点在测评里是硬性核查项，而且实现成本极低，一个账号一个人的成本远低于事后整改。

第三，日志时间同步。所有设备的 NTP 必须指向同一个源，否则日志时间戳乱掉，事后追溯根本对不上，审计的时候也没法证明日志的连续性。

第四，保留变更记录。设备策略改了、固件升了、授权续了，都记一笔，写清楚时间、操作人、原因。测评时问起来能对答如流，比临时翻记录强得多。

第五，别把整改当成一次性项目。设备买回来只是开始，策略要定期复核，特征库要定期升，日志要定期看，应急演练要真做。我在实际项目里见过太多单位，整改当年测评通过，第二年设备就没人管了，第三年再测，问题比第一年还多。

还有一个小技巧，建议给每台设备建一张“健康卡”，记录管理地址、账号保管人、授权到期日、特征库版本、最近一次策略复核时间、日志留存周期。这张卡贴在运维值班表旁边，谁值班谁看一眼，比任何管理制度都管用。设备数量一多，靠脑子记是记不住的，落到纸面或者工单系统里，才是真的可控。