Introduction détaillée au masquage dynamique SQLServer (exemple de code)

Le contenu de cet article est une introduction détaillée (exemple de code) sur le masquage dynamique SQL Server. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. . a aidé.

Le masquage dynamique des données (DDM) est une nouvelle fonctionnalité introduite dans SQL Server 2016. Le but est d’empêcher les personnes sans autorisation de consulter certaines informations privées. Les utilisateurs administrateurs peuvent décider quels champs doivent être masqués, alors comment peuvent-ils être masqués sans modifier le code de l'application ? Il est également nécessaire de s’assurer que quelle que soit la manière dont les données sont accessibles, elles sont cohérentes.

Il s'agit d'une fonctionnalité introduite pour la première fois dans Azure SQL Database, elle est testée par les utilisateurs sur le cloud et a été migrée vers le produit sur site. Je pense que de nombreuses autres nouvelles fonctionnalités suivront cette approche (cloud-local).

Il convient de noter que comme ma précédente sécurité des données au niveau des lignes, il s'agit de contenus liés à la sécurité des données (cours recommandés : Tutoriel MySQL)

colonne Données Masquage

Commencez par créer un tableau avec une version masquée de certaines données. Je vais ajouter un masque à l'un des champs commençant dans la définition de la table. Notez que la façon de procéder consiste à utiliser le format "mask with()" après le type de données, mais avant les options NULL et par défaut, entre parenthèses, incluez FUNCTION = ", qui spécifie notre fonction. À l'intérieur des guillemets, nous spécifions le mask. L'instruction CREATE TABLE est la suivante

CREATE TABLE MyTable
  ( MySSN VARCHAR (10) MASKED WITH (FUNCTION = 'default()') DEFAULT ('0000000000' )
 , MyName VARCHAR (200) DEFAULT ( ' ')
 , MyEmail VARCHAR (250) DEFAULT ( '')
 , MyInt int
)
GO
INSERT dbo. MyTable
 ( MySSN , MyName, MyEmail , MyInt)
VALUES
 ( '1234567890', 'Steve Jones', 'SomeSteve@SomeDomain.com', 10 )

Si le créateur interroge cette table, j'obtiens toutes les données lorsqu'elle est insérée. Un utilisateur avec des privilèges De même que ceux avec les privilèges dbo (rôle db_owner ou sysadmin). ) ne verra pas les données masquées. Créez maintenant un utilisateur normal sans privilèges élevés. Bien sûr, je dois accorder les privilèges SQL Server normaux pour afficher les données dans la table

CREATE USER mytest WITHOUT LOGIN
GRANT SELECT ON mytable TO mytest

Nous pouvons maintenant interroger. ce tableau avec cet utilisateur et voyez quelle est la différence.

Nous pouvons voir la différence avec la première colonne contenant les données masquées. pour masquer les données des utilisateurs non privilégiés. Notez que les données ne sont pas modifiées sur le disque uniquement lorsqu'elles sont renvoyées aux utilisateurs non privilégiés
Je peux voir cela se produire dans la dernière partie du plan d'exécution que je dois donner. autorisation de l'utilisateur pour afficher le plan, mais lorsque je fais cela, je vois le plan de l'utilisateur, en utilisant la même requête que ci-dessus

Je peux définir d'autres types de masques sur. le tableau, celui qui permet de contrôler ce qui est affiché. Le masquage des adresses email, et un masque de nombre aléatoire Nous en parlerons en détail dans un autre article

Il est désormais possible d'ajouter un masque à une autre colonne. , comme la colonne MyEmail. Utilisez le format de masque d'e-mail, le code spécifique est le suivant :

ALTER TABLE dbo.MyTable
 ALTER COLUMN MyEmail VARCHAR(250) MASKED WITH (FUNCTION='email()')
GO

Ensuite, les résultats de la requête sont les suivants :

Vous pouvez également masquer plusieurs colonnes de somme

CREATE TABLE MySecondTable (
  MyEmail VARCHAR( 250) MASKED WITH (FUNCTION= 'email()')
, MySSN VARCHAR (10) MASKED WITH (FUNCTION ='default()')
, MyID INT MASKED WITH (FUNCTION ='random(1,4)')
)GOINSERT MySecondTable VALUES
   ( 'myname@mydomain.com', '1234567890', 100 )
 , ( 'abrother@mycorp.com' , '0123456789' , 555)
 , ( 'somesister@somecompany.org' , '9876543210' , 999)

Les résultats de la requête sont les suivants :

Comme nous pouvons le voir, j'obtiens différents masques de différentes lignes, chacun

Autoriser les utilisateurs à voir les données réelles masquées

Il existe une nouvelle autorisation DDM dans SQL Server 2016 qui est les autorisations UNMASK. accordé comme n'importe quel autre. Voyons comment cela fonctionne. Je vais créer un nouvel utilisateur avec les mêmes autorisations que l'utilisateur existant. Ensuite, j'interrogerai la table

Des résultats similaires à ceux d'avant. on ouvre le masque avec autorisation

Nous pouvons maintenant voir comment les données sont affichées. Les utilisateurs privilégiés sont affichés de la même manière. Pour les utilisateurs de NewTester, toutes les données sont "démasquées". Cependant, le fait que les autorisations UNMASK soient accordées à l'utilisateur dans la portée de la base de données présente un inconvénient. Il n’y a pas de granularité par table ou colonne. Si un utilisateur dispose de UNMASK, il peut afficher toutes les données des tables stockées dans la base de données avec l'autorisation SELECT. Nous pouvons le voir en interrogeant la première table à l’aide de Newtest.

Retirez le masque

Le code est le suivant :

Une fois que j'aurai fait cela, l'utilisateur verra le vrai données directement.

ALTER TABLE dbo.MySecondTable
  ALTER COLUMN MySSN DROP MASKED;

Les données de la colonne MySSN sont démasquées, mais les données de MyEmail et MyID sont toujours masquées

Résumé

Le masquage dynamique des données est une nouvelle fonctionnalité intéressante conçue pour faciliter la protection des données des utilisateurs non privilégiés. Cela peut être implémenté dans la base de données sans nécessiter de modification du code de l'application, ce qui vous permet de masquer les données sensibles des utilisateurs de l'application avec un coût et des efforts minimes. Je voudrais également vous rappeler qu'il ne s'agit pas d'un véritable élément de sécurité. Les données stockées sur les disques et les tables ne sont en aucun cas modifiées. Il s’agit toujours de données en texte brut, et si les utilisateurs sont en mesure d’interroger le système, ils peuvent toujours potentiellement interroger vos données et découvrir leur valeur.

Dans tous les cas, cette fonctionnalité est sans aucun doute utile, en particulier pour les systèmes nécessitant le décryptage des données. Bien entendu, les fonctions ont également beaucoup progressé depuis la 17. Je continuerai à les présenter lorsque j'en aurai l'occasion.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!