15.3 노드 및 사용자 인증 (Authentication)

15.3 노드 및 사용자 인증 (Authentication)

통신 채널을 암호화(TLS)하는 것과, 채널에 진입한 주체의 신원을 확정(Authentication)하는 것은 서로 독립적인 보안 계층의 과제다.

Zenoh 네트워크는 본질적으로 분산형 개방 통신망(Distributed Open Network)을 지향하므로, 익명의 패킷과 인가되지 않은 노드의 횡행을 방지하기 위한 체계가 필수적이다. 본 절에서는 통신 노드가 자신의 신분을 증빙하고 라우터 데몬(Router Daemon)이 이를 논리적으로 검증하는 인증(Authentication) 메커니즘을 해부한다. 허가되지 않은 무단 노드(Unauthorized Node)의 접근을 물리적·논리적 인그레스(Ingress) 단계에서 전면 차단하는 런북(Runbook)을 수립하라.

1. 인증(Authentication)과 인가(Authorization)의 구조적 분리

네트워크 접근 통제 시스템에서 주체를 식별하는 행위(인증)와 도출된 주체에게 자원 사용 권한을 부여하는 행위(인가)는 아키텍처 상 엄격히 분리되어야 한다.

1. 제1 계층: 인증 (AuthN, Authentication)

  • 목적: “네트워크 진입을 시도하는 주체의 신원은 무엇인가?”
  • 동작 원리: 네트워크 입구에서 수문장 역할을 수행한다. 접속자가 제시한 자격 증명(비밀번호, 토큰, TLS 인증서 등)이 불일치할 시, 즉각적으로 하위 전송 계층(TCP/QUIC)의 소켓 연결을 파기(Tear-down)한다. 이는 논리적 세션 수립 단계에서 단 1회성으로 엄격하게 집행되는 초기 검문 절차다.

2. 제2 계층: 인가 (AuthZ, Authorization / ACL)

  • 목적: “신원이 확정된 주체에게 허용된 데이터 접근 범위(Topic 영역)는 어디까지인가?”
  • 동작 원리: 1차 인증 관문을 통과한 클라이언트에게는 신원 토큰(Identity Token, 예: Username)이 부여된다. 이후 해당 클라이언트가 발생시키는 모든 발행(Put) 및 구독(Get, Subscribe) 트래픽에 대하여, 라우터 내부의 접근 제어 목록(ACL) 플러그인이 패킷 단위로 리소스 매칭 검사(Access Control)를 수행한다.

인증 모델이 취약할 경우 시스템 전체의 제어권이 타협되나, 인가 모델의 결함은 특정 리소스 영역의 침해로 제한되는 방어선 효과를 낳는다. 따라서 시스템 아키텍트는 인증을 가장 보수적으로, 인가는 가장 파편화된 다단 구조로 설계해야 한다.

graph TD
    classDef clientClass fill:#e1f5fe,stroke:#333,stroke-width:1px;
    classDef authNClass fill:#fff3e0,stroke:#333,stroke-width:1px;
    classDef authZClass fill:#e8f5e9,stroke:#333,stroke-width:1px;
    classDef resourceClass fill:#f3e5f5,stroke:#333,stroke-width:1px;

    Client[Client Node / User<br>Provides Credentials]
    
    subgraph "Zenoh Router Security Engine"
        AuthN{Authentication Engine<br>AuthN Plugin}
        AuthZ{Authorization Engine<br>ACL Plugin}
    end
    
    TopicA[(Topic A<br>Telemetry)]
    TopicB[(Topic B<br>Control)]

    Client -->|Credentials<br>Cert / Password| AuthN
    AuthN -- Invalid --> Drop((Socket Drop))
    AuthN -- Valid Session<br>Identity Linked --> AuthZ
    
    AuthZ -- `Put` TopicA<br>Allowed --> TopicA
    AuthZ -- `Get` TopicB<br>Denied --> Reject((Packet Drop))

    class Client clientClass;
    class AuthN authNClass;
    class AuthZ authZClass;
    class TopicA,TopicB,Drop,Reject resourceClass;

2. 비밀번호 및 사전 공유 키(PSK) 기반 인증

과거의 16비트/32비트 마이크로컨트롤러(MCU)와 같이 자원이 극도로 제약된 에지 시스템에서는 복잡한 X.509 인증서 파싱 및 비대칭 키 연산을 수행할 메모리 여력이 부족할 수 있다. 이러한 환경에서는 경량화된 평문 비밀번호(Password) 인증법이 차선책으로 활용된다.

1. 하이브리드 패턴 체계의 준수
절대 평문 통신 규약(일반 TCP) 최상단에 비밀번호 인증 방식을 독립적으로 구동시켜서는 안 된다. 반드시 전송 계층 암호화(TLS/QUIC) 터널 시스템과 결합하여, 이터널 내부의 검증 수단으로만 비밀번호를 사용하는 하이브리드(Hybrid) 패턴을 고수해야 한다.

2. 라우터 유저 테이블(htpasswd) 구축 런북
웹 서버 아키텍처의 기본 모듈(.htpasswd)과 동일하게, 암호화 해싱된 유저 자격 증명 테이블 파일을 생성한다.

# Basic Auth 규격의 유저 테이블 생성 및 대상 추가 (robot_alpha)
# -B 매개변수를 통해 bcrypt 해싱 알고리즘 강제 적용
htpasswd -B -c /var/lib/zenoh/users.passwd robot_alpha

3. 데몬 Auth 플러그인 프로비저닝

// zenohd.json5 환경 설정
plugins: {
  // 인증(Authentication) 플러그인 선언
  auth_password: {
    // 기 정의된 해시 패스워드 테이블을 참조하는 스키마
    passwd_file: "/var/lib/zenoh/users.passwd"
  }
}

본 설정을 적용하면 에지 노드는 zenoh::Config 구조체에 사용자 아이디(robot_alpha)와 암호 수단(SuperSecret123!)을 탑재해야만 접속 허가를 취득할 수 있다. 하드웨어 스펙 한계에 묶인 에지 노드군을 단일 환경 재분배 없이 수용할 수 있는 하위 호환성(Backward Compatibility)을 보장한다.

3. X.509 인증서 기반의 강력한 엔드포인트 인증

공유 비밀번호(Shared Password) 모델은 형상 관리 시스템(Git 등)이나 코드 저장소에 하드코딩된 형태로 남을 수 있는 인적 취약성을 내포한다. 하드웨어 보안 모듈(TPM) 또는 안전 구역에 격리 보관된 수리적 인증서(X.509) 기반 신원 증명이 진보된 인증의 최종 형태다.

1. 상호 TLS(mTLS)를 통한 수동적 인가 스위칭 전략
15.2절에 기술된 상호 TLS(mTLS) 모델의 확립은 곧 완벽에 가까운 인증 체계의 구축을 의미한다.
연결이 수립되는 순간 Zenoh 인증 모듈은 클라이언트가 송부한 X.509 인증서에서 Common Name (CN) 메타데이터 필드를 역추적한다.

  • 클라이언트 인증서의 Subject 필드 내 CN=drone_007 항목이 적중될 경우, 시스템은 별도의 질의응답 없이 해당 노드의 논리적 연산 주체 식별자(Username)를 drone_007로 고정 확약한다.
  • 즉각적으로 2차 보안 관문인 ACL(Access Control List) 계층으로 식별자가 인계되어 권한 필터링 구조로 매끄럽게 전이된다.

2. 무결성의 사슬(Chain of Trust) 사수
악의적인 개체가 자체 발급(Self-signed) 인증서에 CN=admin을 기입하여 접근할 경우에 대비한 방어 기제가 요구된다. 라우터는 인증서의 발행 기관(Issuer) 서명이 내부에 등록된 사내 최상위 인증 기관(Root CA)의 암호화 해시와 완벽하게 부합하는지를 검증한다. 검증에 실패한 인증서는 무결성의 사슬(Chain of Trust) 위반으로 간주되며, 세션은 물리적 소켓 레이어에서 즉각 파기된다.

4. 커스텀 인증 플러그인 개발 및 외부 IdP 연동

대규모 IT 인프라를 보유한 90% 이상의 기업 생태계에서는 이미 AWS IAM, Google Cloud OAuth 2.0, 혹은 사내 활성 디렉터리(AD/LDAP)와 같은 전사적 사용자 인증 제공자(IdP, Identity Provider) 체계를 운영 중이다.
Zenoh 전용으로 격리된 .htpasswd 테이블이나 이중화된 단독 CA 시스템을 운영하는 것은 조직의 관리 복잡성(Overhead Nightmare)을 유발한다.

1. OIDC 연계형 커스텀 인증 플러그인 런북
Zenoh는 코어 기능을 Rust 언어 기반의 확장 모듈(Plugin) 시스템으로 분리 제공한다. 시스템 엔지니어는 커스텀 **인증 플러그인(Custom Auth Plugin)**을 구현하여 라우터 엔진에 동적으로 결합(Inject)할 수 있다.

2. zenoh-plugin-trait의 Auth_check 인터페이스 재정의 (Overriding)
아래는 유저가 보낸 비밀번호를 OAuth 기반의 토큰(Token)으로 상정하여 거대 사내 통제 시스템(IdP)으로 HTTP 검증 질의를 위임하는 로직 체계의 예시이다.

// Rust 환경에서의 외부 인증 시스템(SSO) 연동 플러그인 오버라이딩
async fn check(&self, username: &str, provided_token: &str) -> ZResult<bool> {
    // 1. 클라이언트가 암호 입력란에 기입한 값을 사내 IdP 시스템 검증용 토큰으로 취급
    let my_central_auth_api = "https://my-company-sso.cloud.com/api/v1/verify_edge_token";
    
    // 2. 비동기 HTTP 요청을 통해 중앙 관제 시스템으로 토큰의 유효성을 실시간 질의
    let res = reqwest::Client::new()
        .post(my_central_auth_api)
        .json(&serde_json::json!({ 
            "client_id": username,
            "secret_token": provided_token 
        }))
        .send().await;

    // 3. 중앙 검증서버가 HTTP 200 OK 코드를 응답할 때에만 라우터 억세스를 개방(true 반환)
    if res.unwrap().status().is_success() { 
        Ok(true) 
    } else { 
        Ok(false) 
    }
}

상기 설계 방식을 채택할 경우 수만 대의 생산 로봇과 다부서 관리 인원들은 Zenoh 한정의 신규 패스워드 발급 절차를 거칠 필요가 일절 없다. 기존 사내 인트라넷 환경에서 통용되던 검증된 싱글 사인온(SSO, Single Sign-On) 체계만으로 전 지구적 분산 Zenoh 네트워킹의 통합 지침을 확보할 수 있게 된다.