Principi di Base del Mascheramento Dinamico
Introduzione
Questo documento descrive come DataSunrise implementa i Principi di Mascheramento Dinamico dei Dati per dati sensibili in tempo reale e come il mascheramento viene eseguito per i tipi di database SQL e NoSQL.
Principi di Mascheramento dei Dati
Partiamo dall’inizio e familiarizziamo con i due principi di base del mascheramento dei dati nel database:
- Metodo di mascheramento basato sulla modifica dei set di risultati delle query
- Metodo di mascheramento basato sulla modifica delle query SQL
DataSunrise utilizza entrambi gli approcci per i diversi tipi di DBMS. DataSunrise modifica una query SQL stessa dove è possibile, e in quei DBMS che hanno poche funzionalità linguistiche (per esempio, database NoSQL), viene utilizzata la modifica del set di risultati.
Diamo uno sguardo ai vantaggi e svantaggi di entrambi i metodi di mascheramento.
Metodo di Mascheramento Basato sulla Modifica dei Set di Risultati delle Query
Utilizzando questo approccio, il database riceve la query originale e restituisce i dati come avviene normalmente:
Tutto sembra abbastanza semplice e logico. Ora diamo uno sguardo ai dettagli di questo approccio:
Come elaborare i dati restituiti dalla funzione? Ad esempio, il caso:
SELECT anyFunction(email) FROM customers;
Sono anche correlati a questo caso vari metodi di modifica delle stringhe come la concatenazione o la conversione di una stringa a minuscolo/maiuscolo, ottenere una sottostringa, ecc.
Non c’è modo di offuscare i dati che non sono stati restituiti all’applicazione cliente. Ad esempio:
CREATE TABLE demotest.democust AS SELECT * FROM demotest.customers;
o
INSERT INTO demotest.democust SELECT * FROM demotest.customers;
in queste query, i dati di origine saranno salvati nelle tabelle create, il che causa una perdita di dati.
Le applicazioni client ampiamente diffuse raramente utilizzano query isolate. Di solito, le query vengono eseguite una dopo l’altra e il set di risultati della prima query viene utilizzato in una seconda query e così via. Se consideriamo un caso del genere in cui il campo chiave è mascherato, allora per far sì che l’applicazione continui a funzionare correttamente, diventa necessaria una modifica della query. Ad esempio, un’applicazione riceve un elenco di indirizzi email mascherati utilizzato come condizione per recuperare i dati:
SELECT * FROM demotest.customers WHERE email=’masked@email.com’;
SELECT * FROM demotest.customers WHERE email=?; -- ? rappresenta una variabile vincolata
Poiché la tabella non contiene tale valore di email, la logica dell’applicazione cliente sarà interrotta. Poiché un’applicazione cliente attenderà le informazioni per il valore chiave che un’applicazione cliente ha ricevuto precedentemente.
Come conclusione, si può vedere dalle situazioni descritte, che è un obiettivo complicato (e talvolta addirittura impossibile) fornire il metodo di mascheramento dei dati che non influisca sul processo di lavoro di un’applicazione cliente.
Metodo di Mascheramento Basato sulla Modifica delle Query SQL
In questo approccio, il testo della query SQL viene modificato. Costrutti speciali sono integrati nella query che impediscono l’estrazione di dati sensibili dal database:
Nel caso semplice, la conversione appare così:
SELECT email FROM customers -> SELECT ‘masked’ FROM customers;
Quindi, i dati sensibili che dovrebbero essere mascherati non lasciano il database. Risolve anche tutti i principali problemi dell’offuscamento dei dati:
Dati già offuscati forniti a funzioni:
SELECT anyFunction(‘masked’) FROM customers;
SELECT anyFunction(maskFunction(email)) FROM customers;
Lo stesso metodo di offuscamento dei dati è possibile per le operazioni che vengono eseguite internamente nel database:
CREATE TABLE customers2 AS SELECT maskFunction(email) FROM customers;
Esiste anche la possibilità di mascherare le colonne che sono state specificate non solo nella parte select della query ma anche nella parte condizionale della query ad esempio where/join. Pertanto, la logica di lavoro dell’applicazione cliente non sarà influenzata.
Sezioni Principali della Regola di Mascheramento Dinamico dei Dati
In questa sezione forniremo esempi di schermate di come questi parametri influenzano il processo di lavoro con il database quando la regola di mascheramento dinamico è attiva.
Immaginiamo la situazione in cui vogliamo che qualcuno che lavora con il database e la tabella dei clienti non veda i dati delle carte di credito contenuti nella tabella.
Per eseguire un tale scenario, utilizzeremo la nostra tabella di test che contiene diverse informazioni sui clienti:
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card FROM demotest.democust;
ORDER_ID FIRST_NAME LAST_NAME ADDRESS STATE ZIP EMAIL CARD
--------- ---------- --------- --------------------- ----- -------- ------------------- -------------------
1,121 Kathy Abrams High Street, Wheeling MO 132068 kitykatty@fugie.com 4024-0071-8423-6700
4,667 Alma Wade Green Lane, Newport NE 21771 almwa@nprt.com 6011-0551-9875-8094
3,427 Mary Evans 13 The Limes, Leighton OR 10950 evensmary@hitmail.com 4024-4392-7160-9980
3 rows selected.
Come si può vedere, abbiamo 8 colonne. Secondo il nostro scenario, la colonna “card” dovrebbe essere mascherata. Per fare ciò, verrà creata una regola di Mascheramento Dinamico. Nella configurazione della regola di mascheramento dinamico, sarà impostato di mascherare la colonna Card utilizzando il metodo di mascheramento della carta di credito integrato. Diamo un’occhiata rapida alle impostazioni della regola. Ci sono sezioni della regola:
Sezione principale. Nome della regola, tipo di database e il database stesso sono specificati qui.
Sezione Azione. Questa sezione contiene le opzioni menzionate nell’elenco. Cambieremo queste opzioni percorrendo lo scenario e tracceremo come i cambiamenti influenzeranno i risultati e le prestazioni delle query sulla tabella dei clienti. All’inizio, tutte le opzioni saranno lasciate come predefinite.
Sezione filtro sessione e impostazioni di mascheramento. Se ci sono filtri specificati, la regola sarà attivata solo se la condizione soddisfa i requisiti. In ogni altro caso la regola non sarà attivata. Poiché non abbiamo specificato alcun filtro, la regola funzionerà sempre, su qualsiasi query mirata alla tabella dei clienti.
Inoltre, è scelto il metodo di mascheramento della carta di credito per la colonna della tabella dei clienti.
Ora, quando la regola è configurata, proviamo a eseguire la stessa query per selezionare tutte le colonne dalla tabella dei clienti:
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card FROM demotest.democust; ORDER_ID FIRST_NAME LAST_NAME ADDRESS STATE ZIP EMAIL CARD --------- ---------- --------- --------------------- ----- -------- ------------------- ------------------- 1,121 Kathy Abrams High Street, Wheeling MO 132068 kitykatty@fugie.com XXXX-XXXX-XXXX-6700 4,667 Alma Wade Green Lane, Newport NE 21771 almwa@nprt.com XXXX-XXXX-XXXX-8094 3,427 Mary Evans 13 The Limes, Leighton OR 10950 evensmary@hitmail.com XXXX-XXXX-XXXX-9980 3 rows selected.Come si può vedere nello screenshot, la colonna Card è stata mascherata secondo la configurazione della regola.
Opzioni Principali della Regola di Mascheramento Dinamico dei Dati
Colonne da Mascherare
È semplice, questo parametro è responsabile delle colonne che saranno mascherate.
Algoritmo di Mascheramento
Questo è l’algoritmo che verrà utilizzato per il mascheramento delle colonne. L’algoritmo scelto influisce direttamente sul valore che verrà restituito provando a recuperare i valori delle colonne mascherate.
Ecco l’elenco esempio degli algoritmi di mascheramento che potrebbero essere utilizzati con DataSunrise (per essere informati sugli altri algoritmi di mascheramento si prega di fare riferimento alla nostra Guida Utente p. 148 dove è possibile trovare una dettagliata chiarimento su questi):
Numero di Carta di Credito – l’algoritmo è mirato a mascherare i numeri delle carte di credito. Mostra le ultime quattro cifre di un numero di carta di credito, altri caratteri sono sostituiti con “X”. Ad esempio: XXXXXXXX-XXXX-1234.
Mascheramento Email – la sezione nome utente e dominio degli indirizzi email sono sostituite con “*”, tranne il primo e l’ultimo in una riga. Ad esempio: a***@**.**m.
Stringa Fissa – i valori di tipo STRINGA sono sostituiti con una stringa definita dall’utente.
Il DataSunrise Security Suite supporta anche funzioni personalizzate (funzioni specificate nel database) da essere utilizzate come metodo di mascheramento e script LUA che sono creati direttamente nell’ambiente WebUI di DataSunrise.
Filtro Sessione
Questo parametro può essere specificato per configurare il comportamento di una regola di Mascheramento Dinamico in base a diverse condizioni. Ecco l’elenco dei parametri di condizione:
Applicazione – nome dell’applicazione cliente
Utente Applicazione – nome dell’utente dell’applicazione
Utente DB – nome dell’utente del database
Host – indirizzo IP o alias da cui l’utente o l’applicazione si connette al database
Utente SO – nome dell’utente del sistema operativo
Proxy – Proxy di DataSunrise dove la regola dovrebbe funzionare nel caso in cui siano stati configurati più proxy
Ad esempio, si vuole mascherare i dati per l’Utente Ospite del DB, e non si vuole mascherare i dati per l’Utente Amministratore del DB, il che è comprensibile. In questo caso, si specifica semplicemente l’Utente DB uguale Ospite e la regola di mascheramento sarà attivata solo quando l’Utente Ospite esegue query sulle colonne mascherate della tabella.
Mantenere il Conteggio delle Righe
Questa opzione è responsabile del mascheramento dei valori usati nelle clausole where, join ecc. delle query:
quando disattivata, i valori dei campi che devono essere mascherati saranno mascherati anche se sono utilizzati nella clausola WHERE/JOIN.
quando attivata, il mascheramento dei valori usati nelle clausole menzionate sarà disabilitato. Il set di risultati restituito conterrà lo stesso conteggio di righe come sarebbe stato restituito se non fosse stata applicata alcuna regola di mascheramento. Questa opzione aiuta a ricevere lo stesso conteggio di righe anche se i dati sono mascherati perché i loro valori reali possono essere usati nelle clausole WHERE/JOIN della query.
Per capire più a fondo la situazione, supponiamo che io conosca parte di un numero di carta ed è 4024. Abbiamo due clienti il cui numero di carta di credito contiene questa parte:
Kathy Abrams 4024-0071-8423-6700
Mary Evans 4024-0071-2955-9980
Vediamo cosa succede se l’opzione è disattivata:
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card FROM demotest.democust WHERE card LIKE '%4024%'; no rows selected.
La query non restituirà alcun risultato poiché i risultati sono mascherati e l’applicazione non può trovare tali campi.
Vediamo cosa succede se l’opzione è attivata:
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card
FROM demotest.democust
WHERE card LIKE '%4024%';
ORDER_ID FIRST_NAME LAST_NAME ADDRESS STATE ZIP EMAIL CARD
--------- ---------- --------- --------------------- ----- -------- ------------------- -------------------
1,121 Kathy Abrams High Street, Wheeling MO 132068 kitykatty@fugie.com XXXX-XXXX-XXXX-6700
3,427 Mary Evans 13 The Limes, Leighton OR 10950 evensmary@hitmail.com XXXX-XXXX-XXXX-9980
2 rows selected.
Come puoi vedere qui, anche se i risultati sono mascherati, possiamo comunque usare 4024 per trovare le carte che contengono tale parte, ma non possiamo vederlo nel set di risultati.
Mascherare solo SELECT
Questo parametro è responsabile della regola per mascherare i valori delle colonne specificate SOLO se i dati vengono recuperati tramite il tipo di query SELECT. Diamo un’occhiata a come funziona:
SQL> SELECT card FROM demotest.democust; CARD ------------------- XXXX-XXXX-XXXX-6700 XXXX-XXXX-XXXX-8094 XXXX-XXXX-XXXX-9980 3 rows selected.
Come si può vedere qui, i valori delle carte sono stati recuperati utilizzando l’istruzione SELECT e, secondo la regola, la colonna del numero di carta è mascherata.
Ora proviamo a eseguire la query successiva e vediamo cosa succede:
SQL> UPDATE demotest.democust SET state = card;
3 rows updated.
SQL> SELECT order_id, first_name, last_name, state, zip, card FROM demotest.democust;
ORDER_ID FIRST_NAME LAST_NAME STATE ZIP CARD
--------- ---------- --------- ------------------- -------- -------------------
1,121 Kathy Abrams 4024-0071-8423-6700 132068 XXXX-XXXX-XXXX-6700
4,667 Alma Wade 6011-0551-9875-8094 21771 XXXX-XXXX-XXXX-8094
3,427 Mary Evans 4485-4392-7160-9980 10950 XXXX-XXXX-XXXX-9980
3 rows selected.
Come si può vedere, la colonna “state” ora ha valori reali della colonna “card” mascherata, perché non è stato eseguito alcun tipo di query SELECT. Tuttavia, se verrà eseguito un tipo di query SELECT per la colonna mascherata, verrà comunque mascherata.
Blocca una Query Quando la Colonna Mascherata è Relativa a una Modifica dei Dati
L’obiettivo di questo parametro è spiegato dal suo nome. È anche una casella di controllo selezionata per impostazione predefinita quando si crea una regola di Mascheramento Dinamico. Nel caso in cui ci sia una query che va al proxy DataSunrise e una query mira a cambiare il valore nella colonna mascherata, tale query sarà bloccata. Proviamo a eseguire una query che mira a modificare un numero di carta utilizzando la prossima query:
SQL> UPDATE demotest.democust SET card = '1234' WHERE card LIKE '%6700%'; ERROR at line 1: SQL Error [42501]: La query è bloccata
Come risultato è stato restituito “La query è bloccata”.
Conclusione
La funzionalità di Mascheramento Dinamico è una delle caratteristiche più utilizzabili del nostro prodotto. Questa funzionalità aiuta a mascherare i dati sensibili del database protetto secondo la configurazione della regola impostata dall’utente.
DataSunrise utilizza gli approcci più appropriati su come mascherare i dati sensibili scegliendo la migliore soluzione sia per i database SQL che per i database NoSQL.
Le regole di Mascheramento Dinamico hanno molte opzioni che possono essere configurate da un utente. Le più significative sono:
- Opzione Mantenere il Conteggio delle Righe è responsabile del ritorno dello stesso conteggio di righe restituito da una query come sarebbe restituito se non ci fosse configurata alcuna regola di mascheramento. Se questa opzione è attiva, la parte condizionale di una query che è usata per filtrare i dati tramite clausole where/join/ecc. non sarà mascherata. Questa opzione è importante per coloro che utilizzano applicazioni cliente e non vogliono vedere conteggi di righe diversi restituiti da una query quando la regola di mascheramento è attiva.
- L’opzione Mascherare solo SELECT è responsabile di mascherare solo le parti select di una query. Se questa opzione è attiva, solo quelle colonne che seguono l’istruzione SELECT e che sono specificate nella regola verranno mascherate. Questa opzione è anche importante per coloro che utilizzano applicazioni cliente che eseguono query generate automaticamente per esempio, istruzioni UPDATE TABLE. Perché tutte le operazioni con i dati delle tabelle mascherate non saranno influenzate in alcun modo ma saranno viste mascherate se i dati saranno selezionati.
- L’opzione Blocca una Query Quando la Colonna Mascherata è Relativa a una Modifica dei Dati è responsabile di bloccare qualsiasi operazione che influisce sulla colonna mascherata in qualsiasi modo. Se una colonna mascherata è menzionata in qualsiasi parte della query stessa, la query sarà bloccata. Questa opzione è importante per coloro che non vogliono perdere dati sensibili per errore o intenzionalmente.