4. 信息安全开发流程与AURIX映射
ISO/SAE 21434 是道路车辆网络安全工程的通用标准，它并不规定具体芯片如何实现安全，而是规定“组织与项目应如何证明网络安全被系统性地管理”。在 AURIX 项目中落地该标准，核心是把标准要求的活动、工作产物与 AURIX 提供的硬件安全机制、软件包和工具链对应起来，形成可追溯的网络安全计划与安全案例。本节先梳理生命周期与 TARA 方法，再说明安全目标到安全需求的转化，最后给出 AURIX 项目中的映射关系与可执行示例。
一、ISO/SAE 21434 网络安全生命周期
标准把网络安全活动贯穿于概念、开发、生产、运行与维护、报废各阶段，并强调“持续”而非一次性通过。关键活动包括：网络安全治理与能力建设、项目相关的网络安全计划（Cybersecurity Plan）、威胁分析与风险评估（TARA）、概念阶段的安全目标与安全概念、开发阶段的安全需求与实现、验证与确认、生产与运行阶段的监控与事件响应，以及贯穿全程的网络安全案例（Cybersecurity Case）。
在 AURIX 项目中，生命周期映射的关键在于“责任边界”。整车厂负责车辆级 TARA 与安全目标，Tier1 负责 ECU 级安全概念与需求分解，芯片供应商（如英飞凌）提供 AURIX 的安全机制、安全手册、安全应用说明与支持包。项目网络安全计划应明确：谁负责哪一层 TARA、哪些安全需求由 AURIX 硬件承担、哪些由软件与外部安全模块（如 HSM/SHE）承担、验证证据由谁提供。
二、TARA 方法与 AURIX 资产识别
TARA 的核心是识别资产、分析威胁、评估风险并确定处置措施。资产不仅包括数据（密钥、标定数据、诊断数据、固件），还包括功能（安全气囊触发、制动控制、扭矩监控）和接口（CAN/CAN FD、以太网、调试口、OTA 通道）。在 AURIX 上，资产识别要落到具体资源：
- 密钥与证书：存放于 HSM 密钥槽或 UCB（User Configuration Block），受访问权限与生命周期状态保护。
- 安全启动链：从 BootROM 到 HSM 固件、再到应用核固件的逐级校验。
- 调试与测试接口：DAP/JTAG、HSM 调试口，需通过 OCDS 锁定与调试认证控制。
- 通信接口：CAN、以太网、LIN、FlexRay，需考虑报文注入、重放与伪造。
- 诊断与刷写：UDS 服务、Flash 编程、OTA 更新，需考虑未授权刷写与降级攻击。
威胁分析常用 STRIDE 或攻击树，结合攻击可行性（时间、技能、设备、知识）与影响（安全 S、财务 F、操作 O、隐私 P）计算风险值。风险处置策略包括规避、缓解、转移与接受。对 AURIX 项目而言，缓解措施往往直接对应芯片机制：例如用 HSM 做安全启动与密钥运算，用 SMU（安全管理单元）做故障与安全事件上报，用 MPU 做内存隔离，用访问权限控制保护关键寄存器。
三、安全目标到安全需求的转化
安全目标（Security Goal）是概念层对资产保护意图的陈述，例如“防止未授权固件在 ECU 上运行”。安全需求（Security Requirement）是可实现、可验证的工程陈述，例如“ECU 上电后，应用核固件必须由 HSM 使用 ECDSA P-256 公钥验证签名，验证失败时禁止跳转到应用固件并记录安全事件”。转化过程要保证可追溯：每条安全需求应能追溯到安全目标，并向下分解到软件组件、硬件机制与测试用例。
在 AURIX 上，安全需求通常分为三类：硬件机制需求（如 HSM 启动、UCB 保护、SMU 报警）、软件配置需求（如 MPU 区域划分、访问权限、密钥槽分配）、流程与运维需求（如密钥注入、调试锁定、事件日志上传）。需求描述应包含触发条件、输入、预期行为、失败处理和验证方法，避免“应保证安全”这类不可验证的表述。
四、AURIX 项目中的网络安全计划与安全案例
网络安全计划是项目级管理文件，通常包含：范围与边界、角色与职责、TARA 计划、安全需求管理、验证与确认策略、生产与运维接口、事件响应流程、工具与供应链安全、里程碑与交付物。安全案例则是“论证 + 证据”的集合，说明项目如何满足安全目标，包含 TARA 报告、安全概念、需求追溯矩阵、测试报告、渗透测试结果、HSM 配置与密钥管理记录、生产锁定记录等。
下面给出一个 AURIX 项目安全需求与验证映射的示例表，用于说明“需求—机制—验证”的对应关系。表中参数为教学示例，实际项目需按具体型号与安全手册确定。
| 安全需求（示例） | AURIX 机制 | 验证方法 | 证据 |
|---|---|---|---|
| 上电后仅允许签名固件运行 | HSM 安全启动 + ECDSA P-256 | 篡改固件后观察是否拒绝启动 | 启动日志、测试报告 |
| 密钥不可被应用核直接读取 | HSM 密钥槽 + 访问权限 | 应用核读取密钥槽返回错误 | 寄存器访问记录 |
| 调试口在量产阶段锁定 | OCDS 锁定 + UCB 配置 | 尝试连接 DAP 失败 | 锁定配置与验证记录 |
| 安全事件可上报并记录 | SMU 报警 + HSM 日志 | 注入故障触发 SMU 报警 | 报警日志、事件记录 |
在实操层面，AURIX 项目的安全案例构建通常从“安全需求追溯矩阵”开始：每条需求分配唯一 ID，关联安全目标、实现机制、测试用例与证据文件。HSM 配置需记录密钥槽用途、算法、权限与生命周期状态；UCB 配置需记录锁定项与写入时机；SMU 报警需记录触发源、响应动作与日志路径。生产阶段要固化调试锁定与密钥注入流程，运行阶段要建立漏洞监控与 OTA 更新验证机制。
从图中可以看出，AURIX 的安全机制并不是孤立存在的，而是与 TARA 输出的安全目标、分解后的安全需求以及最终的安全案例证据形成闭环。项目实践中，建议在概念阶段就确定哪些安全目标由 HSM 承担、哪些由 SMU 与 MPU 协同完成，并在开发阶段用需求追溯矩阵固化下来。这样在安全案例评审时，评审者可以从任意一条安全目标出发，沿着“目标—需求—机制—测试—证据”的路径逐级核查，快速判断项目是否满足 ISO/SAE 21434 的要求。