RFC 10011이 TLS 종단 장치를 보안 경계 안으로 가져온다

요약

• RFC 10011은 TLS가 외부에서 종단되는 배포 환경을 대상으로만 HTTP RESTCONF 리스너를 모델링하며, 평문으로 노출된 RESTCONF를 허용 가능한 기본값으로 만들지 않는다.
• 규격은 보안 경계가 TLS 종단 장치까지 확장된다고 명시한다. 구성된 주소, 프록시 수 또는 인증서 릴레이 헤더는 의도된 구성을 기술할 뿐, 실제 외부 연결, 릴레이된 신원 또는 백엔드 경로를 증명하지 않는다.
• Daniel Kade는 외부 인증, 헤더 처리, 하류 격리 및 그 결과인 RESTCONF/NACM 결정을 상호 연관시키되, 비밀 키나 페이로드를 저장하지 않는 종단 장치 경계 수신증(terminator-boundary receipt)을 제안한다.

암호화된 연결은 결정보다 먼저 끝난다

요청이 TLS로 로드 밸런서에 도달한다. 로드 밸런서는 클라이언트 인증서를 검증하고, 암호화를 제거한 뒤 HTTP를 RESTCONF 서버로 전달한다. 백엔드는 인증서를 담고 있다고 주장하는 헤더를 보고, 신원을 접근 제어 결정에 매핑한다. 외곽의 녹색 표시등은 인증서가 유효했다고, 백엔드의 녹색 표시등은 요청이 인가되었다고 말한다.

이 두 불빛 사이에 중요한 질문이 있다. 두 신호가 동일한 트랜잭션에 대한 증거인가?

RFC 10011은 이 질문을 구현 세부사항으로 치부할 수 없게 만든다. 이 규격은 일반 연결과 Call Home을 포함해 RESTCONF 클라이언트 및 서버용 YANG 모델을 정의한다. HTTPS는 여전히 RESTCONF의 필수 전송 계층이다. 그러나 서버 모델은 TLS 종단이 외부에서 처리되는 특정 사례를 위한 HTTP 옵션도 포함한다. 보안 고려사항은 그 결과를 명확히 밝힌다. 보안 경계는 TLS 종단 장치까지 확장된다.

이 한 문장이 통제의 단위를 바꾼다. 보호된 연결은 더 이상 그 자체로 완결된 증명이 아니다. 종단 장치의 구성, 백엔드로의 신뢰 경로, 신원 릴레이, 인가 매핑이 모두 주장의 일부가 된다.

이름 붙은 목적을 가진 예외

RFC 8040은 TLS 없이 HTTP를 통해 RESTCONF를 사용해서는 안 된다고 규정한다. 이 문서만 읽으면, 이후 데이터 모델의http-listen기능은 모순처럼 보일 수 있다. RFC 10011은 아키텍처에 이름을 붙여 이 겉보기 충돌을 해소한다. 해당 리스너는 로드 밸런서 같은 TLS 종단 장치 뒤에 놓인 RESTCONF 클라이언트 또는 서버를 위한 것이다.

이 구분이 중요하다. 지배적인 문장은 “HTTP가 구성 가능하다”가 아니라 “TLS가 다른 곳에서 종단되므로 경계가 그곳까지 확장된다”이다. 이 규격은 관리 인터페이스가 평문으로 노출되는 것을 승인하지 않는다. 또한 인가된 외부 종단 장치 뒤의 백엔드 구간이 TLS를 사용해야 한다고 강제하지도 않는다. 분리된 보안 스택을 기술하고, 운영자에게 그 분리를 정직하게 다루도록 요구한다.

이러한 정직함은 운영적으로 유용하다. 외부 종단은 인증서 수명 주기를 중앙화하고, 연결 처리를 흡수하며, 기존 서비스 아키텍처에 맞출 수 있다. 그러나 피어를 인증하는 구성 요소와 RESTCONF 권한을 적용하는 구성 요소를 분리할 수도 있다. 이 구성 요소들이 서로 다른 팀에 소유되고, 서로 다른 시스템으로 구성되며, 서로 다른 로그로 관찰된다면 “인증됨”이라는 말에는 숨은 의존성이 존재한다.

YANG 노드가 말하는 것과 증명할 수 없는 것

서버 측 모델에는external-endpoint컨테이너가 있다. 여기에는 외부 주소와 포트, 신뢰 프록시 수, 그리고client-cert-var—외부 종단 장치가 클라이언트 인증서를 RESTCONF 서버로 릴레이하는 데 사용하는 HTTP 헤더 변수—를 기록할 수 있다. 예시는X-Client-Cert이다. RESTCONF 인증이 반드시 클라이언트 인증서를 사용하는 것은 아니므로 이 필드는 선택 사항이다.

이 노드들은 의도된 토폴로지를 기계 판독 가능하게 만든다. 구성 도구가 외부 종단 리스너를 TLS를 내부에서 처리하는 스택과 구분하도록 한다. 동시에 보안 질문을 정밀하게 드러낸다.

주소와 포트는 트래픽이 그 엔드포인트를 통해 도착했음을 보여주지 않는다. 신뢰 프록시 수는 현재 요청의 프록시를 세지 않는다. 헤더 이름은 신뢰할 수 없는 발신자가 같은 이름을 공급할 수 없음을, 중개자가 그것을 올바르게 제거하고 덮어썼음을, 그 값이 현재 외부 연결에서 검증된 인증서에서 왔음을 증명하지 않는다. 구성은 의도의 증거이지 실행의 흔적이 아니다.

이 필드가 맡지 않은 일을 하지 못한다고 비난해서는 안 된다. 스키마는 상호 운용 가능한 시스템에 무엇을 구성할 수 있는지 알려준다. 거버넌스 오류는 스키마 값이 실시간 경로에 대한 증명으로 승격될 때 발생한다.

신원은 운반체가 바뀌어도 살아남아야 한다

내부 TLS 엔드포인트에서는 애플리케이션이 피어 인증을 RESTCONF 요청을 운반하는 연결에 직접 결합할 수 있는 경우가 많다. 외부 종단은 이 직접 운반체를 끊는다. 인증된 사실은 한 프로세스에서 발생하고, 인가 입력은 다른 프로세스에서 소비된다.

릴레이는 인증서일 수도, 고유 이름(DN), 검증된 사용자명 또는 다른 유한한 신원 속성일 수도 있다. 선택마다 번역이 생긴다. 인증서의 어느 부분이 권위적인가? 누가 이름을 정규화하는가? 필드가 없거나 중복되면 어떻게 되는가? 종단 장치는 인바운드 신원 헤더를 덮어쓰는가, 아니면 단순히 추가하는가? 백엔드가 그 규칙을 거치지 않고 도달될 수 있는가? 요청 재시도가 원래 TLS 세션으로의 흔적 연결을 보존하는가?

RFC 8341의 네트워크 구성 접근 제어 모델(NACM)은 인증된 사용자명에서 출발하여 어떤 작업과 데이터가 허용되는지 결정한다. NACM은 잘못된 사용자명에 대해 완벽하게 규칙을 적용할 수 있다. 올바른 인가 엔진이 검증되지 않은 상류 신원 매핑을 수복하지 못한다.

같은 문제가 Call Home에서 추가적인 혼동의 여지와 함께 나타난다. RFC 8071은 TCP 연결을 시작하는 쪽을 뒤집지만, TLS나 RESTCONF 역할을 뒤집지 않는다. RESTCONF 클라이언트는 여전히 서버 인증서를 검증하고 관련 자격 증명을 사용한다. 연결 방향은 신원 방향이 아니다. 수신 대기 측에 배치된 종단 장치는 이 의미를 보존해야 하며, 장치가 안쪽으로 다이얼했다는 사실에서 신뢰를 추론해서는 안 된다.

백엔드 링크는 통제의 일부이지 빈 공간이 아니다

외부 TLS 세션이 끝나면 하류 요청은 실제 네트워크 경로를 점유한다. 그것을 “내부”라고 부르는 것은 누가 도달할 수 있는지, 누가 헤더를 주입할 수 있는지, 몇 개의 프록시가 개입할 수 있는지, 장애 조치 중 경로가 바뀌었는지를 정의하지 않는다.

관련 통제는 여러 형태를 취할 수 있다. 엄격히 한정된 네트워크 세그먼트, 다른 계층의 상호 인증 보호, 프로세스 로컬 포워딩, 서비스 메시 신원 또는 이에 상응하는 메커니즘이 그것이다. RFC 10011은 Daniel Kade가 선호하는 아키텍처를 규정하지 않는다. 다만 운영자가 백엔드 경로를 보안 스토리의 외부로 취급하지 않도록 요구한다.

여기서 실질적 주권이 문제가 된다. 인증서나 YANG 구성에 대한 형식적 통제는 관리 서비스에 신원을 주장할 수 있는 모든 구성 요소에 대한 실질적 통제와 같지 않다. 별도의 엣지 플랫폼이 종단을 소유하고, 프록시 팀이 헤더 정책을, 네트워크 팀이 백엔드 접근성을 소유한다면 RESTCONF 소유자는 세 곳 모두에 의존한다. 이 의존성은 사건 이전에 드러나야 하며, 사건 이후에 재구성되어서는 안 된다.

RFC 9641과 RFC 9642의 트러스트스토어 및 키스토어 모델, 그리고 RFC 9645의 TLS 클라이언트/서버 그룹화는 자격 증명과 피어 인증 구성의 표준화에 도움이 된다. 이들은 의도의 어휘를 개선한다. 그러나 실행 중인 종단 장치가 어떤 신뢰 앵커를 로드했는지, 어떤 정책 버전을 평가했는지, 어떤 백엔드 요청이 결과되었는지는 증명하지 않는다.

종단 장치 경계 수신증

나는 모든 외부 종단 RESTCONF 엔드포인트를 위한종단 장치 경계 수신증(terminator-boundary receipt)을 제안한다. 이는 편집 방향 제안이며 RFC 10011의 새로운 요구 사항이 아니다.

첫 번째 부분은 선언된 경계를 식별한다. 외부 엔드포인트, 서비스 역할, 구성 개정판, 예상 프록시 체인, 책임 소유자가 그것이다. 종단 장치에서 사용된 인증서와 신뢰 정책 식별자, 그 유효성 또는 순환 상태, 허용된 클라이언트 인증 방법을 기록한다. 개인 키, 베어러 자격 증명, 전체 인증서 아카이브가 아니라 참조와 해시만 저장한다.

두 번째 부분은 신원 운송을 정의한다. 허용된 릴레이 필드, 정규화 규칙, 인바운드 사본 제거 여부, 신뢰 종단 장치의 덮어쓰기 여부, 모호하거나 없을 때의 처리를 명명한다. 클라이언트 인증서가 릴레이된다면, 기록은 외부 연결에서 제시된 인증서와 백엔드로 전달된 속성을 구분한다.

세 번째 부분은 백엔드를 다룬다. 어떤 발신 신원 또는 네트워크 위치가 리스너에 도달할 수 있는지, 어떤 보호가 적용되는지, 예상 프록시 수, 그리고 직접 우회 테스트가 의도대로 실패했는지 여부이다. 사설 주소나 방화벽 덤프를 게시하지 않는다. 범위가 한정된 정책 식별자와 테스트 결과면 보증 기록으로 충분하다.

네 번째 부분은 행동을 상호 연관시킨다. 추적 식별자가 외부 TLS 인증 이벤트, 하류 요청, 도출된 RESTCONF 사용자명, NACM 결정을 묶는다. 시각, 소프트웨어 및 정책 개정판, 검증 결과, 유한한 로그 해시가 체인을 검토 가능하게 만든다. 추적은 명확한 보존 규칙에 따라 만료되어야 하며 관리 페이로드를 제외해야 한다.

수신증은 영구적인 안전 증명서가 아니다. 신선도 기간이 있다. 인증서 순환, 종단 장치 업그레이드, 프록시 변경, 새 백엔드 경로, 헤더 정책 편집 또는 NACM 매핑 변경은 주장을 다시 연다.

구성 요소만이 아니라 이음새를 시험하라

외부 주소의 TLS 스캔은 지정된 제안 하에서 핸드셰이크가 성공했거나 실패했음을 증명할 수 있다. 구성 읽기는 의도된external-endpoint를 보여줄 수 있다. 백엔드 접근 테스트는 한 경로가 차단되었음을 보여줄 수 있다. NACM 테스트는 한 사용자명에 대한 결과를 보여줄 수 있다. 그중 어느 것 하나로만은 결합된 체인을 증명하지 못한다.

유용한 테스트는 경계를 가로지른다. 보호된 헤더를 실은 신뢰할 수 없는 요청을 제출하고 거부되거나 덮어써지는지 확인한다. 낮은 권한 신원에 매핑된 인증서를 제시하고 백엔드가 정확히 그 신원을 관찰하는지 확인한다. 신뢰 범위 바깥에서 백엔드 직접 경로를 시도한다. 프록시 수를 바꾼다. 외부 인증서나 신뢰 앵커를 순환하고 실시간 프로세스가 어느 개정판을 사용하는지 확인한다. 거부된 외부 인증과 백엔드 요청의 부재를 상호 연관시킨다.

부정 테스트가 특히 가치 있는 이유는 위험한 실패가 흔히 의도하지 않은 우회 경로이기 때문이다. 오래된 로드 밸런서, 헬스 체크 리스너, 유지보수 경로 또는 두 번째 헤더 철자가 그것이다. 성공한 해피 패스는 한 경로가 작동함을 증명할 뿐 모든 우회가 닫혔음을 보여주지 않는다.

보증 언어는 경계를 보존해야 한다

대시보드는 “외부 TLS 검증됨”, “승인된 종단 장치에서 신원 릴레이 수락됨”, “백엔드 우회 거부됨”, “NACM 결정 상호 연관됨”이라고 말해야 한다. 체인과 그 커버리지가 명시적이지 않다면 이 관찰들을 “RESTCONF 보안됨”으로 압축해서는 안 된다.

더 좁은 언어는 실패 상황에서 더 유용하다. 인가가 잘못되었다면 수신증은 결함이 피어 검증, 이름 매핑, 헤더 위생, 프록시 범위, 백엔드 접근성 또는 NACM 정책 중 어디에 있는지 보여준다. 단일 녹색 방패는 그중 어느 것도 드러내지 못한다.

RFC 10011은 종단 장치를 인정함으로써 RESTCONF를 약화시키지 않는다. 아키텍처적 정직함을 강화한다. 암호화된 전송이 어디서 끝날 수 있는지 명명하고, 책임은 그곳에서 끝날 수 없음을 알려준다.

출처

1. Lu Heng — Data Sovereignty: Technical vs Practical Realities
2. Lu Heng — Why BTW Media Exists
3. Lu Heng — Running-Code Primacy
4. IANA — YANG Parameters
5. RFC 10011 — A YANG Data Model for RESTCONF Clients and Servers
6. RFC 8040 — RESTCONF Protocol
7. RFC 8071 — NETCONF Call Home and RESTCONF Call Home
8. RFC 8341 — Network Configuration Access Control Model
9. RFC 8342 — Network Management Datastore Architecture
10. RFC 8446 — TLS 1.3
11. RFC 9000 — QUIC
12. RFC 9110 — HTTP Semantics
13. RFC 9641 — A YANG Data Model for a Truststore
14. RFC 9642 — A YANG Data Model for a Keystore
15. RFC 9645 — YANG Groupings for TLS Clients and TLS Servers
16. RFC 10009 — YANG Groupings for HTTP Clients and HTTP Servers