2009/6/30 Marco Ermini <[email protected]> > > 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."
________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
