企业官网建设流程全解析

摘要：车载防火墙的工程价值，不在于规则数量，而在于能否把风险分析、通信需求、运行状态和验证证据连成一条可追踪链路。本文从部署位置、CAN 与车载以太网的过滤维度、规则工程、失效策略和测试方法出发，说明如何避免“规则很多但边界不清”“拦住攻击也拦住安全关键通信”等问题。

适用范围：本文是通用工程方法介绍。示例用于解释思路，不是量产规则模板；具体阈值、默认动作和失效策略必须由项目安全目标、功能安全目标、网络性能及 OEM 要求确定。

图 1：分布式车载防火墙部署架构

一、先确定防火墙部署在哪里

“车载防火墙”不是一个固定盒子。部署点不同，可见流量、可执行动作和失效影响也不同。

1. 主机防火墙

主机防火墙位于 ECU 操作系统、网络栈或通信框架附近，主要控制进入或离开本机的通信。它能够靠近最终服务实施最小权限，但会占用 ECU 的处理器、内存和规则存储资源。

2. 网络转发防火墙

网络转发防火墙部署在中央网关、区域控制器、域控制器或交换设备上，适合控制跨网络、跨区域或跨安全域的通信。它能集中管理边界，但通常无法覆盖完全不经过该节点的域内流量。

3. 协议感知防火墙

协议感知防火墙不仅检查地址和端口，还理解 SOME/IP、SOME/IP-SD、DoIP 等协议字段。它可以把访问控制细化到服务、方法、事件或诊断目标，但规则复杂度、性能开销和升级兼容性也更高。

4. 多点协同

典型分工可以是：中央节点限制跨域路径，区域节点缩小局部攻击面，端点 ECU 保护本机服务。多点部署不是简单重复相同规则，而是让每个执行点承担与其可见范围相匹配的职责。

设计时至少需要回答：

• 哪些通信一定经过这个执行点？
• 它能看到原始通信的哪些字段，经过转换后又会丢失哪些上下文？
• 规则执行失败会影响哪些功能？
• 谁负责配置、签名、加载、更新和回滚规则？
• 多个执行点的允许与拒绝策略是否一致？

二、CAN/CAN FD 防火墙可以检查什么？

CAN/CAN FD 上常见的规则维度包括：

• 物理或逻辑总线通道；
• 报文的接收或发送方向；
• 标准帧、扩展帧及 CAN 标识符；
• 数据长度和项目允许时的部分载荷条件；
• 周期、频率、突发数量或总线负载相关条件；
• 诊断请求的寻址方式、服务范围和车辆状态；
• 网关转发时的源接口与目标接口组合。

CAN 标识符不是可信身份

CAN 标识符参与仲裁并表达报文语义，不能简单称为“ECU 地址”。同一共享总线上的恶意节点在具备发送能力时，可能发送使用其他报文标识符的帧。防火墙依据 CAN 标识符实施白名单仍然有价值，但它控制的是“符合配置特征的报文”，并不天然完成发送 ECU 的密码学身份认证。

如果防火墙位于连接两个独立物理总线的网关，它可以依据入口通道确定报文来自哪个网络分段；若还需要确认报文真实性与新鲜度，则应结合 SecOC 或项目定义的其他认证机制。

频率规则不是越严格越好

周期或频率检测需要考虑正常抖动、总线仲裁、网络管理、故障恢复、诊断和启动阶段。把通信矩阵中的名义周期直接当作硬阻断阈值，可能造成误拦截。

例如，“某报文周期为 10 ms，因此超过每秒 100 帧立即永久阻断”只能算一个不完整的教学想法。量产规则至少还需定义观察窗口、允许抖动、突发行为、启动状态、降级状态、计数恢复和误报处置。

三、车载以太网防火墙可以检查什么？

以太网和基于 IP 的通信提供了更多可供访问控制的字段：

• 二层：源/目标 MAC、VLAN、优先级、EtherType、入口和出口端口；
• 三层：源/目标 IP、IP 版本、上层协议及必要的一致性条件；
• 四层：TCP/UDP、源/目标端口、TCP 连接状态、连接数量；
• 应用层：SOME/IP 服务、方法、事件，SOME/IP-SD 服务发现条目，以及 DoIP 相关字段；
• 行为条件：带宽、请求速率、连接建立速率和特定车辆状态。

图 2：CAN 与车载以太网的典型过滤维度

无状态过滤

无状态过滤逐包匹配规则，例如源/目标地址、协议和端口。实现相对直接，但不了解前后报文的连接关系。

有状态检测

有状态检测维护连接或会话相关信息。例如，TCP 返回流量是否属于已建立连接。它能够表达更严格的策略，但需要状态表、超时管理和资源耗尽防护。

深度包检查

深度包检查进一步解析应用协议。AUTOSAR Adaptive Platform R25-11 防火墙规范描述了针对 SOME/IP、SOME/IP-SD、DoIP 等协议的检查能力，并包含无状态、有状态、规则过滤、限流和状态相关过滤等要求。

引用该规范时应说明两个边界：第一，这是 AUTOSAR Adaptive Platform 标准范围内的能力定义；第二，某个量产产品支持到什么程度，应依据对应版本的正式产品文档和配置，不能仅凭“AUTOSAR 兼容”推断全部功能。

四、如何从安全需求导出规则？

一条规则至少应能追溯到业务通信需求或安全需求，而不是因为“暂时不知道用途”就长期放行。

推荐的数据流如下：

1. 从 TARA 获取安全目标和风险处置需求。**明确要保护的资产、攻击路径、信任边界和风险降低目标。
2. 建立通信基线。汇总通信矩阵、服务接口、诊断需求、网络管理、时间同步、软件升级和生产售后需求。
3. 选择执行点。确认哪个防火墙能够看到所需上下文，并且不会因网络转换丢失判断依据。
4. 形成规则。定义匹配条件、动作、适用状态、日志级别、异常计数和恢复方式。
5. 配置与保护。对规则进行版本管理、完整性保护、授权更新和回滚设计。
6. 建立验证证据。让每条高风险规则对应正向、反向、边界和性能测试。

图 3：从 TARA 和通信需求到规则及测试证据

一个教学化规则示例

以下只是表达规则要素，不是可直接用于量产的配置：

“默认拒绝”是构建最小权限策略的重要原则，但也不能脱离系统启动、应急通信、诊断救援和功能安全需求机械套用。真正的默认动作应在明确通信面和状态模型后确定。

五、特殊运行状态不能遗漏

许多防火墙问题并不发生在稳态通信，而发生在状态切换时。

启动与规则加载

需要定义网络栈可用但完整规则尚未加载时的行为。可选方案包括仅允许最小启动通信、使用受保护的基础规则集，或延迟开放相关服务。不能让短暂的“全放行窗口”成为未经评估的默认行为。

休眠与唤醒

唤醒报文、网络管理和重新建立连接可能出现与稳态不同的频率和顺序。规则应覆盖正常唤醒、重复唤醒、异常唤醒和超时恢复。

诊断、刷写与维护

生产、售后、远程诊断和软件更新可能需要临时开放额外服务。开放条件应与认证授权、车辆状态、时间范围和目标 ECU 绑定，并在会话结束或超时后收回。

网络降级与故障恢复

总线故障、链路切换、ECU 重启或网关降级可能改变通信路径。需要确认替代路径是否仍经过等效安全控制，以及规则状态是否能安全恢复。

六、fail-open 还是 fail-closed？

不存在适用于所有 ECU 和所有通信的统一答案。

• Fail-closed：防火墙异常时拒绝通信，有利于限制未授权访问，但可能中断安全关键功能或故障恢复通信。
• Fail-open：防火墙异常时维持通信连续性，但会扩大攻击面，并可能破坏既定安全目标。
• 受控降级：只保留经过论证的最小通信集合，同时限制诊断、外部连接或非必要服务。

决策至少需要综合网络安全目标、ISO 26262 相关安全目标、预期功能安全（SOTIF）影响、可用性、驾驶状态、故障持续时间和恢复机制。同一 ECU 在启动、行驶、驻车和刷写状态下也可能采用不同策略。

建议把失效策略写成明确的状态和动作表，而不是在需求中只写一句“防火墙故障时系统进入安全状态”。

七、如何验证防火墙？

1. 规则静态检查

• 是否存在永远无法命中的规则；
• 是否有范围过宽的允许规则；
• 规则顺序是否导致后续规则被遮蔽；
• 地址、端口、服务和车辆状态是否与通信需求一致；
• 多个执行点之间是否出现策略冲突；
• 规则版本是否与软件和网络配置匹配。

2. 正向功能测试

验证每一条必要通信在正确接口、状态、方向和时序下都能通过，包括启动、唤醒、诊断、升级和降级场景。只做攻击测试而不验证合法通信，可能把误拦截风险遗漏掉。

3. 反向与边界测试

• 错误源或目标地址；
• 未授权端口、服务、方法或诊断目标；
• 错误车辆状态；
• 边界长度、畸形字段和不一致的协议长度；
• TCP 状态绕过、异常分片及产品明确支持范围内的重组场景；
• 超过允许速率、连接数量或状态表容量。

4. 鲁棒性和拒绝服务测试

评估洪泛、连接耗尽、日志洪泛和大量规则匹配时的行为。防火墙不仅要“拦住”，还要避免自身成为 CPU、内存、存储或总线带宽耗尽的原因。

5. 性能与实时性测试

测量典型和最坏负载下的延迟、抖动、吞吐量、CPU、内存和状态表占用。测试应覆盖规则数量增长、深度包检查开启、日志启用和异常流量条件。

6. 生命周期测试

验证规则升级、断电恢复、版本回滚、配置损坏、签名验证失败和软件版本不匹配。规则本身也是需要保护和维护的软件资产。

八、防火墙如何与 IdsM、IdsR 和 SOC 协同？

防火墙发现规则违反时，可以根据配置丢弃、限流或允许但记录，并向 IdsM 报告安全事件。IdsM 对事件执行过滤和聚合，形成合格安全事件；随后可存入安全事件存储，或交给 IdsR/车载通信单元转发到后端 SOC。

图 4：防火墙阻断路径与 IDS 上报路径

这里有三个容易误写的地方：

1. IdsM 主要处理安全传感器报告的事件，不代表所有原始攻击检测都由 IdsM 完成；
2. IdsM 收到事件不等于攻击已经被阻断，阻断可能由防火墙或其他响应机制执行；
3. 不是所有被拒绝的报文都应无条件上报后端，否则可能造成日志和通信资源耗尽。事件过滤、限频和优先级需要项目化设计。

九、工程落地检查清单

• 防火墙部署点与信任边界是否一致；
• 每条允许规则是否有明确的业务或安全需求来源；
• 是否区分启动、行驶、驻车、诊断、刷写和降级状态；
• CAN 标识符是否被错误当成可信发送者身份；
• 加密认证与访问控制是否各自承担清晰职责；
• 规则加载失败和防火墙运行异常是否有受控策略；
• 日志和安全事件是否有限频、聚合和存储保护；
• 是否同时验证合法通信、违规通信、鲁棒性和性能；
• 规则、软件、通信矩阵和测试证据是否版本一致；
• OTA 或售后更新后是否重新验证受影响规则。

总结

车载 ECU 防火墙工程不是把企业网络规则缩小后放进汽车。它必须理解固定而严格的车内通信、资源和实时性约束，也必须处理车辆状态、诊断维护、功能安全和长生命周期更新。

可靠的工程闭环应当是：

风险和通信需求决定规则，规则由合适的执行点落实，异常事件进入 IDS 体系，所有关键行为通过测试证据证明。

防火墙只是纵深防御中的一层，但如果部署点、规则、状态模型和验证方法设计正确，它可以显著限制攻击面和横向移动范围。

参考资料

1. AUTOSAR, Specification of Firewall for Adaptive Platform, R25-11
2. AUTOSAR, Requirements on Firewall, R25-11
3. AUTOSAR, Requirements on Intrusion Detection System, R25-11
4. Vector, AUTOSAR Intrusion Detection System Manager — MICROSAR IdsM
5. ISO, ISO/SAE 21434:2021 — Road vehicles — Cybersecurity engineering
6. UNECE, UN Regulation No. 155 — Cyber Security and Cyber Security Management System
7. 国家市场监督管理总局、国家标准化管理委员会，GB 44495—2024《汽车整车信息安全技术要求》

本文依据截至 2026 年 8 月可查的公开官方资料整理。ISO/SAE 21434:2021 仍是 ISO 页面列出的已发布版本，同时处于系统复审阶段。标准、法规解释和产品能力可能更新，量产项目应使用正式获取的适用版本，并结合 OEM、供应商及认证要求实施。