Q25. 제로트러스트, 도입해야 하나요?

A. 이 질문은 먼저 바로잡아야 합니다.
“제로트러스트를 도입해야 하나?”라는 표현은
마치 제로트러스트가 하나의 제품이나 솔루션인 것처럼 들립니다.

하지만 제로트러스트는 제품명이 아닙니다.
특정 장비나 서비스를 구매하면 완성되는 구축 사업도 아닙니다.

제로트러스트는
아무도 기본적으로 신뢰하지 않고, 모든 접근을 계속 검증하자는 보안 원칙이자 운영 방식입니다.

따라서 질문은 이렇게 바뀌어야 합니다.

제로트러스트 제품을 도입해야 하는가?
가 아니라,
우리 조직의 접근·권한·행위 검증 체계를
제로트러스트 원칙에 맞게 바꾸고 있는가?

이렇게 질문을 바꾸면 논점이 명확해집니다.

조직은 제로트러스트라는 이름의 제품을 사는 것이 아니라,
접근과 권한을 계속 검증하는 방식으로 보안 운영을 바꿔야 합니다.

다만 제로트러스트 원칙을 적용한다고 해서
침해 탐지와 대응이 자동으로 완성되는 것은 아닙니다.

제로트러스트는 기본적으로
누가, 어떤 기기로, 어떤 애플리케이션에 접근할 수 있는가를
엄격하게 검증하고 제한하는 접근 보안 원칙입니다.

반면 실제 침해 대응에서 더 중요한 질문은 따로 있습니다.

정상적으로 인증된 사용자가 들어온 뒤,
그 안에서 무엇을 했는가?

제로트러스트는 이 질문의 일부에는 답할 수 있습니다.
그러나 전체 공격 흐름을 끝까지 관찰하고,
웹 공격과 호스트 행위를 연결하고,
데이터 유출과 내부 확산을 실시간으로 차단하는 일은
제로트러스트만으로 충분하지 않습니다.

따라서 결론은 단순합니다.

제로트러스트는 구매 대상이 아니라 적용해야 할 원칙입니다.
그러나 그 원칙만으로 침해 탐지와 대응이 완성된다고 말해서는 안 됩니다.

1부. 제로트러스트를 먼저 올바르게 이해해야 합니다

1️⃣ 왜 지금 제로트러스트 원칙이 중요할까요?

예전에는 보안을 이렇게 생각했습니다.

내부망은 신뢰할 수 있고,
외부망은 위험하다.

그래서 방화벽, VPN, 망분리, 접근통제 장비를 중심으로
내부와 외부를 구분하는 방식이 보안의 기본이었습니다.

하지만 지금은 환경이 완전히 달라졌습니다.

• 사용자는 회사 밖에서 접속합니다.
• 업무는 SaaS와 클라우드에서 이루어집니다.
• 협력사와 외주 인력이 내부 시스템에 접근합니다.
• API와 관리자 페이지가 인터넷에 노출됩니다.
• 개발·운영·보안 도구가 서로 자동 연동됩니다.
• 정상 계정 탈취가 침해의 주요 출발점이 되었습니다.

이 상황에서 “내부망이니까 안전하다”는 전제는 더 이상 성립하기 어렵습니다.

제로트러스트가 필요한 이유는 바로 이 때문입니다.

제로트러스트는 사용자가 내부에 있든 외부에 있든,
시스템이 사내망에 있든 클라우드에 있든,
항상 다음을 다시 확인하자는 원칙입니다.

• 이 사용자는 누구인가?
• 이 기기는 신뢰할 수 있는가?
• 이 접근은 업무상 필요한가?
• 이 권한은 최소한인가?
• 이 세션은 계속 정상인가?
• 조건이 바뀌면 접근을 다시 제한할 수 있는가?

즉, 제로트러스트는
신뢰를 없애자는 말이 아니라, 신뢰를 계속 검증하자는 말입니다.

2️⃣ 제로트러스트는 제품명이 아니라 보안 아키텍처입니다

제로트러스트를 말할 때 가장 먼저 조심해야 할 점은
이를 특정 제품군으로 오해하는 것입니다.

제로트러스트는 VPN 대체 제품도 아니고,
IAM 제품도 아니고,
ZTNA 제품 하나로 완성되는 것도 아닙니다.

NIST SP 800-207은 제로트러스트를
정적인 네트워크 경계 중심 방어에서 벗어나
사용자, 자산, 리소스 중심으로 보안을 재구성하는
사이버보안 패러다임으로 설명합니다. (NIST)

CISA의 Zero Trust Maturity Model도
제로트러스트를 한 번에 끝나는 구축 사업이 아니라
정체성, 기기, 네트워크, 애플리케이션·워크로드, 데이터,
그리고 가시성·자동화·거버넌스를 단계적으로 성숙시키는 모델로 다룹니다. (CISA)

즉, 제로트러스트는 다음에 가깝습니다.

모든 접근을 계속 검증하고,
최소 권한으로 제한하며,
접근 이후의 상태 변화를 지속적으로 확인하는 보안 운영 방식

그래서 제로트러스트는
“제품을 샀는가?”가 아니라
다음 질문으로 평가해야 합니다.

이 중 일부만 적용하고
“제로트러스트 구축 완료”라고 말하면 위험합니다.

3️⃣ 제로트러스트를 제품 도입으로 축소하면 왜 위험할까요?

제로트러스트는 보안 아키텍처입니다.
그런데 현실에서는 제로트러스트가
특정 제품 도입 문제로 축소되는 경우가 많습니다.

정책 서버를 도입하면 제로트러스트인가.
IAM / IM 서버를 붙이면 제로트러스트인가.
관리자 콘솔과 에이전트를 배포하면 제로트러스트인가.

이 질문은 과거 IPS를 떠올리게 합니다.

IPS는 원래 침입 방지라는 보안 체계의 개념에 가깝습니다.
그러나 현실에서는 “IPS 제품”을 도입하면
침입이 방지되는 것처럼 인식되었습니다.

그 결과 많은 조직은 IPS 제품을 도입하고도
정책 관리, 탐지 우회, 로그 분석, 웹 공격 대응, 내부 침해 추적은
충분히 하지 못했습니다.

이름부터도 혼란스러웠습니다.

“침입방지시스템”이라는 표현만 보면
방화벽도 침입을 막고, 웹방화벽도 침입을 막고,
EDR도 침입 이후 행위를 막습니다.
그런데 IPS라는 제품군 하나가
마치 침입 방지 전체를 대표하는 것처럼 굳어졌습니다.

제로트러스트도 같은 길을 가서는 안 됩니다.

제로트러스트 아키텍처가
제로트러스트 제품 도입으로 축소되는 순간,
정책은 다시 제품 구매, 인증, 성숙도 점수 중심으로 흐를 수 있습니다.

서툴고 근본적인 검토 없는 ZTA 적용은
오히려 독이 될 수 있습니다.

제로트러스트라는 이름으로
정책 서버, IAM 서버, 관리자 콘솔, 에이전트 배포 서버가 새로 생기는데,
그 구성요소가 웹/API 공격 표면으로 보호되지 않는다면
그 자체가 새로운 침투 경로가 될 수 있습니다.

⚠️ 제로트러스트라는 이름이 붙었다고 안전해지는 것이 아닙니다.
보호되지 않은 제로트러스트 제어면은 또 하나의 고위험 웹/API 시스템입니다.

제로트러스트는 신앙이 아닙니다.
검증되어야 할 아키텍처입니다.

4️⃣ 제로트러스트가 잘하는 것

제로트러스트는 분명히 강력한 효과가 있습니다.

특히 다음 영역에서는 기존 보안 방식보다 훨씬 현실적입니다.

1. VPN 중심 구조의 한계 보완

기존 VPN은 한 번 접속하면
내부망의 넓은 영역에 접근할 수 있는 구조가 많았습니다.

제로트러스트 또는 ZTNA는
사용자가 특정 애플리케이션에 필요한 범위만 접근하도록 제한할 수 있습니다.

이것은 공격자의 내부 이동 가능성을 줄이는 데 도움이 됩니다.

2. 최소 권한 접근

제로트러스트는
“일단 허용하고 나중에 막는 방식”이 아니라
“필요한 것만 허용하는 방식”에 가깝습니다.

이 원칙은 계정 탈취 사고에서 특히 중요합니다.

공격자가 정상 계정을 탈취하더라도
그 계정이 접근할 수 있는 범위가 작다면
피해 범위도 줄어듭니다.

3. 사용자와 기기 상태 기반 접근

사용자 ID만 보는 것이 아니라
기기 상태, 위치, 인증 강도, 세션 위험도 등을 함께 고려합니다.

예를 들어,

• 평소와 다른 국가에서 접속
• 관리되지 않는 기기에서 접속
• MFA는 통과했지만 비정상 시간대 접근
• 민감 시스템에 대한 반복 접근

이런 조건에 따라 접근을 제한하거나
추가 인증을 요구할 수 있습니다.

4. 클라우드·SaaS 환경에 적합

업무 시스템이 더 이상 내부망 안에만 있지 않기 때문에
네트워크 위치 중심 보안은 한계가 큽니다.

제로트러스트는 애플리케이션, 사용자, 기기, 데이터 중심으로
접근 기준을 다시 설계한다는 점에서
클라우드 시대에 더 적합합니다.

정리하면 제로트러스트는
접근면을 줄이고, 권한을 좁히고, 내부 이동을 어렵게 만드는 데 매우 유용합니다.

2부. 제로트러스트의 진짜 위험은 제어면과 가시성 공백입니다

5️⃣ 그러나 제로트러스트가 답하지 못하는 질문도 있습니다

문제는 여기서 시작됩니다.

제로트러스트는 접근을 통제합니다.
하지만 침해 대응은 접근 통제만으로 끝나지 않습니다.

보안 사고에서 정말 중요한 질문은 다음입니다.

허용된 사용자가 허용된 애플리케이션에 접속한 뒤,
그 안에서 정상 업무를 했는가, 공격 행위를 했는가?

예를 들어 보겠습니다.

1. 공격자가 정상 계정을 탈취합니다.
2. MFA를 우회하거나 피싱으로 세션 토큰을 확보합니다.
3. ZTNA를 정상적으로 통과합니다.
4. 허용된 업무 애플리케이션에 접근합니다.
5. 웹 요청 본문에 공격 페이로드를 삽입합니다.
6. 서버에서 비정상 프로세스가 생성됩니다.
7. 내부 파일 조회, 계정 변경, 데이터 압축이 이어집니다.
8. 암호화된 정상 세션처럼 보이는 경로로 데이터가 유출됩니다.

이 흐름에서 제로트러스트가 막을 수 있는 부분도 있습니다.

하지만 모든 단계를 막을 수 있는 것은 아닙니다.

특히 다음 질문은 제로트러스트만으로 충분히 답하기 어렵습니다.

• 웹 요청 본문에 어떤 공격 페이로드가 들어왔는가?
• 서버에서 어떤 프로세스가 실행되었는가?
• 권한 상승이나 계정 변경이 있었는가?
• 대량 조회와 데이터 유출 정황이 있는가?
• 정상 세션처럼 보이지만 실제로는 탈취된 세션인가?
• 웹 공격 이후 호스트 이벤트가 연결되는가?
• 침해 전후 시스템 상태가 어떻게 바뀌었는가?

즉,

제로트러스트는 “들어올 수 있는가”를 묻습니다.
침해 대응은 “들어온 뒤 무엇을 했는가”를 물어야 합니다.

이 두 질문은 서로 다릅니다.

6️⃣ 가시성은 제로트러스트 바깥의 문제가 아니라 제로트러스트의 핵심 필러입니다

제로트러스트를 접근 통제만으로 이해하면
가장 중요한 축 하나를 놓치게 됩니다.

제로트러스트 프레임워크에는 이미
로그, 분석, 자동화, 지속적 검증의 요구가 포함되어 있습니다.

CISA의 성숙도 모델은 제로트러스트를
Identity, Devices, Networks, Applications & Workloads, Data뿐 아니라
Visibility and Analytics, Automation and Orchestration, Governance까지 포함하는 구조로 설명합니다. (CISA)

NSA도 제로트러스트의 Visibility and Analytics Pillar를 별도로 설명하며,
조직이 네트워크, 엔드포인트, 애플리케이션, 데이터, 사용자 행위를 관찰하고
분석할 수 있어야 한다는 점을 강조합니다. (NSA)

따라서 XDR은 제로트러스트와 별개의 개념이 아닙니다.

정확히 말하면,

XDR은 제로트러스트 아키텍처가 요구하는
가시성 및 분석(Visibility and Analytics) 필러를
실전에서 구현하는 핵심 수단입니다.

여기서 WAF와 EDR의 역할도 명확해집니다.

• WAF는 웹/API 요청과 응답의 가시성을 제공합니다.
• EDR은 호스트 내부 실행과 계정·파일·프로세스 행위의 가시성을 제공합니다.
• XDR은 이 둘을 계정, 세션, 네트워크, 포렌식 정보와 연결해 공격 흐름을 해석합니다.

즉, 제로트러스트 제어면만 강조하면
정책 서버, IAM 서버, 관리자 콘솔 보호의 중요성은 잘 드러납니다.

하지만 제로트러스트를 실제로 운영하려면
그 제어면에서 내려진 정책이
현장에서 어떤 행위로 이어졌는지 볼 수 있어야 합니다.

가시성 없는 제로트러스트는
“누가 들어올 수 있는가”는 통제할 수 있어도,
“들어온 뒤 무엇을 했는가”는 놓칠 수 있습니다.

7️⃣ “정상 계정”은 제로트러스트 시대에도 가장 위험합니다

제로트러스트 원칙을 적용해도
정상 계정 기반 침해는 계속 발생할 수 있습니다.

오히려 공격자는 더 적극적으로 정상 계정을 노립니다.

왜냐하면 정상 계정은
보안 정책을 통과할 수 있는 가장 자연스러운 방법이기 때문입니다.

공격자는 다음을 시도할 수 있습니다.

• 크리덴셜 스터핑
• 피싱
• MFA 피로 공격
• 세션 쿠키 탈취
• 토큰 탈취
• OAuth 앱 악용
• 관리자 계정 탈취
• 협력사 계정 악용

이 경우 접근 로그만 보면
공격자가 정상 사용자처럼 보일 수 있습니다.

따라서 제로트러스트 환경에서도
계정 자체의 인증 여부만으로는 부족합니다.

반드시 다음을 함께 봐야 합니다.

정상 계정을 통과시킨 뒤에도
그 계정이 무엇을 했는지 추적하지 못하면
제로트러스트는 절반의 대응에 그칠 수 있습니다.

8️⃣ 제로트러스트 제품 자체도 공격 표면입니다

제로트러스트 논의에서 자주 빠지는 부분이 있습니다.

바로 제로트러스트 제품 자체도 공격받을 수 있다는 점입니다.

제로트러스트가 아키텍처라고 해도
현실에서 그것을 구현하는 구성요소는 결국 소프트웨어와 서버입니다.

특히 제로트러스트 제품 또는 플랫폼은 대체로 다음 구성요소를 가집니다.

• 정책 서버
• IAM / IM 서버
• 관리자 콘솔
• SDP 컨트롤러
• API 게이트웨이
• 에이전트 배포 서버
• 단말 상태 검증 서버
• 로그·정책 연동 API

이 구성요소들은 대부분 웹 애플리케이션이거나 API 서버입니다.

관리자는 브라우저로 접속합니다.
정책은 API로 배포됩니다.
에이전트는 중앙 서버와 통신합니다.
인증·인가 판단도 중앙 시스템과 연동됩니다.

즉, 이름은 제로트러스트이지만
실제 공격 표면은 웹/API입니다.

그리고 웹/API라면 다음 위험에서 자유로울 수 없습니다.

• 관리자 콘솔 취약점
• 인증 우회 취약점
• API 권한 검증 오류
• SSRF, SQL Injection, 파일 업로드 취약점
• OAuth / OIDC / SAML 연동 오류
• 오픈소스 프레임워크 취약점
• 에이전트 업데이트 공급망 공격
• 정책 배포 API 악용

이 문제는 추상적인 가능성만은 아닙니다.

2024년 CISA는 Ivanti Connect Secure와 Ivanti Policy Secure의
여러 취약점이 실제 공격에 악용되었다고 경고했습니다.
CISA 권고에 따르면 이 취약점들에는 웹 컴포넌트의 권한 상승 취약점도 포함되어 있었습니다. (CISA Ivanti Advisory)

또한 Okta는 2023년 고객 지원 시스템 침해 사고에서
일부 HAR 파일에 세션 토큰이 포함되어 있었고,
이 토큰이 세션 하이재킹 공격에 사용될 수 있었다고 설명했습니다. (Okta RCA)
이후 Okta는 지원 시스템 사용자 정보가 포함된 보고서가 다운로드되었고,
영향 범위를 모든 Workforce Identity Cloud 및 Customer Identity Solution 고객으로 확대해 공지했습니다. (Okta Update)

이 사례들이 말해주는 것은 분명합니다.

접근 보안 제품과 IAM 시스템도
조직의 핵심 공격 표면이 될 수 있습니다.

따라서 제로트러스트 제품이 안전하다는 말은
제품 이름으로 증명되지 않습니다.

로그와 증거로 검증되어야 합니다.

9️⃣ 보안 제품의 관리 서버와 업데이트 체계도 공급망 공격 표면입니다

우리는 이미 보안 제품이 공격 표면이 될 수 있다는 사실을 경험하고 있습니다.

NAC는 내부 네트워크 접근을 통제하는 보안 체계입니다.
그러나 NAC 역시 정책 서버, 에이전트, 업데이트 서버, 관리자 콘솔로 구성됩니다.

Genians는 2023년 보안 권고에서
Genian Update 서버와 관련된 여러 취약점을 공개했고,
영향을 받는 구성요소로 Policy Server, Network Sensor, Agent를 명시했습니다. (Genian Advisory)

이 사례가 주는 메시지는 분명합니다.

보안 제품의 관리 서버와 업데이트 체계도 공격 표면입니다.

제로트러스트 제품도 다르지 않습니다.

정책 서버가 장악되면 접근 정책이 바뀔 수 있습니다.
IAM / IM 서버가 장악되면 계정과 권한 체계가 흔들릴 수 있습니다.
관리자 콘솔이 장악되면 보안 설정이 공격자에게 유리하게 바뀔 수 있습니다.
에이전트 배포 서버가 장악되면 내부 단말 확산 경로가 될 수 있습니다.

따라서 제로트러스트 제품을 적용할수록
오히려 그 제품 자체에 대한 WAF, EDR, XDR, 포렌식 검증이 더 중요해집니다.

보안 제품은 안전하다는 전제가 아니라
보안 제품도 공격받을 수 있다는 전제에서 출발해야 합니다.

🔟 인증 체계가 장악되면 내부 측면이동의 통로가 됩니다

제로트러스트를 말할 때 반드시 함께 봐야 하는 것이 있습니다.

바로 인증 체계 자체가 공격받을 경우입니다.

기업 내부망에서 Windows Active Directory(AD)는
단순한 로그인 서버가 아닙니다.

AD는 사용자 계정, 컴퓨터 계정, 보안 그룹, 권한, 정책을 중앙에서 관리합니다.
즉, 조직 내부의 “누가 어디에 접근할 수 있는가”를 결정하는 핵심 인증·권한 기반입니다.

공격자가 AD 계정, 관리자 권한, 서비스 계정, 그룹 정책, 도메인 컨트롤러를 장악하면
그 순간부터 공격은 단일 서버 침해가 아니라
조직 전체의 인증 체계 침해로 확장됩니다.

이때 발생하는 것이 내부 측면이동입니다.

공격자는 하나의 서버나 PC에 머무르지 않습니다.
탈취한 계정과 권한을 이용해 다른 서버로 이동하고,
관리 도구와 정상 인증 흐름을 악용하며,
파일 서버, POS 시스템, 업무 시스템, 백업 시스템, 배포 서버로 공격 범위를 넓힙니다.

Active Directory 환경에서의 측면이동은
공격자가 네트워크 내 접근 범위를 확장하고
원격 시스템에서 코드 실행을 확보하는 대표적인 공격 흐름입니다.

이랜드 랜섬웨어 사고도 이 관점에서 볼 수 있습니다.

공개 보도에 따르면 이랜드는 2020년 랜섬웨어 공격으로
사내 네트워크 시스템이 공격받았고,
그 결과 NC백화점과 뉴코아아울렛 등 50개 점포 중 23개 점포 운영에 차질이 발생했습니다. (Yonhap)

중요한 것은 “점포 몇 곳이 멈췄다”가 아닙니다.

중요한 것은 내부 인증·권한·운영 인프라가 흔들리면
공격 영향이 매장 운영, POS, 업무망, 결제·판매 시스템까지 확산될 수 있다는 점입니다.

그리고 AI 공격 시대에는 같은 문제가
제로트러스트 제어면에서도 반복될 수 있습니다.

제로트러스트 제품 또는 플랫폼이 다음 구성요소를 가진다면,

• 정책 서버
• IAM / IM 서버
• 관리자 콘솔
• SDP 컨트롤러
• API 게이트웨이
• 에이전트 배포 서버
• 단말 상태 검증 서버

이 구성요소들은 또 다른 인증·정책·권한 제어면이 됩니다.

공격자가 제로트러스트 정책 서버를 장악하면
접근 정책을 바꿀 수 있습니다.

공격자가 IAM / IM 서버를 장악하면
사용자·권한·역할 정보를 탈취하거나 조작할 수 있습니다.

공격자가 관리자 콘솔을 장악하면
보안 설정을 비활성화하거나 우회 정책을 삽입할 수 있습니다.

공격자가 에이전트 배포 서버를 장악하면
정상 업데이트 경로를 내부 확산 통로로 바꿀 수 있습니다.

즉, 제로트러스트 제어면이 뚫리면
제로트러스트는 방어 체계가 아니라
공격자의 내부 이동 경로가 될 수 있습니다.

AD가 뚫리면 내부 측면이동이 발생하듯,
제로트러스트 제어면이 뚫리면
새로운 형태의 측면이동이 발생할 수 있습니다.

AI 공격 시대의 제로트러스트 논의는
바로 이 지점에서 출발해야 합니다.

1️⃣1️⃣ 제로트러스트 업체는 정말 보안을 준비했는가

여기서 불편하지만 중요한 질문을 해야 합니다.

제로트러스트 제품을 만드는 회사는
정말 웹 보안을 제대로 알고 있는가?

정책 서버가 웹 서버라는 사실을 알고 있는가.
관리 콘솔이 WAF 보호 대상이라는 사실을 알고 있는가.
React·Next.js·Node.js 취약점에 실시간 대응할 수 있는가.
API 요청과 응답 본문을 기록하고 분석하는가.
관리자 권한 변경과 정책 배포 행위를 감사 로그로 남기는가.
에이전트 배포 서버가 공급망 공격에 악용될 가능성을 검증하는가.
제로트러스트 제어면 자체에 대한 EDR/XDR 상관분석이 가능한가.

이 질문에 답하지 못한다면
제로트러스트 제품은 방어 체계가 아니라
또 하나의 고위험 웹 애플리케이션일 수 있습니다.

1️⃣2️⃣ 우리는 인증만으로는 믿지 않습니다

제로트러스트를 적용한다면
더 먼저 답해야 할 질문이 있습니다.

제로트러스트 제품 자체는 누가 검증했는가?
어떻게 검증했는가?
무엇을 기준으로 안전하다고 판단했는가?

인증서가 있는가.
가이드라인을 따랐는가.
성숙도 모델에 맞췄는가.

이런 질문만으로는 부족합니다.

우리는 인증만으로는 믿지 않습니다.
우리는 검증 가능한 기록과 작동하는 대응 체계를 믿어야 합니다.

보안 제품이 스스로 “안전하다”고 말하는 것은 의미가 없습니다.
인증을 받았다고 해서 AI 공격을 견딜 수 있다는 뜻도 아닙니다.
성숙도 모델의 높은 단계에 있다고 해서 실제 공격을 막는다는 뜻도 아닙니다.

중요한 것은 다음입니다.

즉, 제로트러스트를 말하려면
“제로트러스트 체계로 전환하라”가 아니라
다음까지 말해야 합니다.

제로트러스트 아키텍처를 제품 도입으로 축소하지 말라.
제로트러스트 정책 서버와 관리자 콘솔을 웹/API 공격 표면으로 식별하라.
정책 변경, 권한 변경, 에이전트 배포, 인증 우회 시도를 실시간으로 탐지하라.
제로트러스트 제어면이 장악될 경우를 가정한 대응 훈련을 수행하라.

이것이 AI 공격 시대에 맞는 제로트러스트 논의입니다.

3부. 제로트러스트는 XDR과 함께 운영될 때 완성됩니다

1️⃣3️⃣ AI 공격 시대에는 제로트러스트만으로 부족합니다

AI 기반 공격이 확산되면
공격자는 더 빠르게 탐색하고, 더 빠르게 조합하고, 더 빠르게 우회합니다.

AI는 다음을 자동화할 수 있습니다.

• 노출된 관리자 페이지 탐색
• API 엔드포인트 추정
• 로그인·세션 흐름 분석
• 오픈소스 취약점 매칭
• 페이로드 변형
• WAF 우회 시도
• 정상 계정 기반 행위 위장
• 취약점과 권한의 체이닝

이 상황에서 제로트러스트는 여전히 중요합니다.

그러나 제로트러스트만으로는
AI 공격의 전체 흐름을 막기 어렵습니다.

왜냐하면 AI 공격은
단순히 “접근 허용/차단”의 문제가 아니라
허용된 경로 안에서 계속 변형되기 때문입니다.

AI 공격 시대의 핵심 질문은 다음입니다.

공격자가 정상 계정과 정상 세션을 이용해 들어왔을 때,
우리는 원본 로그를 보고 몇 분 안에 판단하고 차단할 수 있는가?

제로트러스트는 공격자의 접근 범위를 줄입니다.
하지만 다음을 직접 보장하지는 않습니다.

• 웹 요청·응답 본문 기반 공격 탐지
• 서버 내부 실행 체인 분석
• 권한 상승과 lateral movement 탐지
• 데이터 유출 전 차단
• 랜섬웨어 암호화 전 중단
• 웹 로그와 호스트 로그의 상관분석
• 포렌식 diff 기반 침해 범위 확인

따라서 AI 공격 시대의 보안 구조는
제로트러스트와 XDR이 함께 가야 합니다.

1️⃣4️⃣ 현실적인 구조는 “Zero Trust + WAF + EDR + XDR”입니다

제로트러스트는 접근을 줄입니다.
WAF와 EDR은 각각 웹과 호스트의 가시성을 제공합니다.
XDR은 들어온 뒤의 행위를 연결해 봅니다.

이들은 경쟁 관계가 아닙니다.

역할이 다릅니다.

이렇게 보면 제로트러스트는
보안의 출입 통제 레이어입니다.

WAF는 웹/API 가시성 레이어입니다.
EDR은 호스트 가시성 레이어입니다.
XDR은 이 가시성을 묶어 침해 흐름을 해석하고 대응하는 운영 레이어입니다.

제로트러스트 없이 XDR만 있으면
접근면이 너무 넓을 수 있습니다.

XDR 없이 제로트러스트만 있으면
들어온 뒤의 행위를 놓칠 수 있습니다.

WAF 없이 제로트러스트만 있으면
웹 요청 본문에 숨어 있는 공격을 놓칠 수 있습니다.

EDR 없이 제로트러스트만 있으면
서버 내부 실행과 계정·파일·프로세스 변화를 놓칠 수 있습니다.

결국 실전 구조는 다음과 같아야 합니다.

[Zero Trust / ZTNA / IAM]
- 사용자·기기·권한·세션 검증
- 애플리케이션 단위 접근 제한
- 정책 서버·관리자 콘솔 보호 필요

        │
        ▼

[WAF / Web Visibility]
- 웹/API 요청·응답·본문 분석
- 크리덴셜 스터핑, SQL Injection, 우회 시도 탐지
- 관리자 콘솔·정책 서버의 웹/API 공격 표면 보호

        │
        ▼

[EDR / Host Visibility]
- 프로세스·파일·계정·서비스·네트워크 행위 분석
- 웹 침투 이후 서버 내부 실행 추적
- 권한 상승·측면이동·랜섬웨어 행위 탐지

        │
        ▼

[XDR / Correlation & Response]
- 웹 + 계정 + 호스트 + 정책 변경 + 포렌식 상관분석
- 고위험 행위 실시간 판단
- 차단, 격리, 보고, 포렌식 검증

1️⃣5️⃣ XDR 계층은 제로트러스트의 어떤 공백을 메우나요?

XDR의 역할은
제로트러스트를 대체하는 것이 아닙니다.

오히려 제로트러스트가 잘하는 영역을 인정하면서,
그 뒤에 남는 행위 분석과 실시간 대응 공백을 메우는 구조입니다.

1. 웹 요청·응답 본문 분석

제로트러스트는 사용자의 접근 여부를 판단합니다.
하지만 웹 애플리케이션 안에서 실제로 어떤 요청이 들어왔는지는
별도의 웹 보안 가시성이 필요합니다.

XDR과 WAF 계층은 웹 요청과 응답, 본문을 기반으로
다음 공격 정황을 분석할 수 있어야 합니다.

• SQL Injection
• 인증 우회 시도
• 비정상 파일 업로드
• API 파라미터 조작
• 크리덴셜 스터핑
• 응답 본문 기준 정보 노출
• 알려지지 않은 제로데이성 요청 패턴

2. 호스트 실행 체인 분석

공격은 웹에서 끝나지 않습니다.

웹 요청 이후 서버 내부에서
프로세스가 실행되고, 파일이 생성되고, 권한이 바뀌고,
내부 연결이 이어질 수 있습니다.

따라서 다음을 연결해서 봐야 합니다.

• 어떤 계정이 실행했는가
• 어떤 프로세스가 생성되었는가
• 부모-자식 프로세스 관계는 무엇인가
• 어떤 파일과 레지스트리가 바뀌었는가
• 어떤 네트워크 연결이 이어졌는가

제로트러스트가 접근을 통제한다면,
EDR/XDR은 실행 이후의 행위를 확인합니다.

3. 제어면 변경과 행위 로그의 상관분석

제로트러스트 제어면에서는
정책 변경, 권한 변경, 에이전트 배포, 인증 우회 시도 같은 이벤트가 발생합니다.

이 이벤트는 단독으로 보면 관리 작업처럼 보일 수 있습니다.

하지만 다음 흐름과 연결되면 의미가 달라집니다.

관리자 계정 이상 로그인
→ 정책 서버 접근
→ 접근 정책 변경
→ 특정 내부 시스템 접근 허용
→ 서버 내부 프로세스 실행
→ 데이터 접근 증가

이 흐름을 연결해야
제로트러스트 제어면이 정상 운영 중인지,
공격자의 내부 이동 경로로 바뀌었는지 판단할 수 있습니다.

4. 실시간 대응과 포렌식 diff

탐지만 하고 대응이 늦으면
AI 공격 시대에는 의미가 줄어듭니다.

중요한 것은 다음입니다.

• 공격이 진행 중일 때 판단하는가
• 몇 분 안에 차단할 수 있는가
• 차단 후 무엇이 바뀌었는지 확인할 수 있는가
• CEO와 보안 담당자가 같은 근거를 보고 판단할 수 있는가

PLURA-XDR 역시 이러한 관점에서
제로트러스트 이후의 행위를
원본 로그, 상관분석, 자동 대응, 포렌식 검증으로 이어가는 구조를 지향합니다.

중요한 것은 제품명이 아니라
제로트러스트 이후의 행위를 실제로 볼 수 있느냐입니다.

1️⃣6️⃣ 제로트러스트 적용 순서는 이렇게 잡는 것이 현실적입니다

제로트러스트는 한 번에 끝내는 사업으로 접근하면 실패하기 쉽습니다.

처음부터 모든 시스템을 대상으로
완벽한 제로트러스트를 구현하려고 하면
정책 충돌, 사용자 불편, 운영 부담이 커집니다.

현실적인 순서는 다음과 같습니다.

이 순서에서 중요한 것은
제로트러스트 적용과 동시에
로그·탐지·대응 체계를 함께 설계해야 한다는 점입니다.

접근 정책만 바꾸고
그 접근 이후의 행위를 보지 못하면
보안 운영은 오히려 더 복잡해질 수 있습니다.

1️⃣7️⃣ 적용 전에 반드시 물어야 할 질문

제로트러스트 적용을 검토한다면
다음 질문에 답해야 합니다.

접근 통제 관점

• 핵심 업무 시스템은 무엇인가?
• 외부에서 접근 가능한 관리 페이지는 어디인가?
• 협력사와 외주 인력은 어떤 경로로 접속하는가?
• 관리자 계정은 몇 개인가?
• 장기 미사용 계정은 정리되었는가?
• MFA는 어느 범위까지 적용되어 있는가?
• 권한은 최소 권한 원칙으로 운영되는가?

제어면 보호 관점

• ZTNA·IAM·정책 서버 자체의 로그를 확보하는가?
• 관리자 콘솔 요청·응답 로그를 볼 수 있는가?
• 정책 변경과 권한 변경을 실시간으로 확인하는가?
• 에이전트 배포 서버의 무결성을 검증하는가?
• 오픈소스 취약점 대응 체계가 있는가?
• 제로트러스트 제품 자체가 WAF·EDR·XDR 보호 대상인가?

가시성·분석 관점

• 웹/API 요청·응답·본문을 볼 수 있는가?
• 서버 내부 프로세스 실행과 파일 변경을 볼 수 있는가?
• 계정·세션·권한·정책 변경 로그가 연결되는가?
• WAF와 EDR 로그를 XDR에서 상관분석할 수 있는가?
• 제로트러스트 정책 변경 이후 실제 호스트 행위를 추적할 수 있는가?

침해 대응 관점

• 정상 계정 탈취 이후 이상 행위를 탐지하는가?
• 웹 요청 본문 기반 공격을 볼 수 있는가?
• 웹 공격 이후 서버 내부 실행을 연결하는가?
• 데이터 대량 조회와 외부 전송을 탐지하는가?
• 고위험 세션을 자동 차단할 수 있는가?
• 차단 이후 포렌식 diff로 변경 사항을 확인하는가?
• CEO에게 몇 분 안에 공격 흐름을 보고할 수 있는가?

이 질문에 답하지 못하면
제로트러스트 적용은 보안 강화가 아니라
보안 제품 추가에 그칠 수 있습니다.

1️⃣8️⃣ 제로트러스트 적용 시 주의해야 할 점

제로트러스트는 좋은 원칙이지만,
적용 과정에서 다음과 같은 오해가 생기기 쉽습니다.

이 항목들은 제로트러스트를 반대하기 위한 것이 아닙니다.

오히려 제로트러스트를 제대로 적용하기 위해
반드시 확인해야 할 운영 리스크입니다.

1️⃣9️⃣ 정리하면

제로트러스트는 제품으로 도입하는 것이 아니라
보안 운영 원칙으로 적용해야 합니다.

하지만 제로트러스트는
침해 대응의 끝이 아니라 시작입니다.

제로트러스트는 다음에 강합니다.

• 접근면 축소
• 최소 권한
• 사용자·기기 검증
• 애플리케이션 단위 접근
• 내부 이동 제한
• 클라우드·SaaS 환경의 접근 통제

그러나 다음을 단독으로 해결하지는 못합니다.

• 웹 요청·응답 본문 기반 공격 탐지
• 정상 계정 탈취 이후 행위 판별
• 서버 내부 실행 체인 분석
• 권한 상승과 내부 확산 탐지
• 데이터 유출 전 차단
• 제로트러스트 제어면 자체의 침해 탐지
• 포렌식 diff 기반 침해 범위 확인
• CEO 보고 수준의 공격 흐름 요약

따라서 현실적인 결론은 이것입니다.

제로트러스트는 제품으로 사는 것이 아니라
운영 원칙으로 적용해야 합니다.
그러나 제로트러스트만 믿어서는 안 됩니다.

제로트러스트는 접근을 줄이는 원칙입니다.
WAF와 EDR은 웹과 호스트의 가시성을 제공합니다.
XDR은 들어온 뒤의 행위를 분석하고 대응하는 체계입니다.

AI 공격 시대에는 모두 필요합니다.

접근은 제로트러스트로 줄이고,
웹/API 공격은 WAF로 보고,
호스트 행위는 EDR로 보고,
공격 흐름은 XDR로 연결하고,
고위험 행위는 실시간으로 차단하고,
침해 전후 변화는 포렌식으로 확인해야 합니다.

결국 핵심은 제품명이 아닙니다.

실제로 무엇을 검증하는가.
실제로 무엇을 기록하는가.
실제로 무엇을 탐지하는가.
실제로 몇 분 안에 차단하는가.

제로트러스트는 보안의 중요한 원칙입니다.
하지만 보안을 완성하는 것은
원칙이 아니라 운영입니다.

그리고 그 운영은
원본 로그, 가시성, 상관분석, 실시간 대응, 포렌식 검증 위에서 완성됩니다.

📖 함께 읽기

• [정책제안] AI 공격 시대, 정부 안내문은 왜 실전 대응 기준이 되지 못하는가
• 웹서버인 줄 모르는 보안·인프라 장비들
• React2Shell 취약점 대응
• Windows Wildfire: 정상 기능이 공격 도구가 되는 순간
• PLURA-XDR은 Mythos AI 해킹 공격에 어떻게 대응하는가?
• SIEM·SOAR 하이프사이클, 왜 현실과 맞지 않는가
• Q22. SASE만으로 통합 보안이 완성될까요?