Dans une banque, chaque opération, de la connexion d’un client au changement de limite par un collaborateur, commence par une question : qui se trouve vraiment en face, et qu’a-t-il le droit de faire. C’est pourquoi l’identité et l’authentification ont cessé d’être une couche « connexion » pour devenir le socle sur lequel repose tout le reste de la sécurité. Pour un directeur de la sécurité, cela signifie que l’IAM bancaire est un sujet de comité de direction, pas seulement un sujet IT.
D’après notre expérience, le difficile n’est pas de déployer un outil IAM mais de le brancher sur des dizaines de systèmes bancaires existants sans casser les services ni laisser de trous dans la piste d’audit. Nous traitons donc ces projets comme du développement de logiciel critique, avec une équipe qui comprend à la fois la sécurité et la réalité des architectures bancaires. C’est exactement le type d’équipe qui développe depuis 2017 les systèmes de sécurité et les plateformes digitales d’une banque privée mondiale.
Pourquoi l’identité et l’authentification sont-elles le coeur de la sécurité d’une banque ?
Parce que presque tout incident sérieux commence par une identité volée, pas par un chiffrement cassé. Dès que quelqu’un usurpe un client ou un collaborateur, le reste des contrôles se met à travailler en sa faveur. Une couche d’identité bien conçue renverse cela : elle restreint ce qu’un attaquant peut faire, même après avoir pris la main sur un compte.
Pour une banque, l’enjeu n’est pas seulement la perte financière mais aussi la confiance des clients et la responsabilité devant le régulateur. Nous traitons donc l’identité comme une couche qui doit être à la fois étanche, reproductible en audit et supportable au quotidien. Dès que l’une de ces trois dimensions glisse, les deux autres finissent par en souffrir.
Qu’est-ce que la gestion des identités et des accès (IAM) dans une banque ?
En clair : l’IAM répond à la question de savoir qui peut accéder à quoi, et dans quelles conditions, sur tout le cycle de vie d’un compte. Ce n’est pas un outil unique mais un ensemble cohérent de processus et de mécanismes. En pratique, il couvre plusieurs domaines :
- l’identité client (CIAM), c’est-à-dire l’inscription, la connexion et la récupération de compte dans les canaux digitaux,
- l’identité des collaborateurs et des partenaires, du premier jour de travail à la révocation des accès au départ,
- la gouvernance des accès et des rôles, qui décide de ce que chacun peut réellement faire dans un système,
- les identités techniques, c’est-à-dire les comptes de service, les API et les intégrations, souvent les plus négligées.
Nous relions ces domaines pour qu’ils forment un récit d’accès cohérent, plutôt qu’un ensemble d’îlots de connexion séparés dans chaque système.
Qu’est-ce que l’authentification forte (SCA, MFA) et qu’exige la PSD2 ?
L’authentification forte repose sur la combinaison d’au moins deux facteurs indépendants de catégories différentes : quelque chose que l’utilisateur sait (un mot de passe, un code PIN), quelque chose qu’il possède (un téléphone, un token) et quelque chose qu’il est (la biométrie). C’est ce qui se cache derrière les sigles MFA (authentification multifacteur) et SCA (authentification forte du client).
En Europe, ce n’est plus une affaire de bonne volonté. La directive PSD2 oblige les banques à appliquer la SCA lorsque les clients se connectent à leurs comptes en ligne et lorsqu’ils initient des paiements, avec quelques exemptions pour les transactions à faible risque. Nous concevons ces mécanismes pour répondre à cette exigence sans transformer chaque action en parcours du combattant. L’essentiel ici est le lien dynamique entre l’authentification et un montant et un bénéficiaire précis, car c’est cela qui rend réellement plus difficile la falsification d’une transaction.
Comment gouverner les accès et les droits dans une banque ?
C’est généralement là que se cache le plus grand risque, car les droits ont tendance à « s’empiler » avec le temps. Un collaborateur change d’équipe, prend de nouveaux rôles, et les anciens restent. Nous mettons de l’ordre en fondant les accès sur des principes clairs :
- le privilège minimal nécessaire plutôt que des accès accordés « au cas où »,
- des rôles et des groupes liés à un poste, pas à un individu,
- la séparation des tâches, pour qu’aucune personne ne contrôle à elle seule un processus sensible entier,
- des revues et recertifications régulières des accès, avec expiration automatique de ce qui n’est pas utilisé.
Nous y ajoutons un contrôle plus strict des comptes à privilèges (administrateurs, comptes de service), car ce sont les cibles les plus précieuses. Des droits bien structurés font qu’une intrusion réussie sur un compte n’ouvre pas toute la banque à l’attaquant.
Comment branchez-vous l’IAM sur les systèmes existants d’une banque ?
C’est généralement la partie la plus difficile et la moins visible du projet. Une banque ne part pas de zéro : elle a des systèmes core, une banque en ligne, des applications mobiles et des dizaines d’applications internes, souvent dotées de leurs propres mécanismes de connexion. Notre objectif est une source de vérité unique et cohérente sur l’identité, à laquelle ces systèmes se connectent.
Nous les intégrons avec des standards modernes comme OAuth 2.0, OpenID Connect et SAML, et nous introduisons le single sign-on (SSO) là où cela a du sens. Les applications plus anciennes qui ne parlent pas ce langage, nous les enveloppons dans des couches intermédiaires plutôt que de les réécrire tout de suite. La migration reste ainsi progressive et réversible, au lieu d’un risqué « on bascule tout en un week-end ».
Comment assurez-vous la conformité et l’audit dans le domaine de l’identité ?
Pour une banque, être sûre ne suffit pas ; il faut aussi pouvoir le prouver. Nous concevons donc pour l’audit dès le départ, au lieu de greffer la journalisation des événements à la fin. En pratique, cela signifie une piste d’audit complète et non répudiable montrant qui a accédé à quoi et quand, et qui lui a accordé cet accès.
Nous relions les mécanismes à des exigences concrètes, de la PSD2 et des recommandations du superviseur aux politiques internes de la banque, pour qu’en cas de contrôle la réponse se résume à lancer un rapport, et non à fouiller les journaux pendant des semaines. Sur les données personnelles, nous nous tenons aux principes de minimisation et de responsabilité, car dans une banque l’identité et la vie privée voyagent toujours ensemble.
Quelles compétences fournissons-nous pour un projet IAM ?
Nous construisons l’équipe autour de l’étape et de l’architecture concernées, pas « au cas où ». Sur les projets d’identité et de sécurité, nous affectons le plus souvent des rôles comme :
- un architecte sécurité / IAM qui définit le modèle d’identité et de droits,
- des ingénieurs intégration qui relient l’IAM aux systèmes core et aux canaux digitaux,
- des développeurs backend qui construisent les services d’authentification, les API et les mécanismes SCA,
- des spécialistes DevOps et sécurité responsables des déploiements, du durcissement et de la surveillance.
Une telle équipe peut prendre en charge tout le domaine, de la conception à la maintenance, ou renforcer l’équipe de la banque exactement là où manquent les bras ou l’expertise.
Comment faisons-nous chez RITS ?
Nous le faisons comme partenaire nearshore depuis la Pologne, avec une expérience réelle des systèmes critiques d’une banque. Pour une institution mondiale de premier plan en private banking et gestion d’actifs, nous développons depuis 2017 ses systèmes de sécurité ainsi que ses systèmes internes et ses plateformes digitales, et notre équipe engagée a grandi jusqu’à près de 90 spécialistes. Nous traitons la gestion des identités et l’authentification forte comme un domaine au sein de cette compétence sécurité, pas comme un outil isolé.
Sur ces projets, nous nous appuyons sur quelques principes : nous vérifions les compétences avant le démarrage, nous travaillons dans un fuseau horaire proche, ce qui nous permet de rejoindre les revues de code et les réunions sans longue montée en charge, et nous construisons en pensant à l’audit dès le premier jour. Le plus souvent, nous le faisons en logiciel sur mesure construit par notre équipe et, quand la banque doit compléter vite des compétences, en renfort d’équipe.
Par où commencer avec l’IAM et l’authentification forte ?
Commencez par un inventaire honnête : quelles identités, quels systèmes et quelles méthodes de connexion existent aujourd’hui, et où sont les plus grands écarts par rapport à la PSD2 et à vos politiques internes. Choisissez ensuite un canal ou un processus à haut risque (par exemple la connexion et les paiements dans la banque en ligne) et prouvez-y le modèle cible, au lieu de tout reconstruire d’un coup. Cela définit l’architecture, les standards et les rôles nécessaires. Nous avons traité les différences entre modèles de collaboration dans notre article sur les modèles de collaboration IT.
Vous mettez en place ou remettez à plat l’IAM et l’authentification forte dans votre banque ? Parlons-en - nous accorderons une équipe et une architecture à votre environnement et à vos exigences réglementaires.
Mettez en place avec nous l’IAM et l’authentification forte dans votre banque