신속한 패치 적용이 어려우신가요? 최후의 방어선, 제로 트러스트

새로운 기능이 추가되고 애플리케이션이 발전하는 속도는 아키텍처의 복잡성을 가중하는 직접적인 요인이 됩니다. 이러한 끊임없는 속도는 새로운 기능에 대한 요구 때문만은 아닙니다. 새로운 취약점이 지속적으로 발견됨에 따라 어쩔 수 없이 빨라지는 측면이 더 큽니다. 각 제품과 솔루션은 수많은 구현 옵션과 활성화/비활성화 가능한 다양한 기능을 제공합니다. 따라서 단일한 중요 종속성에 패치를 적용하면 필수 업데이트가 연쇄적으로 발생하고 아키텍처가 예기치 않게 변경될 수 있습니다. 이러한 복잡성을 특정 환경에 맞게 조정하다 보면 모든 구성 요소가 업계 모범 사례에 따라 배포되도록 보장하기가 어려워집니다. 검증된 패턴(Validated patterns)은 다양한 사용 사례에 대해 즉시 사용 가능하고 엄격한 테스트를 거친 배포 패턴을 제공하여 이러한 격차를 해소합니다. 이를 통해 보안 중심의 복잡한 아키텍처를 처음부터 구축해야 하는 부담을 줄여줍니다.

취약점 관리의 불편한 진실

2025년에는 40,000개가 넘는 새로운 CVE(공통 취약점 및 노출)가 게시되었습니다. 이는 매일 100개가 넘는 수치입니다. 오늘날 AI 기반의 익스플로잇(공략 코드) 생성 기술은 취약점 공개부터 현장에서의 실제 악용까지 걸리는 시간을 획기적으로 단축하고 있습니다. '성배를 쫓는 행위(Chasing the holy grail)'에서 볼 수 있듯, CVE 개수 '0'이라는 완벽한 점수만 추구하는 것은 더 깊이 있는 심층 방어(Defense-in-depth) 전략의 집중을 방해하여 때로는 역효과를 낼 수 있습니다. 오전 9시에 '안전(Clean)'했던 구성 요소가 오후 5시에는 새롭게 공개된 취약점을 가질 수도 있습니다. 알려진 CVE를 모두 해결해 0으로 만들더라도, 알려지지 않은 취약점은 언제나 남아있기 마련입니다.

수백 개의 컨테이너화된 워크로드를 실행하는 엔터프라이즈 환경에서는 '패치 산식(CVE 수가 적을수록 위험도 낮다는 오해)'이 제대로 성립하지 않습니다. 단일 운영 체제에서 실행되는 기존 모놀리식 아키텍처와 달리, 분산 컨테이너 환경은 아키텍처 복잡성이 훨씬 더 높습니다. 수많은 마이크로서비스와 네트워크 접점은 설정 오류가 발생하기 쉬운 다양한 옵션을 제공하며, 이는 의도치 않은 보안 공백으로 이어질 수 있습니다. 모든 문제를 즉시 해결하려는 시도는 현대적인 리스크 기반 보안 전략과 상충하는 '시지프스의 형벌'과 같은 작업입니다. 또한 업데이트를 아무리 신속하게 적용하더라도 항상 시간 차가 발생할 수밖에 없다는 근본적인 사실을 간과하고 있습니다.

그렇다면 취약점 공개와 패치 배포 사이의 공백기에는 어떻게 대응해야 할까요? 그 해답은 수년 전부터 존재해 왔지만 오늘날 더욱 중요해진 보안 원칙인 제로 트러스트 아키텍처에 있습니다. 제로 트러스트 아키텍처

Red Hat OpenShift 클러스터에서 제로 트러스트가 갖는 의미

제로 트러스트는 설치하는 제품이 아닙니다. 이는 침해가 이미 발생했다고 가정하는 아키텍처 철학으로, 모든 상호 작용에 대해 명시적인 검증과 권한 부여를 요구합니다. NIST SP 800-207에 따르면, 제로 트러스트는 자산, 애플리케이션, 사용자 계정 등의 리소스에 대해 물리적 또는 네트워크 위치만을 근거로 부여했던 암묵적 신뢰를 제거하는 것을 의미합니다. 인증과 권한 부여는 엔터프라이즈 리소스에 대한 세션이 설정되기 전에 수행되는 별개의 기능입니다.

쿠버네티스와 Red Hat OpenShift에서 제로 트러스트를 구현하려면 워크로드 ID, 시크릿 관리, 런타임 액세스 제어를 아우르는 다계층 접근 방식이 필요합니다. 특히 네트워킹 영역에서 이 철학이 시사하는 가장 중요한 점은 모든 포드가 자유롭게 통신할 수 있는 기본 플랫 네트워크 구조에서 벗어나는 것입니다. 기본적으로 쿠버네티스는 내부 네트워크 제한을 적용하지 않습니다. 이는 건물에 정문(클러스터 인그레스 컨트롤러, API 게이트웨이, 경계 방화벽 등)이 있다는 이유만으로 건물 내부의 모든 문을 잠그지 않는 것과 같습니다. 하지만 이러한 경계 방어에만 의존하는 방식은 현대적인 클라우드 네이티브 환경에서 근본적으로 한계가 있습니다.

제로 트러스트 모델에서는 보안 침해가 이미 발생했으며, 경계를 우회한 외부 공격자, 손상된 공급망 구성 요소, 내부 위협 등 악의적인 행위자가 이미 환경 내부에 존재한다고 가정합니다. 쿠버네티스 네트워크 리소스 제한을 구현하면 '기본 거부(Default Deny)' 네트워크 연결 환경을 조성할 수 있습니다. 이 환경에서는 네트워크를 사용하거나 연결된 리소스에 접근할 때 명시적인 인증과 권한 부여가 필요합니다(그림 1).

이론에서 실습까지: 계층화된 제로 트러스트 검증 패턴(ZTVP)

이러한 모범 사례를 실제로 적용하기 위해 Red Hat은 계층화된 제로 트러스트 검증 패턴(ZTVP)을 활용합니다. 검증된 패턴은 코드형 인프라(IaC) 모범 사례와 GitOps 자동화를 결합하여, 보안과 확장성을 고려해 설계된 복잡한 OpenShift 배포의 설정 시간을 대폭 단축해 줍니다. 지난 3개월 동안 ZTVP 프로젝트는 상당한 진전을 이루었으며, Tested 티어 인증을 획득했습니다.

이 패턴은 여러 구성 요소를 하나로 통합하여 GitOps 기반의 유기적인 제로 트러스트 아키텍처를 구축합니다.

• 제로 트러스트 워크로드 ID 관리자: SPIFFE/SPIRE 프로젝트를 기반으로 워크로드에 수명이 짧은 암호화 ID를 제공합니다.
• HashiCorp Vault: 보안 우선 방식으로 민감한 자산과 클러스터 시크릿을 저장하며, JWT 인증을 위해 ZTWIM과 통합됩니다.
• Keycloak의 Red Hat 빌드: 사용자 인증 및 페더레이션 ID를 관리합니다.
• Red Hat Advanced Cluster Security for Kubernetes: 지능형 보안 브레인 역할을 하며, 통합 멀티 클러스터 모니터링, 사전 예방적 어드미션 제어, 실시간 이상 동작 감지, 그리고 이번 예시에서 매우 중요한 네트워크 정책 분석기 기능을 제공합니다.

네트워크 정책: 최후의 방어선

네트워크 정책은 흔히 제로 트러스트의 토대로 언급되지만, 그 자체가 원칙은 아닙니다. 대신 제로 트러스트 모델이 지향하는 결과를 실현하기 위해 사용되는 사전 예방적 아키텍처 메커니즘입니다. Red Hat은 제로 트러스트의 4가지 핵심 원칙을 제시하고 있으며, 잘 설계된 네트워크 정책은 이 모든 원칙을 적극적으로 지원합니다.

• 마이크로 세그멘테이션: 네트워크 정책은 개별 포드 수준에서 트래픽을 제어하여 클러스터를 보안이 강화된 세분화된 세그먼트로 나눕니다.
• 최소 권한 액세스: 기본 거부(Default Deny) 설정을 통해 워크로드가 작동하는 데 꼭 필요한 최소한의 네트워크 권한만 부여하고 그 외의 모든 접근은 차단합니다.
• 경계 해제(Deperimeterization): 보안 제어가 단순히 클러스터의 '정문'에 머물지 않고 워크로드 자체에 직접 적용됩니다.
• 보안 침해 가정: 측면 공격 경로를 사전에 차단함으로써, 보안 침해가 발생하더라도 그 피해 범위를 즉각적으로 제한할 수 있는 엄격한 인그레스 및 이그레스 규칙이 이미 마련되어 있습니다.

또한 쿠버네티스 네트워크 정책의 매우 중요한 특징은 보호 대상인 애플리케이션 포드와 분리된 별도의 컨트롤 플레인에 존재한다는 점입니다. 따라서 공격자가 컨테이너를 침해하고 애플리케이션 내에서 높은 권한을 획득하더라도, 자신을 제한하는 네트워크 경계를 임의로 재정의하거나 우회할 수 없습니다. 내부 환경의 전반적인 보안 태세를 강화하고 이러한 원칙을 실제로 구현하려면, 포드 수준에서 인그레스 및 이그레스 트래픽을 모두 제어하는 세밀한 네트워크 정책을 정의해야 합니다.

• 인그레스(Ingress) 정책: 이는 포드로 유입되는 트래픽을 제어하며, 명시적으로 허용된 소스로부터의 연결만 서비스가 수락하도록 강제합니다. 클러스터 내의 인접한 포드가 손상되더라도 강력한 인그레스 정책이 있다면 공격자가 민감한 워크로드로 측면 이동하는 것을 방지할 수 있습니다.
• 이그레스(Egress) 정책: 이는 포드에서 외부로 나가는 트래픽을 제어합니다. 포드가 접근할 수 있는 외부 또는 내부 리소스를 엄격하게 제한하는 것이 목적입니다. 포드가 침해되더라도 이그레스 정책을 통해 데이터 유출, 광범위한 네트워크 정찰, 외부 C&C(Command-and-Control) 서버로부터의 악성 페이로드 다운로드 등을 무력화할 수 있습니다.

기본 거부(Default Deny) 토대

특정한 인그레스 및 이그레스 규칙을 정의하는 것도 중요하지만, 이에만 의존하면 인적 오류나 기만적인 공격이 파고들 수 있는 위험한 공백이 생길 수 있습니다. 기본적으로 쿠버네티스는 '모두 허용(Allow-all)' 모델로 작동하므로, 명시적으로 제한하지 않은 모든 트래픽은 허용됩니다. 개발자가 실수로 정책 적용을 누락하면 해당 포드는 무방비 상태로 노출됩니다. 하지만 위험은 단순한 실수 그 이상입니다. 공급망 공격의 경우, 개발자는 숨겨진 악성 페이로드나 그 위험성을 인지하지 못한 채 손상된 제3자 구성 요소를 배포하는 함정에 빠질 수 있습니다.

기본 거부 정책은 이러한 패러다임을 차단 목록(Blocklist)에서 허용 목록(Allowlist)으로 전환합니다. 모든 상호 작용은 명시적으로 권한을 부여받아야 한다는 제로 트러스트의 핵심 원칙에 따라, 어떠한 접근도 암묵적으로 허용되어서는 안 된다는 결론에 이르게 됩니다. 처음부터 모든 트래픽을 엄격히 차단하는 기본 거부 설정을 도입하면, 실수로 정책을 누락하거나 교묘하게 위장한 악성 컨테이너가 외부 연결을 시도하더라도 이를 안전하게 차단할 수 있는 환경이 조성됩니다. 설계 단계부터 명시적으로 액세스 권한을 부여하도록 강제함으로써, 자칫 치명적인 보안 사고로 이어질 수 있는 침해 시도를 눈에 띄고 수정 가능한 배포 오류로 전환해 줍니다.

이 방식은 단순하지만 강력한 규칙에서 시작됩니다. 기본적으로 모든 트래픽을 거부합니다. 모든 네임스페이스에는 명시적인 허용 정책이 없는 한 모든 포드의 인그레스 및 이그레스 트래픽을 차단하는 기본 거부 NetworkPolicy가 적용됩니다.

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata:   name: default-deny-in-namespace spec:   podSelector: {}   policyTypes:   - Ingress   - Egress

NetworkPolicy가 네임스페이스의 포드를 대상으로 지정하는 즉시, 해당 포드는 더 이상 제한 없는 액세스 권한을 갖지 못하게 됩니다. 기본적으로 액세스를 차단하는 정책을 정의함으로써 제로 트러스트의 '기본 거부' 태세와 일치하게 됩니다.

패치를 적용할 수 없는 상황에서 이것이 중요한 이유

악명 높았던 Log4j 위기나 최근 React2Shell 취약점(CVE-2025-55182)과 같은 프레임워크 보안 사고를 떠올려 보십시오.

1. 사용 중인 애플리케이션의 공통 라이브러리에서 심각한 원격 코드 실행(RCE) 취약점이 갑자기 발견되었습니다.
2. 공격자가 영향을 받는 서비스에 특수하게 제작된 요청을 보내기만 해도 서버 전체를 장악할 수 있는 취약점입니다.
3. 이 라이브러리는 종속성 깊숙이 자리 잡고 있어, 검증된 패치를 테스트하고 프로덕션 환경에 배포하는 데 며칠이 소요될 수 있습니다.

제로 트러스트 네트워크 정책을 갖춘 조직이라면 그 영향은 다음과 같이 최소화됩니다.

• 어떤 포드라도 침해한 공격자는 네임스페이스를 넘나들며 취약한 서비스에 쉽게 도달할 수 있습니다(측면 격리 부재).
  • ZTVP 네트워크 정책을 적용한 경우: 공격자는 다른 네임스페이스에서 서비스에 접근할 수 없습니다(네임스페이스 격리).
• 공격자는 중요 포트나 관리 포트를 포함하여 서비스에 노출된 모든 포트에 연결할 수 있습니다(포트 수준 필터링 부재).
  • ZTVP 네트워크 정책을 적용한 경우: 공격자는 명시적으로 허용되지 않은 포트에는 연결할 수 없습니다(포트 수준 필터링).
• 공격자는 자유롭게 아웃바운드 연결을 생성하여 데이터를 유출하거나 C2(Command and Control) 채널을 구축할 수 있습니다(이그레스 제한 부재).
  • ZTVP 네트워크 정책을 적용한 경우: 공격자는 외부 엔드포인트로 데이터를 유출할 수 없습니다(이그레스 제한).

데모: 공격 경로 제거

올바르게 구현된 네트워크 정책이 공격 경로를 어떻게 능동적으로 차단하는지 확인할 수 있는 데모 영상을 준비했습니다. 먼저 기본 거부 설정이 없는 환경을 살펴봅니다. 여기서는 공급망 취약점을 악용한 공격자가 손쉽게 광범위한 정찰을 수행하고, 네트워크 내의 패치되지 않은 다른 구성 요소를 자유롭게 탐색하여 공격할 수 있습니다. 반면 엄격한 네트워크 정책을 적용하면 상황은 완전히 달라집니다.

공격자가 포드 침해에 성공하더라도 네트워크를 조사하거나 취약점을 스캔하고 측면으로 이동할 수 있는 능력이 완전히 무력화됩니다. 네트워크 정책이 공격을 침해된 컨테이너 내로 제한하여 위협을 효과적으로 억제하므로, 수정 조치를 취하는 데 필요한 귀중한 시간을 벌 수 있습니다. 통합 보안 전략에서 네트워크 정책이 유일한 해결책은 아닐지라도, 엄격한 네트워크 경계를 설정하는 것은 최후의 방어선을 구축하기 위한 가장 훌륭한 시작점입니다.

이 데모는 네트워크 정책이 공격을 침해된 컨테이너로 제한하여 위협을 효과적으로 억제하고, 대응 조치를 구현하는 데 필요한 시간을 확보하는 방법을 보여줍니다.

종합적인 접근 방식: 심도 있는 보안 대책

네트워크 정책은 포괄적인 보안 전략의 한 계층에 불과합니다. 계층화된 제로 트러스트 검증 패턴은 이러한 정책을 SPIFFE/SPIRE 워크로드 ID(제로 트러스트 워크로드 ID 관리자 사용), Vault 관리 시크릿, Keycloak의 Red Hat 빌드와 같은 ID 제공업체(IdP)를 통한 중앙 집중식 인증, 그리고 Red Hat Advanced Cluster Security for Kubernetes의 런타임 모니터링과 결합합니다. 네트워크 정책은 ID, 시크릿, 애플리케이션 보안이 뚫리더라도 네트워크 계층에서 위협을 억제하도록 보장함으로써 전체적인 방어 체계를 완성합니다.

하지만 네트워크 정책이 실제로 작동하고 있는지, 혹은 침해된 컨테이너가 내부 경계를 반복적으로 탐색하고 있지는 않은지 어떻게 알 수 있을까요? 제로 데이 익스플로잇으로 인해 연결이 거부되면 어떤 일이 발생할까요?

Red Hat은 이 블로그 시리즈를 통해 계층화된 제로 트러스트 검증 패턴이 제로 트러스트 보안 사례를 구현하는 방법을 살펴보며 이러한 중요한 질문들에 대한 답을 제시할 예정입니다. 앞으로 다룰 내용은 다음과 같습니다.

• Red Hat Advanced Cluster Security for Kubernetes를 통한 능동적 방어: 심층적인 런타임 모니터링, 자동화된 네트워크 정책 스캔, 실시간 알림을 구현하여 중앙 보안 브레인 역할을 수행하는 방법을 알아봅니다.
• ID 및 시크릿: 제로 트러스트 워크로드 ID 관리자와 Vault 통합을 통해 워크로드 ID를 더욱 안전하게 관리하는 방법을 다룹니다.
• 공급망: 콘텐츠 서명을 강제하고 파이프라인 태스크를 검증하여, 신뢰할 수 있는 코드만 클러스터에 도달하도록 소프트웨어 공급망을 종단 간으로 보호하는 방법을 살펴봅니다.

실제로 확인해 볼 준비가 되셨나요? 다음 기사가 나올 때까지 기다릴 필요 없이 지금 바로 시작해 보세요. 계층화된 제로 트러스트 검증 패턴을 통해 아키텍처를 확인하고, 네트워크 정책 데모를 직접 체험해 보시기 바랍니다.

참고 자료

• NIST SP 800-207: 제로 트러스트 아키텍처
• NIST SP 800-207A: 클라우드 네이티브 애플리케이션을 위한 제로 트러스트
• CISA: 제로 트러스트 마이크로 세그멘테이션 지침
• 계층화된 제로 트러스트 검증 패턴
• 검증된 패턴
• 성배 추구(Chasing the Holy Grail): Red Hat의 Hummingbird 프로젝트가 제로에 가까운 CVE를 목표로 하는 이유
• CVE 지표