전통적인 보안 모델은 성과 해자(moat) 비유로 설명된다. 방화벽이 해자이고, 일단 안에 들어오면 신뢰한다. 내부 네트워크에서 오는 요청은 별도 인증 없이 통과된다. 이 모델의 전제는 “내부 네트워크는 안전하다"는 것이다.

이 전제가 흔들렸다. 클라우드가 도입되면서 내부/외부 경계가 흐려졌다. 직원이 카페에서 SaaS를 쓰고, 파트너사가 VPN으로 내부에 접근하고, 마이크로서비스가 서로를 호출한다. 한 번 침투하면 내부에서 자유롭게 이동할 수 있는 구조가 됐다.

Zero Trust는 이 구조를 뒤집는다. “절대 신뢰하지 말고, 항상 검증하라(Never Trust, Always Verify)”.

핵심 원칙

위치(IP)가 아니라 아이덴티티로 인증한다. 내부 IP에서 왔다는 것만으로 신뢰하지 않는다. 요청자가 누구인지, 어떤 디바이스에서 왔는지를 확인한다.

최소 권한 접근: 필요한 리소스에만, 필요한 시간 동안만 접근을 허용한다. 한 서비스가 침해돼도 다른 서비스로 이동하기 어렵게 만든다.

매 요청을 검증한다. 한 번 인증했다고 이후 모든 요청을 신뢰하지 않는다. 컨텍스트(디바이스 상태, 위치, 시간)를 계속 확인한다.

명시적으로 검증한다. 암묵적인 신뢰(내부 네트워크니까, VPN 연결됐으니까) 대신 모든 접근을 명시적으로 허용한다.

Google BeyondCorp

Zero Trust의 가장 유명한 실제 구현이다. Google은 2010년대 초부터 내부 네트워크 개념을 없애고 모든 직원이 인터넷에서 직접 내부 서비스에 접근하는 구조를 만들었다.

전통 방식:
  직원 → VPN 연결 → 내부 네트워크 → 서비스 (내부 IP이므로 신뢰)

BeyondCorp:
  직원 → 인터넷 → Access Proxy
    → 사용자 아이덴티티 확인 (Google 계정)
    → 디바이스 상태 확인 (관리 디바이스인지, 최신 패치인지)
    → 접근 정책 평가 (이 사용자가 이 서비스에 접근 가능한지)
    → 허용되면 서비스로 포워딩

VPN 없이 인터넷에서 직접 접근하지만, 모든 요청에서 아이덴티티와 디바이스 상태를 검증한다. 카페에서 접근하든 사무실에서 접근하든 동일한 정책이 적용된다.

구현 요소

아이덴티티 기반 접근 (IAP — Identity-Aware Proxy)

AWS의 경우 ALB + Cognito, 또는 IAP 서비스(BeyondCorp Enterprise, Cloudflare Access)가 이 역할을 한다. 앱 앞에 프록시를 두고, 모든 요청에서 인증을 강제한다. 내부 서비스 URL이 외부에 노출돼 있어도 인증 없이는 접근이 안 된다.

서비스 간 mTLS

사람의 접근뿐 아니라 서비스 간 통신도 검증한다. 서비스 A가 서비스 B를 호출할 때 mTLS로 양방향 인증한다. IP 기반 신뢰를 없애고 서비스 아이덴티티(인증서)로 신뢰를 확립한다. Istio 같은 서비스 메시가 이를 자동화한다.

마이크로세그멘테이션

네트워크를 세밀하게 나눠 서비스 간 통신을 제한한다. k8s의 NetworkPolicy가 이 역할을 한다. 모든 파드가 서로 통신 가능한 기본 상태에서, 필요한 통신만 명시적으로 허용하는 화이트리스트 방식으로 전환한다.

디바이스 신뢰

사용자 인증뿐 아니라 디바이스도 검증한다. MDM(Mobile Device Management)으로 관리되는 디바이스, 최신 OS 패치가 적용된 디바이스인지 확인한다. 개인 디바이스나 패치가 안 된 디바이스에서 오는 요청은 제한하거나 차단한다.

트레이드오프

Zero Trust는 보안 수준을 높이지만 구현 복잡도가 크게 늘어난다. 모든 서비스에 인증 레이어를 붙이고, 인증서를 관리하고, 정책을 유지해야 한다. 개발 환경에서도 같은 정책을 적용하면 개발 속도가 느려진다.

레이턴시도 늘어난다. 매 요청마다 정책 평가가 추가된다. 정책 평가 서버가 병목이 되거나 장애가 나면 전체 서비스 접근이 막힌다. 정책 서버 자체의 고가용성이 중요해진다.

전면 도입보다 가장 중요한 리소스부터 점진적으로 적용하는 것이 현실적이다. 외부 노출 서비스, 민감한 내부 서비스부터 시작해 범위를 넓혀간다.