Booking, Eataly, Trenitalia: perché i dati erano in chiaro

Tre violazioni in pochi mesi, tre infrastrutture diverse, un solo punto cieco che si ripete. I dati anagrafici dei clienti erano conservati in chiaro. Quando l’attaccante ha superato il confine non ha trovato nessuna seconda barriera, ed è lì, non nel modo in cui è entrato, che si è deciso il danno.

In sintesi

• Booking, Eataly e Trenitalia hanno protetto bene password e dati di pagamento, e lasciato in chiaro tutto il resto: nomi, documenti d’identità, tratte, codici fiscali, storico acquisti.
• Un nome associato a un documento, a un viaggio reale o a un acquisto non è un dato neutro. È un profilo, cioè la materia prima del phishing su misura.
• Con Booking le truffe via WhatsApp sono partite in ore, prima che l’azienda completasse le notifiche ai clienti. Quando i dati sono in chiaro, la violazione non ha una data di chiusura.
• Per Trenitalia c’è un livello in più. Il trasporto ferroviario rientra tra i settori ad alta criticità dell’Allegato I della NIS2 (D.Lgs. 138/2024), dove cifratura e controllo degli accessi sono requisiti espliciti, con responsabilità diretta in capo ai vertici aziendali.
• Secondo il Verizon DBIR 2026, il coinvolgimento di terze parti nelle violazioni è salito al 48%, dal 30% dell’anno precedente. Ridurre il danno quando il perimetro cede è oggi urgente quanto prevenire l’intrusione.
• La protezione file-centric cifra il dato alla nascita. Anche superato il perimetro, resta illeggibile per chi non è autorizzato.

 

 

Cosa è successo, e perché i tre casi sono lo stesso caso

Lo scorso 12 aprile 2026 decine di migliaia di utenti Booking.com hanno ricevuto la notifica di un accesso non autorizzato ai loro dati: nomi, email, numeri di telefono, dettagli delle prenotazioni. Dati di pagamento esclusi, tutto il resto in chiaro. Ne ho scritto allora, ragionando sul perché proteggere i sistemi non basti se non si proteggono i dati (analisi anche su Finanza Flash).

Poche settimane dopo è toccato all’e-commerce di Eataly. Nomi, date di nascita, codici fiscali, indirizzi, storico degli acquisti, di nuovo leggibili senza alcun passaggio intermedio, come ho commentato su Wired. Poi Trenitalia, con i dati dei titoli di viaggio esposti: nome, cognome, data e luogo di nascita, contatti, tratte, estremi dei documenti d’identità, datore di lavoro.

Ogni volta la stessa linea di difesa nella comunicazione. Credenziali e pagamenti non sono stati toccati. È vero, ma è merito dell’architettura del sistema dei pagamenti che applica protezioni specifiche a questa tipologia di dati.

 

Perché un dato anagrafico in chiaro fa più danno di quanto sembri

Si guarda spesso alla violazione come a un evento circoscritto. È entrato qualcuno, ha preso qualcosa, si gestiscono le conseguenze. Ma quando i dati rubati sono in chiaro, l’incidente non ha una fine. Un nome associato a un indirizzo, a un documento, a una tratta percorsa o a un acquisto è un profilo. Un profilo è un vettore di phishing, e nelle mani giuste quel vettore diventa una campagna di frode che dura mesi.

Con Booking lo abbiamo visto in diretta. Messaggi WhatsApp che citavano il nome della struttura, la data del soggiorno, il numero di telefono corretto. Non phishing generico, ma frode credibile costruita sui dati reali della vittima. Trenitalia stessa, nella comunicazione ai clienti, invita a diffidare dei contatti che fanno riferimento ai viaggi effettuati. È l’anticipazione esatta di quello che sta per accadere. I dati rubati diventano lo script della truffa, e chi li riceve non ha modo di distinguerla da una comunicazione vera.

 

Il problema non è solo come l’attaccante è entrato

“Un accesso non autorizzato ad alcuni dati personali”. La formula ricorre in tutte e tre le comunicazioni, e dice molto. Quando chi entra raggiunge un archivio anagrafico, vuol dire che dentro al sistema quei dati erano accessibili a chi non avrebbe dovuto vederli. Il controllo degli accessi serve esattamente a questo: fare in modo che ogni file sia leggibile solo da chi ne ha titolo e che un account compromesso non apra l’intero database.

Se chi entra con una credenziale rubata o sfruttando una falla si ritrova davanti i record di migliaia di clienti in chiaro, il problema non è solo il punto di ingresso. Una volta dentro, non ha trovato nessuna seconda barriera: né permessi granulari sul singolo dato né cifratura che rendesse inutile ciò che riusciva a leggere. Il fattore umano resta il vettore principale. Secondo il Verizon DBIR 2026, l’elemento umano è presente nel 62% delle violazioni, e il coinvolgimento di terze parti è salito al 48%, raddoppiando rispetto al 30% dell’anno precedente. Ho approfondito l’importanza della crittografia nel contesto della DLP in questo articolo.

 

Trenitalia e la NIS2: un livello in più

Con Booking ed Eataly il discorso era di responsabilità verso i clienti. Con Trenitalia entra in gioco la norma. Il trasporto ferroviario rientra tra i settori ad alta criticità dell’Allegato I della NIS2, recepita in Italia con il D.Lgs. 4 settembre 2024 n. 138, e un operatore di quelle dimensioni è un soggetto essenziale. Significa obblighi rafforzati sulla gestione del rischio, sul controllo degli accessi, sull’uso della cifratura, sulla notifica degli incidenti, con responsabilità diretta dei vertici. La Determinazione ACN 127437 del 13 aprile 2026 ha ulteriormente spostato il baricentro dalla conformità dichiarata alla resilienza dimostrabile, con riferimento esplicito alla protezione dei dati nella supply chain. Su come la NIS2 cambia concretamente la gestione dei file condivisi abbiamo scritto una guida dedicata alla condivisione file sicura nel 2026, e su come questi requisiti si traducono in un sistema di gestione e modello organizzativo tra NIS2 e GDPR in un secondo approfondimento.

La notifica al Garante e al CSIRT Italia è stata fatta. Resta la domanda che la direttiva pone proprio su questo punto. Se cifratura e gestione degli accessi sono requisiti espliciti, perché i dati anagrafici dei clienti erano leggibili senza alcun passaggio intermedio una volta superato il confine?

 

Cosa succede ai dati quando l’accesso avviene comunque

Nessuna piattaforma che gestisce i dati di milioni di persone può garantire che nessuno entrerà mai. Non dipende dal budget, dalla competenza del team o dalla tecnologia adottata. È la natura delle infrastrutture connesse, e chi lavora nella sicurezza lo sa da anni. Proteggere il perimetro e monitorare gli accessi serve a ridurre la probabilità di un’intrusione. Ma se, dopo tutto questo, i dati al centro del sistema sono in chiaro, ogni misura perimetrale rimane una protezione parziale.

La domanda utile non è come impedire l’accesso, ma cosa succede ai dati quando l’accesso avviene comunque. Se il dato è cifrato nativamente, alla creazione, e resta illeggibile a chi non è autorizzato, la breccia diventa irrilevante. L’attaccante entra ma non trova nulla di utile. Quei messaggi WhatsApp con i dettagli reali delle prenotazioni non sarebbero stati possibili. L’attacco poteva anche riuscire, ma il contenuto sottratto sarebbe rimasto illeggibile fuori dal contesto autorizzato. È la logica della protezione data-centric. Non si difende l’uscita, si protegge il file alla nascita.

 

Come CyberGrant protegge il dato anche oltre il perimetro

La protezione data-centric di CyberGrant nasce da questa domanda. Invece di inseguire il dato lungo le vie di fuga, lo rende sicuro alla creazione, così che la protezione lo segua dovunque vada: sul PC, nel cloud, in mano a una terza parte, su un dispositivo remoto.

In pratica significa tre cose, applicate ai casi di cui abbiamo parlato.

Cifratura alla nascita, anche post-quantum. Il dato entra in un vault cifrato nativamente. La cifratura quantum-safe basata su CRYSTALS-Kyber, standard NIST (FIPS 203 / ML-KEM), risponde anche alla logica “harvest now, decrypt later”: chi raccoglie oggi dati cifrati sperando di decifrarli domani non trova nulla di utilizzabile. Un record anagrafico esfiltrato resta illeggibile fuori dal contesto autorizzato.

Controllo granulare degli accessi. RBAC e permessi sul singolo file fanno sì che un account compromesso non apra l’intero archivio. È la seconda barriera che è mancata a Booking, Eataly e Trenitalia.

Revoca post-condivisione e audit trail. Il proprietario del dato può revocare l’accesso anche dopo l’invio e ricostruire chi ha visto cosa e quando, requisito centrale per la gestione e la notifica degli incidenti richiesta dalla NIS2.

CyberGrant non sostituisce le difese perimetrali, si affianca a esse e copre ciò che il perimetro da solo non protegge. Approfondiamo questo approccio nel whitepaper DLP file-centric di CyberGrant. La cifratura dei dati a riposo non è un componente opzionale da rimandare a una roadmap futura. Per qualsiasi organizzazione che tratta dati personali su scala, è il presupposto minimo di responsabilità. Booking, Eataly e Trenitalia non sono casi limite. Sono il default, finché continua a valere l’assunto sbagliato.

 

FAQ

Cosa significa che i dati erano “in chiaro” dopo un data breach?

Significa che, una volta superato il perimetro, i record erano leggibili e immediatamente utilizzabili senza alcuna decifratura. Le password e i dati di pagamento di Booking, Eataly e Trenitalia erano protetti, i dati anagrafici (nomi, documenti, tratte, codici fiscali) no. Per questo sono diventati subito materia prima per il phishing.

Perché un nome e un indirizzo email sono pericolosi se rubati?

Perché combinati formano un profilo. Un profilo permette di costruire messaggi di phishing personalizzati che citano dettagli reali della vittima: un viaggio, una prenotazione, un acquisto. Questo rende la truffa difficile da distinguere da una comunicazione legittima. Con Booking le frodi via WhatsApp sono partite in poche ore dalla notifica ufficiale.

La cifratura dei dati anagrafici è obbligatoria per legge?

Nessuna norma impone un algoritmo specifico, ma entrambe le normative applicabili richiedono una protezione adeguata al rischio. Il GDPR (Reg. UE 2016/679, art. 32) considera la cifratura una misura adeguata per i dati personali. La NIS2 (D.Lgs. 138/2024) la rende un requisito esplicito per i soggetti essenziali, categoria in cui rientra Trenitalia come operatore ferroviario.

Cosa cambia con la protezione file-centric rispetto alle difese perimetrali?

La protezione perimetrale riduce la probabilità di un accesso non autorizzato. La protezione file-centric cifra il dato alla creazione e fa sì che la protezione lo segua ovunque, così che anche se il perimetro cade il file resta illeggibile per chi non è autorizzato. La differenza è tra gestire un rischio e togliere valore a ciò che l’attaccante riesce a portarsi via.

Quali obblighi NIS2 si applicano specificamente a Trenitalia come operatore ferroviario?

Il trasporto ferroviario è elencato tra i settori ad alta criticità nell’Allegato I della NIS2 (D.Lgs. 138/2024). Come soggetto essenziale, Trenitalia è soggetta a obblighi rafforzati che includono: cifratura dei dati in transito e a riposo, controllo degli accessi e gestione delle identità, audit trail e tracciabilità delle operazioni, sicurezza della supply chain. La Determinazione ACN 127437 del 13 aprile 2026 ha chiarito che la conformità deve essere dimostrabile con evidenze operative, non solo dichiarata. Le misure devono essere pienamente implementate entro ottobre 2026.

Cosa è la revoca post-condivisione e come avrebbe potuto cambiare l’esito di questi breach?

La revoca post-condivisione consente al proprietario di un file di revocarne l’accesso anche dopo che il file è stato condiviso o scaricato, anche se si trova su un sistema esterno. In un breach come quelli di Booking o Trenitalia, questo meccanismo consentirebbe di rendere inaccessibili immediatamente i dati già condivisi con terze parti. L’audit trail associato permette di ricostruire chi ha avuto accesso a ogni file e quando, informazione essenziale per la notifica obbligatoria al Garante e al CSIRT prevista dalla NIS2 e dal GDPR.

La protezione file-centric richiede di sostituire strumenti di lavoro già in uso come SharePoint o Teams?

No. FileGrant non sostituisce le piattaforme di collaborazione esistenti, si aggiunge a esse. La cifratura, il controllo degli accessi e la revoca post-condivisione seguono il file indipendentemente dal canale usato per condividerlo: email, Teams, link diretto. L’esperienza utente non cambia. Quello che cambia è che un account compromesso non apre più l’intero archivio.