Amazon EKS에서 NGINX App Protect로 Shift Left Security 방법

이번 포스트에서는 Amazon EKS에서 NGINX App Protect로 Shift Left Security 하는 방법을 설명합니다.

2022년 애플리케이션 전략 현황 보고서에 따르면 기업의 디지털 혁신은 전 세계적으로 계속해서 가속화되고 있습니다. 대부분의 기업은 여러 클라우드 영역에 걸쳐 200~1,000개의 애플리케이션을 배포하며 오늘날의 애플리케이션은 Monolithic에서 최신 분산 아키텍처로 전환하고 있습니다.

Kubernetes는 불과 6년 전인 2016년에 처음으로 기술 분야에 진입했습니다. 그러나 오늘날 전 세계 조직의 75% 이상이 Production 환경에서 컨테이너화된 애플리케이션을 실행하고 있으며 이는 2019년보다 30% 증가한 수치입니다. Amazon Elastic Kubernetes Service(EKS)를 포함한 Kubernetes 환경에서 중요한 문제 중 하나는 보안입니다. 애플리케이션 개발 프로세스가 끝날 때 보안이 “Bolted On”되는 경우가 너무 많으며 때로는 컨테이너화된 애플리케이션이 이미 가동되고 실행되기 전까지 보안이 적용되지 않는 경우도 있습니다.

COVID‑19 팬데믹으로 가속화된 현재 디지털 전환 물결은 많은 기업이 보안에 대해 보다 전체적인 접근 방식을 취하고 “Shift Left” 전략을 고려하도록 강요했습니다. 보안을 Shift Left한다는 것은 소프트웨어 개발 수명 주기(SDLC) 초기에 보안 조치를 도입하고 애플리케이션, 컨테이너, Microservices 및 API에 대한 CI/CD Pipeline의 모든 단계에서 보안 도구 및 제어를 사용하는 것을 의미합니다. 이는 DevSecOps라는 새로운 패러다임으로의 전환을 의미하며 DevSecOps 프로세스에 보안이 추가되고 최신 소프트웨어 애플리케이션 개발 및 제공의 전형적인 빠른 릴리스 주기에 통합됩니다.

DevSecOps는 중요한 문화적 변화를 나타냅니다. 보안 및 DevOps팀은 고품질 제품을 빠르고 안전하게 시장에 출시한다는 공통의 목적을 가지고 작업합니다. 개발자는 더 이상 Workflow을 중단시키는 보안 절차로 인해 매번 방해를 받지 않습니다. 또한 보안 팀은 더 이상 동일한 문제를 반복적으로 수정하지 않습니다. 이를 통해 조직은 강력한 보안 상태를 유지하고 취약성, 잘못된 구성, 규정 준수 또는 정책 위반을 포착하고 방지할 수 있습니다.

Shift Left Security하고 보안을 코드로 자동화하면 처음부터 Amazon EKS 환경을 보호할 수 있습니다. Kubernetes 기반을 구축하는 데 있어 규모에 맞게 Production을 준비하는 방법을 배우는 것이 중요합니다. Amazon EKS의 적절한 거버넌스(Governance)는 비즈니스 전반에 걸쳐 효율성, 투명성 및 책임성을 높이는 동시에 비용을 통하는 ​​데 도움이 됩니다. 강력한 거버넌스 및 보안 Guardrails은 클러스터를 더 잘 파악하고 제어할 수 있는 프레임워크를 제공합니다. 이러한 조치가 없으면 조직은 보안 침해의 위험과 수익 및 평판 손상과 관련된 과도한 비용에 더 많이 노출됩니다.

목차

1. GitOps로 Amazon EKS의 보안 자동화
2. NGINX App Protect 및 NGINX Ingress Controller는 Amazon EKS에서 애플리케이션과 API를 보호합니다.
3. Amazon EKS에서 NGINX App Protect 및 NGINX Ingress Controller를 배포하는 방법
3-1. NGINX CRD로 로깅 구성
3-2. NGINX CRD로 WAF 정책 정의
4. 결론

1. GitOps로 Amazon EKS의 보안 자동화

자동화는 DevSecOps의 중요한 지원 요소이며, 빠른 개발 및 구축 속도에서도 일관성을 유지할 수 있도록 지원합니다. 코드형 인프라와 마찬가지로 코드형 보안 방식으로 자동화하려면 선언적 정책을 사용하여 원하는 보안 상태를 유지해야 합니다.

GitOps는 자동화를 촉진하여 애플리케이션 제공 및 클러스터 관리를 지원하고 단순화하는 운영 프레임워크입니다. GitOps의 주요 아이디어는 코드로 정의된 Kubernetes 객체 및 Kubernetes에서 실행되는 애플리케이션의 선언적 정책을 저장하는 Git Repository를 갖는 것입니다. 자동화된 프로세스는 Production 환경이 저장된 모든 상태 설명과 일치하도록 GitOps 패러다임을 완성합니다.

Repository는 보안 정책의 형태로 소스 역할을 하며 CI/CD Pipeline 프로세스의 일부로 선언적 코드 구성 설명에 의해 참조됩니다. 예를 들어, NGINX는 NGINX App Protect에 대한 Ansible 역할을 가진 GitHub Repository를 유지 관리합니다. 이는 Shift Left Security 전환하려는 팀을 돕는 데 유용할 것으로 기대합니다.

이러한 Repository를 사용하면 새 애플리케이션을 배포하거나 기존 애플리케이션을 업데이트하는 데 필요한 모든 작업은 Repository를 업데이트하는 것입니다. 자동화된 프로세스는 구성 적용 및 성공적인 업데이트 확인을 포함하여 다른 모든 것을 관리합니다. 이를 통해 개발자를 위한 버전 제어 시스템에서 모든 작업이 수행되고 비즈니스 크리티컬 애플리케이션(Business Critical Applications)의 보안을 적용하기 위해 동기화됩니다.

GitOps는 Amazon EKS에서 실행할 때 보안을 원활하고 강력하게 만드는 동시에 사람의 실수를 실질적으로 제거하고 시간이 지남에 따라 적용되는 모든 버전 변경 사항을 추적합니다.

NGINX App Protect를 통해 소프트웨어 개발 Lifecycle의 모든 단계에서 보안을 코드로 전환할 수 있습니다.

2. NGINX App Protect 및 NGINX Ingress Controller는 Amazon EKS에서 애플리케이션과 API를 보호합니다.

Kubernetes 보안 정책을 위한 강력한 설계는 SecOps와 DevOps 모두의 요구 사항을 수용하고 환경이 확장됨에 따라 적응하기 위한 준비를 포함해야 한다. Kubernetes 클러스터는 다양한 방법으로 공유할 수 있습니다. 예를 들어, 클러스터에는 여러 애플리케이션이 실행되고 리소스를 공유할 수 있으며, 다른 경우에는 각각 다른 최종 사용자 또는 그룹에 대한 하나의 애플리케이션 인스턴스가 여러 개 있을 수 있습니다. 이는 보안 경계가 항상 명확하게 정의되지 않으며 유연하고 세분화된 보안 정책이 필요함을 의미합니다.

전체적인 보안 설계는 예외를 수용할 수 있을 만큼 유연해야 하고 CI/CD Pipeline에 쉽게 통합되어야 하며 멀티 테넌시(Multi-tenancy)를 지원해야 합니다. Kubernetes의 맥락에서 테넌트(Tenant)는 특정 비즈니스 단위, 팀, 사용 사례 또는 환경과 연결된 Kubernetes 개체 및 애플리케이션의 논리적 그룹입니다. 멀티 테넌시란 여러 테넌트가 동일한 클러스터를 안전하게 공유하는 것을 의미하며 테넌트 간의 경계는 비즈니스 요구 사항과 밀접하게 연결된 기술 보안 요구 사항에 따라 적용됩니다.

Amazon EKS에서 지연 시간이 짧은 고성능 보안을 구현하는 쉬운 방법은 NGINX Ingress Controller와 함께 NGINX App Protect WAF 및 DoS 모듈을 포함하는 것입니다. 다른 경쟁업체들은 이러한 유형의 Inline Solution을 제공하지 않습니다. 동기화된 기술이 적용된 하나의 제품을 사용하면 컴퓨팅 시간, 비용 절감 및 무분별한 도구 확장 감소를 비롯한 여러 이점을 얻을 수 있습니다. 여기 몇 가지 추가적인 이점이 있습니다.

• 애플리케이션 경계 보안 – 잘 설계된 Kubernetes 배포 환경에서 NGINX Ingress Controller는 Kubernetes 내에서 실행되는 서비스로 흐르는 Data Plane 트래픽의 유일한 Entry Point이므로 WAF 및 DoS 보호를 위한 이상적인 위치입니다.
• Data Plane 통합 – NGINX Ingress Controller 내에 WAF를 내장하면 별도의 WAF 장치가 필요하지 않습니다. 이를 통해 복잡성, 비용 및 장애 지점 수를 줄일 수 있습니다.
• Control Plane 통합 – WAF 및 DoS 구성은 Kubernetes API로 관리할 수 있으므로 CI/CD 프로세스를 훨씬 쉽게 자동화할 수 있습니다. NGINX Ingress Controller 구성은 Kubernetes 역할 기반 액세스 제어(RBAC) 사례를 준수하므로 WAF 및 DoS 구성을 전담 DevSecOps팀에 안전하게 위임할 수 있습니다.

NGINX App Protect WAF 및 DoS에 대한 구성 개체는 NGINX Ingress Controller와 NGINX Plus 모두에서 일관됩니다. 마스터 구성은 두 장치 모두에 쉽게 변환 및 배포할 수 있으므로 WAF 구성을 코드로 관리하고 모든 애플리케이션 환경에 배포하는 것이 더욱 쉬워집니다.

NGINX App Protect WAF 및 DoS를 NGINX Ingress Controller에 Build하려면 NGINX Plus 및 NGINX App Protect WAF 또는 DoS에 대한 구독이 모두 있어야 합니다. 통합 NGINX Ingress Controller 이미지(Docker 컨테이너)를 Build할 수 있습니다. 이미지를 배포한 후(예: 수동으로 또는 Helm 차트 사용) 익숙한 Kubernetes API를 사용하여 보안 정책 및 구성을 관리할 수 있습니다.

NGINX Ingress Controller의 NGINX App Protect WAF 및 DoS는 애플리케이션 및 API 트래픽을 Amazon EKS에서 실행되는 Pod 및 Microservices로 라우팅합니다.

NGINX Plus를 기반의 NGINX Ingress Controller는 인증, RBAC 기반 권한 부여, Pod와 외부 상호 작용에 대한 세부적인 제어 및 관리를 제공합니다. 클라이언트가 HTTPS를 사용하는 경우 NGINX Ingress Controller는 TLS를 종료하고 트래픽을 해독하여 Layer 7 라우팅을 적용하고 보안을 강화할 수 있습니다.

그런 다음 NGINX App Protect WAF 및 NGINX App Protect DoS를 배포하여 Layer 7의 포인트 공격으로부터 보호하는 보안 정책을 적용할 수 있습니다. NGINX App Protect WAF는 OWASP Top 10 공격으로부터 Kubernetes 애플리케이션을 보호하고 개인 식별 정보(PII)의 악용에 대한 고급 서명 및 위협 보호, 봇 방어 및 Dataguard 보호를 제공합니다. NGINX App Protect DoS는 Layer 4 및 7에서 추가 방어선을 제공하여 사용자 동작 분석 및 애플리케이션 상태 확인을 통해 정교한 애플리케이션 Layer DoS 공격을 완화하여 Slow POST, Slowloris, Flood 공격 및 Challenger Collapsar를 포함한 공격으로부터 보호합니다.

이러한 보안 조치는 REST API와 웹 브라우저를 사용하여 액세스하는 애플리케이션을 모두 보호합니다. API 보안은 North‑South 트래픽 흐름에 따라 Ingress Level에서도 적용됩니다.

NGINX App Protect WAF 및 DoS가 포함된 NGINX Ingress Controller는 서비스별이 아닌 요청별로 Amazon EKS 트래픽을 보호할 수 있습니다. 이는 Layer 7 트래픽에 대한 보다 유용하게 적용하며 SLA 및 North-South WAF를 적용하는 훨씬 더 나은 방법입니다.

NGINX App Protect WAF 및 DoS가 포함된 NGINX Ingress Controller는 North-South 트래픽을 Amazon EKS의 노드로 라우팅합니다.

GigaOm의 최신 고성능 웹 애플리케이션 방화벽 테스트 보고서는 NGINX App Protect WAF가 고성능 및 짧은 대기 시간을 유지하면서 지속적으로 강력한 애플리케이션 및 API 보안을 일관되게 제공하고 테스트한 다른 세 가지 WAF(AWS WAF, Azure WAF 및 Cloudflare WAF)보다 뛰어난 성능을 보여줍니다.

예를 들어 아래 그림은 WAF가 초당 500개의 요청을 처리해야 하는 테스트 결과를 보여주는데, 유효한 요청은 95%(475 RPS), “불량” 요청은 5%(25 RPS)(Simulating Script Injection)입니다. 99번째 백분위수에서 NGINX App Protect WAF의 대기 시간은 AWS WAF보다 10배, Cloudflare WAF보다 60배, Azure WAF보다 120배 짧았습니다.

불량 트래픽이 5%인 475 RPS의 지연 시간

아래 그림은 각 요청에 대해 30 ms 미만의 대기 시간으로 100% 성공(5xx 또는 429 오류 없음)에서 달성한 각 WAF의 최고 처리량을 보여줍니다. NGINX App Protect WAF는 14,000 RPS에서 19,000 RPS 대 Cloudflare WAF를 처리했고, AWS WAF는 6,000 RPS, Azure WAF는 2,000 RPS에 불과했습니다.

100% 성공률의 최대 처리량(throughput)

3. Amazon EKS에서 NGINX App Protect 및 NGINX Ingress Controller를 배포하는 방법

NGINX App Protect WAF 및 DoS는 완전 선언형 구성 및 보안 정책을 포함하는 애플리케이션 중심 보안 접근 방식을 활용하여 Amazon EKS의 애플리케이션 Lifecycle에 맞는 보안을 CI/CD Pipeline에 쉽게 통합할 수 있습니다.

NGINX Ingress Controller는 웹 애플리케이션 보안의 모든 측면을 관리하고 공유 책임 및 멀티 테넌트(Multi Tenant) 모델을 지원하는 여러 사용자 지정 리소스 정의(CRD)를 제공합니다. CRD Manifest는 둘 이상의 작업 그룹에 의한 소유권을 지원하기 위해 조직에서 사용하는 Namespace 그룹에 따라 적용될 수 있습니다.

Amazon EKS에 애플리케이션을 게시할 때 이미 사용 중인 자동화 Pipeline을 활용하고 그 위에 WAF 보안 정책을 계층화하여 보안을 구축할 수 있습니다.

또한 NGINX Ingress Controller에서 NGINX App Protect를 사용하면 CPU 및 메모리 사용률에 대한 리소스 사용 임계값을 구성하여 NGINX App Protect가 다른 프로세스를 부족하게 하지 않도록 방지할 수 있습니다. 이는 리소스 공유에 의존하고 잠재적으로 ‘Noisy Neighbor’ 문제가 발생할 수 있는 Kubernetes와 같은 멀티 테넌트 환경에서 특히 중요합니다.

3-1. NGINX CRD로 로깅 구성

NGINX App Protect 및 NGINX Ingress Controller의 로그는 보안 팀이 일반적으로 DevOps 및 애플리케이션 소유자와 독립적으로 운영되는 방식을 반영하기 위해 설계상 분리되어 있습니다. 매개변수를 syslog Pod의 클러스터 IP 주소에 대한 app-protect-security-log-destination 주석으로 설정하여 NGINX App Protect 로그를 Kubernetes Pod에서 도달할 수 있는 모든 syslog 대상으로 보낼 수 있습니다. 또한 APLogConf 리소스를 사용하여 관심이 있는 NGINX App Protect 로그와 syslog Pod에 Push되는 로그를 지정할 수 있습니다. NGINX Ingress Controller 로그는 모든 Kubernetes 컨테이너와 마찬가지로 로컬 표준 출력으로 전달됩니다.

이 샘플 APLogConf 리소스는 악의적인 요청뿐만 아니라 모든 요청이 기록되도록 지정하고 기록할 수 있는 최대 메시지 및 요청 크기를 설정합니다.

apiVersion: appprotect.f5.com/v1beta1 
kind: APLogConf 
metadata: 
 name: logconf 
 namespace: dvwa 
spec: 
 content: 
   format: default 
   max_message_size: 64k 
   max_request_size: any 
 filter: 
   request_type: all

3-2. NGINX CRD로 WAF 정책 정의

APPolicy 정책 개체는 선언적 접근 방식을 기반으로 하는 서명 집합 및 보안 규칙을 사용하여 WAF 보안 정책을 정의하는 CRD입니다. 이 접근 방식은 NGINX App Protect WAF 및 DoS 모두에 적용되며 다음 예제는 WAF에 중점을 둡니다. 정책 정의는 일반적으로 SecOps 카탈로그의 일부로 조직의 정보 소스에 저장됩니다.

apiVersion: appprotect.f5.com/v1beta1 
kind: APPolicy 
metadata: 
  name: sample-policy
spec: 
  policy: 
    name: sample-policy 
    template: 
      name: POLICY_TEMPLATE_NGINX_BASE 
    applicationLanguage: utf-8 
    enforcementMode: blocking 
    signature-sets: 
    - name: Command Execution Signatures 
      alarm: true 
      block: true
[...]

보안 정책 Manifest가 Amazon EKS 클러스터에 적용되면 log-violations라는 APLogConf 객체를 생성하여 요청이 WAF 정책을 위반할 때 로그에 기록되는 항목의 유형과 형식을 정의합니다.

apiVersion: appprotect.f5.com/v1beta1 
kind: APLogConf 
metadata: 
  name: log-violations
spec: 
  content: 
    format: default 
    max_message_size: 64k 
    max_request_size: any 
  filter: 
    request_type: illegal

그런 다음 waf-policy 정책 객체는 애플리케이션이 NGINX Ingress Controller에 의해 노출될 때 들어오는 트래픽을 시행하기 위해 NGINX App Protect WAF에 대한 샘플 정책을 참조합니다. logDest 필드에 지정된 syslog 서버로 전송되는 로그 항목의 형식을 정의하기 위해 log-violations를 참조합니다.

apiVersion: k8s.nginx.org/v1 
kind: Policy 
metadata: 
  name: waf-policy 
spec: 
  waf: 
    enable: true 
    apPolicy: "default/sample-policy" 
    securityLog: 
      enable: true 
      apLogConf: "default/log-violations" 
      logDest: "syslog:server=10.105.238.128:5144"

DevOps가 Amazon EKS에서 애플리케이션을 노출하도록 NGINX Ingress Controller를 구성하는 VirtualServer 객체를 게시하면 배포가 완료됩니다.

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: eshop-vs
spec:
  host: eshop.lab.local
  policies:
  - name: default/waf-policy
  upstreams:
  - name: eshop-upstream
    service: eshop-service
    port: 80
  routes:
  - path: /
    action:
      pass: eshop-upstream

VirtualServer 객체를 사용하면 SecOps가 포괄적인 보안 정책 카탈로그를 제공하고 DevOps가 이에 의존하여 처음부터 보안을 전환하는 공유 책임 모델을 유지하면서 Amazon EKS에서 실행되는 컨테이너화된 애플리케이션을 쉽게 게시하고 보호할 수 있습니다. 이를 통해 조직은 DevSecOps 전략으로 전환할 수 있습니다.

4. 결론

수년에 걸쳐 구축된 레거시(Legacy) 애플리케이 및 보안 솔루션을 보유한 기업의 경우 Amazon EKS에 남아 있는 보안을 전환하는 것은 점진적인 프로세스일 가능성이 높습니다. 그러나 보안 팀에서 관리 및 유지 관리하고 DevOps에서 사용하는 코드로 보안을 재구성하면 서비스를 더 빠르게 제공하고 운영 준비 상태로 만 수 있습니다.

Amazon EKS에서 North‑South 트래픽을 보호하기 위해 NGINX App Protect WAF가 내장된 NGINX Ingress Controller를 활용하여 Layer 7에서 지점 공격으로부터 보호하고 NGINX App Protect DoS를 Layer 4 및 7에서 DoS 완화에 활용할 수 있습니다.

NGINX App Protect WAF와 함께 NGINX Ingress Controller를 테스트 및 사용해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.