NGINX Plus R24 발표

NGINX Plus 릴리스 24(R24)가 출시되어 기쁩니다. NGINX 오픈 소스를 기반으로 하는 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_flag 지시어는 proxy_cookie_flags 지시어로 대체됩니다. 가능한 한 빨리 구성에서 set_cookie_flag 지시문을 proxy_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 패키지는 이제 TLS 1.3을 지원하고 다양한 방법으로 보안을 강화하는 OpenSSL 1.1에 의존합니다 . 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 repo를 사용하도록 구성된 기존 시스템에서는 패키지 관리자를 업데이트하여 pkgs.nginx.com/plus (및 OS를 나타내는 마지막 경로 요소)를 참조해야 합니다.

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

HTTP 연결 처리 지침의 통합

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

더욱 공격적인 연결 종료

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( 스트림 ) 업스트림 서버 모두에서 변경되었습니다.

• 정상 에서 비정상 으로의 변화는 경고 수준( 정보 수준 )에서 기록됩니다.
• 건강하지 않음 에서 건강함으로 의 변화는 알림 수준( 정보 )에서 기록됩니다.

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

암호화된 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 암호화를 구성합니다.

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

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_filter 지시문을 사용하면 JavaScript를 사용하여 프록시 서버에서 보낸 응답 본문을 검사하고 수정할 수 있습니다. 사용 사례는 다음과 같습니다.

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

이 예에서는 AWS 액세스 키처럼 보이는 모든 항목에 대한 응답을 스캔하고 그러한 항목이 있으면 마스크된 값으로 바꿉니다.

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

js_header_filter 지시문을 사용하여 응답 헤더 필터링

js_header_filter 지시문을 사용하면 응답 헤더의 내용을 조사하거나 가로채서 수정할 수도 있습니다. 올바른 작동에 필수적인 민감한 정보를 포함하는 여러 개의 Set-Cookie 헤더를 발행하는 백엔드 서버를 생각해 보세요. NGINX Plus는 응답을 가로채고, Set-Cookie 헤더를 읽고, 이를 키-값 저장소에 저장할 수 있습니다. 대체 Set-Cookie 헤더는 키-값 저장소에 대한 참조로 생성되어 원래 응답에 삽입될 수 있습니다.

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 클라이언트를 인스턴스화할 수 있습니다. 이를 통해 스트림 컨텍스트에서 액세스 제어를 위해 HTTP 기반 인증 서비스를 사용할 수 있습니다. 예를 들어, 데이터베이스 연결을 프록시할 때 로컬 OpenPolicy Agent 데몬을 호출할 수 있습니다.

이 예제는 포트 8085에서 로컬 HTTP 인증 서비스를 사용하여 각각의 새로운 연결을 인증하는 방법을 보여줍니다. js_access 지시어와 ngx.fetch 함수는 새로 인스턴스화된 HTTP 컨텍스트에서 기능을 구현하는데, 이는 일반 HTTP 요청에 대한 auth_request 지시어에서 구현된 것과 같이 하위 요청의 결과에 따른 클라이언트 권한 부여와 비슷합니다. 응답 객체 에서 사용할 수 있는 HTTP 상태 코드에 따라 백엔드 데이터베이스에 대한 연결이 허용( s.allow )되거나 거부( s.deny )됩니다.

메모: ngx.fetch 함수는 NGINX JavaScript HTTP 모듈과 NGINX JavaScript Stream 모듈에서 모두 작동하지만 HTTP 모듈의 r.subrequest 객체에 비해 상당한 제한이 있습니다. 대부분의 HTTP 사용 사례에서는 TLS 연결, 캐싱 및 프록시 모듈 의 모든 기능을 지원하므로 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 상태 검사를 지속적인 것으로 표시하여 구성을 다시 로드할 때 이전 상태가 기억되도록 할 수 있습니다. 필수 매개변수와 함께 health_check 지시문에 지속성 매개변수를 추가합니다.

동적 쿠키 플래그

NGINX Plus의 이전 릴리스에서는 쿠키 플래그를 설정하기 위한 기본 방법 으로 proxy_cookie_flags 지시문을 도입했습니다. NGINX Plus R24는 쿠키 플래그에 대한 동적 값을 활성화하여 이 기능을 확장합니다. 이를 통해 특정 쿠키 플래그를 NGINX 변수로 제어할 수 있습니다.

메모: proxy_cookie_flags 지시어는 NGINX Plus R26 에서 제거될 Cookie‑Flag 모듈을 더 이상 사용하지 않습니다. 더 이상 사용되지 않는 쿠키 플래그 모듈을 참조하세요.

이 예제에서는 스키마가 http 가 아닌 https 인 경우 보안 쿠키 플래그를 활성화하기 위해 맵을 사용합니다.

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

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

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