2009/6/26 Andrea Adami: [...] > Il mio consiglio è lavorare lato DB. [...]
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. Non so come funzioni in SQL Server, ma in Oracle dalla versione 10g in avanti, la criptazione è trasparente, non è segnalata in alcun modo a meno che non si richieda lo status del DB esplicitamente, e cripta tutti i backup. Questo significa che un "disgruntled DBA" può iniziare la criptazione di un intero DB senza che nessuno se ne accorga (a meno che il DB non venga restartato, ma capita normalmente in Oracle che non venga restartato per mesi e mesi... in Windows immagino un po' meno, dato che devi installare quanto minimo le patch settimanali dell'OS ;-)), e dopo dei mesi - dopo che tutti i backup, completi ed incrementali, di mesi e mesi sono criptati e recuperabili soltanto da questo DBA... - lasciare l'azienda non dopo aver fatto lo shutdown del DB... e chiedere un bel riscatto :-) È molto piu facile e sicuro criptare il solo campo dell'unica tabella in cui il dato serve effettivamente criptato, e lasciar stare il DB come è :-) le funzioni di criptazione trasparente del DB dovrebbero essere lasciate a installazioni specifiche con richieste particolari ed essere trattate di conseguenza, con una procedura di change management messa in pratica per la gestione della criptazione del DB. Cordiali saluti -- Marco Ermini r...@human # mount -t life -o ro /dev/dna /genetic/research http://www.linkedin.com/in/marcoermini "Jesus saves... but Buddha makes incremental back-ups!" ________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
