SROS2：ROS2 安全機制

2026-07-18
  • ros2
  • sros2
  • security
  • dds-security

問題定義

前面所有章節寫的 ROS2 通訊，預設完全沒有身分驗證跟加密——任何能連上同一個網路、知道 ROS_DOMAIN_ID 的裝置，都可以自由訂閱任何主題、呼叫任何服務，甚至偽造訊息假裝自己是某個合法節點。這在封閉的開發環境或單機系統裡通常不是問題，但只要系統一旦連上共享網路、或需要對外提供遠端控制能力，這種完全開放的通訊模式就是明顯的安全風險。SROS2 是 ROS2 官方提供的安全擴充，基於 DDS-Security 標準，補上身分驗證、加密、存取控制這幾層防護。

核心概念說明

三層防護：身分驗證、加密、存取控制

SROS2 提供的安全機制大致可以拆成三個獨立但互補的層面：

  • 身分驗證（Authentication）：確保每個加入通訊的節點，都能證明自己的身分是合法的，而不是任何人隨便啟動一個程式就能假冒成系統裡的既有節點。這透過數位憑證（certificate）機制實現，每個節點需要持有由可信任的憑證頒發機構（Certificate Authority, CA）簽發的憑證。
  • 加密（Encryption）：確保通訊內容即使被中途攔截，沒有正確金鑰的第三方也無法解讀實際內容，防止敏感資訊（例如感測器資料、控制指令）被竊聽。
  • 存取控制（Access Control）：即使一個節點通過了身分驗證、能夠合法加入通訊，存取控制原則進一步限制它實際被允許做的操作範圍（能發布哪些主題、能訂閱哪些主題、能呼叫哪些服務），實現最小權限原則——每個節點只被授予完成自己職責所需要的最小權限，而不是預設可以為所欲為。

Keystore：集中管理憑證與金鑰的目錄結構

SROS2 用一個稱為 keystore 的目錄結構，集中存放整個系統的 CA 憑證、以及每個節點各自的身分憑證與金鑰。建立 keystore、幫每個節點產生對應的憑證，是啟用 SROS2 安全機制的第一步，後續每個節點啟動時，會依照環境變數指向的 keystore 位置，載入自己對應的憑證來完成身分驗證與加密設定。

實作範例：幫第 2.2 節的 talker/listener 啟用安全通訊

1. 建立 keystore

bash
ros2 security create_keystore ~/sros2_keystore

預期輸出

text
creating keystore: ~/sros2_keystore
creating: ~/sros2_keystore/enclaves
creating: ~/sros2_keystore/public
creating: ~/sros2_keystore/private

2. 幫 talker 與 listener 各自建立獨立的 enclave（安全身分單位）

bash
ros2 security create_enclave ~/sros2_keystore /talker
ros2 security create_enclave ~/sros2_keystore /listener
text
creating enclave: ~/sros2_keystore/enclaves/talker
creating enclave: ~/sros2_keystore/enclaves/listener

3. 產生存取控制原則檔案，限制 listener 只能訂閱、不能發布

檔案位置：~/sros2_keystore/policy.xml

xml
<?xml version="1.0" encoding="UTF-8"?>
<policy version="0.2.0">
  <enclaves>
    <enclave path="/talker">
      <profiles>
        <topic subject_name="chatter" publish="ALLOW"/>
      </profiles>
    </enclave>
    <enclave path="/listener">
      <profiles>
        <topic subject_name="chatter" subscribe="ALLOW"/>
      </profiles>
    </enclave>
  </enclaves>
</policy>

把這份原則套用到 keystore：

bash
ros2 security generate_policy ~/sros2_keystore/policy.xml

4. 啟用安全機制並啟動節點

bash
export ROS_SECURITY_KEYSTORE=~/sros2_keystore
export ROS_SECURITY_ENABLE=true
export ROS_SECURITY_STRATEGY=Enforce
bash
ROS_SECURITY_ENCLAVE=/talker ros2 run my_package talker
bash
ROS_SECURITY_ENCLAVE=/listener ros2 run my_package listener

預期輸出

正常情況下，兩個節點會像沒有啟用安全機制時一樣正常通訊，唯一的差異是底層通訊已經過身分驗證與加密，肉眼從終端機輸出上其實看不出差異——這正是良好安全機制的特性：對合法使用者透明，只對未授權的存取造成阻礙。

5. 驗證存取控制確實生效

嘗試用 /listener 這個 enclave 的身分，去嘗試發布訊息到 chatter（違反上面設定的存取控制原則）：

bash
ROS_SECURITY_ENCLAVE=/listener ros2 topic pub /chatter std_msgs/msg/String "{data: '未授權的發布'}"

預期輸出

text
[SECURITY ERROR] Not authorized to publish topic 'chatter'

這個明確的拒絕行為，證明存取控制原則確實限制了 /listener 這個身分的實際權限範圍，即使它通過了身分驗證、技術上能加入通訊，仍然無法執行原則裡沒有明確授權的操作。

常見錯誤與除錯技巧

錯誤一：啟用 ROS_SECURITY_ENABLE=true 之後，節點啟動就直接失敗

text
[SECURITY ERROR] unable to load plugin security_transform

原因：最常見的原因是 ROS_SECURITY_ENCLAVE 指向的路徑，在 keystore 裡實際上不存在（例如打錯字，或忘記先執行 create_enclave），節點啟動時找不到對應的憑證資料，安全外掛初始化失敗。

排除方式：確認 ROS_SECURITY_KEYSTORE 跟 ROS_SECURITY_ENCLAVE 兩個環境變數的路徑組合，實際對應到 keystore 目錄底下存在的檔案：

bash
ls ~/sros2_keystore/enclaves/talker
text
cert.pem  governance.p7s  identity_ca.cert.pem  key.pem  permissions.p7s  permissions_ca.cert.pem

如果這個目錄不存在或檔案不齊全，代表 create_enclave 這一步沒有正確完成，需要重新執行。

錯誤二：忘記某個終端機的環境變數設定，導致除錯 CLI 指令完全連不上啟用了安全機制的系統

現象：ros2 topic echo /chatter 在一個新開的終端機裡完全沒有輸出，即使 talker 明顯在正常發布訊息。

原因：呼應上面 FAQ 提到的——啟用 SROS2 之後，每個想要加入這個安全 domain 的參與者（包括你手動執行的除錯指令）都需要有效的身分，如果新開的終端機沒有設定 ROS_SECURITY_ENABLE、ROS_SECURITY_KEYSTORE 等環境變數，這個終端機執行的 CLI 指令，對啟用了安全機制的系統而言就是一個沒有通過身分驗證的未知參與者，自然收不到任何資料。

排除方式：確保每一個需要跟安全系統互動的終端機，都正確設定了完整的一組安全相關環境變數（包含對應這次要用哪個 enclave 身分的 ROS_SECURITY_ENCLAVE），實務上通常會把這些設定寫進一個共用的環境設定腳本，透過 source 載入，避免每個終端機都要手動重複設定、容易遺漏。

小結

SROS2 用身分驗證、加密、存取控制三層機制，補上一般 ROS2 通訊預設缺乏的安全防護，keystore 集中管理所有節點的憑證，存取控制原則能精細限制每個節點被授權的操作範圍。啟用安全機制後，所有想要跟系統互動的參與者（包括日常除錯用的 CLI 指令）都需要正確的身分設定，這是換取安全性所需要接受的額外複雜度。到這裡，第 10 章前三節（容器化部署、資源受限的即時系統、安全機制）處理的都是「怎麼把系統可靠地交付出去」，最後一節要處理另一個現實問題：在模擬環境裡調校好的系統，實際換上真實硬體時該注意什麼。

延伸閱讀

常見問題

faq_01.log
所有 ROS2 系統都應該啟用 SROS2 嗎？
不一定，取決於部署環境的信任程度。如果整個系統跑在一個完全受控、外部無法存取的封閉網路裡（例如單一機器人內部的通訊，完全不對外開放），啟用 SROS2 帶來的額外設定與效能開銷不一定划算；但只要系統會暴露在共享網路、雲端、或任何外部可能觸及的環境（例如透過 Wi-Fi 遠端控制、或多台機器人透過網際網路協同），沒有身分驗證與加密的 ROS2 通訊等於完全公開、任何人都能竊聽甚至偽造指令，這種場景下啟用 SROS2 是基本要求，不是可選項。
faq_02.log
啟用 SROS2 之後，第 2 章介紹的 ros2 topic echo 這類 CLI 工具還能用嗎？
可以，但前提是執行這些 CLI 指令的終端機環境，也要有對應的有效憑證與正確的環境變數設定（下面實作範例會示範），SROS2 的驗證機制對所有想要加入這個安全 domain 的參與者一視同仁，包括你自己手動執行的除錯指令，這也是啟用安全機制後，日常除錯工作流程需要額外適應的地方。
faq_03.log
存取控制原則（access control policy）可以精細到『這個節點只能發布這個主題，不能訂閱其他主題』嗎？
可以，這正是存取控制原則檔案存在的目的——用 XML 格式明確定義每個節點被允許的發布、訂閱、服務呼叫等操作範圍，任何超出授權範圍的操作會被底層直接拒絕。這種精細粒度的控制在多方協作、或需要嚴格限制某個第三方模組權限的場景特別有價值，例如確保一個負責記錄資料的節點只能訂閱，不能意外（或惡意）對關鍵控制主題發布訊息。