Stai pensando a un progetto di database per la registrazione di audit? Ricorda cosa è successo a Hansel e Gretel:pensavano che lasciare una semplice scia di briciole di pane fosse un buon modo per ripercorrere i loro passi.
Quando progettiamo un modello di dati, siamo addestrati ad applicare la filosofia che ora è tutto ciò che esiste . Ad esempio, se progettiamo uno schema per memorizzare i prezzi per un catalogo di prodotti, potremmo pensare che il database debba solo dirci il prezzo di ciascun prodotto al momento attuale. Ma se volessimo sapere se i prezzi sono stati modificati e, in tal caso, quando e come sono avvenute tali modifiche, saremmo nei guai. Naturalmente, potremmo progettare il database in modo specifico per mantenere un registro cronologico delle modifiche, comunemente noto come traccia di controllo o registro di controllo.
La registrazione dell'audit consente a un database di avere una "memoria" di eventi passati. Continuando con l'esempio del listino prezzi, un registro di controllo appropriato consentirà al database di dirci esattamente quando un prezzo è stato aggiornato, qual era il prezzo prima dell'aggiornamento, chi lo ha aggiornato e da dove.
Soluzioni di registrazione degli audit del database
Sarebbe fantastico se il database potesse conservare un'istantanea del suo stato per ogni modifica che si verifica nei suoi dati. In questo modo, puoi tornare indietro in qualsiasi momento e vedere come erano i dati in quel preciso momento, proprio come se stessi riavvolgendo un film. Ma questo modo di generare la registrazione di audit è ovviamente impossibile; il volume di informazioni risultante e il tempo necessario per generare i log sarebbero troppo elevati.
Le strategie di registrazione degli audit si basano sulla generazione di audit trail solo per i dati che possono essere eliminati o modificati. Qualsiasi alterazione in esse deve essere verificata per annullare le modifiche, interrogare i dati nelle tabelle della cronologia o tenere traccia di attività sospette.
Esistono diverse tecniche di registrazione degli audit popolari, ma nessuna serve a tutti gli scopi. I più efficaci sono spesso costosi, ad alta intensità di risorse o con prestazioni degradanti. Altri sono più economici in termini di risorse, ma sono incompleti, ingombranti da mantenere o richiedono un sacrificio nella qualità del design. La strategia che scegli dipenderà dai requisiti dell'applicazione e dai limiti di prestazioni, dalle risorse e dai principi di progettazione che devi rispettare.
Soluzioni di registrazione pronte all'uso
Queste soluzioni di registrazione degli audit funzionano intercettando tutti i comandi inviati al database e generando un registro delle modifiche in un repository separato. Tali programmi offrono molteplici opzioni di configurazione e reporting per tenere traccia delle azioni dell'utente. Possono registrare tutte le azioni e le query inviate a un database, anche quando provengono da utenti con i privilegi più elevati. Questi strumenti sono ottimizzati per ridurre al minimo l'impatto sulle prestazioni, ma spesso ciò comporta un costo monetario.
Il prezzo di soluzioni dedicate per le tracce di controllo può essere giustificato se stai gestendo informazioni altamente sensibili (come le cartelle cliniche) in cui qualsiasi alterazione dei dati deve essere perfettamente monitorata e verificabile e la traccia di controllo deve essere inalterabile. Ma quando i requisiti dell'audit trail non sono così severi, il costo di una soluzione di registrazione dedicata può essere eccessivo.
Gli strumenti di monitoraggio nativi offerti dai sistemi di database relazionali (RDBMS) possono essere utilizzati anche per generare audit trail. Le opzioni di personalizzazione consentono di filtrare quali eventi vengono registrati, in modo da non generare informazioni non necessarie o sovraccaricare il motore di database con operazioni di registrazione che non verranno utilizzate in seguito. I log così generati consentono un tracciamento dettagliato delle operazioni eseguite sulle tabelle. Tuttavia, non sono utili per eseguire query sulle tabelle della cronologia, poiché registrano solo eventi.
L'opzione più economica per mantenere un audit trail è progettare specificamente il database per la registrazione degli audit. Questa tecnica si basa su tabelle di log popolate da trigger o meccanismi specifici dell'applicazione che aggiorna il database. Non esiste un approccio universalmente accettato per la progettazione del database di registrazione degli audit, ma esistono diverse strategie comunemente utilizzate, ognuna delle quali ha i suoi pro e contro.
Tecniche di progettazione della registrazione di audit del database
Versioning delle righe per la registrazione di controllo in atto
Un modo per mantenere un audit trail per una tabella consiste nell'aggiungere un campo che indichi il numero di versione di ogni record. Gli inserimenti nella tabella vengono salvati con un numero di versione iniziale. Eventuali modifiche o cancellazioni diventano effettivamente operazioni di inserimento, dove vengono generati nuovi record con i dati aggiornati e il numero di versione viene incrementato di uno. Di seguito puoi vedere un esempio di questa progettazione del luogo di registrazione di controllo:
Nota:i progetti di tabella con controllo delle versioni delle righe incorporato non possono essere collegati da relazioni di chiave esterna.
Oltre al numero di versione, è necessario aggiungere alla tabella alcuni campi aggiuntivi per determinare l'origine e la causa di ogni modifica apportata a un record:
- La data/ora in cui è stata registrata la modifica.
- L'utente e l'applicazione.
- L'azione eseguita (inserire, aggiornare, eliminare), ecc. Affinché l'audit trail sia efficace, la tabella deve supportare solo gli inserimenti (gli aggiornamenti e le eliminazioni non devono essere consentiti). La tabella richiede necessariamente anche una chiave primaria surrogata, poiché qualsiasi altra combinazione di campi sarà soggetta a ripetizione.
Per accedere ai dati della tabella aggiornati tramite query, è necessario creare una vista che restituisca solo l'ultima versione di ogni record. Quindi, devi sostituire il nome della tabella con il nome della vista in tutte le query tranne quelle specificamente destinate a visualizzare la cronologia dei record.
Il vantaggio di questa opzione di controllo delle versioni è che non richiede l'utilizzo di tabelle aggiuntive per generare l'audit trail. Inoltre, alle tabelle controllate vengono aggiunti solo pochi campi. Ma ha un enorme svantaggio:ti costringerà a commettere alcuni degli errori di progettazione del database più comuni. Questi includono il non utilizzare l'integrità referenziale o le chiavi primarie naturali quando è necessario, rendendo impossibile l'applicazione dei principi di base della progettazione del diagramma entità-relazione. Puoi visitare queste utili risorse sugli errori di progettazione del database, così sarai avvisato su quali altre pratiche dovrebbero essere evitate.
Tavoli d'ombra
Un'altra opzione dell'audit trail consiste nel generare una tabella shadow per ogni tabella che deve essere controllata. Le tabelle shadow contengono gli stessi campi delle tabelle che controllano, più i campi di controllo specifici (gli stessi menzionati per la tecnica di controllo delle versioni delle righe).
Le tabelle shadow replicano gli stessi campi delle tabelle che controllano, più i campi specifici per scopi di controllo.
Per generare audit trail nelle tabelle shadow, l'opzione più sicura è creare trigger di inserimento, aggiornamento ed eliminazione, che per ogni record interessato nella tabella originale generano un record nella tabella di audit. I trigger dovrebbero avere accesso a tutte le informazioni di controllo necessarie per registrare nella tabella ombra. Dovrai utilizzare la funzionalità specifica del motore di database per ottenere dati come la data e l'ora correnti, l'utente registrato, il nome dell'applicazione e la posizione (indirizzo di rete o nome del computer) in cui ha avuto origine l'operazione.
Se l'utilizzo dei trigger non è un'opzione, la logica per generare gli audit trail dovrebbe far parte dello stack dell'applicazione, in un livello idealmente posizionato appena prima del livello di persistenza dei dati, in modo che possa intercettare tutte le operazioni dirette verso il database.
Questo tipo di tabella di registro dovrebbe consentire solo l'inserimento di record; se consentono la modifica o l'eliminazione, la pista di controllo non svolgerebbe più la sua funzione. Le tabelle devono inoltre utilizzare chiavi primarie surrogate, poiché le dipendenze e le relazioni delle tabelle originali non possono essere applicate ad esse.
Se la tabella per la quale è stato creato un audit trail ha tabelle da cui dipende, anche queste dovrebbero avere tabelle shadow corrispondenti. In questo modo l'audit trail non rimane orfano se vengono apportate modifiche alle altre tabelle.
Le tabelle shadow sono convenienti per la loro semplicità e perché non influiscono sull'integrità del modello di dati; gli audit trail rimangono in tabelle separate e sono facili da interrogare. Lo svantaggio è che lo schema non è flessibile:qualsiasi modifica nella struttura della tabella principale deve riflettersi nella tabella ombra corrispondente, il che rende difficile la manutenzione del modello. Inoltre, se è necessario applicare la registrazione di controllo a un numero elevato di tabelle, anche il numero di tabelle shadow sarà elevato, rendendo ancora più difficile la manutenzione dello schema.
Tabelle generiche per la registrazione degli audit
Una terza opzione consiste nel creare tabelle generiche per i log di controllo. Tali tabelle consentono la registrazione di qualsiasi altra tabella nello schema. Per questa tecnica sono necessarie solo due tabelle:
Una tabella di intestazione che registra:
- La data e l'ora della modifica.
- Il nome della tabella.
- La chiave della riga interessata.
- I dati dell'utente.
- Il tipo di operazione eseguita.
Una tabella dei dettagli che registra:
- I nomi di ogni campo interessato.
- I valori del campo prima della modifica.
- I valori del campo dopo la modifica. (Puoi ometterlo se necessario, poiché può essere ottenuto consultando il seguente record nell'audit trail o il record corrispondente nella tabella verificata.)
L'uso di tabelle log di controllo generiche pone limiti ai tipi di dati che possono essere controllati.
Il vantaggio di questa strategia di registrazione degli audit è che non richiede tabelle diverse dalle due sopra menzionate. Inoltre, i record vengono archiviati solo per i campi interessati da un'operazione. Ciò significa che non è necessario replicare un'intera riga di una tabella quando viene modificato un solo campo. Inoltre, questa tecnica ti consente di mantenere un registro di tutte le tabelle che desideri, senza ingombrare lo schema con un numero elevato di tabelle aggiuntive.
Lo svantaggio è che i campi che memorizzano i valori devono essere di un unico tipo e sufficientemente ampi da memorizzare anche il più grande dei campi delle tabelle per cui si desidera generare un registro di controllo. È più comune utilizzare campi di tipo VARCHAR che accettano un numero elevato di caratteri.
Se, ad esempio, è necessario generare un registro di controllo per una tabella che dispone di un campo VARCHAR di 8.000 caratteri, anche il campo che memorizza i valori nella tabella di controllo deve contenere 8.000 caratteri. Questo è vero anche se memorizzi solo un numero intero in quel campo. D'altra parte, se la tua tabella ha campi di tipi di dati complessi, come immagini, dati binari, BLOB, ecc., dovrai serializzare il loro contenuto in modo che possano essere archiviati nei campi VARCHAR delle tabelle di log.
Scegli saggiamente la progettazione del registro di controllo del database
Abbiamo visto diverse alternative per generare la registrazione di audit, ma nessuna è davvero ottimale. È necessario adottare una strategia di registrazione che non influisca in modo sostanziale sulle prestazioni del database, non lo faccia crescere eccessivamente e possa soddisfare i requisiti di tracciabilità. Se desideri archiviare i registri solo per alcune tabelle, le tabelle shadow potrebbero essere l'opzione più conveniente. Se desideri la flessibilità di registrare qualsiasi tabella, le tabelle di registrazione generiche potrebbero essere le migliori.
Hai scoperto un altro modo per mantenere un registro di controllo per i tuoi database? Condividilo nella sezione commenti qui sotto:i tuoi colleghi progettisti di database te ne saranno molto grati!
