BLOG | NGINX

Sécurisez votre passerelle API avec NGINX App Protect WAF

NGINX-Partie-de-F5-horiz-black-type-RGB
Miniature de Thelen Blum
Thélen Blum
Publié le 26 mai 2022
Vignette de Daphné Won
Daphné Won
Publié le 26 mai 2022

À mesure que les monolithes évoluent vers les microservices, les applications sont développées plus rapidement que jamais. La rapidité est nécessaire pour rester compétitif et les API sont à l’avant-garde de ces efforts de modernisation rapide. Mais la popularité des API pour la modernisation des applications a des implications importantes pour la sécurité des applications. Les API sont des cibles d’attaque vulnérables, exposant la logique d’application et les données sensibles à d’autres applications ou à des tiers. À mesure que l’utilisation des API augmente, le besoin de passerelles API augmente également.

Selon le rapport 2021 de F5 sur l'état de la stratégie applicative , les organisations utilisent diverses méthodes pour se moderniser, et les API arrivent en tête de ces efforts de modernisation :

  • 58 % ajoutent une couche d'API pour permettre des interfaces utilisateur modernes
  • 51 % ajoutent des composants d'application modernes (par exemple, Kubernetes)
  • 47 % procèdent à un refactoring (modification du code de l'application lui-même)
  • 40 % migrent vers le cloud public (lifting et déplacement) sans modernisation

Graphique à barres horizontales montrant le pourcentage d'organisations se modernisant de quatre manières différentes

À mesure que les organisations se développent, elles peuvent atténuer les risques liés aux API en adoptant une passerelle API. Dans le rapport 2022 mis à jour de F5 sur l'état de la stratégie des applications , nous constatons que les passerelles API fonctionnent mieux en périphérie ou à proximité. Ici, les passerelles API peuvent arrêter les attaques avant qu'elles n'affectent l'ensemble du réseau, offrant ainsi une protection uniforme et cohérente pour plusieurs API. Les passerelles API encapsulent la structure interne d'une application, simplifiant ainsi la communication entre le client et l'API. Plutôt que d'appeler des services spécifiques, les clients se connectent simplement à la passerelle API. Cela fournit au client une API spécifique, réduit le nombre d'allers-retours entre le client et l'API et simplifie le code client.

Les clients F5 NGINX ont déployé avec succès des passerelles API dans des environnements distribués. Mais si votre passerelle API n’est pas sécurisée, des acteurs malveillants peuvent toujours y accéder. Chez NGINX, nous disposons d’outils de sécurité puissants pour garantir que vos applications derrière les passerelles API restent sécurisées dans ce paysage en constante évolution.

Plus d'API signifie plus de surface d'attaque

Les API ne sont pas nouvelles. Les API basées sur le Web remontent aux années 1990 et des versions d’API existaient même avant l’Internet que nous connaissons aujourd’hui, sous forme de communication entre de petits réseaux distribués. Ce que nous voyons maintenant – ce qui a changé la donne – ce sont les architectures modernes utilisant des API.

Si les API jouent un rôle essentiel dans l’accélération de la modernisation, elles deviennent simultanément plus faciles à exploiter. Dans les architectures de microservices, une seule API peut avoir des centaines de points de terminaison et une seule application peut être constituée de plusieurs microservices qui utilisent des API pour se connecter les uns aux autres. Cela diffère des applications monolithiques du passé, où il n’y avait qu’un seul point d’entrée à sécuriser. Chaque microservice exposant plusieurs ensembles de points de terminaison d’API, la surface d’attaque potentielle a été multipliée par dix.

Le rapport 2022 de F5 révèle également que la plupart des organisations possèdent entre 200 et 1 000 applications et que 77 % exécutent des applications dans plusieurs clouds. Plus vous ajoutez d’applications et d’API à un portefeuille dans des environnements distribués, plus votre surface d’attaque possible est grande.

Top 10 des vulnérabilités de sécurité des API OWASP

Par définition, les API sont ouvertes et peuvent exposer des données sensibles. L'Open Web Application Security Project (OWASP) met en évidence les vulnérabilités les plus répandues dans son projet OWASP API Security Top 10 :

API1. Autorisation au niveau de l'objet brisé
API2. Authentification utilisateur interrompue
API3. Exposition excessive des données
API4. Manque de ressources et limitation de débit
API5. Autorisation de niveau de fonction interrompue
API6. Affectation de masse
API7. Mauvaise configuration de sécurité
API8. Injection
API9. Mauvaise gestion des actifs
API10. Enregistrement et surveillance insuffisants

 

Les entreprises d’aujourd’hui ont besoin d’agilité et de rapidité à mesure que les cycles de développement s’accélèrent. Les solutions de sécurité dans ce paysage vulnérable axé sur les API doivent être adaptables, légères et intégrées dans le cadre des processus de déploiement automatisés d’une API.

Démarrez la sécurité de votre API avec F5 NGINX Plus

Les attaques d’API de grande envergure font régulièrement la une des journaux. En 2019, la société de covoiturage Uber a vu un bug critique découvert dans son API : un point de terminaison d'API vulnérable permettait à des acteurs malveillants de voler des données précieuses, notamment les jetons d'authentification des passagers. Heureusement, ce bug a été découvert avant qu’un dommage ne survienne. En 2021, LinkedIn n’a pas eu autant de chance : en raison d’une vulnérabilité de l’API, des pirates ont piraté les données appartenant à plus de 700 millions d’utilisateurs de LinkedIn , qui ont ensuite été proposées à la vente sur le dark web.

En déployant F5 NGINX Plus comme passerelle API , vous pouvez entrer dans ce paysage API rapide avec des performances élevées lors de la gestion du routage et de la livraison des API. GigaOm, une société indépendante de recherche et d'analyse technologique, a comparé NGINX à d'autres solutions de passerelle API . Les résultats de référence ont montré que NGINX était capable de fournir 30 000 requêtes par seconde avec une latence inférieure à 30 ms, soit une latence 1 000 fois inférieure à celle des passerelles API des hyperscalers.

NGINX Plus offre une protection prête à l'emploi non seulement contre les vulnérabilités de l'API OWASP, mais sa protection de sécurité supplémentaire comprend également des vérifications des cookies malformés, JSON et XML, et valide les types de fichiers autorisés et les codes d'état de réponse. Il garantit la conformité avec les RFC HTTP et détecte les techniques d'évasion utilisées pour masquer les attaques.

NGINX Plus achemine rapidement les requêtes API, tout en authentifiant et en autorisant les clients API pour sécuriser vos API, et en limitant le débit du trafic pour sécuriser vos services basés sur API contre les surcharges. Ces outils sécurisent également vos API contre les dix principales vulnérabilités de sécurité des API OWASP :

  • Mécanismes d’authentification et d’autorisation – Assurez-vous que seuls les clients disposant des privilèges d’accès appropriés peuvent utiliser vos API. L’un de ces mécanismes est celui des revendications dans les jetons Web JSON (JWT). Cela corrige plusieurs vulnérabilités dans le Top 10 de la sécurité des API OWASP : Autorisation au niveau de l'objet rompue (API1), authentification de l'utilisateur rompue (API2), autorisation au niveau de la fonction rompue (API5) et journalisation et surveillance insuffisantes (API10).
  • Politiques de limitation de débit – Protégez vos API contre les surcharges et atténuez les attaques DDoS en définissant une limite au nombre de requêtes que la passerelle API accepte de chaque client API dans une période définie. Avec NGINX Plus, les limites de débit peuvent être spécifiques à la source (en fonction de la valeur d'une réclamation JWT, par exemple), de sorte que les utilisateurs valides ne sont pas impactés. Cela permet de résoudre la vulnérabilité liée au manque de ressources et à la limitation du débit (API4).

Renforcez vos API avec F5 NGINX App Protect WAF

Sécuriser votre passerelle API avec F5 NGINX App Protect WAF offre une sécurité API supplémentaire et atténue les attaques OWASP telles que l'injection (API8). Contrairement à d’autres fournisseurs de passerelles et de gestion d’API qui offrent le strict minimum pour la protection des API OWASP, NGINX App Protect WAF offre une protection supplémentaire contre les vulnérabilités telles que l’exécution de code à distance (RCE), les scripts intersites (XSS) et d’autres vecteurs d’attaque. NGINX App Protect WAF fournit également la visibilité d'attaque nécessaire pour la journalisation et la surveillance insuffisantes (API10). Ces détails d'attaque enregistrés peuvent être envoyés aux systèmes de gestion des informations et des événements de sécurité (SIEM) ou à d'autres lacs de données clients pour une analyse supplémentaire.

Si vous utilisez NGINX Plus comme passerelle API et équilibreur de charge (pour le routage des API qui doivent être exposées à Internet et pour les développeurs et partenaires externes), c'est l'endroit idéal pour déployer NGINX App Protect WAF pour la protection. Avec un saut de moins pour le trafic API, la protection peut être ajoutée avec le moins de complexité et la latence la plus faible.

Conformément aux exigences de conformité PCI pour le traitement des données sensibles (informations d'identification personnelle [PII]) dans certains secteurs, la charge utile doit être cryptée de bout en bout sur des réseaux publics ouverts . Le fait d'avoir NGINX App Protect WAF au niveau de la passerelle API, derrière un équilibreur de charge ou un CDN, signifie que la charge utile reste entièrement cryptée jusqu'à ce qu'elle soit décryptée au niveau de la passerelle API. Ainsi, vos API peuvent rester protégées tout en répondant aux exigences de traitement des données sensibles.

Protection multicouche avec F5 NGINX App Protect WAF

Diagramme de topologie de trois options de déploiement de NGINX App Protect WAF avec des passerelles API

Vous disposez peut-être d'un équilibreur de charge et d'un WAF (tel que F5 Advanced WAF) sur cet équilibreur de charge. Derrière ceux-ci, vous avez déployé une passerelle API. Alors, pourquoi avez-vous besoin d’un WAF sur votre passerelle API si vous en avez déjà un sur votre équilibreur de charge ?

L’un des principaux avantages du passage d’une combinaison équilibreur de charge-WAF en périphérie à une combinaison passerelle API-WAF au sein de votre environnement est un contrôle plus strict et plus granulaire de la sécurité. La responsabilité de la sécurité peut être transférée à une équipe API pour rendre les politiques plus spécifiques à l’API.

Grâce à cette approche à deux niveaux, vous pouvez garantir que vos API restent protégées même dans les cycles de développement et de publication d’API les plus rapides.

Ajout d'une sécurité positive avec la validation de schéma OpenAPI

Un domaine clé dans lequel la protection doit être spécifique à l'API est la validation de la spécification OpenAPI de Swagger. Les schémas OpenAPI sont uniques à chaque API et changent avec chaque version d'API. La protection basée sur le schéma OpenAPI d'une API ne peut pas attendre qu'une équipe informatique mette à jour les contrôles de sécurité sur le WAF centralisé qu'elle gère, ce qui nécessite une approbation et des tests minutieux pour éviter des effets inattendus sur d'autres API et applications.

NGINX App Protect WAF peut valider les schémas OpenAPI, en vérifiant que les requêtes sont conformes à ce que l'API prend en charge (méthodes, points de terminaison, paramètres, etc.). C’est pourquoi il est idéal que NGINX App Protect WAF fournisse une sécurité positive au niveau de la passerelle API derrière un WAF centralisé au niveau de l’équilibreur de charge.

« La sécurité en tant que code » pour suivre le rythme des déploiements d’API

Les pipelines CI/CD sont conçus pour la vitesse, pas pour la sécurité. Les API sont également publiées plus fréquemment que les applications du passé. C’est pourquoi nous assistons à un mouvement de déplacement vers la gauche dans le paysage piloté par les API. En se déplaçant vers la gauche ou en appliquant des contrôles de sécurité plus tôt dans le cycle de vie du développement de l'application, DevOps évolue vers une culture DevSecOps où la sécurité est traitée comme du code.

Icône avec le symbole de l'infini montrant le flux de travail DevSecOps

Que vous localisiez un WAF au niveau de la passerelle API, de l'équilibreur de charge ou des deux, les configurations WAF doivent être déployées de manière automatisée pour suivre les modifications de version de l'API. Lorsque les organisations adoptent une culture shift-left et intègrent la « sécurité en tant que code » dans le pipeline CI/CD, la sécurité peut être intégrée à chaque étape du développement des applications et des API, plutôt que d’être ajoutée après coup.

La consommation de la politique de sécurité et des configurations sous forme de code présente de nombreux avantages :

  • Le code peut être facilement extrait d’un référentiel de code source.
  • Votre équipe SecOps peut créer et maintenir des politiques de sécurité déclaratives pour garantir que les contrôles nécessaires à la protection de l'entreprise sont en place.
  • Les politiques déclaratives peuvent être codées à plusieurs reprises dans de nouvelles applications et API.
  • La sécurité devient automatisée dans le pipeline CI/CD.

Lors de l'automatisation du schéma d'API, chaque fois que vous mettez à jour une API, vous devez également mettre à jour la configuration et le code de ce fichier. Encore une fois, l’automatisation est la clé. Une fois qu'une philosophie de shift-left ou de « sécurité avant tout » est pleinement adoptée, les développeurs peuvent facilement récupérer ce code à partir du référentiel, préservant ainsi l'agilité, augmentant la vélocité et accélérant la mise sur le marché.

Protection haute performance pour vos API

Quel que soit l'endroit où vous placez un WAF pour protéger vos API, des performances élevées et une faible latence sont des exigences qui permettent à vos API de répondre rapidement aux clients pour une expérience utilisateur plus riche. L’architecture légère de NGINX App Protect WAF offre ces hautes performances et cette faible latence avec des exigences de calcul extrêmement faibles dans le cloud.

Dans son rapport de test de sécurité des applications hautes performances , GigaOm rapporte le résultat des tests de performances pour NGINX App Protect WAF, AWS WAF, Azure WAF et ModSecurity Open Source WAF. GigaOm a découvert que NGINX App Protect WAF avait une latence 4,7 fois inférieure à celle de ModSecurity OSS WAF sur NGINX et une latence 128 fois inférieure à celle d'AWS WAF pour les applications nécessitant des performances élevées.

NGINX est le seul fournisseur qui intègre un WAF dans une passerelle API NGINX, ce qui permet de réduire d'un saut le trafic API. Moins de sauts entre les couches réduisent la latence, la complexité et les points de défaillance. Cela contraste fortement avec les solutions de gestion d’API classiques qui ne s’intègrent pas à un WAF (vous devez déployer le WAF séparément et, une fois qu’il est configuré, le trafic API doit traverser le WAF et la passerelle API séparément). L’intégration étroite de NGINX signifie des performances élevées sans compromettre la sécurité.

Conclusion

Chez NGINX, nous offrons une sécurité API renforcée avec NGINX Plus et NGINX App Protect WAF. Grâce à l’évolutivité légère de NGINX et à la robustesse du moteur WAF avancé de F5, vous pouvez entrer dans le monde piloté par API en étant sûr que vos applications modernes sont sécurisées.

Fidèle aux valeurs fondamentales de NGINX, NGINX App Protect WAF est une solution de sécurité logicielle d'application moderne, indépendante de la plate-forme et s'intègre de manière transparente aux chaînes d'outils DevOps courantes pour éliminer les frictions et accélérer les déploiements sécurisés. Grâce aux capacités de configuration déclarative, la sécurité peut être automatisée dans le cadre du pipeline CI/CD et de l'ensemble du cycle de vie de développement logiciel (SDLC). Non seulement cela contribue à accélérer la vitesse de publication, mais cela aide également les organisations à créer des API fiables et protégées tout en comblant les écarts entre les équipes DevOps et SecOps et en permettant un changement culturel vers DevSecOps.

Prêt à essayer NGINX App Protect WAF par vous-même ? Commencez un essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .


« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."