F5 NGINX App Protect와 F5 NGINX Plus로 보안을 자동화하여 침해 비용 절감

자동화와 인공지능(AI)을 통해 보안 태세를 개선하는 데 지출한 비용이 결과적으로 훨씬 더 큰 비용 절감으로 이어진다는 사실이 놀라울 수도 있습니다. IBM Security 팀은 2021년 데이터 유출 비용 보고서에서 보안 자동화와 AI를 도입하지 않은 조직의 보안 침해 비용이 자동화와 AI를 전면 도입한 조직보다 평균적으로 무려 80% 더 높다고 밝혔습니다. 각각 671만 달러와 290만 달러로, 그 차이는 381만 달러에 달합니다. 보안 자동화와 AI를 우선시하면 조직은 침해 사고를 더 빠르게 식별하고 억제하여 비용과 시간을 모두 절약할 수 있습니다.

보안 자동화와 AI를 도입하지 않은 조직은 데이터 침해로 인해 수백만 달러의 추가 비용을 부담합니다
(출처: 2021년 데이터 침해 비용 보고서)

하지만 CI/CD 파이프라인에 보안을 통합할 때는 도구에 과도한 부하를 주지 않는 것이 중요합니다. 트래픽 검사 횟수가 적을수록 지연 시간도 줄어듭니다. 이를 비즈니스 관점에서 해석하면, 기술적 복잡성은 민첩성을 저해한다는 의미입니다.

F5 NGINX는 원활한 통합과 소프트웨어 개발 수명 주기에서 팀이 “보안을 왼쪽으로 이동”할 수 있도록 지원하는 역량을 갖춘 독보적인 보안 플랫폼을 제공합니다. 조직이 CI/CD 파이프라인에 ‘코드형 보안’을 통합하면 보안 자동화와 AI를 활용할 수 있어 IBM이 설명한 막대한 비용 절감 효과를 얻을 수 있습니다. 애플리케이션 및 API 개발의 각 단계에 보안을 내재화하면 구성 파일과 보안 정책 파일이 코드로 처리되며, SecOps 팀은 DevOps 팀이 앱을 구축할 때 사용할 선언적 보안 정책을 만들고 유지 관리할 수 있습니다. 이러한 정책은 새로운 앱에 반복적으로 적용할 수 있으므로 CI/CD 파이프라인에서 보안을 자동화할 수 있습니다.

한 단계씩 자세히 살펴보면서 F5 NGINX App Protect와 F5 NGINX Plus가 보안 보호 조치를 자동화하는 데 도움이 되는 트래픽 처리의 세 단계를 알아보겠습니다:

• 1단계 – F5 NGINX App Protect DoS는 서비스 거부(DoS) 공격을 탐지하고 방어합니다
• 2단계 – F5 NGINX App Protect WAF는 OWASP 10대 공격과 악성 봇으로부터 보호합니다
• 3단계 – F5 NGINX Plus는 앱 및 API 클라이언트를 인증하고, 기본 기능과 타사 SSO(Single Sign-On) 솔루션과의 통합을 사용하여 권한 부여 요구 사항을 적용합니다.

불법 트래픽을 차단하고 보안을 자동화하여 시간과 비용을 절감하는 효율적인 애플리케이션 트래픽 관리를 위한 3단계 보안 솔루션

이 3단계 보안 솔루션은 특히 퍼블릭 클라우드 환경에서 다음 두 가지 방식으로 비용을 절감해 줍니다:

1. NGINX App Protect DoS가 DoS 공격 트래픽을 필터링한 다음 NGINX App Protect WAF가 OWASP Top 10과 같은 다양한 공격 벡터를 차단하므로 정상적인 트래픽만 애플리케이션에 도달합니다.
2. NGINX Plus는 매우 효율적인 이벤트 기반 설계를 채택하여 CPU 사용량을 낮게 유지하면서도 초당 방대한 수의 요청을 처리할 수 있습니다. 고효율 플랫폼에서 정상적인 애플리케이션 트래픽만 처리하면 필요한 컴퓨팅 리소스가 크게 줄어 시간과 비용을 절약할 수 있으며, 도구에 과부하를 주지 않고도 다양한 공격 벡터로부터 보호할 수 있습니다.

현재 데이터 센터에서 실행되는 애플리케이션을 보호하기 위해 F5 BIG-IP Advanced WAF를 사용하고 있다면, Kubernetes용 Ingress 컨트롤러로 NGINX Plus를 추가하고 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를 사용하면 이미 배포된 앱을 세부적으로 조정하는 동시에 최신 앱 보안 자동화를 도입하여 향후 보안 침해와 잠재적 공격에 따른 비용을 줄일 수 있습니다.

1단계: NGINX App Protect DoS로 DoS 공격 방어

안전한 트래픽 관리 여정의 첫 단계는 서비스 거부(DoS) 공격을 걸러내는 것입니다. 이러한 악용을 초기에 차단하는 것은 반드시 필요한 1차 방어선입니다.

앞서 언급했듯이, 공격자들은 기존의 대규모 트래픽 공격에서 점차 전환하여 HTTP 및 HTTPS 요청이나 API 호출을 이용해 레이어 7을 공격하고 있습니다. 그 이유는 무엇일까요? 가장 저항이 적은 경로를 택하기 때문입니다. 인프라 엔지니어들은 수년간 레이어 3 및 레이어 4 공격에 대한 효과적인 방어 체계를 구축해 왔으며, 그 결과 이러한 공격은 차단하기가 더 쉬워지고 성공 가능성도 낮아졌습니다. 레이어 7 공격은 이러한 기존 방어 체계를 우회할 수 있습니다.

모든 DoS 공격이 대용량 트래픽을 유발하는 것은 아닙니다. Slow POST 또는 Slowloris와 같은 ‘로우 앤드 슬로우’ 방식으로 서버 리소스를 소모하도록 설계된 공격은 정상 트래픽에 쉽게 숨을 수 있습니다. 또한 gRPC와 같은 오픈 소스 HTTP/2 원격 프로시저 호출 프레임워크는 최신 앱에 필요한 속도와 유연성을 제공하지만, 특유의 개방성으로 인해 독점 프로토콜보다 DoS 공격에 더 취약할 수 있습니다.

기존의 DoS 방어 솔루션과 달리 NGINX App Protect DoS는 자동화된 사용자 및 사이트 행동 분석, 선제적 상태 점검, 별도의 조작이 필요 없는 구성을 활용하여 오늘날의 공격을 탐지합니다. 또한 일반적인 공격을 차단하는 저지연 솔루션으로, HTTP GET 플러드, HTTP POST 플러드, Slowloris, Slow read, Slow POST 등의 공격을 차단합니다.

이러한 공격에 대응하려면 SecOps 및 DevOps 팀은 시프트 레프트 사고방식의 일환으로 CI/CD 워크플로에 ‘코드형 보안’ 자동화를 통합해야 합니다. NGINX App Protect DoS는 이를 가능하게 합니다. 최신 분산형 앱과 API를 DoS 위협으로부터 고급 보호 기능을 통해 안전하게 보호하며, 경량 소프트웨어 패키지, 지속적인 위협 완화 피드백 루프, RESTful API를 통한 익숙한 DevOps 도구와의 통합으로 이 모델을 지원하여 때로는 상충하는 SecOps와 DevOps의 우선순위를 조율하는 데 도움을 줍니다.

NGINX App Protect DoS는 IBM Security 보고서에서 상당한 비용 절감의 핵심으로 강조한 머신 러닝(ML) 기술을 통합합니다. 클라이언트 동작과 애플리케이션 상태를 분석하여 정상적인 트래픽 패턴을 모델링하고, 고유한 알고리즘을 사용해 가장 정확한 보호 기능을 제공하는 동적 통계 모델을 생성하며, 동적 시그니처를 배포해 공격을 자동으로 완화합니다. 또한 완화 효과를 지속적으로 측정하고 변화하는 동작이나 상태 조건에 맞게 조정합니다. 이러한 기능을 통해 NGINX App Protect DoS는 각각의 공격 요청이 완전히 정상적인 것처럼 보이고 단일 공격자가 생성하는 트래픽이 일반적인 정상 사용자의 평균 트래픽보다 적을 수도 있는 DoS 공격까지 차단할 수 있습니다.

보안 솔루션 1단계 및 2단계: NGINX App Protect DoS 및 WAF를 활용한 효율적인 트래픽 처리와 애플리케이션 보안

2단계: NGINX App Protect WAF로 OWASP 10대 보안 위험 방어

DoS 방어는 악성 트래픽이 인프라에 유입되는 것을 확실히 차단하지만, 공격이 여전히 방어망을 뚫고 들어올 수 있습니다. 따라서 성공적인 방어의 다음 단계에서는 정상 트래픽으로 위장한 악의적 행위자의 트래픽을 집중적으로 차단하는 웹 애플리케이션 방화벽(WAF)이 필요합니다.

가볍고 뛰어난 성능을 갖춘 NGINX App Protect WAF는 응답 검사, HTTP 프로토콜 준수 적용, 우회 기법 탐지, Data Guard를 통한 신용카드 번호 및 기타 민감한 개인정보 마스킹, 허용되지 않는 메타문자와 파일 형식, 잘못된 형식의 JSON 및 XML, 민감한 매개변수 확인 등 포괄적인 보안 기능을 제공합니다. 또한 최신 OWASP Top 10 위협으로부터 보호합니다:

취약한 접근 통제
암호화 실패
인젝션
안전하지 않은 설계
보안 설정 오류
취약하거나 오래된 구성 요소
식별 및 인증 실패
소프트웨어 및 데이터 무결성 실패
보안 로깅 및 모니터링 실패
서버 측 요청 위조

OWASP Top 10 취약점 중 A03:2021 인젝션과 같은 취약점을 노린 사이버 공격이 여전히 빈번한 것은 놀라운 일이 아닙니다. 2021년 7월, 오픈 소스 전자상거래 사이트인 WooCommerce는 자사의 여러 플러그인에 취약점이 있다고 발표했습니다 그 취약점은 SQL 인젝션이었으며, 당시 이를 악용한 공격이 여러 건 발생하고 있었습니다. 기업과 고객의 활동이 주로 온라인에서 이루어지는 상황에서 공격자가 웹 기반 앱을 집중적으로 노리는 것은 당연합니다. 이러한 앱은 대개 구조가 복잡하고 마이크로서비스로 구성되며, 수많은 API가 서로 통신하는 분산 환경 전반에 걸쳐 있어 악용될 수 있는 엔드포인트가 늘어나기 때문입니다.

최신 공격 역시 빠르게 변화하고 적응합니다. 바로 이 지점에서 AI가 활용되며, IBM이 AI의 중요성을 강조한 이유도 여기에 있습니다. NGINX App Protect DoS와 마찬가지로 NGINX App Protect WAF의 강력한 ML 시스템을 통해 플랫폼 운영, 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 보호는 여러 검사 지점을 마련하여 보안 팀에는 앱 사용 현황에 대한 가시성을 제공하고, 앱 팀에는 앱이 어떻게 유지 관리되고 있는지 파악할 수 있게 해 줍니다.

3단계: NGINX Plus에서 앱 및 API 클라이언트 인증 및 권한 부여

NGINX App Protect Dos와 NGINX App Protect WAF가 악성 트래픽을 걸러낸 후에도 클라이언트가 적법한지, 그리고 요청한 리소스에 액세스할 권한이 있는지 확인해야 합니다. 바로 이 지점에서 NGINX Plus가 인증 및 권한 부여를 처리한 다음 요청을 적절한 서버로 라우팅하는 역할을 합니다. NGINX Plus를 API 게이트웨이로 배포하면 여러 API에 일관된 단일 진입점을 제공하고 기술 스택을 더욱 간소화할 수 있습니다.

인증 및 권한 부여 역시 SSO(Single Sign-On)를 통해 자동화할 수 있으므로 DevOps 팀이 원하는 민첩성을 유지할 수 있습니다. NGINX Plus는 OpenID Connect(OIDC)를 지원합니다. 이는 OAuth 2.0 프로토콜을 기반으로 하는 ID 계층입니다. NGINX 문서에서는 OIDC를 사용하여 NGINX Plus가 프록시하는 애플리케이션에 SSO를 적용하는 방법을 설명합니다.

보안 솔루션 3단계: NGINX Plus 및 OAuth 2.0/OIDC IdP 호환 예제를 사용한 SSO 인증 및 권한 부여

API는 특유의 개방성으로 인해 공격에 취약합니다. 연례 보고서에서 Gartner Research는 2022년에 API가 가장 흔한 공격 경로가 되어 기업용 웹 앱에서 수많은 데이터 침해를 일으킬 것이라고 예측했습니다. 2022년을 지나며 여러 조직에서 API 공격 표면이 계속 확대되는 것을 목격한 결과, 이 예측은 현실이 되었습니다.

The API 인증 사고: 2020 애플리케이션 보호 보고서F5 Labs에서는 API 사고가 발생하는 일반적인 원인 세 가지를 다음과 같이 강조합니다:

1. API 엔드포인트에 인증 없음
2. 취약한 API 인증
3. 취약한 API 권한 부여

API 엔드포인트에 인증 없음

API 트래픽 인증을 구현하면 자신의 신원을 성공적으로 증명한 클라이언트는 신뢰할 수 있는 ID 공급자로부터 토큰을 받습니다. 그런 다음 클라이언트는 각 HTTP 요청과 함께 액세스 토큰을 제시합니다. 요청이 애플리케이션에 전달되기 전에 NGINX Plus는 토큰을 검증하고 토큰에 인코딩된 신원 및 기타 데이터(예: 그룹 멤버십)를 추출하여 클라이언트의 인증과 권한 부여를 확인합니다. 토큰이 검증되고 클라이언트가 리소스에 액세스할 권한이 있다고 판단되면 요청이 애플리케이션 서버로 전달됩니다. 이러한 검증을 수행하는 방법은 여러 가지가 있지만, OAuth 2.0 프로토콜을 기반으로 하는 OpenID Connect는 API 요청에 대한 타사 인증을 지원하는 데 널리 사용되는 방식입니다.

하지만 시중의 많은 API는 인증 계층에서 보호되지 않고 있습니다. 2021년에는 인터랙티브 피트니스 플랫폼인 Peloton의 API에서 정보가 유출될 수 있다는 사실이 밝혀졌습니다. 한 보안 연구원은 Peloton의 API에 인증 없이 요청을 보내 사용자 데이터를 손쉽게 가져올 수 있다는 사실을 발견했습니다. Peloton은 대규모 침해 사고가 발생하기 전에 코드를 수정했지만, 이 사건은 획일적인 보안 접근 방식으로는 API 구조가 본질적으로 다양하다는 점과 그에 따라 API를 민첩하게 방어해야 할 필요성을 고려할 수 없음을 보여줍니다.

취약한 API 인증

API는 컴퓨터 간 연결을 위해 설계되므로 많은 DevOps 팀은 사람이 API 엔드포인트와 통신하지 않는다고 가정합니다. F5 Labs 보고서에 소개된 한 사례에서는 한 연구원이 여러 API 요청을 연계하여 모바일 앱에서 수십만 달러 상당의 크레딧을 ‘획득’했습니다. 이 앱은 악용을 방지하기 위한 토큰을 지속적으로 생성했지만 만료일을 설정하지 않아 토큰을 반복해서 사용할 수 있었습니다.

API 인증 토큰을 제대로 검증하지 않으면 공격자가 API 취약점을 악용할 수 있습니다. 이러한 유형의 취약점을 연구자가 아닌 악의적인 공격자가 발견할 경우 기업 전체가 위험에 처할 수 있습니다.

취약한 API 권한 부여

API 인증 실패는 자연스럽게 API 권한 부여 취약점으로 이어집니다. F5 Labs 보고서에서는 운영 체제의 버그로 인해 악성 HTTP 요청이 API에 전달되어 공격자가 권한 부여 토큰에 쉽게 접근할 수 있었던 사고도 설명합니다. 공격자는 이 권한 부여 토큰을 획득한 후 관리자 권한을 갖게 되었습니다.

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를 직접 사용해 볼 준비가 되셨나요? 지금 30일 무료 평가판을 시작하거나 문의하여 사용 사례를 상담해 보세요.

---