graph LR subgraph NIST["NIST SP 800-207 ZTA"] direction LR PE["Policy Engine"] PA["Policy Administrator"] PEP_N["PEP"] PKI_N["PKI / ID Management"] Logs_N["Activity Logs"] end subgraph Istio["Istio" / OPA] direction LR OPA["OPA"] Istiod["Istio: istiod"] Envoy["Istio: istio-proxy / Waypoint"] SPIFFE["Istio: istiod<br/>(SPIFFE, Citadel)"] Logs_I["Istio: Access Log"] end PE -.-> OPA PA -.-> Istiod PEP_N -.-> Envoy PKI_N -.-> SPIFFE Logs_N -.-> Logs_I style NIST fill:#1e293b,stroke:#94a3b8,color:#ffffff style Istio fill:#1e293b,stroke:#60a5fa,color:#ffffff style PE fill:#0f172a,stroke:#94a3b8,color:#ffffff style PA fill:#0f172a,stroke:#94a3b8,color:#ffffff style PEP_N fill:#0f172a,stroke:#94a3b8,color:#ffffff style PKI_N fill:#0f172a,stroke:#94a3b8,color:#ffffff style Logs_N fill:#0f172a,stroke:#94a3b8,color:#ffffff style OPA fill:#1e293b,stroke:#fbbf24,color:#fbbf24 style Istiod fill:#1e293b,stroke:#60a5fa,color:#60a5fa style Envoy fill:#1e293b,stroke:#34d399,color:#34d399 style SPIFFE fill:#1e293b,stroke:#f472b6,color:#f472b6 style Logs_I fill:#1e293b,stroke:#a78bfa,color:#a78bfa
Mermaid
복사
NIST SP 800-207 Zero Trust Architecture과 Istio / OPA와의 관계
Introduction
사내 보안 전문가 과정 중 작성한 발표 자료의 일부로서, Zero Trust Architecture(ZTA) 및 Kubernetes 환경에서의 ZTA 관점에서 바라본 Istio에 관한 정리이다. 참고로 NIST SP 800-207은 미국 국립표준기술연구소가 작성한 Zero Trust Architecture의 공식 표준 문서로서, 이를 가장 많이 참조하였다. 
Istio overview: Security 에서 역시 ZTA를 언급함과 동시에 여기서 논하는 Istio 보안 features 상세를 다뤘다.
Istio overview: Security 에서 역시 ZTA를 언급함과 동시에 여기서 논하는 Istio 보안 features 상세를 다뤘다.Zero Trust Architecture란
ZTA는 “절대 신뢰하지 않고, 항상 검증한다(Never trust, always verify)”는 원칙에 기반한 새로운 보안 패러다임이다. 방화벽, IDS/IPS, WAF를 필두로 하는 기존의 경계 기반(Perimeter based) 보안 모델이 내부 네트워크를 신뢰하는 것과 달리, ZTA는 위치에 관계없이 모든 사용자, 장치, 그리고 서비스와 트래픽을 잠재적 위협으로 간주하고, 매 순간 인증 및 권한 확인 절차를 거치도록 요구한다. 경계 보안 모델이 침입을 막는 것'에 집중했다면, ZTA는 침입을 가정하고 확산을 막는 것'에 집중한다. 아래는 간단한 경계 기반 보안 모델과 ZTA 간 비교이다.
구분 | 경계 기반 보안 모델 | ZTA |
신뢰 기준 | 내부 네트워크 위치 | 사용자, 디바이스, 서비스 각각의 신원 검증 |
보안 범위 | 네트워크 경계 중심 | 데이터, 서비스, 워크로드 등 개별 리소스 중심 |
접근 제어 | 경계 지점에서의 일회성 인증 | 내/외부 무관, 매 요청마다 검증 및 최소 권한 부여 |
위협 대응 | 외부 침입 차단에 집중 | 내부 침투 가정, 측면 이동 차단 |
ZTA 부각과 현황
2009년 Operation Aurora 해킹, 2015년 OPM(미국 인사관리처) 해킹, 2020년 SolarWinds 공급망 공격 등은 기존 경계 기반 모델의 한계를 보여줌과 동시에 ZTA의 요구를 부각시킨 사례로, 이들 모두 공통적으로 경계 기반 모델이 다룰 수 없는 측면 이동(lateral movement; 내부 침투 후 정상 계정·연결을 이용해 다른 시스템으로 확산하는 공격 기법)을 사용했다.
이후 미국에서는 연방정부 차원의 행정명령을 통해 ZTA는 필수가 되었고, NIST SP 800-207 “Zero Trust Architecture” 표준 문서를 발표하였으며, CISA는 Zero Trust Maturity Model 2.0을 제정하였다. 우리나라의 경우 과학기술정보통신부와 한국인터넷진흥원(KISA)가 "제로 트러스트 가이드라인 2.0"을 발표했으나, 미국처럼 정부 차원에서의 의무화 등은 현재 없어 보인다.
또한, 경계 기반 보안 모델 뿐 아니라 Kubernetes 역시 측면 이동 위협에 취약한 것은 마찬가지이다.
•
평문 통신: 기본적으로 파드 간 통신은 암호화되지 않은 평문으로 이루어진다. 클러스터 네트워크를 도청할 수 있는 공격자는 모든 통신 내용을 가로챌 수 있다.
•
신원 검증 부재: 파드는 서로의 신원을 검증하지 않는다. 공격자가 파드의 IP를 스푸핑하거나 네트워크를 장악하면 다른 서비스로 위장할 수 있다.
•
애플리케이션 계층(L7) 수준 제어 불가: Kubernetes NetworkPolicy는 IP 주소와 포트 기반 제어만 제공한다. 예를 들어 "Service A는 Service B의 80 포트에 접근 가능"이라는 규칙은 만들 수 있지만, "Service A는 Service B의 /api/users 엔드포인트에 GET 요청만 가능"과 같은 애플리케이션 계층 수준의 세밀한 제어는 불가능하다.
Zero Trust Architecture의 원칙과 구조
아래는 NIST SP 800-207 중 ZTA의 핵심을 다루는 Tenets of Zero Trust, Logical Components of Zero Trust Architecture에 대한, Kubernetes / 마이크로서비스 환경을 주로 고려한 요약이다.
Tenets of Zero Trust (원칙)
1.
모든 데이터 소스와 컴퓨팅 서비스는 리소스: 마이크로서비스 환경에서는 모든 서비스 인스턴스와 데이터베이스가 각각으로 독립적인 보호 대상으로 관리되어야 함을 나타낸다.
2.
네트워크 위치와 무관하게 모든 통신 보호: 통신 발생의 내/외부 네트워크 위치는 중요하지 않으며, Kubernetes 내부의 파드 간 통신도 외부 통신과 동일한 수준의 보안 검증을 나타낸다.
3.
리소스에 대한 접근은 세션별로 부여: 각 요청/세션마다 독립적으로 인증·인가가 이루어져야 하며, 세션 종료 후 재접근 시 다시 검증해야 함을 나타낸다.
4.
리소스 접근은 동적 정책에 의해 결정되며, 클라이언트 신원, 애플리케이션, 요청 자산의 상태, 기타 행동 및 환경 속성을 포함: 단순히 누가(Who) 접근하는가 뿐 아니라, 언제(When), 어디서(Where), 무엇을(What), 어떻게(How) 접근하는지를 종합적으로 평가함을 나타낸다.
5.
모든 소유 및 관련 자산의 무결성과 보안 태세를 모니터링하고 측정: 리소스의 보안 상태를 지속적으로 평하고, 취약점이 발견되거나 비정상 행동이 감지되면 접근 권한을 즉시 조정해야 함을 나타낸다.
6.
모든 리소스 인증과 인가는 동적이며, 접근이 허용되기 전에 엄격하게 집행: 기본 거부(Default Deny) 원칙으로 명시적으로 허용되지 않은 모든 것은 차단되어야 함을 나타낸다.
7.
자산, 네트워크 인프라, 통신의 현재 상태에 대해 가능한 한 많은 정보를 수집하고 개선에 활용: 로그, 메트릭, 분산 추적 등 모든 관찰성 데이터를 수집·분석하여 위협을 탐지하여 정책을 지속적으로 개선해야 함을 나타낸다.
Logical Components of Zero Trust Architecture (구조)
ZTA의 논리적 구성 요소. 출처: NIST SP 800-207
핵심 구성요소(Core Components)
ZTA의 핵심 구성요소는 정책의 결정과 집행의 다음 두 요소로 구성된다.
•
정책 결정 지점 (Policy Decision Point, PDP)
◦
모든 접근 요청에 대해 허용/거부를 결정하는 두뇌 역할. PDP는 두 개의 하위 구성요소로 구성됨
▪
정책 엔진 (Policy Engine, PE): 신원 정보, 정책 규칙, 환경 컨텍스트, 위협 인텔리전스 등을 종합 분석하여 Trust Algorithm으로 신뢰 점수 계산 및 접근 허용/거부 결정
▪
정책 관리자 (Policy Administrator, PA): PE의 결정을 PEP에 전달하고, 세션을 생성·해제하며, 정책을 배포·업데이트
•
정책 집행 지점 (Policy Enforcement Point, PEP)
◦
PDP의 결정을 실제로 집행하는 게이트키퍼
◦
모든 리소스 접근 경로에 위치하여 허용된 요청만 통과시킴
관련 내외부 데이터 소스(Local/External Data Sources; PIPs)
그림에 표시된 대로, PDP는 다음 내외부 데이터 소스로부터 정보를 수집하여 정책 결정에 활용한다. 이를 NIST SP 1800-35(Implementing a Zero Trust Architecture)에서는 PIPs(Policy Information Points)로 부르기도 한다.
•
ID Management System (신원 관리 시스템): PDP에 신원 정보를 제공하는 핵심 외부 시스템. 사용자, 디바이스, 서비스의 신원을 관리하고 인증하며, PKI(Public Key Infrastructure)를 통한 인증서 기반 신원 검증 수행
•
Activity Logs (활동 로그): 과거 접근 기록, 사용자 행동 패턴 등 제공
•
CDM System (지속적 진단 및 완화): 자산 상태, 취약점, 패치 수준 등 보안 상태 정보 제공
•
Threat Intelligence (위협 인텔리전스): 실시간 위협 정보, 악성 IP, 공격 패턴 등 제공
•
Industry Compliance (규정 준수): 업계 표준, 법적 요구사항 정보 제공
•
Data Access Policy (데이터 접근 정책): 데이터 분류 및 접근 규칙 제공
•
SIEM System (보안 정보 및 이벤트 관리): 중앙화된 로그 분석, 이상 탐지, 알림
• CDM: Continuous Diagnostics and MitigationSIEM: Security Information and Event Management
• SIEM: Security Information and Event Management
Istio를 통한 ZTA 구현
Istio는 위 NIST SP 800-207 Logical Components of Zero Trust Architecture를 구현하기 위한 도구 중 하나로, 동 문서가 논하는 micro-segmentation 접근 방식에 해당한다.
Istio의 보안 features
1.
모든 통신의 암호화 (mTLS): Istio는 클러스터 내 모든 서비스 간 통신에 상호 TLS(mutual TLS)를 적용한다. 이를 통해 평문 통신을 제거하고, 통신 양측이 서로의 신원을 암호학적으로 검증한다.
2.
강력한 신원 관리 (SPIFFE/SVID): Istio는 SPIFFE(Secure Production Identity Framework for Everyone) 표준을 사용하여 각 서비스에 고유한 신원(SPIFFE ID)을 부여한다. 이 신원은 네트워크 위치(IP 주소)가 아닌 Kubernetes Service Account 기반의 논리적 신원으로, 파드가 재시작되거나 IP가 변경되어도 일관성을 유지한다.
3.
세밀한 접근 제어 (AuthorizationPolicy): Istio의 AuthorizationPolicy는 L7 수준의 접근 제어를 제공한다. HTTP 메서드, URL 경로, 헤더 값, JWT 클레임 등을 기반으로 세밀한 정책 정의를 통해 ZTA의 최소 권한 원칙(Principle of Least Privilege)을 구현 가능하게 한다.
4.
동적 정책 관리: Istio의 컨트롤 플레인(Istiod)은 모든 Sidecar 프록시에 정책을 동적으로 배포하고 업데이트한다. 서비스가 추가되거나 변경되어도 정책은 자동 적용되며, OPA(Open Policy Agent)와 같은 외부 정책 엔진과 통합하여 실시간 컨텍스트 기반 접근 제어가 가능하다.
5.
가시성 및 관찰성 (Observability): Istio는 모든 서비스 간 통신에 대한 로그, 메트릭, 분산 추적 데이터를 수집한다. 이를 통해 비정상적인 접근 실시간 탐지 가능해진다. 상세 내용은 Istio overview: Observability 를 참고한다.
Istio overview: Observability 를 참고한다.6.
보안 정책의 투명한 적용: Istio는 각 파드에 Istio Proxy를 주입하거나(sidecar mode), Waypoint를 통해(ambient mode), 애플리케이션 코드 수정 없이 모든 인바운드/아웃바운드 트래픽을 가로채고 보안 정책을 적용한다.
Istio 구성 요소와 NIST SP 800-207 구성 요소 간 관계
본 글 맨 앞의 그림은 Istio 구성 요소와 NIST SP 800-207의 ZTA 구성요소 간의 관계를 나타낸다. 이를 표로 정리하자면 다음과 같다.
NIST SP 800-207 ZTA 구성요소 | 비고 | Istio / OPA | 역할 |
PDP - Policy Engine (PE) | 핵심 구성요소 | OPA (Open Policy Agent) | 정책 결정 |
PDP - Policy Administrator (PA) | 핵심 구성요소 | Istio: Istiod | 정책 관리 |
PEP | 핵심 구성요소 | Istio: istio-proxy / Waypoint | 정책 수행 |
PKI, ID Management | PIPs | Istio: Istiod (SPIFFE, Citadel) | 신원 관리 |
Activity Logs | PIPs | Istio: Istio Access Log | 감사 로그 |