NGINX Plus R24 の発表

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

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

• 暗号化された JSON Web トークン– 以前のリリースでの署名付き JSON Web トークン (JWT) のサポートを基に、NGINX Plus は、Web ブラウザーやその他のクライアントに保存される機密情報の機密性とデータ整合性を確保するために、暗号化された JWT をサポートするようになりました。
• NGINX JavaScript モジュールの開発における大きなマイルストーン- 新しい機能、特に HTTP ヘッダーと本文の両方に対する応答フィルタリング、および TCP/UDP 接続とセッションに対する HTTP ベースの認証サービスのサポートにより、数多くの強力な新しいユースケースが実現します。
• F5 Device ID+ との統合– このリアルタイムの高精度デバイス識別子は、サイトにアクセスする各デバイスに一意の識別子を割り当て、既知の悪意のある行為者に対する強力な保護と、再訪問者向けのカスタマイズされたユーザー エクスペリエンスを実現します。

このリリースの最後には、必須のヘルスチェックの結果と Cookie フラグの動的な値を構成の再読み込み後もオプションで永続化できるようになっています。

行動における重要な変化

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

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

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

• サポートされる新しいオペレーティング システム:
  • アルパイン Linux 3.13 (aarch64、amd64)
  • CentOS 7.4+ (aarch64、x86_64 および ppc64le に加えて)
  • FreeBSD 13 (amd64)
  • SLES 15 SP2
• 削除された古いオペレーティング システム:
  • Debian 9はサポートされなくなりました。サポートされている最も古いバージョンは10です。
• NGINX Plus R25で非推奨となり削除が予定されている古いオペレーティングシステム:
  • アルパインLinux3.10
  • Amazon Linux 1 (2018.03+)
  • フリーBSD11
  • Ubuntu 16.04 LTS

Amazon Linux 2 は OpenSSL 1.1 に依存します

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接続処理ディレクティブの統合

HTTP/3 標準が完成に近づき、HTTP/2 の使用が増えるにつれて、長時間接続の構成方法が簡素化されました。 NGINX Plus R24以降では、以前は HTTP/1.1 にのみ適用されていた設定ディレクティブが HTTP/2 でも機能します。 プロトコル バージョンが異なるという理由だけで、同じ機能に対して異なるディレクティブを使用する必要がなくなりました。

より積極的な接続の閉鎖

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 はキープアライブ接続だけでなく、リンギングクローズモードの接続も閉じ始めます。

記録されたヘルスステータスの変更の重大度レベルを変更しました

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

• 正常から異常への変更は、警告レベル (以前は情報) で記録されます。
• 不健全から健全への変更は、通知レベル (以前は情報) で記録されます。

新機能の詳細

暗号化されたJSONウェブトークン

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以降では、次の暗号化方式がサポートされています。

NGINX JavaScript モジュールの主要な成熟マイルストーン

NGINX Plus R24は、NGINX JavaScriptモジュール（njs）の開発における大きなマイルストーンであり、現在0.5.3。 さまざまなユースケースに合わせてカスタム ソリューションで NGINX Plus を拡張できるようにする重要な機能強化が 2 つあります。

• HTTPレスポンスのヘッダーと本文の両方に対するレスポンスフィルタリング
• HTTP または TCP/UDP 処理中に HTTP リクエストを行うために使用できる組み込み HTTP クライアント

NGINX JavaScript モジュールに詳しくない場合は、ブログのこちらの紹介をお読みください<.htmla>。

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

レスポンスフィルタリング

API ゲートウェイまたはリバース プロキシとして導入された NGINX Plus の最も強力な機能の 1 つは、レスポンス フィルタリングです。これは、アップストリーム サーバーからのレスポンスをインターセプトし、正規表現のマッチングに基づいてレスポンス本文、ヘッダー、またはその両方の文字列を置き換える機能です。 NGINX JavaScript モジュールで操作されていないトラフィックの場合、応答フィルタリングはSubstitutionモジュールで実装されます。

NGINX Plus R24 では、NGINX JavaScript モジュール内でレスポンス フィルタリングの個別の実装が導入され、JavaScript のパワーを活用してレスポンス本文とヘッダーを分析および変更できる 2 つのディレクティブが導入されました。 JavaScript は、正規表現に基づく単純な文字列置換をはるかに超えて検査と操作の可能性を拡張し、Substitution モジュールよりもさらに強力な応答フィルタリングを実現します。

js_body_filterディレクティブによるレスポンス本文のフィルタリング

js_body_filterディレクティブを使用すると、JavaScript を使用して、プロキシされたサーバーからの応答の本文を検査および変更できます。 使用例は次のとおりです:

• 正規表現による複雑なパターンのスキャン
• データ形式の変換
• レスポンスに動的コンテンツを挿入する

この例では、応答をスキャンして AWS アクセスキーのように見えるものを探し、そのような出現をマスクされた値に置き換えます。

このコードを実行するには、関連するlocationブロック内のmaskAwsKeys関数を参照するだけです。

js_header_filterディレクティブによるレスポンス ヘッダーのフィルタリング

js_header_filterディレクティブを使用すると、レスポンス ヘッダーの内容を調べたり、傍受して変更したりすることができます。 機密情報を含みながらも正しい操作に不可欠な多数のSet-Cookieヘッダーを発行するバックエンド サーバーを検討します。 NGINX Plus は、応答をインターセプトし、 Set-Cookieヘッダーを読み取り、キー値ストアに保存することができます。 置換Set-Cookieヘッダーをキー値ストアへの参照として作成し、元の応答に挿入することができます。

NGINX Plus 設定の 4 ～ 5 行目に、キー値ストアを定義します。

次に、12 行目から 13 行目で、参照 Cookie をキー値ストアの内容に置き換え、JavaScript コードで新しい Cookie をインターセプトします。

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ディレクティブによって実装されるもの)。 Responseオブジェクトで使用可能な HTTP ステータス コードに基づいて、バックエンド データベースへの接続が許可 ( s.allow ) または拒否 ( s.deny ) されます。

注記： ngx.fetch関数は、NGINX JavaScript HTTP モジュールと NGINX JavaScript Stream モジュールで動作しますが、HTTP モジュールのr.subrequestオブジェクトと比較すると大きな制限があります。 ほとんどの HTTP ユースケースでは、TLS 接続、キャッシュ、およびProxy モジュールのすべての機能をサポートするため、 r.subrequestが推奨されます。

その他のnjsの機能強化

NGINX 変数がset [ HTTP ][ Stream ]またはjs_set [ HTTP ][ Stream ]ディレクティブで定義されている場合、リクエスト処理でリダイレクトが発生したときに値が上書きされる可能性があります。 新しいjs_var [ HTTP ][ Stream ]ディレクティブを使用すると、変数を JavaScript 関数で評価し、その値をリダイレクト間で保持できるようになります。

新しいnjs.onオブジェクトにより、njs 仮想マシンの終了時に JavaScript 関数を実行できるようになります。 これを使用して、たとえば TCP 接続の終了時に関数を実行できます。

Stream セッション オブジェクトの新しいs.statusプロパティは、全体的なセッション ステータスへのアクセスを提供します (可能な値については$status を参照してください)。

F5デバイスID+との統合

F5 Device ID+ は、高度な信号収集と実証済みの機械学習アルゴリズムを利用して、サイトにアクセスする各デバイスに一意の識別子を割り当てる、リアルタイムの高精度デバイス識別子です。 導入は簡単で、セキュリティ、ネットワーキング、不正行為、デジタルの各チームにすぐにメリットをもたらします。 アプリケーションにアクセスする固有のデバイスを把握することが、これまでになく簡単になりました。

NGINX Plus インスタンスでF5 Device ID+ をアクティブ化する手順については、 「F5 Device ID+による不正行為とリスクの軽減」を参照してください。

F5 Device ID+を使用するメリット

• アプリケーション セキュリティの強化- 正確なデバイス識別を通じて、攻撃の検出と軽減の分析を強化します。 セキュリティ システムによってすでに疑わしいとフラグが付けられた返却デバイスを認識します。
• トラフィック管理の最適化- 一意のデバイス識別子をルーティング ロジックに組み込むことで、ネットワーク トラフィックをより適切に管理および最適化します。 悪意のある攻撃者がレイヤー 7 データを操作した場合でもデバイスを識別します。
• 詐欺やリスクを軽減– 新規アカウントの作成、ユーザー認証、電子商取引のチェックアウト、金融取引などの操作全体にわたって顧客の行動を監視し、個人情報の盗難などの脅威を示す異常なパターンを検出します。
• オンライン エクスペリエンスをパーソナライズして高速化します。既知のリピーター ユーザーとデバイスに対して、ログイン、チェックアウト、認証をシームレスにします。 F5 による A/B テストでは、セキュリティの摩擦を軽減すると収益が増加することが実証されており、摩擦軽減のためのあらゆる戦略において、デバイスの識別が重要な要素となっています。

F5デバイスID+の仕組み

各ユーザーが Web サイトにアクセスすると、 F5 Device ID+ はJavaScript を活用して、ブラウザ、デバイスの OS、ハードウェア、ネットワーク構成に関する情報を収集します。 これらの属性は、業界で認められた F5 Shape の AI および機械学習機能に基づいて構築されたF5 Device ID+サービスに取り込まれます。 データはリアルタイムで処理され、既知のデバイスでない限り、デバイスに一意の識別子が割り当てられます。 返却されたデバイスについては、動作、アクション、その他のプロパティを記録、学習、調査して、不正行為の削減と、既知の優良ユーザーのスムーズなエクスペリエンスを促進することができます。

NGINX Plus R24のその他の機能強化

必須ヘルスチェックのステータスは構成の再読み込み後も保持されます

必須のヘルスチェックは、 NGINX Plus APIまたは DNS 解決を使用して追加されたアップストリーム サーバーのスロースタートを有効にするために使用されます。 新しいノードが最初にヘルスチェックされ、トラフィックを受信する準備ができたらスロースタートされることを保証します。

以前は、構成の再読み込み後、再読み込み前の状態に関係なく、アップストリーム サーバーは正常でないとみなされていました。 その結果、最初の必須チェックが完了するまで、サーバーはクライアントのリクエストを受け入れませんでした。

NGINX Plus R24 では、必須の HTTP ヘルスチェックを永続的としてマークできるため、設定が再ロードされたときに以前の状態が記憶されます。 必須パラメータとともに、 health_checkディレクティブに永続パラメータを追加します。

動的 Cookie フラグ

NGINX Plus の以前のリリースでは、 Cookie フラグを設定するためのネイティブ メソッドとしてproxy_cookie_flagsディレクティブを導入しました。 NGINX Plus R24 では、 Cookie フラグの動的な値を有効にすることでこの機能が拡張されています。 これにより、特定の Cookie フラグを NGINX 変数で制御できるようになります。

注記： proxy_cookie_flagsディレクティブは Cookie‑Flag モジュールを非推奨とし、 NGINX Plus R26で削除される予定です。 非推奨の Cookie フラグ モジュールを参照してください。

この例では、スキームがhttpではなくhttpsの場合に、マップを使用してSecure Cookie フラグを有効にします。

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

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

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