Depuis 10 ans, les entreprises ont adopté en masse le principe des API pour faciliter l’intégration avec leur écosystème externe. Face à cet engouement et cette facilité de mise en place, elles ont décidé d’utiliser cette technologie à des fins internes. Mais cela s’est-il fait au détriment de la sécurité ?
En mars dernier, Salt Security présentait un rapport alarmant sur la cybersécurité en pointant du doigt les API. En effet, d’après cette étude, au cours des 12 derniers mois, les attaques contre les API ont augmenté de 681% et sur la même période, un incident impliquant une API est survenu chez 95% des entreprises interrogées. De quoi remettre clairement en cause leur utilisation. Mais à y regarder de plus près, de quels types d’API parlons-nous ? De quelles failles ?
Une brève histoire des API
Les interfaces de programmation sont apparues à l'aube de l'informatique, avant même les ordinateurs personnels. À cette époque, elles étaient surtout utilisées en tant que bibliothèques pour les systèmes d'exploitation. Elles résidaient presque toutes en local sur les systèmes sur lesquels elles s'exécutaient, même si elles transféraient parfois des messages entre les mainframes. Presque 30 ans après, les API sont sorties de leurs environnements locaux. Au début des années 2010, elles sont devenues importantes pour l'intégration des données à distance.
Dans le cadre d’une transformation numérique avec des délais de plus en plus urgents, les API permettent aux entreprises de faire communiquer leurs produits ou services avec d'autres produits et services sans avoir à connaître les détails de leur mise en œuvre. Elles simplifient le développement d'applications, font ainsi gagner du temps et de l'argent et réduisent drastiquement les temps d’intégration.
Bien évidemment, comme ces interfaces ont comme mission de faire communiquer des applications internes à l’entreprise avec des applications externes, les développeurs et autre RSSI ou DSI ont sécurisé ces systèmes afin d’éviter de créer des failles.
Fort du succès de ces API externes, les entreprises ont rapidement vu dans les API un intérêt à usage également purement interne. Ainsi, de multiples API se sont développées pour permettre, par exemple, à un logiciel de ventes de pouvoir communiquer avec un logiciel de stocks – pour savoir ce qu’il y a à vendre -, à un logiciel de gestion RH qui va échanger avec un logiciel de comptabilité pour générer les fiches de paye-, à un logiciel de facturation....
Mais comme ces API sont à usages internes, chaque service a développé dans son coin ses propres interfaces et comme le risque était minime, leur sécurisation n’a été que très peu prise en compte. Et pourtant...
De vrais risques de failles exploités par les pirates
Pourtant, aujourd’hui, internet est une armurerie à ciel ouvert où les cybercriminels peuvent faire leurs courses. Par exemple, un logiciel « sniffer » se trouve très facilement et gratuitement. Avec cet outil, le malfrat n’a qu’un mail à envoyer à des collaborateurs d’une entreprise pour que l’un d’entre eux l’ouvre, donnant ainsi accès à celui-ci au réseau interne de l’entreprise et donc aux API internes non sécurisées. Il sera alors aisé pour le cybercriminel de pouvoir accomplir le forfait qu’il souhaite.
Et les dégâts qu’il peut faire sont énormes, ils peuvent se chiffrer en millions d’euros, et toutes les entreprises sont concernées quel que soit le secteur d’activité ou quelle que soit la taille de l’organisation.
Le vol de données ou l’espionnage industriel, par exemple, sont des dégâts bien connus. Tout comme l’est le déni de service où le pirate, après avoir pris la main sur un système, va le surcharger de requêtes pour que celui-ci tombe. C’est typiquement le genre d’attaques pratiquées en ce moment avec le conflit russo-ukrainien.
Mais il faut aussi prendre en compte les préjudices légaux qui peuvent aussi faire monter la note. Parmi des exemples récents, on peut citer le cas de l’éditeur Dedalus Biologie qui a écopé d’une amende de 1,5 millions d’euros pour des défauts de sécurité ayant entraîné la fuite de données médicales de près de 500 000 personnes.
Pour comprendre les failles des API internes, il faut comprendre qu’aujourd’hui tout projet informatique qui se lance dans une entreprise est construit sur la base des API. Et si c’est un projet interne, le développeur réalise l’interface le plus souvent sans en prévenir le service en charge de la sécurité.
L’audit API de sécurité, première pierre
La première des démarches de l’entreprise doit donc être de répertorier de façon exhaustive toutes les API au sein de son système d’information.
Solution de niche il y a encore 4 ou 5 ans, l’audit API s’est fortement démocratisé depuis 2 ou 3 ans surtout avec les changements majeurs qui ont suivi l’épidémie de COVID et l’essor du e-commerce qu’elle a provoqué. Le principe de cette pratique est très simple : l’entreprise va déployer sur le réseau des sniffers qui font observer le trafic. Ainsi, ces systèmes vont identifier clairement qui consomme quelle ressource informatique. Pour ce faire, l’entreprise va également utiliser un sniffer qui va identifier toutes les requêtes réseau et les destinations de ces dernières et ainsi fournir une liste d’URI (adresse URL pour les APIs).
Il faut savoir qu’aujourd’hui, dans 100% des audits réalisés de cette façon, on découvre des API non identifiées et non répertoriées, qui sont autant de portes ouvertes offertes aux hackers qui sauraient les trouver.
Pour qu’il soit efficace, cet audit de sécurité doit répondre à différents critères. D’abord, il doit être réalisé sur une période assez longue. En effet, cette procédure va permettre d’observer le fonctionnement du réseau de l’entreprise et répertorier toutes les applications et API qui vont fonctionner durant cette période. Ainsi, si la période d’audit n’est pas assez longue, il est possible de ne pas identifier les API qui ne se seraient pas mises en action. Et cet audit doit être reproduit fréquemment. En effet, certaines API internes ont des fonctionnements cycliques comme la gestion des inventaires (1 fois par an), la production de fiches de paye (1 fois par mois) ...
Une fois cela identifié, l’entreprise va devoir dans un premier temps décider si elle conserve une interface, si elle doit la sécuriser, si elle la supprime ou si elle en réduit l’accès. Ensuite, l’équipe de gouvernance API va devoir définir des niveaux de sécurité en fonction des risques, allant du plus simple (mot de passe et identifiant) au plus complexe comme le OAuth2, en passant par un niveau intermédiaire qui permet de générer des mots de passe temporaires pour les propriétaires des APIs.
Le développement responsable, deuxième pierre
Comme indiqué plus haut, une des raisons de ces failles dans les API internes tient dans le fait que ces dernières sont généralement développées par le service informatique de la ligne métier qui va agir en silos et sans concertation avec la direction informatique de l’entreprise. Ainsi, on observe que chaque service dispose de ses propres API internes, reposant sur ses propres standards, indépendamment des autres interfaces utilisées dans l’entreprise.
Il va donc être nécessaire pour l’entreprise de développer ses APIs en prenant en compte dès leur conception la notion de sécurité. Dans l’informatique, il est coutume de rappeler que sécuriser une API coûte 1 centime d’euros dans sa phase de développement, 10 centimes si elle est sécurisée lors de la phase de test et 100 € quand l’API est passée en production.
Une responsabilité à unifier, la dernière pierre ?
Au-delà du développement, le point qui rend la gestion de la sécurité des API internes difficile est l’éparpillement de la responsabilité et des acteurs. Qui pilote et surveille l’ensemble de manière transverse ? Si l’on prend l’exemple d’une grande entreprise du secteur de l’énergie, elle est structurée en 4 grands services : la production, l’éolien, la distribution et la gestion des abonnements. Chacun de ces 4 services fonctionne de façon indépendante et développe donc ses propres API en fonction de ses besoins et de son propre système d’information. Finalement, personne dans l’entreprise n’a de vision générale et globale des API en action dans l’entreprise.
Afin de créer un catalogue exhaustif, il s’agit de définir qui sera la bonne ou les bonnes personnes qui auront cette mission de gouvernance et de coordination. La plupart du temps, la bonne pratique consiste à créer un comité de gouvernance comportant des représentants des différents services et le doter d’un outil de gestion des API.
La vulnérabilité des API ne concerne pas que l’externe : auditez vos API internes !
Aujourd’hui, toutes les entreprises, sans distinction de taille ou de secteur, sont concernées par ces attaques sur les API internes. La sécurisation des API relève de la stratégie même de l’entreprise car celles-ci vont faire appel à un nombre de services de plus en plus large, tant en interne qu’en externe. Plus les entreprises opèrent une mutation numérique et se dirigent vers un modèle de plateforme, plus elles vont avoir besoin de se reposer sur une sécurisation opérationnelle et efficace. Et cela ne peut se faire qu’après avoir identifié exhaustivement les API utilisées dans l’entreprise, les avoir sécurisées dès leur création et de mettre en place un dispositif de gouvernance.