Newsgroup: it.comp.sicurezza.varie
Titolo: DPS cifratura e/o separazione dati sanitari

Ciao a tutti.
Mi occupo di software per aziende sanitarie e ho dei dubbi sul discorso
della cifratura.
mi pare di aver capito che la cifratura è richiesta in
legge 196/2003 - articolo 22 -comma 6 
che riporto:
...
6. I dati sensibili e giudiziari contenuti in elenchi, registri o banche di
dati, tenuti con l'ausilio di strumenti elettronici, sono trattati con
tecniche di cifratura o mediante l'utilizzazione di codici identificativi o
di altre soluzioni che, considerato il numero e la natura dei dati
trattati, li rendono temporaneamente inintelligibili anche a chi è
autorizzato ad accedervi e permettono di identificare gli interessati solo
in caso di necessità.
faccio l'esempio di una applicazione che gestisce referti, se accedo
all'applicazione è sempre per vedere dati sensibili quindi è difficile
applicare il principio della separazione
ne ho sentito una interpretazione per cui questa separazione è da intendere
a livello di tabelle di database
per esempio:
se ho una applicazione che gestisce referti medici la tabella contentente
il referto non deve contenere nome e cognome
nome e cognome saranno su un altra tabella che ovviamente deve avere un
legame logico con un campo codice (la join insomma) 
secondo l'interpretazione più restrittiva questo codice che fa la join non
può essere il codice fiscale o il numero di tessera sanitaria perchè
potrebbero permettere di risalire all'identità
è una interpretazione che non mi convince per niente in quanto incentrata
sull'ipotesi che qualcuno acceda direttamente al db e poi "rubi" una
singola tabella, mi chiedo cosa impedisce a questo ipotetico hacker di
vedere tutto il db e farsi le join
un'altra lettura possibile è quella di rivedere le applicazioni in modo che
nelle stampe e nelle maschere nome e cognome non compaiano automaticamente
in chiaro ma siano accessibili solo volontariamente
per esempio: potrei scrivere un referto con riferimento a un numero di
prenotazione senza che mi venga mai mostrato il nome e cognome del paziente 
nome e cognome che potrebbero essere visualizzati solo al momento della
consegna del referto
altro aspetto:
se il mio referto è memorizzato in un db il cui accesso è comunque protetto
da password la situazione è ben diversa dal caso in cui il mio referto è un
file word su un hd, devo cifrare i dati anche sul database o è eccessivo?
cosa ne pensate?
ci sono state delle circolari esplicative su questi aspetti specifici?
grazie
-- 
Talkingh (ex Beppe)
37,130,NO
accelero con una L sola

in caso di necessità.
Io mi concentrerei sul quel "temporaneamente inintelligibili", si
potrebbe intendere che un non avente diritto non possa leggerli se per
caso può accede ai dati.
Un parallelo è quello sui documenti cartacei dove il garante consiglia
di mettere nelle cartelle solo i dati che possano interessare per
l'uso normale, separando quelle sensibili in modo che vi acceda in
caso di neccessità solo l'avente diritto.
In un software medico questo potrebbe dire che divido il database e
alcune informazioni non le faccio vedere in join ma facendo una
chiamata autenticata ad un web service separato. Nulla di impossibile.
Se le informazioni le stampo, vale la regola dei documenti sensibili
su carta, distruzione delle copie dopo l'uso, consegna e custodia dei
documenti. Se non mi conviene metto il codice e non l'identificativo
intelligibile.
Anche la crittografia, crittografia parziale, hash, trasposizione
numerica, inserimento di semi, analisi anti attacchi deduttivi...,
permettono di fare applicazioni anche a crittografia pervasiva, non è
impossibile, ho depositato un brevetto su un modello specifico :-) ma
questa è un altra storia.
La cosa che non si è evidenziata abbastanza è la possibilità di
aumento di errori con l'uso di codici, non siamo in America dove il
codice sanitario è segreto (finché non lo rubano) e assegnato
unicamente alla persona che lo conosce. In caso di uso di codici mi
aspetterei anche l'uso di braccialetti identificativi tipo quelli
delle maternità, ma non ne sento molto parlare.
Un altra chicca medica, la legge da una forte importanza ai dati
genetici, peccato che alcune malattie siano "familiari" e alcuni
indicatori evidenzino peculiarità genetiche, e quindi il dato
sensibile sulle malattie diventa in alcuni casi genetico, basta
disporre di abbastanza dati.
Andrea
www.infocare.it

 
se l'applicazione la devi realizzare oggi no, ma se esiste già non è banale
e del fatto di avere 2 tabelle separate nello stesso db (dati medici in
una, nome e cognome nell'altra) cosa dici? ti sembra sensato?


una, nome e cognome nell'altra) cosa dici? ti sembra sensato?
L'ho sentita anch'io come soluzione, ma mi sembra troppo banale per
essere considerata separazione che poi è citata nell'allegato tecnico
e mi sembra più legata al fatto di rappresentare dati parziali e
specifici solo se necessario (es il laboratorio di analisi non ha
bisogno di sapere il nome del paziente).
E se la chiave di relazione fosse codificata? provo a buttarla lì, non
l'ho verificata in pratica, con una tabella temporanea generata e
legata alla connessione? oppure con una chiave codificata
nell'applicativo?
L'art 22 punto 6 dice della cifratura o utilizzo di codici, l'allegato
tecnico parla di acesso disgiunto... in realtà se io sò il codice
interno usato per un paziente e accedo alla banca dati dei referti
riesco a trovare tutto. Basta che il codice sia messo sul letto o su
altri posti pubblici e il gioco è fatto. Senza una corretta analisi
della sicurezza mi sembra che il tutto si presti a essere una cosa
puramente formale.
Ci sono anche gli attacchi deduttivi, se ho solo i referti ma c'è
l'età del paziente, sesso ...  posso lo stesso risalire... perché
basta che io sappia il periodo.
ciao,
Andrea Benoni
www.infocare.it

 puramente formale.
quoto
penso che sfruttero i sei mesi per discutere con il cliente un intervento
sensato
