简介：这份PDF文档面向需要开展网络安全等级保护三级建设与测评的企业IT负责人、安全运维人员及合规咨询从业者，系统梳理了三级等保落地过程中应配备的设备与服务清单，帮助读者对照标准快速厘清建设范围与合规要点。资源包内共1个PDF文件，约238KB，内容按物理安全、网络安全、主机安全、数据安全及安全服务五大模块展开，逐项列出电子门禁、防盗报警、视频监控、防雷接地、UPS、机房专用空调、防火墙、流量清洗、日志审计、堡垒机、数据库审计、网页防篡改、漏洞扫描、负载均衡、备份容灾等设备或措施，并标注部署位置、是否必须及可替代方案，同时涵盖制度完善、安全检查、安全培训与安全专家等配套服务。目前已有440人学习下载，适合作为等保三级项目立项、设备选型与整改自查的参考底稿，也可用于对照测评项查漏补缺。
1. 三级等保设备清单背后的真实工程账
很多团队第一次拿到《完整版三级等保所需设备及服务.pdf》这类清单时，第一反应是"照着买就行"。真到落地阶段才发现，清单只是起点：同一份清单，在物理机房、私有云、混合云三种环境下，设备形态、部署位置、服务边界完全不同。三级等保的核心不是"买了哪些盒子"，而是"这些盒子能不能在测评时拿出可验证的证据链"。我见过太多项目，设备买齐了，测评时因为日志留存不足六个月、审计记录没关联到自然人、边界访问控制策略没落地，被打回整改，工期直接拖两个月。这篇笔记面向正在做三级等保落地的运维、安全工程师和项目负责人，把清单拆成"哪些是硬性设备、哪些可以用服务替代、参数怎么配、测评前怎么自检"四件事，按可复现的路径讲清楚。适合已经立项、正在选型或准备迎检的团队照着走一遍。
2. 三级等保的设备与服务边界：先分清哪些必须买、哪些能租
三级等保的合规要求来自等保 2.0 的通用要求和扩展要求，落到工程上就是"安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心"五个层面。清单里列的设备和服务，本质是把这五层要求翻译成可采购项。但清单不会告诉你：哪些项在云环境下可以用云厂商的原生能力替代，哪些项必须自建。这一步判断错了，要么多花几十万买冗余设备，要么测评时发现云上能力不满足要求。
2.1 三级等保清单里的四类硬性设备
把常见清单归一下类，真正绕不开的硬性设备集中在四类：
| 类别 | 典型设备 | 对应等保层面 | 是否可云替代 |
|---|---|---|---|
| 边界防护 | 下一代防火墙、入侵防御 | 安全区域边界 | 部分可，需确认云防火墙能力覆盖 |
| 审计与日志 | 日志审计系统、数据库审计 | 安全管理中心 | 可，但需确认留存周期和字段完整性 |
| 身份与访问 | 堡垒机、统一身份认证 | 安全计算环境 | 可，但堡垒机通常建议自建 |
| 检测与响应 | 漏洞扫描、态势感知 | 安全管理中心 | 可，态势感知云上更成熟 |
判断原则很简单：涉及"谁能访问什么、访问过程留没留痕"的，尽量自建或独立部署，因为测评时要能独立取证；涉及"流量检测、漏洞发现"的，云上能力通常够用，前提是能导出报告和原始数据。
2.2 云环境下的服务替代判断
私有云和混合云场景，很多设备可以用服务替代，但替代有前提。以日志审计为例，云厂商的日志服务能采集、存储、检索，但测评要求日志留存不少于六个月，且审计记录要包含事件日期、时间、用户、事件类型、事件结果等字段。如果云日志服务的默认保留期是七天，就必须手动改配置或做转储。
# 以某云日志服务为例，调整日志保留期到 180 天 # 注意：不同云厂商 API 不同，这里只演示参数含义 cloud-cli log update-retention \ --logstore sec-audit-log \ --retention-days 180 \ --region cn-north-1这段命令的关键参数是--retention-days，三级等保要求至少 180 天，实际建议设 365 天留缓冲。--logstore要指向专门的安全审计日志库，不要和业务日志混在一起，否则测评时无法快速定位。执行后必须验证：写入一条测试日志，等一天后确认仍可检索，再检查导出功能是否可用。很多团队只改了保留期，没验证导出，测评时被要求提供原始日志文件，翻车。
2.3 服务清单里容易被忽略的三项
清单里通常会有"安全服务"一栏，容易被当成可选项砍掉，但三项服务在测评时是硬指标：
第一是渗透测试服务。三级等保要求每年至少一次，且报告要包含测试范围、方法、发现的问题和整改建议。自己团队做的内部测试不算，需要第三方出具。
第二是安全加固服务。操作系统、数据库、中间件的基线加固，测评时会抽查配置项。常见做法是准备一份加固基线文档，逐项打勾并截图留证。
第三是应急响应服务。要求有应急预案、演练记录、响应流程。很多团队只写了预案没演练，测评时被扣分。演练记录要包含时间、参与人、模拟场景、处置过程和结论。
这三项服务的采购判断标准是：能不能出具带时间戳和签章的交付物。不能出具的，等于没做。
3. 从清单到落地：设备选型参数与部署位置怎么定
清单只写设备类型，不写参数。选型参数定错了，要么性能不够导致业务受影响，要么配置过剩浪费预算。这一章按设备类型给出关键参数和部署位置建议，都是实际项目里验证过的取值区间。
3.1 下一代防火墙的四个必调参数
防火墙是边界防护的核心，三级等保要求访问控制策略最小化、会话限制、入侵防御开启。选型时看四个参数：
吞吐量要按业务峰值流量的 1.5 倍选。很多团队按平均值选，结果业务高峰时丢包。并发连接数按峰值连接数的 2 倍选，NAT 场景还要乘以转换系数。
# 防火墙策略配置示例（以常见 CLI 风格演示，非特定厂商） # 1. 默认拒绝所有，再按需放行 policy default-action deny # 2. 放行特定业务，限定源、目的、端口 policy add name allow-web \ src-zone untrust \ dst-zone dmz \ src-addr any \ dst-addr 10.0.1.10 \ service tcp/443 \ action permit \ log enable # 3. 开启入侵防御，动作设为阻断 ips enable ips profile set block-mode关键在default-action deny，这是最小化原则的落地。log enable必须开，测评时要能导出策略命中日志。ips profile set block-mode表示检测到攻击直接阻断，如果设成告警模式，测评时会被认为防护未生效。配置完要做验证：从外部扫描端口，确认未放行端口不可达，且日志里有记录。
3.2 日志审计与数据库审计的留存配置
日志审计系统的核心参数是存储容量和留存周期。三级等保要求日志留存不少于六个月，按日均日志量估算容量：
日均日志量 10GB 的场景，六个月需要约 1.8TB 裸容量，加上索引和副本，实际配 4TB 以上。数据库审计要开启全量 SQL 记录，但注意性能影响，通常建议在数据库侧开审计，审计设备旁路镜像。
-- 数据库审计配置示例（以常见数据库审计插件为例） -- 开启审计，记录所有 DDL 和 DML SET GLOBAL audit_log_policy = 'ALL'; SET GLOBAL audit_log_rotate_size = 1073741824; -- 单文件 1GB SET GLOBAL audit_log_retention_days = 180; -- 验证审计是否生效 SELECT * FROM mysql.audit_log LIMIT 10;audit_log_policy = 'ALL'会记录所有操作，性能敏感场景可以改成只记录 DDL 和高危 DML。audit_log_rotate_size控制单文件大小，方便转储。audit_log_retention_days设 180 天是底线，建议 365。验证时执行一条增删改查，确认审计表里有对应记录，且记录包含用户、时间、SQL 语句。
3.3 堡垒机的部署位置与认证对接
堡垒机是三级等保里最容易被低估的设备。它不只是"运维入口"，还是"操作审计"的取证点。部署位置建议放在管理区，所有运维流量必须经过堡垒机，禁止直连。
认证对接要接统一身份认证，实现自然人关联。测评时会检查：能不能通过堡垒机日志定位到具体是谁在什么时间操作了哪台设备。如果堡垒机账号是共享的，直接不合格。
# 堡垒机对接 LDAP 认证示例 # 配置 LDAP 服务器 auth-backend ldap \ --server ldap://10.0.2.5:389 \ --base-dn "ou=users,dc=example,dc=com" \ --bind-dn "cn=admin,dc=example,dc=com" \ --bind-password "******" \ --user-filter "(uid=%s)" # 开启双因素认证 auth-mfa enable --method totp--user-filter决定哪些用户能登录，要限定到具体组织单元。auth-mfa enable开启双因素，三级等保推荐开启。配置后测试：用 LDAP 用户登录，确认能进；再用不存在的用户登录，确认被拒。日志里要能看到登录成功和失败的记录。
3.4 漏洞扫描与态势感知的联动
漏洞扫描和态势感知通常打包在服务里。扫描频率建议每月一次全量，每周一次关键资产。态势感知要能接收防火墙、IDS、审计设备的日志，做关联分析。
部署时注意：扫描器要放在能覆盖所有网段的位置，通常用旁路加代理扫描。态势感知的日志源要配全，否则关联分析出不来结果。测评时会检查扫描报告和态势感知的告警记录，确认有发现、有处置、有闭环。
4. 三级等保落地避坑：五条血泪经验
这一章是实际项目里踩过的坑，每条按现象、原因、解决写。很多坑不是技术问题，是流程和认知问题。
4.1 日志留存够了但字段不全
现象：测评时日志留存六个月没问题，但被指出审计记录缺少"事件结果"字段，无法判断操作成功还是失败。
原因：日志采集时只采了原始日志，没做字段解析和标准化。很多设备默认日志格式里没有结果字段，或者结果字段是编码值。
解决：在日志审计系统里配置解析规则，把关键字段映射到标准字段。以登录日志为例，要把状态码映射成"成功/失败"。配置后抽样验证，确保每条记录都有用户、时间、类型、结果四个字段。
4.2 防火墙策略最小化做过头
现象：按最小化原则把策略收得很紧，结果业务上线后频繁报障，运维临时加策略，加完忘了记录，测评时策略数量和变更记录对不上。
原因：最小化原则落地时没有配套的变更管理流程。策略变更没有审批、没有记录、没有定期复核。
解决：建立策略变更流程，每次变更记录申请人、原因、时间、审批人。每季度做一次策略复核，清理无效策略。测评时提供变更记录和复核记录，证明策略是受控的。
4.3 堡垒机账号共享
现象：测评时发现堡垒机账号是团队共用，无法定位到具体操作人，被判定不符合"身份鉴别"和"访问控制"要求。
原因：图省事，或者运维人员流动大，没做账号生命周期管理。
解决：强制一人一账号，对接统一身份认证，离职即禁用。开启操作录像，录像留存不少于六个月。测评时抽查录像，确认能回放到具体操作。
4.4 渗透测试报告过期
现象：测评时提交的渗透测试报告是去年的，被要求重新做。
原因：三级等保要求每年至少一次渗透测试，很多团队以为做一次就够。
解决：把渗透测试纳入年度安全计划，提前两个月安排。报告要包含测试时间、范围、方法、发现的问题、整改建议和复测结果。整改后要复测，复测报告一起提交。
4.5 应急演练只有预案没有记录
现象：测评时提供了应急预案，但被要求提供演练记录，拿不出来。
原因：预案写完就归档，没组织演练，或者演练了没留记录。
解决：每年至少组织一次应急演练，模拟场景可以是数据泄露、勒索软件、服务中断。记录要包含时间、参与人、场景、处置步骤、耗时、结论。演练后更新预案，形成闭环。
5. 迎检前的自检清单与一个提效技巧
测评前的自检决定了一次过还是反复整改。我一般会在正式测评前两周做一轮内部自检，按等保层面逐项过，重点看证据链是否完整。下面这份自检清单是实际项目里沉淀下来的，按层面组织，每项都要能拿出截图、日志或报告。
| 层面 | 自检项 | 证据形式 | 常见不合格点 |
|---|---|---|---|
| 安全通信网络 | 通信加密、网络架构 | 配置截图、拓扑图 | 未加密的内部通信 |
| 安全区域边界 | 访问控制、入侵防御 | 策略导出、IPS 日志 | 默认放行、IPS 告警模式 |
| 安全计算环境 | 身份鉴别、访问控制、审计 | 堡垒机日志、数据库审计 | 账号共享、审计字段不全 |
| 安全管理中心 | 日志留存、态势感知 | 日志检索截图、告警记录 | 留存不足、日志源不全 |
| 安全管理 | 制度、预案、演练 | 制度文档、演练记录 | 有预案无演练 |
自检时有个提效技巧：把测评项翻译成"可执行的验证命令"，逐条跑一遍。比如验证日志留存，不要只看配置，要实际检索六个月前的日志；验证访问控制，不要只看策略列表，要实际从外部扫描确认未放行端口不可达。这样自检出来的问题，和测评时发现的问题基本一致。
# 自检脚本片段：验证日志留存和检索 # 1. 检索 180 天前的日志，确认存在 log-cli query \ --store sec-audit-log \ --start-time "$(date -d '180 days ago' +%Y-%m-%dT%H:%M:%S)" \ --end-time "$(date -d '179 days ago' +%Y-%m-%dT%H:%M:%S)" \ --limit 1 # 2. 验证审计字段完整性 log-cli query \ --store sec-audit-log \ --filter "user:* AND result:*" \ --limit 10 \ --format json | jq '.[] | {user, time, type, result}'第一段命令验证留存，如果返回空，说明留存没配到位。第二段验证字段，jq过滤出用户、时间、类型、结果四个字段，缺任何一个都要补解析规则。这个脚本可以做成定时任务，每周跑一次，提前发现问题。
最后说个习惯：我做完每个等保项目，会把测评时被扣分的项和整改过程记到一个文档里，下次项目启动时先过一遍。三级等保的坑就那么多，踩过一次记住，第二次就能省两周。希望帮到你。
本文还有配套的精品资源，点击获取
