📚 课程目录第3章 DDS安全规范概览

3. DDS安全规范概览

在ROS2中，节点之间的通信默认建立在DDS之上，而DDS本身最初是为开放、高性能的实时数据分发设计的，并不自带安全能力。为了让机器人系统中的话题、服务、参数在不可信网络中依然可控，OMG组织发布了DDS Security 1.1规范。它并不是一个独立的新中间件，而是在DDS原有通信模型之上叠加的一套安全框架，通过标准化插件接口，把身份认证、访问控制、加密和审计日志等能力注入到DDS的发现与数据收发流程中。

一、DDS Security 1.1的定位与核心思想

DDS Security 1.1的核心思想是“策略驱动 + 插件实现”。规范定义了安全模型、策略语言、插件接口和交互协议，但不限定具体算法实现。这样，不同DDS厂商（如Fast DDS、Cyclone DDS、RTI Connext）可以在同一套安全语义下互操作。它主要解决四类问题：

身份可信：确认通信对端确实是它声称的DomainParticipant。
权限受控：限制某个参与者能发布/订阅哪些主题、能调用哪些服务。
数据保密与完整：对敏感数据加密，并防止篡改和重放。
行为可审计：记录安全相关事件，便于排障与合规。

DDS Security 1.1不是“打开开关就安全”，而是需要为每个DomainParticipant配置身份证书、权限文档和治理文档，三者共同决定安全行为。

二、安全插件架构：五个核心插件

DDS Security 1.1把安全能力拆分为五个可替换的插件，它们通过Service Plugin Interface（SPI）挂载到DDS实现中。下图展示了这些插件在DDS通信栈中的位置与协作关系：

这五个插件中，认证插件负责在DomainParticipant发现阶段完成双向身份验证，通常基于PKI证书和挑战-响应握手；访问控制插件依据治理文档和权限文档，决定是否允许某个参与者加入域、发布或订阅特定主题；加密插件对RTPS子消息进行加密、解密、签名和验证；日志插件记录认证失败、权限拒绝、解密异常等事件；数据标签插件则把安全标签附加到数据上，供上层策略引擎做更细粒度判断。

三、认证与访问控制的工作流程

以两个ROS2节点首次通信为例，安全流程大致如下：

节点A和节点B各自加载身份证书、私钥、CA证书链，以及治理文档和权限文档。
在DDS发现阶段，双方通过认证插件交换证书并验证签名，完成双向身份确认。
认证通过后，访问控制插件检查双方权限文档：A是否允许发布/cmd_vel，B是否允许订阅该话题。
若权限匹配，双方协商加密密钥，后续RTPS数据子消息使用加密插件保护。
整个过程中，日志插件按配置记录关键事件，便于审计。

在Fast DDS中，这些行为由DomainParticipantQos中的properties策略控制，典型配置包括dds.sec.auth.plugin、dds.sec.access.plugin、dds.sec.crypto.plugin等属性。

四、典型配置与代码片段

下面是一个ROS2节点启用DDS Security的简化配置示例，展示了安全插件的挂载方式：

<participant profile_name="secure_participant">
  <domainId>0</domainId>
  <propertiesPolicy>
    <properties>
      <property>
        <name>dds.sec.auth.plugin</name>
        <value>builtin.PKI-DH</value>
      </property>
      <property>
        <name>dds.sec.auth.builtin.PKI-DH.identity_ca</name>
        <value>file://certs/ca.pem</value>
      </property>
      <property>
        <name>dds.sec.auth.builtin.PKI-DH.identity_certificate</name>
        <value>file://certs/nodeA.pem</value>
      </property>
      <property>
        <name>dds.sec.access.plugin</name>
        <value>builtin.Access-Permissions</value>
      </property>
      <property>
        <name>dds.sec.access.builtin.Access-Permissions.permissions_ca</name>
        <value>file://certs/ca.pem</value>
      </property>
      <property>
        <name>dds.sec.crypto.plugin</name>
        <value>builtin.AES-GCM-GMAC</value>
      </property>
    </properties>
  </propertiesPolicy>
</participant>

这段配置说明：认证使用内置PKI-DH插件，访问控制使用内置Access-Permissions插件，加密使用AES-GCM-GMAC算法。实际部署时，证书、治理文档和权限文档需要由安全管理员统一签发和分发。

五、安全插件能力对比与常见误区

插件	主要职责	关键输入	典型失败表现
认证插件	双向身份验证、握手、密钥交换	身份证书、私钥、CA证书链	节点无法发现对端，日志出现认证失败
访问控制插件	域加入、主题发布/订阅权限判定	治理文档、权限文档	能发现但无法匹配，权限拒绝
加密插件	数据加密、签名、完整性校验	会话密钥、加密算法套件	数据解密失败、报文被丢弃
日志插件	记录安全事件与审计信息	日志级别、输出目标	无日志或日志过多影响性能
数据标签插件	为数据附加安全标签	标签策略、数据分类	标签缺失导致策略无法匹配

常见误区一：认为只要启用加密插件就安全了。实际上，如果认证和访问控制没有正确配置，攻击者仍可能以合法身份加入域。误区二：证书和权限文档长期不更新，导致离职节点仍可通信。误区三：把治理文档设置为ALLOW却忘记限制主题，造成权限过宽。

六、复盘：如何选择与落地

在ROS2项目中落地DDS Security 1.1，建议按以下顺序推进：先明确安全边界，确定哪些域、哪些话题需要保护；再生成CA和节点证书，编写治理文档与权限文档；然后在小规模测试环境中启用认证和访问控制，观察发现与匹配是否正常；最后再开启加密插件，评估CPU开销和延迟影响。日志插件应尽早启用，但生产环境要控制日志级别，避免高频安全事件拖慢实时通信。

需要特别注意的是，DDS Security 1.1是标准框架，不同DDS实现的支持程度和配置细节存在差异。在ROS2中，Fast DDS对安全插件支持较完整，Cyclone DDS也在持续完善。实际选型时，应结合中间件版本、证书管理工具和运维能力综合评估，而不是只看规范本身。