Princìpi chiave e misure di sicurezza per la protezione del database. Quali sono i problemi principali?
Al pari di ogni altro componente software, anche il database (DB) deve essere protetto adeguatamente da errori e attacchi informatici, ma probabilmente arriva ultimo nella graduatoria degli sforzi che le aziende fanno per mettere in sicurezza il proprio sistema informativo. Ciò è dovuto al fatto che nella breve storia dell’informatica molti attacchi sono iniziati dalle violazioni del perimetro di rete e che il DB sembra un software sicuro e affidabile. Purtroppo per la security, il perimetro non esiste più e il DB è sicuro soltanto se usato bene.
CONTROLLO ACCESSI
Il controllo accessi, che si interroga su come vengono autenticati e autorizzati gli utenti, non dovrebbe riguardare solamente i dipendenti, i clienti e i fornitori dell’azienda che operano sui dati tramite le applicazioni, ma anche quegli “account” più tecnici che entrano nel DB. In questa area, gli errori più gravi sono di tre tipi: 1) l’uso delle potenti utenze tecniche non nominative da parte degli amministratori del DB; 2) privilegi eccessivi dati all’account usato dall’applicazione stessa; 3) l’uso di quest’ultimo da parte degli sviluppatori per svolgere i loro compiti di ricerca dei malfunzionamenti, modifica manuale dei dati e del software. Si violano così i princìpi di sicurezza relativi al privilegio minimo, all’accountability e alla separazione dei compiti di cui si fa un gran parlare.
MONITORING, AUDITING AND BLOCKING
In questa area rientrano le pratiche relative al controllo dell’SQL prima che sia eseguito e delle tracce che esso lascia nei log, una volta eseguito. Rispetto al primo tema, nonostante tutti i report internazionali documentino numerosi data breach tramite la tecnica della SQL injection, normalmente le aziende non si dotano di tool per il controllo preventivo a “run time” dell’SQL. Anche rispetto all’auditing e logging, la situazione è carente. Per motivi di superficialità, performance e occupazione di spazio disco, i log sono disattivati oppure, quando sono prodotti, non sono protetti, non sono conservati a lungo e non sono analizzati proattivamente in nessun modo. In pratica, si conservano per un po’ perché “non si sa mai”. Purtroppo, visto che gli incidenti vengono scoperti tardivamente, spesso sono già stati cancellati nel momento in cui servono – e inoltre – qualora fossero stati prodotti, sarebbero quasi inutili per via della scarsa accountability.
DATA PROTECTION
In questa area, si osservano due problemi. Il primo: le aziende non applicano alcuna cifratura al DB, allo storage che lo contiene, alla rete che trasporta i dati verso gli application server e neanche quando si produce un backup che viene spedito in un sito remoto. Il secondo: la consuetudine di copiare il DB di produzione nei sistemi di sviluppo e test per facilitare le attività di programmazione e test. Così facendo si espongono dati confidenziali (rispetto al business o alla compliance) a un ampio pubblico di addetti, che – in realtà – non avrebbe bisogno del dato reale ma al quale potrebbe bastare un dato realistico.
SECURE CONFIGURATION
In ambito server, le aziende utilizzano versioni obsolete di sistemi operativi e di DB, e tardano ad applicare le patch di sicurezza perché hanno delle oggettive difficoltà rispetto al fermo macchina e a effettuare i preventivi test di regressione. Inoltre – a volte – lasciano che siano gli sviluppatori a portare in produzione la nuova versione e configurazione del software, mancando così il criterio della separazione dei compiti. Infine, non ci sono controlli per verificare che la configurazione in esercizio non sia stata illecitamente alterata rispetto alla baseline approvata. Serve più che mai conoscere le buone pratiche di DB security e sforzarsi di rimuovere gradualmente gli errori più gravi. La strada è ancora lunga, ma è tutto sommato facile da percorrere. Se questo articolo vi ha sorpreso, fatevi aiutare da degli esperti, altrimenti iniziate a pianificare i rimedi.
Alessandro Vallega, membro del direttivo di Clusit e coordinatore della Oracle Community for Security
