Quando si parla di sicurezza informatica, l'attenzione si concentra spesso sulla prevenzione.
Aggiornamenti, firewall, autenticazione a più fattori e controlli di accesso sono strumenti fondamentali per ridurre il rischio di compromissione.
Ma cosa succede quando qualcosa va storto?
Come possiamo capire se qualcuno ha tentato di accedere a un account, modificare una configurazione o sfruttare una vulnerabilità?
La risposta passa anche attraverso il security logging, ovvero la raccolta e l'analisi degli eventi rilevanti per la sicurezza.
I log permettono di ricostruire attività, individuare comportamenti anomali e supportare le indagini dopo un incidente.
Tuttavia, raccogliere informazioni non basta.
Bisogna decidere quali eventi registrare, come proteggerli e per quanto tempo conservarli.
Che cos'è il security logging?
Il security logging consiste nella registrazione strutturata degli eventi che possono avere rilevanza per la sicurezza di un sistema.
Un evento può riguardare un tentativo di autenticazione, una modifica dei permessi, un accesso negato o un cambiamento alla configurazione.
L'obiettivo è creare una traccia che permetta di comprendere cosa è successo.
È importante distinguere i log di sicurezza dai normali log applicativi.
Un'applicazione può registrare informazioni tecniche utili per il debugging, come tempi di risposta o errori di elaborazione.
I log di sicurezza si concentrano invece sugli eventi che possono indicare attività sospette o modifiche rilevanti.
Le due categorie possono sovrapporsi, ma rispondono a esigenze differenti.
Perché i log sono importanti?
Immaginiamo che un amministratore scopra la presenza di un account sconosciuto nel proprio gestionale.
Senza log, potrebbe essere difficile capire quando l'account è stato creato, quale utente ha eseguito l'operazione e quali attività sono state effettuate successivamente.
Con una registrazione adeguata, invece, è possibile ricostruire almeno parte della sequenza degli eventi.
I log possono aiutare a:
- Individuare tentativi di accesso non autorizzati.
- Riconoscere comportamenti anomali.
- Ricostruire modifiche amministrative.
- Supportare le indagini sugli incidenti.
- Verificare il funzionamento dei controlli di sicurezza.
- Individuare problemi ricorrenti.
Naturalmente, la qualità delle informazioni dipende da ciò che viene effettivamente registrato.
Un sistema che conserva soltanto errori generici potrebbe non fornire dati sufficienti per un'analisi approfondita.
Quali eventi di sicurezza registrare?
La scelta dipende dall'applicazione, ma esistono alcune categorie particolarmente importanti.
Tentativi di autenticazione
È utile registrare gli accessi riusciti e falliti.
Questo permette di individuare tentativi ripetuti, accessi insoliti e possibili attività automatizzate.
Non è necessario registrare la password inserita.
Anzi, farlo rappresenterebbe un grave errore.
Modifiche agli account
La creazione di nuovi utenti, la disattivazione degli account e la modifica dei ruoli sono eventi rilevanti.
Particolare attenzione dovrebbe essere dedicata alle modifiche che assegnano privilegi amministrativi.
Operazioni sensibili
Un'applicazione potrebbe registrare modifiche a configurazioni critiche, esportazioni di dati o operazioni amministrative.
Non tutte le attività devono necessariamente produrre un evento di sicurezza.
È importante selezionare quelle che possono avere un impatto significativo.
Errori di autorizzazione
Tentativi ripetuti di accedere a risorse non autorizzate possono indicare un problema.
Per esempio, un utente che tenta di consultare numerosi identificatori di risorse appartenenti ad altri account potrebbe richiedere un'analisi.
Modifiche alla configurazione
Cambiamenti a impostazioni di autenticazione, integrazioni API o autorizzazioni meritano particolare attenzione.
In un sistema multi-tenant, questi eventi possono essere fondamentali per ricostruire eventuali problemi di isolamento.
Come strutturare correttamente un evento di log
Un log utile dovrebbe contenere informazioni sufficienti per comprendere l'evento.
Tra i campi possibili troviamo:
- Timestamp.
- Tipo di evento.
- Identificatore dell'utente, se disponibile.
- Identificatore della richiesta.
- Esito dell'operazione.
- Risorsa interessata.
- Informazioni contestuali pertinenti.
Per esempio:
{
"timestamp": "2026-10-30T14:30:00Z",
"event": "authentication.failed",
"user_id": null,
"request_id": "req_8f92a1",
"result": "denied",
"reason": "invalid_credentials"
}
Il formato JSON può facilitare l'elaborazione automatica e la ricerca degli eventi.
È importante utilizzare convenzioni coerenti tra le diverse componenti dell'applicazione.
Come registrare eventi di sicurezza in PHP
PHP permette di scrivere messaggi nei log attraverso la funzione error_log().
Per esempio:
<?php
$event = [
'timestamp' => gmdate('c'),
'event' => 'authentication.failed',
'result' => 'denied',
'request_id' => bin2hex(random_bytes(8))
];
error_log(json_encode(
$event,
JSON_UNESCAPED_SLASHES
));
Questo esempio illustra la registrazione di un evento strutturato.
In un'applicazione reale è opportuno utilizzare un sistema di logging centralizzato o una libreria che permetta di gestire livelli, formati e destinazioni.
È inoltre necessario verificare dove vengono effettivamente salvati i log.
Un file di log non dovrebbe essere pubblicamente accessibile attraverso il web server.
Quali informazioni non devono finire nei log?
Uno degli errori più pericolosi consiste nel registrare dati sensibili senza rendersene conto.
Durante il debugging può essere comodo salvare l'intero contenuto di una richiesta HTTP.
Ma quella richiesta potrebbe contenere password, token di autenticazione, API key o dati personali.
Tra le informazioni da evitare troviamo:
- Password.
- Token di sessione.
- API key.
- Refresh token.
- Codici di autenticazione.
- Dati di pagamento completi.
- Informazioni personali non necessarie.
Quando un dato è indispensabile per l'analisi, è opportuno valutare tecniche di minimizzazione, mascheramento o pseudonimizzazione.
Il principio è semplice: registrare ciò che serve per comprendere l'evento, non tutto ciò che è tecnicamente disponibile.
Log injection: quando anche i log diventano un rischio
I sistemi di logging possono essere vulnerabili se registrano dati non attendibili senza adeguate precauzioni.
Immaginiamo che un'applicazione inserisca direttamente nei log un valore fornito dall'utente.
Se il contenuto include caratteri di controllo o sequenze particolari, potrebbe alterare la rappresentazione del log o creare eventi apparentemente differenti.
Questo problema viene spesso chiamato log injection o log forging.
Per ridurre il rischio è utile utilizzare formati strutturati, codificare correttamente i valori e impedire che dati non attendibili modifichino la struttura degli eventi.
Anche gli strumenti utilizzati per visualizzare i log devono trattare i contenuti come dati, evitando interpretazioni non necessarie.
Come proteggere i file di log
I log possono contenere informazioni importanti sull'infrastruttura.
Per questo motivo devono essere protetti attraverso permessi appropriati.
Su Linux è utile verificare quali utenti e processi possono leggere o modificare i file.
I log di sicurezza dovrebbero essere accessibili soltanto ai soggetti autorizzati.
È inoltre opportuno valutare una raccolta centralizzata.
Se un attaccante compromette un server, potrebbe tentare di cancellare o alterare i log locali.
Inviare gli eventi a un sistema separato può rendere più difficile eliminare tutte le tracce.
Naturalmente, anche il sistema centralizzato deve essere protetto.
Quanto tempo conservare i log?
Non esiste un periodo di conservazione valido per qualsiasi applicazione.
La durata dipende dalle finalità, dai rischi, dagli obblighi applicabili e dalle esigenze operative.
Un sistema che gestisce dati personali deve considerare anche i principi del GDPR, tra cui minimizzazione e limitazione della conservazione.
È opportuno definire una politica che stabilisca:
- Quali eventi vengono registrati.
- Per quale finalità.
- Chi può consultarli.
- Per quanto tempo vengono conservati.
- Come vengono eliminati.
- Quali misure di sicurezza li proteggono.
La conservazione indefinita di tutti i log non rappresenta automaticamente una buona pratica.
Logging e monitoraggio sono la stessa cosa?
No.
Il logging consiste nella registrazione degli eventi.
Il monitoraggio utilizza queste informazioni per individuare problemi e comportamenti anomali.
Un'applicazione può produrre milioni di righe di log senza che nessuno le analizzi.
In questo caso, la capacità di rilevare un attacco potrebbe rimanere molto limitata.
Il monitoraggio aggiunge regole, correlazioni e notifiche.
Per esempio, un sistema potrebbe generare un avviso quando rileva un numero anomalo di tentativi di login falliti o una modifica inattesa ai privilegi amministrativi.
Che cos'è un SIEM?
SIEM significa Security Information and Event Management.
Si tratta di una categoria di soluzioni che raccolgono e analizzano eventi provenienti da sistemi differenti.
Un SIEM può correlare informazioni generate da firewall, server, applicazioni e servizi di autenticazione.
L'obiettivo è individuare attività che potrebbero risultare poco evidenti osservando una singola fonte.
Non tutte le organizzazioni hanno bisogno di una piattaforma SIEM complessa.
Per un piccolo progetto SaaS, un sistema di logging strutturato con alert mirati può rappresentare un punto di partenza ragionevole.
L'importante è che gli eventi critici non rimangano completamente ignorati.
Logging e VPS Linux
Su una VPS Ubuntu, molti servizi utilizzano systemd e journald per registrare eventi.
Il comando:
journalctl -p warning -b
permette di consultare i messaggi con priorità warning o superiore relativi all'avvio corrente.
Per verificare le unità in errore:
systemctl --failed
Questi controlli sono utili per la diagnostica generale.
Per un'analisi di sicurezza completa, però, bisogna considerare anche i log specifici di SSH, web server, PHP, database e applicazioni.
In un ambiente con OpenLiteSpeed e Webuzo, è importante conoscere i percorsi effettivi dei log e le modalità di rotazione configurate.
Come individuare comportamenti anomali
Un sistema di monitoraggio può cercare schemi sospetti.
Per esempio, numerosi tentativi di autenticazione falliti seguiti da un login riuscito potrebbero richiedere una verifica.
Allo stesso modo, una modifica ai privilegi amministrativi effettuata in un orario insolito potrebbe essere rilevante.
È importante evitare di interpretare automaticamente ogni anomalia come un attacco.
Un sistema di sicurezza efficace deve ridurre i falsi positivi e fornire informazioni sufficienti per valutare gli eventi.
Gli alert dovrebbero essere utili e comprensibili, non semplicemente numerosi.
Come prepararsi a un incidente di sicurezza
I log diventano particolarmente importanti quando si verifica un incidente.
In questi casi è utile disporre di una procedura che permetta di raccogliere le informazioni senza alterare inutilmente le evidenze.
Bisogna verificare quali sistemi sono coinvolti, quali eventi sono stati registrati e se esistono segnali di attività non autorizzate.
È importante anche sincronizzare correttamente gli orologi dei server.
Timestamp incoerenti possono rendere molto difficile ricostruire una sequenza di eventi distribuita tra più servizi.
L'utilizzo di UTC nei log e di un servizio affidabile di sincronizzazione temporale facilita le analisi.
Security logging nelle applicazioni SaaS multi-tenant
Nelle piattaforme multi-tenant, il logging richiede un'attenzione aggiuntiva.
Gli eventi devono poter essere associati correttamente al tenant interessato, senza esporre informazioni di altri clienti.
È utile distinguere tra log tecnici interni e registri delle attività visibili agli amministratori delle singole organizzazioni.
Un amministratore potrebbe avere bisogno di consultare gli accessi e le modifiche effettuate dai propri collaboratori.
Non dovrebbe però poter accedere ai log di altri tenant.
Questo richiede controlli di autorizzazione applicati anche alle funzionalità di consultazione dei registri.
Come iniziare senza costruire un sistema troppo complesso
Per un piccolo progetto web, non è necessario introdurre immediatamente una piattaforma di monitoraggio enterprise.
Si può partire identificando gli eventi realmente importanti.
Successivamente, è utile adottare un formato coerente, proteggere i log e configurare alcuni alert.
Con la crescita dell'applicazione, il sistema potrà essere ampliato attraverso raccolta centralizzata, correlazione degli eventi e strumenti di analisi.
L'obiettivo non è registrare qualsiasi attività, ma disporre delle informazioni necessarie quando qualcosa richiede attenzione.
Conclusione
La sicurezza informatica non riguarda soltanto la capacità di prevenire gli attacchi.
Riguarda anche la possibilità di riconoscerli e comprenderne le conseguenze.
Un sistema di logging ben progettato aiuta a individuare attività sospette, ricostruire eventi e migliorare progressivamente le difese.
Ma i log devono essere pertinenti, protetti e gestiti nel rispetto della riservatezza dei dati.
La regola fondamentale è registrare gli eventi importanti, proteggerne l'integrità e trasformare le informazioni raccolte in controlli realmente utili.
Per approfondire puoi consultare la Logging Cheat Sheet di OWASP.
Con MiHakero puoi integrare il monitoraggio interno con un controllo della superficie di attacco esterna, individuando esposizioni e configurazioni che potrebbero richiedere ulteriori verifiche.
SEO Meta Title: Security logging: monitorare gli eventi di sicurezza
SEO Meta Description: Scopri quali eventi registrare, come proteggere i log e individuare attività sospette nelle applicazioni web e nei server Linux.