우리의 결정은 ModSecurity를 유지 관리해 온 조직인 Trustwave의 최근 발표에 따른 것입니다 . Trustwave는 2024년 7월 1일 부터 다음 과 같이 할 예정입니다.
또한 OWASP ModSecurity Core Rule Set(CRS) 프로젝트는 ModSecurity에 대한 지원을 계속할 계획이지만 Trustwave의 지원 변경에 대한 조치 및 발표를 감안할 때 ModSecurity 프로젝트의 실행 가능성에 대한 우려를 품고 Coraza라는 새로운 WAF 에 초점을 전환하고 있습니다.
NGINX ModSecurity WAF는 오픈 소스 ModSecurity v3를 기반으로 하며 NGINX ModSecurity WAF 모듈이 NGINX Plus에서 올바르게 작동하도록 보장하는 지원 및 테스트에 의해 뒷받침됩니다. 그러나 ModSecurity 코드 자체는 유지 관리하지 않으며 Trustwave의 지원 부족과 오픈 소스 ModSecurity 프로젝트에 대한 기여 감소로 인해 NGINX Plus 고객은 보안 및 안정성에 대한 요구 사항을 충족하지 못할 수 있는 제품을 제공받게 됩니다.
NGINX는 판매 종료 (EoS) 로 전환되었으며 2022년 4월 1일 에 NGINX ModSecurity WAF 판매를 중단했습니다 . 활성 라이선스가 있는 고객인 경우 구독을 갱신하고 EoL 날짜 (2024년 3월 31일) 까지 NGINX ModSecurity WAF 패키지 업데이트를 포함한 전체 지원을 받을 수 있습니다. NGINX는 고객이 새 솔루션으로 마이그레이션할 수 있는 충분한 시간을 제공하는 목표로 2024년 3월 31일 까지 NGINX ModSecurity 패키지를 업데이트할 계획입니다. 귀사의 계정 관리자가 귀사의 향후 애플리케이션 보안 솔루션 요구 사항을 논의하기 위해 직접 연락할 것입니다. 언제든지 계정 관리자에게 문의하려면 당사에 문의하세요 . 2023년 4월 1일 부터는 더 이상 갱신이 허용되지 않습니다.
NGINX ModSecurity WAF 제품이 EoL로 이동하고 있지만, 우리는 오픈 소스 커뮤니티에 대한 참여와 지원에 전념하고 있습니다. NGINX는 기술을 발전시키고 더 나은 것으로 만들기 위해 헌신하는 오픈 소스 커뮤니티 구성원의 협업과 혁신을 소중히 여깁니다. 우리는 오픈 소스가 핵심 기반 보안의 더 광범위한 사용을 장려하고 글로벌 애플리케이션 인프라의 공격 표면을 줄임으로써 우리 모두에게 이롭다고 믿습니다.
이러한 가치에 따라 NGINX는 NGINX 오픈 소스 및 NGINX Unit 프로젝트를 계속 주도하고 있습니다. 우리는 보안 노력에 큰 자부심을 가지고 있으며, 우리 모두가 일상 생활에서 점점 더 의존하는 기술 구조를 보호하기 위해서는 더 광범위한 팀이 필요하다는 것을 인식하고 있습니다. 따라서 OWASP Core Rule Set (CRS), Let's Encrypt, Open SSL 프로젝트의 후원을 포함하여 인터넷 보안을 직접 강화하는 OSS 프로젝트를 지원하게 되어 기쁩니다.
원래는 OWASP CRS를 사용하여 일반적인 취약성 클래스로부터 앱을 보호하거나 표준 WAF 구현에서 PCI DSS 규정 준수 요구 사항을 준수하기 위해 오픈 소스 ModSecurity WAF의 지원되는 버전으로 NGINX ModSecurity WAF를 선택했을 수 있습니다. 그러나 지난 2년 동안 COVID‑19 팬데믹으로 인해 기업과 소비자 모두가 상품과 서비스의 온라인 구매 및 소비로 전환함에 따라 조직은 수요에 발맞추기 위해 디지털 전환을 가속화해야 했습니다.
웹 애플리케이션과 API에 대한 사이버 공격이 증가함에 따라 WAF에서 필요한 것을 재평가하고 비즈니스 성장을 촉진하는 데 필요한 보다 포괄적인 수준의 보호, 안정성 및 성능을 구현할 적절한 시기일 수 있습니다. F5 NGINX App Protect WAF를 비즈니스와 함께 확장할 수 있는 대체 보안 솔루션으로 제공합니다.
NGINX App Protect WAF는 여러 가지 장점을 제공합니다.
자동차 타이어 공급업체 Reifen.com 이 온라인 성능을 개선하고 내부 및 외부 보안 및 규정 준수 표준을 충족해야 할 때 NGINX ModSecurity WAF 대신 NGINX App Protect WAF를 선택한 이유를 알아보세요. Reifen.com의 전자상거래 컨설턴트인 Sascha Petranka는 "NGINX App Protect WAF를 선택하기로 한 이유는 최고의 성능, 최고의 장기적 솔루션, NGINX와 F5의 결합된 전문성을 제공하기 때문입니다."라고 설명합니다.
NGINX App Protect WAF는 조직이 애플리케이션과 API의 보안과 성능을 개선하는 동시에 DevOps와 SecOps 팀을 더욱 긴밀하게 연결하는 데 도움이 될 수 있습니다. 이는 기업이 수익에 영향을 미치는 공격, 데이터 도난, 평판 손상 및 규정 위반으로부터 보호할 수 있도록 하는 가벼운 보안 솔루션입니다.
위 내용과 같이 NGINX Plus / NGINX App Protect 를 활용하여 보안취약점 완화가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
일상 생활의 점점 더 많은 부분이 온라인으로 옮겨가면서
사이버 공격자들은 우리가 의존하는 앱의 제공 서비스 수준을 떨어뜨리려고 합니다.
사이버 공격자들의 동기는 복수부터 피해 기업의 주가에 영향을 미치는 것,
보안팀의 주의를 데이터 유출로부터 분산시키는 연막작전까지 다양합니다.
이전 블로그에서는 과거에 보안팀이 어떻게 볼륨 서비스 거부(DoS) 및 분산 DoS에 대한
새로운 방어책을 지속적으로 개발해야 했는지 설명합니다;(DDoS)
공격에 대한 네트워크 및 전송 수준 (계층 3 및 4)에서의 방어 기능이 추가되어
서버에 TCP/UDP 연결 요청을 폭주시켜 서버의 가용 대역폭을 고갈시킵니다.
이제 공격자들은 애플리케이션 수준에서 리소스를 고갈시키기 위해 HTTP 요청 또는
API 호출을 사용하는 DoS 및 DDoS 공격이라는 새로운 도구를 무기고에 추가했습니다(Layer 7).
애플리케이션 수준에서는 악성 요청이 정상 요청과 동일하게 보이는 경우가 많기 때문에
네트워크 및 볼륨 공격에 대한 기존의 DoS 방어는 레이어 7 공격에 효과적이지 않습니다.
또한, 레이어 7에서의 HTTP 공격은 네트워크 수준 공격보다 훨씬 낮은 요청 속도와 양으로 피해를 입힐 수 있습니다.
레이어 7 DoS 방어는 완전히 새로운 요구 사항에 직면하여 더욱 민감해야 합니다:
NGINX App Protect 서비스 거부(DoS)>는 이러한 모든 문제를 해결하여 간소화되고
구현하기 쉬우며 적응형 제로 터치 정책 구성을 제공하는 제로 데이 보호를 보장합니다.
공격을 자동으로 차단하기 위해 적응하는 NGINX App Protect DoS의 방법
NGINX App Protect DoS는 다단계 프로세스를 사용하여 레이어 7 DoS 공격을 탐지하고 완화합니다:
통계적 사이트 모델에서 일반적인 행동 포착하기
프로세스의 첫 번째 단계는 사이트가 공격을 받지 않는 시간 동안
사용자 및 애플리케이션 동작을 캡처하여 일반적인 동작의 기준선을 캡처하는 통계 사이트 모델을 생성하는 것입니다.
NGINX 앱 프로텍트는 320개의 사용자 및 앱 지표를 추적하여 앱 배포를 종합적으로 파악합니다.
또한 트래픽을 관찰하면서 통계 사이트 모델을 동적으로 업데이트합니다.
따라서 시스템 임계값을 수동으로 조정할 필요가 없으며,
시간이 지남에 따라 필연적으로 발생하는 트래픽 패턴의 변화를 NGINX App Protect DoS가 고려하도록 보장합니다.
추적되는 지표의 한 종류는 HTTP 요청 특성과 관련된 것으로,
HTTP 메서드, User-Agent 헤더의 값, 그리고 그래픽에 표시된 것과 같은 기타 지표가 있습니다.
서비스 상태 확인
많은 레이어 7 DoS 방어 툴은 클라이언트 트래픽 패턴에만 주의를 기울입니다.
우수한 공격 탐지를 위해 서비스 상태를 능동적으로 확인하도록
NGINX App Protect DoS를 추가로 구성할 수 있습니다.
응답 시간 및 중단된 요청 비율과 같은 여러 서버 성능 지표를 추적합니다.
이러한 지표의 값이 악화되면 애플리케이션이 공격으로 인해 "스트레스"를 받고 있음을 나타냅니다.
서버 메트릭을 추적하면 또 다른 이점이 있습니다.
NGINX App Protect DoS가 공격이 진행 중이라고 판단하면
상태 검사에 대한 응답 패턴을 통해 공격이 시작된 시점을 파악하는 데 도움이 됩니다.
이상 징후 탐지
사이트 통계 모델과의 편차 및 서버 응답 변경(구성된 경우)을 기반으로 공격이 진행 중이라고 판단되면
NGINX App Protect DoS는 사이트 통계 모델 업데이트를 중단하고
대신 현재 지표 값이 설정된 기준선과 어떻게 다른지 분석합니다.
차이가 있다면 글로벌 이상 징후일 가능성이 높습니다.
악성 행위자 및 요청 패턴 식별
그런 다음 NGINX 앱 프로텍트 DoS는 동시에 실행되는 두 가지 절차를 시작합니다:
개별 사용자의 행동을 분석하여 이상 행위를 생성하거나 기여한 사용자를 탐지합니다.
NGINX 앱 프로텍트는 처음에 모든 사용자를 의심스러운 사용자로 간주하고 행동을 분석합니다.
모든 사용자가 공격자일 가능성은 낮지만, 모든 사용자의 행동을 측정하면
NGINX App Protect는 누가 공격에 기여했는지,
기여하지 않았는지 알 수 있는 통계적 그림을 생성할 수 있습니다.
탐지된 악의적인 공격자는 요청에 포함된 IP 주소 또는 X-Forwarded-For 헤더를 사용하여 식별할 수 있습니다.
합법적인 사용자를 차단하지 않고 공격 트래픽을 설명하는
규칙 목록 생성 - 제로데이 공격 방어를 위한 실시간 시그니처. 이전 공격 중에 생성된 시그니처를 재사용할 수 있습니다.
생성된 시그니처는 이 예시에서와 같이 공격과 관련된 HTTP 속성을 식별합니다:
http.request.method eq GET 및 http.user_agent contains Chrome 및 http.uri_parameters eq 6 및 http.accept_header_exists eq false and http.headers_count eq 7
다계층 방어로 공격 완화하기
레이어 7 공격에 대한 방어의 주요 목표는 공격으로 인한 피해를 입기 전에 이를 차단하는 것입니다.
다음 다이어그램에서 볼 수 있듯이 보수적 방어 전략 또는 표준 방어 전략을 구성할 수 있습니다.
두 전략 모두 첫 번째 방어 계층은 이전 단계에서 IP 주소와
X-Forwarded-For 헤더로 식별된 악성 행위자의 요청을 차단하는 것입니다.
다음 방어 계층은 이전 단계에서 생성된 서명과 일치하는 요청을 차단합니다.
마지막으로, 표준 완화를 구성했는데 NGINX App Protect DoS가 처음 두 방어 계층이 충분하지 않다고 판단하면
짧은 기간 동안 글로벌 속도 제한을 적용합니다.
공격 완화 중 오탐 최소화하기
NGINX App Protect DoS가 글로벌 전송률 제한을 적용하면 합법적인 사용자의 요청이 차단될 가능성이 있습니다(오탐).
NGINX App Protect DoS는 일반적인 DoS 공격이 사람이 직접 실행하는 것이 아니라
봇넷 컨트롤러(감염된 컴퓨터의 멀웨어)가 실행하는 스크립트를 사용하여 생성된다는 사실에 기반하여 오탐지를 줄일 수 있습니다.
웹 브라우저와 달리 이러한 단순 스크립트 중 상당수는 HTTP 리디렉션을 제대로 처리할 수 없으며
JavaScript를 처리할 수 있는 스크립트는 더 적습니다.
이러한 스크립트와 브라우저 간의 기능 차이로 인해
NGINX App Protect DoS는 어떤 스크립트가 의심스러운 트래픽을 생성하는지 파악할 수 있습니다.
따라서 모든 클라이언트의 요청을 속도 제한하는 대신 NGINX App Protect DoS는 먼저 HTTP 리디렉션을 전송한 다음
처리할 자바스크립트 스니펫을 전송합니다.
스크립트 봇은 성공적으로 응답할 수 없지만 브라우저는 응답할 수 있으므로
NGINX App Protect DoS는 브라우저 트래픽은 허용하면서 스크립트의 트래픽을 차단할 수 있습니다.
일부 사용자는 오탐이 많이 발생할 가능성이 있기 때문에 적응형 학습에 의존하는 것을 불편해할 수 있지만,
저희는 이것이 레이어 7 DoS 공격을 완화하는 가장 효과적인 방법이라는 것을 알고 있습니다.
NGINX 앱 프로텍트는 사용자 행동 분석, 서비스 상태 확인, 방어 전술의 효과 측정 등
여러 접근 방식을 결합하여 오탐을 줄입니다.
이 세 가지 접근 방식을 함께 사용하면 공격에 대응하여 수동으로 구성을 변경할 필요 없이
포괄적인 가시성과 보호 기능을 제공합니다.
이미 WAF가 있는데 왜 레이어 7 DoS 방어가 필요한가요?
WAF가 이미 봇으로부터 보호하고 있는데 왜 레이어 7 DoS 보호가 필요한지 궁금할 수 있습니다.
레이어 7 디도스 공격이 보통 봇에 의해 시작되는 것은 사실이지만, 그 목적은 다른 봇 활동과 동일하지 않습니다.
봇은 일반적으로 서비스를 방해하지 않고 정보를 수집하려고 하지만, 레이어 7 디도스 공격은 서비스 중단을 목표로 합니다.
또 다른 차이점은 표준 봇 방지 툴은 "좋은 봇"과 "나쁜 봇"을 구분하려고 하는데,
이는 일반적으로 오탐을 방지하기 위해 사람의 감독이 필요한 까다로운 작업이라는 점입니다.
반면, NGINX App Protect DoS는 트래픽이 봇에 의해 생성되었는지
또는 다른 메커니즘에 의해 생성되었는지는 신경 쓰지 않고, 행동에 따라 공격자와 합법적인 사용자를 구분하는 데 집중합니다.
봇이 레이어 7 DoS 공격에 참여하고 있다고 판단되는 경우에만 안티봇 기술을 사용하기 때문에
표준 안티봇 소프트웨어보다 훨씬 적은 수의 오탐을 생성합니다.
또한 NGINX 앱 프로텍트 DoS 완화 방법은 CPU 효율적이기 때문에
레이어 DoS 공격이 진행되는 동안에도 앱을 계속 보호할 수 있습니다.
결론
NGINX 앱 프로텍트는 사용자 및 앱 행동과 관련된 320개 이상의 메트릭을 추적하여
가장 정확한 보호 기능을 제공하는 다요인 통계 모델을 생성합니다.
고유한 알고리즘으로 오탐을 크게 줄입니다.
이러한 기능을 통해 NGINX App Protect DoS는 각 공격 요청이 완전히 합법적으로 보이고
단일 공격자가 일반 정상 사용자보다 적은 트래픽을 생성할 수도 있는
고도로 분산된 DoS 공격을 완화할 수 있습니다.
적응형 기술을 통해 NGINX App Protect DoS는 오늘날의 공격뿐만 아니라
앞으로 진화할 공격으로부터 최신 인프라를 보호합니다.
NGINX 앱 프로텍트는 사용자 및 앱 행동과 관련된 320개 이상의 메트릭을 추적하여
가장 정확한 보호 기능을 제공하는 다요인 통계 모델을 생성합니다.
고유한 알고리즘으로 오탐을 크게 줄입니다.
위 내용과 같이 NGINX App Protect 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
디지털 혁신이 비즈니스 잠재력을 가속화하는 반면, 안타깝게도 위협이 되는 환경도 확장되고 있습니다.
보안 팀이 증가하는 범위와 책임에 대해 적응하고 몰두하는 동안,
공격자는 이를 악용하여 재정적 이익을 위해 애플리케이션을 남용하는 방식이 그 어느 때보다 정교해지고 있습니다.
네트워크 수준에서의 기존 서비스 거부(DoS) 공격과 비교했을 때, 애플리케이션 수준( 7계층 ) DoS 공격은 크게 증가하고 있는데,
그 이유는 최신 애플리케이션 아키텍처에 맞게 설계되지 않은 기존 방어를 우회 할 수 있기 때문입니다.
공격자의 관점에서 볼 때, 레이어 7 DoS 공격에는 두 가지 주요 특징이 있습니다.
첫째, 매우 적은 자원으로도 상당한 혼란을 일으킬 수 있다는 점이고,
둘째, 탐지하기 어렵다는 점입니다.
정교한 도구를 사용하여 생성되고 정밀하게 타겟팅 된 요청으로 인해 이러한 공격은
애플리케이션 서버와 API를 방해하여 정당한 요청을 처리할 수 없게 만듭니다.
서버가 처리할 수 있는 것보다 더 많은 요청이 폭주할 경우,
서버는 정당한 요청을 드롭하거나, 응답하지 않거나,
심지어 충돌할 수도 있습니다.
기존 DoS 완화 솔루션은 최신 앱에 효과적이지 않습니다.
전통적인 DoS 완화 솔루션은 현대 애플리케이션에는 효과적이지 않습니다.
이들은 정적인 규칙 기반 보안을 제공하며,
현대 애플리케이션 환경에서의 변화와 업데이트 속도를 따라잡기 위해
지속적인 유지 관리가 필요합니다.
NGINX App Protect Denial of Service (DoS)는 NGINX Plus를 위한 새로운 경량 동적 모듈로,
최신 애플리케이션을 가장 정교한 애플리케이션 DoS 공격으로부터 보호하도록 설계되었습니다.
NGINX App Protect DoS는 애플리케이션을 중단하고 해치려는 공격을 완화하여 지속적인 성능과 수익 확보를 보장하고
경쟁이 치열한 디지털 세계에서 고객 충성도와 브랜드를 보존합니다.
NGINX App Protect DoS는 Kubernetes 클러스터를 포함한 모든 플랫폼, 아키텍처 또는 환경에서
애플리케이션 및 마이크로서비스에 가깝게 배포할 수 있습니다.
애플리케이션과 함께 확장되며 항상 높은 보안 효과를 유지합니다.
NGINX App Protect DoS는 실행 중입니다.NGINX App Protect DoS는 다양한 위치에 배포하여 애플리케이션 서비스를 보호할 수 있습니다.
NGINX App Protect DoS는 여러 정교한 공격 유형에 대한 보호 기능을 제공합니다.
1. GET플러딩 POST공격 – (HTTP와 HTTPS 모두) 공격자는 대량의 요청으로 서버나 API를 과부하시켜 실제 사용자에게 응답하지 못하게 만들려고 합니다.
2. "느린" 공격 - (HTTP와 HTTPS 모두) "느리고 낮은" 공격은 서버 리소스를 묶어서 실제 사용자의 요청을 처리하는 데 사용할 수 있는 리소스가 없습니다.두 가지 요인으로 인해 방어하기 어렵습니다.
느린 공격에는 세 가지 주요 유형이 있습니다.
3. 이전 공격의 분산된 변형 – 분명히 여러 컴퓨터를 등록하면 더 많은 수의 동시 공격을 쉽게 보낼 수 있습니다.
또한 각 컴퓨터의 트래픽 볼륨이 비교적 낮아 일반 사용자와 유사할 수 있습니다. 컴퓨터는 공격 풀에서 탈락했다가
다시 합류하여 소스 IP 주소 집합을 끊임없이 변화시킬 수도 있습니다.
이러한 트래픽 특성으로 인해 속도 제한 및 지리적 차단과 같은 기존 완화 기술이 덜 효과적입니다.
4. Challenge Collapsar 공격/임의 URI – Challenge Collapsar(CC) 공격 에서 공격자는 일반적인 요청을 자주 보내지만
요청된 URI는 복잡하고 시간이 많이 걸리는 알고리즘이나 데이터베이스 작업을 실행해야 하며, 이는 대상 서버의 리소스를 고갈시킬 수 있습니다.
공격자는 정적 규칙과 같은 레거시 완화 도구를 무력화하는 방식으로 URI와 기타 HTTP 매개변수를 무작위로 지정할 수도 있습니다.
대신 NGINX App Protect DoS는 효능을 극적으로 높이고 거짓 양성을 줄이는 고급 머신 러닝 알고리즘에 의존합니다.
5. NAT 뒤에 숨음 – 공격자는 암호화나 네트워크 주소 변환(NAT)을 사용하여 탐지를 회피합니다.
소스 IP 주소만 추적하여 공격을 탐지하려는 것은 한 명의 사용자만 공격하더라도 모든 NAT 사용자를 공격자로 취급하기 때문에 효과가 없습니다.
NGINX App Protect DoS는 IPv4에 지문을 사용하여 NAT 뒤에 있는 악의적인 행위자를 정확하게 감지합니다.
대부분의 트래픽은 SSL/TLS를 사용하여 암호화되므로 행위자를 식별하는 키를
IP 주소에서 IP 주소와 TLS 지문의 조합으로 확장할 수 있습니다(지문은 TLS hello 메시지를 기반으로 함).
6. 대상 SSL/TLS 공격 – 공격자는 SSL/TLS 핸드셰이크 프로토콜을 악용합니다.
인기 있는 접근 방식 중 하나는 대상 SSL/TLS 서버로 가비지 데이터를 보내는 것입니다.
유효하지 않은 메시지를 처리하는 데는 합법적인 메시지와 마찬가지로 컴퓨팅 비용이 많이 들지만 유용한 결과는 없습니다.
대부분의 방화벽은 이 경우 도움이 되지 않습니다.
유효한 SSL/TLS 핸드셰이크 패킷과 유효하지 않은 SSL/TLS 핸드셰이크 패킷을 구별할 수 없고
방화벽에서 복호화를 구현하는 데 비용이 많이 들기 때문입니다.
NGINX App Protect DoS는 SSL/TLS 서명 메커니즘을 사용하여 암호화되지 않고
SSL/TLS 핸드셰이크 프로세스 초기에 전달되는
CLIENT HELLO 메시지를 기반으로 이상 기반 탐지 및 완화를 제공하여 높은 복호화 비용을 제거합니다.
또한 SSL/TLS 서명을 모니터링 서버 상태 메커니즘과 함께 사용하면 SSL/TLS 종료 없이 DoS 보호 및 완화가 가능합니다.\
요약
DoS 공격이 네트워크가 아닌 애플리케이션을 대상으로 하는 경우가 점점 더 많아지고 있습니다.
이러한 레이어 7 DoS 공격은 합법적인 트래픽처럼 보이기 때문에
기존의 웹 애플리케이션 방화벽(WAF) 방어로는 효과적으로 탐지할 수 없습니다.
게다가 공격자들은 머신러닝과 AI와 같은 새로운 기술을 활용하여 레이어 7 DoS 공격을 감행하고 있어,
단순한 규칙과 고정된 서명으로는 방어가 어려워지고 있습니다.
레이어 7 DoS 완화 솔루션도 진화해야 하며, NGINX App Protect DoS는 적응적이고 동적인 방어 기술로 이에 대응합니다.
위 내용과 같이 NGINX Plus / NGINX App Protect DoS 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
PCI DSS 규정을 준수하는 앱 보안 솔루션: NGINX App Protect
디지털 혁신은 보안 환경에 깊은 영향을 미쳤습니다. 특히, 조직들이 비즈니스 민첩성을 극대화하기 위해 모놀리식 애플리케이션에서 클라우드 네이티브 마이크로서비스 아키텍처로 전환함에 따라 기존의 전통적인 보안 방식은 더 이상 유효하지 않게 되었습니다. 마이크로서비스 아키텍처는 여러 서비스 간 네트워크 통신을 기반으로 하여, 기존의 모놀리식 아키텍처보다 사이버 공격에 훨씬 더 취약해졌습니다. 이에 따라 조직은 보안과 민첩성 사이의 적절한 균형을 찾아야 하며, 특히 PCI DSS(결제 카드 산업 데이터 보안 표준) 규정 준수는 신용 카드 거래를 처리하는 모든 기업에게 필수적인 요소입니다.
이번 글에서는 NGINX App Protect와 같은 고급 보안 솔루션이 어떻게 PCI DSS 규정 준수를 돕고, 특히 **웹 애플리케이션 방화벽(WAF)**을 통해 웹 기반 공격을 방어하는지에 대해 설명하겠습니다.
1. PCI DSS 규정 준수는 오늘날의 최신 애플리케이션에 매우 중요합니다
**PCI DSS (Payment Card Industry Data Security Standard)**는 카드 소유자 데이터를 보호하기 위한 보안 요구 사항을 정의한 국제적인 표준입니다. 이 표준은 신용 카드 결제 처리에 관련된 모든 당사자들이 카드 소유자 데이터를 안전하게 처리하도록 요구합니다. 특히, PCI DSS 규정에서 강조하는 첫 번째 요구 사항은 **“카드 소유자 데이터를 보호하기 위해 방화벽을 설치하고 유지 보수”**하는 것입니다.
주요 요구 사항
하지만 단순히 WAF를 설치하는 것만으로는 충분하지 않습니다. 지속적으로 새로운 형태의 공격이 등장하기 때문에, 최신 애플리케이션 환경에서는 보안 정책을 지속적으로 갱신하고 업데이트하는 것이 필수적입니다.
PCI DSS 요구 사항 6.5: 방어해야 할 취약점
PCI DSS 규정에서는 WAF가 최소한 방어해야 하는 취약점을 명시하고 있습니다. 대표적으로는 다음과 같은 공격이 포함됩니다:
OWASP의 Top 10에도 다양한 보안 취약점이 포함되어 있습니다. 이를 방어하기 위해서는 WAF와 같은 보안 솔루션을 통해 실시간으로 웹 애플리케이션을 보호하고, 새로운 형태의 공격을 탐지할 수 있어야 합니다.
2. NGINX App Protect는 PCI DSS 요구 사항을 충족하거나 능가합니다
NGINX App Protect는 PCI DSS 규정 준수와 최신 보안 취약성으로부터 애플리케이션을 보호하는 데 매우 효과적인 웹 애플리케이션 방화벽(WAF) 솔루션입니다. 이 솔루션은 PCI DSS 요구 사항을 충족하거나 능가하며, 특히 신용 카드 결제와 관련된 민감한 데이터 보호와 웹 기반 공격 탐지 및 방어를 매우 효과적으로 수행합니다.
2.1. 최신 보안 위협에 대응
NGINX App Protect는 최소 2개월마다 6,000개 이상의 서명을 업데이트하여 최신의 보안 위협을 방어합니다. 이를 통해 기존 WAF보다 더 빠르고 정확하게 새로운 공격 패턴을 인식하고 차단할 수 있습니다.
2.2. 강력한 보안 성능
NGINX App Protect는 애플리케이션에 가깝게 배치되어 있어 애플리케이션 성능에 미치는 영향이 적고, 보안 정책을 빠르게 업데이트할 수 있습니다. 또한, CI/CD 파이프라인에 통합될 수 있어 보안이 자동화된 개발 환경에서 실시간으로 적용됩니다.
2.3. 통합된 보호 기능
NGINX App Protect는 다양한 공격 방식을 처리합니다:
2.4. 유연한 배포 및 확장성
NGINX App Protect는 모든 플랫폼에서 일관된 성능을 제공합니다:
2.5. 실제 환경에서의 강력한 보호
NGINX App Protect는 하이브리드 클라우드 환경에서의 보호를 극대화하며, PCI DSS 요구 사항을 완벽하게 준수할 수 있도록 돕습니다. 이 솔루션을 통해 애플리케이션이 PCI DSS 준수 상태를 유지하면서도 높은 성능과 민첩성을 제공할 수 있습니다.
결론
NGINX App Protect는 PCI DSS 요구 사항을 충족하는 웹 애플리케이션 방화벽(WAF) 솔루션으로, 최신의 사이버 공격으로부터 기업의 애플리케이션을 효과적으로 보호합니다. 마이크로서비스 아키텍처와 클라우드 네이티브 환경에서 요구되는 보안과 민첩성의 균형을 맞추는 데 있어, NGINX App Protect는 강력하고 유연한 보안 기능을 제공합니다. 30일 무료 체험을 통해 NGINX App Protect가 어떻게 PCI DSS 규정 준수 문제를 해결하는 완벽한 조합이 될 수 있는지 직접 경험해 보시기 바랍니다.
이제 NGINX App Protect를 통해 신용 카드 결제와 관련된 민감한 데이터를 보호하고, 최신 보안 위협으로부터 애플리케이션을 효과적으로 방어할 수 있습니다.
위 내용과 같이 NGINX Plus / NGINX App Protect 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
시작은 모놀리식 아키텍처였습니다.
이는 소프트웨어 개발자들에게 오랫동안 유용하게 사용되었고, 여전히 일부 사용 사례에서는 효과적입니다.
하지만 애플리케이션이 커지면서 모놀리식 구조는 개발, 보안 및 유지 관리가 어려워졌습니다.
이때 대안으로 등장한 것이 마이크로서비스입니다.
모놀리식 아키텍처가 작고 독립적인 서비스로 분해되어 각각 단일 비즈니스 기능을 수행하고, 네트워크를 통해 통신하여 애플리케이션의 전체 기능을 제공합니다.
초기에는 웹 개발자들이 SOAP을 통신 프로토콜로 사용하고 XML을 데이터 인코딩 방식으로 활용했지만, 많은 개발자들이 이 조합이 번거롭고 느리다고 느끼기 시작했습니다.
그 결과 REST 기반 아키텍처로의 전환과 함께 HTTP와 JSON의 광범위한 채택이 이루어졌습니다.
하지만 기술의 발전은 끊임없이 이루어지며, 개발자들은 SOAP과 REST의 텍스트 기반 한계를 극복할 더 나은 애플리케이션 설계 방안을 모색했습니다.
그 중 하나가 gRPC입니다. 구글이 개발한 gRPC는 방대한 독립 서비스 간의 연결을 위해 설계되었습니다.
gRPC는 프로토콜 버퍼(protobufs)를 플랫폼 및 언어에 구애받지 않는 구조화된 데이터 직렬화 메커니즘으로 사용하며, HTTP/2를 통신 프로토콜로 채택하고 있습니다.
gRPC가 다른 API 프레임워크에 비해 유리한 점으로는 저지연 처리량, 여러 언어 지원, 컴팩트한 데이터 표현, 실시간 스트리밍 등이 있으며,
이 모든 것이 마이크로서비스 간 통신과 저전력, 저대역폭 네트워크를 통한 통신에 특히 적합합니다.
gRPC의 인기는 최근 몇 년 동안 크게 증가했습니다.
이는 더 높은 신뢰성과 확장성, 클라이언트와 서버 모두에 대한 언어 독립성을 통해 새로운 서비스를 더 빠르고 효율적으로 구축하기 쉽게 만들어주기 때문입니다.
gRPC의 이점에 대한 두드러진 예는 오픈 뱅킹으로, 오픈 소스 기술을 사용하여 API를 구축하고 제공하여 타사 개발자가 은행이나 다른 금융 기관의 고객에게 추가 서비스를 제공할 수 있도록 합니다.
오픈 뱅킹의 전체 기반은 금융 정보를 보다 효과적이고 효율적으로 제공한다는 이상에 기반을 두고 있습니다.
gRPC는 프로토콜 버퍼의 컴팩트한 형식과 HTTP/2의 멀티플렉싱으로 인해 주어진 페이로드의 전송이 REST API보다 훨씬 빠르기 때문에 이 목표를 달성하는 데 도움이 됩니다.
데이터를 수신할 때는 약 7배, 데이터를 전송할 때는 10배 더 빠릅니다.
결과적으로 금융 기관은 서비스 간 통신에 gRPC를 채택하여 서비스를 보다 빠르게 제공하고 효율성, 안정성 및 규모를 높이고 있습니다.
gRPC의 속도가 큰 이점이 되는 구체적인 사용 사례 중 하나는 고객 온보딩 프로세스로,
오픈 뱅킹에서의 성공에 가장 중요합니다.
다른 API 프레임워크를 사용하면 새 계좌를 만드는 것이 금융 기관과 고객 모두에게 번거롭고 시간이 많이 걸릴 수 있습니다.
gRPC를 사용하면 빠른 데이터 전송으로 고객이 몇 분 안에 새 계좌를 만들 수 있습니다.
이를 통해 고객 만족도가 크게 향상되고 금융 기관의 비용이 크게 감소합니다.
gRPC 표준과 프로토콜 버퍼 형식은 오픈 소스 라이브러리로 구현되어 있습니다.
프로토콜 버퍼는 사이버 공격에 대해 다른 데이터 표현 방식보다 더 안전하다고 여겨지는데, 이는 라이브러리 파서가 잘못된 요청을 거부하고 라이브러리의 동작을 더 세밀하게 검사하기 때문입니다.
하지만 gRPC에 대한 공격의 가능성은 여전히 존재합니다. 예를 들어, 파서는 다음과 같은 허점을 가지고 있습니다:
공격자는 이러한 gRPC 프로토콜의 허점을 악용하여 애플리케이션을 위협할 수 있습니다.
또한, 프로토콜 버퍼는 메시지 정의에 명시되지 않은 필드를 생성할 수 있도록 허용합니다.
이는 설계의 확장성을 보장하여 향후 메시지의 확장 버전과의 호환성을 가능하게 하지만, 동시에 공격자가 애플리케이션에서 명시적으로 허용되지 않은 필드를 요청에 포함시킬 수 있는 밀반입 공격에 취약하게 만들 수 있습니다.
NGINX App Protect는 서비스 애플리케이션에 더 가까운 최신 gRPC 기반 애플리케이션을 보호하도록 설계되었습니다.
이를 통해 AppDev, DevOps 및 DevSecOps 팀은 애플리케이션 보안을 코드로 관리하고 기본 도구를 활용할 수 있습니다.
예를 들어, NGINX App Protect는 금융 기관과 해당 서비스가 서비스 간 통신을 위해
gRPC를 구현할 때 오픈 뱅킹 표준을 준수하도록 보장합니다.
NGINX App Protect의 엔진은 와이어 요청에서 gRPC 메시지를 심층적으로 검사하고,
프로토콜 버퍼 메시지를 구문 분석하고, 모든 중첩 및 복잡한 데이터 구조를 포함하여 메시지 헤더와 페이로드에서 악성 데이터를 감지합니다.
검사는 모든 요청에 대해 수행되고 각 API 호출 매개변수에 대한 공격 탐지 메커니즘을 적용합니다.
gRPC API를 사용하면 gRPC 인터페이스를 사용하여 유형 라이브러리 파일(IDL 파일)과 프로토콜 버퍼의
proto 정의 파일에 보안 정책을 설정합니다. 업데이트된 파일이 로드되면
NGINX App Protect는 구성을 변경할 필요 없이 즉시 새 보안 정책을 적용하기 시작합니다.
gRPC proto 파일은 CI/CD 파이프라인의 일부로 자주 업데이트되므로
보안 정책을 업데이트해도 프로세스가 중단되거나 오버헤드가 추가되지 않으며
애플리케이션은 항상 최신의 가장 최신 정책으로 보호됩니다.
gRPC 기반 마이크로서비스 간의 동서 트래픽 보호뿐만 아니라,
NGINX App Protect는 공개적으로 노출된 자산 간의 남북 트래픽 또한 효과적으로 안전하게 보호합니다.
gRPC는 서비스 간 통신의 속도, 효율성 및 확장성을 극대화하지만, API 데이터(URL, 헤더 및 페이로드)와
gRPC API를 노출하는 애플리케이션 서비스에 대한 보호가 필수적입니다.
이러한 맥락에서 NGINX App Protect는 현대 애플리케이션 아키텍처에서 핵심적인 역할을 합니다.
NGINX App Protect와 gRPC에 관한 더 자세한 정보는 저희 라이트보드 비디오를 참조해 주시기 바랍니다.
위 내용과 같이 NGINX Plus / NGINX App Protect 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
최근 몇 년 동안 API는 현대적 어플리케이션 경제를 구축하는데 있어 주요한 접근 방식이 되었습니다.
이러한 소프트웨어 인터페이스는 시스템, 애플리케이션 및 장치가 광범위한 데이터와 기능을 통신하고
공유할 수 있도록 하는 주요 방법이 되었습니다.
본질적으로 API는 정보를 위한 현대의 실크로드가 되었으며
고객에게 다양한 공급 업체의 최고 품질의 도구를 결합한 솔루션을 잠금 해제할 수 있는 힘을 제공합니다.
최근 몇 년 동안 API는 현대 애플리케이션 경제의 핵심 요소로 자리 잡았습니다.
이 소프트웨어 인터페이스는 다양한 시스템, 애플리케이션, 장치 간의 데이터와 기능 공유를 가능하게 하며,
본질적으로 현대의 실크로드 역할을 하고 있습니다.
API를 통해 고객은 여러 공급업체의 최첨단 도구를 통합한 솔루션을 활용할 수 있는 강력한 힘을 얻습니다.
MuleSoft의 연례 Connectivity Benchmark Report에 따르면, 조사에 참여한 조직의 80%가 공개 또는 비공식 API를 사용하고 있습니다.
이들 API는 생산성 향상(54%), 혁신 촉진(47%), 비용 절감(34%) 등 다양한 이점을 제공하며,
평균적으로 기업 총 수익의 31%를 차지하는 등 상당한 수익을 창출합니다.
하지만 API의 보안 문제는 여전히 해결해야 할 중요한 과제입니다.
F5 Labs의 연구에 따르면, 2020년 상반기 API 보안 사고의 발생 건수가 지난 2년 동안의 총 사고 수를 초과할 것으로 보입니다.
DevOps 팀은 인증 부족, 인증 및 권한 부여의 문제, 구성 오류 등 다양한 보안 취약점에 직면하고 있습니다.
이제 중요한 질문은 "모든 API 활동을 어떻게 보호할 것인가?"입니다.
이 블로그에서는 NGINX App Protect의 '코드로서의 보안' 접근 방식을 중심으로, API 보안에서 이 접근법이 얼마나 중요한지,
그리고 다른 보안 솔루션들과 함께 CI/CD 파이프라인에 어떻게 통합될 수 있는지를 설명하겠습니다.
ProgrammableWeb에 따르면, 현재 20,000개 이상의 비공식, 파트너, 공개 API가 사용되고 있으며,
이를 통해 우리가 일상적으로 사용하는 애플리케이션을 지원하고 있습니다.
API의 매력과 함께, API가 실행되거나 연결되는 컨테이너 기반 마이크로서비스의 장점은 직원,
전략적 및 상업적 파트너를 포함한 광범위한 사용자에게 소프트웨어 기능과 데이터를 개방할 수 있는 가능성입니다.
이러한 접근 방식은 DevOps 팀에게도 매력적이며,
특정 요구에 적합한 최상의 공급업체를 선택할 수 있는 유연성을 제공합니다.
예를 들어, 많은 기업이 개인 및 파트너 API를 활용하여 셀프 서비스 IT를 활성화하고 있습니다.
IT 자산을 검색 가능하고 재사용 가능한 형태로 만들어
조직의 구성원이 DevOps 팀의 개입 없이도 다양한 작업을 수행할 수 있게 합니다.
이러한 셀프 서비스 IT의 올바른 실행은 민첩성을 향상시키고 출시 속도를 가속화하며,
다양한 공급업체의 솔루션을 결합하여 고객 중심의 효율성과 혁신, 그리고 더 높은 마진 수익을 창출하는 데 기여합니다.
이와 같은 역동성은 개발 및 운영 측면에서도 동일하게 적용됩니다.
컨테이너화된 소프트웨어와 API를 통해 DevOps 팀은 Okta, Auth0, Microsoft와 같은 ID 및 액세스 관리(IAM) 파트너는 물론,
MuleSoft, Akana, Kong과 같은 API 수명 주기 관리 파트너와의 폭넓은 협업을 가능하게 합니다.
오늘날의 빠르게 움직이는 역동적인 CI/CD 환경에서 개발자와 DevOps 팀은 솔루션을 구현하고
소프트웨어를 빠르고 안전하게 출시하는 데 도움이 되는 애플리케이션 보안 도구를 사용하여
웹 앱과 API를 보호하는 전체적인 접근 방식이 필요합니다.
팀은 선택한 액세스 관리 및 라이프사이클 관리 파트너와 긴밀하게 통합된 상태를 유지하면서 코드를 보호해야 합니다.
오늘날의 빠르게 변화하는 CI/CD 환경에서 개발자와 DevOps 팀은
웹 애플리케이션과 API를 보호하기 위해 포괄적인 접근 방식을 필요로 합니다.
이는 솔루션을 구현하고 소프트웨어를 신속하고 안전하게 출시하는 데
도움을 주는 애플리케이션 보안 도구를 활용하는 것을 포함합니다.
또한, 팀은 선택한 액세스 관리 및 라이프사이클 관리 파트너와의 긴밀한 통합을 유지하면서 코드를 보호해야 합니다.
최근 몇 년간 DevOps가 DevSecOps로 전환되면서, 보안을 단순히 개발 후에 적용하는 것이 아니라,
소프트웨어 개발의 모든 단계에 보안을 통합하려는 노력이 증가하고 있습니다.
이는 보안이 단순히 마지막에 추가되는 것이 아니라,
소프트웨어의 모든 측면에 내재되어야 한다는 인식을 반영합니다.
이 접근 방식에는 다음과 같은 주요 관행이 포함됩니다:
1. CI/CD 파이프라인에 보안 자동화 내장
가능한 경우 보안을 CI/CD 파이프라인에 직접 통합하여 자동화합니다.
이는 개발 과정에서 실시간으로 보안 검사를 수행하고,
보안 취약점을 조기에 발견하여 해결할 수 있도록 합니다.
2. 보안을 게이트가 아닌 가드레일로 구축
보안을 단순히 접근을 허용하거나 거부하는 게이트가 아닌,
안내와 도구를 제공하는 가드레일로 구축합니다.
이를 통해 개발자와 팀이 보안 기준을 준수할 수 있도록 지원하고,
실수를 방지하며, 보안의 일관성을 유지할 수 있습니다.
3. 분산형 컨테이너화 환경에서 일관된 보안 유지
다양한 파트너와 협력하여 보안 솔루션이 분산형 컨테이너화 환경을 포함한
모든 환경에서 일관되고 중앙 집중화된 방식으로 제공되도록 하며,
셀프 서비스 기능을 통해 사용이 용이하도록 합니다.
이는 보안 솔루션이 다양한 환경에서 일관되게 적용되고 관리될 수 있도록 합니다.
"코드로서의 보안"은 새로운 소프트웨어의 모든 측면에 보안을 내장한다는 의미입니다.
즉, 마지막에 보안을 추가하는 것이 아닙니다."
F5는 앱 보안을 적응 가능하고 확장 가능하며 신뢰할 수 있게 만드는 코드형 보안 접근 방식의 주요 지지자이며,
NGINX App Protect는 이를 가능하게 하는 데 중요한 역할을 합니다.
NGINX App Protect는 API 보안을 시장을 선도하는
고급 웹 애플리케이션 방화벽(Advanced WAF) 및 봇 보호의 기본 기능과 결합하여 DevOps를 지원합니다.
NGINX App Protect를 사용하면 기본 인프라와 무관한 가벼운 소프트웨어 패키지로 애플리케이션 보안을 배포할 수 있습니다.
따라서 소프트웨어 개발자는 선언적 정책("코드로서의 보안")을 활용하여 API 게이트웨이
또는 기타 Ingress 컨트롤러로 들어오고 나가는 모든 것을 보호할 수 있습니다.
이 모델에 따라 API 자체가 기본적으로 안전하지 않더라도 NGINX App Protect를 사용한 보안은
Ingress, Kubernetes 포드 내부 또는 서비스 간에 여러 지점에 적용할 수 있습니다.
고객이 우선시하는 다른 업계 리더와 협력하고 전 세계 DevOps 팀에서 이미 사용 중인 공급업체와 제품을 수용하면서
F5와 NGINX는 전체 애플리케이션 생태계를 위한 최첨단 솔루션을 제공하기 위해 최선을 다하고 있습니다.
API가 정보 공유를 위한 새로운 실크로드가 되고 그 어느 때보다 사용자와 연결할 수 있게 되면서
NGINX App Protect가 앱과 데이터를 잠재적 위협의 전체 범위에서 방어합니다.
NGINX App Protect는 파트너 생태계와 긴밀하게 통합하는 기능을 포함하여 앱을 제공하는 방식에 맞게 설계되었습니다.
DevOps 환경에서 원활하게 작동하는 이 업계를 선도하는 솔루션은 DevOps 자동화 및 CI/CD 프로세스 전반에 걸쳐
중단 없는 보안 제어를 통합하여 앱 보안이 사후에 추가되거나 임시방편으로 포장되지 않고 처음부터 내장되도록 보장합니다.
위 내용과 같이 NGINX Plus / NGINX App Protect 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
이제 "DevSecOps"라는 개념은 현대 소프트웨어 개발에 종사하는 거의 모든 사람에게 친숙해졌으며,
애플리케이션 보안을 근본적으로 강화하고 DevOps와 보안 팀 간의 마찰을 완화하겠다는 약속을 담고 있습니다 .
DevSecOps 모델에서 보안은 왼쪽으로 이동하여 DevOps 개발 및 배포 프로세스에 직접 통합됩니다.
특히 보안은 CI/CD(Continuous Integration/Continuous Deployment) 파이프라인의대부분 기업은 보안 태세가 어디에 있어야 하는지 알고 있지만, 의도와 현실은 매우 다른 두 가지입니다.
Contrast Security의 2020년 DevSecOps 현황 보고서에 따르면, 조직의 99% 이상이
프로덕션에서 평균적인 애플리케이션에 최소 4개의 취약점이 있다는 것을 인정해야 하는 반면,
거의 80%가 개발 중인 애플리케이션에서 20개 이상의 취약점을 보고합니다.
따라서 GitLab의 2021년 글로벌 DevSecOps 설문 조사에서 설문 조사에 참여한 보안 팀의 70% 가 보안을 left-shift 하고
물론 대부분 기업이 단지 몇 개의 앱 때문에 이러한 장애물을 극복하는 것은 아닙니다. 여러 팀에 분산된 수백 개의 제품과 서비스를 다루며 자체 기술 스택, 툴체인, 프로세스를 실행하고 있으며, 이러한 모든 것에는 취약점으로 인해 공격에 취약성이 생기지 않도록 보장하기 위한 감사와 검사가 필요합니다.
엄연한 사실은 위에서 논의한 과제를 해결할 방법을 찾지 못한다면 관행과 프로세스를 발전시킬 수 없다는 것입니다.
더 빠르게 반복하는 것이 모든 사람에게 필요한 승리처럼 느껴질 수 있지만
DevOps를 최대한 확장하는 유일한 방법은 전체 소프트웨어 개발 라이프 사이클에서 보안을 가능한 한 마찰 없이 적응 가능하게 만드는 것입니다.
점점 더 많은 조직이 Gartner의 리드를 따라 Platform Ops 라고 부르는 접근 방식을 채택하고 있습니다.
핵심 개념은 회사 내부 팀의 요구 사항에 맞게 구축된 플랫폼을 통해 DevOps 기능을 제공하는 것입니다.
내부 플랫폼을 사용하면 중복 작업에 시간을 낭비할 가능성이 줄어들 뿐만 아니라
여러 제품 팀이 속도가 느려지지 않고 지속적이고 효과적으로 협업할 수 있습니다.
Platform Ops 모델에 따라 보안 팀은 개발 팀에 셀프 서비스, 소비형 정책을 제공합니다.
또한 보안 도구는 애플리케이션 제공 프로세스에 완전히 통합됩니다.
이런 방식으로 개발자는 지식이 풍부한 보안 전문가가 정한 모범 사례, 거버넌스 및 액세스 요구 사항을 준수하면서도 더 빠르게 배포할 수 있습니다.
애플리케이션 보안 팀의 큰 승리는 Platform Ops가 개발자가 보안을 더 이상 속도를 늦추는 방해물로 경험하지 않고,
오히려 이미 사용하는 프로세스와 도구의 통합된 부분으로 경험하는 환경을 만든다는 것입니다.
이는 앱 제공팀이 기업 전체에 더 나은 보안을 보장하는 패턴을 채택하도록 동기를 부여합니다.
NGINX에서는 웹 애플리케이션 방화벽(WAF)과 같은 도구를 제공하는 것의 중요성을 인식합니다.
이 도구는 개발 프로세스의 어느 곳에서나 보안을 제공하고 CI/CD 파이프라인과 완벽하게 통합할 수 있도록 쉽게 왼쪽으로 이동할 수 있습니다.
CPU를 독점하거나 성능을 저하시키지 않는 가벼운 솔루션도 중요합니다.
또한 보안이 관문이 아닌 가드레일일 때 개발 및 DevOps 팀이 훨씬 더 행복하다는 것을 보았습니다.
보안이 공유 셀프 서비스 플랫폼에서 강력하고 일관된 제어 및 정책을 제공할 때
개발 및 보안 팀이 최소한의 상호 작용 및 방해로 지침에 맞춰 조정하기가 더 쉬워집니다.
NGINX 애플리케이션 플랫폼이 어떻게 이러한 기능을 제공하는지 살펴보겠습니다.
NGINX App Protect WAF는 앱을 빌드하고 관리하는 모든 곳에 배포할 수 있는 가볍고 현대적인 WAF입니다. F5의 시장을 선도하는 WAF 기술을 기반으로 구축된 App Protect WAF는 클라우드, 하이브리드, 마이크로서비스 기반 컨테이너화 또는 온프레미스 등 아키텍처나 배포 환경에 관계없이 OWASP Top 10 및 기타 고급 위협으로부터 보호합니다. NGINX Plus 의 동적 모듈로 배포되는 App Protect WAF를 사용하면 보안 구성 및 정책을 자동화하여 CI/CD 파이프라인 내에서 직접 프로비저닝할 수 있습니다.
NGINX App Protect DoS는 자동화된 적응형 보호 기능을 제공하여 서비스 거부(DoS) 공격을 식별하고 방지합니다 . F5 보안 전문가의 지원을 받는 App Protect DoS는 적응형 머신 러닝과 기본 제공 이상 탐지 기능을 사용하여 애플리케이션과 마이크로서비스를 애플리케이션 계층 공격으로부터 보호합니다. 타깃 공격을 차단해야 하든 실수로 잘못된 구성으로 인해 앱 성능이 저하되는 것을 방지해야 하든 App Protect DoS는 최신 애플리케이션 아키텍처, 개발 도구 및 프레임워크에 완벽하게 통합되는 제로터치 보호 기능을 제공합니다.
Controller Application Delivery Module 용 NGINX Controller App Security<.htmla> 애드온을 사용하면 운영 및 보안 준수를 저해하지 않고도 개발자 생산성을 강화할 수 있습니다. Controller App Security는 신뢰할 수 있는 앱 보호 및 중앙 집중식 앱 계층 위협 가시성을 제공하며, 이는 다중 클라우드 환경에서 실행되는 HTTP 기반 앱 및 API에서 표준화할 수 있습니다. 또한 보안팀이 사전 승인된 가이드라인을 제공하여 개발자와 DevOps팀이 셀프 서비스 방식으로 사용하여 앱에 앱 보호를 쉽게 추가할 수 있도록 합니다.
NGINX Controller API 관리 모듈 의 고급 보안은 최신 애플리케이션에 대한 분산 API 보안을 지원합니다.
위 내용과 같이 NGINX Plus / NGINX App Protect 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
현대의 서비스 거부(DoS) 공격: 기본 보호만으로는 충분하지 않은 이유
DoS 공격의 소스가 분산되어 있어도(DDoS 공격이 됨) 네트워크 계층의 기본 볼륨 공격은 일반적으로 단일 장치나 서비스를 대상으로 하며,현대의 아키텍처에는 현대적인 보호가 필요하다
암호화는 어디에나 있으며, 기존의 DoS 보호는 대규모 복호화를 위해 설계되지 않았습니다.기본 WAF 방어와 기존 DDoS 완화에만 의존한다면 레이어 7 공격에 대한 적절한 가시성과 맥락을 확보할 수 없으며,
그 결과는 지연, 다운타임, 수익 포기, 브랜드 손상 등 막대한 피해를 초래 할 수 있습니다.
행동 분석을 통해 클라이언트 이상 징후와 서비스 상태를 지속적으로 분석하여 제로데이 DoS 공격을 탐지할 수 있습니다.
사이트 동작을 자세히 살펴보면 다음과 같은 질문에 답할 수 있습니다.
기준 트래픽 패턴과 비교할 때 비정상적인 것이 있습니까?
브라우저가 포함해야 할 정보를 누락한 요청이 있습니까?
요청에 복잡한 데이터베이스 쿼리가 포함되어 높은 CPU 사용률을 유발하고 있습니까?
NGINX App Protect DoS는 일반적인 성능과 동작에 대한 정보를 구축하여
기존 방어 수단을 회피하고 애플리케이션에 스트레스를 가하는 레이어 7 공격에 집중할 수 있습니다.
DoS 공격의 결과는 변하지 않았습니다. 느린 성능, 불만족스러운 사용자, 포기된 수익. 그러나 DoS 공격이 발생하는 방식은 매우 다를 수 있으며, 해커는 암호화와 보안 도구를 사용하여 위협을 합법적인 트래픽으로 위장할 수 있습니다.
사용자들은 아키텍처의 차이를 구별할 수는 없지만, 좋은 사이트 성능과 나쁜 사이트 성능의 차이는 구별할 수 있습니다. 공격 트래픽의 폭격은 지연을 초래해 사용자 경험을 느리게 만듭니다. 충분히 느리고, 가장 인내심 있는 사용자(그다지 많지는 않지만!)조차도 거래를 포기하고 다른 사이트로 전환합니다. 단일의 타겟팅된 요청은 지연과 서버 스트레스를 유발할 수 있으므로, 전문화된 애플리케이션 DoS 보호는 매우 중요합니다.
웹 애플리케이션 보안 솔루션은 OWASP, Automated Threats to Web Applications (웹 애플리케이션에 대한 자동화된 위협)에서 설명한 새로운 공격에 대응하기 위해 계속 발전하고 있습니다. 그러나 애플리케이션 런타임에 본질적으로 통합된 보호가 필요합니다. 동적이고 적응 가능한 보호가 필요합니다. 다른 DoS 솔루션들이 SYN 플러드와 같은 네트워크 DDoS 공격을 위해 설계되었을 수 있지만, NGINX App Protect DoS 솔루션은 애플리케이션 자원을 스트레스를 주는 레이어 7 공격에 특화되어 있습니다. WAF와 레이어 7 DoS 솔루션을 결합함으로써, 애플리케이션은 취약점 악용과 비즈니스 로직 남용 모두로부터 보호받을 수 있으며, 타협뿐만 아니라 지연, 성능 저하, 다운타임을 방지할 수 있습니다.
상거래는 이제 대부분 온라인에서 이루어집니다. 사람들도 대부분 온라인에서 활동합니다. 당신의 온라인 환경을 안전하고 보호된 장소로 만드는 것이 필요합니다. NGINX App Protect WAF와 NGINX App Protect DoS 모듈을 결합하면, 당신의 환경, 애플리케이션, 비즈니스에 적합한 강력한 보호를 제공할 수 있습니다.
위 내용과 같이 NGINX App Protect 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
편집자 - 이 게시물은 10부작 시리즈의 일부입니다.
또한 전체 블로그 세트를 무료 전자책인 ' 테스트에서 프로덕션까지 Kubernetes 활용' 으로 다운로드할 수 있습니다 .
전체 블로그 모음을 '테스트에서 프로덕션으로: Kubernetes 활용하기'라는 무료 전자책으로도 다운로드할 수 있습니다.
Ingress 컨트롤러 선택 가이드의 첫 번째 부분에서는 요구 사항을 식별하는 방법에 대해 설명했습니다. 하지만 아직 제품을 테스트할 시점은 아닙니다!인프라와 관련하여 고려해야 할 또 다른 요소가 있습니다.인증입니다.
위 내용과 같이 NGINX Ingress Controller 및 NGINX App Protect WAF, DoS 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
PUT 요청으로 NGINX App Protect WAF 정책을 보안 정책 엔드포인트에 전달합니다.
https://{{CONTROLLER_FQDN}}/api/v1/security/policies/{{policy}}
다음과 유사한 JSON 개체가 있습니다.
{
"metadata": {
"name": "lowriskapppolicy",
"displayName": "Low-Risk App Protect Policy",
"description": "Corporate WAF policy for internal low-risk apps",
},
"desiredState": {
"content": {
"policy": {
"name": "lowriskapppolicy",
"template": {
"name": "POLICY_TEMPLATE_NGINX_BASE"
},
"applicationLanguage": "utf-8",
"enforcementMode": "blocking",
"signatures": [
{
"signatureId": 123458888,
"enabled": false
},
{
"signatureId": 304500123,
"enabled": false
}
],
}
}
}
}}
PUT 요청을 통해 보안 전략 엔드포인트에 WAF 정책을 참조하는 보안 전략을 만듭니다.
https://{{CONTROLLER_FQDN}}/api/v1/security/strategies/{{strategy}}
다음과 유사한 JSON 개체가 있습니다.
{
"metadata": {
"name": "lowriskstrategy",
"displayName": "Low-Risk App Strategy",
"description": "Corporate strategy for internal low-risk apps",
},
"desiredState": {
"content": {
"securityPolicyRef": "/security/policies/lowriskapppolicy"
}
}
}
앱 구성 요소(예: 앱의 앱 URI)에 WAF 정책을 적용하여 앱 구성 요소 엔드포인트에 대한 PUT 또는 POST 요청으로 보안 전략을 참조합니다.
https://{{Controller_FQDN}}/api/v1/services/environments/{{env}}/apps/{{app}}/components/{{component}}
다음과 유사한 JSON 개체가 있습니다.
{ "metadata": { "name": "main" }, "desiredState": { "ingress": { "uris": { "/": { } }, . . . "security": { "strategyRef": { "ref": "/security/strategies/lowriskstrategy" }, "waf": { "isEnabled": true } }, . . . }
보안 전략 만들기 페이지에서 보안 전략을 만드세요.
NGINX App Protect WAF 정책이 이미 Controller에서 사용 가능한 경우 정책 필드의 드롭 다운 메뉴에서 선택합니다.
아직 나열되지 않은 경우 + 새로 만들기를 클릭합니다.
나타나는 보안 정책 만들기 팝업 창에서 JSON 형식의 NGINX App Protect WAF 정책이 포함된 파일을 업로드합니다.
WAF 정책을 적용할 앱의 앱 구성 요소 편집 페이지에서 연관된 보안 전략을 선택합니다.
Controller App Security의 BYO App Protect Policy 기능(Controller ADM 3.20에서 사용 가능)을 사용하면 이제 사용자 지정 NGINX App Protect WAF 정책을 사용할 수 있으므로 NGINX App Protect WAF 또는 F5 Advanced WAF를 사용하여 구축된 견고하고 일관되며 검증된 정책으로 새 앱을 더 쉽게 보호할 수 있습니다.
무엇보다도 BYO App Protect Policy와 Controller App Security를 사용하면 검증된 단일 정책을 여러 앱에 적용할 수 있어 정책 변경 프로세스가 크게 간소화되고 간소화됩니다.
위 내용과 같이 NGINX Plus / NGINX App Protect 를 활용하여 보안취약점 완화가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요