Come l'Hash Chaining Crittografico Garantisce Log a Prova di Manomissione

Quando un auditor esamina i tuoi log, deve poter fidarsi che ciò che vede sia esattamente ciò che è accaduto, nessun evento rimosso, nessun timestamp alterato, nessun record inserito a posteriori. L'hash chaining crittografico fornisce questa garanzia attraverso la matematica, non attraverso una policy.

Cos'è l'Hash Chaining?

L'hash chaining è una tecnica in cui ogni record di una sequenza include un hash crittografico che dipende dal record precedente. Se un record della catena viene modificato, eliminato o riordinato, i valori hash non corrispondono più e la manomissione è immediatamente rilevabile.

Il concetto è semplice ma potente. L'hash di ogni evento di log viene calcolato a partire da tre input: l'hash dell'evento precedente, il payload canonico dell'evento corrente e un timestamp con precisione al millisecondo. Usiamo SHA-256, lo stesso algoritmo usato nei certificati TLS, nelle firme digitali e in Bitcoin.

La Formula dell'Hash

In AuditRails, l'hash di ogni evento di log viene calcolato come segue:

hash = SHA-256(prev_hash + canonical_payload + timestamp_ms)

Dove:

• prev_hash è l'hash SHA-256 dell'evento immediatamente precedente nella chain dello stesso tenant
• canonical_payload è una serializzazione JSON deterministica dei campi principali dell'evento: log_id, tenant_id, action, actor_id, resource, e metadata
• timestamp_ms è il timestamp assegnato dal server in millisecondi dall'epoca Unix

Il payload canonico esclude deliberatamente i campi aggiunti durante l'elaborazione (come i dati geo-IP, i campi di enrichment e l'hash stesso) per garantire che l'hash venga calcolato sui dati immutabili forniti dall'applicazione.

Chain per Tenant e l'Hash Genesis

Ogni tenant (organizzazione) mantiene la propria hash chain indipendente. Questa è una scelta di design deliberata: l'isolamento dei tenant è un principio di sicurezza fondamentale, e mescolare i tenant in un'unica chain creerebbe dipendenze cross-tenant che complicherebbero sia la sicurezza che la scalabilità.

Ogni chain inizia con un hash genesis, un valore iniziale noto composto da 64 zeri:

genesis_hash = "0000000000000000000000000000000000000000000000000000000000000000"

Il primo evento nella chain di un tenant utilizza questo hash genesis come proprio prev_hash. Da quel momento in poi, ogni evento fa riferimento all'hash dell'evento che lo precede, creando una sequenza ininterrotta.

Come la Manomissione Interrompe la Chain

Considera una chain di tre eventi per un tenant. L'hash di ogni evento dipende dall'hash dell'evento precedente:

Event #1:
  prev_hash:  0000000000000000...  (genesis)
  payload:    {"action": "user.login", "actor_id": "usr_abc", ...}
  timestamp:  1711929600000
  hash:       a1b2c3d4e5f6...

Event #2:
  prev_hash:  a1b2c3d4e5f6...     (hash of Event #1)
  payload:    {"action": "document.create", "actor_id": "usr_abc", ...}
  timestamp:  1711929601500
  hash:       f7e8d9c0b1a2...

Event #3:
  prev_hash:  f7e8d9c0b1a2...     (hash of Event #2)
  payload:    {"action": "document.share", "actor_id": "usr_abc", ...}
  timestamp:  1711929603000
  hash:       3344556677889900...

Supponiamo ora che qualcuno modifichi l'Evento #2, magari cambiando document.create in document.view per nascondere il fatto che è stato creato un documento. Nel momento in cui il payload dell'Evento #2 cambia, il suo hash ricalcolato non corrisponde più a f7e8d9c0b1a2.... E poiché l'hash dell'Evento #3 era stato calcolato usando l'hash originale dell'Evento #2 come prev_hash, anche l'hash dell'Evento #3 diventa non valido. La corruzione si propaga a cascata su ogni evento successivo della chain.

Anche se un attaccante ricalcolasse tutti gli hash a partire dall'evento manomesso in avanti, il nuovo hash della testa della chain differirebbe da quello memorizzato, che AuditRails mantiene in uno store separato e crittograficamente protetto. Non c'è modo di manomettere un singolo evento senza che venga rilevato.

Storage WORM: il Secondo Livello di Protezione

L'hash chaining rileva la manomissione. Lo storage WORM (Write Once, Read Many) la impedisce a livello di infrastruttura.

Ogni batch di eventi di log viene scritto su Amazon S3 con Object Lock attivato in modalità compliance. Una volta scritti, i dati non possono essere eliminati o sovrascritti da nessuno, inclusi gli account AWS root, finché non scade il periodo di retention. I periodi di retention partono da 6 mesi su ogni piano e si estendono automaticamente in base ai framework di compliance a cui sei abbonato, 7 anni per SOX, fino a 10 anni per l'EU AI Act, il requisito più lungo tra tutti i 18, oppure possono essere estesi ulteriormente con un componente aggiuntivo di retention self-service.

Questo approccio a due livelli significa che, anche se un attaccante ottenesse pieno accesso al database, non potrebbe modificare le copie in cold storage, e qualsiasi modifica all'hot storage verrebbe rilevata dalla verifica della hash chain.

Come si Confronta con la Blockchain?

Se l'hash chaining ti sembra familiare, è perché lo è, è lo stesso concetto fondamentale su cui si basa la tecnologia blockchain. Ogni blocco di una blockchain contiene l'hash del blocco precedente, creando un registro immutabile.

La differenza fondamentale è che AuditRails utilizza una chain centralizzata, per tenant piuttosto che un meccanismo di consenso distribuito. Non abbiamo bisogno di proof-of-work, mining o di una rete peer-to-peer. Il modello di fiducia è diverso: invece di fidarti di una rete decentralizzata, ti fidi di AuditRails come custode append-only della tua traccia di audit, supportato da una verifica crittografica che puoi eseguire in modo indipendente.

Questo ti offre le garanzie di tamper-evidence della tecnologia blockchain a una frazione del costo e della complessità, con una latenza di scrittura dell'ordine dei millisecondi invece dei tempi di conferma da secondi a minuti tipici dei registri distribuiti.

Il Processo di Verifica

AuditRails fornisce un endpoint di verifica e una funzionalità della dashboard che scorre la hash chain e ricalcola ogni hash a partire dall'evento genesis. Il processo è semplice:

1. Parti dall'hash genesis ( 0000...0000) come valore atteso di prev_hash
2. Per ogni evento della sequenza, verifica che il prev_hash memorizzato corrisponda al valore atteso
3. Ricalcola SHA-256(prev_hash + canonical_payload + timestamp_ms)
4. Verifica che l'hash ricalcolato corrisponda all'hash memorizzato
5. Usa l'hash memorizzato come il nuovo valore atteso di prev_hash per l'evento successivo

Se un passaggio qualsiasi fallisce, il report di verifica identifica l'evento esatto in cui la chain si interrompe e la natura della discrepanza. Questo fornisce agli auditor una prova concreta e matematicamente verificabile dell'integrità dei log.

Perché Interessa agli Auditor

Framework di compliance come SOC 2 (CC7.2), HIPAA (§164.312(b)) e ISO 27001 (A.12.4) richiedono tutti che le organizzazioni mantengano tracce di audit protette da modifiche non autorizzate. L'hash chaining fornisce una prova crittografica che i log non sono stati manomessi, non solo una dichiarazione di policy, ma una garanzia matematica.

Quando un auditor chiede "Come garantite l'integrità dei vostri audit log?", la risposta non è più "Abbiamo controlli di accesso sul database". È "Ogni evento di log è concatenato crittograficamente usando SHA-256, memorizzato su storage WORM e verificabile in modo indipendente. Ecco il report di verifica".

Questa è la differenza tra un controllo che potrebbe funzionare e un controllo che è dimostrabilmente efficace.