构筑无人驾驶的“铜墙铁壁”：SDP零信任、安全操作系统、Apollo平台与加密存储的融合安全架构
摘要
无人驾驶汽车本质上不是一辆“普通汽车”，而是一套长期在线运行的移动智能系统。它既要实时做感知、规划和控制，又要和云端、运维平台、OTA平台、V2X设备持续交互，所以安全问题不再只是“会不会被黑”，而是“能不能长期、稳定、可控地安全运营”。
本文在原有SDP零信任、安全操作系统、Apollo平台和加密存储四层能力的基础上，再加入AI大模型分析层，形成一套更容易落地的五层协同架构。其中，SDP负责把住访问入口，解决“谁能连进来”；安全操作系统负责安全启动、实时调度和最终仲裁，解决“系统能不能在可信环境里运行”；Apollo负责感知、预测、规划和控制计算，解决“车该怎么开”；加密存储负责保护密钥、日志、模型和配置，解决“数据会不会泄露”；AI大模型负责日志分析、攻击研判、运维问答和策略建议，解决“海量安全信息怎么看得懂、处置跟不跟得上”。
这套架构的核心原则很简单：外部系统不能直接碰底盘，关键数据默认加密，关键操作全程留痕，AI大模型只做分析和辅助决策，不直接发转向、制动等控制命令。通过这样的分层设计，可以把“访问控制、运行可信、驾驶计算、数据保护、智能分析”串成一条完整安全链，更适合Apollo无人驾驶系统的实际部署和运营。
关键词：无人驾驶；零信任；SDP；安全操作系统；Apollo；加密存储；AI大模型；内生安全
一张图看懂整体架构（说明稿）
这是一张逻辑架构示意图，重点说明“谁负责什么、数据怎么走、安全在哪里卡住，以及AI大模型放在哪”，不代表具体ECU数量或厂商选型。
为了方便理解，也可以把这套系统看成五个角色：
1. SDP像“门卫”：所有外部访问先过它，身份不对、权限不够、时间过期，一律不放行。
2. Apollo像“驾驶大脑”：负责看路、判断、规划路线、生成控制建议。
3. QNX像“安全总控”：负责实时性、安全启动和最终仲裁，确保错误命令不能直接落到底盘。
4. 加密存储像“保险柜”：负责保护密钥、日志、模型、配置和地图，防止被偷看或被篡改。
5. AI大模型像“参谋长”：负责分析日志、研判攻击、辅助运维和生成策略建议，但不直接控制车辆。
主业务链路可以概括为：
传感器采集数据 -> Apollo完成感知、预测、规划、控制计算 -> QNX安全控制域做最终校验 -> 底盘执行器执行转向、制动和驱动。
主安全链路可以概括为：
云端发起访问请求 -> SDP网关先做身份认证和权限判断 -> 通过后才允许访问车端服务 -> 关键数据全程加密 -> 关键操作全程留痕。
主智能分析链路可以概括为：
车端日志、告警和运行数据上传到云端安全平台 -> AI大模型结合规则库和知识库进行分析 -> 输出风险判断、处置建议和策略优化建议 -> 由安全人员或规则引擎决定是否执行。
这张图最想表达的核心思想只有四句：
第一，外部系统不能直接碰底盘，必须先过SDP安全网关。
第二，Apollo负责“会不会开”，QNX负责“能不能执行”。
第三，AI大模型负责“看懂异常、给出建议”，但不直接发转向和制动命令。
第四，就算设备被拆、日志被拷走，没有密钥也看不懂数据。
一、引言：无人驾驶信息安全的“四重困境”
无人驾驶汽车正在从“能跑起来”走向“能运营起来”。对Apollo这类平台来说，难点已经不只是算法准不准、车能不能开，而是整套系统能不能长期稳定、安全可控地运行。车上有摄像头、激光雷达、毫米波雷达、定位设备、域控制器、底盘执行器，车外还要和云端、运维平台、OTA平台、V2X设备打交道，任何一个环节出问题，都可能影响行车安全。
与传统IT系统相比，无人驾驶的信息安全更复杂，主要体现在四个方面：
第一，攻击面更大。 过去汽车相对封闭，现在无人驾驶汽车更像“装着轮子的计算机系统”。它既连车内网络，也连5G、蓝牙、V2X和云端服务，攻击入口比传统汽车多得多。
第二，实时性要求更高。 很多安全措施在普通IT系统里很好用，但放到车上未必合适。因为车辆控制是毫秒级的，安全机制如果太重、太慢，就可能影响刹车、转向等关键动作。
第三，运营周期更长。 一辆车要跑很多年，但密码算法、证书、软件版本和漏洞情况都在不断变化。这就要求安全方案不能只顾眼前，而要考虑后续升级、吊销、换钥和长期运维。
第四，功能安全和信息安全绑得更紧。 以前大家常把“系统会不会坏”和“系统会不会被攻击”分开看，但在无人驾驶场景里，这两件事已经分不开了。一次网络攻击，最后可能表现成一次控制异常；一次系统异常，也可能被误判为安全事件。
除了这四个挑战，还有一个越来越现实的问题：车越来越多、日志越来越多、告警越来越多，单靠人工已经很难及时看懂和处理。这时候，AI大模型就有价值了。它适合放在云端做日志分析、异常归因、攻击研判、运维问答和策略建议，帮助安全团队更快找到问题、统一处置口径、提高运营效率。
因此，本文不再把安全理解成某一个单点产品，而是提出一套更容易落地的分层思路：SDP零信任负责把住入口，安全操作系统（如QNX）负责安全执行和最终仲裁，Apollo负责自动驾驶计算，加密存储负责保护数据，AI大模型负责智能分析和辅助决策。五层能力协同起来，才能真正支撑Apollo无人驾驶系统从测试走向长期运营。
二、SDP零信任：先把入口看住
2.1 为什么传统边界防护不够用了
过去很多系统默认“内网可信、外网不可信”。但无人驾驶不是传统办公室网络，车要连云、连运维平台、连OTA平台、连V2X设备，还可能连手机、蓝牙和各类诊断接口。只要有一个入口被打穿，攻击者就可能一路摸到核心控制链路。
所以在无人驾驶场景里，更现实的做法不是“先进来再说”，而是“先证明你是谁、你能干什么、你现在是不是还可信”。这就是零信任最核心的思路。
2.2 SDP落地时重点做什么
把SDP放到车端，最重要的不是概念有多新，而是把下面几件事做扎实：
第一，设备先认证再通信。 车、云、运维终端都要有自己的身份凭证，没有证书或证书异常，就不建立连接。
第二，默认拒绝。 外部系统不能直接看到车上的核心服务，更不能直接访问控制链路，必须经过安全网关放行。
第三，最小权限。 远程运维只能做运维该做的事，OTA只能走升级链路，远程接管只能走接管链路，彼此不能混用。
第四，按会话临时授权。 权限不是“一次登录、永久有效”，而是一次任务一次授权，会话结束就回收。
第五，关键操作全程留痕。 谁在什么时间访问了哪台车、做了什么动作，都要能查到。
2.3 在Apollo项目里怎么理解SDP的价值
放到Apollo无人驾驶项目里，SDP最直接的价值有三点：
一是挡住未授权访问。 没有通过认证的请求，连Apollo内部服务都碰不到。
二是把高风险操作收口。 远程接管、远程诊断、OTA升级这类动作，不再分散在各个接口里，而是统一经过安全网关和策略判断。
三是把风险控制在局部。 就算某个外围系统出问题，也不应该直接影响到底盘控制区。
一句话总结，SDP负责解决“谁能进、能进哪、能做多久”的问题。
三、安全操作系统：负责安全执行和最终仲裁
如果说SDP解决的是“谁能连进来”，那么安全操作系统解决的就是“连进来以后，系统还能不能在可信状态下运行”。在这套方案里，安全操作系统对应的是车端的安全控制域，典型代表就是QNX。
3.1 QNX在这套架构里到底负责什么
QNX不是用来替代Apollo的，它更像“安全总控”。在实际落地中，它主要负责三件事：
第一，安全启动。 从开机开始就逐级校验关键软件，签名不对就不让启动，防止车辆跑在被篡改的系统上。
第二，实时调度。 刹车、转向、故障处理这些动作不能卡顿，也不能被普通任务抢资源，所以要有确定性的实时执行能力。
第三，最终仲裁。 Apollo可以给出控制建议，但真正落到底盘前，还要由安全控制域做最后一次检查。
3.2 为什么它必须和零信任配合
光有网络访问控制还不够。因为即使入口把住了，车内仍然可能出现异常进程、错误配置或被污染的软件。
所以更稳的方式是两层一起上：
一层在网络侧，靠SDP决定“能不能进”；
一层在主机和执行侧，靠QNX决定“进来以后能不能真的执行”。
这样才能把“认证通过”与“实际可执行”分开处理，避免一个访问成功就直接触底盘。
3.3 放到项目里，QNX最适合放在哪
最适合的放法不是“把所有Apollo模块都搬到QNX里”，而是让QNX守住安全控制域，比如：
- 安全启动链
- 故障降级逻辑
- 紧急制动或最小风险状态触发
- 对底盘执行器的最终控制仲裁
一句话总结，QNX负责解决“系统是不是可信地跑着、命令能不能最终执行”的问题。
四、Apollo平台：负责自动驾驶计算，不负责单独拍板
Apollo是这套系统里的“驾驶大脑”。它负责感知、预测、规划、控制计算，决定车辆“应该怎么开”。但它不是安全操作系统，也不应该独自承担最终安全仲裁。
4.1 Apollo在安全架构里的角色
在这套架构里，Apollo主要负责三件事：
第一，看懂环境。 把摄像头、激光雷达、毫米波雷达、定位等数据变成可用的环境信息。
第二，算出轨迹。 根据道路、障碍物、交通规则和车辆状态，计算当前应该怎么走。
第三，输出控制建议。 把规划结果变成转向、加速、减速等建议，送给下游安全控制域。
4.2 在Apollo上要重点加哪些安全控制点
如果想让Apollo方案真正能落地，至少要把这些点看住：
- 命令入口要收口。 远程命令、测试命令、运维命令不能直接打到控制链路。
- 模块状态要可观测。 感知掉帧、定位漂移、规划超时、控制异常，都要能及时发现。
- 异常时要能降级。 一旦发现关键模块异常，要进入告警、减速、靠边或停车等最小风险状态。
- 模型和配置要受控。 上车的模型、参数、地图、规则，必须能校验来源和版本。
4.3 Apollo和QNX怎么配合最合适
可以把两者理解成“一个负责算，一个负责拍板”：
- Apollo负责“会不会开”
- QNX负责“能不能执行”
这也是为什么前面架构图里，Apollo放在自动驾驶域，QNX放在安全控制域。这样既能发挥Apollo在自动驾驶算法上的能力，又不会把最终控制权完全暴露给上层软件。
4.4 AI大模型和Apollo怎么配合
AI大模型可以很好地服务Apollo系统，但位置要放对。更适合的做法是：
- 放在云端做日志分析、异常归因、运维问答和策略建议
- 放在车端做轻量辅助分析，而不是直接接管底盘
- 作为“参谋长”，不作为“最后一脚刹车的人”
一句话总结，Apollo负责解决“车该怎么开”，但最终安全执行不能只靠Apollo自己。
五、加密存储：让数据被拿走也看不懂
很多项目容易把注意力都放在访问控制上，但无人驾驶还有一个很现实的问题：就算入口守住了，如果日志、模型、配置、证书是明文存着，被拷走一样危险。
5.1 车上哪些数据最该保护
至少有四类数据要重点保护：
第一，身份和密钥。 这是整车信任链的根，绝不能明文存放在普通文件里。
第二，控制和接管日志。 这类数据关系到审计、追责和事故复盘。
第三，模型、配置和地图。 一旦被替换或篡改，车可能不是“数据泄露”，而是“直接开错”。
第四，高敏业务数据。 例如精确位置、车内音视频、用户特征信息等。
5.2 更容易落地的做法
加密存储不一定要讲得很复杂，落地时重点是：
- 密钥放在SE芯片、TPM、HSM这类硬件安全模块里
- 关键分区和关键文件默认加密
- OTA包、模型包、配置包默认签名校验
- 日志上传前做脱敏，上传后做访问控制
5.3 为什么它要和零信任一起用
零信任更像“门”，加密更像“锁”。
- 零信任解决“谁能访问”
- 加密解决“被拿走后能不能看懂”
两者一起用，才是更完整的纵深防御。
5.4 AI大模型和数据保护的关系
AI大模型要分析日志和运行数据，就必须遵守同样的数据边界：
- 先脱敏，再进模型
- 先分权，再开放查询
- 敏感原始数据不随意给到通用问答入口
这样才能避免“大模型很聪明，但把不该看的数据也看了”。
六、融合架构：五层协同，才能真正落地
把前面几层放在一起看，整个方案就清楚了：
- SDP负责入口访问控制
- QNX负责安全执行和最终仲裁
- Apollo负责自动驾驶计算
- 加密存储负责数据保护
- AI大模型负责智能分析和辅助决策
6.1 这五层分别解决什么问题
如果用最简单的话来概括：
- SDP回答“谁能进来”
- QNX回答“进来后能不能执行”
- Apollo回答“车该怎么开”
- 加密存储回答“数据会不会泄露”
- AI大模型回答“这么多日志和告警怎么快速看懂”
6.2 云管端一体化怎么理解
这套方案不是只在车上做安全，也不是只在云上做安全，而是云、管道、车端一起配合：
云端负责身份、证书、日志、策略、运维和AI分析；
管道负责双向认证、加密通信和接入控制；
车端负责本地执行、故障降级、加密存储和最终仲裁。
哪怕车辆离线或弱网，车端也要能自己做出保守、安全的决定。
6.3 一个最典型的工作流程
以“远程接管请求”这个场景为例，落地后的流程应该是：
第一步，云端先校验人员身份、岗位权限和任务有效期。
第二步，请求到车端后，先由SDP安全网关验证设备身份、会话状态和访问权限。
第三步，请求进入Apollo相关服务前，要先检查车辆当前状态是否允许接管。
第四步，真正要落到底盘前，再由QNX安全控制域做最后仲裁，不满足物理约束或安全规则就拒绝执行。
第五步，关键指令、执行结果和全过程日志写入加密存储，便于审计。
第六步，日志和告警回传云端后，可由AI大模型自动做归因分析和处置建议，帮助后续复盘和策略优化。
6.4 为什么说这套方案更容易落地
因为它没有把所有希望押在一个产品上，而是明确每一层的职责边界：
- 网络访问不是Apollo自己扛
- 最终控制不是云端直接拍板
- 数据保护不是只靠“不要泄露”
- AI大模型不是直接开车，而是帮助人更快看懂风险
这样的分层更符合实际项目的开发、联调、验收和运营方式。
七、结论与展望
如果把整篇文章压缩成几句话，就是：
第一，Apollo无人驾驶系统要想真正落地，不能只看算法，还要把访问控制、安全执行、数据保护和智能运营一起设计。
第二，安全操作系统在这套架构里对应的是安全控制域，典型代表就是QNX；它不是替代Apollo，而是给Apollo兜底。
第三，AI大模型完全可以融入这套体系，但更适合放在云端做分析、研判、问答和建议，而不是直接控制方向盘和刹车。
第四，真正可落地的方案，不是概念越多越好，而是谁负责什么、出了问题谁兜底、数据怎么保护，都能讲清楚、做得到、查得到。
往后看，这套方案还可以继续往三个方向发展：
- 更智能：让AI大模型参与更多日志分析、攻击研判和运维辅助
- 更标准：把证书、策略、审计、升级流程做成统一规范
- 更工程化：从测试场到量产车都采用同一套分层安全思路
总的来说，这套“SDP + QNX + Apollo + 加密存储 + AI大模型”的方案，更像是一套能真正上车、上云、上线运营的安全架构，而不只是停留在概念层面的安全拼图。
参考文献
[1] Secure Data Provenance in Internet of Vehicles with Data Plausibility for Security and Trust[C]. 2024 IEEE World AI IoT Congress, 2024: 612-618.
[2] BlackBerry QNX. 集成QNX OS for Safety的NVIDIA DRIVE AGX Thor开发套件现已全面上市[EB/OL]. 2025-09-05.
[3] 百度Apollo. Apollo 10.0 新版说明[EB/OL]. Apollo开发者社区.
[4] TP-IoAV: A Tri-Party Cloud Data Protection Scheme for Internet of Autonomous Vehicle Coupled With Chaotic Biometric Cryptography[J]. IEEE Transactions on Intelligent Vehicles, 2025, 10(2): 1208-1221.
[5] 复旦大学大数据研究院. 复旦大学成果入选中国通信学会2024年网络与数据安全十大科技进展[EB/OL]. 2025-12-19.
[6] Thoughtworks. SDV Pulse: Concepts and solutions[EB/OL]. 2025.
[7] 启明创投. 文远知行采用BlackBerry QNX系统，打造极致安全的ADAS解决方案[EB/OL]. 2025-11-04.
[8] 百度Apollo. 百度Apollo发布汽车安全引擎，为智能汽车保驾护航[EB/OL]. 2021-04-21.
[9] 基于混合加密的无人驾驶清扫车与云平台数据交互系统[P]. 中国专利: CN120264270B, 2025.
[10] 创客中国. 基于安全芯片的无人车全链路安全解决方案[EB/OL]. 2026.
)