Cet article illustre l'utilisation d'IRI DarkShield pour identifier et corriger (masquer) les informations d'identification personnelle (PII) et autres données sensibles dans les bases de données MongoDB, Cassandra et Elasticsearch. Bien que ces étapes se concentrent principalement sur la recherche et la protection des données dans les collections MongoDB, les mêmes étapes peuvent également être utilisées pour les données dans les tables Cassandra. Consultez également cet article sur Elasticsearch.
Notez que cet article représente la quatrième méthode prise en charge par IRI pour masquer les données dans MongoDB, et la deuxième méthode pour Cassandra. Ces méthodes précédentes et toujours prises en charge reposent sur la découverte et l'anonymisation de données structurées via IRI FieldShield, tandis que la méthode DarkShield prend en charge les données textuelles dans des collections structurées ou non structurées. Bien que DarkShield et FieldShield soient des produits de masquage de données IRI autonomes, les deux sont inclus dans la plate-forme de gestion de données IRI Voracity.
La dernière approche utilise certains éléments de Classification des données , un paradigme de catalogage de données intégré pour définir les méthodes de recherche utilisées pour trouver des PII indépendamment de la source des données. Bien que cet article fournisse une petite introduction à la classification des données lors de l'étape 1, vous trouverez peut-être utile de lire comment la classification des données s'intègre dans notre approche unifiée pour effectuer des recherches. Pour plus d'informations sur la classification des données dans le frontal IRI Workbench pour DarkShield et al, veuillez lire cet article avant de continuer.
L'identification et la correction des PII à l'aide d'IRI DarkShield impliquent 4 étapes générales :
Étape (facultative) – Enregistrer vos sources de données
Dans cette étape (facultative), les sources de données d'une base de données Mongo, d'un espace de clés Cassandra ou d'un cluster Elasticsearch sont enregistrées. Cela permet aux sources de données d'être réutilisables. Par conséquent, cette étape est facultative si la source de données souhaitée existe déjà dans le registre ou si vous prévoyez de les définir à partir de l'assistant.
Étape 1 - Spécifiez les paramètres de recherche
Ici, tous les aspects d'une recherche sont choisis. Tout d'abord, une collection/table source et cible est configurée en fonction de la connexion de données spécifiée dans le registre ou créée dans l'assistant. Ensuite, vous pouvez spécifier les critères de recherche et de correction pour vos données à l'aide de Search Matchers, les types d'informations à rechercher et la manière dont ces informations doivent être corrigées. Le résultat de cette étape est une .recherche fichier.
Étape 2 - Effectuez une recherche
Une recherche peut être lancée depuis un .search dossier. Le résultat est un .darkdata fichier annotant tout PII identifié.
Étape 3 - Correction (masquage)
La correction peut être effectuée à partir d'un .darkdata dossier. Toute PII identifiée sera corrigée de la manière spécifiée lors de la création de la recherche.
Étape (facultative) :Enregistrez vos sources de données
Comme étape préalable, vous devrez enregistrer les connexions à vos sources de données en ligne (et cibles) dans le registre de connexion d'URL, qui se trouve dans les Préférences> IRI> Registre de connexion d'URL boîte de dialogue dans IRI Workbench.
Toutes les connexions URL, y compris les chaînes de connexion URI pour MongoDB, Cassandra et Elasticsearch peuvent être enregistrées. Cela permet aux URL, aux identifiants d'authentification et à tous les paramètres supplémentaires d'être enregistrés et stockés par IRI Workbench pour une utilisation future.
Étape 1 - Spécifier les paramètres de recherche (Créer un fichier .Search)
Dans l'IDE IRI Workbench pour DarkShield, sélectionnez Nouvelle tâche de découverte de base de données dans le menu DarkShield. Sélectionnez un dossier de projet et saisissez un nom pour la tâche :
Spécifier une source et une cible
Toutes les URL Mongo, Cassandra ou Elasticsearch précédemment créées et enregistrées dans le registre sont accessibles à partir de l'URI liste déroulante pour les sélecteurs Source et Cible. Le nom de la collection MongoDB, de la table Cassandra ou de l'index Elasticsearch correspondant devra également être saisi :
Un nouvel URI peut également être créé en appuyant sur Nouveau bouton. Cela ouvrira la boîte de dialogue Détails de connexion URL. Entrez un nom pour la connexion, sélectionnez le schéma souhaité, entrez l'hôte et entrez la base de données. Si aucun port n'est présent, le port par défaut du schéma sera utilisé.
Un nom d'utilisateur et un mot de passe peuvent également être fournis si la base de données nécessite une autorisation. Toute nouvelle connexion URL sera enregistrée dans le registre de connexion URL et pourra être réutilisée comme cible.
Une fois qu'une source est spécifiée, vous pouvez passer à la page suivante pour sélectionner ou créer un URI cible. Le schéma de l'URI cible sera limité à l'URI source sélectionné, de sorte qu'une source MongoDB ne peut être envoyée qu'à une autre cible MongoDB, et de même pour Cassandra ou Elasticsearch.
Lorsqu'une tâche de masquage est exécutée, toutes les lignes de la source seront ajoutées à la cible et toutes les lignes avec des clés correspondantes seront écrasées. Pour Cassandra, assurez-vous que le schéma de la table cible est compatible avec les données de la table source.
Ajouter des correspondances de recherche
Après avoir spécifié une source et une cible, vous pouvez passer à la page suivante pour ajouter des critères de recherche. Sélectionnez un emplacement de bibliothèque contenant les bibliothèques de modèles ou de règles que vous souhaitez utiliser et cliquez sur Ajouter pour ajouter un nouveau Search Matcher.
KeyNameMatcher
Le premier Search Matcher que nous allons créer sera utilisé pour faire correspondre la valeur entière correspondant à n'importe quelle clé "name" située dans des structures json arbitrairement imbriquées et appliquer un algorithme de chiffrement préservant le format pour le masquer. Nous pouvons y parvenir en créant un filtre de chemin JSON "$..name". Pour plus d'informations sur les chemins JSON, cliquez ici.
Étant donné que les collections MongoDB, les tables Cassandra et les index Elasticsearch sont analysés par DarkShield en tant que documents json, le filtre peut être appliqué aux deux afin de masquer toute valeur correspondant à n'importe quelle clé "nom".
Pour faire correspondre le contenu des données filtrées, nous devons créer une nouvelle classe de données . Une classe de données représente les PII et les matchers associés utilisés pour les identifier. Ces correspondances peuvent inclure n'importe quelle combinaison de :
- Modèles d'expressions régulières
- Définir les recherches dans le dictionnaire de fichiers
- Modèles de reconnaissance d'entités nommées
- Matcheurs de boîtes englobantes (images uniquement)
- Reconnaissance faciale (images uniquement)
Vous pouvez définir des classes de données dans l'assistant ou en ouvrant les Classes et groupes de données page dans les Préférences IRI . Les classes de données définies dans les préférences peuvent être utilisées à la fois dans FieldShield et DarkShield pour d'autres sources de données, y compris des données structurées et non structurées.
Nous pouvons créer un TOUT associé Classe de données pour ce matcher qui correspondra sur tout le contenu de la valeur, puisque nous sommes raisonnablement sûrs que tout ce que nous trouverons dans les valeurs sont des noms. Vous pouvez utiliser des recherches de fichiers d'ensemble contenant un dictionnaire de noms si vous n'êtes pas sûr du contenu de vos clés "nom" ou si vous souhaitez masquer uniquement un sous-ensemble de noms.
Pour le Nom de la règle champ du KeyNameMatcher, nous pouvons sélectionner une règle de données existante à partir de l'emplacement de la bibliothèque que nous avons sélectionné, ou créer une nouvelle règle qui utilise Format Preserving Encryption (FPE), par exemple :
Pour créer une règle FPE, cliquez sur Créer à côté du Nom de la règle champ, sélectionnez Fonctions de chiffrement ou de déchiffrement à partir de l'assistant de règle de données qui s'affiche :
Spécifiez une phrase de passe appropriée pour servir de clé de chiffrement/déchiffrement, qui peut être une chaîne explicite, une variable d'environnement ou le nom d'un fichier sécurisé contenant cette chaîne.
Emails Matcher
Après avoir terminé la boîte de dialogue précédente et créé notre nouveau KeyNameMatcher, nous pouvons ajouter un autre Search Matcher pour les adresses e-mail. Cliquez simplement sur Ajouter pour créer un autre Search Matcher à ajouter à la liste.
L'atelier IRI est préchargé avec un EMAIL Classe de données qui peut être sélectionnée en cliquant sur Parcourir à côté du Nom de la classe de données champ et en sélectionnant EMAIL dans le menu déroulant.
Pour la règle de données, vous pouvez sélectionner la règle FPE que vous avez créée pour le précédent Search Matcher en cliquant sur Parcourir à côté du Nom de la règle ou créez-en un nouveau avec l'une des multiples fonctions de masquage disponibles. J'ai créé une simple fonction de rédaction des données qui remplace l'intégralité de l'e-mail par des astérisques.
Votre Search Matcher peut maintenant être ajouté à la liste en cliquant sur OK.
NamesMacher
Notre dernier Search Matcher sera utilisé pour trouver des noms dans un texte fluide. Pour cela, nous utiliserons la reconnaissance d'entité nommée (NER) pour trouver des noms en utilisant le contexte de la phrase. Pour commencer, nous devons cliquer sur Ajouter pour créer un nouveau Search Matcher et créer une nouvelle classe de données appelée NAMES_NER :
Pour créer un NAMES_NER Data Class, nous devons d'abord télécharger le modèle Person Name Finder, en-ner-person.bin , à partir du référentiel OpenNLP sourceforge. Cliquez ensuite sur Ajouter pour ajouter un nouveau matcher, sélectionnez Modèle NER du menu déroulant. Cliquez sur Parcourir et accédez à l'emplacement du modèle téléchargé ; par exemple :
Après avoir créé la nouvelle classe de données, cliquez sur OK et sélectionnez la règle de données FPE que vous avez définie précédemment pour terminer la création du Search Matcher :
Notez que notre NamesMatcher et KeyNameMatcher peuvent avoir des correspondances qui se chevauchent. Si cela se produit, DarkShield sélectionne la plus longue correspondance disponible et supprime toutes les autres correspondances qui se chevauchent. De cette façon, vous n'avez pas à vous soucier de l'application par DarkShield d'une fonction de masquage sur des valeurs déjà masquées.
Une fois que vous avez ajouté tous les matchers souhaités, cliquez sur terminer pour générer un .search fichier.
Le .search généré Le fichier peut être inspecté pour afficher les détails d'une recherche. Cela inclut les URI source et cible, ainsi que des informations sur tous les matchers.
Étape 2 – Effectuer une recherche (Créer un .Darkdata Fichier)
Terminer la tâche de découverte de données sombres l'assistant génère une nouvelle .recherche fichier de configuration. Ce fichier contient les options que nous avons sélectionnées, y compris la source et la cible de nos données, et les Search Matchers qui seront utilisés pour marquer les PII pour la découverte, la livraison, la suppression et/ou l'anonymisation.
Pour lancer la recherche, faites un clic droit sur le .recherche fichier, sélectionnez Exécuter en tant que et choisissez soit IRI Search Job ou Travail de recherche et de correction d'IRI .
Rechercher effectuera uniquement une recherche, tandis que Rechercher et corriger tentera également de masquer (ou de supprimer) toute donnée identifiée. Les deux généreront un .darkdata fichier identifiant toute donnée d'intérêt.
La source que j'ai utilisée a été remplie avec des valeurs générées aléatoirement, il n'y a donc aucun mal à partager le .darkdata généré dossier ici. Cependant, lors de la manipulation d'informations réellement sensibles, les utilisateurs doivent s'assurer que le .darkdata le fichier n'est pas exposé et est archivé ou supprimé en toute sécurité après l'achèvement de la correction pour éviter les fuites de PII. IRI ajoutera une option de quarantaine pour stocker le .darkdata fichier et artefacts de recherche correspondants dans un endroit sûr ; contactez [email protected] pour plus de détails sur cette fonctionnalité prévue.
Étape 3 - Correction (masquage)
Encore une fois, le masquage ou la suppression des données peut être effectué pendant les opérations de recherche via Rechercher et corriger dans l'assistant Dark Data Discovery. Cependant, si vous souhaitez simplement examiner les informations identifiées et y remédier ultérieurement, exécutez les tâches de masquage à partir du .darkdata fichier produit dans la recherche (étape 2) de cette manière :
Faites un clic droit sur le .darkdata fichier, passez la souris sur Exécuter en tant que , puis cliquez sur Tâche de correction IRI . Une fois la tâche exécutée, les données corrigées doivent apparaître dans la base de données cible.
Voici un exemple montrant un avant et un après d'une petite collection de bases de données MongoDB utilisant l'invite de commande Workbench pour accéder au serveur Mongo local :
CONCLUSION
Dans cet article, nous avons démontré une nouvelle capacité IRI pour accéder aux données non structurées dans les bases de données Mongo, les espaces de clés Cassandra et les clusters Elasticsearch en utilisant plusieurs Search Matchers dans IRI DarkShield. Vous pouvez vérifier le .darkdata généré modèle pour voir les résultats de recherche qui ont été trouvés et corrigés, et vérifiez votre base de données pour voir les tables/collections mises à jour.
- Si les PII sont intégrées dans des objets binaires au sein de vos collections MongoDB, Cassandra, Elasticsearch, nous pouvons vous aider à automatiser leur extraction vers des fichiers autonomes pour les opérations de recherche/masquage DarkShield, et leur réimportation.
- L'IDE d'IRI Workbench, basé sur Eclipse™, est frontal pour tous les FieldShield, DarkShield et le masquage de données associé, ainsi que des capacités de traitement de données plus larges, dans la plate-forme IRI Voracity.
- Le registre de connexion d'URL est utilisé pour configurer et enregistrer les sources de données basées sur l'URL utilisées dans les opérations ETL de recherche/masque DarkShield et CoSort/SortCL (Voracity) ; par exemple, HDFS, Kafka, compartiments S3, MongoDB, S/FTP. Ce registre est similaire, mais pas identique, au registre de connexion de données dans IRI Workbench pour les sources de bases de données relationnelles où les DSN ODBC sont reliés aux profils de connexion JDBC correspondants au profit des assistants de travail tirant parti des deux connexions.
- Un Search Matcher est une association entre une Data Class , qui est utilisé pour définir la méthode de recherche pour trouver et classer les PII, et une règle de données qui sera appliqué à toute instance de la classe de données trouvée dans la collection ou la table. De plus, Search Matchers vous permet de définir des filtres qui peuvent être utilisés pour réduire la portée de la recherche. Ceci est particulièrement utile dans les collections Mongo, les tables Cassandra et les index Elasticsearch, car le nom de la clé peut indiquer les PII qui sont stockées dans la valeur correspondante.
