Roey Eliyahu, cofondateur et PDG de Salt Security, et Ed Amoroso, fondateur et PDG de TAG Cyber, ont récemment animé un webinaire commun consacré à la sécurité des API et au modèle « zero trust ». Lorsque des experts du secteur débattent de deux des sujets les plus brûlants de la cybersécurité, le résultat est forcément instructif, et cette session n'a pas fait exception.
Qu'est-ce qui nous a menés au « zero trust » ?
Dans les années 90 et au début des années 2000, les entreprises s'appuyaient sur des protections périmétriques, utilisant l'authentification pour faciliter un accès utilisateur sans entrave à l'intérieur du périmètre. Avec l'essor des environnements hybrides et le développement du cloud, ces types de protections sont devenus obsolètes, favorisant l'émergence de l'architecture « zero trust ».
Ed définit le « zero trust » comme une situation qui survient lorsque le périmètre disparaît, ce qui englobe pratiquement tout dans les architectures hybrides actuelles. Comme les ressources sont désormais accessibles depuis presque n'importe quel point, il est impossible de définir un périmètre. Le « zero trust » préconise la création d'environnements « de confiance » pour héberger les applications, les systèmes et les données, en appliquant le principe du moindre privilège.
La grande majorité des entreprises cherchent à adopter une forme de « zero trust », un fait que nous avons facilement validé lors d'un sondage rapide durant le webinaire avec la question suivante :
Le « zero trust » est-il pris en compte dans votre architecture de sécurité actuelle ?
- 57 % – Le « zero trust » est une considération majeure
- 7 % – Le « zero trust » est une considération mineure
- 35 % – Le « zero trust » n'est pas encore pris en compte, mais nous évoluons vers ce modèle
En d'autres termes, seul 1 % des répondants a indiqué ne pas prendre du tout en compte le « zero trust » dans son architecture ! Compte tenu de l'influence considérable du « zero trust » sur les stratégies de sécurité, les entreprises doivent également comprendre ses limites en matière de sécurité des API.
Le dilemme entre « zero trust » et sécurité des API
De nombreux risques liés aux API ne peuvent être atténués par le « zero trust ». Comme les API ont besoin d'accéder aux données pour fonctionner, les méthodes « zero trust » atteignent leurs limites en matière de sécurité des API. Voici trois exemples, abordés par Roey et Ed, illustrant pourquoi les méthodologies « zero trust » ne suffisent pas à protéger les API :
- Les API permettent le fonctionnement des applications métier
- Les API inconnues ne peuvent pas être protégées par le « zero trust »
- De nombreuses attaques par API proviennent d'utilisateurs authentifiés
Les API permettent le fonctionnement des applications métier
Avec la multiplication des initiatives de transformation numérique, l'utilisation des API a explosé. Les API ont été spécifiquement conçues pour partager des données et des services entre les applications. La majorité des données qui entrent et sortent de nos entreprises transitent par des API. D'ailleurs, comme l'a souligné Roey lors du webinaire, 83 % du trafic Internet est constitué de trafic API !
Parce que les API font fonctionner toutes vos applications, elles sont essentielles à la création de valeur métier. Les API utilisées dans les applications de commerce en ligne vous permettent d'acheter des produits. Les API de fintech vous permettent de transférer des fonds depuis votre compte bancaire selon vos besoins. Pour mener une activité numérique, les entreprises ne peuvent pas bloquer ces API, sous peine de ne plus avoir d'activité à gérer.
Les API inconnues ne peuvent pas être protégées par le « zero trust »
La rapidité de développement, de déploiement et de modification des API rend impossible leur suivi manuel.
Dans notre rapport sur l'état de la sécurité des API au T3, nous avons constaté que les API « fantômes » ou inconnues, ainsi que les API « zombies » ou obsolètes, constituent une préoccupation majeure pour les entreprises. 42 % des organisations déclarent que leur principale inquiétude en matière de sécurité des API concerne les API obsolètes. En fait, les API obsolètes ont été désignées comme la préoccupation numéro un en matière de sécurité des API lors des quatre dernières enquêtes menées par Salt Security.
Ces API inconnues et non sécurisées peuvent être exposées à l'insu même des organisations ! Quelle que soit la pratique de sécurité adoptée, si vous ignorez l'existence d'un actif, vous ne pouvez pas le protéger !
De nombreuses attaques d'API proviennent d'utilisateurs authentifiés
De nombreux incidents de sécurité liés aux API surviennent alors que l'API est utilisée conformément à sa conception. Par exemple, les attaquants peuvent recourir à des techniques d'ingénierie sociale pour obtenir les clés ou les identifiants d'un utilisateur autorisé afin de mener à bien leur exploitation. Dans ce cas, le fait que chaque utilisateur ait été authentifié par une approche « zero trust » n'a aucune importance.
Les récents incidents liés à l'API de Twitter et à Peloton illustrent l'abus d'une API utilisée conformément à sa conception pour l'exfiltration de données et l'accès non autorisé. Une utilisation légitime d'une API peut permettre à des attaquants d'accéder à des données restreintes, comme l'explique la vulnérabilité OWASP API3 : Exposition excessive de données.
En résumé, certains risques liés aux API ne peuvent être atténués par le « zero trust »
Selon Roey et Ed, il existe souvent une confusion entre la sécurité des API et le « zero trust ». La réalité est que, même avec une stratégie « zero trust » efficace, certains risques liés aux API ne peuvent être atténués par cette seule approche. Vous pouvez écouter l'intégralité du webinaire de Roey et Ed ici.
Pour découvrir comment la plateforme de protection des API de Salt Security peut vous aider à protéger vos services et données critiques, inscrivez-vous pour une démo personnalisée.