” Je me rappelle ce passé avec les équipes de développement où les livraisons de code avaient lieu une fois par semaine, chaque mardi matin à 6h. Nous suivions tôt le matin le déploiement de chaque application monolithique, en espérant que le comportement en production soit conforme et n’entraine aucune régression. 5 années plus tard le monde a bien changé (et tant mieux). “
Des APIs développées avec agilité et ouvertes vers l’extérieur
Les APIs ont pris le relai et les architectures avec des macro-silos de code ont été remplacées par des environnements de microservices testés et livrés via les pipelines CI/CD.
Initialement les flux d’informations étaient principalement internes avec des échanges entre services cloisonnés au sein des datacenters. Par exemple, la transmission des données sur les commandes à expédier par le département des achats vers la logistique. Mais l’exigence d’échange rapide d’informations entre des utilisateurs et des entreprises avec un même référentiel a forcé l’ouverture des APIs vers l’extérieur. Ainsi, les commerciaux suivent leurs opérations au travers de leurs smartphones avec des applications Saas telle que Salesforce, connectées aux points d’accès des données internes de l’entreprise. Et si besoin d’une nouvelle donnée à afficher, il suffit de la rajouter dans l’Endpoint ‘GET’ existant de l’API et de livrer dans la journée.
Finalement, nous sommes capables de faire évoluer nos SI plus rapidement afin de répondre aux attentes du marché toujours en changement. Le code est testé de manière approfondie et si jamais une correction en production est nécessaire, elle est déployée par les DevOps en totale autonomie.
Reste-t-il un avantage de l’époque où la livraison avait lieu une fois par semaine le mardi ?
L’importance de la connaissance des données exposées
Le premier point est sûrement que les architectes avaient une complète visibilité des données exposées et circulant dans le SI.
Les équipes de développement Agile sont aujourd’hui compétentes pour rajouter des données dans les APIs à la demande des « Product Owners ». Et sans forcément passer par l’extrême des API Shadow IT (qui seront développées à l’insu des architectes référents), il n’est pas toujours question de soumettre le nouveau modèle de donnée à validation.
Avec le temps une API exposera une quantité de données trop importante par rapport à la demande initiale. En effet, que ce soit pour répondre à une demande de nouvelle fonctionnalité ou la correction d’un bug en production, l’API drift est une réalité difficile à maitriser.
De même, les APIs sont de plus en plus nombreuses et il est trop difficile d’avoir une visibilité sur les APIs réellement utilisées et celles qu’on aura oublié de décommissionner, les API Zombies.
En 2022, les APIs seront le vecteur d’attaque numéro 1 selon le Gartner
Les attaquants utilisent ce manque de visibilité pour aller découvrir à votre place les APIs oubliées et s’en servir afin d’exfiltrer des données de votre SI. De même, une application Shadow IT sera évidemment moins sécurisée et une cible facile pour atteindre des données à caractères critiques ou soumises à la RGPD.
Le rapport ‘State of API Security Report’ de Salt Security du Q3 2021 a montré que 94% des organisations ayant répondu ont connu un incident de sécurité au cours des 12 derniers mois.
Différentes causes en sont à l’origine dont le manque de visibilité. Nos deux partenaires technologiques sur la sécurisation des API annoncent une découverte de plus de 30% d’API non cataloguées lors des différents « Proof of Value » réalisés chez nos clients.
Les autres causes sont liées à l’application dans les organisations du Secure design, la documentation, ou encore le testing en continu. Ces points seront abordés lors d’un prochain article.
Tristan Aurisset – Cybersecurituy ¨Presales Engineer CS NOVIDYS
