Le but de la masquage des données est d'effacer les caractéristiques qui permettent d'identifier les données sensibles, les rendant anonymes mais toujours utilisables. De cette façon, le risque de vol d'informations sensibles pour l'organisation est éliminé.
L'idée est qu'avec le masquage des données Nous donnons aux développeurs un accès à des données de qualité. Ils sont nécessaires dans les processus de production à des fins de test, mais comme nous l'avons vu dans d'autres messages, nous ne pouvons pas y travailler avec les données réelles. De cette façon, nous nous assurons que nos données sensibles sont en sécurité.
Même si cela semble simple, nous pouvons rencontrer des problèmes. Regardons un sujet simple et quatre problèmes que nous pouvons trouver lorsque nous utilisons des techniques de masquage des données.
Un thème simple: obscurcissement des données
Les développeurs adorent travailler avec les données de production. Mais aujourd'hui, en raison de problèmes de confidentialité, les entreprises ne sont pas très enclines à donner aux développeurs un accès complet à leurs données. Même pour ceux extraits d'une sauvegarde de production. Ils sont très préoccupés par les développeurs qui travaillent avec des listes de clients, numéros de carte de crédit, Dates d'anniversaire, adresses, Noms, etc. et qu'ils peuvent ensuite commercialiser ces données auprès de la concurrence.
Les entreprises souhaitent utiliser des techniques de masquage des données pour masquer rapidement toutes les données de production. Ils veulent restaurer les bases de données de production en développement, exécuter une procédure et laisser les développeurs tester leurs applications sans voir les données de production réelles.
Ils ne veulent pas obscurcir tous les champs. Par exemple, les transactions financières doivent conserver des données monétaires similaires aux données réelles pour faciliter la vérification des rapports. Nous ne pouvons pas avoir de pourcentages de taxes aléatoires comme la TVA, par exemple, parce que nous avons besoin qu'ils se comportent de manière prévisible lorsque nous regardons une facture.
Mais comme on dit, c'est la partie facile du masquage des données. L'obscurcissement des données est quelque chose qui peut être fait facilement. Mais cela a des implications plus compliquées. Voyons les.
Problème 1: maintenance du profil de stockage avec des données cryptées
Le moyen le plus simple de cacher vos données est de les crypter. Malgré cela, le cryptage des données a tendance à produire une taille de données totalement différente. Si vous avez l'intention de voir un exemple en action, vous pouvez visiter cette page démo de cryptage. Cliquez au hasard pour générer une clé, tapez du texte brut et cliquez sur Crypter.
Comme tu peux le voir, les données sont soudainement beaucoup plus grandes. Cela peut ne pas être un obstacle pour certains types de données, mais c'est un gros problème pour les champs avec des entiers, dates et cartes de crédit, par exemple. Le cryptage des noms de clients augmente soudainement la taille de chaque enregistrement et modifie la façon dont les requêtes sont effectuées. Idéalement, les données obscurcies doivent être de la même taille que les données d'origine.
Problème 2: diffuser les statistiques en toute sécurité
Dans un annuaire téléphonique typique, il y a beaucoup de personnes avec le nom de famille Garcia. Si vous regardez un histogramme typique de données de nom de famille, certains noms de famille auront de nombreux enregistrements et d'autres pas beaucoup.
Un système de gestion de base de données tel que SQL Server génère des statistiques comportant des histogrammes indiquant la distribution des données dans chaque colonne, puis utilise ces statistiques pour créer des plans d'exécution.. Lorsque nous testons les requêtes SQL en développement, nous voulons obtenir des variations similaires.
Il est facile d'obscurcir les données grâce au masquage des données, juste le faire au hasard. Si nous avons un champ de date, nous utilisons juste un générateur de nombres aléatoires, mais il n'aura pas la même distribution que nos données d'origine.
Idéalement, les données obscurcies doivent avoir une distribution similaire à celle des données d'origine. Si nous avons des gens dans une table 1000 enregistrements, tous ceux qui portent le nom de famille García doivent être obscurcis de la même manière afin qu'ils portent le même nom de famille. Si ma table people a 500 personnes nommées Garcia et autres 500 personnes avec des noms de famille uniques, mes données obscurcies doivent également avoir 501 noms de famille différents uniques, dont l'un aura 500 enregistrements dans la table.
Problème 3: maintenir l'intégrité référentielle tout au long du masquage des données
Parfois, les données privées font partie de la clé primaire de la table. Idées de conception de base de données de côté, la réalité est que certaines personnes ont des éléments comme leur numéro de sécurité sociale dans le cadre d'une clé primaire. Ou pire encore, certaines personnes ne mettent pas de relations de clé étrangère dans les bases de données, ils se retrouvent donc avec deux champs de numéro de sécurité sociale dans deux tables différentes qui doivent être jointes.
Nous ne pouvons pas faire confiance aux clés étrangères car de nombreuses personnes n'utilisent pas l'intégrité référentielle dans les bases de données.
De plus, plusieurs bases de données peuvent être impliquées. Parfois, les clients ont des données client dans une base de données, informations de vente dans un autre et données de configuration dans un autre, et ils doivent tous être liés.
Idéalement, la réponse serait de déterminer les jointures où vous pourriez conserver les mêmes données dans les deux tables, tout en permettant aux utilisateurs de spécifier des champs qui se lient même si les clés étrangères ne sont pas spécifiées dans la base de données. Cette configuration doit être créée une fois et enregistrée, afin que les utilisateurs n'aient pas à le répéter à chaque mise à niveau de la production.
Problème 4: vitesse des outils de masquage des données
Ces situations impliquent souvent de grandes quantités de données et les gens veulent mettre à niveau le développement avec une copie de production obscurcie du jour au lendemain.. Ceci signifie que, comme d'habitude, il n'est pas pratique d'exporter toutes vos données vers une sorte de serveur d'applications, puis de réessayer. Il n'est pas non plus pratique de mettre à jour la même table à plusieurs reprises, une fois pour chaque colonne à masquer.
Les utilisateurs veulent que les mises à jour d'état sachent approximativement quelle partie de la base de données a été obscurcie, combien reste-t-il à faire et s'il échoue à mi-chemin pour réparer les choses et revenir là où l'outil d'analyse s'est arrêté. masquage des données.
