제13부 보안

13.2 SROS 2 — 키스토어·enclave·정책

13.2.1 이 장에서 배우는 것 / 선수 지식

13.1에서 "기본 상태는 완전 개방"임을 확인했다. SROS 2는 그것을 닫는 ROS 2의 공식 수단이다.

핵심 아이디어는 단순하다. 각 노드(정확히는 enclave)에 신원 증명서(인증서)와 권한 목록(권한서)을 주고, 미들웨어가 그것을 검증한다. 신원이 없으면 그래프에 참여할 수 없고, 권한에 없는 토픽은 발행·구독할 수 없다.

배우는 것:

• 구조 — SROS 2와 DDS-Security의 관계.
• 키스토어 — 무엇이 들어 있는가.
• enclave — 신원의 단위.
• 정책 — 권한을 기술하는 방법.
• 적용 절차 — 생성부터 실행까지.
• 정책 작성 전략 — 실무적 접근.
• 운영 — 갱신·폐기·배포.
• 진단 — 안 될 때.

선수 지식: 13.1(위협 모델), 3.3(디스커버리), 1.1.6(네임스페이스), 3.5(RMW).

정직: 명령·디렉터리 구조·환경 변수·실행 인자는 Jazzy에서 실제로 키스토어와 enclave를 만들어 확인했다(13.2.12). 아래 본문의 (확인 필요) 상당수가 그 결과로 해소됐다. 폐기(CRL)·DDS 벤더별 세부는 여전히 미확인이다. 여기 제시하는 것은 개념과 전형적 형태이며, ros2 security --help와 공식 문서가 정본이다. RMW 구현에 따라 지원 범위가 다르다(확인 필요). 이 환경에서 실행 검증하지 않았다(목차 3). 실제 키 관리는 조직의 보안 정책과 전문가 판단을 따라야 한다.

13.2.2 구조

견해: "SROS 2 = 도구, DDS-Security = 메커니즘"이라는 구분이 이해에 중요하다. SROS 2는 인증서와 XML 권한 파일을 생성해 정해진 위치에 두는 일을 하고, 실제 검증·암호화는 DDS 구현의 보안 플러그인이 한다. 문제가 생기면 어느 층인지 구분해야 진단이 된다.

제공되는 보호:

13.2.3 키스토어

보안 자료를 담는 디렉터리 구조다.

# 키스토어 생성 (실행 확인)
ros2 security create_keystore ~/robot_keystore

실제 구조(실행 확인 — 파일 이름까지 그대로다):

신원용 CA와 권한용 CA가 따로다(identity_ca · permissions_ca). 기본 생성에서는 둘 다 ca.*와 같은 자료를 가리키지만, 운영에서는 분리할 수 있다 — 신원 발급 권한과 정책 서명 권한을 다른 조직이 갖는 구성이다.

함정: CA 개인키가 노출되면 임의의 신원을 만들 수 있다 — 전체 보안이 무너진다. CA 키를 로봇에 배포하지 말라. 로봇에는 그 로봇에 필요한 enclave 자료만 넣고, CA는 안전한 별도 시스템에 둔다(13.2.8).

견해: 개인키 보호가 SROS 2 운용의 가장 어려운 실무 문제다. 파일 시스템에 평문으로 놓이면 로봇에 물리적·원격 접근한 상대가 가져갈 수 있다. 디스크 암호화·접근 권한·가능하면 하드웨어 보안 요소를 고려해야 하며, 이 판단은 보안 전문가의 영역이다.

13.2.4 enclave — 신원의 단위

enclave는 "하나의 보안 신원"이다.

# 실행 시 enclave 지정 (실행 확인 — 짧은 형태는 -e)
ros2 run my_pkg my_node --ros-args --enclave /robot1/perception

견해: enclave 세분화 정도가 설계 판단이다. 모든 프로세스에 같은 enclave를 주면 관리가 쉽지만 권한 분리가 없고, 프로세스마다 다른 enclave를 주면 세밀하지만 정책 파일이 많아진다. 실무에서는 역할별 그룹(제어·인지·운영 도구)이 흔한 절충이다.

함정: 컴포넌트 컨테이너에 여러 노드를 넣으면(2.7) 그들은 같은 enclave를 공유한다. 성능을 위한 컴포넌트화가 권한 분리를 약화시킬 수 있다 — 성능과 보안의 절충이 여기서 나타난다.

함정: enclave를 안 주면 기본 enclave가 쓰이거나 실행이 거부된다(확인 필요: 동작). launch에서 각 노드에 enclave를 지정하는 것을 빠뜨리면 전체가 안 뜨므로, launch 파일에 체계적으로 반영해야 한다.

13.2.5 정책

누가 무엇을 할 수 있는지 기술한다.

<!-- 정책 파일 스키마는 13.2.12.2에 실물을 실었다 -->
<policy version="0.2.0">
  <enclaves>
    <enclave path="/robot1/control">
      <profiles>
        <profile ns="/" node="controller">
          <topics publish="ALLOW">
            <topic>cmd_vel</topic>
            <topic>joint_states</topic>
          </topics>
          <topics subscribe="ALLOW">
            <topic>scan</topic>
            <topic>odom</topic>
          </topics>
          <services reply="ALLOW">
            <service>set_mode</service>
          </services>
        </profile>
      </profiles>
    </enclave>
  </enclaves>
</policy>

# 실행 중인 시스템에서 정책 초안 생성 (실행 확인)
ros2 security generate_policy policy.xml

# 정책으로 권한 생성
ros2 security create_permission ~/robot_keystore /robot1/control policy.xml

견해: "실행 중인 시스템에서 정책을 생성"하는 기능이 실무의 출발점이다. 정책을 처음부터 직접 작성하는 것은 매우 번거롭다. 동작하는 시스템에서 초안을 생성하고, 그것을 검토·축소하는 순서가 현실적이다.

함정: 자동 생성된 정책은 "현재 하고 있는 모든 것"을 허용한다. 그것을 그대로 쓰면 최소 권한 원칙이 지켜지지 않는다. 불필요한 항목을 제거하는 검토가 반드시 필요하며, 이 검토를 건너뛰면 SROS 2를 켠 의미가 절반으로 준다.

함정: 정책에 없는 통신은 조용히 실패할 수 있다. 토픽이 연결되지 않는데 오류가 명확하지 않으면 1.5.4(QoS 불일치)와 증상이 비슷해 진단이 어렵다. SROS 2 적용 후 통신 문제는 정책을 먼저 의심하라(13.2.9).

견해: 와일드카드 사용을 신중히 하라. <topic>*</topic> 같은 광범위 허용은 편리하지만 통제를 무력화한다. 다만 완전한 최소 권한은 유지 비용이 크므로, 위험도에 따라 차등하는 것이 실용적이다 — 명령 토픽은 엄격히, 진단·로그는 느슨하게.

13.2.6 적용 절차

# 6. 환경 변수 (실행 확인 — rcl/security.h 의 정의와 일치)
export ROS_SECURITY_KEYSTORE=~/robot_keystore
export ROS_SECURITY_ENABLE=true
export ROS_SECURITY_STRATEGY=Enforce      # Permissive vs Enforce

함정: Permissive는 "보안이 켜진 것처럼 보이지만 실제로는 아닐 수" 있다. 자료를 못 찾은 노드가 조용히 비보안으로 실행되는데, 겉으로는 정상 동작한다. 운영에서는 반드시 Enforce 를 쓰고, 실패는 명시적으로 드러나게 한다.

견해: 개발에서는 Permissive, 운영에서는 Enforce가 아니라 — 개발에서는 보안 비활성, 운영에서는 Enforce가 낫다. Permissive는 두 상태를 섞어 혼란만 만든다. 켜거나 끄거나 분명히 하는 것이 진단을 쉽게 한다.

launch 통합:

# launch에서 enclave 지정 (개념 — 확인 필요: API)
Node(package='my_pkg', executable='controller',
     ros_arguments=['--enclave', '/robot1/control'])

견해: enclave 지정을 launch에 체계적으로 넣으라. 노드마다 수동으로 지정하면 빠뜨리고, 빠뜨리면 Enforce에서 실행이 실패한다. 역할별 헬퍼 함수를 만들어 일관되게 적용하는 것이 유지보수에 좋다(14.4).

13.2.7 정책 작성 전략

실무적으로 어디까지 세밀하게 할 것인가.

역할별 예시:

견해: "명령을 발행할 수 있는 enclave를 최소화하라"가 핵심 원칙이다(13.1.6의 우선순위). 인지·진단·기록 노드가 /cmd_vel을 발행할 이유가 없으므로, 그 권한을 제거하면 그 노드들이 침해되어도 로봇을 직접 움직이지 못한다.

견해: 진단·모니터링 도구는 구독만 허용하는 별도 enclave로 두라. 운영 중 도구를 연결할 때 강한 권한을 주지 않아도 되고, 도구가 침해되어도 관찰만 가능하다.

함정: 정책이 실제 그래프와 어긋나면 시스템이 부분적으로 동작한다. 일부 통신만 막혀 원인 파악이 어려운 상태가 된다. 정책 변경 후에는 전체 통합 시험을 실행해야 하며, 이것을 CI에 넣으면(14.6) 회귀를 검출할 수 있다.

13.2.8 운영 — 배포·갱신·폐기

함정: 인증서 만료를 놓치면 로봇이 어느 날 갑자기 통신하지 않는다. 만료일을 관리하고 만료 임박을 진단으로 경보하는 것(6.9)이 실용적 방어다. 대량 배치에서는 이것이 심각한 운영 사고가 될 수 있다.

견해: 키·인증서 관리는 배포 파이프라인의 일부로 다뤄야 한다(14.8). 사람이 수동으로 복사하는 방식은 규모가 커지면 실수와 유출을 만든다. 이미지 빌드·프로비저닝 절차에 통합하는 것이 표준적 방법이며, 구체적 설계는 조직의 보안 정책을 따라야 한다.

정직: 폐기 목록(CRL) 지원·갱신 절차의 세부는 DDS 구현과 버전에 의존한다(확인 필요). 침해된 로봇의 신원을 무효화할 수 있는지, 어떻게 하는지를 도입 전에 확인해야 한다 — 이것이 안 되면 침해 대응 수단이 제한된다.

13.2.9 진단

SROS 2 적용 후 흔한 문제들이다.

견해: 시계 오차가 인증서 검증을 깨뜨린다(7.7.6과 연결). 로봇의 시계가 크게 틀리면 "아직 유효하지 않음"·"만료됨"으로 판정될 수 있다. 시계 동기가 보안의 전제임을 인식하라.

견해: "정책 문제인가 QoS 문제인가"를 구분하는 절차를 두라. 보안을 끄고 동작하면 정책 문제, 꺼도 안 되면 QoS·이름 문제다. 이 한 번의 시험이 진단 시간을 크게 줄인다(11.1.2의 계층 좁히기).

13.2.12 키스토어를 실제로 만들어 본 결과 — 실측

Jazzy 컨테이너에서 키스토어와 enclave를 만들고 나온 파일을 그대로 열어 확인했다(실행 확인). 이 장의 (확인 필요) 상당수가 여기서 해소된다.

13.2.12.1 명령 여덟 개와, 그중 하나는 이미 폐기 예정

ros2 security의 동사는 여덟 개다:

list_keys를 실행하면 이런 경고가 출력된다(실행 확인):

FutureWarning: list_keys is deprecated and will be removed in a future release.
Use list_enclaves instead.

옛 자료에는 list_keys가 흔히 나온다. 지금 쓸 것은 list_enclaves다.

13.2.12.2 기본 권한 파일은 "전부 허용"이다

create_enclave로 만든 permissions.xml을 열면 이렇게 들어 있다(실행 확인, 일부):

<grant name="/talker_listener/talker">
  <subject_name>CN=/talker_listener/talker</subject_name>
  <validity>
    <not_before>2026-08-15T09:15:21</not_before>
    <not_after>2036-08-13T09:15:21</not_after>
  </validity>
  <allow_rule>
    <domains><id>0</id></domains>
    <publish>
      <topics>
        <topic>rt/*</topic>
        <topic>rq/*Request</topic>
        <topic>rr/*Reply</topic>
        <topic>rq/*/_action/send_goalRequest</topic>
        …
      </topics>
    </publish>
    <subscribe>…</subscribe>
  </allow_rule>
</grant>

세 가지를 읽어야 한다.

① 기본값이 와일드카드 전부 허용이다. rt/*는 모든 ROS 토픽이다. 즉 enclave를 만들었다고 권한이 좁혀지는 것이 아니다 — 암호화와 인증은 켜지지만, 무엇을 해도 되는가는 여전히 열려 있다. 권한을 좁히려면 generate_policy로 초안을 생성하고 수정한 뒤 create_permission으로 다시 서명해야 한다.

함정: "SROS 2를 켰다"와 "권한을 분리했다"는 다른 일이다. 기본 enclave만 만들어 두고 최소 권한이 적용됐다고 여기는 것이 흔한 오해다. 실제로 좁혀졌는지는 permissions.xml에 rt/*가 남아 있는지로 확인하라.

② 도메인이 0으로 고정된다. <domains><id>0</id></domains>가 하드코딩돼 있다. ROS_DOMAIN_ID를 다른 값으로 바꾸면 권한이 그 도메인에 적용되지 않아 통신이 막힌다. 도메인을 나눠 쓰는 팀에서 "보안을 켜니 안 된다"의 흔한 원인이다(3.3.7).

③ 유효기간이 10년이다. 위 예에서 2026-08-15 → 2036-08-13. 편해 보이지만, 키가 새면 유효기간 10년의 신원이 새는 것이다. 폐기 수단이 마땅치 않은 상황(13.2.8)에서는 유효기간을 짧게 설정하고 갱신을 자동화하는 편이 안전하다.

13.2.12.3 DDS 토픽 이름 접두어 — 정책 파일이 드러내는 것

권한 파일이 흥미로운 이유가 하나 더 있다. ROS 이름이 DDS 이름으로 어떻게 바뀌는지가 그대로 보인다(2.1.4·3.2).

정책을 직접 좁힐 때 이 규칙을 알아야 한다. /scan만 구독하게 하려면 <topic>scan</topic>이 아니라 <topic>rt/scan</topic>이라고 써야 한다(앞의 /도 빠진다). 파라미터를 허용하려면 토픽이 아니라 rq/·rr/ 쪽에 항목을 넣어야 한다 — 파라미터는 서비스이기 때문이다(1.9.2).

13.2.12.4 환경 변수와 실행 인자 — 정확한 이름

rcl/security.h와 rcl/arguments.h에 정의된 그대로다(실행 확인):

enclave 경로는 자동으로 계산된다. 헤더의 설명 그대로 옮기면, 컨텍스트 이름이 /a/b/c이고 키스토어 루트가 /r이면 보안 디렉터리는 /r/a/b/c가 된다. ROS_SECURITY_ENCLAVE_OVERRIDE는 이 계산을 건너뛰고 정확한 디렉터리를 직접 지정할 때 쓴다.

13.2.12.5 환경 변수를 실제로 흔들어 본 결과

값을 바꿔 가며 노드를 실행하고 성공/실패로 판정했다. 키스토어에는 /talker_listener/talker enclave만 있고, 노드는 그 enclave를 지정하지 않은 상태다(실행 확인).

세 가지가 확정된다.

① ROS_SECURITY_ENABLE은 정확히 소문자 "true"여야 한다. 1도 True도 통하지 않는다. 그리고 결정적으로, 틀린 값은 오류를 내지 않고 보안을 조용히 끈다. Enforce를 함께 켜 두었는데도 노드가 정상적으로 기동됐다 — "Enforce니까 잘못되면 막히겠지"라는 안전망이 여기서는 작동하지 않는다. 값이 먼저 무시되기 때문이다.

함정: 이것이 보안 사고로 이어지는 자리다. 배포 스크립트에 ROS_SECURITY_ENABLE=1이라고 써 두면 로봇은 정상 동작하고 로그도 조용하지만 통신은 평문이다. 확인 방법은 노드 실행 로그에 Found security directory: <keystore>/enclaves가 출력되는지 보는 것이다(실행 확인 — 보안이 켜졌을 때만 나온다).

② Enforce와 Permissive의 차이가 실측으로 갈린다. 같은 조건에서 Enforce는 거부하고 Permissive는 통과한다. 운영에서는 Enforce가 기본이어야 한다 — Permissive는 "보안 자료가 있으면 쓰고 없으면 평문"이라 마이그레이션 중에만 쓸 값이다.

③ enclave는 노드 이름이 아니라 컨텍스트로 찾는다. 노드 이름과 네임스페이스를 enclave 경로(/talker_listener/talker)와 똑같이 맞춰도 실패했고, --enclave로 명시하자 통과했다. 13.2.4가 "프로세스 단위"라고 한 것이 이 뜻이다 — 노드를 아무리 잘 이름 지어도 enclave는 자동으로 붙지 않는다.

함정: 컴포넌트 컨테이너에 노드를 여럿 싣는 구성(1.13)에서는 컨테이너 프로세스 하나가 enclave 하나를 갖는다. 그 안의 노드들은 권한을 나눌 수 없다. 권한을 분리하려면 프로세스를 나눠야 한다 — 컴포지션의 성능 이득과 권한 분리가 정면으로 충돌하는 지점이다.

13.2.10 함정 카탈로그

13.2.11 체크포인트

• SROS 2와 DDS-Security의 역할 구분을 설명할 수 있는가. 왜 이 구분이 진단에 중요한가.
• SROS 2가 제공하는 보호 다섯 가지는?
• 키스토어의 구성 다섯 가지와, 가장 보호해야 할 것은?
• CA 키를 로봇에 두면 안 되는 이유는?
• enclave가 무엇이며, 프로세스·노드와의 관계는?
• enclave 세분화의 절충과, 실무적 절충안은?
• 컴포넌트화가 권한 분리에 미치는 영향은?
• 정책이 통제하는 대상 네 가지와, 정책 초안을 생성하는 실무적 순서는?
• 자동 생성 정책을 그대로 쓰면 안 되는 이유는?
• ROS_SECURITY_STRATEGY의 두 값과, 운영에서 Enforce여야 하는 이유는?
• "개발은 비활성, 운영은 Enforce"를 권하는 근거는?
• 정책 작성 전략 네 가지와, 역할별 enclave 예시를 들 수 있는가.
• "명령 발행 enclave를 최소화하라"의 효과는?
• 운영에서 고려할 일곱 항목과, 인증서 만료가 왜 심각한 운영 사고인가.
• 시계 오차가 보안에 미치는 영향은?
• "정책 문제인가 QoS 문제인가"를 구분하는 방법은?
• 키스토어의 디렉터리 구성과 기본 권한 파일의 범위는? ROS_SECURITY_ENABLE을 1로 두면 무슨 일이 생기는가(13.2.12).

다음 장 13.3은 그 아래 층 — DDS-Security 플러그인의 구조와 설정을 다룬다.