제로 트러스트
Zero Trust
제로 트러스트란?
- '기본 신뢰 없음' 보안 원칙
- 내부·외부 없이 매번 검증
- '절대 신뢰 말고 항상 검증'
제로 트러스트를 도입하면 실제로 바뀌는 것은 장비가 아니라 권한을 주는 근거입니다. 예전에는 사내망에 들어왔다는 사실, VPN에 붙었다는 사실이 곧 권한이었습니다. 한 번 통과하면 재무 서버든 설계 서버든 목록이 다 보였고, 계정 하나가 털리면 그 목록이 통째로 넘어갔습니다. 제로 트러스트에서는 네트워크 위치가 여러 판단 재료 중 하나로 내려앉고, 요청 하나하나가 매번 다시 계산됩니다. 현장 체감으로는 'VPN만 켜면 전사가 열리던' 구조가 '업무에 필요한 앱 하나만 열리는' 구조로 바뀌는 일입니다.
설계 기준은 미국 NIST가 2020년에 낸 SP 800-207 문서에 정리돼 있습니다. 뼈대는 접근 여부를 판단하는 두뇌(정책결정지점)와 그 판단을 실제로 집행하는 관문(정책시행지점)을 분리하고, 모든 요청이 이 관문을 지나가게 만드는 것입니다. 여기에 세 가지가 붙습니다. 신원 관리(계정·역할·다중 인증), 기기 상태 확인(백신·패치·회사 자산 여부), 그리고 내부망을 잘게 쪼개 옆으로 번지지 못하게 막는 마이크로세그멘테이션입니다. VPN과 자주 비교되는데, VPN이 '망 안으로 넣어주는' 기술이라면 ZTNA는 앱 단위로만 연결을 터주는 기술이라는 점이 갈림길입니다.
현장에서 가장 많이 어긋나는 지점은 제로 트러스트를 '사서 설치하는 제품'으로 이해하는 것입니다. 솔루션을 깔고 전 직원에게 다중 인증을 걸면 끝난 줄 알지만, 정작 구멍은 다른 데 있습니다. 다중 인증을 지원하지 못하는 레거시 생산관리 시스템, 사람이 아니라 프로그램이 쓰는 서비스 계정, 급하다고 열어준 뒤 회수 절차가 없는 임시 권한이 그대로 남습니다. 반대로 최소 권한을 한 번에 과하게 조이면 결재와 조회가 막혀 현업이 멈추고, 예외 승인이 쏟아지다가 결국 예외가 기본값이 됩니다. 권한 회수 주기와 책임자를 정해두지 않은 채 기술부터 들이면, 불편만 늘고 위험은 그대로인 상태로 끝납니다.
포레스터의 존 킨더백이 2010년 'Zero Trust' 개념을 제시하며 정립됐고, 클라우드·원격근무 확산과 함께 표준으로 자리잡았습니다.
가상의 사례로 살펴보겠습니다. 임직원 1,200명 규모의 자동차 부품 제조사 A사는 국내 공장 2곳과 해외법인 3곳을 VPN 하나로 묶어 쓰고 있었습니다. 협력사 직원에게 발급한 계정이 외부로 유출돼 설계도면 서버 접근 시도가 탐지되면서, 6개월짜리 제로 트러스트 전환 과제가 시작됐습니다.
- 정보보안팀장이 계정 대장을 뽑아보니 활성 계정 3,140개 중 1년 넘게 안 쓴 것이 620개, 퇴사자 계정이 47개였습니다. "문 잠그기 전에 열쇠부터 세자"는 말로 첫 달을 썼습니다.
- CIO가 전 직원 다중 인증을 걸자 3교대 생산현장에서 "라인 세우고 휴대폰 인증하라는 거냐"는 항의가 올라왔고, 현장 공용 단말은 사내 지급 태블릿 기기인증으로 방식을 바꿨습니다.
- 설계도면·품질·ERP 세 시스템을 먼저 떼어내 협력사 계정에는 도면 뷰어 화면 하나만 열리게 했고, 다운로드는 팀장 결재 건에 한해 72시간짜리 임시 권한으로만 풀었습니다.
- 분기 권한 재검토에서 예외 승인 218건을 훑어 91건을 회수했습니다. 보안팀 과장이 "2년 전 프로젝트용으로 열어준 권한이 아직 살아 있었다"고 보고하면서 회수 규칙이 문서화됐습니다.
- 9개월 뒤 전사망 상시 접속 계정은 1,100개에서 180개로 줄었고, 권한 관련 감사 지적은 14건에서 2건으로, 헬프데스크 인증 문의는 초기 월 300건대에서 40건대로 내려앉았습니다.