Il "Nuovo lavoro di protezione multitabella..." la procedura guidata in IRI Workbench descritta in questo articolo è uno dei modi in cui gli utenti del prodotto IRI FieldShield (o della piattaforma IRI Voracity) possono mascherare automaticamente le informazioni di identificazione personale (PII) nelle colonne del database che fanno parte di una relazione di chiave esterna, preservando così l'integrità referenziale tra i tavoli. Ciò garantisce che i record rimangano collegati anche dopo che sono stati resi anonimi.
Nota che dal 2018, un metodo più nuovo e più solido per ottenere lo stesso risultato è stato pubblicato nel nostro articolo sulla classificazione, scoperta e mascheramento di più tabelle di database qui, ed è dimostrato nei video di Youtube 1, 2, 3, 5 e 7 qui.
Ma in questa procedura guidata originale e ancora popolare, gli utenti preservano l'integrità referenziale definendo regole di mascheramento a livello di campo che vengono applicate automaticamente e in modo coerente alle colonne con nomi simili. Qualsiasi delle circa 14 categorie di funzioni di mascheramento dei dati disponibili per gli utenti FieldShield, tra cui crittografia, pseudonimizzazione e redazione, può essere applicata sulla base di tali regole.
Questa procedura guidata è più appropriata per gli utenti che mascherano e mappano più tabelle in uno schema che non contengono tutte PII. Ad esempio, IRI consiglia questa procedura guidata se hai 50 tabelle e devi spostarle tutte in un ambiente inferiore ma hai solo 20 tabelle contenenti PII da mascherare in modo coerente (le altre 30 non hanno PII).
Questo esempio utilizza solo tre tabelle Oracle — Departments, Employees e Job_History — per mostrare come funziona questa procedura guidata. Quando le tabelle sono state originariamente progettate, il numero di previdenza sociale del dipendente è stato utilizzato per il loro ID. Ciò crea un rischio per la sicurezza durante l'esecuzione di rapporti che mostrano il campo ID.
Il diagramma E-R sopra per tali tabelle, la query SQL e i risultati riportati di seguito sono tutti mostrati in varie GUI di IRI Workbench per le viste FieldShield. Vedere questo articolo relativo a:Creazione di ERD in IRI Workbench. La query ha unito le informazioni su dipendenti, manager e reparti, ma espone i valori del numero di previdenza sociale (SSN) nelle colonne SID dipendente e SID manager. Consulta questo articolo sulla codifica e l'esecuzione di processi SQL in IRI Workbench.
Utilizzo del Processo di protezione da più tabelle FieldShield procedura guidata, questi campi possono essere crittografati (o altrimenti de-identificati) in modo che i veri SSN siano mascherati nelle tabelle e nelle query successive. L'integrità referenziale viene mantenuta perché la stessa crittografia viene applicata a tutte le tabelle utilizzando un'unica regola.
Nella pagina di configurazione della procedura guidata, ODBC è selezionato come caricatore. Le tre suddette tabelle sono selezionate nella pagina Estrazione dati. La pagina successiva è la pagina Regole di modifica campo. In questa pagina si possono disegnare le regole da applicare a tutte le tabelle estratte selezionate.
Facendo clic su Crea si aprirà la pagina Field Rule Matcher. Qui è dove vengono inseriti i dettagli del matcher. Inizia inserendo un nome di corrispondenza.
Dopo aver fatto clic su Crea accanto a Nome regola , viene visualizzata la pagina Selezione guidata nuova regola del campo di protezione. Seleziona Funzioni di crittografia o decrittografia . Questa selezione garantisce che lo stesso algoritmo di protezione si applichi a tutti i dati, garantendo l'integrità referenziale.
La pagina successiva è dove viene selezionato il tipo di crittografia. In questo caso, enc_fp_aes256_ascii viene utilizzato. Questo algoritmo di crittografia di conservazione del formato utilizza il set di caratteri ASCII per sostituire i dati reali. Viene utilizzato in questa dimostrazione in modo che la crittografia sia evidente nell'output. Una scelta più realistica sarebbe normalmente l' alphanum versione, che conserverebbe anche l'aspetto effettivo dei SSN (in questo caso 9 numeri).
Sebbene questo esempio utilizzi una passphrase incorporata, è possibile utilizzare anche un file di password per la chiave di crittografia, così come una variabile di ambiente.
Facendo clic su Fine inserirà questa regola nel matcher. Successivamente, è necessario creare il matcher stesso. Fai clic su Aggiungi nei Matcher sezione. Si aprirà la pagina dei dettagli del matcher delle regole sul campo. Qui è possibile utilizzare un modello o una classe di dati. Consulta l'articolo Applicazione delle regole sul campo utilizzando la classificazione per i dettagli sulla seconda opzione.
In questo esempio, Motivo è selezionato e .*SID è inserito nei dettagli. Questa espressione regolare corrisponderà a tutti i nomi di colonna che terminano con SID.
Il matcher finisce con i dettagli visualizzati di seguito. Il test il pulsante può essere utilizzato per testare i matcher per assicurarsi che corrispondano a tutte le colonne previste. È possibile inserire più dettagli di corrispondenza e utilizzare la logica AND/OR per produrre corrispondenze a grana fine. Ad esempio, è presente una colonna aggiuntiva denominata VP_SSN . Lo stesso abbinamento di cui sopra potrebbe essere utilizzato con un altro abbinamento con uno schema di .*SSN e l'operatore AND da abbinare a questa colonna aggiuntiva ma con la stessa regola.
Facendo clic su OK qui torna alla pagina Regole in cui viene visualizzato ogni abbinamento di regole. È possibile utilizzare abbinamenti diversi per campi diversi in modo che sia necessario un solo passaggio di trasformazione anche se le regole dovessero mascherare colonne diverse in modi diversi.
Facendo clic su Avanti visualizzerà la pagina della fase di caricamento dei dati. Qui è dove vengono selezionate la tabella di output e le opzioni. In questo esempio vengono selezionate le stesse tabelle delle tabelle di input. Inoltre, la modalità di output viene modificata in Crea per troncare le tabelle prima del caricamento in modo che le chiavi univoche non vengano violate.
Dopo aver fatto clic su Fine , viene creata una cartella con più script che verranno eseguiti con il file batch incluso.
Per vedere come la regola trasformerà il campo e ci darà la possibilità di modificare manualmente le cose, il SCOTT_EMPLOYEES.fcl lo script può essere rivisto nell'editor di Workbench. Nell'output, sia il EMPLOYEE_SID e il MANAGER_SID mostra l'algoritmo di crittografia applicato.
Dopo aver eseguito il file batch, la stessa query SQL mostra gli stessi risultati uniti, ma con il Employee_SID e Manager_SID ora crittografato. Inoltre, viene preservata l'integrità referenziale. Vengono mantenuti i rapporti originali tra il dipendente e il manager e gli ID del manager sulla riga 2 e del dipendente sulla riga 26 sono gli stessi.
Questo esempio mostra come una regola di crittografia può essere utilizzata su più colonne in più tabelle mantenendo l'integrità referenziale. Tutte le regole create durante le procedure guidate dei processi vengono salvate in una libreria di regole. Ciò consente di riutilizzarli e persino condividerli con colleghi in modo da garantire gli stessi risultati sugli stessi dati.
In caso di domande sulle regole di mascheramento dei dati FieldShield o se hai bisogno di aiuto per l'utilizzo di una delle sue procedure guidate di rilevamento o mascheramento dei dati, contatta il tuo rappresentante IRI.
