Anonymisation des données : quand la sécurité pilote le projet

Remplacer une solution d'anonymisation en place, c'est rarement une simple affaire de fonctionnalités. Chez un grand groupe public français, le projet s'est joué sur un autre terrain. L'outil devait lui-même satisfaire les standards de sécurité de l'organisation.

Retour sur ce projet, raconté de l'intérieur par Cécile Masson, Business Development Manager, et Amina Belhassena, solution architect chez ARCAD Software.

Le client utilisait Informatica pour anonymiser ses données de test et avait engagé une démarche pour migrer d'Informatica Data Masking. La solution coûtait cher. De plus, sa politique d'hébergement des données dans le cloud avait contraint le client à rester sur une ancienne version.

Son patrimoine de données était hétérogène : plusieurs bases de données (SQL Server, MySQL, PostgreSQL), auxquelles s'ajoutaient des fichiers plats à traiter.

Le contact avec ARCAD Software s'est noué par l'intermédiaire d'un partenaire intégrateur. Le terrain n'était pas inconnu : en effet, la solution DOT Anonymizer équipe déjà une autre entité du groupe.

Le besoin était clairement identifié, puisqu'il s'agissait de remplacer un produit existant. La responsable Data du client a supervisé l'ensemble des échanges. Les attentes des métiers étant connues, l'essentiel s'est joué ailleurs.

« Il fallait absolument être au niveau de sécurité de l'organisation, explique Cécile. C'était le prérequis absolu, et cela a conditionné l'affaire jusqu'au bout. » Le client avait en effet renforcé sa politique de sécurité. Or DOT Anonymizer propose une authentification OIDC et une connexion à un coffre-fort de secrets (Vault). Ces deux capacités ont permis d'atteindre le niveau d'exigence attendu. L'équipe d'ARCAD Software a également dû produire un plan d'assurance sécurité.

Deuxième critère : l'architecture du SI. Pour des raisons de sécurité, le client étanchéise ses différentes lignes business. Le responsable de l'architecture a joué un rôle clé pour faire comprendre ces contraintes. ARCAD Software a ainsi pu proposer le Production Server, une réponse adaptée à cette architecture pour un coût acceptable.

Aucun concurrent n'était en lice au moment décisif : ARCAD Software a été le seul à franchir les étapes de la sandbox puis du pilote. Ce qui a fait basculer la décision ? « Le sérieux dans la tenue des délais R&D, qui étaient scrutés régulièrement et challengés », répond Cécile. La souveraineté du produit et la proximité de la R&D ont également compté. Le contexte était alors à la défiance vis-à-vis des produits américains. Enfin, la négociation s'est conduite avec l'acheteur du client et l'achat est passé par une centrale d'achat et un distributeur.

Côté technique, les contraintes ne portaient ni sur la volumétrie ni sur la performance. Elles étaient avant tout architecturales et sécuritaires.

Le client voulait que les traitements d'anonymisation s'exécutent au plus près de la donnée. Il voulait concevoir, livrer et exécuter chaque projet de façon autonome. Il souhaitait également maîtriser les coûts d'infrastructure et de licences. S'y ajoutaient plusieurs exigences : authentification centralisée via OIDC, récupération des identifiants depuis un Vault plutôt que leur stockage dans l'outil, hachage des credentials, gestion fine des utilisateurs et des groupes, et intégration des logs dans la supervision. Enfin, d'autres applications devaient pouvoir déclencher l'anonymisation à la volée, ce qui imposait des API.

« Le client ne se contentait pas de vérifier que l'anonymisation fonctionnait, souligne Amina. Il voulait s'assurer que l'outil d'anonymisation lui-même respectait ses standards de sécurité. » Pour apporter des réponses précises à l'équipe Sécurité, ARCAD Software a donc mobilisé un groupe d'experts de sa R&D. Ce groupe s’est ajouté à l'accompagnement projet. Les équipes ont par ailleurs réalisé les tests directement dans l'environnement du client, plutôt que sur des démonstrations génériques.

La solution retenue repose sur une architecture Design / Production à deux niveaux. Le serveur Design joue le rôle de serveur maître. Il sert à concevoir chaque projet : définition, choix des moteurs d'anonymisation, type de source. On exporte ensuite le projet validé sous forme de package (archive .zip). Ce package regroupe les moteurs, les éventuels scripts Groovy et la description des sources. Un serveur Production unique importe ce package et complète si besoin les informations de connexion. Il lance alors l'exécution, depuis l'interface ou en ligne de commande (CLI).

Ce mode de livraison présente un double avantage. Chaque projet devient un livrable autonome, versionnable et rejouable. Et le serveur Production peut fonctionner sans communication directe avec le serveur Design, ce qui renforce le cloisonnement. Les deux modes, connecté et déconnecté, ont été testés pour permettre à l'équipe Architecture de vérifier l'isolation des environnements.

Le projet s'est appuyé sur deux phases de validation successives, de plus en plus proches du contexte réel.

La première année, le client a découvert la solution en sandbox : des tests fonctionnels menés dans l'infrastructure d'ARCAD Software, avec des données de l'éditeur, sans mobiliser ses environnements ni exposer ses données. Un an plus tard, il a souhaité mener un pilote dans sa propre infrastructure, sur un échantillon de ses propres données, puisque la performance n'était pas un critère clé.

Ce pilote comptait deux volets. Le volet fonctionnel couvrait la détection des données sensibles, la reprise du dictionnaire de données, l'anonymisation de bases avec filtres et de fichiers plats. Le volet technique et sécurité portait sur l'installation des serveurs, leur communication, l'import/export des projets via l'interface, la CLI et les API OpenAPI (Swagger), ainsi que l'évaluation approfondie de la sécurité.

« Commencer par un essai en sandbox sur le fonctionnel, puis un pilote très orienté sécurité, ce n'est pas très courant, note Cécile. Mais c'est révélateur du niveau d'exigence d'un établissement qui s'adapte au niveau de sécurité requis pour éviter les attaques. »

Côté client, trois équipes étaient impliquées. L'équipe Data a pris en charge les règles d'anonymisation. L'équipe Architecture a vérifié l'isolation des serveurs. L'équipe Sécurité a mené l'évaluation de l'outil. Le pilote s'est déroulé sous forme d'ateliers, complétés par des séances de brainstorming avec les architectes, et ces échanges ont réorienté la stratégie. Au départ, le client envisageait plusieurs serveurs d'exécution pour garantir l'autonomie de ses projets. « Nous avons démontré que cette autonomie ne dépendait pas du nombre de serveurs, mais de la façon dont les projets sont conçus, packagés et cloisonnés », explique Amina. Finalement, le client a retenu un seul serveur Production, ce qui a fortement réduit les coûts sans renoncer à aucune exigence.

Le pilote a démontré plusieurs points :

Sur le plan économique, deux éléments ont été décisifs face à Informatica. D'abord, un modèle de prix non indexé sur le volume de données. Ensuite, une installation on premise qui garde les données dans l'infrastructure du client, un argument qui a pesé autant que le prix. Le choix d'un serveur Production unique a, en outre, fortement réduit les coûts.

Le client envisage déjà la suite : intégrer de nouveaux SGBD et de nouvelles lignes business.

Impliquer l'Architecture et la Sécurité dès le départ. Dans un projet d'anonymisation transverse, les questions structurantes ne sont pas seulement fonctionnelles : Où s’exécutent les traitements ? Comment les identifiants sont-ils protégés ? Qui a accès à quoi ? Les traiter tôt évite de remettre en cause des choix en cours de route. Ici, la sécurité a conditionné l'affaire du début à la fin, ce qui rejoint le point de vue du RSSI sur l'anonymisation.

Ne pas confondre autonomie et multiplication des serveurs. Avec une bonne gestion des utilisateurs, des groupes et des projets packagés, un seul serveur Production suffit à cloisonner les projets.

Mener le pilote chez soi, sur ses propres données. Tester l'anonymisation ne suffit pas : il faut aussi valider l'installation, la communication entre serveurs, l'intégration aux outils et l'automatisation. Si la performance n'est pas un enjeu, un échantillon suffit pour obtenir des résultats représentatifs. C'est aussi l'intérêt de commencer sur un périmètre restreint.

Penser industrialisation dès la conception. « Un projet d'anonymisation n'est pas un traitement ponctuel : les règles évolueront et les traitements seront rejoués », rappelle Amina. Séparer le Build, porté par le serveur Design, du Run, porté par le serveur Production, et concevoir des projets versionnables et pilotables en ligne de commande, c'est préparer le passage à l'échelle dès le premier jour. Pour approfondir ce modèle, lire notre article Serveur Design et Serveur Production : deux piliers d'une architecture d'anonymisation moderne et industrialisée.

Pour aller plus loin, découvrez d'autres retours d'expérience clients.