面试翻车现场

面试一家做医疗机器人的公司，面试官问："你们的机器人系统怎么保证通信安全？如果有人恶意注入虚假的传感器数据怎么办？"

我愣了一下，说我们是在内网跑的，没有考虑过安全问题。他摇了摇头："医疗和自动驾驶这些领域，功能安全是强制要求。你知道SROS2吗？ROS2提供了哪些安全机制？"

这个问题让我意识到，做产品级机器人系统和做demo完全是两回事。安全不是可选项，是必须考虑的。

为什么需要安全机制

ROS2基于DDS通信，默认情况下是"信任一切"的。任何知道topic名称的节点都可以发布数据，也可以订阅数据。没有身份验证，没有加密，没有访问控制。

这在实验室环境没问题，但在产品中就很危险了。想象一下：你的自动驾驶车在行驶，有人在同一网络里发一个假的/cmd_vel话题，车辆就失控了。或者有人监听你的传感器数据，获取环境信息。

这不是危言耸听。2015年就有人演示过通过注入虚假GPS信号劫持无人车的攻击。2019年也有研究者展示了通过DDS网络注入恶意数据控制ROS2机器人的方法。随着机器人越来越多地部署在公共空间，安全风险只会越来越大。

另外，很多行业有合规要求。医疗设备要过FDA认证，汽车要过ISO 21434（道路车辆网络安全），工业控制系统要过IEC 62443。这些标准都要求通信有身份验证和加密机制。不做安全，产品连认证都过不了。

SROS2（Secure ROS2）就是为了解决这些问题而设计的。它基于DDS Security标准（OMG DDS Security 1.1），在DDS层面提供安全保障。

SROS2的三大安全能力

SROS2提供三个核心安全能力：身份验证（Authentication）、访问控制（Access Control）和数据加密（Encryption）。

身份验证确保每个参与通信的节点都是经过认证的。SROS2使用X.509证书来验证节点身份。每个节点启动时需要加载证书和私钥，DDS在建立通信前会互相验证身份。未认证的节点无法加入通信网络。

访问控制定义了每个节点能做什么。比如节点A可以发布/cmd_vel但不能订阅/camera/image，节点B可以订阅/cmd_vel但不能发布。这些权限通过权限策略文件（Permission files）来配置，基于XML格式描述。

数据加密保证传输的数据不被窃听和篡改。SROS2支持AES-GCM-128和AES-GCM-256加密算法，DDS在传输层面对数据进行加密。即使有人抓到了网络包，也无法解析内容。加密粒度的选择也很重要——全量加密开销大，可以只对敏感话题（比如控制指令、用户数据）开启加密，普通传感器数据保持明文。

安全enclave和密钥管理

SROS2引入了"enclave"的概念。一个enclave是一组具有相同安全策略的节点。每个enclave有自己的证书、密钥和权限文件。

创建enclave的流程大致是：先用ros2 security create_keystore创建密钥库，然后用ros2 security create_enclave为每个enclave生成证书和权限文件。节点启动时通过--enclave参数指定自己的enclave路径。

密钥管理是一个容易忽略但非常重要的问题。证书有有效期，需要定期更新。私钥要妥善保管，不能泄露。如果私钥被窃取，攻击者就可以冒充合法节点。实际产品中，通常会用硬件安全模块（HSM）或者TPM芯片来存储密钥。

权限文件的编写需要格外小心。一个常见的错误是给某个节点配了"允许发布所有topic"的权限，结果它意外覆盖了关键数据。最佳实践是最小权限原则——每个节点只给它真正需要的权限。权限文件写错不会在编译时报错，只有在运行时通信被拒绝时才会发现，排查起来很头疼。建议在测试环境充分验证权限配置后再部署到生产环境。

说说我在实际项目中配置SROS2的经验。当时我们给一台医疗机器人做安全配置，大概有15个节点需要证书。用ros2 security create_keystore生成密钥库后，每个enclave的证书文件大概有5个（证书、私钥、权限文件、治理文件、默认权限文件）。15个节点就是75个文件要管理。我们写了一个Python脚本来批量生成和分发证书，省了不少手工操作。另外证书有效期设成了1年，到期前一个月脚本会自动提醒更新。有个坑要提醒大家：SROS2的权限文件里topic名用的是DDS的命名格式，和ROS2的topic名有细微差别（比如DDS用斜杠开头），配错了不会报错但通信就是不通，排查了整整一天才发现这个问题。

实际使用中的挑战

SROS2在理论上是完善的，但实际用起来有不少挑战。

首先是性能开销。加密解密会消耗CPU资源，身份验证会增加通信建立时间。对于高频低延迟的场景（比如1kHz的控制回路），加密带来的延迟可能不可接受。需要在安全和性能之间做权衡。

其次是配置复杂度。每个节点都需要证书和权限文件，节点数量多的时候管理成本很高。而且权限策略的编写需要仔细规划，配错了会导致通信失败，排查起来很麻烦。

第三是生态兼容性。不是所有的DDS实现都完整支持DDS Security。有些第三方节点可能没有适配SROS2的安全机制。在混合使用不同DDS实现时，安全策略的一致性是个问题。

网络安全实践

除了SROS2，实际产品中还有很多网络安全措施可以做。

网络隔离是最基础的手段。把机器人的内部通信网络和外网完全隔离，通过防火墙控制进出流量。很多工业机器人就是这样做的——控制网络和生产网络物理隔离，只允许特定的网关设备跨网段通信。

VLAN划分也是常用方案。把传感器网络、控制网络、监控网络分到不同的VLAN，通过交换机ACL控制跨VLAN通信。即使有人物理接入了某个网口，也只能访问对应VLAN的资源。

端口监控和异常检测也值得做。可以部署一个监控节点，持续检查网络中是否有未授权的DDS参与者（Participant）。如果发现未知证书身份的节点试图加入通信，立即告警。

还有一种思路是对敏感数据做应用层加密，不完全依赖DDS层面的安全机制。比如控制指令在发送前用自定义的加密算法处理，接收端解密后再执行。这样即使DDS层面被攻破，攻击者拿到的也是密文。

功能安全 vs 信息安全

面试中还要注意区分两个概念：功能安全（Functional Safety）和信息安全（Cybersecurity）。

功能安全关注的是系统不会因为故障导致人员伤害，比如传感器失效时机器人要能安全停止、紧急情况下要能切断动力。这通常通过冗余设计、监控机制、安全等级认证（如ISO 13482、IEC 61508）来实现。

信息安全关注的是防止恶意攻击和数据泄露，保护系统和用户数据。SROS2属于这个范畴。

两者有交叉但不完全重叠。一个系统可以是功能安全但信息不安全的（比如内部通信没加密但有冗余监控），也可以是信息安全但功能不安全的（比如通信加密了但没有故障检测机制）。好的产品两个都要考虑。

安全审计和渗透测试

产品上线前做一次安全审计是很有必要的。

安全审计的内容包括：检查所有节点的权限配置是否符合最小权限原则，验证证书是否在有效期内，测试未授权节点是否能接入通信网络，检查日志中是否有敏感信息泄露。

渗透测试可以请专门的安全团队来做。他们会尝试各种攻击手段：注入虚假消息、窃听通信、伪造节点身份、DDoS攻击等。通过渗透测试发现的安全漏洞，在上线前修复，比上线后被攻击者发现要好得多。

定期更新安全补丁也很重要。DDS中间件、操作系统、依赖库都可能爆出安全漏洞。建立一套补丁管理流程，及时评估和安装安全更新。在机器人领域，安全不是一次性的工作，而是持续的过程。

面试中怎么聊

面试官问安全机制，你可以说："ROS2通过SROS2提供身份验证、访问控制和数据加密三个层面的安全保障，基于DDS Security标准实现。使用X.509证书做身份认证，XML权限文件做访问控制，AES-GCM做数据加密。实际部署的挑战主要在性能开销、密钥管理和配置复杂度。功能安全和信息安全是两个不同维度，产品级系统都需要考虑。"即使你的项目没用过SROS2，能讲清楚这些概念和安全设计思路，面试官也会认可你的安全意识。如果能提到你在项目中实际做过的安全措施（哪怕只是网络隔离），会比纯理论更有说服力。安全话题在医疗、自动驾驶、军工类公司面试中出现频率很高。

---

上一篇：第141篇 ROS2日志系统——rcl_logging配置和日志分析

下一篇预告：第143篇 ROS2生产环境部署——从开发到产品的差距