一、防火墙选型先回答四个业务问题

防火墙位于不同安全区域之间，负责依据企业安全策略控制网络流量。NIST SP 800-41 Rev.1 将防火墙选型、配置、测试、部署和管理视为一个完整过程，而不是单纯的设备采购。企业在询价前应先回答以下问题：

1. 保护什么：是互联网出口、数据中心边界、分支互联、云上网络、生产网络，还是第三方运维入口？不同位置的流量和故障影响并不相同。
2. 允许什么：哪些用户、设备和应用需要跨区域访问？哪些业务对时延、连续性和加密有特殊要求？
3. 检测什么：计划启用应用控制、IPS、恶意文件检测、DNS或URL安全、加密流量检测中的哪些能力？
4. 怎样运行：由谁维护策略、分析告警、升级版本、备份配置和处理故障？是否有双机、旁路或旧设备回退方案？

如果这四个问题没有答案，型号比较就只能停留在参数表层面。设备即使性能很高，也可能因为接口不匹配、策略无法迁移、日志无人分析或故障无法回退而不适合现网。

二、建立真实的流量和连接基线

建议从现有出口设备、流量分析平台、交换机、路由器或日志系统采集连续多个完整工作周期的数据。既要覆盖普通工作日，也要覆盖结算、备份、发布、视频会议、软件更新等业务高峰。只看瞬时截图或平均带宽，会掩盖真正的容量峰值。

需要采集的指标	选型意义	常见误区
上下行峰值与高位流量	判断链路和安全功能开启后的吞吐需求	只用运营商带宽作为设备需求
并发连接数	判断同时存在的会话规模	把在线人数直接等同于连接数量
每秒新建连接数	评估短连接、网页、API和突发访问能力	只关注总并发，不看连接建立速度
应用与协议分布	识别视频、文件、云服务、数据库和业务接口特征	默认所有流量处理成本相同
加密流量比例	评估是否需要及能够进行TLS检测	把普通吞吐当成解密后的性能
远程与站点VPN	核算用户、隧道、带宽、认证和加密算法	只统计账号数量，不测试同时在线和峰值
平均包长与流量方向	小包和双向流量可能增加处理压力	只看大包顺序转发测试结果

容量规划还要加入可确认的变化，例如新增分支、人员增长、业务上云、视频系统上线、备份窗口调整或互联网链路扩容。余量不宜套用统一百分比，应根据项目周期、扩容难度、设备寿命和故障切换场景确定。如果双机故障时要求单台承载全部业务，就必须验证单台在目标策略下的能力。

三、正确理解防火墙性能指标

不同厂商对指标的命名和测试条件可能不同。比较时应要求说明软件版本、功能组合、报文大小、流量方向、策略数量和测试拓扑。以下指标通常需要分别核对：

• 基础防火墙吞吐：主要反映基础转发能力，不能代表开启威胁检测后的实际效果。
• 威胁防护吞吐：应明确是否包含应用识别、IPS、恶意文件检测和URL过滤，以及启用的规则集。
• 并发连接：反映设备可维持的会话规模；企业应使用真实业务会话特征测试，而不是只看实验室上限。
• 每秒新建连接：对电商、门户、API网关、短连接和突发访问场景尤其重要。
• IPsec与远程接入能力：应同时核对隧道数量、并发用户、加密算法、认证方式、客户端兼容和实际吞吐。
• TLS检测能力：解密会增加计算负载，还涉及证书、隐私、合规和应用兼容，必须单独设计测试。
• 日志处理能力：包括本地存储、外发速率、检索、保留时间和告警能力。日志丢失会直接影响调查和审计。

厂商参数可以用于初筛，但不能替代现网PoC。若参数表没有公开测试条件，应要求供应商在测试方案中写明；如果测试功能与计划上线功能不同，结果不应直接作为采购依据。

四、安全功能要与风险场景对应

功能越多并不等于防护越好。企业应把功能映射到风险和处置流程。例如，IPS用于识别和阻断符合规则的攻击流量，但规则需要更新、调优并处理误报；应用控制可以识别业务类型，但必须考虑办公协作、云应用和自研协议；恶意文件检测可以补充终端防护，却不能替代终端上的行为监测和补丁管理。

建议按以下方式评估功能：

1. 先列出要解决的风险，例如公网服务攻击、恶意下载、远程账号滥用、异常出站或跨区越权。
2. 明确防火墙能提供的检测或控制，以及仍需身份、终端、邮件、备份和应用系统承担的责任。
3. 使用企业真实或脱敏流量验证识别率、误报、延迟和告警信息是否足以支撑处置。
4. 为每类高风险告警指定接收人、核查步骤、升级条件和关闭标准。

防火墙是分层防御的一部分，不应被描述为能够单独解决勒索、数据泄漏或账号失窃。采购文件中如果出现“全面防护”“零风险”等无法验收的表述，应改成具体功能、场景和测试方法。

五、加密流量检测必须先确定边界

大量业务使用TLS加密后，防火墙如果只看到连接信息，无法检查其中的内容；但对所有流量统一解密也不可取。企业需要同时评估技术、隐私、合规和业务兼容。

• 明确允许检测的业务、用户、终端和网络区域，并对金融、医疗、个人隐私或证书绑定应用设置合理例外。
• 规划企业根证书的生成、存储、分发、轮换和吊销，限制私钥访问。
• 测试浏览器、移动应用、客户端证书、双向认证、更新服务和自研程序兼容性。
• 单独测量解密后的吞吐、并发、延迟、CPU和故障行为。
• 向相关人员说明检测范围，并让例外、审批和策略变更可审计。

若企业没有证书管理、兼容测试和隐私治理能力，应先在明确的高风险范围试点，而不是把解密功能一次性覆盖全网。

六、接口、路由、NAT与高可用不可遗漏

性能合格的设备也可能因为网络能力不匹配而无法上线。选型时应核对电口、光口、速率、光模块、链路聚合、VLAN、IPv4/IPv6、动态或静态路由、策略路由、NAT、服务器发布、QoS、旁路和管理接口。涉及多个出口、分支、数据中心或云网络时，要绘制正常与故障状态下的流量路径。

双机高可用需要验证的不只是“能切换”，还包括：

• 配置、对象、策略和会话是否按预期同步；
• 接口、交换、路由、NAT和上游设备是否支持切换路径；
• 单台故障后容量是否仍能承载关键业务；
• 故障检测、切换时间和恢复方式是否满足业务要求；
• 主备恢复、版本升级和配置错误时是否有回退步骤。

高可用不等于没有中断。验收时应由业务系统实际发起连续访问，记录切换期间的连接、丢包和恢复，而不是只观察设备面板状态。

七、策略和运维能力决定长期效果

设备上线后，策略会随系统、人员和供应商变化持续增长。若没有生命周期管理，防火墙最终会积累大量任意源目的、宽端口、重复、被覆盖或无人负责的规则。

运维能力至少应包括：

• 管理员独立账号、多因素认证、角色分权和操作审计；
• 策略申请、业务负责人、有效期、测试、审批、实施和回退记录；
• 规则命中、长期未使用规则、宽范围规则和临时规则复核；
• 配置自动或定期备份、版本对比和恢复验证；
• 软件、特征库、证书和许可证到期提醒；
• 设备资源、接口、双机、日志中断和高风险事件告警；
• 日志外发到独立平台，避免设备故障后证据一并丢失。

选型时应让未来的实际运维人员参与试用，验证策略检索、批量对象、命中分析、日志查询、告警上下文和配置回退，而不只是观看售前演示。

八、PoC测试应怎样设计

PoC应使用双方确认的拓扑、软件版本、许可证和策略，不建议直接在生产出口进行不可回退的压力测试。可以选择镜像流量、测试链路、备用出口或维护窗口，逐步增加功能和负载。

测试类别	测试内容	验收证据
基础连通	路由、NAT、DNS、IPv6、服务器发布和分支互联	测试记录、流量路径与配置
业务兼容	办公、会议、文件、云服务、自研系统和外部接口	业务负责人确认与异常清单
安全功能	应用识别、IPS、恶意文件、URL、VPN和告警	命中证据、误报与处置建议
性能容量	高峰流量、并发、新建连接、延迟、CPU与日志	测试工具、时间、版本和原始结果
加密检测	证书、兼容、例外、解密性能和隐私边界	策略范围、兼容清单与性能数据
高可用	接口、设备、电源、链路故障与主备恢复	切换时间、业务影响和恢复记录
可运维性	分权、备份、恢复、日志、升级和策略复核	操作记录与运维人员确认

每项测试都应写明前置条件、操作步骤、预期结果、实际结果和问题处理。失败项修复后重新测试，不用口头解释替代验收证据。

九、采购与验收清单

• 已采集完整工作周期的峰值流量、并发、新建连接、应用和加密比例；
• 已明确部署位置、安全区域、业务依赖和故障影响；
• 厂商参数说明了测试条件，PoC功能与计划上线功能一致；
• 电口、光口、模块、路由、NAT、VPN和IPv6满足现网要求；
• TLS检测范围、证书管理、例外和兼容性已经评审；
• 双机、链路、电源和单机承载能力完成故障测试；
• 管理员分权、策略生命周期、日志、备份和回退可以实际操作；
• 许可证、订阅、维保、升级、备件和服务边界写入合同；
• 验收以业务和测试结果为准，而不是只核对型号与数量；
• 上线窗口、旧配置备份、回退条件和负责人已经确认。

十、常见选型误区

误区一：出口是千兆，就采购千兆防火墙。出口速率没有包含威胁检测、连接、VPN、解密和增长因素，也没有说明测试条件。

误区二：功能越多越安全。没有数据、人员和处置流程的功能只会产生更多无人处理的告警。

误区三：双机等于业务不中断。上游链路、路由、NAT、会话同步和单机容量都可能成为切换失败点。

误区四：上线后一次配置长期不变。业务、人员、漏洞和应用持续变化，策略、版本和日志必须持续运营。

误区五：报价最低就是总成本最低。许可证续费、日志平台、升级、备件、策略迁移、培训和运维投入都会影响全生命周期成本。

参考资料

• NIST SP 800-41 Rev.1：Guidelines on Firewalls and Firewall Policy
• 工业和信息化部：《中华人民共和国网络安全法》