Zero Trust와 VPN은 무엇이 다른가

“Zero Trust로 가야 한다”는 말을 듣고 나면 대개 두 가지가 동시에 궁금해집니다. 그것이 정확히 무엇인가, 그리고 지금 쓰는 VPN을 걷어내는 일인가입니다. 두 질문은 붙어 있는 것처럼 보이지만 답의 성격이 서로 다릅니다.

혼란의 원인은 대체로 용어에 있습니다. Zero Trust라는 말이 설계 원칙을 가리킬 때와 특정 회사의 제품군을 가리킬 때가 섞여서 쓰이기 때문입니다. 이 글은 제품 비교표를 만들기 전에, 원칙과 제품과 기존 VPN이 서로 어떤 관계에 놓이는지부터 정리합니다.

VPN은 무엇을 전제하고 동작하는가

VPN(가상 사설망)은 “사내 네트워크 안에 있으면 신뢰할 수 있다”는 전제 위에서 동작합니다. 사용자의 기기와 회사 관문 사이에 암호화된 통로를 만들고, 그 통로를 통과한 사용자를 네트워크 내부에 있는 것으로 취급합니다.

이 방식의 판단은 접속하는 순간에 한 번 일어납니다. 아이디와 비밀번호, 경우에 따라 추가 인증까지 확인하고 나면 그 뒤로는 통로가 유지되는 동안 별도의 판단이 끼어들지 않습니다. 그래서 VPN이 다루는 단위는 연결입니다. 어떤 사람에게 어떤 시스템을 열어 줄지가 아니라, 네트워크에 들여보낼지 말지를 정합니다.

이 전제는 오랫동안 잘 맞았습니다. 직원이 사무실에 있고 서버가 전산실에 있던 시절에는 회사 네트워크의 안과 밖이 실제로 갈려 있었고, 안에 들어왔다는 사실 자체가 상당한 정보였기 때문입니다.

위치를 신뢰하는 방식이 부담이 되는 자리

접근 주체와 접근 대상이 모두 네트워크 밖으로 흩어지면서 위치 기반 판단이 감당해야 할 일이 늘었습니다. 다음 네 지점에서 그 부담이 드러납니다.

• 들어온 뒤의 범위가 넓습니다. 통로를 통과한 사용자는 네트워크 계층에서 도달할 수 있는 대상 전체를 마주하게 됩니다. 실제로 써야 하는 시스템이 하나여도 그렇습니다.
• 전부 아니면 전무로 갈립니다. 협력사나 외주 인력에게 특정 시스템 하나만 열어 주려 해도, 도구가 다루는 단위가 네트워크이므로 범위를 그 아래로 쪼개려면 별도의 설계가 추가로 필요합니다.
• 회수가 여러 곳에서 일어납니다. 사람이 나갔을 때 VPN 계정과 각 시스템의 계정이 따로 있으면 회수해야 할 자리가 흩어집니다. 빠뜨린 자리는 빠뜨렸다는 사실 자체가 드러나지 않습니다.
• 관문 한곳에 몰립니다. 원격 인원이 늘면 트래픽과 장애 영향이 같은 지점에 모입니다. 그 지점이 멈추면 모든 접근이 함께 멈춥니다.

여기서 유의하실 점이 있습니다. 이런 부담은 VPN 제품의 결함 목록이 아니라 위치를 신뢰의 근거로 삼는 설계가 원격·외부 인력이 많은 환경에서 겪는 구조적 부담입니다. 환경이 그렇지 않다면 이 부담은 거의 나타나지 않습니다.

Zero Trust는 원칙이지 제품이 아닙니다

Zero Trust는 특정 회사의 상품 이름이 아니라 “네트워크 위치를 신뢰의 근거로 삼지 않는다”는 설계 원칙입니다. 미국 국립표준기술연구소가 펴낸 NIST SP 800-207이 이 원칙을 벤더 중립적으로 정리해 두었고, 오늘날 여러 회사가 쓰는 Zero Trust라는 말은 대체로 이 문서가 정의한 사고방식을 가리킵니다.

원칙이 요구하는 것은 대략 이런 내용입니다.

• 접근 판단은 자원 단위로 한다. 네트워크에 들어왔다는 사실은 판단의 근거가 되지 않는다.
• 판단은 한 번으로 끝나지 않고 요청마다 다시 이뤄진다.
• 판단에는 사용자 신원뿐 아니라 기기 상태(접속에 쓰는 기기가 회사가 정한 조건을 갖췄는지 — 보안 업데이트 적용 여부 같은 것), 요청 시점, 대상 자원의 민감도 같은 여러 신호가 들어간다.
• 허용된 권한은 그 작업에 필요한 만큼으로 좁게 유지한다.

원칙이라는 말의 실질적인 뜻은, 이것을 만족하는 구현이 여럿일 수 있다는 것입니다. 클라우드 제공사의 권한 체계로 일부를 만족시킬 수도 있고, 접근 통제 전용 제품군을 도입해 만족시킬 수도 있으며, 두 가지를 함께 쓰기도 합니다. 그래서 “Zero Trust를 도입했다”는 문장만으로는 무엇을 했는지 알 수 없습니다. 무엇을 어느 범위에 적용했는지를 함께 들어야 내용이 생깁니다.

“Cloudflare Zero Trust”는 제품군의 이름입니다

Cloudflare Zero Trust는 네트워크 위치를 신뢰의 근거로 삼지 않는다는 Zero Trust 원칙을 구현한 상용 제품군의 이름이며, 문서에서는 Cloudflare One이라는 명칭으로도 정리돼 있습니다. 원칙과 이름이 겹치기 때문에 대화 중에 층위가 자주 뒤섞입니다.

제품군을 역할로 나눠 보면 이해가 빠릅니다.

• 애플리케이션 접근 정책 — 어떤 사람이 어떤 애플리케이션에 접근할 수 있는지를 규칙으로 정의하는 부분입니다. 신원 공급자(회사 계정을 한 곳에서 만들고 지우는 체계 — Google Workspace, Microsoft Entra ID, 사내 AD 같은 것)와 연동해 사용자·그룹·기기 조건 등을 조합합니다(Access 정책 문서).
• 자원 연결 — 사내나 클라우드에 있는 대상을 외부에서 들어오는 포트를 열지 않고 연결하는 부분입니다. 대상 쪽에서 바깥으로 연결을 맺는 방식을 씁니다(Cloudflare Tunnel 문서).
• 기기 측 클라이언트 — 사용자의 기기에 설치해 트래픽 경로와 기기 상태 확인을 담당하는 부분입니다.

여기서 두 가지를 구분해 두시는 편이 좋습니다. 첫째, 이 제품군은 원칙의 한 구현이지 원칙 자체가 아닙니다. 같은 원칙을 구현한 제품군은 다른 회사에도 있습니다. 둘째, 제품을 도입하는 것과 원칙을 만족하는 것은 다른 일입니다. 접근 정책을 넓게 열어 둔 채 제품만 얹으면 판단 근거는 그대로 위치에 남습니다.

구성과 요금 구간은 시간이 지나면서 바뀌므로 이 글에서는 다루지 않습니다. 세부는 Cloudflare 공식 문서에서 확인하시는 편이 정확합니다.

AWS IAM 기반 접근통제와는 적용 대상이 다릅니다

AWS IAM과 다단계 인증(MFA)으로 구성하는 접근통제도 Zero Trust 원칙을 따르지만, 원칙이 적용되는 대상이 Cloudflare Zero Trust 같은 접근 제품군과 다릅니다. 이 구분을 놓치면 벤더가 뒤바뀐 채로 논의가 진행됩니다.

두 가지는 대체 관계가 아닙니다. IAM 권한을 아무리 정교하게 짜도 사내 위키나 사내 관리 화면에 누가 들어오는지는 그 체계가 답하지 않고, 반대로 접근 제품군을 아무리 잘 구성해도 클라우드 자원에 붙은 권한이 넓으면 그 부분은 그대로 남습니다. IAM 보안 모범 사례와 Zero trust on AWS가 다루는 범위를 보시면 경계가 분명해집니다.

한 가지 덧붙이면, 빌드업웍스의 통합 보안 서비스 범위에 적힌 Zero Trust 항목은 IAM 최소 권한, MFA, 네트워크 분리, 접근 로그 수집처럼 AWS 쪽 수단을 가리킵니다. 원칙은 같지만 이 글에서 설명한 접근 제품군과는 다른 층위이므로, 두 가지를 같은 항목으로 읽지 않으셔야 합니다.

VPN과 Zero Trust 방식 한눈에 비교

VPN과 검증 기반 접근은 도구의 성능이 아니라 판단의 근거에서 갈립니다.

표의 왼쪽이 틀리고 오른쪽이 맞다는 뜻이 아닙니다. 판단 근거가 다르면 잘 맞는 상황도 달라진다는 뜻입니다.

VPN을 꺼야 하는가

Zero Trust로 옮기는 일과 VPN을 끄는 일은 같은 작업이 아닙니다. 두 가지를 하나의 일정으로 묶으면 일정이 지연되기 쉽고, 지연을 피하려다 접근 범위를 임시로 넓게 열어 두게 됩니다.

실무에서 흔한 순서는 이렇습니다. 먼저 웹으로 접근하는 애플리케이션 중 경계가 분명한 것부터 옮기고, 옮긴 대상은 VPN 경로에서 닫습니다. 그다음 남은 대상을 하나씩 같은 방식으로 처리합니다. 이 과정에서 두 방식은 한동안 함께 존재하며, 그 기간을 실패로 보지 않는 것이 중요합니다.

빌드업웍스의 운영 경험에서는, 전환을 시작하기 전에 “누가 무엇에 접근하는가”의 목록부터 만드는 편이 결과적으로 더 빠릅니다. 목록이 없으면 무엇을 옮겼고 무엇이 남았는지 판단할 기준이 없어서, 옮기는 작업은 진행되는데 기존 경로는 계속 열려 있는 상태가 됩니다.

VPN이 여전히 맞는 경우

VPN이 더 맞는 상황은 분명히 있고, 빌드업웍스도 조건에 따라 VPN을 구성합니다. 아래 상황에서는 검증 기반 접근으로 옮기는 것이 이득보다 부담을 먼저 만듭니다.

• 필요한 것이 애플리케이션이 아니라 네트워크 자체일 때. 데이터베이스 클라이언트, SSH·RDP, 사내 파일 공유, 산업용 장비 프로토콜처럼 웹이 아닌 트래픽이 중심이면 애플리케이션 단위로 나누는 작업 자체가 큰 과제가 됩니다. 이런 대상은 검증 기반 구성으로도 다룰 수 있지만, 웹 애플리케이션을 옮기는 것보다 손이 훨씬 많이 갑니다.
• 거점과 거점을 상시로 이어야 할 때. 본사와 지사, 사무실과 데이터센터처럼 네트워크 대 네트워크를 계속 연결해 두어야 하는 구간은 애초에 사람의 접근을 통제하는 문제가 아닙니다. 이 구간은 검증 기반 접근을 도입한 뒤에도 그대로 남는 것이 보통입니다.
• 접근 주체가 소수이고 거의 바뀌지 않을 때. 정직원 몇 명만 접근하고 인원 변동이 드물다면 회수 부담이 실제로 발생하지 않습니다. 발생하지 않는 문제를 풀기 위해 구조를 바꾸면 운영해야 할 대상만 늘어납니다.
• 신원 공급자가 아직 없을 때. 검증 기반 접근은 “이 사람이 누구인가”를 답해 주는 체계를 축으로 삼습니다. 사내 계정 체계가 정리돼 있지 않은 상태에서 접근 제품군을 먼저 도입하면, 정책의 기준이 될 신원 정보가 없어 결국 넓은 규칙 몇 개만 만들어 두게 됩니다. 이 경우 순서는 계정 체계 정리가 먼저입니다.
• 계약이나 규정이 특정 연결 방식을 지정할 때. 발주처나 규제 요건이 전용 회선이나 VPN 연결을 명시하는 경우가 있습니다. 이때는 기술적 우열과 무관하게 지정된 방식을 유지해야 하고, 검증 기반 접근은 그 안쪽에서 추가로 적용하는 형태가 됩니다.

옮길 때인지 판단하는 기준

전환 시점은 회사 규모가 아니라 접근 구조가 얼마나 복잡한지로 판단하는 편이 정확합니다. 아래 항목에 답해 보시면 지금 어느 쪽에 가까운지 가늠하실 수 있습니다.

• 지금 열려 있는 접근 대상을 애플리케이션 단위로 목록화할 수 있습니까
• 외부 인력이나 협력사에 열어 준 접근이 있고, 그 범위를 사람 단위로 설명할 수 있습니까
• 사람이 나갈 때 회수해야 할 자리가 문서로 정해져 있습니까
• 지난달에 누가 어떤 시스템에 접근했는지 물었을 때 답할 수 있습니까
• 사내 계정을 한곳에서 만들고 비활성화하는 체계(앞서 말한 신원 공급자)가 있습니까

이 중 계정 체계 항목이 특히 중요합니다. 다른 항목이 모두 “아니오”여도 계정 체계가 정리돼 있으면 전환은 진행할 만하지만, 계정 체계가 없으면 나머지가 갖춰져 있어도 정책을 걸 기준이 없습니다.

앞 절의 「VPN이 여전히 맞는 경우」와 이 목록은 같은 질문에 답하는 두 도구입니다. 아래 세 갈래로 묶어서 보시면 됩니다.

• 사내 계정을 한곳에서 만들고 지우는 체계가 없다면 — 순서는 계정 체계 정리가 먼저입니다. 전환 검토는 그다음입니다.
• 계정 체계가 있고, 열어 줄 대상이 주로 웹 애플리케이션이며 외부 인력이 섞여 있다면 — 경계가 분명한 애플리케이션 하나부터 옮기고, 그 대상만 VPN 경로에서 닫습니다.
• 열어 줄 대상이 네트워크 자체(데이터베이스 클라이언트, SSH, 거점 간 연결)가 중심이라면 — VPN을 유지하시고, 웹으로 접근하는 부분에만 검증 기반을 얹습니다.

웹 애플리케이션 한 개를 옮기는 일과 사내 자원 전체를 옮기는 일은 성격이 다릅니다. 전자는 담당자 한 사람이 맡을 수 있고, 후자는 별도의 과제로 잡아야 합니다.

옮기면서 흔히 놓치는 것

계획 단계에서 자주 빠지는 항목은 대체로 정해져 있습니다. 미리 확인해 두시면 대부분 피할 수 있습니다.

• 목록화를 건너뛰고 도구부터 도입하는 것. 도구를 먼저 넣으면 정책을 넓게 열어 두고 시작하게 되고, 그렇게 열어 둔 규칙은 좁힐 계기가 잘 생기지 않습니다.
• 기존 VPN 경로를 닫지 않는 것. 옮긴 애플리케이션에 예전 경로가 그대로 살아 있으면 새 정책은 우회 가능한 장식이 됩니다. 옮기는 작업과 닫는 작업을 한 쌍으로 묶어 두십시오.
• 예외 경로를 방치하는 것. 고정 IP 허용, 임시 계정, 협력사에 준 별도 통로 같은 예외는 처음에는 임시로 만들어졌다가 남습니다. 예외 목록을 따로 관리하고 만료일을 붙이시길 권합니다.
• 로그가 끊기는 것. 접근 경로가 바뀌면 기존에 수집하던 로그의 의미도 달라집니다. 전환 중에 두 경로의 기록이 서로 다른 곳에 쌓이면, 나중에 접근 이력을 물었을 때 답할 수 없는 구간이 생깁니다.
• 관리자 접근을 대상에서 빼는 것. 일반 사용자용 애플리케이션만 옮기고 서버 관리 경로는 예전 방식에 남겨 두는 경우가 있습니다. 권한이 가장 큰 경로가 가장 나중에 남는 셈이라, 순서를 반대로 잡으시는 편이 낫습니다.
• 기기 조건을 처음부터 강하게 거는 것. 기기 상태를 판단에 넣는 것은 원칙에 맞지만, 초기부터 조건을 촘촘히 걸면 정상 사용자가 막히는 일이 잦아 결국 조건을 통째로 풀게 됩니다. 신원과 애플리케이션 단위 통제를 먼저 안정시킨 뒤 단계적으로 더하는 편이 유지됩니다.

다음 단계

지금 어느 단계에 있는지부터 확인하시는 것이 순서상 먼저입니다. 보안 진단에는 경계 신뢰를 줄이고 검증 기반으로 옮기고 있는지를 묻는 항목이 포함돼 있어, 이 글에서 다룬 기준을 자신의 환경에 대입해 보실 수 있습니다. 연락처를 남기지 않아도 결과는 바로 확인하실 수 있습니다.

제공 범위를 먼저 확인하고 싶으시면 통합 보안 서비스 범위에서 어디까지가 저희 몫이고 어디부터 별도인지 나눠 적어 둔 부분을 보십시오. 지금 구조에서 무엇부터 옮기는 것이 맞을지 함께 정리하고 싶으시면 상담 신청으로 연락 주십시오.

참고 자료

• NIST SP 800-207 — Zero Trust Architecture
• AWS Prescriptive Guidance — Understanding Zero Trust principles
• Zero trust on AWS
• Cloudflare One 문서 — 개요
• Cloudflare 문서 — Access 정책
• Cloudflare 문서 — Cloudflare Tunnel
• AWS 문서 — IAM 보안 모범 사례