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!