Annonce de NGINX Plus R22

Liam CrillyDirecteur senior de la gestion des produits

Nous avons le plaisir d’annoncer que NGINX Plus Release 22 (R22) est désormais disponible. Basé sur NGINX Open Source, NGINX Plus est la seule solution logicielle tout-en-un faisant office de répartiteur de charge, de cache de contenu, de serveur web et de passerelle API. Cette version met principalement l’accent sur la surveillance et l’authentification, afin d’améliorer la granularité et la résilience de vos applications à grande échelle.

Les nouvelles fonctionnalités de NGINX Plus R22 incluent :

• Améliorations apportées à l’authentification par certificat client – La vérification via le protocole OCSP (Online Certificate Status Protocol) ajoute une couche de sécurité permettant de détecter les certificats révoqués lors de l’utilisation du protocole TLS mutuel.
• Prise en charge d’OpenID Connect pour plusieurs fournisseurs d’identité – Dans NGINX Plus R15, nous avons introduit l’intégration d’OpenID Connect (OIDC) afin de permettre à nos clients d’ajouter l’authentification unique (SSO) à leurs applications. Avec NGINX Plus R22, vous pouvez facilement intégrer plusieurs fournisseurs d’identité (IdP) OIDC.
• Davantage de métriques sur le tableau de bord de surveillance de l’activité en temps réel – Le tableau de bord affiche désormais des métriques sur l’activité OIDC ainsi que des graphiques historiques sur la limitation des requêtes et des connexions.
• Améliorations du module JavaScript NGINX – Le module JavaScript NGINX (njs) a été mis à jour vers la version 0.4.1, avec plusieurs corrections de bogues et de nouvelles fonctionnalités, telles que l’importation de modules JavaScript et l’accès aux objets d’en-tête bruts.

Modifications importantes du comportement

• Les anciens systèmes d’exploitation ne sont plus pris en charge –
  • Alpine Linux 3.8 n’est plus pris en charge
  • Comme annoncé pour NGINX Plus R21<.htmla>, NGINX Plus n’est plus disponible sur les plateformes 32 bits (architecture i386)

Nouvelles fonctionnalités en détail

Validation OCSP des certificats clients

NGINX Plus prend en charge le TLS mutuel, qui utilise des certificats clients à la fois pour vérifier l’identité du client qui se connecte et pour établir une connexion chiffrée. Le TLS mutuel offre un niveau élevé de garantie quant à l’identité du client, mais la gestion des certificats révoqués peut représenter une charge administrative. Le protocole de vérification en ligne de l’état des certificats (OCSP) résout ce problème en vérifiant l’état des certificats clients lorsqu’ils sont présentés.

Vous pouvez configurer NGINX Plus afin qu’il utilise le protocole OCSP pour vérifier la validité des certificats clients X.509, conformément à la RFC 6960.

Pour activer la validation OCSP des certificats clients SSL, ajoutez la nouvelle directive « ssl_ocsp » avec la directive « ssl_verify_client », qui active la vérification des certificats.

Chargement de l’exemple de code…

NGINX Plus envoie la requête OCSP à l’URI OCSP intégrée au certificat client, sauf si vous définissez une autre URI à l’aide de la directive ssl_ocsp_responder.

Pour mettre en cache les réponses OCSP dans une zone mémoire unique partagée par tous les processus de travail, incluez la directive ssl_ocsp_cache afin de définir le nom et la taille de la zone. Les réponses sont mises en cache pendant 1 heure, sauf si la valeur nextUpdate de la réponse OCSP indique une durée différente.

Le résultat de la validation du certificat client est disponible dans la variable « $ssl_client_verify », y compris le motif de l’échec OCSP.

La négociation TLS échoue si le certificat client n’est pas approuvé ou si la réponse OCSP n’est pas valide. Le code d’état 495 (SSL Certificate Error) est renvoyé et une entrée est créée dans le journal des erreurs avec le niveau de gravité error :

YYYY/MM/DD hh:mm:ss [error] 31222#0: *5 certificate status "revoked" in the OCSP response while requesting certificate status, responder: 127.0.0.1

Améliorations d’OpenID Connect

Notre implémentation de référence d’OpenID Connect pour NGINX Plus étend l’authentification unique aux applications nouvelles et existantes afin de réduire la complexité et les coûts. L’implémentation de référence combine des fonctionnalités de NGINX Plus et le module JavaScript de NGINX (njs) pour effectuer un échange de code avec le point de terminaison d’autorisation et recevoir un jeton d’identité du fournisseur d’identité. Les jetons d’identité sont mis en cache dans le magasin clé-valeur de NGINX Plus, tandis qu’un jeton de session opaque est envoyé au client. Les clients s’authentifient ensuite en présentant un jeton de session valide, que NGINX Plus utilise pour vérifier le jeton d’identité avant d’autoriser l’accès aux applications backend.

Cette version apporte de nombreuses améliorations à l’implémentation de référence OIDC, ainsi que deux changements majeurs :

1. La configuration prend désormais en charge plusieurs fournisseurs d’identité (IdP) en transmettant les variables d’entrée appropriées des requêtes entrantes à plusieurs blocs map. Cette flexibilité supplémentaire réduit la nécessité de modifier le code de l’implémentation de référence d’OIDC.
2. Le code JavaScript est désormais implémenté sous forme de module afin de pouvoir coexister avec d’autres solutions njs sur le même hôte, sans qu’il soit nécessaire de gérer l’ensemble du code njs dans un seul fichier.

Voici un exemple de configuration :

Chargement de l’exemple de code…

Chaque bloc map accepte plusieurs valeurs, ce qui permet de prendre en charge plusieurs fournisseurs d’identité (IdP) et paramètres d’authentification (secret client, fichier de clé JWK, points de terminaison d’autorisation). Ici, nous utilisons la variable $host comme paramètre d’entrée, mais vous pouvez spécifier n’importe quelle variable dérivée de l’en-tête de la requête.

L’API NGINX Plus assure désormais le suivi de l’activité liée aux connexions OpenID Connect afin de faciliter la surveillance et le dépannage. Consultez le dépôt GitHub pour en savoir plus sur l’implémentation de référence d’OpenID Connect.

Graphiques du tableau de bord en temps réel pour la limitation du débit et des connexions

Les attaques DDoS et les attaques par force brute visant à deviner les mots de passe constituent deux menaces critiques pour vos applications. Vous pouvez en atténuer les effets grâce à la limitation du débit, qui permet à NGINX Plus de limiter le nombre de requêtes que chaque client peut effectuer au cours d’une période donnée.

NGINX Plus R20 a ajouté la surveillance en temps réel de la fréquence des requêtes et de la limitation des connexions à l’API NGINX Plus (aux points de terminaison /api/version/http/limit_reqs et /api/version/http/limit_conns). Ces informations apparaissent désormais dans le tableau de bord de surveillance de l’activité en direct de NGINX Plus, avec les nombres cumulés sous forme de tableau et les nombres horodatés sous forme de graphique :

• Les métriques de limitation du débit des requêtes apparaissent dans le tableau « Limit Req » de l’onglet « HTTP Zones »
• Les métriques de limitation des connexions apparaissent dans le tableau Limit Conn de l’onglet Zones TCP/UDP tab

Le tableau comporte une ligne pour chaque zone définie par une directive limit_req_zone ou limit_conn_zone. Pour afficher le graphique, cliquez sur l’icône de graphique située à l’extrémité gauche de la ligne.

Le graphique agrandi est mis à jour en continu et affiche les valeurs de chaque intervalle de temps sous la forme d’un graphique en aires empilées. Vous pouvez personnaliser les informations affichées comme suit :

• Choisissez la plage de temps à afficher : 1 minute, 5 minutes ou 15 minutes
• Survolez le graphique pour afficher les valeurs exactes à un instant donné
• Survolez un type de statistique dans la zone de légende pour mettre en évidence cette statistique dans le graphique
• Cliquez sur un type de statistique dans la zone de légende pour afficher ou masquer cette statistique
• Faites glisser le graphique vers la gauche ou la droite pour consulter les données historiques

Avec l’intervalle d’actualisation du tableau de bord par défaut de 1 seconde, chaque graphique conserve environ 30 minutes de données historiques. Augmenter l’intervalle d’actualisation du tableau de bord (c’est-à-dire réduire la fréquence d’actualisation) permet de disposer de davantage de données historiques. Notez que les graphiques du tableau de bord ne sont pas persistants : les données historiques sont perdues lorsque vous quittez ou rechargez l’onglet.

Améliorations apportées au module JavaScript NGINX

Le module JavaScript NGINX étend les fonctionnalités de NGINX Plus afin de prendre en charge un large éventail de cas d’utilisation, notamment pour contrôler plus finement le trafic, mutualiser les fonctions JavaScript entre les applications et se protéger contre les menaces de sécurité. Le module JavaScript NGINX a été mis à jour vers la version 0.4.1 et inclut les fonctionnalités suivantes :

• La nouvelle directive « js_import » permet d’importer plusieurs fichiers de modules qui implémentent des gestionnaires d’emplacement et de variables
• Prise en charge améliorée des en-têtes, notamment avec de nouveaux objets d’en-têtes bruts
• Vous pouvez utiliser les fichiers de définition TypeScript dans votre code njs
• Prise en charge de la conversion de valeurs externes en objets JavaScript natifs

Le code et la configuration ci-dessous illustrent comment le nouvel objet « r.rawHeadersIn » peut être utilisé pour consigner l’ensemble exact des en-têtes envoyés par le client chaque fois qu’une erreur se produit. [Note de la rédaction – Il ne s’agit là que de l’un des nombreux cas d’utilisation du module JavaScript NGINX. Pour obtenir la liste complète, consultez Cas d’utilisation du module JavaScript NGINX.]

Chargement de l’exemple de code…

Chargement de l’exemple de code…

Voici un exemple d’entrée de journal pour une réponse « 404 » :

$ curl http://localhost/bogus
$ tail --lines=1 /var/log/nginx/access_json.log
{"response":{"timestamp":"YYYY-MM-DDThh:mm:ss+TZ_offset","status":404},"request":{"client":"127.0.0.1","uri":"/bogus","headers":[["Host","localhost:80"],["User-Agent","curl/7.64.1"],["Accept","*/*"]]}}

Délai en cas d’échec de l’authentification

Pour atténuer les attaques temporelles telles que les attaques par force brute sur les mots de passe et le bourrage d’identifiants, vous pouvez configurer NGINX Plus pour qu’il retarde sa réponse en cas d’échec de l’authentification. La nouvelle directive auth_delay définit ce délai, qui peut être appliqué aux requêtes d’authentification traitées par les modules Auth Basic, Auth JWT et Auth Request.

Mettez à niveau ou essayez NGINX Plus

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à NGINX Plus R22 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 découvrir, 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. Découvrez par vous-même comment NGINX Plus peut vous aider à déployer vos applications et à les faire évoluer.

À propos de l’auteur

Liam CrillyDirecteur senior de la gestion des produits

Autres articles de Liam Crilly