MongoDB
 sql >> Database >  >> NoSQL >> MongoDB

Mascherare le PII in MongoDB, Cassandra ed Elasticsearch con DarkShield:...

Questo articolo illustra l'uso di IRI DarkShield per identificare e correggere (mascherare) le informazioni di identificazione personale (PII) e altri dati sensibili nei database MongoDB, Cassandra ed Elasticsearch. Sebbene questi passaggi si concentrino principalmente sulla ricerca e la protezione dei dati nelle raccolte MongoDB, gli stessi passaggi possono essere utilizzati anche per i dati nelle tabelle Cassandra. Vedi anche questo articolo su Elasticsearch.

Si noti che questo articolo rappresenta il quarto metodo supportato da IRI per mascherare i dati in MongoDB e il secondo metodo per Cassandra. I metodi precedenti e ancora supportati si basano sul rilevamento e sulla deidentificazione dei dati strutturati tramite IRI FieldShield, mentre il metodo DarkShield supporta i dati testuali in raccolte strutturate o non strutturate. Sebbene DarkShield e FieldShield siano prodotti di mascheramento dei dati IRI autonomi, entrambi sono inclusi nella piattaforma di gestione dei dati IRI Voracity.

L'ultimo approccio utilizza alcuni elementi della Classificazione dei dati , un paradigma integrato di catalogazione dei dati per definire i metodi di ricerca utilizzati per trovare le PII indipendentemente dalla fonte dei dati. Sebbene questo articolo fornisca una piccola introduzione alla classificazione dei dati durante il passaggio 1, potrebbe essere utile leggere come la classificazione dei dati si inserisce nel nostro approccio unificato alla conduzione delle ricerche. Per ulteriori informazioni sulla classificazione dei dati nel front-end di IRI Workbench per DarkShield et al, leggere questo articolo prima di procedere.

L'identificazione e la correzione delle PII mediante IRI DarkShield prevede 4 passaggi generali:

Passaggio (facoltativo):registra le tue origini dati

In questo passaggio (facoltativo), vengono registrate le origini dati per un database Mongo, uno spazio delle chiavi Cassandra o un cluster Elasticsearch. Ciò consente di riutilizzare le origini dati. Di conseguenza, questo passaggio è facoltativo se l'origine dati desiderata esiste già nel registro o se prevedi di definirla dalla procedura guidata.

Passaggio 1:specifica i parametri di ricerca

Qui vengono scelti tutti gli aspetti di una ricerca. Innanzitutto, vengono impostate una raccolta/tabella di origine e di destinazione in base alla connessione dati specificata nel registro o creata nella procedura guidata. Quindi, puoi specificare i criteri di ricerca e correzione per i tuoi dati utilizzando Search Matchers, i tipi di informazioni da cercare e come tali informazioni devono essere corrette. Il risultato di questo passaggio è una .ricerca file.

Passaggio 2:effettua una ricerca

È possibile eseguire una ricerca da un .search file. Il risultato è un .darkdata file che annota le PII identificate.

Fase 3:correzione (mascheramento)

La correzione può essere eseguita da un .darkdata file. Eventuali informazioni personali identificate verranno corrette nel modo specificato durante la creazione della ricerca.

Passaggio (facoltativo) – Registra le tue origini dati

Come passaggio prerequisito, dovrai registrare le connessioni alle tue origini dati (e destinazioni) online nel registro delle connessioni URL, che si trova in Preferenze> IRI> Registro connessioni URL finestra di dialogo in IRI Workbench.

È possibile salvare tutte le connessioni URL, comprese le stringhe di connessione URI per MongoDB, Cassandra ed Elasticsearch. Ciò consente di salvare e archiviare URL, credenziali di autenticazione ed eventuali parametri aggiuntivi da IRI Workbench per un uso futuro.

Passaggio 1:specifica i parametri di ricerca (Crea file .Search)

Nell'IDE di IRI Workbench per DarkShield, selezionare New Database Discovery Job dal menu DarkShield. Seleziona una cartella di progetto e inserisci un nome per il lavoro:

Specifica di una sorgente e di una destinazione

È possibile accedere a qualsiasi Mongo, Cassandra o ElasticsearchURL precedentemente creato e salvato nel registro dall'URI menu a discesa per entrambi i selettori Sorgente e Destinazione. Dovrà essere inserito anche il nome della raccolta MongoDB corrispondente, della tabella Cassandra o dell'indice Elasticsearch:

È anche possibile creare un nuovo URI premendo Nuovo pulsante. Si aprirà la finestra di dialogo Dettagli connessione URL. Immettere un nome per la connessione, selezionare lo schema desiderato, immettere l'host e immettere il database. Se non è presente alcuna porta, verrà assunta la porta predefinita per lo schema.

È inoltre possibile fornire un nome utente e una password se il database richiede l'autorizzazione. Eventuali nuove connessioni URL verranno salvate nel registro delle connessioni URL e possono essere riutilizzate come destinazione.

Dopo aver specificato un'origine, puoi passare alla pagina successiva per selezionare o creare un URI di destinazione. Lo schema dell'URI di destinazione sarà limitato all'URI di origine selezionato, quindi un'origine MongoDB può essere inviata solo a un'altra destinazione MongoDB, e allo stesso modo per Cassandra o Elasticsearch.

Quando viene eseguito un lavoro di mascheramento, tutte le righe nell'origine verranno aggiunte alla destinazione e tutte le righe con chiavi corrispondenti verranno sovrascritte. Per Cassandra, assicurati che lo schema della tabella di destinazione sia compatibile con i dati della tabella di origine.

Aggiunta di corrispondenze di ricerca

Dopo aver specificato sia una fonte che una destinazione, puoi andare alla pagina successiva per aggiungere i corrispondenti di ricerca. Seleziona una posizione della libreria contenente le librerie Pattern o Regole che desideri utilizzare e fai clic su Aggiungi per aggiungere un nuovo Matcher di ricerca.

KeyNameMatcher

Il primo Search Matcher che creeremo verrà utilizzato per abbinare l'intero valore corrispondente a qualsiasi chiave "nome" situata in strutture json annidate arbitrariamente e applicare un algoritmo di crittografia di conservazione del formato per mascherarlo. Possiamo raggiungere questo obiettivo creando un filtro di percorso JSON "$..name". Ulteriori informazioni sui percorsi JSON sono disponibili qui.

Poiché le raccolte MongoDB, le tabelle Cassandra e gli indici Elasticsearch vengono analizzati da DarkShield come documenti json, il filtro può essere applicato a entrambi per mascherare qualsiasi valore corrispondente a qualsiasi chiave "nome".

Per abbinare i contenuti dei dati filtrati, dobbiamo creare una nuova Classe di dati . Una classe di dati rappresenta le PII e gli abbinamenti associati utilizzati per identificarla. Questi abbinatori possono includere qualsiasi combinazione di:

  • Modelli di espressione regolari
  • Imposta ricerche nel dizionario dei file
  • Modelli di riconoscimento di entità nominative
  • Bounding Box Matchers (solo immagini)
  • Riconoscimento facciale (solo immagini)

Puoi definire le classi di dati all'interno della procedura guidata o aprendo le Classi e gruppi di dati pagina nelle Preferenze IRI . Le classi di dati definite nelle preferenze possono essere utilizzate sia in FieldShield che in DarkShield per altre origini dati, inclusi dati strutturati e non strutturati.

Possiamo creare un TUTTO associato Classe di dati per questo matcher che corrisponderà all'intero contenuto del valore, poiché siamo ragionevolmente sicuri che tutto ciò che troveremo nei valori sono nomi. Puoi utilizzare le ricerche di file impostate contenenti un dizionario di nomi se non sei sicuro del contenuto delle tue chiavi "nome" o se desideri mascherare solo un sottoinsieme di nomi.

Per il Nome regola campo del KeyNameMatcher, possiamo selezionare una regola dati esistente dalla posizione della libreria che abbiamo selezionato, oppure creare una nuova regola che utilizzi la crittografia di conservazione del formato (FPE), ad esempio:

Per creare una regola FPE, fai clic su Crea accanto al Nome regola campo, selezionare Funzioni di crittografia o decrittografia dalla procedura guidata regola dati visualizzata:

Specifica una passphrase appropriata da utilizzare come chiave di crittografia/decrittografia, che può essere una stringa esplicita, una variabile di ambiente o il nome di un file protetto contenente tale stringa.

EmailsMatcher

Dopo aver terminato la finestra di dialogo precedente e aver creato il nostro nuovo KeyNameMatcher, possiamo aggiungere un altro Matcher di ricerca per gli indirizzi e-mail. Basta fare clic su Aggiungi per creare un altro Search Matcher da aggiungere all'elenco.

Il banco di lavoro IRI viene fornito precaricato con un EMAIL Classe di dati selezionabile cliccando su Sfoglia accanto al Nome classe dati campo e selezionando EMAIL dal menu a tendina.

Per la regola dei dati, puoi selezionare la regola FPE che hai creato per il precedente Search Matcher facendo clic su Sfoglia accanto al Nome regola campo o crearne uno nuovo con una delle molteplici funzioni di mascheramento disponibili. Ho creato una semplice funzione Data Redaction che sostituisce l'intera email con asterischi.

Il tuo Search Matcher può ora essere aggiunto all'elenco facendo clic su OK.

NamesMatcher

Il nostro ultimo Matcher di ricerca verrà utilizzato per trovare nomi all'interno di testo a flusso libero. Per questo, utilizzeremo il Riconoscimento di entità nominative (NER) per trovare i nomi usando il contesto della frase. Per iniziare, dobbiamo fare clic su Aggiungi per creare un nuovo Matcher di ricerca e creare una nuova classe di dati denominata NAMES_NER:

Per creare un NAMES_NER Classe di dati, dobbiamo prima scaricare il modello Person Name Finder, en-ner-person.bin , dal repository di openNLP sourceforge. Quindi, fai clic su Aggiungi per aggiungere un nuovo abbinamento, seleziona Modello NER dal menu a discesa. Fai clic su Sfoglia e vai alla posizione del modello scaricato; ad esempio:

Dopo aver creato la nuova classe di dati, fare clic su OK e seleziona la regola dati FPE definita in precedenza per completare la creazione del Matcher di ricerca:

Nota che il nostro NamesMatcher e KeyNameMatcher potrebbero avere corrispondenze sovrapposte. Se ciò accade, DarkShield seleziona la corrispondenza più lunga disponibile e rimuove tutte le altre corrispondenze sovrapposte. In questo modo, non devi preoccuparti che DarkShield applichi una funzione di mascheramento su valori già mascherati.

Dopo aver aggiunto tutti i corrispondenti desiderati, fai clic su fine per generare un .cerca file.

Il .search generato il file può essere ispezionato per mostrare i dettagli su una ricerca. Ciò include gli URI di origine e di destinazione e le informazioni su tutti i corrispondenti.

Fase 2:esegui una ricerca (crea un .Darkdata File)

Completamento del processo di rilevamento dati oscuri la procedura guidata genera una nuova .ricerca file di configurazione. Quel file contiene le opzioni che abbiamo selezionato, tra cui l'origine e la destinazione dei nostri dati, e i Matcher di ricerca che verranno utilizzati per contrassegnare le PII per la scoperta, la consegna, l'eliminazione e/o l'anonimizzazione.

Per iniziare la ricerca, fai clic con il pulsante destro del mouse su .search file, seleziona Esegui come e scegli Ricerca lavoro IRI o Ricerca e correzione di lavoro IRI .

Cerca condurrà solo una ricerca, mentre Cerca e correggi tenterà inoltre di mascherare (o cancellare) i dati identificati. Entrambi genereranno un .darkdata file che identifica eventuali dati di interesse.

La fonte che ho usato è stata popolata con valori generati casualmente, quindi non c'è nulla di male nel condividere i .darkdata generati file qui. Tuttavia, quando si gestiscono informazioni effettivamente sensibili, gli utenti dovrebbero garantire il .darkdata il file non viene esposto e viene archiviato o eliminato in modo sicuro dopo il completamento della riparazione per evitare perdite di PII. IRI aggiungerà un'opzione di quarantena per l'archiviazione di .darkdata file e gli artefatti di ricerca corrispondenti in un luogo sicuro; contatta [email protected] per i dettagli su questa funzionalità pianificata.

Fase 3 – Riparazione (mascheramento)

Anche in questo caso, è possibile eseguire il mascheramento o l'eliminazione dei dati durante le operazioni di ricerca tramite Cerca e correggi opzione nella procedura guidata Dark Data Discovery. Tuttavia, se desideri solo esaminare le informazioni identificate e correggerle in un secondo momento, esegui i lavori di mascheramento da .darkdata file prodotto nella ricerca (passaggio 2) in questo modo: 

Fare clic con il pulsante destro del mouse su .darkdata file, passa il mouse su Esegui come e fare clic su Ripara lavoro IRI . Una volta eseguito il lavoro, i dati corretti dovrebbero apparire nel database di destinazione.

Ecco un esempio che mostra un prima e un dopo di una piccola raccolta di database MongoDB utilizzando il prompt dei comandi di Workbench per accedere al server Mongo locale:

CONCLUSIONE

In questo articolo abbiamo dimostrato la nuova capacità di IRI di accedere ai dati non strutturati nei database Mongo, negli spazi delle chiavi Cassandra e nei cluster Elasticsearch utilizzando diversi Matcher di ricerca in IRI DarkShield. Puoi controllare i .darkdata generati modello per vedere i risultati della ricerca che sono stati trovati e corretti e controlla il tuo database per vedere le tabelle/raccolte aggiornate.

  1. Se le PII sono incorporate in oggetti binari all'interno delle raccolte MongoDB, Cassandra ed Elasticsearch, possiamo automatizzare la loro estrazione in file standalone per le operazioni di ricerca/maschera DarkShield e la loro reimportazione.
  2. L'IDE IRI Workbench, basato su Eclipse™, integra tutte le funzionalità di mascheramento dei dati FieldShield, DarkShield e correlate e più ampie capacità di gestione dei dati nella piattaforma IRI Voracity.
  3. Il registro di connessione URL viene utilizzato per configurare e salvare le origini dati basate su URL utilizzate nelle operazioni di ricerca/maschera DarkShield e CoSort/SortCL (Voracity) ETL; ad esempio, HDFS, Kafka, bucket S3, MongoDB, S/FTP. Questo registro è simile, ma non identico, al registro delle connessioni dati in IRI Workbench per le origini dei database relazionali in cui i DSN ODBC sono collegati ai profili di connessione JDBC corrispondenti a vantaggio delle procedure guidate del lavoro che sfruttano entrambe le connessioni.
  4. Un abbinamento di ricerca è un'associazione tra una Classe di dati , che viene utilizzato per definire il metodo di ricerca per trovare e classificare le PII e una Regola dati che verrà applicato a qualsiasi istanza della classe di dati trovata nella raccolta o nella tabella. Inoltre, i Matcher di ricerca consentono di definire filtri che possono essere utilizzati per ridurre l'ambito della ricerca. Ciò è particolarmente utile nelle raccolte Mongo, nelle tabelle Cassandra e negli indici Elasticsearch perché il nome della chiave può essere indicativo delle PII memorizzate nel valore corrispondente.