NGINXaaS for Azure permet aux entreprises de fournir en toute sécurité des applications hautes performances dans le cloud. Basé sur NGINX Plus, ce service entièrement géré est disponible pour tous depuis janvier 2023. Depuis son lancement et à l’avenir, nous continuerons d’améliorer NGINXaaS for Azure en ajoutant de nouvelles fonctionnalités.
Dans cet article de blog, nous présentons certaines des dernières fonctionnalités en matière de performances et de sécurité qui vous permettent de profiter davantage des avantages de NGINX Plus sans avoir à déployer, maintenir et mettre à jour vos propres instances NGINX Plus. Pour obtenir des informations générales sur NGINXaaS for Azure et l’ensemble de ses fonctionnalités, consultez l’article « Simplifiez et accélérez les migrations vers le cloud avec F5 NGINXaaS for Azure ».
Figure 1 : Présentation de NGINXaaS for Azure
Sécurisation du trafic en amont avec mTLS
Si les proxys inverses nécessitent SSL/TLS pour chiffrer le trafic côté client sur l’Internet public, le protocole TLS mutuel (mTLS) devient indispensable pour authentifier les communications et garantir leur confidentialité côté serveur. Avec l’adoption du modèle « Zero Trust », il est également nécessaire de vérifier que le trafic vers les serveurs en amont n’a pas été altéré ou intercepté.
Figure 2 : mTLS avec NGINXaaS
NGINXaaS for Azure prend désormais en charge les directives NGINX permettant de sécuriser le trafic en amont à l’aide de certificats SSL/TLS. Grâce à ces directives, vous pouvez non seulement maintenir le chiffrement du trafic en amont via mTLS, mais aussi vérifier que les serveurs en amont présentent un certificat valide émis par une autorité de certification de confiance.
Rotation des certificats
Un élément clé (sans mauvais jeu de mots) de l’utilisation de certificats TLS avec NGINXaaS for Azure consiste à gérer ces certificats de manière sécurisée à l’aide d’Azure Key Vault (AKV). AKV protège les éléments cryptographiques sensibles et permet à NGINXaaS for Azure d’utiliser ces certificats tout en empêchant la divulgation accidentelle ou intentionnelle des clés via le portail Azure.
Figure 3 : Rotation des certificats avec Azure Key Vault
NGINXaaS for Azure peut désormais renouveler automatiquement les certificats dans vos déploiements NGINX dès qu’ils sont mis à jour dans AKV. Les nouvelles versions des certificats sont déployées dans un délai de quatre heures.
Proxy HTTP/2 (et options de protocole supplémentaires)
Fermez les yeux et replongez-vous en 1997. Nous chantions « Tubthumping » avec Chumbawamba, vêtus de nos jeans JNCO (ou de nos Modrobes, pour nos amis canadiens), tandis que HTTP/1.1 voyait le jour. À l’époque, la plupart des utilisateurs accédaient à Internet au moyen d’un modem bas débit, les pages web ne comportaient que quelques dizaines d’éléments et, en matière d’expérience utilisateur, la bande passante était une préoccupation bien plus importante que la latence.
Vingt-cinq ans plus tard, une part importante des applications web utilise encore HTTP/1.1 pour diffuser du contenu. Cela peut poser problème. Bien que HTTP/1.1 fonctionne toujours, il ne permet de transmettre qu’une seule ressource à la fois par connexion. Or, les applications web modernes peuvent effectuer des centaines de requêtes pour mettre à jour une interface utilisateur.
Bien que la plupart des utilisateurs disposent d’une bande passante nettement plus importante, la vitesse de transmission des données (limitée par la vitesse fondamentale de la lumière) n’a pas progressé aussi rapidement. Par conséquent, la latence cumulée de toutes ces requêtes peut avoir un impact significatif sur les performances perçues de votre application. Les navigateurs modernes ouvrent plusieurs connexions TCP vers le même serveur, mais les requêtes sur chacune de ces connexions sont toujours traitées de manière séquentielle, ce qui signifie qu’une ressource lente peut retarder toutes celles qui la suivent.
Observez la page d’accueil de F5 lorsqu’elle est chargée uniquement via HTTP/1.1 :
Figure 4 : F5.com consulté via HTTP/1.1
Vous voyez toutes ces barres grises ? C’est un temps précieux que le navigateur perd à attendre l’établissement de la session, à rester bloqué par une seule ressource lente ou à attendre qu’une nouvelle connexion TCP soit disponible.
Activons HTTP/2 et réessayons :
Figure 5 : La même requête, mais avec HTTP/2
C’est beaucoup mieux. Quelques ressources restent lentes, mais elles ne bloquent pas les autres requêtes, et le temps d’attente dû aux délais de mise en file d’attente est considérablement réduit. HTTP/2 conserve la même sémantique que celle de HTTP/1.1, bien connue des navigateurs web et des serveurs, tout en ajoutant de nouvelles fonctionnalités permettant de remédier à certaines causes de mauvaises performances perçues des applications (par exemple, la hiérarchisation des requêtes, la compression des en-têtes et le multiplexage des requêtes).
Compte tenu d’une différence aussi nette, NGINXaaS for Azure permet désormais de traiter les requêtes des clients via HTTP/2. Les connexions côté client sont davantage susceptibles d’être affectées par des temps d’aller-retour plus longs. Vous pouvez donc acheminer ce trafic en profitant de la réduction de latence offerte par HTTP/2, sans modifier vos serveurs en amont.
Contrairement à ce que certains acteurs du secteur des applications web pourraient vouloir croire, nous reconnaissons qu’il existe d’autres options de protocole que HTTP. C’est pourquoi le module gRPC de NGINX est désormais également disponible dans NGINXaaS for Azure. Il fournit plusieurs directives de configuration pour gérer le trafic gRPC, notamment l’interception des erreurs, la manipulation des en-têtes, et bien plus encore.
Pour le trafic autre que HTTP/gRPC, le module stream est désormais disponible dans NGINXaaS for Azure. Ce module prend en charge la mise en proxy et l’équilibrage de charge du trafic TCP et UDP.
Prise en charge de l’équilibrage de charge des couches 4 et 7
NGINXaaS for Azure peut désormais faire office d’équilibreur de charge cloud natif à la fois pour les protocoles TCP/UDP de couche 4 et HTTP/HTTP de couche 7. Pourquoi est-ce important ? Au lieu de déployer deux services ou équilibreurs de charge différents, NGINXaaS for Azure vous permet de déployer un seul équilibreur de charge et de le configurer pour qu’il fonctionne simultanément sur les deux couches, simplifiant ainsi votre architecture cloud et réduisant vos coûts.
Vous pouvez en savoir plus sur la configuration ici.
Capacité supérieure (jusqu’à 160 NCU)
NGINXaaS for Azure est un service basé sur la consommation, mesuré à l’heure et facturé mensuellement en unités de capacité NGINX (NCU). Nous avons récemment doublé cette capacité de déploiement, qui est passée de 80 à 160 NCU. Les clients peuvent déployer un système plus petit de 20 NCU et, si la charge de travail augmente, le faire évoluer jusqu’à 160 NCU. Ils peuvent également choisir de déployer jusqu’à 160 NCU dès le départ.
Ajout de directives NGINX Plus
Afin de faciliter la migration de votre configuration d’un environnement sur site vers une offre cloud entièrement gérée, nous avons ajouté de nombreuses directives NGINX Plus. Consultez toutes les directives NGINX Plus que nous prenons en charge dans NGINXaaS for Azure ici.
Commencez dès aujourd’hui
Nous améliorons et élargissons constamment les possibilités d’utilisation des technologies NGINX et F5 pour sécuriser, diffuser et optimiser chaque application et API, partout. Grâce aux fonctionnalités mentionnées ci-dessus et aux autres nouveautés ajoutées à NGINXaaS for Azure, davantage d’utilisateurs Azure peuvent résoudre de nombreux problèmes liés aux applications et aux API en tirant parti de la puissance de NGINX Plus, sans avoir à gérer une infrastructure supplémentaire de machines virtuelles ou de conteneurs.
Si vous souhaitez en savoir plus sur NGINXaaS for Azure, nous vous invitons à consulter la documentation du produit. Si vous êtes prêt à essayer NGINXaaS for Azure, rendez-vous sur Azure Marketplace ou contactez-nous pour discuter de vos cas d’usage.
À propos de l’auteur
Articles de blog associés
Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.
Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.