Auditing dei database: architetture di implementazione

Tutti i principali DBMS sono dotati di funzionalità di auditing più o meno sofisticate, tutte comunque efficaci nello svolgere i loro compiti. Tuttavia, molti esperti di sicurezza informatica consigliano l'uso di sistemi esterni per separare le funzioni di controllo dalla normale gestione del database.

I vantaggi sono diversi: si aderisce meglio al modello della difesa in profondità, perché un sistema di auditing separato è più difficile da compromettere ed è meno soggetto alle vulnerabilità del database; si soddisfa il requisito della separazione dei compiti; l'utilizzo di prodotti esterni è alla portata di un utente privo di competenze avanzate, consentendo di sgravare il DBA dal lavoro di gestione dell'auditing. Infine, in ambienti ad alto livello di sicurezza è anche possibile usare un prodotto esterno in parallelo con le funzionalità interne del database, per confrontare costantemente i dati e verificare se uno dei due sistemi è stato compromesso.

Le architetture di implementazione dei sistemi di auditing sui database che si sono evolute nel tempo sono tre:

• ispezione delle strutture dati interne del database;
• ispezione delle comunicazioni col database;
• ispezione dei file generati dal database durante il normale funzionamento.
  

I database usano delle strutture dati interne per processare i comandi, gestirne i risultati ecc. In appoggio a queste strutture, il DBMS ne mantiene altre in memoria: un metodo per monitorare quello che succede nel database consiste proprio nell'ispezionare queste aree di memoria. Il sistema di auditing, condividendo lo stesso spazio di indirizzamento del database, interroga in polling le strutture in memoria, come in figura 1.

Figura 1 - Ispezione delle strutture dati interne del database

Nello stesso schema è indicato un metodo alternativo. In alcuni DBMS le strutture interne vengono astratte mediante tabelle e viste disponibili a un utente con privilegi da amministratore. È il caso di Oracle, che mediante le viste identificate dal prefisso v$ (come v$session per esempio) astrae le strutture rappresentate nelle tabelle interne identificate dal prefisso x$. Invece di interrogare direttamente le strutture interne, il sistema di auditing può connettersi al database mediante un account da amministratore e interrogare le viste di sistema.

Questa prima architettura di auditing, pur essendo basata su una struttura semplice, soffre di un problema di sincronizzazione: il polling di entrambi i metodi presentati deve essere eseguito con una frequenza sufficiente a rilevare i dati prima che siano sostituiti da quelli successivi; ma allo stesso tempo tale frequenza non deve essere eccessiva per non sovraccaricare le risorse del database.

Figura 2 - Ispezione delle comunicazioni locali e di rete col database

La seconda architettura, raffigurata in figura 2, consente di ispezionare tutti i flussi di comunicazione che terminano sul database. Le comunicazioni possono transitare su rete (usandone i rispettivi protocolli), o essere locali quando il client risiede sullo stesso server del database. In questo caso le comunicazioni si basano sui meccanismi di comunicazione tra processi (IPC - inter-processing communications). Il sistema di auditing adottato in questo schema fa generalmente uso di strumenti di ispezione dei pacchetti per le connessioni di rete, e di apposite sonde (probe) nel sistema operativo per controllare le comunicazioni IPC. Le sonde possono essere configurate anche per verificare l'ultimo tratto delle connessioni di rete, quando i pacchetti giungono al sistema operativo che le inoltra alle porte su cui il database è in ascolto.

Figura 3 - Ispezione dei file generati dal database

La terza architettura di auditing ricorre ai file di supporto del database, dai quali estrae le informazioni che gli occorrono (figura 3). Tipicamente è coinvolto il log delle transazioni, in cui i DBMS registrano tutti i comandi DDL e DML a scopo di ripristino in caso di guasti. Il sistema di auditing può leggere e processare in tempo reale i record registrati nel log e ricostruire la sequenza di operazioni effettuate sul database. Altri file utilizzati possono essere quelli di configurazione, i trace file, altri tipi di log, a seconda dei meccanismi attivi sul database e del supporto ad essi offerto dal sistema di auditing implementato.

Nel prossimo post concluderò il discorso sull'auditing parlando di archiviazione e protezione dei dati raccolti. Vi aspetto!

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!

Auditing dei database: introduzione

Introduco oggi una breve serie di post sul tema dell'auditing, sulla scia delle considerazioni dell'ultimo intervento (caso Hannaford). Comincerò con una rapida introduzione nell'ambito specifico dei database; nei prossimi giorni parlerò di categorie di auditing, delle architetture implementative più utilizzate, e infine della protezione dei dati di auditing.

L'auditing, o revisione dei sistemi informativi è un processo di verifica sistematico, periodico e documentato, condotto da personale esperto, volto ad accertare che i sistemi informativi di un'azienda o organizzazione siano conformi a quanto previsto da norme, regolamenti o politiche interne. Nello specifico delle basi dati, l'attività di auditing consente di tenere traccia e analizzare qualsiasi attività svolta sulla base dati, tra cui gli accessi, l'attività di utenti e applicazioni connesse, operazioni sui dati e così via.

Monitorare costantemente la sicurezza delle base dati è essenziale per tutte quelle organizzazioni che devono garantire la conformità a norme sempre più restrittive, tra cui il Sarbanes-Hoxley Act (SOX) per la borsa americana, l’Health Insurance Portability and Accountability Act (HIPAA) sulla protezione dei dati clinici dei cittadini americani, la Direttiva Europea 95/46/EC sulla tutela dei dati personali e il Regolamento sul trattamento dei dati del Garante della Privacy italiano. Non solo, il processo di auditing dei database deve essere tale da garantire l'integrità dei dati e identificare possibili falle di sicurezza o tentativi di intrusione nei sistemi.

L'importanza della separazione dei compiti

Le norme citate condividono in particolare due punti: tracciano delle linee guida che stabiliscono le azioni che gli operatori coinvolti devono intraprendere (per evitare delle libere interpretazioni che finiscano col non soddisfare i requisiti imposti); ma soprattutto inducono a separare i compiti di gestione e di controllo dei sistemi informativi all'interno dell'organizzazione. Il concetto di separazione dei compiti nasce dall'idea che non è opportuno affidare i compiti di sistemista e di controllore a un unico individuo (o gruppo). Anzi, è consigliabile definire una catena gerarchica in cui ogni livello garantisce per l'operato del livello sottostante, come nel caso del SOX, che descrive espicitamente i compiti del management, quelli dell'auditing interno e quelli dell'auditing esterno.

In quei paesi come gli Stati Uniti in cui la rispondenza alle norme è questione seria, la separazione dei compiti è obbligatoria, e se non è applicata si è considerati fuorilegge. Chi sbaglia paga: il CEO della Enron, se non fosse morto prima del tempo, avrebbe fatto qualche decina d'anni di galera (il SOX è una delle conseguenze di quello scandalo). Da noi, per il caso Parmalat, a pagare sono stati più che altro gli investitori.

Parlando di database e auditing, la separazione dei compiti implica che il DBA non si occupi delle funzioni di controllo. La questione alla base è semplice e può essere riassunta in modo un po' "brutale": chi controlla un DBA disonesto?

L'utilità dell'auditing non si limita certamente a questo. Tuttavia i casi abbondano: tempo fa una grande azienda di distribuzione nazionale ha licenziato in tronco uno dei suoi DBA perché colto a modificare le presenze della sua fidanzata, collega di lavoro in altro ufficio. Il DBA non potè neppure appellarsi al licenziamento senza giusta causa, avendo contro i risultati dell'auditing sui database; mancò poco che rimediasse anche una denuncia per truffa...

Tornando ai database, tutti i principali DBMS sono provvisti di funzionalità interne di auditing, che spesso sono ritenute sufficienti per i proprio scopi, soprattutto nelle realtà medio-piccole del nostro tessuto economico. Tuttavia, il DBA ha pieno accesso a tali funzionalità, e per attendere alla separazione dei compiti bisognerà prevedere una serie di misure di controllo di non facile implementazione. Risulta invece più comodo fare ricorso a risorse esterne, che sul mercato abbondano (come DbProtect e DB Audit), con l’ulteriore vantaggio di sgravare il DBA dalla gestione diretta dell'auditing, comunque impegnativa.

Nel prossimo post parlerò di categorie di auditing, ovvero di quali elementi del database sottoporre alla revisione. Stay tuned!