Quando un’applicazione web mostra una pagina bianca o un server rifiuta una connessione, la prima cosa che fa un amministratore è aprire un file. Questo file è un log. Contiene la traccia temporale di ogni evento verificatosi nel sistema: una richiesta ricevuta, un errore scatenato, un utente autenticato. Comprendere i log in informatica significa avere un filo conduttore per risalire all’origine di un problema, verificare che un servizio funzioni o rilevare un comportamento anomalo.
Ciò che contiene realmente un log e perché il formato cambia tutto
Un log è una registrazione di eventi. Ogni riga associa almeno una data, una sorgente e un messaggio. Su un server web, ad esempio, ogni visita genera una riga che specifica l’indirizzo IP del visitatore, la pagina richiesta, il codice di risposta HTTP e il tempo di elaborazione.
Hai mai aperto un file di testo pieno di righe incomprensibili? Spesso si tratta di un log non strutturato. Il messaggio è redatto in testo libero, senza un formato fisso. Ogni applicazione scrive a modo suo, il che rende la ricerca difficile non appena più servizi coesistono.
Al contrario, un log strutturato in JSON organizza ogni campo in modo leggibile da una macchina. La data, il livello di severità, il servizio interessato e il messaggio occupano ciascuno un campo dedicato. Il guadagno è diretto: uno strumento di analisi può filtrare, ordinare e incrociare migliaia di eventi in pochi secondi invece di cercare un modello in testo grezzo.
Per saperne di più sui log in informatica, la distinzione tra formato strutturato e non strutturato è il primo concetto da padroneggiare, perché condiziona il resto: raccolta, archiviazione, analisi.
Livelli di severità dei log: leggere il segnale giusto al momento giusto
Tutti gli eventi registrati non hanno la stessa gravità. I framework di registrazione utilizzano una scala di severità che consente di filtrare ciò che merita un’attenzione immediata.
- DEBUG: dettagli fini utilizzati durante lo sviluppo, disattivati in produzione per evitare un volume eccessivo.
- INFO: eventi normali che confermano il buon funzionamento (avvio di un servizio, connessione riuscita).
- WARN: situazione insolita che non impedisce il funzionamento ma segnala un rischio (spazio su disco basso, latenza elevata).
- ERROR: un’elaborazione è fallita, un’azione dell’utente non ha avuto successo. Spesso è necessaria un’intervento.
- FATAL: il servizio si interrompe. L’intera applicazione o il server è offline.
La tentazione frequente è quella di impostare tutto su DEBUG per “non perdere nulla”. Il risultato: file che crescono di diversi gigabyte al giorno, un costo di archiviazione che esplode e un rumore permanente che sovrasta le vere allerte. Scegliere il giusto livello di severità riduce il volume senza perdere informazioni utili.
Dati sensibili nei log: cosa non registrare mai
Un log può catturare quasi tutto ciò che transita in un’applicazione. Questo è proprio il problema. L’OWASP raccomanda di escludere dai log le password, i token di accesso, gli identificatori di sessione, le chiavi di crittografia e i dati personali sensibili.
Perché questa cautela? Perché i log stessi possono diventare una fonte di fuga di dati. Un file log archiviato senza restrizioni di accesso espone informazioni sfruttabili da un attaccante. Quando è necessario un monitoraggio, la buona prassi consiste nel mascherare o pseudonimizzare i valori sensibili prima della scrittura nel log.
La CNIL fornisce un riferimento per le tracce di accesso e di azioni degli utenti: una conservazione da sei mesi a un anno a seconda della finalità. Oltre, il contenuto raccolto deve rimanere proporzionato al bisogno reale. Conservare richieste complete per diversi anni senza una giustificazione definita espone a un rischio legale tanto quanto tecnico.
Proteggere l’integrità dei log
Un log modificato o eliminato perde ogni valore probatorio. L’OWASP raccomanda controlli di integrità, accesso ristretto e monitorato, nonché una protezione dei dati di log. Un log utile a un’indagine deve anche essere affidabile. Un attaccante che accede a un server cercherà spesso di cancellare le proprie tracce nei log prima di qualsiasi altra azione.
Regolamentazione europea e registrazione: obblighi concreti
La registrazione non è più solo una buona prassi tecnica. Il Cyber Resilience Act europeo include la registrazione di eventi di sicurezza tra i requisiti applicabili ai prodotti digitali. La direttiva NIS 2, da parte sua, impone alle entità interessate di implementare capacità di rilevamento e risposta agli incidenti, il che implica un sistema di log funzionale e utilizzabile.
Senze una registrazione affidabile, la conformità NIS 2 o CRA diventa impossibile da dimostrare. Questi testi non specificano quale strumento utilizzare, ma richiedono la capacità di tracciare, rilevare e rispondere. I log sono la base tecnica di questa capacità.
Buone pratiche nella gestione dei log quotidiana
Implementare i log non è sufficiente. La loro utilità dipende da come vengono raccolti, centralizzati e sfruttati.
- Centralizzare i registri di tutti i servizi su una piattaforma unica evita di cercare manualmente in ogni server. Un raccoglitore recupera gli eventi e li invia a un punto di analisi comune.
- Definire una politica di conservazione adeguata a ciascun tipo di log. Le tracce di accesso degli utenti non hanno la stessa durata di conservazione utile dei log di diagnostica applicativa.
- Implementare avvisi sui livelli ERROR e FATAL per reagire prima che gli utenti segnalino il problema.
- Revisionare regolarmente ciò che viene registrato. Un campo aggiunto durante uno sviluppo rapido può contenere dati personali senza che nessuno lo abbia previsto.
Il valore di un sistema di log si misura alla velocità di risoluzione di un incidente. Un log ben strutturato, centralizzato e purgato secondo regole chiare trasforma un guasto di diverse ore in una diagnosi di pochi minuti. È ciò che separa un team che subisce gli incidenti da un team che li anticipa.
