🚋 👨🏽‍🌾 🏞️ Les défauts *** ne sont pas seulement de la randomisation 🐤 👣 👨🏾

Il y a un problème dans la banque: les développeurs et les testeurs doivent avoir accès à la base de données. De nombreuses données client ne peuvent pas être utilisées pour être divulguées aux services de développement et de test conformément aux exigences PCI DSS de la Banque centrale et aux lois sur les données personnelles.

Il semblerait que simplement changer tout en quelques hachages asymétriques soit suffisant et tout ira bien.

Donc, ce ne sera pas le cas.

Le fait est que la base de données de la banque est un ensemble de tables interconnectées. Quelque part, ils sont connectés par nom et numéro de compte client. Quelque part par son identifiant unique. Quelque part (ici commence la douleur) à travers une procédure stockée qui calcule un identifiant d'intercommunication basé sur cela et la table voisine. Etc.

La situation habituelle est que le développeur de la première version du système est déjà décédé ou parti il y a dix ans, et les systèmes du noyau fonctionnant dans l'ancien hyperviseur à l'intérieur du nouvel hyperviseur (pour assurer la compatibilité) sont toujours dans la prod.

Autrement dit, avant d'anonymiser tout cela, vous devez d'abord comprendre la base de données.

Qui fait la dépersonnalisation et pourquoi?

Ils s'engagent dans la dépersonnalisation ou le masquage car il existe des lois et des normes. Oui, il est préférable de tester un «instantané de vente», mais les régulateurs peuvent révoquer une licence pour un tel vol. Autrement dit, pour couvrir l'entreprise en tant que telle.

Toute dépersonnalisation est une couche plutôt coûteuse et maladroite entre les systèmes productifs et les tests de développement.

L'objectif des projets d'anonymisation (masquage) est presque toujours de préparer des données de test aussi similaires que possible aux données réelles stockées dans des bases de données productives. Autrement dit, si les données contiennent des erreurs - au lieu d'un e-mail, le téléphone est bouché, au lieu de l'alphabet cyrillique dans le nom de famille latin, etc., alors les données déguisées doivent être de la même qualité, mais modifiées au-delà de la reconnaissance. Le deuxième objectif est de réduire le volume de bases de données utilisées dans les tests et le développement. Le volume complet n'est laissé que pour les tests de charge, et pour le reste des tâches, une certaine tranche de données est généralement effectuée selon des règles prédéfinies - troncature de la base de données. Le troisième objectif est d'obtenir des données connexes dans différentes bases de données déguisées et tronquées. Cela signifie que les données de différents systèmes, à différents moments, doivent être anonymisées de manière uniforme.

En termes de complexité de calcul, la dépersonnalisation est à peu près la même que quelques archives de bases de données avec une compression extrême. L'algorithme est à peu près similaire. La différence est que les algorithmes d'archivage ont été perfectionnés au fil des ans et ont atteint une efficacité presque maximale. Et les algorithmes de dépersonnalisation sont écrits de manière à ce qu'ils fonctionnent au moins sur la base actuelle et soient assez universels. Et les logiciels après la dépersonnalisation fonctionnaient généralement. C'est un excellent résultat - pour broyer 40 To par nuit. Il se trouve qu'il est moins coûteux pour le client de conduire la base de données en dépersonnalisation une fois tous les six mois pendant une semaine sur un serveur faible - également une approche.

Comment les données sont-elles remplacées?

Chaque type de données change selon les règles qui peuvent être utilisées dans le code. Par exemple, si nous remplaçons le nom par un hachage aléatoire avec des caractères spéciaux et des chiffres, la toute première validation des données produira immédiatement une erreur lors des tests réels.

Par conséquent, le système de dépersonnalisation doit d'abord déterminer quel type de données est stocké sur le terrain. Selon le fournisseur, différentes approches sont utilisées, du balisage manuel aux tentatives de découverte de la base de données et de détection automatique de ce qui y est stocké. Nous avons l'habitude d'introduire toutes les principales solutions du marché. Nous analyserons l'une des options lorsqu'un assistant essaiera de trouver des données et «devinera» quel type de données y est stocké.

Naturellement, pour travailler avec ce logiciel, vous devez avoir accès à des données réelles (il s'agit généralement d'une copie d'une sauvegarde récente de la base de données). Selon l'expérience bancaire, nous signons d'abord une tonne de papiers pendant deux mois, puis nous arrivons à la banque, nous sommes déshabillés, fouillés et habillés, puis nous allons dans une pièce séparée, enfermée dans une cage de Faraday, dans laquelle il y a deux agents de sécurité et respirons chaudement dans le dos.

Supposons donc, après tout cela, que nous voyons une table dans laquelle il y a un champ "Nom". L'assistant l'a déjà marqué comme nom, et nous ne pouvons que confirmer et choisir le type de dépersonnalisation. L'Assistant propose un remplacement aléatoire des noms slaves (il existe des bases pour différentes régions). Nous sommes d'accord et obtenons des remplaçants comme Ivan Ivanov Petrenko - Joseph Albertovich Chingachguk. Si cela est important, le genre est préservé, sinon, les remplacements vont dans toute la base de données des noms.

Exemples de remplacements:

. ->
->
->
->
-> -

Le champ suivant est la date dans Unixtime. L'assistant l'a également déterminé, mais nous devons choisir la fonction de dépersonnalisation. Habituellement, les dates sont utilisées pour contrôler la séquence des événements et la situation où un client a d'abord effectué un virement dans une banque puis ouvert un compte, personne n'a vraiment besoin de le tester. Par conséquent, nous définissons un petit delta - par défaut, dans les 30 jours. Il y aura toujours des erreurs, mais si cela est critique, vous pouvez configurer des règles plus complexes en ajoutant votre script au traitement d'anonymisation.

L'adresse doit être validée, donc la base de données des adresses russes est utilisée. Le numéro de carte doit correspondre aux vrais numéros et être validé par eux. Parfois, la tâche consiste à «créer toutes les cartes MasterCard aléatoires» - cela est également possible en quelques clics.
Sous le capot de l'assistant se trouve le profilage. Le profilage est une recherche de données dans une base de données selon des règles prédéfinies (attributs, domaines). En fait, nous lisons chaque cellule de la base de données du client, appliquons un ensemble d'expressions régulières à chaque cellule, comparons les valeurs de cette cellule avec des dictionnaires, etc. En conséquence, nous avons un ensemble de règles déclenchées sur les colonnes des tables de la base de données. Nous pouvons configurer le profilage, nous ne pouvons pas lire toutes les tables de la base de données, nous ne pouvons prendre qu'un certain nombre de lignes de la table ou un certain pourcentage de lignes.

Que se passe-t-il à l'intérieur?

Pour chaque entrée de la base de données, les règles de dépersonnalisation que nous avons choisies s'appliquent. Dans ce cas, des tables temporaires sont créées pour la durée du processus, où les remplacements sont écrits. Chaque enregistrement suivant dans la base de données est exécuté conformément à ces tables de correspondance de remplacement, et s'il y a une correspondance, elle est remplacée de la même manière qu'auparavant. Tout est en fait un peu plus compliqué en fonction de vos scripts et des règles de correspondance de motifs (il peut y avoir un remplacement inexact, par exemple, pour l'accouchement ou pour remplacer des dates stockées dans un format différent), mais l'idée générale est que.

S'il y a des correspondances balisées «le nom est cyrillique - le nom est latin», alors elles doivent être clairement indiquées au stade du développement, puis dans le tableau de substitution, elles correspondront. Autrement dit, le nom sera anonymisé en cyrillique, puis cette entrée anonymisée sera convertie en alphabet latin, par exemple. À ce stade, nous nous éloignons de l'approche «n'améliore pas la qualité des données dans le système», mais c'est l'un des compromis que vous devez faire pour une sorte de performance du système. La pratique montre que si les tests fonctionnels stressants ne remarquent pas de compromis dans leur travail, alors il n'y a rien. Et voici le point important que la dépersonnalisation dans son ensemble n'est pas un chiffrement. Si vous avez quelques mètres d'entrées dans le tableau, et dans dix d'entre eux, le NIF n'a pas changé, alors quoi? Rien, ces dix enregistrements sont introuvables.

Après la fin du processus, les tables de conversion restent dans la base de données protégée du serveur de dépersonnalisation. La base est coupée (tronquée) et passée aux tests sans tables de conversion, ainsi, pour le testeur, la dépersonnalisation devient irréversible.

La base de données anonyme complète est transmise aux testeurs pour les tests de résistance.

Cela signifie que lorsque vous travaillez avec la base de données, la table de conversion «gonfle» (le montant exact dépend du choix des remplacements et de leur type), mais la base de travail reste la taille d'origine.

À quoi ressemble le processus dans l'interface opérateur?

Vue générale de l'EDI en utilisant l'un des fournisseurs comme exemple:

Débogueur:

démarrage d'une transformation à partir de l'EDI:

configuration d'une expression pour rechercher des données sensibles dans le profileur:

page avec un ensemble de règles pour le profileur:

résultat du profileur, page Web avec recherche de données:

Toutes les données de la base de données sont-elles masquées?

Non. En règle générale, la liste des données pour la dépersonnalisation est réglementée par les lois et les normes de la sphère, et le client a des suggestions pour des domaines spécifiques que personne ne devrait connaître.

La logique est que si nous masquons le nom du patient à l'hôpital, vous pouvez masquer ou non le diagnostic - personne ne saura toujours de qui il vient. Nous avons eu un cas où les notes sur une transaction dans une banque étaient simplement masquées en lettres aléatoires. Il y avait des notes du niveau: "Le prêt a été refusé, parce que le client était ivre, il a vomi au bar". Du point de vue du débogage, ce n'est qu'une chaîne de caractères. Eh bien, laissez-la rester.

Exemples de stratégies:

Une table de départ dynamique est une table de transcodage dans laquelle nous ajoutons le recodage qui s'est déjà produit. Le hachage peut être très différent et dans le cas du même TIN, le plus souvent un nouveau TIN aléatoire est généré avec les premiers caractères stockés, avec des chiffres de contrôle.

Est-il possible de modifier les données en utilisant le SGBD lui-même?

Oui. Lors de la dépersonnalisation des données, il existe deux approches principales - la modification des données dans la base de données à l'aide de la base de données elle-même ou l'organisation d'un processus ETL et la modification des données à l'aide d'un logiciel tiers.

Le principal avantage de la première approche est que vous n'avez pas besoin de retirer des données de la base de données n'importe où, il n'y a pas de coûts de réseau et des outils de base de données rapides et optimisés sont utilisés. Le principal inconvénient est un développement distinct pour chaque système, l'absence de tables de conversion communes pour différents systèmes. Des tables de conversion sont nécessaires pour la reproductibilité de la dépersonnalisation et une intégration plus poussée des données entre les systèmes.

Le principal avantage de la deuxième approche est qu'il n'a pas d'importance quelle base de données, système, fichier il s'agit ou une sorte d'interface Web - une fois que vous implémentez une règle, vous pouvez l'utiliser partout. Le principal inconvénient est que vous devez lire les données de la base de données, les traiter avec une application distincte, les réécrire dans la base de données.

La pratique montre que si le client dispose d'un ensemble de plusieurs systèmes qui nécessitent une intégration plus poussée, seule la deuxième approche peut être mise en œuvre pour le coût final en argent, ainsi que pour des délais de développement acceptables.

Autrement dit, nous pouvons faire tout ce que nous voulons, mais l'approche ETL a fait ses preuves dans le secteur bancaire.

Et pourquoi les données ne se gâtent-elles tout simplement pas manuellement?

Cela peut être fait une fois. Quelqu'un restera assis pendant trois jours, dépersonnalisera un tas de données et préparera une base de données de 500 à 1 000 enregistrements. La difficulté est que le processus doit être répété régulièrement (à chaque changement dans la structure de la base de données et l'apparition de nouveaux champs et tables) et en gros volumes (pour différents types de tests). Une demande courante consiste à dépersonnaliser les 10 à 50 premiers Go de la base de données afin que ce montant tombe uniformément sur chaque table.

Que faire si les numérisations de documents sont stockées dans la base de données?

Si un document peut être réduit au format XML et reconverti (par exemple, des documents Office), vous pouvez également le dépersonnaliser. Mais parfois, il existe des fichiers binaires comme les analyses de passeport en PDF / JPG / TIFF / BMP. Dans ce cas, la pratique généralement acceptée est de fournir des documents similaires avec un script tiers et de remplacer les vrais par des échantillons de la base de ceux générés de manière aléatoire. La chose la plus difficile est avec les photographies, mais il existe des services comme celui-ci qui résolvent le problème de la même manière.

Qui est responsable de quoi?

Lors de la mise à jour après un changement de logiciel ou un «rattrapage», les processus sont plus simples.

Mais que se passe-t-il si quelque chose ne va pas dans les tests?

Cela se produit généralement. Tout d'abord, les testeurs, après le premier cycle de dépersonnalisation, formulent plus précisément les exigences de la base de données. Nous pouvons changer les règles de dépersonnalisation ou rejeter des enregistrements comme «ici, les actions doivent se dérouler dans un ordre chronologique et non dans un chaos». Deuxièmement, selon l'implémentation, nous prenons en charge la dépersonnalisation à mesure que la base de données change, ou laissons toute la documentation, les descriptions de la structure de la base de données et des types de traitement, transférons l'intégralité du code de traitement (règles en xml / sql) et formons des spécialistes du client.

Comment regarder une démo?

Le moyen le plus simple consiste à m'envoyer un e-mail à PSemenov@technoserv.com.

Les défauts *** ne sont pas seulement de la randomisation