Event-store bitemporale: come funziona una cronologia immutabile
Un event store bitemporale memorizza ogni osservazione come evento immutabile e datato (append-only) e distingue due assi temporali: quando qualcosa è accaduto nella realtà e quando è stato registrato nel sistema. Una catena hash aggiuntiva rende riconoscibili le manipolazioni successive — tuttavia esclusivamente a partire dal momento in cui la catena è iniziata, non retroattivamente per il periodo precedente.
- Principio di memorizzazione
- Append-only (mai cancellare, mai sovrascrivere)
- Assi temporali
- 2 (tempo dell'evento + tempo di registrazione)
- Meccanismo di integrità
- Catena hash
- Ancoraggio esterno
- OpenTimestamps (giornaliero) + marca temporale RFC 3161 (settimanale)
Cosa significano «append-only» e «bitemporale»
Append-only significa: un evento scritto una volta non viene mai cancellato o modificato — una correzione viene aggiunta come nuovo evento autonomo, che fa riferimento a quello originale. Bitemporale significa: ogni evento porta due marche temporali — quando è accaduto nella realtà (tempo dell'evento) e quando è stato effettivamente registrato nel sistema (tempo di registrazione). Questa separazione rende visibile quando un'osservazione è stata inserita con ritardo (ad es. rilevamento offline sul campo, sincronizzato solo più tardi), senza falsare il tempo effettivo dell'osservazione.
Cosa dimostra la catena hash — e cosa non dimostra
Ogni nuovo evento contiene il valore hash del suo predecessore. Una modifica successiva di un evento precedente romperebbe visibilmente questa catena. Ma è determinante quanto segue: questo meccanismo dimostra l'integrità solo a partire dal momento in cui la catena ha effettivamente iniziato a funzionare. Per gli eventi precedenti all'inizio della catena non esiste alcuna garanzia crittografica retroattiva — una catena calcolata a posteriori non dimostra nulla sul passato precedente al proprio stesso inizio.
Ancoraggio esterno
Per proteggere la catena stessa da una manipolazione successiva, essa viene inoltre ancorata esternamente: giornalmente tramite il protocollo gratuito OpenTimestamps e settimanalmente tramite un servizio di marcatura temporale conforme a RFC 3161. Ciò sposta la fiducia da un'affermazione interna a un momento verificabile esternamente.
Per la vostra azienda
In pratica ciò significa: un'osservazione rilevata sul campo senza connessione di rete, sincronizzata solo ore dopo, mantiene il proprio tempo effettivo di osservazione — non viene erroneamente datata al momento successivo della sincronizzazione.
Per l'ente committente
Uno storico append-only è un argomento forte, ma non assoluto, di tracciabilità — non sostituisce una propria verifica del concreto valore probatorio nel singolo caso.
Cosa non significa
- Il termine «a prova di tribunale» non fa volutamente parte della nostra comunicazione (Art. 13a LCSl) — un tribunale apprezza sempre liberamente le prove (Art. 157 CPC), una protezione tecnica può sostenere questo apprezzamento, ma non può sostituirlo.
- La catena hash dimostra l'integrità solo A PARTIRE dall'inizio della catena, mai retroattivamente per i dati precedenti — è un limite consapevole e onesto della tecnologia, non un'affermazione di marketing.
- Un event store bitemporale protegge da una modifica successiva non rilevata, non da un'osservazione iniziale sbagliata fin dall'inizio.
Domande frequenti
- Una catena hash dimostra che i dati erano corretti fin dall'inizio?
- No. Dimostra solo che i dati non sono stati modificati inosservati dall'inizio della catena — un'osservazione sbagliata fin dall'inizio resta da ciò non toccata.
- Qual è la differenza tra tempo dell'evento e tempo di registrazione?
- Il tempo dell'evento è quando qualcosa è effettivamente accaduto nella realtà; il tempo di registrazione è quando è stato registrato nel sistema. In caso di rilevamento offline i due possono discostarsi notevolmente.