ROS 2のセキュリティ設計入門：DDS-Securityの適用範囲と性能評価

Sat, 26 Sep 2026 13:45:27 +0900

ROS 2の通信保護では、暗号化の有無だけでなく、どの情報を誰に許可するかまで設計する必要があります。

先に結論

ROS 2の通信を保護する場合は、SROS 2を入口としてDDS-SecurityをDDSのDomainParticipantとRTPS通信に適用します。ただし、すべての通信を一律に暗号化するのではなく、発見情報、RTPSメタデータ、トピックデータごとに保護レベルを選ぶことが重要です。

性能は「有効・無効」の二択では評価できません。認証のみ、完全性保護、暗号化、発見情報の保護などを段階的に比較し、採用するROS 2ディストリビューション、RMW実装、DDS実装、メッセージ特性、ハードウェアを固定して測定します。運用負荷も、初期設定だけでなく証明書・秘密鍵・権限ファイルの更新や障害対応まで含めて判断します。

なぜ適用範囲の設計が必要か

ロボットでは、センサーデータ、制御指令、状態情報などがDDSを通じて交換されます。通信相手が正しい参加者か、特定のノードにpublishやsubscribeを許すか、内容を第三者から読めなくするかは別々の課題です。認証に成功した参加者へ、すべてのトピックへのアクセスを許可する必要はありません。

また、「暗号化を有効にした」という説明だけでは保護範囲が分かりません。DDS-Securityでは、発見情報、liveliness、RTPSメタデータ、トピックデータに異なる保護レベルを指定できます。署名にとどめるか暗号化まで行うかは、機密性、完全性、性能、運用負荷を合わせて決めます。

用語と役割

DDS-Securityは、DDSのDomainParticipantとRTPS通信層に適用されるセキュリティモデルです。認証、アクセス制御、暗号、ロギングなどをプラグインとして構成します。

認証は参加者の識別と相互認証を担います。アクセス制御、つまり認可は、ドメイン、トピック、パーティションなどについて、その参加者がどの操作を実行できるかを判定します。暗号プラグインは、通信の暗号化や完全性保護を担当します。認証できたことと、アクセスを許可することは同じではありません。

ROS 2ではSROS 2がDDS-Securityを利用するツールと統合機能を提供します。キーストアに証明書、秘密鍵、ガバナンス文書、権限文書などを格納し、エンクレーブをノードの論理的なセキュリティ境界として利用します。実行時には、キーストア、エンクレーブ、セキュリティ戦略などを環境変数やCLIで指定します。

内部の仕組みと適用範囲

処理の流れは、参加者の起動、証明書の検証と認証ハンドシェイク、権限検証、発見情報の保護、エンドポイントの許可、トピックデータの署名または暗号化という順序で整理できます。ガバナンス設定はドメインや保護対象の方針を定め、権限ファイルは参加者やエンクレーブ単位のアクセス範囲を定めます。

flowchart LR
  node["ROS 2ノード"] --> rclrmw["rcl / RMW"]
  rclrmw --> dp["DDS DomainParticipant"]

  subgraph sec["DDS-Security"]
    auth["認証プラグイン"]
    access["アクセス制御プラグイン"]
    crypto["暗号プラグイン"]
  end

  dp --> auth
  dp --> access
  dp --> crypto

  subgraph ks["キーストア"]
    cert["Identity certificate"]
    key["Private key"]
    gov["Governance文書"]
    perm["Permissions文書"]
  end

  cert --> auth
  key --> auth
  gov --> access
  perm --> access

  auth --> participant["参加者の識別・相互認証"]
  access --> endpoint["ドメイン・トピック・パーティションの権限"]
  crypto --> discovery["発見情報・RTPSメタデータ"]
  crypto --> topic["トピックデータ"]

  participant --> rtps["DDSを経由するRTPS通信"]
  endpoint --> rtps
  discovery --> rtps
  topic --> rtps

  bypass["DDSをバイパスする経路\n独自トランスポート・実装依存のプロセス内通信など"] -.-> out["DDS-Securityの適用範囲外の可能性\n実装仕様の確認が必要"]

ROS 2のDDS通信に対するDDS-Securityの適用範囲と、キーストア資材およびDDSを経由しない経路の扱いを示します。

DDS-Securityで自動的に保護されるのは、基本的にDDSを経由する通信です。独自トランスポートや、実装によってDDS通信をバイパスするプロセス内通信・共有メモリ経路まで保護されるとは限りません。コンポーネントコンテナや共有メモリを使う場合は、実際の経路をRMWとDDS実装の仕様で確認します。

認証 on Physical AI Hub

ROS 2のセキュリティ設計入門：DDS-Securityの適用範囲と性能評価

先に結論

なぜ適用範囲の設計が必要か

用語と役割

内部の仕組みと適用範囲