NGINX Plus R24 출시 발표

NGINX Plus 릴리스 24(R24)를 사용할 수 있게 되었음을 기쁘게 알려드립니다. NGINX Open Source를 기반으로 하는 NGINX Plus는 웹 서버, 로드 밸런서, 리버스 프록시, 콘텐츠 캐시 및 API 게이트웨이 기능을 모두 갖춘 유일한 통합 소프트웨어입니다.

NGINX Plus R24의 새로운 기능은 다음과 같습니다:

• 암호화된 JSON 웹 토큰 – 이전 릴리스에서 지원한 서명된 JSON 웹 토큰(JWT)을 기반으로, 이제 NGINX Plus는 웹 브라우저 및 기타 클라이언트에 저장되는 민감한 정보의 기밀성과 데이터 무결성을 보장하기 위해 암호화된 JWT를 지원합니다.
• NGINX JavaScript 모듈 개발의 중요한 이정표 – 새로운 기능, 특히 HTTP 헤더와 본문 모두에 대한 응답 필터링과 TCP/UDP 연결 및 세션을 위한 HTTP 기반 인증 서비스 지원을 통해 다양하고 강력한 새로운 사용 사례를 구현할 수 있습니다.
• F5 Device ID+와의 통합 – 이 실시간 고정밀 기기 식별자는 사이트를 방문하는 각 기기에 고유 식별자를 할당하여 알려진 악성 행위자로부터 더욱 강력하게 보호하고 재방문자에게 맞춤형 사용자 경험을 제공할 수 있도록 합니다.

이번 릴리스에는 이 밖에도 필수 상태 점검 결과를 구성 다시 로드 시에도 선택적으로 유지하는 기능과 쿠키 플래그에 동적 값을 사용하는 기능이 포함됩니다.

중요한 동작 변경 사항

지원 중단된 Cookie-Flag 모듈

NGINX Plus R23 출시 당시 발표한 바와 같이 타사 Cookie-Flag 모듈은 더 이상 사용되지 않으며 NGINX Plus R26에서 동적 모듈 리포지토리에서 제거될 예정입니다. 이 모듈에 정의된 set_cookie_flag 지시문은 proxy_cookie_flags 지시문으로 대체됩니다. 구성에 있는 모든 set_cookie_flag 지시문을 가능한 한 빨리 proxy_cookie_flags 지시문으로 교체하는 것이 좋습니다. 동적 쿠키 플래그도 참조하세요.

플랫폼 지원 변경 사항

• 새롭게 지원되는 운영 체제:
  • Alpine Linux 3.13(aarch64, amd64)
  • CentOS 7.4+ (x86_64 및 ppc64le 외에 aarch64도 지원)
  • FreeBSD 13 (amd64)
  • SLES 15 SP2
• 이전 운영 체제 제거됨:
  • Debian 9는 더 이상 지원되지 않으며, 지원되는 가장 오래된 버전은 10입니다.
• NGINX Plus R25에서 지원 중단 예정이며 제거가 예정된 이전 운영 체제:
  • Alpine Linux 3.10
  • Amazon Linux 1(2018.03 이상)
  • FreeBSD 11
  • Ubuntu 16.04 LTS

Amazon Linux 2는 OpenSSL 1.1에 의존합니다

NGINX Plus 패키지는 이제 Amazon Linux 2에서 OpenSSL 1.1을 사용하며, 이를 통해 TLS 1.3을 지원하고 그 밖의 여러 측면에서 보안을 강화합니다. Amazon Linux 2 시스템을 NGINX Plus R24로 업그레이드할 때는 시스템에서 OpenSSL을 사용하는 다른 소프트웨어가 OpenSSL 1.1에서도 계속 정상적으로 작동하는지 확인하십시오.

NGINX Plus 설치 절차 변경 사항

NGINX Plus 패키지 리포지토리를 재구성함에 따라 설치 절차가 변경되었습니다.

리포지토리 구성 변경은 당사의 제품 포트폴리오와 NGINX Plus에 의존하는 제품 생태계의 확장을 반영한 것입니다. 특히 NGINX Plus의 경우, pkgs.nginx.com/plus 리포지토리가 기존 plus-pkgs.nginx.com 리포지토리를 대체합니다.

NGINX Plus를 설치하고 업그레이드할 때 운영 체제의 패키지 관리자(apt, yum, 또는 이에 상응하는 도구)는 NGINX Plus 소프트웨어 저장소를 사용하도록 구성됩니다. plus-pkgs.nginx.com 저장소를 사용하도록 구성된 기존 시스템에서는 패키지 관리자가 pkgs.nginx.com/plus(그리고 운영 체제를 나타내는 마지막 경로 요소)를 참조하도록 업데이트해야 합니다.

기존 시스템을 NGINX Plus R24로 업그레이드하는 방법은 F5 기술 자료를 참조하세요. 최신 최초 설치 지침은 NGINX Plus 관리 가이드의 NGINX Plus 설치를 참조하세요.

HTTP 연결 처리 지시어 통합

As the HTTP/3 표준이 완성 단계에 가까워지고 HTTP/2 사용이 증가함에 따라 장기 연결을 구성하는 방식을 간소화했습니다. NGINX Plus R24 이상에서는 이전에 HTTP/1.1에만 적용되던 구성 지시문이 HTTP/2에서도 작동합니다. 이제 프로토콜 버전이 다르다는 이유만으로 동일한 기능에 서로 다른 지시문을 사용할 필요가 없습니다.

더 이상 사용되지 않는 지시문 대체 지시문http2_idle_timeout keepalive_timeouthttp2_max_field_size
http2_max_header_size large_client_header_buffershttp2_max_requests keepalive_requestshttp2_recv_timeout client_header_timeout

더욱 적극적인 연결 종료

NGINX Plus R23 이상에서는 lingering_close, lingering_time, lingering_timeout 지시문이 HTTP/1.1뿐만 아니라 HTTP/2에서도 작동합니다. 이러한 지시문을 사용하여 HTTP/2 연결을 더 효율적으로 처리하도록 구성하면 NGINX Plus의 전반적인 HTTP/2 기능이 향상됩니다.

NGINX Plus R24에서는 이러한 지시문의 동작이 크게 변경되어 잠재적인 버그가 해결되었습니다. 사용 가능한 워커 연결 풀이 고갈되면 NGINX Plus는 keepalive 연결뿐만 아니라 lingering-close 모드의 연결도 닫기 시작합니다.

기록되는 상태 점검 변경 사항의 심각도 수준 변경

NGINX는 업스트림 서버의 상태가 변경되면 오류 로그에 항목을 기록합니다. 이는 인프라의 전반적인 상태를 모니터링하고 분석하는 데 중요한 도구입니다. 상태 변경이 기록되는 심각도 수준이 HTTP 및 TCP/UDP(stream) 업스트림 서버 모두에서 변경되었습니다:

• Change from healthy에서 unhealthy로의 변경은 warn 수준으로 기록됩니다(이전에는 info 수준).
• Change from unhealthy에서 healthy로 변경되면 notice 수준으로 기록됩니다(이전에는 info 수준).

새로운 기능 상세

암호화된 JSON 웹 토큰

JSON 웹 토큰(JWT)의 사용이 계속 증가하고 있습니다. 이전에는 NGINX Plus가 RFC 7515에 정의된 JSON 웹 서명[JWS] 표준에 따른 서명된 토큰을 지원하여 토큰에 인코딩된 클레임의 데이터 무결성을 보장했습니다. 그러나 JWS는 클레임의 기밀성을 보장하지 않으므로 토큰에 액세스할 수 있는 모든 구성 요소가 클레임을 읽을 수 있습니다. TLS/SSL은 전송 중인 토큰의 노출을 줄여 주지만, 웹 브라우저 및 기타 클라이언트에 저장된 토큰은 여전히 노출됩니다.

NGINX Plus R24에서는 암호화된 토큰(RFC 7516에 정의된 JSON Web Encryption[JWE] 표준)을 지원하여 전체 클레임 집합의 기밀성과 데이터 무결성을 모두 보장합니다. 이제 민감한 정보나 개인 식별 정보(PII)를 안전하지 않은 클라이언트로 인해 데이터가 유출될 위험 없이 JWT에 인코딩할 수 있습니다.

NGINX Plus R24 이상에서는 서명된 JWT와 암호화된 JWT를 모두 지원합니다. 서명된 토큰이 기본값이며 별도의 명시적 구성이 필요하지 않습니다. 새로운 auth_jwt_type 지시문은 JWT 암호화를 구성합니다.

코드 예제를 로드하는 중…

암호화(또는 서명) 알고리즘과 키 사용법은 auth_jwt_key_file 지시문으로 지정한 JWT 키 파일에서 정의합니다. NGINX Plus R24 이상에서는 다음 암호화 방식을 지원합니다.

JWE 키 관리 알고리즘

• A128KW, A192KW, A256KW

• A128GCMKW, A192GCMKW, A256GCMKW

• dir – 공유 대칭 키를 콘텐츠 암호화 키로 직접 사용하도록 구성합니다

JWE 콘텐츠 암호화 알고리즘

• A128CBC-HS256, A192CBC-HS384, A256CBC-HS512

• A128GCM, A192GCM, A256GCM

NGINX JavaScript 모듈의 성숙도를 보여주는 주요 이정표

NGINX Plus R24는 현재 버전이 0.5.3인 NGINX JavaScript 모듈(njs) 개발에서 중요한 이정표가 되는 릴리스입니다. 다양한 사용 사례에 맞는 사용자 지정 솔루션으로 NGINX Plus를 확장할 수 있도록 지원하는 두 가지 중요한 개선 사항은 다음과 같습니다:

• 응답 필터링(HTTP 응답의 헤더와 본문 모두에 적용)
• HTTP 또는 TCP/UDP 처리 중에 HTTP 요청을 수행하는 데 사용할 수 있는 내장 HTTP 클라이언트 that can be used to make HTTP requests during HTTP or TCP/UDP processing

NGINX JavaScript 모듈이 익숙하지 않다면, 다음 블로그 소개 글<.htmla>을 읽어보세요.

[이 섹션에서 설명하는 사용 사례는 NGINX JavaScript 모듈의 수많은 사용 사례 중 일부에 불과합니다. 전체 목록은 NGINX JavaScript 모듈 사용 사례를 참조하세요.]

응답 필터링

API 게이트웨이 또는 리버스 프록시로 배포된 NGINX Plus의 가장 강력한 기능 중 하나는 응답 필터링입니다. 이 기능은 업스트림 서버의 응답을 가로채고 정규식 일치를 기반으로 응답 본문이나 헤더 또는 둘 다에 포함된 문자열을 바꿉니다. NGINX JavaScript 모듈로 처리하지 않는 트래픽의 경우 응답 필터링은 Substitution 모듈에서 구현됩니다.

NGINX Plus R24에서는 NGINX JavaScript 모듈 내에 별도의 응답 필터링 구현이 도입되었으며, 두 가지 지시문을 통해 JavaScript의 강력한 기능을 활용하여 응답 본문과 헤더를 분석하고 수정할 수 있습니다. JavaScript는 검사 및 조작의 가능성을 정규식 기반의 단순 문자열 치환보다 훨씬 더 넓게 확장하여 Substitution 모듈보다 더욱 강력한 응답 필터링을 제공합니다.

Filtering Response Bodies with the js_body_filter 지시문을 사용한 응답 본문 필터링

With the js_body_filter 지시어를 사용하면 JavaScript로 프록시 서버의 응답 본문을 검사하고 수정할 수 있습니다. 사용 사례는 다음과 같습니다:

• 정규 표현식을 사용하여 복잡한 패턴 검색
• 데이터 형식 변환
• 응답에 동적 콘텐츠 삽입

이 예제에서는 응답에서 AWS 액세스 키로 보이는 항목을 검색하고, 발견된 모든 항목을 마스킹된 값으로 대체합니다.

코드 예제를 로드하는 중…

이 코드를 실행하려면 관련 maskAwsKeys 함수를 해당 location 블록 내에서 참조하기만 하면 됩니다.

코드 예제를 로드하는 중…

Filtering Response Headers with the js_header_filter 지시문을 사용한 응답 헤더 필터링

You can use the js_header_filter 지시어를 사용하면 응답 헤더의 내용을 검사하거나 가로채서 수정할 수도 있습니다. 민감한 정보가 포함되어 있지만 정상적인 작동에 꼭 필요한 여러 Set-Cookie 헤더를 발급하는 백엔드 서버를 예로 들어 보겠습니다. NGINX Plus는 응답을 가로채고 Set-Cookie 헤더를 읽어 키-값 저장소에 저장할 수 있습니다. 키-값 저장소를 참조하는 대체 Set-Cookie 헤더를 생성하여 원래 응답에 삽입할 수 있습니다.

키-값 저장소와 js_header_filter의 상호 작용을 보여 주는 요청 흐름

NGINX Plus 구성의 4~5번째 줄에서 키-값 저장소를 정의합니다:

코드 예제를 로드하는 중…

그런 다음 12~13번째 줄에서 참조 쿠키를 키-값 저장소의 콘텐츠로 대체하고, JavaScript 코드로 새 쿠키를 가로챕니다.

코드 예제를 로드하는 중…

JavaScript 코드는 각각의 새로운 Set-Cookie 응답 헤더를 순회하며 이를 저장할 새 키-값 항목을 생성합니다.

코드 예제를 로드하는 중…

간단한 HTTP 클라이언트로 TCP/UDP용 HTTP 서비스 활용하기

API 게이트웨이의 주요 사용 사례는 특정 리소스에 대한 액세스를 제어하는 것입니다. NGINX Plus는 HTTP 요청을 위해 레이어 7에서 강력한 인증 및 액세스 제어 기능을 제공하지만, 최신 API 구현에서는 TCP/UDP도 기반 프로토콜로 활용하므로 새로운 인증 문제가 발생합니다.

기본 제공되는 NGINX JavaScript ngx.fetch 함수를 사용하면 이제 TCP/UDP 연결 컨텍스트 내에서 간단한 HTTP 클라이언트를 인스턴스화할 수 있습니다. 이를 통해 stream 컨텍스트에서 액세스 제어에 HTTP 기반 인증 서비스를 사용할 수 있습니다. 예를 들어 데이터베이스 연결을 프록시할 때 로컬 OpenPolicy Agent 데몬을 호출할 수 있습니다.

이 예제에서는 포트 8085의 로컬 HTTP 인증 서비스를 사용하여 각각의 새 연결을 인증하는 방법을 보여 줍니다. js_access 지시문과 ngx.fetch 함수는 새로 인스턴스화된 HTTP 컨텍스트에서 하위 요청 결과를 기반으로 하는 클라이언트 인증과 유사한 기능을 함께 구현합니다(일반 HTTP 요청의 경우 auth_request 지시문으로 구현됨). Response 객체에서 확인할 수 있는 HTTP 상태 코드를 기반으로 백엔드 데이터베이스 연결을 허용(s.allow)하거나 거부(s.deny)합니다.

코드 예제를 로드하는 중…

코드 예제를 로드하는 중…

참고: ngx.fetch 함수는 NGINX JavaScript HTTP 모듈 및 NGINX JavaScript Stream 모듈에서 모두 작동하지만, HTTP 모듈의 r.subrequest 객체에 비해 상당한 제약이 있습니다. 대부분의 HTTP 사용 사례에서는 TLS 연결, 캐싱 및 r.subrequest에서 제공하는 모든 기능을 지원하는 Proxy 모듈을 사용하는 것이 좋습니다.

기타 njs 개선 사항

NGINX 변수가 set [HTTP][Stream] 또는 js_set [HTTP][Stream] 지시어로 정의된 경우, 요청 처리 중 리디렉션이 발생하면 해당 값을 덮어쓸 수 있습니다. 새로운 js_var [HTTP][Stream] 지시어를 사용하면 JavaScript 함수로 변수를 평가하고 리디렉션 후에도 해당 값을 유지할 수 있습니다.

새로운 njs.on 객체를 사용하면 njs 가상 머신이 종료될 때 JavaScript 함수를 실행할 수 있습니다. 예를 들어 TCP 연결이 종료될 때 함수를 실행하는 데 사용할 수 있습니다.

새로운 s.status Stream 세션 객체 속성을 통해 전체 세션 상태에 액세스할 수 있습니다(가능한 값은 $status 참조).

F5 Device ID+와의 통합

F5 Device ID+는 고급 신호 수집 기술과 검증된 머신 러닝 알고리즘을 활용하여 사이트를 방문하는 각 디바이스에 고유 식별자를 할당하는 실시간 고정밀 디바이스 식별 솔루션입니다. 간편하게 배포할 수 있으며 보안, 네트워킹, 사기 방지 및 디지털 팀에서 즉각적인 효과를 얻을 수 있습니다. 애플리케이션을 방문하는 고유 디바이스를 이처럼 쉽게 파악할 수 있었던 적은 없습니다.

NGINX Plus 인스턴스에서 F5 Device ID+를 활성화하는 방법은 F5 Device ID+를 통한 사기 및 위험 완화를 참조하세요.

F5 Device ID+ 사용의 이점

• 애플리케이션 보안 강화 – 정확한 디바이스 식별을 통해 공격 탐지 및 완화 분석을 강화합니다. 보안 시스템에서 이미 의심스러운 것으로 표시한 재방문 디바이스를 식별합니다.
• 트래픽 관리 최적화 – 고유한 디바이스 식별자를 라우팅 로직에 통합하여 네트워크 트래픽을 더욱 효율적으로 관리하고 최적화합니다. 악의적인 행위자가 계층 7 데이터를 조작하더라도 디바이스를 식별할 수 있습니다.
• 사기 및 위험 완화 – 신규 계정 생성, 사용자 인증, 전자상거래 결제, 금융 거래 등의 과정에서 고객 행동을 모니터링하여 신원 도용을 비롯한 위협을 나타낼 수 있는 비정상적인 패턴을 탐지합니다.
• 온라인 경험 개인화 및 가속화 – 이전에 방문한 적이 있는 것으로 확인된 사용자와 기기가 로그인, 결제 및 인증을 원활하게 진행할 수 있도록 지원합니다. F5의 A/B 테스트 결과, 보안 절차의 불편을 줄이면 매출이 증가하며, 기기 식별은 이러한 불편을 줄이기 위한 모든 전략에서 중요한 요소인 것으로 나타났습니다.

F5 Device ID+의 작동 방식

각 사용자가 웹사이트를 방문하면 F5 Device ID+는 JavaScript를 활용하여 브라우저, 디바이스의 OS, 하드웨어 및 네트워크 구성에 관한 정보를 수집합니다. 이러한 속성은 업계에서 인정받는 F5 Shape의 AI 및 머신 러닝 기능을 기반으로 구축된 F5 Device ID+ 서비스에 입력됩니다. 데이터는 실시간으로 처리되며, 이미 알려진 디바이스가 아닌 경우 해당 디바이스에 고유 식별자가 할당됩니다. 재방문 디바이스의 경우 행동, 작업 및 기타 속성을 기록하고 학습 및 분석하여 사기를 줄이고 정상 사용자에게 원활한 경험을 제공할 수 있습니다.

NGINX Plus R24의 기타 개선 사항

필수 상태 확인 결과를 구성 다시 로드 후에도 유지 가능

필수 상태 확인은 NGINX Plus API 또는 DNS 확인을 통해 추가된 업스트림 서버의 느린 시작을 활성화하는 데 사용됩니다. 이를 통해 새 노드는 먼저 상태 확인을 거친 후 트래픽을 수신할 준비가 되면 느린 시작이 적용됩니다.

이전에는 구성을 다시 로드하면 업스트림 서버가 다시 로드하기 전의 상태와 관계없이 비정상으로 간주되었습니다. 그 결과, 첫 번째 필수 상태 검사를 통과할 때까지 서버가 클라이언트 요청을 수락하지 않았습니다.

NGINX Plus R24에서는 필수 HTTP 상태 확인을 영구적으로 설정하여 구성을 다시 로드할 때 이전 상태가 유지되도록 할 수 있습니다. persistent 매개변수를 health_check 지시문에 mandatory 매개변수와 함께 추가합니다.

코드 예제를 로드하는 중…

동적 쿠키 플래그

이전 NGINX Plus 릴리스에서는 쿠키 플래그를 설정하는 proxy_cookie_flags 지시어를 기본 제공 방식으로 도입했습니다. NGINX Plus R24에서는 쿠키 플래그에 동적 값을 사용할 수 있도록 이 기능을 확장했습니다. 이를 통해 특정 쿠키 플래그를 NGINX 변수로 제어할 수 있습니다.

참고: proxy_cookie_flags 지시문으로 인해 Cookie‑Flag 모듈은 더 이상 사용되지 않으며, NGINX Plus R26에서 제거될 예정입니다. 더 이상 사용되지 않는 Cookie‑Flag 모듈을 참조하세요.

This example uses a map to enable the Secure cookie flag when the scheme is https rather than http.

코드 예제를 로드하는 중…

NGINX Plus로 업그레이드하거나 사용해 보기

NGINX Plus를 실행 중이라면 가능한 한 빨리 NGINX Plus R24로 업그레이드하시기를 강력히 권장합니다. 업그레이드하면 여러 추가 수정 사항과 개선 사항도 적용되며, 지원 티켓을 제출해야 할 때 NGINX가 더 원활하게 지원하는 데 도움이 됩니다.

아직 NGINX Plus를 사용해 보지 않으셨다면 보안, 로드 밸런싱, API 게이트웨이 용도로, 또는 향상된 모니터링 및 관리 API를 갖춘 완전한 기술 지원이 제공되는 웹 서버로 사용해 보시기 바랍니다. 지금 바로 30일 무료 평가판으로 시작할 수 있습니다.

---