Perché la violazione a Trenitalia preoccupa gli esperti cyber

Trenitalia ha comunicato oggi con una mail ai clienti coinvolti un incidente di sicurezza che soggetti esterni non identificati hanno ottenuto un accesso non autorizzato ad alcuni dati personali legati ai titoli di viaggio.

L’attacco risale a ottobre, comunica l’azienda; ma solo ora è riuscita a risalire alle vittime.

Credenziali di accesso e dati di pagamento, scrive l’azienda, non sono stati toccati. Tutto il resto sì.

Violazione dati Trenitalia: cosa è stato esposto

Vale la pena leggere l’elenco di “tutto il resto”, perché è lì che si misura la portata reale di questa violazione. Nome, cognome, data e luogo di nascita del passeggero, e in molti casi anche dell’acquirente dei biglietti. Email e numero di telefono. Tratta, data e orario del viaggio, numero del titolo. Estremi del documento d’identità. Datore di lavoro. Codice della carta fedeltà. Presi singolarmente sono frammenti. Messi insieme, sono un profilo: chi sei, dove vai, quando ti muovi, per chi lavori, con quale documento ti identifichi. Un attaccante non ha bisogno della tua carta di credito quando ha tutto questo.

“Trenitalia ha immediatamente attivato tutte le misure di sicurezza necessarie. Solo al termine di verifiche tecniche è stato possibile procedere con le comunicazioni individuali previste dalla normativa vigente”, scrive l’azienda.

“Trenitalia ha provveduto a notificare l’accaduto all’Autorità Garante per la Protezione dei Dati Personali e agli organi competenti, oltre a presentare denuncia alla Procura della Repubblica presso il Tribunale di Roma, collaborando pienamente con le Autorità”.

Mail Trenitalia e rischi per i clienti coinvolti

La comunicazione di Trenitalia è una notifica all’interessato ai sensi dell’art. 34 del GDPR, l’articolo che scatta quando una violazione comporta un rischio elevato per i diritti e le libertà delle persone. Non è un atto di cortesia, è un obbligo che si attiva solo quando il danno potenziale è concreto. E il danno, qui, ha una forma precisa.

Dal GDPR al phishing su misura

Dati come questi non restano fermi. Finiscono su forum e mercati del dark web, dove vengono venduti e incrociati con altre fughe già in circolazione. Da quel momento alimentano una frode che funziona perché è credibile. Chi ti scrive non manda più il messaggio generico con gli errori di ortografia. Ti cita il treno che hai preso davvero, la tratta esatta, la data. Trenitalia stessa, nella comunicazione, avverte di diffidare da contatti che fanno riferimento ai propri viaggi. È l’ammissione più onesta del problema: l’azienda sa che quei dati diventeranno lo script di un phishing su misura, e che il cliente avrà pochissimi strumenti per distinguerlo da una comunicazione autentica.

Il rischio non è teorico, e non scade con la notifica. Un profilo anagrafico non si può cambiare come una password. Resta sfruttabile per mesi, per anni.

NIS2 e trasporto ferroviario: gli obblighi per Trenitalia

Il trasporto ferroviario rientra tra i settori ad alta criticità dell’Allegato I della NIS2, recepita in Italia con il D.lgs. 138/2024. Un operatore della scala di Trenitalia è un soggetto essenziale, la categoria con gli obblighi più stringenti e la vigilanza più intensa. La direttiva impone, tra le misure minime, politiche per l’uso della crittografia e procedure rigorose per il controllo degli accessi ai dati sensibili. Dal 1° gennaio 2026 l’obbligo di notifica degli incidenti è pienamente operativo, con la prima segnalazione al CSIRT entro 24 ore. E con la NIS2 la responsabilità non resta nel reparto IT: ricade direttamente sugli organi di vertice, che rispondono in prima persona.

Notifiche, Garante e CSIRT Italia

Trenitalia ha notificato al Garante e allo CSIRT Italia, e ha sporto denuncia. Sul piano procedurale ha fatto ciò che la norma chiede. Resta però la domanda che la NIS2 pone esattamente su questo punto, perché la cifratura dei dati sensibili è scritta tra i suoi requisiti minimi: se l’attaccante è riuscito a leggere dati anagrafici, documenti e contatti in chiaro una volta entrato, dov’era la protezione del dato in quanto dato?

Cifratura dei dati Trenitalia: il nodo dopo l’accesso

Qui non si tratta di budget, né di sofisticazione dell’attacco. Si tratta di un’assunzione che il settore continua a dare per buona: che basti difendere il confine. Si investe nel tenere fuori gli estranei (firewall, segmentazione, autenticazione) e si tratta il dato che sta dentro come se fosse già al sicuro per il solo fatto di trovarsi dentro. Ma il confine, prima o poi, qualcuno lo supera. Con una credenziale rubata, con una falla in un fornitore, con una tecnica nuova. Nel momento in cui accade, il perimetro smette di esistere, e l’unica cosa che decide la gravità dell’incidente è lo stato in cui l’attaccante trova i dati.

Se li trova in chiaro, il danno si propaga in poche ore: i record sono già pronti per essere venduti e usati. Se invece il dato è cifrato dalla sua nascita, e quella cifratura lo accompagna ovunque vada (nel database, in una copia, in un file esportato), allora chi entra si porta via byte illeggibili. La protezione, in questo modello, non è un muro intorno ai dati. È una proprietà del dato stesso, che viaggia con lui come se ogni singolo file avesse un firewall cucito addosso. La sicurezza non sta più nel chiudere l’accesso: sta nel fare in modo che ciò che viene preso non serva a niente.

È la differenza tra proteggere l’edificio e proteggere ciò che custodisce. La prima logica ha fatto il suo tempo, non perché sia sbagliata, ma perché in un mondo dove i dati si muovono di continuo non è più sufficiente da sola. La seconda è l’unica che regge quando il confine cede. L’incidente Trenitalia non è un caso eccezionale. È la dimostrazione, ennesima, che la domanda giusta non è solo “come teniamo fuori gli attaccanti”, ma “cosa trovano il giorno in cui entrano”.