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実装仕様の確認が必要"]DDS-Securityで自動的に保護されるのは、基本的にDDSを経由する通信です。独自トランスポートや、実装によってDDS通信をバイパスするプロセス内通信・共有メモリ経路まで保護されるとは限りません。コンポーネントコンテナや共有メモリを使う場合は、実際の経路をRMWとDDS実装の仕様で確認します。
サービス、アクション、parameter service、/rosout、TF関連トピックなども、名前だけで保護状態を判断できません。最終的なガバナンス設定、権限ルール、実装の動作を確認する必要があります。
保護レベルの比較
| 構成 | 認証 | 完全性 | 機密性 | 主な特徴 | 判断の観点 |
|---|---|---|---|---|---|
| 無効 | なし | なし | なし | 比較用の基準状態 | 開発時の比較に利用 |
| 認証中心 | あり | 限定的 | なし | 参加者の本人性を確認 | 内容の秘匿が要件でない場合 |
| 完全性保護 | あり | あり | なし | 改ざん検知を重視 | 内容を読まれるリスクを許容できる場合 |
| RTPSメタデータ保護 | あり | 設定による | 設定による | 通信制御情報を保護 | 発見やメタデータの露出を抑えたい場合 |
| トピックデータ暗号化 | あり | あり | あり | データの秘匿性を確保 | 制御指令や機密センサー情報を守る場合 |
| 全面保護 | あり | あり | あり | 複数の保護対象を強化 | 性能・鍵管理負荷を許容できる本番境界 |
表の具体的なコストや対応範囲は実装によって異なります。DDS-Security仕様はプラグインAPIとセキュリティモデルを定義しますが、暗号アルゴリズム、設定ファイル、証明書の扱い、対応機能はDDSベンダーやRMW実装ごとに同一ではありません。
性能評価の進め方
性能影響は、認証ハンドシェイクや発見時の処理、RTPSメタデータ保護、トピックデータの署名・暗号化によって変わります。さらに、暗号化方式、暗号アクセラレーション、メッセージサイズ、通信頻度、参加者数、CPUによっても変動します。標準的な単一のオーバーヘッド値を前提にしないことが大切です。
比較条件は、少なくとも次のように分けます。
- セキュリティ無効
- 認証のみ
- 完全性保護
- トピックデータの暗号化
- 発見情報やRTPSメタデータの保護
同じノード構成、QoS、RMW、DDS実装、メッセージサイズ、参加者数で比較し、p50・p95・p99レイテンシ、ジッタ、スループット、CPU・メモリ使用量、帯域、起動・発見時間、deadline missed、必要に応じて電力を測定します。
flowchart LR start["Participant起動"] --> handshake["証明書検証・認証ハンドシェイク"] handshake --> authz["権限検証"] authz --> discovery["発見情報の保護"] discovery --> endpoint["Endpointの許可"] endpoint --> steady["定常通信"] steady --> protect["トピックデータの署名または暗号化"] startupMetric["起動時間"] -.-> start handshakeMetric["認証・発見時間"] -.-> handshake discoveryMetric["発見時間"] -.-> discovery latencyMetric["p50・p95・p99レイテンシ\nジッタ"] -.-> steady resourceMetric["CPU・メモリ・帯域\nスループット"] -.-> protect deadlineMetric["deadline missed"] -.-> steady condition["固定する評価条件\nROS 2ディストリビューション\nRMW・DDS実装\nQoS・メッセージサイズ\n参加者数・ハードウェア\n暗号アクセラレーション"] -.-> handshake condition -.-> protect
制御系では平均値だけでなくp95やp99、ジッタ、deadline missedを重視します。大容量・高頻度の通信では帯域とCPU、参加者が多い構成では起動・発見時間を確認します。暗号アクセラレーションの有無も条件に含め、実運用に近い負荷で判断します。
運用負荷と実装上の注意
評価対象は初回の設定だけではありません。CA・証明書・秘密鍵の発行と保管、ガバナンスおよび権限ファイルの署名・配布、エンクレーブ単位の権限変更、期限切れ・更新、障害時の診断、監査ログ、複数RMW間の互換性まで確認します。
本番では、信頼境界ごとにエンクレーブと権限を分け、必要なトピックだけを許可する最小権限を基本にします。ロボット内部と外部ネットワークなどで境界が異なる場合、同一エンクレーブにまとめる設計が適切かを再検討します。
ROS 2ディストリビューションやRMW実装のバージョンによって、設定項目、CLI、既定動作は変わり得ます。採用するディストリビューション、RMW、DDSベンダーの組み合わせを固定して確認してください。Fast DDSとCyclone DDSでも、証明書、XML、プラグイン構成、実行時機能の扱いは異なります。
移行時に緩和モードを使う場合でも、本番ではセキュリティ資材を読み込めないノードが通信を継続できる設定を避けます。失敗時に起動または接続を拒否する運用を検討し、資材不足を見逃さないようにします。
採用判断の基準
- 保護したい信頼境界と、DDSを通る通信経路を特定する。
- 参加者、ドメイン、トピック、パーティション単位の最小権限を定義する。
- 発見情報、RTPSメタデータ、トピックデータごとに、署名か暗号化かを選ぶ。
- ROS 2ディストリビューション、RMW、DDS実装、ハードウェアを固定する。
- 性能測定と、証明書更新・障害復旧を含む運用試験を行う。
機密性や改ざん耐性が必要で、鍵と権限を継続管理できるなら、DDS-Securityを本番適用する価値があります。一方、性能要件を測らず全面保護を選んだり、鍵の更新手順を定めなかったりすると、導入後に運用がボトルネックになり得ます。
まとめ
ROS 2のDDS-Security設計では、認証・認可・暗号化を分け、ガバナンス設定と権限ファイルで保護範囲を明示します。DDSを経由しない経路は別途確認し、性能は保護レベル別にp95・p99、CPU、帯域、発見時間などで測定します。最小権限、エンクレーブ分離、資材更新、実装互換性まで検証して、本番採用を判断します。
参考情報
- OMG DDS Security Version 1.1
- ROS 2 Security
- Introducing ros2 security（ROS 2 Jazzy）
- Security — Fast DDS documentation
- Security — Eclipse Cyclone DDS documentation
- Using Security in ROS 2
性能と運用の両面を測って初めて、DDS-Securityの適用範囲を安全に決められます。
AI利用に関する注記
本サイトの記事は、複数のAIエージェントによる調査・執筆・レビューを経て公開しています。正確性と品質の向上に努めていますが、内容については必ず一次情報をご確認ください。
