Inalterabilità dei log AdS: cosa chiede il Garante

Quando si parla di log degli Amministratori di Sistema, alcune interpretazioni sembrano trasformare un adempimento organizzativo in un'indagine di informatica forense. Catene di hash interminabili, storage WORM presentati come obbligatori, architetture da laboratorio investigativo, firme applicate a ogni singolo evento, sistemi nei quali neppure il titolare dovrebbe poter intervenire: tutto viene descritto come indispensabile per rispettare il Provvedimento del Garante.

Ma il Provvedimento chiede davvero questo? No. La sua finalità è molto più concreta: permettere al titolare del trattamento di controllare l'operato di chi dispone dei massimi privilegi sui sistemi informatici.

Il problema che la norma vuole risolvere non è costituire una prova giudiziaria. È evitare che l'Amministratore di Sistema resti l'unico custode delle proprie tracce: capace di amministrare sistemi, credenziali, dati, backup e anche le sole registrazioni che dovrebbero documentarne gli accessi. Il principio corretto è la separazione del controllo: l'amministratore opera sui sistemi, una piattaforma indipendente ne raccoglie gli accessi, l'amministratore controllato non può modificare le registrazioni, il titolare le consulta e verifica, il controllo viene documentato e i file sono conservati in sicurezza.

PrivacyLog nasce da questo approccio: applicare le prescrizioni con metodo ingegneristico, senza costruire sovrastrutture inutili e senza confondere la conformità con la digital forensics.

Che cosa chiede realmente il Garante

Il Provvedimento stabilisce che l'operato degli Amministratori di Sistema sia verificato almeno annualmente dal titolare o dal responsabile, e richiede sistemi idonei a registrare gli accessi logici, prescrivendo che gli access log siano completi, inalterabili, verificabili nella loro integrità, adeguati allo scopo della verifica e conservati per almeno sei mesi.

Il punto decisivo è l'ultima caratteristica: le proprietà dei log devono essere adeguate allo scopo per cui sono richiesti. E lo scopo non è creare preventivamente una prova forense per un eventuale procedimento giudiziario: è consentire al titolare di verificare che gli amministratori abbiano operato in modo coerente con mansioni, autorizzazioni e misure di sicurezza. Lo stesso Garante precisa che il Provvedimento richiede una forma minima di documentazione dell'uso del sistema — la registrazione degli accessi, conservata per almeno sei mesi in condizioni di ragionevole sicurezza — e aggiunge espressamente di non voler instaurare un regime generalizzato di registrazione di tutti gli usage data dei sistemi informativi.

Per il dettaglio completo di questi obblighi rimandiamo a Log degli Amministratori di Sistema: cosa impone il Garante Privacy.

Il destinatario dei log è il titolare, non l'Autorità

Uno degli errori interpretativi più comuni è progettare l'intero sistema immaginando come destinatario naturale il Garante, un giudice o un consulente forense. Il destinatario ordinario dei log è invece il titolare del trattamento: è lui che deve individuare gli amministratori, definirne gli ambiti operativi, controllare gli account privilegiati, verificare gli accessi, individuare le anomalie, chiedere chiarimenti, adottare misure correttive e documentare la verifica.

L'Autorità di controllo può successivamente verificare che il titolare abbia realmente adottato la misura, ma questo non trasforma ogni access log in un reperto da processo penale. In caso di accertamento, il titolare dovrebbe poter dimostrare chi sono gli amministratori, quali funzioni sono state loro attribuite, quali sistemi sono registrati, come i log vengono raccolti e protetti, che gli amministratori controllati non possono modificarli, che la verifica annuale è stata effettuata e con quali esiti. Questo è accountability: adottare misure adeguate e poter dimostrare di averlo fatto. Il GDPR non prescrive soluzioni massimaliste, ma misure proporzionate al contesto, ai rischi, allo stato dell'arte e ai costi di attuazione.

Sette interpretazioni da ridimensionare

1. "Serve una catena di custodia"

Una catena di custodia formalizzata è fondamentale quando un'evidenza deve essere acquisita e analizzata in un'indagine giudiziaria delicata. Ma il Provvedimento non impone che ogni log aziendale sia gestito fin dall'origine come un reperto. La verifica ordinaria deve accertare che gli accessi siano registrati, che le registrazioni siano complete rispetto al perimetro, che gli amministratori non possano alterarle, che il titolare possa verificarle e che i dati siano conservati per almeno sei mesi. Se da un controllo emergesse un incidente o un illecito, da quel momento potrebbero diventare necessarie procedure più rigorose. Applicare preventivamente a ogni PMI un modello da laboratorio investigativo significa confondere il controllo ordinario con l'acquisizione probatoria in presenza di un caso concreto.

2. "Senza WORM il log non è inalterabile"

Il Garante cita i supporti non riscrivibili come una delle possibili soluzioni, soprattutto nei casi semplici — non come unica tecnologia ammessa. Nelle situazioni complesse richiama anche log server centralizzati e sistemi più sofisticati, lasciando al titolare la scelta. Lo storage WORM impedisce la sovrascrittura, ma non è una formula magica: un file incompleto scritto su WORM resta incompleto, un evento mai generato non appare, un timestamp errato non si corregge. Il requisito di inalterabilità può essere soddisfatto anche con un diverso modello: i log trasferiti fuori dal sistema amministrato, un repository gestito da una piattaforma indipendente su cui l'amministratore controllato non ha privilegi, file firmati o marcati temporalmente, e copie verificabili conservate dal titolare. In questa configurazione il WORM è una protezione aggiuntiva, non il fondamento dell'adempimento.

3. "L'hash rende automaticamente il log conforme"

L'hash calcola un'impronta del file e permette di rilevare variazioni successive. Ma un hash isolato non basta: se qualcuno può modificare sia il file sia il digest, cambia il file, ricalcola l'hash e sostituisce il precedente. L'hash diventa significativo quando è inserito in un processo affidabile, firma elettronica, sigillo, marca temporale, conservazione su un sistema indipendente, protezione del digest. L'utente finale non dovrebbe dover gestire manualmente catene di hash e manifest, salvo che rischio e contesto lo richiedano: questi meccanismi possono operare internamente alla piattaforma senza trasformare l'adempimento in un corso di crittografia applicata.

4. "Bisogna registrare ogni comando dell'amministratore"

Il Provvedimento richiede gli access log, accesso, tentativo di accesso, disconnessione, e non introduce un obbligo generale di registrare ogni comando, file consultato o attività svolta durante la sessione. Il Garante distingue chiaramente la documentazione minima degli accessi da un regime rigoroso di registrazione degli usage data, e afferma che quest'ultimo non è l'obiettivo del Provvedimento. Un'organizzazione può decidere di registrare anche comandi privilegiati, modifiche agli utenti o accessi ai file, ma è una scelta ulteriore, legata a finalità di cybersecurity o incident response, non un obbligo automatico. Anzi, una raccolta eccessiva introduce nuovi problemi: più dati personali trattati, controllo più invasivo dei lavoratori, costi e complessità maggiori, e la difficoltà di individuare gli eventi realmente importanti. Un buon sistema non registra tutto ciò che tecnicamente può, ma ciò che serve rispetto alla finalità dichiarata.

5. "Il titolare non deve poter accedere ai log"

Questa interpretazione rovescia lo scopo della misura. I log esistono proprio perché il titolare possa controllare l'operato degli amministratori. Il soggetto da separare dal repository è innanzitutto l'amministratore controllato, non il titolare che deve svolgere la verifica. Il modello corretto attribuisce ruoli diversi: l'amministratore gestisce i sistemi, la piattaforma indipendente raccoglie e protegge i log, il titolare vi accede per la verifica, il fornitore gestisce tecnicamente il servizio secondo le istruzioni ricevute, e gli accessi alla piattaforma sono a loro volta controllati. Rendere i log indisponibili proprio a chi deve usarli per il controllo non avrebbe senso.

6. "Una firma o una marca temporale non bastano mai"

Dipende dal problema da risolvere. Se un file prodotto da una piattaforma indipendente viene firmato o marcato temporalmente, qualsiasi modifica successiva diventa rilevabile con una verifica crittografica. Una marca temporale conforme al protocollo RFC 3161 collega l'impronta del dato a un riferimento temporale prodotto da una Time Stamping Authority; una validazione temporale qualificata gode inoltre, ai sensi di eIDAS, della presunzione di accuratezza di data e ora e di integrità dei dati associati. Questo non certifica la verità storica di ogni evento, ma qualcosa di più utile per il controllo: il file verificato coincide con quello prodotto e marcato in quel momento, e una modifica successiva sarebbe rilevabile. Per lo scopo ordinario del Provvedimento è una soluzione concreta e coerente — non serve immaginare che ogni PMI gestisca una blockchain privata dei propri login amministrativi.

7. "Integrità e conservazione sono la stessa cosa"

Sono due problemi distinti. L'integrità riguarda la capacità di verificare che il file non sia stato modificato, e si protegge con firma, sigillo, marca temporale, hash protetti e controlli di accesso. La disponibilità riguarda la capacità di recuperare il file per tutto il periodo previsto, e si garantisce con backup, copie multiple, replica e verifiche di ripristino. Tre copie di un file alterato non lo rendono integro; un file perfettamente firmato ma conservato in un'unica copia e poi perso non è disponibile. Firma e marca temporale proteggono la verificabilità dell'integrità; backup e replica proteggono la disponibilità. Per i log valgono le normali pratiche di archiviazione sicura, senza inventare una nuova disciplina solo perché il file contiene access log.

Più complessità non significa più conformità

Il GDPR si fonda su adeguatezza e proporzionalità: le misure devono tenere conto di rischio, stato dell'arte, contesto e costi, ed essere efficaci, verificabili e periodicamente riesaminate. Una soluzione molto complessa può risultare meno efficace se nessuno sa configurarla, se gli alert non vengono letti, se i report sono incomprensibili, se la mole di dati nasconde gli eventi importanti, se i costi inducono ad abbandonare il processo o se la verifica annuale resta una procedura solo formale. L'ingegneria non consiste nell'aggiungere componenti fino a rendere il sistema incomprensibile, ma nel raggiungere un obiettivo definito con misure efficaci, verificabili, sostenibili, proporzionate e comprensibili da chi deve usarle.

Che cosa deve dimostrare concretamente il titolare

In caso di controllo, il titolare non dovrebbe presentare un enorme archivio di file dicendo "ecco i log", ma un processo coerente:

• Individuazione degli amministratori — un elenco aggiornato delle persone fisiche, inclusi i tecnici dei fornitori esterni;
• Ambiti di operatività — quali sistemi o aree sono affidati a ciascuno;
• Sistema di raccolta — come gli accessi vengono acquisiti, trasferiti e conservati;
• Separazione dei ruoli — la prova che gli amministratori controllati non possano modificare le registrazioni centralizzate;
• File verificabili — report o archivi accompagnati dagli elementi per verificarne l'integrità;
• Conservazione — dati disponibili per almeno sei mesi e protetti;
• Verifica annuale — la dimostrazione che gli accessi sono stati effettivamente analizzati;
• Verbale o relazione — che documenti periodo, persone, sistemi, criteri, evidenze, anomalie, esiti e azioni correttive.

Il Provvedimento non prescrive un modello di verbale, ma una relazione scritta è il modo più lineare per dimostrare che la verifica non si è limitata alla raccolta dei log. Su come strutturarla, vedi Verifica annuale degli Amministratori di Sistema, che include un modello di verbale scaricabile. Il fascicolo dell'adempimento può quindi comporsi di: elenco degli amministratori, descrizione del sistema di raccolta, log verificabili, verbale della verifica ed eventuali azioni correttive.

Il modello di PrivacyLog

PrivacyLog è stato progettato da informatici e ingegneri che operano anche nei settori della privacy e del GDPR. L'obiettivo non era costruire un altro SIEM, né un sistema di sorveglianza generalizzata, né un laboratorio forense, ma applicare in modo concreto le prescrizioni del Garante: individuare gli eventi da registrare, raccoglierli dai sistemi interessati, sottrarli al controllo degli amministratori verificati, trasferirli verso una piattaforma indipendente, renderli disponibili al titolare, produrre file di cui sia verificabile l'integrità, conservarli per il periodo stabilito e supportare la verifica annuale con la verbalizzazione degli esiti.

La configurazione standard è deliberatamente limitata agli accessi amministrativi richiesti per la finalità di controllo; eventuali funzioni di sicurezza ulteriori restano distinte e attivabili solo quando esiste una finalità specifica. Questo evita due errori opposti: una soluzione troppo debole, in cui l'amministratore conserva e controlla i propri log, e una soluzione sproporzionata, che trasforma ogni accesso in un'indagine forense preventiva.

Perché una piattaforma indipendente cambia il modello di rischio

Quando i log restano solo sul server amministrato, l'amministratore può spesso cancellarli, ridurne la retention, modificare la configurazione, disattivare il servizio o alterare le sole evidenze disponibili. Quando invece gli eventi vengono trasferiti a una piattaforma indipendente, l'amministratore perde il controllo sul repository, il titolare conserva la capacità di verifica, il fornitore applica misure dedicate, i file possono essere firmati o marcati e le copie archiviate separatamente. È questa separazione, prima ancora dell'accumulo di tecnologie, a ridurre il rischio organizzativo fondamentale: l'amministratore continua ad avere i privilegi per lavorare, ma non possiede più il potere esclusivo di cancellare la memoria dei propri accessi.

Conformità non significa immobilità

Una misura di sicurezza deve essere applicabile nella vita reale. Se per estrarre un report servono un consulente forense, un notaio, un HSM dedicato, quattro firme, tre procedure manuali e due settimane di lavoro, la probabilità che una PMI effettui davvero la verifica annuale crolla. Una procedura semplice, automatizzata e comprensibile ha molte più possibilità di essere utilizzata, controllata, ripetuta, documentata e migliorata nel tempo. L'obiettivo non è far apparire il processo sofisticato, ma fare in modo che il titolare controlli realmente gli accessi degli amministratori e possa dimostrarlo.

Conclusioni: meno formalismo, più controllo effettivo

Il Provvedimento sugli Amministratori di Sistema non richiede una piattaforma forense universale. Richiede che il titolare sappia chi amministra i sistemi, definisca cosa può amministrare, registri gli accessi, sottragga le registrazioni al controllo esclusivo degli amministratori, ne protegga integrità e disponibilità, conservi i dati per almeno sei mesi, verifichi almeno annualmente l'operato e documenti il controllo.

WORM, catene di hash, firme, marche temporali e strumenti forensi sono tecnologie utili in contesti diversi, ma non vanno trasformate in requisiti universali che il Provvedimento non contiene. Una piattaforma indipendente, log non modificabili dagli amministratori controllati, file firmati o marcati, backup sicuri e una verifica annuale verbalizzata costituiscono un modello lineare e coerente con la finalità della norma. La domanda giusta non è "abbiamo costruito il sistema crittograficamente più complesso possibile?", ma "il titolare può controllare l'operato degli Amministratori di Sistema e dimostrare di averlo fatto con registrazioni attendibili?". Se la risposta è sì, il sistema sta facendo il lavoro per cui è stato progettato.

Domande frequenti

Il Provvedimento impone obbligatoriamente uno storage WORM?

No. Il Garante menziona i supporti non riscrivibili come una possibile soluzione e contempla anche software di sistema, esportazioni periodiche e log server centralizzati, secondo la complessità del contesto.

I log devono essere trattati come reperti forensi?

Non ordinariamente. Devono essere completi, inalterabili, verificabili e adeguati allo scopo del controllo. Procedure forensi più rigorose possono diventare necessarie quando emerge uno specifico incidente o contenzioso.

Una marca temporale rende il file inalterabile?

Rende rilevabili le modifiche successive al file marcato. Una validazione temporale qualificata gode inoltre della presunzione di accuratezza di data e ora e di integrità dei dati associati.

Il titolare può consultare i log?

Sì. I log sono raccolti proprio per consentire al titolare o al responsabile di verificare l'operato degli Amministratori di Sistema.

È sufficiente conservare i log senza analizzarli?

No. Il Provvedimento richiede una verifica almeno annuale dell'operato. La sola presenza dei file non dimostra che il controllo sia stato eseguito.

Bisogna registrare tutti i comandi eseguiti?

No. Il Provvedimento richiede come misura minima gli eventi di accesso, tentativo di accesso e disconnessione, senza un regime generalizzato di registrazione di tutte le attività.

Il contenuto esprime un'interpretazione tecnico-organizzativa del Provvedimento e ha finalità informativa. Le misure vanno valutate rispetto al contesto, ai rischi e all'architettura effettivamente adottata.