제로 트러스트

제로 트러스트는 요청이 회사 네트워크 안에서 왔다는 이유만으로 믿어 주지 않는 보안 설계입니다. 안에서 온 요청도 밖에서 온 요청과 똑같이 확인을 거칩니다. 요청 하나하나를 따로 따져 본 다음에야 통과시킵니다.

상세

네트워크 안쪽을 믿던 옛 방식이 어디서 무너졌는지부터 보면 이 설계가 왜 나왔는지 드러납니다.

제로 트러스트(zero trust)는 「기본으로 주는 신뢰가 0」이라는 뜻입니다. 여기서 신뢰는 확인 없이 통과시켜 주는 것을 말합니다. 이 설계에서는 어떤 요청도 확인 없이 통과하지 못합니다.

이 원칙을 따라 지은 시스템 구조 전체는 제로 트러스트 아키텍처(Zero Trust Architecture, ZTA)라고 부릅니다. 실무에서는 두 이름을 거의 가리지 않고 씁니다.

비유로 보는 제로 트러스트

사원증을 정문에서 한 번 찍으면 안의 모든 방이 열려 있는 회사 건물을 떠올려 봅시다. 정문만 지나면 사장실이든 금고든 막는 문이 없습니다.

호텔도 정문은 지킵니다. 하지만 로비에 들어왔다고 방이 열리지는 않습니다. 손님이 가진 카드키는 자기 방 하나만 엽니다. 제로 트러스트는 회사 건물을 호텔처럼 바꾸는 일입니다.

안쪽을 믿는 옛 방식

제로 트러스트 이전의 기본값은 경계 보안이었습니다. 회사 네트워크 둘레에 방화벽을 세워 바깥 요청을 거릅니다. 안쪽에서 오는 요청은 믿습니다. 성을 성벽과 해자로 지키는 모습에 빗대어 성과 해자 모델이라고도 부릅니다.

방화벽처럼 요청을 멈춰 세우고 들여보낼지 따지는 곳을 검사 지점이라고 부르겠습니다. 경계 보안에서는 검사 지점이 네트워크 입구 한 곳에만 있습니다. 입구를 지난 요청은 다시 검사받지 않습니다.

밖에서 일하는 사람은 VPN(Virtual Private Network, 가상 사설망)으로 들어옵니다. VPN 은 바깥 컴퓨터를 암호화된 통로로 사내망에 이어 붙입니다. 한 번 붙고 나면 그 컴퓨터도 안쪽에 있는 것처럼 대우받습니다.

안쪽을 믿을 때 생기는 구멍

첫째 구멍은 안쪽이 한 번 뚫린 뒤에 드러납니다. 피싱 메일 하나로 직원 노트북 한 대가 넘어가면 공격자는 이미 안쪽에 있습니다. 안쪽 서버들은 서로를 믿으니 그 노트북에서 오는 요청을 막지 않습니다.

공격자가 뚫은 한 대를 발판 삼아 옆 서버로 옮겨 가는 것이 측면 이동입니다. 경계 보안에는 이 이동을 막는 문이 거의 없습니다. 그래서 작은 침입 하나가 전체 유출로 번집니다.

둘째 구멍은 경계 자체가 흐려진 것입니다. 서버는 클라우드로 나갔습니다. 직원은 집과 카페에서 일합니다. 업무 도구는 다른 회사가 돌리는 서비스입니다. 지킬 대상이 한곳에 모여 있지 않으니 둘레에 벽을 세울 곳이 마땅치 않습니다.

검사 지점을 자원 바로 앞으로

마지막 검사 지점을 지난 요청들이 모두 같은 수준으로 믿어지는 구역을 암묵적 신뢰 구역이라고 부릅니다. 경계 보안에서는 사내망 전체가 하나의 암묵적 신뢰 구역입니다. 입구만 지나면 누구든 같은 대우를 받습니다.

제로 트러스트는 이 구역을 가능한 한 작게 줄입니다. 검사 지점을 네트워크 입구에 하나 두는 대신, 지키려는 자원 바로 앞으로 옮깁니다. 자원은 서버, 데이터베이스, 서비스가 내놓은 기능처럼 요청이 만지려는 대상을 말합니다.

아래 그림은 주문 서비스가 결제 서비스와 회원 데이터베이스를 부르는 같은 구성을 두 방식으로 그린 것입니다.

flowchart TD
    subgraph 경계["경계 보안"]
        O1["바깥 요청"] --> F["방화벽 · 검사 지점 하나"]
        F --> A1["주문 서비스"]
        A1 --> B1["결제 서비스"]
        A1 --> D1["회원 데이터베이스"]
    end
    subgraph 제로["제로 트러스트"]
        O2["모든 요청"] --> C1["검사 지점"]
        C1 --> A2["주문 서비스"]
        A2 --> C2["검사 지점"]
        C2 --> B2["결제 서비스"]
        A2 --> C3["검사 지점"]
        C3 --> D2["회원 데이터베이스"]
    end
    B1 ~~~ O2

위쪽은 방화벽을 지난 뒤로 검사 지점이 하나도 없습니다. 주문 서비스가 뚫리면 결제 서비스와 회원 데이터베이스까지 그냥 열립니다. 아래쪽은 화살표마다 검사 지점이 서 있어서, 주문 서비스가 뚫려도 다음 자원 앞에서 다시 확인합니다.

요청마다 확인하는 것

검사 지점이 요청 하나를 받으면 세 가지를 봅니다.

표에 네트워크 위치는 없습니다. 요청이 사내망 안에서 왔는지 바깥에서 왔는지는 통과시킬 근거가 되지 못합니다.

그렇다고 검사 지점이 요청이 어디서 왔는지를 아예 안 보는 것은 아닙니다. 접속한 나라나 시각 같은 값은 표의 세 가지를 판단할 때 곁들여 보는 보조 값으로 씁니다. 예를 들어 평소 쓰지 않던 나라에서 로그인하면 신원을 더 엄격하게 확인합니다.

신원을 확인하는 일이 인증입니다. 확인된 상대에게 무엇을 허락할지 정하는 일은 인가입니다. 제로 트러스트는 이 둘을 처음 한 번이 아니라 요청마다 합니다. 사용자의 신원은 비밀번호 하나로 끝내지 않고 휴대폰 확인 같은 둘째 수단을 더하는 다중 인증으로 확인하는 경우가 많습니다.

기기를 보는 까닭은 신원이 맞아도 기기가 이미 오염됐을 수 있어서입니다. 몇 달째 업데이트를 안 한 컴퓨터에서 온 요청은 계정이 맞아도 거절하거나 허락 범위를 좁힙니다. 기기가 얼마나 안전한 상태인지가 그 기기의 보안 태세입니다.

권한은 그 일을 하는 데 꼭 필요한 만큼만 줍니다. 이것이 최소 권한 원칙입니다. 뚫린 계정이 있어도 그 계정이 닿는 범위가 좁으면 피해도 그만큼 좁습니다.

판단이 도는 순서

검사 지점은 두 부품으로 나눠 둡니다. 하나는 요청을 막아 세우는 정책 시행 지점(Policy Enforcement Point)입니다. 다른 하나는 들여보낼지 계산하는 정책 결정 지점(Policy Decision Point)입니다. 이 아래로는 줄여서 시행 지점, 결정 지점이라고 씁니다.

둘로 나누는 까닭은 규칙을 한 곳에서 고치기 위해서입니다. 결정 지점의 규칙을 고치면 그 결정 지점에 묻는 모든 시행 지점에 같이 적용됩니다.

sequenceDiagram
    participant 요청자
    participant 시행 as 시행 지점
    participant 결정 as 결정 지점
    participant 자원
    요청자->>시행: 주문 내역을 달라
    시행->>결정: 이 요청을 들여보내도 되나
    Note over 결정: 신원 · 기기 · 권한을 따져 본다
    결정-->>시행: 들여보낸다
    시행->>자원: 요청을 넘긴다
    자원-->>시행: 주문 내역
    시행-->>요청자: 주문 내역

시행 지점은 스스로 판단하지 않습니다. 결정 지점의 답대로 요청을 넘기거나 끊기만 합니다. 판단이 시행 지점마다 흩어지면 규칙을 한 곳에서 고치려고 나눈 뜻이 사라지기 때문입니다.

그림은 허락이 난 경우입니다. 거절이 돌아오면 요청은 시행 지점에서 끊깁니다. 자원은 그 요청을 본 적이 없습니다.

허락의 범위와 수명

허락은 자원 하나, 접속 하나에만 걸립니다. 주문 서비스에 들어가도 된다는 허락이 결제 서비스 문을 열어 주지 않습니다. 결제 서비스 앞의 검사 지점이 처음부터 다시 확인합니다.

허락이 한 번 났다고 끝까지 가지도 않습니다. 접속 중에 기기에서 이상한 움직임이 보이거나 더 민감한 자원을 요청하면 다시 확인합니다. 로그인을 다시 하라는 창이 뜨거나 접속이 끊기는 것이 이때 일어나는 일입니다.

판단을 계속 고쳐 나가려면 재료가 필요합니다. 그래서 기기 상태, 네트워크 흐름, 요청 기록을 되도록 많이 모읍니다. 모은 기록으로 규칙을 고칩니다. 사고가 나면 이 기록이 되짚어 볼 감사 로그가 됩니다.

백엔드 서비스에서 보이는 모습

백엔드 개발자가 제로 트러스트를 가장 먼저 만나는 곳은 서비스끼리의 호출입니다. 예전에는 같은 사내망에 있는 서비스라면 인증 없이 불러도 됐습니다. 제로 트러스트에서는 사내 호출도 바깥 요청과 같은 확인을 거칩니다.

같은 자원에 들어온 요청 셋을 검사 지점이 어떻게 판단하는지 보면 이렇습니다.

판단(출발지=사내망, 신원=없음)    // 거부
판단(출발지=카페, 신원=확인됨)    // 허용
판단(출발지=사내망, 신원=확인됨)  // 허용

첫째 줄은 사내망에서 왔는데도 거부됐습니다. 둘째 줄은 카페에서 왔는데도 허용됐습니다. 답을 가른 것은 출발지가 아니라 신원입니다.

TLS(Transport Layer Security)는 통신을 암호화하는 규약입니다. 서버는 이 규약으로 인증서를 내밀어 자기 신원을 밝힙니다. 서비스끼리 서로의 신원을 확인할 때는 흔히 이것을 넓힌 상호 TLS를 씁니다. 상호 TLS 는 부르는 쪽도 인증서를 내밀게 해서 양쪽이 서로를 확인합니다.

암호화도 위치를 가리지 않습니다. 사내망 안이니 평문으로 보내도 된다는 가정을 버립니다. 안쪽을 오가는 통신이 엿보여도 내용이 새지 않게 하려는 것입니다.

서비스가 수십 개가 되면 서비스마다 인증서를 챙기는 일이 버거워집니다. 서비스 메시는 서비스 옆에 붙은 프록시가 인증서를 받아 두고 상호 TLS 연결을 대신 맺게 합니다. 애플리케이션 코드는 이 일을 모른 채 평소처럼 호출합니다.

사용자 요청에서는 토큰이 신원을 싣고 다닙니다. 토큰은 로그인에 성공한 사용자에게 내주는 서명된 증표입니다. 사용자는 요청마다 이것을 같이 보냅니다.

서비스들 앞에는 바깥 요청을 한곳에서 받아 나눠 주는 API 게이트웨이(Application Programming Interface 게이트웨이)가 흔히 섭니다. 게이트웨이가 토큰을 한 번 검사했다고 뒤의 서비스가 무조건 믿으면, 게이트웨이 뒤쪽이 다시 작은 경계 보안이 됩니다. 그래서 뒤의 서비스도 받은 토큰을 스스로 검사합니다.

쓰면 나빠지는 것

모든 요청에 검사가 붙으니 응답이 늦어집니다. 결정 지점에 묻는 왕복이 요청마다 하나씩 더 생깁니다. 답을 잠깐 캐시해 두면 왕복은 줄지만 그동안 바뀐 상태를 놓칩니다.

결정 지점이 멈추면 전부 멈춥니다. 모든 검사 지점이 결정 지점에 묻는 구조라 이 부품이 단일 장애 지점이 됩니다. 이를 막으려고 결정 지점은 여러 벌 띄워 둡니다.

신원과 기기를 관리하는 바탕이 먼저 있어야 합니다. 누가 누구인지, 어느 기기가 회사 것인지 모르는 조직은 규칙을 적을 재료가 없습니다. 서비스마다 인증서를 발급하고 기한 전에 바꾸는 일도 새로 생깁니다.

한 번에 바꿀 수 없습니다. 오래된 시스템은 네트워크 위치로 믿는 것을 전제로 짜여 있어서 하나씩 옮겨야 합니다. 대부분의 조직이 오랫동안 경계 보안과 제로 트러스트를 섞어서 굴립니다.

이름에서 생기는 오해

제로 트러스트는 제품 하나의 이름이 아닙니다. 설계 원칙의 묶음입니다. 여러 제품과 규칙이 모여 이 원칙을 이룹니다. 이름에 이 낱말을 붙인 제품을 들여와도 그 하나로 끝나지 않습니다.

방화벽을 걷어내자는 뜻도 아닙니다. 둘레의 벽은 남겨 둡니다. 다만 그 벽 안에 있다는 사실만으로는 믿지 않습니다. 여러 겹으로 막는 심층 방어와 함께 서는 생각입니다.

아무것도 믿지 않는다는 뜻도 아닙니다. 확인을 마친 요청은 믿고 통과시킵니다. 없애는 것은 확인 없이 주는 신뢰입니다.

잘 안 맞는 대상

익명 사용자를 받는 공개 서비스에는 이 원칙을 그대로 걸 수 없습니다. 누구나 보는 뉴스 페이지의 방문자에게는 확인할 신원이 없습니다. 제로 트러스트가 다루는 것은 조직 안의 사람과 서비스와 기기, 그리고 협력사처럼 관계가 맺어진 상대의 접근입니다.

관련 항목

제로 트러스트가 속하는 상위 분류

보안 엔지니어링 · 네트워크 보안 · 접근 제어 · 정보 보안

제로 트러스트 이전의 경계 방어 수단

경계 보안 · 방화벽 · VPN · DMZ · 배스천 호스트 · 사설망

제로 트러스트가 따르는 보안 원칙

최소 권한 · 심층 방어 · 기본 차단 · 권한 분리 · 공격 표면 · 신뢰 경계

요청마다 신원을 확인하는 수단

인증 · 인가 · 인증과 인가 · 다중 인증 · 싱글 사인온 · 신원 공급자 · OpenID Connect · OAuth 2.0 · SAML · JWT · 토큰

허락 규칙을 적는 접근 제어 방식

속성 기반 접근 제어 · 역할 기반 접근 제어 · 접근 제어 목록 · 관계 기반 접근 제어

검사 지점을 나눠 맡는 구성 요소

정책 시행 지점 · 정책 결정 지점 · 정책 엔진 · 정책 관리자

서비스 사이의 신원을 세우는 기술

상호 TLS · TLS · 인증서 · 공개 키 기반 구조 · 서비스 메시 · 사이드카 · SPIFFE · 서비스 계정

검사 지점을 자원 가까이 옮기는 구현 방식

마이크로세그멘테이션 · 소프트웨어 정의 경계 · ZTNA · SASE · API 게이트웨이 · 리버스 프록시 · 프록시

제로 트러스트를 내세운 제품

BeyondCorp · Cloudflare · Tailscale · Istio

제로 트러스트가 막으려는 공격

측면 이동 · 피싱 · 내부자 위협 · 자격 증명 탈취 · 권한 상승 · 랜섬웨어

판단의 재료를 모으는 감시 체계

감사 로그 · 보안 태세 · SIEM · 엔드포인트 탐지 및 대응 · 단말 관리

제로 트러스트를 불러온 환경 변화

클라우드 · 원격 근무 · SaaS · BYOD