Annonce de NGINX Plus R24

Nous sommes heureux d’annoncer la disponibilité de NGINX Plus version 24 (R24). Basé sur NGINX Open Source, NGINX Plus est la seule solution logicielle tout-en-un faisant office de serveur web, d’équilibreur de charge, de proxy inverse, de cache de contenu et de 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 (JWT) signés dans les versions précédentes, NGINX Plus prend désormais en charge les JWT chiffrés afin de garantir la confidentialité et l'intégrité des données 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, ainsi que la prise en charge des services d’authentification HTTP pour les connexions et sessions TCP/UDP – ouvrent la voie à de nombreux nouveaux cas d’utilisation avancés.
• Intégration avec F5 Device ID+ – Cet identifiant d’appareil haute précision en temps réel attribue un identifiant unique à chaque appareil qui visite votre site, ce qui permet de renforcer la protection contre les acteurs malveillants connus et de personnaliser l’expérience des visiteurs récurrents.

Pour compléter cette version : la conservation facultative des résultats des contrôles d’intégrité obligatoires lors des rechargements de configuration, ainsi que des valeurs dynamiques pour les attributs des cookies.

Modifications importantes du 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 dépôt des 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 dès que possible toutes les directives set_cookie_flag de votre configuration par des directives proxy_cookie_flags. Consultez également Indicateurs de cookie dynamiques.

Modifications de la prise en charge des plateformes

• 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 plus ancienne version prise en charge est la version 10
• Anciens systèmes d’exploitation obsolètes et dont la 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 permet d’utiliser 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 du système qui utilisent OpenSSL fonctionnent toujours correctement avec OpenSSL 1.1.

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

Nous avons réorganisé les dépôts de paquets NGINX Plus, ce qui a entraîné des modifications de la procédure d’installation.

La modification de l’organisation des dépôts reflète l’élargissement de notre gamme de produits et de l’écosystème de produits qui dépendent de NGINX Plus. Pour NGINX Plus en particulier, le dépôt pkgs.nginx.com/plus remplace l’ancien dépôt plus-pkgs.nginx.com.

Lorsque vous installez et mettez à niveau NGINX Plus, le gestionnaire de paquets du système d’exploitation (apt, yum ou équivalent) est configuré avec le dépôt logiciel de NGINX Plus. Sur les systèmes existants configurés pour utiliser le dépôt plus-pkgs.nginx.com, vous devez mettre à jour le gestionnaire de paquets afin qu’il pointe vers pkgs.nginx.com/plus (suivi du dernier élément du chemin indiquant 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 les instructions actualisées concernant l’installation initiale, consultez la section « Installation de NGINX Plus » du guide d’administration de NGINX Plus.

Regroupement des directives de gestion des connexions HTTP

Alors que la norme HTTP/3 est en voie de finalisation et que l’utilisation de HTTP/2 augmente, nous avons simplifié la configuration des connexions persistantes. Dans NGINX Plus R24 et les versions ultérieures, les directives de configuration qui ne s’appliquaient auparavant qu’à HTTP/1.1 fonctionnent également avec HTTP/2. Il n’est désormais plus nécessaire d’utiliser des directives différentes pour une même fonctionnalité simplement parce que la version du protocole diffère.

Directive obsolète Directive de remplacementhttp2_idle_timeout keepalive_timeouthttp2_max_field_size
http2_max_header_size large_client_header_buffershttp2_max_requests keepalive_requestshttp2_recv_timeout client_header_timeout

Fermeture plus agressive des connexions

Dans NGINX Plus R23 et les versions ultérieures, les directives « lingering_close », « lingering_time » et « lingering_timeout » fonctionnent aussi bien avec HTTP/2 qu’avec HTTP/1.1. Une gestion plus efficace des connexions HTTP/2 grâce à ces directives améliore les capacités HTTP/2 globales de NGINX Plus.

NGINX Plus R24 modifie considérablement l’effet de ces directives et élimine un bug potentiel : si le pool de connexions de processus de travail disponibles est épuisé, NGINX Plus commence à fermer non seulement les connexions persistantes, mais aussi celles en mode de fermeture différée.

Modification du niveau de gravité des changements d’état de santé consignés

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

• Le passage de l’état « sain » à l’état « défaillant » est consigné avec le niveau avertissement (auparavant information).
• Le passage de l’état « unhealthy » à l’état « healthy » est journalisé au niveau notice (auparavant info).

Nouvelles fonctionnalités en détail

Jetons Web JSON chiffrés

L’utilisation des jetons Web JSON (JWT) continue de se développer. 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 des revendications encodées dans le jeton. Cependant, JWS ne garantit pas la confidentialité des revendications : elles peuvent être lues par tout composant ayant accès au jeton. TLS/SSL limite l’exposition des jetons en transit, mais les jetons stockés dans les navigateurs Web et autres clients restent exposés.

NGINX Plus R24 prend désormais en charge les 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 permettant d’identifier une personne (PII) peuvent désormais être encodées dans des JWT sans risque que ces données soient divulguées par des clients non sécurisés.

NGINX Plus R24 et les versions ultérieures prennent en charge les JWT signés et chiffrés. Les jetons signés sont utilisés par défaut et ne nécessitent aucune configuration explicite. La nouvelle directive « auth_jwt_type » permet de configurer le chiffrement des JWT.

Chargement de l’exemple de code…

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

Algorithmes de gestion des clés JWE

• A128KW, A192KW, A256KW

• A128GCMKW, A192GCMKW, A256GCMKW

• dir – Configure l’utilisation directe d’une clé symétrique partagée comme clé de chiffrement du contenu

Algorithmes de chiffrement du contenu JWE

• A128CBC-HS256, A192CBC-HS384, A256CBC-HS512

• A128GCM, A192GCM, A256GCM

Une étape majeure dans la maturité du module JavaScript de NGINX

NGINX Plus R24 marque une étape majeure dans le développement du module JavaScript NGINX (njs), qui atteint désormais la version 0.5.3. Deux améliorations importantes vous permettent d’étendre NGINX Plus avec des solutions personnalisées adaptées à 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é pouvant être utilisé pour effectuer des requêtes HTTP lors du traitement HTTP ou TCP/UDP

Si vous ne connaissez pas le module JavaScript NGINX, veuillez lire cette présentation sur notre blog<.htmla>.

[Les cas d’utilisation décrits dans cette section ne représentent qu’une partie des nombreux cas d’utilisation du module JavaScript NGINX. Pour obtenir la liste complète, consultez Cas d’utilisation du module JavaScript NGINX.]

Filtrage des réponses

L’une des fonctionnalités les plus puissantes de NGINX Plus lorsqu’il est déployé en tant que passerelle d’API ou proxy inverse est le filtrage des réponses, qui consiste à intercepter les réponses des serveurs en amont et à remplacer des chaînes dans le corps de la réponse, les en-têtes ou les deux, selon des correspondances avec des expressions régulières. Pour le trafic qui n’est pas manipulé à l’aide du module JavaScript de NGINX, le filtrage des réponses est mis en œuvre dans le module Substitution.

NGINX Plus R24 introduit une implémentation distincte du filtrage des réponses au sein du module JavaScript de NGINX, avec deux directives qui vous permettent de tirer parti de la puissance de JavaScript pour analyser et modifier le 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 fondée sur des expressions régulières, offrant ainsi un filtrage des réponses 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 examiner et modifier le corps de la réponse provenant d’un serveur mandataire. Voici quelques cas d’utilisation :

• Recherche de motifs complexes à l’aide d’expressions régulières
• Transformation du format des données
• Insertion de contenu dynamique dans les réponses

Dans cet exemple, nous analysons les réponses afin de détecter tout élément ressemblant à une clé d’accès AWS et remplaçons chaque occurrence par une valeur masquée.

Chargement de l’exemple de code…

Pour exécuter ce code, il nous suffit de référencer la fonction « maskAwsKeys » dans le bloc « location » concerné.

Chargement de l’exemple de code…

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

Vous pouvez utiliser la directive js_header_filter pour examiner, voire intercepter et modifier, le contenu des en-têtes de réponse. Prenons l’exemple d’un serveur backend qui émet plusieurs en-têtes Set-Cookie contenant des informations sensibles, mais indispensables à son bon fonctionnement. NGINX Plus peut intercepter la réponse, lire les en-têtes Set-Cookie et les enregistrer dans le magasin clé-valeur. Un en-tête Set-Cookie de remplacement peut être créé sous forme de référence au magasin clé-valeur, puis injecté dans la réponse d’origine.

Flux de requête montrant js_header_filter interagissant avec le magasin clé-valeur

Aux lignes 4 et 5 de la configuration de NGINX Plus, nous définissons le magasin clé-valeur :

Chargement de l’exemple de code…

Ensuite, aux lignes 12 et 13, nous remplaçons le cookie de référence par le contenu du magasin clé-valeur et interceptons tout nouveau cookie à l’aide de notre code JavaScript.

Chargement de l’exemple de code…

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.

Chargement de l’exemple de code…

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

Le principal cas d’usage d’une passerelle API consiste à contrôler l’accès à des ressources spécifiques. NGINX Plus offre un puissant ensemble 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 utilisent également TCP/UDP comme protocole sous-jacent, ce qui pose de nouveaux défis en matière d’authentification.

Grâce à 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 d’utiliser des services d’authentification basés sur HTTP pour le contrôle d’accès dans le contexte stream, par exemple en appelant un démon OpenPolicy Agent local lors de la mise en proxy d’une connexion à une base de données.

Cet exemple illustre l’utilisation d’un service local d’authentification HTTP sur le port 8085 pour authentifier chaque nouvelle connexion. La directive « js_access » et la fonction « ngx.fetch » implémentent conjointement, dans le contexte HTTP nouvellement instancié, une fonctionnalité similaire à l’autorisation des clients fondée sur le résultat d’une sous-requête (telle qu’implémentée par la directive « auth_request » pour les requêtes HTTP classiques). Selon le code d’état HTTP disponible dans l’Responseobjet «  », la connexion à la base de données principale est autorisée (s.allow) ou refusée (s.deny).

Chargement de l’exemple de code…

Chargement de l’exemple de code…

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

Autres améliorations de njs

Lorsqu’une variable NGINX est définie à l’aide de la directive set [HTTP][Stream] ou js_set [HTTP][Stream], sa valeur peut être remplacée lorsqu’une redirection survient pendant le traitement de la requête. La nouvelle directive js_var [HTTP][Stream] permet d’évaluer une variable à l’aide d’une fonction JavaScript et de conserver sa valeur après les redirections.

Le nouvel objet njs.on permet d’exécuter une fonction JavaScript lorsque la machine virtuelle njs s’arrête. Cela permet, par exemple, d’exécuter une fonction à la fin d’une connexion TCP.

La nouvelle propriété « s.status » de l’objet de session Stream permet d’accéder à l’état global de la session (voir « $status » pour connaître les valeurs possibles).

Intégration avec F5 Device ID+

F5 Device ID+ est une solution d’identification des appareils en temps réel et de haute précision, qui s’appuie sur une collecte avancée de signaux et sur des algorithmes éprouvés d’apprentissage automatique pour attribuer un identifiant unique à chaque appareil qui consulte votre site. Son déploiement est simple et offre des avantages immédiats à vos équipes chargées de la sécurité, des réseaux, de la lutte contre la fraude et du numérique. Il n’a jamais été aussi facile d’identifier les différents appareils qui accèdent à vos applications.

Pour savoir comment activer 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 – Améliorez vos analyses de détection et d’atténuation des attaques grâce à une identification précise des appareils. Reconnaissez les appareils déjà signalés comme suspects par vos systèmes de sécurité lorsqu’ils se reconnectent.
• Optimisez la gestion du trafic – Intégrez un identifiant unique d’appareil à la logique de routage afin de mieux gérer et optimiser le trafic réseau. Identifiez les appareils même lorsque des acteurs malveillants manipulent les données de couche 7.
• Atténuer la fraude et les risques – Surveillez le comportement des clients lors d’opérations telles que la création de comptes, l’authentification des utilisateurs, le paiement en ligne et les transactions financières, afin de détecter les schémas anormaux susceptibles d’indiquer une usurpation d’identité, entre autres menaces.
• Personnalisez et accélérez les expériences en ligne – Fluidifiez la connexion, le paiement et l’authentification pour les utilisateurs et appareils connus qui reviennent sur le site. Les tests A/B réalisés par F5 montrent que la réduction des contraintes de sécurité augmente le chiffre d’affaires, et que l’identification des appareils constitue un élément important de toute stratégie visant à réduire ces contraintes.

Fonctionnement de F5 Device ID+

Lorsqu’un utilisateur visite votre site web, F5 Device ID+ s’appuie sur JavaScript pour recueillir des informations sur le navigateur, le système d’exploitation de l’appareil, le matériel et la configuration réseau. Ces attributs alimentent le service F5 Device ID+, qui repose sur les capacités d’IA et d’apprentissage automatique de F5 Shape, reconnues dans le secteur. Les données sont traitées en temps réel et un identifiant unique est attribué à l’appareil, sauf s’il est déjà connu. Pour les appareils déjà identifiés, le comportement, les actions et d’autres propriétés peuvent être enregistrés, analysés et étudiés afin de contribuer à réduire la fraude tout en offrant une expérience fluide aux utilisateurs légitimes connus.

Autres améliorations de NGINX Plus R24

L’état des contrôles d’intégrité obligatoires peut être conservé après le rechargement de la configuration

Les contrôles d’intégrité obligatoires permettent d’activer le démarrage progressif des serveurs en amont ajoutés à l’aide de l’API NGINX Plus ou via la résolution DNS. Ils garantissent que l’intégrité des nouveaux nœuds est d’abord vérifiée, puis que leur démarrage progressif est lancé dès qu’ils sont prêts à recevoir du trafic.

Auparavant, après le rechargement de la configuration, les serveurs en amont étaient considérés comme défaillants, quel que soit leur état avant le rechargement. Par conséquent, ils n’acceptaient aucune requête client tant que la première vérification obligatoire n’avait pas réussi.

Avec NGINX Plus R24, vous pouvez marquer les contrôles d’intégrité HTTP obligatoires comme persistants, afin que leur état précédent soit conservé lors du rechargement de la configuration. Ajoutez le paramètre « persistent » à la directive « health_check », avec le paramètre « mandatory ».

Chargement de l’exemple de code…

Attributs dynamiques des cookies

Dans la version précédente de NGINX Plus, nous avons introduit la directive proxy_cookie_flags comme méthode native permettant de définir les attributs des cookies. NGINX Plus R24 étend cette fonctionnalité en permettant d’utiliser des valeurs dynamiques pour les attributs des cookies. Ainsi, certains attributs de cookies peuvent être contrôlés par des variables NGINX.

Remarque : La directive proxy_cookie_flags rend obsolète le module Cookie‑Flag, qui sera supprimé dans NGINX Plus R26. Consultez la section « Module Cookie‑Flag obsolète ».

Cet exemple utilise une map pour activer l’attribut de cookie Secure lorsque le schéma est https plutôt que http.

Chargement de l’exemple de code…

Mettez à niveau ou essayez NGINX Plus

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à NGINX Plus R24 dès que possible. Vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires, et cela permettra à NGINX de mieux vous aider lorsque vous aurez besoin d’ouvrir un ticket d’assistance.

Si vous n’avez pas encore essayé NGINX Plus, nous vous invitons à le faire, que ce soit pour la sécurité, l’équilibrage de charge et la passerelle d’API, ou comme serveur web entièrement pris en charge, doté d’API avancées de surveillance et de gestion. Vous pouvez commencer dès aujourd’hui avec un essai gratuit de 30 jours.

---