📚 지식 노트

경계 보안의 한계: 성벽 하나에 모든 것을 걸면

오랫동안 회사 보안은 성과 해자의 모양이었다. 바깥과 안쪽 사이에 방화벽이라는 성벽을 세우고, 성벽 안쪽 네트워크에 있는 사람과 기기는 믿는다. 사무실에 앉아 있거나 VPN으로 들어왔다면 내부 서버에 거의 막힘없이 닿는다. 이것을 경계 보안(perimeter security)이라 한다. 방화벽 자체는 네트워크 보안 노트에 있다.

약점은 두 가지다. 첫째, 성벽은 한 번만 넘으면 된다. 피싱, 패치가 늦은 서버, 도난당한 VPN 계정 중 하나로 안에 들어온 공격자는 안쪽 기기의 신분을 빌려 다른 서버로 옮겨 간다. 이것을 옆으로 이동(lateral movement)이라 하고, 큰 침해 사고는 대개 첫 침입보다 이 단계에서 피해가 커진다. 둘째, 성벽 자체가 흐려졌다. 직원은 집과 카페에서 일하고, 업무 앱은 사내 서버실이 아니라 클라우드와 SaaS에 있으며, 협력사와 개인 기기도 드나든다. 지킬 "안쪽"이 한 장소에 모여 있지 않으니 성벽을 어디에 세울지부터 분명하지 않다.

한국의 공공기관과 금융회사가 오래 써 온 망분리도 이 성벽을 두 겹으로 쌓은 경계 보안의 한 갈래다. 업무망과 인터넷망을 아예 떼어 첫 번째 약점은 크게 줄이지만, 안쪽을 믿는 구조와 두 번째 약점(클라우드·SaaS·AI를 쓰기 어려움)은 오히려 커진다. 방식과 규제의 흐름, 데이터 등급에 따른 통제로 바꾸는 국가 망 보안체계(N2SF)는 네트워크 보안 노트의 망분리 절에 있다.

제로 트러스트(zero trust)는 여기서 출발한다. 네트워크 위치로 신뢰를 주지 않고, 요청 하나하나를 그 자리에서 확인한다. 이름은 2010년 무렵 업계 분석가들이 퍼뜨렸고, 표준 정의는 미국 표준기술연구소(NIST)가 2020년에 낸 NIST SP 800-207(Zero Trust Architecture)이 가장 널리 쓰인다.

원칙: 믿지 말고 확인하라, 그리고 이미 뚫렸다고 가정하라

제로 트러스트를 한 줄로 줄이면 "결코 믿지 말고 항상 확인하라"(never trust, always verify)다. 여기서 "믿지 않는다"는 말은 사용자를 의심한다는 뜻이 아니다. 접속한 장소나 지난번 로그인 같은 암묵적 신뢰를 근거로 삼지 않고, 판단에 필요한 증거를 요청마다 다시 본다는 뜻이다.

• 항상 확인: 사내망이든 인터넷이든 같은 기준으로 인증하고 인가한다. 통신은 위치와 상관없이 늘 암호화한다.
• 요청마다 최소 권한: 계정 하나에 넓은 권한을 오래 주지 않고, 지금 이 요청에 필요한 만큼만 이 세션 동안만 준다. 최소 권한 자체는 보안의 기초 노트에 있다.
• 침해 가정(assume breach): 이미 누군가 안에 들어와 있다고 보고 설계한다. 그래서 한 곳이 뚫려도 번지는 범위를 좁히고, 모든 접근을 기록해 이상을 빨리 찾는다.

SP 800-207은 이를 일곱 가지 기본 원칙(tenet)으로 풀어 쓴다. 요지를 옮기면 이렇다. 데이터와 서비스는 모두 보호할 자원으로 본다. 통신은 네트워크 위치와 상관없이 보호한다. 접근은 세션 단위로 주고, 한 자원에 받은 허락이 다른 자원으로 이어지지 않는다. 허용 여부는 사용자 신원, 기기 상태, 행동과 환경 같은 속성을 보는 동적 정책으로 정한다. 조직은 자기 기기들의 무결성과 보안 상태를 계속 살핀다. 인증과 인가는 접근 전에 엄격하게, 그리고 계속 다시 한다. 자산과 네트워크, 통신 상태를 최대한 모아 정책을 다듬는 데 쓴다.

영국 국가사이버보안센터(NCSC)의 제로 트러스트 아키텍처 설계 원칙도 같은 방향이다. 그중 "자기 네트워크를 포함해 어떤 네트워크도 믿지 말라"는 원칙이 제로 트러스트가 경계 보안과 갈라지는 지점을 가장 짧게 보여 준다.

구조: 판단하는 곳과 막는 곳을 나눈다

SP 800-207은 제로 트러스트를 논리적인 부품 몇 개로 설명한다. 요청이 지나가는 길목에는 정책 집행 지점(PEP, Policy Enforcement Point)이 서서 연결을 열고 닫는다. PEP는 스스로 판단하지 않고 정책 결정 지점(PDP, Policy Decision Point)에 묻는다. PDP는 다시 둘로 나뉜다. 정책 엔진(PE)은 허용할지 정하고, 정책 관리자(PA)는 그 결정을 PEP에 전해 세션을 열거나 닫게 하고, 세션에 쓸 토큰 같은 자격 증명을 만든다.

정책 엔진이 보는 재료는 대략 다섯 갈래다. 누가 요청했고 얼마나 강하게 인증했는가(신원), 어떤 기기로 왔고 그 기기가 관리되고 패치되어 있는가(기기 상태), 평소와 같은 곳·같은 시간인가(위치와 시간), 위협 정보나 비정상 행동 탐지가 경고를 냈는가(위험 신호), 그리고 요청한 자원이 얼마나 민감한가다. 같은 사람도 사내 위키는 바로 열리지만 급여 데이터는 더 강한 인증을 한 번 더 요구받는 식으로, 판단은 자원마다 다르게 나온다.

판단과 집행을 나누면 좋은 점이 있다. 정책을 한 곳에서 바꾸면 모든 길목에 같이 적용되고, PEP는 단순하게 유지된다. 반대로 PDP는 모든 접근이 지나는 길이 되므로, 멈추면 업무가 멈추고 뚫리면 모든 문이 열린다. PDP를 여러 벌로 두고 그 자체를 가장 엄격하게 보호하는 이유다.

신원 중심 접근: 네트워크 대신 사용자와 기기를 본다

위치를 믿지 않는다면 무엇을 믿는가. 제로 트러스트의 답은 신원(identity)이다. 사람의 계정, 기기의 인증서, 서비스의 신원이 판단의 중심이 된다. 그래서 인증이 약하면 제로 트러스트 전체가 약하다. 비밀번호 하나로 신원을 확인하면 피싱 한 번에 신원이 통째로 넘어가므로, 피싱에 강한 다중 인증과 패스키가 사실상 출발 조건이다. 자세한 내용은 인증과 인가 노트에 있다.

가장 잘 알려진 사례는 구글의 BeyondCorp다. 구글은 2011년 무렵부터 직원이 VPN 없이 믿을 수 없는 네트워크에서 일할 수 있게 사내 접근 방식을 바꿨고, 2014년 논문 BeyondCorp: A New Approach to Enterprise Security로 그 구조를 공개했다. 핵심은 세 가지다. 접속한 네트워크로 접근을 정하지 않는다. 사용자와 기기에 대해 아는 것으로 접근을 준다. 모든 접근은 인증되고 인가되고 암호화된다. 사내망도 인터넷과 똑같이 취급하므로 사무실 자리에 앉아도 특권이 없다.

이때 앱 앞에 서는 PEP가 신원 인식 프록시(identity-aware proxy)다. 모든 내부 앱을 이 프록시 뒤에 두고, 요청이 오면 로그인한 사용자와 기기 정보를 확인한 뒤 앱별 정책에 맞을 때만 넘긴다. 구글이 2016년에 쓴 BeyondCorp: The Access Proxy가 이 부분을 다룬다. 프록시를 하나로 모으면 인증, 로그, 정책이 한곳에 모이는 대신 프록시가 꼭 지나야 하는 길이 되므로, 앞 절의 PDP처럼 가용성과 보호에 공을 들여야 한다.

기기 상태와 지속 검증: 한 번 확인으로 끝나지 않는다

맞는 사람이 맞는 비밀번호를 넣어도, 그 사람이 쓰는 노트북이 악성코드에 감염돼 있다면 요청을 믿을 수 없다. 그래서 제로 트러스트는 기기 상태(device posture)를 함께 본다. 회사가 관리하는 기기인지(기기 인증서나 관리 도구 등록), 운영체제와 브라우저가 최신인지, 디스크 암호화와 화면 잠금이 켜져 있는지, 보안 에이전트가 살아 있는지 같은 것이다. 구글은 BeyondCorp에서 기기 목록(inventory)을 만들고 상태에 따라 기기의 신뢰 등급을 매겼다.

확인은 로그인할 때 한 번으로 끝나지 않는다. 세션 도중에도 신호가 바뀌면 다시 판단하는 것을 지속 검증(continuous verification)이라 한다. 기기의 보안 기능이 꺼지거나, 몇 분 사이에 먼 나라에서 같은 계정으로 접속하거나, 평소 안 보던 데이터를 한꺼번에 내려받기 시작하면 위험 점수가 올라간다. 그에 따라 다시 인증을 요구하거나, 읽기만 허용하거나, 세션을 끊는다. 이처럼 상황에 맞춰 요구를 바꾸는 것을 적응형(adaptive) 접근이라 한다.

이를 받쳐 주는 장치가 짧게 사는 자격 증명이다. 몇 달씩 유효한 API 키나 몇 주짜리 세션 대신 몇 분에서 몇 시간짜리 토큰과 인증서를 쓰면, 새어 나가도 쓸 수 있는 시간이 짧고 다시 받을 때마다 판단이 새로 이뤄진다. 다만 토큰이 짧아도 만료 전에는 유효하므로, 급할 때는 토큰 폐기나 세션 강제 종료 같은 즉시 끊는 수단이 따로 있어야 한다. 확인이 잦아지면 사용자를 귀찮게 하기 쉬우니, 위험이 낮을 때는 조용히 넘기고 위험이 오를 때만 사용자에게 묻는 균형이 필요하다.

마이크로세그멘테이션: 뚫려도 번지지 않게

경계 보안이 막는 것은 바깥에서 안으로 들어오는 남북(north-south) 방향 통신이다. 하지만 침입 뒤의 옆으로 이동은 서버와 서버 사이의 동서(east-west) 통신으로 일어난다. 마이크로세그멘테이션(microsegmentation)은 네트워크를 서비스나 작업 단위의 작은 칸으로 나누고, 칸 사이에는 꼭 필요한 통신만 연다. 이렇게 하면 한 곳이 뚫렸을 때 피해가 미치는 범위, 곧 폭발 반경(blast radius)이 줄어든다.

그림의 오른쪽에서도 회원 DB까지는 닿는다. 웹 서버가 API를 부르고 API가 DB를 읽는 것은 업무에 필요한 길이기 때문이다. 그래서 세그멘테이션만으로 끝내지 않고, 그 길 위에서도 서비스끼리 서로의 신원을 확인하고 요청마다 인가한다. API는 웹 서버가 보낸 요청이라도 "이 사용자의 이 데이터"에 대한 것인지 다시 따진다.

칸을 나누는 방법은 VLAN과 방화벽 규칙 같은 네트워크 수단에서, 서버마다 도는 호스트 방화벽, 그리고 IP 주소 대신 서비스 신원으로 규칙을 쓰는 방식으로 옮겨 가고 있다. 컨테이너처럼 주소가 수시로 바뀌는 환경에서는 주소 규칙이 금방 낡기 때문이다. NIST는 클라우드 네이티브 환경에 맞춘 지침으로 NIST SP 800-207A(2023)를 냈다. 서비스 메시가 서비스마다 신원을 주고, 서비스 사이 통신을 상호 TLS로 암호화하며 요청 단위 정책을 거는 구조를 다룬다.

ZTNA와 VPN: 망에 들이는가, 앱에 잇는가

원격 접속의 오랜 답은 VPN이었다. VPN은 바깥의 노트북을 사내망 안으로 들여보내는 터널이고, 동작 원리는 네트워크 보안 노트의 VPN 절에 있다. 문제는 터널이 끝나는 곳이 사내망 전체라는 점이다. 한 번 인증하면 망 안의 많은 서버가 네트워크로 보이고, VPN 계정이나 장비가 뚫리면 공격자도 같은 범위를 얻는다. 실제로 VPN 장비의 취약점은 오랫동안 침입의 흔한 입구였다.

ZTNA(Zero Trust Network Access)는 사용자를 망에 들이지 않고 앱 하나에 잇는다. 브로커나 프록시가 요청마다 신원과 기기를 확인하고, 허락한 앱으로 가는 연결만 만든다. 앱은 대개 바깥에서 들어오는 연결을 받지 않고 브로커 쪽으로 먼저 연결을 걸어 두므로, 인터넷에서 앱의 주소가 보이지 않는다.

둘이 모든 면에서 갈리지는 않는다. 개인정보를 지키려 쓰는 개인용 VPN은 목적이 다르고, ZTNA도 내부적으로는 암호화된 터널을 쓴다. 또 오래된 업무 시스템 가운데는 앱 단위로 나누기 어려운 것이 있어, 실제 조직은 한동안 VPN과 ZTNA를 함께 운영하며 앱을 하나씩 옮기는 경우가 많다.

도입 단계: 제품이 아니라 여정이다

제로 트러스트는 한 번에 사서 끝나는 제품이 아니라, 기존 시스템을 단계적으로 바꿔 가는 설계 방향이다. 진척을 재는 자로 가장 많이 쓰이는 것이 미국 사이버보안·인프라보안청(CISA)의 제로 트러스트 성숙도 모델(Zero Trust Maturity Model)이다. 2023년 4월에 나온 2.0판이 현재 판이다. 미국 연방 기관을 위해 만들었지만 다른 조직도 참고하도록 공개되어 있다.

• 다섯 기둥: 신원(Identity), 기기(Devices), 네트워크(Networks), 앱과 워크로드(Applications and Workloads), 데이터(Data).
• 세 공통 능력(cross-cutting capabilities): 가시성과 분석(Visibility and Analytics), 자동화와 오케스트레이션(Automation and Orchestration), 거버넌스(Governance). 기둥 하나에 속하지 않고 모두에 걸친다.
• 네 단계: 전통(Traditional, 수작업·정적 정책·암묵적 신뢰), 초기(Initial, 자동화와 기둥 간 연동의 시작), 고급(Advanced, 기둥을 잇는 중앙 관리와 위험 기반 판단), 최적(Optimal, 완전 자동화와 동적 최소 권한).

실제로는 작은 곳부터 시작한다. 첫째, 지킬 자원과 그 자원에 접근하는 사람·기기·서비스를 목록으로 만든다. 무엇이 있는지 모르면 정책을 쓸 수 없다. 둘째, 신원을 한곳으로 모으고(단일 로그인) 피싱에 강한 다중 인증을 먼저 깐다. 미국 정부의 연방 제로 트러스트 전략인 OMB M-22-09(2022)도 피싱 저항 다중 인증을 맨 앞에 둔다. 셋째, 기기 목록과 상태 확인을 붙인다. 넷째, 중요한 앱 몇 개를 접근 프록시나 ZTNA 뒤로 옮기고 VPN 의존을 줄인다. 다섯째, 서버 사이 통신을 나누고 로그를 모아 정책을 다듬는다.

여러 제품을 실제로 엮어 보는 예시가 필요하면 NIST 산하 국가 사이버보안 우수 센터(NCCoE)가 업계와 함께 만든 실천 지침 NIST SP 1800-35(2025)가 있다. 어느 단계든 원칙은 같다. 위치가 아니라 신원과 상태로, 넓게가 아니라 요청 하나만큼, 그리고 이미 뚫렸다고 보고 설계한다.

한국에서는 과학기술정보통신부와 한국인터넷진흥원(KISA)이 2023년 7월 제로트러스트 가이드라인 1.0을, 2024년 12월 도입 절차와 성숙도 평가를 구체화한 2.0을 냈다. 2.0은 식별자, 기기·엔드포인트, 네트워크, 시스템, 애플리케이션·워크로드, 데이터의 여섯 핵심 요소마다 기존·초기·향상·최적화 네 단계로 성숙도를 매기게 해, 위 CISA 모델과 뼈대가 닮았다. 공공 부문의 망분리 개편(N2SF)도 정식판에서 "항상 검증, 최소 권한"을 보안 대책의 기준으로 넣었다.