Cinq domaines dans lesquels une meilleure protection des API renforce la sécurité des services financiers

Joshua Goldfarb

La sécurité des API est aujourd’hui un sujet brûlant, et à juste titre. À bien y réfléchir, la plupart des acteurs des services financiers s’apparentent désormais davantage à des entreprises technologiques. Ils sont constamment poussés à innover afin de suivre le rythme des FinTechs, qui placent toujours plus haut la barre pour répondre aux attentes numériques des clients, voire à nouer des partenariats avec elles. L’évolution de l’écosystème des services financiers qui en résulte, intégrant les FinTechs par le biais d’API, a fortement contribué à l’essor de la finance ouverte. Les établissements de services financiers dépendent donc plus que jamais des API pour assurer le fonctionnement de leurs activités.

Sans surprise, à mesure que les banques ont pris conscience de l’importance des API, les attaquants en ont fait autant. Les API essentielles à l’activité sont constamment prises pour cible par des attaquants, qui savent qu’ils peuvent tirer profit ou bénéficier d’une autre manière de leur exploitation abusive et/ou de leur compromission. Parallèlement, la surface d’attaque s’est considérablement étendue ces dernières années. Cela s’explique en grande partie par la complexité croissante des environnements hybrides et multicloud, ainsi que par les difficultés accrues liées à leur gestion, qui se sont généralisées dans le secteur. Tout cela entraîne d’importantes répercussions sur les entreprises, notamment des violations de données à grande échelle, des problèmes de conformité et des amendes réglementaires.

Bien sûr, les nouvelles ne sont pas toutes mauvaises. En collaborant avec un partenaire de confiance, les organismes de services financiers peuvent mieux se protéger contre les menaces qui pèsent sur leurs API. Examinons cinq domaines dans lesquels le bon partenaire de confiance peut contribuer à renforcer la sécurité des API.

1. Développement : Les équipes de développement sont confrontées à un défi de taille. D’un côté, elles doivent respecter des délais stricts pour développer les fonctionnalités requises et les rendre opérationnelles. De l’autre, elles développent des API conformément aux exigences définies par l’équipe de sécurité. Pourtant, il n’existe aucun véritable moyen d’imposer ces exigences ni d’en vérifier le respect. Certes, le code peut faire l’objet d’audits et de revues, mais ce processus fastidieux et chronophage est sujet aux erreurs humaines et aux oublis. Il est également le plus souvent relégué au second plan au profit d’autres priorités urgentes. Dans la plupart des entreprises, les développeurs sont généralement bien plus nombreux que les professionnels de la sécurité, ce qui pose un problème de passage à l’échelle. Par conséquent, des bogues, des oublis et des vulnérabilités échappent au processus de développement et se retrouvent dans les API en production. Seule l’automatisation permet d’adapter les contrôles de sécurité à grande échelle, sans que l’équipe de sécurité ne devienne un obstacle ni ne ralentisse le rythme imposé par les besoins de l’entreprise. Il est préférable de faire appel à un partenaire de confiance pour appliquer automatiquement les schémas, les normes et les politiques.
2. Contrôle des accès : Croyez-le ou non, contrôler qui a accès à quelles API reste un défi. Au vu de la complexité des entreprises modernes, cela n’est peut-être pas si difficile à croire. La plupart des entreprises font appel à au moins deux fournisseurs de services cloud, tout en disposant d’environnements sur site et/ou de centres de données. En règle générale, plusieurs équipes sont nécessaires pour gérer les infrastructures réseau, technologiques, de développement et de sécurité sur chacun de ces sites disparates. Il n’est donc pas surprenant que le contrôle (et la surveillance) des accès aux API soit devenu un défi majeur. En effet, quatre des 10 principaux risques de sécurité des API de l’OWASP en 2023 concernent l’authentification ou l’autorisation. Un prestataire de confiance adapté peut contribuer à simplifier cette complexité et à soulager les équipes débordées. L’entreprise peut ainsi se concentrer pleinement sur l’exploitation, la maintenance et la sécurisation de ces environnements, notamment en assurant un contrôle approprié des accès.
3. API non autorisées : Il arrive que les processus officiels prennent du temps et que les développeurs mettent en place de nouvelles infrastructures et de nouveaux points de terminaison afin de respecter une échéance de développement. Il se peut aussi que certaines infrastructures et certains points de terminaison soient passés entre les mailles du filet et n’aient jamais été correctement inventoriés, gérés, surveillés et sécurisés. Quelle qu’en soit la raison, des API non autorisées existent bel et bien. Lorsqu’une API n’est pas connue, elle ne peut pas être inventoriée, gérée, surveillée ni sécurisée. Un partenaire fiable aidera l’entreprise non seulement à détecter les API inconnues, mais aussi à les sécuriser.
4. Le WAF ne suffit pas : Il ne fait aucun doute que les pare-feu d’applications web (WAF) constituent un élément essentiel d’une architecture de sécurité. Les WAF offrent une protection importante contre une grande variété de menaces. Toutefois, ils n’ont jamais été conçus pour bloquer tous les types d’attaques auxquelles les API sont quotidiennement confrontées. En outre, les API évoluent rapidement, ce qui fait apparaître de toutes nouvelles catégories de vulnérabilités susceptibles d’échapper aux contrôles de sécurité. L’offre d’un partenaire de confiance ne saurait être complète sans proposer, en complément du WAF et intégrées au WAF, des fonctionnalités avancées permettant d’identifier et d’atténuer les vulnérabilités des API.
5. Attaques sophistiquées : L’époque où les applications étaient la cible d’attaques courantes et connues est révolue. Les cyberattaquants chevronnés lancent des attaques sophistiquées, conçues notamment pour passer inaperçues afin de mettre au jour des processus métier sensibles, d’extraire des données, de commettre des fraudes, de rendre des applications indisponibles et de nuire à la réputation des entreprises. Il peut s’agir aussi bien d’attaques manuelles que d’attaques automatisées (par des bots). L’identification, la détection et l’atténuation de ces types d’attaques sophistiquées nécessitent un savoir-faire spécialisé. Toute offre de sécurité des API proposée par un partenaire de confiance doit inclure une protection contre les attaques les plus sophistiquées.

Bien entendu, cette liste n’est pas exhaustive. Chaque organisme de services financiers doit examiner son registre des risques afin de déterminer quels risques et quelles menaces sont susceptibles d’avoir le plus fort impact sur son activité. Ceux dont l’impact potentiel est le plus grave peuvent être traités en priorité. Il convient toutefois de noter que de nombreux dirigeants ne savent pas toujours comment évaluer au mieux l’ampleur réelle des risques liés à la sécurité des API. Il est donc d’autant plus important de collaborer avec le bon partenaire. Idéalement, les risques liés à la sécurité des API doivent figurer en bonne place sur la liste, ce qui en fait un enjeu prioritaire méritant des investissements. Cela implique notamment de travailler avec un partenaire adapté, qui comprend l’importance de la sécurité des API et propose les solutions adéquates.

Pour en savoir plus, veuillez consulter « Cybersécurité pour les banques et les services financiers ».

À propos de l’auteur

Joshua Goldfarb

Autres articles de Joshua Goldfarb