F5의 2022년 애플리케이션 전략 현황 보고서에 따르면, 전 세계적으로 기업의 디지털 트랜스포메이션이 계속 가속화되고 있습니다. 대부분의 기업은 여러 클라우드 영역에 걸쳐 200~1,000개의 앱을 배포하고 있으며, 오늘날의 앱은 모놀리식 구조에서 현대적인 분산 아키텍처로 전환되고 있습니다.
Kubernetes가 주류 기술로 처음 등장한 것은 불과 6년 전인 2016년입니다. 하지만 오늘날 전 세계 조직의 75% 이상이 프로덕션 환경에서 컨테이너화된 애플리케이션을 실행하고 있으며, 이는 2019년보다 30% 증가한 수치입니다. Amazon Elastic Kubernetes Service(EKS)를 비롯한 Kubernetes 환경에서 가장 중요한 문제 중 하나는 보안입니다. 보안은 애플리케이션 개발 프로세스의 마지막 단계에서 뒤늦게 추가되는 경우가 너무 많으며, 때로는 컨테이너화된 애플리케이션이 이미 가동된 후에야 적용되기도 합니다.
COVID‑19 팬데믹으로 가속화된 현재의 디지털 트랜스포메이션 물결로 인해 많은 기업이 보안을 보다 종합적인 관점에서 접근하고 ‘시프트 레프트’ 전략을 고려하게 되었습니다. 보안 시프트 레프트란 소프트웨어 개발 수명 주기(SDLC)의 초기 단계부터 보안 조치를 도입하고 애플리케이션, 컨테이너, 마이크로서비스 및 API를 위한 CI/CD 파이프라인의 모든 단계에서 보안 도구와 제어 기능을 사용하는 것을 의미합니다. 이는 DevSecOps라는 새로운 패러다임으로의 전환을 뜻합니다. DevSecOps에서는 DevOps 프로세스에 보안을 추가하고, 최신 소프트웨어 애플리케이션의 개발 및 제공에서 일반적으로 사용되는 빠른 릴리스 주기에 보안을 통합합니다.
DevSecOps는 중대한 문화적 변화를 의미합니다. 보안 팀과 DevOps 팀은 고품질 제품을 빠르고 안전하게 시장에 출시한다는 공동의 목표를 위해 협력합니다. 개발자는 더 이상 워크플로를 중단시키는 보안 절차로 인해 매번 업무에 제약을 받지 않습니다. 보안 팀도 더 이상 동일한 문제를 반복해서 해결하지 않아도 됩니다. 이를 통해 조직은 강력한 보안 태세를 유지하면서 취약점, 잘못된 구성, 규정 준수 또는 정책 위반이 발생하는 즉시 이를 탐지하고 방지할 수 있습니다.
보안을 개발 초기 단계로 전환하고 보안을 코드로 자동화하면 처음부터 Amazon EKS 환경을 보호할 수 있습니다. 대규모 프로덕션 환경에 대비하는 방법을 익히는 것은 Kubernetes 기반을 구축하는 데 있어 중요한 부분입니다. Amazon EKS를 적절히 거버넌스하면 비용을 관리하는 동시에 비즈니스 전반의 효율성, 투명성, 책임성을 높일 수 있습니다. 강력한 거버넌스와 보안 가드레일은 클러스터에 대한 가시성과 제어력을 향상하는 프레임워크를 제공합니다. 이러한 체계가 없으면 조직은 보안 침해 위험이 커질 뿐만 아니라, 그에 따른 매출 및 평판 손상으로 장기간 지속되는 비용까지 부담할 수 있습니다.
보안 우선 전략으로 전환할 때 고려해야 할 사항에 대해 자세히 알아보려면 O’Reilly에서 최근 발간한 다음 보고서를 살펴보세요. 애플리케이션 보안을 위한 시프트 레프트.
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 파이프라인에 쉽게 통합되며, 멀티테넌시를 지원해야 합니다. Kubernetes에서 테넌트란 특정 사업부, 팀, 사용 사례 또는 환경과 연관된 Kubernetes 객체 및 애플리케이션의 논리적 그룹을 의미합니다. 따라서 멀티테넌시란 여러 테넌트가 동일한 클러스터를 안전하게 공유하면서, 비즈니스 요구 사항과 밀접하게 연계된 기술적 보안 요구 사항에 따라 테넌트 간 경계를 적용하는 것을 의미합니다.
Amazon EKS에서 지연 시간이 짧고 성능이 뛰어난 보안을 손쉽게 구현하려면 NGINX App Protect WAF 및 DoS 모듈을 NGINX Ingress Controller에 내장하면 됩니다. 다른 경쟁업체는 이러한 유형의 인라인 솔루션을 제공하지 않습니다. 동기화된 기술이 적용된 단일 제품을 사용하면 컴퓨팅 시간과 비용을 줄이고 도구의 난립을 방지하는 등 여러 이점을 얻을 수 있습니다. 그 밖의 이점은 다음과 같습니다.
- 애플리케이션 경계 보호 – 잘 설계된 Kubernetes 배포 환경에서 NGINX Ingress Controller는 Kubernetes 내에서 실행되는 서비스로 유입되는 데이터 플레인 트래픽의 유일한 진입점이므로 WAF 및 DoS 보호를 적용하기에 이상적인 위치입니다.
- 데이터 플레인 통합 – NGINX Ingress Controller에 WAF를 내장하면 별도의 WAF 장비가 필요하지 않습니다. 이를 통해 복잡성과 비용을 줄이고 장애 지점의 수를 최소화할 수 있습니다.
- 제어 플레인 통합 – Kubernetes API를 통해 WAF 및 DoS 구성을 관리할 수 있어 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는 OWASP 10대 공격으로부터 Kubernetes 앱을 보호하며, 고급 시그니처 및 위협 방어, 봇 방어, 개인 식별 정보(PII) 악용을 방지하는 Dataguard 보호 기능을 제공합니다. NGINX App Protect DoS는 사용자 행동 분석 및 앱 상태 검사를 통해 정교한 애플리케이션 계층 DoS 공격을 완화하는 계층 4 및 7의 추가 방어선을 제공하여 Slow POST, Slowloris, 플러드 공격, Challenger Collapsar 등의 공격으로부터 보호합니다.
이러한 보안 조치는 REST API와 웹 브라우저를 통해 액세스하는 애플리케이션을 모두 보호합니다. 또한 남북 방향 트래픽 흐름에 따라 Ingress 수준에서도 API 보안이 적용됩니다.
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는 각 WAF가 요청당 지연 시간이 30밀리초 미만이고 성공률이 100%일 때 달성한 최대 처리량을 보여줍니다(5xx 또는 429 오류 없음). 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 및 애플리케이션 소유자와 독립적으로 운영되는 방식을 반영하기 위해 의도적으로 분리되어 있습니다. app-protect-security-log-destination 어노테이션의 매개변수를 syslog 파드의 클러스터 IP 주소로 설정하면 Kubernetes 파드에서 연결할 수 있는 모든 syslog 대상으로 NGINX App Protect 로그를 전송할 수 있습니다. 또한 APLogConf 리소스를 사용하여 필요한 NGINX App Protect 로그를 지정하고, 이에 따라 syslog 파드로 전송할 로그를 결정할 수 있습니다. 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: allNGINX CRD를 사용하여 WAF 정책 정의하기
The 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
[...]Amazon EKS 클러스터에 보안 정책 매니페스트를 적용한 후, 요청이 WAF 정책을 위반할 때 로그에 기록되는 항목의 유형과 형식을 정의하기 위해 log-violations라는 APLogConf 객체를 생성합니다:
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 Policy 객체는 애플리케이션이 NGINX Ingress Controller를 통해 노출될 때 NGINX App Protect WAF가 수신 트래픽에 적용할 sample-policy를 참조합니다. 또한 log-violations를 참조하여 logDest 필드에 지정된 syslog 서버로 전송되는 로그 항목의 형식을 정의합니다.
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가 다음을 게시하면 배포가 완료됩니다. VirtualServer 객체는 NGINX Ingress Controller를 구성하여 Amazon EKS에서 애플리케이션을 외부에 노출합니다:
apiVersion: k8s.nginx.org/v1kind: 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-upstreamVirtualServer 객체를 사용하면 공동 책임 모델을 준수하면서 Amazon EKS에서 실행되는 컨테이너화된 애플리케이션을 손쉽게 게시하고 보호할 수 있습니다. 이 모델에서는 SecOps가 포괄적인 보안 정책 카탈로그를 제공하고, DevOps는 이를 활용해 첫날부터 개발 초기 단계에 보안을 적용합니다. 이를 통해 조직은 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일 무료 평가판을 시작하거나 사용 사례에 대해 논의하려면 문의해 주세요.
Amazon EKS에서 NGINX Ingress Controller와 NGINX App Protect WAF 및 DoS를 사용하여 보안 침해를 방지하고 Kubernetes 앱을 대규모로 보호하는 방법을 알아보려면 eBook F5 NGINX로 Amazon EKS 보안 강화를 다운로드하세요.
NGINX App Protect WAF가 AWS, Azure 및 Cloudflare의 기본 WAF보다 얼마나 뛰어난 성능을 발휘하는지 자세히 알아보려면 GigaOm의 고성능 웹 애플리케이션 방화벽 테스트 보고서를 다운로드하고, GigaOm 애널리스트 Jake Dolezal이 결과를 검토하는 12월 6일 웨비나에 등록하세요.
작성자 소개
관련 블로그 게시물
시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric
이 영상에서는 KubeCon의 NGINX 부스를 찾아가, 저희가 공개한 Kubernetes Gateway API 구현을 살펴봅니다.
F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법
앱 보안을 강화하는 두 가지 방법을 소개합니다. NGINX Management Suite를 통해 WAF 운영에 대한 가시성을 높이고, NGINX App Protect WAF를 활용해 코드형 보안을 구현하는 것입니다.
Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션
개발 주체, 개발 철학, 프로덕션 환경 준비도, 보안 및 지원을 기준으로 어떤 NGINX Ingress 컨트롤러가 가장 적합한지 알아보세요.
진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법
NGINX App Protect Denial of Service(DoS)가 계층 7 DoS 공격을 방어하기 위해 완화 방법을 실시간으로 조정하는 방식을 설명합니다. 정상적인 사용자 행동과 서버 상태에 대한 모델을 생성하여 공격을 나타내는 이상 징후를 감지하고 맞춤형 완화 시그니처를 적용할 수 있습니다.
NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리
NGINX Instance Manager 버전 1.0에는 두 가지 새로운 기능이 도입되었습니다. NGINX 인스턴스에 태그와 사용자 역할을 지정하면 전체 그룹에 구성을 한 번에 적용할 수 있습니다. 인증서 검사는 만료 예정인 인증서를 감지하여 서비스 중단을 방지할 수 있도록 인증서를 교체할 수 있게 해줍니다.
Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유
Netflix가 글로벌 콘텐츠 전송 네트워크인 Open Connect의 스트리밍 미디어 기술로 NGINX를 선택한 이유를 NGINX 개발자 Gleb Smirnoff에게서 알아보세요.