Integrità dei log ed evidenza di manomissione: come costruire log firmati, append-only con archiviazione verificabile offsite

Chi considera i log solo come „analisi degli errori“ sottovaluta il loro valore nei casi critici. Non appena si presenta un incident, un caso di insider o un audit, un log diventa parte della catena probatoria. Proprio qui interviene la integrità dei log: la capacità di dimostrare che i dati di log sono completi e non sono stati modificati successivamente senza essere rilevati. Nella pratica non si tratta tanto di una perfetta immutabilità (che nei sistemi complessi è rara) quanto di evidenza di manomissione: ogni modifica lascia tracce verificabili anche al di fuori del sistema compromesso.

Questo contributo mostra come costruire log firmati, append-only e un'archiviazione verificabile offsite in modo operativo: con prerequisiti chiari, insidie tipiche, passaggi di verifica, un pattern architetturale realizzabile e una strategia di fallback. L'obiettivo non è uno strumento singolo, ma un meccanismo affidabile che potete implementare con componenti esistenti (Syslog/journald, log-forwarder, object storage, backup-repository, SIEM).

Cosa significa davvero «integrità dei log» in esercizio

Nel quotidiano l'integrità viene spesso confusa con il «sola lettura». Per i log questo è riduttivo. Un attaccante non deve necessariamente modificare file; spesso basta fermare le sorgenti di log, filtrare selettivamente o alterare i timestamp. L'integrità dei log è quindi un insieme di tre obiettivi:

• Non alterabilità: singole voci non devono poter essere modificate senza essere rilevate (evidenza di manomissione).
• Completezza: le lacune devono essere rilevabili (p.es. mediante sequenze o catene di hash).
• Dimostrabilità: la prova deve essere possibile al di fuori dell'ambiente compromesso (verifica offsite).

Importante: «append-only» (solo aggiunta) è un modello di scrittura, non una prova di sicurezza. Se un host è compromesso, un attaccante può spesso aggirare comunque l'append-only agendo altrove (riconfigurando forwarder, svuotando code, abusando di credenziali di storage). Perciò servono in aggiunta concatenazione crittografica e un anchor offsite.

Modello di minaccia: da cosa proteggono i log firmati e append-only — e da cosa no?

Un design robusto parte dal modello di minaccia. L'evidenza di manomissione punta tipicamente alle seguenti classi:

• Occultamento post-compromissione: dopo l'infiltrazione si cancellano o alterano tracce per nascondere persistenza e esfiltrazione di dati.
• Manipolazione interna: un amministratore o un fornitore con privilegi altera le tracce di audit.
• Pressione di conformità: è necessario dimostrare in modo verificabile che i log non sono stati „post-elaborati“.

Contro cosa non protegge automaticamente:

• Contenuti falsi: se un'applicazione produce voci di log errate, il vostro sistema le firmerà comunque. L'integrità non è una verifica di veridicità.
• Mancata registrazione: se la sorgente non logga o il logging viene disabilitato, nessuna firma può recuperare quei dati. Potete solo rendere visibili le lacune.
• Perdita completa delle chiavi: se le chiavi di firma e gli anchor di verifica sono compromessi, la prova perde valore. L'architettura delle chiavi è quindi un elemento centrale.

Pattern architetturale: append-only + catena di hash + firma + anchor offsite

Nella pratica si è affermato un pattern a più livelli che funziona indipendentemente da prodotti specifici:

1. Raccolta: i log originano dalle sorgenti (Linux journald/syslog, Windows Event Logs, appliance, API di audit SaaS).
2. Trasporto con buffer: un Forwarder (Agent o Relay) trasporta in modo affidabile, idealmente con coda/backpressure (così, in caso di problemi di rete, i dati non vengono persi).
3. Memorizzazione append-only: un percorso simile a write-once, p.es. object storage con Object Lock (WORM) o uno storage con funzionalità di immutabilità.
4. Prova di integrità: catena di hash (ogni riga/batch contiene l’hash del predecessore) più firme digitali (asimmetriche, p.es. Ed25519/ECDSA/RSA) per finestra temporale/bucket.
5. Offsite-Anchor: un luogo esterno, protetto separatamente, dove si deposita periodicamente un „impronta“ (root-hash/manifest-signature), in modo che una piattaforma di logging compromessa non possa essere riscritta retroattivamente senza essere rilevata.

Termini brevemente contestualizzati: Una catena di hash collega i blocchi di dati in modo crittografico; qualsiasi modifica a un blocco rompe la catena. Una firma digitale utilizza una chiave privata per firmare e una chiave pubblica per la verifica; in questo modo ogni verificatore può accertarne l’autenticità senza possedere diritti di scrittura. Un Offsite-Anchor è un punto di verifica indipendente (altro account, altro provider, supporto offline, tenant di sicurezza separato).

Perché „append-only“ da solo non è sufficiente (e dove è comunque utile)

L’approccio append-only è comunque utile, perché aumenta lo sforzo necessario per la manomissione e riduce le modifiche accidentali. Implementazioni tipiche:

• Flag append-only a livello di filesystem (p.es. su Linux) – utile contro la cancellazione accidentale, ma non resistente in caso di compromissione del root.
• Object storage con Immutability (WORM/Object Lock) – notevolmente più robusto, perché anche gli admin nello stesso account spesso non possono eliminare finché la retention è attiva.
• Supporti write-once (p.es. nastro, export offline) – molto robusti come ultima risorsa, ma più lenti nella ricerca/indicizzazione.

La debolezza principale: se un attaccante ottiene l’accesso abbastanza presto, può tentare, prima che la retention entri in vigore, di impedire l’invio dei dati (bloccare il forwarding) o di deviare i percorsi di scrittura. Perciò è necessario considerare la completezza (lacune) e la verifica offsite.

Log firmati nella pratica: cosa viene esattamente firmato

Molti team non falliscono per la crittografia, ma per la domanda: „Firmiamo ogni riga?“ Questo è raramente necessario e spesso oneroso in esercizio (CPU, overhead, operazioni su chiavi). Si è dimostrato efficace un approccio a batch:

• I log vengono suddivisi in finestre temporali brevi (p.es. 1 minuto o 5 minuti) o finestre per dimensione (p.es. 50–200 MB).

Con ciò si ottiene: la manomissione di un singolo file è rilevabile (l’hash non corrisponde), e la manomissione dell’intera cronologia è anch’essa rilevabile (l’Offsite-Anchor non corrisponde più). Allo stesso tempo la pipeline di log resta performante.

Insidie: la sincronizzazione del tempo come compromissione nascosta dell’integrità

L’integrità dipende fortemente dal tempo. Se i sistemi hanno orari diversi, si generano lacune apparenti o ordini errati. Per gli amministratori è spesso il primo errore che emerge negli audit. Il minimo è disporre di NTP/Chrony/PTP coerenti (servizi di sincronizzazione dell’ora), oltre al monitoraggio del drift. Per prove altamente critiche alcuni team utilizzano inoltre un servizio di timestamp (Trusted Timestamping): conferma crittograficamente che un hash esistesse a un dato istante. Questo è particolarmente utile se si depositano Offsite-Anchor in un sistema esterno e in seguito si deve dimostrare che non sono stati „generati a posteriori“.

Archiviazione verificabile offsite: separare percorso di scrittura, percorso di lettura e verificatore

„Offsite“ non significa solo „altro data center“. In termini di rilevamento delle manomissioni si tratta di indipendenza amministrativa:

• Account/Tenant separato: il logging scrive in uno storage la cui retention è gestita da un account separato di Security o Compliance.
• Chiavi separate: le chiavi di firma non risiedono sui server di log; le chiavi di verifica sono ampiamente distribuite (sola lettura).
• Ruolo verificatore in sola lettura: la verifica deve funzionare senza diritti di modifica, idealmente anche da un sistema isolato (Jump Host/Forensik-VM).

L’obiettivo è un modello di potere asimmetrico: la produzione può fornire, ma non „riscrivere“ retroattivamente. I verificatori possono verificare, ma non manipolare.

Schema di implementazione concreto (indipendente dallo strumento) con struttura di file e manifest

Uno schema praticabile, trasferibile in molti ambienti, lavora con una struttura chiara e prevedibile. Esempio di una struttura giornaliera per sorgente:

/archive/logs/<source>/YYYY/MM/DD/HH/part-000123.log.gz
/archive/logs/<source>/YYYY/MM/DD/HH/manifest-YYYYMMDDHH.json
/archive/logs/<source>/YYYY/MM/DD/HH/manifest-YYYYMMDDHH.sig
/archive/anchors/YYYY/MM/DD/anchor-YYYYMMDDHH.txt

Il Manifest (JSON) contiene gli hash delle parti di log e le informazioni sulla catena. Struttura di esempio:

{
  "source": "vpn-gateway-01",
  "window": {
    "start": "2026-08-09T10:00:00Z",
    "end":   "2026-08-09T11:00:00Z"
  },
  "sequence": {
    "first": 12001,
    "last":  12067
  },
  "prev_manifest_hash": "b5f6...",
  "chunks": [
    {"file": "part-00012001.log.gz", "sha256": "0c1a..."},
    {"file": "part-00012002.log.gz", "sha256": "9f3e..."}
  ],
  "manifest_sha256": "(optional self-hash)"
}

Perché questo funziona: la sequenza rende visibili le lacune, il prev_manifest_hash forma una catena attraverso le finestre temporali, e gli hash dei chunk assicurano i file. Anche se qualcuno sostituisce singoli file, il Manifest non corrisponde più; se sostituisce Manifest e file insieme, deve falsificare la catena di Offsite-Anchor.

Gestione delle chiavi: la causa più comune per cui le firme negli audit risultano inutili

I log firmati dipendono dal modello di chiavi. È essenziale una separazione chiara:

• Chiave di firma (private key): Solo il servizio di signing deve poterla usare. Non dovrebbe risiedere sullo stesso sistema della raccolta dei log. Ideale: HSM (Hardware Security Module) o Cloud-KMS con API di firma; in alternativa un host di signing isolato con accesso rigoroso.
• Chiave di verifica (public key): Può essere distribuita ampiamente (auditor, forensics, validator SIEM), poiché serve solo a verificare.
• Rotazione: Pianificate la rotazione delle chiavi (es. annuale o semestrale) e conservate le vecchie public key per la verifica dei dati storici.

Trappola comune: se lo stesso team di amministrazione può in qualsiasi momento esportare la chiave privata e rieseguire la firma, la prova può essere contestata. Controllate quindi a livello organizzativo: chi ha accesso alla chiave privata, chi gestisce la retention e chi opera l’istanza di verifica?

How-to: Verifica dell’integrità (Runbook) con OpenSSL e liste di hash

Avete bisogno di almeno due prove verificabili: (1) verifica della firma del manifesto e (2) verifica degli hash dei chunk. La procedura seguente è generica e funziona per molti formati di firma (qui a titolo di esempio: l’hash del manifesto è stato firmato con una chiave privata, la verifica avviene con la public key).

1) Verificare la firma

# Dateien
MANIFEST="manifest-2026080910.json"
SIG="manifest-2026080910.sig"
PUBKEY="log-signing-public.pem"

# Prüfen (Beispiel RSA/ECDSA über SHA256)
openssl dgst -sha256 -verify "$PUBKEY" -signature "$SIG" "$MANIFEST"

Erwartung: „Verified OK“. Wenn nicht, ist entweder das Manifest verändert, die falsche Public-Key-Version im Einsatz oder das Signaturverfahren passt nicht zum Key. Genau diese Fehler sollten Sie im Betrieb dokumentieren (Key-ID, Algorithmus, Gültigkeitszeiträume).

2) Chunk-Hashes prüfen

Estraete la lista degli hash dal manifest (es. con jq) e verificate i file. Esempio:

# Hashliste aus Manifest erzeugen: <sha256>  <filename>
jq -r '.chunks[] | "(.sha256)  (.file)"' "$MANIFEST" > checksums.sha256

# Prüfen
sha256sum -c checksums.sha256

Se singoli file mancano o gli hash non corrispondono, l’integrità è compromessa o la struttura dell’archivio non è più coerente. In quel caso dovete verificare anche se si tratta di un problema di trasporto/retention (es. perdita nella coda) o di manipolazione (es. cancellazione selettiva).

Troubleshooting: Typische Ursachen für Lücken und Integritätsfehler

1) Queue/Backpressure nicht sauber gelöst

Molte frecce di log sembrano a posto nel diagramma, ma si interrompono durante i picchi di carico: il Forwarder scarta eventi o blocca applicazioni. Prestate attenzione a code di persistenza reali (disk-backed) e a limiti chiari. Segnali di allarme sono „dropped messages“, „queue full“, „retry storm“.

Passi di verifica:

• Metriche del Forwarder: Drop-Count, Retry-Count, livello di riempimento della coda.
• Latenza dello storage: se l’Object-Storage/indice è lento, il Forwarder deve poter bufferizzare.
• Capacità: volume di log al giorno, crescita, Retention.

2) Rotation/Kompression kollidiert mit Signaturfenstern

Se firmate i file prima e poi li modificate successivamente con rotazione/compressione (ad es. gzip a posteriori), la verifica della firma fallirà prevedibilmente. Regola: firmate il formato finale, non gli stati intermedi. Oppure: prima normalizzare/comprimere, poi calcolare l’hash e firmare. Oppure: firmate lo stream grezzo, ma archiviate esattamente quello stream grezzo invariato.

3) Zeitdrift und DST/Timezone-Mischung

Se una parte dell’infrastruttura usa orario locale (CET/CEST) e altre UTC, si generano „ore mancanti“ o finestre duplicate. Operativamente UTC è la scelta più robusta per i percorsi di archivio. Tenete le conversioni di fuso orario fuori dalla pipeline di log: conservate in UTC, presentate/ correlate negli strumenti secondo necessità.

4) Berechtigungen: Das Logging kann löschen, obwohl es nicht sollte

Un errore di progettazione comune è che il Log-Writer abbia anche diritti di Delete perché è „più semplice“. Per l’evidenza di manomissione è dannoso. Meglio: Write-only (Put), opzionale List per diagnostica, ma nessun Delete. La Retention deve essere gestita tramite un percorso amministrativo separato.

Checkliste: Mindestanforderungen für manipulationssichere Log-Archivierung

• QuellenaBDEckung: Quali sistemi forniscono audit-logs (AD, VPN, Firewall, IAM, Cloud Control Plane, Datenbanken, Business-Software, Admin-Portale)?
• Zeitkonsistenz: NTP/Chrony attivi, monitoraggio della deriva, UTC nell’archivio.
• Transport: TLS garantito, coda persistente, strategia di Retry definita.
• Append-only Storage: Object Lock/WORM o immutabilità equivalente, Retention documentata.
• Integritätslayer: catena di hash + manifest firmato per finestra temporale/bucket.
• Offsite-Anchor: Root-Hash/firmatura del manifest in tenant/account separato o offline.
• Schlüsselmodell: Private Key isolata, rotation pianificata, conservare le vecchie Public Keys.
• Verifikation: passi di verifica ripetibili (Runbook), campionamenti automatizzati.
• Alarmierung: lacune, errori di firma, sovraccarico della coda, modifiche alla Retention.

Umsetzung in Etappen: So kommen Sie ohne Big-Bang ans Ziel

In ambienti esistenti un Big-Bang raramente è sensato. Un approccio graduale riduce il rischio e facilita l’adozione:

Etappe 1: Offsite-Archiv + Immutability

Assicuratevi di estrarre i log in modo affidabile dal dominio di produzione, compresa la retention. Questa è la base per evitare lo scenario „server gone, logs gone“ e per contrastare i ransomware che cifrano i log server locali. Utilizzate inizialmente la pipeline di log esistente, ma rafforzate storage e permessi.

Tappa 2: Manifest + hash

Generate per finestra temporale un manifest con hash. Non è ancora una firma, ma rende possibili controlli di consistenza e vi costringe a definire i confini dei file e le finestre.

Tappa 3: Firme e ancoraggio offsite

Aggiungete firme e ancorate gli hash offsite. Da questo punto diventa a prova di audit, se la gestione delle chiavi e i ruoli sono separati in modo chiaro.

Tappa 4: Verifica automatizzata e integrazione con gli incident

Automatizzate controlli a campione (es. 10 finestre casuali al giorno) e integrate gli errori di verifica come classe di incidente (runbook, ownership, SLA). L’evidenza di manomissione ha valore solo se gli indicatori di manipolazione vengono gestiti operativamente.

Strategia di fallback: cosa fare se la verifica della firma fallisce?

Un errore di verifica non è automaticamente un „attacco“. Spesso si tratta di errori operativi. Tuttavia dovRESTe procedere come per un evento di sicurezza, con un’escalation pragmatica:

1. Determinare l’ambito: Riguarda una finestra, una sorgente o tutte? Correlazione con deployment/modifiche (aggiornamento del forwarder, policy di storage).
2. Isolare la causa: Manca un file (trasporto), non corrisponde un hash (modifica/bitrot/errore di processo), è valida solo la firma non corretta (chiave/algoritmo/formato)?
3. Verificare l’ancoraggio offsite: I hash ancorati esternamente corrispondono? Se sì, il sistema offsite è probabilmente integro; se no, procedete con un’escalation più severa.
4. Verificare lo stato delle sorgenti: Le sorgenti hanno continuato a scrivere log? Ci sono metriche di drop, overflow delle code, disco pieno?
5. Preservazione forense: Conservate gli artefatti interessati (manifest, firma, chunk coinvolti, metadati) in sola lettura, prima di „riparare“.
6. Ripristino: Se si tratta di un errore operativo, ricostruite preferibilmente dalle sorgenti originali o da percorsi di log secondari (es. SIEM-ingest, syslog-relay).

Importante: evitate di „rifirmare per far tornare tutto verde“. Questo è esattamente il comportamento che rende gli audit sospettosi. Se è necessaria una correzione, deve rimanere visibile come correzione (nuova finestra, nuova firma, motivo documentato).

Best Practices per il funzionamento di WordPress e dei portali di amministrazione: dove l’evidenza di manomissione aiuta particolarmente

In ambienti vicini a WordPress (portali admin, sistemi di redazione, API per login/SSO, plugin, reverse-proxy) la situazione dei log è spesso eterogenea. Fonti tipiche su cui dovRESTe concentrare l’integrità:

• Webserver/Proxy: accessi, errori, decisioni della WAF (importante per brute-force, tentativi di exploit, percorsi insoliti).
• Auth/SSO: log dell’IdP (login, MFA, emissione token), in particolare per utenti privilegiati.
• Eventi di audit di WordPress: azioni admin (installazione plugin, modifiche ai temi, ruoli utente, API key), se disponibili.
• Database: login admin, query privilegiate (a seconda del setup DB e delle policy).
• Sistema: sudo/SSH, installazioni di pacchetti, riavvii dei servizi, cron/systemd timer.

Consiglio pratico: adottate in queste aree due prospettive: (1) applicazioni-/weblogs e (2) infrastruttura-/identity-logs. Un aggressore può influenzare più facilmente una prospettiva che entrambe. Tamper-Evidence vi aiuta allora a dimostrare quale prospettiva è rimasta coerente.

Verifica offsite: come testare regolarmente se la vostra prova è veramente indipendente

La verifica offsite è credibile solo se la testate. Un esercitazione semplice e ripetibile (mensile o trimestrale) si svolge così:

1. Selezionate un intervallo temporale (p.es. un’ora) e una fonte critica.
2. Scaricate i file di archivio esclusivamente in sola lettura dallo storage offsite.
3. Verificate la firma del manifesto e gli hash dei chunk come sopra.
4. Controllate l’ancoraggio offsite (p.es. Root-Hash) confrontandolo con il vostro archivio indipendente.
5. Documentate risultato, Key-ID, strumenti utilizzati e hash in un report di verifica.

Se questo sembra troppo manuale: automatizzate i passaggi, ma mantenete almeno un’esercitazione manuale in cui un operatore senza conoscenze specialistiche esegue rigidamente il Runbook. Questo si rivela inestimabile in caso di emergenza.

Conclusione: Tamper-Evidence è un processo operativo, non una feature

Log firmati, append-only, con archiviazione verificabile offsite non sono un lusso, ma una risposta robusta a una questione operativa reale: «Possiamo ancora fidarci dei nostri log se qualcosa va storto?» La chiave è un design multilivello: archiviazione append-only, catene di hash e manifesti firmati per il rilevamento di manipolazioni, più un ancoraggio offsite indipendente dal dominio di produzione. Se a questo aggiungete stabilità delle code, coerenza temporale, una gestione delle chiavi pulita e una strategia di fallback, otterrete non solo migliore auditabilità, ma anche maggiore sicurezza nella risposta agli incidenti e nelle analisi forensi.

Nel lavoro quotidiano ciò si ripaga soprattutto se operationalizzate la verifica di integrità: controlli a campione, allarmi in caso di lacune, responsabilità chiare e un Runbook che funzioni anche alle 03:00. Allora l’integrità dei log non è solo una promessa, ma uno stato verificabile.