Annonce de NGINX Plus R24

Nous sommes heureux d'annoncer la disponibilité de NGINX Plus Release 24 (R24). Basé sur NGINX Open Source, NGINX Plus est le seul serveur Web logiciel tout-en-un, équilibreur de charge, proxy inverse, cache de contenu et passerelle API.

Les nouvelles fonctionnalités de NGINX Plus R24 incluent :

• Jetons Web JSON chiffrés – S'appuyant sur la prise en charge des jetons Web JSON signés (JWT) dans les versions précédentes, NGINX Plus prend désormais en charge les JWT chiffrés pour la confidentialité et l'intégrité des données des informations sensibles lorsqu'elles sont stockées dans des navigateurs Web et d'autres clients.
• Une étape majeure dans le développement du module JavaScript NGINX : de nouvelles fonctionnalités, notamment le filtrage des réponses pour les en-têtes et les corps HTTP et la prise en charge des services d'authentification basés sur HTTP pour les connexions et sessions TCP/UDP, ouvrent la voie à un certain nombre de nouveaux cas d'utilisation puissants.
• Intégration avec F5 Device ID+ – Cet identifiant d'appareil haute précision en temps réel attribue un identifiant unique à chaque appareil visitant votre site, permettant une protection renforcée contre les mauvais acteurs connus et des expériences utilisateur personnalisées pour les visiteurs récurrents.

La version est complétée par une persistance facultative lors des rechargements de configuration des résultats des contrôles de santé obligatoires et des valeurs dynamiques pour les indicateurs de cookies.

Changements importants dans le comportement

Module Cookie-Flag obsolète

Comme annoncé lors de la sortie de NGINX Plus R23 , le module tiers Cookie-Flag est obsolète et sera supprimé du référentiel de modules dynamiques dans NGINX Plus R26 . La directive set_cookie_flag définie dans ce module est remplacée par la directive proxy_cookie_flags . Nous vous recommandons de remplacer toutes les directives set_cookie_flag dans votre configuration par les directives proxy_cookie_flags dès que possible. Voir également les indicateurs de cookies dynamiques .

Modifications apportées à la prise en charge de la plateforme

• Nouveaux systèmes d'exploitation pris en charge :
  • Alpine Linux 3.13 (aarch64, amd64)
  • CentOS 7.4+ (aarch64, en plus de x86_64 et ppc64le)
  • FreeBSD 13 (amd64)
  • SLES 15 SP2
• Anciens systèmes d’exploitation supprimés :
  • Debian 9 n'est plus pris en charge ; la version la plus ancienne prise en charge est 10
• Les anciens systèmes d'exploitation sont obsolètes et leur suppression est prévue dans NGINX Plus R25 :
  • Alpine Linux 3.10
  • Amazon Linux 1 (2018.03+)
  • FreeBSD 11
  • Ubuntu 16.04 LTS

Amazon Linux 2 dépend d'OpenSSL 1.1

Le package NGINX Plus pour Amazon Linux 2 dépend désormais d'OpenSSL 1.1 , qui active TLS 1.3 et renforce la sécurité de nombreuses autres manières. Lors de la mise à niveau des systèmes Amazon Linux 2 vers NGINX Plus R24 , vérifiez que les autres logiciels qui utilisent OpenSSL sur le système fonctionnent toujours correctement avec OpenSSL 1.1.

Modifications apportées à la procédure d'installation de NGINX Plus

Nous avons réorganisé les référentiels de packages NGINX Plus, avec les modifications résultantes dans la procédure d'installation.

Le changement d’organisation du référentiel reflète l’expansion de notre portefeuille de produits et de l’écosystème de produits qui dépendent de NGINX Plus. Pour NGINX Plus en particulier, le référentiel pkgs.nginx.com/plus remplace l'ancien référentiel plus-pkgs.nginx.com .

Lorsque vous installez et mettez à niveau NGINX Plus, le gestionnaire de packages du système d'exploitation ( apt , yum ou équivalent) est configuré avec le référentiel de logiciels pour NGINX Plus. Sur les systèmes existants configurés pour utiliser le référentiel plus-pkgs.nginx.com , vous devez mettre à jour le gestionnaire de packages pour faire référence à pkgs.nginx.com/plus (plus l'élément de chemin final qui indique le système d'exploitation).

Pour obtenir des instructions sur la mise à niveau d'un système existant vers NGINX Plus R24 , consultez la base de connaissances F5 . Pour obtenir des instructions mises à jour pour l’installation initiale, consultez Installation de NGINX Plus dans le Guide d’administration de NGINX Plus.

Consolidation des directives de gestion des connexions HTTP

Alors que la norme HTTP/3 touche à sa fin et que l’utilisation de HTTP/2 augmente, nous avons simplifié la configuration des connexions de longue durée. Dans NGINX Plus R24 et versions ultérieures, les directives de configuration qui s'appliquaient auparavant uniquement à HTTP/1.1 fonctionnent également pour HTTP/2. Vous n’avez plus besoin d’utiliser des directives différentes pour la même fonctionnalité simplement parce que la version du protocole est différente.

Fermeture de connexion plus agressive

Dans NGINX Plus R23 et versions ultérieures, les directives lingering_close , lingering_time et lingering_timeout fonctionnent aussi bien pour HTTP/2 que pour HTTP/1.1. La configuration d'une gestion plus efficace des connexions HTTP/2 avec ces directives améliore les capacités HTTP/2 globales de NGINX Plus.

NGINX Plus R24 modifie l'effet de ces directives de manière importante et élimine un bug potentiel : si le pool de connexions de travailleurs libres est épuisé, NGINX Plus commence à fermer non seulement les connexions keepalive, mais également les connexions en mode de fermeture persistante.

Modification du niveau de gravité des modifications de l'état de santé enregistrées

NGINX écrit une entrée dans le journal des erreurs lorsque l’état de santé d’un serveur en amont change – un outil important pour surveiller et analyser l’état de santé global de votre infrastructure. Le niveau de gravité auquel les changements d’état sont enregistrés a changé pour les serveurs en amont HTTP et TCP/UDP ( stream ) :

• Le passage de sain à malsain est enregistré au niveau d'avertissement (était info ).
• Le changement de malsain à sain est enregistré au niveau de la notification (était info ).

Nouvelles fonctionnalités en détail

Jetons Web JSON cryptés

L’utilisation des jetons Web JSON ( JWT ) continue de croître. Auparavant, NGINX Plus prenait en charge les jetons signés (la norme JSON Web Signature [JWS] définie dans la RFC 7515 ), qui garantissent l'intégrité des données pour les revendications codées dans le jeton. Cependant, JWS ne garantit pas la confidentialité des réclamations : elles peuvent être lues par n’importe quel composant ayant accès au jeton. TLS/SSL atténue l’exposition des jetons en transit, mais les jetons stockés dans les navigateurs Web et d’autres clients sont toujours exposés.

NGINX Plus R24 introduit la prise en charge des jetons chiffrés (la norme JSON Web Encryption [JWE] définie dans la RFC 7516 ), qui assurent à la fois la confidentialité et l'intégrité des données pour l'ensemble des revendications. Les informations sensibles ou personnellement identifiables (PII) peuvent désormais être codées dans des JWT sans risque que ces données soient divulguées par des clients non sécurisés.

NGINX Plus R24 et versions ultérieures prennent en charge les JWT signés et chiffrés. Les jetons signés sont la valeur par défaut et ne nécessitent aucune configuration explicite. La nouvelle directive auth_jwt_type configure le cryptage JWT.

Vous définissez l'algorithme de chiffrement (ou de signature) et l'utilisation de la clé dans le fichier de clé JWT nommé par la directive auth_jwt_key_file . NGINX Plus R24 et versions ultérieures prennent en charge les méthodes de cryptage suivantes.

Étape majeure de maturité pour le module JavaScript NGINX

NGINX Plus R24 marque une étape majeure dans le développement du module JavaScript NGINX (njs), désormais disponible0.5.3 . Il existe deux améliorations importantes qui vous permettent d'étendre NGINX Plus avec des solutions personnalisées pour une grande variété de cas d'utilisation :

• Filtrage des réponses pour les en-têtes et les corps des réponses HTTP
• Un client HTTP intégré qui peut être utilisé pour effectuer des requêtes HTTP pendant le traitement HTTP ou TCP/UDP

Si vous n'êtes pas familier avec le module JavaScript NGINX, veuillez lire cette introduction sur notre blog<.htmla>.

[ Les cas d'utilisation décrits dans cette section ne sont que quelques-uns des nombreux cas d'utilisation du module JavaScript NGINX. Pour une liste complète, voir Cas d'utilisation du module JavaScript NGINX . ]

Filtrage des réponses

L’une des fonctionnalités les plus puissantes de NGINX Plus déployée en tant que passerelle API ou proxy inverse est le filtrage des réponses , qui consiste à intercepter les réponses des serveurs en amont et à remplacer les chaînes dans le corps de la réponse, les en-têtes ou les deux, en fonction de la correspondance des expressions régulières. Pour le trafic non manipulé avec le module JavaScript NGINX, le filtrage des réponses est implémenté dans le module Substitution .

NGINX Plus R24 introduit une implémentation distincte du filtrage des réponses dans le module JavaScript NGINX, avec deux directives qui vous permettent de profiter de la puissance de JavaScript pour analyser et modifier les corps et les en-têtes des réponses. JavaScript étend les possibilités d'inspection et de manipulation bien au-delà de la simple substitution de chaînes basée sur des expressions régulières, pour un filtrage de réponse encore plus puissant qu'avec le module Substitution.

Filtrage des corps de réponse avec la directive js_body_filter

Avec la directive js_body_filter, vous pouvez utiliser JavaScript pour inspecter et modifier le corps de la réponse d'un serveur proxy. Les cas d’utilisation incluent :

• Recherche de modèles complexes avec des expressions régulières
• Transformation du format des données
• Insérer du contenu dynamique dans les réponses

Dans cet exemple, nous analysons les réponses à la recherche de tout ce qui ressemble à une clé d’accès AWS et remplaçons toutes ces occurrences par une valeur masquée.

Pour exécuter ce code, nous devons simplement référencer la fonction maskAwsKeys à l'intérieur du bloc d'emplacement pertinent.

Filtrage des en-têtes de réponse avec la directive js_header_filter

Vous pouvez utiliser la directive js_header_filter pour examiner – ou même intercepter et modifier – le contenu des en-têtes de réponse. Considérez un serveur backend qui émet un certain nombre d’en-têtes Set-Cookie qui contiennent des informations sensibles mais qui sont essentielles au bon fonctionnement. NGINX Plus est capable d’intercepter la réponse, de lire les en-têtes Set-Cookie et de les enregistrer dans le magasin clé-valeur. Un en-tête Set-Cookie de remplacement peut être créé en tant que référence au magasin clé-valeur et injecté dans la réponse d'origine.

Sur les lignes 4 à 5 de la configuration NGINX Plus, nous définissons le magasin de clés-valeurs :

Ensuite, sur les lignes 12 à 13, nous remplaçons le cookie de référence par le contenu du magasin clé-valeur et interceptons tous les nouveaux cookies avec notre code JavaScript.

Le code JavaScript parcourt chaque nouvel en-tête de réponse Set-Cookie et crée une nouvelle entrée clé-valeur pour le stocker.

Exploiter les services HTTP pour TCP/UDP avec un client HTTP simple

Le cas d’utilisation principal d’une passerelle API est le contrôle de l’accès à des ressources spécifiques. NGINX Plus prend en charge un ensemble puissant de fonctionnalités d’authentification et de contrôle d’accès au niveau de la couche 7 pour les requêtes HTTP, mais les implémentations d’API modernes exploitent également TCP/UDP comme protocole sous-jacent, présentant de nouveaux défis en matière d’authentification.

Avec la fonction JavaScript NGINX intégrée ngx.fetch , vous pouvez désormais instancier un client HTTP simple dans le contexte d'une connexion TCP/UDP. Cela permet l'utilisation de services d'authentification basés sur HTTP pour le contrôle d'accès dans le contexte du flux , par exemple en appelant un démon OpenPolicy Agent local lors de la proxy d'une connexion à une base de données.

Cet exemple illustre l’utilisation d’un service d’authentification HTTP local sur le port 8085 pour authentifier chaque nouvelle connexion. La directive js_access et la fonction ngx.fetch implémentent ensemble une fonctionnalité dans le contexte HTTP nouvellement instancié qui est similaire à l'autorisation client basée sur le résultat d'une sous-requête (comme implémentée par la directive auth_request pour les requêtes HTTP classiques). En fonction du code d'état HTTP disponible dans l' objet Response , la connexion à la base de données backend est autorisée ( s.allow ) ou rejetée ( s.deny ).

Note: La fonction ngx.fetch fonctionne avec le module HTTP NGINX JavaScript ainsi qu'avec le module NGINX JavaScript Stream, mais présente des limitations importantes par rapport à l'objet r.subrequest dans le module HTTP. Pour la plupart des cas d'utilisation HTTP, r.subrequest est préféré car il prend en charge les connexions TLS, la mise en cache et toutes les fonctionnalités du module Proxy .

Autres améliorations du njs

Lorsqu'une variable NGINX est définie avec la directive set [ HTTP ][ Stream ] ou js_set [ HTTP ][ Stream ] , la valeur peut être remplacée lorsque le traitement de la requête rencontre une redirection. La nouvelle directive js_var [ HTTP ][ Stream ] permet à une variable d'être évaluée par une fonction JavaScript et à sa valeur de persister à travers les redirections.

Le nouvel objet njs.on permet d'exécuter une fonction JavaScript lorsque la machine virtuelle njs se ferme. Cela peut être utilisé pour exécuter une fonction à la fin d'une connexion TCP, par exemple.

La nouvelle propriété s.status de l'objet de session Stream donne accès à l'état global de la session (voir $status pour les valeurs possibles).

Intégration avec F5 Device ID+

F5 Device ID+ est un identifiant d’appareil en temps réel et de haute précision qui utilise une collecte de signaux avancée et des algorithmes d’apprentissage automatique éprouvés pour attribuer un identifiant unique à chaque appareil visitant votre site. Le déploiement est simple, avec des avantages immédiats pour vos équipes de sécurité, de réseau, de fraude et numériques. Jamais il n’a été aussi simple de comprendre les appareils uniques qui visitent vos applications.

Pour obtenir des instructions sur l'activation de F5 Device ID+ sur vos instances NGINX Plus, consultez Atténuer la fraude et les risques avec F5 Device ID+ .

Avantages de l'utilisation de F5 Device ID+

• Renforcez la sécurité des applications – Renforcez votre détection des attaques et votre analyse d’atténuation grâce à une identification précise des appareils. Identifiez les appareils de retour que vos systèmes de sécurité ont déjà signalés comme suspects.
• Optimisez la gestion du trafic – Incorporez un identifiant d’appareil unique dans la logique de routage pour mieux gérer et optimiser le trafic réseau. Identifiez les appareils même lorsque des acteurs malveillants manipulent les données de la couche 7.
• Réduisez la fraude et les risques – Surveillez le comportement des clients à travers des opérations telles que la création de nouveaux comptes, l’authentification des utilisateurs, le paiement en ligne et les transactions financières, en détectant des modèles anormaux qui pourraient indiquer un vol d’identité entre autres menaces.
• Personnalisez et accélérez les expériences en ligne – Facilitez la connexion, le paiement et l'authentification pour les utilisateurs et les appareils connus qui reviennent. Les tests A/B réalisés par F5 démontrent que la réduction des frictions de sécurité augmente les revenus, et l'identification des appareils est un élément important de toute stratégie de réduction des frictions.

Comment fonctionne F5 Device ID+

Lorsque chaque utilisateur visite votre site Web, F5 Device ID+ utilise JavaScript pour collecter des informations sur le navigateur, le système d'exploitation, le matériel et la configuration réseau de l'appareil. Ces attributs alimentent le service F5 Device ID+ basé sur les capacités d'IA et d'apprentissage automatique reconnues par l'industrie de F5 Shape. Les données sont traitées en temps réel et un identifiant unique est attribué à l’appareil, sauf s’il s’agit déjà d’un appareil connu. Pour les appareils restitués, le comportement, les actions et d'autres propriétés peuvent être enregistrés, appris et étudiés pour faciliter la réduction de la fraude et une expérience fluide pour les bons utilisateurs connus.

Autres améliorations dans NGINX Plus R24

Le statut des contrôles de santé obligatoires peut persister après les rechargements de configuration

Les contrôles de santé obligatoires sont utilisés pour permettre le démarrage lent des serveurs en amont ajoutés à l’aide de l’ API NGINX Plus ou via la résolution DNS. Ils garantissent que les nouveaux nœuds sont d’abord vérifiés en termes de santé, puis démarrés lentement une fois qu’ils sont prêts à recevoir du trafic.

Auparavant, après un rechargement de configuration, les serveurs en amont étaient considérés comme non sains, quel que soit leur état avant le rechargement. En conséquence, les serveurs n’acceptaient pas les requêtes des clients tant que le premier contrôle obligatoire n’était pas passé.

Avec NGINX Plus R24, vous pouvez marquer les contrôles de santé HTTP obligatoires comme persistants, afin que leur état précédent soit mémorisé lorsque la configuration est rechargée. Ajoutez le paramètre persistant à la directive health_check avec le paramètre obligatoire .

Drapeaux de cookies dynamiques

Dans la version précédente de NGINX Plus, nous avons introduit la directive proxy_cookie_flags comme méthode native pour définir les indicateurs de cookies . NGINX Plus R24 étend cette capacité en activant des valeurs dynamiques pour les indicateurs de cookies. Cela permet aux indicateurs de cookies spécifiques d'être contrôlés par des variables NGINX.

Note: La directive proxy_cookie_flags rend obsolète le module Cookie-Flag, qui sera supprimé dans NGINX Plus R26 . Voir le module Cookie-Flag obsolète .

Cet exemple utilise une carte pour activer l'indicateur de cookie sécurisé lorsque le schéma est https plutôt que http .

Mettre à niveau ou essayer NGINX Plus

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer une mise à niveau vers NGINX Plus R24 dès que possible. Vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires, et cela aidera NGINX à vous aider lorsque vous aurez besoin de créer un ticket d'assistance.

Si vous n'avez pas essayé NGINX Plus, nous vous encourageons à l'essayer - pour la sécurité, l'équilibrage de charge et la passerelle API, ou en tant que serveur Web entièrement pris en charge avec des API de surveillance et de gestion améliorées. Vous pouvez commencer dès aujourd'hui avec un essai gratuit de 30 jours .