15.4 접근 제어 목록(ACL)과 권한 인가 (Authorization)

15.4 접근 제어 목록(ACL)과 권한 인가 (Authorization)

네트워크의 1차 관문인 인증(Authentication)을 통과한 노드라 할지라도, 허가되지 않은 전역 광역 질의(**)나 파괴적인 삭제 명령(Delete)을 통해 인프라 전반을 타협(Compromise)할 위험은 여전히 존재한다.

Zenoh 시스템은 데이터 버스를 통과하는 모든 단일 패킷의 페이로드를 검사하여, 대상 토픽(Key Expression)과 오퍼레이션 유형(Put, Get 등)의 적합성을 즉각적으로 판독하는 ACL(Access Control List) 접근 제어 모듈을 기본 내장하고 있다. 이 모듈은 단일의 비인가 패킷이 감지되는 즉시 백엔드 스토리지 계층에 도달하기 전 선제적으로 이를 폐기(Drop)하는 심층 방어(Defense in Depth) 아키텍처를 제공한다.

1. Zenoh 키 표현식(Key Expression) 기반의 정밀한 권한 제어

전통적인 하드웨어 방화벽이 L3/L4 계층의 IP 주소와 포트 번호에 의존했다면, 데이터 중심형(Data-Centric) 통신 격자인 Zenoh는 L7 애플리케이션 계층의 **키 표현식(Key Expression, URIs)**을 기반으로 논리적 차폐를 수행한다.

1. 와일드카드 블랙리스트 전술
가장 치명적인 위협 패턴은 광역 탐색 와일드카드(**)의 무분별한 남용이다. 라우터 ACL 설정을 통해 특정 식별자 그룹에게 하위 트리의 데이터 구조 전체를 순회(Traverse)하는 범위 질의 쿼리를 원천적으로 배제해야 한다.

  • 허용: factory/sensor/temp
  • 금지: factory/sensor/**
    본 명세를 적용할 경우, 개별 센서 값의 단일 구독은 승인하되 단 한 번의 쿼리로 전체 관제망의 메타데이터를 싹쓸이하는 스니핑(Sniffing) 시도는 라우터 코어에서 블로킹된다.

2. 스페이스 기반 논리적 망 분리 (Lateral Movement 방어)
운영 관제 노드(Admin Node)에게는 전체 네임스페이스 구독 권한을 인가하되, 단위 로봇 노드(robot_1)에게는 자신의 제한된 토픽 공간(robot/1/**)에 대해서만 발행(Put)을 허용하도록 구획화해야 한다. 이를 통해 개별 에지(Edge) 장치가 물리적으로 탈취당하더라도, 공격자가 타 노드의 제어 명령 채널로 수평 이동(Lateral Movement)하는 행위를 네트워크 상에서 완벽히 격리할 수 있다.

2. Publish, Subscribe, Query, Reply 각각의 권한 분리 전략

Zenoh 라우팅 네트워크를 경유하는 메시지는 4개의 오퍼레이션 유형(Operation Type)으로 엄격하게 계층화되어 통제된다. 단일 네임스페이스에 대한 포괄적 읽기/쓰기 권한을 지양하고, 마이크로 퍼미션(Micro-Permissions) 단위의 통제를 적용해야 한다.

1. 생산자 노드(Sensor Edge) 샌드박싱
무인 텔레메트리를 담당하는 단순 온도 센서는 데이터를 브로드캐스트(Put)하는 역할만을 인가받아야 한다.

  • 인가 권한: publisher (발행 전용 오퍼레이션 인가)
  • 보안 검증: 생산자 노드가 해킹되어 역으로 전체망의 Get 쿼리를 시도하거나 스파이 목적의 Subscribe 소켓을 개시할 경우, 라우터 보안 엔진은 즉시 에지 단말의 접속 세션을 강제 종료시킨다.

2. 소비자 노드(Dashboard/Monitor) 샌드박싱
데이터를 소비하는 중앙 관제 소프트웨어는 오직 청취 역할에만 국한되어야 한다.

  • 인가 권한: subscriberquerier (구독 및 질의 오퍼레이션 인가)
  • 보안 검증: 대시보드 인스턴스에서 비정상적인 액추에이터 제어 명령(z_put "robot/motor/speed" "200")이 발생하더라도 인가되지 않은 쓰기 권한은 송출 단계에서 소멸(Discard)된다.

3. 백엔드 스토리지 엔진(Backend Storage) 샌드박싱
데이터베이스 연동 전용 라우터 플러그인 또는 스토리지 엔진 노드 역시 최소 권한 원칙을 준수한다.

  • 인가 권한: 타 노드의 쿼리 질의에 응답하기 위해 필수적인 replier 오퍼레이션만이 선별적으로 승인되어야 한다. 데이터의 위상을 점유하는 공식 인스턴스만이 유효한 반환값 블록을 회신할 수 있다.

3. 역할 기반 접근 제어(RBAC) 모델의 Zenoh 적용

1만 대 규모의 대단위 로봇 플릿(Robot Fleet)을 운영할 시 개별 노드 아이디(Node ID) 대상의 명시적 권한 부여는 설정 파일의 팽창과 연산 오버헤드를 야기한다. 시스템 설계자는 개별 사용자가 아닌 **군집 역할(Role)**이라는 메타 컨테이너를 기반으로 검열 트리를 구축해야 한다.

1. 역할(Role) 정의
시스템 기획 단계에서 zenohd.json5 내에 다음과 같은 논리적 권한 그룹을 선언한다.

  • Role: Edge_Worker (현장 생산 장비)
  • Role: Datacenter_Inspector (감사 및 모니터링 노드)
  • Role: Super_Admin (시스템 제어기)

2. 유저(Identity) 투하 및 매핑
초기 통신 핸드쉐이크의 인증(AuthN) 단계를 통과하여 drone_05 또는 operator_1로 식별된 주체들은, 중앙 매핑 규칙(Mapping Rule)에 수렴하여 즉시 특정 롤 식별자로 격상(Upgrade)된다.

3. 퍼미션(Permission) 구조 연계
ACL 검열소는 네트워크 헤더에서 사용자 아이디를 삭제하고, 상응하는 권한 그룹에 대한 인가 대조 작업만을 시행한다. 이는 라우팅 테이블 크기를 O(N)에서 O(1) 수준으로 극단적으로 단축 시키는 효율적 스케일아웃(Scalable Access Control) 패턴의 근간이 된다.

graph TD
    classDef userClass fill:#e1f5fe,stroke:#333,stroke-width:1px;
    classDef dictClass fill:#fff9c4,stroke:#333,stroke-width:1px;
    classDef roleClass fill:#ffcc80,stroke:#333,stroke-width:1px;
    classDef permClass fill:#e8f5e9,stroke:#333,stroke-width:1px;

    User1[drone_01]:::userClass
    User2[drone_02]:::userClass
    User3[operator_server]:::userClass

    Dict{Identity to Role<br>Mapping Table}:::dictClass

    RoleW[Role: worker]:::roleClass
    RoleI[Role: inspector]:::roleClass

    PermW[Allow: Put `drone/**` <br> Deny: Query `**`]:::permClass
    PermI[Allow: Sub `**` <br> Deny: Put `**`]:::permClass

    User1 --> Dict
    User2 --> Dict
    User3 --> Dict

    Dict -.-> RoleW
    Dict -.-> RoleI

    RoleW ==> PermW
    RoleI ==> PermI

4. JSON/JSON5 기반 ACL 설정 파일 작성 문법 및 예제

접근 제어 파라미터를 명시적으로 선언하기 위한 라우터 JSON5 검열 룰북의 적용 런북을 아래와 같이 명문화한다.

// zenohd.json5 보안 플러그인 상세 매니페스트
plugins: {
  access_control: {
    // 1. 개별 인증 식별자(User)를 접근 제어 권한 그룹(Role)에 매핑한다.
    users: {
      "drone_01": "worker",
      "drone_02": "worker",
      "monitoring_server": "inspector",
      "admin_sys": "god_mode"
    },

    // 2. 권한 그룹별 정규식 및 연산자 접근 정책(ACL)을 강제한다.
    roles: {
      "worker": {
        // [허용 목록] 소속 도메인 데이터 발행(Put)과 브로드캐스트 수신(Sub) 허용.
        allow: [
          "Put:drone/telemetry/**",
          "Sub:drone/telemetry/**"
        ],
        // [금지 목록] 전역 탐색(Query), 객체 소거(Delete) 및 시스템 루트 경로 쓰기 금지.
        deny: [
          "Query:**",
          "Delete:**",
          "Put:system/config/**"
        ]
      },

      "inspector": {
        // 모니터링 패널은 오직 데이터 상태 수집 및 쿼리만 기능하며 어떠한 변조도 불허한다.
        allow: ["Query:**", "Sub:**"]
      },

      "god_mode": {
        allow: ["**"] // 최상위 시스템 관리 모드 전면 개방
      }
    }
  }
}

해당 접근 제어 규칙이 적재되는 순간, Zenoh 데몬은 라우팅 결정자(Decision Engine) 최전선에 deny 블랙리스트 정책을 오버레이(Overlay)하여 비인가 패킷이 내부 워커 스레드로 전파되는 확률을 원천적으로 소거한다.

5. 시스템 재시작 없는 동적 ACL 업데이트 및 핫 리로드(Hot Reload)

조직을 이탈한 엔지니어의 계정 파기(deny)를 위해 운영 중인 라이브 라우터(Router)를 재기동(Restart)하는 행위는 관제망에 소속된 전체 무인 기기들의 제어 단절(Blind Spot)을 야기한다. 보안 조치가 시스템 전체의 물리적 가용성(Availability) 붕괴를 수반해서는 안 된다.

1. 관리자 토픽스(Admin Topics) 인터페이스 활용
Zenoh는 코어 라우터의 환경 변수 및 보안 정책 자체를 고유 식별자 토픽(Key Expression) 형태로 노출시켜 제어하는 특유의 재귀적(Recursive) 아키텍처를 지원한다. 특정 스탠드얼론 라우터(식별자: 1234)의 보안 ACL 트리는 관리용 예약 네임스페이스 경로인 @/router/1234/plugin/access_control/config에 매핑되어 상주한다.

2. 핫-리로드 API 호출(REST / Zenoh Native Put)
서버를 중지시키지 않고 원격의 인가된 터미널에서 신규 JSON 데이터그램을 타깃 경로에 주입(Put)하는 무정지 업데이트(Hot-Swapping) 런북은 다음과 같다.

# REST API (HTTP PUT) 리퀘스트를 통한 인프라 무정지 정책 핫-리로드
curl -X PUT http://admin:admin_password@<ROUTER_IP>:8000/@/router/local/plugin/access_control/config \
     -H "Content-Type: application/json" \
     -d '{
           "users": { "drone_01": "worker", "compromised_node": "isolated" },
           "roles": { "isolated": { "deny": ["**"] } }
         }'

이 주입 신호가 코어 메모리에 닿는 즉시 데몬 프로세스는 기존 통신 소켓의 단 1나노초의 세션 드랍 없이 ACL 파서 트리 지침을 동적으로 교체한다. 향후 compromised_node 개체가 발송하는 후속 데이터 프레임부터는 즉각적인 네트워크 방화 필터링이 가동되며, 이는 서비스 지속성(Continuity)과 보안 응답 속도를 극한으로 통합한 오퍼레이션 패턴의 전형을 시사한다.