Newsgroup: it.comp.appl.access
Titolo: A proposito di cifratura [2]

 
Seguendo il consiglio di Roberto dalla campagna, prima di pubblicare 
l'esempio sul sitocomune, propongo qui il testo della descrizione che 
accompagnerà l'esempio.
Visto che è di interesse comune ognuno (come suggerisce Roberto) può 
aggiungere le sue personali considerazioni che verranno aggiunte alla 
descrizione.
A Roberto ho già inviato il .doc.
Questo il testo:
Criptare-Decriptare i dati sensibili.
Di Carlo Costarella
Chi è obbligato ad usare Access per i suoi applicativi, si trova spesso a 
dover fronteggiare problemi di sicurezza. Com'è noto, una delle critiche 
maggiori mosse ad Access, è proprio la sua mediocre possibilità di criptare 
i dati riservati e di permettere, quasi a chiunque, di leggere una sua 
tabella. Molto si è fatto con la protezione a livello utente e molti 
contributi in questo SitoComune e in vari NG hanno non poco migliorato le 
funzioni di protezione. Poco o nulla si è fatto per la cifratura dei dati; 
in pratica resta solo la possibilità di usare la funzione standard di 
"Cifra-Decifra DataBase".
L'esempio qui presentato utilizza una procedura di criptazione dei dati che, 
una volta eseguita, resta stabile e solo chi possiede la chiave di 
decodifica è in grado di leggere in chiaro.
Il modulo annesso all'esempio sfrutta una funzione messa a punto da Dima 
Mnushkin che utilizza una PASSWORD_KEY a numero di caratteri variabile (nell'esempio 
sono 24) per cifrare i dati passati. Nello stesso modulo sono presenti due 
Sub che s'incaricano di criptare e decriptare la "descrizione" di un'ipotetica 
tabella Comuni. Alla tabella è stato aggiunto un campo chiamato  "Criptato" 
di tipo booleano (Sì/No) che è molto importante affinché si possa evitare di 
sovrascrivere, criptandoli, dati già criptati. Questo campo deve essere 
incluso o aggiunto anche al nuovo applicativo dove si userà la funzione.
Da prove fatte e con questa PASSWORD_KEY = "QuEStA ChIaVe12345PassAT", i 
tempi di attesa per circa 10.000 record, sono trascurabili e praticamente 
inavvertibili. Ritengo che con 100.000 record e con due campi da 
cifrare-decifrare, si arrivi ad un'attesa di un paio di secondi con sistemi 
di penultima generazione (Pentium III). Ancora accettabile.
Se i campi da criptare dovessero essere più di tre credo, si debba restare 
sui 100.000 record specie se si fa un uso intensivo di combo che prelevano 
contemporaneamente i valori dai campi crittati: in questo caso, infatti, la 
stessa funzione "Encrypt" viene usata nella query che alimenta la combo e i 
dati vengono decifrati "al volo" o all'apertura della maschera.
Nessun problema per i report: i dati da stampare possono essere decriptati 
"al bisogno" e solo nei controlli del report, senza mai toccare i valori 
originali.
Un problema a parte è la scrittura di nuovi dati o la modifica degli 
esistenti.
Per la modifica dei dati esistenti, l'esempio propone una maschera "Comuni 
dati Modificabili" che, vicino la descrizione del comune, ha un pulsantino 
con tre puntini. Premendo il pulsante si apre una seconda maschera che 
riporta in chiaro il dato da modificare. Terminata la modifica, un pulsante 
"Modifica" s'incarica di criptare il nuovo dato e collocarlo al posto 
giusto. Questo approccio alla modifica può anche essere sostituito da un'inputbox.
Per la scrittura dei nuovi dati penso si debba ricorrere ad una maschera non 
associata e solo al termine della scrittura trasferire i dati alla tabella 
provvedendo alla cifratura dei soli dati sensibili.
Prima di usare le funzioni riportate nell'esempio, si raccomanda di fare 
copia del database originale.
Se l'applicativo che si andrà a creare prevede la criptazione di dati 
sanitari o in ogni modo sensibili (l'uso principale per cui è stato 
realizzato l'esempio), si raccomanda di leggere bene le attuali disposizione 
di legge in materia di privacy. Questo un buon link di partenza:
http://www.garanteprivacy.it/garante/navig/jsp/index.jsp
Non mi assumo responsabilità per eventuali danni creati dall'applicativo, 
quindi prima di usare le funzioni proposte, sui database "seri", cercate di 
testare a fondo tutti i vari aspetti di questo esempio.
Questo il link per scaricare l'esempio:
http://www.frantoiogestione.com/Cripto.zip

Carlo Costarella wrote:
[Cut]
Per me va bene
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it


[CUT]
Anche per me va bene così: sicuramente così si dà una soluzione al problema
buona e documentata.
Si potrebbe, salvo controindicazioni che verranno segnalate in questo
thread, pubblicare questo come commento della FAQ a cui allegare il demo di
Carlo.
Se in seguito poi usciranno altre soluzioni più o meno valide di questa
pubblicheremo anche quelle sul Sito Comune, si vedrà, se possibile,
stabilire i pro ed i contro di ognuna, quindi lo sviluppatore userà quella
che preferisce.
Non saebbe la prima volta che sul Sito comune verrebero pubblicate soluzioni
diverse per lo stesso argomento.
-- 
Roberto
-----------------------------------------------------
il Sito Comune di it.comp.appl.access
http://www.sitocomune.com
----------------------------------------------------

 accompagnerą l'esempio.
Per me č Ok