Architecture zero trust bancaire

La référence est NIST SP 800-207, Zero Trust Architecture, publiée en août 2020. NIST SP 800-207 décrit le zero trust comme un ensemble évolutif de paradigmes déplaçant les défenses des périmètres réseau statiques vers les utilisateurs, actifs et ressources, et refuse explicitement la confiance automatique envers des actifs ou comptes fondée sur leur emplacement réseau ou leur propriété. L’authentification et l’autorisation du sujet comme de l’appareil sont des fonctions distinctes exécutées avant l’ouverture d’une session vers une ressource.

La banque doit abandonner l’hypothèse confortable qu’une application du centre de données parle à un collègue. L’application doit désormais demander qui l’appelle, depuis quel appareil, dans quel état et pour quelle ressource, à chaque fois. Le BSI situe ce modèle dans ses recommandations aux organisations allemandes, une référence utile pour expliquer l’architecture à un auditeur souhaitant une source allemande et pas seulement américaine.

Définir ce que l’on protège avant tout achat distingue le zero trust d’un simple exercice d’approvisionnement. Il faut identifier les données, applications, actifs et services dont l’atteinte ferait réellement mal, un ensemble bien inférieur au parc complet, puis cartographier les transactions qui les atteignent: quels systèmes s’appellent, dans quel ordre et avec quels identifiants.

Les cinq étapes de DXC pour les services financiers suivent cet ordre, surface protégée, flux transactionnels, architecture, politique, surveillance. Cet ordre est essentiel, car sans cartographie des flux, une politique bloque un traitement de paiements en fin de mois et l’organisation en conclut que le zero trust perturbe le fonctionnement. Une cartographie préalable transforme cela en question de conception dont la réponse est connue.

Si l’emplacement ne donne plus accès, l’identité doit assurer cette fonction, avec un inventaire de tous ceux qui peuvent s’authentifier, humains ou machines, un responsable par entrée et une revue supprimant réellement les entrées. Les accès privilégiés sont les plus sensibles: identifiants administrateurs, comptes d’urgence, compte de service créé pour une migration en 2014 et jamais désactivé.

La séparation des tâches relève du même sujet, car empêcher une personne de créer puis d’approuver un paiement tient à la conception des accès, pas à un document de politique. DORA inclut la gestion du risque TIC et des droits d’accès dans les obligations des entités financières européennes, tandis que les orientations de l’EBA sur les risques TIC et de sécurité détaillent les attentes de supervision. Les identifiants jamais utilisés par un humain posent un problème propre, traité dans l’identité machine bancaire, tandis que les connexions des clients et salariés résistantes à l’hameçonnage figurent dans les passkeys bancaires.

La microsegmentation limite les ressources accessibles à un système compromis à celles prévues, empêchant qu’une intrusion initiale touche toute la banque. Elle se heurte aussi à la machine la plus ancienne du bâtiment. Une plateforme bancaire centrale ou un mainframe antérieur au concept ne peut souvent pas autoriser chaque requête, et ses applications périphériques supposent que le réseau se porte garant.

Les contraintes décrites par WWT sur le déploiement zero trust concernent les accès anciens, les environnements opérationnels résistant au changement pour de bonnes raisons et l’absence initiale d’inventaire complet des identités. Cela explique pourquoi la plupart des banques sont à mi-chemin: le cœur ancien reçoit généralement une frontière renforcée avec des accès nommés et surveillés, tandis que le parc récent applique le modèle complet. Le core banking en Allemagne traite le volet plateforme de cette question.

Les établissements allemands connaissaient déjà ces attentes avant l’entrée en vigueur de DORA. Les exigences informatiques prudentielles de BaFin, les BAIT, portaient depuis des années sur la gestion des accès, les autorisations et la gouvernance informatique, domaines désormais repris par DORA dans un droit européen directement applicable. Les projets doivent toujours démontrer la maîtrise des accès et autorisations, en identifiant les règles applicables à chaque établissement.

Un document d’architecture peut donc rattacher le zero trust à des obligations précises au lieu de le défendre comme bonne pratique. DORA en Allemagne présente le règlement et sa supervision par BaFin, tandis que la gestion des risques à Francfort couvre la fonction de risque plus large dont il relève.

Le zero trust détermine qui peut accéder à une ressource. Il ne précise ni son emplacement ni quelle juridiction peut imposer son accès, deux questions trop souvent confondues dans une même réunion.

Une banque peut exploiter une architecture zero trust exemplaire dans un cloud dont l’opérateur subit une injonction étrangère de divulgation, sans que l’architecture résolve ce problème. Le cloud souverain bancaire traite l’emplacement et le contrôle, tandis que les centres de données financiers à Francfort abordent le volet physique.

Cette approche ne fait confiance à aucune demande en raison de sa provenance, chaque accès à une ressource est authentifié et autorisé selon les informations actuelles sur l’utilisateur et l’appareil. Dans une banque, elle définit les systèmes à protéger, cartographie les transactions qui les atteignent, puis impose des décisions par requête, les plateformes anciennes étant généralement entourées d’une frontière renforcée et surveillée.

DORA définit des obligations sans imposer le choix d’une architecture. Il exige la gestion des risques TIC, des mesures de protection et des droits d’accès contrôlés, auxquels une conception zero trust peut clairement répondre. Une banque atteignant ces objectifs autrement est conforme; elle ne peut pas les ignorer.

Par la surface protégée: la courte liste des données et systèmes dont la compromission ferait réellement mal, puis la cartographie de leurs flux transactionnels. Les choix technologiques viennent ensuite, car une politique ignorant les flux bloquera des travaux légitimes et fera perdre ses soutiens au projet.

Ils le sont partiellement, une situation habituelle dans les banques. Une plateforme incapable d’autoriser chaque requête reçoit une frontière renforcée avec des accès nommés, surveillés et limités dans le temps, tandis que le parc environnant applique le modèle complet. L’échec consiste à nier cette exception ancienne, car un attaquant qui l’atteint trouve l’endroit où le réseau garantit encore tout le monde.