In merito a questo mio articolo sulla cifratura dei dati in SQL Server 2005, ho ricevuto una mail in cui un lettore mi chiede "...nel caso si debbano criptare dei campi superiori agli 8000 caratteri, la funzione di cifratura dice che i dati saranno troncati. Ha già incontrato questa necessità trovandone la soluzione?"
In primo luogo il limite è leggermente inferiore dal momento che gli 8000 byte che il Books On Line riferisce come limite devono riferirsi non al campo da cifrare ma al risultato cifrato. Ne consegue che in funzione dell'algoritmo scelto per la cifratura dei dati varia la lunghezza massima del campo da cifrare e agli 8000 byte ne vanno in realtà sottratti un centinaio.
Campi di dimensioni superiori non sono pertanto cifrabili con le funzionalità native di SQL Server 2005 e per trovare un workaround è indispensabile fare un passo indietro chiedendosi le ragioni per le quali si ha necessità di cifrare dati del genere. In passato mi è stato presentato un quesito analogo e la ragione di ciò derivava da una scarsa (o sarebbe meglio dire inesistente) politica di controllo degli accessi e si voleva, con la cifratura dei dati, ovviare a questa grave lacuna.
Per il mio punto di vista, sicuramente condiviso da chi ha deciso di implementare l'infrastruttura PKI in SQL Server 2005, la cifratura dei dati non è una alternativa alla protezione dei dati per mezzo di permessi sugli oggetti ma deve rappresentare una ulteriore protezione limitata a quei dati più sensibili per cui le business rules (e/o disposizioni di legge) impongono un occhio di riguardo. Mi riferisco ai dati di una carta di credito, coordinate bancarie, dati sanitari, credenziali di accesso ad una applicazione, ecc.
Tutti gli altri casi possono essere risolti semplicemente negando i permessi su di una tabella e far utilizzare agli utenti e alle applicazioni solo viste, stored procedure e user defined functions.
Ogni altra esigenza particolare che suggerisce la cifratura dei dati (fermo restando che ciò non deve essere un palliativo di quanto indicato in precedenza) deve essere risolta lato applicazione o utilizzando soluzioni DRM.
Colgo l'occasione per segnalare il blog di Laurentiu Cristofor che si rivela sempre una fonte inesauribile di documentazione sulla cifratura dei dati ed in particolare questo post di pochi giorni fa il cui titolo, molto esplicativo, è "Who needs encriptions?"
Bye
Gianni, innanzitutto grazie per il feedback.
Per rispondere alle tue perplessità, ti faccio innanzitutto presente che "cifrare tutti i campi" non la vedo una soluzione percorribile; non da un punto di vista tecnico ma da un punto di vista pratico. Fin qui ci troviamo, mi sembra, daccordo.
Sarai senz'altro daccordo con me anche sul fatto che la soluzione primaria deve essere quella di proteggere i dati definendo opportunamente i privilegi di accesso agli stessi; definendo opportunamente i permessi di accesso alle risorse sei già in grado di ottenere il risultato voluto (solo chi è autorizzato leggerà il referto, altri potranno leggere solo altri dati e altri ancora il minimo indispensabile).
Quello che puoi pensare di cifrare è, a titolo di esempio, il riferimento al paziente (il codice fiscale o altro identificativo) rendendo quindi impossibile ricondurre il referto alla persona fisica (e credo che già in questo modo soddisfi ampiamente i requisiti richiesti dalla normativa vigente).
Quanto alle preoccupazioni che "qualunque smanettone potesse venire in possesso dei file che compongono il db" questa è una preoccupazione legittima ma che evidenzia un buco di sicurezza posto altrove, ovvero alla facilità di accesso al file system della macchina. Se uno "smanettone" è in grado di fermare un servizio e copiare dei file da un server mi preoccuperei non poco di come è stata configurata la macchina e non mi sforzerei in nessun modo di proteggere "i piani alti", ovvero i dati, in quanto sono le fondamenta ad essere compromesse
Questo tipo di problemi non lo risolvi cifrando i dati a livello di SQL Server ma cifrando i file che compongono il database con le funzionalità offerte dal sistema operativo (EFS). Analoga attenzione, ovviamente, devi prestarla per i supporti di backup.
La sicurezza è un aspetto da va considerato a 360°. In questo post abbiamo parlato della protezione dei dati, abbiamo accennato alla protezione del file system, dovremmo ancora estendere il discorso all'hardening del sistema operativo (per ridurre della superficie di attacco), alla definizione dei privilegi di accesso alla macchina (a livello di so) e alla sicurezza fisica e perimetrale. Cifrare i dati senza preoccuparsi di tutti gli altri aspetti equivale a dotarsi di una porta blindata di ultima generazione ma non preoccuparsi delle finestre.
La sicurezza va vista come una catena dove è sempre l'anello più debole quello che si appresta a cedere e ad essere attaccato.
Abbiamo già trasformato questo blog in un thread di un forum e per questo motivo preferisco chiudere qui la mia risposta al tuo commento invitandoti, se vuoi, a postare nel forum di questo sito ogni quesito che ritieni opportuno.
Bye
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Stampa 
Download 
Premesso che sono la persona che aveva posto il quesito iniziale, ti ringrazio per la risposta, anche se la condivido parzialmente.
Mi scuso anche per eventuali inesattezze in quanto mi ritengo, almeno nell'ambiente sql server 2005, uno alle prime armi.
E' vero che proceduralmente si può ovviare al problema di cifratura di tutti i campi, anche nel mio caso ciò è ovviamente possibile ma data la natura dell'applicazione per rendere ciò possibile bisogna creare qualche complicazione operativa per gli utenti.
In sintesi: il campo da cifrare è un testo rtf contenente il referto di un medico, tenendo non uniti i dati sanitari dai dati anagrafici si limiterebbe, nella semplicità, la compilazione del referto stesso creando pure, anche se minima, una possibilità di errore(qui si potrebbe aprire una interminabile discussione sull'applicazione della legge sulla privacy).
Si può ovviamente proteggere le cartelle contenenti il DB, ma se malauguratamente il file del DB dovesse cadere nelle mani di un qualsiasi smanettone, una semplice visualizzazione del file fisico renderebbe visibile in chiaro, o quasi, i testi rtf contenuti nel db con una inequivocabile vicinanza dei dati anagrafici ai dati sanitari.
Un sincero ringraziamento per l'articolo da te pubblicato per le modalità di cifratura, estremamente chiaro e di semplice comprensione.
saluti
Gianni
Continua »»» | Rispondi »»»