Concevoir un environnement bancaire ouvert sécurisé
This post is also available in:
Anglais 
Allemand 
Italien 
Portugais - du Brésil 
Espagnol 
Russe
Nous sommes nombreux à utiliser des solutions innovantes comme Mint, Chime ou Venmo sans nous douter qu’elles reposent sur des API d’Open Banking.
L’initiative Open Banking découle principalement de la deuxième Directive européenne sur les services de paiements (DSP2) visant à ouvrir les données fermées et propriétaires des clients des banques de dépôt à des fournisseurs tiers (TPP) de manière sécurisée par le biais d’API grand public, dans l’objectif de stimuler l’innovation et d’accroître la concurrence. Contrairement au système bancaire traditionnel, dans lequel toutes les données des clients sont sous le contrôle de la maison mère, un système bancaire ouvert les expose de façon sécurisée aux TPP via des API, mais uniquement si le client a donné son accord. Gartner prévoit que d’ici 2022, les interfaces de programmation d’applications (API) deviendront le vecteur d’attaque le plus fréquent, entraînant des violations de données pour les applications web d’entreprise. La sécurité passe par une couverture des menaces, une intégration facile et une visibilité complète pour les API documentées et non documentées.
Selon une étude Celent de 2018, le nombre d’institutions financières (IF) américaines disposant de portails bancaires ouverts facilitant l’accès des PPT aux données financières et autres des consommateurs devrait progresser de 20 à plus de 200 d’ici la fin 2021. Au premier trimestre de 2020, plus de 300 PPT étaient enregistrés au Royaume-Uni. D’autres pays, comme l’Inde et l’Australie, ont suivi l’approche de l’UE et disposent d’un écosystème bancaire ouvert florissant.
API d’Open banking – Qu’est-ce qui pourrait mal tourner ?
Avant la mise en place de l’Open Banking, de nombreux acteurs FinTech innovants utilisaient la capture de données d’écran pour accéder aux données des clients, notamment leurs informations d’identification, à l’insu de la maison mère. Les API d’Open Banking cherchent à rationaliser les implications juridiques du partage d’identifiants et d’informations clients par le biais des API, du consentement et de l’autorité réglementaire.
Si les API présentent des avantages considérables, elles peuvent aussi se révéler problématiques sur le plan de la disponibilité et de la sécurité, par exemple :
- Perturbation des services : Services d’API indisponibles en raison d’erreurs de configuration du système de sécurité, du réseau et de l’application, attaques par déni de service sur les API ou pannes de l’application ou de l’infrastructure d’authentification.
- Méfiance : De nombreuses solutions d’Open Banking sont construites sur une infrastructure hybride ou exclusivement cloud. Cependant, la migration vers les clouds publics suscite une méfiance en raison de l’incompatibilité des solutions de sécurité, des difficultés de configuration vu la diversité des environnements, des erreurs de configuration et des aspects liés aux politiques et profils de sécurité des applications.
- Vulnérabilité accrue : Les API sont assez régulièrement la cible d’attaques variées. Une enquête Radware révèle que, au moins une fois par mois, 55 % des entreprises connaissent une attaque DoS sur leurs API, 48 % subissent une forme d’attaque par injection, et 42 % sont victimes d’une manipulation d’éléments/attributs. Les autres attaques portent sur les processus d’authentification et d’autorisation des API, ou sont intégrées, comme l’injection SQL, le cross-site scripting (XSS) et les attaques de bots.
- Attaques de bots sur les API : Les attaques de bots sont des programmes automatisés, scriptés pour s’introduire dans des comptes d’utilisateurs, usurper des identités, commettre des fraudes de paiement, récupérer du contenu, des prix, des coupons ou des données, diffuser des spams ou de la propagande et impacter les activités d’une entreprise.
- Vol de données : De nombreuses API manipulent des PII (Personally Identifiable Information ou informations personnellement identifiables) sensibles. Le caractère sensible et confidentiel des informations se conjugue au manque de visibilité sur le fonctionnement de ces API et des applications tierces pour donner lieu à un véritable casse-tête en cas d’attaque.
- API non documentées mais publiées : Si elles n’ont pas été testées, des API non documentées peuvent divulguer accidentellement des informations sensibles et s’exposer à des manipulations et exploitations de leur vulnérabilité.
Ma passerelle API et mon WAF ne sont-ils pas suffisants ?
Puisque les menaces varient, la sécurisation des API passe par une combinaison de contrôles de sécurité, notamment :
- Des contrôles d’authentification, d’autorisation et de gestion des accès
- Une protection contre les attaques de bots
- La prévention des attaques DDoS et de disponibilité
- Une protection contre les attaques intégrées, les vulnérabilités et les manipulations
- La prévention des fuites de données PII et d’une exposition excessive des données
- La protection contre la fraude et les escroqueries par hameçonnage
La protection DDoS, les WAF et les passerelles sont généralement les principaux dispositifs de sécurité utilisés pour protéger les API. Même si les passerelles API permettent une gestion et une intégration dotées de capacités d’authentification et d’autorisation, leurs capacités de sécurisation et de protection face aux bots et applications web sont limitées ou absentes. La plupart des WAF ne font pas la différence entre les API et les applications web ordinaires. Et même quand c’est le cas, ils n’inspectent pas ou ne détectent pas les véritables risques de sécurité.
[Sur le même thème : 4 questions à se poser à propos de l’Open Banking].
Les bots ne sont pas toujours amicaux ou visibles !
Les API sont également vulnérables aux attaques de bots. Selon Forrester, plus d’un quart des requêtes web proviennent de mauvais bots. Ces bots tentent des attaques automatisées sur les API, par exemple la prise de contrôle de compte, le déni de service, l’utilisation malveillante de données de paiement et le déni d’inventaire. On ne protège pas les API contre les attaques automatisées de la même façon que les applications web et mobiles, tout simplement parce que le comportement des bots, les flux de navigation et les indicateurs sont différents.
La plupart des entreprises n’ayant pas d’outils dédiés à la gestion des bots, elles s’exposent à un risque accru de piratages potentiels via les API, telles que des tentatives de remplissage d’identifiants, de force brute et d’extraction.
Comment sécuriser les API de l’Open Banking ?
La solution Radware est conçue pour sécuriser les API contre les pirates et les attaques par les États. Elle sécurise les API d’applications contre les attaques par déni de service, par applications et par bots, les protège contre les vulnérabilités et les manipulations, et empêche les perturbations de service tout en répondant aux exigences de confiance et de sécurité des clients qui migrent vers un déploiement multi-cloud ou hybride.
Conclusion :
Le système bancaire ouvert n’en est qu’à ses balbutiements, mais connaît un essor fulgurant. Cet environnement ouvre les données des clients à des prestataires tiers via des API pour leur proposer des services innovants. Il en découle toutefois une vulnérabilité accrue face aux incursions malveillantes et frauduleuses, dont il faut se prémunir. Les banques et les fintech actives dans cet environnement se doivent de proposer des solutions sécurisées pour gagner la confiance des clients. Pour en savoir plus sur l’aide que Radware peut vous apporter, visitez le site FrictionlessSecurityAtThePaceofInnovation|Radware
