NGINX App Protect WAF로 지연시간 추가 없는 API Gateway 보호

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

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

  • 58%는 최신 사용자 인터페이스를 지원하기 위해 API 계층을 추가하고 있습니다.
  • 51%는 최신 애플리케이션 구성 요소(예: Kubernetes)를 추가하고 있습니다.
  • 47%는 refactoring(애플리케이션 코드 자체 수정)
  • 40%는 현대화 없이 public 클라우드(lifting and shifting)로 전환하고 있습니다.
Horizontal bar graph showing percentage of organizations modernizing in four different ways

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

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

목차

1. API가 많을수록 공격 표면도 넓어집니다.
2. OWASP API 보안 상위 10개 취약점
3. NGINX Plus로 API 보안 시작
4. NGINX AppProtect WAF로 API 강화
5. NGINX App Protect WAF를 통한 Multi-Layer 보호
6. OpenAPI 스키마 검증으로 확실한 보안 추가
7. API 배포 보조를 맞추는 “Security as Code”
8. API를 위한 고성능 보호
9. 결론

1. API가 많을수록 공격 표면도 넓어집니다.

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

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

Bar graph comparing average size of application portfolios for organizations between 2017 to 2022. Average size is 200 to 1000 with a range of 1 to 3000+

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

2. OWASP API Security Top 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 보안 시작

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

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

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

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

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

4. NGINX AppProtect WAF로 API 강화

NGINX App Protect WAF를 사용하여 API Gateway를 보호하면 추가 API 보안을 제공되며 Injection(API8)과 같은 OWASP 공격을 완화합니다. 최소한의 OWASP API 보호를 제공하는 다른 API Gateway 및 관리 공급자와 달리 NGINX App Protect WAF는 RCE(원격 코드 실행), XSS(사이트 간 스크립팅) 및 기타 공격 벡터와 같은 취약점에 대한 추가 보호 기능을 제공합니다. 또한 NGINX App Protect WAF는 Insufficient Logging & Monitoring(API10)에 필요한 공격 가시성을 제공합니다. 이렇게 기록된 공격 세부 정보는 추가 분석을 위해 SIEM(보안 정보 및 이벤트 관리) 시스템 또는 기타 고객 data lake로 보낼 수 있습니다.

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

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

5. NGINX App Protect WAF를 통한 Multi-Layer 보호

Topology diagram of three options for deploying NGINX App Protect WAF with API gateways

Load balancer가 있고 해당 Load balancer에 Advanced WAF와 같은 WAF가 있을 수 있습니다. 그 뒤에 API Gateway를 배치했습니다. 그러면 Load balancer에 이미 WAF가 이미 있는데 API Gateway에 WAF가 필요한 이유는 무엇입니까?

Load balancer에서 전환할 때 얻을 수 있는 주요 이점 중 하나는 다음과 같습니다.API Gateway에 대한 Edge에 있는 WAF 조합 -환경 내의 WAF 조합은 보안을 더욱 세밀하게 제어합니다. 보안 책임은 정책을 보다 구체적인 API로 만들기 위해 API 팀에 인계될 수 있습니다.

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

6. OpenAPI 스키마 검증으로 확실한 보안 추가

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

NGINX AppProtect WAF가 Open을 검증할 수 있음API 스키마, 요청이 API가 지원하는 것(methods, endpoints, parameter 등)을 준수하는지 확인합니다. 따라서 Load balancer의 중앙 집중형 WAF 뒤에 있는 API Gateway에서 NGINX App Protect WAF가 확실한 보안을 제공하는 것이 이상적입니다.

7. API 배포 보조를 맞추는 “Security as Code”

CI/CD pipeline은 보안이 아니라 속도를 위해 구축되었습니다. API는 또한 과거의 애플리케이션보다 더 자주 공개됩니다. 이것이 우리가 API 중심 환경에서 왼쪽 움직임을 보고 있는 이유입니다. 왼쪽으로 이동(shifting left)하거나 애플리케이션 개발 수명 주기 초기에 보안 제어를 적용함으로써 DevOps는 보안이 Code로 취급되는 DevSecOps 문화로 이동합니다.

Icon with infinity symbol showing the DevSecOps workflow

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

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

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

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

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 관리 솔루션과 극명한 대조를 이룹니다(WAF를 별도로 배포해야 하며 일단 설정되면 API 트래픽이 WAF와 API Gateway를 별도로 통과해야 함). NGINX의 긴밀한 통합은 보안에 영향을 주지 않으면서 고성능을 의미합니다.

9. 결론

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

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

NGINX App Protect WAF의 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.