글을 쓰기 위해 무언가를 조사하다 보면, 고구마 줄기에 연결된 고구마처럼 새로운 지식이 딸려 나와서 처음에 단순하게 생각했던 것이 사실은 쉽게 말하기 어려운 주제가 되어버리곤 합니다.
지금 적으려는 제로 트러스트(Zero Trust) 역시 그 개념은 단순하지만 구현 방법은 그리 단순하지 않습니다. 현대 정보 시스템의 복잡성과 그것을 지키려는 전략이 함께 복잡해지는 게 아닐까 싶습니다.
제로 트러스트라는 거대한 고구마 줄기를 캐다 보니 썸네일만 거창해진 게 아닌가 싶어 쑥스럽네요. 기술적 깊이보다는 제 일상과 고민의 궤적을 가볍게 담아보았으니 편하게 읽어주시면 감사하겠습니다!
Zero Trust의 정의
가장 명확하고 완벽한 설명보다는, 오늘의 제가 이해하고 있는 바를 편하게 적어보겠습니다.
제로 트러스트는 보안 분야에서 나온 용어로, '신뢰' 자체가 취약점이라는 문제의식에서 출발한 철학입니다. 이를 구현한 제로 트러스트 아키텍처(Zero Trust Architecture)를 중심으로 설명하는 것이 좀 더 확실할 것 같습니다.
실제 적용의 계기: Google BeyondCorp
2009년 구글은 Operation Aurora 사이버 공격을 받은 후 'BeyondCorp'라는 내부 프로젝트를 시작했다고 합니다. 목표는 VPN 없이도 직원들이 안전하게 원격 근무를 할 수 있게 하는 것이었습니다. 2014년 구글이 이를 공개하면서 제로 트러스트는 "그럴듯하지만 비현실적인 아이디어"에서 당장 회사에 적용해야 하는 "긴급한 우선순위"로 위상이 바뀌었습니다.
사내 No-VPN 캠페인
코로나 팬데믹이 한창이던 시절, 우리는 사내 리소스에 접근하기 위해 집에서 매일 VPN을 켜고 일했습니다. 그러다 시간이 흘러 사내 보안팀에서 많은 서비스를 VPN 없이도 사용할 수 있도록 변경하기 시작했고, 상당수 서비스가 VPN이 아닌 형태로 인증하여 접속할 수 있게 되자 'VPN을 사용하지 말자'는 캠페인을 벌이기도 했습니다.
보안에 별 관심이 없던 저는 왜 그런 일을 하는지 알지 못했지만, 그게 바로 제로 트러스트 아키텍처에서 출발한 변화였습니다. 제로 트러스트 아키텍처는 다른 말로 'Perimeterless Security', 즉 '경계 없는 보안'이라고 부릅니다.
VPN이라는 것이 외부로부터 사내 네트워크 장비를 효과적으로 지켜준다고 생각할지 모르지만, 반대로 VPN이 있기 때문에 내부 네트워크 장비들은 상대적으로 보안에 취약한 상태로 노출될 수 있습니다. VPN 방식 자체가 안과 밖을 구분하고, 일단 안으로 들어온 사람은 신뢰하는 방식으로 보안을 유지하기 때문입니다. 제로 트러스트는 이러한 '경계'에 기반한 보안에 의문을 던집니다.
대신 개별 서비스마다 인증을 요구하는 방식으로 전환합니다. 'No-VPN'이라고 불렀지만, 기술적으로는 Identity-Aware Proxy 같은 중간 계층을 거치므로 넓은 의미에서 VPN과 유사합니다. 핵심적인 차이는 "네트워크 경계 안에 들어왔으니 신뢰한다"가 아니라 "매 접근마다 신원을 확인한다"는 철학에 있습니다. 또한 경계 기반 VPN 사용을 줄이면, 외부에 있는 직원의 장비가 사내 네트워크 전체에 연결되는 상황 자체를 피할 수 있습니다.
가정에서의 적용
집에서 돌리는 리눅스 서버에 접근할 때도 비슷한 선택지가 있습니다. 라우터에서 VPN 서비스를 실행하고 여기에 접속하여 서버에 들어가는 방식은, 한 번 연결되면 리눅스 서버뿐 아니라 내부 네트워크의 다른 장치들까지 노출시킵니다.
반면, Tailscale과 Termius를 세팅하여 외부에서 리눅스 서버에 접근하는 방식이 있습니다. Tailscale도 기술적으로는 mesh VPN이지만, 네트워크 전체가 아닌 개별 디바이스 단위로 접근을 제어합니다. '네트워크 안에 들어왔으니 신뢰한다'는 가정을 제거했기 때문에 제로 트러스트 철학에 더 가깝습니다.
물론 리눅스 장비에 SSH로 접근한다는 것 자체가, 내부 네트워크에 있는 그 장비로 할 수 있는 일이 무궁무진하다는 뜻이기도 합니다. 정말 보안을 생각하는 사람이라면 이 지점에서도 신뢰를 어떻게 줄일지 고민해야 할 것입니다. 더 나아가 mesh VPN을 구성하는 Tailscale과 Termius에 보안 문제가 생겼을 때는 어떻게 할지도요.
이런 보안 아키텍처를 설계할 때 서비스의 평판에 의존할까요? 아니면 위험도를 확률적으로 측정하는 도구가 있을까요? 보안을 몰라서 거기까지 궁금합니다만, 여기서 멈출게요.
PostgreSQL RLS와 Zero Trust
어제 적은 글에서 다뤘듯, Multi-tenant SaaS를 Pool Model로 효율적으로 구현할 때, 기존 방식은 애플리케이션이 WHERE tenant_id = ...를 잘 붙여줄 것이라고 '신뢰'했습니다. 하지만 PostgreSQL의 Row Level Security(RLS)는 DB 엔진이 직접 검증하므로, 애플리케이션에 대한 무조건적인 신뢰 없이도 보안을 유지할 수 있습니다. 어떤 경로로 접근하든 데이터 자체가 접근 권한을 강제한다는 점에서 제로 트러스트의 훌륭한 구현 사례 중 하나라고 생각합니다.
AI 시대의 보안
또한 많은 애플리케이션 코드를 AI가 생성하고 있는 시대인 만큼, PostgreSQL RLS와 같은 다양한 레이어에서 제로 트러스트로 보안을 보장하는 구조가 더욱 필요해지고 있습니다. 실제로 RLS의 필요성을 다룬 어떤 블로그 글에서는 'AI가 생성하는 코드'를 RLS 도입의 주요한 이유로 꼽기도 하더군요.
결국 제로 트러스트는 특정 기술이 아니라, '아무도 믿지 않되, 검증된 절차는 보장한다'는 철학의 실천입니다. AI가 코드를 짜고 에이전트가 팀원으로 일하는 시대에, 이 철학은 선택이 아닌 필수적인 설계 원칙이 될 것입니다. 보안은 이제 전문가만의 영역이 아니라, 견고한 시스템을 만들고자 하는 모든 개발자의 기본 소양이 되어가고 있습니다.
