ブログ | NGINX

NGINX Plus R26 の発表

NGINX-F5 水平黒タイプ RGB の一部
ロバート・ヘインズ サムネイル
ロバート・ヘインズ
2022年2月15日公開

NGINX Plus リリース 26 (R26)が利用可能になったことをお知らせします。 NGINX オープンソースをベースにした NGINX Plus は、唯一のオールインワンソフトウェア Web サーバー、ロード バランサー、リバース プロキシ、コンテンツ キャッシュ、API ゲートウェイです。

NGINX Plus R26の新機能と強化された機能は次のとおりです。

  • JSON Web キー セット キャッシュによる JWT 検証の高速化- 過去数回のリリースで追加された JSON Web Token (JWT) サポートの一連の機能強化に続き、JSON Web キー セット (JWKS) のインメモリ キャッシュを導入しました。これにより、JWT 検証のオーバーヘッドが大幅に削減されます。
  • 強化された TLS ハンドシェイク- クライアントが、確立されているセッションの NGINX 構成コンテキストと一致しない ALPN 経由の通信プロトコルを提案した場合、NGINX Plus は TLS ハンドシェイクを拒否します (たとえば、 http{}コンテキストで仮想サーバーに IMAP 電子メール プロトコルを提案した場合)。
  • NGINX JavaScript モジュールの機能強化– asyncおよびawaitキーワードとPromiseオブジェクトを使用する非同期関数がサポートされるようになり、暗号化操作 (乱数の生成や Cookie の暗号化など) 用の WebCrypto API が実装されました。

このリリースには、 IBM System Z (s390x)アーキテクチャのサポート、TCP 接続の各方向を個別に閉じる機能、および Perl 互換正規表現 (PCRE) ライブラリのバージョン 2 のサポートが含まれています。

行動における重要な変化

NGINX JavaScript モジュールはjs_includeをサポートしなくなりました

NGINX Plus R23のリリース時に発表されたように、バージョン0.4.0NGINX JavaScript モジュールでは、 js_includeディレクティブがjs_importディレクティブに置き換えられました。 js_includeディレクティブは当時非推奨となり、このリリースではサポートされなくなりました。

NGINX Plus R26にアップグレードする前に、NGINX 設定ファイルでjs_includeをjs_importに置き換え、NGINX 設定で参照される関数の JavaScript ファイルにexportステートメントを追加します。 次の手順に従ってください。

  1. NGINX 設定ファイルを編集します。

    • js_includeをjs_importに置き換え、暗黙のmodule_name ( .js拡張子のないディレクティブへの JavaScript ファイル名パラメータ) をメモします。

    • JavaScript 関数を参照する各ディレクティブで、関数名の前にmodule_nameを付けます。 関数名はこれらのディレクティブの最初のパラメータです。

      これは、 js_set [ HTTP ][ Stream ] ディレクティブの 2 番目のパラメーターです。

    たとえば、次のように変更します。

    js_set $foo myFunction;

    に：

    js_set $fooモジュール名.myFunction;

  2. NGINX 構成ファイルで参照される関数を定義する JavaScript ( module_name .js ) ファイルを編集します。 参照される関数に名前を付けて、次のようなエクスポートステートメントを各ファイルに追加します。

    デフォルトをエクスポートする { myFunction, otherFunction }

    exportステートメントは.jsファイル内のどこにでも記述できますが、慣例により関数の真上かファイルの末尾に配置されます。

Cookie-Flag モジュールは廃止されました

サードパーティの 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 の Next Protocol Negotiation (NPN) 拡張は、この目的で最初に使用された方法でしたが、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リポジトリを使用するように構成された既存のシステム ( NGINX Plus R23以前を実行しているシステム) でNGINX Plus R26にアップグレードする場合は、新しい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)
  • CentOS 8.1 以上
  • アルパイン Linux 3.12

新機能の詳細

JSON Web キー セット キャッシュによる JWT 検証の高速化

JSON Web トークンを検証する際、NGINX は JSON Web キー セット (JWKS) を使用してトークンの署名を検証するか、トークンを復号化します。 JWKS は、構成ファイルに保存することも、HTTP リクエストを介して外部サービスから取得することもできます。 さらに、JWKS をメモリにキャッシュすることにはいくつかの利点があります。

  • CPU使用率の大幅な削減
  • リクエストのレイテンシの短縮
  • JWT検証の合理化。キャッシュプロセスの一環として、JWKSキーがJSONから暗号化操作に最適化されたバイナリ形式に変換されるため。

JWKS をメモリにキャッシュするには、新しいauth_jwt_key_cacheディレクティブを追加し、各キー セットの有効期限を指定します (この例では 3 時間)。

 

JWK を外部サーバーから取得する場合は、標準のコンテンツ キャッシュを設定し、 proxy_cache_use_staleディレクティブを含めることもお勧めします。これにより、期限切れの JWKS をバックグラウンドで更新しながら引き続き提供するように NGINX Plus に指示します。

 

JWKS キャッシュに加えてコンテンツ キャッシュを使用する利点は 2 つあります。

  • 回復力- JWKS は期限が切れた場合でもキャッシュから取得できます。 これにより、JWKS プロバイダーが一時的に利用できない場合の回復力が向上しますが、セキュリティ リスクが増加するというトレードオフがあります。

  • 認可サーバーへの影響– キャッシュされた JWKS の有効期限が切れると、JWKS キャッシュが単独で使用されているか、コンテンツ キャッシュと組み合わせて使用されているかによって、認可サーバーに異なる影響が及びます。

    • JWKS キャッシュのみの場合、期限切れの JWKS の新しいバージョンがキャッシュに再入力されるまで、すべての受信認証要求は認証サーバーに転送されます。 認証サーバーの応答が遅い場合、JWKS に対する HTTP リクエストの繰り返しが急増する可能性があります。 この余分な負荷により認証サービスが過負荷になり、問題が悪化する可能性があります。

    • 期限切れの JWKS の提供でコンテンツ キャッシュが有効になっている場合、JWKS のリクエストが 1 つだけ認証サーバーに転送され、後続のリクエストはコンテンツ キャッシュが読み込まれた後、NGINX がそれらを満たすことができるまでキューに入れられます。 これにより、認証サービスに対する需要 (およびリソース消費) が減少します。

強化された TLS ハンドシェイク

ALPACAなどの TLS に対する攻撃が増加しています。 エクスプロイトに対するプロアクティブな防御への継続的な取り組みの一環として、NGINX の TLS 接続の処理を強化しました。

アプリケーション層プロトコル ネゴシエーション (ALPN) は、TLS ハンドシェイクのオプションの拡張機能であり、TLS ハンドシェイク中にクライアントとサーバーによって使用され、ハンドシェイクによって確立された暗号化セッションで使用するレイヤー 7 プロトコルを選択します。 ALPN の最も一般的な使用例は、ブラウザと Web サーバーまたはアプリ サーバー間のセッションで 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.2NGINX JavaScript モジュール (njs) の 2 つの機能強化が含まれています。

注記： このセクションでは、非同期操作と暗号化操作の JavaScript 構造を理解していることを前提としています。 コード スニペットの完全な分析はこのブログの範囲外です。

[編集者注– このセクションで説明するユースケースは、NGINX JavaScript モジュールの多くのユースケースのうちのほんの一部です。 完全なリストについては、 「NGINX JavaScript モジュールの使用例」を参照してください。

非同期関数のサポート強化

PHP などの一般的に使用される多くのスクリプト言語では、コマンドと関数は同期して実行されます。つまり、スクリプトが関数を呼び出した後、関数が結果を返すまでスクリプトは一時停止（実行を停止）します。

JavaScript は非同期的に動作することもできます。関数が非同期的に呼び出されると、スクリプトは関数から結果が返されるのを待たずに実行を続けます。

次のサンプル スクリプトをご覧ください。

 

njs ランタイムは定義されたタイムアウトが経過するのを待たないため、空の応答が返されます (待機した場合、出力はb,aになります)。

$カール http://127.0.0.1/ $

非同期操作を正しく処理することは、意図した結果を得るために明らかに重要です。 JavaScript ではこれを行う方法がいくつか提供されていますが、一般的な NGINX の使用例では、実行フローを同期させる方法で非同期関数をラップすることが望ましい場合がよくあります。 ここで、 Promiseオブジェクトとasyncおよびawaitキーワードが役立ちます。

ECMAScript 6 (JavasScript の ECMA‑262 言語仕様の第 6 版) では、 Promiseオブジェクトを非同期関数の戻り値の型として定義しています。 次の 3 つの状態のいずれかが存在します。

  • 完了– 操作が正常に完了しました
  • 拒否– 操作に失敗しました
  • 保留中– 初期状態（完了でも拒否でもない）

キーワードasync を使用して JavaScript 関数を定義すると、関数の戻り値の型がPromiseに設定されます。 Promiseオブジェクトを扱う njs 関数を記述する場合、 asyncおよびawaitキーワードは重要です。

次の例を見てみましょう。

 

fs.readFile関数 (12 行目) はPromiseを返します。 これは、ファイルがuser.textと呼ばれる場合にのみfs.readFile()が呼び出されるようにするカスタム非同期関数でラップされています。 awaitキーワードがあるため、ラッピング関数はPromiseを待機し、データを返します。

fs.readFile() を別の関数でラップすると、エラーをキャッチしやすくなります。非同期関数で例外が発生すると、 Promiseの状態がdeniedに設定されます。 これを行う別の方法は、9 行目を、拒否されたPromise を返すステートメントに置き換えることです。

 

Promiseオブジェクトを直接操作することもできます。 次の例では、 Promise.resolve関数はp1とp2のそれぞれに対してPromiseを返します。 Promise.all関数は、結果を返す前に、 p1とp2 の両方の Promise が解決されるのを待機します。

 

これで、 curlコマンドからの出力が目的のものになりました (タイムアウト値が短いため、最初にbが返されることに注意してください)。

$カール http://127.0.0.1/ b,a $

WebCrypto API による新しい暗号化機能

NGINX JavaScript は、 WebCrypto APIを介して強化された暗号化機能にアクセスできるようになりました。一般的な njs 暗号化の使用例は次のとおりです。

  • セッションID用の安全な乱数を生成する
  • メッセージ、データ、Cookie の暗号化と復号化
  • 対称および非対称暗号アルゴリズムを使用したデジタル署名の作成または検証

この 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関数にラップされていない限り、その結果が次のステップで使用できることは保証されません。 そこで、ここでは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 をソフトウェア ベースの Web サーバー、ロード バランサー、リバース プロキシ、コンテンツ キャッシュ、API ゲートウェイとして導入できるようになりました。

ストリームモジュールにおける TCP ハーフクローズのサポート

新しいproxy_half_closeディレクティブにより、TCP 接続の各方向を独立して閉じることができるため、 stream{}コンテキストでの効率が向上します。

PCRE2 ライブラリ サポート

以前のバージョンの NGINX Plus では、 Perl 互換正規表現 (PCRE) ライブラリ(バージョン 1) を使用して、NGINX 構成で使用される正規表現を評価します。 この重要なオープンソース プロジェクトは最近サポート終了となり、 PCRE2に置き換えられました。 NGINX Plus は PCRE2 を使用して構築されていますが、基盤となるオペレーティング システムで利用可能なバージョンを使用して、PCRE と PCRE2 の両方で構築された動的モジュールをサポートします。 構成の変更は必要ありません。

NGINX Plus をアップグレードまたは試用する

NGINX Plus を実行している場合は、できるだけ早くNGINX Plus R26にアップグレードすることを強くお勧めします。 また、いくつかの追加の修正と改善も行われ、サポート チケットを発行する必要があるときに NGINX がサポートしやすくなります。

NGINX Plus をまだお試しいただいていない方は、セキュリティ、負荷分散、API ゲートウェイとして、または強化された監視および管理 API を備えた完全にサポートされた Web サーバーとして、ぜひお試しください。 30 日間の無料トライアルを今すぐ開始できます。

F5 NGINX に関するブログ投稿をもっと読む ›

「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"