Certificare l'integrità di un flusso di log continuo, una posta in gioco di sicurezza cruciale

Perché dimostrare l'integrità di un registro di log?

1. La complessità di integrazione lato applicativo,
2. I costi indotti dall'archiviazione e dalla firma digitale,
3. Il carico operativo legato alla gestione e alla verifica dei logs sicuri.

• un'implementazione ingenua basata su una blockchain (che è una soluzione semplice ed efficace, ma che non permette la rotazione dei logs),
• una versione più efficace e pragmatica costruita attorno ai Merkle Trees*.

type LogEntry struct {
	Message   string    `json:"message"`
	Timestamp time.Time `json:"timestamp"`
}

Implementazione naive: una blockchain

Albero di Merkle: un'alternativa più flessibile

• l'hash della foglia (il log stesso),
• la lista ordinata degli hash fratelli incontrati risalendo verso la radice, così come la loro posizione sinistra/destra.

• Non è più necessario riprodurre l'intera sequenza di eventi, per verificare un log è sufficiente una prova di appartenenza, composta unicamente dagli hash laterali.
• Ogni sotto-albero può essere calcolato indipendentemente, ciò permette di distribuire il calcolo su più macchine (o threads), eliminando il collo di bottiglia inerente alla catena di hash (dove ogni blocco dipende dal precedente).
• Si può troncare o archiviare un sotto-albero completo senza rompere la validità del resto: si taglia il link verso la parte obsoleta, si ricalcolano gli hash fino al nodo di taglio e si considera questo nodo come nuova radice per la finestra corrente. Non c'è bisogno di eliminare né di riprodurre tutte le foglie conservate.
• Ogni servizio o VM può costruire il proprio albero in parallelo e pubblicare la sua radice, queste radici possono poi essere combinate in un albero di radici, rendendo il modello perfettamente scalabile orizzontalmente.

Proof of concept

• Costruire e aggiornare la radice in streaming tramite un StreamBuilder, in O(log n) memoria (non c'è quindi un albero completo in RAM).
• Generare e verificare prove di inclusione con un albero esplicito, serializzabile in SQLite per audit e ricostruzione.
• Validare l'equivalenza stream <=> albero, anche in concorrenza, tramite test deterministici e fuzzing.
• Pubblicare regolarmente le radici (e firme) in storage immutabile tipo S3 Object Lock / equivalente, per datare e bloccare i checkpoint.

const (
  leafPrefix     byte = 0x00
  internalPrefix byte = 0x01
)

func LeafDigest(e LogEntry) [32]byte {
  m := e.Serialize()
  b := make([]byte, 1+len(m))
  b[0] = leafPrefix
  copy(b[1:], m)
  return sha256.Sum256(b)
}

func CombineDigests(l, r [32]byte) [32]byte {
  var buf [1 + 32 + 32]byte
  buf[0] = internalPrefix
  copy(buf[1:33], l[:])
  copy(buf[33:], r[:])
  return sha256.Sum256(buf[:])
}

Albero esplicito e prove

• Node contiene sia una foglia (Data), sia dei puntatori Left/Right e un hash memorizzato nella cache.
• BuildMerkleRoot ripiega ogni livello fino alla radice.
• GenerateProof risale dalla foglia alla radice raccogliendo gli hash fratelli e la loro posizione sinistra/destra.
• VerifyProof rifà il percorso e confronta con la radice attesa.

type ProofStep struct{ Hash [32]byte; Right bool }

func VerifyProof(leaf LogEntry, proof []ProofStep, root [32]byte) bool {
  h := LeafDigest(leaf)
  for _, s := range proof {
    if s.Right { h = CombineDigests(h, s.Hash) } else { h = CombineDigests(s.Hash, h) }
  }
  return h == root
}

Streaming in O(log n)

type StreamBuilder struct {
  mu sync.Mutex
  levels []levelDigest
  entryCount int
}

func (s *StreamBuilder) AddEntry(e LogEntry) {
  d := LeafDigest(e)
  s.mu.Lock()
  s.foldDigestLocked(0, d)
  s.entryCount++
  s.mu.Unlock()
}

func (s *StreamBuilder) Root() ([32]byte, bool) {
  s.mu.Lock(); defer s.mu.Unlock()
  var out [32]byte; var ok bool
  for _, slot := range s.levels {
    if !slot.filled { continue }
    if !ok { out, ok = slot.hash, true; continue }
    out = CombineDigests(slot.hash, out)
  }
  return out, ok
}

Persistenza e audit

• di riprodurre l'albero / verificare prove localmente
• di esportare le foglie originali per una finestra di N giorni indietro
• di ispezionare la struttura ordinando per level / position.

Test, robustezza e fuzzing

Invarianti di hash e di ordine

• Separazione di dominio effettiva: un hash di foglia non deve mai uguagliare un hash interno con lo stesso payload (prefissi 0x00 / 0x01).
• Non-commutatività: invertire sinistra/destra deve dare un digest diverso, il che impedisce di riordinare i figli senza allertare.
• Stabilità: a input identico, il digest è stabile (nessuno stato nascosto né sorgente di casualità).

Albero, prove e negativi

Concorrenza

Fuzzing

Checkpointing e ancoraggio immutabile per la conformità

Perché ancorare i checkpoints?

• si calcola una radice per un periodo dato (es. un giorno)
• la si pubblica in uno storage immutabile
• non la si tocca mai più

Con quale frequenza pubblicare la radice?

• Pubblicare più spesso (es. ogni ora, o ogni 10k input). Il costo è trascurabile poiché un checkpoint è solo un hash + firma.
• Mantenere una radice "di lavoro" generata continuamente (il StreamBuilder sa dare la radice in ogni istante) e ancorarla nell'object store non appena viene richiesto un audit. Questa radice istantanea diventa quindi il punto di riferimento per questo log.

S3 Object Lock: immutabilità garantita a livello di storage

• L'oggetto non può essere modificato né eliminato finché il periodo di ritenzione non è scaduto (Write Once Read Many)
• Ogni tentativo di sostituzione crea una nuova versione; si può anche applicare un legal hold per bloccare l'eliminazione amministrativa.

aws s3api put-object \
  --bucket merkle-checkpoints \
  --key roots/2025-10-01.json \
  --object-lock-mode COMPLIANCE \
  --object-lock-retain-until-date 2025-12-31T00:00:00Z \
  --body checkpoint.json

Alternative presso altri fornitori

• Azure Blob Storage : propone immutable blob policies e legal holds, con meccanismi simili (durata di ritenzione o blocco legale).
• Google Cloud Storage : offre le Object Retention Policies e Bucket Lock, bloccando gli oggetti per durate predefinite.
• MinIO : in self-hosted, implementa anche Object Lock, compatibile con l'API S3 (affidabile a condizione di avere un'infrastruttura zero trust).

Perché questo approccio è ideale

1. Risponde direttamente ai requisiti di ritenzione delle norme come NF525, PCI-DSS o HDS : il checkpoint è in modalità Write Once, Read Many (WORM). Se i log grezzi venissero eliminati altrove, la prova di inclusione fallirebbe, rendendo l'eliminazione rilevabile; per la prevenzione, si memorizzano anche i log in un bucket con ritenzione/Object Lock.
2. Ogni checkpoint è un oggetto di pochi byte archiviato una sola volta, quindi il costo è trascurabile rispetto al volume dei logs stessi.
3. Una radice al giorno / settimana è sufficiente; possono essere replicate e firmate per rafforzare la tracciabilità.

Ottimizzazione dei costi e design operativo

Archiviazione

• i logs grezzi possono essere compressi e archiviati in un S3 Glacier fino alla fine del loro periodo di conservazione
• i checkpoints sono archiviati durevolmente a costi inferiori

Elaborazione

Conclusione