NGINX Plus R25を発表

Zach Westallシニアプロダクトマーケティングマネージャー

NGINX Plus Release 25（R25）の提供開始をお知らせします。NGINX Open SourceをベースとするNGINX Plusは、Webサーバー、ロードバランサー、リバースプロキシ、コンテンツキャッシュ、APIゲートウェイの機能をすべて備えた唯一のオールインワンソフトウェアです。

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

• 追加された、より高度なJSON Web Tokenのユースケース – NGINX Plus R25では、NGINX Plus R24で導入された暗号化JSON Web Token（JWE）のサポートがさらに強化されています。
• HTTPレスポンスコードのより詳細なレポート – NGINX Plus APIでは、HTTPレスポンスコードをクラス別に集計するだけでなく、個別にもカウントできるようになりました。メモリ割り当てを増やす必要がある場合があります。詳しくは「起動エラーを防ぐための十分なメモリの割り当て」を参照してください。
• プロキシ接続用SSL/TLSクライアント証明書の動的読み込み – 変数を使用して、NGINX Plusとバックエンドサーバー間のmTLS接続に使用する証明書を動的に選択できます。
• HTTPリクエスト処理のセキュリティ強化 – NGINX Plusは、潜在的な攻撃からアプリケーションを保護するため、HTTPリクエストに対して複数の追加チェックを実行します。
• TCP/UDPアプリケーションでのリロード後のヘルスチェック状態の保持 – TCP/UDPサーバーに対する必須ヘルスチェックの結果を、設定のリロード後も保持できるようになりました。
• NGINX JavaScriptモジュールの機能強化 – JavaScript ES6との互換性が強化されました。

動作に関する重要な変更

アップストリームゾーンのメモリ要件の増加

「HTTPレスポンスコードのより詳細なレポート」で詳しく説明しているように、NGINX Plus R25では、個々のステータスコードの件数に加え、クラス別の集計件数も確認できます。NGINX Plusをリバースプロキシまたはロードバランサーとして構成している場合、アップストリームの「ピア」（バックエンドサーバー）が20台を超えると、ピアの監視に使用する共有メモリゾーンのサイズを増やす必要が生じることがあります。

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

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

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

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

NGINX Plus R25を新規インストールする場合は、Installing NGINX Plus in the NGINX Plus Admin Guideを参照してください。

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

非推奨のCookie-Flagモジュール

リリース時にお知らせしたとおり、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で削除される予定の旧バージョンのオペレーティングシステム：
  • Alpine 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のサポート
• JWEの非対称暗号化
• 複数ソースのJSON Web Keyをサポート
• 追加のカスタムJWT検証ルール

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

JWTは、HTTPリクエストのステートレス認証（すなわち、トークンベース認証）に広く使用され、信頼されている方式です。トークンのペイロードでエンドユーザー属性を送信することで、JWTはリクエストのセキュリティ向上に役立ちます。しかし、セキュリティ研究者とDevSecOps担当者は、暗号化されていないPIIをWebクライアントに保存することによるリスクが喫緊の懸念事項であるとの認識で一致しています。これを受けて、暗号化トークンの実装に関するガイドラインを定めた「JSON Web Encryption標準（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によってアプリケーション環境が複雑になる可能性があります。この問題に対処する方法の1つが、ネストされたJWTの使用です。

ネストされたJWTの構造

ネストされたJWTでは、JWSがJWEの暗号文として埋め込まれます。NGINX Plus R25は、JWSとJWEの両方を同時にサポートすることで、HTTPリクエストの認証方法としてネストされたJWTを利用できるようにします。NGINX Plusでは、1回の処理でJWE内の暗号文を復号し、得られた平文をJWSとして検証したうえで、内包されたトークンのexp（有効期限）クレームとnbf（有効開始日時）クレームを使用して、そのトークンが有効であることを確認できるようになりました。これにより、既存のJWS環境をJWEでラップし、ペイロード暗号化に対応させることができます。

次の設定スニペットは、この処理を示しています。新しい「nested」パラメーターを「auth_jwt_type」ディレクティブに指定すると、NGINX PlusはJWEの復号とJWSの検証を両方実行します。また、JWTヘッダーおよびJWTクレームの変数の評価方法にも影響します。

• The auth_jwt_header_setディレクティブは、外側のJWEヘッダーを処理します。
• The auth_jwt_claim_setディレクティブは、ネストされたJWSクレームを処理します。
• $jwt_header_name変数には、外側のJWEヘッダープロパティが格納されます。
• $jwt_claim_name変数には、ネストされたJWSクレームが格納されます。

コード例を読み込み中…

以下の設定により、NGINX Plusは追加のHTTPリクエストヘッダーを構築し、バックエンドアプリケーションに送信します。JWEヘッダーの暗号化アルゴリズム（変数$jwt_header_enc）と、JWSペイロードのJWTサブジェクトクレーム（変数$jwt_claim_sub）は、元のリクエストとともにプロキシされます。これにより、アプリケーションは暗号化コードやライブラリを実装することなく、HTTPヘッダーを受け取るだけでJWEベースの認証を利用できます。

コード例を読み込み中…

ゼロトラストアーキテクチャを運用している場合、以下の設定により、バックエンドアプリケーションは$jwt_payload変数に格納されたJWSトークンを検証できます。この変数には、JWE暗号文を復号した平文が格納されます。ネストされたJWTがある場合は、JWSをベアラートークンとしてバックエンドアプリケーションに渡すことができます。

コード例を読み込み中…

要するに、ネストされたJWTを使用すると、NGINX Plusはセキュアトークンの復号と検証を同時に行いながら、バックエンドアプリケーション向けの署名済み「通常のJWT」トークンを解析またはプロキシできるため、運用が効率化され、アプリケーションセキュリティが向上します。

JWEの非対称暗号化

NGINX Plus R24では、AES標準を使用したトークンの対称暗号化がサポートされました。NGINX Plus R25では、RSA鍵ペアを使用する場合の非対称暗号化が新たにサポートされます。非対称暗号方式では、暗号化と復号に異なる鍵（公開鍵と秘密鍵）を使用します。これらの鍵は、RSA（Rivest–Shamir–Adleman）アルゴリズムによって数学的に関連付けられています。これは、クライアントとサーバー間のHTTPSトラフィックをSSL/TLSで暗号化する際に使用されるものと同じ仕組みです。

NGINX Plus R25は、鍵管理アルゴリズムとしてOptimal Asymmetric Encryption Padding（OEAP）を使用するRSAをサポートしており、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は、指定されたすべてのソースから鍵を読み込み、統合された鍵セットから一致する検証鍵を検索します。これは、外部のアイデンティティプロバイダーが発行したJWSが、別のプロセスで暗号化されたJWE内にネストされている場合に非常に便利です。

この機能により、APIゲートウェイとして導入されたNGINX Plusの柔軟性、セキュリティ、処理能力がさらに向上します。

カスタムJWT検証ルール

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

NGINX Plus R25では、JWT検証プロセス中にトークンを追加チェックするネイティブな方法を提供することで、この制約に対処しています。auth_jwt_requireディレクティブにより、JWT検証プロセスに任意でカスタマイズ可能なステップを追加できます。このディレクティブは、スペース区切りの文字列リストを受け取ります。JWT検証が成功するには、すべての文字列が空でなく、かつ0（ゼロ）以外である必要があります。これにより、JWT検証プロセスの柔軟性が大幅に向上します。

JWT標準では必須のクレームが規定されていないため、auth_jwt_requireを使用して、環境ごとに適切なクレームを指定できます。

以下の設定により、すべてのトークンにexpクレームとsubクレームの両方が含まれるようになります。

コード例を読み込み中…

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

以下の設定では、クライアント証明書認証（mTLS）とJWT検証の両方を実行します。14行目のauth_jwt_requireディレクティブにより、$thumbprint_match変数が評価され、その値が0以外の場合にのみJWT検証が成功します。この変数は、2行目で呼び出されるJavaScript関数を実行することで評価されます。

コード例を読み込み中…

以下は、前のコードスニペットの2行目で呼び出されるvalidate関数のコードです。

コード例を読み込み中…

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

監視と可視化は、アプリケーションのパフォーマンス、可用性、セキュリティを支える基盤です。HTTPレスポンスコードは、アプリケーションの健全性を把握するうえで特に重要な情報源の1つです。NGINX Plus APIは、NGINXとクライアント間、およびNGINXとアップストリームサーバー間のやり取りにおけるHTTPレスポンスコードを追跡し、その件数をNGINX Plusのライブアクティビティ監視ダッシュボードの該当するタブに表示します。

以前のバージョンのNGINX Plus APIでは、HTTPレスポンスコードの数をクラス別（2xx、4xxなど）に集計していました。現在は、コード別（200、404、503など）の集計にも対応しています。これにより、認証失敗（403）の急増やコンテンツの欠落（404）など、原因が大きく異なるエラーを区別し、アプリケーションで何が起きているかをより詳細に把握できます。メトリクス収集の設定については、NGINX Plus Admin Guideを参照してください。

NGINX Plus R25とともにリリースされたNGINX Plus APIの最新バージョン（バージョン 7）では、個々のHTTPレスポンスコードをカウントできるように、codesオブジェクトがresponsesオブジェクト内に追加されています。集約されたレスポンスも引き続き利用できます。また、codesオブジェクトを含まない以前のバージョンのNGINX Plus APIも、NGINX Plus R25で引き続き使用できます。新しいメトリクスセットの例を次に示します。

$ curl -s http://localhost:8080/api/7/http/server_zones/www.example.com | jq{
  "processing": 31,
  "requests": 63192,
  "responses": {
    "1xx": 0,
    "2xx": 54368,
    "3xx": 8454,
    "4xx": 330,
    "5xx": 9,
    "codes": {
      "200": 54368,
      "302": 8454,
      "401": 30,
      "404": 200,
      "429": 100,
      "503": 9
    },
    "total": 63161
  },
  "discarded": 0,
  "received": 693436,
  "sent": 13843478
}

起動エラーを防ぐために十分なメモリを割り当てる

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

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

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

コード例を読み込み中…

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

• ライブアクティビティ監視ダッシュボードの［HTTP Upstreams］タブを確認します。次のdemo.nginx.comの例では、使用率は54%です。
  
• 次のコマンドを実行して、ホストからNGINX Plus 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"'; done

• 必要に応じてjqユーティリティをインストールしてください if necessary
• Set the API変数に、apiディレクティブが有効になっている場所を設定します

現在の使用率が40%を超えている場合（スクリーンショットの例）、zoneディレクティブの2番目のパラメーター（サイズ）を少なくとも2.5倍に増やしてください。たとえば、上記の設定スニペットでは、64kを160kに増やすことを推奨します。

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

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

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

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

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

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

コード例を読み込み中…

以下のディレクティブは、アップストリームサーバーとのmTLSで証明書を動的に読み込む機能をサポートします。

• grpc_ssl_certificate
• grpc_ssl_certificate_key
• proxy_ssl_certificate
• proxy_ssl_certificate_key
• uwsgi_ssl_certificate
• uwsgi_ssl_certificate_key

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

NGINXの理念における中核的な原則の1つは、継続的な改善であり、特にセキュリティの向上を重視しています。セキュリティ研究者との連携、F5の業界をリードするセキュリティ技術の製品への統合、社内での開発など、利用可能なあらゆるリソースを活用しています。

最後に挙げた社内開発の例として、NGINX Plus R25では、アプリケーションを潜在的な攻撃から保護するため、HTTPリクエストに対して複数の追加チェックを実行します。攻撃の例としては、リクエストスマグリングがあります。次の条件に該当する場合はエラーを返します。

• HTTP/1.0リクエストにTransfer-Encodingヘッダーが含まれている
• The Transfer-EncodingとContent-Lengthの両方のヘッダーが存在する
• リクエスト行またはいずれかのヘッダー名に、スペースまたは制御文字が含まれている
• There are spaces or control characters in the Hostヘッダーにスペースまたは制御文字が含まれています
• The CONNECTメソッドが使用されている

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

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

TCP/UDPアプリケーションの再読み込み時における必須ヘルスチェック状態の維持

NGINX Plusでは、必須ヘルスチェックを使用して、アップストリームグループに新しく追加されたサーバーをテストし、正常であることを確認してから、クライアントリクエストをそのサーバーにプロキシします。NGINX Plus R23以前では、設定の再読み込み前のステータスにかかわらず、再読み込み後のアップストリームサーバーは異常と見なされていました。そのため、最初の必須チェックに合格するまで、NGINX Plusはサーバーにリクエストを送信しませんでした。

NGINX Plus R24では、HTTPアプリケーション向けに、リロード後も必須ヘルスチェックのステータスを保持できるオプションが導入されました。リロード前の最後の必須ヘルスチェックが成功していれば、NGINX Plusはリロード後の必須ヘルスチェックが成功するのを待たずに、サーバーへ直ちにリクエストを送信できます。

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

コード例を読み込み中…

NGINX JavaScript Moduleの機能強化

NGINX JavaScriptモジュール（njs）はバージョン 0.6.2に更新され、複数のバグ修正と、JavaScript ES6との互換性を強化するいくつかの機能改善が加えられました。

Variable Declaration with the letおよびconstキーワードによる変数宣言

NGINX JavaScriptでは、letおよびconstキーワードを使用したスコープ付き変数の宣言がサポートされるようになりました。以前のバージョンのNGINX Plusとnjsでは、変数の宣言と代入に使用できるのはvarキーワードのみでした。そのため、特定のblock文のスコープに限定された変数を使用できませんでした。このような変数は、異なるプロジェクト、プログラミング言語、エンジニアリングチームが共有コードベースやライブラリで共同作業する際に生じがちな複雑さに対処するために必要です。

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

• let変数のスコープは、その変数が使用されているblock文または式に限定されます。一方、varキーワードで宣言した変数は、グローバル変数、またはブロックスコープに関係なく関数全体をスコープとするローカル変数になります。
• const変数のスコープは、letキーワードを使用して宣言された変数と同様にブロック内に限定されます。定数の値は再代入によって変更できず、再宣言もできません。

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

With the addition of the 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日間の無料トライアルを開始できます。

著者について

Zach Westallシニアプロダクトマーケティングマネージャー

Zach Westallのその他のブログ記事