Re: R: [ml] Criptare dati sensibili

2009/6/30 Marco Ermini <marco.ermini@xxxxxxxxx>
>
> Secondo me dipende moltissimo da quello che si deve fare e dal perchÃ,
> ma in linea di massima, ci andrei piano con la criptazione lato DB.
> L'esperienza pratica insegna che pone pià problemi di quanti ne
> risolve.

Alle volte sÃ, alle volte no. Quello che interessa sapere, sopratutto,
quale à il requisito riguardo allla criptazione dei dati e da cosa
proteggerli. Se lo scopo à quello di non perdere il controllo dei dati
presenti nel DB (per esempio nella sostituzione di un disco guasto, al
furto dei dischi o nella copia dell'intero DB in altra copia) allora,
la criptazione lato DB à utile. Mentre, se à richiesta una separazione
di compiti tra i DBAs (che hanno full-access sul DB stesso) e i dati
in esso contenuto, allora la criptazione lato DB non à del tutto
sufficente (anche facendo una coerente profilatura degli account). Si
possono comunque abbinare le due soluzioni.

Un'altra possibilità à quella di criptare le informazioni a livello di
colonna utilizzando le primitive Oracle (non conoscendo SQL
Server)come DBMS_CRYPTO, questo pero sottointende di riscrivere le
applicazioni che accedono al DB e/o alle tabelle, rivedendo la
struttura della base dati (esempio gli indici).

Un ulteriore sicurezza à quella di sviluppare by-hand l'algoritmo di
criptazione, ma in questo caso porre attenzione anche alle questioni
di performance della base dati.

Da non dimenticare che anche il colloquio tra il DB e i relativi
client che accedono ai dati devono essere criptati, per ovviare al
network-sniffing.

Cesare
--

Clifford Stoll Â- "The Internet is a telephone system that's gotten uppity."