목차
- 제로트러스트는 ‘제품’이 아니라, 접근 결정을 만드는 운영 체계다
- 제로트러스트 구현 3원칙: Verify, Least Privilege, Assume Breach
- 제로트러스트 구현 설계의 기본: NIST PDP/PEP 구조 이해
- 클라우드 제로트러스트 구현: 5개 Pillar와 3개 크로스컷
- 클라우드 제로트러스트 구현 흐름 7단계(권장 순서)
- Step 0. 제로트러스트 구현의 시작: 보호 표면 정의
- Step 1. 제로트러스트 구현 첫 단계: Identity를 새 경계로 (SSO + MFA)
- Step 2. 제로트러스트 구현 디바이스 검증: 포스처 기반 신뢰
- Step 3. 제로트러스트 구현 핵심: VPN 대신 PEP를 앞으로(ZTNA)
- Step 4. 제로트러스트 구현 네트워크: 세그멘테이션으로 작은 방들로 쪼개기
- Step 5. 제로트러스트 구현 워크로드 보안: 서비스 계정도 검증 대상
- Step 6. 제로트러스트 구현 데이터 보호: 경계가 아닌 데이터 자체를 지킨다
- Step 7. 제로트러스트 구현 완성: 가시성 + 자동화 + 거버넌스
- 제로트러스트 구현 서비스 매핑: PDP/PEP/PIP 클라우드 대응표
- 제로트러스트 구현 90일 로드맵(현실 버전)
- 0~2주: “계정부터” 정상화
- 3~6주: “PEP를 앞단에” 붙이기 (ZTNA 파일럿)
- 7~12주: 세그멘테이션 + 로그/자동화 시작
- 제로트러스트 구현 실패 패턴 7가지와 대응 방법
- 제로트러스트 구현은 한 번의 구축이 아닌 지속적 검증 운영이다
- 제로트러스트 구현 자주 묻는 질문(FAQ)
- Q1. 제로트러스트는 “VPN을 없애는 것”인가요?
- Q2. 제로트러스트 3원칙(Verify/Least Privilege/Assume breach)은 어디서 나온 건가요?
- Q3. PDP/PEP는 뭐고, 왜 중요하죠?
- Q4. 클라우드에서 PEP는 보통 무엇으로 구현하나요?
- Q5. “제로트러스트는 제품이 아니다”라는 말이 무슨 뜻이죠?
- Q6. 어디부터 시작해야 가장 효과가 큰가요?
제로트러스트는 ‘제품’이 아니라, 접근 결정을 만드는 운영 체계다
제로트러스트 구현을 검토하면서 VPN 대체(ZTNA) 얘기부터 접하는 경우가 많습니다.
하지만 제로트러스트(Zero Trust)의 핵심은 더 단순하고, 더 강력합니다.
- 네트워크 안쪽이면 믿는다 → (기존)
- 안쪽/바깥쪽 관계없이, 매 요청마다 검증한다 → (제로트러스트)
NIST는 “제로트러스트가 정적 네트워크 경계(perimeter) 중심 방어에서 벗어나 사용자·자산·리소스 중심으로 초점을 옮기는 패러다임”이며, 네트워크 위치나 소유만으로 암묵적 신뢰를 주지 않는다고 설명합니다. (NIST Computer Security Resource Center)
그리고 중요한 한 문장.
ZTA(Zero Trust Architecture)는 ‘사서 붙이는’ 단일 서비스가 아니라, 여러 보안/운영 구성요소를 묶어 구현하는 전략입니다. (buy.gsa.gov)
제로트러스트 구현 3원칙: Verify, Least Privilege, Assume Breach
Microsoft가 정리한 제로트러스트 핵심 원칙 3개는, 클라우드 구현 순서 자체입니다.
- Verify explicitly(명시적으로 검증): 가능한 모든 데이터 포인트로 인증/인가 (Microsoft Learn)
- Use least privilege access(최소 권한): JIT/JEA 등으로 필요 최소만 (Microsoft Learn)
- Assume breach(침해를 가정): 폭발 반경 최소화, 세그멘테이션, 가시성/탐지 (Microsoft Learn)
이 3문장을 “클라우드 아키텍처 언어”로 바꾸면:
- 정체성(Identity)이 새 경계(perimeter)가 된다
- 정책(Policy)이 네트워크가 아니라 ‘요청’에 붙는다
- 로그/가시성/자동화가 없으면 제로트러스트가 성립하지 않는다
제로트러스트 구현 설계의 기본: NIST PDP/PEP 구조 이해
NIST SP 800-207은 제로트러스트 접근을 이렇게 모델링합니다.
- 사용자가 리소스에 접근하려면
- PDP(Policy Decision Point)가 판단하고
- PEP(Policy Enforcement Point)가 집행한다 (NIST Publications)
그리고 PDP는 다시 두 개로 쪼개집니다.
- Policy Engine(PE): 허용/거부/회수의 “최종 결정”을 내림
- Policy Administrator(PA): 그 결정을 실행(세션 토큰/경로 설정, PEP 제어) (NIST Publications)
PEP는 “연결을 열고/모니터링하고/종료”하는 게이트키퍼 역할을 하죠. (NIST Publications)
또 하나 핵심 포인트:
NIST는 제로트러스트 논리 컴포넌트들이 컨트롤 플레인(control plane)으로 통신하고, 실제 앱 데이터는 데이터 플레인(data plane)에서 흐른다고 설명합니다. (NIST Publications)
요청 흐름(실무식으로 번역한 그림)
(1) 사용자/워크로드가 리소스 요청
↓
(2) PEP(프록시/게이트웨이/에이전트)가 요청을 가로챔
↓
(3) PDP(=Policy Engine)가 정책 + 컨텍스트(PIP 신호)로 허용/거부/조건부 허용 판단
↓
(4) Policy Admin이 PEP에 "세션 열어/닫아/재인증" 지시
↓
(5) 데이터 플레인에서 세션 통신 + 지속 모니터링
↓
(6) 리스크 상승 시 즉시 세션 회수(Assume breach)
NIST는 정책 결정을 위해 자산 상태(CDM), 위협 인텔리전스, 활동 로그, ID 관리 시스템 같은 다양한 입력을 예로 들며, 이런 데이터 소스가 정책 엔진 판단에 들어간다고 설명합니다. (NIST Publications)
클라우드 제로트러스트 구현: 5개 Pillar와 3개 크로스컷
미국 GSA의 Zero Trust Architecture 기술 문서는 ZTA를 다음처럼 구조화합니다.
- 5대 Pillar: Identity, Devices, Networks, Applications & Workloads, Data
- 3대 크로스컷: Visibility & Analytics, Automation & Orchestration, Governance (buy.gsa.gov)
이게 왜 중요하냐면요.
제로트러스트를 “ZTNA(원격접속)”만으로 시작하면
Identity/Device/Data가 비어 있어서 사고가 나도 “왜 허용됐는지” 설명이 안 됩니다.
클라우드 제로트러스트 구현 흐름 7단계(권장 순서)
아래 순서로 가면, 시행착오(=보안 예산 낭비)가 크게 줄어듭니다.
Step 0. 제로트러스트 구현의 시작: 보호 표면 정의
- 무엇을 지켜야 하는가? (데이터/업무/시스템 티어링)
- 누가 접근하는가? (직원/협력사/고객/워크로드)
- 어디서 접근하는가? (사내/재택/해외/모바일)
- 어떤 방식으로? (웹/SSH/RDP/API/DB)
이 단계가 없으면 정책이 “전사 다 막기” 또는 “전사 다 풀기”로 극단화됩니다.
Step 1. 제로트러스트 구현 첫 단계: Identity를 새 경계로 (SSO + MFA)
제로트러스트에서 가장 먼저 해야 할 일은 인증/인가의 중앙화입니다. 클라우드 IAM 설정에서 흔히 발생하는 실수를 피하려면 IAM 권한 설계 실수 TOP 10과 예방책도 함께 참고하세요.
- 계정이 흩어져 있으면: “검증(verify)” 자체가 불가능
- MFA가 없으면: “assume breach”가 아니라 “assume hacked”가 됩니다
Microsoft는 제로트러스트를 “명시적 검증/최소 권한/침해 가정”으로 요약하고, 이를 기반으로 접근 정책을 설계하라고 안내합니다. (Microsoft Learn)
특히 Microsoft 문서에서는 Microsoft Entra ID가 사용자·엔드포인트·대상 리소스·환경 신호를 기반으로 접근 정책을 집행하는 PDP로 동작할 수 있다고 설명합니다. (Microsoft Learn)
Step 2. 제로트러스트 구현 디바이스 검증: 포스처 기반 신뢰
제로트러스트는 “사용자만”이 아니라 디바이스도 검증합니다.
NIST도 정책 엔진 입력으로 자산 상태(패치/취약점/승인 SW 여부)를 수집하는 CDM 같은 시스템을 언급합니다. (NIST Publications)
실무 체크포인트:
- 디스크 암호화
- 최신 패치 수준
- EDR 설치 여부
- 루팅/탈옥/관리 대상 여부
- 인증서 기반 디바이스 신원
Step 3. 제로트러스트 구현 핵심: VPN 대신 PEP를 앞으로(ZTNA)
여기서 ZTNA가 등장합니다. 다만 포인트는 “VPN 대체”가 아니라:
앱/리소스 앞단에 PEP(정책 집행 지점)를 두는 것
클라우드에서 이 PEP는 보통 “프록시/게이트웨이/아이덴티티 기반 프론트도어”로 구현됩니다.
- AWS Verified Access: VPN 없이 기업 애플리케이션/리소스에 안전하게 접근시키고, 사용자 신원 + 디바이스 보안 상태 기반으로 정책을 적용할 수 있다고 설명합니다. (Amazon Web Services, Inc.)
- Google Cloud Identity-Aware Proxy(IAP): Google Cloud 리소스에 대해 제로트러스트 접근을 구현한다고 명시합니다. (Google Cloud)
- Microsoft Entra Private Access: “Zero Trust 원칙 기반”으로 온프렘 및 모든 클라우드의 프라이빗 앱에 빠르고 안전하게 연결한다고 안내합니다. (Microsoft)
또한 Google BeyondCorp 페이지는 “전통적 VPN 없이도 어디서나 더 안전하게 일할 수 있게 하는 제로트러스트 모델(구글 구현)”로 BeyondCorp를 설명합니다. (Google Cloud)
Step 4. 제로트러스트 구현 네트워크: 세그멘테이션으로 작은 방들로 쪼개기
Assume breach를 현실로 만드는 단계입니다. 보안 설정 과정에서 클라우드 비용이 급증할 수 있으므로 AWS 비용 폭탄 방지 체크리스트를 병행하면 좋습니다.
- 동서(East-West) 트래픽: 내부 lateral movement(수평 이동)를 줄이는 게 핵심
- 원칙: “필요한 통신만 허용(deny-by-default)”
AWS도 제로트러스트의 이점으로 신원/디바이스 포스처 기반으로 리소스 접근을 제공하고, 불필요한 통신 경로를 줄여 최소 권한 원칙을 적용한다고 설명합니다. (Amazon Web Services, Inc.)
Step 5. 제로트러스트 구현 워크로드 보안: 서비스 계정도 검증 대상
클라우드 침해의 절반은 “사람 로그인”이 아니라 “토큰/키/서비스 계정”에서 시작합니다.
그래서 여기서는:
- 워크로드 정체성을 분리(서비스별로)
- 짧은 수명의 자격 증명(임시 토큰)
- 서비스 간 통신에 인증/인가를 붙이기(mTLS, 서비스 메시 등)
(이 부분은 조직의 플랫폼 성숙도에 따라 난이도가 크게 갈립니다. 처음부터 완벽보다, “키/토큰 누수 경로부터 제거”가 현실적입니다.)
Step 6. 제로트러스트 구현 데이터 보호: 경계가 아닌 데이터 자체를 지킨다
제로트러스트가 ‘진짜’가 되는 지점입니다.
- 데이터 분류(민감도)
- 암호화(전송/저장)
- 키 관리(KMS/HSM)
- DLP/마스킹/토큰화
- 접근 시도/유출 징후 탐지
GSA 문서도 ZTA를 5대 Pillar로 설명하면서 Data를 핵심 축으로 둡니다. (buy.gsa.gov)
Step 7. 제로트러스트 구현 완성: 가시성 + 자동화 + 거버넌스
NIST는 정책 엔진이 의사결정을 위해 네트워크/시스템 활동 로그 같은 입력을 활용할 수 있다고 설명합니다. (NIST Publications)
즉, 로그/가시성이 빈약하면 “검증”도 “회수”도 못합니다.
- Visibility: 통합 로깅, 리스크 신호(UEBA/EDR/ID 리스크)
- Automation: 자동 차단/격리, 정책 자동 롤아웃
- Governance: 계정/권한/정책 표준, 예외 승인, 정기 리뷰
제로트러스트 구현 서비스 매핑: PDP/PEP/PIP 클라우드 대응표
| 역할(논리 컴포넌트) | 무엇을 하는가 | 클라우드에서 흔한 구현 예 |
|---|---|---|
| PDP (Policy Decision Point) | 허용/거부/조건을 결정 | IdP/조건부 접근/리스크 엔진 (예: Entra ID가 PDP로 동작 가능) (Microsoft Learn) |
| PEP (Policy Enforcement Point) | 결정을 집행(세션 열기/막기/종료) | ZTNA 프록시/게이트웨이/앱 앞단 프론트도어 (AWS Verified Access, Google IAP, Entra Private Access 등) (Amazon Web Services, Inc.) |
| PIP (Policy Information Points) | 결정을 위한 컨텍스트 신호 제공 | 디바이스 포스처/EDR, 취약점, 위협 인텔, 활동 로그 등(NIST가 다양한 입력 예시 제시) (NIST Publications) |
클라우드별 제로트러스트 구현 주요 서비스
| 구분 | AWS | Azure | GCP |
|---|---|---|---|
| ZTNA(PEP) | Verified Access | Entra Private Access | Identity-Aware Proxy(IAP) |
| 조건부 접근(PDP) | IAM Identity Center + SCP | Entra ID Conditional Access | Access Context Manager |
| 디바이스 포스처 | Systems Manager + Jamf 연동 | Intune + Compliance Policy | BeyondCorp Enterprise |
| 세그멘테이션 | Security Group + VPC Lattice | NSG + Azure Firewall | VPC Service Controls |
제로트러스트 구현 90일 로드맵(현실 버전)
0~2주: “계정부터” 정상화
- SSO 적용 범위 확장
- MFA 전면 적용(예외 최소화)
- 관리자 계정 분리 + JIT(가능하면)
- 장기 키/토큰 인벤토리(유출 리스크 제거)
3~6주: “PEP를 앞단에” 붙이기 (ZTNA 파일럿)
- 가장 중요한 내부 앱 1~2개를 선정
- ZTNA(Verified Access / IAP / Entra Private Access 등)로 VPN-less 접근 파일럿 (Amazon Web Services, Inc.)
- 디바이스 신호(관리 단말/최신 패치 등) 조건을 정책에 반영
7~12주: 세그멘테이션 + 로그/자동화 시작
- 중요 자산(결제/DB/관리자 콘솔)부터 통신 경로 최소화
- 접근 로그 + 리스크 이벤트의 중앙 수집(“정책이 왜 허용됐는지” 설명 가능하게)
- 고위험 이벤트(비정상 위치/비관리 단말/과도 권한) 자동 대응 룰 1~3개만 먼저
제로트러스트 구현 실패 패턴 7가지와 대응 방법
- ZTNA만 도입하고 Identity/MFA가 약하다 → 문 앞은 새로 달았는데 열쇠가 복사됨
- “예외”가 너무 많다 → 정책이 아니라 선언문이 됨
- 디바이스 포스처가 없다 → 계정 털리면 끝
- 로그가 없다 → “검증”을 했는지 증명 불가(NIST는 로그를 정책 입력으로도 본다) (NIST Publications)
- 워크로드 키/토큰을 방치 → 사람보다 먼저 털림
- 세그멘테이션을 너무 크게 시작 → 운영/장애로 되돌림
- 거버넌스(권한/정책 표준)가 없다 → 팀마다 제로트러스트 정의가 달라짐(GSA도 Governance를 크로스컷으로 둠) (buy.gsa.gov)
제로트러스트 구현은 한 번의 구축이 아닌 지속적 검증 운영이다
- NIST 관점: 제로트러스트는 PDP가 결정하고 PEP가 집행하며, 다양한 신호를 입력으로 삼아 접근을 통제합니다. (NIST Publications)
- 현장 관점: Identity → Device → ZTNA(PEP) → Segmentation → Data → Visibility/Automation/Governance 순서로 가면 실패 확률이 크게 줄어듭니다. 클라우드 전략 수립 시에는 멀티클라우드 vs 하이브리드 판단 가이드도 참고하세요. (buy.gsa.gov)
제로트러스트 구현 핵심 요약
| 단계 | 핵심 과제 | 주요 결과물 |
|---|---|---|
| 1단계 | Identity 중앙화(SSO/MFA/조건부 접근) | 통합 인증 체계, MFA 전면 적용 |
| 2단계 | Device 포스처 + ZTNA(PEP) 파일럿 | 디바이스 신뢰 정책, VPN-less 접근 파일럿 |
| 3단계 | 세그멘테이션 + 로그/자동화 | 통신 경로 최소화, 중앙 로그 수집, 자동 대응 |
제로트러스트 구현 자주 묻는 질문(FAQ)
Q1. 제로트러스트는 “VPN을 없애는 것”인가요?
VPN 제거는 결과 중 하나일 뿐입니다. 핵심은 “네트워크 위치로 신뢰하지 않고, 매 요청마다 검증/인가”하는 모델입니다. Google은 BeyondCorp를 “전통적 VPN 없이 어디서나 더 안전하게 일하는 제로트러스트 모델(구글 구현)”로 설명합니다. (Google Cloud)
Q2. 제로트러스트 3원칙(Verify/Least Privilege/Assume breach)은 어디서 나온 건가요?
Microsoft의 제로트러스트 개요 문서는 3원칙을 Verify explicitly / Use least privilege access / Assume breach로 정리합니다. (Microsoft Learn)
Q3. PDP/PEP는 뭐고, 왜 중요하죠?
NIST SP 800-207은 접근이 PDP(정책 결정)와 PEP(정책 집행)을 통해 이뤄진다고 모델링하고, PDP는 Policy Engine/Policy Administrator로 나뉜다고 설명합니다. (NIST Publications)
이 구조로 생각하면 “우리가 지금 무엇을 빠뜨렸는지(결정? 집행? 신호?)”가 바로 보입니다.
Q4. 클라우드에서 PEP는 보통 무엇으로 구현하나요?
대표적으로 ZTNA 프록시/게이트웨이 형태가 많습니다.
예: AWS Verified Access(디바이스 상태/신원 기반 정책), Google Cloud IAP(제로트러스트 접근 구현), Microsoft Entra Private Access(제로트러스트 원칙 기반 프라이빗 앱 접근). (Amazon Web Services, Inc.)
Q5. “제로트러스트는 제품이 아니다”라는 말이 무슨 뜻이죠?
GSA 문서는 ZTA가 “구매하는 단일 서비스가 아니라, 조직이 조달한 여러 서비스로 구현되는 전략적 개념”이라고 설명합니다. (buy.gsa.gov)
Q6. 어디부터 시작해야 가장 효과가 큰가요?
대부분 조직은 Identity(SSO/MFA/조건부 접근)부터 시작하는 것이 ROI가 가장 큽니다. 그 다음이 Device 포스처, 그리고 ZTNA(PEP) 파일럿입니다. (Microsoft Learn)
 | AX 100배의 법칙 – 나와 조직의 능력을 100배 높이는 AI 경영의 실제 도서 구매 |
함께 읽으면 좋은 글:
디지털 트랜스포메이션: 조직의 습관을 바꾸는 일, 도서 구매