mobile background
NGINX App Protect WAF/DoS 에서 구현가능한 기술 / 사용사례 소개 26
프로필 이미지
관리자
2025-01-16
조회 10


지난 5년 동안 F5 NGINX는 OWASP ModSecurity Core Rule Set(CRS)을 사용하여 표준 클래스의 취약성에 대한 지원을 제공하는 NGINX Plus용 NGINX ModSecurity WAF 모듈을 고객에게 제공하게 되어 기뻤습니다. 그러나 ModSecurity WAF에 대한 타사 지원에 대한 최근 변경으로 인해 NGINX ModSecurity WAF를 2024 년 3월 31일 부터 End-of-Life  (EoL) 로 전환하게 되어 유감입니다 .

우리의 결정은 ModSecurity를 유지 관리해 온 조직인 Trustwave의 최근 발표에 따른 것입니다 . Trustwave는 2024년 7월 1일 부터 다음 과 같이 할 예정입니다.

  • ModSecurity 오픈 소스 코드 및 WAF 지원 중단
  • ModSecurity 코드 유지 관리에 대한 책임을 오픈 소스 커뮤니티에 반환
  • 더 이상 상업 규칙을 제공하지 않습니다

또한 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 DNA의 필수 요소로 남아 있습니다.

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 – 최신 앱 및 API를 위한 고급 보안

NGINX App Protect WAF는 여러 가지 장점을 제공합니다.

  • NGINX App Protect WAF는 수십 년 동안 수천 명의 기업 고객이 실전 테스트를 거친 F5의 고급 WAF 엔진을 기반으로 합니다. 다른 F5 제품을 배포하는 경우 신속한 버그 수정 및 규칙 업데이트와 장기 로드맵에 대한 영향을 포함하여 전체 보안 솔루션 제품군에 대한 단일 지원 지점이 있습니다. 또한 전체 인프라에서 일관된 보호를 위해 F5 솔루션 간에 WAF 규칙을 쉽게 이식할 수 있습니다 .
  • 기본 ModSecurity 규칙은 오픈 소스 커뮤니티 구성원이 작성하고 유지 관리하며 일반적인 취약성을 다루도록 설계되었습니다. NGINX App Protect WAF 규칙은 F5 Labs에서 추적한 광범위한 취약성 및 위협 보고서를 기반으로 합니다. 그 결과 더 풍부한 규칙 세트가 제공되어 진화하는 위협에 발맞추기 위해 더 큰 애플리케이션 보안 보호 기능을 제공합니다.
  • ModSecurity 규칙에는 정규 표현식 평가가 포함되므로, 활성화하는 추가 제어마다 성능이 직접적으로 저하되어 우수한 성능과 포괄적 보호 중에서 선택해야 합니다. NGINX App Protect WAF 규칙은 활성화하는 규칙 수에 관계없이 고성능을 위해 바이트코드로 사전 컴파일됩니다.
  • NGINX App Protect WAF는 플랫폼에 구애받지 않고 설치 공간이 작고 리소스 요구 사항이 낮아 클라우드 배포에 이상적입니다.
  • NGINX App Protect WAF는 "코드로서의 보안"에 대한 선언적 정책과 CI/CD 툴 체인에 대한 쉬운 통합을 통해 DevOps 팀의 요구 사항을 충족합니다.
  • NGINX App Protect WAF는 웹 앱, 마이크로서비스, 컨테이너 및 API에 대한 일관된 보안 제어 기능을 제공합니다.

자동차 타이어 공급업체 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 를 활용하여 보안취약점 완화가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요


전문가에게 상담받기

프로필 이미지
관리자
2025-01-16
조회 11

일상 생활의 점점 더 많은 부분이 온라인으로 옮겨가면서 

사이버 공격자들은 우리가 의존하는 앱의 제공 서비스 수준을 떨어뜨리려고 합니다. 

사이버 공격자들의 동기는 복수부터 피해 기업의 주가에 영향을 미치는 것, 

보안팀의 주의를 데이터 유출로부터 분산시키는 연막작전까지 다양합니다.


이전 블로그에서는 과거에 보안팀이 어떻게 볼륨 서비스 거부(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 공격을 탐지하고 완화합니다:

  1. 통계 사이트 모델에서 일반적인 행동 캡처
  2. 서비스 상태 확인
  3. 이상 징후 탐지
  4. 악성 행위자 및 요청 패턴 식별
  5. 다계층 방어로 공격 완화

통계적 사이트 모델에서 일반적인 행동 포착하기

프로세스의 첫 번째 단계는 사이트가 공격을 받지 않는 시간 동안 

사용자 및 애플리케이션 동작을 캡처하여 일반적인 동작의 기준선을 캡처하는 통계 사이트 모델을 생성하는 것입니다. 

NGINX 앱 프로텍트는 320개의 사용자 및 앱 지표를 추적하여 앱 배포를 종합적으로 파악합니다. 

또한 트래픽을 관찰하면서 통계 사이트 모델을 동적으로 업데이트합니다. 

따라서 시스템 임계값을 수동으로 조정할 필요가 없으며, 

시간이 지남에 따라 필연적으로 발생하는 트래픽 패턴의 변화를 NGINX App Protect DoS가 고려하도록 보장합니다.

추적되는 지표의 한 종류는 HTTP 요청 특성과 관련된 것으로, 

HTTP 메서드, User-Agent 헤더의 값, 그리고 그래픽에 표시된 것과 같은 기타 지표가 있습니다.

Pie charts representing proportin of values for HTTP request characteristics (method, value of User-Agent header, and 6 others)

서비스 상태 확인

많은 레이어 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 provides multi-layer defense against attacks, incorporating conservative mitigation (block bad IP addresses and matching signatures) followed by standard mitigation (rate limiting) if necessary

공격 완화 중 오탐 최소화하기

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개 이상의 메트릭을 추적하여 

가장 정확한 보호 기능을 제공하는 다요인 통계 모델을 생성합니다. 

고유한 알고리즘으로 오탐을 크게 줄입니다. 


  • 복잡하고 최신 공격으로부터 애플리케이션 방어
  • 엔진엑스 앱 프로텍트 서비스 거부로 애플리케이션 수준의 DoS 공격 차단



위 내용과 같이 NGINX App Protect 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요


전문가에게 상담받기

프로필 이미지
관리자
2025-01-15
조회 4



디지털 혁신이 비즈니스 잠재력을 가속화하는 반면, 안타깝게도 위협이 되는 환경도 확장되고 있습니다. 

보안 팀이 증가하는 범위와 책임에 대해 적응하고 몰두하는 동안, 

공격자는 이를 악용하여 재정적 이익을 위해 애플리케이션을 남용하는 방식이 그 어느 때보다 정교해지고 있습니다. 


네트워크 수준에서의 기존 서비스 거부(DoS) 공격과 비교했을 때, 애플리케이션 수준( 7계층 ) DoS 공격은 크게 증가하고 있는데, 

그 이유는 최신 애플리케이션 아키텍처에 맞게 설계되지 않은 기존 방어를 우회 할 수 있기 때문입니다.


공격자의 관점에서 볼 때, 레이어 7 DoS 공격에는 두 가지 주요 특징이 있습니다. 

첫째, 매우 적은 자원으로도 상당한 혼란을 일으킬 수 있다는 점이고, 

둘째, 탐지하기 어렵다는 점입니다. 

정교한 도구를 사용하여 생성되고 정밀하게 타겟팅 된 요청으로 인해 이러한 공격은 

애플리케이션 서버와 API를 방해하여 정당한 요청을 처리할 수 없게 만듭니다. 


서버가 처리할 수 있는 것보다 더 많은 요청이 폭주할 경우, 

서버는 정당한 요청을 드롭하거나, 응답하지 않거나, 

심지어 충돌할 수도 있습니다.

기존 DoS 완화 솔루션은 최신 앱에 효과적이지 않습니다. 


전통적인 DoS 완화 솔루션은 현대 애플리케이션에는 효과적이지 않습니다. 

이들은 정적인 규칙 기반 보안을 제공하며, 

현대 애플리케이션 환경에서의 변화와 업데이트 속도를 따라잡기 위해 

지속적인 유지 관리가 필요합니다.

NGINX App Protect 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는 다양한 위치에 배포하여 애플리케이션 서비스를 보호할 수 있습니다.

  • Edge  – 외부 로드 밸런서 및 프록시
  • Ingress Controller – 쿠버네티스 거래소
  • 서비스별 프록시  - 내부 서비스 프록시 계층
  • 포드당 프록시  - 포드에 내장된 프록시
  • API 게이트웨이  - 마이크로서비스로의 진입점

완화된 공격 유형

NGINX App Protect DoS는 여러 정교한 공격 유형에 대한 보호 기능을 제공합니다.


1. GET플러딩 POST공격  – (HTTP와 HTTPS 모두) 공격자는 대량의 요청으로 서버나 API를 과부하시켜 실제 사용자에게 응답하지 못하게 만들려고 합니다.

2. "느린" 공격 - (HTTP와 HTTPS 모두) "느리고 낮은" 공격은 서버 리소스를 묶어서 실제 사용자의 요청을 처리하는 데 사용할 수 있는 리소스가 없습니다.

두 가지 요인으로 인해 방어하기 어렵습니다.

  1. 네트워크 DDoS 공격과 달리 광범위한 대역폭을 사용하지 않으므로 일반 트래픽과 구별하기 어렵습니다.
  2. 시작하는 데 많은 리소스가 필요하지 않으므로 정교한 자동화 도구를 사용하여 단일 컴퓨터에서 수천 개의 요청을 보낼 수 있습니다.

느린 공격에는 세 가지 주요 유형이 있습니다.

  1. Slowloris  – 공격자가 서버에 연결하고 느린 속도로 부분적인 요청 헤더를 보냅니다. 
    서버는 나머지 헤더를 기다리는 동안 연결을 열어두고 실제 사용자가 사용할 수 있는 연결 풀을 고갈시킵니다.
  2. 느린 읽기  - 공격자는 잘 구성된 HTTP 요청을 보내지만, 응답을 느린 속도로 읽습니다.
    이는 서버 리소스를 소모하는 누적 효과가 있어 합법적인 요청이 통과하지 못하게 합니다.
  3. 느림POST  - 공격자는 POST서버로 합법적인 HTTP 헤더를 보내고, 뒤따를 메시지 본문의 크기에 대한 올바른 사양을 포함합니다.
    그런 다음 메시지 본문을 매우 느리게 보냅니다. 메시지가 유효한 것처럼 보이기 때문에 서버는 전체 본문이 도착할 때까지 연결을 열어 둡니다.
    많은 수의 느린 POST공격은 실제 사용자가 사용할 수 있는 연결 풀을 고갈 시킵니다.

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 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요



전문가에게 상담받기

프로필 이미지
관리자
2024-11-08
조회 15

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 규정에서 강조하는 첫 번째 요구 사항은 **“카드 소유자 데이터를 보호하기 위해 방화벽을 설치하고 유지 보수”**하는 것입니다.

주요 요구 사항

  • 요구 사항 6.6은 웹 애플리케이션에 대한 보안 방안을 언급하며, 공개 웹 애플리케이션 소유자가 웹 기반 공격(예: SQL 인젝션, XSS 등)을 탐지하고 방지하기 위한 자동화된 보안 솔루션을 설치해야 한다고 명시합니다. 이때 **웹 애플리케이션 방화벽(WAF)**이 필수적인 도구로 등장합니다.

하지만 단순히 WAF를 설치하는 것만으로는 충분하지 않습니다. 지속적으로 새로운 형태의 공격이 등장하기 때문에, 최신 애플리케이션 환경에서는 보안 정책을 지속적으로 갱신하고 업데이트하는 것이 필수적입니다.

PCI DSS 요구 사항 6.5: 방어해야 할 취약점

PCI DSS 규정에서는 WAF가 최소한 방어해야 하는 취약점을 명시하고 있습니다. 대표적으로는 다음과 같은 공격이 포함됩니다:

  • Injection flaws: SQL Injection, OS Command Injection, LDAP Injection, XPath Injection
  • Cross-Site Scripting (XSS) 및 Cross-Site Request Forgery (CSRF)
  • 잘못된 인증 및 세션 관리
  • 잘못된 액세스 제어
  • 보안되지 않은 암호화 저장소 및 통신
  • 불충분한 로깅 및 모니터링

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는 다양한 공격 방식을 처리합니다:

  • HTTP 프로토콜 및 회피 매개 변수 검사: HTTP 메시지 내용의 잘못된 메타 문자나 길이 오류를 탐지합니다. 이는 알려지지 않은 공격(zero-day)에 대한 탐지 가능성을 높입니다.
  • JSON 및 XML 콘텐츠 처리: 악의적인 주입에 대한 payload를 확인할 수 있습니다.
  • 데이터 마스킹 (Response Scrubbing): 민감한 정보를 응답에 노출하지 않도록 보호하는 고유한 기능입니다.

2.4. 유연한 배포 및 확장성

NGINX App Protect는 모든 플랫폼에서 일관된 성능을 제공합니다:

  • 퍼블릭 및 프라이빗 클라우드, VM, 컨테이너 등 다양한 환경에서 배포 가능합니다.
  • API 게이트웨이 및 Kubernetes Ingress Controller와 통합되어, 마이크로서비스 아키텍처를 지원하는 클라우드 네이티브 환경에서도 강력한 보안을 제공합니다.

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 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요



전문가에게 상담 하기

프로필 이미지
관리자
2024-09-24
조회 34



gRPC


시작은 모놀리식 아키텍처였습니다. 

이는 소프트웨어 개발자들에게 오랫동안 유용하게 사용되었고, 여전히 일부 사용 사례에서는 효과적입니다. 

하지만 애플리케이션이 커지면서 모놀리식 구조는 개발, 보안 및 유지 관리가 어려워졌습니다. 


이때 대안으로 등장한 것이 마이크로서비스입니다. 

모놀리식 아키텍처가 작고 독립적인 서비스로 분해되어 각각 단일 비즈니스 기능을 수행하고, 네트워크를 통해 통신하여 애플리케이션의 전체 기능을 제공합니다.

초기에는 웹 개발자들이 SOAP을 통신 프로토콜로 사용하고 XML을 데이터 인코딩 방식으로 활용했지만, 많은 개발자들이 이 조합이 번거롭고 느리다고 느끼기 시작했습니다. 

그 결과 REST 기반 아키텍처로의 전환과 함께 HTTP와 JSON의 광범위한 채택이 이루어졌습니다.


하지만 기술의 발전은 끊임없이 이루어지며, 개발자들은 SOAP과 REST의 텍스트 기반 한계를 극복할 더 나은 애플리케이션 설계 방안을 모색했습니다.

 

그 중 하나가 gRPC입니다. 구글이 개발한 gRPC는 방대한 독립 서비스 간의 연결을 위해 설계되었습니다. 

gRPC는 프로토콜 버퍼(protobufs)를 플랫폼 및 언어에 구애받지 않는 구조화된 데이터 직렬화 메커니즘으로 사용하며, HTTP/2를 통신 프로토콜로 채택하고 있습니다.

gRPC의 이점

gRPC가 다른 API 프레임워크에 비해 유리한 점으로는 저지연 처리량, 여러 언어 지원, 컴팩트한 데이터 표현, 실시간 스트리밍 등이 있으며, 

이 모든 것이 마이크로서비스 간 통신과 저전력, 저대역폭 네트워크를 통한 통신에 특히 적합합니다. 

gRPC의 인기는 최근 몇 년 동안 크게 증가했습니다. 

이는 더 높은 신뢰성과 확장성, 클라이언트와 서버 모두에 대한 언어 독립성을 통해 새로운 서비스를 더 빠르고 효율적으로 구축하기 쉽게 만들어주기 때문입니다.


gRPC의 이점에 대한 두드러진 예는 오픈 뱅킹으로, 오픈 소스 기술을 사용하여 API를 구축하고 제공하여 타사 개발자가 은행이나 다른 금융 기관의 고객에게 추가 서비스를 제공할 수 있도록 합니다. 

오픈 뱅킹의 전체 기반은 금융 정보를 보다 효과적이고 효율적으로 제공한다는 이상에 기반을 두고 있습니다. 


gRPC는 프로토콜 버퍼의 컴팩트한 형식과 HTTP/2의 멀티플렉싱으로 인해 주어진 페이로드의 전송이 REST API보다 훨씬 빠르기 때문에 이 목표를 달성하는 데 도움이 됩니다. 

데이터를 수신할 때는 약 7배, 데이터를 전송할 때는 10배 더 빠릅니다. 

결과적으로 금융 기관은 서비스 간 통신에 gRPC를 채택하여 서비스를 보다 빠르게 제공하고 효율성, 안정성 및 규모를 높이고 있습니다.


gRPC의 속도가 큰 이점이 되는 구체적인 사용 사례 중 하나는 고객 온보딩 프로세스로, 

오픈 뱅킹에서의 성공에 가장 중요합니다. 

다른 API 프레임워크를 사용하면 새 계좌를 만드는 것이 금융 기관과 고객 모두에게 번거롭고 시간이 많이 걸릴 수 있습니다. 

gRPC를 사용하면 빠른 데이터 전송으로 고객이 몇 분 안에 새 계좌를 만들 수 있습니다. 

이를 통해 고객 만족도가 크게 향상되고 금융 기관의 비용이 크게 감소합니다.

gRPC 보안


gRPC 표준과 프로토콜 버퍼 형식은 오픈 소스 라이브러리로 구현되어 있습니다. 

프로토콜 버퍼는 사이버 공격에 대해 다른 데이터 표현 방식보다 더 안전하다고 여겨지는데, 이는 라이브러리 파서가 잘못된 요청을 거부하고 라이브러리의 동작을 더 세밀하게 검사하기 때문입니다.

하지만 gRPC에 대한 공격의 가능성은 여전히 존재합니다. 예를 들어, 파서는 다음과 같은 허점을 가지고 있습니다:

  • stream 키워드 없이 메시지 스트림을 허용: 이를 통해 스트림 방식의 메시지가 전송될 수 있습니다.
  • 메시지 내에서 반복 가능한 필드가 선언되지 않더라도 여러 번의 필드를 허용: 이는 의도치 않은 데이터 중복을 초래할 수 있습니다.
  • 맵 필드에서 반복 키를 확인하지 않음: 마지막 발생만 고려되어 이전 키가 무시됩니다.
  • oneOf 복합 유형을 체크하지 않음: 여러 필드가 동시에 존재하는 것을 허용합니다.

공격자는 이러한 gRPC 프로토콜의 허점을 악용하여 애플리케이션을 위협할 수 있습니다. 

또한, 프로토콜 버퍼는 메시지 정의에 명시되지 않은 필드를 생성할 수 있도록 허용합니다. 

이는 설계의 확장성을 보장하여 향후 메시지의 확장 버전과의 호환성을 가능하게 하지만, 동시에 공격자가 애플리케이션에서 명시적으로 허용되지 않은 필드를 요청에 포함시킬 수 있는 밀반입 공격에 취약하게 만들 수 있습니다.



NGINX App Protect는 gRPC API를 보호합니다.

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 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요



전문가에게 상담받기




프로필 이미지
관리자
2024-09-13
조회 38


최근 몇 년 동안 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 파이프라인에 어떻게 통합될 수 있는지를 설명하겠습니다.

API는 직원과 파트너 모두에게 서비스를 제공합니다.


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. 분산형 컨테이너화 환경에서 일관된 보안 유지

다양한 파트너와 협력하여 보안 솔루션이 분산형 컨테이너화 환경을 포함한 

모든 환경에서 일관되고 중앙 집중화된 방식으로 제공되도록 하며, 

셀프 서비스 기능을 통해 사용이 용이하도록 합니다. 

이는 보안 솔루션이 다양한 환경에서 일관되게 적용되고 관리될 수 있도록 합니다.

"코드로서의 보안"은 새로운 소프트웨어의 모든 측면에 보안을 내장한다는 의미입니다. 

즉, 마지막에 보안을 추가하는 것이 아닙니다."

최신 애플리케이션 인프라를 위한 고급 API 보안

F5는 앱 보안을 적응 가능하고 확장 가능하며 신뢰할 수 있게 만드는 코드형 보안 접근 방식의 주요 지지자이며, 

NGINX App Protect는 이를 가능하게 하는 데 중요한 역할을 합니다. 

NGINX App Protect는 API 보안을 시장을 선도하는 

고급 웹 애플리케이션 방화벽(Advanced WAF) 및 봇 보호의 기본 기능과 결합하여 DevOps를 지원합니다.

  • 보안 팀의 승인에 따라 중단 없는 보안 제어를 자동화 및 CI/CD 프로세스에 통합합니다.
  • 컨테이너 및 마이크로서비스와 같은 분산 환경에서 앱 보안 제어를 배포하고 관리합니다.
  • 릴리스 속도나 애플리케이션 성능에 부정적인 영향을 미치지 않고 비용 효율적인 보안 제어를 구현합니다.

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 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요


전문가에게 상담받기



프로필 이미지
관리자
2024-08-16
조회 24


이제 "DevSecOps"라는 개념은 현대 소프트웨어 개발에 종사하는 거의 모든 사람에게 친숙해졌으며, 

애플리케이션 보안을 근본적으로 강화하고 DevOps와 보안 팀 간의 마찰을 완화하겠다는 약속을 담고 있습니다 .

DevSecOps 모델에서 보안은 왼쪽으로 이동하여 DevOps 개발 및 배포 프로세스에 직접 통합됩니다. 

특히 보안은 CI/CD(Continuous Integration/Continuous Deployment) 파이프라인의 
모든 단계에 내장되어 보안 결함을 조기에 식별하는 데 도움이 됩니다. 

기존 보안 모델과 달리 DevSecOps는 보안을 개발의 핵심에 두고, 문제의 근원에 더 가까운 문제를 식별하여 비용이 많이 들고 
시간이 많이 걸리는 수정을 줄이고 취약성이 프로덕션에 도달하는 것을 방지하는 데 도움이 됩니다.

하지만 DevSecOps에 대한 추진에도 불구하고 보안팀은 여전히 DevOps의 속도에 뒤처져 있는 듯합니다. 
snyk의 DevSecOps Insights 2020 보고서에 따르면, 
개발자의 48%는 여전히 보안이 소프트웨어를 신속하게 제공하는 능력에 큰 제약이라고 생각합니다.

애플리케이션 보안이 여전히 너무 느린 이유는 무엇일까?


대부분 기업은 보안 태세가 어디에 있어야 하는지 알고 있지만, 의도와 현실은 매우 다른 두 가지입니다. 

Contrast Security의 2020년 DevSecOps 현황 보고서에 따르면, 조직의 99% 이상이

프로덕션에서 평균적인 애플리케이션에 최소 4개의 취약점이 있다는 것을 인정해야 하는 반면, 

거의 80%가 개발 중인 애플리케이션에서 20개 이상의 취약점을 보고합니다.

 

따라서 GitLab의 2021년 글로벌 DevSecOps 설문 조사에서 설문 조사에 참여한 보안 팀의 70% 가 보안을 left-shift 하고 
그 어느 때보다 개발자와 긴밀하게 협력하고 있다고 말했지만, 상당한 보안 격차가 여전히 남아 있다는 것은 분명합니다.

NGINX 고객과의 대화를 통해 보안 팀의 DevOps 관행 도입을 지속적으로 늦추거나 방해하는 세 가지 광범위한 과제를 발견했습니다.

 1. 끊임없이 변화하는 분산된 경계 
20년 전과 달리, 보안 팀은 이제 단일하고 쉽게 보안할 수 있는 경계를 방어하는 일에만 집중하지 않습니다. 대신, DevOps 팀이 자유롭게 선택한 환경, 플랫폼, 도구에서 개발 및 배포된 애플리케이션을 보호해야 합니다. DevOps 실천은 혁신에 좋지만, API를 통해 상호 통신하는 다양한 서비스, 엔드포인트, 디바이스를 보호해야 하는 보안 전문가들에게는 부담이 됩니다. GitLab 설문조사 응답자의 절반만이 마이크로서비스와 컨테이너와 같은 현대 개발 전략을 사용해 생성된 애플리케이션을 모니터링하고 보호할 프로세스를 갖추고 있다고 말했습니다.


 2. CI/CD 파이프라인에 보안 정책을 자동화하고 내장할 수 없음
여러 팀 간의 변환은 같은 속도로 진행되지 않으며 보안 팀에서 사용할 수 있는 대부분의 레거시 도구는 Shifted-Left(조기도입) 환경에 맞게 설계되지 않았습니다. 결과적으로 보안 팀은 자동화 및 최신 인프라에 적합하지 않은 도구를 파이프라인에 적응하고 통합해야 합니다. 더 나쁜 것은 이러한 도구에 셀프 서비스 기능이 없기 때문에 개발자와 DevOps 엔지니어는 보안이 정책 및 프로세스에 대한 수동 감사를 마칠 때까지 진행을 기다려야 합니다.

 3. 중앙 집중화된 가시성과 보안 통찰력을 얻는 것이 어려움
대부분의 엔터프라이즈 앱은 분산되어 있을 뿐만 아니라 소유권 영역도 분산되어 있으며, 각각 다른 도구를 사용합니다. 이로 인해 조직 내 보안 포스처에 대한 통합된 가시성을 얻는 것이 엄청나게 고통스럽습니다. 보안 팀은 문제의 근본 원인을 파헤치는 대신 종종 다른 곳의 데이터를 통합하고 상관 관계를 파악하는 데 시간을 낭비합니다.

물론 대부분 기업이 단지 몇 개의 앱 때문에 이러한 장애물을 극복하는 것은 아닙니다. 여러 팀에 분산된 수백 개의 제품과 서비스를 다루며 자체 기술 스택, 툴체인, 프로세스를 실행하고 있으며, 이러한 모든 것에는 취약점으로 인해 공격에 취약성이 생기지 않도록 보장하기 위한 감사와 검사가 필요합니다.

Enterprise Teams Turning to Platform Ops


그렇다면 애플리케이션 보안팀의 민첩성을 높이는 동시에 개발자가 빠르고 안전하게 계속 움직일 수 있도록 지원하려면 어떻게 해야 할까요?

엄연한 사실은 위에서 논의한 과제를 해결할 방법을 찾지 못한다면 관행과 프로세스를 발전시킬 수 없다는 것입니다. 

더 빠르게 반복하는 것이 모든 사람에게 필요한 승리처럼 느껴질 수 있지만 

DevOps를 최대한 확장하는 유일한 방법은 전체 소프트웨어 개발 라이프 사이클에서 보안을 가능한 한 마찰 없이 적응 가능하게 만드는 것입니다.


점점 더 많은 조직이 Gartner의 리드를 따라 Platform Ops  라고 부르는 접근 방식을 채택하고 있습니다. 

핵심 개념은 회사 내부 팀의 요구 사항에 맞게 구축된 플랫폼을 통해 DevOps 기능을 제공하는 것입니다. 

내부 플랫폼을 사용하면 중복 작업에 시간을 낭비할 가능성이 줄어들 뿐만 아니라 


여러 제품 팀이 속도가 느려지지 않고 지속적이고 효과적으로 협업할 수 있습니다.

Platform Ops 모델에 따라 보안 팀은 개발 팀에 셀프 서비스, 소비형 정책을 제공합니다. 

또한 보안 도구는 애플리케이션 제공 프로세스에 완전히 통합됩니다. 


이런 방식으로 개발자는 지식이 풍부한 보안 전문가가 정한 모범 사례, 거버넌스 및 액세스 요구 사항을 준수하면서도 더 빠르게 배포할 수 있습니다.

애플리케이션 보안 팀의 큰 승리는 Platform Ops가 개발자가 보안을 더 이상 속도를 늦추는 방해물로 경험하지 않고, 

오히려 이미 사용하는 프로세스와 도구의 통합된 부분으로 경험하는 환경을 만든다는 것입니다. 

이는 앱 제공팀이 기업 전체에 더 나은 보안을 보장하는 패턴을 채택하도록 동기를 부여합니다.


NGINX가 어떻게 도움이 되는가 


NGINX에서는 웹 애플리케이션 방화벽(WAF)과 같은 도구를 제공하는 것의 중요성을 인식합니다. 

이 도구는 개발 프로세스의 어느 곳에서나 보안을 제공하고 CI/CD 파이프라인과 완벽하게 통합할 수 있도록 쉽게 왼쪽으로 이동할 수 있습니다. 

CPU를 독점하거나 성능을 저하시키지 않는 가벼운 솔루션도 중요합니다.

또한 보안이 관문이 아닌 가드레일일 때 개발 및 DevOps 팀이 훨씬 더 행복하다는 것을 보았습니다. 

보안이 공유 셀프 서비스 플랫폼에서 강력하고 일관된 제어 및 정책을 제공할 때 

개발 및 보안 팀이 최소한의 상호 작용 및 방해로 지침에 맞춰 조정하기가 더 쉬워집니다.


NGINX Ingress Controller와 NGINX App Protect WAF를 사용한 Kubernetes 생태계 다이어그램  

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 App Protect WAF는 이제 API 게이트웨이와 함께 배치되어 분산 환경에 대한 API 트래픽 관리 및 보안을 제공할 수 있습니다. 데이터 플레인(API 게이트웨이와 이제 NGINX App Protect WAF로 구성됨)이 제어 플레인에 대한 런타임 종속성이 없는 NGINX의 분리된 아키텍처를 통해 NGINX는 온프레미스 또는 퍼블릭, 프라이빗 또는 하이브리드 클라우드에서 호스팅되는 API에 대해 동급 최고의 고성능 및 보안을 제공합니다.
    • API 관리 모듈용 NGINX Controller App Security 애드온 은 베어메탈, VM, 컨테이너, 클라우드 환경 등 어디에나 배포된 NGINX API 게이트웨이와 강력한 보안을 원활하게 통합합니다. 이 애드온은 바로 사용할 수 있으며, OWASP API Security Top 10 취약성과 SQL 주입, 원격 명령 실행(RCE)과 같은 기타 취약성으로부터 보호합니다. 허용된 파일 유형과 응답 상태 코드를 검증하고 잘못된 JSON, XML, 쿠키를 확인합니다. 또한 이 애드온은 공격을 가리는 데 사용되는 회피 기술을 감지하고 HTTP RFC를 준수합니다.


위 내용과 같이 NGINX Plus / NGINX App Protect 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요



전문가에게 상담받기

프로필 이미지
관리자
2024-08-16
조회 37


사용자 경험이 전부입니다. 소비자와 고객이 사용하지 않는다면 앱과 웹사이트를 가질 이유가 없습니다. 
따라서 특히 사용자가 지연, 다운타임, 오류에 덜 관대해질 때 긍정적이고 일관된 사용자 경험을 보장하는 것이 중요합니다.
사용자가 앱이나 웹사이트에서 부정적인 경험을 하면 평생 고객을 잃을 수 있습니다. 
Salesforce 설문 조사에서 소비자의 61%가 단 한 번의 나쁜 경험 후 경쟁사로 전환했다고 보고했습니다. 
나쁜 경험을 반복하면 이탈은 불가피합니다. 온라인에서 선택할 수 있는 것이 너무 많으면 브랜드 충성도는 그다지 중요하지 않습니다.
소비자 불만족의 주요 원인 중 하나는 다운타임이며, 서비스 거부(DoS) 공격은 지속적인 다운타임의 주요 원인입니다
애플리케이션 설계의 변화로 인해 새로운 위협 벡터가 등장했고 공격자는 20년 이상 사용되어 온 DoS 공격을 현대 아키텍처를 악용하도록 조정했습니다. 

2020년 1월과 2021년 3월 사이에 애플리케이션 계층(7계층)의 DoS 공격이 급격히 증가하여 모든 DDoS 사고의 16%를 차지했습니다. 
실제로 F5 보안 사고 대응팀에 대한 요청의 절반은 애플리케이션 계층 DoS 공격에 대한 도움 요청입니다.

중앙 집중식 보안 완화책은 네트워크 계층(4계층)의 볼륨형 DoS 공격에 효과적일 수 있지만, 애플리케이션 계층 DoS 공격은 보다 집중화되어 있기 때문에 
API와 마이크로서비스로 구성되고 클라우드와 같은 보다 유연한 인프라에서 실행되는 점점 더 분산되는 최신 애플리케이션을 보호하기 위한 특수한 방어책이 필요합니다.

현대의 서비스 거부(DoS) 공격: 기본 보호만으로는 충분하지 않은 이유

DoS 공격의 소스가 분산되어 있어도(DDoS 공격이 됨) 네트워크 계층의 기본 볼륨 공격은 일반적으로 단일 장치나 서비스를 대상으로 하며, 
기존 보호 도구도 마찬가지로 모놀리식이고 중앙 집중화되어 있습니다. 
이러한 도구는 여전히 애플리케이션 보안 환경에서 자리를 잡고 있지만 충분하지는 않습니다. 

오늘날 클라우드 기반 DDoS 보호 서비스는 업계 표준으로 자리잡고 있지만,
그러나 여전히 이러한 서비스는 애플리케이션이 더 이상 모놀리식 단일 서비스가 아니라 
보호가 필요한 많은 통합 지점을 가진 복잡한 구조로 변모한 현실을 해결하지 못합니다.

디지털 변환과 API, 마이크로서비스, 클라우드 기반 통합으로의 대규모 아키텍처 전환이 이루어지기 전에 
기본 웹 애플리케이션 방화벽(WAF)은 취약성 악용과 DoS 공격을 크게 완화할 수 있었습니다. 
예를 들어 클라이언트 측에서 플러드로 나타나는 볼륨 공격의 경우 트래픽이 중앙 집중화되어 있기 때문에 기본 WAF와 기존 DoS 도구가 효과적입니다. 
클라우드 스크러빙 서비스는 트래픽이 유입 파이프에 들어가기 전에 공격을 완화하거나 애플리케이션 스택 앞에 보호를 배치할 수 있습니다. 

기본 WAF는 여전히 속도 제한, 거부 목록, 봇 시그니처를 통해 기존 공격으로부터 보호하지만 위협 환경은 이를 넘어섰습니다.
간단히 말해, 상황이 바뀌었고 기본 WAF와 기존 DoS 보호는 최신 애플리케이션 아키텍처에서는 효과적이지 않습니다.
현대의 DoS 공격은 레이어 7에서 발생하며, 암호화된 채널에서 숨겨져 있고 애플리케이션 로직을 목표로 하기 때문에 탐지하기가 훨씬 어렵습니다. 
따라서 클라이언트 행동과 서버 스트레스라는 두 가지 주요 지표를 측정할 수 있는 추가적인 보호 계층이 필요합니다. 
이 문제를 해결하기 위해 최근 NGINX App Protect Denial of Service 모듈을 출시했습니다. 
WAF와 기존 DoS 보호가 이미 있는 경우 DoS 모듈이 필요한지 궁금할 수 있습니다. 
실제로 필요합니다. 이유를 알아보려면 계속 읽어보세요.

현대의 아키텍처에는 현대적인 보호가 필요하다

암호화는 어디에나 있으며, 기존의 DoS 보호는 대규모 복호화를 위해 설계되지 않았습니다. 
모놀리식 애플리케이션 시대에는 암호화가 그렇게 널리 퍼지지 않았고, 
공격은 대부분 클라이언트 측만 살펴보면 감지할 수 있었기 때문에 
중앙 집중식 DoS 완화가 합리적이었습니다.

오늘날 거의 모든 트래픽이 암호화되어 있으므로 유입 트래픽에만 초점을 맞춘 상태 없는 DoS 완화는 거의 효과가 없습니다. 
특히 공격이 단일 대상 요청을 사용하여 애플리케이션 스트레스를 가하는 경우 더욱 그렇습니다.
애플리케이션은 이제 마이크로서비스와 같은 분산 아키텍처에 맞게 설계되고 최적화되었으며, 
사용자 개인 정보 보호에 대한 강조(및 후속 법률)와 암호화의 발전으로 인해 엔드투엔드 암호화가 일반화되고 있습니다. 

최신 아키텍처는 API에 크게 의존하며, API 간 통신(동서 트래픽이라고도 함)은 중앙 집중식 보안 제어를 통과하지 못할 수도 있습니다.
효과적인 애플리케이션 수준 DoS 보호에는 클라이언트 측 이상 및 서버 측 스트레스를 감지하는 기능을 포함하여 
엔드투엔드 가시성과 컨텍스트가 필요합니다. 고급 레이어 7 DoS 공격은 종종 합법적인 트래픽으로 
위장되므로 속도 제한, 거부 목록, 서명 및 프로토콜 준수와 같은 기본 완화책으로는 더 이상 충분하지 않습니다.

정교한 레이어 7 공격은 표면적으로는 합법적인 트래픽처럼 보이고, 기본 WAF는 이를 탐지하는 데 필요한 행동 분석 기능이 부족합니다. 
NGINX App Protect DoS는 클라이언트 이상과 서버 스트레스를 모두 살펴보도록 특별히 설계되었으며, 
동적으로 공격을 식별하고 완화하며 완화 효과를 측정할 수 있습니다. 
이는 이미 과중화된 업무에 시달리고 있는 보안 팀의 추가적인 주의를 요구하지 않습니다. 

기본 WAF 방어와 기존 DDoS 완화에만 의존한다면 레이어 7 공격에 대한 적절한 가시성과 맥락을 확보할 수 없으며, 

그 결과는 지연, 다운타임, 수익 포기, 브랜드 손상 등 막대한 피해를 초래 할 수 있습니다. 

행동 분석을 통해 클라이언트 이상 징후와 서비스 상태를 지속적으로 분석하여 제로데이 DoS 공격을 탐지할 수 있습니다. 


사이트 동작을 자세히 살펴보면 다음과 같은 질문에 답할 수 있습니다. 

기준 트래픽 패턴과 비교할 때 비정상적인 것이 있습니까? 

브라우저가 포함해야 할 정보를 누락한 요청이 있습니까? 

요청에 복잡한 데이터베이스 쿼리가 포함되어 높은 CPU 사용률을 유발하고 있습니까?

NGINX App Protect DoS는 일반적인 성능과 동작에 대한 정보를 구축하여 

기존 방어 수단을 회피하고 애플리케이션에 스트레스를 가하는 레이어 7 공격에 집중할 수 있습니다.

NGINX App Protect WAF 및 DoS가 차단하는 8가지 공격 유형을 나타내는 다이어그램

여러 모듈로 완화하기

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 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요



전문가에게 상담하기

프로필 이미지
관리자
2024-08-16
조회 58


편집자  - 이 게시물은 10부작 시리즈의 일부입니다.

  1. 프로덕션 등급 Kubernetes로 복잡성 감소
  2. 고급 트래픽 관리를 사용하여 Kubernetes의 복원력을 개선하는 방법
  3. Kubernetes에서 가시성을 개선하는 방법
  4. 트래픽 관리 도구를 사용하여 Kubernetes를 보호하는 6가지 방법
  5. Ingress Controller 선택 가이드, 1부: 요구 사항 식별
  6. Ingress Controller 선택 가이드, 2부: 위험 및 미래 대비(이 게시물)
  7. Ingress Controller 선택 가이드, 3부: 오픈소스 대 기본 대 상업용
  8. Ingress Controller 선택 가이드, 4부: NGINX Ingress 컨트롤러 옵션
  9. 서비스 메시를 선택하는 방법
  10. 동적 Kubernetes 클라우드 환경에서 NGINX Ingress 컨트롤러 성능 테스트

또한 전체 블로그 세트를 무료 전자책인 ' 테스트에서 프로덕션까지 Kubernetes 활용' 으로 다운로드할 수 있습니다 .

전체 블로그 모음을 '테스트에서 프로덕션으로: Kubernetes 활용하기'라는 무료 전자책으로도 다운로드할 수 있습니다.

Ingress 컨트롤러 선택 가이드의 첫 번째 부분에서는 요구 사항을 식별하는 방법에 대해 설명했습니다. 하지만 아직 제품을 테스트할 시점은 아닙니다! 
이번 포스트에서는 잘못된 Ingress 컨트롤러 선택이 릴리스 속도를 저하시킬 수 있으며, 심지어 고객을 잃게 할 수도 있는 위험성을 설명합니다. 
Ingress 컨트롤러는 다른 도구와 마찬가지로 위험을 초래하고 향후 확장성에 영향을 미칠 수 있습니다. 
이제 선택 과정에서 더 큰 피해를 줄 수 있는 옵션을 어떻게 제거할 수 있는지 살펴보겠습니다.

Ingress 컨트롤러 위험


쿠버네티스를 위한 트래픽 관리 도구를 도입할 때 고려해야 할 세 가지 구체적인 위험은 복잡성, 지연 시간, 보안입니다.
이러한 문제는 종종 서로 얽혀 있습니다. 이러한 문제들은 종종 서로 얽혀 있으며, 하나가 나타나면 다른 문제들도 발생할 가능성이 높습니다.
각 문제는 Ingress 컨트롤러에 의해 발생할 수 있으며, 그 위험이 감수할 만한 것인지 결정하는 것은 여러분의 조직에 달려 있습니다.
오늘날의 소비자는 변덕스럽기 때문에, 아무리 매력적인 기능을 갖추고 있더라도 디지털 경험이 좋지 않으면 받아들이기 어렵습니다.

복잡성 - 마이크로서비스 아키텍처의 목적을 저해하는가?


최고의 쿠버네티스 도구는 마이크로서비스 아키텍처의 목표를 충족하는 도구입니다. 가볍고 디자인이 단순합니다. 
이러한 원칙을 고수하는 매우 기능이 풍부한 Ingress 컨트롤러를 개발하는 것은 가능하지만, 항상 그런 것은 아닙니다. 
일부 디자이너는 너무 많은 기능을 포함하거나 복잡한 스크립팅을 사용하여 
기본 엔진에 기본이 아닌 기능을 추가하여 불필요하게 복잡한 Ingress 컨트롤러를 만듭니다.
그리고 그게 왜 중요할까요? Kubernetes에서 지나치게 복잡한 도구는 앱 성능에 부정적인 영향을 미치고 배포를 수평적으로 확장하는 능력을 제한할 수 있습니다. 
일반적으로 지나치게 복잡한 Ingress 컨트롤러는 크기로 알아볼 수 있습니다. 풋프린트가 클수록 도구가 더 복잡합니다.

지연 시간 - Ingress 컨트롤러가 앱 속도를 저하시키나요?


Ingress 컨트롤러는 리소스 사용, 오류 및 시간 초과로 인해 지연 시간을 추가할 수 있습니다.
정적 및 동적 배포에서 추가된 지연 시간을 살펴보고 내부 요구 사항에 따라 허용할 수 없는 지연 시간을 도입하는 옵션을 제거하세요.
재구성이 앱 속도에 어떤 영향을 미칠 수 있는지에 대한 자세한 내용은 블로그에서 
동적 Kubernetes 클라우드 환경에서 NGINX Ingress 컨트롤러 성능 테스트를 참조하세요.

보안 – Ingress 컨트롤러가 해커에게 문을 열어줄까?


오늘날의 인터넷에는 일반적인 취약점 및 노출(CVEs)이 널리 퍼져 있으며, 
Ingress 컨트롤러 제공업체가 CVE 패치를 제공하는 데 
걸리는 시간이 안전과 침해를 가르는 중요한 차이가 될 수 있습니다. 
조직의 리스크 수용 능력에 따라 패치 제공에 며칠(혹은 최대 몇 주) 이상 걸리는 솔루션은 제외하는 것이 좋습니다.
CVEs를 넘어선, 일부 Ingress 컨트롤러는 또 다른 잠재적 취약점을 노출시킬 수 있습니다. 
다음과 같은 시나리오를 고려해 보세요: 온라인 소매업체에서 근무하며 오픈 소스 Ingress 컨트롤러의 구성 문제를 해결하려고 합니다. 

상업적 지원을 받을 수 없으므로 Stack Overflow와 같은 포럼에 문제를 게시합니다. 
누군가가 도움을 제공하고 Ingress 컨트롤러 및 기타 Kubernetes 구성 요소의 문제를 확인하고자 합니다. 
문제를 신속히 해결하고 싶어하는 마음에 파일을 공유합니다.


“착한 사마리안”이 문제를 해결해 주지만, 6개월 후에 보니 고객 기록에서 신용 카드 번호가 도난당한 것을 발견하게 됩니다. 
공유한 파일에 해커가 앱에 침투하는 데 사용된 정보가 포함되어 있었던 것입니다. 
이 시나리오는 상업적 지원을 선택하는 주요 이유 중 하나를 보여줍니다: 그것은 기밀성을 보장해줍니다.

OpenResty 기반 Ingress 컨트롤러에 대한 참고 사항


OpenResty는 NGINX 오픈 소스에 구축된 웹 플랫폼으로, LuaJIT, Lua 스크립트 및 타사 NGINX 모듈을 통합하여 NGINX 오픈 소스의 기능을 확장합니다. 
차례로, OpenResty에 구축된 여러 Ingress 컨트롤러가 있으며, 이는 NGINX 오픈 소스 및 NGINX Plus에 기반한 Ingress 컨트롤러와 비교할 때 잠재적으로 두 가지 위험을 추가할 수 있다고 생각합니다.


  • 시간 초과  - 언급했듯이 OpenResty는 Lua 스크립팅을 사용하여 상용 NGINX Plus 기반 Ingress Controller와 같은 고급 기능을 구현합니다. 이러한 기능 중 하나는 동적 재구성으로, 가용성을 감소시키는 NGINX 오픈 소스 요구 사항을 제거합니다. 즉, 서비스 엔드포인트가 변경될 때 NGINX 구성을 다시 로드해야 합니다. OpenResty로 동적 재구성을 수행하기 위해 Lua 핸들러는 요청을 라우팅할 업스트림 서비스를 선택하여 NGINX 구성을 다시 로드할 필요성을 제거합니다.
    그러나 Lua는 백엔드에 대한 변경 사항을 지속적으로 확인해야 하므로 리소스가 소모됩니다. 들어오는 요청을 처리하는 데 시간이 더 오래 걸리므로 일부 요청이 중단되고 이로 인해 시간 초과 가능성이 커집니다. 더 많은 사용자와 서비스로 확장할수록 초당 들어오는 요청 수와 Lua가 처리할 수 있는 수 사이의 격차가 기하급수적으로 커집니다. 그 결과 지연, 복잡성 및 더 높은 비용이 발생합니다.
    동적 Kubernetes 클라우드 환경에서 NGINX Ingress 컨트롤러의 성능 테스트를 읽고 Lua가 얼마나 많은 지연 시간을 추가할 수 있는지 확인하세요.

  • CVE 패치 지연  – NGINX의 Ingress 컨트롤러와 비교했을 때, CVE에 대한 패치는 NGINX 오픈 소스를 기반으로 하는 OpenResty와 같은 도구를 기반으로 하는 Ingress 컨트롤러에서 나타나는 데 필연적으로 더 오래 걸립니다. Mitigating Security Vulnerabilities Quickly and Easily with NGINX Plus 에서 자세히 설명했듯이 , NGINX에서 CVE가 발견되면 공급업체인 우리는 일반적으로 CVE가 공개되기 전에 통보를 받습니다. 이를 통해 CVE가 발표되는 즉시 NGINX 오픈 소스 및 NGINX Plus에 대한 패치를 릴리스할 수 있습니다.
    NGINX 오픈 소스 기반 기술은 그 시점까지 CVE에 대해 알지 못할 수 있으며, 우리의 경험에 따르면 OpenResty 패치는 우리 패치보다 상당히 뒤떨어집니다. 최근 사례에서는 4개월이 걸렸습니다 . OpenResty 기반 Ingress 컨트롤러용 패치는 불가피하게 더 많은 시간이 걸리므로 악의적인 행위자가 취약성을 악용할 충분한 기회를 제공합니다.

Ingress Controller 미래에 대비하세요


쿠버네티스를 막 시작했더라도 언젠가는 프로덕션에 투입하고 싶어할 가능성이 큽니다. 
시간이 지남에 따라 요구 사항이 증가할 가능성이 있는 네 가지 주요 영역은 인프라, 보안, 지원 및 멀티 테넌시입니다.

인프라 – 하이브리드 또는 멀티 클라우드 환경에서 Kubernetes를 사용할 것인가?


조직이 단일 환경에 완전히 영구적으로 전념하는 경우는 드뭅니다. 더 일반적으로 조직은 온프레미스와 클라우드를 혼합하여 사용하는데, 
여기에는 프라이빗, 퍼블릭, 하이브리드 클라우드, 멀티 클라우드가 포함될 수 있습니다.
 (이러한 환경이 어떻게 다른지 자세히 알아보려면 멀티 클라우드와 하이브리드 클라우드의 차이점은 무엇인가요?를 읽어보세요.)

이 시리즈의 1부에서 언급했듯이, 각 환경에 기본으로 제공되는 도구를 선택하는 유혹이 있지만, 
기본 Ingress 컨트롤러에 특정된 문제들이 있습니다. 
이 문제의 모든 단점은 시리즈의 3부에서 다룰 예정이지만, 미래 대비 측면에서 가장 중요한 문제는 벤더 종속성입니다. 
클라우드 특정 Ingress 컨트롤러를 모든 환경에서 사용할 수 없기 때문입니다. 기본 클라우드 특정 도구를 사용하면 확장성이 제한됩니다. 
결과적으로 두 가지 비효율적인 대안만 남게 됩니다:  
  1. 기존 클라우드를 모든 요구 사항에 맞게 조정하려고 시도하기
  2. 모든 새로운 환경에서 Ingress 컨트롤러의 구성을 새로 작성하기 – 로드 밸런싱뿐만 아니라 보안까지 포함됩니다.

첫 번째 대안은 비즈니스 이유로 종종 실현 불가능하며, 
두 번째 대안은 도구 분산, 새로운 보안 취약점 발생, 직원들이 급격히 학습해야 하는 곤란을 초래합니다. 
세 번째이자 가장 효율적인 대안은 인프라에 구애 받지 않는 Ingress 컨트롤러를 처음부터 선택하여
모든 환경에서 동일한 도구를 사용하는 것입니다.

인프라와 관련하여 고려해야 할 또 다른 요소가 있습니다.인증입니다.


예를 들어, Red Hat OpenShift Container Platform (OCP) 사용자는 Red Hat Marketplace에서 OCP에 대해 인증된 오퍼레이터를 제공받는 것을 알고 있을 것입니다. 여기에는 NGINX Ingress Operator도 포함됩니다. Red Hat의 인증 기준은 도구가 배포와 호환됨을 보장하며, Red Hat과 공급업체 간의 공동 지원도 포함될 수 있습니다. 
많은 조직이 보안과 안정성 이유로 인증된 도구를 사용하는 요구 사항을 가지고 있으므로, 현재 테스트 중이라도 회사의 프로덕션 환경 요구 사항을 염두에 두는 것이 중요합니다. Red Hat의 인증 표준은 도구가 배포와 함께 작동하고 Red Hat과 공급 업체의 공동 지원을 포함할 수도 있다는 것을 알고 안심할 수 있음을 의미합니다. 많은 조직에서 보안 및 안정성을 이유로 인증된 도구를 사용해야 하므로 지금은 테스트 중이더라도 프로덕션 환경에 대한 회사의 요구 사항을 염두에 두는 것이 좋습니다.

보안 –  Kubernetes를 내부에서 어떻게 보호할 것인가?


더 이상은 단순한 경계 보안만으로 앱과 고객을 안전하게 지킬 수 있는 시대는 지났습니다. 
Kubernetes 앱은 보안, 즉 인증 및 권한 부여가 앱에 가까이 위치할 때 가장 잘 보호됩니다. 
또한, 조직들이 점점 더 종단 간 암호화와 제로 트러스트 네트워크 모델을 Kubernetes 내에서 채택하고 있기 때문에, 
서비스 메쉬가 미래에 필요할 수 있습니다.

이 모든 것이 Ingress 컨트롤러와는 어떤 관계가 있을까요? 매우 밀접한 관계가 있습니다! 
Ingress 지점에서 보안을 중앙 집중화하는 것은 비용과 효율성 측면에서 매우 합리적입니다 (인증, 권한 부여, DoS 보호, 웹 애플리케이션 방화벽). 
대부분의 서비스 메쉬는 대부분의 Ingress 컨트롤러와 통합될 수 있지만, 통합 방식이 매우 중요합니다. 
보안 전략에 맞는 Ingress 컨트롤러를 선택하면 앱 개발 과정에서 큰 문제를 예방할 수 있습니다.

더 자세한 내용은 속도를 잃지 않으면서 클라우드 네이티브 앱을 안전하게 보호하기 Kubernetes에서 애플리케이션 서비스 배포하기, 2부를 
읽어 보시기 바랍니다. 여기서는 클라우드 네이티브 앱 제공의 위험성과 보안 도구의 최적 위치에 대한 요소를 더 많이 다루고 있습니다.

지원 – “혼자서” 얼마나 견딜 수 있나요?

팀이 Kubernetes를 실험할 때, 지원(커뮤니티 지원이나 회사 지원)은 종종 최우선 사항이 아닐 수 있습니다. 
이는 팀이 자체 솔루션과 우회 방법을 마련할 시간이 많다면 괜찮습니다. 
하지만 프로덕션 환경으로 이동할 때는 지속 가능하지 않습니다. 현재 지원이 필요하지 않더라도, 
미래에 지원을 추가할 수 있거나, 확장하면서 업그레이드 가능한 저렴한 지원 계층을 가진 Ingress 컨트롤러를 선택하는 것이 현명할 수 있습니다.

다중 테넌시 - 여러 팀과 앱이 컨테이너 환경을 안전하고 보안적으로 공유할 수 있는 방법은 무엇입니까?

처음에는 하나의 팀과 하나의 앱이 있었죠… 모든 이야기가 이렇게 시작되지 않나요? 그 이야기는 종종 하나의 팀이 Kubernetes 앱을 성공적으로 개발하고, 이를 통해 조직이 Kubernetes에서 더 많은 서비스를 운영하게 되는 것으로 이어집니다. 그리고 물론, 더 많은 서비스는 더 많은 팀과 더 많은 복잡성을 의미합니다.


최대의 효율성을 달성하기 위해 조직은 다중 테넌시를 채택하고, 비즈니스 프로세스에서 요구하는 액세스 및 격리를 지원하면서 운영자에게 필요한 안정성과 제어를 제공하는 Kubernetes 모델을 채택합니다. 일부 Ingress 컨트롤러는 여러 가지 기능과 개념을 통해 클러스터를 분할하는 데 도움을 줄 수 있습니다. 예를 들어, 여러 개의 Ingress, 클래스, 네임스페이스 및 역할 기반 액세스 제어(RBAC)를 지원하는 범위가 지정된 리소스가 그것입니다.

다음 단계: 옵션 좁히기


이제 요구 사항, 위험 허용 범위, 미래 보호에 대해 생각해 보았으니, Ingress 컨트롤러의 매우 광범위한 분야를 좁힐 준비가 되었습니다. 이 단계를 신속하게 처리하기 위해 분야를 범주 별로 나누는 것이 도움이 될 수 있습니다. 시리즈의 3부에서는 세 가지 다른 Ingress 컨트롤러 범주를 살펴보고 각 범주의 장단점을 분석할 것입니다.



위 내용과 같이 NGINX Ingress Controller 및 NGINX App Protect WAF, DoS 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요


전문가에게 상담하기





프로필 이미지
관리자
2024-08-16
조회 27


NGINX가 2년 전 F5와 함께한 이래로 고객에게 가장 큰 이점 중 하나는 F5의 업계를 선도하는 보안 전문 지식을 NGINX 제품에 통합한 것입니다.
F5 NGINX App Protect WAF 및 F5 NGINX Controller App Security는 F5 Advanced WAF, F5 Silverline WAF 및
기타 F5 보안 솔루션과 동일한 웹 애플리케이션 방화벽(WAF) 기술을 활용합니다.
각 제품은 특정 환경, 배포 시나리오 및 관리 사용 사례를 지원하기 위해 서로 다른 form-factor를 가지고 있지만, 고객은 잘 알려진 바대로 신뢰할 수 있는 보안을 강화한 엔진으로 가장 진보 된 웹 공격으로부터 그들을 보호할 수 있다는 확신을 가질 수 있습니다.


NGINX 및 F5 보안 솔루션은 F5의 업계 최고 WAF 기술을 활용합니다.공유 WAF 기술은 또한 F5 고객이 F5 Advanced WAF와 같은 제품을 사용하는 기존 환경에서 컨테이너화되고 클라우드 환경으로 마이그레이션할 때 보안 팀에서 이미 승인한 표준화 된 정책을 유지할 수 있다는 것을 의미합니다.
이러한 환경에서는 NGINX App Protect WAF가 더 적합합니다. 제품 간 WAF 정책의 이식성 덕분에 F5 및 NGINX 고객은 강력하고 일관되며 규정을 준수하는 보안 태세를 빠르고 쉽게 보장할 수 있습니다.
Application Delivery Module용 NGINX Controller App Security가 출시되었을 때, 최소한의 오탐지로 OWASP Top 10 및 기타 위협으로부터 보호하는 데 중점을 둔 기본 정책이 함께 제공되었습니다.
Application Delivery Module 버전 3.20용 Controller App Security를 사용하면 이제 사용자 지정 NGINX App Protect WAF 정책을 가져와 모든 관리형 배포에 배포할 수 있습니다. 이를 Bring Your Own NGINX App Protect WAF Policy(BYO App Protect Policy)라고 합니다.

자세히 알아보려면 계속 읽고 이 비디오 개요를 확인하세요.



앱 현대화 여정 전반에 걸쳐 일관된 WAF 정책 유지

기존 애플리케이션 제공 환경을 사용하는 많은 고객이 F5 Advanced WAF 또는 BIG-IP ASM을 사용하여 시작합니다.
앱 현대화 여정을 진행함에 따라, DevOps에 맞춘 WAF 서비스를 배포해야 하는 새로운 앱들에는 NGINX App Protect와 NGINX Controller App Security를 활용할 수 있습니다. .
NGINX App Protect WAF는 단독으로 OWASP Top Ten 및 기타 고급 위협에 대한 방어부터 단순화된 선언적 정책 정의에 이르기까지 다양한 기능으로 최신 앱을 보호합니다. NGINX App Protect WAF 인스턴스를 관리하기 위해 Controller App Security를 도입하면 다음과 같은 추가 이점이 있습니다.
보안팀은 개선된 기본 제공 가시성을 얻고 Dev 및 DevOps팀에 승인된 WAF 정책과 NGINX App Protect WAF 인스턴스의 셀프 서비스 프로비저닝 및 관리를 제공할 수 있습니다. 더 나은 점은 단일 Controller 인스턴스가 여러 팀을 지원할 수 있다는 것입니다.
개발 및 DevOps 팀은 이미 익숙한 Controller API와 GUI를 사용하여 데이터 플레인에서 정책을 시행하는 NGINX App Protect WAF 인스턴스의 정책이나 구성에 대한 심층적인 이해가 필요 없이 승인된 WAF 정책을 앱에 적용할 수 있습니다.

관리 평면에서 작동하는 NGINX Controller App Security Add-On과 데이터 평면에서 작동하는 NGINX App Protect WAF를 보여주는 토폴로지 다이어그램
Controller App Security는 NGINX App Protect WAF를 사용하여 데이터 플레인에서 정책을 시행합니다.

컨트롤러 앱 보안을 위한 F5 WAF 정책 준비

앱 현대화 여정을 진행하면서 모든 F5 및 NGINX WAF 구현에서 일관된 정책을 유지할 수 있도록 NGINX App Protect Policy Converter를 제공합니다. 우리는 NGINX App Protect Policy Converter를 제공합니다.
이 도구는 F5 Advanced WAF 정책(XML 형식)을 NGINX App Protect WAF 정책(JSON 형식)으로 변환합니다. 
변환된 정책은 다음 섹션에서 설명하는 대로 Controller App Security로 전달할 수 있습니다.
다음은 F5 Advanced WAF 정책을 NGINX App Protect WAF 정책으로 변환하는 단계와 지침에 대한 링크입니다.


F5 Advanced WAF 정책을 NGINX App Protect 정책으로 변환하는 단계를 보여주는 다이어그램


F5 Advanced WAF 정책을 NGINX App Protect 정책으로 변환NGINX App Protect Policy Converter용 Docker 이미지를 다운로드하고 설치합니다.
F5 Advanced WAF 정책을 내보냅니다(지침에서는 "BIG‑IP ASM 보안 정책"을 참조하지만 F5 Advanced WAF 정책에도 적용됩니다).
정책을 JSON 형식의 NGINX App Protect WAF 정책으로 변환합니다.

NGINX 앱 보호 WAF 정책을 컨트롤러 앱 보안으로 가져오기

Application Delivery Module의 버전 3.20용 Controller App Security를 사용하면 BYO App Protect 정책 프로세스를 사용하여 NGINX App Protect WAF 정책을 가져와 모든 관리형 NGINX App Protect 인스턴스에 배포할 수 있습니다. 
NGINX App Protect WAF 정책은 기본 정책이거나 이전 섹션에서 설명한 대로 F5 Advanced WAF에서 변환한 정책일 수 있습니다.
BYO 앱 보호 정책 프로세스는 보안 전략이라는 컨트롤러 객체를 사용합니다. 
보안 전략은 사용자 지정 NGINX 앱 보호 WAF 정책을 포함한 보안 관련 정책에 대한 논리적 컨테이너입니다. 
그런 다음 앱에서 보안 전략을 참조하여 앱에 연결된 WAF 정책을 적용합니다.
BYO 앱 보호 정책 프로세스에 대한 자세한 내용은 제품 설명서를 참조하세요.
선택한 인터페이스에 대한 다음 섹션의 지침을 참조하세요.

API 사용하기
GUI 사용

단계를 완료한 후, BYO 앱 보호 정책 프로세스를 사용하여 Controller 앱 보안에 가져온 WAF 정책 업데이트는 연관된 보안 전략을 참조하는 모든 앱 구성 요소에 자동으로 전파됩니다.
Application Delivery Module의 버전 3.20용 Controller App Security에서는 단일 파일에 정의된 WAF 정책만 지원됩니다. 외부 참조(여러 파일로 표현된 WAF 정책)를 사용하는 WAF 정책에 대한 지원은 향후 릴리스에서 계획되어 있습니다.

API 사용하기

Controller API를 사용하여 WAF 정책을 Controller App Security로 가져오려면 다음 단계를 수행하세요.

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
            }
        },
. . . 
}

GUI 사용

Controller GUI를 사용하여 Controller App Security에 WAF 정책을 가져와 적용하려면 다음 단계를 수행하세요.

보안 전략 만들기 페이지에서 보안 전략을 만드세요.


NGINX App Protect WAF 정책이 이미 Controller에서 사용 가능한 경우 정책 필드의 드롭 다운 메뉴에서 선택합니다.
아직 나열되지 않은 경우 + 새로 만들기를 클릭합니다. 

나타나는 보안 정책 만들기 팝업 창에서 JSON 형식의 NGINX App Protect WAF 정책이 포함된 파일을 업로드합니다.





WAF 정책을 적용할 앱의 앱 구성 요소 편집 페이지에서 연관된 보안 전략을 선택합니다.

NGINX 컨트롤러 내에서 정책 공유

BYO App Protect 정책 프로세스를 사용하여 Controller App Security에 정책을 가져온 후에는 다른 팀에서 관리하더라도 Controller에 정의된 모든 앱에서 공유할 수 있습니다. 
여러 Controller App Components(또는 URI와 같은 앱의 하위 구성 요소)가 동일한 정책을 참조하면 여러 앱과 API에서 보안 포스처를 표준화 하는 데 도움이 됩니다.

여러 앱이 동일한 BYO App Protect WAF 정책을 참조하는 방식을 보여주는 다이어그램
여러 앱이 동일한 정책을 참조할 수 있습니다.Controller는 WAF 정책의 관리 및 버전 관리를 중앙화합니다. 
정책의 새 버전을 게시하면 이를 참조하는 모든 Controller 앱 구성 요소에서 업데이트되어 운영이 극적으로 간소화됩니다.

요약


F5 WAF 기술 플랫폼은 앱 전체에서 표준화된 보안 포스처를 위해 동일한 WAF 보호 정책의 이식성과 재사용성을 가능하게 합니다.
이 설계 철학은 또한 F5 및 NGINX 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 를 활용하여 보안취약점 완화가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요