CYBSicurezza informatica

Sherlock Holmes e i file di log: quanto conservarli e dove, per ricostruire un attacco

Dopo un incidente le domande sono sempre le stesse: chi è entrato, quando, da dove, che cosa ha toccato. Rispondono i file di log, se esistono ancora. Quali raccogliere, quanto tenerli e dove.

Redazione Strategic 28 marzo 2026 Aggiornato il 16 settembre 2026 8 min di lettura

Sherlock Holmes e i file di log: quanto conservarli e dove, per ricostruire un attacco

Senza file di log un attacco informatico non si ricostruisce: non si sa chi è entrato, quando, da dove e che cosa ha toccato. Perché i log servano il giorno dell’incidente devono avere tre caratteristiche: essere raccolti sui sistemi che contano, essere conservati abbastanza a lungo e lontano dai server che descrivono, ed essere letti da qualcuno prima che sia tardi. Quanto a lungo tenerli non lo decide un numero valido per tutti: lo decidono il rischio, le norme applicabili e le regole sulla riservatezza dei dipendenti.

Che cosa c’entra Sherlock Holmes?

Davanti a un furto, Sherlock Holmes non chiedeva subito chi fosse il colpevole. Chiedeva di vedere la serratura, la finestra, le impronte sul pavimento. Nei sistemi informatici le impronte si chiamano log: registri, spesso noiosi e voluminosi, in cui ogni sistema annota ciò che accade. Un accesso riuscito, una password sbagliata, un file scaricato, una regola del firewall che blocca un collegamento.

Il guaio è che molte aziende scoprono di non averli proprio quando servono: la scena del delitto è già stata ripulita con l’aspirapolvere.

Che cosa racconta un file di log?

Un log è una riga con data, ora, sistema, utente e azione. Da sola dice poco; in fila con le altre racconta una storia e risponde alle domande di direzione, legali e autorità:

da dove è entrato l’attaccante: una connessione remota, una casella di posta, un’applicazione esposta;
quando è successo: il primo accesso anomalo, non il giorno in cui qualcuno si è accorto del problema;
che cosa ha toccato: quali cartelle, quali database, quali account;
se è ancora dentro: accessi recenti con credenziali rubate o strumenti lasciati sui server.

Per un’azienda soggetta alla NIS2 queste risposte non sono una curiosità. La direttiva chiede, entro un mese dalla notifica di un incidente significativo, una relazione finale con la descrizione dettagliata dell’accaduto, il tipo di minaccia o la causa di fondo e le misure adottate. Senza log, quella relazione diventa un esercizio di ipotesi.

Perché dopo un attacco i log spesso mancano?

I motivi ricorrono quasi sempre, e nessuno è un problema di costi.

La conservazione predefinita è breve. Molti sistemi tengono i registri per pochi giorni o poche settimane, oppure fino a una certa dimensione, e poi li sovrascrivono. È un’impostazione pensata per non riempire i dischi, non per le indagini.

Gli attacchi vengono scoperti tardi. Secondo il rapporto M-Trends 2026 di Mandiant, pubblicato a marzo 2026, nel 2025 il tempo mediano tra l’ingresso di un attaccante e la sua scoperta è stato di 14 giorni a livello globale, e di 25 giorni quando a dare l’allarme è stato qualcuno esterno all’azienda. Se i log durano una settimana, l’inizio della storia è già stato cancellato.

I log stanno sullo stesso server che descrivono. Chi ottiene i privilegi di amministratore può modificarli o cancellarli, ed è una delle prime cose che fa un attaccante attento.

Non sono attivi dove servirebbero. Accessi remoti non registrati, servizi in cloud con la registrazione dettagliata mai accesa, orologi dei server non sincronizzati che rendono impossibile mettere in fila gli eventi.

Quanto tempo vanno conservati?

Non esiste un periodo unico, ma ci sono riferimenti chiari da cui partire.

Soggetti NIS in Italia. Le misure di base stabilite dall’Agenzia per la Cybersicurezza Nazionale (Determinazione ACN n. 379907/2025, misura PR.PS-04) chiedono di registrare tutti gli accessi remoti e quelli con utenze amministrative, di conservare in modo sicuro, e possibilmente centralizzato, i log necessari al monitoraggio degli eventi di sicurezza e di definire per iscritto i tempi di conservazione in base alla valutazione del rischio.
Amministratori di sistema. Il provvedimento del Garante per la protezione dei dati personali del 27 novembre 2008 chiede di registrare gli accessi logici degli amministratori di sistema e di conservare quelle registrazioni, complete e inalterabili, per un periodo congruo non inferiore a sei mesi.
Posta elettronica dei dipendenti. Per i metadati della posta raccolti per far funzionare il servizio, il documento di indirizzo del Garante del 6 giugno 2024 indica, a titolo orientativo, una conservazione che non dovrebbe superare i 21 giorni. Periodi più lunghi vanno motivati e, oltre certi limiti, richiedono le garanzie previste dall’articolo 4 dello Statuto dei lavoratori.

Il punto di equilibrio si trova mettendo allo stesso tavolo IT, DPO e, dove serve, il legale del lavoro: i log di sicurezza servono per mesi, ma contengono dati personali e non possono diventare uno strumento di controllo dei dipendenti. Il risultato va scritto in una politica di conservazione, con i tempi per ciascun tipo di registro e le persone che possono consultarli. Per le imprese sammarinesi il quadro è diverso e va valutato caso per caso.

Dove vanno tenuti?

La regola è semplice: lontano dal sistema che descrivono. I log vanno inviati, mentre vengono prodotti, a una raccolta centralizzata a cui gli amministratori dei singoli server non possono accedere in scrittura. Una buona raccolta ha alcune caratteristiche riconoscibili:

conserva i dati in una forma che non si può modificare né cancellare prima della scadenza stabilita;
ha accessi separati e registrati a loro volta;
riceve l’ora da una fonte comune, così gli eventi di sistemi diversi si possono mettere in fila;
è dimensionata per il periodo deciso, con un controllo che segnala quando una fonte smette di inviare dati.

Le linee guida sulla registrazione degli eventi pubblicate nel 2024 dall’agenzia australiana per la sicurezza informatica con CISA, FBI, NSA e altri partner internazionali insistono proprio su questi punti: archiviazione protetta, raccolta tempestiva e centralizzata, formati coerenti.

Quali log raccogliere per primi?

Raccogliere tutto subito è costoso e poco utile. Conviene partire dalle fonti che rispondono alle domande più frequenti dopo un incidente.

Fonte	Che cosa dice	Perché serve
Accessi remoti (VPN, desktop remoto)	chi si collega dall’esterno, da dove, a che ora	è una delle porte d’ingresso più usate
Autenticazioni e directory aziendale	accessi riusciti e falliti, nuovi account, cambi di privilegi	mostra l’uso di credenziali rubate
Posta elettronica	accessi alle caselle, regole di inoltro create	rivela caselle compromesse e furti di informazioni
Firewall e sistemi perimetrali	collegamenti bloccati e consentiti	ricostruisce da dove arriva e dove va il traffico
Server e database critici	accessi amministrativi, esportazioni, modifiche	dice che cosa è stato toccato
Protezione dei computer (EDR)	programmi sospetti, comportamenti anomali	collega l’evento alla postazione di partenza
Servizi in cloud	accessi alla console, chiavi create, condivisioni	copre ciò che non passa dalla rete aziendale

Chi li legge?

Raccogliere non significa sorvegliare. Un archivio che nessuno consulta serve solo dopo, per l’indagine; un archivio con pochi allarmi ben scelti può fermare un attacco mentre è in corso. Gli eventi da cui partire sono pochi: molti accessi falliti seguiti da uno riuscito, un accesso da un Paese dove l’azienda non opera, un nuovo account amministrativo, la disattivazione di una protezione, un’esportazione insolita di dati.

Per ogni allarme serve una risposta scritta a due domande: chi lo riceve e che cosa fa. Di solito se ne occupa l’IT interno, con una revisione periodica degli allarmi e delle regole. L’importante è che l’avviso non finisca in una casella che nessuno apre: anche il collegamento di un falso supporto tecnico lascia tracce che qualcuno deve notare. E i log non sostituiscono le protezioni sui computer, di cui parla l’articolo sull’antivirus.

E gli assistenti di intelligenza artificiale?

Valgono le stesse regole. Un assistente AI collegato a posta, documenti o gestionale deve lasciare un registro consultabile: chi ha chiesto che cosa, quali documenti ha letto, quali azioni ha proposto o eseguito. Senza quel registro è impossibile capire se un’informazione riservata è uscita o se il sistema ha eseguito istruzioni nascoste in un documento. È uno dei controlli previsti nei progetti di sicurezza e governance dell’intelligenza artificiale.

In sintesi

I log sono le impronte di un attacco: senza, non si sa chi è entrato, quando e che cosa ha toccato.
La conservazione predefinita dura spesso pochi giorni o settimane, mentre gli attacchi vengono scoperti dopo settimane.
Per i soggetti NIS le misure ACN chiedono di registrare accessi remoti e amministrativi e di fissare per iscritto i tempi di conservazione.
Gli accessi degli amministratori di sistema si conservano per almeno sei mesi, secondo il Garante.
I log vanno tenuti lontano dai server che descrivono, in una raccolta protetta e con l’ora sincronizzata.
Tempi e usi si decidono con il DPO: i log di sicurezza non devono diventare controllo dei dipendenti.
Pochi allarmi ben scelti, con un responsabile, valgono più di un archivio che nessuno legge.

Domande frequenti

Per quanto tempo bisogna conservare i log di sicurezza?

Non c’è un periodo unico. Per gli accessi degli amministratori di sistema il Garante indica almeno sei mesi; i soggetti NIS devono fissare i tempi in base alla valutazione del rischio; per i metadati della posta dei dipendenti il Garante suggerisce periodi brevi. La scelta va documentata in una politica di conservazione decisa con IT e DPO.

Basta attivare i log sui server?

No. Se restano sullo stesso server, chi lo compromette può cancellarli. Vanno inviati a una raccolta separata, protetta da modifiche e con accessi distinti da quelli dei sistemi che descrivono.

Raccogliere i log significa controllare i dipendenti?

Non deve significarlo. I log di sicurezza servono a proteggere sistemi e dati; il loro uso va limitato a questo scopo, con accessi ristretti e tempi proporzionati. Quando registrano attività dei dipendenti entrano in gioco anche le regole sul controllo a distanza: conviene decidere con il DPO e con il legale del lavoro.

Da quali log conviene partire?

Dagli accessi remoti, dalle autenticazioni, dalla posta elettronica, dai firewall e dai sistemi critici. Sono le fonti che rispondono alle domande più frequenti dopo un incidente: da dove è entrato l’attaccante e con quali credenziali.

Chi deve leggere gli allarmi?

Una persona o un gruppo con un compito scritto: chi riceve l’avviso, entro quando lo guarda, che cosa fa. Può essere l’IT interno o un servizio esterno; ciò che conta è che l’allarme non resti senza risposta.

Una buona configurazione dei log fa la differenza tra «sappiamo che cosa è successo» e «possiamo solo supporlo». La divisione Cybersecurity di Strategic aiuta a scegliere le fonti da raccogliere, a definire i tempi di conservazione con il DPO e a impostare la gestione degli incidenti, così che il giorno in cui servono le prove ci siano.

Fonti

ApprofondisciCybersecurityVerifiche fatte come le farebbe un attaccante (penetration test), gestione degli incidenti, continuità operativa e aiuto ad adeguarsi alla NIS2, anche per i fornitori.