NGINX Plus Release 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+와 통합 – 이 실시간 고정밀 장치 식별자는 사이트를 방문하는 각 장치에 고유 식별자를 할당하여 알려진 불량 행위자에 대한 더 강력한 보호와 방문자를 다시 방문할 때 사용자 경험을 맞춤화할 수 있습니다.
이번 릴리스의 핵심은 필수 상태 검사 결과의 구성 재로드와 쿠키 플래그의 동적 값에 대한 선택적 지속성입니다.
행동의 중요한 변화
더 이상 사용되지 않는 쿠키 플래그 모듈
NGINX Plus R23 출시 시 발표된 대로 타사 Cookie‑Flag 모듈은 더 이상 사용되지 않으며 NGINX Plus R26 의 동적 모듈 리포에서 제거됩니다 . 해당 모듈에서 정의된 지시문은 지시문으로 대체됩니다 . 가능한 한 빨리 구성의 모든 지시문을 지시문으로 대체하는 것이 좋습니다 . 동적 쿠키 플래그 도 참조하세요 .set_cookie_flagproxy_cookie_flagsset_cookie_flagproxy_cookie_flags
플랫폼 지원 변경
- 지원되는 새로운 운영 체제 :
- 알파인 리눅스 3.13(aarch64, amd64)
- CentOS 7.4+ (aarch64, x86_64 및 ppc64le 추가)
- 프리BSD 13(amd64)
- SLES 15 SP2
- 제거된 이전 운영 체제 :
- Debian 9는 더 이상 지원되지 않습니다. 지원되는 가장 오래된 버전은 10입니다.
- NGINX Plus R25 에서 더 이상 지원되지 않고 제거될 예정인 이전 운영 체제 :
- 알파인 리눅스 3.10
- 아마존 리눅스 1 (2018.03+)
- 프리BSD 11
- 우분투 16.04
Amazon Linux 2는 OpenSSL 1.1에 의존합니다.
Amazon Linux 2 용 NGINX Plus 패키지는 이제 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 repo가 이전의 plus-pkgs.nginx.com repo를 대체합니다.
NGINX Plus를 설치하고 업그레이드할 때 운영 체제의 패키지 관리자( apt, , 또는 이와 동등한 것)는 NGINX Plus의 소프트웨어 저장소로 구성됩니다. plus-pkgs.nginx.comyum 저장소를 사용하도록 구성된 기존 시스템에서는 패키지 관리자를 업데이트하여 pkgs.nginx.com/plus(OS 를 나타내는 최종 경로 요소 포함) 를 참조해야 합니다 .
기존 시스템을 NGINX Plus R24 로 업그레이드하는 방법에 대한 지침은 F5 Knowledge Base를 참조하세요 . 초기 설치에 대한 업데이트된 지침은 NGINX Plus 관리자 가이드의 NGINX Plus 설치를 참조하세요.
HTTP 연결 처리 지침의 통합
HTTP/3 표준이 완성에 가까워지고 HTTP/2 사용이 증가함에 따라 , 우리는 장수 연결의 구성 방법을 간소화했습니다. NGINX Plus R24 이상에서는 이전에 HTTP/1.1에만 적용되었던 구성 지시문이 HTTP/2에도 적용됩니다. 더 이상 프로토콜 버전이 다르다는 이유만으로 동일한 기능에 대해 다른 지시문을 사용할 필요가 없습니다.
폐기된 지침교체 지침| http2_idle_timeout | keepalive_timeout |
http2_max_field_size
http2_max_header_size | large_client_header_buffers |
| http2_max_requests | keepalive_requests |
| http2_recv_timeout | client_header_timeout |
더욱 공격적인 연결 종료
NGINX Plus R23 이상에서는 , lingering_close, lingering_time및lingering_timeout 지시어가 HTTP/2와 HTTP/1.1 모두에 적용됩니다. 이러한 지시어로 HTTP/2 연결을 보다 효율적으로 처리하도록 구성하면 NGINX Plus의 전반적인 HTTP/2 기능이 향상됩니다.
NGINX Plus R24는 이러한 지침의 효과를 중요한 방식으로 수정하고 잠재적인 버그를 제거합니다. 즉, 사용 가능한 작업자 연결 풀이 고갈되면 NGINX Plus는 keepalive 연결뿐만 아니라 lingering‑close 모드의 연결도 닫기 시작합니다.
기록된 건강 상태 변경에 대한 심각도 수준 변경
NGINX는 업스트림 서버의 상태가 변경되면 오류 로그 에 항목을 기록합니다 . 이는 인프라의 전반적인 상태를 모니터링하고 분석하는 데 중요한 도구입니다. HTTP 및 TCP/UDP( stream) 업스트림 서버 모두에서 상태 변경이 기록되는 심각도 수준이 변경되었습니다.
- healthy에서 로의 변경은 (이전) 수준 unhealthy에서 기록됩니다 .warninfo
- unhealthy에서 로의 변경은 (이전) 수준 healthy에서 기록됩니다 .noticeinfo
새로운 기능에 대한 자세한 정보
암호화된 JSON 웹 토큰
JSON 웹 토큰( JWT ) 의 사용은 계속해서 증가하고 있습니다. 이전에 NGINX Plus는 서명된 토큰( RFC 7515 에 정의된 JSON 웹 서명[JWS] 표준 )을 지원했으며, 이는 토큰에 인코딩된 클레임에 대한 데이터 무결성을 제공합니다. 그러나 JWS는 클레임에 대한 기밀성을 제공하지 않습니다. 토큰에 액세스할 수 있는 모든 구성 요소에서 클레임을 읽을 수 있습니다. TLS/SSL은 전송 중인 토큰에 대한 노출을 완화하지만 웹 브라우저 및 기타 클라이언트에 저장된 토큰은 여전히 노출됩니다.
NGINX Plus R24는 암호화된 토큰( RFC 7516 에 정의된 JSON 웹 암호화[JWE] 표준 )에 대한 지원을 도입하여 전체 클레임 세트에 대한 기밀성과 데이터 무결성을 모두 제공합니다. 민감하거나 개인 식별 정보(PII)는 이제 보안되지 않은 클라이언트에 의해 데이터가 유출될 위험 없이 JWT 내부에 인코딩될 수 있습니다.
NGINX Plus R24 이상은 서명된 JWT와 암호화된 JWT를 모두 지원합니다. 서명된 토큰이 기본값이며 명시적 구성이 필요하지 않습니다. 새 auth_jwt_type지시문은 JWT 암호화를 구성합니다.
| location /private/ { |
| auth_jwt "Private"; |
| auth_jwt_type encrypted; |
| auth_jwt_key_file conf/api_secret.jwk; |
|
|
| proxy_pass http://my_backend; |
| } |
view rawjwe.conf hosted with ❤ by GitHub
지시문으로 명명된 JWT 키 파일에서 암호화(또는 서명) 알고리즘과 키 사용을 정의합니다 auth_jwt_key_file. 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는 NGINX JavaScript 모듈(njs) 개발에서 중요한 이정표를 세웠으며, 현재 버전은 0.5.3 입니다 . 다양한 사용 사례에 대한 사용자 정의 솔루션으로 NGINX Plus를 확장할 수 있도록 하는 두 가지 중요한 개선 사항이 있습니다.
- HTTP 응답의 헤더와 본문 모두에 대한 응답 필터링
- HTTP 또는 TCP/UDP 처리 중에 HTTP 요청을 하는 데 사용할 수 있는 내장 HTTP 클라이언트
NGINX JavaScript 모듈에 익숙하지 않으시다면 저희 블로그<.htmla>에서 이 소개글을 읽어보세요.
[ 이 섹션에 설명된 사용 사례는 NGINX JavaScript 모듈에 대한 많은 사용 사례 중 일부에 불과합니다. 전체 목록은 NGINX JavaScript 모듈에 대한 사용 사례를 참조하세요 . ]
응답 필터링
API 게이트웨이 또는 역방향 프록시로 배포된 NGINX Plus의 가장 강력한 기능 중 하나는 응답 필터링 으로 , 이는 업스트림 서버의 응답을 가로채고 정규 표현식 매칭에 따라 응답 본문, 헤더 또는 둘 다의 문자열을 대체하는 것을 포함합니다. NGINX JavaScript 모듈로 조작되지 않는 트래픽의 경우 응답 필터링은 Substitution 모듈에 구현됩니다.
NGINX Plus R24는 NGINX JavaScript 모듈 내에서 응답 필터링의 별도 구현을 도입하여 JavaScript의 힘을 활용하여 응답 본문과 헤더를 분석하고 수정할 수 있는 두 가지 지시문을 제공합니다. JavaScript는 정규 표현식을 기반으로 하는 간단한 문자열 대체를 훨씬 넘어서 검사 및 조작 가능성을 확장하여 Substitution 모듈보다 훨씬 강력한 응답 필터링을 제공합니다.
js_body_filter지시문을 사용하여 응답 본문 필터링
지시문을 사용하면 js_body_filterJavaScript를 사용하여 프록시 서버에서 응답 본문을 검사하고 수정할 수 있습니다. 사용 사례는 다음과 같습니다.
- 정규 표현식을 사용하여 복잡한 패턴 스캔
- 데이터 형식 변환
- 응답에 동적 콘텐츠 삽입
이 예에서는 AWS 액세스 키처럼 보이는 모든 항목에 대한 응답을 스캔하고 그러한 항목이 있으면 마스크된 값으로 바꿉니다.
| var response = ""; |
|
|
| function maskAwsKeys(r, data, flags) { |
| response += data; // Collect the entire response, |
| if (flags.last) { // until we get the last byte. |
| var masked = response.replace(/([^A-Z0-9]|^)(AKIA|A3T|AGPA|AIDA|AROA|AIPA|ANPA|ANVA|ASIA)([A-Z0-9]{12,})/g, |
| function ($0, $1) { |
| return $1 + (new Array($0.length).join('*')); |
| } |
| ); |
| r.sendBuffer(masked, flags); |
| } |
| } |
|
|
| export default { maskAwsKeys } |
view rawfilter.js hosted with ❤ by GitHub
maskAwsKeys이 코드를 실행하려면 해당 블록 내부의 함수를 참조하기만 하면 됩니다 location.
| js_import conf.d/filter.js; |
|
|
| server { |
| listen 80; |
| location / { |
| proxy_pass http://my_backend; |
| js_body_filter filter.maskAwsKeys; |
| } |
| } |
view rawproxy_mask.conf hosted with ❤ by GitHub
js_header_filter지시문을 사용하여 응답 헤더 필터링
js_header_filter지시문을 사용하여 응답 헤더의 내용을 조사하거나 가로채서 수정할 수 있습니다. Set-Cookie민감한 정보를 포함하지만 올바른 작업에 필수적인 여러 헤더를 발행하는 백엔드 서버를 고려합니다. NGINX Plus는 응답을 가로채고 헤더를 읽고 Set-Cookie키-값 저장소에 저장할 수 있습니다. 대체 Set-Cookie헤더는 키-값 저장소에 대한 참조로 생성되어 원래 응답에 삽입될 수 있습니다.
js_header_filter키-값 저장소와의 상호 작용을 보여주는 요청 흐름
NGINX Plus 구성의 4~5행에서 키-값 저장소를 정의합니다.
| js_import conf.d/cookies.js; |
|
|
| keyval_zone zone=cookie_jar:16M; |
| keyval $cookie_session $cookies zone=cookie_jar; |
| keyval $request_id $new_session zone=cookie_jar; |
view rawproxy.conf hosted with ❤ by GitHub
그런 다음 12~13번째 줄에서는 참조 쿠키를 키-값 저장소의 내용으로 바꾸고 JavaScript 코드로 새로운 쿠키를 가로챕니다.
| server { |
| listen 80; |
|
|
| location / { |
| proxy_pass http://my_backend; |
| proxy_set_header Cookie $cookies; # Replace reference cookie with original |
| js_header_filter cookies.jar; # Intercept and replace Set-Cookie |
| } |
| } |
view rawproxy.conf hosted with ❤ by GitHub
JavaScript 코드는 새로운 응답 헤더를 반복 Set-Cookie하고 이를 저장할 새로운 키-값 항목을 만듭니다.
| function jar(r) { |
| // Replace Set-Cookie response headers with an opaque reference |
| if (r.headersOut['Set-Cookie'].length) { |
| var kvs = []; |
| r.headersOut['Set-Cookie'].forEach(c => kvs.push(c.split(';')[0])); // Omit cookie flags |
| r.variables.new_session = kvs.join('; '); // Store in keyval cookie jar |
| r.headersOut['Set-Cookie'] = "session=" + r.variables.request_id + "; SameSite=Lax"; |
| } |
| } |
|
|
| export default { jar } |
view rawcookies.js hosted with ❤ by GitHub
간단한 HTTP 클라이언트를 사용하여 TCP/UDP에 대한 HTTP 서비스 활용
API 게이트웨이의 주요 사용 사례는 특정 리소스에 대한 액세스를 제어하는 것입니다. NGINX Plus는 HTTP 요청에 대해 레이어 7에서 강력한 인증 및 액세스 제어 기능 세트를 지원하지만 최신 API 구현은 TCP/UDP를 기본 프로토콜로 활용하여 새로운 인증 과제를 제시합니다.
내장된 NGINX JavaScript ngx.fetch함수를 사용하면 이제 TCP/UDP 연결 컨텍스트 내에서 간단한 HTTP 클라이언트를 인스턴스화할 수 있습니다. 이를 통해 컨텍스트에서 액세스 제어를 위해 HTTP 기반 인증 서비스를 사용할 수 있습니다 stream(예: 데이터베이스 연결을 프록시할 때 로컬 OpenPolicy Agent 데몬 호출).
이 예제는 포트 8085에서 로컬 HTTP 인증 서비스를 사용하여 각 새 연결을 인증하는 방법을 보여줍니다. 지시문 js_access과 ngx.fetch함수는 새로 인스턴스화된 HTTP 컨텍스트에서 하위 요청의 결과에 따라 클라이언트 권한 부여와 유사한 기능을 함께 구현합니다(일반 HTTP 요청에 대한 지시문에서 구현 ). 개체auth_request 에서 사용할 수 있는 HTTP 상태 코드에 따라 백엔드 데이터베이스에 대한 연결이 허용( )되거나 거부( )됩니다.Responses.allows.deny
| stream { |
| js_import stream.js; |
|
|
| server { |
| listen 3306; # MySQL default port |
|
|
| js_access stream.access; |
| proxy_pass mysql_backend; |
| } |
| } |
view rawstream.conf hosted with ❤ by GitHub
| function access(s) { |
| ngx.fetch('http://127.0.0.1:8085/') |
| .then(response => { |
| if (response.ok) { |
| s.allow(); |
| return; |
| } |
| }) |
| .then(body => {}) |
| .catch(e => r.return(501, e.message)) |
|
|
| s.deny(); |
| return; |
| } |
|
|
| export default { access } |
view rawstream.js hosted with ❤ by GitHub
참고: 이 ngx.fetch기능은 NGINX JavaScript HTTP 모듈과 NGINX JavaScript Stream 모듈에서 작동하지만 r.subrequestHTTP 모듈의 객체에 비해 상당한 제한이 있습니다. 대부분의 HTTP 사용 사례에서는 TLS 연결, 캐싱 및 Proxy 모듈r.subrequest 의 모든 기능을 지원하므로 선호됩니다 .
기타 njs 향상
set[ HTTP ][ Stream ] 또는 js_set[ HTTP ][ Stream ] 지시문 으로 NGINX 변수가 정의된 경우 요청 처리가 리디렉션을 만나면 값이 재정의될 수 있습니다. 새로운 js_var[ HTTP ][ Stream ] 지시문을 사용하면 JavaScript 함수에서 변수를 평가하고 해당 값을 리디렉션 간에 유지할 수 있습니다.
새로운 njs.on객체는 njs 가상 머신이 종료될 때 JavaScript 함수를 실행할 수 있도록 합니다. 예를 들어, TCP 연결이 끝날 때 함수를 실행하는 데 사용할 수 있습니다.
Stream 세션 객체의 새로운 s.status속성은 전체 세션 상태에 대한 액세스를 제공합니다( $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_checkmandatory
| upstream my_backend { |
| zone my_backend 64k; |
| server 10.0.0.1; |
| server 10.0.0.2; |
| } |
|
|
| server { |
| #... |
| location / { |
| proxy_pass http://my_backend; |
| health_check mandatory persistent; |
| } |
| } |
view rawpersistent.conf hosted with ❤ by GitHub
동적 쿠키 플래그
이전 NGINX Plus 릴리스에서 쿠키 플래그를 설정하기 위한 기본 방법proxy_cookie_flags 으로 지시문을 도입했습니다 . NGINX Plus R24는 쿠키 플래그에 대한 동적 값을 활성화하여 이 기능을 확장합니다. 이를 통해 특정 쿠키 플래그를 NGINX 변수로 제어할 수 있습니다.
참고: 이 지시문은 NGINX Plus R26proxy_cookie_flags 에서 제거될 Cookie‑Flag 모듈을 더 이상 사용하지 않습니다 . 더 이상 사용하지 않는 Cookie‑Flag 모듈을 참조하세요 .
이 예제에서는 스키마가 http 가 아닌 https 일 때 쿠키 플래그를 활성화하기 위해 맵을 사용합니다 .Secure
| map $scheme $secure_flag { |
| http ''; |
| https 'Secure'; |
| } |
|
|
| server { |
| #... |
| location / { |
| proxy_cookie_flags appcookie HttpOnly SameSite=strict $secure_flag; |
| proxy_pass http://my_backend; |
| } |
| } |
view rawcookie_flags.conf hosted with ❤ by GitHub
위 내용과 같이 NGINX Plus 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
NGINX Plus Release 24(R24) 의 출시를 발표하게 되어 기쁩니다 . NGINX Open Source를 기반으로 하는 NGINX Plus는 유일한 올인원 소프트웨어 웹 서버, 로드 밸런서, 리버스 프록시, 콘텐츠 캐시 및 API 게이트웨이입니다.
NGINX Plus R24 의 새로운 기능은 다음과 같습니다.
이번 릴리스의 핵심은 필수 상태 검사 결과의 구성 재로드와 쿠키 플래그의 동적 값에 대한 선택적 지속성입니다.
행동의 중요한 변화
더 이상 사용되지 않는 쿠키 플래그 모듈
NGINX Plus R23 출시 시 발표된 대로 타사 Cookie‑Flag 모듈은 더 이상 사용되지 않으며 NGINX Plus R26 의 동적 모듈 리포에서 제거됩니다 . 해당 모듈에서 정의된 지시문은 지시문으로 대체됩니다 . 가능한 한 빨리 구성의 모든 지시문을 지시문으로 대체하는 것이 좋습니다 . 동적 쿠키 플래그 도 참조하세요 .set_cookie_flagproxy_cookie_flagsset_cookie_flagproxy_cookie_flags
플랫폼 지원 변경
Amazon Linux 2는 OpenSSL 1.1에 의존합니다.
Amazon Linux 2 용 NGINX Plus 패키지는 이제 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 repo가 이전의 plus-pkgs.nginx.com repo를 대체합니다.
NGINX Plus를 설치하고 업그레이드할 때 운영 체제의 패키지 관리자( apt, , 또는 이와 동등한 것)는 NGINX Plus의 소프트웨어 저장소로 구성됩니다. plus-pkgs.nginx.comyum 저장소를 사용하도록 구성된 기존 시스템에서는 패키지 관리자를 업데이트하여 pkgs.nginx.com/plus(OS 를 나타내는 최종 경로 요소 포함) 를 참조해야 합니다 .
기존 시스템을 NGINX Plus R24 로 업그레이드하는 방법에 대한 지침은 F5 Knowledge Base를 참조하세요 . 초기 설치에 대한 업데이트된 지침은 NGINX Plus 관리자 가이드의 NGINX Plus 설치를 참조하세요.
HTTP 연결 처리 지침의 통합
HTTP/3 표준이 완성에 가까워지고 HTTP/2 사용이 증가함에 따라 , 우리는 장수 연결의 구성 방법을 간소화했습니다. NGINX Plus R24 이상에서는 이전에 HTTP/1.1에만 적용되었던 구성 지시문이 HTTP/2에도 적용됩니다. 더 이상 프로토콜 버전이 다르다는 이유만으로 동일한 기능에 대해 다른 지시문을 사용할 필요가 없습니다.
폐기된 지침교체 지침http2_max_header_size
더욱 공격적인 연결 종료
NGINX Plus R23 이상에서는 , lingering_close, lingering_time및lingering_timeout 지시어가 HTTP/2와 HTTP/1.1 모두에 적용됩니다. 이러한 지시어로 HTTP/2 연결을 보다 효율적으로 처리하도록 구성하면 NGINX Plus의 전반적인 HTTP/2 기능이 향상됩니다.
NGINX Plus R24는 이러한 지침의 효과를 중요한 방식으로 수정하고 잠재적인 버그를 제거합니다. 즉, 사용 가능한 작업자 연결 풀이 고갈되면 NGINX Plus는 keepalive 연결뿐만 아니라 lingering‑close 모드의 연결도 닫기 시작합니다.
기록된 건강 상태 변경에 대한 심각도 수준 변경
NGINX는 업스트림 서버의 상태가 변경되면 오류 로그 에 항목을 기록합니다 . 이는 인프라의 전반적인 상태를 모니터링하고 분석하는 데 중요한 도구입니다. HTTP 및 TCP/UDP( stream) 업스트림 서버 모두에서 상태 변경이 기록되는 심각도 수준이 변경되었습니다.
새로운 기능에 대한 자세한 정보
암호화된 JSON 웹 토큰
JSON 웹 토큰( JWT ) 의 사용은 계속해서 증가하고 있습니다. 이전에 NGINX Plus는 서명된 토큰( RFC 7515 에 정의된 JSON 웹 서명[JWS] 표준 )을 지원했으며, 이는 토큰에 인코딩된 클레임에 대한 데이터 무결성을 제공합니다. 그러나 JWS는 클레임에 대한 기밀성을 제공하지 않습니다. 토큰에 액세스할 수 있는 모든 구성 요소에서 클레임을 읽을 수 있습니다. TLS/SSL은 전송 중인 토큰에 대한 노출을 완화하지만 웹 브라우저 및 기타 클라이언트에 저장된 토큰은 여전히 노출됩니다.
NGINX Plus R24는 암호화된 토큰( RFC 7516 에 정의된 JSON 웹 암호화[JWE] 표준 )에 대한 지원을 도입하여 전체 클레임 세트에 대한 기밀성과 데이터 무결성을 모두 제공합니다. 민감하거나 개인 식별 정보(PII)는 이제 보안되지 않은 클라이언트에 의해 데이터가 유출될 위험 없이 JWT 내부에 인코딩될 수 있습니다.
NGINX Plus R24 이상은 서명된 JWT와 암호화된 JWT를 모두 지원합니다. 서명된 토큰이 기본값이며 명시적 구성이 필요하지 않습니다. 새 auth_jwt_type지시문은 JWT 암호화를 구성합니다.
지시문으로 명명된 JWT 키 파일에서 암호화(또는 서명) 알고리즘과 키 사용을 정의합니다 auth_jwt_key_file. NGINX Plus R24 이상은 다음 암호화 방법을 지원합니다.
NGINX JavaScript 모듈의 주요 성숙 이정표
NGINX Plus R24는 NGINX JavaScript 모듈(njs) 개발에서 중요한 이정표를 세웠으며, 현재 버전은 0.5.3 입니다 . 다양한 사용 사례에 대한 사용자 정의 솔루션으로 NGINX Plus를 확장할 수 있도록 하는 두 가지 중요한 개선 사항이 있습니다.
NGINX JavaScript 모듈에 익숙하지 않으시다면 저희 블로그<.htmla>에서 이 소개글을 읽어보세요.
[ 이 섹션에 설명된 사용 사례는 NGINX JavaScript 모듈에 대한 많은 사용 사례 중 일부에 불과합니다. 전체 목록은 NGINX JavaScript 모듈에 대한 사용 사례를 참조하세요 . ]
응답 필터링
API 게이트웨이 또는 역방향 프록시로 배포된 NGINX Plus의 가장 강력한 기능 중 하나는 응답 필터링 으로 , 이는 업스트림 서버의 응답을 가로채고 정규 표현식 매칭에 따라 응답 본문, 헤더 또는 둘 다의 문자열을 대체하는 것을 포함합니다. NGINX JavaScript 모듈로 조작되지 않는 트래픽의 경우 응답 필터링은 Substitution 모듈에 구현됩니다.
NGINX Plus R24는 NGINX JavaScript 모듈 내에서 응답 필터링의 별도 구현을 도입하여 JavaScript의 힘을 활용하여 응답 본문과 헤더를 분석하고 수정할 수 있는 두 가지 지시문을 제공합니다. JavaScript는 정규 표현식을 기반으로 하는 간단한 문자열 대체를 훨씬 넘어서 검사 및 조작 가능성을 확장하여 Substitution 모듈보다 훨씬 강력한 응답 필터링을 제공합니다.
js_body_filter지시문을 사용하여 응답 본문 필터링
지시문을 사용하면 js_body_filterJavaScript를 사용하여 프록시 서버에서 응답 본문을 검사하고 수정할 수 있습니다. 사용 사례는 다음과 같습니다.
이 예에서는 AWS 액세스 키처럼 보이는 모든 항목에 대한 응답을 스캔하고 그러한 항목이 있으면 마스크된 값으로 바꿉니다.
maskAwsKeys이 코드를 실행하려면 해당 블록 내부의 함수를 참조하기만 하면 됩니다 location.
js_header_filter지시문을 사용하여 응답 헤더 필터링
js_header_filter지시문을 사용하여 응답 헤더의 내용을 조사하거나 가로채서 수정할 수 있습니다. Set-Cookie민감한 정보를 포함하지만 올바른 작업에 필수적인 여러 헤더를 발행하는 백엔드 서버를 고려합니다. NGINX Plus는 응답을 가로채고 헤더를 읽고 Set-Cookie키-값 저장소에 저장할 수 있습니다. 대체 Set-Cookie헤더는 키-값 저장소에 대한 참조로 생성되어 원래 응답에 삽입될 수 있습니다.
NGINX Plus 구성의 4~5행에서 키-값 저장소를 정의합니다.
JavaScript 코드는 새로운 응답 헤더를 반복 Set-Cookie하고 이를 저장할 새로운 키-값 항목을 만듭니다.
간단한 HTTP 클라이언트를 사용하여 TCP/UDP에 대한 HTTP 서비스 활용
API 게이트웨이의 주요 사용 사례는 특정 리소스에 대한 액세스를 제어하는 것입니다. NGINX Plus는 HTTP 요청에 대해 레이어 7에서 강력한 인증 및 액세스 제어 기능 세트를 지원하지만 최신 API 구현은 TCP/UDP를 기본 프로토콜로 활용하여 새로운 인증 과제를 제시합니다.
내장된 NGINX JavaScript ngx.fetch함수를 사용하면 이제 TCP/UDP 연결 컨텍스트 내에서 간단한 HTTP 클라이언트를 인스턴스화할 수 있습니다. 이를 통해 컨텍스트에서 액세스 제어를 위해 HTTP 기반 인증 서비스를 사용할 수 있습니다 stream(예: 데이터베이스 연결을 프록시할 때 로컬 OpenPolicy Agent 데몬 호출).
이 예제는 포트 8085에서 로컬 HTTP 인증 서비스를 사용하여 각 새 연결을 인증하는 방법을 보여줍니다. 지시문 js_access과 ngx.fetch함수는 새로 인스턴스화된 HTTP 컨텍스트에서 하위 요청의 결과에 따라 클라이언트 권한 부여와 유사한 기능을 함께 구현합니다(일반 HTTP 요청에 대한 지시문에서 구현 ). 개체auth_request 에서 사용할 수 있는 HTTP 상태 코드에 따라 백엔드 데이터베이스에 대한 연결이 허용( )되거나 거부( )됩니다.Responses.allows.deny
참고: 이 ngx.fetch기능은 NGINX JavaScript HTTP 모듈과 NGINX JavaScript Stream 모듈에서 작동하지만 r.subrequestHTTP 모듈의 객체에 비해 상당한 제한이 있습니다. 대부분의 HTTP 사용 사례에서는 TLS 연결, 캐싱 및 Proxy 모듈r.subrequest 의 모든 기능을 지원하므로 선호됩니다 .
기타 njs 향상
set[ HTTP ][ Stream ] 또는 js_set[ HTTP ][ Stream ] 지시문 으로 NGINX 변수가 정의된 경우 요청 처리가 리디렉션을 만나면 값이 재정의될 수 있습니다. 새로운 js_var[ HTTP ][ Stream ] 지시문을 사용하면 JavaScript 함수에서 변수를 평가하고 해당 값을 리디렉션 간에 유지할 수 있습니다.
새로운 njs.on객체는 njs 가상 머신이 종료될 때 JavaScript 함수를 실행할 수 있도록 합니다. 예를 들어, TCP 연결이 끝날 때 함수를 실행하는 데 사용할 수 있습니다.
Stream 세션 객체의 새로운 s.status속성은 전체 세션 상태에 대한 액세스를 제공합니다( $status가능한 값은 참조).
F5 Device ID+와 통합
F5 Device ID+는 고급 신호 수집 및 검증된 머신 러닝 알고리즘을 활용하여 사이트를 방문하는 각 기기에 고유한 식별자를 할당하는 실시간 고정밀 기기 식별자입니다. 배포가 간단하며 보안, 네트워킹, 사기 및 디지털 팀에 즉각적인 이점이 있습니다. 애플리케이션을 방문하는 고유한 기기를 이해하는 것이 그 어느 때보다 쉬워졌습니다.
NGINX Plus 인스턴스에서 F5 Device ID+를 활성화하는 방법에 대한 자세한 내용은 F5 Device ID+를 사용하여 사기 및 위험 완화를 참조하세요 .
F5 Device ID+ 사용의 이점
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_checkmandatory
동적 쿠키 플래그
이전 NGINX Plus 릴리스에서 쿠키 플래그를 설정하기 위한 기본 방법proxy_cookie_flags 으로 지시문을 도입했습니다 . NGINX Plus R24는 쿠키 플래그에 대한 동적 값을 활성화하여 이 기능을 확장합니다. 이를 통해 특정 쿠키 플래그를 NGINX 변수로 제어할 수 있습니다.
참고: 이 지시문은 NGINX Plus R26proxy_cookie_flags 에서 제거될 Cookie‑Flag 모듈을 더 이상 사용하지 않습니다 . 더 이상 사용하지 않는 Cookie‑Flag 모듈을 참조하세요 .
이 예제에서는 스키마가 http 가 아닌 https 일 때 쿠키 플래그를 활성화하기 위해 맵을 사용합니다 .Secure
위 내용과 같이 NGINX Plus 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기