11.8 ROS2와 Zenoh 환경의 시스템 보안 및 접근 제어

로봇이 해킹당하면 그것은 단순한 정보 유출이 아니라, “수백 킬로그램짜리 쇳덩어리가 사람을 향해 돌진하는” 물리적 테러(Cyber-Physical Attack)가 된다.

기존 ROS2 에서는 SROS2 라는 복잡한 보안 스펙이 존재했지만, 인증서를 노드마다 발급해 줘야 하는 미친듯한 관리 오버헤드 때문에 사실상 공장망에서는 방화벽만 믿고 다 꺼두는 평문(Cleartext) 통신이 만연했다. 이 장에서는 Zenoh 가 어떻게 SROS2 의 고통을 없애면서도 클라우드 레벨의 견고한 인증(Authentication)과 차단(ACL)을 ROS2 생태계에 이식해 주는지에 대한 보안 관제 런북을 제시한다.

1. ROS2 SROS2와 Zenoh 기본 보안 정책의 차이점과 연동

“내 로봇은 SROS2 를 쓰고 있는데, Zenoh 브릿지를 붙이면 어떻게 되는 건가요?”
가장 많은 보안 담당자들이 묻는 질문이다.

1.0.1 [인스펙션] 혼돈의 이중 보안망 분리 해석

SROS2 (DDS-Security 기반)는 데이터가 칩(메모리)에서 나오는 순간 AES 알고리즘으로 패킷을 잠가버린다. 이 암호화된 패킷이 브릿지를 거쳐 Zenoh 로 넘어가면 어떻게 될까?

이중 암호화 충돌의 늪 (The Double-Encryption Trap)
SROS2 로 완벽히 잠긴 패킷을 zenoh-bridge-dds 가 받아들면 브릿지는 이렇게 생각한다. “어? 내가 해독할 수 없는 이상한 바이트네?”
그리고는 이 암호화된 덩어리를 있는 그대로 뭉뚱그려서 Zenoh 망으로 던져버린다. 이렇게 되면, Zenoh 단의 강력한 필터 매핑 기능 (예: fleet/status 토픽만 허용) 같은 라우팅 기능이 모조리 먹통이 된다. 내용물을 못 읽으니까!
아키텍처 분리 전술 (Decoupling Policy)
가장 이상적인 타협안은 “로봇 내부망은 SROS2 를 아예 꺼버리고 순수 DDS 평문으로 돌리되, 밖으로 나가는 출구인 Zenoh 세션에만 TLS/SSL 을 강하게 거는 것” 이다.
로봇 안에 해커가 들어왔다면 이미 끝난 게임이다. 보안은 외부(WAN)에서 내부(LAN)로 들어오는 관문을 Zenoh 의 무식할 정도로 단단한 보안 스펙으로 틀어막는 데 집중해야 한다.

2. 인증서 기반의 노드 및 라우터 상호 인증 적용

누군가 당신의 공장 AWS 라우터 IP를 알아내어 가짜 센서 데이터를 흘려보내면 공장 라인이 멈춘다. 오직 “내가 허락한 내 로봇” 만이 이 클라우드 통신망에 들어올 수 있도록 인증서 통과(Handshake) 절차를 강제해야 한다.

2.0.1 [Runbook] 상호 인증 (Mutual TLS) 인프라 구축 전술

서버만 인증서를 갖는 일반 웹(HTTPS)과 달리, 기계(로봇)도 자기가 진짜라는 증명서(Client Cert)를 서버에 제출해야 하는 mTLS 세팅이다.

1. 중앙 CA (Certificate Authority) 생성

## 본사에서 관리할 최상위 마스터 키 창조 (절대 유출 금지)
openssl req -x509 -newkey rsa:4096 -keyout ca.key -out ca.crt -days 3650 -nodes

2. AWS 라우터용 인증서 발급

openssl req -newkey rsa:2048 -keyout aws_router.key -out router.csr -nodes
openssl x509 -req -in router.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out aws_router.crt -days 365

3. 로봇 1호기용 인증서 발급 (로봇 펌웨어에 주입할 것)

openssl req -newkey rsa:2048 -keyout robot001.key -out robot001.csr -nodes
openssl x509 -req -in robot001.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out robot001.crt -days 365

4. 라우터와 브릿지의 무장 개시

관제 라우터 (AWS) 구동: “내 CA 가 도장 찍어준 로봇 인증서가 아니면 다 끊어버려라!”
zenohd -e tls/0.0.0.0:7447 --tls-server-cert aws_router.crt --tls-server-key aws_router.key --tls-client-auth-trust-store ca.crt
로봇 브릿지 (공장) 구동: “AWS 에 도킹할 때 내 로봇 신분증명서를 제출한다!”
zenoh-bridge-dds -e tls/aws-ip.com:7447 --tls-client-cert robot001.crt --tls-client-key robot001.key --tls-server-trust-store ca.crt

이 10줄의 런북으로 당신의 로봇 군집망은 해커의 무차별적인 봇넷(Botnet) 포트 스캐닝으로부터 100% 방어막을 갖추게 되었다.

3. TLS/DTLS를 이용한 ROS2 토픽 페이로드 암호화 전송

로봇의 카메라(Camera)와 음성(Microphone) 데이터는 심각한 프라이버시 침해 유발 물질이다.
위 11.8.2 장에서 tls/ 엔드포인트를 열어 인증서를 꽂아 넣은 순간, 당신은 인증뿐만 아니라 완벽한 패킷 암호화의 궤도에 오른 것이다.

3.0.1 [인스펙션] TCP TLS 와 UDP DTLS 의 전술적 분기

1. TLS (TCP 기반 암호화)

명령어: zenoh-bridge-dds -e tls/...
ROS2 의 좌표, 상태, 에러 로그 통신에 완벽하다. TCP 의 강력한 무결성 위에 AES 암호화가 올라타기 때문에 단 1바이트의 유출이나 위조도 불가능하다. 단점은 핑(Ping)이 떨어지면 통신이 버벅댄다는 것.

2. DTLS (UDP 기반 암호화)

명령어: zenoh-bridge-dds -e dtls/...
카메라 영상(Video Stream)이나 라이다(LiDAR) 를 관제 서버로 쏴 올릴 때 무조건 사용해야 하는 “비밀 스텔스기” 모드다.
UDP 라서 일부 프레임이 유실될 수는 있어도, 스트리밍 자체의 실시간성 지연은 없으며, 이 영상들을 중간에 통신사가 엿듣더라도 완벽한 노이즈 폭풍(Garbage Bytes)으로만 보이게 된다.

아키텍트의 타협점:
모든 통신을 전부 암호화하면 로봇 보드(라즈베리 파이)는 암호 변환 계산을 하다가 스스로 열사병에 걸려 죽는다.
민감한 데이터(/camera)만 DTLS 로 올려 보내는 전용 브릿지를 하나 파고, 배터리 같은 쓰레기 데이터는 그냥 평문 UDP udp/ 로 던지는 “채널 분리 런북” 이야말로 마스터 엔지니어의 품격이다.

4. 접근 제어(ACL) 설정을 통한 비인가 노드의 토픽 구독 및 발행 원천 차단

“우리 사내망(LAN)에 누군가 실수로 ROS2 노드를 켰더니, 그 녀석이 공장 로봇 전체에 엉뚱한 /cmd_vel 을 퍼블리시해서 로봇들이 일시에 미쳐 날뛰었다.”

이런 ‘내부자 트롤링’ 은 SROS2 로 잡기엔 너무 품이 많이 든다. Zenoh 라우터가 강력한 경찰(ACL) 역할을 대신 수행해야 한다.

4.0.1 [Runbook] 라우터 톨게이트 ACL 검문 전술

AWS 이든 공장 관제 PC 든, 중앙에 떠 있는 zenohd (라우터)의 설정 파일(zenoh.json5) 안에서 어떤 IP 혹은 어떤 인증서를 가진 자가 어떤 토픽을 만질 수 있는지를 강제로 명문화해야 한다.

// zenohd_acl_config.json5
{
  plugins: {
    // 접근 제어 플러그인 가동!
    access_control: {
      rules: [
        {
          // [규칙 1: 관제 서버 특권]
          // 관제 서버망(10.0.0.99)에서 들어오는 자는 로봇 컨트롤(/fleet/*/cmd)을 '발행(Put)' 할 수 있다.
          id: "admin-server",
          host: "10.0.0.99",
          allow: {
            publish: [ "fleet/*/cmd" ],
            subscribe: [ "fleet/*/**" ] // 모든 상태 조회 가능
          }
        },
        {
          // [규칙 2: 로봇 단말 통제]
          // 인증서 이름(Subject Name)이 "robot001" 인 접속자는 
          // 오직 자기 자신의 폴더(/fleet/robot001/...) 안에만 게시(Put) 할 수 있다!
          // 감히 002번 로봇의 좌표를 건들거나, 자기가 명령권자인 척 /cmd 토픽을 발사하면 즉각 통신을 해방시켜버린다(Drop).
          id: "robot-nodes",
          cert_subject: "CN=robot001", 
          allow: {
            publish: [ "fleet/robot001/status", "fleet/robot001/camera" ],
            subscribe: [ "fleet/robot001/cmd" ]
          }
        }
      ]
    }
  }
}

이 규칙이 장전된 상태로 라우터가 깨어나는 순간, 무자비한 네트워크 통제가 시작된다.
만약 해커가 1번 로봇을 탈취하여 /fleet/robot002/cmd_vel (2번 로봇아 죽어라) 이라는 토픽을 생산해서 라우터로 쐈다 치자. 라우터는 이 패킷의 아이디를 확인하고 매몰차게 폐기(Drop)해버린 후 콘솔창에 시뻘건 ACL 위반 경고 로그를 뱉어낸다.

물리적 격리 없이 오직 텍스트 파일(ACL) 하나로 거대한 로봇 군집 파티션을 완벽하게 구획(Segmentation) 해내는 지배의 설계다.