Network/Zero Trust

[Zero Trust - Policy Engine] Connector와 Gateway: 정책 결정이 실제 트래픽으로 집행되는 방법

러러 2026. 4. 18. 17:46

보안 감사 중에 이런 질문이 나올 때가 있다.

"VPN 없이 내부 개발 서버에 접근한다면, 그 연결은 어떻게 만들어지나요? 내부 서버의 포트가 외부에 열려 있는 건가요?"

 

이 질문이 불편하게 느껴지는 데는 이유가 있다. VPN을 걷어냈다고 선언했다면, 그 자리를 대체하는 것이 무엇인지를 구체적으로 설명할 수 있어야 한다. "Zero Trust를 도입했습니다"라는 말만으로는 충분하지 않다.

 

Vol.11에서 PDP(Policy Decision Point)가 접근 요청에 허용/거부를 결정한다고 설명했다. 앞선 포스팅에서는 OPA와 Cedar가 그 결정을 어떤 언어로 표현하는지를 다뤘다. 그런데 OPA가 allow = true를 반환했다고 해서 사용자의 노트북과 내부 앱 서버 사이에 연결이 저절로 생기지는 않는다.

 

정책 결정이 실제 패킷이 흐르는 것으로 이어지려면 무언가가 그 연결을 만들어야 한다. 그것이 Connector와 Gateway다.

VPN이 이 문제를 해결한 방식

VPN은 이 문제를 단순하게 해결한다. 사용자가 VPN 클라이언트를 실행하면 암호화 터널이 생기고, 그 터널을 통해 기업 내부 네트워크에 라우팅 경로가 생긴다. 사용자의 기기는 마치 사무실 내부에 있는 것처럼 내부 IP 대역에 접근할 수 있게 된다.

 

이 구조의 암묵적 전제는 하나다. "VPN 터널을 통과한 사용자는 신뢰할 수 있다." 그리고 이 전제가 성립하면 내부 네트워크 전체에 대한 접근을 허용하는 것이 자연스러운 귀결이 된다.

문제는 VPN이 제공하는 것이 "앱에 대한 접근"이 아니라 "네트워크에 대한 접근"이라는 점이다. 사용자에게 필요한 것은 특정 앱 하나인데, 접근 가능한 범위는 서브넷 전체가 된다.

 

Castle-and-Moat(해자와 성) 모델이 정확히 이 구조다. 해자(방화벽)를 넘으면 내부는 신뢰한다. 자격증명이 탈취되거나, 사용자의 기기가 침해되거나, VPN 서버 자체에 취약점이 있으면, 공격자는 그 터널을 통해 내부 네트워크 전체를 자유롭게 이동할 수 있다. 이것이 래터럴 무브먼트(lateral movement)다.

아키텍처가 달라지면 전제도 달라진다

Zero Trust의 출발점은 이 전제를 거부하는 데 있다. 내부 네트워크에 있다고 해서, VPN 터널을 통과했다고 해서, 그 트래픽을 신뢰하지 않는다. 대신 모든 접근 요청을 신원과 기기 상태와 정책 기준으로 개별적으로 결정한다.

 

이 원칙을 구현할 때 핵심 설계 선택이 하나 있다.

 

사용자는 네트워크가 아니라 앱에 접근한다.

VPN은 사용자에게 네트워크 접근을 주고, 그 위에서 앱을 찾아가게 한다. ZTNA는 반대다. 사용자가 특정 앱에 접근하려는 요청을 받고, 그 요청에 대해 허용 여부를 결정하고, 허용됐을 때만 그 앱과의 연결을 만들어준다.

이 하나의 선택이 Connector와 Gateway의 구조 전체를 결정한다.

Gateway: PEP가 구현되는 방식

앞에서 PEP(Policy Enforcement Point)는 PDP의 결정을 실제로 집행하는 컴포넌트라고 설명했다. Gateway가 바로 그 PEP의 구체적 구현이다.

 

Gateway는 인터넷과 내부 애플리케이션 사이에 위치한다. 클라우드 환경이나 DMZ에 배치되며, 외부 사용자의 모든 접근 요청을 수신하는 단일 진입점이 된다.

 

Gateway가 수행하는 일은 순서가 있다. 먼저 사용자 신원을 검증한다(IdP와 연동해서 세션 토큰을 확인하고 이 요청이 누구의 것인지 확인한다. 다음으로 PDP에 인가 질의를 보낸다). "이 사용자가, 이 기기로, 이 리소스에 대해, 이 액션을 요청했는데, 허용해야 하는가." PDP의 결정이 허용이면 내부 연결을 만들고 트래픽을 전달한다. 거부면 연결을 차단한다.

Reverse proxy 패턴

Gateway의 동작 방식을 네트워크 관점에서 보면 역방향 프록시(reverse proxy)다.

 

순방향 프록시(forward proxy)는 내부 클라이언트가 외부로 나가는 트래픽을 중계한다. "내가 example.com에 연결하려는데, 프록시를 통해 나가겠다"는 구조다. 클라이언트가 목적지를 알고 있고, 프록시에게 대신 가달라고 요청한다.

 

역방향 프록시는 반대 방향이다. 외부 클라이언트가 서버에 연결하려는데, 프록시가 그 앞에 있다. 클라이언트는 실제 서버의 존재를 모른다. 프록시가 연결을 받아서 내부 서버에 새로운 연결을 맺고 응답을 클라이언트에게 돌려준다.

ZTNA Gateway는 역방향 프록시다. 사용자는 app.company.com에 연결하지만, 내부 앱 서버의 실제 IP나 주소를 알지 못한다. Gateway가 그 주소를 숨기고 트래픽을 중계한다.

 

이 구조에서 클라이언트와 Gateway 사이에는 TLS 연결이 맺어진다. Gateway는 TLS 요청을 복호화해서 요청 내용을 확인하고, 필요하면 DLP(데이터 유출 방지) 검사나 로깅을 수행한 뒤, 내부 앱과 새로운 연결을 맺는고 TLS 연결을 종단(termination)한다.

SNI 기반 라우팅

단일 Gateway로 여러 내부 앱을 처리할 때 문제가 하나 있다. HTTPS 연결에서 어떤 앱으로 라우팅할지를 어떻게 결정하는가.

TCP 연결이 맺어지면 패킷의 목적지 IP는 하나다. 여러 앱이 같은 Gateway IP를 공유한다면, 어떤 앱으로 보낼지를 IP만으로는 알 수 없다. 여기서 TLS SNI(Server Name Indication)가 사용된다.

 

SNI는 TLS 핸드셰이크의 Client Hello 메시지에 포함된 확장이다. 클라이언트가 연결하려는 호스트명을 핸드셰이크 초반에 평문으로 전달한다. 아직 TLS 암호화가 적용되기 전이므로, Gateway는 TLS를 완전히 종단하기 전에 이 SNI 값을 읽어서 어떤 내부 앱으로 라우팅할지 결정한다.

 

app1.company.com으로 들어온 연결은 내부 앱 A로, db-admin.company.com으로 들어온 연결은 내부 DB 관리 도구로 라우팅하며 단일 IP와 단일 포트(443)로 여러 앱을 처리할 수 있다. 사용자는 앱마다 다른 엔드포인트 주소를 쓰지만, 실제로 모든 연결은 같은 Gateway로 향한다.

Connector: 아웃바운드 전용 연결의 의미

Connector는 내부 네트워크 안에 설치되는 소프트웨어 에이전트다. 앱 서버 가까이에 배치되어, 내부 앱과 Gateway 사이를 중계하는 역할을 한다.

 

Connector의 핵심 특성은 하나다. 아웃바운드 방향으로만 연결을 맺는다.

 

Connector는 시작하면 Gateway에 먼저 연결을 맺는다. "나는 여기 있다. 요청이 오면 내게 전달하라." 이후 Gateway에서 요청이 오면 기존 연결을 통해 내부 앱과의 연결을 만들어 중계한다. Connector는 어떤 인바운드 포트도 열지 않는다.

 

이 설계가 가져오는 결과들이 있다.

 

첫째, 내부 방화벽에 인바운드 허용 규칙이 필요 없다. 기존 아키텍처에서 외부 접근이 가능하려면 방화벽에 443 포트 인바운드 같은 규칙이 있어야 했다. 그 규칙이 없어도 된다. 방화벽은 Connector가 수립한 아웃바운드 연결을 상태 테이블에 기록하고, Gateway에서 오는 반환 트래픽은 이미 수립된 연결의 일부로 처리한다. 별도의 인바운드 허용 규칙이 없어도 통과된다.

 

둘째, 내부 앱 서버의 IP가 외부에 노출되지 않는다. 사용자가 연결하는 것은 Gateway다. Gateway가 내부 앱 서버의 실제 주소를 완전히 숨긴다. 외부에서 앱 서버를 직접 스캔하거나 접근하는 경로가 구조적으로 차단된다.

 

셋째, NAT(Network Address Translation) 환경에서도 자연스럽게 동작한다. 많은 사내 네트워크에서 내부 기기들은 사설 IP를 사용하고, 외부에서 직접 접근할 수 없다. Connector가 먼저 아웃바운드 연결을 맺기 때문에 NAT traversal 문제가 생기지 않는다.

Connector 등록과 신뢰 수립

아웃바운드로 연결을 맺는다는 것만으로는 설명이 끝나지 않는다. 내부 네트워크의 임의 소프트웨어가 Gateway에 연결을 맺을 수 있다면 보안 구조가 무너진다. 가짜 Connector가 Gateway에 등록되면 공격자는 사용자 트래픽을 악의적인 서버로 중계하거나 임의 앱으로의 연결을 만들어낼 수 있다.

 

따라서 Connector가 Gateway에 처음 연결을 맺을 때는 자신이 신뢰할 수 있는 Connector임을 증명해야 한다. 이 초기 신뢰 수립(bootstrapping)은 대개 두 가지 방식으로 구현된다.

 

서비스 토큰 기반 등록: 관리자가 관리 콘솔(PAP)에서 Connector 등록 토큰을 발급한다. 이 토큰은 단기 유효기간을 가진 일회성 비밀이다. Connector 설정 파일에 이 토큰을 포함해서 배포하면, 첫 연결 시 Gateway는 토큰을 검증하고 이 Connector를 신뢰 목록에 등록한다. 이후에는 mTLS 인증서로 전환되어 토큰 없이 인증이 이루어진다.

 

사전 발급 클라이언트 인증서: Connector에 클라이언트 인증서(SVID 등)를 직접 배포하는 방식이다. SPIFFE(Secure Production Identity Framework For Everyone)는 워크로드 신원을 표준화하는 프레임워크로, SPIRE(SPIFFE Runtime Environment)가 각 Connector에 단기 유효 SVID(SPIFFE Verifiable Identity Document)를 자동 발급·갱신한다. Connector는 이 SVID를 mTLS 클라이언트 인증서로 사용해 Gateway에 자신의 신원을 증명한다.

인증서 갱신도 설계 포인트다. mTLS 인증서가 만료되면 Connector와 Gateway 사이의 터널이 끊긴다. 운영 환경에서는 인증서 유효기간이 짧을수록(예: 24시간) 침해 시 피해 범위가 줄지만, 갱신 실패가 서비스 중단으로 이어지는 위험이 있다. 사람이 직접 인증서를 관리하면 갱신 누락이 발생하기 쉽기 때문에 SPIRE 같은 도구가 자동 갱신을 처리 한다.

Gateway와 Connector 사이의 터널

Connector가 Gateway에 맺는 연결은 단순한 HTTP 요청이 아니다. 영구적으로 유지되는 터널(persistent tunnel)이다. 이 터널을 통해 Gateway는 "사용자 X가 앱 Y에 연결을 요청했다"는 정보를 Connector에 전달하고, Connector는 내부 앱과의 연결을 만들어 데이터를 중계한다.

 

이 터널에는 두 가지 요구가 동시에 있다. 낮은 레이턴시와 높은 신뢰성이다. 그리고 방화벽의 아웃바운드 허용 정책을 자연스럽게 통과할 수 있어야 한다.

 

실제 구현에서 자주 사용되는 프로토콜은 두 가지다.

  • WebSocket over TLS: HTTP 연결을 HTTP 업그레이드 요청으로 시작해서 지속적인 양방향 채널로 전환한다. 방화벽이나 프록시를 통과하기 쉽다는 장점이 있다. 기존 HTTPS 인프라와 호환성이 높다.

  • QUIC: Google이 처음 개발하고 IETF에서 RFC 9000으로 표준화한 전송 프로토콜이다. UDP 기반으로 동작하며 TCP의 Head-of-Line Blocking 문제를 해결하고 연결 설정 지연을 줄인다. 네트워크 경로가 변경될 때(예: Wi-Fi에서 LTE로 전환) 연결이 끊기지 않는 연결 마이그레이션(connection migration)을 지원한다. 다만 UDP를 차단하는 기업 방화벽 환경에서는 QUIC을 사용할 수 없어 WebSocket으로 폴백이 필요하다.

터널의 보안은 상호 TLS(mTLS, Mutual TLS)로 보장된다. 일반 TLS에서는 클라이언트가 서버 인증서를 검증하지만, mTLS는 서버도 클라이언트 인증서를 검증한다. Gateway는 이 Connector가 신뢰할 수 있는 것인지 확인하고, Connector도 이 Gateway가 신뢰할 수 있는지 확인한다. 공격자가 가짜 Gateway를 만들어 Connector를 속이거나, 가짜 Connector를 만들어 Gateway에 등록하는 것을 방지한다.

트래픽의 전체 흐름

사용자가 내부 앱에 접근하는 요청이 처음부터 끝까지 어떻게 처리되는지를 순서대로 보면:

이 흐름은 새로운 애플리케이션 세션이 수립될 때마다 거친다. 이미 수립된 세션 내의 개별 HTTP 요청은 PDP를 매번 다시 질의하지 않는다.

 

사용자 관점에서는 일반적인 HTTPS 연결처럼 보인다. 내부 앱 서버의 IP나 Connector의 존재는 보이지 않는다.

클라이언트 패턴: 에이전트 기반과 에이전트리스

사용자 기기 측에서 Gateway에 연결하는 방식은 두 가지로 나뉜다.

에이전트 기반

사용자 기기에 클라이언트 소프트웨어가 설치된다. 이 소프트웨어는 기기 수준에서 트래픽을 가로채서 Gateway로 전달하는 역할을 한다. 그리고 동시에 Device Posture 정보 — OS 버전, 패치 상태, EDR(Endpoint Detection and Response) 설치 여부, MDM(Mobile Device Management) 등록 상태 등 — 를 수집해서 인가 요청에 함께 실어 보낸다.

 

기기 상태를 인가 결정에 반영할 수 있다는 것이 에이전트 기반의 큰 장점이다. "OS 패치가 30일 이상 지연된 기기는 민감 리소스 접근 거부"처럼 정책이 기기 수준까지 내려갈 수 있다. 반면 에이전트를 설치하고 관리해야 하므로, 회사가 관리하는 기기(managed device)에 적합하다.

에이전트리스 (브라우저 기반)

별도 소프트웨어 없이 브라우저로 Gateway에 연결한다. Gateway가 HTTPS로 요청을 받아 내부 앱과의 연결을 중계한다. 웹 앱에 대한 접근은 이 방식으로 충분히 처리된다.

 

에이전트 설치가 어려운 BYOD(개인 기기), 파트너·계약직, 임시 접근과 같은 상황에 적합하다. 단점은 기기 상태 정보를 수집하기 어렵다는 것이다. 브라우저는 OS의 패치 수준이나 EDR 설치 여부를 신뢰할 수 있는 방식으로 제공하지 않는다. 인가 결정에 사용할 수 있는 신호가 신원과 네트워크 컨텍스트 정도로 제한된다.

 

두 방법을 별도로 운용하기 보다는 두 가지를 함께 운용하는 것이 일반적이다. 관리 기기에는 에이전트를 배포해서 Device Posture 기반 정책을 적용하고, BYOD나 파트너에게는 에이전트리스로 제한된 리소스 접근만 허용한다.

Split Tunneling 트레이드오프

에이전트 기반 클라이언트에서 선택해야 하는 설계가 있다. 모든 네트워크 트래픽을 Gateway로 보낼 것인가(Full Tunneling), 아니면 내부 앱 트래픽만 Gateway로 보내고 나머지는 직접 인터넷으로 보낼 것인가(Split Tunneling).

 

Full Tunneling은 사용자의 모든 트래픽이 Gateway를 통과하므로 완전한 가시성을 가진다. DLP(데이터 유출 방지), 악성 사이트 차단, 인터넷 트래픽 감사가 가능하다. 하지만 Gateway가 병목이 된다. 사용자가 YouTube를 보는 트래픽까지 Gateway를 거친다.

Split Tunneling은 내부 앱 트래픽만 Gateway로 보내고, 나머지 인터넷 트래픽은 사용자 기기에서 직접 나간다. Gateway 부하가 줄고 사용자 경험이 좋다. 하지만 인터넷 방향 트래픽에 대한 가시성이 없다. 이 트래픽을 감사하려면 별도의 SWG(Secure Web Gateway - 순방향 프록시)가 필요하다.

 

SASE(Secure Access Service Edge)는 ZTNA와 SWG를 포함하여 SD-WAN, CASB, FWaaS 등을 클라우드 엣지에서 통합 제공하는 서비스 프레임워크다. 사용자 트래픽의 방향에 상관없이 단일 클라우드 엣지에서 처리한다.

Gateway 고가용성: 단일 진입점의 딜레마

Gateway는 모든 외부 접근의 단일 진입점이다. 이 구조는 보안 설계에서 강점이지만 모든 트래픽이 한 곳을 통과하므로 제어가 집중된다는 가용성 관점에서는 취약점이 된다. Gateway 하나가 장애를 일으키면 그 Gateway를 통하는 앱 전체의 외부 접근이 중단된다.

 

운영 환경에서는 다중 Gateway를 배포하고 글로벌 로드밸런서(GLB) 또는 Anycast를 앞에 둔다.

 

여기서 설계 선택이 하나 있다. Gateway를 stateless로 설계할 것인가, stateful로 설계할 것인가.

 

Stateless Gateway: 각 요청에 필요한 신원 정보가 서명된 토큰(JWT 등) 형태로 요청 자체에 포함된다. 어떤 Gateway 인스턴스가 요청을 받아도 토큰 서명을 검증하는 것만으로 동일하게 처리할 수 있다. 특정 Gateway에 장애가 생겨도 로드밸런서가 다른 인스턴스로 요청을 보내면 된다. 수평 확장도 자유롭다. 단, 세션 강제 종료가 복잡해진다. 토큰이 살아있는 한 어느 인스턴스에서든 처리되기 때문에, 토큰 무효화를 위한 중앙 블랙리스트가 필요하다.

 

Stateful Gateway: 세션 상태(활성 Connector 매핑, 현재 세션 메타데이터)를 Gateway 인스턴스가 보유한다. 세션 종료나 재평가가 즉각적이고 명확하다. 하지만 특정 클라이언트의 요청이 항상 같은 Gateway 인스턴스로 가야 한다(sticky session). 장애 시 해당 인스턴스의 세션 상태가 유실될 수 있으므로, Redis 같은 공유 상태 저장소에 세션을 외부화하는 것이 일반적이다.

 

Cloudflare Access나 Zscaler Private Access 같은 상용 ZTNA 솔루션은 글로벌 분산 PoP(Point of Presence)에 Gateway를 배치한다. 사용자는 가장 가까운 PoP에 연결되고, PoP들은 백본 네트워크로 연결된다. 각 PoP는 토큰 기반의 stateless 설계로 독립적으로 요청을 처리하므로, 특정 PoP 장애가 다른 PoP에 영향을 주지 않는다. 이 구조가 SASE의 핵심 아키텍처다. 클라우드 엣지의 여러 지점에서 접근 제어와 트래픽 처리가 동시에 이루어진다.

고가용성 Connector 설계

Connector는 내부 앱과 외부 연결의 유일한 다리가 된다. 단일 Connector가 장애를 일으키면 그 Connector에 연결된 앱 전체가 접근 불가가 된다.

 

운영 환경에서는 같은 앱을 가리키는 Connector를 여러 대 배포한다. Gateway는 활성 Connector 목록을 유지하고 요청을 분산한다. 특정 Connector가 응답하지 않으면 Gateway는 자동으로 다른 Connector로 요청을 전환한다.

연결 수립 방향은 여전히 Connector → Gateway(아웃바운드)다. Gateway는 이미 수립된 터널들 중 어느 쪽으로 요청을 라우팅할지만 결정한다.

 

Connector를 어디에 배포하는가도 설계 선택이다. 앱마다 전용 Connector를 두면 한 Connector가 침해돼도 피해 범위가 그 앱에 국한된다. Connector 수가 많아지면 관리 부담이 늘지만, 폭발 반경(blast radius)이 줄어든다는 보안 이점이 있다.

Gateway가 PEP로서 집행하는 것들

Gateway는 트래픽을 통과시키는 투명한 파이프가 아니다. PDP의 결정이 단순히 "허용 또는 거부"에 그치지 않는 것처럼, PEP인 Gateway가 집행하는 내용도 그보다 넓다.

 

앞의 포스팅에서 설명한 Obligations (PDP가 허용 결정과 함께 지시하는 부가 조건) 를 Gateway가 실행한다. 세션 유효 시간을 30분으로 제한하거나, 특정 HTTP 메서드(DELETE, PUT)를 차단하거나, 응답 본문에서 민감 필드를 마스킹하거나, 다운로드 속도를 제한하는 것이 그 예다. 정책 결정이 "허용 + 조건"으로 내려오면 Gateway가 그 조건을 트래픽 수준에서 시행한다.

 

Gateway는 또한 모든 접근 이벤트를 로깅한다. 누가, 어떤 기기로, 언제, 어떤 리소스에 접근했는지, PDP의 결정 근거는 무엇이었는지가 기록된다. 이 로그가 SIEM으로 전달되어 Continuous Verification 레이어의 원료가 된다. Gateway의 접근 로그 없이는 SIEM이 개별 트래픽을 인가 결정 맥락 — 어떤 신원으로, 어떤 정책 기준으로, 어떤 Device Posture 아래에서 허용됐는지 — 과 연결하기 어렵다. 앱 서버 로그만으로는 "누가 접근했는가"를 알 수 있어도, "왜 허용됐는가"는 파악할 수 없다.

세션 중 재평가

접근이 허용된 시점의 상태가 세션 내내 유지되리라는 보장은 없다. 사용자가 앱을 사용하는 도중 기기 Posture가 변할 수 있다. EDR이 위협을 탐지했거나, OS 업데이트가 실패했거나, 기기가 보안되지 않은 공용 Wi-Fi에 연결됐을 수 있다. 사용자의 리스크 점수가 임계값을 넘을 수도 있다.

 

ZTNA의 "Never Trust, Always Verify" 원칙을 엄격하게 적용하면, 접근 결정은 접속 시점 한 번으로 끝나지 않아야 한다. Gateway는 두 가지 방식으로 이를 처리한다.

 

하나는 주기적 재질의(periodic re-evaluation)다. 세션이 유지되는 동안 Gateway가 일정 주기로 PDP에 인가를 다시 묻는다. PDP가 이번에는 거부를 내리면 Gateway는 기존 세션을 강제 종료한다.

 

재 질의 주기는 보안과 운영 비용 사이의 트레이드오프다. 짧은 주기(예: 5분)면 침해된 기기가 오래 접근을 유지하기 어렵지만, PDP 부하가 높아지고 재평가마다 짧은 지연이 발생한다. 긴 주기(예: 30분)면 부하와 UX 모두 안정적이지만, 그 창 안에서는 정책 변경이나 기기 침해가 반영되지 않는다. 실무에서는 리소스 민감도에 따라 주기를 다르게 설정하는 것이 일반적이다. 민감한 데이터에 접근하는 세션은 짧게, 일반 개발 도구에 접근하는 세션은 길게.

 

다른 하나는 PDP 주도 세션 철회(PDP-initiated revocation)다. PDP(또는 PIP를 통해 신호를 받은 PDP)가 특정 세션의 조건이 바뀌었음을 감지하면 Gateway에 세션 종료를 지시한다. Gateway가 폴링을 기다리지 않고 즉시 반응한다. EDR이 위협을 탐지한 순간 해당 기기의 모든 세션을 즉시 종료하는 것이 이 방식이다.

 

이 세션 재평가 메커니즘이 Continuous Verification의 네트워크 레이어 구현이다. 접근 결정은 상태가 아니라 흐름이다.

PDP 불가용 시 설계 선택

Gateway가 PDP에 인가 질의를 보냈는데 PDP가 응답하지 않으면 어떻게 되는가. 이것은 설계에서 명시적으로 결정해야 하는 항목이다.

 

Fail-close: PDP가 응답하지 않으면 모든 새로운 접근 요청을 거부한다. "결정을 내릴 수 없으면 허용하지 않는다"는 원칙이다. 보안은 강하게 유지되지만, PDP가 다운된 순간 서비스 접근 전체가 차단된다.

 

Fail-open: PDP가 응답하지 않으면 접근을 허용한다. 가용성을 우선하는 선택이다. PDP가 다운돼도 사용자는 계속 일할 수 있다. 하지만 그 시간 동안 어떤 접근도 정책 기반으로 제어되지 않는다.

 

대부분의 ZTNA 구현은 기본값으로 fail-close를 택한다. Zero Trust의 핵심 전제 — "결정 없이는 신뢰하지 않는다" — 에 부합하기 때문이다. 대신 PDP 자체를 고가용성으로 운영해서 fail-close의 가용성 문제를 완화한다.

 

실무에서 자주 사용되는 절충안이 있다. 결정 캐시(decision cache)다. Gateway가 최근 PDP 결정 결과를 짧은 TTL로 캐시한다. PDP가 응답하지 않으면 캐시된 결정으로 처리한다. 새로운 세션(캐시 없는 요청)은 거부하고, 이미 허용된 세션은 캐시 기간 동안 유지된다. 보안과 가용성의 중간 지점이다.

 

캐시에도 위험이 있다. 캐시된 "허용" 결정이 살아있는 동안 정책이 바뀌거나 기기가 침해되어도 변경이 반영되지 않는다. TTL이 짧을수록 이 위험이 줄지만, PDP 다운 시 가용성 창도 줄어든다. 캐시 TTL은 재질의 주기와 마찬가지로 리소스 민감도에 따라 다르게 설정하는 것이 합리적이다.

ZTNA가 해결하지 못하는 것

Connector와 Gateway로 이루어진 ZTNA 아키텍처는 외부에서 내부로 향하는 트래픽(North-South 방향)을 제어한다. 사용자의 노트북에서 내부 앱으로 가는 연결이다.

 

그런데 실제 공격에서 더 위험한 경우는 내부 서비스 간 이동이다. 공격자가 내부 네트워크에 발판을 마련한 뒤, 서비스 A에서 서비스 B로, 서비스 B에서 데이터베이스로 이동하는 것이다. 이것이 East-West 트래픽이다.

이 East-West 트래픽을 제어하는 것은 마이크로세그멘테이션(microsegmentation)의 영역이다. Kubernetes 환경에서는 NetworkPolicy로 파드 간 통신을 제한하거나, Istio·Linkerd 같은 서비스 메시를 통해 서비스 간 mTLS와 접근 제어를 적용한다.

 

ZTNA Connector/Gateway가 North-South를 제어하고, 마이크로세그멘테이션이 East-West를 제어할 때 비로소 내부 네트워크에 대한 암묵적 신뢰가 제거된다. 어느 하나만으로는 Zero Trust의 "내부에서도 신뢰하지 않는다"는 원칙이 완전히 구현되지 않는다.

참고 자료

[1] Rose, Scott, et al., "Zero Trust Architecture", NIST Special Publication 800-207, National Institute of Standards and Technology, 2020.
https://doi.org/10.6028/NIST.SP.800-207

[2] Ward, Rory and Beyer, Betsy, "BeyondCorp: A New Approach to Enterprise Security", USENIX ;login:, December 2014.
https://www.usenix.org/system/files/login/articles/login_dec14_02_ward.pdf

[3] Iyengar, Jana and Thomson, Martin (Eds.), "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, IETF, May 2021.
https://datatracker.ietf.org/doc/html/rfc9000

[4] Eastlake, Donald (Ed.), "Transport Layer Security (TLS) Extensions: Extension Definitions (Server Name Indication)", RFC 6066, IETF, January 2011.
https://datatracker.ietf.org/doc/html/rfc6066

[5] Rescorla, Eric, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, IETF, August 2018. (Section 4.4: Certificate-based client authentication — mTLS의 기반 메커니즘)
https://datatracker.ietf.org/doc/html/rfc8446

[6] Cloudflare, "How Cloudflare Tunnel works", Cloudflare Developer Documentation.
https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/

[7] Gartner, "The Future of Network Security Is in the Cloud", Neil MacDonald and Joe Skorupa, August 2019. (Gartner 구독자 접근 가능 — SASE 개념의 최초 정의 보고서)