À mesure que les architectures monolithiques évoluent vers des microservices, les applications sont développées plus rapidement que jamais. La rapidité est indispensable pour rester compétitif, et les API sont au cœur de ces efforts de modernisation accélérée. Toutefois, la popularité des API dans la modernisation des applications a des conséquences importantes sur leur sécurité. Les API constituent des cibles vulnérables, car elles exposent la logique applicative et les données sensibles à d’autres applications ou à des tiers. À mesure que l’utilisation des API augmente, le besoin de passerelles API s’accroît également.
Selon le rapport 2021 de F5 sur l’état de la stratégie applicative, les entreprises utilisent différentes méthodes pour se moderniser, et les API sont au cœur de ces efforts de modernisation :
- 58 % ajoutent une couche d’API pour permettre la mise en place d’interfaces utilisateur modernes
- 51 % ajoutent des composants applicatifs modernes (par exemple, Kubernetes)
- 47 % procèdent à une refactorisation (en modifiant le code de l’application lui-même)
- 40 % migrent vers le cloud public (« lift and shift ») sans modernisation
À mesure que les organisations se développent, elles peuvent atténuer les risques liés aux API en adoptant une passerelle API. Dans la version actualisée du Rapport 2022 sur l’état de la stratégie applicative de F5, nous constatons que les passerelles API sont plus performantes à la périphérie du réseau ou à proximité. Elles peuvent ainsi bloquer les attaques avant qu’elles n’affectent l’ensemble du réseau, tout en assurant une protection uniforme et cohérente de plusieurs API. Les passerelles API encapsulent la structure interne d’une application, ce qui fluidifie la communication entre le client et l’API. Au lieu d’appeler des services spécifiques, les clients se connectent simplement à la passerelle API. Le client dispose ainsi d’une API dédiée, le nombre d’allers-retours entre le client et l’API est réduit et le code côté client est simplifié.
Les clients de F5 NGINX ont déployé avec succès des passerelles API dans des environnements distribués. Toutefois, si votre passerelle API n’est pas sécurisée, des acteurs malveillants peuvent toujours parvenir à s’introduire. Chez NGINX, nous disposons d’outils de sécurité robustes pour garantir que vos applications derrière les passerelles API restent sécurisées dans ce paysage en constante évolution.
Davantage d’API signifie une surface d’attaque plus étendue
Les API ne sont pas nouvelles. Les API web remontent aux années 1990, et certaines formes d’API existaient même avant l’Internet tel que nous le connaissons aujourd’hui, pour permettre la communication entre de petits réseaux distribués. Ce que nous observons aujourd’hui — et qui a changé la donne —, ce sont les architectures modernes qui utilisent des API.
Si les API jouent un rôle essentiel dans l’accélération de la modernisation, elles deviennent parallèlement plus faciles à exploiter à des fins malveillantes. Dans les architectures de microservices, une seule API peut comporter des centaines de points de terminaison, et une même application peut être constituée de nombreux microservices qui utilisent des API pour communiquer entre eux. Cette approche diffère de celle des applications monolithiques d’autrefois, qui ne comportaient 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 a également révélé que la plupart des organisations possèdent entre 200 et 1 000 applications et que 77 % d’entre elles exécutent des applications dans plusieurs clouds. Plus le nombre d’applications et d’API ajoutées à un portefeuille dans des environnements distribués est élevé, plus la surface d’attaque potentielle est importante.
Les 10 principales vulnérabilités de sécurité des API selon l’OWASP
Par nature, 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 courantes dans son projet « OWASP API Security Top 10 » :
API1. Autorisation défaillante au niveau des objets
API2. Authentification utilisateur défaillante
API3. Exposition excessive des données
API4. Manque de ressources et limitation insuffisante du débit
API5. Autorisation défaillante au niveau des fonctions
API6. Affectation de masse
API7. Mauvaise configuration de la sécurité
API8. Injection
API9. Gestion inadéquate des actifs
API10. Journalisation et surveillance insuffisantes
Les entreprises d’aujourd’hui doivent faire preuve d’agilité et de rapidité face à l’accélération des cycles de développement. Dans cet environnement vulnérable axé sur les API, les solutions de sécurité doivent être adaptables, légères et intégrées aux processus de déploiement automatisé des API.
Lancez la sécurisation de vos API avec F5 NGINX Plus
Les attaques d’API très médiatisées font régulièrement la une. En 2019, la société de VTC Uber a découvert une faille critique dans son API : un point de terminaison d’API vulnérable permettait à des acteurs malveillants de dérober des données précieuses, notamment les jetons d’authentification des passagers. Heureusement, cette faille a été découverte avant qu’elle ne cause le moindre préjudice. En 2021, LinkedIn n’a pas eu cette chance : en raison d’une vulnérabilité de son API, des pirates ont compromis les données de plus de 700 millions d’utilisateurs de LinkedIn, qui ont ensuite été mises en vente sur le dark web.
En déployant F5 NGINX Plus comme passerelle API, vous pouvez évoluer dans cet environnement des API en pleine mutation tout en bénéficiant de hautes performances pour le routage et la distribution des API. GigaOm, un cabinet indépendant d’études et d’analyses technologiques, a comparé les performances de NGINX à celles d’autres solutions de passerelle API. Les résultats ont montré que NGINX pouvait traiter 30 000 requêtes par seconde avec une latence inférieure à 30 ms, soit une latence 1 000 fois plus faible que celle des passerelles API des hyperscalers.
NGINX Plus offre une protection prête à l’emploi qui ne se limite pas aux vulnérabilités des API répertoriées par l’OWASP : ses fonctions de sécurité supplémentaires vérifient également les cookies, les données JSON et XML malformés, et valident les types de fichiers autorisés ainsi que les codes d’état des réponses. Il garantit la conformité aux RFC HTTP et détecte les techniques de contournement utilisées pour dissimuler les attaques.
NGINX Plus achemine rapidement les requêtes API, tout en authentifiant les clients API et en vérifiant leurs autorisations afin de sécuriser vos API, et limite le débit du trafic pour protéger vos services basés sur des API contre les surcharges. Ces outils protègent également vos API contre les dix principales vulnérabilités du classement OWASP API Security Top Ten :
- Mécanismes d’authentification et d’autorisation – Veillez à ce que seuls les clients disposant des droits d’accès appropriés puissent utiliser vos API. L’un de ces mécanismes repose sur les revendications contenues dans les jetons web JSON (JWT). Cela permet de remédier à plusieurs vulnérabilités du Top 10 de la sécurité des API de l’OWASP : Défaillance de l’autorisation au niveau de l’objet (API1), Défaillance de l’authentification utilisateur (API2), Défaillance de l’autorisation au niveau de la fonction (API5) et Journalisation et surveillance insuffisantes (API10).
- Politiques de limitation du débit – Protégez vos API contre les surcharges et atténuez les attaques DDoS en limitant le nombre de requêtes que la passerelle API accepte de chaque client d’API pendant une période définie. Avec NGINX Plus, les limites de débit peuvent être propres à chaque source (en fonction de la valeur d’une revendication JWT, par exemple), afin de ne pas affecter les utilisateurs légitimes. Cela permet de remédier à la vulnérabilité Manque de ressources et limitation du débit (API4).
Renforcez vos API avec le WAF F5 NGINX App Protect
La sécurisation de votre passerelle d’API avec F5 NGINX App Protect WAF renforce la sécurité de vos API et atténue les attaques répertoriées par l’OWASP, telles que l’Injection (API8). Contrairement aux autres fournisseurs de passerelles d’API et de solutions de gestion des API, qui n’offrent que le strict minimum en matière de protection des API contre les risques de l’OWASP, NGINX App Protect WAF fournit une protection supplémentaire contre des 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 offre également la visibilité nécessaire sur les attaques pour remédier à l’Insuffisance de la journalisation et de la surveillance (API10). Les informations consignées sur ces attaques peuvent être envoyées à des systèmes de gestion des informations et des événements de sécurité (SIEM) ou à d’autres lacs de données du client afin d’être analysées plus en détail.
Si vous utilisez NGINX Plus comme passerelle d’API et équilibreur de charge (pour acheminer les API qui doivent être accessibles sur Internet ainsi qu’aux développeurs et partenaires externes), il s’agit d’un emplacement idéal pour déployer NGINX App Protect WAF afin de les protéger. En supprimant un saut pour le trafic des API, cette protection peut être ajoutée avec un minimum de complexité et de latence.
Conformément aux exigences de conformité PCI relatives au traitement des données sensibles (informations permettant d’identifier une personne [PII]) dans certains secteurs, la charge utile doit être chiffrée de bout en bout sur les réseaux ouverts et publics. Le déploiement de NGINX App Protect WAF au niveau de la passerelle API, derrière un équilibreur de charge ou un CDN, permet à la charge utile de rester entièrement chiffrée jusqu’à son déchiffrement au niveau de la passerelle API. Ainsi, vos API restent protégées tout en respectant les exigences relatives au traitement des données sensibles.
Protection multicouche avec F5 NGINX App Protect WAF
Vous disposez peut-être d’un équilibreur de charge sur lequel est installé un WAF, tel que F5 Advanced WAF. Derrière ces deux éléments, vous avez déployé une passerelle d’API. Alors, pourquoi avez-vous besoin d’un WAF sur votre passerelle d’API si votre équilibreur de charge en possède déjà un ?
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 réside dans un contrôle plus strict et plus granulaire de la sécurité. La responsabilité de la sécurité peut être confiée à une équipe API afin d’adapter davantage les politiques aux spécificités des API.
Grâce à cette approche à deux niveaux, vous pouvez garantir la protection de vos API, même lors des cycles de développement et de publication les plus rapides.
Ajout d’une sécurité positive grâce à la validation des schémas OpenAPI
Un domaine clé dans lequel la protection doit être propre à chaque API est la validation de la spécification OpenAPI de Swagger. Les schémas OpenAPI sont propres à chaque API et évoluent à chaque version de l’API. Une protection fondé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é du WAF centralisé qu’elle gère, car cela nécessite une approbation et des tests rigoureux afin d’éviter des effets inattendus sur d’autres API et applications.
NGINX App Protect WAF peut valider les schémas OpenAPI afin de vérifier que les requêtes sont conformes à ce que l’API prend en charge (méthodes, points de terminaison, paramètres, etc.). C’est pourquoi la solution idéale consiste à utiliser NGINX App Protect WAF pour assurer une sécurité positive au niveau de la passerelle API, derrière un WAF centralisé situé 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 rapidité, et non pour la sécurité. Les API sont également publiées plus fréquemment que les applications d’autrefois. C’est pourquoi nous assistons à un mouvement de shift left dans un environnement axé sur les API. En décalant la sécurité vers la gauche, c’est-à-dire en appliquant les contrôles de sécurité plus tôt dans le cycle de développement des applications, le DevOps évolue vers une culture DevSecOps où la sécurité est traitée comme du code.
Que vous placiez un WAF au niveau de la passerelle API, de l’équilibreur de charge ou des deux, les configurations du WAF doivent être déployées de manière automatisée afin de suivre les changements de version des API. Lorsque les organisations adoptent une culture « shift left » et intègrent la « sécurité en tant que code » au pipeline CI/CD, la sécurité peut être incorporée à chaque étape du développement des applications et des API, plutôt que d’être ajoutée après coup.
L’utilisation des politiques et des configurations de sécurité sous forme de code présente de nombreux avantages :
- Le code peut facilement être récupéré depuis un dépôt de code source.
- Votre équipe SecOps peut créer et gérer des politiques de sécurité déclaratives afin de garantir la mise en place des contrôles nécessaires à la protection de l’entreprise.
- Les politiques déclaratives peuvent être intégrées de manière répétée dans de nouvelles applications et API.
- La sécurité est automatisée au sein du 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 dans ce fichier. Là encore, l’automatisation est essentielle. Une fois qu’une approche « shift-left » ou privilégiant la sécurité dès le départ est pleinement adoptée, les développeurs peuvent facilement récupérer ce code depuis le dépôt, ce qui permet de préserver l’agilité, d’accélérer le rythme de développement et de réduire le délai de mise sur le marché.
Protection haute performance pour vos API
Quel que soit l’emplacement où vous déployez un WAF pour protéger vos API, des performances élevées et une faible latence sont indispensables pour permettre à vos API de répondre rapidement aux clients et d’offrir ainsi une expérience utilisateur plus riche. L’architecture légère du WAF NGINX App Protect garantit ces performances élevées et cette faible latence, tout en nécessitant des ressources de calcul extrêmement limitées dans le cloud.
Dans son rapport « Tests de sécurité des applications hautes performances », GigaOm présente les résultats des tests de performances de NGINX App Protect WAF, d’AWS WAF, d’Azure WAF et du WAF open source ModSecurity. GigaOm a constaté que NGINX App Protect WAF offre une latence 4,7 fois inférieure à celle du WAF open source ModSecurity sur NGINX, et 128 fois inférieure à celle d’AWS WAF pour les applications nécessitant des performances élevées.
NGINX est le seul fournisseur à intégrer un WAF à une passerelle d’API NGINX, ce qui évite une étape supplémentaire au trafic des API. La réduction du nombre d’étapes entre les couches diminue la latence, la complexité et les points de défaillance. Cette approche contraste fortement avec les solutions classiques de gestion des API qui n’intègrent pas de WAF (vous devez déployer le WAF séparément et, une fois celui-ci configuré, le trafic des API doit transiter séparément par le WAF et la passerelle d’API). L’intégration étroite de NGINX garantit des performances élevées sans compromettre la sécurité.
Conclusion
Chez NGINX, nous proposons une sécurité robuste des API avec NGINX Plus et le WAF NGINX App Protect. Grâce à la scalabilité légère de NGINX et à la robustesse du moteur Advanced WAF de F5, vous pouvez aborder sereinement un monde piloté par les API, avec la certitude que vos applications modernes sont sécurisées.
Fidèle aux valeurs fondamentales de NGINX, NGINX App Protect WAF est une solution moderne de sécurité logicielle des applications, indépendante de la plateforme et s’intégrant parfaitement aux chaînes d’outils DevOps courantes afin de réduire les frictions et d’accélérer les déploiements sécurisés. Grâce à ses 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 du développement logiciel (SDLC). Cela permet non seulement d’accélérer le rythme des mises en production, mais aussi d’aider les entreprises à créer des API fiables et protégées, tout en comblant les écarts entre les équipes DevOps et SecOps et en favorisant une évolution culturelle vers le 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.
À 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.