Un plan de masquage des données approfondi et bien pensé garantit une sécurité maximale et conserve la plus grande valeur commerciale.
L'utilisation des directives de meilleures pratiques suivantes garantira que le masquage des données aboutira à des données sensibles sécurisées.
Le tableau des responsabilités#data-masking détaille les étapes qui sont de la responsabilité du client et celles qui sont de celle de cegedim.cloud.
Créez un catalogue de chaque source de données. Documentez les types d'informations suivants :
Accès à partir de : onshore, offshore, ou les deux.
Utilisation : développement, AQ, tests, formation ou autres types d'utilisation.
Type de base de données : Oracle, MS SQL Server, IMS, DB2 for z ou autres bases de données.
Mouvement des données : liste des flux de données dans l'environnement.
Fréquence d'actualisation : annuelle, trimestrielle, ad hoc, ou autres intervalles.
Propriétaires : propriétaires de la base de données et de l'application.
Niveau de risque : élevé, moyen ou faible.
Il est également important de définir quelles réglementations s'appliquent à l'organisation cliente et de déterminer le type de données sensibles ou confidentielles pour l'entreprise.
Recherchez quelles réglementations s'appliquent au projet de masquage (ex : GDPR, HDS, etc.) et assurez-vous que les obligations connexes ont été exécutées (ex : informer la personne concernée, ajouter le processus au registre des activités de traitement, réaliser une analyse d'impact sur la protection des données (DPIA) si nécessaire, etc.)
Désignez une personne ayant une bonne connaissance des problèmes de confidentialité de la base de données du projet. Cette personne doit avoir une bonne connaissance de la base de données à masquer, de ses dépendances et des contraintes d'intégrité qu'elle contient.
Il peut s'agir par exemple du responsable du projet, ou de l'administrateur de la base de données, à condition qu'il dispose d'informations suffisantes sur le contexte de la confidentialité.
Cette personne sera le point de contact privilégié pour compléter les informations concernant l'expression des besoins et le fichier contenant les informations sur le projet.
Définir une liste de domaines de données sensibles ou confidentielles, comme le nom, le prénom, la carte de crédit, etc. Décrire les caractéristiques de chaque domaine de données, notamment le type de données probable, la sensibilité des données, les descriptions et les modèles de données et de métadonnées. Cette étape garantit la collaboration entre les entreprises, la sécurité, la gouvernance des données et l'informatique.
Identifier les contraintes d'identité dans la base de données : les contraintes telles que les clés étrangères doivent être identifiées pour que le travail de masquage puisse être effectué.
Certaines informations sont nécessaires avant d'effectuer les travaux de masquage.
Type de masquage : In-Place ou In-Stream
In-Place : une seule base de données. Le masquage est effectué sur la base de données.
In-Stream : Il s'agit du type de masquage le plus couramment utilisé. Il implique deux bases de données : une "source" contenant les données que le client veut masquer, et une base de données vide de destination. Le masquage est effectué "à la volée" pendant la copie des données de la base de données source vers la base de données de destination. La base de données de destination doit être vide.
Complexité : Simple, Moyen ou Complexe. Ces catégories représentent la difficulté globale de mise en œuvre du projet de masquage. Elle dépend directement de la complexité de la base de données. Il tient également compte du fait que les spécifications de masquage nécessitent des paramètres personnalisés (règles ou dictionnaires de masquage).
Type de base de données : Oracle, MS SQL Server, IMS, DB2 for z ou autres bases de données.
Afin d'effectuer le masquage, nous devons comprendre comment le client souhaite que les données soient masquées.
Pour ce faire, le client doit définir pour chaque colonne de chaque table de la base de données quelle "règle de masquage" il souhaite voir appliquer. Une règle de masquage est appliquée à une ligne.
Par exemple, le client peut utiliser les techniques suivantes :
Réduire à néant les données hautement sensibles
Utiliser une substitution répétable non unique (basée sur des dictionnaires).
Utiliser le masquage aléatoire avec une plage (pour une valeur numérique)
Utiliser des techniques spéciales (masquage de carte de crédit, masquage d'adresse IP, etc.)
Des règles de masquage personnalisées peuvent être définies pour répondre aux besoins de projets complexes.
La conception de règles de masquage peut nécessiter des explications détaillées (voir la colonne "spécification avancée des règles de masquage"), plus de temps et plus d'échanges d'informations entre les deux parties.
Ces informations seront nécessaires pour la mise en œuvre des règles de masquage. Le client doit remplir le document joint "spécification" donné en annexe 1. Il doit contenir toutes les informations nécessaires à la mise en place des règles de masquage : tables, colonnes, description du masquage que le client souhaite effectuer, règle de masquage correspondante à appliquer, demandes spécifiques (ex : règle de masquage personnalisée, bijection du masquage).
Le livrable est la base de données contenant les données masquées. Comme cegedim.cloud n'a pas d'accès direct à la base de données, il appartient au client de mettre en place des règles de validation pour vérifier que toutes les données sensibles sont masquées dans l'environnement de non-production selon les spécifications souhaitées.
| Complexité | Nombre de colonnes | Complexité du masquage |
|---|---|---|
Simple
< 10
Seulement des règles de masquage préexistantes, peu de règles de masquage différentes
Moyen
> 10 et < 20
Complexe
> 20
règles de masquage spécifiques, nombreuses contraintes (clé étrangère, etc.), dictionnaires spécifiques
La solution Data Masking transforme les données sensibles contenues dans les bases de données en données moins sensibles, selon vos propres spécifications et besoins.
La solution permet aux entreprises d'utiliser ces données tout en réduisant l'impact des violations de données. Elle offre une réponse aux questions de sécurité et de réglementation (par exemple, le RGPD).
Une quantité importante de techniques de masquage et des paramètres de pseudonymisation efficaces sont utilisables tout en conservant la cohérence des données.
La solution est adaptable et couvre une grande variété de types de bases de données telles que Oracle, DB2, SQL Server, MySQL, MongoDB, Sybase, Teradata.
Pour bénéficier de ce service, veuillez contacter votre Service Delivery Manager pour évaluer la complexité de la base de données à pseudonymiser et le devis correspondant.
Le service Data Masking s'appuie sur TDM (Test Data Management).
Un dictionnaire est un fichier plat ou une table relationnelle qui contient des données de substitution et un numéro de série. Les dictionnaires peuvent être utilisés pour remplacer des données sensibles dans une table.
Divers dictionnaires existent déjà dans TDM (prénom, nom, noms de pays, poste, etc.). Les dictionnaires peuvent être utilisés dans les règles de masquage afin de créer des règles de masquage par substitution.
Des dictionnaires personnalisés peuvent être importés ou créés :
Si les résultats doivent contenir des données spécifiques. Exemple : pour le prénom, seulement un sous-ensemble du nom de la liste ; pour le pays, seulement le pays de l'UE, etc.
Si les dictionnaires ne correspondent pas aux spécifications d'un projet
Les règles de masquage sont des outils utilisés pour masquer les données. Différents types de règles de masquage peuvent être définis et de nombreuses règles de masquage existent par défaut.
Exemple de propriétés de la règle de masquage :
Une sortie répétable renvoie une valeur déterministe à chaque fois que les valeurs de la source et de la graine sont les mêmes. Cela dépend de la semence, qui peut être modifiée à volonté.
Substitution unique : les données renvoient une valeur unique pour chaque entrée et graine unique.
Dictionnaire : dictionnaire utilisé dans la règle
Valeur masquée : détermine la valeur qui sera masquée dans la base de données (et quelle colonne est "appliquée").
Colonne de consultation : pour les règles plus avancées, définit une condition de consultation qui peut être utilisée pour déclencher des résultats conditionnels.
colonne Numéro de série : identifiant utilisé par l'application (transparent pour l'utilisateur)
Des règles de masquage personnalisées avancées peuvent être créées si nécessaire.
Exemples :
Règle de masquage basée sur plusieurs entrées. Ex : concaténation prénom + nom de famille
Règle de masquage avancée combinant plusieurs règles de masquage. Ex : masquage d'un champ à l'aide de différents dictionnaires en fonction du contenu d'un autre champ de la base de données.
Vous trouverez ci-dessous quelques techniques de masquage non exhaustives :
Substitution : Remplace une colonne de données par des données similaires provenant d'un dictionnaire
Randomisation : Produit des résultats aléatoires pour les mêmes données sources et règles de masquage
Floutage : Renvoie une valeur aléatoire proche de la valeur originale
Clé : Produit des résultats déterministes pour les mêmes données sources, règle de masquage et valeur de départ
Expression : Applique une expression aux données et renvoie les données masquées ou modifiées. Exemple : concaténation
Nullification : Remplacer une colonne ou une donnée par une valeur nulle
Cryptage : Transformer des données en données inintelligibles à l'aide d'un algorithme cryptographique et d'une clé définie.
Carte de crédit : Applique une technique intégrée pour déguiser le numéro de carte de crédit
Adresse IP : Applique une technique intégrée pour déguiser l'adresse IP
Téléphone : Applique une technique intégrée pour déguiser le numéro de téléphone
Courriel : Applique une technique intégrée pour déguiser l'adresse électronique
Shuffle : Applique des valeurs de colonnes sensibles au hasard d'une ligne à une autre dans le même tableau
Advanced : Applique une technique de masquage personnalisable à plusieurs colonnes d'entrée et de sortie.
Un projet est une entité qui définit le lien entre les règles de masquage et les bases de données.
Connexions aux projets : Chaque projet est associé à une (en cas de masquage en place) ou plusieurs (en cas de masquage en flux) bases de données en utilisant des connexions (ex : oracle jdbc string).
Mappage des règles : Une fois créées, les règles peuvent être mises en correspondance avec les entrées de la base de données dans "Projets". Pour chaque colonne qui doit être masquée, une règle de masquage est ajoutée :
Une fois que tous les attributs de cartographie ont été saisis en fonction des besoins du client, le projet peut être lancé.
Exécution du travail : Chaque projet peut être exécuté pour effectuer le masquage. L'opération de masquage est appelée "travail". Pendant un travail, l'application TDM effectue le masquage de la base de données "à la volée". La base de données n'est pas stockée localement sur le nœud de travail, ni conservée dans l'application.
Les nœuds désignent la machine virtuelle sur laquelle le travail est effectué. Pour chaque client, un nœud est créé. Les performances du nœud dépendent de la complexité du travail de masquage.
Différents types de masquage peuvent être réalisés en fonction des bases de données utilisées :
In-Stream : Il s'agit du type de masquage le plus couramment utilisé. Elle implique deux bases de données : une "source" contenant les données que vous voulez masquer, et une base de données vide de destination. Le masquage est effectué "à la volée" pendant la copie des données de la base de données source vers la base de données de destination. La base de données de destination doit être vide.
In-place : une seule base de données. Le masquage est effectué sur la base de données.
