Vous serez peut-être surpris d’apprendre que les sommes consacrées à l’amélioration de votre posture de sécurité grâce à l’automatisation et à l’intelligence artificielle (IA) vous permettent au final de réaliser des économies bien plus importantes. Dans son rapport 2021 sur le coût d’une violation de données, l’équipe IBM Security révèle qu’une violation de sécurité coûte en moyenne 80 % de plus aux organisations qui ne disposent ni de l’automatisation de la sécurité ni de l’IA qu’à celles qui les ont entièrement déployées : 6,71 millions de dollars contre 2,90 millions, soit une différence de 3,81 millions de dollars. En donnant la priorité à l’automatisation de la sécurité et à l’IA, les organisations peuvent détecter et contenir plus rapidement une violation, économisant ainsi du temps et de l’argent.
(Source : Rapport 2021 sur le coût d’une violation de données)
Cependant, lorsque vous intégrez la sécurité à votre pipeline CI/CD, il est important de ne pas surcharger vos outils. Moins vous inspectez le trafic, moins vous introduisez de latence. Il en découle, sur le plan commercial, que la complexité technique est l’ennemie de l’agilité.
Chez F5 NGINX, nous proposons une plateforme de sécurité unique par son intégration transparente et sa capacité à aider les équipes à « déplacer la sécurité vers l’amont » au cours du cycle de développement logiciel. Lorsque les entreprises intègrent la « sécurité en tant que code » à leur pipeline CI/CD, elles peuvent automatiser la sécurité et tirer parti de l’IA, ce qui leur permet de réaliser les économies considérables décrites par IBM. La sécurité étant intégrée à chaque étape du développement des applications et des API, les fichiers de configuration et de politique de sécurité sont traités comme du code, et votre équipe SecOps peut créer et gérer une politique de sécurité déclarative que l’équipe DevOps utilisera lors du développement des applications. Ces mêmes politiques peuvent être appliquées de manière répétée aux nouvelles applications, automatisant ainsi la sécurité au sein de votre pipeline CI/CD.
Examinons les choses de plus près et intéressons-nous aux trois phases du traitement du trafic au cours desquelles F5 NGINX App Protect et F5 NGINX Plus vous aident à automatiser les mesures de sécurité :
- Phase 1 – F5 NGINX App Protect DoS détecte les attaques par déni de service (DoS) et protège contre celles-ci
- Phase 2 – F5 NGINX App Protect WAF protège contre les attaques du Top 10 de l’OWASP et les bots malveillants
- Phase 3 – F5 NGINX Plus authentifie les clients des applications et des API et applique les exigences d’autorisation à l’aide de fonctionnalités natives et d’intégrations avec des solutions tierces d’authentification unique (SSO)
Cette solution de sécurité en trois volets vous permet de réaliser des économies de deux manières, en particulier dans un environnement de cloud public :
- Seul le trafic légitime atteint vos applications, car NGINX App Protect DoS filtre le trafic provenant des attaques par déni de service, puis NGINX App Protect WAF élimine plusieurs vecteurs d’attaque, tels que ceux du Top 10 de l’OWASP.
- Grâce à sa conception événementielle hautement efficace, NGINX Plus peut traiter un très grand nombre de requêtes par seconde tout en consommant peu de ressources processeur. Le traitement du seul trafic applicatif légitime sur une plateforme hautement efficace nécessite nettement moins de ressources de calcul, ce qui vous permet d’économiser du temps et de l’argent, tout en assurant une protection contre de multiples vecteurs d’attaque sans surcharger vos outils.
Si vous utilisez actuellement F5 BIG-IP Advanced WAF pour sécuriser les applications exécutées dans votre centre de données, vous pouvez facilement ajouter NGINX Plus en tant que contrôleur Ingress pour Kubernetes, avec NGINX App Protect DoS et WAF, afin de disposer d’une solution complète permettant de faire évoluer et de sécuriser vos applications modernes, ainsi que d’orchestrer les applications Kubernetes dans le cloud. Grâce à l’approche de F5 fondée sur la sécurité en tant que code, vous pouvez définir sous forme de code les contrôles des politiques d’infrastructure et de sécurité, au moyen d’une API déclarative ou de définitions déclaratives au format JSON dans un fichier. Vous pouvez également convertir des fichiers XML BIG-IP en fichiers JSON. Vos politiques – les contrôles de sécurité standard de l’entreprise détenus et gérés par les équipes SecOps – peuvent être stockées dans un référentiel de code, depuis lequel elles sont récupérées et intégrées à votre pipeline de développement comme n’importe quel autre élément de code. Cette approche aide les équipes DevOps et SecOps à combler les écarts opérationnels et à commercialiser plus rapidement les applications, à moindre coût et avec une sécurité renforcée.
F5 intègre la création et l’établissement d’une référence de base des politiques WAF au processus de développement, une étape essentielle pour « intégrer la sécurité en amont » dans le pipeline de développement des applications et automatiser leur déploiement.
Les outils de visibilité de BIG‑IP et de NGINX se complètent et permettent aux équipes SecOps d’intégrer des processus d’automatisation dès le début de votre cycle de vie DevOps. BIG‑IP permet aux équipes de convertir des fichiers XML en fichiers JSON utilisés par NGINX afin de garantir la cohérence de vos politiques de sécurité. NGINX permet aux équipes d’affiner les applications déjà en place, tout en apportant une automatisation moderne de la sécurité des applications afin de limiter les risques de futures violations et le coût de ces attaques potentielles.
Phase 1 : NGINX App Protect DoS protège contre les attaques DoS
La première étape de notre parcours vers une gestion sécurisée du trafic consiste à éliminer les attaques par déni de service (DoS). Mettre fin à ces abus dès le départ constitue une première ligne de défense indispensable.
Nous avons déjà constaté que les attaquants délaissent de plus en plus les attaques volumétriques traditionnelles au profit de requêtes HTTP et HTTPS ou d’appels d’API pour mener des attaques au niveau de la couche 7. Pourquoi ? Parce qu’ils choisissent la voie de la moindre résistance. Les ingénieurs en infrastructure ont consacré des années à mettre en place des défenses efficaces contre les attaques visant les couches 3 et 4, qui sont donc plus faciles à bloquer et ont moins de chances d’aboutir. Les attaques visant la couche 7 peuvent contourner ces défenses traditionnelles.
Toutes les attaques DoS ne sont pas volumétriques. Les attaques conçues pour accaparer les ressources des serveurs au moyen de méthodes lentes et à faible débit, telles que Slow POST ou Slowloris, peuvent facilement se dissimuler dans le trafic légitime. Et si les frameworks open source d’appel de procédure à distance sur HTTP/2 tels que gRPC offrent la rapidité et la flexibilité nécessaires aux applications modernes, leur nature intrinsèquement ouverte peut les rendre plus vulnérables aux attaques DoS que les protocoles propriétaires.
Contrairement aux protections traditionnelles contre les attaques DoS, NGINX App Protect DoS détecte les attaques actuelles en s’appuyant sur l’analyse automatisée du comportement des utilisateurs et du site, des contrôles d’intégrité proactifs et une configuration sans intervention. Il s’agit d’une solution à faible latence permettant de bloquer les attaques courantes telles que les attaques par saturation HTTP GET, les attaques par saturation HTTP POST, Slowloris, Slow read et Slow POST.
Pour lutter contre ces attaques, les équipes SecOps et DevOps doivent intégrer l’automatisation de la « sécurité en tant que code » à leur workflow CI/CD, dans le cadre d’une approche shift-left. NGINX App Protect DoS rend cela possible. Il sécurise les applications et API modernes et distribuées grâce à une protection avancée contre les menaces DoS, et contribue à concilier les priorités parfois contradictoires des équipes SecOps et DevOps en facilitant l’adoption de ce modèle au moyen d’un package logiciel léger, d’une boucle continue de rétroaction sur l’atténuation des menaces et d’une intégration aux outils DevOps habituels via des API RESTful.
NGINX App Protect DoS intègre la technologie d’apprentissage automatique (ML) que le rapport IBM Security considère comme essentielle pour réaliser d’importantes économies. Il analyse le comportement des clients et l’état de santé des applications afin de modéliser les schémas de trafic normaux, utilise des algorithmes uniques pour créer un modèle statistique dynamique offrant les protections les plus précises et déploie des signatures dynamiques pour atténuer automatiquement les attaques. Il mesure également en continu l’efficacité des mesures d’atténuation et s’adapte à l’évolution des comportements ou de l’état de santé. Ces fonctionnalités permettent à NGINX App Protect DoS de bloquer les attaques DoS dans lesquelles chaque requête malveillante semble parfaitement légitime, et où un seul attaquant peut même générer moins de trafic que l’utilisateur légitime moyen.
NGINX App Protect DoS and WAF
Phase 2 : NGINX App Protect WAF protège contre les dix principales menaces de l’OWASP
Si la protection contre les attaques par déni de service (DoS) empêche clairement le trafic malveillant de pénétrer dans votre infrastructure, certaines attaques peuvent néanmoins parvenir à la contourner. C’est pourquoi, pour la prochaine phase d’une défense efficace, vous avez besoin d’un pare-feu d’applications web (WAF), qui se concentre sur le trafic provenant d’acteurs malveillants se faisant passer pour du trafic légitime.
Léger et hautement performant, « NGINX App Protect WAF » offre une protection complète qui inspecte les réponses, veille au respect du protocole HTTP, détecte les techniques de contournement, masque les numéros de carte bancaire et autres informations personnelles sensibles grâce à Data Guard, et recherche les métacaractères et types de fichiers interdits, les données JSON et XML mal formées ainsi que les paramètres sensibles. Il protège également contre les menaces du classement OWASP Top 10 actualisé :
Contrôle d’accès défaillant
Défaillances cryptographiques
Injection
Conception non sécurisée
Mauvaise configuration de la sécurité
Composants vulnérables et obsolètes
Défaillances d’identification et d’authentification
Défaillances de l’intégrité des logiciels et des données
Défaillances de la journalisation et de la surveillance de la sécurité
Falsification de requête côté serveur
Il n’est pas surprenant que les cyberattaques exploitant des vulnérabilités du Top 10 de l’OWASP, telles que A03:2021 Injection restent courantes. En juillet 2021, le site d’e-commerce open source WooCommerce a annoncé que nombre de ses extensions étaient vulnérables aux injections SQL, et plusieurs attaques étaient alors en cours. Les entreprises et les clients opérant principalement en ligne, il est logique que les attaquants ciblent les applications web, qui sont souvent complexes, composées de microservices et réparties dans des environnements distribués où de nombreuses API communiquent entre elles, ce qui augmente le nombre de points de terminaison susceptibles d’être exploités.
Les attaques modernes évoluent et s’adaptent également rapidement. C’est là que l’IA entre en jeu, ce qui explique pourquoi IBM a souligné son importance. Comme dans NGINX App Protect DoS, le puissant système de ML de NGINX App Protect WAF permet aux équipes Platform Ops, DevOps et SecOps de partager facilement les tendances et les données relatives aux attaques. Une nouvelle fonctionnalité – l’évaluation adaptative des violations – exploitera davantage le ML en détectant les changements de comportement d’une application. Grâce à cette capacité de ML, NGINX App Protect WAF évalue en permanence le comportement prédictif de chaque application. Sur la base de cet apprentissage, il peut autoriser des requêtes clientes qui seraient autrement bloquées, réduisant ainsi le score d’évaluation des violations d’une application et diminuant considérablement les faux positifs, pour une meilleure expérience utilisateur et des coûts de gestion réduits.
NGINX App Protect WAF offre également une protection contre les bots. Aujourd’hui, près de 50 % du trafic Internet provient de botsEn éliminant en amont le trafic malveillant connu, NGINX App Protect WAF peut rapidement bloquer le trafic des bots grâce à sa base de données de signatures de bots.
L’intégration d’un WAF comme couche de sécurité dès les premières étapes de votre pipeline CI/CD contribue à réduire les risques de sécurité. NGINX App Protect WAF étant compatible avec les processus CI/CD, vous pouvez intégrer et automatiser la sécurité sous forme de code dès le début du processus de développement de vos applications. Une sensibilisation précoce à la sécurité et une collaboration adéquate entre les équipes permettent également d’éliminer les goulots d’étranglement, tels que les risques liés à la livraison. La protection multiniveau contre les attaques DoS et assurée par le WAF crée de nombreux points d’inspection, offrant aux équipes de sécurité une visibilité sur l’utilisation des applications et aux équipes applicatives une meilleure compréhension de leur maintenance.
Phase 3 : NGINX Plus authentifie et autorise les clients des applications et des API
Même après que NGINX App Protect Dos et NGINX App Protect WAF ont éliminé le trafic malveillant, vous devez encore vérifier que les clients sont légitimes et autorisés à accéder aux ressources qu’ils demandent. C’est là que NGINX Plus entre en jeu, en assurant l’authentification et l’autorisation, puis en acheminant les requêtes vers les serveurs appropriés. En déployant NGINX Plus comme passerelle d’API, vous pouvez fournir un point d’entrée unique et cohérent pour plusieurs API et, là encore, simplifier votre infrastructure.
L’authentification et l’autorisation peuvent également être automatisées grâce à l’authentification unique (SSO), afin de permettre aux équipes DevOps de conserver l’agilité souhaitée. NGINX Plus prend en charge OpenID Connect (OIDC), une couche d’identité reposant sur le protocole OAuth 2.0. Dans la documentation NGINX, nous expliquons comment utiliser OIDC pour activer l’authentification unique pour les applications faisant l’objet d’un proxy par NGINX Plus.
En raison de leur nature intrinsèquement ouverte, les API sont des cibles vulnérables. Dans son rapport annuel, Gartner Research prévoyait que les API deviendraient le vecteur d’attaque le plus courant en 2022, entraînant d’innombrables violations de données pour les applications web d’entreprise. Cette prévision se confirme à mesure que nous avançons dans l’année 2022 et constatons que la surface d’attaque des API continue de s’étendre au sein des organisations.
Le rapport Incidents liés à l’authentification des API : rapport 2020 sur la protection des applications de F5 Labs met en évidence trois causes courantes d’incidents liés aux API :
- Absence d’authentification aux points de terminaison de l’API
- Authentification d’API défaillante
- Autorisation d’API défaillante
Absence d’authentification sur les points de terminaison de l’API
Lorsque vous mettez en œuvre l’authentification du trafic des API, les clients qui parviennent à prouver leur identité reçoivent un jeton d’un fournisseur d’identité de confiance. Le client présente ensuite le jeton d’accès avec chaque requête HTTP. Avant de transmettre la requête à l’application, NGINX Plus assure l’authentification et l’autorisation du client en validant le jeton et en extrayant l’identité ainsi que d’autres données (l’appartenance à un groupe, par exemple) encodées dans celui-ci. Si le jeton est validé et que le client est autorisé à accéder à la ressource, la requête est transmise au serveur d’applications. Il existe plusieurs méthodes pour effectuer cette validation, mais OpenID Connect (basé sur le protocole OAuth 2.0) est une solution couramment utilisée pour permettre l’authentification des requêtes d’API par un tiers.
Cependant, de nombreuses API disponibles sur le marché ne sont pas protégées au niveau de l’authentification. En 2021, il a été révélé que la plateforme de fitness interactif Peloton présentait une API non sécurisée. Un chercheur en sécurité a découvert qu’il était possible d’envoyer des requêtes non authentifiées à l’API de Peloton et de récupérer ainsi facilement des données utilisateur sans authentification. Bien que Peloton ait corrigé le code avant qu’une faille majeure ne se produise, cet incident montre qu’une approche monolithique de la sécurité ne tient pas compte de la diversité intrinsèque des structures d’API ni de la nécessité qui en découle de faire preuve d’agilité pour les protéger.
Authentification des API défaillante
Les API sont conçues pour connecter des ordinateurs entre eux. De nombreuses équipes DevOps partent donc du principe que les humains ne communiquent pas avec le point de terminaison de l’API. Le rapport de F5 Labs cite notamment le cas d’un chercheur qui a enchaîné plusieurs requêtes API afin de « gagner » des centaines de milliers de dollars de crédits sur une application mobile. L’application générait en permanence des jetons destinés à prévenir les abus, mais ne leur attribuait aucune date d’expiration, ce qui permettait de les réutiliser indéfiniment.
Si vous ne validez pas correctement les jetons d’authentification des API, des attaquants peuvent exploiter les vulnérabilités de ces API. Si ce type de vulnérabilité est découvert par un acteur malveillant plutôt que par un chercheur, il peut compromettre toute une entreprise.
Autorisation d’API défaillante
L’échec de l’authentification des API entraîne naturellement une défaillance de leur mécanisme d’autorisation. Le rapport de F5 Labs décrit également un incident au cours duquel un bug du système d’exploitation a permis l’envoi de requêtes HTTP malveillantes à l’API, donnant ainsi à des acteurs malveillants un accès facile aux jetons d’autorisation. Une fois ce jeton obtenu, les attaquants disposaient de droits d’administrateur.
NGINX propose plusieurs approches pour protéger les API et authentifier les clients d’API. Pour plus d’informations, consultez la documentation relative aux listes de contrôle d’accès basées sur les adresses IP (ACL), à l’authentification par certificat numérique et à l’authentification HTTP Basic. En outre, NGINX Plus prend nativement en charge la validation des jetons web JSON (JWT) pour l’authentification des API. Pour en savoir plus, consultez l’article Authentification des clients d’API avec JWT et NGINX Plus sur notre blog.
Commencez dès aujourd’hui
L’automatisation de la sécurité en fait l’affaire de tous. En donnant la priorité à cette automatisation, votre organisation peut développer des applications plus fiables, atténuer les risques, réduire les dépenses d’exploitation et accélérer le rythme des mises en production. Vos microservices, applications et API bénéficient ainsi d’une sécurité agile, évolutive et suffisamment rapide pour suivre le rythme de la concurrence actuelle.
Cette structure de sécurité en trois phases offre également un flux optimal, car vous ne voulez pas surcharger votre WAF en lui faisant inspecter le trafic provenant d’une attaque par déni de service (DoS), ni gaspiller de précieuses ressources à tenter d’authentifier et d’autoriser des acteurs malveillants. En éliminant rapidement les attaques faciles à identifier, vous pouvez gagner du temps, réduire les coûts et améliorer les performances de votre application.
Prêt à essayer NGINX Plus et NGINX App Protect par vous-même ? Commencez dès aujourd’hui un essai gratuit de 30 jours ou contactez-nous pour discuter de vos cas d’utilisation.
À propos des auteurs
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.