Introduzione
I log sono evidenze tecniche, ma anche evidenze di governance.
I log permettono di rilevare incidenti, ricostruire sequenze di eventi, comprendere l'origine di una compromissione, dimostrare accountability e supportare audit interni, audit ISO 27001, verifiche su data breach e controlli di cybersecurity. Senza log attendibili, molte decisioni di sicurezza restano opinioni: non evidenze.
Il problema nasce quando la sicurezza chiede più conservazione e la privacy chiede minimizzazione. Da un lato servono dati storici per detection, forensic readiness e incident response; dall'altro il GDPR impone finalità chiare, conservazione limitata, proporzionalità e sicurezza del trattamento. Il punto non è scegliere tra sicurezza e privacy, ma progettare un sistema di log management coerente con entrambe.
Framework integrati
Perché i log sono centrali per NIS2, GDPR e ISO 27001
La NIS2 richiede alle organizzazioni di governare il rischio cyber, rilevare eventi, gestire incidenti, assicurare continuità e presidiare la supply chain. In questo contesto i log sono la base per monitoraggio, escalation, notifica e accountability del management.
Il GDPR guarda agli stessi log da una prospettiva diversa: se contengono dati personali, sono un trattamento. Devono quindi essere leciti, necessari, proporzionati, protetti e conservati per tempi coerenti con la finalità. Nei casi più invasivi serve una DPIA o almeno una valutazione privacy/rischio documentata.
ISO/IEC 27001:2022 fornisce il sistema di gestione che tiene insieme rischio, controlli, evidenze, audit e miglioramento continuo. I controlli ISO/IEC 27002:2022 relativi a logging, monitoring, accessi, gestione eventi, protezione delle informazioni e supplier security aiutano a trasformare i requisiti in procedure verificabili.
Matrice normativa
Tabella di correlazione NIS2 / GDPR / ISO 27001
| Ambito | Esigenza NIS2 | Esigenza GDPR | Collegamento ISO 27001 / ISO 27002 | Implicazione pratica sui log |
|---|---|---|---|---|
| Incident detection | Capacità di rilevare eventi anomali e compromissioni sui servizi essenziali o importanti. | Sicurezza del trattamento e rilevazione tempestiva di possibili data breach. | ISO 27001 risk treatment; ISO 27002 controlli su logging, monitoring e threat intelligence. | Centralizzare eventi critici, definire use case di detection e mantenere evidenze interrogabili. |
| Incident response | Gestione, escalation, reporting e ricostruzione degli incidenti cyber. | Valutazione dell'impatto sui dati personali e supporto alla notifica entro i termini applicabili. | Controlli su incident management, evidence collection e lesson learned. | Conservare log integri, sincronizzati e disponibili per analisi forense e decisioni di notifica. |
| Accountability | Dimostrare governance, responsabilità e attuazione delle misure di sicurezza. | Dimostrare liceità, proporzionalità, sicurezza e rispetto dei principi del trattamento. | SGSI, audit trail, riesame direzionale, miglioramento continuo e registrazioni documentate. | Collegare policy di logging, risk assessment, DPIA, retention e riesami periodici. |
| Accessi privilegiati | Controllo delle attività amministrative su asset, reti e piattaforme critiche. | Limitazione degli accessi ai dati personali e tracciabilità degli operatori autorizzati. | Identity management, privileged access management, segregation of duties e access review. | Raccogliere log amministrativi separati, protetti e consultabili solo da ruoli autorizzati. |
| Conservazione dei dati | Mantenere evidenze sufficienti per detection, response, continuità e verifiche. | Limitazione della conservazione e cancellazione quando la finalità non è più attuale. | Gestione delle informazioni documentate, protezione delle registrazioni e retention controllata. | Definire tempi differenziati per categoria di log, rischio, finalità e criticità del sistema. |
| Minimizzazione | Raccogliere eventi utili alla sicurezza senza creare rumore operativo non governato. | Trattare solo i dati personali necessari rispetto alla finalità dichiarata. | Risk-based approach, data classification e security by design. | Ridurre campi non necessari, mascherare attributi sensibili e separare identificativi quando possibile. |
| Protezione dei log | Impedire alterazioni, cancellazioni o accessi non autorizzati alle evidenze. | Garantire riservatezza, integrità e disponibilità dei dati personali presenti nei log. | Cryptography, access control, backup, information transfer e protection of records. | Applicare cifratura, immutabilità, segregazione degli accessi e controllo degli accessi ai log. |
| Monitoraggio continuo | Sorvegliare asset, fornitori, servizi digitali e segnali di compromissione. | Rilevare trattamenti anomali, accessi impropri e possibili violazioni dei dati. | Security monitoring, vulnerability management, audit e performance evaluation del SGSI. | Integrare SIEM/SOC, alerting, review periodiche e metriche di efficacia. |
| Supply chain / fornitori IT | Governare dipendenze ICT, MSP, MDR, cloud, SaaS e fornitori rilevanti. | Gestire responsabili del trattamento, sub-responsabili e trasferimenti di dati. | Supplier relationships, cloud services, contractual controls e monitoring dei fornitori. | Richiedere log, SLA, incident notification, auditabilità e responsabilità chiare nei contratti. |
| Evidenze di audit | Dimostrare misure, controlli e capacità di risposta in caso di verifica. | Dimostrare accountability, DPIA, basi giuridiche, misure e retention. | Audit interni, audit di certificazione, non conformità e corrective action. | Mantenere registrazioni verificabili, versionate e coerenti con policy e procedure operative. |
Perimetro di raccolta
Quali log raccogliere
Non tutti i log hanno lo stesso valore e non tutti richiedono la stessa retention. La selezione deve partire da asset critici, scenari di rischio, processi aziendali, categorie di dati personali e requisiti di audit. Una raccolta efficace privilegia log utili alla detection, alla risposta e alla dimostrazione dei controlli.
| Tipologia di log | Finalità | Rischio trattato | Dati personali potenzialmente presenti | Priorità di raccolta |
|---|---|---|---|---|
| Log di autenticazione | Rilevare login, MFA, anomalie di accesso, brute force e sessioni sospette. | Account takeover, accessi non autorizzati, credential stuffing. | User ID, indirizzo IP, timestamp, device, esito autenticazione. | Alta |
| Log amministrativi e privilegiati | Tracciare attività di amministratori, modifiche di configurazione e comandi critici. | Abuso di privilegi, errore amministrativo, compromissione di account privilegiati. | Identificativo amministratore, sistema, azione eseguita, oggetto modificato. | Critica |
| Log applicativi | Monitorare errori, transazioni, accessi funzionali e anomalie applicative. | Frode, data leakage, malfunzionamenti, abuso di funzionalità. | ID utente, ID pratica, payload ridotto, eventi funzionali. | Media/Alta |
| Log di rete e firewall | Analizzare traffico, blocchi, connessioni e pattern di comunicazione. | Intrusione, lateral movement, esfiltrazione, C2. | IP sorgente/destinazione, porte, protocolli, esito regola. | Alta |
| Log endpoint/EDR | Rilevare malware, esecuzioni anomale, processi e comportamenti sospetti. | Ransomware, compromissione endpoint, persistence. | Hostname, utente, processo, hash, percorso file. | Alta |
| Log cloud e SaaS | Tracciare accessi, configurazioni, API, tenant, storage e attività amministrative. | Misconfiguration, abuso API, accessi esterni, data exposure. | Account, tenant, IP, oggetto cloud, attività effettuata. | Alta |
| Log di backup | Verificare esecuzione, errori, restore test e integrità delle copie. | Indisponibilità dei backup, ransomware, mancato ripristino. | Sistema, job, esito, timestamp, operatore. | Alta |
| Log di accesso ai dati personali | Dimostrare chi accede a dataset personali, quando e per quale funzione. | Accesso improprio, data breach, trattamento non autorizzato. | Utente, record o categoria dati, finalità applicativa, timestamp. | Critica |
| Log SIEM/SOC | Correlare eventi, alert, escalation, triage e decisioni operative. | Detection tardiva, mancata escalation, perdita di evidenze. | Alert, owner, severità, asset, regola, note operative. | Critica |
Retention log GDPR
Retention dei log: come definire i tempi di conservazione
Non esiste un tempo unico valido per tutti. I tempi di conservazione devono derivare da analisi del rischio cyber, obblighi normativi, finalità del trattamento, criticità dei sistemi, necessità di detection e forensic readiness, principi GDPR e requisiti del sistema ISO 27001.
I valori seguenti sono esempi orientativi. Devono essere validati caso per caso tramite DPIA, valutazione privacy/rischio, risk assessment cyber, policy interne e confronto con eventuali vincoli contrattuali o settoriali.
| Categoria log | Finalità | Retention suggerita | Motivazione | Misure compensative |
|---|---|---|---|---|
| Log autenticazione utenti ordinari | Detection accessi anomali e supporto a indagini su account compromessi. | 6-12 mesi | Bilanciamento tra capacità di detection, analisi storica e minimizzazione. | Aggregazione, rotazione, masking IP quando compatibile con la finalità. |
| Log amministratori | Controllo attività privilegiate, audit e ricostruzione di modifiche critiche. | 12-24 mesi | Rischio elevato e necessità di evidenze in audit, incident response e forensics. | Accesso segregato, immutabilità, revisione periodica, alert su attività sensibili. |
| Log firewall | Analisi traffico, detection, correlazione con eventi di sicurezza. | 6-12 mesi | Utile per pattern storici e ricostruzioni tecniche senza conservazione indefinita. | Sintesi statistiche oltre il periodo pieno, filtraggio del rumore non necessario. |
| Log SIEM | Correlazione eventi, incident management e forensic readiness. | 12-18 mesi | Supporta campagne persistenti, attacchi lenti e verifiche successive all'incidente. | Tiering, cifratura, access control, data minimization sulle sorgenti. |
| Log applicativi con dati personali | Sicurezza applicativa, audit funzionale e troubleshooting controllato. | 3-12 mesi | Dipende da finalità, criticità applicativa e quantità di dati personali inclusi. | Payload minimizzati, masking, separazione ID, cancellazione automatizzata. |
| Log backup | Evidenza di esecuzione, fallimenti e restore readiness. | 12-24 mesi | Serve a dimostrare continuità, test e capacità di ripristino nel tempo. | Conservare esiti e metadati, evitare contenuti personali non necessari. |
| Log accesso a dati particolari | Tracciabilità rafforzata su dati ad alto impatto privacy. | 6-12 mesi, da validare | Rischio elevato per diritti e libertà; richiede proporzionalità documentata. | DPIA, pseudoanonimizzazione, autorizzazioni ristrette, audit degli accessi. |
DPIA log
DPIA per la gestione dei log
Una DPIA sui log deve descrivere trattamento, finalità, categorie di interessati, categorie di dati personali, basi giuridiche, necessità, proporzionalità, rischi per diritti e libertà e misure tecniche e organizzative. Deve inoltre includere criteri di retention, pseudoanonimizzazione, access control, segregazione dei ruoli, logging degli accessi ai log e revisione periodica.
| Elemento DPIA | Domanda da porsi | Evidenza attesa | Collegamento con NIS2 / ISO 27001 |
|---|---|---|---|
| Descrizione del trattamento | Quali eventi vengono raccolti, da quali sistemi e con quali flussi? | Mappa sorgenti log, data flow, owner e responsabili. | Perimetro cyber NIS2 e contesto SGSI ISO 27001. |
| Finalità | Il log serve a sicurezza, audit, continuità, troubleshooting o compliance? | Registro finalità e matrice log/finalità. | Accountability GDPR, risk treatment ISO 27001 e incident detection NIS2. |
| Categorie di interessati | Chi può essere identificato nei log? | Dipendenti, amministratori, clienti, utenti, fornitori, visitatori. | Analisi impatto privacy e gestione identità/accessi. |
| Categorie di dati personali | Quali identificativi o dati sensibili possono comparire? | IP, user ID, email, device ID, dati particolari, record ID. | Data classification ISO 27001 e minimizzazione GDPR. |
| Base giuridica | Quale fondamento legittima la raccolta e conservazione? | Obbligo legale, legittimo interesse, sicurezza del trattamento, contratto. | Coerenza con compliance NIS2, GDPR e policy SGSI. |
| Necessità e proporzionalità | Il livello di logging è proporzionato al rischio e alla finalità? | Valutazione comparativa, alternative meno invasive e minimizzazione. | Risk-based approach ISO 27001 e principi GDPR. |
| Rischi per diritti e libertà | Quali danni possono derivare da abuso o esposizione dei log? | Scenari di accesso improprio, profilazione, sorveglianza e data breach. | DPIA GDPR e gestione rischio sicurezza informazioni. |
| Misure tecniche e organizzative | Come si proteggono log, chiavi, console e procedure? | Cifratura, RBAC, PAM, segregazione, alert, backup, audit. | Controlli ISO 27002 e misure NIS2 di gestione del rischio. |
| Retention | Per quanto tempo ogni categoria resta necessaria? | Matrice retention, cancellazione automatica e riesami. | Limitazione della conservazione GDPR e informazioni documentate ISO. |
| Revisione periodica | Quando si riesamina l'efficacia e la proporzionalità? | Verbali di review, audit interni, change log e corrective action. | Miglioramento continuo ISO 27001 e accountability NIS2/GDPR. |
Privacy by design
Pseudoanonimizzazione dei log
Anonimizzazione e pseudoanonimizzazione non sono la stessa cosa. L'anonimizzazione elimina la possibilità realistica di re-identificare l'interessato; la pseudoanonimizzazione sostituisce o separa identificativi, ma consente re-identificazione con informazioni aggiuntive custodite separatamente.
Nei log l'anonimizzazione completa spesso non è praticabile: se non è più possibile sapere quale account ha eseguito un'azione, diventa difficile gestire un incidente, valutare un data breach o ricostruire un abuso di privilegi. La scelta corretta va documentata nella DPIA, distinguendo dove serve il dato identificativo e dove è sufficiente un identificativo mascherato, tokenizzato o aggregato.
| Tecnica | Applicazione sui log | Vantaggi | Limiti | Quando usarla |
|---|---|---|---|---|
| Masking | Oscuramento parziale di email, IP, ID cliente o campi payload. | Riduce esposizione immediata e leggibilità di dati non necessari. | Può non essere sufficiente se altri campi consentono re-identificazione. | Dashboard operative e log applicativi usati da team non privacy-critical. |
| Tokenizzazione | Sostituzione di identificativi con token reversibili gestiti separatamente. | Consente indagini autorizzate mantenendo separato il dato identificativo. | Richiede gestione robusta del vault e delle autorizzazioni. | Accessi a dati personali, audit applicativi, ambienti SIEM multi-team. |
| Hashing | Trasformazione di identificativi per correlazione senza esposizione diretta. | Utile per matching e pattern ricorrenti con minore visibilità del dato. | Se il dominio è piccolo può essere vulnerabile a dizionari o brute force. | Correlazioni statistiche, alerting e analisi aggregate. |
| Separazione identificativi | Log tecnici separati da tabelle di riconciliazione custodite da ruoli diversi. | Riduce accesso diffuso al dato personale completo. | Aumenta complessità operativa e tempi di indagine se non progettata bene. | Contesti con dati particolari, ruoli segregati e requisiti di audit elevati. |
| Chiavi controllate | Accesso alle chiavi di re-identificazione solo tramite workflow autorizzato. | Mantiene forensic readiness senza accesso indiscriminato. | Richiede logging degli accessi alle chiavi e approvazioni tracciate. | Incident response, data breach assessment e audit ad alto impatto. |
Controlli operativi
Misure tecniche e organizzative consigliate
Un sistema di log management maturo combina piattaforma, governance, procedure, responsabilità e controlli di accesso. Le misure devono essere proporzionate al rischio e integrate nel SGSI, non aggiunte come attività laterale.
Rischi da evitare
Errori comuni nella gestione dei log
Gli errori più frequenti nascono da un approccio frammentato: l'IT conserva eventi per sicurezza, la privacy interviene solo dopo, il sistema ISO 27001 non riceve evidenze strutturate e i fornitori non sono governati contrattualmente.
- Conservare tutto per sicurezza senza finalità, criteri e controlli documentati.
- Non distinguere log tecnici, log di sicurezza e log contenenti dati personali.
- Definire retention indefinite o uguali per tutte le categorie di log.
- Consentire accessi ai log senza tracciamento, autorizzazione e riesame periodico.
- Lasciare i log modificabili dagli stessi amministratori che devono essere monitorati.
- Non svolgere DPIA o valutazione privacy/rischio quando il trattamento è invasivo.
- Non correlare log management, incident response, data breach e sistema ISO 27001.
- Affidare tutto al fornitore SOC o cloud senza clausole, evidenze e responsabilità verificabili.
Approccio operativo UNICA Consulting
Come UNICA supporta le aziende su log, NIS2, GDPR e ISO 27001
UNICA Consulting aiuta direzioni, DPO, CISO, responsabili compliance, IT manager e auditor a trasformare requisiti normativi e standard ISO in un modello operativo verificabile. L'obiettivo è costruire una gestione dei log utile alla sicurezza e difendibile in audit, senza eccedere nella raccolta di dati personali.
FAQ SEO
Domande frequenti sulla gestione dei log
Per quanto tempo devono essere conservati i log?
Non esiste un tempo unico valido per tutti. La retention deve derivare da analisi del rischio cyber, finalità del trattamento, obblighi normativi, criticità dei sistemi e principi GDPR. In molti casi serve una valutazione privacy/rischio o una DPIA.
I log contengono dati personali?
Spesso sì. User ID, indirizzi IP, email, identificativi dispositivo, timestamp, record consultati e attività degli utenti possono rendere identificabile una persona fisica. Per questo i log devono essere progettati con minimizzazione, access control e retention documentata.
Serve una DPIA per gestire i log?
Dipende da perimetro, intensità del monitoraggio, categorie di interessati, dati trattati e rischi per diritti e libertà. Se i log includono monitoraggio sistematico, accessi a dati particolari o controllo esteso dei lavoratori, una DPIA o una valutazione privacy strutturata è normalmente opportuna.
La NIS2 obbliga ad avere un SIEM?
La NIS2 richiede misure proporzionate di gestione del rischio cyber, detection, incident response e continuità. Non impone sempre uno specifico prodotto SIEM, ma per molte organizzazioni un SIEM o un servizio SOC/MDR è lo strumento più efficace per correlare eventi e documentare il monitoraggio.
Come si concilia ISO 27001 con GDPR nella gestione dei log?
ISO 27001 aiuta a strutturare risk assessment, controlli, audit e miglioramento continuo; il GDPR impone minimizzazione, limitazione della conservazione, sicurezza e accountability. Un modello maturo collega policy di logging, DPIA, retention, controlli di accesso e registrazioni del SGSI.
I log degli amministratori devono essere separati?
È una misura fortemente raccomandata nei contesti critici. I log privilegiati dovrebbero essere protetti, non modificabili dagli amministratori monitorati, accessibili solo a ruoli autorizzati e riesaminati con procedure tracciate.
È possibile pseudoanonimizzare i log?
Sì, con masking, tokenizzazione, hashing, separazione degli identificativi e controllo delle chiavi. Tuttavia nei log di sicurezza l'anonimizzazione completa spesso non è praticabile perché può impedire incident response, forensic readiness e valutazione dei data breach.
Assessment integrato
Vuoi verificare se la gestione dei log della tua organizzazione è conforme a NIS2, GDPR e ISO 27001?
UNICA Consulting può supportarti con un assessment integrato e operativo su log management, retention, DPIA, controlli ISO 27001 e cybersecurity compliance.