Un registro che si può correggere non è una prova

La domanda arriva sempre nello stesso momento: dopo. Un prezzo modificato in un ordine già confermato, un documento che risulta inviato ma non è mai partito, un’anagrafica cambiata da qualcuno che non avrebbe dovuto. «Chi l’ha fatto?» Il sistema, in genere, una risposta la dà. Il punto è se quella risposta vale qualcosa.

Un log serve a diagnosticare, un registro serve a dimostrare

Sono due cose diverse che finiscono spesso nella stessa tabella. Il log tecnico esiste per gli sviluppatori: è verboso, ruota ogni settimana, viene ripulito quando il disco si riempie, e nessuno si scandalizza se qualcuno lo tocca. Il registro delle operazioni esiste per l’azienda: descrive fatti — chi, cosa, quando, com’era prima e com’è dopo — e il suo valore sta interamente nel fatto di non poter essere rimaneggiato.

Confonderli è comodo finché non serve. Il giorno in cui serve, il costo si paga tutto insieme: una contestazione con un cliente, una verifica ispettiva, un incidente da ricostruire. E ricostruire l’accaduto dai backup e dai log applicativi richiede settimane, per produrre comunque una risposta che nessuno è disposto a firmare.

Il test è banale: chi può cambiarlo?

Se una riga può essere modificata o cancellata — dall’applicazione, da un amministratore, o da una query diretta sul database — allora quel registro descrive ciò che è successo soltanto finché nessuno ha interesse contrario. Tre proprietà lo trasformano in qualcosa di difendibile, e nessuna delle tre è costosa se decisa all’inizio:

• Solo aggiunte. Le scritture aggiungono, mai aggiornano. Una correzione è un nuovo evento che ne rettifica uno precedente, non una sostituzione: resta visibile l’errore e la rettifica.
• Catena verificabile. Ogni evento porta con sé un’impronta di quello che lo precede. Rimuovere o alterare una riga rompe la catena da lì in avanti, e la manomissione diventa visibile invece che invisibile.
• Scrittura separata dalla lettura. Chi usa l’applicazione non deve avere alcun modo di scrivere nel registro se non producendo l’evento. Se l’accesso diretto al database aggira il meccanismo, il meccanismo non esiste.

Cosa registrare per davvero

L’elenco utile è più corto di quanto sembri, ma ha due voci che quasi sempre mancano. La prima sono i dinieghi: un tentativo respinto è un dato di sicurezza, e un registro che annota solo i successi racconta metà della storia. La seconda è l’identità effettiva. Nelle integrazioni le operazioni arrivano da un utente tecnico, e tracciare quello equivale a non tracciare nulla: serve l’attore umano, o il sistema committente, dietro la chiamata — propagato fino alla scrittura.

Il resto è ovvio, e va fatto bene comunque: valore prima e dopo, orario con fuso esplicito, riferimento all’entità toccata.

Non è un progetto da dodici mesi

Non serve tracciare tutto — anzi, tracciare tutto è il modo più affidabile per ottenere un registro che nessuno consulta. Serve la lista breve delle operazioni su cui, un giorno, qualcuno chiederà conto: importi, autorizzazioni, dati trasmessi all’esterno, cancellazioni. Trenta eventi scelti bene e immodificabili valgono più di un tracciamento integrale che si può riscrivere.