NGINX App Protect WAF로 API 게이트웨이 보호

NGINX | 2022년 5월 26일

Thelen BlumNGINX App Protect 수석 제품 마케팅 매니저 | F5

모놀리식 아키텍처가 마이크로서비스로 전환되면서 애플리케이션 개발 속도는 그 어느 때보다 빨라지고 있습니다. 경쟁력을 유지하려면 속도가 필수적이며, 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배로 확대되었습니다.

2017년부터 2022년까지 조직의 평균 애플리케이션 포트폴리오 규모를 비교한 막대그래프. 평균 규모는 200~1,000개이며, 범위는 1개에서 3,000개 이상입니다.

F5의 2022년 보고서에 따르면, 대부분의 조직은 200~1,000개의 앱을 보유하고 있으며 77%는 여러 클라우드에서 애플리케이션을 실행하고 있습니다. 분산 환경 전반의 포트폴리오에 앱과 API가 더 많이 추가될수록 잠재적인 공격 표면도 더 넓어집니다.

OWASP API 보안 10대 취약점

일반적으로 API는 개방되어 있어 민감한 데이터가 노출될 수 있습니다. OWASP(Open Web Application Security Project)는 OWASP API 보안 10대 위험 프로젝트에서 가장 널리 퍼진 취약점을 다음과 같이 소개합니다:

API1. 객체 수준 권한 부여 취약점
API2. 사용자 인증 취약점
API3. 과도한 데이터 노출
API4. 리소스 및 요청 속도 제한 미흡
API5. 기능 수준 권한 부여 취약점
API6. 대량 할당
API7. 보안 구성 오류
API8. 인젝션
API9. 부적절한 자산 관리
API10. 불충분한 로깅 및 모니터링

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

F5 NGINX Plus로 API 보안을 시작하세요

대규모 API 공격은 정기적으로 언론의 헤드라인을 장식합니다. 2019년에는 차량 공유 회사인 Uber의 API에서 심각한 버그가 발견되었습니다 – 취약한 API 엔드포인트로 인해 악의적인 공격자가 이용자의 인증 토큰을 비롯한 중요한 데이터를 탈취할 수 있었습니다. 다행히 이 버그는 피해가 발생하기 전에 발견되었습니다. 2021년 LinkedIn은 그만큼 운이 좋지 않았습니다. API 취약점으로 인해 해커들이 7억 명이 넘는 LinkedIn 사용자의 데이터를 유출했으며, 해당 데이터는 이후 다크 웹에서 판매되었습니다.

By F5 NGINX Plus를 API 게이트웨이로 배포하면, 빠르게 변화하는 API 환경에서 API 라우팅 및 전송을 고성능으로 처리할 수 있습니다. 독립 기술 연구 및 분석 기관인 GigaOm은 NGINX와 다른 API 게이트웨이 솔루션의 성능을 비교했습니다. 벤치마크 결과, NGINX는 30ms 미만의 지연 시간으로 초당 30,000건의 요청을 처리할 수 있었으며, 이는 하이퍼스케일러의 API 게이트웨이보다 지연 시간이 1,000배 더 짧은 수준입니다.

NGINX Plus는 OWASP API 취약점에 대한 보호 기능을 기본으로 제공할 뿐만 아니라, 잘못된 형식의 쿠키, JSON 및 XML을 검사하고 허용된 파일 형식과 응답 상태 코드를 검증하는 추가 보안 기능도 제공합니다. 또한 HTTP RFC 준수를 보장하고 공격을 은폐하는 데 사용되는 우회 기법을 탐지합니다.

NGINX Plus는 API 요청을 신속하게 라우팅하는 동시에 API 클라이언트를 인증하고 권한을 부여하여 API를 보호하며, 트래픽 속도를 제한해 API 기반 서비스가 과부하되지 않도록 보호합니다. 또한 이러한 도구는 OWASP API Security Top Ten 취약점으로부터 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 보안 강화

API 게이트웨이에 F5 NGINX App Protect WAF를 적용하여 보안을 강화하면 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 규정 준수 요건에 따라 페이로드는 개방형 공용 네트워크 전 구간에서 종단 간 암호화되어야 합니다. 로드 밸런서 또는 CDN 뒤의 API 게이트웨이에 NGINX App Protect WAF를 배치하면 페이로드는 API 게이트웨이에서 복호화될 때까지 완전히 암호화된 상태로 유지됩니다. 따라서 민감한 데이터 처리 요건을 충족하면서 API를 안전하게 보호할 수 있습니다.

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

API 게이트웨이와 함께 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 문화로 나아갑니다.

WAF를 API 게이트웨이, 로드 밸런서 또는 두 곳 모두에 배치하는 경우, API 버전 변경에 발맞추려면 WAF 구성을 자동화된 방식으로 배포해야 합니다. 조직이 시프트 레프트 문화를 도입하고 ‘코드형 보안’을 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일 무료 체험을 시작하거나, 사용 사례에 대해 논의하려면 문의해 주세요.