Le "Nouveau travail de protection multi-tables…" L'assistant dans IRI Workbench décrit dans cet article est l'un des moyens par lesquels les utilisateurs du produit IRI FieldShield (ou de la plate-forme IRI Voracity) peuvent automatiquement masquer les informations personnelles identifiables (PII) dans les colonnes de la base de données qui font partie d'une relation de clé étrangère, et ainsi préserver l'intégrité référentielle entre les tables. Cela garantit que les enregistrements restent liés même après avoir été anonymisés.
Notez que depuis 2018, une méthode plus récente et plus robuste pour atteindre ce même résultat est publiée dans notre article sur la classification, la découverte et le masquage de plusieurs tables de base de données ici, et est démontré dans les vidéos Youtube 1, 2, 3, 5 et 7 ici.
Mais dans cet assistant original et toujours populaire, les utilisateurs préservent l'intégrité référentielle en définissant des règles de masquage au niveau du champ qui sont automatiquement et systématiquement appliquées aux colonnes portant le même nom. N'importe laquelle des quelque 14 catégories de fonctions de masquage de données disponibles pour les utilisateurs de FieldShield (y compris le chiffrement, la pseudonymisation et la rédaction) peut être appliquée sur la base de ces règles.
Cet assistant est plus approprié pour les utilisateurs masquant et mappant plusieurs tables dans un schéma qui ne contiennent pas toutes des PII. Par exemple, IRI recommande cet assistant si vous avez 50 tables et que vous devez toutes les déplacer dans un environnement inférieur, mais que vous n'avez que 20 tables contenant des PII à masquer de manière cohérente (les 30 autres n'ont pas de PII).
Cet exemple utilise seulement trois tables Oracle — Departments, Employees et Job_History — pour montrer le fonctionnement de cet assistant. Lorsque les tables ont été conçues à l'origine, le numéro de sécurité sociale de l'employé a été utilisé pour leur identification. Cela crée un risque de sécurité lors de l'exécution de rapports affichant le champ ID.
Le diagramme E-R ci-dessus pour ces tables, ainsi que la requête SQL et ses résultats ci-dessous sont tous affichés dans diverses vues IRI Workbench GUI pour FieldShield. Voir cet article concernant la création d'ERD dans IRI Workbench. La requête a joint des informations sur les employés, les responsables et les services, mais expose les valeurs de numéro de sécurité sociale (SSN) dans les colonnes Employee SID et Manager SID. Consultez cet article sur le codage et l'exécution de tâches SQL dans IRI Workbench.
Utilisation de la tâche de protection multi-tables de FieldShield Assistant, ces champs peuvent être chiffrés (ou autrement anonymisés) afin que les vrais SSN soient masqués dans les tables et les requêtes ultérieures. L'intégrité référentielle est conservée car le même cryptage est appliqué à toutes les tables à l'aide d'une seule règle.
Sur la page de configuration de l'assistant, ODBC est sélectionné comme chargeur. Les trois tables susmentionnées sont sélectionnées sur la page Extraction de données. La page suivante est la page Règles de modification des champs. Sur cette page, les règles à appliquer à toutes les tables extraites sélectionnées peuvent être conçues.
Cliquez sur Créer ouvrira la page Field Rule Matcher. C'est ici que les détails du matcher sont entrés. Commencez par entrer un nom de matcher.
Après avoir cliqué sur Créer à côté de Nom de la règle , la page Sélection de l'assistant Nouvelle règle de champ de protection s'affiche. Sélectionnez Fonctions de chiffrement ou de déchiffrement . Cette sélection garantit que le même algorithme de protection s'applique à toutes les données, garantissant l'intégrité référentielle.
La page suivante est celle où le type de cryptage est sélectionné. Dans ce cas, enc_fp_aes256_ascii est utilisé. Cet algorithme de chiffrement préservant le format utilise le jeu de caractères ASCII pour remplacer les données réelles. Il est utilisé dans cette démonstration afin que le cryptage soit perceptible dans la sortie. Un choix plus réaliste serait normalement le alphanum version, qui préserverait également l'apparence réelle des SSN (9 chiffres dans ce cas).
Bien que cet exemple utilise une phrase de passe intégrée, un fichier de mots de passe peut également être utilisé pour la clé de chiffrement, tout comme une variable d'environnement.
Cliquez sur Terminer entrera cette règle dans le matcher. Ensuite, le matcher lui-même doit être créé. Cliquez sur Ajouter dans les Matcheurs section. Cela ouvrira la page Détails de Field Rule Matcher. Ici, un modèle ou une classe de données peut être utilisé. Consultez l'article Appliquer des règles de champ à l'aide de la classification pour plus de détails sur la deuxième option.
Dans cet exemple, Modèle est sélectionné et .*SID est saisi dans les détails. Cette expression régulière correspondra à tous les noms de colonne se terminant par SID.
Le matcher termine avec les détails affichés ci-dessous. Le test peut être utilisé pour tester les matchers afin de s'assurer qu'ils correspondent à toutes les colonnes prévues. Plusieurs détails de matcher peuvent être entrés et la logique AND/OR peut être utilisée pour produire des matchers à grain fin. Par exemple, il existe une colonne supplémentaire nommée VP_SSN . Le même matcher ci-dessus peut être utilisé avec un autre matcher avec un modèle .*SSN et l'opérateur ET à faire correspondre sur cette colonne supplémentaire mais avec la même règle.
Cliquez sur OK renvoie ici à la page Règles où chaque matcher de règle est affiché. Différents comparateurs peuvent être utilisés pour différents champs, de sorte qu'une seule passe de transformation est nécessaire, même si les règles devaient masquer différentes colonnes de différentes manières.
Cliquez sur Suivant affichera la page de l'étape de chargement des données. C'est ici que la table de sortie et les options sont sélectionnées. Dans cet exemple, les mêmes tables que les tables d'entrée sont sélectionnées. De plus, le mode de sortie est remplacé par Créer pour tronquer les tables avant le chargement afin que les clés uniques ne soient pas violées.
Après avoir cliqué sur Terminer , un dossier est créé avec plusieurs scripts qui seront exécutés avec le fichier batch inclus.
Pour voir comment la règle transformera le champ et nous donnera une chance de modifier les choses manuellement, le SCOTT_EMPLOYEES.fcl le script peut être examiné dans l'éditeur Workbench. Dans le résultat, le EMPLOYEE_SID et le MANAGER_SID afficher l'algorithme de chiffrement appliqué.
Après l'exécution du fichier batch, la même requête SQL affiche les mêmes résultats joints, mais avec le Employee_SID et Manager_SID maintenant crypté. De plus, l'intégrité référentielle est préservée. Les relations d'origine employé-manager sont conservées et les identifiants du manager sur la ligne 2 et de l'employé sur la ligne 26 sont les mêmes.
Cet exemple montre comment une règle de chiffrement peut être utilisée sur plusieurs colonnes dans plusieurs tables tout en conservant l'intégrité référentielle. Toutes les règles créées au cours des assistants de tâche sont enregistrées dans une bibliothèque de règles. Cela permet de les réutiliser et même de les partager avec des collègues afin de garantir les mêmes résultats sur les mêmes données.
Si vous avez des questions sur les règles de masquage des données FieldShield ou si vous avez besoin d'aide pour utiliser l'un de ses assistants de découverte ou de masquage de données, contactez votre représentant IRI.
