e-Xpert Solutions Lausanne
Auteur : Youssef
Date de publication : 4 juin 2019 - Dernière mise à jour : 4 juin 2019
PSD2 (Payment Services Directive 2) est une nouvelle directive européenne imposant aux banques de l'Union européenne, d'accorder aux prestataires tiers l'accès aux comptes bancaires des clients (sous réserve d’un accord au préalable).
Pour rappel, l’UE a adopté cette directive début 2018. Ce texte contraint les banques à instaurer un droit d’accès aux comptes bancaires en faveur de tous les autres acteurs financiers. Il n’est cependant pas applicable en Suisse, puisque cette dernière n’est pas membre de l’UE. Toutefois, les banques ayant des succursales en Europe doivent se plier à cette exigence.
De ce fait, le monopole des banques sur les données de leurs clients disparaît peu à peu. Cela permet aux clients des banques, aussi bien professionnels que grand public, d’autoriser des fournisseurs tiers à récupérer ou gérer leurs données bancaires.
Les banques sont contraintes d’autoriser l’accès et la gestion des comptes de leurs clients à des "tiers autorisés" (avec l’accord du client). De cette manière, les entreprises agréées pourront administrer des paiements à votre place, vérifier le solde de votre compte et récupérer vos informations (solde, mouvements, …).
Prenons par exemple Payconiq qui est une application pour smartphones permettant d’effectuer des paiements (y compris les sans contact). Dans le cadre de ces services, elle pourrait potentiellement se connecter au compte du client afin d’initier des paiements.
Toutefois, il est important de garder à l’esprit que votre banque ne pourra jamais communiquer vos informations bancaires sans votre accord explicite au préalable.
L’introduction de PSD2, bouscule les règles du jeu du monde financier européen, il ne s’agit plus d’une évolution mais clairement d’un changement des schémas opérationnels ouvrant la porte à de nombreux acteurs financiers (indépendamment du secteur bancaire) proposant des services financiers de toutes sortes.
Les banques devront mettre une interface d’accès à des sociétés tiers (pour l’accès aux comptes bancaires des clients). Cependant, un tel service pourrait potentiellement être exposé à des risques non négligeables, si une politique de sécurité stricte n’a pas été mise en place.
La corruption d’un tel service (aussi bien le client que la ressource) pourrait générer des dommages considérables :
Autant dire que la corruption de ce service reviendrait à remettre au hacker un chèque en blanc (au montant limité) ainsi qu’un exemplaire de tous vos relevés de compte.
L’open banking, est un concept permettant à des acteurs non-bancaires (les Third Party Providers) d’accéder (manipuler) de manière sûre aux données des comptes bancaires de leurs utilisateurs, via une API fournie par les banques.
Dès lors que de nouveaux acteurs rentrent dans ce processus (schéma opérationnel financier) des questions d’ordre sécuritaire se posent de manière légitime : Comment les APIs mises à disposition par les instituts bancaires doivent-elles être sécurisées contre la fraude et les abus ? Tout en garantissant une bonne expérience utilisateur.
Sur cet aspect, la régulation PSD2 reste neutre sur le plan technologique et ne spécifie pas en détail comment ces APIs devraient être sécurisées.
Cependant, certaines entités emboîtent le pas et vont encore plus loin avec PSD2, par exemple l'Autorité britannique de la concurrence et des marchés (AMC) a mis en place des normes communes en matière de sécurité et d’interfaçage de données des APIs. Aujourd’hui, l’AMC ainsi que d’autres entités ont opté pour l’utilisation du protocole OAuth2.0/OIDC pour sécuriser l’accès aux informations client au travers des APIs, et ainsi garantir une protection optimale. Cela signifie que toute société tiers souhaitant entrer dans l'écosystème bancaire devra supporter le protocole OAuth 2.0 / OIDC.
OpenID Connect (OIDC) est un protocole d’authentification qui se base sur OAuth 2.0 pour faire de la délégation d’autorisation, c’est-à-dire que dans la grande majorité des cas, l’utilisateur final n’aura plus besoin de fournir directement ses informations d’identification à la ressource sollicitée.
Dans notre cas, l’utilisateur n’aura pas à s’authentifier auprès de sa banque pour autoriser une application tierce à gérer ses informations bancaires.
Entre autres, OAuth 2.0/OpenID Connect va vous permettre de déléguer à un système indépendant (une application tierce) l’authentification des utilisateurs finaux afin qu’elle puisse en toute sécurité accéder à vos informations bancaires.
OIDC utilise également le formalisme d’échange JWT (JSON Web Token) pour transmettre l’identité des utilisateurs aux applications, ainsi que leurs rôles/habilitations.
L’utilisation d’OpenID Connect offre également aux banques et aux applications tierces un moyen de répondre à certaines exigences en termes de conformité sur la protection des données (GDPR). En effet, OIDC joue un rôle décisif dans la négociation du consentement et de l'autorisation.
Pour résumer, OIDC est une solution parfaite pour remédier à certaines des faiblesses de la sécurité d'OAuth 2.0 en fournissant l'authentification et l'intégrité du message.
L’éditeur F5 au travers de son module APM (IAM) offre une solution complète conforme aux exigences spécifiques de l'OIDC imposées par « l’Open Banking ». Le support du protocole Oauth2/OIDC de manière exhaustive ainsi que ses capacités d’intégration constituent un élément clé pour le déploiement d’une infrastructure API sécurisée.
De plus, l’éditeur F5 Networks offre un portefeuille complet de solutions pouvant ajouter une couche de sécurité supplémentaire non négligeable, en l’occurrence l’ASM (Firewall applicatif).
Use case : prenons l’exemple d’une application mobile qui combine des services de paiement et de gestion de compte. Dans notre exemple nous supposerons que le client au travers de son application voudrait initier un paiement (sans contact ou sur un site marchand qui est interfacé avec son application).
Dans le use case ci-dessous la solution F5 permet :
Cette demande de paiement se caractérise par un call API accompagné d’un JWT généré par l’autorisation serveur.
User Agent : Le « user agent » est un navigateur ou une application mobile via laquelle l'utilisateur communique avec le serveur d'autorisation. Le client est le code Applicatif qui veut accéder aux ressources de l'utilisateur sur le serveur de ressources (SPA / Mobile App).
Client : Quant au client, il se trouve en général sur un serveur (comme une application Web), sur l'appareil (application mobile) ou dans le navigateur (application JavaScript).
OpenID provider (Module F5 - APM): il s’agit de « l’autorisation server », le serveur qui authentifie et délivre les jetons (JWT) au client.
APM (Module F5 - APM) : il s’agit du « Resource server » qui effectuera la validité de la requête du client.
ASM (Module F5 - ASM): le module ASM (WAF) permettra d’inspecter les différents requêtes APIs de manière granulaire. Nous pourrons entre autre restreindre certains caractères, paramètres, valider les méthodes et les objets. Nous pouvons aussi appliquer une base de signature mise à jour régulièrement pour identifier des séquences ou des classes d’attaques.
Events
Archives