Come garantire la sicurezza del database

Lo dicono gli esperti, la protezione del database, specie dopo la recente violazione di LinkedIn, non può più essere sottovalutata. Ecco alcuni consigli su come procedere per garantirla.

Le best practice di gestione delle password sono tipicamente rivolte all'utente finale, ma le imprese svolgono un ruolo importante nella protezione dei dati degli account utente e queste policy comprendono alcuni fondamenti di sicurezza relativi al lockdown delle password di database e indirizzi di posta elettronica. Secondo Josh Shaul, CTO di Application Security, “l'approccio giusto è aggiungere protezioni affidabili al database per assicurare, in primo luogo, che i visitatori indesiderati non riescano ad accedervi. Nessuno dovrebbe essere in grado di mettere le mani sui dati delle password. Tali informazioni dovrebbero essere trattate e protette allo stesso modo di quanto avviene per la tutela della proprietà intellettuale più preziosa di un'organizzazione”.

La necessità di affrontare la sicurezza dei database è risultata evidente con la recente violazione delle password di LinkedIn. La società sta studiando come è stato possibile che 6,5 milioni di password dei suoi utenti siano trapelate e siano state pubblicate sul forum di un hacker russo. La portata della violazione era così enorme che gli altri operatori sono stati costretti ad affrontare la sicurezza delle password dei clienti, tra cui Facebook, Last.fm e eHarmony, perché gli utenti spesso utilizzano la stessa password per più account diversi, una pratica comune anche se piuttosto rischiosa.

Si parte dall’inventario

“Le imprese dovrebbero iniziare effettuando un inventario per determinare quali server contengono dati relativi alle password”, si dice convinto Johannes Ullrich, CTO del SANS Internet Storm Center. Molte imprese hanno diversi account database in produzione, visto che hanno stratificato diverse applicazioni nel corso degli anni. Alcune aziende scopriranno dozzine di applicazioni, ciascuna con la propria password memorizzata sul database, e alcune basi dati conterranno anche informazioni che vengono memorizzate in chiaro, cosa questa che rappresenta una delle principali debolezze dell’intero sistema di protezione aziendale.

“L'integrazione di un file system unico per tutte le applicazioni legacy è una sfida ardua - sostiene Ullrich -. Non è qualcosa che si fa dall'oggi al domani. È necessario assicurarsi che le impostazioni di protezione siano state attivate correttamente e che le funzioni inutilizzate vengano rimosse”. “La configurazione del database è qualcosa che viene dopo - gli fa eco Shaul -. I penetration tester sanno che nove volte su dieci riescono a penetrare un database protetto utilizzando la password di default o, comunque, una password debole”. La "Database Security Technical Implementation Guide" fornita dalla Defense Information Systems Agency americana rappresenta un buon punto di partenza per gli amministratori di database, che potranno rendersi conto di cosa significa creare una configurazione intrinsecamente sicura.

Il Center for Information Security è un'organizzazione non-profit che fornisce anche report aggiornati e benchmark di configurazione per i più comuni sistemi di gestione dei database.

Patchare il database

Le patch per il database rappresentano, spesso, il più grande punto di debolezza per un’organizzazione. I venditori rilasciano regolarmente patch, ma spesso le organizzazioni le ignorano o rimandano le attività di aggiornamento e patch per evitare di creare problemi o interruzioni sui sistemi in produzione. Le patch devono essere testate e distribuite e il mantenimento di un forte programma di patching che si rivolga ai database server più critici rappresenta, spesso, la differenza tra un'organizzazione nella quale si verifica una violazione e una organizzazione che, invece, non viene violata. “Occorre ricontrollare lo stato delle patch almeno una volta al mese e mettere in atto un processo di rapido aggiornamento e distribuzione delle patch”, suggerisce Shaul. Sempre secondo l’esperto, la finestra di ricontrollo delle patch dovrà ridursi a soli sette giorni nel caso in cui il database supporti un’applicazione dotata di interfaccia Web.

Limitare i privilegi

Una volta che il database risulta protetto da attacchi esterni, occorre occuparsi anche delle minacce interne. Limitare i privilegi a quelli necessari per permettere agli operatori interni di svolgere il proprio lavoro è non solo consigliato ma necessario.

Controllare ogni utente con accesso ai dati delle password e inibire l’accesso a quanti più utenti possibile è la strada giusta, si dice convinto Shaul. “Inoltre - aggiunge -, è necessario esaminare i privilegi di sistema e fare in modo che siano assegnati solo agli account dei database administrator ancora validi”.

Infine, occorre perfezionare l'attività di monitoraggio del database (DAM). Questa si concretizza in un’analisi complessa, utile per determinare chi accede al database e in che modo le informazioni che contiene vengono manipolate. “Una tecnologia DAM configurata correttamente - conclude - può essere utilizzata per fare in modo che siano previsti degli allert immediati che informino in tempo reale il database administrator quando il sistema rileva una incongruenza, dandogli la possibilità di isolare il problema prima che si trasformi in una grave violazione”.

Clicca qui maggiori informazioni

Fonte: http://searchsecurity.techtarget.it
30/06/2012