Business

Les API internes, parents pauvres de la cybersécurité ?


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 trigger leur utilisation. Mais à y regarder de plus près, de quels varieties 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 native 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 companies avec d’autres produits et companies sans avoir à connaître les détails de leur mise en œuvre. Elles simplifient le développement d’functions, 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 functions internes à l’entreprise avec des functions 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 à utilization é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 shares – 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, web est une armurerie à ciel ouvert où les cybercriminels peuvent faire leurs programs. 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 hundreds of thousands 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 most important sur un système, va le surcharger de requêtes pour que celui-ci tombe. C’est typiquement le style d’attaques pratiquées en ce second avec le conflit russo-ukrainien.

Mais il faut aussi prendre en compte les préjudices légaux qui peuvent aussi faire monter la word. Parmi des exemples récents, on peut citer le cas de l’éditeur Dedalus Biologie qui a écopé d’une amende de 1,5 hundreds of thousands 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 cost 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’data.

Solution de area of interest 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 easy : 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 locations 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 functions et API qui vont fonctionner durant cette période. Ainsi, si la période d’audit n’est pas assez longue, il est attainable de ne pas identifier les API qui ne se seraient pas mises en motion. 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 manufacturing de fiches de paye (1 fois par mois) …

Une fois cela identifié, l’entreprise va devoir dans un premier temps décider si elle preserve 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 easy (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 path informatique de l’entreprise. Ainsi, on observe que chaque service dispose de ses propres API internes, reposant sur ses propres requirements, 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 section de développement, 10 centimes si elle est sécurisée lors de la section de take a look at et 100 € quand l’API est passée en manufacturing.

Une responsabilité à unifier, la dernière pierre ?

Au-delà du développement, le level 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 companies : la manufacturing, l’éolien, la distribution et la gestion des abonnements. Chacun de ces 4 companies 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’data. Finalement, personne dans l’entreprise n’a de imaginative and prescient générale et globale des API en motion 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 companies 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 automotive celles-ci vont faire appel à un nombre de companies de plus en plus giant, 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.





Source hyperlink

Leave a Reply

Your email address will not be published.