Annonce de NGINX Plus R22

Nous sommes heureux d'annoncer que NGINX Plus Release 22 (R22) est désormais disponible. Basé sur NGINX Open Source, NGINX Plus est le seul équilibreur de charge logiciel tout-en-un, cache de contenu, serveur Web et passerelle API. L’objectif principal de cette version est la surveillance et l’authentification, pour une granularité et une résilience améliorées de vos applications à grande échelle.

Les nouvelles fonctionnalités de NGINX Plus R22 incluent :

• Améliorations apportées à l’authentification du certificat client : la vérification du protocole OCSP (Online Certificate Status Protocol) ajoute une couche de sécurité pour vérifier les certificats révoqués avec TLS mutuel.
• Prise en charge d'OpenID Connect pour plusieurs IdP – Dans NGINX Plus R15 , nous avons introduit l'intégration d'OpenID Connect (OIDC) pour permettre à nos clients d'ajouter l'authentification unique (SSO) à leurs applications. Avec NGINX Plus R22 , vous pouvez facilement intégrer plusieurs fournisseurs d'identité OIDC (IdP).
• Plus de mesures sur le tableau de bord de surveillance des activités en direct – Le tableau de bord affiche désormais des mesures sur l’activité OIDC et des graphiques historiques sur les limitations de demande et de connexion.
• Améliorations du module JavaScript NGINX – Le module JavaScript NGINX (njs) a été mis à jour pour0.4.1 , avec plusieurs corrections de bugs et de nouvelles fonctionnalités telles que l'importation de modules JavaScript et l'accès aux objets d'en-tête bruts .

Changements importants dans le 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 protocole TLS mutuel, qui utilise des certificats clients à la fois pour vérifier l'identité du client connecté et pour établir une connexion cryptée. Le protocole TLS mutuel offre un niveau élevé d’assurance sur l’identité du client, mais la gestion des certificats révoqués peut constituer une charge administrative. Le protocole OCSP (Online Certificate Status Protocol ) résout ce problème en vérifiant le statut des certificats clients au fur et à mesure qu'ils sont présentés.

Vous pouvez configurer NGINX Plus pour utiliser OCSP afin de vérifier la validité des certificats clients X.509, comme défini par RFC 6960 .

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

NGINX Plus envoie la requête OCSP à l'URI OCSP intégré dans le certificat client, sauf si vous définissez un URI différent avec la directive ssl_ocsp_responder .

Pour mettre en cache les réponses OCSP dans une seule zone de mémoire partagée par tous les processus de travail, incluez la directive ssl_ocsp_cache pour 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 dans la réponse OCSP spécifie une valeur différente.

Le résultat de la validation du certificat client est disponible dans la variable $ssl_client_verify , y compris la raison 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. Statut code 495 (SSL Certificat Erreur) est renvoyé et une entrée est créée dans le journal des erreurs à l' erreur niveau de gravité :

AAAA / MM / JJ hh : mm : ss [erreur] 31222#0 : *5 état du certificat « révoqué » dans la réponse OCSP lors de la demande de statut du certificat, répondeur : 127.0.0.1

Améliorations d'OpenID Connect

Notre implémentation de référence OpenID Connect pour NGINX Plus étend SSO aux applications nouvelles et existantes afin de minimiser la complexité et les coûts. L'implémentation de référence utilise une combinaison de fonctionnalités NGINX Plus et du module JavaScript NGINX (njs) pour effectuer un échange de code avec le point de terminaison d'autorisation et recevoir un jeton d'identification de l'IdP. Les jetons d’ID eux-mêmes sont mis en cache dans le magasin de clés-valeurs NGINX Plus et 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'identification avant d'accéder aux applications back-end.

Cette version apporte de nombreuses améliorations à l'implémentation de référence OIDC et deux changements importants :

1. La configuration prend désormais en charge plusieurs IdP en transmettant les variables d'entrée appropriées des requêtes entrantes dans plusieurs blocs de carte . Cette flexibilité supplémentaire réduit la nécessité de modifier le code d’implémentation de référence OIDC.
2. Le code JavaScript est désormais implémenté sous forme de module afin qu’il puisse coexister avec d’autres solutions njs sur le même hôte sans avoir besoin de gérer tout le code njs dans un seul fichier.

Voici un exemple de configuration :

Chaque bloc de carte autorise plusieurs valeurs afin que plusieurs IdP et paramètres d'authentification (secret client, fichier de clé JWK, points de terminaison d'autorisation) puissent être pris en charge. 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 suit désormais l'activité liée aux connexions OpenID Connect, pour faciliter la surveillance et le dépannage. Consultez le référentiel GitHub pour plus d’informations sur l’implémentation de référence d’OpenID Connect.

Tableaux de bord en temps réel pour la limitation du débit et de la connexion

Les attaques DDoS et les attaques par force brute de devinette de mot de passe sont deux menaces critiques pour vos applications. Vous pouvez atténuer leurs effets en limitant le débit, c'est-à-dire en laissant NGINX Plus limiter le nombre de requêtes que chaque client peut effectuer sur une certaine période.

NGINX Plus R20 a ajouté une surveillance en temps réel du taux de requête et de la limitation de connexion à l' API NGINX Plus (aux points de terminaison /api/ version /http/limit_reqs et /api/ version /http/limit_conns ). Les informations apparaissent désormais sur le tableau de bord de surveillance des activités en direct de NGINX Plus, avec des comptages cumulés sous forme de tableau et des comptages horodatés sous forme de graphique :

• Les mesures de limitation du taux de requêtes apparaissent dans le tableau Limite requise de l'onglet Zones HTTP
• Les mesures de limitation de connexion apparaissent dans le tableau Limit Conn de l'onglet Zones TCP/UDP

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

Le graphique développé est mis à jour en continu et affiche les valeurs pour chaque intervalle de temps sous forme de graphique à aires empilées. Vous pouvez personnaliser les informations affichées des manières suivantes :

• Choisissez la plage horaire à afficher : 1 minute, 5 minutes ou 15 minutes
• Passez la souris sur le graphique pour afficher les décomptes précis pour un point temporel
• Passez la souris sur 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 basculer entre l'affichage et le non-affichage
• Faites glisser le graphique vers la gauche et la droite pour afficher les données historiques

À l’intervalle de mise à jour du tableau de bord par défaut de 1 seconde, chaque graphique stocke environ 30 minutes de données historiques. L'augmentation de l'intervalle de mise à jour du tableau de bord (mise à jour moins fréquente) augmente la quantité de données historiques disponibles. Notez que les graphiques du tableau de bord ne sont pas persistants et que les données historiques sont perdues lorsque vous quittez l'onglet ou le rechargez.

Améliorations apportées au module JavaScript NGINX

Le module JavaScript NGINX étend les fonctionnalités de NGINX Plus pour permettre un large éventail de cas d'utilisation, notamment un contrôle plus précis du trafic, la consolidation des fonctions JavaScript dans les applications et la défense contre les menaces de sécurité. Le module JavaScript NGINX a été mis à jour pour0.4.1 et comprend ces fonctionnalités :

• La nouvelle directive js_import pour importer plusieurs fichiers de module qui implémentent des gestionnaires d'emplacement et de variables
• Prise en charge améliorée des en-têtes, y compris de nouveaux objets d'en-tête bruts
• Vous pouvez utiliser des 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 suivants illustrent comment le nouvel objet r.rawHeadersIn peut être utilisé pour enregistrer l'ensemble exact des en-têtes envoyés par le client chaque fois qu'une erreur est rencontrée. [ Éditeur – Ce n'est qu'un des nombreux cas d'utilisation du module JavaScript NGINX. Pour une liste complète, voir Cas d'utilisation du module JavaScript NGINX . ]

Voici un exemple d'entrée de journal pour un404 réponse:

$ curl http://localhost/bogus $ tail --lines=1 /var/log/nginx/access_json.log {"réponse":{"horodatage": " AAAA - MM - JJ J hh : mm : ss + TZ_offset ","état":404},"request":{"client": "127.0.0.1", "uri": "/bogus", "headers":[["Hôte", "localhost:80"],["Agent utilisateur", "curl/7.64.1"],["Accepter", "*/*"]]}}

Retard en cas d'échec d'authentification

Pour atténuer les attaques temporelles telles que les attaques par force brute sur les mots de passe et le bourrage d’informations d’identification, vous pouvez configurer NGINX Plus pour retarder sa réponse lorsque l’authentification échoue. La nouvelle directive auth_delay spécifie le délai, qui peut être appliqué aux demandes d'authentification traitées par les modules Auth Basic , Auth JWT et Auth Request .

Mettre à niveau ou essayer NGINX Plus

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer une mise à niveau vers NGINX Plus R22 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 . Découvrez par vous-même comment NGINX Plus peut vous aider à fournir et à faire évoluer vos applications.