Principes de Base du Masquage Dynamique
Introduction
Ce document décrit comment DataSunrise implémente les principes du masquage de données dynamique pour les données sensibles à la volée et comment le masquage est effectué pour les types de bases de données SQL et NoSQL.
Principes du Masquage de Données
Commençons par le début et familiarisons-nous avec deux principes de base du masquage de données dans la base de données :
- Méthode de masquage basée sur la modification des ensembles de résultats de requête
- Méthode de masquage basée sur la modification de requêtes SQL
DataSunrise utilise les deux approches pour différents types de SGBD. DataSunrise modifie une requête SQL elle-même où cela est possible, et dans les SGBD qui ont peu de fonctionnalités linguistiques (par exemple, les bases de données NoSQL), la modification de l’ensemble de résultats est utilisée.
Examinons les avantages et les inconvénients des deux méthodes de masquage.
Méthode de Masquage Basée sur la Modification des Ensembles de Résultats de Requête
Avec cette approche, la base de données reçoit la requête originale et renvoie les données comme cela se produit généralement :
Tout semble assez simple et logique. Examinons maintenant les détails de cette approche :
Comment traiter les données renvoyées par la fonction ? Exemple de cas :
SELECT anyFunction(email) FROM customers;
Différentes méthodes de modification de chaîne telles que la concaténation ou la conversion d’une chaîne en minuscules/majuscules, l’obtention d’une sous-chaîne, etc. sont également liées à ce cas.
Il n’y a aucun moyen d’obscurcir les données qui n’ont pas été renvoyées à l’application cliente. Par exemple :
CREATE TABLE demotest.democust AS SELECT * FROM demotest.customers;
ou
INSERT INTO demotest.democust SELECT * FROM demotest.customers;
dans ces requêtes, les données sources seront enregistrées dans les tables créées, ce qui provoque une fuite de données.
Les applications clientes largement répandues utilisent rarement des requêtes isolées. Habituellement, les requêtes sont exécutées les unes après les autres et l’ensemble de résultats de la première requête est utilisé dans une seconde requête, et ainsi de suite. Si nous considérons un tel cas lorsque le champ clé est masqué, alors pour que l’application continue de fonctionner correctement, une modification de requête devient nécessaire. Par exemple, une application reçoit une liste d’adresses e-mail masquées qui est utilisée comme condition pour extraire des données :
SELECT * FROM demotest.customers WHERE email=’masked@email.com’;
SELECT * FROM demotest.customers WHERE email=?; -- ? représente une variable liée
Puisque la table ne contient pas une telle valeur d’e-mail, la logique de l’application cliente sera rompue. Parce qu’une application cliente attendra l’information par la clé-valeur que l’application cliente a reçue précédemment.
En conclusion, vous pouvez voir à partir des situations décrites, qu’il est compliqué (et parfois même impossible) de fournir la méthode de masquage de données qui n’affectera pas le processus de travail d’une application cliente.
Méthode de Masquage Basée sur la Modification de Requêtes SQL
Dans cette approche, le texte de la requête SQL est modifié. Des constructions spéciales sont intégrées dans la requête pour empêcher l’extraction de données sensibles de la base de données :
Dans un cas simple, la conversion ressemble à ceci :
SELECT email FROM customers -> SELECT ‘masqué’ FROM customers;
Ainsi, les données sensibles qui doivent être masquées ne quittent pas la base de données. Cela résout également tous les principaux problèmes d’obfuscation des données :
Les données déjà obfusquées sont fournies aux fonctions :
SELECT anyFunction(‘masqué’) FROM customers;
SELECT anyFunction(maskFunction(email)) FROM customers;
La même méthode d’obfuscation des données est possible pour les opérations effectuées en interne dans la base de données :
CREATE TABLE customers2 AS SELECT maskFunction(email) FROM customers;
Il est également possible de masquer les colonnes qui ont été spécifiées non seulement dans la partie select de la requête mais aussi dans la partie conditionnelle de la requête, par exemple where/join. Ainsi, la logique de travail de l’application cliente ne sera pas affectée.
Sections Principales de la Règle de Masquage de Données Dynamique
Dans cette section, nous fournirons des exemples de captures d’écran montrant comment ces paramètres affectent le processus de travail avec la base de données lorsque la règle de masquage dynamique est active.
Imaginons la situation où nous voulons que quelqu’un qui travaille avec la base de données et la table des clients ne voie pas les données de carte de crédit contenues dans la table.
Pour réaliser un tel scénario, nous utiliserons notre table de test qui contient différentes informations sur les clients :
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card FROM demotest.democust;
ORDER_ID FIRST_NAME LAST_NAME ADDRESS STATE ZIP EMAIL CARD
--------- ---------- --------- --------------------- ----- -------- ------------------- -------------------
1,121 Kathy Abrams High Street, Wheeling MO 132068 kitykatty@fugie.com 4024-0071-8423-6700
4,667 Alma Wade Green Lane, Newport NE 21771 almwa@nprt.com 6011-0551-9875-8094
3,427 Mary Evans 13 The Limes, Leighton OR 10950 evensmary@hitmail.com 4024-4392-7160-9980
3 lignes sélectionnées.
Comme vous pouvez le voir, nous avons 8 colonnes. Selon notre scénario, la colonne “card” devrait être masquée. Pour cela, une règle de masquage dynamique sera créée. Dans la configuration de la règle de masquage dynamique, il sera défini de masquer la colonne Carte en utilisant la méthode de masquage de carte de crédit intégrée. Jetons un œil rapide aux paramètres de la règle. Il y a des sections de la règle :
Section principale. Le nom de la règle, le type de base de données et la base de données elle-même y sont spécifiés.
Section des actions. Cette section contient les options mentionnées dans la liste. Nous changerons ces options en parcourant le scénario et suivrons comment les modifications affecteront les résultats et les performances des requêtes à la table des clients. Au départ, toutes les options seront laissées par défaut.
Section de filtrage de session et paramètres de masquage. Si des filtres sont spécifiés, la règle ne sera déclenchée que si la condition répond aux exigences. Dans tous les autres cas, la règle ne sera pas déclenchée. Puisque nous n’avons spécifié aucun filtre, la règle fonctionnera toujours sur n’importe quelle requête ciblée sur la table des clients.
De plus, la méthode de masquage de carte de crédit est choisie pour la colonne de la table des clients.
Maintenant, lorsque la règle est configurée, essayons d’effectuer la même requête pour sélectionner toutes les colonnes de la table des clients :
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card FROM demotest.democust; ORDER_ID FIRST_NAME LAST_NAME ADDRESS STATE ZIP EMAIL CARD --------- ---------- --------- --------------------- ----- -------- ------------------- ------------------- 1,121 Kathy Abrams High Street, Wheeling MO 132068 kitykatty@fugie.com XXXX-XXXX-XXXX-6700 4,667 Alma Wade Green Lane, Newport NE 21771 almwa@nprt.com XXXX-XXXX-XXXX-8094 3,427 Mary Evans 13 The Limes, Leighton OR 10950 evensmary@hitmail.com XXXX-XXXX-XXXX-9980 3 lignes sélectionnées.Comme vous pouvez le voir sur la capture d’écran, la colonne Carte a été masquée selon la configuration de la règle.
Principales Options de la Règle de Masquage de Données Dynamique
Colonnes à Masquer
C’est simple, ce paramètre est responsable des colonnes qui seront masquées.
Algorithme de Masquage
C’est l’algorithme qui sera utilisé pour masquer les colonnes. L’algorithme choisi affecte directement la valeur qui sera renvoyée lors de la tentative de récupération des valeurs des colonnes masquées.
Voici la liste des algorithmes de masquage qui peuvent être utilisés avec DataSunrise (pour être informé sur d’autres algorithmes de masquage, veuillez vous référer à notre Guide Utilisateur p. 148 où vous pouvez trouver des explications détaillées à ce propos) :
Numéro de Carte de Crédit – l’algorithme vise à masquer les numéros de carte de crédit. Il affiche les quatre derniers chiffres d’un numéro de carte de crédit, les autres caractères étant remplacés par “X”. Par exemple : XXXXXXXX-XXXX-1234.
Masquage de Courriel – la partie utilisateur et la section de domaine des adresses e-mails sont remplacées par “*”, sauf le premier et le dernier dans une rangée. Par exemple : a***@**.**m.
Chaîne Fixe – les valeurs du type STRING sont remplacées par une chaîne prédéfinie par l’utilisateur.
La suite de sécurité DataSunrise prend également en charge des fonctions personnalisées (fonctions spécifiées dans la base de données) à utiliser comme méthode de masquage et des scripts LUA qui sont créés directement dans l’environnement DataSunrise WebUI.
Filtrer la Session
Ce paramètre peut être spécifié pour configurer un comportement de règle de masquage dynamique selon différentes conditions. Voici la liste des paramètres de condition :
Application – nom de l’application cliente
Utilisateur de l’Application – nom de l’utilisateur de l’application
Utilisateur de la Base de Données – nom de l’utilisateur de la BDD
Hôte – adresse IP ou alias depuis lequel l’utilisateur ou l’application se connecte à la base de données
Utilisateur du Système d’Exploitation – nom de l’utilisateur du système d’exploitation
Proxy – proxy DataSunrise où la règle devrait fonctionner si plusieurs proxies ont été configurés
Par exemple, vous souhaitez masquer les données pour l’utilisateur invité de la base de données et vous ne souhaitez pas masquer les données pour l’utilisateur administrateur de la base de données, ce qui est compréhensible. Dans ce cas, vous spécifiez simplement Utilisateur de la BDD Équivaut à Invité et la règle de masquage sera déclenchée uniquement lorsque l’utilisateur invité effectue des requêtes sur les colonnes masquées de la table.
Conserver le Nombre de Lignes
Cette option est responsable du masquage des valeurs utilisées dans les clauses where, join etc. des requêtes :
lorsqu’elle est désactivée, les valeurs des champs qui doivent être masqués seront masquées même si elles sont utilisées dans la clause WHERE/JOIN.
lorsqu’elle est activée, le masquage des valeurs utilisées dans les clauses mentionnées sera désactivé. L’ensemble de résultats renvoyé contiendra le même nombre de lignes que celui qui serait renvoyé si aucune règle de masquage n’était appliquée. Cette option permet de recevoir le même nombre de lignes même si les données sont masquées parce que leurs valeurs réelles peuvent être utilisées dans les clauses WHERE/JOIN de la requête.
Pour comprendre la situation plus en profondeur, supposons que je connaisse une partie d’un numéro de carte et que ce soit 4024. Nous avons deux clients dont le numéro de carte de crédit contient ce nombre :
Kathy Abrams 4024-0071-8423-6700
Mary Evans 4024-0071-2955-9980
Voyons ce qui se passe si l’option est désactivée :
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card FROM demotest.democust WHERE card LIKE '%4024%'; aucune ligne sélectionnée.
La requête ne retournera aucun résultat car les résultats sont masqués et l’application ne peut pas trouver ces champs.
Voyons ce qui se passe si l’option est activée :
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card
FROM demotest.democust
WHERE card LIKE '%4024%';
ORDER_ID FIRST_NAME LAST_NAME ADDRESS STATE ZIP EMAIL CARD
--------- ---------- --------- --------------------- ----- -------- ------------------- -------------------
1,121 Kathy Abrams High Street, Wheeling MO 132068 kitykatty@fugie.com XXXX-XXXX-XXXX-6700
3,427 Mary Evans 13 The Limes, Leighton OR 10950 evensmary@hitmail.com XXXX-XXXX-XXXX-9980
2 lignes sélectionnées.
Comme vous pouvez le voir ici, même si les résultats sont masqués, nous pouvons toujours utiliser 4024 pour trouver des cartes contenant une telle partie, mais nous ne pouvons pas la voir dans l’ensemble de résultats.
Masquer Uniquement les SELECTs
Ce paramètre est responsable de la règle pour masquer les valeurs des colonnes spécifiées UNIQUEMENT si les données sont récupérées par le type de requête SELECT. Voyons comment cela fonctionne :
SQL> SELECT card FROM demotest.democust; CARD ------------------- XXXX-XXXX-XXXX-6700 XXXX-XXXX-XXXX-8094 XXXX-XXXX-XXXX-9980 3 lignes sélectionnées.
Comme vous pouvez le voir ici, les valeurs de carte ont été récupérées en utilisant l’instruction SELECT et, selon la règle, la colonne du numéro de carte est masquée.
Essayons maintenant d’exécuter la requête suivante et voyons ce qui se passe :
SQL> UPDATE demotest.democust SET state = card;
3 lignes mises à jour.
SQL> SELECT order_id, first_name, last_name, state, zip, card FROM demotest.democust;
ORDER_ID FIRST_NAME LAST_NAME STATE ZIP CARD
--------- ---------- --------- ------------------- -------- -------------------
1,121 Kathy Abrams 4024-0071-8423-6700 132068 XXXX-XXXX-XXXX-6700
4,667 Alma Wade 6011-0551-9875-8094 21771 XXXX-XXXX-XXXX-8094
3,427 Mary Evans 4485-4392-7160-9980 10950 XXXX-XXXX-XXXX-9980
3 lignes sélectionnées.
Comme vous pouvez le voir, la colonne “state” a maintenant les valeurs réelles de la colonne masquée “card”, car ce n’est pas le type de requête SELECT qui a été effectué. Cependant, si un type de requête SELECT est exécuté pour la colonne masquée, elle sera toujours masquée.
Bloquer une Requête Lorsqu’elle est Liée à une Modification de Données Majeure
L’objectif de ce paramètre est expliqué par son nom. C’est aussi une case à cocher qui est cochée par défaut lors de la création d’une règle de masquage dynamique. Dans le cas où une requête arrive au proxy DataSunrise et qu’une requête est destinée à changer la valeur dans la colonne masquée, une telle requête sera bloquée. Essayons d’exécuter une requête qui visera à modifier un numéro de carte en utilisant la requête suivante :
SQL> UPDATE demotest.democust SET card = '1234' WHERE card LIKE '%6700%'; ERREUR à la ligne 1 : Erreur SQL [42501] : La requête est bloquée
En conséquence, il est retourné “La requête est bloquée”.
Conclusion
La fonctionnalité de masquage dynamique est l’une des fonctionnalités les plus utilisables de notre produit. Cette fonctionnalité aide à masquer les données sensibles de la base de données protégée selon la configuration de la règle définie par l’utilisateur.
DataSunrise utilise les approches les plus appropriées pour masquer les données sensibles en choisissant la meilleure solution pour les bases de données basées sur SQL ainsi que pour les bases de données NoSQL.
Les règles de masquage dynamique ont de nombreuses options qui peuvent être configurées par un utilisateur. Les plus significatives de celles-ci sont :
- Conserver le Nombre de Lignes option est responsable de retourner le même nombre de lignes retournées par une requête comme il serait retourné si aucune règle de masquage n’était configurée. Si cette option est active, la partie conditionnelle d’une requête qui est utilisée pour filtrer les données en utilisant des clauses where/join/etc. ne sera pas masquée. Cette option est importante pour ceux qui utilisent des applications clientes et ne veulent pas voir un nombre différent de lignes retournées par une requête lorsque la règle de masquage est active.
- Masquer Uniquement les SELECTs option est responsable de masquer uniquement les parties select d’une requête. Si cette option est active, seules les colonnes qui se trouvent après l’instruction SELECT et sont spécifiées dans la règle seront masquées. Cette option est également importante pour ceux qui utilisent des applications clientes qui effectuent des requêtes générées automatiquement, par exemple pour les instructions UPDATE TABLE. Parce que toutes les opérations avec les données de la table masquée ne seront pas affectées de quelque façon que ce soit mais seront vues masquées si les données sont sélectionnées.
- Bloquer une Requête Lorsqu’elle est Liée à une Modification de Données option est responsable du blocage de toute opération qui affecte la colonne masquée de quelque manière que ce soit. Si une colonne masquée est mentionnée dans une partie quelconque de la requête elle-même, la requête sera bloquée. Cette option est importante pour ceux qui ne veulent pas perdre des données sensibles par accident ou par intention.