Jérôme Pouponnot
Les écosystèmes financiers modernes sont largement construits à partir d’API financières qui permettent un partage aisé des données. Bien que la majorité des organisations partent du principe que la sécurité des API est intégrée par le programmeur dans le code qui utilise l’API, la sécurité des API nécessite plusieurs couches pour être efficace. Une Tribune par Alexandre Cogné, Expert Cyber chez Ping Identity.
L’adoption d’outils de technologie financière, ou fintech, n’a jamais été aussi forte que de nos jours. Les consommateurs s’attendent aujourd’hui à un accès numérique facile à leurs ressources financières – ils veulent pouvoir transférer de l’argent, vérifier l’état d’un dossier d’assurance et gérer leurs investissements en ligne. 93 % des consommateurs déclarent avoir constaté des avantages réels de leurs applications fintech en 2022, soit une augmentation par rapport aux 90 % par rapport à 2021. Les institutions financières sont alors extrêmement motivées à proposer des dispositifs internes, ainsi qu’à se connecter à des solutions tierces, afin d’attirer et de fidéliser les clients.
Le rôle des API dans les écosystèmes financiers
Il est alors important de comprendre comment ces écosystèmes sont construits. Les connexions entre les partenaires de l’écosystème sont généralement mises en place par le biais d’API financières, permettant un partage aisé des données. Avec l’essor de ces écosystèmes financiers, les institutions financières donnent la priorité au développement des API : le pourcentage de banques et de coopératives de crédit qui ont investi dans des API ou les ont développées est passé de 35 % en 2019 à 47 % en 2021. Les API sont omniprésentes et se trouvent au cœur des services financiers numériques modernes. Malheureusement, la protection de ces API n’est pas aussi simple qu’il n’y paraît. Il est facile de mettre en place un endpoint API, mais il est beaucoup plus difficile de garantir sa sécurité. La plupart des organisations partent du principe que la sécurité des API est intégrée par le programmeur dans le code qui utilise l’API, alors que les programmeurs sont bien plus concentrés sur la sortie rapide du code et ont tendance à croire que le fournisseur du logiciel de passerelle API est responsable de la sécurité. Ce fournisseur, à son tour, peut ne fournir que les protections les plus élémentaires en supposant que l’équipe de sécurité du client final prendra le relais. Il en résulte des connexions faciles à exploiter, et ces problèmes ne sont qu’exacerbés par les processus de développement rapide tels que la méthode Agile. Les cyberattaquants sont bien conscients de la confusion qui règne autour de la sécurité des API et cherchent à exploiter ces vulnérabilités. C’est l’un des facteurs qui contribuent au haut pourcentage de brèches impliquant des partenaires de la supply chain. Le fait est que la sécurité des API financières nécessite plusieurs couches pour être réellement efficace.
Les bases de la sécurité des API
Les connexions API sont classées en deux catégories : exposées et non exposées. Les API exposées sont ouvertes au public et permettent à tout tiers d’accéder facilement à la logique de l’entreprise via une interface. Naturellement, même avec une API exposée, l’entreprise peut contrôler ce qu’elle montre et à qui, mais ce type d’API accélère considérablement les connexions avec les tiers qui constituent la chaîne d’approvisionnement. En revanche, une API non exposée est une connexion point-to-point entre deux parties spécifiques. Bien que cela semble intrinsèquement plus sûr à première vue, cela rend la croissance de l’écosystème plus difficile, et les problèmes de sécurité qui peuvent survenir ne sont pas vraiment différents.
Dans les deux cas, l’API dispose d’un certificat qui chiffre le flux, et l’organisation et le partenaire de confiance en question partagent un code secret, que toute personne interagissant avec l’API doit connaître pour pouvoir interagir avec elle. Malheureusement, tout comme un mot de passe ou toute autre question d’authentification basée sur la connaissance, un secret peut être piraté. Ce qui rend ce niveau de base de sécurité de l’API inadéquat est le fait que l’organisation n’a généralement aucun contrôle sur les protocoles de sécurité du tiers et de toutes ses entités connectées. Une brèche chez un tiers peut conduire à l’exploitation d’une API dans n’importe quelle organisation connectée. Malheureusement, étant donné la nature de la chaîne d’approvisionnement financière, fonctionner sans connexions API n’est pas une option. Au lieu de cela, les organisations doivent aller au-delà de la protection de base offerte par le chiffrement des canaux et les sécurités collectives pour se protéger des risques de la supply chain.
Les passerelles API
Les passerelles API constituent le niveau de protection suivant pour les API d’une institution financière, rendant plus difficile le passage d’un pirate informatique – bien que la protection qu’elles offrent soit encore incomplète. Pourquoi ? Les passerelles font plusieurs choses utiles, en fournissant une fonction de gouvernance qui sert de courtier pour les connexions entre les entités et agit comme un point central qui achemine les demandes d’API, regroupe les réponses aux API et applique les accords de niveau de service. Une passerelle fournit des fonctions d’authentification et d’autorisation, contrôle le trafic, arrête les attaques par déni de service et ajoute des fonctions de télémétrie et d’analyse, aidant ainsi les organisations à mieux comprendre comment les API sont utilisées. Cependant, les passerelles API ne contrôlent pas toutes les données transmises entre les endpoints, ce qui est essentiel pour protéger pleinement l’API.
L’importance des données
Supposons qu’un pirate ait infiltré un de vos partenaires et a eu accès au secret partagé. Maintenant, ce cybercriminel peut s’authentifier dans la passerelle API de la banque en tant qu’utilisateur apparemment autorisé. Cela peut conduire à la divulgation indésirable d’informations, à la prise de contrôle de comptes, voire à la possibilité de modifier ou de supprimer des informations que la banque n’a jamais eu l’intention de partager. Le pirate peut également essayer d’injecter un code ou des commandes malveillantes dans l’API en les dissimulant dans le contenu de confiance ou attendu. Ce sont là quelques-uns des types d’attaque les plus courants lorsqu’un maillon faible de la chaîne d’approvisionnement est utilisé pour violer une institution financière,
Si les seuls contrôles en place sont le secret partagé et la passerelle API, ces types d’attaques peuvent passer inaperçues sur le moment. Si la banque s’aperçoit plus tard que ce type d’attaque s’est produit en analysant les informations provenant des données analytiques fournies par la passerelle, le mal aura déjà été fait. Afin de répondre à ces menaces en temps réel, l’organisation a besoin d’une solution de sécurité API qui examine les données passant entre les terminaux, identifie les anomalies en temps réel, alerte l’équipe de sécurité appropriée et prend des mesures immédiates.
Sur le même sujet :
Tribune : 3 priorités pour les chaînes d’approvisionnement dans le secteur des biens de consommation
Tribune : les 5 commandements pour une bonne gestion des retours
Tribune – Edge Computing, 4 approches qui transforment le secteur du retail
