15.7 이기종 통신 및 특수 환경의 보안 확장

15.7 이기종 통신 및 특수 환경의 보안 확장

Zenoh 생태계는 본질적으로 이기종 프로토콜(Heterogeneous Protocols)과의 상호 운용성(Interoperability)을 전제로 설계되었다. 그러나 ROS 2, MQTT, DDS 와 같은 레거시(Legacy) 통신망이 Zenoh 브릿지(Bridge)를 통해 단일 네트워크로 통합되는 시점은, Zenoh의 강력한 제로 트러스트(Zero-Trust) 보안 경계가 외부망의 가장 취약한 링크(Weakest Link) 수준으로 하향 평준화될 수 있는 치명적인 위협 벡터(Threat Vector)를 생성한다.

본 절에서는 프로토콜 통역 레이어(Protocol Translation Layer)가 개입하는 복합 네트워크 환경에서, 타 통신 규약의 암호화 스펙(SROS2, MQTT TLS 등)을 Zenoh의 고유 인증 체계로 안전하게 위임(Delegation)하고 논리적 오류를 방어하는 디커플링(Decoupling) 전술을 명세한다.

1. SROS 2(Secure ROS 2)와 Zenoh 브릿지 간의 보안 컨텍스트 위임

로봇 운영체제인 ROS 2는 독자적인 SROS 2(Secure ROS 2) 암호화 및 접근 제어 아키텍처를 내장하고 있다. ROS 2 노드 군집이 생성하는 데이터 스트림을 Zenoh 브릿지가 수집하여 광역 클라우드로 전송할 시, 상이한 두 보안 공간(Security Enclave) 간의 식별 및 인가 교착 상태(Deadlock)를 해소해야 한다.

1. SROS 2 참전(Enclave) 자격 획득 및 컨텍스트 매핑
브릿지(Bridge) 프로세스는 ROS 2 도메인 내부에서는 합법적인 ’참여 노드’로, 외부 Zenoh 라우터망에서는 ’데이터 퍼블리셔’로 기능하는 식별의 이중성(Identity Duality)을 지닌다. 프로세스 기동 시 ROS 2 보안 공간(Enclave)에 합당한 x.509 인증서 스토어(Keystore)를 선제적으로 프로비저닝해야 한다.

# 브릿지 데몬이 SROS 2 보안 공간 구조를 해석할 수 있도록 필수 환경변수 선언
export ROS_SECURITY_ENABLE=true
export ROS_SECURITY_STRATEGY=Enforce
export ROS_SECURITY_KEYSTORE=/path/to/my_bridge_keystore

# SROS 2 보안 컨텍스트를 상속받은 상태로 브릿지 인스턴스 기동 및 TLS 터널 연결
zenoh-bridge-dds -e "tls/cloud-router-endpoint:7447"

2. Zenoh TLS 터널로의 암호학적 환승 (Cryptographic Handover)
브릿지가 SROS 2 망에서 암호화된 페이로드를 성공적으로 수신 및 해독(Decryption) 완료 시, 즉각적으로 데이터를 클라우드 전송에 적합한 Zenoh TLS 프로토콜 스펙으로 재암호화(Re-encryption)해야 한다.
이는 zenoh-bridge-dds 실행 플래그(-e)의 접두사를 tls/ 스킴으로 강제하고, 브릿지 고유의 zenoh.json5 설정 파일 내 클라이언트 인증서(mTLS)를 명시함으로써 구현된다. 결과적으로 데이터는 SROS 2(로컬 엔클레이브) \rightarrow 브릿지 매립 계층(해독 및 재포장) \rightarrow Zenoh TLS(광역 네트워크)이라는 물리적으로 격리된 두 개의 암호화 터널을 순차적으로 통과하는 종단간 방어망을 형성한다.

2. Zenoh-Pico (마이크로컨트롤러 환경)의 경량 암호화 적용 한계와 대안

초저전력 아키텍처(예: 아두이노, ESP32 등) 기반의 에지 장치를 타겟으로 하는 Zenoh-Pico 환경에서는 수십 킬로바이트(KB) 수준의 가용 메모리 한계로 인하여 연산 집약적인 TLS 1.3 암호화 제품군을 네이티브로 구동하는 것이 물리적으로 불가능하다.

1. 물리적 고립(Physical Isolation) 기반 P2P 평문(Plaintext) 허용
비대칭 암호화 연산이 제한되는 마이크로컨트롤러(MCU) 노드 \rightarrow 에지 게이트웨이(예: 라즈베리 파이) 구간 단말 링크(예: I2C, BLE, Serial, 격리된 로컬 TCP)에 한하여, 평문 데이터 전송을 예외적으로 승인한다. 이 구간의 보안은 네트워크 암호화가 아닌 물리적 접근 통제(Physical Access Control)에 전적으로 의존한다.

// [관문용 에지 라우터 설정 - zenohd.json5]

// 1. 단말 노드(Pico)가 접속할 로컬 평문 소켓 개방 (외부 라우팅 금지)
listen: ["tcp/192.168.1.100:7447"] 

// 2. 수집된 데이터를 상위 클라우드에 업링크할 때는 강제가 적용된 TLS 채널만을 사용
connect: ["tls/cloud-server.com:7447"]

2. 에지 라우터의 “보안 대리인(Security Proxy)” 승격 로직
초소형 센서 단말망의 기능 요구사항은 관문(Gateway) 라우터까지만 메시지를 전파하는 파이어 앤 포겟(Fire-and-Forget) 패턴으로 한정된다.
수신된 평문 패킷은 게이트웨이에 상주하는 범용 Zenoh 라우터 본체(zenohd)의 유휴 컴퓨팅 자원을 활용하여 즉각 TLS 터널 페이로드로 포장 체인지(Encryption Offloading)된다. 이는 MCU 단말의 연산 부하 리스크를 전멸시키며 외부 인터넷 구간에서의 도청 취약점을 완벽히 봉쇄하는 최적의 현실적 보안 타협점이다.

3. MQTT 및 DDS 브릿지 연결 시의 보안 경계(Security Perimeter) 설정

산업 현장에 산재한 레거시 MQTT(1883 포트 기저) 단말기 집단은 대부분 기본 인증(Basic Auth) 정보만을 평문화하여 브로드캐스트하는 구조적 약점을 지니고 있다.

1. DMZ (Demilitarized Zone) 억류 전술 및 전진 배치
서드파티 브릿지 인스턴스를 중앙 클라우드 네트워크나 코어망 깊숙이 배치해서는 안 된다. 오염 가능성이 농후한 레거시 프로토콜이 Zenoh 생태계와 최초로 맞닿는 접점, 즉 “브릿지 프로세스” 자체를 최전방 엣지(Edge) 지뢰밭으로 물리적 전진 배치해야 한다.

  • 경계망 설계: 기존 MQTT 브로커(Mosquitto 등)가 구동되는 현장 제어 PC망 내부에 zenoh-bridge-mqtt를 동거(Co-location)시킨다.
  • 센서 \rightarrow 브로커 \rightarrow 브릿지 구간: 단일 건물 내부의 스위칭 허브 구간(물리적 통제 구역)으로 위험 노출 면적을 최소화한다.
  • 브릿지 \rightarrow Zenoh 라우터 구간: 브릿지망이 수렴된 데이터를 외부로 유출하는 지점부터는 Zenoh의 엄격한 상호 인증(mTLS)과 ACL 룰셋의 지배를 받는 암호화 터널을 의무적으로 생성한다.

2. 브릿지 전용 격리 식별자(Isolated Identity) 생성
코어 Zenoh 라우터의 인증 스키마 관점에서 zenoh-bridge-mqtt는 하나의 외부 클라이언트(Client) 엔티티로 취급된다.
시스템 운영자는 브릿지의 인증 파일에 username: legacy_mqtt_bridge 등의 격리 식별자를 명시해야 한다. 더불어 라우터 중앙 ACL 정책에서는 해당 계정이 주요 제어망이나 코어 백엔드 토픽 트리 구간에 간섭할 수 없도록 차폐하고, 오로지 이양된 센서 서브트리(factory/mqtt_zone/**) 영역에 대해서만 단방향 발행(Put)을 허용하는 엄격한 샌드박스(Sandbox) 정책을 강제해야 한다. 레거시 단말의 침해 리스크가 핵심 네트워크 심장부로 상속되는 전이(Spill-over) 현상을 원천 방어하라.

graph TD
    classDef legacy fill:#ffe3e3,stroke:#c62828,stroke-width:1px;
    classDef bridge fill:#fff3e0,stroke:#ef6c00,stroke-width:1px;
    classDef zenoh fill:#e1f5fe,stroke:#0277bd,stroke-width:1px;
    classDef cloud fill:#f3e5f5,stroke:#6a1b9a,stroke-width:1px;

    subgraph Factory_Floor [Factory Floor (Physical Perimeter)]
        MQTTSensor[Legacy MQTT Sensor<br>Plaintext: 1883]:::legacy
        Broker[Mosquitto Broker]:::legacy
        Bridge{zenoh-bridge-mqtt<br>Identity: legacy_mqtt_bridge}:::bridge

        MQTTSensor -- Local Network --> Broker
        Broker -- Local Loopback --> Bridge
    end

    subgraph Cloud_Infrastructure [Zenoh Cloud Network]
        CloudRouter[Zenoh Cloud Router<br>TLS / ACL Enforced]:::zenoh
        Backend[(Backend Datastore)]:::cloud
    end

    Bridge == TLS Tunnel (mTLS) ==> CloudRouter
    
    CloudRouter -.-> |ACL Drop| MaliciousPut[Attempt to Put<br>`core/control`]
    CloudRouter --> |ACL Allow| ValidPut[Allowed Put<br>`factory/mqtt_zone/**`]
    
    ValidPut --> Backend