1 messaggio dal 04 dicembre 2006
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

Gianni
1.024 messaggi dal 19 dicembre 2003
Contributi | Blog
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

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.