Découvrez notre société Contactez-nous

e-Xpert Solutions Genève

109, chemin du Pont-Du-Centenaire
CH-1228 Plan-les-Ouates / Genève
SUISSE

Tel. : +41 22 727 05 55 Fax : +41 22 727 05 50

e-Xpert Solutions Lausanne

Avenue de Gratta-Paille 20
CH-1018 Lausanne
SUISSE

Tel. : +41 21 802 26 78 Fax : +41 22 727 05 50
Contactez notre support : +41 22 727 05 56
Envoyez votre message

Swiss Security Hackademy

Suivez notre blog bilingue en sécurité informatique !

Retour aux articles

Directive PSD2

Introduction du « système bancaire ouvert »


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.

En quoi consiste l’accès à votre compte par des tiers :

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.

Mise en situation

Directive PSD2
  • 1. L’utilisateur souhaite faire un achat.
  • 2. Pour ce faire, il souhaite procéder au paiement en utilisant une application tierce. Cette application a les autorisations nécessaires pour gérer certaines tâches sur le compte du client. Toutefois, pour utiliser cette application il devra s’authentifier (OTP, certificat, biométrie …).
  • 3. L’utilisateur au travers de son application récupère les modalités de paiement.
  • 4. L’utilisateur doit autoriser l’application à exécuter le paiement.
  • 5. Une confirmation de paiement est retournée par l’institution bancaire.

De nouveaux acteurs financiers

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 :

  • L’accès au compte du client,
  • Consultation de paiement (loyer, salaire, assurance, téléphone…),
  • Exécution d’un paiement,

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 et la sécurité

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.

Qu'est-ce qu'OpenID Connect et quel est son lien avec OAuth 2.0?

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.

Implémentation d'une sécurité API de niveau financier

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 :

  • D’authentifier et d’autoriser l’utilisateur,
  • Valide la conformité et l’intégrité des « Call APIs »,
  • Et inspecte le flux contre d’éventuelles attaques.
Directive PSD2
  • 1. L’utilisateur sélectionne une marchandise à acheter. Son application mobile interagit automatiquement et s’exécute.
  • 2. L’utilisateur est convié à s’authentifier (de manière forte) sur son application (OTP, Biométrique, …).
  • 3. Une fois authentifié, un jeton est généré par l’autorisation serveur. Celui-ci sera par la suite remis au « ressource server » (service bancaire) pour autoriser la transaction.
  • 4. La demande de paiement est soumise à la banque au travers du service API.

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.