[Zero Trust] VPN을 믿으면 안 되는 이유 — Zero Trust 보안 아키텍처

2020년 3월, VPN 문제는 용량이 아니었다

2020년 3월 11일, WHO가 팬데믹을 선언했다. 그 다음 주, 전 세계 수천 개의 기업이 동시에 재택근무로 전환했다. VPN 트래픽은 하룻밤 사이에 폭증했고, 많은 기업의 접속 인프라가 응답을 멈췄다.

 

IT 팀은 VPN 집선 장비를 긴급 증설하고 라이선스를 늘리고 대역폭을 확장했다. 그리고 시스템은 다시 돌아갔다.

 

그런데 그해 말, 보안 사고가 쏟아졌다. VPN 취약점을 통한 침투, 탈취된 VPN 계정을 이용한 내부망 장악, 재택 엔드포인트에서 시작된 랜섬웨어 확산. Pulse Secure, Fortinet, Citrix  당시 주요 VPN 벤더들의 취약점 목록은 길었다.

 

용량 문제는 해결됐지만 VPN이 전제하는 신뢰 모델 자체가 현대의 위협 환경과 맞지 않는다는 더 근본적인 문제가 드러났다.

---

Castle-and-Moat — VPN이 만드는 신뢰의 구조

VPN을 "암호화 터널을 뚫어주는 도구"라고 설명하는 것은 기술적으로 맞지만, 더 중요한 것을 놓친다. VPN은 도구이기 이전에 하나의 신뢰 모델 위에 서 있다.

 

그 모델을 Castle-and-Moat라고 부른다. 성(castle)과 해자(moat)로 네트워크를 나눈다. 방화벽 안쪽은 신뢰 구역, 바깥은 비신뢰 구역이다. 외부에서 들어오려면 해자를 건너야 한다. VPN은 그 다리다. 그리고 다리를 건너 성 안에 들어오면 신뢰한다.

 

이 모델의 암묵적 전제는 두 가지다.

• 첫째, 신뢰는 네트워크 위치로 결정된다.
  VPN은 3~4계층(L3/L4)에서 동작한다. IP 패킷을 암호화 터널로 감싸 내부 네트워크의 주소 공간을 할당받는 구조다. 192.168.x.x에서 온 패킷인가 — 이것이 신뢰 판단의 전부다. 그 패킷을 보낸 사람이 누구인지, 기기가 감염됐는지, 계정이 탈취됐는지는 모델이 묻지 않는다. L3/L4 수준의 동작이기 때문에 애플리케이션 단위의 접근 제어는 원천적으로 불가능하다. 내부망에 들어온 사용자는 정책이 허용하는 모든 서버의 모든 포트에 도달할 수 있다.
• 둘째, 신뢰는 세션 단위로 부여된다.
  VPN에 연결되는 순간 신뢰가 시작되고, 세션이 종료될 때까지 유지된다. 접속 시점의 상태만 검증하고 이후 상태 변화는 감지하지 않는다. 연결 후 1시간이 지나 기기가 악성코드에 감염됐어도, 이미 인증된 세션은 살아있다. VPN은 "지금 이 순간"이 아니라 "연결 당시"를 기준으로 신뢰를 판단한다.

두 전제에서 비롯되는 구조적 결과가 하나 더 있다. Hub-and-Spoke 아키텍처가 만드는 트래픽 경로다. 재택 직원이 Salesforce에 접근하는 경우를 생각해 보자. VPN 환경에서 트래픽은 데이터센터를 반드시 경유한다. 물리적으로 데이터센터와 무관한 SaaS에 접근하기 위해 트래픽이 데이터센터를 왕복한다. 이것을 헤어피닝(hairpinning)이라고 부른다.

워크로드가 클라우드와 SaaS로 이동한 환경에서 이 구조는 성능 병목이자 불필요한 복잡성이고, 데이터센터 VPN 게이트웨이가 단일 장애 지점(single point of failure)이 된다.

---

경계가 사라진 세 가지 이유

세계가 변했다. Castle-and-Moat 모델이 전제하는 조건들이 하나씩 사라졌다.

1. 클라우드와 SaaS의 확산.
   워크로드가 AWS, GCP, Azure로 이동하고 업무 도구가 Salesforce, Slack, Google Workspace로 이동했다. 보호해야 할 리소스가 더 이상 방화벽 안에 없다. 경계를 지키더라도 정작 접근해야 할 시스템은 그 경계 밖에 있다. 보호 대상이 경계를 떠났는데 경계를 지키는 것의 의미가 무엇인지 물어야 한다.
   
   
2. 엔드포인트의 분산.
   재택근무, 하이브리드 근무, 다수의 계약직과 파트너. 기업 리소스에 접근하는 기기가 사무실 네트워크 밖에 상시 존재하게 됐다. "내부망에 있다"는 조건 자체가 성립하지 않는 사용자가 늘었다. 경계를 기준으로 신뢰를 구분하는 모델은 경계 밖에 있는 합법적인 사용자를 기본적으로 적대적으로 취급하거나, 반대로 경계 안으로 모두 끌어들여야 하는 딜레마에 빠진다.
   
   
3. 내부자 위협과 래터럴 무브먼트.
   Verizon Data Breach Investigations Report (DBIR)에 따르면 침해 사고의 상당수는 외부 공격자가 내부로 들어온 뒤 내부에서 이동하는 방식으로 진행된다. Castle-and-Moat 모델은 경계를 넘어온 이후의 이동을 막을 구조가 없다. 경계를 뚫은 공격자는 내부에서 신뢰받는다. 경계 방어가 완벽하더라도 경계 안에 들어온 순간부터는 무방비 상태다.

---

취약점 하나가 내부망 전체를 여는 이유

2019년 8월, Pulse Secure VPN에서 CVE-2019-11510이 공개됐다.

인증 없이 임의의 파일을 읽을 수 있는 경로 탐색(path traversal) 취약점이었다. 공격 경로는 간단했다. 특수하게 조작된 HTTP 요청 하나로 VPN 게이트웨이의 세션 캐시 파일에 접근할 수 있었고, 그 안에는 현재 연결된 사용자들의 자격증명이 저장되어 있었다.

패치는 공개됐지만 수천 개의 기업이 수개월에서 수년간 적용하지 않은 채 운영했다. 2020년 NSA와 CISA는 이 CVE가 국가 행위자들에 의해 실제로 악용되고 있다는 공동 경보를 발령했다. 2019년 공개된 Fortinet FortiOS의 CVE-2018-13379도 동일한 패턴이었다. 벤더가 다르고 취약점 번호가 달라도 공격 흐름은 같다.

 

이 사건들이 보여주는 것은 단순한 패치 관리 실패가 아니다. VPN 게이트웨이가 신뢰의 유일한 경계였다는 구조적 문제다. 하나의 게이트웨이가 전체 내부망으로의 관문이면, 그 게이트웨이에 취약점이 생기는 순간 전체 내부망이 열린다. Castle-and-Moat 모델이 내재적으로 가진 단일 실패 지점 문제다.

---

Operation Aurora — Google이 내부망을 없애기로 한 이유

2009년 12월, Google은 정교한 사이버 공격을 받았다. 이후 Operation Aurora로 알려진 이 공격은 중국 Advanced Persistent Threat (APT) 그룹이 수행한 것으로 분석됐으며, 소스코드 저장소와 Gmail 계정 데이터가 탈취됐다.

 

침투 경로를 사후 분석하면서 Google이 도달한 결론은 불편했다. 공격자는 내부망에 있다는 이유만으로 신뢰받던 시스템을 경유해 이동했다. 경계 방어는 작동했지만, 경계 안에서의 이동을 막을 방법이 없었다.

 

Google의 대응은 점진적 개선이 아니었다. 모델 자체를 바꾸기로 했다.

 

2011년부터 시작된 내부 프로젝트의 이름은 BeyondCorp. 목표는 하나였다. 직원이 어느 네트워크에 있든 동일한 정책으로 접근을 제어한다. 사내망 특권을 없앤다. VPN을 없앤다. 카페 WiFi에서의 접근과 사무실에서의 접근을 동일하게 취급한다.

 

BeyondCorp 아키텍처는 네 개의 핵심 컴포넌트로 구성된다.

• Device Inventory Service
  기업이 관리하는 모든 기기를 추적한다. 각 기기에는 PKI 기반의 고유한 인증서가 발급되고, OS 버전, 패치 상태, 보안 에이전트 설치 여부 등 기기 상태(device posture)가 지속적으로 갱신된다. 기기는 네트워크 위치가 아니라 인증서로 신원을 증명한다.
  
• Access Control Engine
  정책 결정을 담당한다. 요청이 들어오면 — 누가(user), 어떤 기기로(device), 어디서(context), 무엇에(resource) 접근하려 하는가 — 를 종합해 허용·거부를 결정한다. 네트워크 위치는 이 판단에서 제외된다. 이후 시리즈에서 다룰 Policy Decision Point (PDP)의 원형이다.
• Access Proxy
  모든 외부 요청의 단일 진입점이다. 내부 애플리케이션은 인터넷에 직접 노출되지 않는다. 모든 요청은 Proxy를 통과하며, Proxy는 Access Control Engine의 결정을 집행한다. Policy Enforcement Point (PEP)에 해당한다.
• User and Group Database
  사용자의 신원, 소속 팀, 역할 정보를 관리한다. Access Control Engine이 정책 결정을 내릴 때 참조하는 기반 데이터다.

판단의 기준을 네트워크 위치에서 두 가지로 옮겼다.

1. 신원(identity): 누가 요청하는가.
2. 기기 상태(device posture): 어떤 기기에서 요청하는가.

2014년부터 2018년까지 Google은 이 경험을 논문 시리즈로 공개했다. BeyondCorp 1편부터 6편까지. 이 논문들이 이후 ZTNA 아키텍처 설계의 레퍼런스가 된다.

---

Zero Trust — 슬로건이 아닌 설계 명제

"Zero Trust"는 현재 마케팅 용어로 오염돼 있다. VPN 제품에도, 방화벽에도, 심지어 Zero Trust와 거의 무관한 제품에도 붙는다. 

 

Zero Trust의 핵심은 세 문장으로 압축된다. 그리고 각 문장은 구체적인 설계 결정을 요구한다.

• Never trust, always verify.
  모든 요청을 처음 보는 것처럼 검증한다. 내부망에 있어도, 이전에 인증했어도, 세션이 유효해도 현재 요청은 현재 기준으로 검증한다. 기술적으로는 세 가지 설계 결정으로 이어진다.
  첫째, 요청마다 토큰을 검증한다. 세션이 유효하다는 사실이 현재 요청의 인가(authorization)를 보장하지 않는다.
  둘째, mTLS로 양방향 인증한다. 클라이언트가 서버를 신뢰하는 것처럼, 서버도 클라이언트의 인증서를 검증한다.
  셋째, 세션 재평가 주기를 설계한다. 오래 지속되는 세션은 중간의 상태 변화 (기기 감염, 위치 변경, 권한 변경)를 반영하지 못한다.
  
  
• Least privilege access.
  필요한 리소스에만, 필요한 시간 동안만 접근을 허용한다. VPN이 제공하는 것은 네트워크 레벨의 접근이다. 내부망에 들어온 사용자는 방화벽 규칙이 막지 않는 한 모든 서버의 모든 포트에 접근할 수 있다. ZTNA는 애플리케이션 단위로 접근을 제어한다. 특정 앱, 특정 API 엔드포인트, 특정 시간 범위. 상시 부여된 광범위한 권한(standing privilege)이 아니라 요청 시점의 컨텍스트를 반영한 동적 권한이 기본값이다. 이 원칙의 극단적 구현이 JIT(Just-In-Time) Access다.
  
  
• Assume breach.
  이미 침해당했다고 가정하고 설계한다. 이 원칙은 경계 방어에 관한 것이 아니라 내부 아키텍처에 관한 것이다.
  마이크로세그멘테이션
  내부망을 작은 구역으로 나눠 공격자의 수평 이동(래터럴 무브먼트)을 제한하여 피해를 최소화 한다. 침해가 발생했을 때 공격자가 이동할 수 있는 범위를 설계 단계에서 제한하는 방법이다. 또한 지속적 모니터링을 통해 침해 중에도 이상 행동을 탐지하고 대응한다. "침해를 막는다"에서 "침해의 영향 범위를 통제한다"로 목표가 바뀐다.

---

ZTNA의 두 가지 구현 패턴

ZTNA를 어떻게 구현하는지는 이 시리즈 전체에서 반복되는 주제다. 크게 두 패턴으로 나뉜다.

• Client-initiated (에이전트 기반).
  사용자 기기에 에이전트가 설치된다. 에이전트는 컨트롤러에 연결을 요청하고, 기기 인증서와 사용자 신원 정보를 전달한다. 인증이 완료되면 컨트롤러는 해당 사용자가 접근 가능한 애플리케이션 목록을 반환하고, 에이전트는 각 앱으로의 암호화 터널을 동적으로 생성한다. 기기 상태(device posture)를 정밀하게 수집할 수 있고 네트워크 레벨 제어가 가능하다. 에이전트 설치가 불가능한 BYOD(Bring Your Own Device)나 외부 파트너 환경에는 적용이 어렵다.

• Service-initiated (에이전트리스, 리버스 프록시).
  사용자 기기에 에이전트를 설치하지 않는다. 대신 내부 애플리케이션 앞에 커넥터(connector)를 배치한다. 커넥터는 외부 게이트웨이로 아웃바운드 연결을 유지한다. 사용자가 접근을 요청하면 브라우저를 통해 게이트웨이를 거쳐 커넥터로 트래픽이 흐른다. 내부 인프라가 인터넷에 직접 노출되지 않고(dark network), 에이전트 없이 동작한다는 장점이 있다. 비관리 기기에도 적용할 수 있다.

---

신뢰의 기준이 바뀌었다

두 패턴은 구현 방식이 다르지만 전제하는 것은 같다. 신뢰의 근거가 네트워크 위치에서 벗어났다. 에이전트 기반이든 리버스 프록시든, 접근을 허용하기 전에 묻는 질문은 동일하다.

 

누가 요청하는가. 어떤 기기로 요청하는가. 지금 이 순간 그 조합은 신뢰할 수 있는가.

 

VPN은 이 질문을 묻지 않았다. 다리를 건넜는가만 물었다. 그 차이가 Castle-and-Moat와 Zero Trust를 가른다.