Sécurité API PSD2 : Guide d’intégration Open Banking sur Google Cloud

Dans le paysage fintech actuel, la directive PSD2 (Payment Services Directive 2) n’est plus une nouveauté réglementaire, mais la norme opérationnelle de facto pour l’interopérabilité bancaire. Cependant, pour les architectes logiciels et les ingénieurs DevOps, le défi est passé de la simple conformité à la mise en œuvre d’architectures robustes, évolutives et, surtout, sécurisées. Lorsque l’on connecte un CRM propriétaire aux comptes courants des clients via des API bancaires, la sécurité API PSD2 devient le pilier fondamental sur lequel repose toute l’infrastructure.

Ce guide technique explore comment construire une passerelle API sécurisée en utilisant l’écosystème Google Cloud, avec un accent particulier sur Apigee comme couche de médiation. Nous analyserons les modèles architecturaux nécessaires pour gérer l’authentification mTLS, les flux OAuth 2.0 complexes, le chiffrement des données sensibles (PII) et la résilience opérationnelle face aux latences des banques tierces.

Prérequis et Contexte Architectural

Avant de plonger dans le code et les configurations, il est nécessaire de définir le périmètre opérationnel. Dans un scénario d’Open Banking, votre application agit généralement en tant que TPP (Third Party Provider), spécifiquement comme AISP (Account Information Service Provider) ou PISP (Payment Initiation Service Provider).

Pour suivre ce guide, nous supposons la disponibilité de :

• Un compte Google Cloud Platform (GCP) actif.
• Une instance d’Apigee X ou Apigee Hybrid configurée.
• Des certificats eIDAS (QWAC et QSEAL) valides, nécessaires pour l’identification formelle auprès des banques européennes.
• Une connaissance de base des conteneurs (si vous utilisez Cloud Run/GKE pour les microservices du CRM).

L’Architecture « Secure Hub »

L’approche recommandée est le modèle « Secure Hub ». Au lieu de permettre au CRM d’appeler directement les API des banques, on interpose une passerelle API (Apigee) qui agit comme point unique d’application des politiques de sécurité. Le flux des données est le suivant :

CRM (Backend) → Google Cloud Apigee (Gateway) → ASPSP (API Banque)

1. Mise en œuvre de mTLS (Mutual TLS) pour l’Authentification Serveur-à-Serveur

Selon les normes techniques réglementaires (RTS) de la PSD2, la simple authentification par clé API n’est pas suffisante pour la communication entre le TPP et la Banque. L’utilisation de Mutual TLS (mTLS) est obligatoire.

Dans mTLS, ce n’est pas seulement le client (vous) qui vérifie le certificat du serveur (la banque), mais la banque doit également vérifier votre certificat client (le certificat eIDAS QWAC). Voici comment le configurer sur Apigee :

Configuration du Keystore et du TargetServer

Dans Apigee, la gestion de mTLS vers le backend (la banque) se fait via la définition de TargetServers.

1. Chargement du Certificat : Chargez votre certificat QWAC (clé publique et privée) dans le Keystore d’Apigee.
2. Définition SSLInfo : Dans la configuration du TargetServer, activez SSL et référencez le Keystore.

<TargetServer name="Bank-API-Target">
  <Host>api.banca-partner.com</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
    <Enabled>true</Enabled>
    <ClientAuthEnabled>true</ClientAuthEnabled>
    <KeyStore>ref://my-qwac-keystore</KeyStore>
    <KeyAlias>my-key-alias</KeyAlias>
    <TrustStore>ref://bank-truststore</TrustStore>
  </SSLInfo>
</TargetServer>

Note technique : Assurez-vous que le TrustStore contient la chaîne complète de l’autorité de certification (CA) qui a émis le certificat de la banque, sinon le handshake échouera.

2. Gestion des Jetons : OAuth 2.0 et OIDC

La sécurité API PSD2 exige que l’accès aux données du compte soit explicitement autorisé par l’utilisateur final via une Authentification Forte du Client (SCA). Cela se traduit techniquement par le flux OAuth 2.0 Authorization Code Grant.

Le Rôle d’Apigee comme Médiateur de Jetons

Votre CRM ne devrait jamais gérer directement les jetons d’accès bruts des banques, sauf en cas de nécessité absolue. Un modèle sécurisé prévoit qu’Apigee gère l’échange des jetons et fournisse au CRM un jeton opaque interne.

1. Redirection : L’utilisateur est redirigé vers le portail de la banque pour la connexion.
2. Callback : La banque renvoie un authorization_code à votre endpoint de callback sur Apigee.
3. Échange de Jeton : Apigee appelle l’endpoint /token de la banque en utilisant mTLS et échange le code contre un access_token et un refresh_token.
4. Stockage Sécurisé : Apigee chiffre ces jetons et les stocke dans son cache sécurisé (ou dans une base de données externe chiffrée), renvoyant au CRM un identifiant de session.

Cette approche réduit la surface d’attaque : si la base de données du CRM est compromise, les attaquants ne trouveront pas de jetons bancaires valides.

3. Chiffrement des Données Sensibles (PII) avec Google Cloud KMS

Les données financières (IBAN, solde, transactions) sont des PII (Personally Identifiable Information) critiques. La conformité RGPD et PSD2 impose le chiffrement tant en transit (déjà couvert par TLS 1.2+) qu’au repos.

Chiffrement d’Enveloppe (Envelope Encryption)

Pour une sécurité de niveau entreprise, utilisez Google Cloud Key Management Service (KMS). Ne codez jamais en dur les clés de chiffrement dans le code ou les configurations d’Apigee.

Mettez en œuvre une stratégie de Chiffrement d’Enveloppe :

• Utilisez une DEK (Data Encryption Key) pour chiffrer la charge utile de la réponse bancaire avant qu’elle ne soit sauvegardée ou journalisée.
• Utilisez une KEK (Key Encryption Key) gérée par Cloud KMS pour chiffrer la DEK.

Dans Apigee, vous pouvez utiliser une politique ServiceCallout pour invoquer les API de Cloud KMS et déchiffrer les clés uniquement lorsque cela est nécessaire pour le traitement, en gardant les données obfusquées dans les journaux système.

4. Modèles de Résilience : Circuit Breaker et Limitation de Débit

Les API bancaires, en particulier celles des établissements historiques adaptés à la PSD2, peuvent souffrir de latences imprévisibles ou de temps d’arrêt. Un CRM qui attend indéfiniment une réponse bancaire offre une mauvaise expérience utilisateur et risque un crash en chaîne.

Mise en œuvre du Circuit Breaker

Le modèle Circuit Breaker empêche qu’une erreur dans un service externe (la banque) ne sature les ressources de votre système.

Dans Apigee, il n’existe pas de politique « Circuit Breaker » native prête à l’emploi, mais on peut l’implémenter en combinant KVM (Key Value Maps) et une logique conditionnelle :

1. Si un appel au TargetServer échoue ou expire, incrémentez un compteur dans KVM.
2. Si le compteur dépasse un seuil (ex. 5 erreurs en 1 minute), activez un drapeau « Open Circuit ».
3. Les requêtes suivantes sont rejetées immédiatement avec une erreur 503 personnalisée, sans tenter de contacter la banque, permettant au système externe de récupérer.
4. Après une période de refroidissement, le circuit passe en état « Half-Open » pour tester à nouveau la connectivité.

Gestion de la Limitation (Spike Arrest et Quota)

Les banques imposent des limites strictes sur le nombre d’appels API (ex. 4 appels par jour pour l’actualisation des soldes en arrière-plan). Dépasser ces limites peut entraîner le blocage temporaire de votre certificat TPP.

Utilisez la politique Quota d’Apigee pour appliquer ces limites côté client :

<Quota name="CheckBankLimits">
    <Interval>1</Interval>
    <TimeUnit>day</TimeUnit>
    <Allow count="4"/>
    <Identifier ref="request.header.account_id"/>
    <Distributed>true</Distributed>
</Quota>

Pour protéger votre backend contre les pics de trafic soudains, utilisez plutôt la politique SpikeArrest, qui lisse les pics de trafic en les répartissant dans le temps.

5. Validation des Certificats et Sécurité de la Charge Utile

Au-delà du transport, il est vital de valider le contenu. Selon les spécifications FAPI (Financial-grade API), souvent adoptées dans le cadre de la PSD2, les jetons JWT doivent être signés et parfois chiffrés.

Utilisez la politique VerifyJWT d’Apigee pour vous assurer que les jetons reçus de la banque sont valides et n’ont pas été altérés. Configurez la politique pour valider :

• La signature (en utilisant la clé publique de la banque exposée via JWKS).
• L’audience (claim aud) pour s’assurer que le jeton vous est destiné.
• L’expiration (claim exp).

Conclusion

Mettre en œuvre la sécurité API PSD2 n’est pas une tâche banale ; elle nécessite une superposition de protocoles réseau (mTLS), de normes d’autorisation (OAuth 2.0/OIDC) et de pratiques d’ingénierie logicielle (Circuit Breakers). En utilisant Google Cloud Apigee comme hub central, vous centralisez la complexité, permettant à votre CRM de rester léger et concentré sur la logique métier, tandis que la passerelle prend en charge la conformité cryptographique et réglementaire.

N’oubliez pas que la sécurité est un processus continu : surveillez constamment les journaux (obfusqués) via Google Cloud Operations Suite et maintenez vos certificats QWAC à jour pour éviter les interruptions de service.

Foire aux questions

Sources et Approfondissements

1. Texte officiel de la Directive (UE) 2015/2366 (PSD2) – EUR-Lex
2. Règlement délégué (UE) 2018/389 sur l’authentification forte et la communication sécurisée (RTS) – EUR-Lex
3. Cadre réglementaire DSP2 et Open Banking – Banque de France (ACPR)
4. Politique des services de paiement – Commission européenne
5. Définition et contexte de l’Open Banking – Wikipédia

Francesco Zinghinì

Ingénieur électronique avec pour mission de simplifier le numérique. Grâce à son bagage technique en théorie des systèmes, il analyse logiciels, matériel et infrastructures réseau pour offrir des guides pratiques sur l’informatique et les télécommunications. Il transforme la complexité technologique en solutions accessibles à tous.

LinkedInFacebookBiographie complète →