Gestion des API : le difficile équilibre entre fiabilité et sécurité
Une fois l’API déployée, il appartient à son développeur d’en assurer la mise à jour et la sécurité. Un véritable défi quand les applications d’entreprise dépendent de plus en plus de ces interfaces.
La sécurisation des API est un sous-domaine des bonnes pratiques de développement. En principe, les organisations mettent en place de nombreux processus pour minimiser les erreurs de code entraînant d’éventuelles vulnérabilités. Les équipes les plus alertes déploient un pipeline automatisé. Celui-ci doit permettre de résoudre rapidement les questions de sécurité des API. Mais compte tenu du rythme de développement (qui inclut le développement et la modification du code accessible par le biais des API publiées), du code non sécurisé risque néanmoins de se glisser dans les systèmes en production.
En avril 2022, Dynatrace a demandé à Coleman Parkes de mener une enquête mondiale auprès de 1 300 responsables de la sécurité des systèmes d’information (RSSI) dans de grandes entreprises de plus de 1 000 employés. Cette étude a révélé les risques courus par les entreprises en matière de développement et de déploiement de code. En effet, deux tiers (67 %) des RSSI estiment que les développeurs n’ont pas toujours le temps de rechercher les vulnérabilités dans leur code et de les résoudre avant le passage en production. Seuls 27 % des RSSI interrogés sont sûrs que les applications ont été intégralement testées avant leur mise en production.
« Il existe toujours un risque que des vulnérabilités échappent aux équipes de sécurité, quels que soient les niveaux de défense en place », réagit Bernd Greifeneder, Chief Technology Officer chez Dynatrace. « Les nouvelles applications, tout comme les logiciels déjà existants et stables, sont sujettes à des vulnérabilités qui sont détectées de manière plus fiable en production. »
« Breaking change » : un véritable enjeu pour les développeurs
« Il existe toujours un risque que des vulnérabilités échappent aux équipes de sécurité, quels que soient les niveaux de défense en place. »
Bernd GreifenederCTO, Dynatrace
Les vulnérabilités doivent être corrigées au plus vite, mais les développeurs doivent aussi mettre leur code à jour pour répondre aux nouvelles exigences de l’entreprise. Une difficulté demeure néanmoins : à mesure qu’évolue la fonctionnalité à laquelle on accède par le biais de l’API, il faudra peut-être aussi modifier l’API elle-même, car les données qu’elle exige (les paramètres qu’un programmeur doit lui fournir) et les données qu’elle renvoie à l’application qui y accède risquent de devoir être adaptées à la nouvelle fonctionnalité.
Or tout changement d’une API est susceptible de nuire au fonctionnement des applications – et donc aux processus métier – qui en dépendent.
Les équipes de développement ne pensent pas souvent à assurer la rétrocompatibilité des API, souligne Stephen Feloney, vice-président des produits, tests continus chez Perforce. « Une API risque de ne plus fonctionner dans une application mise à jour ».
À chaque nouvelle version d’une API, l’ajout de paramètres supplémentaires s’avère généralement nécessaire. Les résultats sont d’être livrés dans différents formats, et même lorsque les développeurs assurent la rétrocompatibilité, les anciennes API continueront peut-être à fonctionner, mais sur une période limitée, explique Stephen Feloney. « Les équipes qui consomment les API ne prennent pas conscience des nouveaux changements apportés à l’API jusqu’à ce qu’une panne soudaine survienne », ajoute-t-il.
Si cela se produit, remarque Stephen Feloney, les équipes de développement doivent remonter jusqu’à la source pour trouver la cause profonde du problème et vérifier que la documentation est à jour. Cela risque de prendre du temps et s’avérer coûteux. Il en va de même lors de la mise à jour d’un composant sur lequel s’appuie l’API. Les équipes peuvent éviter les pannes d’API inattendues, à condition de suivre les dépendances du code et les modifications des API, rappelle Stephen Felony.
Appliquer l’approche DevSecOps au développement d’API
Les enjeux sécurité devraient être pris en compte dès le processus de développement des API et tout au long de leur consommation par des applications. Qu’ils soient producteurs ou consommateurs de ces interfaces, les développeurs doivent se demander : « le code est-il protégé ? L’API est-elle sûre ? Peut-elle servir de porte dérobée aux pirates pour accéder aux systèmes de l’entreprise ? »
Selon l’étude mondiale menée par Dynatrace auprès de 1 300 RSSI, plus d’un tiers (34 %) des entreprises ont déjà opté pour une approche DevSecOps consistant, pour la majorité des équipes, à intégrer les pratiques de sécurité tout au long du cycle de développement des logiciels.
Partant d’un flux simple à trois étapes (programmation-compilation-déploiement), Alejandro Bernal, architecte de la sécurité et membre du groupe de travail sur les tendances émergentes de l’ISACA, explique que le modèle DevSecOps est principalement associé à l’étape de programmation. Or, chaque étape présente des défis particuliers. Au niveau de la gestion du code source par exemple, Bernal précise que les développeurs doivent déjà s’interroger : « Connaissons-nous le nombre de vulnérabilités que comporte notre référentiel source ? Pouvons-nous tracer chacune d’entre elles jusqu’à son package source ? Comment les contrôler/surveiller ? »
Telles sont quelques-unes des questions à se poser au moment d’écrire du code.
C’est là qu’interviennent les tests statiques de sécurité des applications.
La phase suivante (le développement) oblige les développeurs à intégrer des composants ou artefacts provenant de référentiels de codes externes. Au regard des pratiques modernes induites par le cloud, cela sous-entend généralement la conteneurisation de ces artefacts. Selon Alejandro Bernal, les développeurs doivent veiller à ce que la sécurité associée à ces artefacts de code respecte les mêmes critères que ceux définis pour le code développé en interne.
« Si on décide d’accepter les risques (par exemple, un package qui, malgré l’absence de correctifs, est indispensable au fonctionnement de l’application) ou si on a résolu toutes les vulnérabilités, l’artefact doit conserver le même niveau de sécurité, poursuit-il. Y a-t-il un moyen de savoir si une erreur s’est infiltrée jusqu’à l’image du conteneur ? »
Quelle que soit l’architecture logicielle utilisée, la phase finale (le déploiement) fait intervenir ce qu’Alejandro Bernal décrit comme une « chaîne d’outils appropriée » en phase avec cette architecture.
Les risques qui pèsent sur la sécurité des API augmentent
À l’occasion d’une étude menée auprès de 350 de ses clients, Salt Security a découvert que le nombre moyen d’API par client avait augmenté de 82 % en un an, passant de 89 en juillet 2021 à 162 en juillet 2022. Au cours de la même période, le trafic total d’API par client a augmenté de 168 %, dénotant ainsi l’explosion de leur usage.
Plus inquiétant : les attaques ont suivi le rythme de croissance spectaculaire de l’utilisation des API, et parasitent désormais 2,1 % du trafic total des API des clients de Salt Security. Cette enquête a également révélé une augmentation de 117 % des attaques ciblant les API sur l’année écoulée : de 12,22 millions d’appels frauduleux mensuels, on est passés à 26,46 millions.
Plus de la moitié (54 %) des participants à cette étude déclarent avoir retardé le déploiement d’une nouvelle application en raison de problèmes de sécurité liés aux API. Toujours plus nombreuses, les obligations réglementaires visant à éviter les fuites de données finissent par nuire à la rentabilité, et le public en prend acte. En fait, près d’un tiers des sondés reconnaissent avoir subi une fuite de données sensibles ou une atteinte à la vie privée sur leurs interfaces en production, soit une hausse de 19 % en un an.
« Aujourd’hui, de nombreuses attaques d’API sont menées par des entités authentifiées qui ont le droit d’utiliser l’API ciblée et font tout pour passer inaperçues. »
Nick RagoCTO, Salt Security
« Aujourd’hui, de nombreuses attaques d’API sont menées par des entités authentifiées qui ont le droit d’utiliser l’API ciblée et font tout pour passer inaperçues de manière à échapper aux limites de débit imposées par les contrôles du trafic », analyse Nick Rago, CTO chez Salt Security.
Selon Nick Rago, les mécanismes de sécurité utilisés par les passerelles API, les pare-feu d’applications web et les services d’identité ne suffisent pas à se protéger contre une surface d’attaque aussi étendue. « Pour arrêter les attaques, les entreprises doivent élaborer une stratégie de sécurité spécialement conçue pour les API », conseille-t-il.
Une stratégie de sécurité bien conçue devrait permettre de surveiller la surface d’attaque en continu, de découvrir les API nouvellement créées ou modifiées, de comprendre le comportement des API en contexte de manière à détecter et à arrêter au plus vite les attaques et l’utilisation abusive des ressources, puis de résoudre les vulnérabilités dans la phase de développement.
Brian Otten, vice-président chargé de la promotion de la transformation numérique chez Axway, estime également que les entreprises doivent gérer le cycle de vie de leurs API. « La fourniture d’API implique un cycle de vie distinct qui inclut, mais sans s’y limiter, une surveillance unifiée des API sur les plans de la sécurité, de la disponibilité et de la performance », précise-t-il. « Il faut aussi être capable de cataloguer et de gérer les API au quotidien, parallèlement aux contrôles liés aux normes, à la gouvernance et aux tests. »
