Il giorno 06 Luglio 2009 22.54, Cesare <[email protected]> ha scritto:
> 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). > Oracle dalla versione 11 permette di gestire le chiavi e la cifratura con un HSM e PKCS#11. Senza utilizzare Package PL/SQL e/o modificare il codice per aprire il password wallet e via dicendo. Ovviamente si deve comunque accedere all'HSM con un'autenticazione e richiedere la decifratura del dato da visualizzare lato client. > > 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. > Si ma oltre a questo andrebbe minimizzato il tempo in cui il dato ? visibile in chiaro nella parte client. Sparare a video una tabella con tutti i dati in chiaro annullerebbe tutta la sicurezza del sistema. Bisogna quindi gestire in modo opportuno il dato e quindi la sua visualizzazione/modifica sul client. Per esempio visualizzando di volta in volta solo il singolo dato (con eventuale modifica), una sessione di tempo ridotta e "zeroing" delle zone di memoria client. Certo se poi si dota l'utente di funzionalit? di stampa :-) Comunque la cifratura del dato attraverso un sistema nativo (ex: DBMS connesso ad HSM) con protezione del canale e sviluppo dell'applicazione client in modo opportuno pu? garantire (IMHO) un buon livello di sicurezza del sistema. Inoltre delegare a meccanismi nativi la cifratura permetterebbe di superare pi? agilmente eventuali Audit e/o certificazioni (di almeno una parte dell'infrastruttura). Diversamente con soluzioni home-made bisognerebbe far analizzare agli auditor l'intero codice, anche di cifratura. E l? la vedo pi? dura! Ciao Roberto > > Cesare > -- > > Clifford Stoll - "The Internet is a telephone system that's gotten > uppity." > > ________________________________________________________ > http://www.sikurezza.org - Italian Security Mailing List > >
________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
