Annonce de NGINX Plus R10

[ Éditeur – Le module WAF NGINX ModSecurity pour NGINX Plus est officiellement en fin de commercialisation depuis le 1er avril 2022 et passe en fin de vie à compter du 31 mars 2024 . Pour plus de détails, voir F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> sur notre blog.]

Nous sommes ravis d'annoncer NGINX Plus Release 10 (R10), notre version la plus importante à ce jour. NGINX Plus étend NGINX Open Source avec des fonctionnalités avancées et un support primé, offrant aux clients une solution complète de distribution d'applications. Avec cette version, nous fournissons un certain nombre de nouvelles fonctionnalités pour améliorer considérablement la sécurité et les performances des applications fournies par NGINX Plus, ainsi que des fonctionnalités supplémentaires pour une meilleure intégration réseau et la prise en charge de la personnalisation de NGINX Plus via des scripts.

[ Éditeur – Pour plus de détails sur les nouvelles fonctionnalités clés de NGINX Plus R10, consultez ces ressources associées :

• Authentification des clients API avec JWT et NGINX Plus
• NGINX Plus R10 exploite la puissance d'IBM
• Authentification des utilisateurs sur des applications existantes avec OpenID Connect et NGINX Plus
• Utilisation du module JavaScript NGINX pour effectuer la transition progressive des clients vers un nouveau serveur
• Transparence IP et retour direct du serveur avec NGINX et NGINX Plus comme proxy transparent
• Quoi de neuf dans NGINX Plus R10 ? (webinaire à la demande)

]

NGINX Plus R10 présente la version initiale de notre pare-feu d'application Web (WAF) , optimisé par ModSecurity et entièrement pris en charge par NGINX, Inc. Selon Akamai, les attaques d'applications Web ont augmenté de 50 % au cours de l'année écoulée et les attaques DDoS ont plus que doublé. Chaque application est désormais exposée au risque d’être attaquée. NGINX ModSecurity WAF aide à protéger les applications Web contre les utilisateurs malveillants et offre aux clients un outil polyvalent pour aider à protéger leurs applications et leurs données.

NGINX ModSecurity WAF est basé sur le nouveau logiciel ModSecurity 3 et fonctionne nativement dans NGINX Plus. Disponible en option payante dans notre référentiel de modules dynamiques et pris en charge par NGINX, Inc., il a été testé en profondeur avec NGINX Plus. Nous travaillons avec Trustwave et maintiendrons des mises à jour testées au fur et à mesure que nous ajouterons des fonctionnalités, améliorerons les performances et résoudrons les problèmes.

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

• Jetons Web JSON – Beaucoup de nos clients utilisent NGINX Plus comme passerelle API et nous ont demandé un moyen commun et standard d’authentifier l’accès aux API au niveau de la couche NGINX Plus. Pour répondre à ce besoin, avec cette version, nous ajoutons la prise en charge de l’authentification à l’aide de jetons Web JSON (JWT).

  NGINX Plus peut désormais 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 avec une norme ouverte, évitant ainsi le verrouillage d’un fournisseur sur une norme propriétaire. La prise en charge native de JWT réduit également la complexité pour les administrateurs d’applications en déchargeant les opérations d’authentification (telles que la validation des jetons OpenID Connect compatibles OAuth 2.0) des serveurs d’applications vers NGINX Plus.

• Prise en charge « Dual-Stack » pour les certificats ECC et RSA – Avec NGINX Plus R10, vous pouvez publier des services SSL/TLS à l’aide de certificats RSA et ECC. NGINX Plus sélectionne le certificat optimal en fonction des capacités de chaque client, permettant aux clients modernes d'utiliser des certificats ECC à plus haut débit tout en prenant en charge les anciens clients RSA uniquement. Les certificats ECC peuvent être jusqu'à 3 fois plus rapides que les certificats RSA de puissance équivalente ; cela se traduit par davantage de connexions SSL/TLS par serveur et des négociations SSL/TLS plus rapides.

En plus des 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 s'appuyer sur un en-tête X-Forwarded-For , certaines applications héritées et d'autres services TCP ou UDP font référence à 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 TCP et des datagrammes UDP qu'il transmet aux serveurs en amont. Cela peut être utilisé pour fournir une transparence IP , une configuration dans laquelle NGINX Plus envoie des paquets avec l'adresse IP du client distant afin que le serveur en amont considère les paquets comme provenant de cette adresse plutôt que d'une adresse IP locale sur le serveur NGINX Plus. Cette fonctionnalité peut également être utilisée pour activer le retour direct au serveur 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 de nouvelle génération pour NGINX et NGINX Plus, offrant aux utilisateurs un contrôle approfondi et précis sur la manière dont leurs applications sont livrées et sécurisées. Dans cette version préliminaire, le module JavaScript NGINX augmente votre contrôle sur le trafic HTTP, TCP et UDP, générant des réponses et prenant des décisions précises pour acheminer les requêtes vers les serveurs optimaux.
• Autres améliorations de l'équilibrage de charge TCP et UDP – Les extensions du module Stream ajoutent la prise en charge de davantage de variables NGINX , des calculs à l'aide de la directive map , la prise en charge des tests A/B avec la directive split_clients , les opérations Geo et GeoIP et le routage sélectif ( paramètre variable de la directive proxy_pass ). Ces extensions vous permettent de créer des politiques d’équilibrage de charge TCP et UDP plus sophistiquées, pilotées par le langage de configuration NGINX et la nouvelle intégration JavaScript NGINX.

NGINX Plus R10 en détail

Pare-feu d'application Web NGINX ModSecurity

La fonctionnalité principale de NGINX Plus R10 est la version initiale de notre WAF, basé sur la technologie ModSecurity bien connue et fiable. Depuis sa première version open source en 2002, ModSecurity a contribué à protéger certaines des plus grandes propriétés Web du monde contre les utilisateurs malveillants. On l’appelle communément le « couteau suisse® » de la sécurité. NGINX ModSecurity WAF est une option payante et est fournie aux abonnés via notre référentiel de modules dynamiques.

NGINX ModSecurity WAF est une solution indispensable pour sécuriser les applications critiques. Il offre une alternative rentable aux appareils matériels rigides et coûteux , tels que ceux fournis par F5, Citrix et Imperva, tout en dépassant leurs capacités avec la flexibilité du logiciel. NGINX ModSecurity WAF peut être déployé dans n’importe quel environnement : serveurs sur site et clouds publics, privés et hybrides.

Un WAF fonctionne sur une base de données de « règles » qui définissent les comportements malveillants à bloquer et/ou à enregistrer. 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 le CRS OWASP pour identifier et bloquer une large gamme d'attaques d'applications, avec 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 HTTP, les injections SQL, les attaques XSS, RFI et LFI, etc.
• Atténuation des attaques DDoS – Maintenez une disponibilité continue en atténuant et en réduisant l’effet des attaques DDoS et des botnets sophistiqués au niveau des applications.
• Listes de refus en temps réel : bloquez automatiquement les utilisateurs malveillants connus en refusant le trafic provenant d'adresses IP connues pour être malveillantes en fonction de leur réputation.
• Conformité PCI-DSS 6.6 – Commencez à vous conformer aux exigences PCI-DSS 6.6 pour des transactions en ligne sécurisées.
• Journalisation d’audit – Réagissez plus rapidement aux attaques et à tout autre trafic d’application anormal à l’aide des informations contenues dans des journaux détaillés.

Des ensembles de règles supplémentaires sont également disponibles auprès de différents fournisseurs, tels que TrustWave , à différents niveaux de coût. De plus, vous pouvez utiliser le puissant langage de règles ModSecurity pour définir vos propres règles personnalisées qui augmentent les ensembles de règles que vous utilisez.

La prise en charge de NGINX ModSecurity WAF est fournie directement par NGINX, Inc. Notre équipe d'assistance peut vous aider à installer, configurer et déboguer les problèmes liés au WAF et à l'ensemble de règles de base OWASP.

NGINX ModSecurity WAF est disponible sous forme de module dynamique dans le référentiel NGINX Plus que vous installez à l'aide d'outils de gestion de packages standard. Ces commandes sont destinées aux systèmes d’exploitation basés sur Debian :

# apt-get mise à jour # apt-get installation nginx-plus # apt-get installation nginx-plus-module-modsecurity

Notez que seuls les abonnés qui ont acheté le module NGINX ModSecurity WAF, ainsi que les abonnés et évaluateurs qui ont demandé l'accès, peuvent télécharger le package 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 NGINX Plus :

Pour activer NGINX ModSecurity WAF avec NGINX Plus, incluez la directive modsecurity avec la directive modsecurity_rules_file pour spécifier l'ensemble de règles :

Rechargez ensuite la configuration NGINX Plus :

# nginx -t && nginx -s recharger

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

Avec la prise en charge native de la norme d'authentification JSON Web Token (JWT), NGINX Plus R10 facilite l'ajout de solutions d'authentification sophistiquées à vos applications et API.

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

[ Éditeur – Pour les cas d’utilisation qui exploitent la prise en charge native de JWT, consultez ces blogs :

• Authentification des clients API avec JWT et NGINX Plus
• Authentification des utilisateurs sur des applications existantes avec OpenID Connect et NGINX Plus

]

En tant que proxy inverse et équilibreur de charge , NGINX Plus se place devant les applications, ce qui le place idéalement en position de simplifier le développement d'applications en déchargeant la validation du JWT fourni dans chaque requête HTTP. Cela présente deux avantages. Tout d’abord, NGINX Plus peut aider à empêcher les demandes non authentifiées, malformées et malveillantes d’atteindre l’application, la protégeant ainsi des efforts et des risques liés au traitement de telles demandes.

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 utiliser la puissance et la flexibilité inhérentes à sa syntaxe de configuration pour fournir des solutions d'authentification sophistiquées pour les microservices et les API :

• Un cas d’utilisation typique pour les microservices consiste à demander à NGINX Plus de valider le JWT et de fournir l’identité de l’utilisateur authentifié à l’application backend sous forme d’en-tête HTTP. Cela élimine le besoin d’implémenter la même fonctionnalité d’authentification encore et encore, dans chaque microservice.
• Pour les API, NGINX Plus peut limiter l’accès sur une base réelle par utilisateur au lieu de s’appuyer sur le mappage approximatif des adresses IP aux utilisateurs finaux.

L'extrait de configuration NGINX Plus suivant montre comment utiliser les JWT pour protéger un site Web.

La directive auth_jwt indique à NGINX Plus d'utiliser JWT pour authentifier les utilisateurs effectuant des demandes pour un domaine, dans ce cas myrealm . La directive auth_jwt_key_file indique quelle clé Web JSON (JWK) utiliser pour valider la signature du jeton ; elle fonctionne comme la clé publique dans le cryptage SSL/TLS. L'emplacement du fichier doit être accessible à NGINX Plus.

Lorsque NGINX Plus valide et analyse le jeton, il crée automatiquement des variables NGINX pour les « revendications » dans le JWT, qui représentent les entités qui lui sont associées (son émetteur, l'utilisateur à qui il a été émis et le destinataire prévu, par exemple). Les noms de variables commencent tous par $jwt_claim_ . Vous pouvez ensuite utiliser la directive add_header pour que NGINX Plus transmette une réclamation aux serveurs principaux sous la forme d'un en-tête HTTP défini sur la valeur 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'ID utilisateur ( sub claim) dans le JWT.

Dans NGINX Plus R8, nous avons publié un aperçu technologique de la prise en charge d'OAuth2. Dans l'implémentation de NGINX Plus R10, nous avons pris en compte les commentaires de nos clients pour fournir une implémentation prête pour la production qui répond aux cas d'utilisation les plus précieux dans le monde complexe de l'authentification des utilisateurs et des ordinateurs.

Prise en charge des certificats RSA et ECC « Dual-Stack »

Il existe désormais de nombreuses raisons de commencer à crypter SSL/TLS tout le trafic des applications. Google récompense les sites cryptés SSL/TLS avec des classements plus élevés dans les moteurs de recherche . De plus, les normes Web modernes, telles que HTTP/2, imposent le cryptage SSL/TLS pour tous les sites Web.

Avec NGINX Plus R10, vous pouvez publier des services SSL/TLS en utilisant des certificats RSA et ECC. Lors de nos tests, les certificats ECC étaient jusqu'à 3 fois plus rapides que les certificats RSA de puissance équivalente ; cela se traduit par davantage de connexions SSL/TLS par serveur et des échanges SSL/TLS plus rapides. NGINX Plus sélectionne le certificat optimal en fonction des capacités de chaque client, permettant aux clients modernes d’utiliser des certificats ECC à plus haut débit tout en prenant en charge les anciens clients RSA uniquement.

Pour prendre en charge les certificats RSA et ECC, dans la configuration d'un serveur virtuel, incluez simplement une paire de directives ssl_certificate et ssl_certificate_key pour chaque type de certificat, comme indiqué dans l'exemple suivant.

Proxy transparent

Nous ajoutons continuellement des fonctionnalités à NGINX Plus, telles que l'équilibrage de charge TCP et UDP , pour prendre en charge une plus large gamme 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 source et n'importe quel port. Cela permet des configurations telles que la transparence IP et le retour direct au serveur.

La 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. Cela signifie que les serveurs en amont voient les paquets comme provenant de l'adresse IP du client distant, plutôt que d'une adresse IP locale sur l'équilibreur de charge. Cela est important lorsque les applications font référence à l’adresse IP source à des fins de journalisation, de sécurité, de limitation de débit ou d’authentification.

La transparence IP est également un élément de base d’une technique d’équilibrage de charge réseau appelée Direct Server Return (DSR). NGINX Plus peut effectuer DSR pour les protocoles basés sur UDP (mais pas TCP ou HTTP), permettant aux paquets de retour de contourner complètement l'équilibreur de charge et d'aller directement au client distant.

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

Notez que les contrôles de santé 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 des contrôles d’intégrité prenant en charge les applications actives est obligatoire pour une configuration DSR. Pour un exemple, veuillez consulter nos instructions détaillées pour les configurer pour les serveurs DNS à charge équilibrée.

Les configurations de transparence IP et DSR sont complexes, avec des exigences supplémentaires de routage et de réécriture de paquets qui ne relèvent pas du champ d'application du logiciel NGINX Plus. Pour des instructions complètes, consultez Transparence IP et retour direct du serveur avec NGINX et NGINX Plus comme 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 généralement disponible dans NGINX Plus R12 (et NGINX 1.11.10).

Pour des explorations détaillées d'autres cas d'utilisation du module JavaScript NGINX, voir Cas d'utilisation du module JavaScript NGINX .

Le code de cette section est mis à jour pour utiliser la directive js_import , qui remplace la directive js_include dans NGINX Plus R23 et versions ultérieures. Pour plus d’informations, consultez la documentation de référence du module JavaScript NGINX – la section Exemple de configuration montre la syntaxe correcte pour la configuration NGINX et les fichiers JavaScript. ]

NGINX Plus R10 inclut une version préliminaire de notre nouveau langage de configuration JavaScript NGINX. Les fonctionnalités ne sont pas encore complètes et nous apprécions tous les commentaires sur le travail effectué 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 manière dont vos applications sont livrées et sécurisées. Avec NGINX JavaScript vous pouvez :

• Écrivez des fonctions « sans serveur » directement dans NGINX Plus à l'aide du puissant langage de programmation JavaScript
• Formater, manipuler et transformer les données API
• Fournir des services TCP simples, tels qu'un serveur de temps
• Utilisez JavaScript pour définir des variables NGINX, créer des décisions d'équilibrage de charge personnalisées, des clés de cache, etc.

L'aperçu JavaScript NGINX est disponible dans notre référentiel de modules dynamiques . Vous pouvez l'installer à l'aide d'outils de gestion de paquets standard. Ces commandes sont destinées aux systèmes d’exploitation basés sur Debian :

# apt-get mise à jour # apt-get installation nginx-plus # apt-get installation nginx-plus-module-njs

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

Rechargez ensuite la configuration NGINX Plus pour charger les modules JavaScript NGINX :

# nginx -t && nginx -s recharger

Les utilisateurs de NGINX Open Source peuvent obtenir NGINX JavaScript à partir de notre référentiel de code open source .

Le code JavaScript n'est pas inclus directement dans la configuration NGINX Plus. Au lieu de cela, il est lu avec la directive js_import . Dans cet exemple, le code JavaScript pour une fonction « sans serveur » simple est lu 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.

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é :

Fonctionnalités supplémentaires

NGINX Plus R10 introduit un certain nombre d'améliorations supplémentaires pour vous aider à fournir des applications sans faille, notamment :

• L'équilibrage de charge TCP/UDP, implémenté dans le module Stream , présente désormais une plus grande parité de fonctionnalités avec l'équilibrage de charge HTTP. Les nouveaux modules pris en charge incluent Split Clients pour les tests A/B, GeoIP pour prendre des mesures en fonction de l'emplacement géographique des clients et Geo pour définir des variables en fonction de l'adresse IP. Plus d'informations sont disponibles via des variables NGINX supplémentaires et vous pouvez prendre des décisions de routage en utilisant une variable comme paramètre de la directive proxy_pass .
• Un problème courant pour les applications à fort trafic est l'épuisement des ports éphémères , où de nouvelles connexions aux serveurs en amont ne peuvent pas être créées car le système d'exploitation n'a plus de numéros de ports disponibles. Pour surmonter ce problème, 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 « 4-tuple » standard (adresse IP source, adresse IP de destination, port source, port de destination) soit unique. Il est disponible sur les systèmes avec le noyau Linux version 4.2 et ultérieure, et glibc 2.22 et 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 back-end et aux microservices afin que toutes les parties du système puissent enregistrer 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 peuvent être utilisées pour basculer la mise en mémoire tampon des requêtes.
• La nouvelle directive http2_body_preread_size permet aux clients HTTP/2 de commencer à envoyer le corps de la requête immédiatement. La directive contrôle la taille de la mémoire tampon utilisée avant que NGINX Plus ne commence à lire le corps de la demande du client.

Le package NGINX Plus Extras est obsolète

Comme nous l'avons annoncé lors de la sortie de NGINX Plus R9, R10 est la dernière version qui inclura le package NGINX Plus Extras.

Nous vous recommandons fortement de modifier dès maintenant vos procédures d'installation et de configuration pour utiliser le package nginx-plus et charger dynamiquement les modules du package nginx-plus-extras que vous utilisez réellement. À partir de NGINX Plus R11, ce sera le seul moyen possible d'utiliser des modules qui ne sont pas intégrés au package nginx-plus .

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

1. Supprimez le package nginx-plus-extras et installez nginx-plus et les modules dynamiques que vous souhaitez utiliser. Pour les systèmes basés sur Debian, l’ensemble de commandes approprié est :

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

2. Dans le contexte principal (de niveau supérieur) de /etc/nginx/nginx.conf , ajoutez une directive load_module pour chaque module chargé dynamiquement :

3. Vérifiez la validité syntaxique de la nouvelle configuration et rechargez-la :

   # nginx -t && nginx -s recharger

Mettre à niveau ou essayer NGINX Plus

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer la mise à niveau vers la version 10 dès que possible. Vous bénéficierez d'un certain nombre de correctifs et d'améliorations, et cela nous aidera à 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 .

NOTE : NGINX Plus R10 est la dernière version qui inclura le package nginx-plus-extras . Voir Le package NGINX Plus Extras est obsolète ci-dessus.

Si vous n'avez pas essayé NGINX Plus , nous vous encourageons à l'essayer pour l'accélération Web, l'équilibrage de charge et la distribution d'applications, 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 gratuitement dès aujourd’hui avec une évaluation de 30 jours et voir par vous-même comment NGINX Plus peut vous aider à fournir et à faire évoluer vos applications.

Plus d'informations sur NGINX Plus R10

Pour plus de détails sur les nouvelles fonctionnalités clés de NGINX Plus R10, consultez ces ressources associées :

• Authentification des clients API avec JWT et NGINX Plus
• NGINX Plus R10 exploite la puissance d'IBM
• Authentification des utilisateurs sur des applications existantes avec OpenID Connect et NGINX Plus
• Utilisation du module JavaScript NGINX pour effectuer la transition progressive des clients vers un nouveau serveur
• Transparence IP et retour direct du serveur avec NGINX et NGINX Plus comme proxy transparent
• Quoi de neuf dans NGINX Plus R10 ? (webinaire à la demande)

[NGINX ModSecurity WAF est officiellement en fin de commercialisation depuis le 1er avril 2022 et passe en fin de vie à compter du 31 mars 2024 . Pour plus de détails, voir F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life sur notre blog.]