블로그 | NGINX

NGINX Plus R26 발표

NGINX-F5-수평-검정-유형-RGB의 일부
로버트 헤인스 썸네일
로버트 헤인스
2022년 2월 15일 게시

NGINX Plus 릴리스 26(R26)이 출시되어 기쁩니다. NGINX 오픈 소스를 기반으로 하는 NGINX Plus는 유일한 올인원 소프트웨어 웹 서버, 로드 밸런서, 역방향 프록시, 콘텐츠 캐시 및 API 게이트웨이입니다.

NGINX Plus R26 의 새롭고 향상된 기능은 다음과 같습니다.

  • JSON 웹 키 세트 캐싱을 통한 더 빠른 JWT 검증 – 지난 몇 번의 릴리스에서 추가된 JSON 웹 토큰(JWT) 지원에 대한 일련의 개선 사항을 계속하면서 JSON 웹 키 세트(JWKS)의 메모리 내 캐싱을 도입하여 JWT 검증의 오버헤드를 크게 줄입니다.
  • 강화된 TLS 핸드셰이크 – 클라이언트가 세션에 대한 NGINX 구성 컨텍스트와 일치하지 않는 ALPN을 통한 통신 프로토콜을 제안하는 경우 NGINX Plus는 TLS 핸드셰이크를 거부합니다(예: http{} 컨텍스트에서 가상 서버에 IMAP 이메일 프로토콜을 제안하는 경우).
  • NGINX JavaScript 모듈 개선 사항 – async 및 await 키워드와 Promise 객체를 사용하는 비동기 함수가 이제 지원되며 암호화 작업(예: 난수 생성 또는 쿠키 암호화)을 위한 WebCrypto API가 구현되었습니다.

이 릴리스의 핵심 기능으로 는 IBM System Z(s390x) 아키텍처 지원, TCP 연결의 각 방향을 독립적으로 닫을 수 있는 기능, Perl 호환 정규 표현식(PCRE) 라이브러리 버전 2 지원 등이 있습니다.

행동의 중요한 변화

NGINX JavaScript 모듈은 더 이상 js_include를 지원하지 않습니다.

NGINX Plus R23 버전 출시 시 발표된 바와 같이0.4.0 NGINX JavaScript 모듈의 js_import 지시어가 js_include 지시어를 대체했습니다. js_include 지시어는 당시에 더 이상 사용되지 않으며 이 릴리스부터는 더 이상 지원되지 않습니다.

NGINX Plus R26 으로 업그레이드하기 전에 NGINX 설정 파일에서 js_include를 js_import 로 바꾸고 NGINX 설정에서 참조되는 함수에 대한 export 명령문을 JavaScript 파일에 추가합니다. 다음 단계를 따르세요.

  1. NGINX 구성 파일 편집:

    • js_include를 js_import 로 바꾸고 암묵적인 module_name (지시문에 대한 JavaScript 파일 이름 매개변수, 확장자 .js 제외)을 기록해 둡니다.

    • JavaScript 함수를 참조하는 각 지시문에서 함수 이름 앞에 module_name 을 접두사로 붙입니다. 함수 이름은 다음 지시문에 대한 첫 번째 매개변수입니다.

      js_set [ HTTP ][ Stream ] 지시문의 두 번째 매개변수입니다.

    예를 들어, 다음을 변경합니다.

    js_set $foo 내 함수;

    에게:

    js_set $foo 모듈 이름 .myFunction;

  2. NGINX 구성 파일에서 참조되는 함수를 정의하는 JavaScript( module_name .js ) 파일을 편집합니다. 각 파일에 다음과 같이 export 명령문을 추가하고 참조되는 함수의 이름을 지정합니다.

    기본 내보내기 { myFunction, otherFunction }

    export 문은 .js 파일 어디에나 나타날 수 있지만 관례에 따라 함수 바로 위나 파일 끝에 나타납니다.

쿠키 플래그 모듈이 더 이상 사용되지 않습니다.

타사 Cookie‑Flag 모듈은 NGINX Plus R23 에서 더 이상 지원되지 않으며, 당시 발표된 대로 이번 릴리스부터는 NGINX 모듈 저장소 에서 더 이상 사용할 수 없습니다.

NGINX Plus R26 으로 업그레이드하기 전에 NGINX 구성을 편집하여 더 이상 사용되지 않는 모듈에 정의된 set_cookie_flag 지시어를 기본 제공 proxy_cookie_flags 지시어로 모두 대체합니다.

TLS 협상은 더 이상 NPN 프로토콜을 지원하지 않습니다.

NGINX가 TLS 및 HTTP/2 연결을 설정하는 방식이 업데이트되었습니다. NGINX와 클라이언트(일반적으로 브라우저) 간 TLS 핸드셰이크의 일부로, 두 사람은 핸드셰이크에서 설정된 세션에서 어떤 통신 프로토콜을 사용할지 협상합니다(대부분의 경우 협상을 통해 세션이 HTTP 1.x 에서 HTTP/2로 업그레이드됩니다). TLS에 대한 NPN(Next Protocol Negotiation) 확장은 이 목적을 위해 사용된 첫 번째 방법이었지만 NPN은 현재 더 이상 사용되지 않으며 RFC 7301 로 게시된 ALPN(Application‑Layer Protocol Negotiation) 확장으로 대체되었습니다.

NGINX Plus R26은 더 이상 NPN을 지원하지 않으므로 클라이언트는 이제 ALPN을 전적으로 사용해야 합니다.

또한, ALPN 구현이 확장되고 강화되었습니다. 강화된 TLS 핸드셰이크를 참조하세요.

이전 NGINX Plus 소프트웨어 저장소는 더 이상 업데이트되지 않습니다.

NGINX Plus R24 가 출시되면서 모든 NGINX 소프트웨어의 패키지 저장소가 재구성되어 NGINX Plus 설치 절차가 변경되었습니다.

NGINX Plus를 설치하거나 업그레이드하면 운영 체제의 패키지 관리자( apt , yum 또는 이와 동등한 패키지)가 NGINX Plus용 소프트웨어 저장소로 구성됩니다.

기존 시스템에서 plus-pkgs.nginx.com 저장소를 사용하도록 구성되어 NGINX Plus R26 으로 업그레이드하는 경우( NGINX Plus R23 이하 버전을 사용하는 경우), 패키지 관리자를 업데이트하여 새 pkgs.nginx.com/plus 저장소를 참조해야 합니다. F5 지식 기반 의 지침을 참조하세요.

NGINX Plus R26 의 초기 설치를 수행하는 경우 NGINX Plus 관리자 가이드 의 NGINX Plus 설치를 참조하세요.

NGINX Plus R26은 더 이상 업데이트되지 않는 이전 저장소에서 사용할 수 없습니다 .

NGINX Plus API에 대한 OpenAPI 사양에 대한 액세스 변경

NGINX Plus 소프트웨어 패키지에는 더 이상 NGINX Plus API 에 대한 YAML 형식 OpenAPI 사양 및 Swagger UI가 포함되지 않습니다. 이제 NGINX Plus 관리자 가이드 에서 액세스할 수 있습니다.

플랫폼 지원 변경

지원되는 새로운 운영 체제 및 아키텍처:

제거된 이전 운영 체제:

  • Alpine Linux 3.11(지원되는 가장 오래된 버전은 3.12)

NGINX Plus R27 에서 더 이상 지원되지 않으며 제거될 예정인 이전 운영 체제 및 아키텍처:

  • Power8 아키텍처(ppc64le)
  • 센트OS 8.1 이상
  • 알파인 리눅스 3.12

새로운 기능에 대한 자세한 정보

JSON 웹 키 세트 캐싱을 통한 더 빠른 JWT 검증

JSON 웹 토큰을 검증할 때 NGINX는 JSON 웹 키 세트(JWKS)를 사용하여 토큰 서명을 검증하거나 토큰을 암호 해독합니다. JWKS는 구성 파일에 저장하거나 HTTP 요청을 통해 외부 서비스에서 가져올 수 있습니다. 또한 JWKS를 메모리에 캐싱하는 데는 여러 가지 이점이 있습니다.

  • CPU 사용량이 크게 감소했습니다
  • 요청 지연 시간 감소
  • 캐싱 프로세스의 일부로 JWKS 키가 암호화 작업에 최적화된 바이너리 형식으로 JSON에서 변환되기 때문에 JWT 검증이 간소화됩니다.

JWKS를 메모리에 캐시하려면 새로운 auth_jwt_key_cache 지시문을 포함하고 각 키 세트의 만료 시간을 지정합니다(이 예에서는 3시간).

 

외부 서버에서 JWK를 가져오는 경우 표준 콘텐츠 캐싱을 구성하고 proxy_cache_use_stale 지시문을 포함하는 것이 좋습니다. 이 지시문은 NGINX Plus가 백그라운드에서 새로 고쳐지는 동안 만료된 JWKS를 계속 제공하도록 지시합니다.

 

JWKS 캐싱 외에 콘텐츠 캐싱의 이점은 두 가지입니다.

  • 복원력 – JWKS는 만료된 경우에도 캐시에서 검색할 수 있습니다. 이렇게 하면 JWKS 공급자를 일시적으로 사용할 수 없을 때 복원력이 증가하지만 보안 위험이 증가한다는 단점이 있습니다.

  • 권한 부여 서버에 미치는 영향 – 캐시된 JWKS의 만료는 JWKS 캐싱이 단독으로 사용되는지 또는 콘텐츠 캐싱과 함께 사용되는지에 따라 인증 서버에 미치는 영향이 다릅니다.

    • JWKS 캐싱만 사용하는 경우, 만료된 JWKS의 새 버전으로 캐시가 다시 채워질 때까지 모든 수신 인증 요청은 인증 서버로 전달됩니다. 인증 서버의 응답이 느리면 JWKS에 대한 HTTP 요청이 갑자기 반복될 수 있습니다. 이러한 추가적인 부하로 인해 인증 서비스에 과부하가 걸려 문제가 더 악화될 수 있습니다.

    • 만료된 JWKS 제공과 함께 콘텐츠 캐싱이 활성화된 경우, JWKS에 대한 요청은 단 한 번만 인증 서버로 전달되고, 이후 요청은 콘텐츠 캐시가 채워진 후 NGINX에서 충족될 때까지 대기열에 저장됩니다. 이로 인해 인증 서비스에 대한 수요(따라서 리소스 소비)가 낮아집니다.

강화된 TLS 핸드셰이크

ALPACA 와 같은 TLS에 대한 공격이 증가하고 있습니다. 우리는 악용에 대한 사전 방어에 대한 지속적인 노력의 일환으로 TLS 연결에 대한 NGINX의 처리를 강화했습니다.

ALPN(애플리케이션 계층 프로토콜 협상)은 TLS 핸드셰이크에 대한 선택적 확장으로, TLS 핸드셰이크 중에 클라이언트와 서버가 핸드셰이크에서 설정된 암호화된 세션에서 사용할 계층 7 프로토콜을 선택하는 데 사용됩니다. ALPN의 가장 일반적인 사용 사례는 브라우저와 웹 또는 앱 서버 간 세션에 대해 HTTP/ 1.x 에서 HTTP/2로 업그레이드를 협상하는 것입니다.

NGINX Plus는 이제 클라이언트가 세션이 설정되는 NGINX 구성 컨텍스트와 일치하지 않는 ALPN을 통해 프로토콜을 제안하는 경우 TLS 핸드셰이크를 거부합니다. 예를 들어, http{} 컨텍스트에서 정의된 가상 서버는 HTTP에 대한 ALPN 프로토콜 ID를 필요로 하는 반면, mail{} 컨텍스트의 가상 서버는 SMTP, POP 또는 IMAP에 대한 프로토콜 ID를 필요로 합니다.

NGINX Plus R26은 협상된 프로토콜을 캡처하기 위해 $ssl_alpn_protocol [ HTTP ][ Stream ] 변수를 도입합니다. ( NGINX Plus R15 에서 stream{} 컨텍스트에 도입된 $ssl_preread_alpn_protocols 변수는 핸드셰이크 중에 클라이언트가 광고하는 모든 프로토콜 목록을 여전히 캡처합니다.)

이 스니펫은 $ssl_alpn_protocol을 사용하여 액세스 로그의 항목인 alpn= 필드에 프로토콜을 포함하는 alpn 로그 형식을 정의합니다.

 

stream{} 컨텍스트의 새로운 ssl_alpn 지시어는 NGINX Plus가 허용하는 프로토콜을 정의합니다. NGINX Plus가 클라이언트가 제시한 모든 프로토콜을 고려할 수 있도록 지시문을 생략합니다.

 

NGINX JavaScript 모듈 향상

NGINX Plus R26 에는 다음 버전이 통합되어 있습니다.0.7.2 NGINX JavaScript 모듈(njs)의 두 가지 향상된 기능이 포함되어 있습니다.

메모: 이 섹션에서는 비동기 및 암호화 작업을 위한 JavaScript 구조를 이해하고 있다고 가정합니다. 코드 조각에 대한 전체적인 분석은 이 블로그의 범위를 벗어납니다.

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

비동기 함수에 대한 향상된 지원

PHP와 같이 일반적으로 사용되는 많은 스크립팅 언어에서 명령과 함수는 동기적으로 실행됩니다. 즉, 스크립트가 함수를 호출한 후 함수가 결과를 반환할 때까지 일시 중지(실행 중지)됩니다.

JavaScript는 비동기적으로도 작동할 수 있습니다. 즉, 함수가 비동기적으로 호출되면 스크립트는 함수에서 결과가 반환될 때까지 기다리지 않고 계속 실행됩니다.

다음 샘플 스크립트를 살펴보세요.

 

njs 런타임은 정의된 시간 초과가 경과할 때까지 기다리지 않기 때문에 빈 응답을 반환합니다(기다렸다면 출력은 b,a 입니다).

$ 컬 http://127.0.0.1/ $

의도한 결과를 얻으려면 비동기 작업을 올바르게 처리하는 것이 분명히 중요합니다. JavaScript는 이를 수행하는 여러 가지 방법을 제공하지만, 일반적인 NGINX 사용 사례에서는 비동기 함수를 단순히 래핑하여 실행 흐름을 동기적으로 만드는 것이 바람직한 경우가 많습니다. 여기서 Promise 객체와 async , await 키워드가 등장하게 됩니다.

ECMAScript 6 (JavaScript용 ECMA‑262 언어 사양의 6번째 에디션)에서는 Promise 객체를 비동기 함수의 반환 유형으로 정의합니다. 다음 세 가지 상태 중 하나로 존재합니다.

  • 완료됨 – 작업이 성공적으로 완료되었습니다.
  • 거부됨 – 작업이 실패했습니다.
  • 보류 중 – 초기 상태(이행되지 않았거나 거부되지 않음)

async 키워드로 JavaScript 함수를 정의하면 함수의 반환 유형이 Promise 로 설정됩니다. async 및 await 키워드는 Promise 객체를 처리하는 njs 함수를 작성할 때 중요합니다.

다음 예를 살펴보세요.

 

fs.readFile 함수(12번째 줄)는 Promise를 반환합니다. fs.readFile()은 파일 이름이 user.text 인 경우에만 호출되도록 하는 사용자 지정 비동기 함수에 래핑되어 있습니다. await 키워드 덕분에 래핑 함수는 Promise 를 기다리고 데이터를 반환합니다.

fs.readFile()을 다른 함수로 래핑하면 오류를 더 쉽게 포착할 수 있습니다. 비동기 함수에서 발생하는 모든 예외는 Promise 상태를 denied 로 설정합니다. 이를 수행하는 또 다른 방법은 9번째 줄을 거부된 Promise를 반환하는 명령문으로 바꾸는 것입니다.

 

Promise 객체로 직접 작업할 수도 있습니다. 다음 예에서 Promise.resolve 함수는 p1 과 p2 각각에 대한 Promise를 반환합니다. Promise.all 함수는 결과를 반환하기 전에 p1 과 p2 에 대한 약속이 해결될 때까지 기다립니다.

 

이제 curl 명령의 출력은 원하는 내용입니다(시간 초과 값이 더 짧기 때문에 b가 먼저 반환됩니다).

$ 컬 http://127.0.0.1/ b,a $

WebCrypto API를 사용한 새로운 암호화 기능

NGINX JavaScript는 이제 WebCrypto API를 통해 향상된 암호화 기능에 액세스할 수 있습니다. 일반적인 njs 암호화 사용 사례는 다음과 같습니다.

  • 세션 ID에 대한 보안 난수 생성
  • 메시지, 데이터 및 쿠키 암호화 및 암호 해독
  • 대칭 및 비대칭 암호 알고리즘을 사용하여 디지털 서명을 생성 또는 검증

이 njs 코드는 무작위 숫자를 생성합니다:

 

그리고 이 NGINX Plus 구성은 njs 코드를 호출합니다.

 

함수의 출력은 다음과 같은 난수입니다.

$ 컬 127.0.0.123225320050,3668407277,1101267190,2061939102,2687933029,2361833213,32543985,4162087386

WebCrypto의 getRandomValues 함수는 보안 난수와 WebCrypto 전반을 시작하기에 좋은 시작점입니다. 구현은 매우 간단하며, 해당 함수는 Promise 를 반환하는 것과 달리 결과를 직접 반환합니다.

그러나 다른 보다 집중적인 WebCrypto 암호화 기능 중 일부는 비동기적으로 작동합니다. 예를 들어, сrypto.subtle.digest() 에 대한 설명서는 다음과 같이 기술되어 있습니다.

제공된 데이터의 다이제스트를 생성합니다. 다이제스트 알고리즘에 사용할 식별자와 다이제스트할 데이터를 인수로 사용합니다. 반환합니다 약속하다 이는 다이제스트를 통해 충족됩니다.

따라서 сrypto.subtle.digest()를 직접 호출하더라도 비동기 함수로 래핑하지 않는 한, 결과가 다음 단계에서 사용 가능하다는 보장은 없습니다. 따라서 여기서는 async 및 await 키워드를 사용하여 함수로 묶어 함수가 반환되기 전에 해시 변수에 결과가 채워지도록 합니다.

 

이 NGINX Plus 구성의 js_set 지시문은 setReturnValue 함수에서 반환된 값( host_hash 함수에 래핑됨)으로 $hosthash 변수를 채웁니다.

 

다음은 호스트 이름 example.com을 해시하는 예입니다.

$ curl -H "호스트: example.com" 127.0.0.1 # e8e624a82179b53b78364ae14d14d63dfeccd843b026bc8d959ffe0c39fc4ded1f4dcf4c8ebe871e657a12db6f11c3af87c9a1d4f2b096ba3deb56596f06b6f4

NGINX Plus R26의 기타 개선 사항

IBM Z(s390x) 아키텍처 지원

현대적 애플리케이션이 이용 가능한 모든 디지털 바이옴을 식민지화함에 따라 NGINX와 같은 필수적인 생명 지원 구성 요소도 함께 이동하는 것이 중요하므로 CentOS 8.1 이상, RHEL 8.1 이상 및 Ubuntu 20.04가 설치된 IBM Z(s390x) 아키텍처에서 NGINX Plus를 지원하게 되어 기쁩니다. 기존 메인프레임 자산에서 최신 애플리케이션을 호스팅하려는 조직은 이제 NGINX 및 NGINX Plus를 소프트웨어 기반 웹 서버, 부하 분산 장치, 역방향 프록시, 콘텐츠 캐시 및 API 게이트웨이로 배포할 수 있습니다.

스트림 모듈의 TCP 반닫기 지원

새로운 proxy_half_close 지시어는 stream{} 컨텍스트에서 추가적인 효율성을 위해 TCP 연결의 각 방향을 독립적으로 닫을 수 있도록 합니다.

PCRE2 라이브러리 지원

이전 버전의 NGINX Plus에서는 NGINX 구성에서 사용되는 정규 표현식을 평가하기 위해 Perl 호환 정규 표현식(PCRE) 라이브러리 (버전 1)를 사용합니다. 이 중요한 오픈소스 프로젝트는 최근 수명이 다해 PCRE2 로 대체되었습니다. NGINX Plus는 PCRE2를 사용하여 구축되었지만, 기본 운영 체제에서 사용 가능한 버전을 사용하여 PCRE와 PCRE2로 구축된 동적 모듈을 지원합니다. 구성 변경이 필요하지 않습니다.

업그레이드 또는 NGINX Plus를 사용해 보세요

NGINX Plus를 사용하고 계시다면 가능한 한 빨리 NGINX Plus R26 으로 업그레이드하실 것을 적극 권장합니다. 또한 몇 가지 추가적인 수정 사항과 개선 사항을 얻을 수 있으며, 지원 티켓을 제출해야 할 때 NGINX에서 도움을 주는 데 도움이 됩니다.

NGINX Plus를 사용해보지 않으셨다면 보안, 부하 분산, API 게이트웨이로 사용하거나 향상된 모니터링 및 관리 API를 갖춘 완벽히 지원되는 웹 서버로 사용해보시기 바랍니다. 오늘 무료 30일 체험판을 통해 시작해 보세요.

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

"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."