Principes de Base du Masquage Dynamique
Introduction
Ce document décrit comment DataSunrise masque 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 du 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êtes
- Méthode de masquage basée sur la modification des requêtes SQL
DataSunrise utilise les deux approches pour différents types de SGBD. DataSunrise modifie une requête SQL elle-même lorsque cela est possible, et dans les SGBD qui ont peu de fonctionnalités linguistiques (par exemple, les bases de données NoSQL), la modification des ensembles de résultats est utilisée.
Examinons maintenant 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êtes
Avec cette approche, la base de données reçoit la requête originale et renvoie les données comme cela se produit habituellement :
Tout semble suffisamment simple et logique. Regardons maintenant les détails de cette approche :
Comment traiter les données retournées par la fonction ? Par exemple :
SELECT anyFunction(email) FROM customers;
Différentes méthodes de modification de chaîne telles que la concaténation ou le passage en minuscules/majuscules, l’obtention d’une sous-chaîne, etc. sont également liées à ce cas.
Il n’existe aucun moyen d’obscurcir des 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 sauvegardées dans les tables créées, ce qui entraîne une fuite de données.
Les applications clientes largement utilisées 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 où 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 récupérer des données :
SELECT * FROM demotest.customers WHERE email='[email protected]';
SELECT * FROM demotest.customers WHERE email=?; -- ? représente une variable liée
Étant donné que 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 valeur-clé que l’application cliente a reçue précédemment.
En conclusion, vous pouvez voir à partir des situations décrites, qu’il s’agit d’un objectif compliqué (et parfois même impossible) d’élaborer une méthode de masquage des données qui n’affectera pas le processus de travail d’une application cliente.
Méthode de Masquage Basée sur la Modification des Requêtes SQL
Dans cette approche, le texte de la requête SQL est modifié. Des constructions spéciales sont intégrées à la requête qui empêchent l’extraction de données sensibles de la base de données :
Dans le cas simple, la conversion ressemble à cela :
SELECT email FROM customers -> SELECT ‘masked’ FROM customers;
Par conséquent, les données sensibles qui devraient être masquées ne quittent pas la base de données. Cela résout également tous les principaux problèmes d’obscurcissement des données :
Des données déjà obscurcies sont fournies aux fonctions :
SELECT anyFunction('masked') FROM customers;SELECT anyFunction(maskFunction(email)) FROM customers;
La même méthode d’obscurcissement 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 e.g. where/join. Ainsi, la logique de fonctionnement de l’application cliente ne sera pas affectée.
Sections Principales de la Règle de Masquage Dynamique des Données
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 qu’une personne travaillant 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 exécuter 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 [email protected] 4024-0071-8423-6700
4,667 Alma Wade Green Lane, Newport NE 21771 [email protected] 6011-0551-9875-8094
3,427 Mary Evans 13 The Limes, Leighton OR 10950 [email protected] 4024-4392-7160-9980
3 rows selected.
Comme vous pouvez le voir, nous avons 8 colonnes. Selon notre scénario, la colonne “card” doit être masquée. Pour ce faire, une règle de masquage dynamique sera créée. Dans la configuration de la règle de masquage dynamique, elle sera réglée pour masquer la colonne Carte en utilisant la méthode de masquage de carte de crédit intégrée. Jetons un coup d’œ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 sont spécifiés ici.
Section Action. Cette section contient les options qui ont été mentionnées dans la liste. Nous allons modifier ces options au fur et à mesure que nous avançons dans le scénario et suivre comment les changements affecteront les résultats et les performances des requêtes à la table des clients. Au début, 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 respecte les exigences. Dans tout autre cas, la règle ne sera pas déclenchée. Étant donné que nous n’avons spécifié aucun filtre, la règle fonctionnera toujours sur toute requête ciblant la table des clients.
En outre, la méthode de masquage de la carte de crédit est choisie pour la colonne de la table des clients.
Maintenant, lorsque la règle est configurée, essayons d’exécuter 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 [email protected] XXXX-XXXX-XXXX-6700 4,667 Alma Wade Green Lane, Newport NE 21771 [email protected] XXXX-XXXX-XXXX-8094 3,427 Mary Evans 13 The Limes, Leighton OR 10950 [email protected] XXXX-XXXX-XXXX-9980 3 rows selected.Comme vous pouvez le voir sur la capture d’écran, la colonne Carte a été masquée selon la configuration de la règle.
Options Principales de la Règle de Masquage Dynamique des Données
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 le masquage de la colonne. L’algorithme choisi affecte directement la valeur qui sera retournée lors de la tentative d’extraction des valeurs des colonnes masquées.
Voici la liste des exemples d’algorithmes de masquage qui pourraient être utilisés avec DataSunrise (pour vous informer sur d’autres algorithmes de masquage, veuillez vous référer à notre Guide Utilisateur p. 148 où vous pouvez trouver une clarification détaillée sur ceux-ci) :
Numéro de Carte de Crédit – algorithme destiné à 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 sont remplacés par “X”. Par exemple : XXXXXXXX-XXXX-1234.
Masquage d’E-mail – la section nom d’utilisateur et domaine des adresses e-mail est remplacée par “*”, à l’exception du premier et du dernier dans une rangée. Par exemple : a***@**.**m.
Chaîne Fixe – les valeurs de 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 (des fonctions spécifiées dans la base de données) pour être utilisées comme méthode de masquage et des scripts LUA qui sont créés directement dans l’environnement WebUI de DataSunrise.
Filtrer la Session
Ce paramètre peut être spécifié pour configurer le comportement de la 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 DB – nom de l’utilisateur DB
Hôte – adresse IP ou alias à partir duquel l’utilisateur ou l’application se connecte à la base de données
Utilisateur OS – nom de l’utilisateur du système d’exploitation
Proxy – proxy DataSunrise où la règle doit fonctionner en cas de configuration de plusieurs proxys
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 DB User Equals Guest et la règle de masquage ne sera déclenchée que lorsque l’Utilisateur Invité exécute des requêtes sur des colonnes masquées de la table.
Maintenir le Nombre de Lignes
Cette option est responsable du masquage des valeurs utilisées dans les clauses where, join etc. des requêtes :
quand désactivé, les valeurs des champs qui devraient être masquées seront masquées même si elles sont utilisées dans la clause WHERE/JOIN.
quand activé, le masquage des valeurs utilisées dans les clauses mentionnées sera désactivé. Le jeu de résultats renvoyé contiendra le même nombre de lignes que ce qui serait renvoyé si aucune règle de masquage n’était appliquée. Cette option aide à obtenir le même nombre de lignes même si les données sont masquées car 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 c’est 4024. Nous avons deux clients dont le numéro de carte de crédit contient ce numéro :
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 renverra 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 [email protected] XXXX-XXXX-XXXX-6700
3,427 Mary Evans 13 The Limes, Leighton OR 10950 [email protected] XXXX-XXXX-XXXX-9980
2 rows selected.
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 le jeu de résultats.
Masquer les SELECTs uniquement
Ce paramètre est responsable de masquer les valeurs des colonnes spécifiées UNIQUEMENT si les données sont extraites par le type de requête SELECT. Regardons comment cela fonctionne :
SQL> SELECT card FROM demotest.democust; CARD ------------------- XXXX-XXXX-XXXX-6700 XXXX-XXXX-XXXX-8094 XXXX-XXXX-XXXX-9980 3 rows selected.
Comme vous pouvez le voir ici, les valeurs de carte ont été extraites 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 rows updated.
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 rows selected.
Comme vous pouvez le voir, la colonne “state” a maintenant les valeurs réelles de la colonne masquée “card”, car ce n’était pas un type de requête SELECT 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 Lorsque la Colonne Masquée est Liée à une Modification de Données
L’objectif de ce paramètre est expliqué par son nom. Il s’agit également d’une case à cocher qui est cochée par défaut lors de la création d’une règle de masquage dynamique. En cas de requête allant au proxy DataSunrise et qu’une requête vise à modifier la valeur dans la colonne masquée, cette requête sera bloquée. Essayons d’effectuer 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%'; ERROR at line 1: SQL Error [42501]: La requête est bloquée
En résultat, il est retourné “La requête est bloquée”.
Conclusion
La fonctionnalité de Masquage Dynamique est l’une des fonctionnalités les plus utilisées de notre produit. Cette fonctionnalité aide à masquer les données sensibles de la base de données protégée conformément à la configuration de la règle que l’utilisateur a définie.
DataSunrise utilise les approches les plus appropriées pour masquer les données sensibles en choisissant la meilleure solution tant pour les bases de données basées sur SQL 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 :
- Option Keep Row Count est responsable du retour du même nombre de lignes renvoyées par une requête que celui qui serait renvoyé s’il n’y avait pas de règle de masquage 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 where/join/etc. clauses ne sera pas masquée. Cette option est importante pour ceux qui utilisent des applications clientes et ne veulent pas voir un nombre de lignes différent renvoyé par une requête lorsque la règle de masquage est active.
- Option Mask SELECTs only est responsable du masquage uniquement des parties select d’une requête. Si cette option est active, seules les colonnes qui suivent l’instruction SELECT et qui 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, 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 manière que ce soit, mais seront masquées si les données sont sélectionnées.
- Option Block a Query When the Masked Column Related to a Data Modification 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 de la requête elle-même, la requête sera bloquée. Cette option est importante pour ceux qui ne veulent pas perdre de données sensibles par accident ou intentionnellement.