search

보안 정책(Policy) 설정과 접근 제어

hashtag
보안 정책의 기본 개념

ROS2의 보안 체계는 DDS Security를 기반으로 하며, 이를 통해 데이터 무결성, 기밀성, 인증, 접근 제어를 강화한다. 이 중 **접근 제어(Access Control)**를 효과적으로 운용하기 위해서는 **보안 정책(Security Policy)**을 명확히 정의하고 적용해야 한다. 보안 정책은 주로 다음의 항목들을 결정한다.

  • 인증된 노드(Participant)가 어떤 토픽, 서비스, 액션에 접근할 수 있는지에 대한 권한 규칙

  • 노드 간 통신 시 메시지 무결성과 암호화(기밀성)를 위한 알고리즘 및 암호 스위트

  • 데이터 플로우(Flow)에 대한 임계값, 즉 트래픽을 어느 정도까지 허용하거나 차단할지 결정하는 정책

  • 특정 리소스(네임스페이스, 파라미터 서버 등)에 대한 제한, 혹은 모니터링 기준

ROS2 보안 정책은 보안 Governance 파일과 Permissions(권한) 파일로 표현되며, 이 두 파일은 DDS Security 플러그인에 의해 해석되어 접근 가능 여부와 권한 수준을 결정하게 된다. Governance 파일에는 전역 수준 보안 설정이, Permissions 파일에는 각 참가자(Participant)가 가진 구체적인 접근 권한 정보가 담긴다.

hashtag
DDS Security 구조와 Policy 설계의 중요성

ROS2에서 DDS Security를 사용하면 노드는 기본적으로 ‘Participant’ 단위로 인증과 암호화를 수행한다. ROS2 노드는 RMW 레이어를 통해 DDS 구현체와 상호 작용하므로, DDS Security 레이어가 활성화되면 노드 간 통신은 일련의 보안 규칙에 따라 제한 혹은 허용된다.

정확한 Policy 설정이 중요한 이유는 다음과 같다.

  1. 안전한 메시지 교환: 허가된 노드만이 민감 토픽을 발행·구독할 수 있도록 할 수 있다.

  2. 비인가된 접근 차단: 보안 설정이 제대로 구축되지 않으면 외부 공격자가 임의로 노드를 생성하고 토픽을 가로챌 수 있다.

  3. 미세한 권한 제어: 같은 시스템 내에서도 특정 파티션(partition) 또는 네임스페이스에서만 발행·구독이 가능한 등, 세분화된 접근 전략을 수립할 수 있다.

hashtag
ROS2 보안 설정 시 필요한 파일 구조

ROS2 보안을 활성화하려면, SROS2를 통해 생성된 일련의 파일과 디렉터리를 적절히 구성해야 한다. 일반적으로 다음과 같은 구조를 가진다.

<root-ca.crt>
└── enclaves
    ├── robot1
    │   ├── governance.xml
    │   ├── permissions.xml
    │   ├── key.pem
    │   └── cert.pem
    └── robot2
        ├── governance.xml
        ├── permissions.xml
        ├── key.pem
        └── cert.pem

여기서 governance.xml과 permissions.xml이 핵심적인 보안 정책 파일이다.

  1. governance.xml: 전역적인 보안 정책(Policy)을 정의한다. 어떤 암호화 방식을 사용할지, 로깅 레벨과 보안 이벤트 처리는 어떻게 할지 등을 설정한다.

  2. permissions.xml: 파티션별, 토픽별 혹은 노드별로 허용할 권한(예: 읽기/쓰기)을 세밀하게 기술한다.

hashtag
접근 제어 메커니즘: Governance와 Permissions

  1. Governance 파일

    • 암호화, 인증 및 접근 제어가 반드시 활성화되어야 하는지 여부를 선언한다.

    • 데이터 무결성(Integrity) 또는 기밀성(Confidentiality)을 위한 플러그인을 사용할지 여부를 결정한다.

    • 허용할 수 있는 보안 이벤트(예: 허가되지 않은 participant가 접근 요청 시 로그 남기기 등)를 정의한다.

  2. Permissions 파일

    • $<allow_rule>$ 또는 $<deny_rule>$ 등을 사용하여 특정 노드가 특정 토픽이나 파티션에 대해 접근 가능한지 여부를 결정한다.

    • 예를 들어 robot1은 토픽 /cmd_vel에 쓰기(Publish) 권한이 있지만, /odom 구독(Subscribe)은 허가되지 않을 수 있다.

    • Permissions에 정의된 허용 범위를 벗어나면 DDS Security 레이어에서 패킷 통신을 차단하거나 오류를 발생시켜 접근을 방어한다.

hashtag
파일 내용 예시

다음은 Permissions 파일의 일부 예시 형태를 간단히 살펴본 것이다(실제 XML 스키마와 다를 수 있으며, 개념 설명을 위해 축약되었다).

위 예시에서 robot1이라는 인증 주체(Participant)는 도메인 ID 0에서 cmd_vel 토픽에 Publish 권한만 허용되었다. 반면 subscribe 필드는 false로 설정되어 있으므로 구독 권한은 없다.

hashtag
보안 정책 생성 및 업데이트 절차

ROS2에서 보안 정책을 구성하는 핵심 파일은 크게 두 가지(보안 Governance, Permissions)이며, 이를 구축 및 업데이트하는 절차는 다음과 같이 정리할 수 있다.

키(Key)와 인증서(Certificate) 생성:

  • SROS2를 이용하거나, OpenSSL 등으로 직접 루트 인증서(root CA)와 개별 노드용 키/인증서를 생성한다.

  • 각 노드(Participant)는 고유한 private key와 인증서를 가져야 하며, 이를 통해 상호 간 **신뢰(Trust)**를 보장한다.

Governance 파일 생성 및 구성:

  • 암호화, 서명, 접근 제어 사용 여부, DDS 보안 플러그인 동작 모드 등을 설정한다.

  • <enable_discovery_protection>, <enable_liveliness_protection> 등과 같이 DDS Security에서 제공하는 다양한 옵션을 활용하여 보안 수준을 세밀하게 결정한다.

  • 예: discovery 단계에서 메타데이터도 암호화할지, 통신 중 ROS Graph 정보를 보호할지 등을 설정.

Permissions 파일 생성 및 권한 할당:

  • 특정 도메인 ID, 토픽, 서비스, 액션에 대한 접근 권한을 세분화한다.

  • 예: robot1 노드는 /scan 토픽에 구독 권한만 부여하고, /cmd_vel 토픽에는 발행 권한만 부여하는 식으로 미세 조정한다.

  • 필요시 $<deny_rule>$를 추가하여 특정 토픽에 대한 접근을 명시적으로 거부할 수도 있다.

파일 유효성 검사:

  • 생성된 Governance, Permissions 파일이 DDS Security 스펙에 부합하는지 검사한다.

  • SROS2에서 제공하는 security 관련 명령을 통해 XML 구조나 필드 값을 확인할 수 있다.

예시:

  • 유효성 검사 결과 오류가 발생하면, XML 스키마나 Tag 구문 등을 점검하여 수정해야 한다.

실 시스템에 배포:

  • 보안 폴더(enclaves 디렉터리 구조)를 구성한 뒤, 각 노드 실행 시 ROS_SECURITY_NODE_DIRECTORY 또는 ROS_SECURITY_KEYSTORE와 같은 환경 변수를 올바르게 설정하여 정책을 적용한다.

  • 실제 노드 실행 시:

  • 이렇게 하면 노드가 실행될 때 DDS Security 레이어에서 governance.xml과 permissions.xml을 읽어들여 접근 제어를 적용하게 된다.

hashtag
정책 구문 구조 예시 분석

다음은 DDS Security Permissions 파일 내부 구문의 주요 요소를 간단히 정리한 예시다. 실제 구현 시에는 XML 스키마와 DTD 등에 맞추어 작성해야 한다.

  • <subject_name>: 인증 주체, 즉 노드(Participant)의 식별자(보통 인증서의 Common Name)와 연결된다.

  • <validity>: 권한이 유효한 기간(만료 기간) 설정으로, 이 기간을 벗어나면 접근이 거부될 수 있다.

  • <allow_rule>: 허용할 도메인과 토픽, 퍼블리시·서브스크라이브 권한을 선언한다.

  • <deny_rule>: 특정 토픽, 도메인 등에 대해 접근을 거부할 수도 있으며, <allow_rule>에 없는 모든 항목은 자동으로 거부되도록 설정할 수도 있다(화이트리스트 방식).

hashtag
서비스, 액션에 대한 접근 제어

토픽(topic) 접근 제어와 유사하게, **서비스(service)**와 **액션(action)**도 DDS Security 접근 제어(permissions.xml) 내에서 정책을 정의할 수 있다. DDS Security 스펙 자체가 토픽 단위 접근 제어를 기본적으로 지원하지만, ROS2 레이어에서 서비스·액션을 내부적으로 요청·응답(request/response) 토픽으로 매핑하여 처리하기 때문에, 결국 서비스·액션 권한 설정도 토픽 권한 설정 방식과 유사하다.

  • 서비스의 경우: <service_request>, <service_response> 형태로 내부적으로 토픽 이름이 생성됨

  • 액션의 경우: <action_feedback>, <action_status>, <action_goal>, <action_result> 등 다중 토픽이 생성됨

Permissions XML에서 이를 정확히 인식해 접근 제어를 적용하기 위해서는, 실제 서비스를 이루는 토픽명(예: /example_serviceRequest, /example_serviceReply) 또는 액션 토픽명(예: /move_base/feedback, /move_base/result)을 확인하고, 해당 토픽 명칭에 따라 allow_rule 또는 deny_rule를 작성해야 한다.

hashtag
파티션과 네임스페이스를 통한 세분화

ROS2/DDS에서 보안 정책을 더 정교하게 제어하기 위해, 파티션(Partition) 또는 네임스페이스(Namespace) 사용을 권장한다. 아래와 같은 전략이 가능하다.

  1. 물리적/논리적 그룹화

    • 예를 들어, 센서 데이터 토픽은 /sensors/ 네임스페이스에, 로봇 제어 토픽은 /control/ 네임스페이스에 모으고, SROS2 권한 부여 시 네임스페이스 전체를 허용하거나 거부하는 방식으로 간편하게 접근 제어를 설정할 수 있다.

    • DDS에서 제공하는 ‘Partitions’ 메커니즘을 사용해, 로봇 그룹별로 다른 파티션을 부여하면 파티션 단위로 권한을 구분할 수 있다.

  2. 맞춤형 정책 파일 구성

    • <topic>**</topic>와 같이 와일드카드 또는 정규표현식을 사용해서 특정 네임스페이스 내 모든 토픽을 한 번에 허용/거부할 수 있다.

    • 혹은 <partition>robot1_partition</partition> 식으로 DDS 파티션을 명시하고, 해당 파티션에서 발행되는 모든 토픽에 대해 구독 권한만 주는 식의 정책을 구성할 수도 있다.

hashtag
고급 DDS Security 옵션

ROS2 보안 정책은 DDS Security 플러그인이 제공하는 다양한 고급 옵션을 활용하여 확장될 수 있다.

  1. 보안 로그(audit) 수집 옵션

    • Governance 파일에 <enable_audit_logging>를 true로 설정하면, DDS Security가 접근 거부 이벤트, 인증 실패 이벤트 등을 로그로 남기도록 설정할 수 있다.

    • 이를 통해 어떤 노드가 언제 권한을 초과하려 했는지, 혹은 인증서가 만료되었는지 등을 추적 가능하다.

  2. 리스너(Listener) 기반 알림

    • DDS Security 레벨에서 이벤트가 발생할 때 사용자 레벨에서 콜백을 받을 수 있는 구조가 제공된다(구현체마다 다를 수 있음).

    • 심층 방어가 필요한 환경이라면, 접근 거부 시 특정 로직을 수행하거나, 재시도를 제한하는 식으로 동작을 강화할 수 있다.

  3. QoS와 연계된 보안 설정

    • ROS2에서 QoS(신뢰성, 지속성, 히스토리 등)를 DDS 레벨에서 설정하듯이, 보안 정책 역시 QoS와 결합하여 특정 상황에만 강화된 암호화를 적용하거나, 노드 간 네트워크 상태에 따라 권한을 동적으로 변경할 수 있다.

    • 그러나 DDS Security 기본 스펙 상, 동적 권한 변경은 제한적이며, 주로 사전에 준비된 Permissions 파일의 범주 내에서만 동작이 가능하다.

hashtag
권한 충돌 및 우선순위

실제 시스템에서 노드가 여러 개의 Permissions 파일 또는 여러 개의 <grant>를 동시에 가질 수도 있는데, 이럴 때 충돌이 발생할 수 있다.

  • 기본적으로 가장 구체적인 규칙이 우선하며, <deny_rule>가 <allow_rule>보다 우선 적용된다.

  • <allow_rule>에 명시되지 않은 토픽은 기본 거부로 설정하는 화이트리스트(deny by default) 접근 방법이 보안적으로 안전하다.

hashtag
예시: 서비스에 대한 접근 제어

아래 예시는 /my_service라는 서비스를 호출(request)만 허용하고, 응답(response) 처리(=구독)는 허용하지 않는 단순한 Permissions XML의 일부분 예시다. 실제로는 서비스 요청과 응답을 모두 허용해야 정상적인 동작이 가능하지만, 보안 교육용 예시로 참고 가능하다.

  • <subject_name>client_node</subject_name>: 이 권한은 ‘client_node’라는 노드(Participant)에 대한 것임을 나타낸다.

  • <allow_rule>: 도메인 0 내에서 my_serviceRequest 토픽을 퍼블리시할(서비스 호출) 권한만 허용.

  • <deny_rule>: my_serviceResponse 토픽 구독(서비스 응답 수신)은 거부.

hashtag
정책 일관성(Consistency) 및 상호 운용성

ROS2 시스템에서 여러 노드가 동시에 서로 다른 보안 정책 파일을 사용하거나, Governance/Permissions 설정이 서로 충돌하면 통신이 정상적으로 이뤄지지 않을 수 있다. DDS Security에서 각 Participant가 사용하는 governance.xml과 permissions.xml 정보가 상호 호환되지 않으면, DDS Discovery 단계부터 서로를 신뢰할 수 없다고 판단하여 연결이 거부되기 때문이다.

  1. Governance 파일 충돌

    • 예를 들어, 한 노드는 <enable_discovery_protection>을 true로 설정해두었고, 다른 노드는 이를 false로 설정했다면, 노드들 간 메타데이터 교환 방식이 달라지므로 통신 호환성 문제가 발생할 수 있다.

    • 보안이 적용되는 노드와 적용되지 않는 노드가 동일한 DDS 도메인(ID)에서 만나면, 보안 노드 입장에서는 비보안 노드를 신뢰할 수 없어 세션이 생성되지 않는다.

  2. Permissions 파일 충돌

    • 노드 A가 노드 B의 특정 토픽 구독을 허용한다고 Permissions에 명시했더라도, 정작 노드 B 측에서는 토픽을 발행할 권한이 없도록 설정되어 있으면 실제 데이터 교환이 불가능하다.

    • 또한 노드 B가 사용하는 Permissions 파일에서 토픽 이름을 다르게 지정했을 수도 있는데, 이러한 불일치로 인해 연결이 이루어지지 않을 수 있다.

  3. 상호 운용성(Interoperability)

    • 여러 DDS 구현체(Fast DDS, Cyclone DDS, RTI Connext, eProsima 등)를 혼합하여 사용 시, DDS Security 스펙은 동일하더라도 구현체별 확장 기능이 달라 상호 운용성 문제가 발생할 수 있다.

    • 이 경우, 표준 DDS Security 설정만 이용하도록 제한하고, 벤더별 플러그인 기능은 가급적 동일하게 맞추거나 사용하지 않는 편이 좋다.

hashtag
동적 권한 재설정 및 한계

ROS2/DDS Security에서 권한(permissions)은 대체로 정적으로 부여된다. 즉, 프로그램 실행 전 $permissions.xml$을 준비하고, 노드 실행 시 이 파일을 기반으로 접근 제어가 이루어진다.

  • 동적 정책 업데이트: 일부 DDS 구현체에서 런타임 중에 새로운 permissions 파일을 로드하거나, 특수 API로 권한을 재할당할 수 있도록 지원한다.

  • 한계점: 모든 DDS 구현체가 이 기능을 제공하지는 않으며, ROS2 RMW 계층과 완전히 호환되지 않을 수도 있다. 높은 수준의 신뢰성과 안정성을 요구하는 로봇 시스템에서는 실행 중 보안 정책이 예기치 않게 변동되는 상황 자체가 위험할 수 있으므로, 보안 정책은 보통 시스템 구동 전 결정된 형태로 유지된다.

hashtag
SROS2 CLI를 활용한 접근 제어 설정 예시

ROS2에서 기본 제공되는 SROS2 툴을 사용하면, Governance/Permissions 템플릿 생성부터 인증서 발급까지 비교적 간편하게 처리 가능하다. 아래는 간단한 예시 시나리오다.

Keystore 생성:

키·인증서와 정책 파일 생성:

  • 이 명령을 실행하면, my_keystore/enclaves/robot_controller 안에 governance.xml, permissions.xml, cert.pem, key.pem 등이 생성된다.

  • 생성된 기본 템플릿 permissions.xml에는 접근 제어 규칙이 거의 비어 있으므로, 필요에 따라 토픽/서비스/액션 권한을 수정해야 한다.

수정된 정책 적용:

  • permissions_mod.xml는 사용자가 수정한 접근 제어 규칙 파일이며, 이 파일을 바탕으로 DDS Security에서 해석 가능한 최종 permissions.xml을 생성한다.

노드 실행:

  • 이제 robot_controller_node는 DDS Security를 기반으로 지정된 보안 정책에 따라 통신한다.

hashtag
정책 상태 모니터링

보안 정책이 적용된 후에는, 각 노드가 실제로 어떤 권한을 사용하고 있는지를 모니터링하고 필요하다면 로그를 검토해야 한다.

  • DDS Security Audit 로그: Governance 파일에서 $<enable_audit_logging>$을 true로 설정하면, 접근 성공/실패, 인증 에러 등을 별도 로그로 남길 수 있다.

  • ROS2 CLI 도구: 특정 토픽 목록, 노드 목록, 서비스 상태를 주기적으로 확인하면서, 예상치 못한 노드가 존재하거나 비인가 토픽이 보이는지 점검할 수 있다.

hashtag
성능(Performance) 영향 분석

ROS2에 보안 정책을 적용하면, 데이터 암호화·서명·검증 등 보안 프로세스가 추가되므로 **통신 지연(latency)**과 **처리량(througput)**에 영향을 미친다. 실제 로봇 제어 시스템에서는 실시간성(Real-time)도 중요한 요소이므로, 보안 정책을 설정할 때 다음과 같은 성능적 측면을 고려해야 한다.

암호화 비용

  • 모든 토픽 데이터를 암호화할 경우, CPU 리소스 사용량이 증가하고 메시지 전송 시 지연이 발생한다.

  • 고성능 임베디드 프로세서가 아니라면 전체 토픽 암호화 대신, 민감 토픽만 암호화하는 방식을 택할 수도 있다.

서명(Integrity) 검증 비용

  • 메시지 무결성 확인을 위해 MAC(Message Authentication Code)나 디지털 서명을 사용하는 경우, 송·수신 단에서 각각 서명 생성/검증 시간이 추가된다.

  • DDS Security에서는 무결성(Integrity) 전용 플러그인을 켜거나 끄는 설정이 가능하므로, 필요 수준만큼 선택적으로 적용이 가능하다.

메타데이터(Discovery, 파라미터) 보호 여부

  • <enable_discovery_protection>를 활성화하면, 노드·토픽 이름 등의 메타데이터도 암호화된다. 이로 인해 DDS Discovery 단계에서 일정 성능 저하가 발생한다.

  • 보안 성능과 공개될 수 있는 정보(메타데이터 공개 위험)에 대한 트레이드오프를 고려해야 한다.

QoS 설정과 상호 작용

  • 보안 처리를 위해 메시지 전송 지연이 발생하면, Deadline, Liveliness, Time-based Filter 등과 같은 QoS 정책에 영향을 준다.

  • 예: Deadline QoS가 매우 빡빡하게 설정되어 있는 경우, 보안 암호화로 인해 메시지 처리가 지연되면 Deadline을 맞추지 못해 QoS 이벤트가 발생할 수 있다.

하드웨어 가속

  • 고급 임베디드 시스템이나 산업용 PC에서는 TLS/SSL 암호화용 하드웨어 가속기를 내장하기도 한다.

  • DDS Security 계층에서 OpenSSL 라이브러리를 사용하는 경우, 하드웨어 가속이 지원되는 OpenSSL 엔진(Engine)을 설정하면 암호화 처리 성능이 크게 향상될 수 있다.

hashtag
보안 정책 최적화 방법

성능 저하를 최소화하면서도 일정 수준 이상의 보안을 유지하고자 한다면, 다음과 같은 접근 방법을 고려할 수 있다.

토픽 레벨 차등 적용

  • ROS2 시스템에서 보안이 정말 중요한 토픽(예: 로봇 제어 명령, 비인가 공개시 치명적인 정보)에 한정해서 암호화·인증을 사용한다.

  • 덜 중요한 토픽(예: 디버깅용 로그, 비공개여도 큰 문제 없는 상태 정보)에는 무결성 검증만 적용하거나, 혹은 아예 보안 처리를 비활성화할 수 있다.

  • 이를 위해서는 Governance 파일에서 <allow_unauthenticated_participants>, <authentication> 플러그인 설정, <enforce_liveliness_protection> 옵션 등을 세밀하게 조정할 수 있어야 한다.

키(Secrets) 관리 주기 최적화

  • 키를 너무 자주 교체하면, 매번 노드 전환 또는 재시작 시 인증서 재검증이 발생하므로 오버헤드가 커진다.

  • 반면 키를 오래 사용하면 보안 침해 위험이 커지므로, 조직 내 보안 정책(예: Key Rotation 정책)과 시스템 가용성 요구사항을 균형 있게 맞출 필요가 있다.

네트워크 레벨 방어와 결합

  • DDS Security가 아니라도, VPN, TLS Proxy, 방화벽, VLAN 등 네트워크 레이어에서 추가 보안을 적용하여 DDS 자체 부담을 줄일 수 있다.

  • 특히 로컬 네트워크가 비교적 안전하다면, DDS Security를 최소한도로만 설정하고 네트워크 방어를 강화하는 아키텍처도 고려할 수 있다.

컴퓨팅 자원 증설

  • 암호화와 서명 검증에 따른 CPU 사용량이 증가하므로, 보안이 중요한 시스템이라면 초기부터 CPU 예산(코어 수, 클럭 등)을 여유롭게 설계하는 편이 안전하다.

  • 메시지 크기가 큰 경우(예: 고해상도 이미지 스트리밍)에는 네트워크 대역폭과 함께 암호화에 드는 처리 시간을 반드시 고려해야 한다.

hashtag
운영 환경별 권장 시나리오

ROS2 보안 정책 설계는 시스템 운영 환경에 따라 달라진다.

개발·테스트 환경

  • 빠른 프로토타이핑을 위해 초기에 보안 기능을 최소화(또는 비활성화)하고 개발 편의성을 우선시한다.

  • 이후 실제 배포 환경에서 필요한 정책을 점진적으로 적용하여, 기능적 문제부터 해결한 뒤 보안을 강화한다.

산업용·임베디드 환경

  • 로봇 팔, AGV(Automated Guided Vehicle), 산업용 센서 등 실시간 제어가 중요한 환경에서는 보안 처리 지연이 생산성에 직접 영향을 주므로, 무거운 암호화보다는 핵심 토픽 위주 최소보안(선택적 암호화) 방식을 주로 채택한다.

  • 네트워크 분리(망 분리)를 함께 적용하여, 외부로부터의 침입을 원천 차단하고 내부 DDS 통신은 상대적으로 가벼운 보안 모드로 관리하는 사례도 많다.

클라우드 연동 로보틱스

  • 원격 제어, 클라우드 매니지먼트, 데이터 업링크/다운링크 등이 잦은 경우, 퍼블릭 네트워크를 통한 통신에서 TLS 기반 VPN 터널링을 적용한 뒤, DDS Security를 병행한다.

  • 클라우드 브리지(Bridge) 노드에 대한 Permissions를 철저히 설정해, 내부 네트워크 핵심 정보가 외부에 노출되지 않도록 한다.

hashtag
보안 정책 디버깅과 트러블슈팅

보안 정책(Policy)을 설정한 뒤, 실제로 노드를 실행했을 때 DDS Security 초기화 오류, 통신 실패, Discovery 미동작 등의 문제가 발생할 수 있다. 이런 상황에서 원인을 찾는 방법은 다음과 같다.

DDS 로그 확인

  • DDS 구현체(예: Cyclone DDS, Fast DDS)의 로그 레벨을 높여서(NOTICE, DEBUG 등) 접근 거부나 인증 실패가 언제, 왜 발생하는지 확인할 수 있다.

  • “Security authentication failed” 등의 키워드를 통해 어떤 인증서가 거부되었는지, 혹은 Governance/Permissions 파일 구문 오류가 있는지 파악한다.

SROS2 유효성 검사

  • SROS2가 제공하는 ros2 security verify_policy 명령으로 governance.xml과 permissions.xml의 구조적 유효성을 검사한다.

  • XML 문법 오류나, DDS Security 스키마에 맞지 않는 태그가 있을 경우 즉시 수정해야 한다.

환경 변수 설정 재확인

  • ROS2 보안이 정상 동작하기 위해서는 $ROS_SECURITY_ENABLE=true, $ROS_SECURITY_STRATEGY=Enforce, $ROS_SECURITY_KEYSTORE 등이 올바르게 세팅되어 있어야 한다.

  • 각 노드마다 다른 enclave 디렉터리를 사용하는지, 권한 파일(permissions.xml)을 잘 가리키는지 확인한다.

주체 이름(Subject Name) 일치 여부

  • permissions.xml의 <subject_name> 태그 값과, 실제 노드가 사용하는 인증서의 Common Name(CN) 등이 일치해야 한다.

  • 인증서 생성 시 create_key 명령에 사용한 노드 이름(예: robot_controller)과 <subject_name>이 불일치하면 DDS Security 레벨에서 인증을 통과할 수 없다.

네트워크 포트·방화벽 문제

  • DDS 통신 포트가 방화벽 등으로 차단되어 있으면 Discovery 자체가 실패하므로, 보안 정책과 무관하게 통신이 이루어지지 않을 수 있다.

  • 보안과 방화벽을 함께 구성할 때는, DDS가 사용하는 UDP 포트 범위를 적절히 열어주어야 한다.

hashtag
멀티-로봇 시나리오에서의 접근 제어

ROS2를 멀티-로봇 환경에서 사용할 때, 각 로봇(또는 그룹)은 개별 enclave(키 저장소 디렉터리)를 사용하고, 서로 교차 통신을 허용할 수도 있고 제한할 수도 있다.

로봇별 분리된 enclave

  • 로봇1, 로봇2 각각에 대해 별도의 인증서·Governance·Permissions 파일을 발급한다.

  • 시스템에 따라 ‘중앙 관리 keystore’ 또는 ‘로봇별 독립 keystore’를 사용할 수도 있다.

토픽 할당 예

  • 로봇1은 /robot1/cmd_vel, /robot1/odom, 로봇2는 /robot2/cmd_vel, /robot2/odom 등을 사용하고, 서로 교차로 /tf를 공유해야 한다면, 두 로봇 모두 /tf 토픽에 대한 구독·발행 권한을 부여해야 한다.

  • 반면 /robot1/diagnostics 토픽은 로봇2가 볼 필요가 없다면, robot2의 permissions.xml에는 해당 토픽 접근 권한을 부여하지 않는다.

중앙 관제 노드

  • 여러 로봇을 모니터링·제어하기 위한 중앙 관제(Central Controller) 노드가 존재할 수 있으며, 이 노드에는 모든 로봇의 토픽에 대한 접근 권한(READ 혹은 WRITE)이 부여되어야 할 수 있다.

  • 따라서 중앙 관제 노드(혹은 클라우드 브리지 노드)의 <subject_name>을 명시하고, 모든 /robotX/ 네임스페이스 접근이 가능하도록 설정하되 필요 이상의 권한은 부여하지 않는 방식을 택한다.

hashtag
실제 시스템 배포 시 고려 사항

인증서(루트 CA) 보관

  • SROS2로 생성한 root-ca.crt(루트 인증서)는 모든 Participant가 신뢰해야 하므로, 안전하게 보관·배포해야 한다.

  • 유출될 경우, 내부 인증서 발급이 위조될 위험이 있으므로, 별도 보안 저장소(HSM)나 접근 통제된 서버를 사용한다.

버전 관리

  • Governance, Permissions 파일을 버전 관리(Git 등)하되, private key(key.pem)는 일반적으로 코드 리포지토리에 저장해서는 안 된다.

  • 파일이 변경될 때마다 해당 노드를 재배포해야 하므로, CI/CD 파이프라인에서 보안 아티팩트를 어떻게 처리할지 결정해야 한다.

테스트 자동화

  • 단순 통합 테스트 뿐 아니라, 보안 테스트(Unauthorized Node Attempt, 권한 없는 토픽 구독 시도 등)를 자동화 테스트 스크립트로 구성해둔다.

  • 스모크 테스트(smoke test) 형태로 실제 노드 실행 후 로그를 분석해, 비인가 접근 시도가 차단되는지 확인한다.

운영 시 모니터링

  • 보안 관련 이벤트(인증 실패, 접근 거부 등)가 발생할 때 알림을 받을 수 있도록, ROS2 로그나 DDS 보안 로그를 수집·분석한다.

  • 심각도 높은 이벤트가 연속으로 발생하면 시스템 관리자에게 실시간 경고를 보내거나, 자동 방어 프로세스를 가동할 수도 있다.

hashtag
추가 참고 자료

ROS 2 Documentation:

  • 공식 문서에서 DDS Security 설정 가이드, ROS2 CLI 예제, 보안 베스트 프랙티스 등을 확인할 수 있다.

DDS Security 표준:

  • OMG가 제정한 “DDS Security Specification”을 통해 Governance 파일과 Permissions 파일의 XML 스키마, 플러그인 API 등을 정확히 이해할 수 있다.

SROS2 튜토리얼:

  • ROS 2 레포지토리 내 sros2 패키지의 예제와 튜토리얼을 통해 실제 키스토어 생성, 권한 설정, 배포 과정을 실습 가능하다.

Previous보안 키(Key)와 인증서(Certificate) 생성NextROS2 보안 기초: 통신 암호화와 성능 영향

Last updated