8.2 SROS2安全通信

8.2 SROS2 安全通信

本节摘要：第 1 章说过 ROS1 的网络是"谁接入谁可信"；ROS2 借助 DDS Security 标准补上了这一课——节点用证书证明身份，按策略决定谁能说什么话，必要时全程加密。本节讲清 SROS2 的三能力与落地步骤，给一张"要不要上安全"的决策表，并用实测视角交代性能代价。安全不是开关，是一笔要算清的账。

先回答"要不要"，再回答"怎么开"

看到安全话题，工程直觉的第一反应应当是"我的场景需要吗"。给一个诚实的答案：多数室内实验与原型不需要开——办公网络里的避障机器人，威胁模型撑不起安全开销。三类场景则强烈建议开：机器人与办公网共域（访客 Wi-Fi 能摸到机器人）、多租户或公共区域部署（ mall 里的服务机器人）、任何有法规或保险要求的场景（医疗、物流冷链）。决策的实质是威胁建模：你的网络里有谁、他们能做什么、做了会怎样。答案模糊时，倾向开——安全更像安全带而不是刹车。

一、三能力与底层事实

SROS2 封装的是 DDS Security 标准，提供三种可独立启用的能力。认证：每个节点持有一份证书，入网时互相验明正身——陌生人直接无法加入发现，第 1.3 节那种"接入即看见"的默认变成"接入先查证"。访问控制：策略文件声明"哪个节点可以发布或订阅哪些话题"，越权的读写被中间层拒绝——即便节点身份是真的，也只能说它该说的话。加密：话题数据在传输层加密，抓包只能看到密文。

一个底层事实帮助你理解它的机制与开销来源：DDS Security 在发现与数据两个阶段插入握手与校验，认证发生在参与者建立时（一次性），加解密发生在每条消息上（持续性）。所以认证的开销是冷启动成本，加密的开销是持续税。三者可以只开其一——只要认证不要加密的组合在内部网络里很常见，身份管住了，数据明文的风险可控。

二、落地步骤：密钥库与策略

SROS2 的工具链把证书体系包装成了三条命令的故事：

# 第一步：建密钥库（一次性，产线环境要离线保管根密钥）
ros2 security create_enclave my_keystore

# 第二步：为每个节点签发身份与权限
ros2 security create_key my_keystore /patrol_controller
ros2 security create_permission my_keystore /patrol_controller \
  permissions.patrol.xml

# 第三步：节点带安全配置启动
ros2 run my_pkg controller --ros-args --enclave /patrol_controller \
  -r ROS_SECURITY_KEYSTORE:=my_keystore
# 或全局开关：ROS_SECURITY=true 环境变量统一启用
​

策略文件是访问控制的正文，它的思路类似防火墙规则——按节点声明允许的话题与方向：

<policy version="1.2.0">
  <enclaves>
    <enclave path="/patrol_controller">
      <profiles>
        <profile node="patrol_controller">
          <topics publish>
            <topic>/cmd_vel</topic>
          </topics>
          <topics subscribe>
            <topic>/scan</topic>
          </topics>
        </profile>
      </profiles>
    </enclave>
  </enclaves>
</policy>
​

这份策略读作：巡检控制节点可以发 cmd_vel、收 scan，别的一概不行。写成清单的过程本身就是一次很好的架构审查——每个节点真正需要哪些话题，很多团队写完策略才发现自己的节点权限远比想象的宽。最小权限原则在 ROS2 里落地的最好练习，就是写这份文件。

三、性能代价与实施策略

安全不是免费的，给一个量级感（以主流硬件、AES 加速可用为前提）：只开认证，启动期的握手增加数百毫秒，运行期开销可忽略；开加密，高频大消息（点云、图像）的吞吐下降约一到两成，CPU 占用上升明显。控制类小消息（几十字节的指令）加密的绝对开销很小——按消息算而非按字节算，小消息是"便宜"的加密对象。

实施策略按这个量级分层：第一层全系统只开认证（冷启动代价，几乎无运行期税）；第二层给关键话题加访问控制（策略文件，无运行期税）；第三层只对小而关键的话题开加密（cmd_vel 这类指令流），大流保持明文或走网络层加密（TLS 网关、IPsec）。三层递进让安全开销始终花在刀刃上。

💡 关键直觉：安全的性能税是"按字节"的，而风险是"按话题"的。把加密的粒度对齐到话题的重要度，就能用有限预算买到最大风险削减。

四、安全落地的演练：一个最小可信部署

理论与分层都有了，值得走一遍最小可信部署的完整过程，把三步命令变成一次可复查的实操。场景：一台服务机器人在商场公共区域作业，威胁模型是"访客设备可能接入同一无线网"。按 8.2 开头的决策表，这类场景至少要开到第二层（认证加访问控制），指令话题加第三层加密。

实施顺序：先在离线机器上建密钥库并签发全部节点身份（离线签发是根密钥纪律）；把密钥库与策略文件纳入配置管理（8.3 节的"配置与镜像分离"），随镜像分发到机器；逐节点启用——先非关键节点灰度一周，确认发现与通信行为无回归，再覆盖控制节点；最后给 cmd_vel 一类指令话题单独开加密策略。

灰度期间的观测重点有两个：一是发现时延——认证握手会让首批互见时间增加数百毫秒，Launch 里的就绪编排要能容忍；二是权限拒绝日志——策略文件写漏一个合法话题时，症状是该收的数据收不到，日志里能看到权限拒绝记录。这两个观测点都过稳，安全层才算真正"装完了"。

这次演练的总结论值得记住：安全部署的难点从来不是命令，而是顺序与观测——离线签发保根密钥安全，灰度保可用性，日志观测保可诊断性。三条都做到，SROS2 才从"开了"变成"落地了"。

本节要点回顾

• 先做威胁建模再决定开不开：共域网络、公共区域、强合规场景倾向开；
• 三能力可独立启用：认证管身份、访问控制管权限、加密管内容，开销一次比一次大；
• 落地三步：建密钥库、按节点签身份与权限、带配置启动；
• 写策略文件是最小权限的实战练习，顺便完成一次架构审查；
• 分层实施：认证全开、控制管关键话题、加密只给小而关键的指令流。

信任关过了。下一关是一致性：同一套系统怎么保证在十台机器上装出同一个样子。