ブログ | NGINX

NGINX Plus R25 の発表

NGINX-F5 水平黒タイプ RGB の一部
ザック・ウェストール サムネイル
ザック・ウェストール
2021年9月28日公開

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

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

行動における重要な変化

上流ゾーンのメモリ要件の増加

「HTTP レスポンス コードのより詳細なレポート」で詳しく説明されているように、 NGINX Plus R25 は、個々のステータス コードのカウントとクラスごとの集計カウントを提供します。 NGINX Plus がリバース プロキシまたはロード バランサとして構成されている場合、ピアが 20 個を超えると、アップストリームの「ピア」(バックエンド サーバー) を監視するために使用される共有メモリ ゾーンのサイズを増やす必要がある場合があります。

共有メモリゾーンが不足していると、 NGINX Plus R25 は起動せず、アップグレードが失敗します。 アップグレードする前に、各アップストリーム ゾーンのメモリ使用率を確認することが重要です。 メモリ割り当ての確認と調整の手順については、 「起動エラーを防ぐために十分なメモリを割り当てる」を参照してください。

NGINX Plus リポジトリの構成とインストール手順の変更

NGINX Plus R24のリリースでは、すべての NGINX ソフトウェアのパッケージ リポジトリが再編成され、NGINX Plus のインストール手順が変更されました。

NGINX Plus をインストールまたはアップグレードすると、オペレーティング システムのパッケージ マネージャー ( apt 、 yum 、または同等のもの) が NGINX Plus のソフトウェア リポジトリで構成されます。 古いリポジトリを使用するように設定された既存のシステム ( NGINX Plus R23以前を実行しているシステム) では、新しいリポジトリを参照するようにパッケージ マネージャーを更新する必要があります。 F5 ナレッジベースの手順を参照してください。

NGINX Plus R25の初期インストールを実行する場合は、『 NGINX Plus 管理者ガイド』の「NGINX Plus のインストール」を参照してください。

注記： 新しいソフトウェア リポジトリを使用する必要があります。 古いリポジトリは更新されなくなり、将来のインストールやアップグレードでエラーが発生する可能性があります。

非推奨の Cookie フラグ モジュール

NGINX Plus R23のリリース時に発表されたように、サードパーティの Cookie-Flag モジュールは非推奨となり、 NGINX Plus R26の動的モジュール リポジトリから削除されます。 そのモジュールで定義されているset_cookie_flagディレクティブは、組み込みのproxy_cookie_flagsディレクティブに置き換えられます。 できるだけ早く、設定内のset_cookie_flagディレクティブをproxy_cookie_flagsディレクティブに置き換えることをお勧めします。

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

  • サポートされる新しいオペレーティング システム:
    • Debian 11 (x86_64、aarch64)
    • Alpine Linux 3.14 (x86_64、aarch64)
  • 削除された古いオペレーティング システム:
    • Alpine Linux 3.10; サポートされている最も古いバージョンは 3.11 です
    • Amazon Linux 1 (2018.03+)、Amazon Linux 2 LTS に切り替える
    • FreeBSD 11.4+; サポートされている最も古いバージョンは12.1+です
    • Ubuntu 16.04 LTS; サポートされている最も古いバージョンは 18.04 LTS です
  • NGINX Plus R26で非推奨となり削除が予定されている古いオペレーティング システム:
    • アルパイン Linux 3.11

新機能の詳細

追加のJSON Web Tokenの使用例と機能

NGINX Plus R24 では、暗号化された JSON Web Token (JWE) の初期サポートが導入され、データの機密性を備えたクライアント認証の最も一般的な方法の 1 つが拡張されました。 NGINX Plus R25 では、その機能に基づいて、署名付き (JWS) と暗号化された (JWE) の両方のユースケースで JWT ベースの認証のセキュリティを向上させる、追加のより高度な認証ユースケースのサポートが導入されています。 これらの機能強化により、個人を特定できる情報 (PII) が漏洩するリスクが軽減され、柔軟性が向上します。 NGINX Plus の新しい JWT 機能と拡張機能には以下が含まれます。

復号化された JWE 暗号文の変数

JWT は、HTTP リクエストのステートレス認証 (つまり、トークンベースの認証) に広く使用され、信頼されている方法です。 JWT は、トークン ペイロードでエンドユーザー属性を送信することにより、リクエストのセキュリティを強化します。 しかし、セキュリティ研究者や DevSecOps 実践者は、Web クライアントに暗号化されていない PII を保存することによるリスクが差し迫った懸念であることに同意しており、そのため、暗号化されたトークンを実装するためのガイドラインを提供するJSON Web 暗号化標準 (RFC 7516)が開発されました。

NGINX Plus R24では JWE のサポートが導入され、クレーム セット全体のデータの整合性と機密性が確保されました。 暗号化されたトークン内で PII をエンコードすると、JWT を使用する際のデータ漏洩のリスクが大幅に軽減されます。

NGINX Plus R25 は、初期の JWE サポートを基盤として、新しい変数$jwt_payloadを導入しました。これにより、NGINX Plus は JWE と暗号文を復号化し、HTTP リクエストの処理中にプレーンテキストにアクセスできるようになります。 この新しい機能は、高度なアクセス制御ポリシーとリクエスト ルーティングの決定を実装するために使用できるほか、ユーザーがバックエンド アプリケーションの JWE 復号化レイヤーとして NGINX Plus を導入できるようにもなります。

ネストされた JWT のサポート

JWE トークンは PII の保護に効果的であり、暗号テキストにより CDN やその他の TLS 終端プロキシ間でも機密性が維持されます。 しかし、暗号化は諸刃の剣であり、JWE はアプリケーション環境に複雑さをもたらす可能性があります。 この問題に対処する方法は、ネストされた JWT を使用することです。

ネストされた JWT の構造を示す図
ネストされた JWT の構造

ネストされた JWT は、JWE の暗号テキストとして JWS を埋め込みます。 NGINX Plus R25 では、 JWS と JWE の両方を同時にサポートすることで、HTTP リクエストを認証する方法としてネストされた JWT が有効になります。 NGINX Plus は、1 回の操作で、JWE 内の暗号文を復号化し、結果のプレーンテキストを JWS として検証し、同封のトークン内のexp (有効期限) およびnbf (有効期限以前) クレームを使用して、それが有効であることを検証できるようになりました。 これにより、既存の JWS 環境を JWE でラップすることで、ペイロード暗号化を使用してアップグレードできるようになります。

次の構成スニペットはプロセスを示しています。 auth_jwt_typeディレクティブの新しいネストされたパラメータは、NGINX Plus に JWE 復号化と JWS 検証の両方を実行するように指示します。 これは、JWT ヘッダーと JWT クレームの変数の評価方法にも影響します。

  • auth_jwt_header_setディレクティブは、外部の JWE ヘッダーに対して動作します。
  • auth_jwt_claim_setディレクティブは、ネストされた JWS クレームに対して動作します。
  • $jwt_header_ name変数には、外部 JWE ヘッダー プロパティが含まれます。
  • $jwt_claim_ name変数にはネストされた JWS クレームが含まれます。

 

次の構成では、NGINX Plus は追加の HTTP リクエスト ヘッダーを構築し、バックエンド アプリケーションに送信します。 JWE ヘッダー ( $jwt_header_enc変数) からの暗号化アルゴリズムと、JWS ペイロード ( $jwt_claim_sub変数) からの JWT サブジェクト クレームは、元のリクエストでプロキシされます。 つまり、アプリケーションは暗号化コードやライブラリを実装する必要なく、HTTP ヘッダーを使用するだけで JWE ベースの認証を活用できます。

 

ゼロトラスト アーキテクチャで操作しているユーザーの場合、次の構成により、バックエンド アプリケーションは$jwt_payload変数でキャプチャされた JWS トークンを検証できるようになります。 変数には、JWE 暗号文の復号化されたプレーンテキスト バージョンが含まれます。 ネストされた JWT がある場合、JWS はベアラー トークンとしてバックエンド アプリケーションに渡すことができます。

 

本質的には、ネストされた JWT は、バックエンド アプリケーションの「通常の JWT」署名付きトークンを解析またはプロキシしながら、NGINX Plus が安全なトークンを同時に復号化および検証できるようにすることで、操作を合理化し、アプリケーションのセキュリティを向上させます。

JWE の非対称暗号化

NGINX Plus R24 では、 AES 標準を使用したトークンの対称暗号化のサポートが導入されました。 NGINX Plus R25 では、 RSA キー ペアを使用する際の非対称暗号化のサポートが追加されました。 非対称暗号化では、暗号化と復号化に異なるキー（公開キーと秘密キー）を使用します。これらのキーは、クライアントとサーバー間の HTTPS トラフィックの SSL/TLS 暗号化に使用されるメカニズムと同じRSA（Rivest-Shamir-Adleman）アルゴリズムを使用して数学的に相互にリンクされています。

NGINX Plus R25 は、キー管理アルゴリズムとして RSA と最適非対称暗号化パディング (OEAP) をサポートしており、NGINX Plus 側で明示的な構成は必要ありません。 JWS alg (アルゴリズム) ヘッダーでサポートされている値は、 RSA-OAEP 、 RSA-OAEP-256 、 RSA-OAEP-384 、およびRSA-OAEP-512です。

次の構成は、JWE の非対称暗号化を実装するために必要なのは、RSA 秘密 (ラップ解除) キーを含む JSON Web Key (JWK) ファイルをauth_jwt_key_fileディレクティブのパラメーターとして指定することだけであることを示しています ( auth_jwt_key_requestディレクティブも使用できます)。

 

マルチソース JWK サポート

ネストされた JWT を活用するということは、関連する JWK が複数のソースから取得される可能性が高くなることを意味します。 NGINX Plus R25 は、同じコンテキストで複数のauth_jwt_key_fileおよびauth_jwt_key_requestディレクティブをサポートします。 NGINX Plus は、指定されたすべてのソースからキーをロードし、結合されたキーのセットの中から一致する検証キーを探します。これは、外部の ID プロバイダーによって発行され、別のプロセスによって暗号化が行われた JWE 内にネストされた JWS を操作する場合に非常に便利です。

この機能により、API ゲートウェイとして展開された NGINX Plus にさらなる柔軟性、セキュリティ、パワーが追加されます。

カスタム JWT 検証ルール

NGINX Plus を API ゲートウェイとして導入する場合、きめ細かいアクセス制御を実装するために JWT クレームを検査するのが一般的です。 これにより、構成が複雑になる可能性があります。 以前の NGINX Plus リリースでは、 if構成ブロックを使用して JWT クレームを評価できましたが、このアプローチは多少制限があり、暗号化されたトークンでは機能しませんでした。

NGINX Plus R25 は、 JWT 検証プロセス中にトークンに対して追加のチェックを実行するネイティブな方法を提供することで、この制限に対処します。 auth_jwt_requireディレクティブは、JWT 検証プロセスにオプションのカスタマイズ可能なステップを追加します。 スペースで区切られた文字列のリストを受け入れます。文字列はすべて空ではなく、0 (ゼロ) を指定すると JWT 検証が成功します。 これにより、JWT 検証プロセスに大きな柔軟性が追加されます。

JWT 標準では、どのクレームが必須であるかは規定されていないため、 auth_jwt_require を使用して、各環境に適切なクレームをリストすることができます。

次の構成により、 expクレームとsubクレームの両方がすべてのトークンに存在することが保証されます。

 

マップブロックまたは NGINX Plus キー値ストアを使用してブール値をauth_jwt_requireディレクティブに渡すことで、より複雑なユースケースを設定できます。 NGINX JavaScript モジュールを使用して、相互 TLS (mTLS) クライアント証明書にバインドされたアクセス トークン ( RFC 8705で定義) などの豊富な認証ソリューションを実装することもできます。

次の構成では、クライアント証明書認証 (mTLS) と JWT 検証の両方が実行されます。 14 行目のauth_jwt_requireディレクティブは、 $thumbprint_match変数の評価を要求し、その値がゼロ以外の場合にのみ JWT 検証が成功します。 この変数は、2 行目で呼び出された JavaScript 関数を実行することによって評価されます。

 

前のスニペットの 2 行目で呼び出された検証関数のコードは次のとおりです。

 

HTTP レスポンス コードのより詳細なレポート

監視と可視性は、アプリケーションのパフォーマンス、可用性、セキュリティの基礎となります。 HTTP 応答コードは、アプリケーションの健全性に関する最も重要な情報源の 1 つです。 NGINX Plus API は、 NGINX とクライアント間、および NGINX とアップストリーム サーバー間の両方のやり取りについて HTTP 応答コードを追跡します。その数は、NGINX Plusライブ アクティビティ監視ダッシュボードの関連タブに報告されます。

以前のバージョンのNGINX Plus APIでは、HTTP 応答コードのカウントがクラス ( 2xx 、 4xxなど) 別に集計されていました。 今ではコードも個別にカウントされるようになりました（ 200、404 、503など）。 これにより、アプリケーションで何が起こっているかをより深く理解できます。認証失敗の急増など、原因の異なるエラーを区別できます（403 ) および欠落しているコンテンツ (404 ）。 メトリック収集の設定については、 NGINX Plus 管理者ガイドを参照してください。

NGINX Plus R25でリリースされた最新バージョンのNGINX Plus API (バージョン 7 ) には、応答オブジェクト内にコードオブジェクトが含まれており、個々の HTTP 応答コードをカウントできます。 集約された応答は引き続き利用可能であり、コードオブジェクトを含まない以前のバージョンのNGINX Plus APIもNGINX Plus R25で引き続き使用できます。 新しいメトリック セットの例を次に示します。

$ curl -s http://localhost:8080/api/7/http/server_zones/www.example.com | jq { "処理中": 31、「リクエスト」： 63192、「応答」: {「1xx」: 0、「2xx」： 54368、「3xx」: 8454、「4xx」: 330、「5xx」： 9、「コード」：{「200」： 54368、「302」： 8454、「401」： 30、「404」： 200、「429」： 100、「503」： 9 }, "合計": 63161 }, "破棄されました": 0、「受信済み」: 693436、「送信済み」: 13843478 }

起動失敗を防ぐために十分なメモリを割り当てる

重要な注意: NGINX Plus がリバース プロキシまたはロード バランサとして構成されている場合、個々のコードをカウントすると、各アップストリーム グループの共有メモリ ゾーンのメモリ使用率が増加します。 アップストリーム グループに 20 を超えるピアがある場合は、ゾーンディレクティブで設定されているように、メモリ サイズを増やす必要がある場合があります。

アップストリーム ゾーンが不足している場合、 NGINX Plus R25 は起動せず、アップグレードが失敗します。

アップストリーム グループの共有メモリ ゾーンの一般的な構成を次に示します。

 

NGINX Plus R25にアップグレードする前に、既存のアップストリーム ゾーンのメモリ使用率を確認することが重要です。 これを行うには、次のいずれかの方法を使用する前に、 NGINX Plus APIが有効になっていることを確認してください。

  • ライブ アクティビティ モニタリング ダッシュボードのHTTP Upstreamsタブを確認します。demo.nginx.comのこの例では、使用率は 54% です。

  • 次のコマンドを実行して、ホストから直接NGINX Plus API を使用します。 初め：

    • 必要に応じてjqユーティリティをインストールします
    • API変数を、 APIディレクティブが有効になっている場所に設定します。
    $ API=http://localhost:8080/api; for i in `curl -s $API/1/http/upstreams | jq -r '.[].zone | @uri'`; do echo -n $i; curl -s $API/1/slabs/$i | jq -r '.pages | 100*(.used / (.used + .free)) | " \(round)% used"'; 完了

現在の使用率が 40% を超えている場合 (スクリーンショットのように)、ゾーンディレクティブの 2 番目の (サイズ) パラメータを少なくとも 2.5 倍に増やします。 たとえば、上記の構成スニペットでは64k を160kに増やすことをお勧めします。

プロキシ用の動的 SSL/TLS クライアント証明書の読み込み

相互 TLS (mTLS) は、クライアントとサーバーの両方の ID を検証する一般的な認証方法です。 NGINX Plus を使用すると、アップストリーム グループ内のサーバーを変数を使用して動的に定義できます。 つまり、NGINX Plus がアップストリーム サーバーに対して自身を検証するために使用する TLS 証明書を動的に選択できる必要がある場合もあります。

NGINX Plus R25 は、 mTLS に使用される構成ディレクティブをバックエンド サーバーに拡張し、証明書を表す変数を受け入れるようになりました。 変数は次のいずれかを参照できます。

  • ディスク上のファイル
  • PEM 形式の生データ。先頭にdata:が付きます。

これにより、NGINX Plus は証明書と秘密鍵を動的に選択できるようになります。これは、絶えず変化する最新のアプリケーション環境に役立ちます。 証明書と秘密鍵をNGINX Plus キー値ストアに保存できます。これにより、秘密鍵がディスクではなくメモリに保存されるため、セキュリティが強化されます。 もう 1 つのユースケースは、API 呼び出しを使用してキー値ストア内の証明書を更新する自動証明書ローテーションです。

次の構成では、NGINX Plus はホスト名に基づいてリクエストを異なるアップストリーム グループにルーティングします。 プロキシ接続は mTLS を使用して行われ、各アップストリームに適切なクライアント証明書が動的に選択されます。

 

次のディレクティブは、アップストリーム サーバーを使用した mTLS の動的証明書の読み込みをサポートします。

HTTP リクエスト処理のセキュリティ強化

NGINX 哲学の中核となる信条の 1 つは、特にセキュリティに関する継続的な改善です。 当社では、セキュリティ研究者との連携、F5 の業界をリードするセキュリティ テクノロジーの当社製品への統合、社内開発の取り組みなど、利用可能なすべてのリソースを活用しています。

最後の例として、 NGINX Plus R25 は、リクエストの密輸などの潜在的な攻撃からアプリケーションを保護するために、HTTP リクエストに対していくつかの追加チェックを実行します。 次の条件ではエラーが返されます。

  • HTTP/1.0リクエストにはTransfer-Encodingヘッダーが含まれています
  • Transfer-EncodingとContent-Lengthヘッダーの両方が存在する
  • リクエスト行またはヘッダー名にスペースまたは制御文字が含まれています
  • ホストヘッダーにスペースまたは制御文字が含まれています
  • CONNECTメソッドが使用される

さらに、プロキシされた URI では、次の文字が常にエスケープされるようになりました: " 、 < 、 > 、 \ 、 ^ 、 ` 、 { 、 | 、 } 。

これらの変更は予防的なセキュリティ強化であり、既知の脆弱性への対応として行われるものではないことにご注意ください。

TCP/UDP アプリケーションのリロード時の必須ヘルスチェック ステータスの永続化

NGINX Plus は、クライアント要求がプロキシされる前に、アップストリーム グループに追加された新しいサーバーがテストされ、正常であることを確認するために、必須のヘルス チェックを使用します。 NGINX Plus R23以前では、アップストリーム サーバーは、リロード前の状態に関係なく、設定のリロード後には正常ではないとみなされていました。 その結果、NGINX Plus は最初の必須チェックが完了するまでサーバーにリクエストを送信しませんでした。

NGINX Plus R24 では、 HTTP アプリケーションのリロード全体にわたって必須のヘルスチェック ステータスを永続化するオプションが導入されました。 リロード前の最後の必須ヘルスチェックが成功した場合、NGINX Plus は、リロード後の必須ヘルスチェックが成功するまで待たずに、すぐにサーバーにリクエストを送信できます。

NGINX Plus R25 では、この機能が TCP/UDP アプリケーション (ストリームコンテキスト内) に拡張されます。 HTTP の場合、必須パラメータとともに、 health_checkディレクティブにpersistentパラメータを追加します。

 

NGINX JavaScript モジュールの機能強化

NGINX JavaScript モジュール (njs) がバージョン 0.6.2 に更新され、いくつかのバグ修正と、 JavaScript ES6との互換性を強化する機能強化が行われました。

letとconstキーワードを使用した変数宣言

NGINX JavaScript では、 letおよびconstキーワードを使用したスコープ付き変数の宣言がサポートされるようになりました。 以前のバージョンの NGINX Plus および njs では、変数の宣言と割り当てにvarキーワードのみがサポートされていました。 これには、特定のブロックステートメントのスコープ内に制限される変数が用意されていませんでした。これは、さまざまなプロジェクト、プログラミング言語、エンジニアリング チームが共有コードベースまたはライブラリで共同作業を行うときによく発生する複雑さに対処するために必要です。

JavaScript ES6 では、スコープ付き変数を定義するためのletおよびconstキーワードが提供されています。

  • let変数は、それが使用されるブロックステートメントまたは式のスコープ内に制限されます。 対照的に、 varキーワードは、ブロックのスコープに関係なく、変数をグローバルに宣言するか、関数全体に対してローカルに宣言します。
  • const変数は、 letキーワードを使用して宣言された変数と同様に、ブロックスコープです。 定数の値は再割り当てによって変更することはできず、再宣言することもできません。

すべてのPromiseコンストラクタ メソッドのサポート

Promise.all() 、 Promise.allSettled() 、 Promise.any() 、およびPromise.race()コンストラクター メソッドの追加により、njs は JavaScript ES6 標準で定義されているコンストラクター メソッドの完全なセットをサポートするようになりました。

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

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

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

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

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