Zero Trust

학습 목표

경계 방어(castle-and-moat)와 Zero Trust 모델의 차이를 설명할 수 있다.

never trust, always verify — 매 요청·세션 마다 신원·디바이스·컨텍스트를 검증하는 원칙을 설명할 수 있다.

ZTNA(Zero Trust Network Access)가 VPN 전체 네트워크 신뢰와 어떻게 다른지 설명할 수 있다.

micro-segmentation·NetworkPolicy·서비스 메시 mTLS로 워크로드 간 최소 통신을 설계할 수 있다.

16편 체크리스트·8편 인가·3편 mTLS와 연계한 Zero Trust 도입 단계를 설명할 수 있다.

문제 상황

• 사내 VPN 접속 = 내부망 전체 스캔 가능 — 노트북 탈취 시 DB·관리 콘솔 동시 노출
• 평문 ClusterIP — Pod 하나 뚫리면 동일 네임스페이스 API 전부 호출
• 방화벽 "내부" 존 허용 — lateral movement 무방비
• 인증 한 번 끝 — 8시간 세션 동안 권한·위치 변경 무시
• 16편 체크리스트 통과했지만 인프라는 암묵적 신뢰 — 앱 보안만으로 부족

Part 5 클라우드·공급망 시작 — 앱 계층 통제 위에 신뢰 모델을 재정의한다. 네트워크 위치가 아니라 주체·리소스·정책이 판단 기준이다.

Zero Trust는 제품 이름이 아니라 아키텍처 원칙이다. 벤더 스택은 수단; 목표는 침해 가정 하 피해 최소화다.

1. Castle-and-moat vs Zero Trust

전통 모델 — 강한 경계(방화벽·VPN), 내부는 신뢰.

	Castle-and-moat	Zero Trust
신뢰 기준	내부 IP·VPN 접속	없음 — 매번 검증
침해 가정	경계 뚫리면 게임 오버	이미 뚫렸다 가정
접근	네트워크 세그먼트 전체	앱·API 단위 최소
원격	VPN = LAN 확장	ZTNA = 허용 앱 만
MSA	내부 평문 허용	mTLS·세그먼트 기본 거부

• 클라우드·원격·MSA — "내부" 경계 불명확 → moat 모델 한계
• 2편 defense in depth — Zero Trust는 계층 마다 검증 반복

2. Never trust, always verify

핵심 — 위치·과거 로그인 만으로 신뢰 하지 않음. 주체(user·service)·디바이스·컨텍스트(시간·위험 점수)·리소스 민감도를 매 접근 마다 평가.

신호	예
Identity	MFA 완료, OAuth token 유효, SPIFFE ID
Device	관리 MDM 등록, OS 패치, jailbreak 없음
Context	geo, 시간, 이상 로그인, IP reputation
Resource	데이터 분류, API sensitivity
Policy	RBAC·ABAC·OPA (8편)

요청 → 인증 확인 → 디바이스/컨텍스트 평가 → 인가(리소스) → 감사 로그(15편)
         ↑________________ 세션 중에도 재평가 ________________|

• 세션 고정 신뢰 금지 — 권한 상승·디바이스 변경 시 재인증
• 서비스 간 — 사용자 인증과 별도로 워크로드 신원(mTLS)

3. ZTNA

ZTNA — 원격 사용자를 특정 애플리케이션에만 연결. 전체 VPC·서브넷에 브로드 접근 하지 않음.

	VPN	ZTNA
연결	L3 터널 — 네트워크 레이어	L7 프록시·커넥터
가시성	내부 IP 스캔 가능	허용 앱 목록 만
정책	IP·포트	user·device·app
예	OpenVPN, IPSec	Cloudflare Access, Zscaler, BeyondCorp

Remote user → IdP MFA → ZTNA broker → policy allow → app connector → internal API
                              ↓ deny
                         audit event (15편)

• 6~7편 OAuth·OIDC — ZTNA 앞단 SSO·MFA 연동
• 관리 콘솔·SSH — ZTNA·bastion 없이 VPN 만 쓰면 moat 잔존

4. Micro-segmentation

네트워크를 작은 존으로 나누고 기본 거부(default deny). 필요 통신 만 명시 허용.

계층	통제
VPC subnet	public / private / data tier
K8s NetworkPolicy	Pod label 간 ingress/egress
Service mesh	AuthorizationPolicy L7
Cloud SG	security group 최소 포트

# code/network-policy-default-deny.example.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-from-gateway
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: payment-api
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: ingress-gateway
      ports:
        - protocol: TCP
          port: 8080

• east-west 트래픽 — Ingress 밖 서비스 간 호출이 대부분; 세그먼트 없으면 lateral movement
• Platform 서비스 메시 — envoy sidecar가 L4/L7 정책 강화

5. mTLS와 워크로드 신원

3편 mTLS — 양방향 인증서로 서비스 신원 확인. Zero Trust에서 "내부" 호출도 주체가 명확해야 한다.

	Edge TLS	mTLS (mesh)
범위	client → ingress	service → service
신원	서버(＋선택 클라이언트)	SPIFFE 워크로드 ID
키 관리	cert-manager·ACM	istiod 자동 회전
정책	WAF·rate limit (14편)	PeerAuthentication STRICT

# code/peerauthentication-strict.yaml
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

# code/authorizationpolicy-service.yaml
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payment-api
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-api
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/production/sa/order-service"]
      to:
        - operation:
            methods: ["POST"]
            paths: ["/v1/charge"]

• PERMISSIVE — 마이그레이션 용; 프로덕션 목표는 STRICT
• 감사 — SPIFFE ID를 audit 로그 actor에 기록 (15편)

6. 컨텍스트 기반 정책 (개념)

ABAC·OPA에 Zero Trust 신호 추가.

// code/zt-context-policy.example.json
{
  "input": {
    "user_id": "u-42",
    "mfa": true,
    "device_posture": "compliant",
    "risk_score": 25,
    "resource": "payment-api",
    "action": "read"
  },
  "policy": {
    "allow_if": [
      "input.mfa == true",
      "input.device_posture == 'compliant'",
      "input.risk_score < 50"
    ]
  }
}

신호 변화	동작
risk_score 상승	step-up MFA
device non-compliant	deny
비정상 geo	세션 종료·알람

7. 도입 단계

단계	조치
1 가시성	자산·트래픽 맵 — 누가 누구 호출
2 신원	IdP 통합, 서비스 account, mTLS 파일럿
3 세그먼트	default deny NetworkPolicy, namespace 분리
4 ZTNA	VPN 축소, 관리 앱 먼저
5 연속	컨텍스트 정책, SIEM 상관 (15편)

• 빅 뱅 금지 — PERMISSIVE → STRICT, VPN·ZTNA 병행 기간
• 16편 체크리스트에 Zero Trust 행 추가 — mTLS, default deny, ZTNA 대상 앱

8. 체크리스트

항목	확인
Implicit trust	no "internal zone" blind allow
User access	MFA, ZTNA or app-level for remote
Service identity	mTLS STRICT or equivalent
Segmentation	NetworkPolicy default deny + allowlist
Authz	every API — 8편, not network alone
Audit	workload ID + user on sensitive access
VPN	scope review — full LAN vs ZTNA

안티패턴
ZTNA 만 구매	서비스 간 평문 잔존
mTLS 없이 mesh	관측 만·암호화 없음
NetworkPolicy 없음	Pod 탈취 = 동일 NS 전체
VPN = Zero Trust	네트워크 신뢰 모델 동일

9. 정리

• Zero Trust — 경계 신뢰 폐기; 매 접근 검증
• ZTNA — 원격 최소 노출; VPN 대체 방향
• Micro-segmentation + mTLS — 워크로드 간 lateral movement 억제
• 앱 보안(1~16편) + 인프라 신뢰 모델 = Defense in depth 완성 방향
• 공급망·클라우드 IAM은 다음 편에서 확장

다음에 다룰 것

• Supply Chain 보안
• SBOM, SLSA, dependency·container scanning

---

해당 내용은 NIST SP 800-207, CISA Zero Trust Maturity Model, Istio Documentation 의 내용을 기반으로 합니다.