ZTNA(제로 트러스트 네트워크 액세스) 란?

ZTNA의 정의?

ZTNA(Zero Trust Network Access)는 사용자와 디바이스를 신뢰하지 않고, 접근 요청이 발생할 때마다 사용자가 누구인지, 어떤 디바이스에서 접속하는지, 어떤 업무 시스템을 요청하는지, 해당 접근이 정책에 맞는지를 검증한 뒤 필요한 애플리케이션에만 접근을 허용하는 보안 모델이다.

기존 네트워크 보안은 VPN과 방화벽을 중심으로 운영되며 방화벽은 외부와 내부 네트워크의 경계를 보호하고, VPN은 외부 사용자가 내부 네트워크에 접속할 수 있는 암호화된 통로를 제공했다. 이와 같은 보안 모델은 네트워크 경계가 명확한 환경에서 효과적이었으나 기업 환경은 바뀌었으며 업무 시스템은 온프레미스뿐 아니라 클라우드와 SaaS로 확장됐고, 사용자는 사무실 밖에서도 여러 업무 애플리케이션을 통해 접근한다. 이로 인해 네트워크 경계는 흐려지고, 보안팀은 더 이상 사용자가 내부 네트워크에 접속했는지 만으로 접근을 판단하기 어려워졌다.

기존 네트워크 보안 모델의 한계

기존 네트워크 보안 모델은 방화벽과 VPN을 중심으로 내부와 외부의 경계를 구분하고 정상적인 경로로 접근한 사용자를 신뢰하는 방식이다. 방화벽은 네트워크 경계에서 트래픽을 통제하고, VPN은 외부 사용자가 내부 시스템에 안전하게 접속하도록 지원한다. 이와 같은 방식은 기업 네트워크의 내부와 외부 경계가 명확한 환경에서 효과적이었지만 클라우드, SaaS, 온프레미스 시스템에 동시에 접근하는 업무 환경에서는 네트워크 경계만으로 모든 접근을 세밀하게 판단하기 어렵다.

기존 보안 모델은 인증 이후에도 보안 취약점이 존재한다. 기존 방화벽은 네트워크 접근한 사용자를 신뢰하기 때문에 계정 탈취와 같은 방법으로 내부에 접속을 성공한다면 내부에서 활동을 통제하는 것이 어렵다. 이 때문에 보안팀은 로그인을 했는지가 아니라 어떤 디바이스로 접속했는지, 어떤 애플리케이션에 접근하는지, 해당 접근이 업무 목적에 맞는지도 확인해야 한다. 더 나아가 한번 인증했다고 끝나는 것이 아닌, 지속적으로 검증해야 하며 네트워크 전체가 아니라 필요한 애플리케이션에만 연결하도록 설계한다.

웨비나

[AhnLab ISF 2025] ZTNA 기반 네트워크 보안 플랫폼의 현재와 미래

Zero Trust 기반 접근 제어

Zero Trust는 모든 접근을 신뢰하지 않는 보안 원칙으로 접근 요청이 발생할 때마다 조건을 확인하고, 필요한 범위 안에서만 권한을 부여한다.

ZTNA는 이 원칙을 네트워크 접근 제어에 적용한다. 사용자가 특정 업무 시스템에 접속하려고 하면, 사용자 신원을 확인하고 디바이스 상태, 접속 위치, MFA 적용 여부, 사용자 역할, 요청한 애플리케이션도 함께 검토한다. 이를 통해 조건을 충족하면 접근을 허용하고, 조건이 맞지 않으면 차단하거나 추가 인증을 요구할 수 있다.

ZTNA의 핵심은 사용자를 네트워크 전체에 연결하지 않고, 정책으로 허용된 애플리케이션과 리소스에만 접근하도록 제한하는 데 있다. 예를 들어 재무 담당자가 회계 시스템에 접근해야 한다면 ZTNA는 회계 시스템 접근만 허용하며 사용자가 접근 권한이 없는 개발 서버, 관리자 콘솔, 다른 부서의 업무 시스템은 보이지 않거나 연결되지 않는다. 이 구조는 공격자가 계정을 확보했을 때 내부에서 움직일 수 있는 범위를 줄인다.

ZTNA 동작 방식

ZTNA는 일반적으로 사용자와 업무 애플리케이션 사이에서 접근 요청을 검증한다. 사용자가 특정 애플리케이션에 접근하려고 할 때 ZTNA는 해당 요청이 사전에 정의된 정책에 부합하는지 확인한다. 이 과정에서 Identity Provider, Single Sign-On, MFA, 엔드포인트 보안 솔루션, Mobile Device Management, 보안 분석 시스템과 연동해 확인할 수 있다.

일반적인 ZTNA 동작 흐름은 다음과 같다.

1. 사용자가 내부 업무 애플리케이션에 접근을 요청
2. ZTNA는 사용자의 신원을 확인하거나, 기존 인증 세션이 유효한지 검증
3. 시스템은 사용자 역할, 그룹 정보, MFA 적용 여부, 디바이스 상태, 접속 위치, 네트워크 환경 등 접근 맥락 확인
4. 요청이 정책 조건을 충족하면 ZTNA는 사용자와 해당 애플리케이션 사이에 제한된 연결을 생성
5. 사용자는 전체 내부 네트워크에 접속하는 것이 아니라, 허용된 애플리케이션에만 접근
6. 세션 중에도 위치 변경, 디바이스 보안 상태 변화, 비정상 접근 패턴 등 위험 신호가 나타나면 접근을 다시 평가하거나 세션 종료

ZTNA는 애플리케이션 접근과 네트워크 접근을 분리한다. 사용자가 인증을 완료했거나 특정 네트워크에 연결됐다고 해서 모든 내부 시스템에 접근할 수 있는 것이 아니라 접근 권한이 없는 애플리케이션, 서버, 내부 IP는 연결되지 않으며, 이를 통해 공격자가 침투하더라도 내부 구조를 탐색하거나 다른 시스템으로 이동하는 경로를 최소화할 수 있다.

ZTNA의 주요 검증 요소

ZTNA는 단순한 로그인 시스템이 아니다. 접근 요청이 있을 때 발생하는 다양한 신호를 확인하고, 접근이 업무 목적에 맞는지 판단한다.

사용자 신원

ZTNA는 사용자의 신원을 파악하여 직원, 협력사, 관리자 등 계정 권한에 따라 접근을 허용한다. 같은 애플리케이션이라도 일반 사용자와 관리자가 필요한 권한 및 작업이 다르기 때문에 역할 기반 정책이 필요하다.

디바이스 상태

동일한 계정으로 접속했더라도 디바이스에 따라 보안 취약점이 발생할 수 있다. 안전한 접속을 위해 디바이스 관리 상태, 보안 패치 적용 및 엔드포인트 보안 솔루션 설치 등의 디바이스 상태를 확인해야 한다. 감염됐거나 보안 상태를 확인할 수 없는 디바이스라면 정상 계정으로 로그인했더라도 접근을 제한할 필요가 있다.

위치와 접속 환경

사용자가 평소와 다른 국가나 네트워크에서 접속하거나, 비정상적인 시간대에 민감한 시스템 접근을 시도헐 경우 추가 검증이 필요하다. 위치 정보 하나만으로 차단 여부를 결정할 수는 없지만, 디바이스 성태와 계정과 같은 추가적인 신호와 함께 위협수준을 파악할 수 있다.

애플리케이션과 권한

접근을 시도하는 애플리케이션 권한도 중요하다. 일반 협업 도구와 관리자 콘솔, 개발 시스템, 고객 데이터베이스과 같은 민감한 시스템은 같은 수준의 보안을 적용해서는 안된다. ZTNA는 사용자가 요청한 애플리케이션의 중요도와 사용자의 역할을 검증하여 접근여부를 결정한다. 이 과정에서 최소 권한 원칙을 적용해 업무에 필요하지 않은 접근을 최소화할 수 있다.

세션과 사용자 행동

접근이 허용된 뒤에도 사용자의 행동를 계속 확인해야 한다. 평소 사용하지 않던 시스템에 접근, 짧은 시간 안에 여러 애플리케이션을 접속, 관리자 기능을 반복적으로 호출하는 행동 등은 추가 검토가 필요할 수 있다. ZTNA는 이런 행동이 정책 조건을 충족하지 않으면 추가 인증, 세션 종료, 접근 기록 검토를 요청할 수 있다.

Article

제로트러스트(Zero Trust) 구현 전략: 신뢰하지 않고 검증하는 네트워크 보안

ZTNA로 대응 가능한 공격

ZTNA는 악성코드를 직접 탐지하거나 취약점을 제거하는 기술이 아니다. 위와 같은 요소를 지속적으로 검증해 공격이 내부 시스템으로 확산되지 않도록 제한한다. 접근 대상을 업무에 필요한 애플리케이션으로 제한하고, 최소 권한 원칙을 기반으로 공격자가 침투한다 하더라도 이후 접근할 수 있는 범위를 크게 제한하는데 목적이 있다.

• 계정 탈취 공격
  공격자는 피싱, 인증 정보 유출, 세션 탈취 등을 통해 정상 계정을 확보할 수 있다. 해당 계정으로 공격자가 접속할 경우 로그인 자체는 정상 사용자와 비슷하게 보인다. ZTNA는 계정이 인증됐더라도 모든 네트워크를 노출하지 않고, 정책상 허용된 애플리케이션과 리소스에만 접근하도록 제한한다. 공격자가 계정을 확보하더라도 접근 가능한 범위가 줄어든다.
• 내부 이동(Lateral Movement)
  내부 이동(Lateral Movement)은 공격자가 하나의 계정이나 시스템을 발판으로 다른 서버, 애플리케이션, 관리 콘솔로 이동하는 과정이다. 기존 네트워크 접근 방식에서는 인증 이후 쉽게 같은 네트워크 안의 다른 시스템에 접속이 가능하다. ZTNA는 허용된 대상에만 연결을 제공하기 때문에 공격자가 내부 구조를 확인하거나 추가 시스템으로 이동하는 경로를 최소화할 수 있다.
• 권한 악용
  업무에 필요하지 않은 권한이 넓게 부여되면 계정 탈취, 내부자 위협, 실수로 인한 데이터 노출로 이어질 수 있다. ZTNA는 최소 권한 원칙을 적용해 사용자가 업무에 필요한 애플리케이션과 리소스만 이용하도록 제한한다. 이를 통해 공격자가 탈취 계정으로 활용할 수 있는 권한을 줄이고, 정상 사용자나 내부자가 불필요한 시스템에 접근하는 상황도 줄일 수 있다.

ZTNA vs VPN

ZTNA와 VPN는 연결 대상이 다르다. VPN은 네트워크에 접속을 허용하여 필요한 시스템을 이용한다. 반면 ZTNA는 사용자를 필요한 애플리케이션에만 연결을 해, 권한이 없는 자산은 노출되지 않는다.

구분	VPN	ZTNA
접근 대상	네트워크 중심	애플리케이션 중심
신뢰 방식	인증 이후 접속 허용	접근 요청마다 조건 확인 및 지속 검증
접근 범위	네트워크 단위로 넓어질 수 있음	허용된 애플리케이션으로 제한
주요 통제 방식	터널링, 방화벽 정책, 네트워크 분리	신원, 디바이스 상태, 정책, 세션
계정 탈취 시 위험	내부 탐색과 이동 가능성 증가	접근 가능한 대상 축소
적합한 환경	레거시 시스템, 네트워크 수준 접속	클라우드, SaaS, 원격·협력사 접근

이와 같은 차이는 보안 운영 방식에도 영향을 준다. VPN 환경에서는 방화벽 정책, 네트워크 분리, 계정 권한을 통해 접근을 관리한다. ZTNA 환경에서 애플리케이션 단위로 접근을 허용하며 사용자와 디바이스 상태를 함께 확인하기 때문에, 단순히 네트워크 접속에 성공했다는 이유만으로 광범위한 권한을 부여하지 않는다.

ZTNA을 도입했다 하더라도 VPN의 모든 기능을 대체하지는 않는다. 레거시 시스템, 특수한 관리 접속, 네트워크 수준 연결이 필요한 환경에서는 VPN이 계속 필요하다. 다만 외부 접근이 많은 업무 시스템, 협력사 접근, 클라우드 애플리케이션, 관리자 포털처럼 접근 범위를 좁게 관리해야 하는 영역에서는 ZTNA 방식이 더 적합할 수 있다.

ZTNA 배포 방식

ZTNA는 환경에 따라 다양한 방식으로 배포할 수 있으며, 관리 대상 디바이스, 애플리케이션 유형, 협력사 접근 여부, 클라우드 사용 비중을 기준으로 선택해야 한다.

• 에이전트 기반 ZTNA
  에이전트 기반 ZTNA는 사용자 디바이스에 ZTNA 에이전트를 설치해 접근 요청과 디바이스 상태를 확인하는 방식이다. 기업에서 관리하는 디바이스에 적용하기 쉽고, 관리자 계정이나 민감한 내부 시스템 접근을 통제할 때 유용하다. 에이전트 기반 ZTNA는 디바이스의 보안 상태를 비교적 세밀하게 확인할 수 있다는 장점이 있지만, 협력사 또는 외부 인력과 같이 기업이 직접 관리하지 않는 디바이스에는 적용 부담이 생길 가능성이 있다.
• 에이전트리스 ZTNA
  에이전트리스 ZTNA는 사용자 디바이스에 별도 에이전트를 설치하지 않고 접근을 제어하는 방식이다. 주로 웹 기반 애플리케이션이나 SaaS 접근 통제하는데 활용되며, 협력사, 외주 인력, 일시적인 접근 권한이 필요한 사용자에게 적용하기 쉽다. 하지만 디바이스 상태를 직접 확인하기 어렵기 때문에, 관리된 단말에 비해 디바이스 보안 상태를 상세하게 확인하고 판단하는데 한계가 있다.
• 클라우드 기반 ZTNA
  클라우드 기반 ZTNA는 클라우드 서비스를 활용해 접근 정책을 적용하는 방식이다. 사용자와 애플리케이션이 분산된 환경에서 일관된 접근 정책을 적용하기 쉽다. SaaS, 클라우드 애플리케이션, 원격 근무 환경처럼 사용자가 특정 네트워크 안에 있지 않아도 업무 시스템에 접근해야 하는 구조에 적합하다. 다만 기존 온프레미스 시스템과 함께 운영할 경우 연동 구조를 미리 조율해야 한다.
• 하이브리드 ZTNA
  하이브리드 ZTNA는 온프레미스 시스템과 클라우드 애플리케이션을 같이 보호하기 위해 활용하는 방식이다. 레거시 시스템을 유지하면서 일부 애플리케이션 대상으로 ZTNA로 전환해야 하는 기업에서 현실적인 선택지가 될 수 있다. 온프레미스 환경에서 기존 방화벽, VPN, IAM, MFA, EDR, SIEM과 함께 운영되는 경우가 많기 때문에, 어떤 시스템을 먼저 전환하고 어떤 접근은 기존 방식으로 유지할지 정리하는 과정이 필요하다.

ZTNA와 SASE

ZTNA를 검토하다 보면 SASE(Secure Access Service Edge)라는 용어를 함께 접하게 된다. 두 개념은 관련이 있지만 같은 의미는 아니다. ZTNA는 사용자와 애플리케이션 또는 리소스 사이의 접근을 제어하는 보안 아키텍처이며, SASE는 네트워크와 보안 기능을 클라우드 기반으로 통합하는 더 넓은 프레임워크다.

SASE는 분산된 사용자와 애플리케이션을 보호하기 위해 다양한 보안 기능을 함께 활용한다. 여기에는 ZTNA뿐 아니라 SWG(Secure Web Gateway), CASB(Cloud Access Security Broker), FWaaS(Firewall as a Service), SD-WAN 같은 요소가 포함될 수 있다. 즉, ZTNA는 SASE에서 애플리케이션 접근 제어를 담당하는 핵심 구성요소 중 하나로 볼 수 있다.

예를 들어 사용자가 SaaS 애플리케이션이나 내부 업무 시스템에 접속할 때 ZTNA는 해당 사용자가 접근 권한을 갖고 있는지 검증한다. 동시에 SASE 환경에서는 웹 트래픽 보안, 클라우드 애플리케이션 제어, 방화벽 정책, 네트워크 경로 관리가 함께 적용될 수 있다.

기업이 ZTNA와 SASE를 함께 검토하는 이유는 접근 제어만으로는 분산된 업무 환경 전체를 보호하기 어렵기 때문이다. ZTNA가 누가 어떤 애플리케이션에 접근할 수 있는지를 판단한다면, SASE는 어디서 접속하든 네트워크와 보안 정책을 어떻게 일관되게 적용할 것인가에 집중한다.

ZTNA 도입 전 고려사항

ZTNA 도입은 어떤 솔루션을 도입할 것인가가 아닌 어떤 애플리케이션을 보호할 것인지, 어떤 사용자가 어떤 권한으로 접근해야 하는지 정리해야 한다. 이와 같은 기준이 없으면 정책은 복잡해지고, 예외 정책이 증가하면서 기대한 보안 효과를 충족할 수 없게 된다.

1. 보호할 애플리케이션과 데이터 식별
   모든 시스템을 일괄적으로 전환하려고 하면 정책 설계가 복잡해진다. 외부 접근이 많거나 민감 데이터와 연결된 애플리케이션과 데이터를 식별하고 이를 바탕으로 우선순위를 정해야 한다.
2. 사용자 그룹과 접근 권한 정리
   직원, 협력사, 외주 인력, 관리자 계정은 접근 목적과 권한 범위가 다르다. 사용자 그룹별로 어떤 애플리케이션에 접근해야 하는지 먼저 정리해야 한다.
3. IdP, SSO, MFA 연동 상태 확인
   ZTNA는 신원 확인을 기반으로 동작한다. 기존 IdP, SSO, MFA 체계가 정리돼 있지 않으면 접근 정책도 안정적으로 운영할 수 없다.
4. 디바이스 상태 확인 기준 정의
   관리된 디바이스와 관리되지 않는 디바이스를 어떻게 구분할지 정의해야 한다. 보안 패치, 백신 또는 EDR 동작 여부, 디바이스 등록 상태 등을 정책 조건으로 활용할 수 있다.
5. 고위험 애플리케이션부터 단계적 적용
   관리자 포털, 개발 시스템, 고객 정보 시스템, 협력사 접근 시스템처럼 위험이 큰 영역부터 적용하는 것이 현실적이다. 단계적으로 적용해야 사용자 불편과 운영 중단을 최소화할 수 있다.
6. 로그와 정책 예외 검토
   ZTNA 정책은 한 번 만들고 끝나는 것이 아니라 지속적으로 확인하고 검토해야 한다. 접근 로그를 확인해 과도한 권한, 반복되는 예외 사항, 비정상 접근 패턴을 지속적으로 조정해야 한다.

Article

XDR이 ZTNA를 만났을 때

Article

차세대 방화벽과 EPP로 구현하는 제로 트러스트 보안

ZTNA 도입 시 주의할 점

ZTNA는 접근기반 보안을 세밀하게 적용할 수 있지만, 도입 과정에서 운영 부담이 발생할 수 있다. 기존 시스템 구조와 사용자 업무 흐름을 충분히 검토하지 않으면 보안은 강화됐지만 업무 지연 문제가 발생할 수 있다.

가장 먼저 확인해야 할 부분은 레거시 시스템이다. 오래된 내부 애플리케이션은 최신 인증 방식이나 프록시 기반 접근 제어 적용이 불가능할 가능성이 있다. 이 경우 시스템 구조를 변경, 예외 정책, VPN과 ZTNA를 병행하는 등의 조치가 필요하다.

사용자 경험도 중요하다. 인증과 재검증이 너무 자주 발생하면 사용자의 업무 연속성을 방해할 수 있다. 위험이 낮은 일반 업무와 민감한 관리자 작업에 같은 수준의 검증을 요구하면 운영 효율이 떨어지기 때문에 접근 대상의 중요도와 위험 수준에 따라 정책 강도를 다르게 설계해야 한다.

예외 정책 관리도 주의해야 한다. 협력사, 긴급 작업, 임시 관리자 권한처럼 예외가 필요한 상황은 항상 존재한다. 하지만 이와 같은 예외 사항이 누적되면 최소 권한 원칙이 무너진다. 예외 권한에는 만료 기간, 승인 절차, 접속 로그, 권한 회수 기준이 함께 있어야 한다.

ZTNA는 방화벽, VPN, IAM, MFA, EDR, SIEM을 대체하는 단일 기술이 아니다. 접근 제어를 더 세밀하게 만드는 역할을 하며, 다른 보안 체계와 함께 운영될 때 효과가 커진다. 보안팀은 ZTNA를 도입할 때 기존 보안 도구와 어떤 신호를 주고받을지, 어떤 이벤트를 모니터링할지 함께 설계해야 한다.

FAQ

안랩의 ZTNA 솔루션

안랩은 차세대 네트워크 방화벽 솔루션 XTG기반 ZTNA 구현을 지원한다. AhnLab XTG는 사용자와 디바이스의 신원과 보안 상태를 지속적으로 확인하고 검증된 사용자만 접근을 허용하는 ZTNA 기능을 통해 제로트러스트 아키텍처 구축을 지원한다. 또한, 암호화 트래픽 분석과 애플리케이션 단위 정책 설정 기능을 통해 네트워크 가시성을 높이고, 국내외 주요 애플리케이션에 대한 심층 보안 기능을 제공해 다양한 위협에 효과적으로 대응할 수 있다.