제로트러스트 보안: 원칙·ZTNA·도입 단계

왜 제로트러스트인가

전통적인 경계 보안(Perimeter Security) 모델은 "내부 네트워크는 안전하다"는 전제에서 출발합니다. 하지만 클라우드 전환, 재택근무 확산, 내부자 위협 증가로 이 전제는 무너졌습니다. 2020년 SolarWinds 공격, 2021년 Colonial Pipeline 사태 모두 경계 보안의 한계를 보여줬습니다.

제로트러스트는 "절대 신뢰하지 말고, 항상 검증하라(Never Trust, Always Verify)"는 원칙입니다.

핵심 원칙 3가지

1. 명시적 검증(Verify Explicitly) 모든 접근 요청에서 사용자 신원, 디바이스 상태, 위치, 시간대를 종합적으로 검증합니다. 단순 패스워드 인증이 아닌 MFA + 디바이스 인증서 + 행위 분석을 결합합니다.

2. 최소 권한(Least Privilege) 업무에 필요한 최소한의 권한만 부여하고, 세션 단위로 권한을 재검증합니다. AWS IAM의 경우 와일드카드(*) 정책 대신 리소스 수준 정책을 적용합니다.

3. 침해 가정(Assume Breach) 이미 내부가 뚫렸다는 가정 하에 설계합니다. 마이크로세그멘테이션으로 lateral movement를 차단하고, 모든 트래픽을 암호화합니다.

구현 로드맵

1단계: 자산 식별 (1~2개월)

• 모든 사용자, 디바이스, 앱, 데이터 인벤토리 작성
• 크리티컬 데이터 분류 및 접근 패턴 분석

2단계: 정책 엔진 구축 (2~3개월)

• IdP(Identity Provider) 통합: Okta, Azure AD, Google Workspace
• 디바이스 관리: MDM/EDR 연동 (Intune, CrowdStrike)
• 조건부 접근 정책 설계

# 예시: Azure AD 조건부 접근 정책
conditions:
  users: all_users
  cloud_apps: all_apps
  device_state:
    require_compliant: true
  sign_in_risk: medium_or_above
grant_controls:
  operator: AND
  mfa_required: true
  compliant_device: true

3단계: 네트워크 마이크로세그멘테이션

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

4단계: 지속적 모니터링

• SIEM과 연동해 이상 접근 패턴 탐지
• User and Entity Behavior Analytics(UEBA) 도입
• 접근 로그 90일 이상 보존

결론

제로트러스트는 제품이 아닌 전략입니다. Microsoft, Google 등 빅테크는 이미 전사 적용을 완료했습니다. 국내 금융권과 공공기관도 ISMS-P 인증 요건 강화에 따라 도입이 가속화되고 있습니다.

ZTNA는 VPN을 어떻게 대체하나

제로트러스트의 네트워크 구현체가 **ZTNA(Zero Trust Network Access)**입니다. 전통적 VPN과의 차이가 핵심입니다.

VPN은 "터널 안이면 다 신뢰"하지만 ZTNA는 사용자·디바이스·앱 조합마다 정책을 평가합니다.

국내 도입 맥락

• KISA가 제로트러스트 가이드라인 2.0을 발간해 성숙도 모델·도입 단계를 제시합니다.
• 공공·금융은 망분리 규제와 함께 적용해야 하므로, ZTNA를 "망분리를 대체"가 아니라 "보완·현대화"하는 방향으로 설계하는 것이 현실적입니다.

흔한 실패 패턴

• MFA만 도입하고 끝 — 디바이스 상태·컨텍스트 검증 없이 MFA만으론 제로트러스트가 아닙니다.
• 세그멘테이션 누락 — 신원 검증만 강화하고 횡적 이동(lateral movement) 차단을 빼면 침해 시 피해가 그대로 확산됩니다.
• 빅뱅 전환 — 한 번에 전사 적용하려다 업무 마비. 크리티컬 앱부터 단계적 적용이 정석입니다.

정책 적용 후 접속이 끊길 때: 원인·검증·해결

제로트러스트 전환 중 가장 흔한 사고는 보안 사고가 아니라 정상 사용자의 접속이 갑자기 거부되는 것입니다.

원인

• 기기 상태 조건(OS 버전, EDR 설치, 디스크 암호화)을 강제했는데 일부 기기가 준수 상태를 보고하지 못함
• 서비스 계정·배치 작업처럼 사람이 아닌 주체가 MFA 조건에 걸림
• IdP 그룹 동기화 지연으로 새 입사자·부서 이동자가 정책 대상에서 빠짐

검증 순서

1. IdP 로그인 로그에서 거부 사유 코드를 확인합니다(예: Microsoft Entra ID의 로그인 로그, Okta System Log의 policy 평가 결과).
2. 거부된 기기의 준수 상태를 MDM 콘솔에서 확인합니다.
3. 네트워크 경로 문제인지 분리하기 위해, 같은 사용자가 준수 기기에서 접속되는지 확인합니다.

# 예: Okta System Log에서 특정 사용자의 정책 거부 이벤트 조회
curl -s -H "Authorization: SSWS $OKTA_TOKEN" \
  "https://<org>.okta.com/api/v1/logs?filter=actor.alternateId+eq+%22user@corp.com%22+and+outcome.result+eq+%22DENY%22"

해결과 단계적 적용

• 새 정책은 먼저 "보고 전용(report-only)" 모드로 1~2주 운영해 영향받는 사용자·기기를 파악한 뒤 강제로 전환합니다.
• 서비스 계정은 사람용 정책에서 분리하고, 워크로드 ID(관리형 ID, 짧은 수명 토큰)와 출발지 제한으로 대체합니다.
• 긴급 접근용 계정(break-glass)을 2개 두고, 사용 시 즉시 경보가 가도록 설정합니다.

재발 방지

• 정책 변경은 티켓과 변경 이력으로 관리하고, 거부율이 평소보다 급증하면 경보를 받도록 합니다.

자주 묻는 질문 (FAQ)

Q. 제로트러스트면 VPN을 당장 버려야 하나요? 아니요. 대개 ZTNA와 VPN을 병행하다 앱 단위로 점진 전환합니다. 레거시 앱은 VPN에 남기고 신규/핵심 앱부터 ZTNA로 옮기는 식입니다.

Q. 작은 회사도 제로트러스트가 필요한가요? 규모와 무관하게 원칙(MFA·최소권한·로깅)은 유효합니다. 다만 풀스택 ZTNA 제품 대신 IdP(MFA)+클라우드 조건부 접근부터 시작하면 비용 효율적입니다.

에디터 노트 — 현장에서는

제로트러스트는 '제품 사면 끝'이 아니라 조직 정치에 가깝습니다. 가장 큰 저항은 기술이 아니라 '내 권한을 왜 줄이냐'는 부서들이죠. 그래서 성공한 도입은 거의 다 '관리자 계정 MFA + 핵심 시스템 1개'처럼 작게 시작해 성과를 보여준 뒤 확장했습니다. 전사 빅뱅은 대부분 실패합니다. 기술 로드맵만큼 '누구를 먼저 설득하느냐'의 순서를 설계하세요.

참고 자료

• NIST SP 800-207: Zero Trust Architecture (공식 표준)
• Kubernetes Network Policies 공식 문서

도입 단계 (현실형)

1. IdP MFA + 조건부 접근
2. 관리자·원격 접속부터 ZTNA
3. 세그멘테이션·최소권한 확대
4. 장치 상태(컴플라이언스) 연동

VPN 빅뱅 폐기 ❌ → 앱 단위 병행 전환 ✅

검증 환경·편집자 주

• 2026-09. KISA 제로트러스트 가이드라인과 함께 읽기.

자주 묻는 질문 (FAQ) — 보강

Q. 사내망 PC도 제로트러스트인가요?
원칙은 동일. 다만 우선순위는 원격·고권한부터입니다.