Amazon EKS에서 F5 NGINX App Protect로 보안을 왼쪽으로 이동

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

쿠버네티스가 처음으로 대중적으로 사용되기 시작한 것은 불과 6년 전인 2016년이었습니다. 하지만 오늘날 전 세계 조직의 75% 이상이 프로덕션에서 컨테이너화된 애플리케이션을 실행하고 있으며, 이는 2019년 대비 30% 증가한 수치입니다. Amazon Elastic Kubernetes Service(EKS)를 포함한 Kubernetes 환경에서 가장 중요한 문제 중 하나는 보안입니다. 보안은 앱 개발 프로세스의 마지막에 "추가"되는 경우가 너무 많고, 때로는 컨테이너화된 애플리케이션이 이미 실행된 후에도 추가되지 않는 경우도 있습니다.

COVID‑19 팬데믹으로 인해 가속화된 현재의 디지털 혁신 흐름으로 인해 많은 기업이 보안에 대해 보다 포괄적인 접근 방식을 취하고 "왼쪽으로 이동" 전략을 고려해야 했습니다. 보안을 좌측으로 전환한다는 것은 소프트웨어 개발 라이프사이클(SDLC)의 초기 단계에 보안 조치를 도입하고 애플리케이션, 컨테이너, 마이크로서비스, API에 대한 CI/CD 파이프라인의 모든 단계에서 보안 도구와 제어 기능을 사용하는 것을 의미합니다. 이는 DevSecOps라는 새로운 패러다임으로의 전환을 의미하며, DevOps 프로세스에 보안을 추가하고 현대 소프트웨어 앱 개발 및 제공에서 일반적인 빠른 릴리스 주기에 통합됩니다.

DevSecOps는 상당한 문화적 변화를 나타냅니다. 보안 및 DevOps 팀은 공통된 목표를 가지고 일합니다. 즉, 고품질 제품을 빠르고 안전하게 시장에 출시하는 것입니다. 개발자들은 더 이상 작업 흐름을 멈추게 하는 보안 절차로 인해 매번 어려움을 겪지 않습니다. 보안팀은 더 이상 동일한 문제를 반복해서 해결하지 않아도 됩니다. 이를 통해 조직은 강력한 보안 태세를 유지하고 취약점, 구성 오류, 규정 또는 정책 위반이 발생하는 즉시 이를 포착하고 예방할 수 있습니다.

보안을 좌측으로 이동하고 보안을 코드로 자동화하면 Amazon EKS 환경이 처음부터 보호됩니다. 대규모로 프로덕션에 대비하는 방법을 배우는 것은 Kubernetes 기반을 구축하는 데 있어 중요한 부분입니다. Amazon EKS를 적절하게 거버넌스하면 비용도 통제하는 동시에 기업 전반의 효율성, 투명성, 책임을 강화하는 데 도움이 됩니다. 강력한 거버넌스와 보안 가드레일을 통해 클러스터에 대한 가시성과 제어를 개선할 수 있는 프레임워크가 구축됩니다. 이러한 보안이 없다면 조직은 보안 침해의 위험에 더 많이 노출될 것이고, 이로 인해 수익과 평판이 손상되는 데 따른 장기적 비용이 발생할 것입니다.

보안 우선 전략으로 전환할 때 고려해야 할 사항에 대해 자세히 알아보려면 O'Reilly의 최근 보고서인 Shifting Left for Application Security를 살펴보세요.

GitOps를 사용하여 Amazon EKS의 보안 자동화

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

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

저장소는 보안 정책의 형태로 진실의 원천 역할을 하며, CI/CD 파이프라인 프로세스의 일부로 선언적 구성 코드 설명에서 참조됩니다. 예를 들어 NGINX는 F5 NGINX App Protect에 대한 Ansible 역할이 있는 GitHub 저장소를 유지 관리하는데, 이는 보안을 왼쪽으로 전환하려는 팀에게 도움이 되기를 바랍니다.

이러한 저장소를 사용하면 새로운 애플리케이션을 배포하거나 기존 애플리케이션을 업데이트하려면 저장소를 업데이트하기만 하면 됩니다. 자동화된 프로세스는 구성을 적용하고 업데이트가 성공적으로 수행되도록 하는 등 다른 모든 작업을 관리합니다. 이를 통해 개발자를 위한 버전 제어 시스템에서 모든 작업이 수행되고 비즈니스에 중요한 애플리케이션의 보안이 강화되도록 동기화됩니다.

Amazon EKS에서 GitOps를 실행하는 경우 보안을 원활하고 강력하게 구축하는 동시에 사실상 인적 오류를 없애고 시간 경과에 따라 적용되는 모든 버전 변경 사항을 추적합니다.

NGINX App Protect 및 NGINX Ingress Controller는 Amazon EKS에서 앱과 API를 보호합니다.

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

전반적인 보안 설계는 예외를 수용할 만큼 유연해야 하며 CI/CD 파이프라인에 쉽게 통합되어야 하며 다중 테넌시를 지원해야 합니다. 쿠버네티스 맥락에서 테넌트는 특정 사업부, 팀, 사용 사례 또는 환경과 연관된 쿠버네티스 객체와 애플리케이션의 논리적 그룹입니다. 다중 테넌시는 여러 테넌트가 동일한 클러스터를 안전하게 공유하는 것을 의미하며, 테넌트 간의 경계는 비즈니스 요구 사항과 긴밀하게 연결된 기술적 보안 요구 사항에 따라 적용됩니다.

Amazon EKS에서 저지연, 고성능 보안을 구현하는 쉬운 방법은 NGINX Ingress Controller 에 NGINX App Protect WAF 및 DoS 모듈을 내장하는 것입니다. 다른 경쟁사에서는 이런 유형의 인라인 솔루션을 제공하지 않습니다. 동기화된 기술을 갖춘 하나의 제품을 사용하면 컴퓨팅 시간, 비용, 도구 확산이 줄어드는 등 여러 가지 이점이 있습니다. 추가적인 혜택은 다음과 같습니다.

• 애플리케이션 경계 보안 – 잘 설계된 Kubernetes 배포에서 NGINX Ingress Controller는 Kubernetes 내에서 실행되는 서비스로 흐르는 데이터 평면 트래픽의 유일한 진입점이므로 WAF 및 DoS 보호를 위한 이상적인 위치입니다.
• 데이터 플레인 통합 – NGINX Ingress Controller 내에 WAF를 내장하면 별도의 WAF 장치가 필요 없습니다. 이를 통해 복잡성, 비용, 실패 지점 수가 줄어듭니다.
• 제어 평면 통합 – 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에 구축하려면 NGINX Plus와 NGINX App Protect WAF 또는 DoS에 대한 구독이 모두 있어야 합니다. 몇 가지 간단한 단계만 거치면 통합 NGINX Ingress Controller 이미지 (Docker 컨테이너)를 빌드할 수 있습니다. 이미지를 배포한 후에는(예: 수동으로 또는 Helm 차트를 사용하여) 익숙한 Kubernetes API를 사용하여 보안 정책과 구성을 관리할 수 있습니다.

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

NGINX App Protect WAF 및 NGINX App Protect DoS를 배포하면 가벼운 소프트웨어 보안 솔루션으로 레이어 7의 지점 공격을 차단하는 보안 정책을 시행할 수 있습니다. NGINX App Protect WAF는 Kubernetes 앱을 OWASP Top 10 공격으로부터 보호하고 고급 시그니처 및 위협 보호, 봇 방어, 개인 식별 정보(PII) 악용으로부터 Dataguard 보호 기능을 제공합니다. NGINX App Protect DoS는 사용자 동작 분석과 앱 상태 검사를 통해 정교한 애플리케이션 계층 DoS 공격을 완화하고, Slow POST , Slowloris, 플러드 공격, Challenger Collapsar 등의 공격으로부터 보호하기 위해 4계층과 7계층 에서 추가적인 방어선을 제공합니다.

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

NGINX App Protect WAF 및 DoS를 탑재한 NGINX Ingress Controller는 서비스별이 아닌 요청별로 Amazon EKS 트래픽을 보호할 수 있습니다. 이는 레이어 7 트래픽을 보다 유용하게 볼 수 있으며 SLA와 남북 WAF 보안을 시행하는 훨씬 더 나은 방법입니다.

GigaOm의 최신 고성능 웹 애플리케이션 방화벽 테스트 보고서는 NGINX App Protect WAF가 높은 성능과 낮은 대기 시간을 유지하면서도 지속적으로 강력한 앱 및 API 보안을 제공하는 방식을 보여주며, 모든 테스트된 공격률에서 테스트된 다른 세 가지 WAF(AWS WAF, Azure WAF, Cloudflare WAF)보다 성능이 우수합니다.

예를 들어, 그림 4는 WAF가 초당 500개의 요청(RPS)을 처리해야 하는 테스트 결과를 보여줍니다. 요청의 95%(475 RPS)가 유효하고 요청의 5%(25 RPS)가 "불량"(스크립트 주입 시뮬레이션)입니다. 99번째 백분위수에서 NGINX App Protect WAF의 대기 시간은 AWS WAF보다 10배, Cloudflare WAF보다 60배, Azure WAF보다 120배 짧았습니다.

그림 5는 100% 성공 시 각 WAF가 달성한 최고 처리량을 보여줍니다( 5xx 또는429 각 요청에 대한 지연 시간이 30밀리초 미만으로 오류가 발생합니다. NGINX App Protect WAF는 19,000 RPS를 처리한 반면, Cloudflare WAF는 14,000 RPS, AWS WAF는 6,000 RPS, Azure WAF는 2,000 RPS에 그쳤습니다.

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

NGINX App Protect WAF 및 DoS는 완전한 선언적 구성 및 보안 정책을 갖춘 앱 중심 보안 접근 방식을 활용하므로 Amazon EKS의 애플리케이션 수명 주기 동안 CI/CD 파이프라인에 보안을 쉽게 통합할 수 있습니다.

NGINX Ingress Controller는 웹 애플리케이션 보안의 모든 측면을 관리하고 공유 책임과 다중 테넌트 모델을 지원하기 위해 여러 가지 사용자 정의 리소스 정의 (CRD)를 제공합니다. CRD 매니페스트는 조직에서 사용하는 네임스페이스 그룹화에 따라 적용되어 여러 운영 그룹의 소유권을 지원할 수 있습니다.

Amazon EKS에 애플리케이션을 게시하는 경우 이미 사용 중인 자동화 파이프라인을 활용하고 그 위에 WAF 보안 정책을 적용하여 보안을 구축할 수 있습니다.

또한 NGINX Ingress Controller에서 NGINX App Protect를 사용하면 CPU와 메모리 사용률에 대한 리소스 사용 임계값을 구성하여 NGINX App Protect가 다른 프로세스를 굶기지 않도록 할 수 있습니다. 이는 리소스 공유에 의존하고 잠재적으로 '소음 이웃' 문제로 어려움을 겪을 수 있는 Kubernetes와 같은 다중 테넌트 환경에서 특히 중요합니다.

NGINX CRD로 로깅 구성

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

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

apiVersion: appprotect.f5.com/v1beta1 종류: APLogConf 
메타데이터: 
이름: logconf 
네임스페이스: dvwa 
스펙: 
내용: 
형식: 기본값 
최대 메시지 크기: 64k 
max_request_size: any 
필터: 
request_type: all

NGINX CRD를 사용하여 WAF 정책 정의

APPolicy 정책 객체는 선언적 접근 방식을 기반으로 하는 서명 세트와 보안 규칙을 사용하여 WAF 보안 정책을 정의하는 CRD입니다. 이러한 접근 방식은 NGINX App Protect WAF와 DoS 모두에 적용되는 반면, 다음 예에서는 WAF에 초점을 맞춥니다. 정책 정의는 일반적으로 SecOps 카탈로그의 일부로 조직의 진실 출처에 저장됩니다.

apiVersion: appprotect.f5.com/v1beta1 종류: APPolicy
메타데이터: 
이름: 샘플 정책
스펙: 
정책: 
이름: 샘플 정책 
템플릿: 
이름: POLICY_TEMPLATE_NGINX_BASE 
applicationLanguage: utf-8 
enforcementMode: 차단 
signature-sets: 
- 이름: 명령 실행 서명 
알람: 참 
블록: 참
[...]

Amazon EKS 클러스터에 보안 정책 매니페스트가 적용되면 WAF 정책을 위반하는 요청이 있을 때 로그에 기록되는 항목의 유형과 형식을 정의하기 위해 log-violations 라는 APLogConf 객체를 만듭니다.

apiVersion: appprotect.f5.com/v1beta1 종류: APLogConf 
메타데이터: 
이름: 로그 위반
스펙: 
내용: 
형식: 기본값 
최대 메시지 크기: 64k 
max_request_size: any 
필터: 
request_type: 불법

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

api버전: k8s.nginx.org/v1 종류: 정책 
메타데이터: 
이름: waf-정책 
스펙: 
waf: 
활성화: 참 
apPolicy: "기본/샘플-정책" 
securityLog: 
활성화: 참 
apLogConf: "기본/로그-위반" 
logDest: "syslog:server=10.105.238.128:5144"

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

api 버전: k8s.nginx.org/v1kind: VirtualServer
메타데이터:
이름: eshop-vs
사양:
호스트: eshop.lab.local
정책:
- 이름: default/waf-policy
업스트림:
- 이름: eshop-upstream
서비스: eshop-service
포트: 80
경로:
- 경로: /
작업:
패스: eshop-upstream

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

결론

수년에 걸쳐 기존 앱과 보안 솔루션을 구축해 온 회사의 경우, Amazon EKS로 보안을 전환하는 것은 점진적인 프로세스가 될 가능성이 높습니다. 하지만 보안을 보안 팀이 관리하고 유지하는 코드로 재구성하고 DevOps에서 사용하면 서비스를 더 빠르게 제공하고 프로덕션에 활용할 수 있습니다.

Amazon EKS에서 남북 트래픽을 보호하려면 NGINX App Protect WAF가 내장된 NGINX Ingress Controller를 활용하여 7계층에서 지점 공격을 보호하고 NGINX App Protect DoS를 활용하여 4계층과 7계층 에서 DoS를 완화할 수 있습니다.

NGINX App Protect WAF와 함께 NGINX Ingress Controller를 사용해 보려면 AWS Marketplace 에서 무료 30일 평가판을 시작하거나 당사에 문의하여 사용 사례에 대해 논의하세요 .

NGINX Ingress Controller와 NGINX App Protect WAF 및 Amazon EKS의 DoS를 사용하여 보안 침해를 방지하고 대규모 Kubernetes 앱을 보호하는 방법을 알아보려면 전자책 ' F5 NGINX로 Amazon EKS에 보안 추가' 를 다운로드하세요.

NGINX App Protect WAF가 AWS, Azure, Cloudflare용 기본 WAF보다 성능이 뛰어난 방법에 대해 자세히 알아보려면 GigaOm에서 고성능 웹 애플리케이션 방화벽 테스트 보고서를 다운로드하고 12월 6일에 GigaOm 분석가 Jake Dolezal이 결과를 검토하는 웨비나 에 등록하세요.