Offuscamento dei dati in SQL Server

Qual è la migliore pratica per l'offuscamento dei dati in SQL Server?

Vorremmo utilizzare i dati di produzione mascherati nel nostro sistema UAT.

Se vogliamo farlo rapidamente e con un livello più elevato di oscuramento, quale approccio dovrebbe essere adottato? Sto pensando al personaggio che si affanna per il nome e il cognome della gente, ma come? Devo creare una funzione da solo o sono disponibili funzioni predefinite da utilizzare? Non voglio perdere tempo a reinventare la ruota :)

Che ne dici di campi data? Ad esempio, la data di nascita dovrebbe essere scelta casualmente da tutta la tabella e assegnata a un record, oppure esiste un modo migliore per farlo?

Vorrei poterti votare 100 punti solo per averci pensato! Ho visto questo argomento trascurato così tante volte che non è vero - così ben fatto. Da quello che ho capito in realtà vuoi mescolare i dati all'interno dei campi stessi, e anche se capisco cosa stai cercando di ottenere, potrebbe non essere del tutto necessario farlo - anche se dovrebbe essere considerato caso per caso.

La maggior parte delle leggi sulla protezione dei dati ruota attorno alla possibilità di associare correttamente un dato a un individuo, ad esempio una data di nascita o un numero di telefono. Puoi soddisfare i requisiti della legge assicurandoti che quando sposti i tuoi dati fuori produzione in UAT siano confusi, in modo che non possano essere facilmente mappati alla persona originale, specialmente quando si mescolano nome e cognome.

Tuttavia, questo non risolve il problema, ad esempio diciamo i dettagli di contatto. Puoi soddisfare i requisiti della legge mescolando i dati ma i numeri di telefono sono ancora reali, le e-mail ancora reali ecc ... non sono semplicemente assegnate alla persona corretta. Per questo ti consiglio se possibile cancellare quei dati prima di trasferirli in UAT, Red Gate fa un software chiamato Generatore di dati che può creare dati di test casuali per te in modo da poter ripopolare i campi con dati che possono essere testati.

Per quanto riguarda lo scrambling dei dati: esistono molte applicazioni che lo fanno per te e onestamente hai ragione a non voler reinventare la ruota. Quello che usiamo nella nostra azienda è un prodotto chiamato Data Masker da una società chiamata Net2000. La licenza è piuttosto economica, funziona in modo estremamente rapido e non devi preoccuparti di dover disabilitare tutti i tuoi vincoli prima di decodificare il database.

Puoi ovviamente creare la tua soluzione se non trovi qualcosa che soddisfi i tuoi requisiti - se decidi di farlo ti consiglio vivamente di utilizzare le procedure CLR per farlo poiché è molto più flessibile del puro TSQL (per non dire che tu non è possibile utilizzare TSQL vedere qui ).

Dopo aver scelto un'applicazione per eseguire questa operazione per te, la prossima cosa che devi decidere è che cosa vuoi veramente / di cui hai bisogno? Sinceramente la tua miglior risorsa per questo è il team legale della tua azienda e / o i revisori della società. So che a volte non ci piace lavorare con loro, ma saranno molto più gentili con te per avvicinarti a loro e porre loro la domanda piuttosto che cercare di farlo da soli e sbagliarli, non c'è assolutamente nulla di sbagliato nel chiedere aiuto - specialmente quando è importante come questo.

Spero che questo ti aiuti e ti auguro buona fortuna nella tua ricerca ... ;-)

Il signor Brownstone ha colpito l'unghia proprio sulla testa. Ora per aiutarti un po ', ecco la mia funzione "garble", usata per offuscare le stringhe (risultati divertenti con i nomi!). Passa una stringa, restituisce una stringa confusa. Includilo nelle istruzioni di aggiornamento rispetto alle colonne stringa. Modifica la lunghezza dei dati come ritieni opportuno.

---------------------
-- Garble Function --
---------------------
-- Make a function to slightly garble the strings
IF (object_id('fn_Garble') is not null)
  drop function fn_Garble
go
create function fn_Garble
(
  @String varchar(255)
)  
returns varchar(255)
as
BEGIN
  select @String = replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(@String,'o','e'),'a','o'),'i','a'),'u','i'),'t','p'),'c','k'),'d','th'),'ee','e'),'oo','or'),'ll','ski')
  return @String
END
go

Ho dovuto farlo per i miei dati di vendita al dettaglio dei miei clienti. Per i nomi sono andato al censimento e ho scaricato tutti i nomi e i cognomi, li ho fatti scorrere in un ciclo per unire ogni primo all'ultimo, ho aggiunto un codice sessuale e l'ho caricato in una tabella in maiuscolo. Ho quindi avuto un tavolo con circa 400 milioni di nomi univoci. Ho usato le lettere maiuscole poiché i nostri dati attuali non erano in maiuscolo, così da poter riconoscere più facilmente i dati cancellati.

Quando ho cancellato i miei dati utente ho scambiato i nomi, per compleanno ho messo tutti al 1 ° gennaio dell'anno in cui erano effettivamente nati e ho aggiornato tutti i numeri di telefono con il loro codice postale (i miei dati erano solo USA). Gli indirizzi e-mail sono diventati i primi iniziali più il cognome @ mycompany.co. L'indirizzo postale mi ha dato più dolore, ma ho mantenuto la città, lo stato e il CAP perché ritengo che non siano un problema se l'indirizzo viene cambiato. Avevo un collega che aveva un programma che generava lettere confuse e aggiornava la riga dell'indirizzo con quello.

Ovunque avessi dati duplicati ma avevo ancora un FK per l'utente principale (design errato sì, ma non mio), ho aggiornato anche quei dati in modo che il nome fosse coerente nel database per l'utente x.

Nel complesso i miei dati erano ancora molto leggibili sebbene l'indirizzo non avesse alcun senso. Mi ci sono voluti un paio di giorni per far funzionare tutto questo, ma una volta fatto e creato un lavoro di agente sql ho potuto cancellare i dati in appena 15 minuti.

Per offuscare un singolo campo, che ne dici di usare la funzione HASHBYTES (in SQL 2008+)? Puoi scegliere il tuo algoritmo (probabilmente MD5 è abbastanza) purché tu salini i tuoi dati. Quindi, invece di SELECT HASHBYTES('SHA2_256', <LAST NAME FIELD>) assicurarti di farlo SELECT HASHBYTES('SHA2_256', <LAST NAME FIELD> + '<my salt string>')e ora hai un hash che non può essere facilmente forzato.

È una funzione reale che è sostenibile, ripetibile e probabilmente molto più veloce. A seconda di quanto hai bisogno di proteggere veramente contro solo offuscare, potresti anche usare un hash più debole e più veloce.

Dai un'occhiata al modulo dbatools PowerShell per un'opzione gratuita per Static Data Masking, scritta da Chrissy Lemaire (@ chrissy-lemaire) e dal suo team. Tutti i loro strumenti sono fantastici, quindi sono sicuro che vale la pena dare un'occhiata.

I due comandi da cercare in dbatools sono: New-DbaDbMaskingConfig Invoke-DbaDbDataMasking

Dai un'occhiata al post sul blog che annuncia questo: mascheramento automatico dei dati