제로 트러스트 보안이란? 기업이 알아야 할 핵심 개념

전통적인 네트워크 보안은 성(castle)과 해자(moat)에 비유된다. 외부의 공격을 방화벽으로 막고, 내부 네트워크에 들어온 사용자와 기기는 신뢰한다. 문제는 한 번 뚫리면 내부에서 자유롭게 움직일 수 있다는 거다. 공격자가 VPN 계정 하나만 탈취하면 내부 네트워크를 돌아다니면서 원하는 데이터에 접근할 수 있다.

제로 트러스트(Zero Trust)는 이 전제를 뒤집는다. 내부든 외부든, 누구든 아무것도 신뢰하지 않는다. 모든 접근을 매번 검증한다.

"Never Trust, Always Verify"

이게 제로 트러스트의 핵심 문장이다. 사내 네트워크에 접속했다고 해서 신뢰받는 게 아니다. 회사 노트북이라고 해서 무조건 안전한 게 아니다. 모든 요청에 대해 "이 사용자가 누구인지, 이 기기가 안전한지, 이 리소스에 접근할 권한이 있는지"를 확인한다.

왜 이런 모델이 필요해졌을까.

첫째, 경계가 사라졌다. 코로나 이후 원격 근무가 보편화됐다. 직원들이 집, 카페, 공항에서 회사 시스템에 접속한다. "회사 네트워크 안에 있으니까 안전하다"는 전제가 성립하지 않는다.

둘째, 클라우드 전환. 데이터와 애플리케이션이 온프레미스 데이터센터가 아니라 AWS, Azure, GCP에 흩어져 있다. SaaS 서비스도 쓴다. "내부 네트워크"라는 개념이 희석됐다.

셋째, 공격 수법의 진화. 피싱으로 한 명의 계정을 탈취한 뒤 내부에서 횡적 이동(lateral movement)하며 권한을 올리는 게 일반적인 공격 패턴이다. 외부를 막는 것만으로는 부족하다.

핵심 원칙

최소 권한 원칙 (Least Privilege)

사용자, 기기, 애플리케이션에 필요한 최소한의 권한만 부여한다. 마케팅 팀원이 프로덕션 DB에 접근할 이유가 없다. 개발자라고 해서 모든 서비스의 관리자 권한을 가질 필요가 없다.

AWS IAM으로 치면, "Effect": "Allow", "Action": "*", "Resource": "*" 같은 정책은 논외다. 필요한 서비스의 필요한 액션에만 권한을 부여해야 한다.

역할 기반 접근 제어(RBAC)가 기본이고, 더 세밀하게는 속성 기반 접근 제어(ABAC)를 쓸 수 있다. ABAC는 시간, 위치, 기기 상태 같은 속성을 조건에 포함시킨다. "오전 9시~6시, 회사 관리 기기에서, 한국 IP로 접속할 때만 허용" 같은 정책이 가능하다.

마이크로 세그멘테이션

네트워크를 작은 단위로 분할하는 거다. 전통적인 네트워크에서는 같은 VLAN에 있는 서버들끼리 자유롭게 통신할 수 있었다. 웹 서버가 뚫리면 같은 네트워크의 DB 서버로 바로 접근 가능했다.

마이크로 세그멘테이션은 각 워크로드 사이에 방화벽을 둔다. 웹 서버는 앱 서버의 특정 포트로만 통신할 수 있고, 앱 서버는 DB 서버의 특정 포트로만 통신할 수 있다. 하나가 뚫려도 옆으로 이동하기 어렵게 만든다.

쿠버네티스에서는 Network Policy로 이걸 구현한다. Pod 간 통신을 명시적으로 허용하지 않으면 차단하는 방식.

지속적 검증

한 번 인증했다고 끝이 아니다. 세션 중에도 계속 검증한다. 갑자기 다른 나라에서 접속하면? 평소 안 쓰던 기기에서 접속하면? 비정상적인 양의 데이터를 다운로드하면? 이런 상황에서 재인증을 요구하거나 접근을 차단한다.

이런 접근을 "Continuous Adaptive Risk and Trust Assessment"라고 하는데, 줄여서 CARTA라고 부르기도 한다. 실시간으로 위험도를 평가해서 접근 수준을 동적으로 조절하는 거다.

핵심 기술

IAM (Identity and Access Management)

제로 트러스트의 중심. 사용자의 신원을 확인하고, 적절한 권한을 부여하고, 접근을 제어한다.

단순한 ID/비밀번호를 넘어서 다중 인증(MFA)이 기본이다. FIDO2 보안 키, 생체인증 같은 피싱 저항형 인증이 권장된다. SSO(Single Sign-On)로 인증을 중앙화하면 관리가 수월하고, 퇴사자의 계정을 한 곳에서 비활성화할 수 있다.

주요 솔루션: Okta, Microsoft Entra ID(구 Azure AD), Google Workspace, Ping Identity

ZTNA (Zero Trust Network Access)

VPN의 대안이다. VPN은 접속하면 내부 네트워크 전체에 접근할 수 있는 반면, ZTNA는 특정 애플리케이션에만 접근을 허용한다. "네트워크에 연결한다"가 아니라 "특정 앱에 접근한다"로 패러다임이 바뀌는 거다.

VPN은 터널을 열면 네트워크 레벨의 접근이 생기니까, 그 안에서 어떤 서버에든 접근을 시도할 수 있다. ZTNA는 애플리케이션 레벨에서 접근을 제어하니까 허용된 앱 외에는 보이지도 않는다.

Zscaler Private Access, Cloudflare Access, Palo Alto Prisma Access 같은 제품이 ZTNA를 제공한다.

SDP (Software-Defined Perimeter)

ZTNA와 비슷한 개념인데, 더 넓은 프레임워크다. 인증 전에는 서비스 자체가 보이지 않는다. DNS 조회도 안 되고, 포트 스캔도 안 되고, 네트워크 레벨에서 아예 존재를 감춘다. 인증과 인가를 통과한 후에야 해당 서비스에 대한 접근이 열린다.

"다크 클라우드"라고 불리기도 한다. 보이지 않으니까 공격할 수 없다는 접근.

EDR / XDR

엔드포인트(기기)의 보안 상태를 모니터링하고 위협에 대응하는 솔루션. 제로 트러스트에서는 기기의 상태도 신뢰 결정에 포함된다. OS 패치가 안 되어 있거나, 백신이 꺼져 있거나, 탈옥된 기기라면 접근을 제한할 수 있다.

CrowdStrike, SentinelOne, Microsoft Defender for Endpoint 같은 제품. 최근에는 EDR을 넘어서 네트워크, 클라우드, 이메일까지 통합 모니터링하는 XDR(Extended Detection and Response)로 확장되고 있다.

Google의 BeyondCorp

제로 트러스트를 가장 먼저 대규모로 구현한 사례로 자주 인용된다. Google이 2011년부터 자사 내부에서 구축한 제로 트러스트 아키텍처다.

핵심 아이디어: VPN을 없앤다. Google 직원은 사내 네트워크와 외부 네트워크에서 동일한 방식으로 사내 시스템에 접근한다. 모든 접근은 사용자의 신원과 기기 상태를 기반으로 결정된다.

BeyondCorp의 구성 요소:

• Device Inventory — 회사가 관리하는 모든 기기의 목록과 보안 상태를 추적
• Access Proxy — 모든 사내 앱 접근이 프록시를 통한다. 이 프록시가 인증과 인가를 수행
• Trust Engine — 사용자의 신원 + 기기 상태 + 접근 정책을 종합해서 접근 허용 여부 결정

Google이 2014년에 발표한 BeyondCorp 논문들이 업계 전반의 제로 트러스트 움직임에 상당한 영향을 줬다. Cloudflare, Zscaler 같은 회사들이 이 모델을 제품화한 셈이다.

도입 단계

하루아침에 제로 트러스트로 전환할 수는 없다. 단계적으로 접근해야 한다.

1단계: 자산 파악

뭘 보호해야 하는지 먼저 알아야 한다. 사용자, 기기, 애플리케이션, 데이터의 목록을 만든다. 이걸 "보호 표면(Protect Surface)"이라고 부른다. 공격 표면(Attack Surface)이 너무 넓으니까, 보호해야 할 핵심 자산을 식별하는 거다.

2단계: 트래픽 흐름 파악

누가, 어디서, 어떤 데이터에 접근하는지 현재 흐름을 파악한다. 이걸 알아야 어디에 접근 제어를 걸지 결정할 수 있다.

3단계: ID 기반 접근 제어 도입

IAM을 강화한다. MFA를 적용하고, SSO를 도입하고, 역할 기반 접근 제어를 정비한다. 많은 조직이 여기서부터 시작한다.

4단계: 마이크로 세그멘테이션 적용

네트워크를 분할한다. 핵심 자산부터 시작해서 점진적으로 확대한다.

5단계: VPN → ZTNA 전환

VPN을 ZTNA로 대체한다. 한꺼번에 전환하기보다 특정 앱부터 시작해서 점진적으로 이전한다.

6단계: 지속적 모니터링과 개선

제로 트러스트는 "구축하면 끝"이 아니라 지속적인 프로세스다. 접근 로그를 분석하고, 정책을 조정하고, 새로운 위협에 대응한다.

도입 시 겪는 어려움

이론은 깔끔한데 현실은 복잡하다.

레거시 시스템 — 20년 된 온프레미스 애플리케이션이 최신 인증 프로토콜을 지원하지 않는 경우가 많다. SAML도 안 되고, OAuth도 안 되고. 이런 시스템에 제로 트러스트를 적용하려면 앞단에 프록시를 두거나, 결국 시스템 자체를 현대화해야 한다.

사용자 경험 — 매번 인증을 요구하면 사용자가 불편해한다. MFA 피로(MFA fatigue)라는 게 있다. 너무 자주 인증을 요구하면 사용자가 무의식적으로 "승인"을 눌러버린다. 실제로 2022년 Uber 해킹이 MFA 피로 공격으로 시작됐다. 공격자가 탈취한 계정으로 계속 MFA 푸시를 보내서, 귀찮아진 직원이 결국 승인한 거다.

보안과 편의 사이의 균형을 잡아야 한다. 위험도가 낮은 접근은 간소화하고, 위험도가 높은 접근만 강화하는 적응형 인증이 답이 될 수 있다.

비용과 복잡성 — 제로 트러스트는 단일 제품이 아니라 아키텍처다. IAM, ZTNA, EDR, SIEM 등 여러 솔루션을 도입하고 연동해야 한다. 중소기업에게는 부담스러울 수 있다.

조직 문화 — "항상 검증한다"는 건 어떻게 보면 "직원을 신뢰하지 않는다"로 받아들여질 수 있다. 기술 도입 전에 왜 이런 접근이 필요한지 조직 전체가 이해해야 한다. 보안 팀만의 프로젝트로는 성공하기 어렵다.

제로 트러스트는 목적지가 아니라 여정이다

"제로 트러스트를 도입했다/안 했다"로 이분법으로 나뉘는 게 아니다. 성숙도의 스펙트럼 위에서 어디에 있느냐의 문제다.

중요한 건 방향성이다. 경계 기반 보안에서 ID 기반 보안으로, 암묵적 신뢰에서 명시적 검증으로, 한 번 인증에서 지속적 검증으로. 이 방향으로 한 발짝씩 움직이는 거다. IAM 강화와 MFA 도입만으로도 보안 수준은 확실히 올라간다. 거기서부터 시작하면 된다.