Kubernetes에서 제로 트러스트(Zero Trust)를 구현하기 위한 7가지 지침

치명적인 보안 침해 및 랜섬웨어 공격의 끝없는 행진의 결과, 바이든 행정부는 2021년 5월 국가 보안 기술의 개선을 명령하고 특히 제로 트러스트(ZT) 보안 모델의 필요성을 촉구하는 행정 명령으로 가속 페달을 밟았습니다.

NIST(National Institute of Standards and Technology)는 8월에 ZTA(제로 트러스트 아키텍처)를 정의하고 “ZT가 기업의 전반적인 정보 기술 보안 태세를 개선할 수 있는 배포 모델 및 사용 사례”를 탐구하는 백서를 발표했습니다. CISA(Cybersecurity and Infrastructure Security Agency)와 예산 관리국(Office of Management and Budget)을 비롯한 다양한 정부 기관은 구현자가 완전한 ZT 배포로의 여정을 이해하는 데 도움이 되는 성숙도 모델을 포함하여 ZT 구현을 안내하는 문서를 발표하고 있습니다.

Kubernetes 커뮤니티는 end-to-end 암호화 전략의 핵심 구성 요소로서 수년 동안 ZT에 대해 논의해 왔습니다. Service Mesh 제공업체는 ZT를 더 쉽게 구현하기 위해 몇 가지 핵심 사례(mTLS 및 인증서 키 교체 등)를 구현했지만 우리는 여전히 대규모 애플리케이션에서 강력한 ZTA를 구현하는 초기 단계에 있습니다. Kubernetes에서 ZT가 의미하는 것과 모범 사례가 무엇인지에 대한 약간의 논쟁이 남아 있습니다. 기본적으로 Kubernetes는 Kubernetes 네트워킹 및 보안이 기존 IT 및 인프라 시스템과 어떻게 다른지에 대해 교육을 받지 못한 팀에게 심각한 보안 문제를 제시합니다.

목차

1. 제로 트러스트(Zero Trust)란 무엇이며 왜 중요한가요?
2. Kubernetes에서 제로 트러스트를 구현하기 위한 7가지 지침
  2-1. 지침 1: Kubernetes 아키텍처에 복잡성 추가 방지
  2-2. 지침 2: 개발자와 최종 사용자에게 최소한의 Overhead 추가
  2-3. 지침 3: Data Plane과 Control Plane 모두에 ZT 규칙 적용
  2-4. 지침 4: East-West 및 North-South 트래픽에 ZT 시행
  2-5. 지침 5: Ingress Controller와 Service Mesh를 모두 사용
  2-6. 지침 6: Ingress Controller를 Service Mesh와 통합
  2-7. 지침 7: 인증서의 적절한 처리 자동화
3. NGINX를 통한 제로 트러스트: 보이지 않고 편재하며 간편함

1. 제로 트러스트(Zero Trust)란 무엇이며 왜 중요한가요?

기존 보안 모델은 중앙 집중식 게이트키퍼가 사용자 ID를 확인하고 승인된 사용자만 내부 인프라에 액세스할 수 있도록 하여 배포 환경 주변에 강력한 경계를 설정합니다. 마이크로서비스, 클라우드 및 분산 배포가 도입됨에 따라 경계가 어디에 있는지 또는 경계가 있는지 여부가 점점 더 불분명하기 때문에 이 모델은 더 이상 선택 사항이 아닙니다.

ZT 모델에서는 사용자, 애플리케이션, 네트워크, 서버, 서비스, API 등 말 그대로 아무 것도 신뢰할 수 없으며 누구도 신뢰할 수 없습니다. 모든 단일 계층의 모든 단일 요소는 인증을 위해 인증되고 테스트되어야 합니다. 기술 자산, 앱 또는 서비스가 연결하고 데이터를 교환할 때 모든 통신은 모든 당사자를 인증하고 액세스 정책에 따라 권한을 부여하는 지정된 에이전트를 통해 라우팅됩니다. 중요하게도 ZT 시스템은 모든 수준에서 최소 권한 기반으로 작동하여 특정 리소스에 대해 명시적으로 승인된 사람을 제외한 모든 당사자에 대한 액세스를 거부합니다.

ZT의 이점은 다양합니다. 다음을 통해 보안 태세를 개선합니다.

  • 무단 활동 자동 방지
  • 접근 통제를 통해 접근 가능한 공격 표면 감소
  • 행동 이상 및 침해 지표를 신속하게 감지
  • 실시간 최소 권한 정책을 통한 액세스 시간 제한
  • 환경 및 지리를 포함한 다른 모든 변수와 독립적인 보안
  • 지속적인 인증 및 신원 확인을 통한 지속적인 공격 차단

ZT는 클라우드 네이티브 앱 및 인프라에 특히 중요합니다. 느슨하게 결합되고 이식 가능한 클라우드 네이티브 앱은 컨테이너에서 실행되고 필요에 따라 위치와 상태를 변경하도록 설계되었습니다. 코드, 구성 및 클라우드 네이티브 앱을 외부 또는 내부 서비스에 연결하는 IP 주소와 같은 몇 가지 필수 요소를 제외하고는 모든 것이 일시적입니다. east-west 트래픽(환경 내부)과 north-south 트래픽(환경에 들어오고 나가는)은 점점 더 유사해 보입니다. API는 앱 환경 내 및 외부 클라이언트와의 모든 통신을 중재합니다. 권한과 ID를 지속적으로 검증하는 것은 유용할 뿐만 아니라 궁극적으로 보안상의 필수 요소입니다.

2. Kubernetes에서 제로 트러스트를 구현하기 위한 7가지 지침

Kubernetes 기반 인프라 및 애플리케이션에 ZT를 배포하는 것은 어려울 수 있으므로 여기에서 일련의 지침을 제공합니다. 그것들은 명백해 보일 수 있지만 처음부터 구현하는 것은 놀라울 정도로 어려울 수 있습니다.

2-1. 지침 1: Kubernetes 아키텍처에 복잡성 추가 방지

ZT 프레임워크 없이 Kubernetes를 실행하는 것은 어려운 일이며 ZT를 추가하면 상황이 훨씬 더 복잡해질 수 있습니다. 많은 공급업체에서 추가 서비스 또는 기능을 제공하는 기본 방법은 새로운 Sidecar 또는 Kubernetes 사용자 지정 리소스 정의(CRD)를 사용하는 것입니다. 불행히도 이러한 추가는 복잡성을 증가시킵니다. 예를 들어 관찰 가능성 데이터를 전송하기 위해 새 Sidecar를 추가하면 Kubernetes는 네트워크 연결을 한 개 또는 두 개 더 유지해야 합니다. 복잡성이 추가되면 애플리케이션 요구 사항을 수용하기 위해 더 큰 파드(Pod)가 필요하므로 애플리케이션 속도가 느려지고 인프라 비용이 커질 수 있습니다. Occam의 면도날이 여기에 적용됩니다. 사이드카(Sidecar)와 CRD가 가장 적은 ZT로 가는 가장 간단한 경로가 일반적으로 가장 좋습니다.

2-2. 지침 2: 개발자와 최종 사용자에게 최소한의 Overhead 추가

개발자는 ZT에 대해 생각하고 싶지 않으며 만들 이유가 없습니다. ZT를 구현하면 개발자가 행동이나 워크플로를 변경해야 할 때 보안이 느려진다고 생각하기 때문에 뒤로 물러날 가능성이 높습니다. 행동이나 워크플로를 변경하면 인적 오류의 가능성도 크게 높아집니다. “wetware”는 항상 보안 사슬의 약한 고리입니다. NetOps 또는 SecOps 엔지니어는 ZT 메커니즘이 너무 투명하여 개발자가 자신이 있는지조차 모를 정도로 성공했으며 최종 사용자와 고객도 마찬가지입니다. 실제로 ZT는 이론적으로 보안 정책을 더 강력하고 깔끔하게 자동화함으로써 다단계 인증의 추악한 측면과 많은 보안 프로세스의 고정된 느낌을 제거함으로써 최종 사용자 경험을 향상시킬 수 있습니다.

2-3. 지침 3: Data Plane과 Control Plane 모두에 ZT 규칙 적용

Data Plane은 애플리케이션의 “작업이 있는 곳”이지만 Control Plane은 공급망 공격 및 기타 손상에 취약한 경우가 많습니다. 정책 엔진, 원격 측정 및 추적을 위한 데이터 수집 시스템 등과 같은 복잡한 요소로 인해 Data Plane보다 Control Plane에서 ZT 규정 준수를 시행하는 데 더 많은 작업이 필요합니다. Data Plane을 ZT로 만들고 모든 움직이는 부분이 있는 Control Plane에 대해 덜 걱정하고 싶을 수 있지만 ZT의 영향을 최대화하려면 둘 다 규정을 준수하는지 확인해야 합니다.

2-4. 지침 4: East-West 및 North-South 트래픽에 ZT 시행

많은 조직은 환경 외부에서 발생하는 트래픽이 내부 트래픽보다 덜 신뢰할 수 있는 것처럼 보이기 때문에 처음에는 north-south 트래픽에만 ZT를 적용하기로 선택합니다. 이 접근 방식은 실수입니다. Kubernetes에서 east-west 트래픽은 north-south 트래픽과 비슷하게 보이고 작동합니다. Kubernetes Service, Node 및 Pod는 모두 HTTP 또는 HTTPS를 통해 API를 통해 통신합니다. 모든 트래픽에 동일한 ZT 정책 및 프로세스를 적용하는 것이 훨씬 더 안전하며 그렇게 하면 더 많은 Overhead가 발생하지 않습니다. 또한 처음부터 ZT를 모든 곳에 적용하면 north-south ZT 관행이 발전했을 수 있는 east-west ZT를 결합하려는 위험이나 골칫거리를 제거할 수 있습니다.

2-5. 지침 5: Ingress Controller와 Service Mesh를 모두 사용

Ingress Controller나 Service Mesh 없이 Kubernetes에서 애플리케이션을 빌드하고 실행하는 것이 가능합니다. 그러나 ZT를 인프라의 모든 요소에 대한 쉬운 기본 설정으로 만들려면 이 두 가지가 모두 필요합니다. Ingress Controller는 API Gateway 및 Load Balancer의 보다 유용한 기능 중 일부를 통합합니다. 또한 기존의 Load Balancer와 달리 특정 Kubernetes 파드(Pod)로 트래픽을 라우팅할 수 있는 진정한 리버스 프록시처럼 작동한다는 강력한 이점이 있습니다. Service Mesh는 east-west 트래픽에 대한 ZT 시행과 감사 및 검증 목적을 위한 관찰 가능성 및 보고를 근본적으로 단순화합니다. 따라서 ZT로 더 쉽고 깔끔한 경로를 택하려면 Ingress Controller와 Service Mesh를 동시에 설계하십시오.

2-6. 지침 6: Ingress Controller를 Service Mesh와 통합

이것은 지침 5에 가까운 결과입니다. 모든 Ingress Controller가 모든 Service Mesh와 긴밀하게 통합될 수 있는 것은 아닙니다. 예를 들어 Istio 기반 Service Mesh는 NGINX Ingress Controller와 다른 유형의 인증서 관리 시스템을 사용합니다. 설계 단계에서 두 도구가 최소한의 노력으로 긴밀하게 통합될 수 있도록 하면 나중에 상당한 복잡성과 구성 해킹을 피할 수 있습니다.

2-7. 지침 7: 인증서의 적절한 처리 자동화

대부분의 다른 보안 연결 형식의 경우 인증서 유지 관리는 Kubernetes에서 암호화를 위한 PKI(public key infrastructure) 구성 요소를 실행하는 데 중요합니다. ZT 준수를 위해 인증서 관리는 자동화되고 동적이어야 합니다. 즉, 인증서가 만료되고 지속적인 인증을 보장하기 위해 정기적으로 교체됩니다. Service Mesh와 Ingress Controller 모두 자동화된 인증서 발급, 교체 및 만료가 필요합니다. Ingress Controller 또는 Service Mesh용 기본 또는 가장 통합된 인증서 관리 도구가 이 작업을 수행할 수 없는 경우 다른 옵션을 알아내거나 물러나야 합니다.

3. NGINX를 통한 제로 트러스트: 보이지 않고 편재하며 간편함

우리는 ZT의 초기 단계에 있습니다. Kubernetes 채택 파트너가 표시된다면 학습 곡선은 우리가 원하는 것보다 약간 가파르게 됩니다. 하지만 클라우드 네이티브 및 클라우드 호스팅 앱에 대한 추세와 지속적인 사이버 보안 위협으로 인해 머지 않아 ZT로의 전환이 불가피합니다. 상식을 사용하고 ZT용으로 배포하는 시스템에 대해 현명한 선택을 하면 ZT를 가치 있을 뿐만 아니라 보이지 않고 편재하고 쉽게 만드는 최종 목표를 향해 더 빠르고 원활하게 전환할 수 있습니다.

Kubernetes에서 ZT를 활성화하는 것은 쉬운 일이 아니지만 사전에 구운 ZTA 기능과 함께 Ingress Controller 및 Service Mesh를 사용하면 시간과 골칫거리를 절약할 수 있습니다. 지금 바로 Kubernetes 솔루션인 NGINX Service Mesh가 포함된 NGINX Ingress Controller를 시작할 수 있습니다. 이를 통해 간단한 구성 변경을 위한 단 하나의 CLI 명령으로 ZT에 필요한 대부분을 사용할 수 있습니다.