NGINX App Protect WAF로 API 게이트웨이를 보호하세요

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

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

• 58%는 최신 사용자 인터페이스를 활성화하기 위해 API 계층을 추가하고 있습니다.
• 51%는 최신 애플리케이션 구성 요소(예: Kubernetes)를 추가하고 있습니다.
• 47%는 리팩토링(애플리케이션 코드 자체 수정)을 하고 있습니다.
• 40%는 현대화 없이 퍼블릭 클라우드로 이동(리프팅 및 전환)하고 있습니다.

조직이 성장함에 따라 API 게이트웨이를 채택하여 API 위험을 완화할 수 있습니다. F5의 2022년 업데이트된 애플리케이션 전략 보고서 에 따르면 API 게이트웨이는 에지 또는 에지 근처에서 가장 좋은 성능을 발휘하는 것으로 나타났습니다. API 게이트웨이는 공격이 전체 네트워크에 영향을 미치기 전에 공격을 차단하여 여러 API에 대해 균일하고 일관된 보호 기능을 제공합니다. API 게이트웨이는 앱의 내부 구조를 캡슐화하여 클라이언트와 API 간의 통신을 간소화합니다. 클라이언트는 특정 서비스를 호출하는 대신 API 게이트웨이에 연결하기만 하면 됩니다. 이를 통해 클라이언트에게 특정 API를 제공하고, 클라이언트와 API 간의 왕복 횟수를 줄이고, 클라이언트 코드를 단순화할 수 있습니다.

F5 NGINX 고객은 분산 환경 전반에 API 게이트웨이를 성공적으로 배포했습니다. 하지만 API 게이트웨이가 보안되지 않은 경우에도 악의적인 공격자가 침입할 수 있습니다. NGINX에서는 끊임없이 변화하는 환경에서 API 게이트웨이 뒤에 있는 앱의 보안을 보장하는 강력한 보안 도구를 갖추고 있습니다.

API가 많을수록 공격 표면이 더 많아짐

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

API는 현대화를 가속화하는 데 중요한 역할을 하지만, 동시에 악용이 쉬워지고 있습니다. 마이크로서비스 아키텍처에서는 단일 API가 수백 개의 엔드포인트를 가질 수 있으며 단일 애플리케이션은 API를 사용하여 서로 연결하는 여러 마이크로서비스로 구성될 수 있습니다. 이는 과거의 단일형 앱과는 다릅니다. 과거의 앱은 보안을 위해 진입점이 하나뿐이었습니다. 각 마이크로서비스가 여러 개의 API 엔드포인트를 노출함에 따라 잠재적인 공격 표면이 10배로 늘어났습니다.

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

OWASP API 보안 상위 10개 취약점

API는 일반적으로 개방적이어서 민감한 데이터를 노출할 수 있습니다. OWASP(Open Web Application Security Project)는 OWASP API 보안 상위 10개 프로젝트 에서 가장 널리 퍼진 취약점을 강조했습니다.

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

F5 NGINX Plus로 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를 보호합니다.

• 인증 및 권한 부여 메커니즘 – 적절한 액세스 권한이 있는 클라이언트만 API를 사용할 수 있도록 보장합니다. 그러한 메커니즘 중 하나가 JSON 웹 토큰(JWT)의 클레임 입니다. 이는 OWASP API 보안 상위 10개 항목의 여러 취약점을 해결합니다. 손상된 개체 수준 인증 (API1), 손상된 사용자 인증 (API2), 손상된 기능 수준 인증 (API5), 불충분한 로깅 및 모니터링 (API10).
• 속도 제한 정책 – 정의된 기간 내에 각 API 클라이언트에서 API 게이트웨이가 허용하는 요청 수에 제한을 설정하여 API가 과부하되지 않도록 보호하고 DDoS 공격을 완화합니다. NGINX Plus를 사용하면 속도 제한을 소스에 따라 구체적으로 지정할 수 있습니다(예: JWT 클레임 값 기준). 따라서 유효한 사용자에게 영향을 미치지 않습니다. 이는 리소스 부족 및 속도 제한 (API4) 취약점을 해결하는 데 도움이 됩니다.

F5 NGINX App Protect WAF로 API 강화

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

NGINX Plus를 API 게이트웨이 및 로드 밸런서(인터넷에 노출되어야 하는 API 라우팅 및 외부 개발자와 파트너용)로 사용하는 경우 보호를 위해 NGINX App Protect WAF를 배포하기에 가장 적합한 곳입니다. API 트래픽의 홉이 하나 적기 때문에 최소한의 복잡성과 가장 낮은 지연 시간으로 보호 기능을 추가할 수 있습니다.

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

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

로드 밸런서가 있을 수 있으며 해당 로드 밸런서에 F5 Advanced WAF와 같은 WAF가 있을 수도 있습니다. 그 뒤에 API 게이트웨이를 배포했습니다. 그러면 로드 밸런서에 이미 WAF가 있다면, API 게이트웨이에 왜 WAF가 필요할까요?

에지의 로드 밸런서‑WAF 조합에서 환경 내부의 API 게이트웨이‑WAF 조합으로 이동하는 주요 이점 중 하나는 보안에 대한 보다 엄격하고 세부적인 제어가 가능하다는 것입니다. 보안에 대한 책임을 API 팀에 위임하여 정책을 API에 더욱 특화시킬 수 있습니다.

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

OpenAPI 스키마 검증을 통한 긍정적 보안 추가

보호가 API별로 이루어져야 하는 주요 영역은 Swagger의 OpenAPI 사양 에 대한 검증입니다. OpenAPI 스키마는 각 API마다 고유하며 API 버전마다 변경됩니다. API의 OpenAPI 스키마를 기반으로 하는 보호는 IT 팀이 유지 관리하는 중앙 집중형 WAF에 대한 보안 제어를 업데이트할 때까지 기다릴 수 없으며, 다른 API와 앱에 예상치 못한 영향을 미치지 않도록 승인과 신중한 테스트가 필요합니다.

NGINX App Protect WAF는 OpenAPI 스키마를 검증하여 요청이 API가 지원하는 것(메서드, 엔드포인트, 매개변수 등)을 준수하는지 확인합니다. 이것이 로드 밸런서의 중앙화된 WAF 뒤에 있는 API 게이트웨이에서 NGINX App Protect WAF가 긍정적인 보안을 제공하는 것이 이상적인 이유입니다.

API 배포에 발맞추기 위한 "코드로서의 보안"

CI/CD 파이프라인은 보안보다는 속도를 위해 만들어졌습니다. API는 과거 앱보다 더 자주 공개됩니다. 이것이 API 중심 환경에서 좌측으로 의 이동이 나타나는 이유입니다. DevOps는 앱 개발 수명 주기의 초기 단계에서 보안 제어를 적용하거나 좌측으로 이동함으로써 보안을 코드로 처리하는 DevSecOps 문화로 전환합니다.

API 게이트웨이, 로드 밸런서 또는 둘 다에 WAF를 배치하든, WAF 구성은 API 버전 변경에 맞춰 자동화된 방식으로 배포되어야 합니다. 조직이 Shift-Left 문화를 채택하고 CI/CD 파이프라인에 "코드로서의 보안"을 통합하면 보안을 사후에 추가하는 것이 아니라 애플리케이션 및 API 개발의 각 단계에 내장할 수 있습니다.

보안 정책과 구성을 코드로 사용하면 다음과 같은 많은 이점이 있습니다.

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

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

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는 NGINX API 게이트웨이에 WAF를 내장한 유일한 공급업체로, 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)의 일부로 자동화할 수 있습니다. 이는 릴리스 속도를 높이는 데 도움이 될 뿐만 아니라, 조직이 안정적이고 보호된 API를 구축하는 동시에 DevOps와 SecOps 팀 간의 격차를 메우고 DevSecOps로의 문화적 변화를 이루는 데에도 도움이 됩니다.

NGINX App Protect WAF를 직접 사용해 볼 준비가 되셨나요? 오늘 무료 30일 체험판을 시작하거나, 저희에게 연락해 사용 사례에 대해 논의해 보세요 .