Annonce de NGINX Plus R10

Owen GarrettDirecteur senior de la gestion des produits

[Éditeur – Le module NGINX ModSecurity WAF pour NGINX Plus a officiellement cessé d’être commercialisé le 1er avril 2022 et arrivera en fin de vie le 31 mars 2024. Pour plus de détails, consultez l’article F5 NGINX ModSecurity WAF arrive en fin de vie<.htmla> sur notre blog.]

Nous sommes ravis d’annoncer la sortie de NGINX Plus Release 10 (R10), notre version la plus importante à ce jour. NGINX Plus enrichit NGINX Open Source de fonctionnalités avancées et d’un support primé, offrant ainsi aux clients une solution complète de mise à disposition d’applications. Cette version propose plusieurs nouvelles fonctionnalités qui améliorent considérablement la sécurité et les performances des applications mises à disposition par NGINX Plus, ainsi que des fonctionnalités supplémentaires pour une meilleure intégration réseau et la personnalisation de NGINX Plus au moyen de scripts.

[Éditeur – Pour en savoir plus sur les principales nouveautés de NGINX Plus R10, consultez les ressources connexes suivantes :

• Authentification des clients d’API avec JWT et NGINX Plus
• NGINX Plus R10 exploite la puissance d’IBM POWER
• Authentification des utilisateurs auprès d’applications existantes avec OpenID Connect et NGINX Plus
• Utilisation du module JavaScript de NGINX pour migrer progressivement les clients vers un nouveau serveur
• Transparence IP et retour direct au serveur avec NGINX et NGINX Plus en tant que proxy transparent
• Quelles sont les nouveautés de NGINX Plus R10 ? (webinaire à la demande)

]

NGINX Plus R10 intègre la première version de notre pare-feu pour applications web (WAF), basé sur ModSecurity et entièrement pris en charge par NGINX, Inc. Les attaques contre les applications web ont augmenté de 50 % au cours de l’année écoulée et les attaques DDoS ont plus que doublé, selon Akamai. Toutes les applications risquent désormais de subir une attaque. NGINX ModSecurity WAF contribue à protéger les applications web contre les utilisateurs malveillants et offre aux clients un outil polyvalent pour assurer la sécurité de leurs applications et de leurs données.

Le WAF NGINX ModSecurity bloque les intrus

NGINX ModSecurity WAF repose sur le nouveau logiciel ModSecurity 3 et s’exécute nativement dans NGINX Plus. Disponible en option payante supplémentaire dans notre dépôt de modules dynamiques et pris en charge par NGINX, Inc., il a été testé de manière approfondie avec NGINX Plus. Nous collaborons avec Trustwave et continuerons à proposer des mises à jour testées à mesure que nous ajouterons des fonctionnalités, améliorerons les performances et résoudrons les éventuels problèmes.

Deux nouvelles fonctionnalités supplémentaires renforcent encore les capacités de sécurité de NGINX Plus :

• Jetons Web JSON – Beaucoup de nos clients utilisent NGINX Plus comme passerelle d’API et nous ont demandé de leur proposer une méthode commune et standard pour authentifier l’accès aux API au niveau de NGINX Plus. Pour répondre à ce besoin, cette version prend désormais en charge l’authentification à l’aide de jetons Web JSON (JWT). NGINX Plus peut maintenant valider un JWT avant d’autoriser les clients à accéder aux API. Cette fonctionnalité permet aux administrateurs d’applications de sécuriser l’accès à leurs API à l’aide d’un standard ouvert, sans être captifs d’un standard propriétaire. La prise en charge native des JWT simplifie également le travail des administrateurs d’applications en transférant les opérations d’authentification – telles que la validation des jetons OpenID Connect conformes à OAuth 2.0 – des serveurs d’applications vers NGINX Plus.
• Prise en charge « double pile » des certificats ECC et RSA – Avec NGINX Plus R10, vous pouvez publier des services SSL/TLS utilisant à la fois des certificats RSA et ECC. NGINX Plus sélectionne le certificat optimal en fonction des capacités de chaque client, ce qui permet aux clients modernes d’utiliser des certificats ECC plus rapides tout en continuant à prendre en charge les anciens clients compatibles uniquement avec RSA. Les certificats ECC peuvent être jusqu’à trois fois plus rapides que les certificats RSA offrant un niveau de sécurité équivalent, ce qui se traduit par davantage de connexions SSL/TLS par serveur et des négociations SSL/TLS plus rapides.

Outre les fonctionnalités de sécurité, NGINX Plus R10 comprend :

• Prise en charge du proxy transparent – Bien que de nombreuses applications HTTP modernes puissent être configurées pour utiliser un en-tête X-Forwarded-For, certaines applications anciennes et d’autres services TCP ou UDP se réfèrent à l’adresse IP source de la transaction à des fins de journalisation, de sécurité ou d’authentification. NGINX Plus peut désormais « usurper » l’adresse IP source et le port des connexions HTTP et des connexions TCP et datagrammes UDP qu’il transmet aux serveurs en amont. Cette fonctionnalité permet d’assurer la transparence IP, une configuration dans laquelle NGINX Plus envoie des paquets avec l’adresse IP du client distant, de sorte que le serveur en amont considère que les paquets proviennent de cette adresse plutôt que d’une adresse IP locale du serveur NGINX Plus. Cette fonctionnalité peut également être utilisée pour activer le retour direct du serveur (Direct Server Return) pour les protocoles basés sur UDP.
• Prise en charge du module JavaScript NGINX – Le module JavaScript NGINX est le langage de configuration et de contrôle nouvelle génération pour NGINX et NGINX Plus. Il permet aux utilisateurs de contrôler de manière approfondie et précise la diffusion et la sécurisation de leurs applications. Dans cette version préliminaire, le module JavaScript NGINX offre un contrôle accru sur le trafic HTTP, TCP et UDP, en générant des réponses et en prenant des décisions précises afin d’acheminer les requêtes vers les serveurs les plus adaptés.

• Nouvelles améliorations de l’équilibrage de charge TCP et UDP – Les extensions du module Stream prennent désormais en charge davantage de variables NGINX, les calculs à l’aide de la directive map, les tests A/B avec la directive split_clients, les opérations Geo et GeoIP, ainsi que le routage sélectif (paramètre variable de la directive proxy_pass directive). Ces extensions vous permettent de créer des stratégies d’équilibrage de charge TCP et UDP plus sophistiquées, pilotées par le langage de configuration NGINX et la nouvelle intégration JavaScript de NGINX.

NGINX Plus R10 en détail

Pare-feu d’applications web NGINX ModSecurity

La fonctionnalité phare de NGINX Plus R10 est la première version de notre WAF, basé sur la technologie reconnue et éprouvée ModSecurity. Depuis sa première publication en open source en 2002, ModSecurity contribue à protéger certains des plus grands sites web au monde contre les utilisateurs malveillants. Il est souvent qualifié de « couteau suisse® » de la sécurité. NGINX ModSecurity WAF est une option payante supplémentaire, mise à la disposition des abonnés via notre dépôt de modules dynamiques.

NGINX ModSecurity WAF est une solution incontournable pour contribuer à sécuriser les applications critiques. Elle constitue une alternative économique aux appliances matérielles coûteuses, telles que celles proposées par F5, Citrix et Imperva, tout en offrant des fonctionnalités supérieures grâce à la flexibilité du logiciel. NGINX ModSecurity WAF peut être déployé dans n’importe quel environnement : sur des serveurs sur site ainsi que dans des clouds publics, privés et hybrides.

NGINX ModSecurity WAF contribue à protéger contre les attaques DDoS

Un WAF s’appuie sur une base de données de « règles » qui définissent les comportements malveillants à bloquer et/ou à consigner. L’ensemble de règles de base OWASP ModSecurity (CRS) est l’un des ensembles de règles les plus utilisés avec ModSecurity. NGINX ModSecurity WAF utilise l’OWASP CRS pour identifier et bloquer un large éventail d’attaques visant les applications, grâce à des fonctionnalités telles que :

• Protection contre les attaques de couche 7 – Protégez vos applications contre un large éventail d’attaques, telles que les violations du protocole HTTP, les injections SQL, les attaques XSS, RFI et LFI, entre autres.
• Atténuation des attaques DDoS – Assurez une disponibilité continue en atténuant et en réduisant l’impact des attaques DDoS sophistiquées au niveau applicatif et des botnets.
• Listes de blocage en temps réel – Bloquez automatiquement les utilisateurs malveillants connus en refusant le trafic provenant d’adresses IP identifiées comme malveillantes en fonction de leur réputation.
• Conformité à la norme PCI-DSS 6.6 – Commencez à vous conformer aux exigences de la norme PCI-DSS 6.6 afin de sécuriser les transactions en ligne.
• Journalisation des audits – Réagissez plus rapidement aux attaques et autres trafics applicatifs anormaux grâce aux informations consignées dans des journaux détaillés.

Des jeux de règles supplémentaires sont également disponibles auprès de différents fournisseurs, tels que TrustWave, à différents niveaux de prix. En outre, vous pouvez utiliser le puissant langage de règles de ModSecurity pour définir vos propres règles personnalisées afin de compléter les jeux de règles que vous utilisez.

La prise en charge du WAF NGINX ModSecurity est assurée directement par NGINX, Inc. Notre équipe d’assistance peut vous aider à installer et à configurer le WAF et l’ensemble de règles de base OWASP, ainsi qu’à résoudre les problèmes qui y sont liés.

NGINX ModSecurity WAF est disponible sous forme de module dynamique dans le dépôt NGINX Plus, que vous pouvez installer à l’aide des outils standard de gestion des paquets. Ces commandes sont destinées aux systèmes d’exploitation basés sur Debian :

# apt-get update# apt-get install nginx-plus
# apt-get install nginx-plus-module-modsecurity

Notez que seuls les abonnés ayant acheté le module WAF NGINX ModSecurity, ainsi que les abonnés et les utilisateurs de la version d’évaluation ayant demandé l’accès, peuvent télécharger le paquet nginx-plus-module-modsecurity.

Pour charger le module WAF NGINX ModSecurity, incluez la directive load_module dans le contexte « main » de niveau supérieur du fichier de configuration de NGINX Plus :

Chargement de l’exemple de code…

Pour activer le WAF NGINX ModSecurity avec NGINX Plus, incluez la directive « modsecurity » ainsi que la directive « modsecurity_rules_file » pour spécifier le jeu de règles :

Chargement de l’exemple de code…

Rechargez ensuite la configuration de NGINX Plus :

# nginx -t && nginx -s reload

Prise en charge native des JWT pour OAuth 2.0 et OpenID Connect

Grâce à la prise en charge native de la norme d’authentification JSON Web Token (JWT), NGINX Plus R10 facilite l’ajout de solutions d’authentification avancées à vos applications et API.

Les jetons JWT (prononcés « jot »), définis dans la RFC 7519, constituent le format de données sous-jacent pour les informations utilisateur dans la norme OpenID Connect, qui est la couche d’identité standard reposant sur le protocole OAuth 2.0. Les responsables du déploiement d’API et de microservices se tournent également vers la norme JWT pour sa simplicité et sa flexibilité.

[Éditeur – Pour les cas d’usage qui tirent parti de la prise en charge native des JWT, consultez ces articles de blog :

• Authentification des clients d’API avec JWT et NGINX Plus

• Authentification des utilisateurs auprès d’applications existantes avec OpenID Connect et NGINX Plus

]

NGINX Plus valide le JWT avant d’autoriser l’accès aux clients

En tant que proxy inverse et répartiteur de charge, NGINX Plus se place devant les applications, ce qui lui permet de simplifier le développement applicatif en prenant en charge la validation du JWT fourni dans chaque requête HTTP. Cela présente deux avantages. Premièrement, NGINX Plus peut empêcher les requêtes non authentifiées, mal formées et malveillantes d’atteindre l’application, lui épargnant ainsi les efforts et les risques liés au traitement de telles requêtes.

Le deuxième avantage est que NGINX Plus a accès à tous les champs du JWT validé (après vérification de la signature) et peut exploiter la puissance et la flexibilité intrinsèques de sa syntaxe de configuration pour fournir des solutions d’authentification sophistiquées, aussi bien pour les microservices que pour les API :

• Un cas d’utilisation courant pour les microservices consiste à faire valider le JWT par NGINX Plus et à transmettre l’identité de l’utilisateur authentifié à l’application backend sous la forme d’un en-tête HTTP. Il n’est ainsi plus nécessaire d’implémenter la même fonctionnalité d’authentification dans chaque microservice.
• Pour les API, NGINX Plus peut limiter le débit d’accès réellement par utilisateur, au lieu de s’appuyer sur une correspondance approximative entre les adresses IP et les utilisateurs finaux.

L’extrait d’exemple de configuration de NGINX Plus ci-dessous montre comment utiliser des JWT pour protéger un site Web.

La directive « auth_jwt » indique à NGINX Plus d’utiliser un JWT pour authentifier les utilisateurs qui envoient des requêtes à un domaine, dans ce cas myrealm. La directive « auth_jwt_key_file » indique la clé web JSON (JWK) à utiliser pour valider la signature du jeton ; elle joue un rôle similaire à celui de la clé publique dans le chiffrement SSL/TLS. L’emplacement du fichier doit être accessible à NGINX Plus.

Lorsqu’il valide et analyse le jeton, NGINX Plus crée automatiquement des variables NGINX pour les « revendications » du JWT, qui représentent les entités qui lui sont associées (par exemple, son émetteur, l’utilisateur auquel il a été délivré et le destinataire prévu). Les noms de ces variables commencent tous par $jwt_claim_. Vous pouvez ensuite utiliser la directive add_header pour que NGINX Plus transmette une revendication aux serveurs backend sous la forme d’un en-tête HTTP dont la valeur est celle de la variable $jwt_claim_. Dans notre exemple, NGINX Plus transmet l’identité de l’utilisateur à l’application backend dans la variable $jwt_claim_sub, qui correspond à l’identifiant de l’utilisateur (revendication sub) dans le JWT.

Chargement de l’exemple de code…

Avec NGINX Plus R8, nous avons publié une version préliminaire de la prise en charge d’OAuth2. Dans l’implémentation de NGINX Plus R10, nous avons pris en compte les retours de nos clients afin de proposer une solution prête pour la production, qui répond aux cas d’usage les plus importants dans le domaine complexe de l’authentification des utilisateurs et des machines.

Prise en charge des certificats RSA et ECC en « double pile »

Il existe désormais de nombreuses raisons de commencer à chiffrer l’ensemble du trafic applicatif avec SSL/TLS. Google favorise les sites chiffrés avec SSL/TLS en leur accordant un meilleur classement dans les moteurs de recherche. En outre, les normes web modernes, telles que HTTP/2, imposent le chiffrement SSL/TLS pour tous les sites web.

Avec NGINX Plus R10, vous pouvez publier des services SSL/TLS utilisant à la fois des certificats RSA et ECC. Lors de nos tests, les certificats ECC se sont révélés jusqu’à trois fois plus rapides que les certificats RSA offrant un niveau de sécurité équivalent, ce qui permet d’établir davantage de connexions SSL/TLS par serveur et d’accélérer les négociations SSL/TLS. NGINX Plus sélectionne le certificat optimal en fonction des capacités de chaque client, permettant ainsi aux clients modernes d’utiliser des certificats ECC plus rapides tout en continuant à prendre en charge les anciens clients compatibles uniquement avec RSA.

Pour prendre en charge à la fois les certificats RSA et ECC, il suffit d’inclure, dans la configuration d’un serveur virtuel, une paire de directives « ssl_certificate » et « ssl_certificate_key » pour chaque type de certificat, comme dans l’exemple suivant.

Chargement de l’exemple de code…

Proxy transparent

Nous ajoutons continuellement de nouvelles fonctionnalités à NGINX Plus, telles que la répartition de charge TCP et UDP, afin de prendre en charge un éventail plus large d’applications et de modèles de déploiement. Avec NGINX Plus R10, nous avons ajouté une fonctionnalité de proxy transparent qui permet à NGINX Plus d’envoyer des paquets aux serveurs en amont en utilisant n’importe quelle adresse IP et n’importe quel port sources. Cela permet de mettre en œuvre des configurations telles que la transparence IP et le retour direct du serveur.

Transparence IP est une configuration dans laquelle l’équilibreur de charge (NGINX Plus) utilise l’adresse IP du client distant comme adresse IP source dans les paquets qu’il envoie aux serveurs en amont. Ainsi, les serveurs en amont voient les paquets comme provenant de l’adresse IP du client distant, plutôt que d’une adresse IP locale de l’équilibreur de charge. Cela est important lorsque les applications utilisent l’adresse IP source à des fins de journalisation, de sécurité, de limitation du débit ou d’authentification.

La transparence IP est également un élément constitutif d’une technique d’équilibrage de charge réseau appelée « retour direct du serveur » (DSR). NGINX Plus peut utiliser le DSR pour les protocoles basés sur UDP (mais pas pour TCP ou HTTP), ce qui permet aux paquets de retour de contourner complètement l’équilibreur de charge et d’être envoyés directement au client distant.

En mode DSR, le serveur backend répond directement au client

La transparence IP et le DSR sont configurés à l’aide du nouveau paramètre transparent des directives proxy_bind, fastcgi_bind, memcached_bind, scgi_bind et uwsgi_bind. L’exemple suivant montre comment configurer le DSR pour un serveur DNS en amont. La directive proxy_responses indique que NGINX Plus n’a pas besoin de recevoir les réponses du serveur (zéro est la valeur appropriée pour le DSR).

Chargement de l’exemple de code…

Notez que les contrôles d’intégrité passifs ne sont pas efficaces lorsque DSR est activé, car ils impliquent que NGINX Plus vérifie que le serveur a envoyé une réponse au client. La configuration de contrôles d’intégrité actifs tenant compte de l’application est obligatoire dans une configuration DSR. Pour consulter un exemple, reportez-vous à nos instructions détaillées sur leur configuration pour des serveurs DNS avec équilibrage de charge.

Les configurations de transparence IP et de DSR sont complexes et impliquent des exigences supplémentaires en matière de routage et de réécriture des paquets qui dépassent le cadre du logiciel NGINX Plus. Pour obtenir des instructions complètes, consultez l’article « Transparence IP et retour direct au serveur avec NGINX et NGINX Plus en tant que proxy transparent » sur notre blog.

Le module JavaScript NGINX pour les applications basées sur HTTP, TCP et UDP

[Éditeur – Le module JavaScript NGINX s’appelait auparavant nginScript. Le module est devenu disponible pour tous dans NGINX Plus R12 (et NGINX 1.11.10).

Pour une présentation détaillée d’autres cas d’utilisation du module JavaScript NGINX, consultez Cas d’utilisation du module JavaScript NGINX.

Le code de cette section a été mis à jour pour utiliser la directive js_import, qui remplace la directive js_include à partir de NGINX Plus R23. Pour plus d’informations, consultez la documentation de référence du module JavaScript NGINX : la section « Exemple de configuration » présente la syntaxe correcte pour les fichiers de configuration NGINX et les fichiers JavaScript.]

NGINX Plus R10 inclut une version préliminaire de notre nouveau langage de configuration NGINX JavaScript. Toutes les fonctionnalités ne sont pas encore disponibles, et nous vous invitons à nous faire part de vos commentaires sur le travail accompli jusqu’à présent. NGINX JavaScript vous permet d’utiliser du code JavaScript pour effectuer des actions complexes et personnalisées sur le trafic HTTP, TCP et UDP. Il offre un nouveau moyen puissant de contrôler la diffusion et la sécurisation de vos applications. Avec NGINX JavaScript, vous pouvez :

• Écrivez des fonctions « sans serveur » directement dans NGINX Plus à l’aide du puissant langage de programmation JavaScript
• Formatez, manipulez et transformez les données d’API
• Fournir des services TCP simples, tels qu’un serveur de temps
• Utilisez JavaScript pour définir des variables NGINX, créer des règles personnalisées de répartition de charge, des clés de cache, et bien plus encore

La préversion de NGINX JavaScript est disponible dans notre dépôt de modules dynamiques. Vous pouvez l’installer à l’aide des outils standard de gestion des paquets. Ces commandes sont destinées aux systèmes d’exploitation basés sur Debian :

# apt-get update
# apt-get install nginx-plus
# apt-get install nginx-plus-module-njs

Pour charger les modules JavaScript NGINX pour HTTP et TCP/UDP, ajoutez la directive load_module dans le contexte « main » de niveau supérieur du fichier de configuration de NGINX Plus :

Chargement de l’exemple de code…

Rechargez ensuite la configuration de NGINX Plus afin de charger les modules JavaScript NGINX :

# nginx -t && nginx -s reload

Les utilisateurs de NGINX Open Source peuvent obtenir NGINX JavaScript depuis notre dépôt de code open source.

Le code JavaScript n’est pas inclus directement dans la configuration de NGINX Plus. Il est chargé à l’aide de la directive js_import. Dans cet exemple, le code JavaScript d’une fonction « sans serveur » simple est chargé depuis /etc/nginx/conf.d/functions.js. La directive js_content indique à NGINX Plus d’appeler la fonction JavaScript et de renvoyer les résultats au client.

Chargement de l’exemple de code…

Le code JavaScript dans /etc/nginx/conf.d/functions.js complète une chaîne de caractères avec un ensemble de caractères spécifié :

Chargement de l’exemple de code…

Fonctionnalités supplémentaires

NGINX Plus R10 apporte plusieurs améliorations supplémentaires pour vous aider à assurer une diffusion irréprochable de vos applications, notamment :

• TCP/UDP load balancing, implemented in the Stream module, now has greater feature parity with HTTP load balancing. Newly supported modules include Split Clients for A/B testing, GeoIP to take actions based on the geographical location of clients, and Geo to define variables based on IP address. More information is available through additional NGINX variables, and you can perform routing decisions using a variable as the parameter to the proxy_pass directive.
• Un problème courant pour les applications à fort trafic est l’épuisement des ports éphémères, qui empêche la création de nouvelles connexions aux serveurs en amont lorsque le système d’exploitation ne dispose plus de numéros de port disponibles. Pour y remédier, NGINX Plus utilise désormais l’option de socket IP_BIND_ADDRESS_NO_PORT lorsqu’elle est disponible. Cette option permet de réutiliser les ports sources pour les connexions sortantes vers les serveurs en amont, à condition que le « quadruplet » standard (adresse IP source, adresse IP de destination, port source, port de destination) soit unique. Elle est disponible sur les systèmes équipés du noyau Linux version 4.2 ou ultérieure et de glibc 2.22 ou ultérieure.
• NGINX Plus génère automatiquement la nouvelle variable $request_id pour chaque nouvelle requête HTTP, attribuant ainsi à la requête un « ID de transaction » unique. Cela facilite le traçage des applications et apporte des fonctionnalités APM aux outils d’analyse des journaux. L’ID de transaction est transmis par proxy aux applications backend et aux microservices afin que tous les composants du système puissent consigner un identifiant cohérent pour chaque transaction.
• Les directives « proxy_request_buffering », « fastcgi_request_buffering », « scgi_request_buffering » et « uwsgi_request_buffering » fonctionnent désormais avec HTTP/2 et permettent d’activer ou de désactiver la mise en mémoire tampon des requêtes.
• La nouvelle directive « http2_body_preread_size » permet aux clients HTTP/2 de commencer immédiatement à envoyer le corps de la requête. Cette directive contrôle la taille du tampon utilisé avant que NGINX Plus ne commence à lire le corps de la requête du client.

Le package NGINX Plus Extras est obsolète

Comme nous l’avions annoncé à l’avance lors de la sortie de NGINX Plus R9, R10 est la dernière version à inclure le package NGINX Plus Extras.

Nous vous recommandons vivement de modifier dès maintenant vos procédures d’installation et de configuration afin d’utiliser le paquet nginx-plus et de charger dynamiquement les modules du paquet nginx-plus-extras dont vous avez réellement besoin. À partir de NGINX Plus R11, ce sera la seule façon d’utiliser des modules qui ne sont pas intégrés au paquet nginx-plus.

Pour passer au paquet nginx-plus et aux modules dynamiques, procédez comme suit :

1. Supprimez le paquet nginx-plus-extras, puis installez nginx-plus ainsi que les modules dynamiques que vous souhaitez utiliser. Pour les systèmes basés sur Debian, utilisez les commandes suivantes :

# apt-get update
# apt-get remove nginx-plus-extras
# apt-get install nginx-plus
# apt-get install module-name

1. Dans le contexte principal (de premier niveau) du fichier /etc/nginx/nginx.conf, ajoutez une directive load_module pour chaque module chargé dynamiquement :

   Chargement de l’exemple de code…

2. Vérifiez la validité syntaxique de la nouvelle configuration, puis rechargez-la :

# nginx -t && nginx -s reload

Mettez à niveau ou essayez NGINX Plus

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à la version 10 dès que possible. Vous bénéficierez ainsi de plusieurs correctifs et améliorations, et cela nous permettra de mieux vous aider si vous devez ouvrir un ticket d’assistance. Les instructions d’installation et de mise à niveau sont disponibles sur le portail client NGINX Plus.

REMARQUE: NGINX Plus R10 est la dernière version à inclure le paquet nginx-plus-extras. Consultez la section « Le paquet NGINX Plus Extras est obsolète » ci-dessus.

Si vous n’avez pas encore essayé NGINX Plus, nous vous invitons à le tester pour l’accélération Web, l’équilibrage de charge et la mise à disposition d’applications, ou comme serveur Web entièrement pris en charge, doté d’API avancées de surveillance et de gestion. Vous pouvez commencer gratuitement dès aujourd’hui avec une évaluation de 30 jours et constater par vous-même comment NGINX Plus peut vous aider à déployer vos applications et à les faire évoluer.

Plus d’informations sur NGINX Plus R10

Pour en savoir plus sur les principales nouveautés de NGINX Plus R10, consultez les ressources connexes suivantes :

• Authentification des clients d’API avec JWT et NGINX Plus
• NGINX Plus R10 exploite la puissance d’IBM POWER
• Authentification des utilisateurs auprès d’applications existantes avec OpenID Connect et NGINX Plus
• Utiliser le module JavaScript de NGINX pour migrer progressivement les clients vers un nouveau serveur
• Transparence IP et retour direct du serveur avec NGINX et NGINX Plus en tant que proxy transparent
• Quoi de neuf dans NGINX Plus R10 ? (webinaire à la demande)

[La commercialisation de NGINX ModSecurity WAF a officiellement pris fin le 1er avril 2022 et sa fin de vie est effective depuis le 31 mars 2024. Pour plus de détails, consultez l’article « F5 NGINX ModSecurity WAF passe en fin de vie » sur notre blog.]

À propos de l’auteur

Owen GarrettDirecteur senior de la gestion des produits

Autres articles de Owen Garrett