Protezione dei dati inattivi e in movimento
Le applicazioni di database che aggiornano ed eseguono query sulle tabelle potrebbero dover proteggere i dati che entrano o vengono recuperati da tali tabelle. I dati sensibili devono essere protetti durante l'ingresso nella tabella, una volta nella tabella o in uscita. In ogni caso, l'obiettivo è impedire a persone non autorizzate di accedere a determinati valori di righe o colonne considerati sensibili.
Per i dati in forma normale (strutturati) nei database relazionali, l'utilità di mascheramento dei dati standalone IRI FieldShield, o la sua libreria compatibile di funzioni di mascheramento richiamabili, può adattarsi agli scenari precedenti, fornendo molte opzioni sia per statici (persistenti, a riposo) che dinamici (in -transit) opzioni di mascheramento dei dati. Se hai anche valori PII/PHI che fluttuano in modo casuale all'interno di colonne RDB semi e non strutturate (come testo, C/BLOB, XML/JSON), consulta questo articolo sull'approccio IRI DarkShield.
Questo articolo parlerà delle opzioni FieldShield, tuttavia, poiché la maggior parte degli utenti RDB si preoccupa di trovare e mascherare i valori di colonna fissa. Gli utenti FieldShield possono classificare, individuare e mascherare i dati nelle tabelle DB e, per gli utenti dell'applicazione, eseguire tramite:
- un data masking statico sulle tabelle di produzione e un smascheramento dinamico da parte degli utenti autorizzati dell'app
- Funzioni di mascheramento incorporate in processi di trasformazione, pulizia o reporting compatibili con i metadati
- un sistema di redazione di dati dinamici basato su proxy
- attraverso un'API SDK o un sistema, chiama da un programma
- in situ, tramite procedure SQL utilizzando una libreria personalizzata
Se i tuoi dati si trovano in database NoSQL come MongoDB, Cassandra, Elasticsearch o MarkLogic, FieldShield gestirebbe raccolte strutturate, mentre DarkShield gestirebbe raccolte strutturate e non strutturate.
Per impostazione predefinita — e il modo in cui la GUI di IRI Workbench presenta FieldShield agli utenti finali e ai DBA — una o più tabelle complete sono in genere protette con funzioni di mascheramento dei dati statici (come crittografia, redazione, pseudonimizzazione) in base alle regole aziendali. La scelta di ogni "scudo campo (colonna)" dovrebbe essere basata su sicurezza, realismo, reversibilità e forse considerazioni sulla CPU o sull'archiviazione.
L'approccio statico funziona bene quando i dati sono a riposo. È possibile proteggere la tabella di origine oppure è possibile creare una nuova tabella o file di destinazione con le protezioni applicate. Le applicazioni che recuperano i dati protetti non devono preoccuparsi della sicurezza perché le loro origini dati erano preprotette. I programmi FieldShield progettati per proteggere i dati inattivi possono anche essere programmati o richiamati in lavori batch per aggiornamenti regolari.
Tuttavia, in un ambiente in tempo reale in cui le righe aggiornate necessitano di protezione dinamica, le funzioni FieldShield devono essere integrate nel flusso di dati dell'applicazione. Ci sono diversi approcci da considerare:
1) Il tuo programma chiama FieldShield
Il database e altri programmi che recuperano o inviano dati nuovi o modificati in tabelle possono passarli a una funzione API di crittografia, hashing, codifica o redazione FieldShield in C, Java o .NET. Puoi anche trasferire i dati in movimento in un programma FieldShield autonomo attraverso una procedura di input o pipe. Ognuno di questi metodi può popolare i target con le funzioni di protezione (o rivelazione) a livello di colonna applicate.
2) FieldShield protegge solo gli aggiornamenti
I programmi FieldShield possono anche essere personalizzati tramite le funzioni /QUERY e /UPDATE, o per filtrare condizionalmente solo i nuovi record, dove le righe da proteggere soddisfano criteri specifici, come la novità. Le chiamate API consentirebbero una logica di business ancora più granulare e faciliterebbero più condizioni di "velocità" (o latenza) dei dati, ad esempio più mascheramento dei dati in tempo reale, perché tali esigenze possono essere espresse attraverso l'applicazione e definite dalla sua logica. Guarda questo esempio PL/SQL di mascheramento in tempo reale basato su un trigger.
3) Cattura e proteggi i delta in CoSort (FieldShield Parent)
I lavori di Change Data Capture (CDC) possono anche essere programmati in Sort Control Language (SortCL) di CoSort, dopodiché solo gli inserimenti, gli aggiornamenti, le eliminazioni o le righe non modificate selezionati possono essere passati a tabelle o file con le protezioni delle colonne applicate quando ciò accade. Gli utenti di CoSort hanno a disposizione tutte le funzioni di protezione FieldShield, quindi è possibile mascherare solo i dati modificati in questo paradigma di reporting in blocco.
4) Intercettazioni di query basate su proxy
IRI ora fornisce uno speciale driver "JDBC SQL Trail" per le applicazioni da utilizzare che filtra le query DB per utenti autorizzati e tabelle e colonne particolari. Coloro che non sono esentati dalla definizione della politica DDM vedranno solo valori completamente o parzialmente redatti in volo verso quell'applicazione appositamente collegata dal database, che rimane smascherata a riposo.
5) Integrazioni personalizzate
IRI può collaborare con il tuo DBA o programmatore di applicazioni per progettare una soluzione su misura che includa elementi di quanto sopra, o per fornire librerie FieldShield che le tue procedure SQL possono invocare in situ come queste per proteggere o rivelare (crittografare o decrittografare) query risultati, tabelle di query, viste materializzate e così via.
Contatta per assistenza sull'integrazione di una funzione di mascheramento dinamico dei dati come la redazione o la crittografia di conservazione del formato nella tua applicazione.
