3 approches pour devancer les menaces ciblant les API
Une sécurité centrée sur les API pour un monde centré sur les API
Les pièges dissimulés de l'interconnexion des ressources par API
Il y a plus de vingt ans de cela, Jeff Bezos a déclaré que toutes les équipes d'Amazon devraient « exposer leurs données et leurs fonctionnalités par le biais d'interfaces de service », sans aucune exception. Ce mémo (aujourd'hui connu sous le nom de « API mandate») stipule fondamentalement que les interfaces de programmation d'applications (API) ne sont pas facultatives, et il a contribué à lancer les développeurs du monde entier dans une course visant à connecter toutes les ressources par l'intermédiaire d'API. Néanmoins, pour de nombreuses entreprises, la sécurité des API a pris du retard par rapport au rythme rapide du déploiement des API.
Selon le récent Rapport 2024 consacré à la gestion et à la sécurité des API, le trafic lié aux API représente désormais la majorité (environ 57 %) de la totalité du trafic Internet dynamique. Cependant, les entreprises se trouvent souvent confrontées à des défis tels que les suivants :
Des surfaces d'attaque invisibles et non protégées : les services informatiques et de sécurité ne peuvent pas défendre des ressources qu'ils ne voient pas, et les entreprises utilisent des « API fantômes (c'est-à-dire des API non gérées par leurs équipes informatiques ou de sécurité), ce qui entraîne une exposition des données, des mouvements latéraux et d'autres cyber-risques.
Autorisations trop permissives : entre de mauvaises mains, l'accès « en écriture » à des API conçues à l'origine pour être en lecture seule rend les systèmes vulnérables aux attaques et aux pertes de données potentielles. Près de 60 % des entreprises accordent un accès « en écriture » à au moins la moitié de leurs API.
Les entreprises peuvent facilement négliger et classer incorrectement les causes des erreurs liées aux API : toutes les erreurs liées aux API ne sont pas imputables à des attaques, et toutes les attaques contre des API ne peuvent pas être atténuées de la même manière. Une erreur ou une vulnérabilité manquée ou incorrectement diagnostiquée peut conduire à une expérience utilisateur insatisfaisante, voire, pire encore, à une cyberattaque.
On estime à 200 millions le nombre d'API publiques et privées actuellement utilisées, et ce chiffre ne cesse d'augmenter. Pour exploiter en toute sécurité la puissance de ces API (et des API futures), les entreprises ont besoin d'une approche dédiée de gestion des API, qui tiennent compte des trois bonnes et mauvaises pratiques suivantes.
1) Ayez recours à des services d'apprentissage automatique dédiés pour améliorer l'efficacité de la visibilité des API et de la gestion de la sécurité.
Supposons que l'hôpital Acme propose des initiatives numériques appréciées par ses patients et ses prestataires – tout, d'une expérience fluide de la télésanté mobile au traitement assisté par IA des dossiers médicaux. Un jour, un des développeurs d'Acme autorise l'accès « en écriture » à l'API d'un système de facturation sans documentation appropriée. Quelques mois plus tard, le fournisseur de l'API est victime d'une cyber-attaque. Ensuite, par le biais de mouvements latéraux, les acteurs malveillants sont en mesure d'exploiter l'API publique d'Acme pour s'introduire dans les dossiers médicaux des patients de l'hôpital.
L'hôpital Acme aurait pu détecter et atténuer ce scénario plus tôt s'il avait disposé d'un moyen de le faire automatiquement :
Découvrir tous les points de terminaison d'API publics (y compris les API non authentifiées) et le trafic associé.
Détecter les schémas d'API, c'est-à-dire les métadonnées qui définissent les spécifications d'un appel/d'une réponse d'API valide)
Détecter les variantes d'attaques contre les API
C'est ici qu'entrent en scène des solutions de sécurité des API utilisant des modèles d'apprentissage automatique et ne nécessitant pas de communications manuelles et ponctuelles entre le service informatique, le service de sécurité et les développeurs.
Par exemple, la découverte d'API et la détection de schémas d'API recourant à l'apprentissage automatique peuvent permettre à des entreprises comme Acme de disposer d'un inventaire plus complet de leurs API : quelles sont ces API ? À quelles données et quels systèmes accèdent-elles ? À quel instant et depuis quel emplacement se déroulent les accès ? À quels utilisateurs ont été accordées les autorisations en « lecture seule » ou en « écriture » ?
Ce type de données est essentiel pour empêcher la prolifération d'API fantômes. Lors du développement de nouvelles fonctionnalités pour les clients (qui sont souvent exposées en premier lieu sous la forme d'API accessibles depuis Internet), la documentation des API et les « bonnes pratiques » en matière de sécurité sont généralement laissées à l'appréciation des développeurs individuels. Souvent, l'intégration des équipes de sécurité au processus est grevée par le manque de temps ou de ressources.
C'est pour cette raison que des problèmes de sécurité apparaissent : les entreprises ne peuvent pas protéger ce qu'elles ne voient pas . En réalité, les modèles d'apprentissage automatique de Cloudflare ont permis de découvrir un nombre de terminaisons d'API supérieur de 31 % au nombre déclaré par les entreprises, ce qui suggère que près d'un tiers des API sont fondamentalement des API fantômes.
Les API fantômes (souvent installées pour des raisons légitimes lors de fréquentes modifications du code) ne sont pas intrinsèquement malveillantes. Toutefois, si l'on considère que 86 % des développeurs ne considèrent pas la sécurité des applications comme une priorité absolue, les API fantômes constituent effectivement une menace de premier ordre. Si elles sont exploitées, elles peuvent entraîner une exposition des données, des vulnérabilités non corrigées, des violations de la conformité des données, ainsi que d'autres risques. L'apprentissage automatique permet de révéler au grand jour ces API fantômes.
2) Ne vous fiez pas uniquement aux outils de sécurité des applications web pour la sécurité et la gestion des API.
Les applications web et les API sont fondamentalement différentes. Une application de covoiturage est « visible » pour ses utilisateurs, mais l'API qui permet à l'application d'accéder aux données de Google Maps est « invisible ». Compte tenu de ces différences (et d'autres également), les entreprises ont besoin d'une solution dédiée de sécurité des API, et pas uniquement d'une solution de sécurité des applications web, pour protéger les API.
Par exemple, un pare-feu d'applications web (WAF) traditionnel filtre et surveille le trafic HTTP entre une application web et le site Internet sur la base d'une liste de blocage. Le pare-feu WAF recherche les signes connus d'une attaque, puis prend des mesures afin d'y mettre un terme. Le reste du trafic est autorisé. Il s'agit du modèle de sécurité « négatif », qui peut être efficace pour la sécurité des applications web, qui permet d'identifier et de bloquer plus facilement le trafic web malveillant.
Cependant, la protection des API contre l'utilisation abusive (c'est-à-dire la sécurité des API) nécessite une sécurité « positive ». Au lieu de rechercher les « requ êtes malveillantes connues », recherchez les « requêtes légitimes connues » et autorisez uniquement ces dernières, en bloquant toutes les autres.(Pour en savoir plus sur ce qui définit ces requêtes, c'est-à-dire les appels d'API, cliquez ici).
Pourquoi ?
Prenons l'exemple d'un fournisseur de télécommunications australien, qui a subi une violation ayant entraîné la divulgation des données de près de 10 millions de clients. Le pirate informatique avait accédé à une certaine base de données clients via une API non authentifiée. Bien que tous les détails de l'attaque ne soient pas connus du public, il convient de noter qu'un modèle « positif » de sécurité des API aurait permis d'autoriser uniquement le trafic d'API conforme aux spécifications d'API de l'entreprise.
En d'autres termes, vous devez adopter une approche « positive » de la sécurité des API et autoriser uniquement le trafic provenant d'utilisateurs authentifiés et de réseaux d'entreprise authentifiés, effectuant des actions autorisées. (Les entreprises peuvent également associer des modèles de sécurité, par exemple, en superposant la sécurité « négative » d'un pare-feu WAF et la sécurité « positive » d'une passerelle API).
Pour conclure, la protection des API nécessite une approche défensive exhaustive contre un large spectre de dangers, parmi lesquelles figurent notamment les 6 principales menaces suivantes pour les API :
Source : rapport 2024 consacré à la gestion et à la sécurité des API
Comme le montre le graphique ci-dessus, les anomalies HTTP constituent la majorité (60,7 %) des menaces ciblant les API atténuées. Les anomalies HTTP (telles que l'absence d'agents utilisateurs, c'est-à-dire le logiciel récupérant le contenu Internet pour les utilisateurs finaux, ainsi que et d'autres anomalies) sont des signaux courants de requêtes malveillantes.
En appliquant une sécurité « positive » (comme décrit précédemment), les entreprises peuvent identifier les anomalies HTTP et les autres menaces, et autoriser uniquement le trafic « propre » pour chaque API vers leurs serveurs d'API.
3) Unifiez la gestion du développement, des performances et de la sécurité des applications.
Les équipes responsables de l'informatique, de la sécurité et du développement d'applications doivent toutes être solidaires de la responsabilité de la protection de l'immense surface d'attaque qu'entraîne la présence de milliers de ressources prises en charge par des API. Cependant, les priorités de ces équipes sont souvent contradictoires :
73 % des développeurs affirment que les tâches ou les outils qui leur sont imposés par leur équipe de sécurité « interfèrent avec leur productivité et leur capacité d'innovation ».
87 % des DSI pensent que les ingénieurs logiciels et les développeurs « font des compromis sur les politiques de sécurité et les mesures de contrôle pour lancer de nouveaux produits et services plus rapidement sur le marché ».
La moitié seulement des RSSI estiment que les développeurs sont « très familiers » avec les risques que comportent les outils de développement et d'automatisation en matière de sécurité.
En conséquence, les entreprises peuvent être confrontées à la nécessité d'accepter des « compromis » entre une innovation plus rapide et l'amélioration de la sécurité, ce qui rend leurs API vulnérables. Selon le rapport, près de 60 % des entreprises autorisent l'accès en écriture à la moitié de leurs API au moins ; mais en fin de compte, à qui incombe-t-il de s'assurer que l'accès « en écriture » n'est pas accordé au mauvais utilisateur ?
Pour une entreprise qui expose continuellement de nouveaux services via des API, le cloud de connectivité peut constituer le tissu conjonctif entre le déploiement d'applications et la défense en profondeur des API.
La solution de cloud de connectivité se présente sous la forme d'une plateforme unifiée de services cloud-native, qui simplifie la sécurisation de la connectivité point-à-point (« any-to-any ») sur l'ensemble des environnements informatiques. Elle permet ainsi aux entreprises de reprendre le contrôle et la visibilité sur leurs domaines numériques tentaculaires, et notamment leur trafic d'API.
Avec le cloud de connectivité, les entreprises peuvent mettre en œuvre les initiatives suivantes (et bien d'autres également) depuis un plan de contrôle unique :
Automatiser la découverte et la visibilité des API, afin de présenter à toutes les parties prenantes un inventaire clair de leur parc d'API
Moderniser les processus d'authentification et d'autorisation d'API dès le départ
Gérer les points de terminaison d'API afin de surveiller des indicateurs tels que la latence, les erreurs et les taux d'erreur, ainsi que la taille de la réponse pour les domaines pilotés par API
Offrir une protection contre les menaces liées à la couche application (couche 7) des API, telles que les attaques DDoS, les tentatives de connexion par force brute et d'autres utilisations abusives de l'API.
Améliorer la maturité de la sécurité des API au fil du temps
La technologie des API n'est pas nouvelle ; toutefois, la prise en compte exhaustive de la sécurité des API est une nouveauté pour de nombreuses équipes AppSec et AppDev. Cependant, tout progrès doit commencer quelque part, et la sécurité des API peut être abordée par étapes :
Étape 1 – Visibilité : commencez par identifier toutes les API utilisées au sein de votre entreprise. Utilisez des outils de découverte d'API, examinez la documentation technique et les accords, échangez avec vos développeurs et surveillez votre trafic web.
Étape 2 – Protection générale contre les attaques web : les applications web et les API opèrent souvent ensemble (par exemple, un site web d'e-commerce utilisant une API pour traiter les paiements). L'utilisation et l'intégration d'outils conçus directement pour protéger les applications web (et, dans une certaine mesure, les API sur lesquels elles reposent) contre les attaques DoS et DDoS, les attaques par bourrage d'identifiants (« credential stuffing »), les vulnérabilités zero-day et d'autres menaces.
Étape 3 – Consolidation de la sécurité avancée des API : le portefeuille de solutions de protection des applications web et des API (WAAP) de Cloudflare, qui repose sur le cloud de connectivité, fournit une sécurité et des performances exhaustives autour des API accessibles au public sans inhiber la productivité. Grâce aux fonctionnalités de découverte d'API, de gestion et d'analyse des données intégrées et de défense par couches des API, Cloudflare permet aux équipes informatiques et de sécurité de bénéficier d'une visibilité et d'un contrôle sur leurs API.
Cet article fait partie de notre série consacrée aux nouvelles tendances et évolutions susceptibles d'affecter les décideurs en matière de technologies d'aujourd'hui.
Approfondir le sujet.
Téléchargez le rapport 2024 API Security and Management pour explorer les vulnérabilités les plus courantes des API, les prévisions sectorielles et des recommandations plus approfondies concernant la protection des API.
Points clés
Cet article vous permettra de mieux comprendre les points suivants :
3 défis courants liés aux API
Les bonnes et mauvaises pratiques en matière de gestion d'API dédiées
Comment améliorer progressivement la maturité de la sécurité des API