Obfuscation des données dans SQL Server
Quelle est la meilleure pratique pour l'obfuscation des données dans SQL Server?
Nous aimerions utiliser des données de production masquées dans notre système UAT.
Si nous voulons le faire rapidement et avec un niveau d’éducation plus élevé, quelle approche adopter? Je pense au personnage qui cherche le prénom et le nom de famille des gens, mais comment? Dois-je créer une fonction moi-même ou des fonctions prédéfinies sont-elles disponibles? Je ne veux pas passer du temps à réinventer la roue :)
Et pour les champs de date? Par exemple, la date de naissance devrait-elle être choisie au hasard dans l'ensemble du tableau et attribuée à un enregistrement, ou existe-t-il une meilleure façon de procéder?
J'aimerais pouvoir vous voter 100 points juste pour avoir pensé à ça! J'ai vu ce sujet négligé tellement de fois qu'il est faux - si bien fait. D'après ce que je comprends, vous voulez réellement brouiller les données dans les champs eux-mêmes, et bien que je comprenne ce que vous essayez de réaliser, il ne sera peut-être pas tout à fait nécessaire de le faire - bien que cela devrait être considéré au cas par cas.
La plupart des lois sur la protection des données tournent autour de la possibilité d'associer correctement un élément de données à un individu - par exemple une date de naissance ou un numéro de téléphone. Vous pouvez répondre aux exigences de la loi en veillant à ce que lorsque vous transférez vos données hors de la production vers UAT, elles soient mélangées de sorte qu'elles ne soient pas facilement réaffectées à la personne d'origine - en particulier lorsque vous mélangez les prénoms et noms de famille.
Cependant, cela ne résout pas le problème, par exemple des coordonnées de contact. Vous pouvez répondre aux exigences de la loi en confondant les données mais les numéros de téléphone sont toujours réels, les e-mails toujours réels, etc. ils ne sont tout simplement pas attribués à la bonne personne. Pour cela, je recommande si possible d'effacer ces données avant de les transmettre dans UAT, Red Gate fait un logiciel appelé Data Generator qui peut créer des données de test aléatoires pour vous afin que vous puissiez repeupler les champs avec données qui peuvent être testées.
Quant au brouillage des données: il existe de nombreuses applications qui le font pour vous et honnêtement vous avez raison de ne pas vouloir réinventer la roue. Celui que nous utilisons dans notre entreprise est un produit appelé Data Masker par une entreprise appelée Net2000. La licence est assez bon marché, elle fonctionne extrêmement rapidement et vous n'avez pas à vous soucier de devoir désactiver toutes vos contraintes avant de brouiller la base de données.
Vous pouvez bien sûr rouler votre propre solution si vous ne trouvez rien qui réponde à vos besoins - si vous décidez de le faire, je vous recommande fortement d'utiliser les procédures CLR pour le faire car il est beaucoup plus flexible que le TSQL pur (pour ne pas dire que vous ne peut pas utiliser TSQL voir ici ).
Une fois que vous avez choisi une application pour effectuer cela pour vous, la prochaine chose que vous devez décider est ce que vous voulez/devez réellement brouiller? Honnêtement, votre meilleure ressource pour cela est l'équipe juridique de votre entreprise et/ou les auditeurs de l'entreprise. Je sais que parfois nous n'aimons pas travailler avec eux, mais ils seront beaucoup plus gentils avec vous pour les approcher et leur poser la question plutôt que d'essayer de le faire par vous-même et de vous tromper, il n'y a absolument rien de mal à demander de l'aide - surtout quand c'est aussi important que ça.
J'espère que cela vous aide et je vous souhaite bonne chance dans votre quête ... ;-)
M. Brownstone a frappé le clou directement sur la tête. Maintenant, pour vous aider un peu, voici ma fonction "garble", utilisée pour obscurcir les chaînes (résultats amusants avec des noms!). Passez une chaîne, elle retourne une chaîne tronquée. Incluez-le dans les instructions de mise à jour par rapport aux colonnes de chaînes. Modifiez la longueur des données comme bon vous semble.
---------------------
-- Garble Function --
---------------------
-- Make a function to slightly garble the strings
IF (object_id('fn_Garble') is not null)
drop function fn_Garble
go
create function fn_Garble
(
@String varchar(255)
)
returns varchar(255)
as
BEGIN
select @String = replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(@String,'o','e'),'a','o'),'i','a'),'u','i'),'t','p'),'c','k'),'d','th'),'ee','e'),'oo','or'),'ll','ski')
return @String
END
go
Je devais le faire pour les données de vente au détail de mes clients. Pour les noms, je suis allé au recensement et j'ai téléchargé tous les prénoms et noms de famille, les ai parcourus en boucle pour joindre chaque premier à chaque dernier, ajouté un code de sexe et l'ai chargé dans un tableau en majuscules. J'ai ensuite eu une table avec environ 400 millions de noms uniques. J'ai utilisé des majuscules car nos données actuelles n'étaient pas en majuscules afin que je puisse plus facilement dire les données qui ont été nettoyées.
Lorsque j'ai nettoyé mes données utilisateur, j'ai échangé les noms, pour l'anniversaire, j'ai mis tout le monde au 1er janvier de l'année où ils étaient réellement nés et mis à jour tous les numéros de téléphone avec leur code postal (mes données étaient uniquement aux États-Unis). Les adresses e-mail sont devenues les premières et le nom de famille @ mycompany.co. L'adresse postale m'a fait le plus de peine mais j'ai gardé la ville, l'état et Zip car je pense qu'ils ne seront pas un problème si l'adresse est changée. J'avais un collègue qui avait un programme qui générait des lettres brouillées et mettait à jour la ligne d'adresse avec ça.
Partout où j'avais des données en double mais j'avais toujours un FK pour l'utilisateur principal (mauvaise conception oui, mais pas la mienne) J'ai également mis à jour ces données afin que le nom soit cohérent dans la base de données pour l'utilisateur x.
Dans l'ensemble, mes données étaient encore très lisibles, même si l'adresse n'avait aucun sens. Il m'a fallu quelques jours pour que tout cela fonctionne, mais une fois que cela a été fait et qu'un travail d'agent SQL a été créé, j'ai pu nettoyer les données en aussi peu que 15 minutes.
Jetez un œil au module PowerShell de dbatools pour une option gratuite pour le masquage de données statiques, écrit par Chrissy Lemaire (@ chrissy-lemaire) et son équipe. Tous leurs outils sont excellents, donc je suis sûr que cela vaut le coup d'œil.
Les deux commandes à rechercher dans dbatools sont: New-DbaDbMaskingConfig Invoke-DbaDbDataMasking
Jetez un œil au billet de blog annonçant ceci: masquage automatique des données
Pour masquer un seul champ, pourquoi ne pas utiliser la fonction HASHBYTES (dans SQL 2008+)? Vous pouvez choisir votre algorithme (MD5 est probablement suffisant) à condition de saler vos données. Donc, au lieu de simplement SELECT HASHBYTES('SHA2_256', <LAST NAME FIELD>) assurez-vous que vous faites SELECT HASHBYTES('SHA2_256', <LAST NAME FIELD> + '<my salt string>') et maintenant vous avez un hachage qui ne peut pas être facilement forcé brutalement.
C'est une fonction réelle qui est supportable, reproductible et probablement beaucoup plus rapide. En fonction de ce dont vous avez besoin pour vraiment sécuriser ou simplement masquer, vous pouvez également utiliser un hachage plus faible et plus rapide.