Anonymisation : garanties recherchées, mécanismes et contraintes métier

Nous vous présentons les principales garanties recherchées. Pour chaque type métier de données, le processus d’anonymisation, qui peut s’appuyer sur une ou plusieurs techniques d’anonymisation pré-citées, doit être :

• Irréversible : c’est obligatoire pour les données personnelles, et de manière générale, le processus doit être irréversible, sinon l’anonymisation n’a pas d’intérêt !
• Sinon, réversible sous conditions : parfois il peut être utile de pouvoir retrouver l’information originelle, mais ceci doit être évité dans la mesure du possible car cela peut introduire un risque (une faille) souvent inutile. En tout état de fait, la réversibilité ne doit être possible uniquement pour le propriétaire des données (on peut l’obtenir en utilisant des fonctions de chiffrements, qui sont réversibles, et en conservant la clef secrète par exemple).
• Déterministe : permet de garantir que l’anonymisation d’une même valeur (d’un type donné) correspondra toujours à la même valeur anonymisée, ce qui est utile si le processus d’anonymisation est exécuté plusieurs fois sur des données dont seule une partie évolue.
• Surjectif : plusieurs valeurs peuvent être anonymisées en une même valeur, mais de manière déterministe (exemple : « Pierre » et « Paul » seront toujours anonymisées en « Jacques »). La bijectivité (qui garantit que chaque valeur sera anonymisée en une valeur distincte des autres, également de manière déterministe) peut sembler plus pertinente, par exemple pour garantir les caractéristiques statistiques des données, mais elle est souvent difficile à obtenir. La surjectivité est un bon compromis, généralement suffisant.
• Intelligible : permet d’obtenir une valeur anonymisée compréhensible par un humain. Certaines techniques d’anonymisation produisent une valeur inintelligible en sortie (hachage, chiffrement, remplacement aléatoire, etc), mais il est possible, en les combinant avec une autre technique (comme les tables de substitutions) de produire une valeur anonymisée intelligible.

Dans le cas d’une base de données (cas le plus courant), l’anonymisation peut être appliquée de différentes manières :

• Dans la base source elle-même : à éviter, car on perd les informations originelles, et les données anonymisées sont directement accessibles (via les interfaces de l’application), sans qu’elles ne passent par une phase de recette.
• Dans une copie de la base source, directement dans l’environnement cible. A éviter également, car les informations non anonymisées sont accessibles dans l’environnement cible, tant que l’anonymisation n’est pas réalisée.
• Dans une copie de la base source, cette copie devra être dans un environnement protégé (puisqu’elle contiendra les informations non anonymisées), puis recettée avant livraison en production ou externalisation. C’est de loin la meilleure solution.

On procédera de manière similaire pour anonymiser des documents, ou toute autre source d’informations.

Nous ne pouvons terminer ce tour d’horizon de l’anonymisation sans tenir compte des contraintes que l’on peut rencontrer. Elles sont principalement de deux types :

• Contraintes techniques : il s’agit par exemple des contraintes d’intégrité référentielle dans les bases de données (ce que l’on appelle les clefs étrangères), et d’autres contraintes (par exemple, dans le cas des bases de données relationnelles, on peut trouver des contraintes exprimées par des check, certains trigger, au niveau des procédures stockées, etc) ;
• Contraintes métiers : il s’agit de contraintes qui peuvent être exprimées au niveau de la base de données (dans ce cas elles deviennent également des contraintes techniques), mais qui sont parfois implémentées seulement au niveau de l’application utilisant la base de données, voire non formalisées (elles sont respectées par les utilisateurs, sans aucune vérification au niveau de l’application). Exemple de règle métier à respecter : la base anonymisée doit contenir la même proportion hommes/femmes que la base source, la moyenne d’âge doit être la même, les identifiants des clients doivent respecter la règle de construction « maison », les montants et sommes doivent être réalistes, les monnaies (ou les prénoms) doivent être cohérentes avec les pays, etc.

Comme on s’en doute, il existe un nombre infini de contraintes possibles, on ne peut donc qu’esquisser des pistes pour résoudre les problèmes qu’elles posent :

• Les contraintes techniques peuvent généralement être respectées par les outils d’anonymisation, donc par des solutions techniques. Ce n’est pas toujours aisé, mais cela dépend avant tout de la complexité du modèle physique de base de données. Le cas typique, les contraintes d’intégrité référentielle, peuvent être désactivées momentanément, puis réactivées à la fin du processus d’anonymisation. Cela implique bien entendu que les règles d’anonymisation respectent ces contraintes. Par exemple, si une clef (primaire) doit être anonymisée (formée d’un ou plusieurs champs), elle devra l’être partout où elle est utilisée comme clef étrangère.
• Les contraintes métiers sont plus complexes à respecter, car souvent non formalisées ou impossibles à récupérer ou interpréter depuis un logiciel :
  • Tout d’abord, il faut les identifier et les recenser ;
  • Ensuite, étudier, pour chacune, comment anonymiser les données tout en les respectant ;
  • Enfin, implémenter le mécanisme.

Pour terminer cet article, prenons le prénom « Paul », après hachage SHA-2 de ce prénom, on obtient une valeur complètement inintelligible (mais irréversible !) :

a6b54c20a7b96eeac1a911e6da3124a560fe6dc042ebf270e3676e7095b95652

Supposons que l’on dispose d’une table de substitutions de prénoms :

Si l’on prend le dernier caractère du haché de « Paul », c’est-à-dire 2, la table nous donne la correspondance « Oliver », qui sera le prénom anonymisé, mais intelligible (contrairement au haché SHA-2).

De plus, il sera irréversible, même s’il n’est pas impossible de trouver un autre prénom qui donnera la même valeur anonymisée (l’opération que nous venons de faire est surjective), mais cela n’est pas grave : l’essentiel est de ne pas pouvoir retrouver que « Paul » a produit « Olivier », et cela même en connaissant la technique utilisée et la table de substitution (et c’est effectivement irréversible, grâce à la fonction de hachage cryptographique, qui est sûre).

On peut aisément adapter ce type d’algorithme à d’autres types de données métiers :

• Pour une date, on peut hacher le jour, le mois et l’année, puis utiliser les derniers caractères (ou les premiers, à votre convenance) en les transformant en chiffres. En opérant un modulo 31 pour le jour, un modulo 12 pour le mois, un modulo 2015 pour l’année, et en vérifiant que la date est valide (exemples : pas de 31/04 quelle que soit l’année, tenir compte des années bissextiles pour le mois de février) et incluse dans une plage définie (par exemple entre 1900 et l’année courante), on obtiendra à peu de frais une date anonymisée, irréversible et réaliste.
• Si l’on doit garder une cohérence entre la date de naissance et l’âge de chaque individu, il suffit par exemple d’anonymiser la date de naissance (comme ci-dessus) puis calculer à quel âge cela correspond (l’âge sera donc implicitement anonymisé).
• Pour un numéro de sécurité sociale (de carte bleue, de permis de conduire, de compte bancaire…) : ces numéros suivent des règles assez simples (plages de valeurs pour certains groupes de chiffres, somme de contrôle à la fin), qu’il est aisé de respecter. Un hachage, suivi d’opérations de réductions des valeurs, et du calcul d’une somme de contrôle valide, permet de produire un numéro anonymisé, tout en respectant les contraintes métiers.

Il ne faut pas sous-estimer, ou pire négliger, un chantier d’anonymisation. Les conséquences juridiques, économiques, ou en matière de sécurité et d’image, peuvent être importantes.

A l’heure actuelle, aucune solution du marché n’offre toutes les techniques d’anonymisation (par exemple pour les documents numériques ET les données en bases), avec toutes les garanties recherchées (voir plus haut), la personnalisation complète des règles d’anonymisation et la possibilité de respecter les contraintes métiers. Il est d’ailleurs peu probable qu’une telle solution soit disponible un jour. En sécurité informatique, le pire étant de ne pas connaître, et pouvoir vérifier, les algorithmes utilisés (les mécanismes d’anonymisation). Certaines solutions sont libres (ou au moins  »open source »), mais les leaders du marché ne proposent généralement que des solutions fermées, dont la sécurité ne peut être vérifiée.

Cette liberté n’est possible qu’avec le développement d’un outil spécifique (pouvant s’appuyer sur des outils génériques de manipulation de données, tels que les outils d’ETL), entraînant un coût et un délai de réalisation. De plus, cela implique de disposer de ressources en développement logiciel, ayant de réelles compétences en cryptographie et sécurité, ce dont ne disposent pas toutes les entreprises (pour des raisons de coût notamment, ou simplement parce que ce n’est pas leur cœur de métier).

Avec une solution logicielle d’anonymisation du marché, les coûts de licences et de formation, ainsi que les délais de mise en place sont à mettre dans la balance pour pouvoir prendre une décision.