Auditing dei database: categorie di dati da monitorare

Il processo di auditing di un database può facilmente produrre enormi quantità di dati: si può infatti sottoporre a controllo qualsiasi operazione o evento sui dati e sulle strutture interne. Tuttavia, appare ovvio come non sia conveniente controllare tutto, sia per le inevitabili problematiche prestazionali (risorse di calcolo e spazio disco), sia per l'utilità delle informazioni che si possono estrapolare dai dati raccolti.

L'approccio corretto consiste nel decidere in prima istanza quali sono gli aspetti che si vuole monitorare, basandosi sulle specifiche imposte dalla regolamentazione esterna (leggi, standard di conformità ecc.) e dalla politica di sicurezza aziendale. Le possibilità sono molte, ma mi limiterò a elencare quelle fondamentali.

I login al database si sottopongo praticamente sempre ad auditing. Occorre registrare le connessioni e le disconnessioni, complete di orario, indirizzo IP di provenienza e nome dell'eventuale applicazione usata. Una categoria particolare è rappresentata dai login falliti, che possono essere dovuti a una password digitata male o a un tentativo di accesso non autorizzato. I dati dei login riusciti e falliti possono essere tenuti insieme per praticità, ma vanno sempre presentati separatamente nei rapporti per evidenziare i tentativi di intrusione e possibili trend sospetti. Le informazioni sui login possono inoltre essere usate per una baseline (un elenco di riferimento): qualsiasi variazione, come un utente che si connette regolarmente ma da un indirizzo IP insolito, o ad un orario imprevisto, risulterebbe sospetto e richiederebbe un controllo ulteriore.

È buona norma bloccare uno username dopo un certo numero di login falliti consecutivi. Per farlo si può ricorrere a una stored procedure che allerti in tempo reale il DBA; oppure si può gestire l'evento dall'esterno, tipicamente con un SQL firewall (in questo caso il database non riceverebbe neanche i tentativi di login).

È importante fare l'auditing dei login che avvengono fuori dal normale orario di lavoro. In questi casi è utile monitorare tutte le operazioni compiute dall'utente sospetto. Bisogna però fare attenzione a non monitorare le operazioni programmate (come i backup notturni) per evitare alti livelli di "rumore". Anche in questo caso tornerà utile l'uso di una baseline per individuare quali operazioni siano da escludere dal processo di auditing.

Oltre ai tentativi di login, una delle attività di auditing più importanti consiste nel controllare i comandi DDL che modificano lo schema del database. Tale misura garantisce l'aderenza alle norme, ma soprattutto rinforza la sicurezza del sistema: i comandi DDL sono potenzialmente molto pericolosi, perché possono compromettere il funzionamento del database. Possono essere impartiti non intenzionalmente per effetto di un'operazione maldestra di un amministratore o di uno sviluppatore di applicazioni; ma possono anche essere dovuti a un aggressore che intende creare tabelle d'appoggio su cui copiare i dati, da cui li estrarrà in un secondo tempo per evitare l'auditing attivo sulle tabelle più protette.

Essenziale poi è fare l'auditing di tutte le modifiche apportate allo schema di protezione e dei privilegi del database: aggiunta e eliminazione di utenti, mappattura tra i login e i ruoli, modifiche ai privilegi assegnati e alle password associate agli username. Vista la pericolosità di queste operazioni se effettuate da un aggressore, è sempre opportuno prevedere degli avvisi in tempo reale per intervenire tempestivamente.

Un'altra categoria che è spesso sottoposta ad auditing è quella degli errori restituiti dal database, che possono essere causati da un tentativo di SQL injection (di cui ho parlato qualche tempo fa). L'auditing degli errori è utile anche per supportare la qualità delle applicazioni che si interfacciano al database, perché si individuano più facilmente gli errori di programmazione e i bug di funzionamento derivanti dall'integrazione tra software diversi. È da notare che è abbastanza comune avere piccoli errori anche in ambienti di produzione. Questi errori si manifestano sempre alle stesse condizioni, in modalità sempre uguali: l'uso di una baseline permetterà di individuare prontamente gli errori che se ne discostano, sui quali sarà opportuno investigare.

Uno degli attacchi più sofisticati rivolti ai database (di cui ho intenzione di parlare in futuro) è basato sull'uso dei cosiddetti DB trojan, che attaccano direttamente i trigger e le stored procedure. Se il database che si gestisce può essere soggetto a questo tipo di rischi, sarà dunque opportuno attivare l'auditing sui tentativi di creazione e modifica di questi elementi del database.

Alcuni dei dati conservati in un database sono più sensibili di altri alle modifiche non autorizzate. In ambito lavorativo, una tabella dei dipendenti potrebbe avere tra i suoi attributi il livello retributivo, il numero di giorni di ferie disponibili ecc. (oppure, pensiamo alla recente polemica sulla pubblicazione on-line delle nostre dichiarazioni dei redditi del 2005). Tutte le modifiche apportate a questi attributi possono essere oggetto di auditing se esiste il rischio di accessi e modifiche non autorizzate. In questi casi è opportuno registrare anche il vecchio e il nuovo valore inseriti per ripristinare le condizioni antecedenti (Oracle mette a disposizione per questa operazione LogMiner, di cui ho già parlato in un post sull'analisi forense su Oracle). Va però tenuto presente che questa categoria di auditing può occupare molto spazio per l'archiviazione, per cui occorre valutare attentamente quali oggetti del database e quali comandi DML monitorare.

In tema di dati sensibili, si possono sottoporre ad auditing anche i comandi SELECT quando occorre vigilare sulla riservatezza dei dati, specie per rispondere alle regole imposte dalle norme di legge. Poiché anche in questo caso si genera una grande mole di dati, è conveniente farlo solo sugli elementi che rappresentano dati strettamente confidenziali.

Per concludere, in alcune circostanze può essere necessario monitorare anche le modifiche apportate ai settaggi dei parametri dell'auditing, per evitare che un aggressore ne manipoli l'esecuzione in corso sul sistema, o ne modifichi i dati raccolti. Paranoia? Non credo, i casi reali non mancano...

La prossima volta vedremo le tre principali architetture di auditing sui database. A presto!