Principi Base del Mascheramento Dinamico
Introduzione
Questo documento descrive come DataSunrise maschera i dati sensibili al volo e come viene eseguito il mascheramento per tipi di database SQL e NoSQL.
Principi di Mascheramento dei Dati
Iniziamo dall’inizio e familiarizziamo con due principi base di mascheramento dei dati nel database:
- Metodo di mascheramento basato sulla modifica dei set di risultati della query
- Metodo di mascheramento basato sulla modifica della query SQL
DataSunrise utilizza entrambi gli approcci per diversi tipi di DBMS. DataSunrise modifica una query SQL quando è possibile, e nei DBMS che hanno poche funzionalità di linguaggio (ad esempio, database NoSQL), viene utilizzata la modifica del set di risultati.
Analizziamo i vantaggi e gli svantaggi di entrambi i metodi di mascheramento.
Metodo di Mascheramento Basato sulla Modifica dei Set di Risultati della Query
Utilizzando questo approccio, il database riceve la query originale e restituisce i dati come solitamente accade:
Tutto appare abbastanza semplice e logico. Ora diamo un’occhiata ai dettagli di questo approccio:
Come elaborare i dati restituiti dalla funzione? Ad esempio, caso:
SELECT anyFunction(email) FROM customers;
Varie metodi di modifica delle stringhe come la concatenazione o il casting di una stringa in minuscolo/maiuscolo, ottenendo una sottostringa, ecc. sono anche correlati a questo caso.
Non c’è modo di offuscare i dati che non sono stati restituiti all’applicazione client. Per 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 verranno salvati nelle tabelle create, causando una perdita di dati.
Le applicazioni client ampiamente diffuse raramente utilizzano query isolate. Solitamente, 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 in cui il campo chiave è mascherato, allora per far sì che l’applicazione continui a funzionare correttamente, diventa necessaria una modifica della query. Per esempio, un’applicazione riceve un elenco di indirizzi email mascherati che viene utilizzato come condizione per recuperare i dati:
SELECT * FROM demotest.customers WHERE email='[email protected]';
SELECT * FROM demotest.customers WHERE email=?; -- ? rappresenta una variabile associata
Poiché la tabella non contiene tale valore email, la logica dell’applicazione client sarà interrotta. Poiché un’applicazione client attenderà informazioni dal valore chiave che l’applicazione client ha ricevuto in precedenza.
In conclusione, come si può vedere dalle situazioni descritte, è un obiettivo complicato (e talvolta anche impossibile) fornire un metodo di mascheramento dei dati che non influisca sul processo operativo di un’applicazione client.
Metodo di Mascheramento Basato sulla Modifica della 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;
Pertanto, i dati sensibili che dovrebbero essere mascherati non lasciano il database. Risolve anche tutti i principali problemi di offuscamento dei dati:
I dati già offuscati vengono forniti alle funzioni:
SELECT anyFunction('masked') FROM customers;SELECT anyFunction(maskFunction(email)) FROM customers;
Lo stesso metodo di offuscamento dei dati è possibile per le operazioni eseguite internamente nel database:
CREATE TABLE customers2 AS SELECT maskFunction(email) FROM customers;
C’è 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. In tal modo, la logica operativa dell’applicazione client non sarà influenzata.
Sezioni Principali della Regola di Mascheramento Dinamico dei Dati
In questa sezione forniremo esempi di schermate di come questi parametri influiscono sul processo di lavoro con il database quando la regola di mascheramento dinamico è attiva.
Immaginiamo la situazione in cui desideriamo 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 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; ORDINE_ID NOME COGNOME INDIRIZZO STATO CAP EMAIL CARTA --------- ---------- --------- -------------------- ----- --- ------------------------------- -------------------- 1.121 Kathy Abrams High Street, Wheeling MO 132068 [email protected] 4024-0071-8423-6700 4.667 Alma Wade Green Lane, Newport NE 21771 [email protected] 6011-0551-9875-8094 3.427 Mary Evans 13 The Limes, Leighton OR 10950 [email protected] 4024-4392-7160-9980 3 righe selezionate.
Come si può vedere, abbiamo 8 colonne. Secondo il nostro scenario, la colonna “carta” dovrebbe essere mascherata. Per farlo, verrà creata una regola di Mascheramento Dinamico. Nella configurazione della regola di mascheramento dinamico, verrà impostato di mascherare la colonna Carta utilizzando il metodo di mascheramento delle carte di credito integrato. Diamo un’occhiata rapida alle impostazioni della regola. Ci sono sezioni della regola:
Sezione principale. Qui vengono specificati il nome della regola, il tipo di database e il database stesso.
Sezione Azione. Questa sezione contiene le opzioni che sono state menzionate nell’elenco. Cambieremo queste opzioni lungo il percorso dello scenario e tracciamo come le modifiche influenzeranno i risultati e le prestazioni delle query alla tabella dei clienti. All’inizio, tutte le opzioni saranno lasciate come predefinite.
Sezione della sessione di filtro e impostazioni di mascheramento. Se ci sono filtri specificati, la regola verrà attivata solo se la condizione soddisfa i requisiti. In qualsiasi altro caso la regola non sarà attivata. Dato che non abbiamo specificato alcun filtro, la regola funzionerà sempre, su qualsiasi query mirata alla tabella dei clienti.
Inoltre, è stato scelto il metodo di mascheramento della carta di credito per la colonna della tabella dei clienti.
Ora che 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; ORDINE_ID NOME COGNOME INDIRIZZO STATO CAP EMAIL CARTA --------- ---------- --------- -------------------- ----- --- ------------- ------------------- 1.121 Kathy Abrams High Street, Wheeling MO 132068 [email protected] XXXX-XXXX-XXXX-6700 4.667 Alma Wade Green Lane, Newport NE 21771 [email protected] XXXX-XXXX-XXXX-8094 3.427 Mary Evans 13 The Limes, Leighton OR 10950 [email protected] XXXX-XXXX-XXXX-9980 3 righe selezionate.Come si può vedere dallo screenshot, la colonna Carta è stata mascherata secondo la configurazione della regola.
Opzioni Principali della Regola di Mascheramento Dinamico dei Dati
Colonne per il Mascheramento
È semplice, questo parametro è responsabile delle colonne che saranno mascherate.
Algoritmo di Mascheramento
Questo è l’algoritmo che verrà utilizzato nel mascheramento delle colonne. L’algoritmo scelto influisce direttamente sul valore che verrà restituito tentando di recuperare i valori delle colonne mascherate.
Ecco l’elenco di esempio degli algoritmi di mascheramento che potrebbero essere utilizzati con DataSunrise (per informarti su altri algoritmi di mascheramento, ti preghiamo di fare riferimento alla nostra Guida per l’Utente a p. 148 dove puoi trovare una chiarificazione dettagliata su questi):
Numero di Carta di Credito – algoritmo progettato per mascherare i numeri di carta di credito. Visualizza le ultime quattro cifre di un numero di carta di credito, altri caratteri sono sostituiti con “X”. Ad esempio: XXXXXXXX-XXXX-1234.
Mascheramento E-mail – il nome utente e la sezione dominio degli indirizzi email sono sostituiti 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 predefinita dall’utente.
DataSunrise Security Suite supporta anche funzioni personalizzate (funzioni specificate nel database) da utilizzare come metodo di mascheramento e script LUA creati direttamente nell’ambiente DataSunrise WebUI.
Sessione di Filtro
Questo parametro può essere specificato per configurare il comportamento della regola di Mascheramento Dinamico secondo diverse condizioni. Qui è l’elenco dei parametri di condizione:
Applicazione – nome dell’applicazione client
Utente dell’Applicazione – nome dell’utente dell’applicazione
Utente DB – nome dell’utente del DB
Host – indirizzo IP o alias da cui l’utente o l’applicazione si connette al database
Utente OS – nome dell’utente del sistema operativo
Proxy – proxy DataSunrise in cui la regola dovrebbe operare nel caso in cui molti proxy fossero configurati
Ad esempio, si desidera mascherare i dati per l’Utente Ospite DB e non si desidera mascherare i dati per l’Utente Amministratore DB, il che è comprensibile. In questo caso, si specifica semplicemente Utente DB Uguale Ospite e la regola di mascheramento verrà attivata solo quando l’Ospite eseguirà query sulle colonne mascherate della tabella.
Mantenere il Conteggio delle Righe
Questa opzione è responsabile del mascheramento dei valori utilizzati in dove, join ecc. clausole delle query:
quando disabilitata, i valori dei campi che dovrebbero essere mascherati saranno mascherati, anche se sono utilizzati nella clausola WHERE/JOIN.
quando abilitata, il mascheramento dei valori utilizzati nelle clausole menzionate sarà disabilitato. Il set di risultati restituito conterrà lo stesso numero di righe che sarebbe stato restituito se non fosse stata applicata alcuna regola di mascheramento. Questa opzione aiuta a ricevere lo stesso conteggio delle righe anche se i dati sono mascherati perché i suoi valori reali possono essere utilizzati nelle clausole WHERE/JOIN della query.
Per comprendere meglio la situazione, supponiamo di conoscere una parte di un numero di carta ed è 4024. Abbiamo due clienti il cui numero di carta di credito contiene questo numero:
Kathy Abrams 4024-0071-8423-6700
Mary Evans 4024-0071-2955-9980
Vediamo cosa accade se l’opzione è disabilitata:
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card FROM demotest.democust WHERE card LIKE '%4024%'; nessuna riga selezionata.
La query non restituirà alcun risultato poiché i risultati sono mascherati e l’applicazione non può trovare tali campi.
Vediamo cosa accade se l’opzione è abilitata:
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card FROM demotest.democust WHERE card LIKE '%4024%'; ORDINE_ID NOME COGNOME INDIRIZZO STATO CAP EMAIL CARTA --------- --------- ------------- ----------------- ---- ----- ------------------- ------------ 1.121 Kathy Abrams High Street, Wheeling MO 132068 [email protected] XXXX-XXXX-XXXX-6700 3.427 Mary Evans 13 The Limes, Leighton OR 10950 [email protected] XXXX-XXXX-XXXX-9980 2 righe selezionate.
Come si può vedere qui, anche se i risultati sono mascherati, si può ancora usare 4024 per trovare le carte che contengono tale parte, ma non si può vederla nel set di risultati.
Mascherare Solo le SELECT
Questo parametro è responsabile della regola per mascherare i valori delle colonne specificate SOLO se i dati sono recuperati tramite query di tipo SELECT. Vediamo come funziona:
SQL> SELECT card FROM demotest.democust; CARTA -------------------- XXXX-XXXX-XXXX-6700 XXXX-XXXX-XXXX-8094 XXXX-XXXX-XXXX-9980 3 righe selezionate.
Come si può vedere qui, i valori delle carte sono stati recuperati utilizzando una istruzione SELECT e secondo la regola, la colonna del numero della carta è mascherata.
Ora proviamo a eseguire la prossima query e vediamo cosa succede:
SQL> UPDATE demotest.democust SET state = card; 3 righe aggiornate. SQL> SELECT order_id, first_name, last_name, state, zip, card FROM demotest.democust; ORDINE_ID NOME COGNOME STATO CAP CARTA --------- ---------- --------- ------------------ -------- -------------------- 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 righe selezionate.
Come si può vedere, la colonna “stato” ora ha valori reali della colonna “carta” mascherata, perché non è stata eseguita una query di tipo SELECT. Tuttavia, se verrà eseguita una query di tipo SELECT per la colonna mascherata, sarà ancora mascherata.
Bloccare una Query Quando la Colonna Mascherata è Relativa a una Modifica di Dati
L’obiettivo di questo parametro è spiegato dal suo nome. È anche una casella di controllo che è 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 è destinata a cambiare il valore nella colonna mascherata tale query verrà bloccata. Proviamo a eseguire una query che sarà mirata a modificare un numero di carta utilizzando la seguente query:
SQL> UPDATE demotest.democust SET card = '1234' WHERE card LIKE '%6700%'; ERRORE alla riga 1: Errore SQL [42501]: La query è bloccata
Come risultato, viene restituito “La query è bloccata”.
Conclusione
La funzione di Mascheramento Dinamico è una delle funzionalità più utilizzate del nostro prodotto. Questa funzione 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 soluzione migliore per i database SQL e per i database NoSQL.
Le regole di Mascheramento Dinamico hanno molte opzioni che possono essere configurate da un utente. Le più significative di queste sono:
- Opzione Mantenere il Conteggio delle Righe è responsabile della restituzione dello stesso conteggio delle righe restituito da una query come sarebbe restituito se non fosse configurata alcuna regola di mascheramento. Se questa opzione è attiva, la parte condizionale di una query che viene utilizzata per filtrare i dati utilizzando le clausole where/join/etc. non verrà mascherata. Questa opzione è importante per coloro che utilizzano applicazioni client e non vogliono vedere un diverso conteggio delle righe restituito da una query quando è attiva una regola di mascheramento.
- Opzione Mascherare Solo le SELECT è responsabile del mascheramento solo delle parti di select di una query. Se questa opzione è attiva, solo quelle colonne che si trovano dopo l’istruzione SELECT e sono specificate nella regola saranno mascherate. Anche questa opzione è importante per chi utilizza applicazioni client che eseguono query automaticamente generate per es. istruzioni UPDATE TABLE. Perché tutte le operazioni con i dati della tabella mascherata non saranno influenzate in alcun modo ma saranno viste mascherate se i dati verranno selezionati.
- Opzione Bloccare una Query Quando la Colonna Mascherata è Relativa a una Modifica di Dati è responsabile per il blocco di qualsiasi operazione che interessa la colonna mascherata in qualsiasi modo. Se una colonna mascherata è menzionata in qualsiasi parte della query stessa, la query verrà bloccata. Questa opzione è importante per chi non vuole perdere dati sensibili per errore o per intenzione.