API Gateway에 고성능 WAF를 쉽게 통합하는 방법

모놀리스가 마이크로서비스로 이동함에 따라 애플리케이션은 그 어느 때보다 빠르게 개발됩니다. 경쟁력을 유지하려면 속도가 필요하며 API는 이러한 빠른 현대화 노력의 선두에 있습니다. 그러나 애플리케이션 현대화를 위한 API의 인기는 앱 보안에 상당한 영향을 미칩니다. API는 취약한 공격 대상이며 애플리케이션 로직과 민감한 데이터를 다른 앱이나 제3자에게 노출시킵니다. API 사용량이 증가함에 따라 API Gateway의 필요성도 증가합니다.

NGINX의 2021년 애플리케이션 전략 현황 보고서에 따르면 조직은 현대화를 위해 다양한 방법을 사용하고 있으며 API는 이러한 현대화 노력의 정점에 있습니다.

  • 58%는 최신 사용자 인터페이스를 지원하기 위해 API 계층을 추가하고 있습니다.
  • 51%는 최신 애플리케이션 구성 요소(예: Kubernetes)를 추가하고 있습니다.
  • 47%는 리팩토링(애플리케이션 코드 자체 수정)
  • 40%는 현대화 없이 Public Cloud로 이동(lifting and shifting)

조직이 성장함에 따라 API Gateway를 채택하여 API 위험을 완화할 수 있습니다. NGINX의 업데이트된 2022 애플리케이션 전략 현황 보고서에서 API Gateway가 Edge에서 또는 Edge 근처에서 가장 잘 수행되는 것을 확인했습니다. 여기에서 API Gateway는 공격이 전체 네트워크에 영향을 미치기 전에 차단하여 여러 API에 대해 균일하고 일관된 보호를 제공합니다. API Gateway는 앱의 내부 구조를 캡슐화하여 클라이언트와 API 간의 통신을 간소화합니다. 클라이언트는 특정 서비스를 호출하는 대신 API Gateway에 연결하기만 하면 됩니다. 이는 클라이언트에 특정 API를 제공하고 클라이언트와 API 간의 왕복 횟수를 줄이며 클라이언트 코드를 단순화합니다.

NGINX 고객은 분산 환경 전반에 API Gateway를 성공적으로 배포했습니다. 그러나 API Gateway가 안전하지 않은 경우 악의적인 행위자가 여전히 통과할 수 있습니다. NGINX에는 API Gateway 뒤에 있는 앱이 끊임없이 변화하는 환경에서 안전하게 유지되도록 하는 강력한 보안 도구가 있습니다.


목차

1. 더 많은 API는 더 많은 공격 노출 영역을 의미합니다.
2. OWASP API 보안 상위 10개 취약점
3. NGINX Plus로 API 보안 시작
4. NGINX App Protect WAF로 API 강화
5. NGINX App Protect WAF를 통한 다중 계층 보호
6. OpenAPI 스키마 유효성 검사로 확실한 보안 추가
7. API Deployments에 보조를 맞추는 “코드로서의 보안”
8. API를 위한 고성능 보호
9. 결론

1. 더 많은 API는 더 많은 공격 노출 영역을 의미합니다.

API는 새로운 것이 아닙니다. 웹 기반 API는 1990년대로 거슬러 올라가며 API 버전은 오늘날 우리가 알고 있는 인터넷 이전에도 소규모 분산 네트워크 간의 통신으로 존재했습니다. 지금 우리가 보고 있는 – 게임을 바꾼 것은 API를 사용하는 최신 아키텍처입니다.

API는 현대화를 가속화하는 데 중요한 역할을 하는 동시에 악용하기 더 쉬워지고 있습니다. 마이크로서비스 아키텍처(MSA)에서 단일 API는 수백 개의 Endpoints를 가질 수 있고 단일 애플리케이션은 API를 사용하여 서로 연결하는 많은 Microservices로 구성될 수 있습니다. 이는 보안을 위한 진입점이 단 하나였던 과거의 모놀리식 앱과 다릅니다. 각 마이크로서비스가 여러 API Endpoint 세트를 노출하면서 잠재적인 공격 표면이 10배 증가했습니다.

NGINX의 2022년 보고서에 따르면 대부분의 조직에는 200~1,000개의 앱이 있으며 77%는 여러 클라우드에서 애플리케이션을 실행합니다. 분산 환경의 포트폴리오에 더 많은 앱과 API가 추가될수록 가능한 공격 표면이 커집니다.

2. OWASP API 보안 상위 10개 취약점

특징적으로 API는 개방적이며 민감한 데이터를 노출할 수 있습니다. OWASP(Open Web Application Security Project)는 OWASP API Security Top 10 프로젝트에서 가장 널리 퍼진 취약점을 강조합니다.

  • API1. Broken Object Level Authorization
  • API2. Broken User Authentication
  • API3. Excessive Data Exposure
  • API4. Lack of Resources & Rate Limiting
  • API5. Broken Function Level Authorization
  • API6. Mass Assignment
  • API7. Security Misconfiguration
  • API8. Injection
  • API9. Improper Assets Management
  • API10. Insufficient Logging & Monitoring

오늘날의 비즈니스에는 개발 주기가 빨라짐에 따라 민첩성과 속도가 필요합니다. 이 취약한 API 중심 환경의 보안 솔루션은 적응 가능하고 가벼우며 API의 자동화된 배포 프로세스의 일부로 통합되어야 합니다.

3. NGINX Plus로 API 보안 시작

높은 프로필 API 공격은 정기적으로 헤드라인을 장식합니다. 2019년에 승차 공유 회사인 Uber는 API에서 치명적인 버그를 발견했습니다. 취약한 API Endpoint를 통해 악의적인 행위자가 탑승자의 인증 토큰을 비롯한 귀중한 데이터를 훔칠 수 있었습니다. 고맙게도 이 버그는 피해가 발생하기 전에 발견되었습니다. 2021년 LinkedIn은 운이 좋지 않았습니다. API 취약성으로 인해 해커가 7억 명이 넘는 LinkedIn 사용자의 데이터를 유출했으며 다크 웹에서 판매용으로 제공되었습니다.

NGINX Plus를 API Gateway로 배포하면 API 라우팅 및 전달을 처리할 때 고성능으로 이 빠른 API 환경에 진입할 수 있습니다. 독립 기술 연구 및 분석 회사인 GigaOm은 다른 API Gateway 솔루션에 대해 NGINX를 벤치마킹했습니다. 벤치마크 결과에 따르면 NGINX는 하이퍼스케일러의 API Gateway보다 1000배 낮은 지연 시간인 30ms 미만의 지연 시간으로 초당 30,000개의 요청을 전달할 수 있었습니다.

NGINX Plus는 OWASP API 취약점에 대한 즉시 사용 가능한 보호 기능을 제공합니다. 추가 보안 보호 기능에는 잘못된 쿠키, JSON 및 XML 검사가 포함되어 있으며 허용된 파일 유형 및 응답 상태 코드의 유효성을 검사합니다. HTTP RFC 준수를 보장하고 공격을 마스킹하는 데 사용되는 회피 기술을 탐지합니다.

NGINX Plus는 API 요청을 빠르게 라우팅하는 동시에 API 클라이언트를 인증 및 승인하여 API를 보호하고 트래픽 속도를 제한하여 과부하로부터 API 기반 서비스를 보호합니다. 이러한 도구는 또한 OWASP API 보안 상위 10개 취약점으로부터 API를 보호합니다.

  • 인증 및 권한 부여 메커니즘 – 올바른 액세스 권한이 있는 클라이언트만 API를 사용할 수 있도록 합니다. 그러한 메커니즘 중 하나는 JWT(JSON Web Tokens)의 클레임입니다. 이것은 OWASP API Security Top 10의 여러 취약점인 Broken Object Level Authorization(API1), Broken User Authentication(API2), Broken Function Level Authorization(API5), Insufficient Logging & Monitoring(API10)을 해결합니다.
  • 속도 제한 정책 – API Gateway가 정의된 기간 내에 각 API 클라이언트에서 수락하는 요청 수에 제한을 설정하여 과부하로부터 API를 보호하고 DDoS 공격을 완화합니다. NGINX Plus를 사용하면 비율 제한이 소스에 따라 달라질 수 있으므로(예: JWT 청구 값을 기반으로) 유효한 사용자가 영향을 받지 않습니다. 이는 리소스 부족 및 속도 제한(API4) 취약점을 해결하는 데 도움이 됩니다.

4. NGINX App Protect WAF로 API 강화

NGINX App Protect WAF로 API Gateway를 보호하면 추가 API 보안을 제공하고 주입(API8)과 같은 OWASP 공격을 완화합니다. 최소한의 OWASP API 보호를 제공하는 다른 API Gateway 및 관리 공급자와 달리 NGINX App Protect WAF는 RCE(원격 코드 실행), XSS(교차 사이트 스크립팅) 및 기타 공격 벡터와 같은 취약점에 대한 추가 보호 기능을 제공합니다. NGINX App Protect WAF는 또한 불충분한 로깅 및 모니터링(API10)에 필요한 공격 가시성을 제공합니다. 이러한 기록된 공격 세부 정보는 추가 분석을 위해 SIEM(보안 정보 및 이벤트 관리) 시스템 또는 기타 고객 데이터 레이크로 보낼 수 있습니다.

NGINX Plus를 API Gateway 및 Load Balancer(인터넷에 노출되어야 하는 API 라우팅 및 외부 개발자 및 파트너용)로 사용하는 경우 보호를 위해 NGINX App Protect WAF를 배포하는 것이 가장 좋습니다. API 트래픽에 대한 홉(hop)이 하나 줄어들면 최소한의 복잡성과 최저 지연 시간으로 보호 기능을 추가할 수 있습니다.

특정 산업에서 민감한 데이터(개인 식별 정보[PII])를 처리하기 위한 PCI 규정 준수 요구 사항에 따라 페이로드는 개방형 공용 네트워크에서 종단 간 암호화되어야 합니다. 로드 밸런서 또는 CDN 뒤의 API Gateway에 NGINX App Protect WAF가 있다는 것은 페이로드가 API Gateway에서 해독될 때까지 완전히 암호화된 상태로 유지된다는 의미입니다. 따라서 민감한 데이터를 처리하기 위한 요구 사항을 충족하면서 API를 보호할 수 있습니다.

5. NGINX App Protect WAF를 통한 다중 계층 보호

로드 밸런서가 있을 수 있고 해당 로드 밸런서에 WAF가 있을 수 있습니다. 그 뒤에 API Gateway를 배포했습니다. 그렇다면 로드 밸런서에 이미 WAF가 있는 경우 API Gateway에 WAF가 필요한 이유는 무엇일까요?

Edge의 로드 밸런서-WAF 조합에서 환경 내부의 API Gateway-WAF 조합으로 이동할 때 얻을 수 있는 주요 이점 중 하나는 보안에 대한 보다 엄격하고 세분화된 제어입니다. 보안에 대한 책임은 API 팀으로 이관되어 정책을 보다 API에 맞게 만들 수 있습니다.

이 2계층 접근 방식을 사용하면 가장 빠른 API 개발 및 릴리스 주기에서도 API를 보호할 수 있습니다.

6. OpenAPI 스키마 유효성 검사로 확실한 보안 추가

API별로 보호되어야 하는 핵심 영역은 Swagger의 OpenAPI 사양 검증입니다. OpenAPI 스키마는 각 API에 고유하며 각 API 버전에 따라 변경됩니다. API의 OpenAPI 스키마 기반 보호는 IT 팀이 유지 관리하는 중앙 집중식 WAF에 대한 보안 제어를 업데이트하기를 기다릴 수 없습니다. 이를 위해서는 다른 API 및 앱에 대한 예기치 않은 영향을 방지하기 위해 승인과 신중한 테스트가 필요합니다.

NGINX App Protect WAF는 OpenAPI 스키마의 유효성을 검사하여 요청이 API가 지원하는 항목(메서드, Endpoint, 매개변수 등)과 호환되는지 확인할 수 있습니다. 이것이 바로 NGINX App Protect WAF가 로드 밸런서의 중앙 집중식 WAF 뒤에 있는 API Gateway에서 확실한 보안을 제공하도록 하는 것이 이상적인 이유입니다.

7. API Deployments에 보조를 맞추는 “코드로서의 보안”

CI/CD 파이프라인은 보안이 아닌 속도를 위해 구축되었습니다. API는 또한 과거의 앱보다 더 자주 게시됩니다. 이것이 우리가 API 중심 환경에서 왼쪽으로 이동하는 움직임을 보고 있는 이유입니다. 왼쪽으로 이동하거나 앱 개발 수명 주기 초기에 보안 제어를 적용함으로써 DevOps는 보안이 코드로 취급되는 DevSecOps 문화로 이동합니다.

API Gateway, 로드 밸런서 또는 둘 다에서 WAF를 찾으든 상관없이 WAF 구성은 API 버전 변경 사항을 따라잡기 위해 자동화된 방식으로 배포되어야 합니다. 조직에서 shift-left 문화를 채택하고 “security as code”을 CI/CD 파이프라인에 통합할 때 보안은 나중에 고려하는 것이 아니라 애플리케이션 및 API 개발의 각 단계에 구축될 수 있습니다.

코드로 사용되는 보안 정책 및 구성에는 많은 이점이 있습니다.

  • 소스 코드 저장소에서 코드를 쉽게 가져올 수 있습니다.
  • SecOps 팀은 선언적 보안 정책을 만들고 유지 관리하여 비즈니스를 보호하는 데 필요한 제어가 제대로 이루어지도록 할 수 있습니다.
  • 선언적 정책은 새로운 앱과 API에 반복적으로 코딩할 수 있습니다.
  • 보안이 CI/CD 파이프라인으로 자동화됩니다.

API 스키마를 자동화할 때 API를 업데이트할 때마다 해당 파일의 구성과 코드도 업데이트해야 합니다. 다시 말하지만, 자동화가 핵심입니다. 시프트 레프트 또는 “보안 우선” 철학이 완전히 채택되면 개발자는 리포지토리에서 해당 코드를 쉽게 가져와 민첩성을 유지하고 속도를 높이며 출시 시간을 단축할 수 있습니다.

8. API를 위한 고성능 보호

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 Gateway에 내장하여 API 트래픽에 대한 홉(hop)을 한 개 줄여주는 유일한 공급업체입니다. 레이어 간 홉(hop) 수가 줄어들면 지연 시간, 복잡성 및 실패 지점이 줄어듭니다. 이는 WAF와 통합되지 않는 일반적인 API Management 솔루션과 극명한 대조를 이룹니다(WAF를 별도로 배포해야 하며 일단 설정되면 API 트래픽이 WAF와 API Gateway를 별도로 통과해야 함). NGINX의 긴밀한 통합은 보안을 손상시키지 않으면서 고성능을 의미합니다.

9. 결론

NGINX에서는 NGINX Plus 및 NGINX App Protect WAF를 통해 강력한 API 보안을 제공합니다. NGINX의 가벼운 확장성과 고급 WAF 엔진의 견고함을 통해 최신 앱이 안전하다는 확신을 갖고 API 중심의 세계로 들어갈 수 있습니다.

NGINX의 핵심 가치에 충실한 NGINX App Protect WAF는 플랫폼에 구애받지 않고 일반적인 DevOps 도구 체인과 원활하게 통합되어 마찰을 제거하고 보안 배포를 가속화하는 최신 애플리케이션 소프트웨어 보안 솔루션입니다. 선언적 구성 기능을 사용하면 CI/CD 파이프라인과 전체 소프트웨어 개발 수명 주기(SDLC)의 일부로 보안을 자동화할 수 있습니다. 이는 릴리스 속도를 높이는 데 도움이 될 뿐만 아니라 조직이 DevOps와 SecOps 팀 간의 격차를 해소하고 DevSecOps로의 문화적 전환을 가능하게 하는 동시에 안정적이고 보호되는 API를 구축하는 데 도움이 됩니다.