NGINX Plus Release 26(R26) 의 출시를 발표하게 되어 기쁩니다 . NGINX Open Source를 기반으로 하는 NGINX Plus는 유일한 올인원 소프트웨어 웹 서버, 로드 밸런서, 리버스 프록시, 콘텐츠 캐시 및 API 게이트웨이입니다.
NGINX Plus R26 의 새롭고 향상된 기능은 다음과 같습니다.
- JSON 웹 키 세트 캐싱을 통한 더 빠른 JWT 검증 – 지난 몇 번의 릴리스에서 추가된 JSON 웹 토큰(JWT) 지원에 대한 일련의 개선 사항을 계속하면서 JSON 웹 키 세트(JWKS)의 메모리 내 캐싱을 도입하여 JWT 검증의 오버헤드를 크게 줄입니다.
- 강화된 TLS 핸드셰이크 – 클라이언트가 세션에 대한 NGINX 구성 컨텍스트와 일치하지 않는 ALPN을 통한 통신 프로토콜을 제안하는 경우(예: 컨텍스트에서 가상 서버에 IMAP 이메일 프로토콜을 제안하는 경우http{}) NGINX Plus는 TLS 핸드셰이크를 거부합니다.
- NGINX JavaScript 모듈 개선 사항 – 및 키워드와async객체 사용하는 비동기 함수가이제 지원되며 암호화 작업(예: 난수 생성 또는 쿠키 암호화)을 위한 WebCrypto API가 구현되었습니다.awaitPromise
이 릴리스의 핵심 기능으로 는 IBM System Z(s390x) 아키텍처 지원 , TCP 연결의 각 방향을 독립적으로 닫을 수 있는 기능, Perl 호환 정규 표현식(PCRE) 라이브러리 버전 2 지원 등이 있습니다.
행동의 중요한 변화
NGINX JavaScript 모듈이 더 이상 지원하지 않습니다.js_include
NGINX Plus R23 출시 당시에 발표된 대로 , NGINX JavaScript 모듈의 버전 0.4.0js_import 에서 지시어가 지시어를 대체했습니다 js_include. js_include그 당시 지시어는 더 이상 사용되지 않으며 이 릴리스부터 더 이상 지원되지 않습니다.
NGINX Plus R26 으로 업그레이드하기 전에 NGINX 구성 파일에서 js_include를 대체 하고 NGINX 구성에서 참조되는 함수에 대한 명령문을 JavaScript 파일에 js_import추가합니다 . 다음 단계를 따르세요.export
NGINX 구성 파일 편집:
js_include로 바꾸고 암묵적인 module_name (지시문에 대한 JavaScript 파일 이름 매개변수, 확장자 .js 제외 ) js_import을 기록해 둡니다 .
JavaScript 함수를 참조하는 각 지시문에서 함수 이름 앞에 module_name 을 접두사로 붙입니다 . 함수 이름은 이러한 지시문의 첫 번째 매개변수입니다.
- js_body_filter
- js_content
- js_filter
- js_header_filter
js_set[ HTTP ][ Stream ] 지시문 의 두 번째 매개변수입니다 .
예를 들어, 다음을 변경합니다.
js_set $foo myFunction;
에게:
js_set $foo module_name.myFunction;
NGINX 구성 파일에서 참조되는 함수를 정의하는 JavaScript( module_name .jsexport ) 파일을 편집합니다. 각 파일에 다음과 같은 문장을 추가하고 참조되는 함수의 이름을 지정합니다.
export default { myFunction, otherFunction }해당 문장은 .jsexport 파일 어디에나 나타날 수 있지만 관례에 따라 함수 바로 위나 파일 끝에 나타납니다.
쿠키 플래그 모듈이 더 이상 사용되지 않습니다.
타사 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 로 게시된 Application‑Layer Protocol Negotiation(ALPN) 확장으로 대체되었습니다 .
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 repo( NGINX Plus R23 또는 이전 버전을 실행 중인 시스템)를 사용하도록 구성된 NGINX Plus R26 으로 업그레이드하는 경우 패키지 관리자를 업데이트하여 새 pkgs.nginx.com/plus repo를 참조해야 합니다. F5 Knowledge Base 의 지침을 참조하세요 .
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 관리자 가이드 에서 액세스할 수 있습니다 .
플랫폼 지원 변경
지원되는 새로운 운영 체제 및 아키텍처:
- 알파인 리눅스 3.15(x86_64, arm64)
- CentOS 8.1+, RHEL 8.1+ 및 Ubuntu 20.04가 포함된 IBM Z 플랫폼(s390x)은 IBM Z s390x 아키텍처 지원을 참조하세요.
제거된 이전 운영 체제:
- 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백그라운드에서 새로 고침되는 동안 만료된 JWKS를 계속 제공하도록 NGINX Plus에 알리는 지시문을 포함하는 것이 좋습니다 .
JWKS 캐싱 외에 콘텐츠 캐싱의 이점은 두 가지입니다.
강화된 TLS 핸드셰이크
ALPACA 와 같은 TLS에 대한 공격이 증가하고 있습니다. 익스플로잇에 대한 사전 방어에 대한 지속적인 노력의 일환으로 NGINX의 TLS 연결 처리를 강화했습니다.
Application‑Layer Protocol Negotiation(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 의 컨텍스트 $ssl_preread_alpn_protocols에서 도입된 변수는 여전히 핸드셰이크 동안 클라이언트가 광고한 모든 프로토콜 목록을 캡처합니다.)stream{}
이 스니펫은 액세스 로그의 항목 필드 에 프로토콜을 포함하는 데 사용되는 ALPN 로그 형식을 정의합니다.$ssl_alpn_protocolalpn=
ssl_alpn컨텍스트 의 새 지시문은 stream{}NGINX Plus가 어떤 프로토콜을 허용하는지 정의합니다. NGINX Plus가 클라이언트가 제시한 모든 프로토콜을 고려하도록 하려면 지시문을 생략합니다.
NGINX JavaScript 모듈 향상
NGINX Plus R26은 NGINX JavaScript 모듈(njs)의 버전 0.7.2를 통합하고 두 가지 향상된 기능을 포함합니다.
- ECMAScript 6에 도입된 키워드와 객체를 async사용 await하여 비동기 함수에 대한 지원이 향상되었습니다.Promise
- WebCrypto API 구현
참고: 이 섹션에서는 비동기 및 암호화 작업을 위한 JavaScript 구조를 이해한다고 가정합니다. 코드 조각에 대한 전체 분석은 이 블로그의 범위를 벗어납니다.
[ 편집자 - 이 섹션에 설명된 사용 사례는 NGINX JavaScript 모듈의 여러 사용 사례 중 일부에 불과합니다. 전체 목록은 NGINX JavaScript 모듈의 사용 사례를 참조하세요 . ]
비동기 함수에 대한 향상된 지원
PHP와 같이 일반적으로 사용되는 많은 스크립팅 언어에서 명령과 함수는 동기적으로 실행됩니다. 즉, 스크립트가 함수를 호출한 후 함수가 결과를 반환할 때까지 일시 중지(실행 중지)됩니다.
JavaScript는 비동기적으로도 작동할 수 있습니다. 즉, 함수가 비동기적으로 호출되면 스크립트는 함수에서 결과가 반환될 때까지 기다리지 않고 계속 실행됩니다.
다음 샘플 스크립트를 살펴보세요.
정의된 시간 초과가 경과할 때까지 njs 런타임이 기다리지 않기 때문에 빈 응답이 반환됩니다(기다렸다면 출력은 다음과 같습니다 b,a).
$ curl http://127.0.0.1/
$
의도한 결과를 얻는 데 비동기 작업을 올바르게 처리하는 것은 분명히 중요합니다. JavaScript는 이를 수행하는 여러 가지 방법을 제공하지만 일반적인 NGINX 사용 사례에서는 실행 흐름을 동기적으로 만드는 방식으로 비동기 함수를 래핑하는 것이 종종 바람직합니다. 여기서 Promiseobject 및 asyncand await키워드가 작용합니다.
ECMAScript 6 (JavaScript용 ECMA‑262 언어 사양의 여섯 번째 에디션)은 Promise객체를 비동기 함수의 반환 유형으로 정의합니다. 다음 세 가지 상태 중 하나로 존재합니다.
- 완료됨 – 작업이 성공적으로 완료되었습니다.
- 거부됨 – 작업이 실패했습니다.
- 보류 중 – 초기 상태(이행되지 않았거나 거부되지 않음)
키워드로 JavaScript 함수를 정의하면 async함수의 반환 유형이 .으로 설정됩니다 Promise. 객체 를 다루는 njs 함수를 작성할 때 async및 키워드가 중요합니다 .awaitPromise
다음 예를 살펴보세요.
함수 fs.readFile(12번째 줄)는 .을 반환합니다 . 이 함수 는 파일이 user.text 라고 불리는 경우에만 호출되도록 하는 Promise사용자 지정 함수에 래핑됩니다 . 키워드 때문에 래핑 함수는 를 기다리고 데이터를 반환합니다.asyncfs.readFile()awaitPromise
다른 함수로 래핑하면 fs.readFile()오류를 잡기가 더 쉬워집니다. 함수의 모든 예외는 to async의 상태를 설정합니다 . 이를 수행하는 또 다른 방법은 9번째 줄을 거부된 를 반환하는 명령문으로 바꾸는 것입니다 .PromiserejectedPromise
객체 와 직접 작업할 수도 있습니다 Promise. 다음 예에서 함수는 및 각각에 대해 Promise.resolvea를 반환합니다 . 함수는 및 둘 다에 대한 약속이 해결될 때까지 기다린 후 결과를 반환합니다.Promisep1p2Promise.allp1p2
이제 명령의 출력은 curl원하는 내용입니다( b시간 초과 값이 짧기 때문에 먼저 반환됨에 유의하세요).
$ curl http://127.0.0.1/b,a
$
WebCrypto API를 사용한 새로운 암호화 기능
NGINX JavaScript는 이제 WebCrypto API를 통해 향상된 암호화 기능에 액세스할 수 있습니다 . 일반적인 njs 암호화 사용 사례는 다음과 같습니다.
- 세션 ID에 대한 보안 난수 생성
- 메시지, 데이터 및 쿠키 암호화 및 암호 해독
- 대칭 및 비대칭 암호 알고리즘을 사용하여 디지털 서명을 생성 또는 검증
이 njs 코드는 무작위 숫자를 생성합니다:
그리고 이 NGINX Plus 구성은 njs 코드를 호출합니다:
함수의 출력은 다음과 같은 난수입니다.
$ curl 127.0.0.123225320050,3668407277,1101267190,2061939102,2687933029,2361833213,32543985,4162087386
WebCrypto의 함수 getRandomValues는 보안 난수와 WebCrypto를 전반적으로 시작하기에 좋은 진입점입니다. 구현은 매우 간단하고, 함수는 .을 반환하는 것과 달리 결과를 직접 반환합니다 Promise.
그러나 다른 보다 집중적인 WebCrypto 암호화 함수 중 일부는 비동기적으로 작동합니다. 예를 들어, 상태 에 대한 설명서сrypto.subtle.digest() :
주어진 데이터의 다이제스트를 생성합니다. 다이제스트 알고리즘에서 사용할 식별자와 다이제스트할 데이터를 인수로 사용합니다. Promise다이제스트와 함께 충족될 a를 반환합니다.
따라서 직접 호출해도 함수에 래핑 сrypto.subtle.digest()되지 않는 한 결과가 다음 단계에서 사용 가능하다는 보장은 없습니다 . 따라서 여기서는 및 키워드를 async사용하여 함수에 래핑하여 함수가 반환되기 전에 해시 변수에 결과가 채워지도록 합니다.asyncawait
js_set이 NGINX Plus 구성의 지시문은 함수 $hosthash에서 반환된 값 setReturnValue(함수 내에서 래핑됨 host_hash)으로 변수를 채웁니다.
다음은 호스트 이름 example.com을 해시하는 예입니다 .
$ curl -H "Host: 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지침은 컨텍스트에서 추가적인 효율성을 위해 TCP 연결의 각 방향을 독립적으로 닫을 수 있도록 합니다 stream{}.
PCRE2 라이브러리 지원
이전 버전의 NGINX Plus는 Perl Compatible Regular PCRE) 라이브러리 (버전 1)를 사용하여 NGINX 구성에서 사용되는 정규 표현식을 평가합니다. 이 중요한 오픈 소스 프로젝트는 최근 수명이 다하여 PCRE2 로 대체되었습니다 . NGINX Plus는 PCRE2로 빌드되었지만 기본 운영 체제에서 사용 가능한 버전을 사용하여 PCRE와 PCRE2로 빌드된 동적 모듈을 지원합니다. 구성 변경은 필요하지 않습니다.
위 내용과 같이 NGINX Plus 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
NGINX Plus Release 26(R26) 의 출시를 발표하게 되어 기쁩니다 . NGINX Open Source를 기반으로 하는 NGINX Plus는 유일한 올인원 소프트웨어 웹 서버, 로드 밸런서, 리버스 프록시, 콘텐츠 캐시 및 API 게이트웨이입니다.
NGINX Plus R26 의 새롭고 향상된 기능은 다음과 같습니다.
이 릴리스의 핵심 기능으로 는 IBM System Z(s390x) 아키텍처 지원 , TCP 연결의 각 방향을 독립적으로 닫을 수 있는 기능, Perl 호환 정규 표현식(PCRE) 라이브러리 버전 2 지원 등이 있습니다.
행동의 중요한 변화
NGINX JavaScript 모듈이 더 이상 지원하지 않습니다.js_include
NGINX Plus R23 출시 당시에 발표된 대로 , NGINX JavaScript 모듈의 버전 0.4.0js_import 에서 지시어가 지시어를 대체했습니다 js_include. js_include그 당시 지시어는 더 이상 사용되지 않으며 이 릴리스부터 더 이상 지원되지 않습니다.
NGINX Plus R26 으로 업그레이드하기 전에 NGINX 구성 파일에서 js_include를 대체 하고 NGINX 구성에서 참조되는 함수에 대한 명령문을 JavaScript 파일에 js_import추가합니다 . 다음 단계를 따르세요.export
NGINX 구성 파일 편집:
js_include로 바꾸고 암묵적인 module_name (지시문에 대한 JavaScript 파일 이름 매개변수, 확장자 .js 제외 ) js_import을 기록해 둡니다 .
JavaScript 함수를 참조하는 각 지시문에서 함수 이름 앞에 module_name 을 접두사로 붙입니다 . 함수 이름은 이러한 지시문의 첫 번째 매개변수입니다.
js_set[ HTTP ][ Stream ] 지시문 의 두 번째 매개변수입니다 .
예를 들어, 다음을 변경합니다.
js_set $foo myFunction;에게:
js_set $foo module_name.myFunction;NGINX 구성 파일에서 참조되는 함수를 정의하는 JavaScript( module_name .jsexport ) 파일을 편집합니다. 각 파일에 다음과 같은 문장을 추가하고 참조되는 함수의 이름을 지정합니다.
export default { myFunction, otherFunction }해당 문장은 .jsexport 파일 어디에나 나타날 수 있지만 관례에 따라 함수 바로 위나 파일 끝에 나타납니다.
쿠키 플래그 모듈이 더 이상 사용되지 않습니다.
타사 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 로 게시된 Application‑Layer Protocol Negotiation(ALPN) 확장으로 대체되었습니다 .
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 repo( NGINX Plus R23 또는 이전 버전을 실행 중인 시스템)를 사용하도록 구성된 NGINX Plus R26 으로 업그레이드하는 경우 패키지 관리자를 업데이트하여 새 pkgs.nginx.com/plus repo를 참조해야 합니다. F5 Knowledge Base 의 지침을 참조하세요 .
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 관리자 가이드 에서 액세스할 수 있습니다 .
플랫폼 지원 변경
지원되는 새로운 운영 체제 및 아키텍처:
제거된 이전 운영 체제:
NGINX Plus R27 에서 더 이상 지원되지 않으며 제거될 예정인 이전 운영 체제 및 아키텍처 :
새로운 기능에 대한 자세한 정보
JSON 웹 키 세트 캐싱을 통한 더 빠른 JWT 검증
JSON 웹 토큰을 검증할 때 NGINX는 JSON 웹 키 세트(JWKS)를 사용하여 토큰의 서명을 검증하거나 토큰을 복호화합니다. JWKS는 구성 파일에 저장하거나 HTTP 요청을 통해 외부 서비스에서 가져올 수 있습니다. 또한 JWKS를 메모리에 캐싱하는 데는 여러 가지 이점이 있습니다.
JWKS를 메모리에 캐시하려면 새 auth_jwt_key_cache지침을 포함하고 각 키 세트의 만료 시간을 지정합니다(이 예에서는 3시간).
외부 서버에서 JWK를 가져오는 경우 표준 콘텐츠 캐싱을 구성 하고 proxy_cache_use_stale백그라운드에서 새로 고침되는 동안 만료된 JWKS를 계속 제공하도록 NGINX Plus에 알리는 지시문을 포함하는 것이 좋습니다 .
JWKS 캐싱 외에 콘텐츠 캐싱의 이점은 두 가지입니다.
복원성 – JWKS는 만료된 경우에도 캐시에서 검색할 수 있습니다. 이는 JWKS 제공자가 일시적으로 사용할 수 없을 때 복원성을 높이지만 보안 위험이 증가한다는 단점이 있습니다.
권한 부여 서버에 미치는 영향 – 캐시된 JWKS의 만료는 JWKS 캐싱이 단독으로 사용되는지 또는 콘텐츠 캐싱과 함께 사용되는지에 따라 인증 서버에 미치는 영향이 다릅니다.
JWKS 캐싱만 사용하는 경우, 들어오는 모든 권한 부여 요청은 만료된 JWKS의 새 버전으로 캐시가 다시 채워질 때까지 인증 서버로 전달됩니다. 인증 서버의 응답이 느리면 JWKS에 대한 반복적인 HTTP 요청이 갑자기 증가할 수 있습니다. 이러한 추가 부하는 인증 서비스에 과부하를 일으켜 문제를 더 악화시킬 수 있습니다.
만료된 JWKS를 제공하는 콘텐츠 캐싱이 활성화되면 JWKS에 대한 요청이 하나만 인증 서버로 전달되고, 이후의 요청은 콘텐츠 캐시가 채워진 후 NGINX가 이를 충족할 수 있을 때까지 대기합니다. 이로 인해 인증 서비스에서 수요가 낮아지고(따라서 리소스 소비도 낮아집니다).
강화된 TLS 핸드셰이크
ALPACA 와 같은 TLS에 대한 공격이 증가하고 있습니다. 익스플로잇에 대한 사전 방어에 대한 지속적인 노력의 일환으로 NGINX의 TLS 연결 처리를 강화했습니다.
Application‑Layer Protocol Negotiation(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 의 컨텍스트 $ssl_preread_alpn_protocols에서 도입된 변수는 여전히 핸드셰이크 동안 클라이언트가 광고한 모든 프로토콜 목록을 캡처합니다.)stream{}
이 스니펫은 액세스 로그의 항목 필드 에 프로토콜을 포함하는 데 사용되는 ALPN 로그 형식을 정의합니다.$ssl_alpn_protocolalpn=
ssl_alpn컨텍스트 의 새 지시문은 stream{}NGINX Plus가 어떤 프로토콜을 허용하는지 정의합니다. NGINX Plus가 클라이언트가 제시한 모든 프로토콜을 고려하도록 하려면 지시문을 생략합니다.
NGINX JavaScript 모듈 향상
NGINX Plus R26은 NGINX JavaScript 모듈(njs)의 버전 0.7.2를 통합하고 두 가지 향상된 기능을 포함합니다.
참고: 이 섹션에서는 비동기 및 암호화 작업을 위한 JavaScript 구조를 이해한다고 가정합니다. 코드 조각에 대한 전체 분석은 이 블로그의 범위를 벗어납니다.
[ 편집자 - 이 섹션에 설명된 사용 사례는 NGINX JavaScript 모듈의 여러 사용 사례 중 일부에 불과합니다. 전체 목록은 NGINX JavaScript 모듈의 사용 사례를 참조하세요 . ]
비동기 함수에 대한 향상된 지원
PHP와 같이 일반적으로 사용되는 많은 스크립팅 언어에서 명령과 함수는 동기적으로 실행됩니다. 즉, 스크립트가 함수를 호출한 후 함수가 결과를 반환할 때까지 일시 중지(실행 중지)됩니다.
JavaScript는 비동기적으로도 작동할 수 있습니다. 즉, 함수가 비동기적으로 호출되면 스크립트는 함수에서 결과가 반환될 때까지 기다리지 않고 계속 실행됩니다.
다음 샘플 스크립트를 살펴보세요.
정의된 시간 초과가 경과할 때까지 njs 런타임이 기다리지 않기 때문에 빈 응답이 반환됩니다(기다렸다면 출력은 다음과 같습니다 b,a).
$ curl http://127.0.0.1/ $의도한 결과를 얻는 데 비동기 작업을 올바르게 처리하는 것은 분명히 중요합니다. JavaScript는 이를 수행하는 여러 가지 방법을 제공하지만 일반적인 NGINX 사용 사례에서는 실행 흐름을 동기적으로 만드는 방식으로 비동기 함수를 래핑하는 것이 종종 바람직합니다. 여기서 Promiseobject 및 asyncand await키워드가 작용합니다.
ECMAScript 6 (JavaScript용 ECMA‑262 언어 사양의 여섯 번째 에디션)은 Promise객체를 비동기 함수의 반환 유형으로 정의합니다. 다음 세 가지 상태 중 하나로 존재합니다.
키워드로 JavaScript 함수를 정의하면 async함수의 반환 유형이 .으로 설정됩니다 Promise. 객체 를 다루는 njs 함수를 작성할 때 async및 키워드가 중요합니다 .awaitPromise
다음 예를 살펴보세요.
함수 fs.readFile(12번째 줄)는 .을 반환합니다 . 이 함수 는 파일이 user.text 라고 불리는 경우에만 호출되도록 하는 Promise사용자 지정 함수에 래핑됩니다 . 키워드 때문에 래핑 함수는 를 기다리고 데이터를 반환합니다.asyncfs.readFile()awaitPromise
다른 함수로 래핑하면 fs.readFile()오류를 잡기가 더 쉬워집니다. 함수의 모든 예외는 to async의 상태를 설정합니다 . 이를 수행하는 또 다른 방법은 9번째 줄을 거부된 를 반환하는 명령문으로 바꾸는 것입니다 .PromiserejectedPromise
객체 와 직접 작업할 수도 있습니다 Promise. 다음 예에서 함수는 및 각각에 대해 Promise.resolvea를 반환합니다 . 함수는 및 둘 다에 대한 약속이 해결될 때까지 기다린 후 결과를 반환합니다.Promisep1p2Promise.allp1p2
이제 명령의 출력은 curl원하는 내용입니다( b시간 초과 값이 짧기 때문에 먼저 반환됨에 유의하세요).
$ curl http://127.0.0.1/b,a $WebCrypto API를 사용한 새로운 암호화 기능
NGINX JavaScript는 이제 WebCrypto API를 통해 향상된 암호화 기능에 액세스할 수 있습니다 . 일반적인 njs 암호화 사용 사례는 다음과 같습니다.
이 njs 코드는 무작위 숫자를 생성합니다:
그리고 이 NGINX Plus 구성은 njs 코드를 호출합니다:
함수의 출력은 다음과 같은 난수입니다.
$ curl 127.0.0.123225320050,3668407277,1101267190,2061939102,2687933029,2361833213,32543985,4162087386WebCrypto의 함수 getRandomValues는 보안 난수와 WebCrypto를 전반적으로 시작하기에 좋은 진입점입니다. 구현은 매우 간단하고, 함수는 .을 반환하는 것과 달리 결과를 직접 반환합니다 Promise.
그러나 다른 보다 집중적인 WebCrypto 암호화 함수 중 일부는 비동기적으로 작동합니다. 예를 들어, 상태 에 대한 설명서сrypto.subtle.digest() :
주어진 데이터의 다이제스트를 생성합니다. 다이제스트 알고리즘에서 사용할 식별자와 다이제스트할 데이터를 인수로 사용합니다. Promise다이제스트와 함께 충족될 a를 반환합니다.
따라서 직접 호출해도 함수에 래핑 сrypto.subtle.digest()되지 않는 한 결과가 다음 단계에서 사용 가능하다는 보장은 없습니다 . 따라서 여기서는 및 키워드를 async사용하여 함수에 래핑하여 함수가 반환되기 전에 해시 변수에 결과가 채워지도록 합니다.asyncawait
js_set이 NGINX Plus 구성의 지시문은 함수 $hosthash에서 반환된 값 setReturnValue(함수 내에서 래핑됨 host_hash)으로 변수를 채웁니다.
다음은 호스트 이름 example.com을 해시하는 예입니다 .
$ curl -H "Host: example.com" 127.0.0.1# e8e624a82179b53b78364ae14d14d63dfeccd843b026bc8d959ffe0c39fc4ded1f4dcf4c8ebe871e657a12db6f11c3af87c9a1d4f2b096ba3deb56596f06b6f4NGINX 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지침은 컨텍스트에서 추가적인 효율성을 위해 TCP 연결의 각 방향을 독립적으로 닫을 수 있도록 합니다 stream{}.
PCRE2 라이브러리 지원
이전 버전의 NGINX Plus는 Perl Compatible Regular PCRE) 라이브러리 (버전 1)를 사용하여 NGINX 구성에서 사용되는 정규 표현식을 평가합니다. 이 중요한 오픈 소스 프로젝트는 최근 수명이 다하여 PCRE2 로 대체되었습니다 . NGINX Plus는 PCRE2로 빌드되었지만 기본 운영 체제에서 사용 가능한 버전을 사용하여 PCRE와 PCRE2로 빌드된 동적 모듈을 지원합니다. 구성 변경은 필요하지 않습니다.
위 내용과 같이 NGINX Plus 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기