VPN에 로그인한 직원이 업무와 무관한 시스템에도 접속할 수 있다면, 회사 네트워크 안으로 들어오는 절차와 개별 자원에 접근하는 권한이 충분히 구분되지 않은 상태일 수 있습니다. 계정이 탈취되거나 단말이 감염되면 넓게 열린 접근 범위가 피해를 키울 수 있습니다. Zero Trust는 이때 ‘어디에서 접속했는가’만으로 신뢰를 부여하지 않고, 어떤 주체가 어떤 자원을 어떤 조건에서 사용할 수 있는지 판단하는 보안 모델입니다.
Zero Trust는 내부망이라는 이유만으로 신뢰하지 않는 모델
NIST SP 800-207은 네트워크 위치나 자산 소유권만으로 사용자와 자산에 암묵적 신뢰를 부여하지 않는다고 설명합니다. 회사 사무실에서 회사 노트북을 사용하더라도 그것만으로 모든 업무시스템에 접근할 근거가 되지는 않습니다. 자원에 대한 세션을 만들기 전에 사용자·단말의 인증과 접근 권한을 확인하는 것이 출발점입니다. [1]
인증은 접속 주체가 누구인지 확인하는 과정이고, 인가는 그 주체가 해당 자원에서 무엇을 할 수 있는지 결정하는 과정입니다. 로그인에 성공했다는 사실과 인사자료 다운로드 권한이 있다는 사실은 다릅니다. 최소 권한은 허용 범위를 줄이는 원칙이며, Zero Trust는 여기에 단말 상태와 요청 맥락, 정책 집행과 재평가를 함께 연결합니다.
경계 보안과 달라지는 것은 접근 판단의 중심
경계 보안은 방화벽이나 원격접속 게이트웨이 등에서 네트워크 구역 사이의 통신을 통제합니다. 이것만으로 내부의 모든 접근을 정당화하면, 경계를 통과한 계정이나 단말이 다른 시스템으로 이동하는 일을 제한하기 어렵습니다. Zero Trust는 보호할 자원과 접근 요청을 중심으로 판단 범위를 더 세밀하게 만듭니다.
아래 표는 경계 통제에 주로 의존하는 구성과 Zero Trust를 지향하는 구성을 비교한 것입니다. 실제 경계 보안 환경도 내부 인증·망 분리·세부 권한을 적용할 수 있으므로, 모든 기존 시스템이 내부를 무조건 신뢰한다는 뜻은 아닙니다.
| 비교 기준 | 경계 통제에 주로 의존하는 구성 | Zero Trust를 지향하는 구성 |
|---|---|---|
| 판단의 중심 | 허용된 네트워크 구역과 통신 경로 | 주체·단말·대상 자원·요청 조건 |
| 내부망 접속 이후 | 넓은 접근 범위가 남을 수 있음 | 자원별로 허용 범위와 조건 확인 |
| 접근 허용 이후 | 초기 접속 판단에 의존하기 쉬움 | 정책과 신호 변화에 따라 재평가 |
| 사고 확산 억제 | 구역 간 차단 규칙에 크게 의존 | 세분화된 접근과 권한 제한을 함께 적용 |
| 기존 장비의 역할 | 경계 통제 수행 | 경계 통제를 유지하며 자원별 통제와 연계 |
따라서 Zero Trust 도입은 방화벽을 없애는 작업과 같지 않습니다. VPN도 접속 경로의 일부로 남을 수 있습니다. 확인할 대상은 제품 이름보다 ‘이 경로를 통과하면 어디까지 접근할 수 있는가’입니다.
접근 결정과 집행이 연결되는 구조
NIST의 구현 가이드는 정책 엔진(PE), 정책 관리자(PA), 정책 집행 지점(PEP)을 핵심 논리 구성요소로 구분합니다. PE는 접근 허용·거부·취소를 판단하고, PA는 그 결정을 실행하도록 PEP에 지시하며, PEP는 실제 연결을 허용·감시·종료합니다. 이 명칭마다 별도 장비를 한 대씩 구매해야 한다는 의미는 아닙니다. 하나의 서비스가 여러 역할을 수행하거나 여러 시스템이 나누어 구현할 수 있습니다. [2]
예를 들어 직원이 문서시스템에 접속하면 사용자 계정과 그룹, 단말의 관리 상태, 요청한 자원의 민감도 같은 정보를 정책 판단에 사용할 수 있습니다. 허용된 요청은 집행 지점을 통해 해당 자원에 연결되고, 관련 상태가 바뀌면 정책과 구현 범위에 따라 접근을 다시 평가합니다.
‘지속적인 검증’을 모든 클릭마다 비밀번호를 입력하는 절차로 이해하면 곤란합니다. 사용자에게 보이는 재인증 외에도 세션과 단말 상태를 평가하는 방법이 있습니다. 어떤 신호를 얼마나 자주 확인하고 언제 세션을 중단할지는 정책과 연동 기능에 달려 있으며, 모든 제품이 상태 변화를 즉시 반영한다고 가정해서는 안 됩니다. [2]
같은 계정도 단말 상태에 따라 결과가 달라지는 가상 예시
외부 협력사 직원이 회사의 계약문서 시스템을 사용하는 상황을 가정해 보겠습니다. 회사가 ‘지정 계정, 승인된 관리 단말, 해당 계약 폴더’라는 조건을 정했다면, 인증에 성공해도 조건에 맞지 않는 단말에서는 접근을 제한할 수 있습니다. 이는 설명을 위한 가상 정책이며 모든 회사에 동일하게 적용되는 필수 규칙은 아닙니다.
처음에는 조건을 충족한 노트북이라도 보안 프로그램이 중지되거나 관리 상태가 해제되면 판단 근거가 달라집니다. 연동된 상태 정보와 세션 제어 기능이 이를 지원한다면, 정책에 따라 재인증·접근 제한·세션 종료 등을 적용할 수 있습니다. 이때 사용자 계정이 같다는 이유만으로 기존 허용을 계속 유지하지 않는 것이 핵심입니다.
다만 문서시스템 앞의 접근 통제로 다운로드 이후의 파일 이용까지 모두 관리할 수 있는 것은 아닙니다. 읽기·다운로드 권한, 데이터 분류와 반출 통제는 애플리케이션 및 데이터 보호 기능과 함께 설계해야 합니다. 접속 통제와 데이터 사용 통제의 범위를 구분해야 과도한 기대를 피할 수 있습니다.
도입은 제품 목록보다 보호할 업무 한 가지에서 시작
처음부터 전체 시스템을 한꺼번에 바꾸기보다, 외부 협력사 접속이나 관리자 원격접속처럼 범위가 분명한 업무를 선정하는 편이 실행 계획을 세우기 쉽습니다. 다음 순서는 이 글에서 제안하는 실무용 점검 순서이며, 특정 표준의 의무 절차는 아닙니다.
- 보호할 자원과 행위를 정합니다. ‘문서시스템’에서 한 단계 더 나아가 조회·다운로드·관리 기능을 구분합니다.
- 접근 주체와 경로를 조사합니다. 사람 계정뿐 아니라 서비스 계정, 직접 접속 주소, 배치 작업도 포함합니다.
- 정책에 쓸 신호를 확인합니다. 계정·단말 정보의 출처, 갱신 주기, 누락 시 처리 방식을 정합니다.
- 집행 지점을 점검합니다. 정상 경로에서 차단해도 별도 주소나 기존 연결로 자원에 접근할 수 있다면 통제 범위가 불완전합니다.
- 정상·거부·상태 변화 사례를 검증합니다. 허용 로그뿐 아니라 거부 이유, 반영 지연, 기존 세션 처리 결과를 확인합니다.
CISA의 성숙도 모델은 신원, 단말, 네트워크, 애플리케이션·워크로드, 데이터의 다섯 축과 이를 가로지르는 가시성·분석, 자동화·오케스트레이션, 거버넌스를 다룹니다. 특정 접속 제품 하나만으로 전체 범위를 완성했다고 판단하지 않도록 돕는 점검 틀로 활용할 수 있습니다. 미국 연방기관을 위한 모델을 국내 모든 기업의 법적 의무로 해석해서는 안 됩니다. [3]
실무자 관점: 예외와 장애 처리가 통제의 지속성을 결정
계정과 단말 정보가 부정확한 상태에서 차단 규칙을 강화하면 정상 업무가 막힐 수 있습니다. 단말 상태 수집 실패를 실제 보안 위반과 같은 것으로 처리할지도 먼저 정해야 합니다. 모니터링이나 제한된 시범 적용으로 영향을 확인한 뒤 집행 범위를 늘리는 접근을 권합니다.
예외가 필요하다면 승인자, 사유, 허용 자원, 가능한 행위, 종료 시점을 기록해야 합니다. 협력사 단말이 조건을 충족하지 못한다는 이유로 내부망 전체를 열어 주면 세밀한 정책을 만든 효과가 약해집니다. 예외 기간이 끝난 뒤 권한과 활성 세션이 어떻게 처리되는지도 검증 대상으로 삼아야 합니다.
인증 서비스나 정책 시스템에 장애가 났을 때도 같은 문제가 생깁니다. 전면 허용과 전면 차단 중 하나를 무조건 정답으로 삼기보다, 업무 위험에 맞춰 제한된 비상 접근과 승인·감사 절차를 설계해야 합니다. 운영 지표도 제품 설치 대수보다 보호 대상의 정책 적용 범위, 남아 있는 우회 경로, 예외 만료 처리, 세션 제어의 실제 동작을 중심으로 잡는 편이 유용합니다.
결론: 내부 접속 성공과 자원 사용 허가를 분리
Zero Trust의 적용 여부를 살펴보려면 ‘VPN을 통과했는가’ 다음에 어떤 검증이 이어지는지 확인하면 됩니다. 접속한 계정과 단말이 특정 자원에서 어떤 행위를 할 수 있는지, 상태가 바뀌었을 때 그 허용을 어떻게 조정하는지가 판단 기준입니다.
첫 적용 대상에서는 허용 조건, 집행 지점, 우회 경로, 예외 만료, 장애 대응을 한 묶음으로 검증해 보십시오. 기존 경계 보안을 활용하면서도 불필요하게 넓은 접근을 줄일 수 있어야 실제 운영의 변화로 이어집니다.