NGINX Plus R24リリースのお知らせ

NGINX Plus Release 24（R24）の提供開始をお知らせします。NGINX Open SourceをベースとするNGINX Plusは、Webサーバー、ロードバランサー、リバースプロキシ、コンテンツキャッシュ、APIゲートウェイの機能を1つに統合した唯一のソフトウェアです。

NGINX Plus R24の新機能は次のとおりです。

• 暗号化されたJSON Web Token – 以前のリリースで対応した署名付きJSON Web Token（JWT）に加え、NGINX Plusは暗号化されたJWTにも対応しました。これにより、機密情報をWebブラウザーやその他のクライアントに保存する際の機密性とデータ整合性を確保できます。
• NGINX JavaScript Moduleの開発における大きな節目 – 新機能、特にHTTPヘッダーと本文の両方に対応するレスポンスフィルタリング、およびTCP/UDP接続とセッション向けのHTTPベース認証サービスのサポートにより、さまざまな強力な新しいユースケースが可能になります。
• F5 Device ID+との統合 – このリアルタイムかつ高精度のデバイス識別機能は、サイトにアクセスする各デバイスに一意の識別子を割り当てます。これにより、既知の悪意ある攻撃者に対する保護を強化し、再訪問者に合わせたユーザーエクスペリエンスを提供できます。

このリリースを締めくくる機能として、必須ヘルスチェックの結果を構成の再読み込み後も保持できるオプションと、Cookieフラグの動的な値が追加されています。

動作に関する重要な変更

非推奨となったCookie-Flagモジュール

NGINX Plus R23のリリース時に発表したとおり、サードパーティ製のCookie-Flagモジュールは非推奨となっており、NGINX Plus R26で動的モジュールリポジトリから削除されます。このモジュールで定義されているset_cookie_flagディレクティブは、proxy_cookie_flagsディレクティブに置き換えられます。設定内のset_cookie_flagディレクティブは、できるだけ早くproxy_cookie_flagsディレクティブに置き換えることを推奨します。あわせて「動的Cookieフラグ」も参照してください。

プラットフォームサポートの変更

• 新たにサポートされるオペレーティングシステム：
  • 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に依存

The NGINX Plus package for 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リポジトリが従来のplus-pkgs.nginx.comリポジトリに代わります。

NGINX Plusをインストールまたはアップグレードすると、オペレーティングシステムのパッケージマネージャー（apt、yum、または同等のもの）にNGINX Plusのソフトウェアリポジトリが設定されます。plus-pkgs.nginx.comリポジトリを使用するように設定されている既存のシステムでは、パッケージマネージャーの参照先をpkgs.nginx.com/plus（およびOSを示す末尾のパス要素）に更新する必要があります。

既存のシステムを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はキープアライブ接続だけでなく、lingering-closeモードの接続も閉じ始めます。

ヘルスステータスの変更を記録する際の重大度レベルの変更

アップストリームサーバーのヘルスステータスが変化すると、NGINXはエラーログにエントリを書き込みます。これは、インフラストラクチャ全体の健全性を監視および分析するための重要な手段です。ステータスの変化を記録する際の重大度レベルが、HTTPとTCP/UDP（stream）の両方のアップストリームサーバーで変更されました。

• Change from healthyからunhealthyへの変更は、warnレベルでログに記録されます（以前はinfoレベル）。
• 変更前：unhealthy、変更後：healthy。ログレベルはnoticeです（以前はinfo）。

新機能の詳細

暗号化されたJSON Web Token

JSON Web Token（JWT）の利用は拡大し続けています。これまでNGINX Plusは、RFC 7515で定義されているJSON Web Signature（JWS）標準に準拠した署名付きトークンをサポートし、トークンにエンコードされたクレームのデータ整合性を確保していました。しかし、JWSではクレームの機密性は確保されません。トークンにアクセスできるコンポーネントであれば、クレームを読み取ることができます。TLS/SSLにより転送中のトークンが漏えいするリスクは軽減されますが、Webブラウザーやその他のクライアントに保存されたトークンは、依然として漏えいのリスクにさらされています。

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 Moduleの成熟度における大きな節目

NGINX Plus R24は、現在バージョン0.5.3となったNGINX JavaScriptモジュール（njs）の開発における大きな節目です。幅広いユースケースに対応するカスタムソリューションでNGINX Plusを拡張できる、2つの重要な機能強化が加わりました。

• レスポンスフィルタリング（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の特に強力な機能の1つが、レスポンスフィルタリングです。この機能は、アップストリームサーバーからのレスポンスをインターセプトし、正規表現によるマッチングに基づいて、レスポンス本文、ヘッダー、またはその両方の文字列を置換します。NGINX JavaScriptモジュールで操作されないトラフィックについては、レスポンスフィルタリングはSubstitutionモジュールで実装されます。

NGINX Plus R24では、NGINX JavaScriptモジュール内にレスポンスフィルタリングの別の実装が導入されました。2つのディレクティブにより、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ヘッダーを読み取ってKey-Valueストアに保存できます。Key-Valueストアへの参照として代替のSet-Cookieヘッダーを作成し、元のレスポンスに挿入できます。

キーバリューストアとjs_header_filterの連携を示すリクエストフロー

NGINX Plus構成の4～5行目で、キー・バリューストアを定義します。

コード例を読み込み中…

次に、12～13行目で参照Cookieをキーバリューストアの内容に置き換え、新しいCookieを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認証サービスを使用して、新しい接続ごとに認証する方法を示します。新たにインスタンス化されたHTTPコンテキストでは、js_accessディレクティブとngx.fetch関数を組み合わせることで、サブリクエストの結果に基づくクライアント認可と同様の機能を実装します（通常の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 moduleのすべての機能を利用できるため、こちらの使用を推奨します。

その他のnjs機能強化

NGINX変数をset［HTTP］［Stream］またはjs_set［HTTP］［Stream］ディレクティブで定義した場合、リクエスト処理中にリダイレクトが発生すると、その値が上書きされることがあります。新しい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のデータを操作した場合でも、デバイスを識別できます。
• 不正行為とリスクを軽減 – 新規アカウントの作成、ユーザー認証、eコマースでの決済、金融取引など、一連の操作における顧客の行動を監視し、個人情報の盗難をはじめとする脅威の兆候となり得る異常なパターンを検出します。
• オンライン体験のパーソナライズと迅速化 – 既知の再訪ユーザーやデバイスが、ログイン、チェックアウト、認証をスムーズに行えるようにします。F5によるA/Bテストでは、セキュリティ上の摩擦を減らすことで収益が増加することが実証されており、デバイス識別は、摩擦を軽減するあらゆる戦略において重要な要素です。

F5 Device ID+の仕組み

各ユーザーがWebサイトにアクセスすると、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パラメーターとともに追加します。

コード例を読み込み中…

動的Cookieフラグ

NGINX Plusの前回のリリースでは、Cookieフラグを設定するproxy_cookie_flagsディレクティブをネイティブな方法として導入しました。NGINX Plus R24では、Cookieフラグに動的な値を使用できるよう、この機能を拡張しています。これにより、特定のCookieフラグを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を備え、フルサポート付きのWebサーバーとしても活用できます。今すぐ30日間の無料トライアルを開始できます。

---