Indice dei contenuti
- Il mito del logging come bene assoluto
- Quando i log diventano una superficie d’attacco
- Log contenenti token e sessioni: un rischio concreto
- PII nei log e implicazioni di compliance
- Attacchi post-breach e SIEM mal protetti
- Il costo reale della retention inutile
- Logging e architettura: una questione di design
- Verso un logging consapevole
Nel mondo della cyber security il logging è sempre stato considerato un bene assoluto. Più log significano più visibilità, più capacità di investigazione, più controllo. O almeno così ci siamo raccontati per anni. In realtà, la raccolta indiscriminata dei log sta diventando uno dei problemi più sottovalutati della sicurezza moderna.
Questo articolo analizza in profondità il logging eccessivo come nuova superficie d’attacco, mettendo in luce implicazioni reali su security, compliance e architettura dei sistemi. Non parliamo di teoria, ma di incidenti concreti, costi nascosti e rischi che spesso emergono solo dopo una violazione.
Il mito del logging come bene assoluto
Per anni il logging è stato trattato come una forma di assicurazione. Se qualcosa va storto, “almeno abbiamo i log”. Questa mentalità nasce in un’epoca in cui i sistemi erano più semplici, i dati meno sensibili e le normative sulla protezione delle informazioni molto meno stringenti. Oggi il contesto è radicalmente cambiato, ma il riflesso condizionato è rimasto lo stesso: loggare tutto, sempre e comunque.
In molti ambienti enterprise, soprattutto quelli cloud-native, il logging viene attivato in modo quasi automatico. Framework applicativi, librerie di terze parti, middleware e servizi di infrastruttura producono enormi quantità di dati senza che nessuno si ponga davvero la domanda fondamentale: perché stiamo loggando questa informazione? Il risultato è una crescita incontrollata di dati che spesso nessuno legge, ma che restano archiviati per mesi o anni.
Questo approccio nasce da una paura comprensibile: perdere informazioni utili in fase di incidente. Ma paradossalmente, l’eccesso di logging finisce per produrre l’effetto opposto. Troppi dati rendono più difficile individuare i segnali rilevanti, aumentano il rumore operativo e introducono nuovi rischi che spesso vengono ignorati fino a quando non è troppo tardi.
Quando i log diventano una superficie d’attacco
Ogni dato memorizzato è, per definizione, un potenziale obiettivo. I log non fanno eccezione, anzi: spesso contengono informazioni estremamente sensibili, proprio perché sono pensati per “dire tutto” su cosa sta succedendo in un sistema. Token di autenticazione, session ID, chiavi API, indirizzi email, numeri di telefono, riferimenti a documenti, dettagli di errori applicativi: tutto può finire nei log se non esiste una politica chiara di filtraggio.
In molti casi, i log non sono protetti allo stesso livello dei database primari. Vengono inviati a sistemi SIEM, piattaforme di osservabilità o storage centralizzati con controlli di accesso meno rigorosi. Questo crea una situazione pericolosa: un attaccante che riesce a compromettere il sistema di logging può ottenere una visione completa dell’infrastruttura, spesso più dettagliata di quella disponibile agli amministratori.
Il problema non è solo teorico. In diversi incidenti post-breach, gli attaccanti hanno sfruttato i log come fonte primaria di informazioni per muoversi lateralmente, impersonare utenti legittimi o ricostruire flussi di autenticazione. In questi scenari, il logging eccessivo non è stato un alleato della difesa, ma un moltiplicatore dell’impatto dell’attacco.
Log contenenti token e sessioni: un rischio concreto
Uno degli errori più comuni è la registrazione nei log di token di accesso o identificativi di sessione. Questo accade spesso durante lo sviluppo, quando i log servono per il debugging, ma rimane attivo anche in produzione.
Esempio
Il logging completo degli header HTTP, che possono contenere token JWT o cookie di sessione.
Dal punto di vista di un attaccante, questi dati sono oro puro. Un token valido può consentire l’accesso diretto a servizi protetti senza bisogno di forzare credenziali. Se i log sono accessibili, anche solo temporaneamente, il rischio di abuso è elevatissimo. In ambienti cloud, dove i log vengono spesso aggregati in sistemi centralizzati, una singola configurazione errata può esporre migliaia di token.
Il problema è aggravato dal fatto che molti sistemi di logging non sono progettati per la gestione di segreti. Non prevedono rotazione automatica, mascheramento o invalidazione dei dati sensibili. Una volta scritto il log, l’informazione resta lì, magari replicata in più sistemi di backup e retention, aumentando la finestra di esposizione.
PII nei log e implicazioni di compliance
Oltre agli aspetti di sicurezza pura, il logging eccessivo ha un impatto diretto sulla compliance normativa. I dati personali (PII) finiscono spesso nei log in modo accidentale: nomi, email, indirizzi IP associabili a persone fisiche, identificativi utente. In molti casi, nessuno si rende conto che questi dati sono stati raccolti, perché i log non vengono trattati come un vero e proprio datastore.
Dal punto di vista del GDPR e di altre normative sulla protezione dei dati, questo è un problema serio. Ogni dato personale deve avere una base giuridica, uno scopo chiaro e una durata di conservazione definita. I log, invece, vengono spesso conservati “per sicurezza”, senza una reale giustificazione e senza un piano di cancellazione. Questo espone le organizzazioni a sanzioni e contestazioni, soprattutto in caso di data breach.
Un aspetto spesso trascurato è il diritto alla cancellazione. Se un utente esercita il diritto all’oblio, come si gestiscono i suoi dati presenti nei log? Nella maggior parte dei casi, semplicemente non si gestiscono. Questo crea un disallineamento pericoloso tra le policy dichiarate e la realtà tecnica dei sistemi.
Attacchi post-breach e SIEM mal protetti
Un altro mito diffuso è che il SIEM sia automaticamente un ambiente sicuro. In realtà, molte piattaforme di Security Information and Event Management sono accessibili da reti interne ampie, integrate con numerosi sistemi e gestite da team diversi. Questo le rende un obiettivo interessante dopo una prima compromissione.
In diversi incidenti, gli attaccanti hanno utilizzato il SIEM come strumento di ricognizione. Analizzando i log, hanno potuto capire quali sistemi esistono, quali utenti sono attivi, quali errori si verificano e quali tentativi di accesso vengono registrati. In pratica, il sistema pensato per monitorare la sicurezza diventa una mappa dettagliata dell’infrastruttura.
Il problema è accentuato quando il SIEM conserva log molto dettagliati per lunghi periodi. Più dati sono disponibili, più facile è per un attaccante ricostruire eventi passati e identificare pattern utili per futuri attacchi. Questo ribalta completamente la narrativa tradizionale del logging come strumento difensivo.
Il costo reale della retention inutile
Oltre ai rischi di sicurezza e compliance, il logging eccessivo ha un costo economico spesso sottovalutato. Storage, indicizzazione, licenze SIEM basate sul volume di dati, risorse di calcolo per l’analisi: tutto questo ha un impatto diretto sul budget IT. In molti casi, una percentuale significativa dei costi di sicurezza è legata alla gestione di log che non vengono mai consultati.
Ma il costo non è solo economico. Esiste anche un costo operativo. I team SOC si trovano sommersi da alert e informazioni, con una difficoltà crescente nel distinguere i segnali realmente importanti. Questo fenomeno, noto come “alert fatigue”, riduce l’efficacia complessiva della difesa e aumenta il rischio che un incidente reale passi inosservato.
In questo senso, il logging eccessivo non è solo inefficiente, ma controproducente. Più dati non significano automaticamente più sicurezza. Spesso significano solo più rumore.
Logging e architettura: una questione di design
Affrontare il problema del logging eccessivo richiede un cambio di prospettiva architetturale. Il logging non dovrebbe essere un sottoprodotto automatico del sistema, ma una componente progettata con la stessa attenzione riservata ad altri aspetti critici. Questo significa definire chiaramente cosa loggare, a che livello di dettaglio e per quanto tempo.
Un approccio maturo prevede la classificazione dei log in base al loro valore e alla loro sensibilità. Non tutti i log hanno la stessa importanza. Alcuni sono fondamentali per la sicurezza, altri solo per il debugging temporaneo. Trattarli allo stesso modo è un errore di design. È necessario introdurre livelli di logging, politiche di mascheramento e meccanismi di retention differenziata.
Dal punto di vista architetturale, è anche importante separare i flussi di log operativi da quelli di sicurezza. Mescolare tutto in un unico sistema aumenta il rischio e la complessità. Una progettazione più granulare consente di applicare controlli di accesso più rigorosi e di ridurre l’esposizione dei dati sensibili.
Verso un logging consapevole
Il vero valore del logging emerge quando viene usato in modo consapevole. Questo significa accettare che non tutto deve essere registrato e che la perdita di alcuni dettagli è un compromesso accettabile rispetto ai rischi introdotti. Un logging efficace è selettivo, mirato e allineato agli obiettivi di sicurezza e compliance.
In pratica, questo approccio richiede collaborazione tra sviluppatori, architetti e team di sicurezza. I log non devono essere decisi solo in fase di sviluppo o solo dal SOC. Devono essere il risultato di una strategia condivisa, basata su una valutazione reale dei rischi. Solo così il logging può tornare a essere uno strumento di difesa, invece che una vulnerabilità silenziosa.
Conclusione
Il problema invisibile dei log è uno dei paradossi della cyber security moderna. Ciò che per anni abbiamo considerato un bene assoluto sta diventando, se non gestito correttamente, un rischio significativo. Il logging eccessivo amplia la superficie d’attacco, complica la compliance e introduce costi nascosti che spesso emergono solo dopo un incidente.
Ripensare il logging non significa rinunciare alla visibilità, ma renderla sostenibile e sicura. In un contesto in cui ogni dato può essere un’arma a doppio taglio, la vera maturità sta nel saper scegliere cosa non registrare.
Domande e risposte
- Cos’è il logging eccessivo?
È la pratica di registrare grandi quantità di dati senza una reale valutazione del loro valore o dei rischi associati. - Perché il logging può diventare un rischio di sicurezza?
Perché i log possono contenere informazioni sensibili utili a un attaccante in caso di compromissione. - I log possono contenere dati personali?
Sì, spesso includono PII come email, indirizzi IP e identificativi utente. - Qual è il legame tra logging e GDPR?
I log sono soggetti alle stesse regole di protezione dei dati personali previste dal GDPR. - Un SIEM è sempre sicuro?
No, se mal configurato può diventare un obiettivo privilegiato per attacchi post-breach. - Perché conservare i log costa così tanto?
I costi includono storage, licenze, risorse di analisi e gestione operativa. - È meglio loggare meno?
È meglio loggare in modo selettivo e consapevole, non semplicemente meno. - Come evitare token nei log?
Implementando mascheramento, filtri e controlli a livello applicativo. - Chi dovrebbe decidere cosa loggare?
Una decisione condivisa tra sviluppo, sicurezza e architettura. - Il logging consapevole riduce la sicurezza?
No, se progettato bene aumenta l’efficacia della sicurezza riducendo rumore e rischi.
