Challenges clés
Pour nombre d’entreprises, la fuite de données est l’un des risques les plus sérieux auxquelles elles sont confrontées, si non le principal.
Pour les institutions financières cependant, les préoccupations relatives à celles-ci ont une toute autre envergure. En effet, en plus de se faire interdire l’accès au marché, la violation de la confidentialité des données ou des lois sur la protection des consommateur peut entraîner des frais juridiques et des poursuites judiciaires et endommager la réputation de l’entreprise ainsi que sa santé financière à long-terme.
Les autorités de régulation financières s’appuient donc sur de nombreuses régulations pour protéger et sécuriser les données bancaires des clients finaux.
Dans le contexte Suisse, le régulateur agréé « FINMA » a soulevé le risque posé par la masse de données sensibles présentes dans les environnements hors production qu’on peut appeler « de premiers niveaux » : bac à sable, développement, intégration, etc.
Ces derniers sont souvent moins sécurisés que les environnements plus proches de la production car ils sont plus propices aux innovations, auxquelles par définition, on ne souhaite pas mettre de contrainte.
Cependant, si une donnée unique ne pose pas un risque majeur, une masse de données exposée peut soulever un risque opérationnel pour une banque lors de fuites de données potentielles. Afin de réduire l’exposition des banques à ce risque, le régulateur souhaite donc que le nombre de « Client Identifying Data (CID) » Directes ou Indirectes exposées soit limité.
Dans le contexte de notre client, ces environnements était déjà sécurisés au niveau des CID directes (données personnelles, adresses, etc.). La mission a consisté a anonymiser des « CID indirectes » telles que des références à des données sensibles, ou des combinaisons toxiques.
Afin de répondre à ces exigences, le projet a été structuré en deux phases : une première phase d’analyse visant à faire un état des lieux, trouver des réponses aux problématiques posées et conceptualiser une solution, et une seconde phase d’implémentation de la solution choisie.
Notre approche
Prérequis du projet
Un certain nombre de contraintes métiers, opérationnelles et techniques ont été énoncées :
1. Fiabilité et pérennité
Des utilisateurs d’une donnée doivent pouvoir compter sur sa pérennité, sans quoi chaque changement peut devenir impactant pour l’utilisateur. Si les changements sont fréquents, l’impact opérationnel peut s’avérer exponentiel. Hors un mécanisme d’anonymisation, quel qu’il soit, modifie une donnée par définition. La sécurisation des environnements devait donc assurer une protection fiable sur le long terme.
2. Evolutivivité
A l’opposé, s’agissant d’environnements de « premier niveaux », ils sont voués à évoluer avec le temps. Une donnée anonymisée à un instant T car identifiée comme faisant partie d’un périmètre donné, peut se retrouver « en clair » l’instant d’après suite à un changement de l’infrastructure. La solution devait donc assurer d’être évolutive et de prendre en compte les changements d’architecture et évolutions du parc applicatif.
3. Performance
Enfin, le client étant opérationnel 24/24h, les temps d’indisponibilité des environnements, y compris hors production, devaient être proches de zéro. Ce projet représentait non seulement un défi en terme de performance dans le cas d’une sécurisation d’une large masse de données, mais imposait également de prendre en compte les processus existants du client afin de s’y intégrer et de minimiser l’impact opérationnel du projet.
Phase d’identification des données
Nous avons proposé plusieurs solutions à notre client.
Dans un premier temps, la phase d’analyse nous a permis d’identifier les données à anonymiser, leur localisation, et leur degré de sensibilité.
Une solution a été proposée afin de répondre à ces questions. Elle permet une identification similaire à des outils dits « de DLP » (Data Loss Prevention) qui vont permettre deux types de recherches :
- Recherche par « exact match », auquel cas une liste de « chaine de caractère recherchée » est établie et recherchée dans les données du client.
- Recherche par « expression régulière », qui permet de réaliser des recherches intelligentes basées sur des critères spécifiques.
Notre solution proposait d’utiliser ces mécanismes pour identifier de manière très précise les données à sécuriser et d’en extraire leurs métadonnées techniques. Cette étape nous permettrait par la suite d’en faire l’analyse, et d’utiliser les métadonnées pour réaliser les opérations techniques de sécurisation.
En fonction des prérequis énoncés précédemment, que nous avons évalué techniquement, nous avons établi une liste d’exigences :
- Les durées estimées de validité du mécanisme de protection,
- Le mécanisme préférable en fonction de chaque type donnée et de sa sensibilité,
- L’architecture fonctionnelle nécessaire,
- L’infrastructure existante et nécessaire à la mise en œuvre du projet,
- L’organisation requise pour la mise en place et le cycle de vie de la solution.
Grace à cela, et à une analyse de marché conduite en parallèle, nous avons pu nous projeter et proposer un ensemble de solutions au client. Certaines utilisent des mécanismes internes, d’autres proviennent d’éditeurs du marché. Les solutions proposées permettaient de proposer un programme de sécurisation des environnements hors production de A à Z.
Phase d’anonymisation des données
A ce stade, un enjeu a été identifié sur la mise en production du projet. En effet, étant donné que l’intégrité d’un environnement était un critère fort donc que le périmètre était complet et ne pouvait être réduit, que la masse de donnée était conséquente donc que son anonymisation prend du temps, et par ailleurs, que le client ne souhaitait pas d’interruption de service dans ses activités même hors production, il a fallu trouver un moyen de s’intégrer aux processus existants et paralléliser les actions d’anonymisation tout en gardant la cohérence afin de répondre à toutes les exigences. Ceci a constitué autant un défi technique qu’organisationnel.
Les solutions proposées ont toutes plus ou moins la même architecture. Utilisant les métadonnées stockées précédemment, et les résultats d’une analyse sur la nature de chaque données, elles vont pouvoir utiliser les mécanismes suivants afin de protéger les données :
- Anonymisation : transformation de la donnée pour une chaine de caractère aléatoire,
- Pseudonymisation : transformation de la donnée pour une chaine de caractère connue des personnes utilisant la donnée uniquement,
- Tokenisation : transformation de la donnée pour un jeton aléatoire,
- Ensemble : transformation de la donnée pour une valeur d’un ensemble connu. Par exemple, des dates de naissance entre 1950 et 1990, les montants de facture entre deux valeurs ne dépassant pas un maximum, ou l’utilisation d’un ensemble adresses permettant des statistiques par pays mais pas l’identification d’une donnée.
- Bruit : L’ajout de donnée à un environnement afin d’en masquer les valeur réelles ainsi noyées dans un flot plus grand.
Certaines solutions du marché permettent des centaines d’autres options de sécurisation, et permettent entre autre des évolutions natives, tandis que les solutions modélisées pour le client permettent une intégration adaptée à certains contextes. Dans ce cas-ci, le besoin d’une solution customisable émanait du fait que certains identifiants avaient une spécificité fonctionnelle induisant un mécanisme de sécurisation dédié.
Bénéfices
Grace à la solution implémentée, notre client est désormais en mesure de répondre à ses obligations légales vis-à-vis de son régulateur local, mais d’autres avantages beaucoup plus opérationnels ont pu également émerger de ce projet.
En effet, l’assurance d’un environnement totalement anonymisé et sécurisé permet d’imaginer de nouveaux axes de développement et le client est maintenant en capacité de proposer l’accès à ses environnements hors-production à des partenaires du monde entier tout en assurant au régulateur local qu’aucune donnée ne sort du territoire, un impératif primordial au projet.
Par ailleurs, le client peut maintenant déployer ses environnements hors production sur des plateformes cloud sans compromettre ses impératifs opérationnels, et profiter dès lors des avantages de modularité, de flexibilité, budgétaire et d’évolutivité de ces plateformes, et par conséquent être plus réactif et concurrentiel sur les services qu’il propose.
Tout en répondant à ses impératifs de conformité, ce projet a donc permis à notre client d’améliorer ses processus opérationnels et surtout lui a permis d’acquérir un degré de flexibilité et de réactivité qu’il n’avait pas auparavant.
Technologies
