조직이 워크로드를 클라우드로 마이그레이션할 때 리버스 프록시, 로드 밸런서, API 게이트웨이를 사용하여
앱 외부에서 구현된 애플리케이션 요구 사항의 복잡성을 해결해야 하는 경우가 많습니다.
예를 들어, 개발팀은 애플리케이션 스택에서 보안, 확장성, 가용성, 가시성 정책, 규칙, 로직을 구현하기 위해
NGINX를 사용할 수 있으며, 이 기능이 없으면 구성 제어의 깊이가 부족합니다.
또한 클라우드 기반 고객은 성능, 확장성, 가용성, 가동 시간 SLA를 보장하면서
인프라 운영 및 유지 관리에 대한 부담을 없애고자 하는 욕구와 수요에 따라 관리형 서비스를 선호합니다.
또한 많은 조직이 미션 크리티컬 애플리케이션을 제공하기 위해
매일 NGINX의 프록시, 로드 밸런싱, 캐싱 기능에 의존하고 있다는 사실을 알고 있습니다.
F5 NGINX는 이를 기반으로 다른 네트워킹 서비스에서는 사용할 수 없는
상당한 프로그래밍 기능과 제어 기능을 제공하는
비교적 독특한 서비스형 인프라, 즉 NGINXaaS for Azure를 구축했습니다.
Azure용 NGINXaaS는 설치, 라이선스, 업그레이드, 패치 등의 복잡성을 제거하면서
NGINX Plus의 강력한 기능을 제공합니다.
기본 제공 고가용성, 핵심 Azure 서비스와의 통합, Azure 인터페이스를 통한 일관된 가시성 및 관리,
사용량 기반 가격 책정 등이 특징입니다.
이 서비스는 모든 운영상의 수고를 자동으로 처리합니다.
NGINX 구성과 백엔드 애플리케이션만 가져오면 됩니다.
일류 클라우드 서비스인 Azure용 NGINXaaS는 포털, cli, SDK, Terraform 등
모든 Azure 인터페이스에서 기본 환경을 제공하며,
다른 클라우드 인프라 서비스와 긴밀하게 통합되어 완벽한 경험을 제공합니다.
예를 들어, NGINX Plus는 200개 이상의 메트릭을 제공하여 애플리케이션에 대한
심층적이고 상세한 인사이트를 제공하며,
이러한 메트릭은 Azure Monitoring 통합을 통해 쉽게 사용할 수 있습니다.
또한, NGINX App Protect WAF v5가 이제 Azure용 NGINXaaS의 애드온으로
미리 보기에서 사용할 수 있게 되어 기쁘게 생각합니다.
NGINX App Protect WAF는 클릭 한 번으로 NGINX의 표준 요금제 배포에서 개별적으로 쉽게 활성화할 수 있습니다.
미리 보기 기능에는 기본 정책을 선택할 수 있는 기능 및 Azure 로그 분석과의 통합이 포함됩니다.
Azure용 NGINXaaS는 Microsoft Azure 마켓플레이스를 방문하기만 하면 쉽게 시작할 수 있습니다: https://go.f5.net/nm4zmb5q.
누구나 기본 요금제로 시작하여 나중에 99.95% 가동 시간 SLA, 확장 및 전체 NGINX Plus 상태 공유를 통해
고가용성을 제공하는 엔터프라이즈 요금제로 업그레이드할 수 있습니다.
위 내용과 같이 NGINX Plus / NGINX App Protect 를 활용하여 보안취약점 완화가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
F5 의 2022년 애플리케이션 전략 상태 에 따르면 , 기업의 디지털 전환은 전 세계적으로 계속 가속화되고 있습니다. 대부분의 기업은 여러 클라우드 영역에 걸쳐 200~1,000개의 앱을 배포하고 있으며, 오늘날의 앱은 모놀리식에서 최신 분산 아키텍처로 이동하고 있습니다.
쿠버네티스는 2016년에 처음으로 주류로 사용되기 위해 기술 분야에 등장했습니다. 불과 6년 전입니다. 하지만 오늘날 전 세계 조직의 75% 이상이 프로덕션에서 컨테이너화된 애플리케이션을 실행하고 있으며, 이는 2019년 대비 30% 증가한 수치입니다. Amazon Elastic Kubernetes Service(EKS)를 포함한 쿠버네티스 환경에서 중요한 문제 중 하나는 보안입니다. 보안은 앱 개발 프로세스의 마지막에 "볼트온"되는 경우가 너무 많고, 때로는 컨테이너화된 애플리케이션이 이미 가동되고 실행된 후에도 보안이 적용되지 않는 경우가 많습니다.
COVID‑19 팬데믹으로 인해 가속화된 현재의 디지털 혁신의 물결은 많은 기업이 보안에 대해 보다 전체적인 접근 방식을 취하고 "왼쪽으로 이동" 전략을 고려하도록 강요했습니다. 보안을 왼쪽으로 이동한다는 것은 소프트웨어 개발 수명 주기(SDLC) 초기에 보안 조치를 도입하고 애플리케이션, 컨테이너, 마이크로서비스 및 API에 대한 CI/CD 파이프라인의 모든 단계에서 보안 도구와 제어를 사용하는 것을 의미합니다. 이는 DevSecOps라는 새로운 패러다임으로의 전환을 나타내며, 여기서 보안은 DevOps 프로세스에 추가되고 최신 소프트웨어 앱 개발 및 제공의 일반적인 빠른 릴리스 주기에 통합됩니다.
DevSecOps는 상당한 문화적 변화를 나타냅니다. 보안 및 DevOps 팀은 공통된 목적을 가지고 일합니다. 즉, 고품질 제품을 빠르고 안전하게 시장에 출시하는 것입니다. 개발자는 더 이상 워크플로를 중단시키는 보안 절차로 인해 매번 좌절감을 느끼지 않습니다. 보안 팀은 더 이상 동일한 문제를 반복적으로 해결하지 않습니다. 이를 통해 조직은 강력한 보안 태세를 유지하고 취약성, 잘못된 구성 및 규정 준수 또는 정책 위반이 발생하는 대로 포착하고 예방할 수 있습니다.
보안을 왼쪽으로 이동하고 코드로 보안을 자동화하면 처음부터 Amazon EKS 환경을 보호할 수 있습니다. 대규모로 프로덕션에 대비하는 방법을 배우는 것은 Kubernetes 기반을 구축하는 데 중요한 부분입니다. Amazon EKS의 적절한 거버넌스는 비용도 제어하면서 비즈니스 전반에 걸쳐 효율성, 투명성 및 책임을 추진하는 데 도움이 됩니다. 강력한 거버넌스와 보안 가드레일은 클러스터에 대한 더 나은 가시성과 제어를 위한 프레임워크를 만듭니다. 이러한 프레임워크가 없으면 조직은 보안 침해의 위험과 수익 및 평판 손상과 관련된 장기 비용에 더 많이 노출됩니다.
보안 우선 전략으로 전환할 때 고려해야 할 사항에 대해 자세히 알아보려면 O'Reilly의 최근 보고서인 Shifting Left for Application Security를 살펴보세요 .
자동화는 DevSecOps의 중요한 지원 요소로, 빠른 개발 및 배포 속도에서도 일관성을 유지하는 데 도움이 됩니다. 코드로서의 인프라와 마찬가지로 코드로서의 보안 접근 방식으로 자동화하려면 선언적 정책을 사용하여 원하는 보안 상태를 유지해야 합니다.
GitOps는 애플리케이션 제공 및 클러스터 관리를 지원하고 단순화하기 위한 자동화를 용이하게 하는 운영 프레임워크입니다. GitOps의 주요 아이디어는 Kubernetes 객체와 Kubernetes에서 실행되는 애플리케이션의 선언적 정책을 저장하는 Git 저장소를 갖는 것입니다. 이 저장소는 코드로 정의됩니다. 자동화된 프로세스는 프로덕션 환경이 모든 저장된 상태 설명과 일치하도록 GitOps 패러다임을 완성합니다.
저장소는 보안 정책의 형태로 진실의 원천 역할을 하며, 이는 CI/CD 파이프라인 프로세스의 일부로 선언적 구성-코드 설명에 의해 참조됩니다. 예를 들어, NGINX는 F5 NGINX App Protect에 대한 Ansible 역할이 있는 GitHub 저장소를 유지 관리하는데 , 이는 보안을 왼쪽으로 이동하려는 팀에 도움이 되기를 바랍니다.
이러한 리포지토리를 사용하면 새 애플리케이션을 배포하거나 기존 애플리케이션을 업데이트하는 데 필요한 것은 리포지토리를 업데이트하는 것뿐입니다. 자동화된 프로세스는 구성을 적용하고 업데이트가 성공적으로 수행되도록 하는 것을 포함하여 다른 모든 것을 관리합니다. 이를 통해 모든 것이 개발자를 위한 버전 제어 시스템에서 발생하고 비즈니스에 중요한 애플리케이션에 대한 보안을 강화하도록 동기화됩니다.
Amazon EKS에서 실행하는 경우 GitOps는 보안을 원활하고 강력하게 구축하는 동시에 사실상 인적 오류를 없애고 시간 경과에 따라 적용되는 모든 버전 변경 사항을 추적합니다.
Kubernetes 보안 정책에 대한 견고한 설계는 SecOps와 DevOps의 요구 사항을 모두 수용해야 하며 환경이 확장됨에 따라 적응할 수 있는 조항을 포함해야 합니다. Kubernetes 클러스터는 여러 가지 방법으로 공유할 수 있습니다. 예를 들어, 클러스터에는 여러 애플리케이션이 실행되고 리소스를 공유하는 반면, 다른 경우에는 한 애플리케이션의 여러 인스턴스가 있으며 각각 다른 최종 사용자 또는 그룹을 위한 것입니다. 이는 보안 경계가 항상 명확하게 정의되지 않으며 유연하고 세분화된 보안 정책이 필요하다는 것을 의미합니다.
전반적인 보안 설계는 예외를 수용할 만큼 충분히 유연해야 하며, CI/CD 파이프라인에 쉽게 통합되어야 하며, 멀티 테넌시를 지원해야 합니다. Kubernetes의 맥락에서 테넌트는 특정 사업부, 팀, 사용 사례 또는 환경과 관련된 Kubernetes 객체 및 애플리케이션의 논리적 그룹입니다. 멀티 테넌시는 여러 테넌트가 동일한 클러스터를 안전하게 공유하고, 테넌트 간의 경계는 비즈니스 요구 사항과 긴밀하게 연결된 기술적 보안 요구 사항에 따라 시행되는 것을 의미합니다.
Amazon EKS에서 저지연, 고성능 보안을 구현하는 쉬운 방법은 NGINX Ingress Controller 에 NGINX App Protect WAF 및 DoS 모듈을 내장하는 것입니다. 다른 경쟁사 중 어느 누구도 이런 유형의 인라인 솔루션을 제공하지 않습니다. 동기화된 기술을 갖춘 하나의 제품을 사용하면 컴퓨팅 시간, 비용 및 도구 확산을 줄이는 등 여러 가지 이점이 있습니다. 다음은 몇 가지 추가 이점입니다.
NGINX App Protect WAF 및 DoS에 대한 구성 객체는 NGINX Ingress Controller와 NGINX Plus 에서 모두 일관됩니다 . 마스터 구성은 두 장치 모두에 쉽게 변환 하여 배포할 수 있으므로 WAF 구성을 코드로 관리하고 모든 애플리케이션 환경에 배포하는 것이 더욱 쉬워집니다.
NGINX Ingress Controller에 NGINX App Protect WAF 및 DoS를 빌드하려면 NGINX Plus와 NGINX App Protect WAF 또는 DoS에 대한 구독이 있어야 합니다. 몇 가지 간단한 단계만 거치면 통합 NGINX Ingress Controller 이미지 (Docker 컨테이너)를 빌드할 수 있습니다. 이미지를 배포한 후( 예: 수동으로 또는 Helm 차트 사용 ) 익숙한 Kubernetes API를 사용하여 보안 정책 및 구성을 관리할 수 있습니다.
NGINX Plus 기반의 NGINX Ingress Controller는 인증, RBAC 기반 권한 부여 및 포드와의 외부 상호작용에 대한 세부적인 제어 및 관리를 제공합니다. 클라이언트가 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는 사용자 동작 분석 및 앱 상태 검사를 통해 Slow, Slowloris, 플러드 공격, Challenger Collapsar를 포함한 공격으로부터 보호하기 위해 4계층과 7계층POST 에서 추가 방어선을 제공 합니다.
이러한 보안 조치는 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는 각 WAF가 100% 성공(오류 없음 또는 오류 없음) 시 각 요청에 대해 30밀리초 미만의 지연 시간으로 달성한 최고 처리량을 보여줍니다 . NGINX App Protect WAF는 19,000 RPS를 처리한 반면 Cloudflare WAF는 14,000 RPS, AWS WAF는 6,000 RPS, Azure WAF는 2,000 RPS에 불과했습니다.5xx429
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 App Protect 및 NGINX Ingress Controller의 로그는 보안 팀이 일반적으로 DevOps 및 애플리케이션 소유자와 독립적으로 운영하는 방식을 반영하기 위해 설계상 분리되어 있습니다. 매개변수를 app-protect-security-log-destinationsyslog pod의 클러스터 IP 주소에 대한 주석으로 설정하여 Kubernetes pod에서 도달 가능한 모든 syslog 대상으로 NGINX App Protect 로그를 보낼 수 있습니다. 또한 APLogConf 리소스를 사용하여 어떤 NGINX App Protect 로그를 신경 써야 하는지, 그리고 암시적으로 어떤 로그를 syslog pod에 푸시할지 지정할 수 있습니다. 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
APPolicy Policy 객체 는 선언적 접근 방식을 기반으로 서명 세트와 보안 규칙이 있는 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 클러스터에 보안 정책 매니페스트가 적용되면 log-violations요청이 WAF 정책을 위반할 때 로그에 기록되는 항목의 유형과 형식을 정의하기 위해 호출되는 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
그런 다음 Policy 객체는 NGINX Ingress Controller에서 애플리케이션이 노출될 때 들어오는 트래픽에 적용할 NGINX App Protect WAF를 waf-policy참조합니다 . 필드 에 지정된 syslog 서버로 전송되는 로그 항목의 형식을 정의하기 위해 참조합니다 .sample-policylog-violationslogDest
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/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-upstream
VirtualServer 객체는 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 Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
문제는 더 이상 클라우드에 있는지 여부가 아니라 얼마나 많은 클라우드에 있는지입니다. 오늘날 대부분의 기업은 "하나의 클라우드가 모든 것에 맞는" 솔루션이 없다는 것을 인식하고 하이브리드 또는 멀티 클라우드 아키텍처로 전환했습니다. F5의 2023년 애플리케이션 전략 상태 보고서에 따르면, 85%의 기업이 두 개 이상의 다른 아키텍처로 애플리케이션을 운영합니다.
개발 및 API 팀에게 이는 많은 압박을 가합니다. 이들은 복잡하고 분산된 환경에서 대규모로 API를 안전하게 제공해야 하는 임무를 맡고 있습니다. 연결은 더 이상 단순히 클라이언트와 백엔드 서비스 간에만 있는 것이 아니라, 이제는 서로 다른 클라우드, 지역, 데이터 센터 또는 에지 위치에 배포된 애플리케이션 간에 있습니다. 한편, 모든 API는 배포 위치와 제공 및 보안에 사용되는 도구에 관계없이 조직의 보안 및 규정 준수 요구 사항을 충족해야 합니다.
이러한 고도로 분산된 환경에서 API를 보호하려면 고유한 역량과 모범 사례가 필요합니다. 저는 이전에 API 보안에 대한 두 가지 접근 방식 의 중요성에 대해 썼습니다. 처음부터 보안을 구축하기 위한 "왼쪽으로 이동"과 일련의 글로벌 포스처 관리 관행으로 "오른쪽으로 보호"하는 것입니다. 이 블로그 게시물에서는 클라우드, 온프레미스 및 엣지 환경에서 API를 안전하게 제공하면서 이 전략을 실행하는 방법을 살펴보겠습니다.
하이브리드 및 멀티 클라우드 아키텍처는 특히 민첩성, 확장성 및 회복성 측면에서 많은 확실한 이점이 있습니다. 그러나 복잡성이 한 겹 더 추가됩니다. 사실, F5의 2023년 애플리케이션 전략 상태 보고서는 복잡성 증가가 오늘날 조직이 직면한 가장 흔한 과제임을 보여주었습니다. 두 번째로 흔한 과제는? 일관된 보안을 적용하는 것입니다.
오늘날의 문제는 특정 WAF 와 같은 일부 보안 솔루션이 API에 필요한 컨텍스트와 보호 기능이 부족하다는 것입니다. 동시에 전용 API 보안 솔루션은 공격을 중단하기 위한 정책을 만들고 시행할 수 있는 능력이 없습니다. 아키텍처와 기술을 발견, 관찰, 관리 및 시행을 아우르는 상호 연결된 스택으로 취급하는 솔루션이 필요합니다.
실제로 API 보안은 API 트래픽이 중요한 인프라 지점을 통과할 때 보호를 제공하기 위해 3단계에 걸쳐 통합되어야 합니다.
아래 참조 아키텍처는 F5 분산 클라우드 서비스 와 F5 NGINX가 어떻게 함께 작동하여 멀티 클라우드 및 하이브리드 아키텍처에서 포괄적인 API 보호를 제공하는지에 대한 개요를 제공합니다.
이 참조 아키텍처에서 F5 Distributed Cloud는 에지, 클라우드 및 온프레미스 배포에 걸쳐 글로벌 계층의 보호를 제공합니다. NGINX App Protect WAF 가 포함된 NGINX Plus는 소프트웨어 개발 라이프사이클에 통합하여 런타임 보안을 강화함으로써 사이트 계층 및/또는 앱 계층에서 세분화된 보호를 제공합니다.
이 아키텍처의 각 구성 요소가 제공하는 보안 보호 기능을 살펴보겠습니다.
시작하려면 퍼블릭 클라이언트의 API 트래픽이 에지에 배포된 F5 Distributed Cloud Web Application and API Protection(WAAP)을 통과합니다. 중요한 점은 이것이 DDoS 공격 , 봇 남용 및 기타 악용으로부터 글로벌 보호를 제공한다는 것입니다. 또한 다양한 클라우드, 온프레미스 데이터 센터 및 에지 배포로 들어오는 API 트래픽에 대한 중요한 글로벌 가시성을 제공합니다.
API 트래픽이 빠르게 증가하고 있으며 대부분의 API 공격은 몇 주 또는 몇 달에 걸쳐 천천히 전개됩니다. 정기적인 API 요청과 응답의 홍수 속에서 악성 트래픽을 찾는 것은 마치 건초더미에서 바늘을 찾는 것과 같을 수 있습니다. 이 문제를 해결하기 위해 F5 Distributed Cloud는 인공 지능(AI)과 머신 러닝(ML)을 사용하여 API 트래픽에 대한 통찰력을 생성합니다. 여기에는 API 검색, 엔드포인트 매핑, 새로운 위협을 나타낼 수 있는 이상에 대한 적극적인 학습 및 탐지가 포함됩니다.
앱 및 API 보안의 글로벌 계층 역할을 하는 F5 Distributed Cloud WAAP는 다음과 같은 이점을 제공합니다.
F5 분산 클라우드 WAAP를 시작하려면 API 보안, 봇 방어, 엣지 컴퓨팅, 멀티 클라우드 네트워킹이 포함된 F5 분산 클라우드 서비스의 무료 엔터프라이즈 평가판을 요청하세요 .
API 트래픽이 글로벌 계층을 통과하면 사이트 계층 및/또는 앱 계층에 도착합니다. 글로벌 계층은 일반적으로 IT 네트워킹 및 보안 팀에서 관리하는 반면, 사이트 계층 및 앱 계층의 개별 API는 소프트웨어 엔지니어링 팀에서 빌드하고 관리합니다.
액세스 제어와 관련하여 API 게이트웨이는 개발자가 가장 일반적인 보안 요구 사항 중 일부를 애플리케이션 위의 공유 인프라 계층으로 오프로드할 수 있기 때문에 일반적인 선택입니다. 이를 통해 중복된 작업(예: 각 개발자 또는 팀이 자체 인증 및 권한 부여 서비스를 빌드하는 것)이 줄어듭니다.
F5 NGINX Management Suite API Connectivity Manager를 사용하면 플랫폼 엔지니어링 및 DevOps 팀이 개발자가 요청 티켓이나 기타 복잡한 시스템을 작성하지 않고도 API 게이트웨이, 개발자 포털 등의 공유 인프라에 대한 액세스를 제공할 수 있습니다.
API Connectivity Manager를 사용하면 보안 정책을 설정하여 NGINX Plus를 API 게이트웨이로 구성하고 NGINX App Protect WAF 정책을 구성 및 모니터링할 수 있습니다. 함께 사용하면 다음을 포함하여 중요한 API 런타임 보호 기능을 제공합니다.
NGINX API 연결 스택의 무료 30일 평가판을 시작하면 NGINX Management Suite와 해당 API 연결 관리자, 인스턴스 관리자, 보안 모니터링 모듈에 액세스할 수 있으며, API 게이트웨이로 NGINX Plus와 WAF 및 DoS 보호를 위한 NGINX App Protect도 사용할 수 있습니다.
NGINX는 클라우드와 온프레미스 데이터 센터 환경에서 탁월한 런타임 보호를 제공합니다. F5 Distributed Cloud와 결합하면 보안 및 플랫폼 엔지니어링 팀은 연관된 앱이 배포된 위치에 관계없이 API 엔드포인트에 대한 지속적인 가시성을 확보할 수 있습니다. F5 Distributed Cloud와 NGINX는 함께 필요한 모든 방식으로 아키텍처를 구축하고 보안할 수 있는 완벽한 유연성을 제공합니다.
위 내용과 같이 NGINX Plus / NGINX App Protect 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
디지털 경제는 COVID-19 팬데믹 이후 계속 확장되고 있으며, 90%의 조직이 최신 앱 아키텍처를 성장시키고 있습니다. F5의 2023년 애플리케이션 전략 상태 보고서 에 따르면 , 설문 조사에 참여한 1,000명의 글로벌 IT 의사 결정권자 중 40% 이상이 앱 포트폴리오를 "현대적"이라고 설명합니다. 이 비율은 지난 몇 년 동안 꾸준히 증가해 왔으며 2025년까지 50%를 초과할 것으로 예상됩니다. 그러나 최신 앱의 증가와 마이크로서비스 사용은 API와 API 엔드포인트의 확산을 동반하여 취약성의 가능성과 공격 표면적을 기하급수적으로 증가시킵니다.
F5 CTO 사무소의 보고서인 Continuous API Sprawl 에 따르면 2021년 전 세계적으로 약 2억 개의 API가 있었으며, 2030년까지는 20억 개에 달할 것으로 예상됩니다. 이러한 급속한 API 성장으로 인한 복잡성을 가중시키는 것은 하이브리드 및 멀티 클라우드 환경에서 분산 애플리케이션을 관리하는 과제입니다. 2023 State of Application Strategy 보고서 에 응답한 사람들은 멀티 클라우드 환경에 앱을 배포할 때 여러 도구와 API를 관리하는 복잡성을 1순위 과제로 꼽았습니다. 일관된 보안 정책을 적용하고 앱 성능을 최적화하는 것이 2위를 차지했습니다.
API는 현대적 애플리케이션의 빌딩 블록일 뿐만 아니라 디지털 비즈니스의 핵심이기도 합니다. F5 2023 보고서에 따르면 설문 조사에 참여한 조직의 58%가 수익의 절반 이상을 디지털 서비스에서 얻는다고 답했습니다. API는 사용자-앱 간 및 앱-앱 간 통신을 가능하게 하며, 개인 고객 데이터와 내부 기업 정보에 대한 액세스를 제공하므로 공격자에게 수익성 있는 대상이 됩니다. API는 2022년에 선택한 공격 벡터였습니다.
API를 보호하는 것은 전반적인 애플리케이션 보안 전략에서 가장 중요합니다. 공격은 소비자 개인 정보를 침해하는 것(그게 아무리 나쁘더라도)을 훨씬 넘어서서 공공 안전을 해치고 지적 재산을 손실하는 심각도가 높아질 수 있는 파괴적인 결과를 초래할 수 있습니다. 다음은 2022년에 발생한 이러한 유형의 API 공격에 대한 몇 가지 예입니다.
이러한 API 공격은 경고 이야기 역할을 합니다. API에 보안 취약성이 있고 보호되지 않은 채로 방치하면 롱테일 결과는 금전적 비용을 훨씬 넘어설 수 있습니다. API 보안의 중요성은 과장할 수 없습니다.
NGINX API Connectivity Stack 솔루션은 여러 클라우드 환경에서 API 게이트웨이와 API를 관리하는 데 도움이 됩니다. NGINX App Protect WAF 와 함께 NGINX Plus를 API 게이트웨이로 배포하면 F5 2023 State of Application Strategy Report 에서 식별된 상위 3가지 API 과제 (여러 클라우드 환경에서 API 복잡성 관리, 보안 정책 보장, 앱 성능 최적화)와 이전 섹션에서 설명한 API 공격 유형을 해결하는 일반적인 API 익스플로잇을 방지하고 완화하는 데 도움이 될 수 있습니다. NGINX Plus는 API 요청을 빠르게 라우팅하고, API 클라이언트를 인증 및 승인하여 API를 보호하고, 트래픽 속도를 제한하여 API 기반 서비스를 과부하로부터 보호하는 등 여러 가지 방법으로 사용할 수 있습니다.
NGINX Plus는 OWASP API Security Top 10 취약점 뿐만 아니라 기본 제공 보호 기능을 제공합니다 . 또한 잘못된 쿠키, JSON 및 XML을 확인하고, 허용된 파일 유형과 응답 상태 코드를 검증하고, 공격을 가리는 데 사용되는 회피 기술을 감지합니다. NGINX Plus API 게이트웨이는 REST, GraphQL 및 gRPC를 포함한 HTTP 또는 HTTP/2 API 프로토콜에 대한 보호를 보장합니다.
NGINX App Protect WAF는 OWASP API Security Top 10 및 OWASP(Application) Top 10 에 대한 기본 보호를 넘어서는 가볍고 고성능의 앱 및 API 보안을 제공하며 , 7,500개 이상의 고급 시그니처, 봇 시그니처 및 위협 캠페인으로부터 보호합니다. 이를 통해 왼쪽으로 이동 전략을 사용하고 API 보안을 쉽게 자동화하여 CI/CD 파이프라인에 코드로 보안을 통합할 수 있습니다. AWS, Azure 및 Cloudflare WAF에 대한 테스트에서 NGINX App Protect WAF는 더 나은 성능과 더 낮은 대기 시간을 유지하면서도 강력한 앱 및 API 보안을 제공하는 것으로 나타났습니다. 자세한 내용은 이 GigaOm 보고서를 확인하세요 .
NGINX App Protect WAF는 NGINX Plus API 게이트웨이에 내장되어 있어 API 트래픽에 대한 홉이 하나 줄어듭니다. 계층 간 홉이 적으면 지연, 복잡성 및 장애 지점이 줄어듭니다. 이는 WAF와 통합되지 않는 일반적인 API 관리 솔루션과는 극명한 대조를 이룹니다(WAF를 별도로 배포해야 하며, 설정한 후 API 트래픽은 WAF와 API 게이트웨이를 별도로 통과해야 함). NGINX의 긴밀한 통합은 보안에 대한 타협 없이 높은 성능을 의미합니다.
앱 및 API 개발자는 유연성, 속도, 사용 및 배포 용이성을 높일 수 있는 새로운 방법을 끊임없이 찾고 있습니다. Postman의 2022년 API 보고서 에 따르면 REST는 여전히 오늘날 가장 인기 있는 API 프로토콜(89%)이지만 GraphQL(28%)과 gRPC(11%)도 인기가 계속 증가하고 있습니다. 궁극적으로 API 프로토콜의 선택은 애플리케이션의 목적과 비즈니스에 가장 적합한 솔루션에 따라 크게 달라집니다. 각 프로토콜에는 고유한 이점이 있습니다.
GraphQL API를 사용하는 주요 이점은 다음과 같습니다.
GitHub은 GraphQL의 잘 알려진 사용자 중 하나입니다. 그들은 확장성과 유연성을 이유로 2016년에 GraphQL로 전환했습니다.
gRPC API를 사용하는 주요 이점은 다음과 같습니다.
대부분의 성능은 클라이언트 측에서 제공되고, 관리와 계산은 해당 리소스를 호스팅하는 원격 서버로 오프로드됩니다. gRPC는 마이크로 서비스 간 트래픽이나 요청자(예: IoT 장치)가 제한된 리소스를 보존해야 하는 데이터 수집 등 일정량의 데이터나 처리가 정기적으로 필요한 사용 사례에 적합합니다.
Netflix는 gRPC API를 사용하는 잘 알려진 사례입니다.
NGINX App Protect WAF는 이제 REST 및 gRPC API 외에도 GraphQL API를 지원합니다 . 공격 시그니처를 적용하고, 악의적인 익스플로잇을 제거하고, 공격을 방어하여 GraphQL API를 보호합니다. GraphQL 트래픽은 기본적으로 구문 분석되므로 NGINX App Protect WAF는 GraphQL 구문과 프로파일을 기반으로 위반 사항을 감지하고 공격 시그니처를 적용할 수 있습니다. NGINX App Protect WAF는 인트로스펙션 쿼리에 대한 가시성을 통해 이를 차단하고 응답에서 감지된 패턴을 차단할 수 있습니다. 이 방법은 공격을 감지하고 페이로드의 적절한 세그먼트에서 시그니처를 실행하는 데 도움이 되며, 그렇게 함으로써 거짓 양성을 줄이는 데 도움이 됩니다.
이 데모에서 NGINX App Protect WAF가 GraphQL API를 공격으로부터 방어하는 방법을 알아보세요.
NGINX App Protect WAF를 사용한 GraphQL API 보안의 이점:
NGINX App Protect WAF는 이제 단항 메시지 유형 외에도 gRPC 양방향 스트리밍을 지원하여 메시지 스트림(클라이언트, 서버 또는 둘 다)을 사용하는 gRPC 기반 API를 보호할 수 있습니다. 이는 통신 유형에 관계없이 gRPC API에 대한 완벽한 보안을 제공합니다.
NGINX App Protect WAF는 스키마를 적용하고, 크기 제한을 설정하고, 알 수 없는 파일을 차단하고, 리소스 고갈 유형의 DoS 공격을 방지하여 gRPC API를 보호합니다. 인터페이스 정의 언어(IDL) 파일을 NGINX App Protect WAF로 가져와서 gRPC 메시지의 구조와 스키마를 적용하고 올바른 위치에서 공격을 스캔할 수 있습니다. 이를 통해 gRPC를 통해 애플리케이션을 악용하려는 시도를 정확하게 감지하고 컨텍스트 없이 잘못된 위치에서 보안을 스캔할 때 발생할 수 있는 거짓 긍정을 방지할 수 있습니다.
이 데모에서 NGINX App Protect WAF가 gRPC 양방향 API를 공격으로부터 어떻게 방어하는지 알아보세요.
NGINX App Protect WAF를 사용한 gRPC API 보안의 이점:
Postman의 2022년 API 상태 보고서 에 따르면 , 설문 조사에 참여한 37,000명의 개발자와 API 전문가 중 20%가 조직에서 API 사고가 한 달에 한 번 이상 발생하여 데이터 손실, 서비스 중단, 남용 또는 부적절한 액세스가 발생한다고 밝혔습니다. 반면, 응답자의 52%는 1년에 한 번 미만으로 API 공격을 받았으며, 이는 API 보안을 위한 Shift-Left 전략 의 일환으로 보안을 조기에 통합하는 것의 중요성을 강조합니다 . API가 애플리케이션보다 더 자주 게시됨에 따라, Shift-Left 전략이 API 보안에 점점 더 많이 적용되고 있습니다. 조직이 Shift-Left 문화를 채택하고 CI/CD 파이프라인에 코드로서의 보안을 통합하면 API 개발의 각 단계에 보안을 구축하고 개발자가 민첩성을 유지하고 배포 속도를 가속화할 수 있습니다.
보호가 API별로 이루어져야 하는 주요 영역은 gRPC IDL 파일 및 GraphQL 쿼리를 포함한 API 스키마의 검증입니다. 스키마는 각 API에 고유하며 각 API 버전에 따라 변경됩니다. API 스키마를 자동화할 때 API를 업데이트할 때마다 해당 파일의 구성과 코드도 업데이트해야 합니다. WAF 구성은 API 버전 변경에 맞춰 자동화된 방식으로 배포할 수 있습니다. NGINX App Protect WAF는 스키마를 검증하여 요청이 API가 지원하는 사항(메서드, 엔드포인트, 매개변수 등)을 준수하는지 확인할 수 있습니다. NGINX App Protect WAF는 SecOps 팀이 만들 수 있는 선언적 정책을 통해 일관된 앱 보안을 제공하며, API 개발 팀은 보다 세부적인 제어와 민첩성을 위해 API 보안을 관리하고 배포할 수 있습니다. 하이브리드 및 멀티 클라우드 환경에서 대규모로 API 보안을 자동화하려는 경우 NGINX App Protect WAF가 도움이 될 수 있습니다.
최신 앱 포트폴리오는 계속 성장하고 있으며, 마이크로서비스를 사용하면 API가 더욱 널리 퍼집니다. API 보안은 복잡하고 도전적이며, 특히 하이브리드 또는 멀티 클라우드 환경에서 운영하는 조직의 경우 더욱 그렇습니다. API 보안이 부족하면 금전적 비용을 넘어 파괴적인 롱테일 효과가 발생할 수 있습니다. NGINX App Protect WAF는 REST, GraphQL 및 gRPC API에 대한 보호를 포함하는 포괄적인 API 보안을 제공하며 SecOps 및 API 팀이 API 수명 주기 전체와 분산 환경에서 보안을 왼쪽으로 이동하고 자동화하도록 지원합니다.
위 내용과 같이 NGINX Plus / NGINX App Protect 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
DDoS 공격에 대한 전투는 계속해서 변화하고 있습니다. 2023년 DDoS 공격 추세 보고서 에서 F5 Labs는 분산 서비스 거부 (DDoS) 공격에 대한 3년간의 최근 데이터를 분석한 결과 공격자가 여전히 복잡한 다중 벡터 DDoS 공격을 사용하지만, 더 순수한 애플리케이션 계층(계층 7) 공격을 시작하는 방향으로 전환했다는 사실을 발견했습니다. 2022년 한 해만 해도 계층 7 공격의 유행이 165% 증가했습니다.
일반적으로 공격자는 웹사이트 운영을 방해하거나 대상을 강탈하는 등 목표를 달성하기 위해 가장 쉬운 경로를 추구합니다. 레이어 7 공격의 증가는 볼륨 또는 프로토콜 전략만 사용하여 DDoS 공격을 시작하기가 더 어려워지고 있으며 애플리케이션 레이어 공격이 더 효과적이라는 것을 나타내는 지표일 수 있습니다.
DDoS 공격으로부터 애플리케이션을 방어할 때 가능한 한 기술의 발전을 활용하여 애플리케이션을 계속 사용할 수 있는 기회(그리고 사용자를 만족시킬 수 있는 기회)를 극대화하는 것이 중요합니다. eXpress Data Path (XDP) 기술을 탑재 한 확장된 Berkeley Packet Filter (eBPF)는 2014년부터 있었지만, 마이크로서비스와 클라우드 네이티브 아키텍처의 채택이 증가함에 따라 현재 개발자, SRE 및 운영 커뮤니티에서 인기가 급등하고 있습니다.
eBPF는 사용자가 프로그램을 안전하고 효율적으로 실행할 수 있도록 하는 Linux 커널의 데이터 링크 계층 가상 머신(VM)입니다. 또한 커널 소스 코드를 변경하거나 추가 커널 모듈을 추가하지 않고도 런타임에 커널의 기능을 확장합니다. eBPF는 이벤트 트리거 방식입니다. Linux 호스트에서 특정 활동을 감지하고 특정 작업을 수행합니다. 이 기술은 마이크로서비스와 최종 사용자 간의 연결 및 트랜잭션을 추적하는 기능을 통해 앱과 앱 서비스에 대한 전체 스택 가시성을 제공합니다. 사용 가능한 데이터의 범위는 매우 광범위합니다. 급성 관찰 가능성을 해결하고, 네트워크 트래픽 관리 및 런타임 보안 요구 사항을 분석하고, 기본적인 효율적인 설계를 사용하여 컴퓨팅 비용을 낮출 수 있습니다.
F5 DevCentral에서 eBPF 기술에 대한 간략한 개요를 설명하는 비디오 ' eBPF란 무엇인가?'를 확인하세요.
XDP는 고성능 네트워킹의 이점을 제공합니다. 사용자 공간 프로그램이 네트워크 패킷 데이터를 직접 읽고 쓸 수 있고 커널 수준에 도달하기 전에 패킷을 처리하는 방법에 대한 결정을 내릴 수 있습니다. 이 기술을 통해 개발자는 Linux 커널 내의 네트워크 장치 드라이버에서 구현된 저수준 후크에 eBPF 프로그램을 첨부할 수 있습니다.
NGINX App Protect DoS 는 NGINX Plus와 NGINX Ingress Controller에서 실행되는 고급 동작 기반 Layer 7 DDoS 완화 솔루션으로, Slowloris 및 HTTP Flood 와 같은 공격으로부터 HTTP 및 HTTP/2 앱을 방어합니다 . 간단히 말해, NGINX App Protect DoS는 간단한 네트워크 DDoS 솔루션이 감지할 수 없는 애플리케이션 계층 공격으로부터 보호합니다.
NGINX App Protect DoS와 함께 사용할 경우 eBPF는 상당히 향상된 DDoS 공격 흡수 용량을 약속합니다. NGINX App Protect DoS는 소스 IP 주소로 식별되거나 TLS 지문과 함께 사용되는 악의적 행위자의 트래픽을 차단하여 완화 성능을 가속화하는 다중 계층 솔루션의 일부로 eBPF(NGINX Ingress Controller 자체에서는 사용할 수 없음)를 사용합니다.
다음으로, NGINX App Protect DoS 가 이상 탐지 , 동적 규칙 생성 및 적응 학습 , 규칙 적용 의 세 단계로 작동하는 기본적인 메커니즘을 살펴보겠습니다 .
NGINX App Protect DoS는 보호된 애플리케이션을 지속적으로 모니터링하고 머신 러닝을 사용하여 애플리케이션 및 클라이언트 동작의 통계적 사이트 모델을 구축합니다. 실시간으로 트래픽을 관찰하고 300개 이상의 HTTP 요청 메트릭을 추적하여 지속적으로 업데이트되는 포괄적인 활동 및 성능 기준을 만듭니다. NGINX App Protect DoS는 애플리케이션 트래픽을 수동적으로 모니터링하는 것 외에도 활성 애플리케이션 상태 검사를 수행하고 응답 시간 및 삭제된 요청과 같은 메트릭을 모니터링합니다.
애플리케이션이 7계층 DDoS 공격을 받으면 애플리케이션 응답 시간(또는 오류율)이 학습된 모델과 달라지고 애플리케이션 보호 시스템이 트리거됩니다.
이상이 감지되면 NGINX App Protect DoS는 동적으로 규칙을 생성하여 악성 트래픽을 식별하고 차단합니다. 합법적인 사용자가 애플리케이션에 액세스할 수 있도록 하고 악성 공격자를 차단하는 것을 목표로 클라이언트 동작의 통계적 그림을 생성하여 어떤 사용자가 공격에 기여하고 있는지 또는 기여하지 않는지 식별합니다.
NGINX App Protect DoS는 공격을 차단하기 위해 동적 시그니처를 배포하는 것 외에도 완화 효과를 지속적으로 측정하고 적응형 학습을 적용하여 지속적으로 강력한 앱 보안을 제공하고 제로데이 공격을 차단합니다. 공격을 유발하는 클라이언트와 요청이 식별되면 해당 트래픽을 거부하는 규칙을 구축합니다.
NGINX App Protect DoS는 다음을 포함하는 다층 방어 전략을 구현합니다.
이 세 가지 완화책은 합법적 사용자에게 영향을 미치지 않으면서 공격자가 최대한 차단되도록 점진적으로 적용됩니다. 그러나 차단 활동의 대부분은 IP 주소와 TLS 지문 차단 또는 IP 주소만 차단 단계의 초기 조합에서 자주 발생합니다. 다행히도 이것들은 eBPF 프로그램에서 효과적으로 시행할 수 있는 정확한 규칙 유형입니다.
NGINX App Protect DoS는 생성된 규칙을 사용하여 들어오는 애플리케이션 트래픽에 적용하여 악성 요청을 차단합니다. 모든 애플리케이션 트래픽은 NGINX Plus 프록시에 의해 백엔드(또는 업스트림 ) 애플리케이션으로 프록시되므로 차단 규칙과 일치하는 모든 요청은 간단히 삭제되고 백엔드 애플리케이션으로 전달되지 않습니다.
NGINX Plus가 고성능 프록시이기는 하지만 공격 및 완화 규칙에 의해 생성된 추가 작업 부하가 NGINX가 실행되는 플랫폼의 사용 가능한 리소스를 압도할 가능성이 있습니다. 여기서 eBPF가 등장합니다. IP 주소 전용 차단을 적용하거나 커널에서 IP 주소 및 TLS 지문 차단과 결합하면 악성 트래픽을 전송 계층(4계층)에서 조기에 평가하여 차단할 수 있습니다. 이는 사용자 공간에서 실행되는 NGINX에서 수행할 때보다 훨씬 더 효율적입니다.
지원되는 플랫폼에서 NGINX App Protect DoS가 소스 IP 주소 또는 TLS 지문을 기반으로 공격자를 차단하는 규칙을 만들면 규칙은 네트워크 이벤트(후크라고 함)가 발생할 때 커널에서 실행되는 eBPF 바이트코드 프로그램으로 컴파일됩니다. 특정 네트워크 이벤트가 규칙을 트리거하면 트래픽은 레이어 4에서 일찍 삭제됩니다. 이를 통해 레이어 7에 도달하기 전에 DDoS 완화를 가속화하는 데 도움이 됩니다. 이 활동은 모두 커널에서 발생하므로 매우 효율적이며 규칙이 사용자 공간에서 구현될 때보다 더 많은 트래픽(리소스를 고갈시키기 전에)을 필터링할 수 있습니다.
NGINX App Protect DoS 가속 완화 기능은 다음 Linux 배포판에서 사용할 수 있습니다.
가속화된 DDoS 완화를 활성화 하려면 다음 단계를 따르세요.
NGINX Plus 구성 블록 에 다음 지침을 추가합니다.http{}
protect_dos_accelerated_mitigation on;
NGINX 구성을 다시 로드 합니다.
$ sudo nginx -t && nginx -s reload
NGINX App Protect DoS의 적응 학습 기능과 eBPF 커널 실행의 고효율 트래픽 처리를 결합하면 오늘날의 다중 벡터 및 애플리케이션 중심 DDoS 공격에 대한 개선된 기능을 갖춘 다중 계층, 가속화된 Layer 7 DDoS 완화 전략이 제공됩니다. 또한 주어진 DDoS 공격을 완화하는 데 필요한 리소스를 줄여 인프라 및 컴퓨팅 비용을 낮춥니다.
조직이 디지털로 전환하고 애플리케이션 포트폴리오를 확대함에 따라 보안 과제도 변화하고 증가합니다. F5의 2022년 애플리케이션 전략 현황 에서 우리는 오늘날 얼마나 많은 조직이 그 어느 때보다 더 많은 앱을 모니터링해야 하는지 보았습니다. 종종 200개에서 1000개까지 다양합니다!
그 높은 숫자는 잠재적인 공격 표면을 더 많이 만들어 오늘날의 앱은 특히 악의적인 행위자에게 취약합니다. 이 취약성은 웹 애플리케이션이 더 많은 양의 트래픽을 처리해야 할 때 더 심해집니다. 다운타임을 최소화하려면(또는 더 나은 방법으로 없애려면!) 보안을 최우선으로 하는 전략을 개발하는 것이 중요합니다.
우리의 웨비나 F5 NGINX로 앱 보안을 쉽게 보고, 관리하고, 확장하는 방법 에서 , 우리는 웹 애플리케이션 방화벽 (WAF)이 웹 애플리케이션을 보호하고 보안하는 데 선택해야 할 도구인 이유를 다룹니다. 트래픽을 모니터링하고 필터링함으로써 WAF는 분산 서비스 거부 (DDoS) 와 같은 정교한 레이어 7 공격으로부터 애플리케이션을 보호하는 첫 번째 방어선입니다 .
다음 WAF 기능은 강력한 앱 보안 솔루션을 보장합니다.
하지만 WAF가 앱을 모니터링하는 동안, 귀하의 팀은 WAF를 어떻게 모니터링합니까? 그리고 여러 공격을 처리하기 위해 여러 WAF를 플릿에 배포하는 경우는 어떨까요? 웨비나 에서 이러한 질문에 답하고 실시간 데모도 진행합니다.
웨비나를 미리 보기 위해 이 게시물에서는 WAF 플릿을 대규모로 관리하는 데 도움이 되는 두 가지 주요 결과를 살펴봅니다.
WAF 전략의 성공은 WAF를 구현하고 관리하는 팀이 생성, 배포 및 수정하는 동안 사용할 수 있는 가시성 수준에 따라 달라집니다. 여기서 관리 플레인이 등장합니다. 팀이 각 WAF를 별도의 개별 렌즈를 통해 살펴보는 대신 모든 WAF를 모니터링하기 위한 하나의 중앙 집중식 창을 갖는 것이 중요합니다. 중앙 집중식 가시성을 통해 현재 공격에 대한 정보에 입각한 결정을 내리고 보안 정책을 미세 조정할 수 있는 통찰력을 쉽게 얻을 수 있습니다.
또한 SecOps, Platform Ops, DevOps 팀이 명확하고 응집력 있는 전략을 공유하는 것이 중요합니다. 이 세 팀이 WAF의 설정과 유지 관리를 모두 함께 작업하면 대규모로 더 강력한 앱 보안을 달성할 수 있습니다.
F5 NGINX Management Suite 라는 관리 플레인을 사용하여 각 팀이 어떤 이점을 얻을 수 있는지 알아보세요. 이 관리 플레인은 NGINX App Protect WAF 와 쉽게 통합됩니다 .
Instance Manager는 NGINX Management Suite의 핵심 모듈이며, NGINX App Protect WAF 보안 정책을 대규모로 중앙에서 관리할 수 있도록 합니다. DevOps 팀이 SecOps에서 관리하는 보안 정책을 쉽게 사용할 수 있게 되면 DevSecOps 문화로 전환하여 CI/CD 파이프라인의 모든 단계에서 보안을 즉시 통합하고 보안을 왼쪽으로 옮길 수 있습니다.
왼쪽으로 이동하여 WAF 플릿을 중앙에서 관리한다는 것은 다음을 의미합니다.
플랫폼에 독립적인 NGINX App Protect WAF를 사용하면 쉽게 왼쪽으로 이동하여 CI/CD 파이프라인으로 보안을 자동화할 수 있습니다. 웨비나의 이 짧은 클립에서 자세히 알아보세요.
위 내용과 같이 NGINX Plus / NGINX App Protect 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
F5의 2022년 애플리케이션 전략 상태 보고서에 따르면, IT 의사결정권자의 90%가 조직에서 200~1,000개의 앱을 관리하고 있다고 보고했으며, 이는 5년 전보다 31% 증가한 수치입니다. Enterprise Strategy Group에서 실시한 Modern App Security Trends Drive WAAP Adoption (2022년 5월, F5 제공)에 대한 또 다른 설문 조사에서, 대부분의 IT 의사결정권자는 지난 2년 동안 애플리케이션 보안이 더 어려워졌으며, 72%가 WAF를 사용하여 웹 애플리케이션을 보호한다고 답했습니다. 조직이 디지털 혁신을 계속하고 웹 애플리케이션이 계속 확산됨에 따라 WAF 보호 강화에 대한 필요성도 커지고 있습니다. 하지만 대부분의 도구와 마찬가지로 WAF가 많을수록 일관되고 효과적으로 관리하기가 더 어려워집니다.
대규모 WAF를 관리하는 데에는 다음과 같은 과제가 있습니다.
대규모 WAF 관리란 보안 및 애플리케이션 팀이 모두 설정 및 유지 관리에 참여한다는 것을 의미합니다. WAF를 효과적으로 관리하고 애플리케이션을 적절하게 보호하려면 공격과 WAF 성능에 대한 전체적인 가시성과 글로벌 규모로 구성을 편집하고 게시할 수 있는 기능을 결합한 적절한 도구가 필요합니다. 이 블로그에서는 WAF에 대한 중앙 집중식 보안 시각화 및 구성 관리의 이점을 살펴봅니다.
WAF를 대규모로 쉽게 관리하고 정보에 입각한 결정을 내리는 데 필요한 통찰력을 얻으려면 단일 창에서 WAF 에 대한 가시성을 제공하는 관리가 필요합니다. 주요 위반 및 공격, 거짓 긍정 및 거짓 부정, 공격을 받는 앱 및 악의적 행위자에 대한 정보를 볼 수 있습니다. 지리적 위치를 포함한 공격 그래프를 기반으로 보안 정책을 조정하는 방법을 알아보고 WAF 이벤트 로그를 자세히 살펴볼 수 있습니다.
F5 NGINX Management Suite 에서 보안 모니터링 모듈의 일반 출시를 발표하게 되어 기쁩니다. 이 모듈은 2022년 8월에 출시한 NGINX 을 위한 통합 트래픽 관리 및 보안 솔루션 입니다. 보안 모니터링은 F5 NGINX App Protect WAF를 위한 시각화 도구 로, 바로 사용하기 쉽습니다. 타사 도구의 필요성을 줄일 뿐만 아니라 앱과 API 보호에 대한 고유하고 큐레이팅된 통찰력을 제공합니다. 보안, 개발 및 플랫폼 운영 팀은 위협을 분석하고, 보호 통찰력을 보고, 정책 조정 영역을 식별할 수 있는 기능을 얻게 되므로 문제를 더 쉽게 감지하고 문제를 신속하게 해결할 수 있습니다.
보안 모니터링 모듈을 사용하면 다음을 수행할 수 있습니다.
인지와 가시성은 앱 공격과 취약성을 식별하는 데 필수적이지만, 공격을 자동으로 탐지하고 완화하는 WAF 정책을 구현하여 얻은 통찰력에 따라 행동할 수 없다면 별 가치가 없습니다. WAF의 진정한 가치는 WAF 플릿에서 정책을 만들고, 배포하고, 수정할 수 있는 속도와 용이성에 의해 정의됩니다. 수동 업데이트에는 엄청난 시간과 정확한 기록 보관이 필요하므로 공격과 취약성에 더 취약해집니다. 그리고 타사 도구는 잠재적으로 효과적이기는 하지만 불필요한 복잡성을 더합니다.
중앙 관리 플레인은 보안 정책을 업데이트하고 버튼을 한 번만 눌러 하나, 여러 개 또는 모든 WAF에 푸시할 수 있는 기능을 통해 구성 관리를 가능하게 합니다. 이 방법에는 두 가지 명확한 이점이 있습니다.
이제 NGINX Management Suite의 Instance Manager 모듈 로 NGINX App Protect WAF를 대규모로 관리할 수 있습니다 . 이 향상된 기능을 통해 NGINX App Protect WAF에 대한 정책, 공격 시그니처 및 위협 캠페인을 만들고, 수정하고, 게시할 수 있는 중앙 집중식 인터페이스를 제공하여 위협에 대한 대응력이 더 뛰어나고 트래픽 급증을 처리할 수 있습니다.
인스턴스 관리자 모듈을 사용하면 다음을 수행할 수 있습니다.
자동화와 인공지능(AI)으로 보안 태세를 개선하는 데 지출하는 비용이 결국 훨씬 더 많은 비용을 절감하게 된다는 사실에 놀랄 수도 있습니다. IBM 보안팀은 2021년 데이터 침해 비용 보고서 에서 보안 침해로 인해 보안 자동화와 AI가 없는 조직은 완전히 구축된 자동화와 AI가 있는 조직보다 평균적으로 무려 80% 더 많은 비용이 든다고 밝혔습니다. 671만 달러 대 290만 달러로 381만 달러 차이가 납니다 . 조직은 보안 자동화와 AI를 우선시 함으로써 침해를 더 빨리 식별하고 격리하여 비용과 시간을 모두 절약할 수 있습니다.
그러나 CI/CD 파이프라인에 보안을 통합할 때 도구에 과부하를 주지 않는 것이 중요합니다. 트래픽을 검사하는 횟수가 적을수록 지연 시간이 줄어듭니다. 비즈니스적 추론은 기술적 복잡성이 민첩성의 적이라는 것입니다.
F5 NGINX에서는 소프트웨어 개발 라이프사이클 동안 팀이 " 보안을 왼쪽으로 이동 "하는 데 도움이 되는 원활한 통합과 기능에서 독보적인 보안 플랫폼을 제공합니다. 조직이 CI/CD 파이프라인에 "코드로서의 보안"을 통합하면 보안 자동화 및 AI가 활성화되어 IBM에서 설명한 막대한 절감 효과가 발생합니다. 애플리케이션 및 API 개발의 각 단계에 보안이 내장되어 있으므로 구성 및 보안 정책 파일이 코드로 사용되고 SecOps 팀은 DevOps가 앱을 빌드할 때 사용할 선언적 보안 정책을 만들고 유지 관리할 수 있습니다. 이러한 동일한 정책을 새 앱에 반복적으로 적용하여 CI/CD 파이프라인으로 보안을 자동화할 수 있습니다.
F5 NGINX App Protect와 F5 NGINX Plus가 보안 보호를 자동화하는 데 도움이 되는 트래픽 처리의 세 가지 단계를 살펴보겠습니다.
이 3부 구성 보안 솔루션은 특히 퍼블릭 클라우드 환경에서 두 가지 방법으로 비용을 절감해줍니다.
현재 데이터 센터에서 실행되는 앱을 보호하기 위해 F5 BIG-IP Advanced WAF를 사용하고 있다면 NGINX Plus를 Kubernetes용 Ingress 컨트롤러로 추가하여 NGINX App Protect Dos 및 WAF를 포괄적인 솔루션으로 사용하여 최신 애플리케이션을 확장하고 보호하고 클라우드에서 Kubernetes 앱을 조율하는 것이 간단합니다. F5의 보안-코드 방식을 사용하면 선언적 API 또는 파일의 선언적 JSON 형식 정의를 통해 인프라 및 보안 정책 제어를 코드로 정의할 수 있으며 BIG-IP XML 파일을 JSON 파일로 변환할 수도 있습니다. SecOps가 소유하고 유지 관리하는 표준 기업 보안 제어인 정책은 다른 코드와 마찬가지로 코드 저장소에 저장하여 개발 파이프라인에 가져와 통합할 수 있습니다. 이 방식은 DevOps와 SecOps가 운영상의 격차를 메우고 더 낮은 비용과 더 나은 보안으로 앱을 더 빠르게 출시하는 데 도움이 됩니다.
F5는 WAF 정책 구축 및 베이스라인 설정을 개발 프로세스에 통합합니다. 이는 애플리케이션 개발 파이프라인에서 "보안을 좌측으로 이동"하고 애플리케이션 배포를 자동화하는 데 중요한 부분입니다.
BIG‑IP와 NGINX의 가시성 도구는 서로를 보완하며 SecOps가 DevOps 라이프사이클 초기에 자동화 프로세스를 구축할 수 있도록 합니다. BIG‑IP를 사용하면 팀이 XML 파일을 NGINX에서 사용하는 JSON 파일로 변환하여 일관된 보안 정책을 유지할 수 있습니다. NGINX를 사용하면 팀이 이미 구축된 앱을 미세 조정하는 동시에 최신 앱 보안 자동화를 도입하여 향후 침해와 잠재적 공격 비용을 상쇄할 수 있습니다.
보안 트래픽 관리 여정의 첫 번째 단계는 서비스 거부(DoS) 공격을 제거하는 것입니다. 이러한 남용을 처음부터 차단하는 것은 필수적인 첫 번째 방어선입니다.
우리는 공격자들이 점점 더 전통적인 볼륨 공격에서 HTTP 및 HTTPS 요청 또는 API 호출을 사용하여 레이어 7에서 공격하는 방향으로 전환하고 있다는 것을 이전에 언급했습니다. 이유는 무엇일까요? 그들은 저항이 가장 적은 경로를 따르고 있기 때문입니다. 인프라 엔지니어는 수년간 레이어 3 및 레이어 4 공격에 대한 효과적인 방어를 구축하여 차단하기 쉽고 성공 가능성이 낮아졌습니다. 레이어 7 공격은 이러한 전통적인 방어를 우회할 수 있습니다.
POST모든 DoS 공격이 볼륨형은 아닙니다. Slow 또는 Slowloris 와 같은 "낮고 느린" 방법을 통해 서버 리소스를 소모하도록 설계된 공격은 합법적인 트래픽에 쉽게 숨길 수 있습니다. 그리고 gRPC 와 같은 오픈 소스 HTTP/2 원격 프로시저 호출 프레임워크는 최신 앱에 필요한 속도와 유연성을 제공하지만, 특성상 개방적인 특성으로 인해 독점 프로토콜보다 DoS 공격에 더 취약할 수 있습니다.
기존 DoS 보호와 달리 NGINX App Protect DoS는 자동화된 사용자 및 사이트 동작 분석, 사전 예방적 상태 검사 및 터치 없는 구성을 활용하여 오늘날의 공격을 감지합니다. HTTP 플러드, HTTP 플러드, Slowloris, Slow read 및 Slow를 포함한 일반적인 공격을 차단하기 위한 저지연 솔루션 입니다 .GETPOSTPOST
이러한 공격에 대처하기 위해 SecOps 및 DevOps 팀은 CI/CD 워크플로에 "코드로서의 보안" 자동화를 통합해야 합니다. 이는 Shift-Left 사고방식의 일부입니다. NGINX App Protect DoS가 이를 가능하게 합니다. 이는 최신 분산 앱과 API를 DoS 위협으로부터 고급 보호 기능으로 보호하고, 가벼운 소프트웨어 패키지, 지속적인 위협 완화 피드백 루프, RESTful API를 통한 익숙한 DevOps 도구와의 통합을 통해 이 모델을 용이하게 함으로써 SecOps와 DevOps의 때때로 충돌하는 우선순위를 조정하는 데 도움이 됩니다.
NGINX App Protect DoS는 IBM Security 보고서에서 상당한 비용 절감의 핵심으로 강조한 머신 러닝(ML) 기술을 통합합니다 . 클라이언트 동작과 애플리케이션 상태를 분석하여 정상적인 트래픽 패턴을 모델링하고, 고유한 알고리즘을 사용하여 가장 정확한 보호를 제공하는 동적 통계 모델을 만들고, 동적 시그니처를 배포하여 자동으로 공격을 완화합니다. 또한 완화 효과를 지속적으로 측정하고 변화하는 동작 또는 상태 조건에 적응합니다. 이러한 기능을 통해 NGINX App Protect DoS는 각 공격 요청이 완전히 합법적으로 보이고 단일 공격자가 평균적인 합법적 사용자보다 적은 트래픽을 생성할 수도 있는 DoS 공격을 차단할 수 있습니다.
DoS 보호가 악성 트래픽이 인프라에 유입되는 것을 분명히 막는 반면, 공격은 여전히 침투할 수 있습니다. 성공적인 방어의 다음 단계를 위해 웹 애플리케이션 방화벽(WAF)이 필요한 이유는 합법적인 것으로 위장한 악의적인 행위자의 트래픽에 초점을 맞추기 때문입니다.
가볍고 고성능인 NGINX App Protect WAF는 응답을 검사하고, HTTP 프로토콜 준수를 시행하고, 회피 기술을 탐지하고, Data Guard로 신용카드 번호와 기타 민감한 개인 정보를 가리고, 허용되지 않는 메타 문자와 파일 유형, 잘못된 JSON 및 XML, 민감한 매개변수를 확인하는 포괄적인 보안 보호 기능을 제공합니다. 또한 업데이트된 OWASP Top 10 에 대해서도 보호합니다 .
A03:2021 Injection 과 같은 OWASP Top 10 취약점 에 대한 사이버 공격이 여전히 인기 있는 것은 놀라운 일이 아닙니다 . 2021년 7월, 오픈소스 전자상거래 사이트 WooCommerce는 많은 플러그인이 SQL Injection 에 취약하다고 발표했으며 , 그 당시 여러 공격이 발생하고 있었습니다. 기업과 고객이 주로 온라인에서 운영되고 있기 때문에 공격자가 종종 복잡하고 마이크로서비스로 구성되고 여러 API가 서로 통신하는 분산 환경에 걸쳐 있는 웹 기반 앱에 집중하는 것은 당연합니다. 이로 인해 악용에 취약한 엔드포인트 수가 증가합니다.
최신 공격도 빠르게 변화하고 적응합니다. 여기서 AI가 등장하고 IBM이 그 중요성을 언급한 이유입니다. NGINX App Protect DoS에서와 마찬가지로 NGINX App Protect WAF의 풍부한 ML 시스템은 Platform Ops, DevOps 및 SecOps 팀이 공격 추세와 데이터를 쉽게 공유할 수 있도록 합니다. 새로운 기능 중 하나인 적응형 위반 평가 기능은 애플리케이션의 동작이 변경될 때를 감지하여 ML을 더욱 활용합니다. 이 ML 기능을 통해 NGINX App Protect WAF는 각 애플리케이션의 예측 동작을 지속적으로 평가합니다. 이러한 학습을 기반으로 차단되었을 클라이언트 요청을 활성화하여 앱의 위반 평가 점수를 낮추고 거짓 양성을 크게 줄여 관리 비용을 낮추면서 더 나은 사용자 경험을 제공할 수 있습니다.
NGINX App Protect WAF는 또한 봇 보호 기능을 제공합니다. 오늘날 인터넷 트래픽의 약 50%가 봇에서 발생합니다 . 알려진 악성 트래픽을 미리 제거함으로써 NGINX App Protect WAF는 Bot Signature 데이터베이스를 사용하여 봇 트래픽을 빠르게 차단할 수 있습니다.
CI/CD 파이프라인 초기에 WAF를 보안 계층으로 도입하면 보안 위험을 완화하는 데 도움이 됩니다. NGINX App Protect WAF는 CI/CD 친화적이므로 애플리케이션 개발 프로세스 초기에 코드로 보안을 구축하고 자동화할 수 있습니다. 초기 보안 인식과 팀 간의 적절한 협업을 통해 전달 위험과 같은 병목 현상도 제거할 수 있습니다. 다단계 DoS 및 WAF 보호는 많은 검사 지점을 생성하여 보안 팀에 앱 사용에 대한 가시성을 제공하고 앱 팀에 유지 관리 방법에 대한 지식을 제공합니다.
NGINX App Protect Dos와 NGINX App Protect WAF가 악성 트래픽을 제거한 후에도 클라이언트가 합법적이고 요청하는 리소스에 액세스할 권한이 있는지 확인해야 합니다. 여기서 NGINX Plus가 등장하여 인증 및 권한을 처리한 다음 요청을 적절한 서버로 라우팅합니다. NGINX Plus를 API 게이트웨이로 배포하면 여러 API에 대한 하나의 일관된 진입점을 제공하고 스택을 간소화할 수 있습니다.
인증 및 권한 부여는 Single Sign‑On(SSO)을 통해 자동화할 수도 있어 DevOps 팀이 원하는 민첩성을 유지할 수 있습니다. NGINX Plus는 OAuth 2.0 프로토콜을 기반으로 하는 ID 계층인 OpenID Connect (OIDC)를 지원합니다 . NGINX 문서에서 NGINX Plus에서 프록시된 애플리케이션에 대해 SSO를 활성화하기 위해 OIDC를 사용하는 방법을 설명합니다 .
API는 특성상 개방적 이므로 취약한 대상입니다. Gartner Research는 연례 보고서에서 API가 2022년에 가장 흔한 공격 벡터가 되어 기업 웹 앱에 대한 수많은 데이터 침해를 일으킬 것이라고 예측했습니다. 그 예측은 2022년을 맞이하며 조직 전반에서 API 공격 표면이 계속 증가하는 것을 관찰 하면서 사실로 드러납니다.
F5 Labs의 API 인증 사고: 2020 애플리케이션 보호 보고서는 API 사고의 세 가지 일반적인 이유를 강조합니다.
API 트래픽의 인증을 구현하면 신원을 성공적으로 증명한 클라이언트는 신뢰할 수 있는 신원 공급자 로부터 토큰을 받습니다. 그런 다음 클라이언트는 각 HTTP 요청과 함께 액세스 토큰을 제시합니다. 요청이 애플리케이션에 전달되기 전에 NGINX Plus는 토큰을 검증하고 토큰에 인코딩된 신원 및 기타 데이터(예: 그룹 멤버십)를 추출하여 클라이언트의 인증 및 권한 부여를 보장합니다. 토큰이 검증되고 클라이언트가 리소스에 액세스할 수 있는 권한이 부여 되었다고 가정하면 요청이 애플리케이션 서버로 전달됩니다. 이 검증을 수행하는 방법은 여러 가지가 있지만 OpenID Connect(OAuth 2.0 프로토콜 기반)는 API 요청의 타사 인증을 활성화하는 인기 있는 방법입니다.
그러나 시중에 나와 있는 많은 API는 인증 계층에서 보호되지 않습니다. 2021년에 대화형 피트니스 플랫폼인 펠로톤이 누출된 API를 가지고 있는 것으로 밝혀졌습니다 . 보안 연구원은 펠로톤의 API에 인증되지 않은 요청을 하여 인증 없이도 사용자 데이터를 쉽게 검색할 수 있다는 것을 발견했습니다. 펠로톤은 주요 침해가 발생하기 전에 코드를 수정했지만, 이 사고는 보안에 대한 모놀리식 접근 방식이 API 구조의 본질적인 다양성과 이를 방어하는 데 필요한 민첩성을 고려하지 않는다는 점을 보여줍니다.
API는 컴퓨터와 컴퓨터를 연결하도록 설계 되었으므로 많은 DevOps 팀은 인간이 API 엔드포인트와 통신하지 않는다고 가정합니다. F5 Labs 보고서의 한 예는 모바일 앱에서 수십만 달러의 크레딧을 "획득"하기 위해 여러 API 요청을 체인으로 연결한 연구원과 관련이 있습니다. 이 앱은 남용을 방지하기 위해 설계된 토큰을 지속적으로 생성했지만 만료일을 설정하지 않아 계속해서 사용할 수 있었습니다.
API 인증 토큰을 제대로 검증하지 않으면 공격자가 API 취약성을 악용할 수 있습니다. 이런 유형의 취약성이 연구자가 아닌 악의적인 행위자에게 발견되면 전체 비즈니스를 손상시킬 수 있습니다.
실패한 API 인증은 자연스럽게 API 권한 부여가 깨지는 결과를 초래합니다. F5 Labs 보고서는 또한 운영 체제의 버그로 인해 API에 악의적인 HTTP 요청이 허용되어 악의적인 행위자가 권한 부여 토큰에 쉽게 액세스할 수 있는 사건을 설명합니다. 공격자가 이 권한 부여 토큰을 획득한 후 관리자 권한이 부여되었습니다.
NGINX는 API를 보호하고 API 클라이언트를 인증하기 위한 여러 가지 접근 방식을 제공합니다. 자세한 내용은 IP 주소 기반 액세스 제어 목록 (ACL), 디지털 인증서 인증 및 HTTP 기본 인증 에 대한 설명서를 참조하세요. 또한 NGINX Plus는 API 인증을 위해 JSON 웹 토큰(JWT)의 검증을 기본적으로 지원합니다. 자세한 내용은 블로그의 JWT 및 NGINX Plus를 사용하여 API 클라이언트 인증 에서 확인하세요 .
보안을 자동화하면 모든 사람의 책임이 됩니다. 보안 자동화를 우선시 함으로써 조직은 보다 안정적인 앱을 구축하고, 위험을 완화하고, OpEx를 줄이고, 릴리스 속도를 가속화할 수 있습니다. 즉, 마이크로서비스, 앱 및 API는 오늘날의 경쟁에 발맞추기에 충분히 확장 가능하고 빠른 민첩한 보안을 얻게 됩니다.
이 3단계 보안 구조는 DoS 공격으로부터 WAF 검사 트래픽을 막거나 악의적인 행위자를 인증하고 허가하려고 귀중한 리소스를 낭비하고 싶지 않기 때문에 최상의 흐름을 제공합니다. 쉽게 식별되는 공격을 일찍 제거함으로써 시간과 비용을 절약하고 앱 성능을 가속화할 수 있습니다.
위 내용과 같이 NGINX Plus / NGINX App Protect 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
현대 애플리케이션 팀은 " 보안 좌측 이동(Shift-left) " 의 중요성과 이점을 점점 더 인식하고 있습니다 . 즉, 애플리케이션 개발 및 배포 주기 초기에 보안 제어를 통합하는 것입니다. 좌측 이동 세계에서 각 팀은 애플리케이션에 가장 적합한 보안 솔루션과 매개변수를 선택합니다. 물론 이는 합리적입니다. NGINX에서는 적절한 보안 솔루션 세트를 적극적으로 큐레이팅하여 개발자에게 "가드레일이 있는 선택권"을 제공하는 Platform Ops 팀을 옹호합니다 . 그런 다음 개발자는 앱에 대한 보안을 구성해야 하며, 여기에는 일반적으로 내부용 애플리케이션 및 마이크로서비스에 대해서도 웹 애플리케이션 방화벽(WAF)을 배포하는 작업이 포함됩니다.
하지만 쿠버네티스에서 Shift-Left 하는 것은 훨씬 더 복잡해집니다. 쿠버네티스는 현대 앱 팀을 위한 사실상의 표준 컨테이너 오케스트레이션 엔진이며, 특히 커뮤니케이션과 조정은 큰 과제를 안겨줍니다. 개발자에게 여러 클러스터에서 커뮤니케이션을 관리하도록 요청하는 것은 현실적이지 않습니다. 또한 쿠버네티스에서 WAF를 배치하는 데는 아키텍처 및 성능 고려 사항이 있습니다. NGINX App Protect WAF를 사용하면 WAF를 NGINX Ingress Controller와 통합하거나 특정 마이크로서비스나 애플리케이션 앞에 별도의 WAF를 배치할 수 있습니다.
두 접근 방식 모두 훌륭하지만, 각각 다른 사용 사례에 가장 적합합니다. 자체 애플리케이션만 관리하는 데 집중하는 개발자와 앱 팀의 경우, 앱 앞에 있는 NGINX Plus 로드 밸런서에 NGINX App Protect WAF를 배포하는 것이 완벽한 솔루션으로, 이를 통해 제어력과 민첩성을 얻을 수 있습니다. Kubernetes 클러스터와 클러스터에서 실행되는 애플리케이션에 대한 포드 또는 서비스 수준에서 보안을 관리하려는 DevSecOps 팀의 경우, NGINX Plus 기반 NGINX Ingress Controller에서 NGINX App Protect WAF를 실행하는 것이 최적이며, 이를 통해 Ingress 제어의 모든 이점과 Kubernetes API와의 기본 통합을 얻을 수 있습니다.
그러나 앞서 언급했듯이 클러스터 간, 심지어 클러스터 내에서도 로드 밸런서, Ingress 컨트롤러 및 WAF 간의 통신을 설정하는 것은 어렵습니다. 이를 위해서는 레이어 7 및 L4 네트워킹에 대한 자세한 이해와 지속적인 튜닝이 필요합니다. 즉, 강력하고 실시간에 가까운 통신은 강력한 보안 태세를 유지하는 데 필수적 입니다. 적절한 통신을 통해 WAF, 로드 밸런서 및 Ingress 컨트롤러는 모든 애플리케이션과 인스턴스에 새로운 공격을 신속하게 알리고 공격 유형, 대상 프로토콜 및 소프트웨어, 관련 IP 주소 블록 등에 대한 데이터를 공유할 수 있습니다. 빠른 패턴 인식을 위해 머신 러닝(ML)을 추가하면 통신이 더욱 강력해 집니다.
NGINX App Protect WAF에는 Platform Ops, DevSecOps 및 SecOps 팀이 단일 조직에서 NGINX Plus 또는 NGINX Plus 기반 NGINX Ingress Controller에서 관리되는 모든 WAF에서 공격 추세와 데이터를 쉽게 공유할 수 있는 풍부한 ML 시스템이 포함되어 있습니다. NGINX App Protect WAF에서 새로운 기능인 Adaptive Violation Rating 기능을 개발하고 있으며, 이는 마이크로서비스의 동작이 변경될 때를 감지하여 보안 튜닝을 개선하기 위해 ML을 더욱 활용합니다. 이 ML 기능을 통해 NGINX App Protect WAF는 전 세계에 있는 수천 개 또는 수만 개의 WAF에서도 공격 추세를 지속적이고 자동으로 분석할 수 있습니다. 이 분석의 결과는 개발자 및 기타 Shift-Left 팀이 보안 전문가가 되어 WAF를 조작할 필요 없이 거의 실시간으로 보안 포스처를 지속적으로 조정하는 데 사용할 수 있습니다. 더 좋은 점은 NGINX App Protect WAF 인스턴스 간에 공유되는 데이터가 많을수록 WAF가 더욱 지능화 된다는 것입니다.
기업이 마이크로서비스 사용을 확대하고 내부 및 외부 애플리케이션 간의 구분이 줄어들면서 ML 기능은 점점 더 중요하고 가치가 높아지고 있습니다. 잠재적으로 수천 개의 마이크로서비스가 있고 각각 자체 경량 WAF를 가지고 있는 네트워크 및 ML 지원 NGINX App Protect WAF는 앱을 감시하는 살아있는 보안 브레인과 같습니다. 최신 앱은 Shift-Left 팀을 수용하고 보안 전문가가 되지 않고도 코드와 기능 제공에 집중할 수 있도록 더 스마트해야 합니다. DevSecOps 팀도 수동 조정 없이도 모든 클러스터의 모든 WAF가 같은 페이지에 있다는 것을 알고 마음의 평화를 누릴 수 있습니다.
커뮤니케이션이 핵심입니다. 이는 우리가 모든 제품에 걸쳐 구축하고 있는 핵심 기능으로, 대량 분산 컴퓨팅과 현대 앱이 빠르게 진화하는 이 시대에 최상의 기술을 계속 제공하기 위해 노력하고 있습니다.
위 내용과 같이 NGINX Ingress Controller 및 NGINX App Protect WAF 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
모놀리스가 마이크로서비스로 이동함에 따라 애플리케이션은 그 어느 때보다 빠르게 개발됩니다. 경쟁력을 유지하려면 속도가 필요하며 API는 이러한 신속한 현대화 노력의 최전선에 있습니다. 그러나 애플리케이션 현대화를 위한 API의 인기는 앱 보안에 상당한 영향을 미칩니다. API는 취약한 공격 대상이며 애플리케이션 로직과 민감한 데이터를 다른 앱이나 타사에 노출시킵니다. API 사용이 증가함에 따라 API 게이트웨이에 대한 필요성도 커집니다.
F5의 2021년 애플리케이션 전략 보고서 에 따르면 조직은 다양한 방법을 사용하여 현대화하고 있으며 API는 이러한 현대화 노력의 선두에 있습니다.
조직이 성장함에 따라 API 게이트웨이를 채택하여 API 위험을 완화할 수 있습니다. F5의 업데이트된 2022년 애플리케이션 전략 보고서 에서 API 게이트웨이는 에지에서 또는 에지 근처에서 가장 좋은 성능을 발휘하는 것을 확인할 수 있습니다. 여기서 API 게이트웨이는 전체 네트워크에 영향을 미치기 전에 공격을 차단하여 여러 API에 대한 균일하고 일관된 보호를 제공할 수 있습니다. API 게이트웨이는 앱의 내부 구조를 캡슐화하여 클라이언트와 API 간의 통신을 간소화합니다. 클라이언트는 특정 서비스를 호출하는 대신 API 게이트웨이에 연결하기만 하면 됩니다. 이를 통해 클라이언트에 특정 API가 제공되고 클라이언트와 API 간의 왕복 횟수가 줄어들며 클라이언트 코드가 간소화됩니다.
F5 NGINX 고객은 분산 환경에서 API 게이트웨이를 성공적으로 배포했습니다. 하지만 API 게이트웨이가 안전하지 않으면 악의적인 행위자가 여전히 침투할 수 있습니다. NGINX에서는 API 게이트웨이 뒤에 있는 앱이 끊임없이 변화하는 이 환경에서 안전하게 유지되도록 보장하는 강력한 보안 도구를 갖추고 있습니다.
API는 새로운 것이 아닙니다. 웹 기반 API는 1990년대로 거슬러 올라가며, 오늘날 우리가 알고 있는 인터넷 이전에도 소규모 분산 네트워크 간의 통신으로 API 버전이 존재했습니다. 지금 우리가 보고 있는 것, 게임을 바꾼 것은 API를 사용하는 최신 아키텍처입니다.
API는 현대화를 가속화하는 데 중요한 역할을 하지만 동시에 악용하기가 더 쉬워지고 있습니다. 마이크로서비스 아키텍처에서 단일 API는 수백 개의 엔드포인트를 가질 수 있고 단일 애플리케이션은 API를 사용하여 서로 연결하는 여러 마이크로서비스로 구성될 수 있습니다. 이는 보안해야 할 진입점이 하나뿐이었던 과거의 모놀리식 앱과 다릅니다. 각 마이크로서비스가 여러 API 엔드포인트 세트를 노출함에 따라 잠재적인 공격 표면이 10배로 늘어났습니다.
F5의 2022년 보고서는 또한 대부분 조직이 200~1,000개의 앱을 보유하고 있으며 77%가 여러 클라우드에서 애플리케이션을 실행한다는 사실을 발견했습니다. 분산 환경에서 포트폴리오에 추가된 앱과 API가 많을수록 공격 표면이 커질 가능성이 있습니다.
API는 일반적으로 개방되어 민감한 데이터를 노출할 수 있습니다. Open Web Application Security Project(OWASP)는 OWASP API Security Top 10 프로젝트 에서 가장 널리 퍼진 취약점을 강조합니다 .
오늘날의 기업은 개발 주기가 빨라짐에 따라 민첩성과 속도가 필요합니다. 이 취약한 API 중심 환경에서 보안 솔루션은 적응 가능하고 가벼우며 API의 자동화된 배포 프로세스의 일부로 통합되어야 합니다.
프로필이 높은 API 공격은 정기적으로 헤드라인을 장식합니다. 2019년에 승차 공유 회사 Uber는 API에서 심각한 버그를 발견했습니다 . 취약한 API 엔드포인트를 통해 악의적인 행위자가 라이더의 인증 토큰을 포함한 귀중한 데이터를 훔칠 수 있었습니다. 다행히도 이 버그는 피해가 발생하기 전에 발견되었습니다. 2021년에 LinkedIn은 운이 좋지 않았습니다. API 취약성으로 인해 해커가 7억 명이 넘는 LinkedIn 사용자의 데이터를 침해했고 , 이 데이터는 다크 웹에서 판매되었습니다.
F5 NGINX Plus를 API 게이트웨이로 배포 하면 API 라우팅 및 전달을 처리할 때 고성능으로 이 빠른 API 환경에 진입할 수 있습니다. 독립적인 기술 연구 및 분석 회사인 GigaOm은 NGINX를 다른 API 게이트웨이 솔루션과 비교했습니다 . 벤치마크 결과에 따르면 NGINX는 30ms 미만의 지연 시간으로 초당 30,000개의 요청을 전달할 수 있었으며, 이는 하이퍼스케일러의 API 게이트웨이보다 1000배 낮은 지연 시간입니다.
NGINX Plus는 OWASP API 취약성 뿐만 아니라, 추가 보안 보호 기능에는 잘못된 쿠키, JSON 및 XML에 대한 검사, 허용된 파일 유형 및 응답 상태 코드의 검증이 포함됩니다. HTTP RFC를 준수하고 공격을 가리는 데 사용되는 회피 기술을 감지합니다.
NGINX Plus는 API 요청을 빠르게 라우팅하는 동시에 API 클라이언트를 인증하고 승인하여 API를 보호하고 트래픽 속도를 제한하여 API 기반 서비스를 과부하로부터 보호합니다. 이러한 도구는 또한 OWASP API 보안 상위 10대 취약성으로부터 API를 보호합니다.
F5 NGINX App Protect WAF 로 API 게이트웨이를 보호하면 추가적인 API 보안을 제공하고 Injection (API8)과 같은 OWASP 공격을 완화합니다. OWASP API 보호를 위한 최소한의 보안만 제공하는 다른 API 게이트웨이 및 관리 공급업체와 달리 NGINX App Protect WAF는 원격 코드 실행(RCE), 크로스 사이트 스크립팅(XSS) 및 기타 공격 벡터와 같은 취약성에 대한 추가적인 보호 기능을 제공합니다. NGINX App Protect WAF는 또한 Insufficient Logging & Monitoring (API10)에 필요한 공격 가시성을 제공합니다. 이러한 로깅된 공격 세부 정보는 추가 분석을 위해 SIEM(보안 정보 및 이벤트 관리) 시스템 또는 기타 고객 데이터 레이크로 전송할 수 있습니다.
NGINX Plus를 API 게이트웨이 및 로드 밸런서(인터넷에 노출되어야 하는 API 라우팅 및 외부 개발자 및 파트너용)로 사용하는 경우 보호를 위해 NGINX App Protect WAF를 배포하기에 최적의 장소입니다. API 트래픽에 대한 홉이 하나 적기 때문에 최소한의 복잡성과 가장 낮은 지연 시간으로 보호를 추가할 수 있습니다.
특정 산업에서 민감한 데이터(개인 식별 정보[PII])를 처리하기 위한 PCI 규정 준수 요구 사항에 따라 페이로드는 개방형 퍼블릭 네트워크에서 종단 간 암호화 되어야 합니다 . 로드 밸런서 또는 CDN 뒤의 API 게이트웨이에 NGINX App Protect WAF가 있으면 페이로드가 API 게이트웨이에서 복호화될 때까지 완전히 암호화된 상태로 유지됩니다. 따라서 API는 민감한 데이터 처리 요구 사항을 충족하는 동안 보호 상태를 유지할 수 있습니다.
로드 밸런서가 있고, 로드 밸런서에 F5 Advanced WAF와 같은 WAF가 있을 수 있습니다. 그 뒤에 API 게이트웨이를 배포했습니다. 로드 밸런서에 이미 WAF가 있는데 왜 API 게이트웨이에 WAF가 필요할까요?
에지의 로드 밸런서-WAF 조합에서 환경 내부의 API 게이트웨이-WAF 조합으로 이동하는 주요 이점 중 하나는 보안에 대한 더 엄격하고 세부적인 제어입니다. 보안에 대한 책임을 API 팀에 넘겨 정책을 더 API에 특화할 수 있습니다.
이러한 2계층 접근 방식을 사용하면 가장 빠른 API 개발 및 릴리스 주기에서도 API가 보호되도록 할 수 있습니다.
보호가 API별로 이루어져야 하는 주요 영역은 Swagger의 OpenAPI 사양 검증 입니다 . OpenAPI 스키마는 각 API에 고유하며 각 API 버전에 따라 변경됩니다. API의 OpenAPI 스키마를 기반으로 하는 보호는 IT 팀이 유지 관리하는 중앙 집중식 WAF에서 보안 제어를 업데이트할 때까지 기다릴 수 없으며, 다른 API와 앱에 예상치 못한 영향을 미치지 않도록 승인과 신중한 테스트가 필요합니다.
NGINX App Protect WAF는 OpenAPI 스키마를 검증하여 요청이 API가 지원하는 것(메서드, 엔드포인트, 매개변수 등)을 준수하는지 확인할 수 있습니다. 이것이 NGINX App Protect WAF가 로드 밸런서의 중앙 집중식 WAF 뒤에 있는 API 게이트웨이에서 긍정적인 보안을 제공하는 것이 이상적인 이유입니다.
CI/CD 파이프라인은 보안이 아닌 속도를 위해 구축되었습니다. API는 또한 과거 앱보다 더 자주 게시됩니다. 이것이 API 중심 환경에서 쉬프트 레프트(Shift Left) 움직임을 보는 이유입니다. 쉬프트 레프트(Shift Left) 또는 앱 개발 수명 주기 초기에 보안 제어를 적용함으로써 DevOps는 보안을 코드로 처리하는 DevSecOps 문화로 이동합니다.
API 게이트웨이, 로드 밸런서 또는 둘 다에 WAF를 배치하든, WAF 구성은 API 버전 변경에 맞춰 자동화된 방식으로 배포해야 합니다. 조직이 Shift‑Left 문화를 채택하고 CI/CD 파이프라인에 "코드로서의 보안"을 통합하면 보안을 사후에 볼트로 고정하는 대신 애플리케이션 및 API 개발의 각 단계에 내장할 수 있습니다.
보안 정책과 구성을 코드로 사용하면 다음과 같은 많은 이점이 있습니다.
API 스키마를 자동화할 때 API를 업데이트할 때마다 해당 파일의 구성과 코드도 업데이트해야 합니다. 다시 말하지만, 자동화가 핵심입니다. Shift‑Left 또는 "보안 우선" 철학이 완전히 채택되면 개발자는 리포에서 해당 코드를 쉽게 가져올 수 있습니다. 민첩성을 유지하고 속도를 높이며 출시 시간을 단축할 수 있습니다.
API를 보호하기 위해 WAF를 어디에 두든, 고성능과 낮은 대기 시간은 API가 고객에게 빠르게 대응하여 더 풍부한 사용자 경험을 제공할 수 있는 요구 사항입니다. NGINX App Protect WAF의 가벼운 아키텍처는 클라우드에서 매우 낮은 컴퓨팅 요구 사항으로 이러한 고성능과 낮은 대기 시간을 제공합니다.
GigaOm은 고성능 애플리케이션 보안 테스트 보고서 에서 NGINX App Protect WAF, AWS WAF, Azure WAF 및 ModSecurity 오픈 소스 WAF에 대한 성능 테스트 결과를 보고합니다. GigaOm은 NGINX App Protect WAF가 NGINX의 ModSecurity OSS WAF보다 대기 시간이 4.7배 낮고, 고성능이 필요한 애플리케이션의 경우 AWS WAF보다 대기 시간이 128배 낮다는 것을 발견했습니다.
NGINX는 WAF를 NGINX API 게이트웨이에 내장하는 유일한 공급업체로, API 트래픽에 대한 홉이 하나 줄어듭니다. 계층 간 홉이 적으면 지연, 복잡성 및 장애 지점이 줄어듭니다. 이는 WAF와 통합되지 않는 일반적인 API 관리 솔루션과는 극명한 대조를 이룹니다(WAF를 별도로 배포해야 하며, 일단 설정되면 API 트래픽이 WAF와 API 게이트웨이를 별도로 통과해야 함). NGINX의 긴밀한 통합은 보안을 손상시키지 않으면서도 높은 성능을 의미합니다.
NGINX에서는 NGINX Plus와 NGINX App Protect WAF로 강력한 API 보안을 제공합니다. NGINX의 가벼운 확장성과 F5의 Advanced WAF 엔진의 견고성을 통해 최신 앱이 안전하다는 확신을 가지고 API 중심 세계에 진입할 수 있습니다.
NGINX의 핵심 가치 에 충실한 NGINX App Protect WAF는 플랫폼에 구애받지 않고 일반적인 DevOps 툴체인과 원활하게 통합되어 마찰을 제거하고 안전한 배포를 가속화하는 최신 애플리케이션 소프트웨어 보안 솔루션입니다. 선언적 구성 기능을 통해 보안은 CI/CD 파이프라인과 전체 소프트웨어 개발 수명 주기(SDLC)의 일부로 자동화될 수 있습니다. 이는 릴리스 속도를 높이는 데 도움이 될 뿐만 아니라 조직이 DevOps와 SecOps 팀 간의 격차를 메우고 DevSecOps로의 문화적 변화를 가능하게 하면서 안정적이고 보호된 API를 구축하는 데 도움이 됩니다.
위 내용과 같이 NGINX Plus / NGINX App Protect 를 활용하여 보안취약점 완화가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요