알림
뒤로
mobile background

NGINX DOCS


NGINX 전문가가 작성한 AppProtect WAF 문서를 확인해 보세요

NGINX App Protect WAF/DoS 에서 구현가능한 기술 / 사용사례 소개 16
검색
프로필 이미지
관리자
2024-11-13
조회 18



이미지는 unsplash.com의 John T. 에서 제공되었습니다.


API 호출을 인증하는 방법에는 X.509 클라이언트 인증서부터 HTTP 기본 인증까지 다양한 옵션이 존재합니다. 

그러나 최근 몇 년 간, OAuth 2.0 액세스 토큰이 사실상의 표준으로 자리잡았습니다.

이 액세스 토큰은 클라이언트에서 API 서버로 전달되는 인증 자격 증명으로, 일반적으로 HTTP 헤더를 통해 전송됩니다.

하지만 OAuth 2.0은 다양한 관련 표준들이 얽혀 있는 복잡한 시스템입니다. 

OAuth 2.0 인증 흐름을 발급, 제시, 검증하는 과정은 여러 표준에 의존하며, 

이 글을 작성하는 시점에서만 하더라도 8개의 OAuth 2.0 표준이 존재합니다. 


그 중 가장 대표적인 것이 바로 액세스 토큰입니다. 

하지만 OAuth 2.0 핵심 사양(RFC 6749)은 액세스 토큰의 형식을 명시하지 않기 때문에, 

실제로 사용되는 액세스 토큰 형식은 두 가지로 나눠집니다.

  • RFC 7519에 정의된 JSON 웹 토큰(JWT)
  • 인증된 클라이언트를 위한 고유 식별자에 불과한 불투명 토큰

인증된 클라이언트는 보호된 리소스에 접근하기 위해, 각 HTTP 요청에 액세스 토큰을 함께 전달합니다. 

액세스 토큰 검증은 발급한 신뢰할 수 있는 ID 공급자(IdP)를 통해 이루어지며, 

이 과정에서 토큰이 실제로 발급 되었고, 만료되지 않았는지를 확인해야 합니다.


JWT는 발급된 ID 공급자(IdP)에서 암호화 방식으로 서명되므로, "오프라인" 환경에서도 검증이 가능합니다. 

JWT는 일반적으로 만료 날짜도 포함되어 있어, 이를 통해 토큰의 유효성을 쉽게 확인할 수 있습니다. 

NGINX Plus의 auth_jwt 모듈은 바로 이 "오프라인" JWT 검증을 처리합니다.


반면, 불투명 토큰은 이를 발급한 IdP로 다시 보내어 검증을 받아야 합니다. 

이 방식은 IdP가 토큰을 취소할 수 있다는 장점이 있습니다. 

예를 들어, 글로벌 로그아웃 작업을 수행할 때, 사용자가 로그아웃을 해도 이전에 로그인한 세션을 취소할 수 있어 보안상 유리합니다. 


그러나 이 경우, JWT와 달리 IdP에서 실시간으로 검증을 해야 하므로 그에 따른 오버헤드가 발생할 수 있습니다.

이 블로그에서는 NGINX와 NGINX Plus가 OAuth 2.0 Relying Party로서 역할을 수행하는 방법을 다룹니다. 

여기서 Relying Party란, **ID 공급자(IdP)**로부터 액세스 토큰을 받아 검증하고, 검증된 요청만을 프록시하는 시스템을 의미합니다. 


이를 통해 NGINX가 어떻게 액세스 토큰 검증을 처리하며, 검증 프로세스가 통과된 요청만을 서버로 전달하는지 설명합니다.

또한, 검증 응답을 캐싱하여 사용자 경험을 개선하는 방법도 다룹니다. 

NGINX Plus에서는 R18 버전부터 JavaScript 모듈을 활용해 캐시를 관리하고, 

이 캐시를 NGINX Plus 인스턴스 클러스터에 분산시켜 성능을 최적화하는 방법을 소개합니다. 

이를 통해, 토큰 검증에 필요한 리소스를 절감하고, 높은 트래픽 환경에서도 효율적인 보안 처리가 가능합니다.

본 블로그의 내용은 NGINX Open Source와 NGINX Plus 모두에 적용되며, NGINX Plus에 대한 언급은 해당 제품에만 적용됩니다.

토큰 내성


액세스 토큰 검증을 위한 표준화된 방법은 바로 **토큰 내성(Token Introspection)**입니다. 

이 방법은 RFC 7662에 정의되어 있으며, 이제 많은 주요 **ID 공급자(IdP)**와 클라우드 공급업체에서 널리 지원되고 있습니다. 

토큰 내성은 Relying Party가 액세스 토큰을 IdP에 제출하여, 해당 토큰의 유효성 및 상태를 검증하는 JSON/REST 인터페이스를 정의합니다. 

이를 통해 IdP는 액세스 토큰에 대한 정보를 반환하며, 그 결과를 바탕으로 Relying Party가 적절한 액션을 취할 수 있습니다.

하지만, 어떤 토큰 형식을 사용하더라도 각 백엔드 서비스나 애플리케이션에서 직접 검증을 수행하는 것은 여러 가지 문제를 일으킬 수 있습니다. 

특히, 서비스마다 검증 로직이 달라지면 중복된 코드와 불필요한 처리가 많아집니다. 

또한, 다양한 오류 조건과 에지 케이스를 모두 고려해야 하기 때문에, 

각 서비스에서 검증을 독립적으로 처리하면 일관성 없는 구현과 예측할 수 없는 사용자 경험이 발생할 수 있습니다.

백엔드 서비스에서 고려해야 할 주요 오류 조건

  • 액세스 토큰이 없습니다
  • 매우 큰 액세스 토큰
  • 액세스 토큰에 잘못된 문자 또는 예상치 못한 문자가 있습니다.
  • 여러 액세스 토큰이 제시됨
  • 백엔드 서비스 전반의 시계 오차
토큰 검증을 수행하는 백엔드 애플리케이션

NGINX auth_request모듈을 사용하여 토큰 검증

NGINX auth_request 모듈을 사용하여 액세스 토큰 검증

액세스 토큰 검증을 중앙에서 처리하기 위해 NGINX의 auth_request 모듈을 사용하는 방법은 코드 중복을 방지하고, 

검증 프로세스를 일관성 있게 유지하는 효과적인 접근 방식입니다. 

이를 통해 여러 가지 중요한 이점을 얻을 수 있습니다.

1. 요청은 유효한 토큰을 가진 경우에만 백엔드 서비스에 전달됩니다

NGINX는 요청이 클라이언트로부터 유효한 액세스 토큰을 제시하는 경우에만 백엔드 서비스로 전달하도록 설정할 수 있습니다. 

auth_request 모듈은 인증을 처리하는 별도의 엔드포인트에 요청을 보내 액세스 토큰을 검증하고, 

검증이 성공적으로 완료된 경우에만 원래 요청을 백엔드 서비스로 포워딩합니다. 

만약 토큰이 유효하지 않으면 요청은 차단되며, 클라이언트는 인증 오류를 받게 됩니다.


2. 기존 백엔드 서비스는 코드 변경 없이 보호됩니다

NGINX를 사용하면 기존의 백엔드 서비스에 별다른 코드 변경 없이 액세스 토큰으로 보호를 추가할 수 있습니다. 

auth_request 모듈을 통해 액세스 토큰 검증을 NGINX에서 처리함으로써, 

기존 백엔드는 인증 관련 로직을 신경 쓸 필요 없이 기존의 비즈니스 로직에 집중할 수 있습니다. 

모든 인증 작업은 NGINX에서 중앙 집중식으로 처리되므로, 백엔드 코드의 변경 없이도 강력한 보안이 적용됩니다.


3. NGINX 인스턴스만 IdP에 등록하면 됩니다

보안 인증을 위한 Identity Provider(IdP) 등록은 단 한 번만 수행하면 됩니다. 

즉, NGINX만 IdP에 등록하면 각 백엔드 서비스가 개별적으로 등록하거나 인증을 처리할 필요가 없습니다. 

NGINX는 중앙 인증 지점 역할을 하며, 백엔드 서비스는 NGINX의 검증을 신뢰하게 됩니다. 

이로 인해 인증 관리가 간소화되고, 인증 프로세스의 일관성도 유지됩니다.


4. 누락되거나 잘못된 토큰에 대한 일관된 오류 처리

토큰이 누락되었거나 잘못된 경우, NGINX는 일관된 오류 처리를 제공합니다. 

auth_request 모듈은 인증 요청을 처리하고, 인증 실패 시 HTTP 상태 코드(예: 401 Unauthorized)를 반환합니다. 

이러한 오류 처리는 모든 백엔드 서비스에서 일관되게 동작하며, 

개발자는 각 서비스에서 발생할 수 있는 다양한 오류를 따로 처리할 필요 없이 공통된 오류 처리 로직을 사용할 수 있습니다.


NGINX가 역방향 프록시로 토큰 검증을 수행함


NGINX auth_request 모듈 사용 예시

다음은 NGINX에서 auth_request 모듈을 사용하여 액세스 토큰을 검증하는 설정 예시입니다.

NGINX가 하나 이상의 애플리케이션에 대한 역방향 프록시 역할을 하므로, 

auth_request모듈을 사용하여 백엔드로 요청을 프록시하기 전에 IdP에 대한 API 호출을 트리거할 수 있습니다. 

잠시 후에 살펴보겠지만, 다음 솔루션에는 근본적인 결함이 있지만, 

모듈의 기본 작동을 소개하는데 auth_request, 이는 이후 섹션에서 자세히 설명하겠습니다.


1server {
2    listen 80;
3
4    location / {
5        auth_request /_oauth2_token_introspection;                              
6        proxy_pass http://my_backend;
7    }
8
9    location = /_oauth2_token_introspection {
10        internal;
11        proxy_method      POST;
12        proxy_set_header  Authorization "bearer SecretForOAuthServer";
13        proxy_set_header  Content-Type "application/x-www-form-urlencoded";
14        proxy_set_body    "token=$http_apikey&token_hint=access_token";
15        proxy_pass        https://idp.example.com/oauth/token;
16    }
17}
view rawauth_request.conf hosted with ❤ by GitHub


지시문 auth_request(5행)은 API 호출을 처리할 위치를 지정합니다. 

백엔드(6행)로의 프록시는 응답이 auth_request성공한 경우에만 발생합니다. 

auth_request위치는 9행에서 정의됩니다. 외부 클라이언트가 직접 액세스하지 못하도록 표시되어 있습니다 internal.

11-14행은 토큰 인트로스펙션 요청 형식을 준수하도록 요청의 다양한 속성을 정의합니다. 

인트로스펙션 요청에서 전송된 액세스 토큰은 14행에 정의된 본문의 구성 요소입니다. 

여기서는 token=$http_apikey클라이언트가 apikey요청 헤더에서 액세스 토큰을 제공해야 함을 나타냅니다. 

물론 액세스 토큰은 요청의 모든 속성에서 제공될 수 있으며, 이 경우 다른 NGINX 변수를 사용합니다.

auth_requestNGINX JavaScript 모듈로 확장

언급했듯이, auth_request이런 방식으로 모듈을 사용하는 것은 완전한 해결책이 아닙니다. 

auth_request모듈은 HTTP 상태 코드를 사용하여 성공( =좋음,  =나쁨)을 결정합니다. 

그러나 OAuth 2.0 토큰 인트로스펙션 응답은 JSON 객체에서 성공 또는 실패를 인코딩하고 두 경우 모두 HTTP 상태 코드를 반환합니다  .2xx4xx200 (OK)


유효한 토큰에 대한 토큰 내성 검사 응답의 JSON 형식

우리에게 필요한 것은 IdP의 인트로스펙션 응답을 적절한 HTTP 상태 코드로 변환해주는 JSON 파서입니다. 

이를 통해 모듈이 auth_request해당 응답을 올바르게 해석할 수 있습니다.

다행히도 JSON 파싱은 NGINX JavaScript 모듈(njs)에 대한 사소한 작업입니다. 

따라서 토큰 인트로스펙션 요청을 수행하기 위한 블록을 정의하는 대신, 

모듈에 JavaScript 함수를 호출하라고 location말합니다 .auth_request

[ 편집자  - 이 게시물은 NGINX JavaScript 모듈의 사용 사례를 탐색하는 여러 게시물 중 하나입니다. 

전체 목록은 NGINX JavaScript 모듈의 사용 사례를 참조하세요 .

이 섹션의 코드는 NGINX Plus R23 이상 에서 지시어를js_import 대체하는 지시어를 사용하도록 업데이트되었습니다. 

자세한 내용은 NGINX JavaScript 모듈 의 참조 문서를 참조하세요 . 

예제 구성 섹션은 NGINX 구성 및 JavaScript 파일에 대한 올바른 구문을 보여줍니다. ]js_include

참고: 이 솔루션은 JavaScript 모듈을 nginx.confload_module 의 지시문 과 함께 동적 모듈로 로드해야 합니다 . 

지침은 NGINX Plus 관리자 가이드 를 참조하세요 .


1js_import oauth2.js; # Location of JavaScript code
2
3server {
4    listen 80;
5
6    location / {
7        auth_request /_oauth2_token_introspection;
8        proxy_pass http://my_backend;
9    }
10
11    location = /_oauth2_token_introspection {
12        internal;
13        js_content oauth2.introspectAccessToken;                                       
14    }
view rawauth_request_njs.conf hosted with ❤ by GitHub


13번째 줄의 지시문 js_content은 JavaScript 함수, 를 핸들러 introspectAccessToken로 지정합니다.

auth_request. 핸들러 함수는 oauth2.js 에 정의되어 있습니다 .


1function introspectAccessToken(r) {
2    r.subrequest("/_oauth2_send_request",
3        function(reply) {
4            if (reply.status == 200) {
5                var response = JSON.parse(reply.responseText);
6                if (response.active == true) {
7                    r.return(204); // Token is valid, return success code
8                } else {
9                    r.return(403); // Token is invalid, return forbidden code
10                }
11            } else {
12                r.return(401); // Unexpected response, return 'auth required'
13            }
14        }
15    );
16}
17
18export default { introspectAccessToken }
view rawoauth2.js hosted with ❤ by GitHub


이 함수는 아래 구성 스니펫에 정의된 다른 위치( /oauth2_send_requestintrospectAccessToken ) 에 HTTP 하위 요청(2번째 줄)을 만듭니다. 

그런 다음 JavaScript 코드는 응답(5번째 줄)을 구문 분석하고 필드 값에 따라 적절한 상태 코드를 모듈 로 다시 보냅니다. 

유효한(활성화된) 토큰은 HTTP (하지만 성공)를 반환하고 잘못된 토큰은 HTTP를 반환합니다. 

오류 조건은 HTTP를  반환 하므로 오류와 잘못된 토큰을 구별할 수 있습니다.

auth_requestactive204 (No Content)403 (Forbidden)401 (Unauthorized)

참고: 이 코드는 개념 증명으로만 제공되며 프로덕션 품질이 아닙니다. 

포괄적인 오류 처리 및 로깅이 포함된 완전한 솔루션이 아래에 제공됩니다 .

2번째 줄에 정의된 하위 요청 대상 위치는 원래 구성과 매우 유사합니다 auth_request.


16    location /_oauth2_send_request {
17        internal;
18        proxy_method      POST;
19        proxy_set_header  Authorization "Bearer SecretForOAuthServer";
20        proxy_set_header  Content-Type "application/x-www-form-urlencoded";
21        proxy_set_body    "token=$http_apikey&token_hint=access_token";
22        proxy_pass        https://idp.example.com/oauth/token/introspect;
23    }
view rawauth_request_njs.conf hosted with ❤ by GitHub


OAuth 2.0 토큰 인트로스펙션 요청은 `/ _oauth2_send_request` 경로에 모든 필수 구성이 포함되어 있습니다. 주요 구성 요소로는 인증(19행), 액세스 토큰(21행), 토큰 인트로스펙션 엔드포인트의 URL(22행)이 있으며, 일반적으로 이 세 가지 항목만으로 요청을 처리할 수 있습니다. 

IdP(Identity Provider)가 NGINX 인스턴스에서 토큰 인트로스펙션 요청을 수락하려면 인증이 필요합니다. OAuth 2.0 토큰 인트로스펙션 사양은 인증을 필수로 요구하지만, 특정 인증 방식을 명시하지는 않습니다. 이 예제에서는 `Authorization` 헤더에 베어러 토큰을 사용하는 방식을 적용했습니다.

구성 적용 후, NGINX는 클라이언트로부터 요청을 수신하면 이를 JavaScript 모듈로 전달하여 IdP에 토큰 인트로스펙션 요청을 전송합니다. IdP로부터 받은 응답을 검토하고, 응답 필드에서 `active` 값이 `true`일 경우 인증이 성공한 것으로 판단합니다. 이러한 접근 방식은 NGINX를 활용해 OAuth 2.0 토큰 인트로스펙션을 간결하고 효율적으로 수행할 수 있는 솔루션으로, 다른 인증 API에도 손쉽게 적용 가능합니다.

다만, 토큰 인트로스펙션의 주요 과제는 모든 HTTP 요청에 추가적인 지연 시간을 초래한다는 점입니다. 특히 IdP가 호스팅 서비스나 클라우드 기반 솔루션인 경우 이러한 지연은 심각한 성능 문제로 이어질 수 있습니다. 

이를 해결하기 위해 NGINX와 NGINX Plus는 토큰 인트로스펙션 응답을 캐싱하는 기능을 제공하여 이러한 단점을 최적화할 수 있습니다. 캐싱을 통해 인증 요청으로 인한 지연 시간을 효과적으로 줄이고, 전체 시스템의 성능과 안정성을 향상시킬 수 있습니다.

최적화 1: NGINX의 캐싱

OAuth 2.0 토큰 내성은 JSON/REST 엔드포인트에서 IdP에 의해 제공되므로 표준 응답은 HTTP 상태가 있는 JSON 본문입니다  

200. 이 응답이 액세스 토큰과 키로 연결되면 캐시 가능성이 높아집니다.


유효한 토큰에 대한 완전한 토큰 내성 응답

NGINX는 액세스 토큰에 대한 인트로스펙션 응답을 캐싱할 수 있도록 구성할 수 있습니다. 

이를 통해 동일한 액세스 토큰이 다시 제시될 경우, 

IdP에 추가적인 API 호출을 수행하는 대신 캐시된 응답을 활용하여 요청을 처리합니다. 

이러한 캐싱 방식은 후속 요청의 처리 속도를 크게 개선하여 전반적인 대기 시간을 줄이는 데 효과적입니다.

만료되거나 취소된 액세스 토큰을 수락할 위험을 줄이기 위해 캐시된 응답의 유효 기간을 세밀히 제어할 수 있습니다. 


예를 들어, API 클라이언트가 짧은 시간 동안 여러 요청을 집중적으로 보내는 경우, 

캐시 유효 기간을 10초로 설정하면 사용자 경험을 향상시키는 동시에 보안 리스크를 최소화할 수 있습니다.

캐싱은 적절한 저장소 구성을 통해 활성화됩니다. 이를 위해 인트로스펙션 응답을 저장할 디스크 

디렉토리와 액세스 토큰 키를 관리할 공유 메모리 영역을 지정해야 합니다. 

이러한 구성은 캐싱된 데이터를 효율적으로 관리하면서 성능과 안정성을 동시에 보장합니다.


1proxy_cache_path /var/cache/nginx/oauth keys_zone=token_responses:1m max_size=2m;
view rawauth_request_cache.conf hosted with ❤ by GitHub


이 proxy_cache_path지시문은 필요한 저장소를 할당합니다: 

인트로스펙션 응답을 위한 /var/cache/nginx/oauth 와 키에 대한 token_responses 라는 메모리 영역입니다 . 

컨텍스트에서 구성되므로 http및 블록 외부에 나타납니다 server. 

캐싱 자체는 토큰 인트로스펙션 응답이 처리되는 블록 location내부에서 활성화됩니다 .location



18    location /_oauth2_send_request {
19        internal;
20        proxy_method      POST;
21        proxy_set_header  Authorization "Bearer SecretForOAuthServer";
22        proxy_set_header  Content-Type "application/x-www-form-urlencoded";
23        proxy_set_body    "token=$http_apikey&token_hint=access_token";
24        proxy_pass        https://idp.example.com/oauth/token/introspect;
25
26        proxy_cache           token_responses; # Enable caching
27        proxy_cache_key       $http_apikey;    # Cache for each access token
28        proxy_cache_lock      on;              # Duplicate tokens must wait
29        proxy_cache_valid     200 10s;         # How long to use each response
30        proxy_ignore_headers  Cache-Control Expires Set-Cookie;
31    }
view rawauth_request_cache.conf hosted with ❤ by GitHub


캐싱은 proxy_cache 지시문(26행)을 통해 활성화됩니다. 기본적으로 NGINX는 URI에 따라 응답을 캐싱하지만, 

이 경우 요청 헤더에서 제공되는 액세스 토큰(apikey)에 따라 응답을 캐싱하려고 합니다(27행).


26~28행에서는 proxy_cache_lock 지시문을 사용하여, 동일한 캐시 키에 대한 동시 요청이 있을 경우 

첫 번째 요청이 캐시를 채운 후에 나머지 요청이 응답을 받을 수 있도록 대기하도록 NGINX에 지시합니다. 

29행에서 proxy_cache_valid 지시문을 사용하여, 인트로스펙션 응답이 캐시될 유효 기간을 설정합니다. 


이 지시문이 없으면, NGINX는 IdP에서 제공한 캐시 제어 헤더에 따라 캐시 시간을 결정합니다. 

그러나 이러한 헤더는 항상 신뢰할 수 없기 때문에, 

proxy_cache_valid 지시문을 통해 NGINX에 응답 캐시 방법을 명확히 지시합니다(30행).

이렇게 설정된 캐싱 기능을 통해, 액세스 토큰을 제시하는 클라이언트는 10초마다 토큰 검증을 위한 추가 요청을 하더라도, 

그에 따른 지연 비용은 최소화할 수 있습니다.


최적화 2: NGINX Plus를 사용한 분산 캐싱

토큰 인트로스펙션 캐싱은 보안을 해치지 않으면서 애플리케이션 성능을 크게 개선하는 효과적인 방법입니다. 

하지만, NGINX가 분산 환경(예: 여러 데이터 센터, 클라우드 플랫폼, 액티브-액티브 클러스터)에서 운영될 경우, 

캐시된 토큰 인트로스펙션 응답은 요청을 처리한 NGINX 인스턴스에만 존재합니다.

NGINX Plus를 사용하면 keyval 모듈(메모리 내 키-값 저장소)을 통해 캐시된 토큰 인트로스펙션 응답을 저장할 수 있습니다. 

또한, zone_sync 모듈을 사용하면 여러 NGINX Plus 인스턴스 간에 캐시된 응답을 동기화할 수 있어, 

어떤 NGINX Plus 인스턴스에서 토큰 인트로스펙션 요청을 수행했는지에 관계없이 응답을 클러스터 내 모든 인스턴스에서 사용할 수 있습니다.

참고: zone_sync 모듈을 통한 런타임 상태 공유는 이 블로그의 범위를 벗어나므로, 이에 대한 자세한 사항은 NGINX Plus 관리자 가이드를 참조하세요.


NGINX Plus R18 이상에서는 keyval 모듈을 사용해 변수 값을 수정하여 키-값 저장소를 업데이트할 수 있습니다. 

JavaScript 모듈은 NGINX 변수에 접근할 수 있기 때문에, 응답 처리 중에도 키-값 저장소에 인트로스펙션 응답을 채울 수 있습니다.

NGINX 파일 시스템 캐시처럼, 키-값 저장소는 저장소를 지정하여 활성화됩니다. 

이 경우 액세스 토큰을 키로, 인트로스펙션 응답을 값으로 저장하는 메모리 영역을 설정하게 됩니다.


1keyval_zone zone=access_tokens:4m timeout=10s sync;
2keyval $http_apikey $token_data zone=access_tokens;
view rawauth_request_keyval.conf hosted with ❤ by GitHub


timeout지시문 에 대한 매개변수를 사용하여 auth_request_cache.confkeyval_zone 의 29번째 줄에서와 같이 

캐시된 응답에 대해 동일한 10초 유효 기간을 지정하여 NGINX Plus 클러스터의 각 멤버가 만료 시 응답을 독립적으로 제거하도록 합니다. 

2번째 줄은 각 항목에 대한 키-값 쌍을 지정합니다. 

키는 요청 헤더에 제공된 액세스 토큰 이고 값은 변수에서 평가한 인트로스펙션 응답입니다 .apikey$token_data

apikey이제 요청 헤더를 포함하는 각 요청에 대해 $token_data변수는 이전 토큰 인트로스펙션 응답(있는 경우)으로 채워집니다. 

따라서 JavaScript 코드를 업데이트하여 토큰 인트로스펙션 응답이 이미 있는지 확인합니다.


1function introspectAccessToken(r) {
2    if (r.variables.token_data) {
3        tokenResult(r); // Existing response in key-value store so do validation
4    } else {
5        r.subrequest("/_oauth2_send_request",
6            function(reply) {
7                if (reply.status == 200) {
8                    r.variables.token_data = reply.responseText; // Create entry
9                    tokenResult(r); // Do validation of response
10                } else {
11                    r.return(401); // Unexpected response, return auth-required
12                }
13            }
14        );
15    }
16}
view rawoauth2_keyval.js hosted with ❤ by GitHub


2번째 줄은 이 액세스 토큰에 대한 키-값 저장소 항목이 이미 있는지 테스트합니다. 

인트로스펙션 응답을 얻을 수 있는 경로가 두 가지(키-값 저장소에서 또는 인트로스펙션 응답에서) 있기 때문에 

검증 논리를 다음과 같은 별도 함수로 옮깁니다 tokenResult.


18function tokenResult(r) {
19    var response = JSON.parse(r.variables.token_data);
20
21    if (response.active) {
22        r.return(204);
23    } else {
24        r.return(401);
25    }
26}
view rawoauth2_keyval.js hosted with ❤ by GitHub


이제 각 토큰 인트로스펙션 응답은 키-값 저장소에 저장되고 NGINX Plus 클러스터의 다른 모든 멤버에서 동기화됩니다. 

다음 예는 유효한 액세스 토큰이 있는 간단한 HTTP 요청과 키-값 저장소의 내용을 표시하기 위한 NGINX Plus API에 대한 쿼리를 보여줍니다.

$ curl -IH "apikey: tQ7AfuEFvI1yI-XNPNhjT38vg_reGkpDFA" http://localhost/HTTP/1.1 200 OK
Date: Wed, 24 Apr 2019 17:41:34 GMT
Content-Type: application/json
Content-Length: 612

$ curl http://localhost/api/4/http/keyvals/access_tokens
{"tQ7AfuEFvI1yI-XNPNhjT38vg_reGkpDFA":"{\"active\":true}"}

키-값 저장소 자체는 JSON 형식을 사용하므로 토큰 내부 검사 응답에는 따옴표에 이스케이프가 자동으로 적용됩니다.

최적화 3: 내성 응답에서 속성 추출

OAuth 2.0 토큰 내성의 유용한 기능은 응답에 활성 상태 외에도 토큰에 대한 정보가 포함될 수 있다는 것입니다. 

이러한 정보에는 토큰 만료 날짜와 연관된 사용자의 속성(사용자 이름, 이메일 주소 등)이 포함됩니다.

토큰 속성을 사용한 토큰 내성 검사 응답

토큰 내성 검사 응답을 통해 제공되는 추가 정보는 보안과 액세스 제어에 매우 중요한 역할을 할 수 있습니다. 

이 정보는 다양한 방식으로 활용될 수 있으며, 예를 들어 세분화된 액세스 제어 정책을 구현하거나, 

백엔드 애플리케이션에 필요한 추가 정보를 제공하는 데 사용될 수 있습니다. 

이러한 추가 정보는 auth_request 모듈을 사용하여 HTTP 응답과 함께 전달될 수 있습니다. 


토큰 내성 검사 응답을 활용한 예시

auth_request 모듈은 인증 과정에서 액세스 토큰을 확인하고, 그 결과로 추가적인 정보를 HTTP 응답 헤더로 전달할 수 있습니다. 

이 정보를 활용하면, 다양한 애플리케이션 레벨에서 토큰의 상태와 관련된 세부 정보를 처리하고, 

액세스 제어 결정을 내리는 데 도움을 줄 수 있습니다.

주요 예시: 응답 헤더에 추가 정보 포함하기

토큰 내성 검사 후, auth_request 모듈은 성공적인 HTTP 응답

(예: 204 No Content)과 함께 토큰에 대한 추가 정보를 응답 헤더로 전달할 수 있습니다. 

예를 들어, 액세스 토큰에 대한 유효성 검사 후, 응답 헤더에 다음과 같은 정보가 포함될 수 있습니다:


18function tokenResult(r) {
19    var response = JSON.parse(r.variables.token_data);
20
21    if (response.active) {
22        // Convert all members of the response into response headers
23        for (var p in response) {
24            if (!response.hasOwnProperty(p)) continue;
25            r.log("OAuth2 Token-" + p + ": " + response[p]);
26            r.headersOut['Token-' + p] = response[p];
27        }
28        r.status = 204;
29        r.sendHeader();
30        r.finish();
31    } else {
32        r.return(401);
33    }
34}
view rawoauth2_attributes.js hosted with ❤ by GitHub


auth_request우리는 인트로스펙션 응답(23행)의 각 속성을 반복하고 응답 헤더로 모듈로 다시 보냅니다. 

각 헤더 이름은 표준 응답 헤더(26행)와의 충돌을 피하기 위해 접두사로 붙습니다 Token-. 

이러한 응답 헤더는 이제 NGINX 변수로 변환하여 일반 구성의 일부로 사용할 수 있습니다.


9    location / {
10        auth_request /_oauth2_token_introspection;   
11        auth_request_set $username $sent_http_token_username;
12        proxy_set_header X-Username $username;
13        proxy_pass http://my_backend;
14    }
view rawauth_request_attributes.conf hosted with ❤ by GitHub

username이 예에서 속성을 새 변수로 변환합니다 $username(11번째 줄). 

auth_request_set지시문을 사용하면 토큰 인트로스펙션 응답의 컨텍스트를 현재 요청의 컨텍스트로 내보낼 수 있습니다. 

각 속성에 대한 응답 헤더(JavaScript 코드에서 추가됨)는 . 그런 다음 12번째 줄에는 백엔드로 프록시되는 요청 헤더로 값을 포함합니다 . 

토큰 인트로스펙션 응답에서 반환된 모든 속성에 대해 이 구성을 반복할 수 있습니다.$sent_http_token_attribute$username


토큰 내성 검사 응답에서 프록시 요청에 대한 속성 내보내기

생산 구성

위에서 제시된 코드는 개념 증명(proof of concept) 수준이나 특정 사용 사례에 맞춘 사용자 정의 환경에서 잘 작동할 수 있습니다. 

그러나 프로덕션 환경에서는 추가적인 고려가 필요합니다. 오류 처리, 로깅, 그리고 유연한 구성 등을 통해 시스템의 안정성을 높이고 

유지보수성을 강화하는 것이 중요합니다.

 GitHub의 공식 리포지토리에서는 NGINX 및 NGINX Plus에 대한 더 강력하고 세부적인 구현 예시를 찾아볼 수 있습니다.


  • NGINX를 사용한 OAuth 2.0 토큰 인트로스펙션 (디스크 캐싱)

    NGINX를 사용할 때, 액세스 토큰의 인트로스펙션 응답을 디스크 캐싱 방식으로 저장하여 후속 요청 시 빠른 응답을 제공할 수 있습니다. 이 방식은 파일 시스템 캐시를 활용하여 디스크에 저장된 캐시된 응답을 참조함으로써 인트로스펙션 검사를 반복할 필요 없이 성능을 향상시킬 수 있습니다.

  • NGINX Plus를 사용한 OAuth 2.0 토큰 인트로스펙션 (키-값 캐싱)

NGINX Plus에서는 키-값 저장소를 사용하여 액세스 토큰의 인트로스펙션 응답을 메모리 내에서 캐시할 수 있습니다. 이를 통해 응답 속도를 더욱 개선하고, 분산 캐시로 여러 NGINX Plus 인스턴스에서 인트로스펙션 응답을 공유할 수 있습니다. 이 방식은 특히 다수의 데이터 센터나 클라우드 환경에서의 배포에 적합하며, NGINX Plus의 클러스터링 기능을 활용하여 전체 시스템에서 캐시된 응답을 효율적으로 동기화할 수 있습니다.

요약

이 블로그에서는 NGINX 모듈을 JavaScript 모듈과 함께 사용하여 클라이언트 요청에서 

OAuth 2.0 토큰 인트로스펙션을 수행하는 방법을 보여주었습니다.

auth_request. 또한 캐싱으로 해당 솔루션을 확장하고 NGINX 구성에서 사용할 인트로스펙션 응답에서 속성을 추출했습니다.

또한 NGINX Plus 키-값 저장소를 NGINX Plus 인스턴스 클러스터 전반의 프로덕션 배포에 적합한, 

내성 응답을 위한 분산 캐시로 사용하는 방법도 설명했습니다.


NGINX Plus로 OAuth 2.0 토큰을 직접 사용해 보세요. 

오늘 무료 30일 평가판을 시작하거나 사용 사례에 대해 논의하려면 저희에게 문의하세요 .





전문가와 상담하기




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

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를 통해 신용 카드 결제와 관련된 민감한 데이터를 보호하고, 최신 보안 위협으로부터 애플리케이션을 효과적으로 방어할 수 있습니다.

전문가에게 상담 하기

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



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 App Protect를 무료로 사용해보세요!


NGINX App Protect의 gRPC 지원에 대한 자세한 내용은 문서를 참조하시기 바랍니다.

gRPC API와 함께 NGINX Plus 및 NGINX App Protect를 사용해 보려면 30일 무료 체험을 시작하거나 

사용 사례에 대해 논의하려면 저희에게 문의해 주세요.

전문가에게 상담받기




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


최근 몇 년 동안 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 App Protect를 직접 사용해 볼 준비가 되셨나요? 

무료 30일 체험판을 시작하거나, 저희에게 연락하여 사용 사례에 대해 논의하세요.

전문가에게 상담받기



프로필 이미지
관리자
2024-08-23
조회 52


올해 초에 NGINX Instance Manager를 출시하여

기업이 NGINX Open Source 및 NGINX Plus 인스턴스를 검색, 추적, 보안 및 구성할 수 있도록 지원했습니다.

다음 기능을 도입한 NGINX Instance Manager 버전 1.0을 발표하게 되어 기쁩니다.


  • NGINX 인스턴스 및 사용자 역할 태그 지정  – 자산을 그룹화하여 대규모로 간편하게 관리합니다. 
  • 몇 번만 클릭하면 그룹의 모든 NGINX 인스턴스에 구성 및 역할 기반 액세스 제어(RBAC) 설정을 한 번에 적용할 수 있습니다.
  • 인증서 관리  – 만료된 인증서를 감지하고 교체하여 안전하고 중단 없는 서비스를 보장합니다.

규모에 따른 간소화된 관리를 위한 태그 지정

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 인스턴스에 인증서를 업로드합니다.

NGINX Instance Manager를 사용해보고 싶으신가요?

30일 무료 체험판을 다운로드하거나 저희 에게 연락해 사용 사례에 대해 논의해 보세요 .




프로필 이미지
관리자
2024-08-23
조회 62


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

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

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


네트워크 수준에서의 기존 서비스 거부(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는 적응적이고 동적인 방어 기술로 이에 대응합니다.

DoS 보호를 보장하는 방법에 대해 자세히 알아보려면 솔루션 브리핑을 확인하세요 . 또한 다음 관련 블로그도 참조하세요.

  • 복잡하고 현대적인 공격으로부터 애플리케이션 방어
  • NGINX 앱 보호 서비스 거부가 진화하는 공격 환경에 적응하는 방식
  • NGINX App Protect DoS를 직접 사용해보세요. 오늘 무료 30일 체험판을 시작하거나 저희에게 연락해 사용 사례에 대해 논의해보세요 .



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


이제 "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 App Protect 및 NGINX Controller 와 함께 NGINX Plus 의 무료 30일 평가판을 시작하고 , 클라우드( AWS , Google Cloud Platform , Microsoft Azure )에서 제공되는 서비스를 확인하고, 강사가 진행하는 NGINX App Protect 소개 수업에 등록하세요 .



F5 NGINX에 대한 더 많은 블로그 게시물 읽기 ›

전문가에게 상담받기

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


사용자 경험이 전부입니다. 소비자와 고객이 사용하지 않는다면 앱과 웹사이트를 가질 이유가 없습니다. 
따라서 특히 사용자가 지연, 다운타임, 오류에 덜 관대해질 때 긍정적이고 일관된 사용자 경험을 보장하는 것이 중요합니다.
사용자가 앱이나 웹사이트에서 부정적인 경험을 하면 평생 고객을 잃을 수 있습니다. 
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
조회 44


편집자  - 이 게시물은 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
조회 24


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