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!