Quando si parla di GDPR e sistemi informativi, il tema dell’auditing non coincide con un audit legale o documentale sulla conformità privacy. In ambito tecnico, auditing significa soprattutto poter ricostruire chi ha effettuato un accesso, su quale sistema, in quale momento, con quali privilegi e quali operazioni rilevanti sono state eseguite.
I log costituiscono l’evidenza tecnica di queste attività. Se raccolti in modo completo, protetti da alterazioni e conservati secondo criteri documentati, permettono di verificare accessi amministrativi, modifiche ai privilegi, autenticazioni anomale, operazioni su sistemi critici e sequenze di eventi utili durante un’indagine di sicurezza.
Il punto chiave è quindi distinguere l’“audit GDPR” dall’“auditing dei log”: il primo riguarda la verifica complessiva di adempimenti, ruoli, trattamenti e misure organizzative; il secondo riguarda la tracciabilità tecnica delle attività sui sistemi e la possibilità di produrre evidenze affidabili quando servono.
Devi centralizzare e rendere verificabili i log aziendali?
Nexsys progetta soluzioni per raccolta, conservazione, ricerca e correlazione dei log provenienti da ambienti on-premise e cloud.
Scopri il servizio di Log ManagementChe cosa significa auditing dei log
L’auditing dei log è il processo con cui un’organizzazione definisce quali eventi devono essere registrati, verifica che le sorgenti stiano producendo le evidenze attese e controlla che tali evidenze siano integre, ricercabili e coerenti con le finalità di sicurezza e controllo.
Non è sufficiente “avere i log”. Un ambiente può generare grandi quantità di eventi ma restare poco auditabile se i dati sono distribuiti tra sistemi diversi, se gli orologi non sono sincronizzati, se la retention non è definita, se gli amministratori possono cancellare le proprie tracce oppure se mancano eventi essenziali come login, logout, tentativi falliti e modifiche ai privilegi.
Un processo efficace di auditing dovrebbe consentire almeno di:
- identificare l’utente, l’account di servizio o l’identità tecnica che ha generato l’evento;
- associare all’evento data e ora attendibili, possibilmente con sincronizzazione temporale centralizzata;
- distinguere accessi riusciti, tentativi falliti, elevazioni di privilegio e modifiche amministrative;
- ricostruire l’origine dell’accesso, ad esempio indirizzo IP, dispositivo, rete o servizio utilizzato;
- proteggere i log da alterazioni, cancellazioni non autorizzate e accessi impropri;
- conservare le evidenze per un periodo definito e motivato;
- ricercare e correlare rapidamente gli eventi in caso di incidente o verifica.
GDPR e log: cosa richiede realmente la normativa
Il GDPR non contiene una regola generale che imponga a tutte le organizzazioni di conservare ogni tipologia di log per un numero fisso di mesi. Il Regolamento richiede invece di adottare misure tecniche e organizzative adeguate al rischio, proteggere integrità e riservatezza dei dati e poter dimostrare le scelte effettuate secondo il principio di accountability.
Riferimento normativo: Regolamento (UE) 2016/679 - GDPR. In questo quadro, la registrazione degli eventi può costituire una misura tecnica fondamentale per dimostrare chi ha avuto accesso ai sistemi, rilevare anomalie e ricostruire attività rilevanti.
La retention deve quindi essere definita in relazione alle finalità del trattamento, ai rischi, alla necessità di investigazione, agli obblighi settoriali e alle policy interne. Conservare tutto indefinitamente non è una buona pratica: anche i log possono contenere dati personali e devono essere gestiti secondo principi di proporzionalità, minimizzazione e limitazione della conservazione.
Il caso specifico degli amministratori di sistema
In Italia esiste però una previsione specifica per gli amministratori di sistema. Il Provvedimento del Garante del 27 novembre 2008, come successivamente modificato, prevede la registrazione degli accessi logici degli amministratori ai sistemi di elaborazione e agli archivi elettronici, con caratteristiche idonee alla verifica dell’attività svolta e con conservazione non inferiore a sei mesi nei casi in cui il provvedimento trova applicazione.
Approfondimento ufficiale: Provvedimento del Garante sugli amministratori di sistema.
Questo punto non va esteso impropriamente a ogni log aziendale. Il minimo di sei mesi è un requisito specifico riferito agli access log degli amministratori di sistema nel relativo perimetro, non una retention universale prevista dal GDPR per firewall, endpoint, applicazioni, posta elettronica o servizi cloud.
Quali log dovrebbero essere sottoposti ad auditing
Il perimetro va definito in base agli asset, ai rischi e ai processi aziendali. In una tipica infrastruttura ibrida, l’auditing dovrebbe partire dalle sorgenti che permettono di ricostruire autenticazioni, privilegi, azioni amministrative e accessi ai servizi critici.
- Active Directory e Microsoft Entra ID: login, tentativi falliti, modifiche a gruppi e privilegi, creazione e disabilitazione account, attività amministrative;
- Microsoft 365: audit di Exchange Online, SharePoint, OneDrive, Teams, ruoli amministrativi e operazioni sugli oggetti del tenant;
- server Windows e Linux: autenticazioni, elevazioni, servizi, attività amministrative e modifiche di configurazione rilevanti;
- firewall, VPN, proxy e apparati di rete: connessioni, accessi remoti, variazioni di configurazione, eventi IDS/IPS e anomalie di traffico;
- endpoint ed EDR/XDR: processi, eventi di sicurezza, esecuzioni sospette, rilevamenti e attività di risposta;
- applicazioni gestionali e database: accessi ai dati, operazioni privilegiate, modifiche a ruoli e configurazioni, esportazioni o cancellazioni sensibili;
- sistemi di backup e amministrazione: accessi, modifiche alle policy, cancellazioni, restore e operazioni che possono impattare la resilienza.
Per ambienti Microsoft 365, una verifica verticale può essere collegata al Microsoft 365 Security Assessment, che include anche configurazioni di audit, retention e sicurezza del tenant.
Per identità e privilegi on-premise, l’analisi può essere integrata con un Active Directory Security Assessment & Hardening.
Le caratteristiche di un audit trail affidabile
Un audit trail utile deve poter essere considerato un’evidenza tecnica affidabile. La qualità del dato registrato è quindi più importante della semplice quantità di eventi raccolti.
Completezza: Gli eventi necessari devono essere realmente prodotti dalle sorgenti e non presentare lacune incompatibili con la finalità di controllo.
Integrità: I log devono essere protetti contro modifiche o cancellazioni non autorizzate e, quando necessario, trasferiti verso repository separati dai sistemi che li generano.
Riferimento temporale: Gli eventi devono essere associati a timestamp coerenti; differenze di orario tra sistemi possono rendere difficile o errata la ricostruzione di un incidente.
Attribuzione: L’evento deve consentire di identificare account, sistema, origine e operazione con un livello di dettaglio adeguato.
Accesso controllato: L’accesso ai log deve essere limitato ai ruoli autorizzati e a sua volta tracciato quando il contesto lo richiede.
Retention documentata: Tempi e criteri di conservazione devono essere definiti in policy, collegati a finalità, rischio e obblighi applicabili.
Ricercabilità: Gli eventi devono poter essere interrogati rapidamente senza dipendere dalla consultazione manuale di singoli file distribuiti.
Auditing dei log e Log Management: la differenza
Auditing dei log e Log Management sono concetti collegati, ma non equivalenti. L’auditing definisce cosa deve essere verificabile e quali evidenze sono necessarie. Il Log Management è l’insieme di processi e tecnologie utilizzati per raccogliere, normalizzare, proteggere, conservare, ricercare e analizzare tali evidenze.
In ambienti piccoli è possibile controllare manualmente alcune sorgenti. Quando però aumentano server, tenant cloud, firewall, endpoint e applicazioni, la frammentazione rende l’audit inefficiente. Una piattaforma centralizzata consente di applicare retention coerenti, controlli di accesso, alert, ricerche trasversali e correlazioni tra eventi provenienti da sistemi differenti.
Per la componente progettuale e tecnologica, consulta il servizio Nexsys di gestione centralizzata dei log.
Perché i log sono essenziali durante un incidente di sicurezza
Quando si verifica un incidente, la disponibilità dei log incide direttamente sulla capacità di stabilire cosa è successo. Senza evidenze affidabili può essere difficile determinare l’account inizialmente compromesso, l’origine della connessione, i sistemi raggiunti, le modifiche effettuate e l’eventuale accesso a dati personali.
Un audit trail correttamente progettato supporta quindi detection, incident response e analisi forense. Permette inoltre di documentare le verifiche svolte e di produrre elementi tecnici utili nella valutazione di un possibile data breach.
Approfondimento correlato: Data Breach: gestione e procedure operative.
Auditing dei log e NIS2
Anche nel perimetro NIS2 il monitoraggio e la registrazione degli eventi assumono un ruolo rilevante nella gestione del rischio cyber. Per i soggetti interessati dai requisiti tecnici applicabili, il logging deve essere definito in funzione degli asset e della valutazione del rischio, con procedure di monitoraggio, documentazione e revisione degli eventi.
Questo non significa applicare automaticamente una retention identica a tutte le organizzazioni o a tutte le sorgenti. La policy deve essere coerente con il quadro normativo applicabile, la criticità dei sistemi, gli obiettivi di sicurezza e le esigenze di investigazione.
Vuoi verificare se i log attuali sono realmente utilizzabili in caso di incidente?
Valutiamo sorgenti, audit policy, accessi privilegiati, retention, integrità delle evidenze e possibilità di correlazione.
Richiedi una consulenza cybersecurityCome impostare un processo di auditing dei log
Un progetto efficace parte dall’architettura e dalle finalità, non dal prodotto. L’obiettivo è costruire una catena di evidenze verificabile e sostenibile nel tempo.
- Definire il perimetro: sistemi, applicazioni, servizi cloud, account privilegiati e dati critici da sottoporre a tracciamento.
- Mappare le sorgenti: identificare quali eventi ciascun sistema produce e quali configurazioni di audit devono essere abilitate.
- Definire gli eventi minimi: accessi, errori di autenticazione, cambi di privilegi, operazioni amministrative, modifiche di configurazione ed eventi di sicurezza.
- Stabilire retention e finalità: documentare tempi di conservazione distinti per tipologia di log e motivazione.
- Proteggere le evidenze: limitare gli accessi, separare dove opportuno il repository dei log e prevenire alterazioni o cancellazioni non autorizzate.
- Centralizzare e normalizzare: aggregare le sorgenti quando il volume e la complessità rendono inefficiente la consultazione locale.
- Definire controlli e alert: individuare eventi che richiedono revisione immediata o periodica.
- Testare la ricostruzione: simulare un incidente e verificare se i log consentono realmente di ricostruire la sequenza degli eventi.
- Riesaminare periodicamente: aggiornare sorgenti, retention e regole quando cambiano infrastruttura, rischio o obblighi.
Errori comuni nell’auditing dei log
- considerare la semplice attivazione dei log come prova di un processo di auditing efficace;
- applicare “sei mesi” a qualsiasi tipologia di log senza distinguere il requisito specifico sugli amministratori di sistema;
- conservare log sullo stesso sistema amministrato senza adeguate protezioni contro cancellazioni o manipolazioni;
- raccogliere volumi elevati di eventi senza aver definito cosa deve essere ricercato e perché;
- non sincronizzare l’orario dei sistemi, rendendo incoerente la timeline degli eventi;
- concedere accesso ai log a un numero eccessivo di amministratori senza separazione dei ruoli;
- non verificare periodicamente che le sorgenti stiano ancora inviando gli eventi previsti;
- confondere una piattaforma SIEM o Log Management con la governance del processo: lo strumento non sostituisce policy, perimetro e responsabilità.
Quando serve una soluzione centralizzata
La centralizzazione diventa particolarmente utile quando l’organizzazione deve correlare eventi tra più ambienti, mantenere una retention coerente, produrre report periodici o accelerare le indagini. Il valore non è soltanto nella conservazione: è nella possibilità di collegare identità, sistemi, rete e applicazioni in una timeline unica.
Nexsys può supportare la definizione del perimetro di logging, la configurazione delle sorgenti, la raccolta centralizzata, la protezione dei repository, le regole di alerting e la reportistica, integrando il progetto con attività di assessment e sicurezza sugli ambienti Microsoft, Active Directory e infrastruttura di rete.
Vuoi verificare se i log attuali sono realmente utilizzabili in caso di incidente?
Valutiamo sorgenti, audit policy, accessi privilegiati, retention, integrità delle evidenze e possibilità di correlazione.
Richiedi una consulenza cybersecurityConclusione
L’auditing dei log è un controllo tecnico: serve a rendere verificabili accessi e attività sui sistemi. Il GDPR costituisce una parte del contesto di accountability e sicurezza, ma non trasforma automaticamente ogni attività di logging in un “audit GDPR”. La progettazione corretta parte da finalità, rischio e sistemi da controllare, definisce le evidenze necessarie e stabilisce come proteggerle, conservarle e riesaminarle.
Quando la quantità di sorgenti rende il controllo manuale insufficiente, il passo successivo è adottare un processo strutturato di raccolta e gestione centralizzata dei log, mantenendo separati l’obiettivo di audit tecnico e la componente commerciale della soluzione.
FAQ
Il GDPR obbliga a conservare i log?
Il GDPR non impone una retention unica per tutti i log. Richiede però misure tecniche e organizzative adeguate, sicurezza dei dati e accountability. In molti contesti il logging è una misura necessaria per dimostrare accessi, attività amministrative e ricostruire incidenti. La durata va definita in base a finalità, rischio e obblighi specifici.
Per quanto tempo devono essere conservati i log?
Non esiste un periodo valido per ogni sorgente. I tempi devono essere documentati e proporzionati alla finalità. In Italia, per gli accessi logici degli amministratori di sistema nel perimetro del Provvedimento del Garante del 27 novembre 2008, è prevista una conservazione non inferiore a sei mesi. Questo requisito non va automaticamente esteso a tutti gli altri log.
Qual è la differenza tra audit log e Log Management?
L’audit log è la registrazione di eventi utilizzata come evidenza delle attività svolte su un sistema. Il Log Management è il processo e l’insieme di tecnologie che raccolgono, normalizzano, proteggono, conservano, ricercano e analizzano log provenienti da più sorgenti.
Quali eventi conviene tracciare per primi?
Le priorità tipiche sono autenticazioni riuscite e fallite, attività degli account privilegiati, creazione o modifica degli utenti, cambi di ruolo e permessi, operazioni amministrative, modifiche di configurazione, accessi remoti, eventi di sicurezza e attività su sistemi o applicazioni critiche.
Come deve essere protetto un audit trail?
I log devono essere accessibili solo ai soggetti autorizzati, protetti da modifiche e cancellazioni improprie e mantenuti con riferimenti temporali coerenti. Nei contesti più critici è opportuno inviarli a un repository centralizzato separato dai sistemi che li generano.
I log possono aiutare nella gestione di un data breach?
Sì. Log completi e affidabili permettono di ricostruire la timeline di un incidente, identificare account e sistemi coinvolti, verificare accessi anomali e raccogliere evidenze tecniche utili alla valutazione dell’evento e alle successive attività di incident response.
NIS2 richiede il logging?
Nel perimetro NIS2 il monitoraggio e la registrazione degli eventi sono componenti rilevanti delle misure di gestione del rischio cyber. L’applicazione concreta dipende dal soggetto, dagli atti applicabili e dalla valutazione del rischio; per questo logging, asset da tracciare e retention devono essere formalizzati in modo coerente con il contesto.