Masquage dynamique des données dans l’entrepôt de données Fabric

S’applique à : point de terminaison d’analytique SQL et entrepôt dans Microsoft Fabric

Le masquage des données dynamiques limite l’exposition des données sensibles en les masquant pour les utilisateurs sans privilège. Il peut être utilisé pour simplifier considérablement la conception et le codage de la sécurité dans votre application.

Le masquage dynamique des données permet d'empêcher l'affichage non autorisé des données sensibles en permettant aux administrateurs de spécifier la quantité de données sensibles à révéler, avec un effet minimal sur la couche d'application. Le masquage dynamique des données peut être configuré sur des champs de base de données désignés pour masquer les données sensibles dans les ensembles de résultats des requêtes. Avec le masquage dynamique des données, les données de la base de données ne sont pas modifiées et peuvent donc être utilisées avec des applications existantes puisque les règles de masquage sont appliquées aux résultats des requêtes. De nombreuses applications peuvent masquer des données sensibles sans modifier les requêtes existantes.

  • Une stratégie de masquage des données centrale agit directement sur les champs sensibles de la base de données.
  • Désignez les utilisateurs ou les rôles privilégiés qui ont accès aux données sensibles.
  • Le masquage dynamique des données a des fonctions de masquage complet et partiel, ainsi qu’un masque aléatoire pour les données numériques.
  • Des commandes Transact-SQL simples définissent et gèrent les masques.

Le masquage des données dynamiques vise à limiter l’exposition des données sensibles, en empêchant les utilisateurs qui ne doivent pas pouvoir y accéder de les consulter. En revanche, le masquage des données dynamiques n’a pas pour but d’empêcher des utilisateurs d’une base de données de se connecter directement à celle-ci ou d’exécuter des requêtes exhaustives ayant pour effet d’exposer des éléments de données sensibles.

Le masquage dynamique des données est complémentaire des autres fonctionnalités de sécurité de Fabric comme la sécurité au niveau des colonnes et la sécurité au niveau des lignes. Il est vivement recommandé d’utiliser ces fonctionnalités de protection des données ensemble pour protéger les données sensibles de la base de données.

Définir un masque de données dynamique

Il est possible de définir une règle de masquage sur une colonne d’une table, afin de masquer les données qui y figurent. Quatre types de masques sont disponibles.

Fonction Description Examples
Par défaut Masquage complet en fonction des types de données des champs désignés.

Pour les données de type chaîne (string), utilisez XXXX (ou moins) si la taille du champ est inférieure à 4 caractères (char, nchar, varchar, nvarchar, text, ntext).

Pour les données de type numérique, utilisez une valeur zéro (bigint, bit, decimal, int, money, numeric, smallint, smallmoney, tinyint, float, real).

Pour les données de type date et heure, utilisez 1900-01-01 00:00:00.0000000 (date, datetime2, datetime, datetimeoffset, smalldatetime, time).

Pour les données de type binaire, utilisez un seul octet de valeur ASCII 0 (binary, varbinary, image).
Exemple de syntaxe de définition de colonne : Phone# varchar(12) MASKED WITH (FUNCTION = 'default()') NULL

Exemple de syntaxe alter : ALTER COLUMN Gender ADD MASKED WITH (FUNCTION = 'default()')
Email Méthode de masquage qui affiche la première lettre d’une adresse de messagerie et le suffixe de constante « .com », sous la forme d’une adresse de messagerie. aXXX@XXXX.com. Exemple de syntaxe de définition : Email varchar(100) MASKED WITH (FUNCTION = 'email()') NULL

Exemple de syntaxe alter : ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()')
Random Fonction de masquage aléatoire à utiliser sur tout type de données numérique pour masquer la valeur d’origine à l’aide d’une valeur aléatoire dans une plage spécifiée. Exemple de syntaxe de définition : Account_Number bigint MASKED WITH (FUNCTION = 'random([start range], [end range])')

Exemple de syntaxe alter : ALTER COLUMN [Month] ADD MASKED WITH (FUNCTION = 'random(1, 12)')
Chaîne personnalisée Méthode de masquage qui affiche les première et dernière lettres, et ajoute une chaîne de remplissage personnalisée au milieu. prefix,[padding],suffix

Si la valeur d’origine est trop courte pour occuper la totalité du masque, une partie du préfixe ou du suffixe n’est pas exposée.
Exemple de syntaxe de définition : FirstName varchar(100) MASKED WITH (FUNCTION = 'partial(prefix,[padding],suffix)') NULL

Exemple de syntaxe alter : ALTER COLUMN [Phone Number] ADD MASKED WITH (FUNCTION = 'partial(1,"XXXXXXX",0)')

Cela transforme un numéro de téléphone comme 555.123.1234 en 5XXXXXXX.

Autre exemple :

ALTER COLUMN [Phone Number] ADD MASKED WITH (FUNCTION = 'partial(5,"XXXXXXX",0)')

Cela transforme un numéro de téléphone comme 555.123.1234 en 555.1XXXXXXX.

Pour plus d’exemples, consultez Comment implémenter un masquage dynamique des données dans Synapse Data Warehouse.

Autorisations

Les utilisateurs sans les droits Administrateur, Membre ou Contributeur sur l’espace de travail, et sans autorisations élevées sur l’entrepôt, voient les données masquées.

Vous n’avez pas besoin d’autorisation spéciale pour créer une table avec un masque de données dynamiques. Les autorisations de schéma standard CREATE TABLE et ALTER suffisent.

Pour ajouter, remplacer ou supprimer le masque d’une colonne, vous devez disposer des autorisations ALTER ANY MASK et ALTER sur la table. Il convient d’octroyer l’autorisation ALTER ANY MASK à un responsable sécurité.

Les utilisateurs disposant de l’autorisation SELECT sur une table peuvent afficher les données de celle-ci. Les colonnes définies comme masquées affichent alors les données masquées. Accordez l’autorisation UNMASK à un utilisateur pour lui permettre de récupérer les données non masquées de colonnes pour lesquelles un masquage est défini.

L’autorisation CONTROL sur la base de données inclut les autorisations ALTER ANY MASK et UNMASK permettant à l’utilisateur d’afficher les données non masquées. Les utilisateurs administratifs ou les rôles tels qu’Administrateur, Membre ou Contributeur disposent d’une autorisation CONTROL sur la base de données par conception et peuvent afficher les données non masquées par défaut. Les autorisations élevées sur l’entrepôt incluent l’autorisation CONTROL.

Considération de sécurité : ignorer le masquage à l’aide de techniques d’inférence ou de force brute

Le masquage dynamique des données est conçu pour simplifier le développement d’applications en limitant l’exposition des données dans un ensemble de requêtes prédéfinies utilisées par l’application. Bien que le masquage dynamique des données puisse également s’avérer utile pour empêcher une exposition accidentelle des données sensibles lorsque vous accédez directement aux données, il est important de noter que les utilisateurs non privilégiés bénéficiant d’autorisations de requête peuvent appliquer des techniques pour accéder aux données réelles.

Par exemple, considérez un utilisateur qui dispose de privilèges suffisants pour exécuter des requêtes sur l’entrepôt et essaie de « deviner » les données sous-jacentes, pour enfin déduire les valeurs réelles. Supposons que nous disposons d’un masque défini sur la colonne [Employee].[Salary], et que cet utilisateur se connecte directement à la base de données et commence à deviner les valeurs, pour enfin déduire la valeur [Salary] dans la table Employees :

SELECT ID, Name, Salary FROM Employees
WHERE Salary > 99999 and Salary < 100001;

Retourne comme résultat :

Récompenses client Nom Salaire
62543 Jane Doe 0
91245 John Smith 0

Cela montre que le masquage dynamique des données ne doit pas être utilisé seul pour sécuriser entièrement les données sensibles des utilisateurs disposant d’un accès aux requêtes à l’entrepôt ou au point de terminaison d’analytique SQL. La fonctionnalité convient pour empêcher une exposition des données sensibles, mais elle ne protège pas contre des intentions malveillantes de déduire les données sous-jacentes.

Il est important de gérer correctement la sécurité au niveau des objets avec des autorisations granulaires SQL et de suivre toujours le principe minimal des autorisations requises.

Étape suivante