Crittografia a livello di campo SQL, quanto è sicuro?

Se si desidera utilizzare la crittografia a livello di colonna in SQL Server 2005 e versioni successive, è disponibile un certo numero di codice di esempio su come utilizzare le funzionalità di crittografia incorporate in SQL Server per proteggere i dati riservati. Il codice è tutto disponibile su link

Nel codice mostra come crittografare i dati sensibili e garantire che solo gli utenti autorizzati possano decrittografarli. Approfitto delle funzionalità di gestione delle chiavi incorporate e ho una strong chiave simmetrica AES generata casualmente gestita dal motore del database e quelle chiavi AES sono quindi protette con certificati. I ruoli del database controllano chi ha accesso a quali chiavi e con la crittografia incorporata di SQL Server è possibile utilizzare anche passphrase per proteggere ulteriormente chiavi o certificati in modo che non ci si debba nemmeno fidare del proprio DBA se i dati sono altamente sensibili. Detto questo, se non ti fidi del tuo DBA allora hai altri problemi :)

Poiché SQL Server fa le cose giuste con la crittografia (garantendo IV esclusivi) non è possibile cercare le colonne crittografate senza eseguire una scansione della tabella e decodificare ogni riga per vedere se c'è una corrispondenza. Fornisco un codice di esempio per la creazione di un HMAC di dati crittografati in modo da poter eseguire almeno una ricerca di base senza perdite di informazioni in chiaro.

Ho anche esempi su come memorizzare hash salati e allungati di password usando sia gli algoritmi di hash incorporati (che sono insufficienti per l'uso di produzione) sia un'implementazione SQLCLR dell'algoritmo di hash bCrypt per una memorizzazione delle password molto migliore.

C'è anche un codice di esempio per mostrare l'uso della crittografia trasparente dei dati per crittografare l'intero contenuto dei dati e registrare i file sul disco.

Alcuni dei vantaggi dell'utilizzo della crittografia incorporata sono:

• Ottima gestione delle chiavi, il server fa la cosa giusta quando genera chiavi di crittografia e utilizza più livelli di crittografia per proteggere le chiavi
• Correggere la crittografia il server assicura che ogni pezzo di dati sia crittografato con un nonce IV ogni volta che viene scritto, il che significa che qualcuno non può guardare due valori cifrati e determinare che sono identici valori di testo libero.
• Verifica dell'integrità opzionale delle colonne crittografate per garantire che qualcuno non possa semplicemente sovrascrivere un valore crittografato con un altro valore crittografato
• Portabilità, puoi accedere ai tuoi dati da più piattaforme senza dover affrontare grattacapi di differenze nelle implementazioni della piattaforma che funzionano in modo diverso.
• Dati buoni per la sicurezza del riposo, la crittografia viene eseguita prima che qualsiasi registro o pagine di dati vengano scritte su disco, quindi tutti i dati registrati non contengono testo in chiaro.
• Possibilità di seguire facilmente il principio del privilegio minimo e solo concedere l'accesso alle chiavi di crittografia ai ruoli e / o agli utenti che li richiedono.

• Modifica: per informazioni specifiche su Microsoft SQL Server , leggi @ commento di Joe sotto . Inoltre,

• Mi aspetto che mentre la funzione che descrivi codifica i binlogs (o simili, come nel caso di un'intrusione al filesystem), probabilmente non sarebbe di aiuto se qualcuno avesse ottenuto l'accesso ai dati usando SQL injection, a causa della natura automatica della decrittazione. Penso che dovresti inserire le informazioni sensibili in un utente SQL separato (e limitare dall'utente principale), in alternativa puoi aggiungere un ulteriore livello di crittografia / hashing.

• Per non parlare del doppio controllo della prevenzione dell'iniezione SQL.

Come accennato, i database crittografati sono computazionalmente più costosi, per non parlare dello sforzo di programmazione.

Alcuni suggerimenti

• Come già accennato, crittografa le informazioni sensibili come le password (che potrebbero essere utilizzate per ottenere informazioni più sensibili su altri account), o numeri di carte di credito, SSN (ovviamente). Se non hai bisogno di decifrare (ad esempio, per confrontare una sola password crittografata con quella su file, non è necessario decrittografarla) utilizzare una funzione di hash.

• Per l'injection SQL riduzione del rischio, guarda boxing l'accesso utente SQL . Le parti di autenticazione del tuo sistema possono essere separate dal resto del sistema. Può trattarsi di una quantità di codice molto inferiore, che viene esaminata più attentamente e modificata meno frequentemente.

• Se crittografate i dati utilizzando una routine strong e consigliata, come AES, e una chiave casuale a lunghezza intera (non solo una semplice passphrase), quindi i dati diventa inutile senza la chiave , ad eccezione delle basi come puoi rilevare i duplicati, puoi contare le righe, vedere come si relaziona alle informazioni non crittografate, ecc.

• L'intruso potrebbe avere accesso a più del database . Se l'intruso ottiene l'accesso al tuo database e alla chiave (ad esempio, se è codificato nel tuo programma), allora è praticamente non efficace. Se vuoi, puoi considerare un modello complesso che impedisce la memorizzazione della chiave in chiaro . Questo è ovviamente molto impegnativo se si sta installando un sistema esistente.

• Non utilizzare le funzioni di crittografia integrata SQL . Si verificherebbe un problema simile se un intruso accede al database e ai binlogs . (Log di istruzioni SQL, ad esempio in MySQL) Le routine SQL incorporate sono valutate dopo l'istruzione, con i parametri in chiaro copiati nei binlogs. È necessario attenersi alla crittografia in-programma per evitare che questa perdita della versione normale, che trova la sua strada nei registri delle istruzioni (bin-logs, log lenti), possa anche fuoriuscire nella lista dei processi.

Ma davvero

• Dovresti assicurarti che non ci sia prima l'iniezione SQL.

E altre vulnerabilità più evidenti. Indurire il tuo guscio esterno sembra un investimento più economico.

• Patching i tuoi servizi web-facing,
• disabilitazione porte di accesso non utilizzate,
• include anche una lista di accesso è una buona idea per impedire indirizzi IP non attendibili o utenti non VPN di sfruttare vulnerabilità (senza contare che può ridurre carico che aiuta contro gli attacchi Denial of Service)

La crittografia è una successiva linea di difesa potenzialmente valida.
Ma anche il modello complesso a cui ho fatto riferimento è strong quanto il link più debole .

• Molte persone usano davvero solo una parola singola per la loro password ,

e potresti scoprire che ti manca qualcosa, come

• non usando una routine hash abbastanza lenta, o
• non anticipando che l'intruso potrebbe affittare un gruppo di cracking per un breve periodo.

Ma dovresti comunque fare il massimo sforzo.

Idealmente , i tuoi computer darebbero solo ciò che è permesso e la crittografia dello storage sarebbe inutile. Questo è raramente il caso.

Nota che questa risposta si concentra solo sull'hacking diretto e non sull'accesso fisico o sull'accesso attraverso uno dei PC del tuo sysadmin.

Spesso la crittografia non è il problema. Nella maggior parte dei casi la crittografia dell'intero database è quasi certamente una perdita di tempo.

Ci sono spesso valori molto importanti che dovrebbero essere criptati. Un valore che viene spesso trascurato è l'ID di sessione, i token csrf, la password salt e il token password dimenticata . Se sei abbastanza sciocco da archiviare il tuo ID di sessione nel database, un hacker con un difetto di SQL Injection può estrarre questo valore e accedere senza dover craccare un hash della password.

Come già detto da altri utenti, la crittografia dell'intero database è probabilmente eccessiva, il che significa che si perderebbero troppe prestazioni e si otterrebbe poca sicurezza in più, dal momento che si crittograferebbero i campi che non è necessario crittografare.

Pensaci in questo modo: immagina che un utente malintenzionato sia riuscito ad accedere a tutti i dati nel tuo database grazie a un'iniezione SQL. Quale informazione dovrebbe assolutamente non vedere l'attaccante e quali informazioni invece non sono così importanti, il che significa che anche se fosse in grado di leggerlo, non potrebbe fare nulla con esso? Un esempio del primo tipo sono le password degli utenti e uno dei molti esempi del secondo tipo potrebbe essere il colore preferito dell'utente, se per qualche motivo è necessario memorizzare queste informazioni nel database: D

Quindi, la crittografia dell'intero database non vale il tempo e la perdita di prestazioni, ma ci sono alcuni campi che devono assolutamente essere crittografati (password, numeri di carta di credito, SSN, ID di sessione e potresti anche aggiungere informazioni personali dell'utente a questo elenco, come i numeri di telefono ecc., gli utenti sarebbero grati per questo :)).

Non dimenticare che se l'utente malintenzionato ha accesso al tuo database, potrebbe finalmente accedere a tutte le informazioni in esso contenute anche se alcuni campi sono stati crittografati, ha solo bisogno di più tempo per farlo. E se hai informazioni molto importanti nel tuo database, questo tempo extra è estremamente importante.

E infine un suggerimento: investire tempo nella prevenzione degli attacchi SQL injection. Questa è probabilmente la tecnica più utilizzata con cui un utente malintenzionato può accedere illegittimamente al tuo database.

Dipende. Ricorda che gli hacker punteranno sempre al collegamento di sicurezza più debole del tuo sistema. Pensi che i dati del database non crittografati siano il link più debole del tuo sistema? Sembra un po 'improbabile. Sebbene fornirà sicuramente una protezione aggiuntiva, il tuo tempo sarà probabilmente meglio speso per proteggere altre parti del tuo sistema, che sono più probabilmente il link più debole per la sicurezza.

Inoltre, tieni presente che la crittografia di un DB è generalmente piuttosto costosa, a livello computazionale. Se il tuo DB serve molti dati a molti client, questo potrebbe rallentare il tuo sistema.