SROS2 설치 및 초기 설정
개요
ROS2에서 보안을 적용하기 위해서는 DDS 계층의 보안 기능을 활용하고, 이를 편리하게 사용할 수 있도록 제공되는 툴이 바로 SROS2(Secure ROS2)이다. ROS1 시절에도 SROS라는 패키지가 있었지만, ROS2부터는 DDS의 보안 확장(Security Extension)을 활용할 수 있게 되면서 SROS2가 좀 더 체계적으로 제공된다. 이번 장에서는 ROS2 Humble 버전을 기준으로 SROS2를 설치하고, 기본적으로 설정해야 할 항목들을 엄밀히 살펴본다.
준비 사항
SROS2를 이용하기 위해서는 다음과 같은 환경이 준비되어 있어야 한다.
ROS2 Humble가 설치된 Ubuntu (일반적으로 20.04 이상) 환경
DDS 보안 플러그인을 지원하는 RTPS 구현체 (Fast DDS, Cyclone DDS 등)
Python 3.8 이상 (ROS2 패키지 빌드 및 스크립트 실행을 위해 필요)
SROS2 설치 전, 현재 ROS2 버전 및 DDS 설정을 확인할 필요가 있다. 예를 들어, Cyclone DDS를 사용 중이라면 $ apt list --installed | grep cyclonedds 명령어를 통해 설치 여부를 확인한다.
apt list --installed | grep cyclonedds만약 Fast DDS를 사용한다면 $ apt list --installed | grep fastdds 명령어로 확인한다.
apt list --installed | grep fastddsSROS2 설치
ROS2 Humble 환경에서 SROS2는 일반적으로 ros-humble-sros2 패키지로 제공된다. 다음과 같이 설치할 수 있다.
sudo apt update
sudo apt install ros-humble-sros2설치가 완료되면, sros2라는 명령어를 사용할 수 있어야 한다. 다음 명령어로 버전을 확인할 수 있다.
sros2 --help만약 sros2 명령어가 동작하지 않는다면, 터미널에서 ROS2 설정이 올바르게 되어 있는지 확인한다. 예를 들어, 다음과 같이 ROS2 Humble 환경을 미리 설정해야 한다.
별도의 워크스페이스를 사용 중이라면, colcon build 후에 source install/setup.bash 등의 명령어로 워크스페이스도 불러온다.
보안 디렉토리 구조
ROS2에서 보안을 활성화하면, 각 노드는 보안 아티팩트(키, 인증서 등)를 저장하는 보안 디렉토리를 참조한다. SROS2를 통해 생성되는 기본 디렉토리 구조는 다음과 같다.
enclaves/: ROS2 보안 도메인을 구분하는 디렉토리 구조로, 실제 키와 인증서가 저장되는 폴더 구조가 여기에 생성된다.
keys/: 각 엔클레이브(Enclave)에 대한 비공개 키(Private Key)와 공개 키(Public Key)를 포함한다.
policies/: XML 형식 등의 보안 정책(Access Control Policy)이 저장된다.
이때 각 노드가 액세스할 수 있는 토픽, 서비스를 정의한 정책 파일이 필요하며, 이 파일은 ROS2 보안에서 매우 중요한 역할을 한다.
작업공간에서 SROS2 소스 빌드 (선택)
표준 패키지로 설치한 ros-humble-sros2 외에, 최신 소스 코드를 직접 빌드하여 사용하고 싶다면, 다음 단계를 수행한다.
워크스페이스 내 src 폴더에서 SROS2를 내려받는다.
의존성을 설치하고, 빌드한다.
sros2 명령어가 동작하는지 확인한다.
빌드가 잘 되었다면, 위 명령어에 대한 사용법이 출력될 것이다.
보안 정책 파일 개념
SROS2를 활용하기 위해서는 보안 정책(Security Policy) 개념을 이해해야 한다. 보안 정책은 크게 두 가지 요소로 구성된다.
Authentication: 노드를 인증하기 위한 인증서, 키 등의 자격 증명.
Access Control: 토픽, 서비스, 액션에 대한 접근 권한을 정의하는 XML 정책 파일.
ROS2 DDS 보안 모델에서 액세스 컨트롤은 DDS 보안 정책을 XML 형식으로 작성하여 적용한다. 실제로는 다음과 같은 XML 구조로 작성하게 된다.
이 파일에서 특정 노드(Identity)가 어떤 토픽에 대해 퍼블리시/서브스크라이브 권한을 가지는지 선언한다. 이는 보안을 적용하는 핵심 중 하나다.
인증서와 키 생성
SROS2 환경에서 보안을 활성화하려면, 각 노드는 적절한 인증서(Certificate)와 키(Key)를 통해 자신을 증명하고, 보안 정책에 따라 DDS 통신을 수행하게 된다. 보안 정책 파일(Access Control Policy)과 더불어, 노드의 암호화 통신을 위한 공개 키와 비공개 키, 그리고 노드 신뢰를 위한 인증서가 필요하다. 이를 자동화하는 스크립트가 sros2 명령어에 포함되어 있으며, 가장 기본적으로는 CA(Certificate Authority)를 먼저 생성하고, 각 노드별로 인증서를 발급받는 순서로 진행한다.
1. CA 생성
보안 통신 구조에서 CA는 인증서를 발급해 주는 루트 인증기관(Root CA) 역할을 한다. sros2 툴은 CA 생성에 필요한 파일을 자동으로 생성해 준다. 아래 예시는 기본적으로 $HOME/.ros/sros2/ 폴더에 CA 관련 파일들을 생성한다.
위 명령을 실행하면 다음과 유사한 파일 구조가 생성된다.
ca.cert.pem: CA의 인증서
ca.key.pem: CA의 비공개 키
CA 생성 시, CA 명이나 유효기간 등을 추가 옵션으로 지정할 수 있다. 예를 들어 다음과 같은 옵션들을 확인해 볼 수 있다.
2. 노드별 인증서 생성
노드별 엔클레이브(Enclave)를 생성하면서, 인증서와 키를 발급받는다. 일반적으로 CA 디렉토리와 별개의 출력 폴더를 지정하여, 노드별 인증서를 체계적으로 관리한다. 예시로, enclave_example이라는 이름으로 엔클레이브를 생성해보자.
이 명령어를 실행하면, 다음과 같은 디렉토리 구조가 생긴다. (기본적으로 ~/.ros/sros2/enclave_example/ 경로에 생성)
cert.pem:
enclave_example엔클레이브의 인증서key.pem:
enclave_example엔클레이브의 개인 키identity_ca.cert.pem: 노드용 CA 인증서
identity_ca.key.pem: 노드용 CA 개인 키
실제 생성된 인증서(cert.pem)와 키(key.pem)는 노드에서 보안 통신에 사용되며, CA 인증서로부터 서명(Signature)을 받은 상태이므로, 인증 신뢰 체인(Trust Chain)이 형성된다.
3. 보안 정책 파일 생성
노드별 권한 설정을 위해 XML 형식의 보안 정책(Access Control Policy) 파일을 작성해야 한다. sros2 툴은 템플릿을 생성하는 기능을 제공한다. 예를 들어, 아래와 같이 sros2 create_policy 명령어로 정책 템플릿을 생성할 수 있다.
이렇게 하면, my_policy.xml 파일이 생성되며, 기본적인 구조만 포함한다. 생성된 XML 내부에서 토픽, 서비스, 액션, 파라미터 등에 대한 접근 권한을 직접 명시해야 한다. 예시 구조는 다음과 같다.
이 정책 파일을 토대로, 실제 노드가 퍼블리시/서브스크라이브 할 수 있는 대상 리소스를 제어할 수 있다. 정책 파일이 완성된 후에는, 해당 정책과 연결된 엔클레이브가 올바르게 접근 권한을 가져야 한다.
4. 보안 아티팩트 적용
엔클레이브별로 발급된 인증서와 키, 그리고 정책 파일을 함께 묶어 DDS 보안을 활성화하기 위해 다음 과정을 수행한다.
CA 인증서: 전체 노드가 신뢰할 수 있는 상위 인증서.
엔클레이브 인증서: 노드별로 부여된 개별 인증서.
엔클레이브 비공개 키: 노드별로 엄격히 보관되는 비밀 키.
액세스 컨트롤 정책 파일: XML 형식의 정책 선언.
이 모든 아티팩트를 보안 디렉토리(Security Artifacts Directory)에 적절히 배치해야 한다. 일반적으로 다음과 같은 계층 구조를 사용한다.
위 구조에서 permissions.xml 파일이 정책 파일이며, 실제 이름은 policy.xml, permissions.xml, allow.xml 등으로 다양하게 지정할 수 있다. 중요한 것은 DDS 보안에서 참조하는 표준 이름과 위치에 맞춰 배치하거나, XML 태그 내에서 적절히 참조할 수 있도록 구성해야 한다.
보안 모드 활성화
ROS2에서 보안을 활성화하기 위해서는 ROS2 런타임이 DDS 보안 확장을 사용할 수 있도록 설정해야 한다. 이때 중요한 환경 변수(ROS_SECURITY_*)를 지정하면, 노드 실행 시 보안 관련 파일(인증서, 정책 파일 등)을 자동으로 참조하게 된다.
일반적으로 다음 변수를 설정하여 노드를 실행한다.
ROS_SECURITY_ENABLE:
true로 설정하면 보안을 활성화한다.ROS_SECURITY_STRATEGY:
Enforce로 설정하면, 보안 아티팩트가 없거나 유효하지 않은 노드는 통신을 차단한다.Permissive로 설정하면, 보안 아티팩트가 없는 노드도 통신할 수 있지만 보안은 적용되지 않는다.ROS_SECURITY_KEYSTORE: 노드가 사용할 CA, 인증서, 키, 정책 등이 위치한 보안 디렉토리 경로를 지정한다.
위와 같은 환경 변수들을 설정한 뒤, ros2 run 명령어 등을 통해 노드를 실행하면 DDS 보안이 활성화된 상태에서 통신을 수행한다.
예:
만약 엔클레이브(Enclave)를 여러 개 사용해야 한다면, 각 노드별로 고유 엔클레이브 폴더를 생성해 사용하거나, 노드 실행 시점에 --enclave 옵션을 활용할 수도 있다.
여러 엔클레이브(Enclaves) 사용
ROS2에서 보안 설정을 세분화하기 위해, 노드마다 독립적인 엔클레이브를 부여할 수 있다. 엔클레이브 경로가 다르면 인증서와 키, 정책 파일 역시 독립적으로 운영 가능하다.
예시 시나리오: 물리 로봇 제어 노드와 센서 데이터 노드를 분리하여, 서로 다른 보안 정책을 적용하고 싶을 때
~/sros2/robot_control폴더: 로봇 제어 노드에 대한 인증서, 정책~/sros2/robot_sensing폴더: 센서 노드에 대한 인증서, 정책
엔클레이브 구분을 위해서는 다음과 같이 노드를 실행할 때, --enclave 옵션 또는 환경 변수를 활용한다.
이때, ROS_SECURITY_KEYSTORE를 각각의 엔클레이브 폴더로 지정해 두거나, SROS2가 만들어 놓은 표준 디렉토리 구조에 맞춰 노드를 실행해야 한다. 더 세부적으로는 ROS2의 rmw_fastrtps 또는 rmw_cyclonedds 보안 구현체가 관련 폴더를 어떻게 참조하는지 확인해야 한다.
실행 및 검증
보안 디렉토리 확인:
~/.ros/sros2/<엔클레이브>경로에cert.pem,key.pem,permissions.xml등 보안 아티팩트가 있는지 확인한다.환경 변수 설정:
ROS_SECURITY_ENABLE,ROS_SECURITY_STRATEGY,ROS_SECURITY_KEYSTORE등이 올바르게 설정되어 있는지 확인한다.노드 실행:
ros2 run ...명령어를 사용하여 노드를 실행한다.통신 확인:
ros2 topic echo,ros2 topic list등 명령어로 통신이 정상적으로 이루어지는지 확인한다. 보안이 적용된 상태라면, 노드들이 서로 신뢰할 수 없을 때 통신이 차단된다.
만약 설정이 올바르지 않다면, DDS 통신이 이루어지지 않거나 노드가 제대로 동작하지 않을 수 있다. 이 경우, 다음과 같은 절차로 문제를 진단한다.
환경 변수 체크:
printenv | grep ROS_SECURITYCA 인증서와 노드 인증서, 키의 유효성 검사
permissions.xml정책에서 해당 노드와 토픽이 허용되어 있는지 확인DDS 보안 로깅 옵션 또는
RMW_SECURITY_LOG_LEVEL설정을 통해 디버깅 메시지를 확인
참고: 보안 설정 자동화
개발 환경에서 매번 환경 변수를 수동으로 설정하기 번거롭다면, setup.bash 스크립트에 미리 지정해 두거나, 별도의 .sh 파일을 만들어 로드하는 방식을 활용할 수 있다. 예를 들어, 다음과 같이 secure_setup.sh를 만들어 두고 필요할 때마다 source 명령어로 불러오면 편리하다.
이렇게 하면 간단한 명령어로 보안 모드를 활성화하고, 노드를 실행할 수 있다.
추가적인 보안 설정
ROS2 보안은 DDS 계층의 다양한 설정 옵션을 통해 세밀하게 구성될 수 있다. 여기서는 SROS2를 기반으로, 몇 가지 추가적인 보안 항목들을 간략히 살펴본다.
보안 로깅(Log)
DDS 보안에서는 인증 실패나 정책 위반이 발생했을 때 로깅 정보를 남길 수 있도록 다양한 옵션을 제공한다. 예컨대, rmw_fastrtps_cpp나 rmw_fastrtps_dynamic_cpp를 사용 중이라면, 환경 변수를 통해 디버깅 메시지를 확인할 수 있다.
이 변수를 debug 수준으로 설정하면, 노드가 DDS 보안 인증을 시도할 때의 과정을 좀 더 상세히 확인할 수 있다. 이를 통해 인증서가 유효한지, 정책이 올바르게 적용되는지 등을 진단할 수 있다.
요청/응답(Service) 보안
ROS2는 토픽만이 아니라 서비스도 DDS를 통해 통신한다. 서비스 호출(Request)과 응답(Response)은 기본적으로 DDS RPC(Remote Procedure Call) 개념 위에서 동작하며, 보안이 활성화되면 이들 역시 마찬가지로 인증과 권한 확인 과정을 거친다.
보안 정책 파일(XML)에서 토픽이 아닌 서비스 이름에 대해 접근 제어를 지정할 수 있다. 예시를 들면, 특정 노드가 /my_robot/move 서비스만을 호출할 수 있도록 정책을 작성한다.
이렇게 하면, 보안이 적용된 상태에서 /controller_node가 /my_robot/move 서비스만 콜할 수 있고, 다른 서비스에 대한 호출은 허용되지 않는다.
액션(Action) 보안
액션(Action)도 내부적으로 피드백(Feedback), 목표(Goal), 결과(Result), 취소(Cancel) 등의 트픽/서비스를 사용해 구현된다. 따라서, 액션 보안을 구성하기 위해서는 액션이 내부적으로 사용하는 토픽과 서비스를 모두 정책에서 허용해 주어야 한다.
ROS2 Humble 이후에는 ros2 action CLI를 통해 생성되는 액션 인터페이스 파일을 참고하여, 해당 액션 이름에 매핑되는 주제명/서비스명을 파악할 수 있다. 이를 기반으로 XML 정책에 해당 항목을 추가하면 액션 레벨에서도 보안을 유지할 수 있다.
윈도우 및 Docker 환경
ROS2 보안은 플랫폼에 관계없이 동작하지만, CA 생성 및 인증서 관련 툴 체인이 Linux 기반 명령어에 최적화되어 있으므로, Windows나 Docker 컨테이너 환경에서 사용할 때는 몇 가지 주의 사항이 있다.
Windows 환경: OpenSSL 등 관련 라이브러리를 별도로 설치해야 하며,
sros2 generate_ca명령어 등이 의존하는 툴이 있는지 확인해야 한다.Docker: Docker 컨테이너 내부에서 보안을 설정할 경우, 볼륨 마운트(volume mount)를 통해 호스트의 CA 인증서와 키를 컨테이너에 전달하거나, 컨테이너 내부에서
sros2명령어를 실행해 CA를 생성한다.
특히 Docker 내에서 여러 컨테이너 간 통신에 보안을 적용할 경우, 각 컨테이너가 동일한 CA를 신뢰하는지, 노드 이름(enclave 이름)을 어떻게 구분할지 등에 대해 미리 설계해야 한다.
에피머럴(일시적) 키/인증서
일부 환경에서는 보안성을 강화하기 위해, 노드가 실행될 때마다 일시적인(에피머럴, ephemeral) 키/인증서를 생성해 사용하고, 노드 종료 시 폐기하기도 한다. 이런 시나리오를 위해서는 다음과 같은 순서를 자동화 스크립트로 구성한다.
노드 실행 전, 임시 CA 및 노드용 인증서를 생성한다.
정책 파일을 기반으로 SROS2 아티팩트를 완성한다.
노드 종료 시, 해당 인증서와 키를 삭제한다.
이렇게 하면 키 유출 위험을 줄일 수 있으나, 생성/삭제 과정이 매번 필요하므로 구현이 복잡할 수 있다.
보안 업데이트/회수(Revocation)
보안 설정을 변경하거나, 특정 인증서를 폐기(회수)해야 하는 경우도 발생한다. DDS 보안 계층에서는 다음과 같은 방식으로 처리할 수 있다.
CRL(Certificate Revocation List): 폐기된 인증서 목록을 DDS가 참조할 수 있도록 관리한다.
정책 파일 갱신: 허용/거부 노드 목록이 바뀌었을 때, 새로운 정책 파일(permissions.xml 등)을 반영한다.
새 인증서 재발급: 유효 기간 만료나 키 교체 등이 필요할 때, 새로 발급받은 인증서와 키를 사용한다.
대규모 시스템에서는 자동화된 인증서 발급 및 폐기 메커니즘이 중요한 이슈가 된다.
Last updated