Cold Case Santander: come 30 milioni di clienti sono finiti in vendita per un database di un fornitore

Madrid, metà maggio 2024. Banco Santander pubblica un comunicato breve. La banca conferma un accesso non autorizzato a un database ospitato non sui propri server, ma in mano a un fornitore esterno. Due settimane dopo, su un forum del dark web, qualcuno mette in vendita milioni di record clienti.

Cosa portare a casa in 30 secondi

• Il breach Santander del maggio 2024 non è partito dai server della banca, ma dal database di un fornitore cloud privo di autenticazione multifattore obbligatoria. La responsabilità normativa, però, è rimasta tutta del titolare del trattamento.
• Secondo il Verizon DBIR 2026, il coinvolgimento di terze parti nei breach è salito al 48%, dal 30% dell'anno precedente: un aumento del 60% dopo un raddoppio già registrato l'anno prima.
• Sempre il DBIR 2026 rileva che le credenziali compaiono nel 28% dei breach: una password rubata da un infostealer, senza un secondo livello, è una porta aperta sul cloud di un fornitore.
• Nessun firewall e nessun DLP perimetrale entra in gioco quando una credenziale legittima si autentica su un cloud terzo: il dato è già fuori dal perimetro.
• La protezione file-centric ribalta la domanda: non "come blocco l'accesso", ma "cosa rendo inutile se l'accesso passa lo stesso". Un file cifrato alla nascita resta illeggibile anche dopo l'esfiltrazione.

Santander è la prima banca spagnola e una delle dieci più grandi al mondo per capitalizzazione: 200.000 dipendenti, oltre 8.500 filiali, più di 165 milioni di clienti. Il 14 maggio diffonde una nota in cui ammette che un terzo non autorizzato ha avuto accesso a un database ospitato da un fornitore, e che l'incidente riguarda principalmente clienti di Spagna, Cile e Uruguay. Nelle settimane successive emerge che sono colpiti anche dipendenti negli Stati Uniti, con codice fiscale (SSN) e dati bancari del payroll esposti.

Il 30 maggio il gruppo cybercriminale ShinyHunters pubblica su BreachForums un'inserzione: 30 milioni di record clienti, 28 milioni di numeri di carta, 6 milioni di numeri di conto e saldi, dati di cittadinanza, liste HR. Prezzo richiesto: 2 milioni di dollari. La cifra dei 30 milioni resta discussa, perché il financial report del primo trimestre 2024 dichiara meno di 20 milioni di clienti nei paesi colpiti. La sostanza non cambia: per settimane la banca non sa con precisione cosa sia uscito.

L'incidente non è isolato. Le ricostruzioni successive lo collegano a una campagna molto più ampia: oltre 160 organizzazioni clienti della piattaforma cloud Snowflake hanno subito accessi alle proprie istanze sfruttando credenziali rubate da infostealer e configurazioni che non imponevano l'autenticazione multifattore. Tra le altre vittime documentate, AT&T, Ticketmaster, LendingTree, Advance Auto Parts.

Dove ha ceduto la governance del dato?

Il punto di rottura non è dentro Santander. È in un database tenuto da un fornitore SaaS. La responsabilità normativa, però, è rimasta tutta della banca. Sono cinque le falle visibili.

MFA assente sui tenant del fornitore cloud. Il fornitore offriva l'autenticazione multifattore come opzione, non come default obbligatorio. Le credenziali di accesso al tenant sono finite nei cataloghi di infostealer (Lumma, RisePro, RedLine) venduti tra 1.000 e 3.000 dollari. Senza MFA, una credenziale rubata è una chiave universale. Il principio Zero Trust, lato cliente, non era applicato.

Articolo 28 GDPR ignorato nella sostanza. Il fornitore cloud opera come responsabile del trattamento. La banca, in quanto titolare, mantiene la responsabilità totale sui dati personali ospitati altrove. Il contratto di outsourcing avrebbe dovuto imporre requisiti minimi di sicurezza tecnica e organizzativa (MFA, segregazione, audit periodici, notifica nei tempi dell'art. 33 GDPR) e una verifica effettiva, non solo dichiarazioni di compliance.

Nessuna segregazione per geografia e finalità. Il database conteneva clienti di tre paesi e dipendenti di un quarto in un'unica istanza. Il principio di minimizzazione (art. 5 GDPR) richiede di limitare la conservazione al necessario per la finalità. Concentrare milioni di soggetti in un solo asset, accessibile da credenziali singole, amplifica per ordini di grandezza il raggio di compromissione.

DORA applicato in ritardo. Il Digital Operational Resilience Act (Reg. UE 2022/2554) è diventato pienamente applicabile il 17 gennaio 2025, mesi dopo l'incidente. Il testo del 2022, però, descriveva già esattamente lo scenario Santander: registro dei fornitori ICT critici, valutazione preliminare, monitoraggio continuo, exit strategy. Lo stesso impianto è ribadito in Italia dalla Circolare 285 di Banca d'Italia su data governance e outsourcing.

Visibilità nulla sulla mappatura dei dati personali. Il primo presidio normativo consiste nel sapere cosa c'è, dove sta, chi vi accede. Nel caso Santander la disclosure iniziale parlava di alcuni clienti, la dichiarazione successiva includeva dipendenti USA, l'inserzione del criminale parlava di 30 milioni di record. Tre stime diverse in due settimane: la banca non aveva la fotografia di cosa il fornitore custodisse per suo conto.

Per dimensionare il rischio, due numeri dalle edizioni più recenti. Il Verizon DBIR 2026 porta il coinvolgimento delle terze parti nei breach al 48%, dal 30% dell'anno prima. L'IBM Cost of a Data Breach 2025 registra una media globale del breach di 4,44 milioni di dollari, in calo dell'anno precedente, con il settore healthcare al primo posto per costo (7,42 milioni di dollari). Il finance resta tra i settori più esposti per valore del dato trattato, anche quando non guida la classifica del costo medio.

Perché il DLP tradizionale non avrebbe fermato nulla?

L'incidente Santander è un caso da manuale di DLP perimetrale che fallisce. Nessun firewall, nessun antivirus, nessuna rete protetta entra in gioco quando una credenziale legittima si autentica su un cloud terzo. Il dato è già fuori dal perimetro.

La domanda corretta non è "come blocco l'accesso", ma "cosa rendo inutile se l'accesso passa lo stesso". È lo spostamento che separa la protezione perimetrale da quella file-centric: non si protegge l'uscita, si protegge il file alla nascita. La piattaforma CyberGrant si affianca alla dotazione esistente della banca e risponde proprio a questo schema.

FileGrant: il dato cifrato resta dato inutile

FileGrant porta il documento dentro un vault cifrato nativamente con tecnologia Lock&Go quantum-proof (CRYSTALS-Kyber, standard NIST post-quantum FIPS 203). La protezione segue il file: dentro la banca, fuori, sul cloud di un fornitore, condiviso con un terzo. Anche quando il file viene esfiltrato dall'ambiente del responsabile esterno, esce in formato cifrato e resta tale.

Gli stessi record offerti su BreachForums sarebbero stati ottenibili anche con FileGrant attivo, ma sarebbero stati inutilizzabili. La vera misura di sicurezza non è bloccare l'accesso, è fare in modo che ciò che viene preso non serva a niente. Un file cifrato esfiltrato non è un breach commerciale, è un blocco di byte privo di valore di mercato.

Il vettore d'ingresso del caso Santander è una credenziale rubata e riutilizzata. Il modulo SecretGrant di FileGrant tratta le credenziali aziendali, comprese quelle usate per autenticarsi sui fornitori esterni, come un asset di sicurezza pari ai documenti: vault cifrato, segregazione per ruolo, accesso solo a chi ha permessi espliciti. Per i tenant cloud dei responsabili del trattamento la policy può imporre rotazione automatica, scadenza programmata, password aggiuntiva per le credenziali critiche, log di ogni accesso. Una credenziale finita in un infostealer non basta più, perché il livello successivo non è negoziabile dall'utente.

AIGrant: la banca sa cosa ha, dove sta e chi lo legge

Il punto cieco del caso è la mappatura. Nessuno, dentro la banca, sapeva in tempo reale quanti record sensibili stessero in quel database, di quali soggetti, con quali categorie particolari. AIGrant è una AI privata on-premise che indicizza, classifica e tagga automaticamente i documenti aziendali in base al contenuto: tagga per livello di riservatezza, segrega per reparto, traccia chi accede a cosa, segnala pattern di consultazione anomali per volume, orario o geografia.

AIGrant blocca anche lo scraping automatico da parte di AI pubbliche. Nel banking, dove posta elettronica e strumenti collaborativi sono pieni di dati personali, questo significa che un dipendente che incolla un dataset per farsi aiutare con un'analisi non riesce ad alimentare un LLM esterno. La banca smette di scoprire dopo l'incidente cosa il fornitore custodiva: lo sa prima, in modo automatico e classificato.

Lo scenario alternativo con CyberGrant attivo

• L'accesso al database del fornitore richiede credenziali nel vault SecretGrant, con MFA forzato e password aggiuntiva, non sottratte da un infostealer su un laptop personale.
• I record sono cifrati con Lock&Go all'origine: l'esfiltrazione massiva produce byte illeggibili senza la chiave master detenuta on-premise dalla banca.
• AIGrant classifica automaticamente il livello di riservatezza e segnala consultazioni anomale prima che il danno si propaghi.
• Verso il Garante e l'EBA ai fini DORA, la banca documenta con audit trail granulare il chi-quando-cosa di ogni asset. La notifica ex art. 33 GDPR diventa fattuale, non stimata.

CyberGrant non elimina i rischi. Li trasforma in controllo e consapevolezza.

Cosa deve cambiare nella testa di un CISO bancario

1. La responsabilità non si delega al fornitore. Si delega l'operatività, non l'obbligo. L'art. 28 GDPR è inequivocabile e DORA, in vigore dal 17 gennaio 2025, lo amplifica con registro dei fornitori ICT critici, contratti standard, monitoraggio continuo. Se il fornitore sbaglia, il sanzionato è il titolare.
2. MFA non è un'opzione contrattuale, è un default contrattuale. Ogni accordo con un responsabile che custodisce dati personali deve imporre MFA obbligatoria, segregazione per geografia, rotazione credenziali, audit periodici. Una clausola che recita "il fornitore implementa misure adeguate" non basta.
3. La protezione viaggia con il dato, non con la rete. Il perimetro logico della banca finisce alla prima riga di codice del fornitore. Tutto ciò che sta nel cloud di un responsabile deve essere cifrato nativamente alla nascita. Se non lo è, il breach è una questione di tempo.
4. Visibilità prima di compliance. Non si rispetta l'art. 5 GDPR se la banca non sa cosa ci sia nei suoi repository, anche presso terzi. La mappatura dei dati personali è il prerequisito, non il deliverable finale.

Domande frequenti

Chi è responsabile quando il breach avviene sul cloud di un fornitore?

La responsabilità normativa resta del titolare del trattamento, cioè la banca, anche quando i dati sono fisicamente ospitati da un fornitore che agisce come responsabile ex art. 28 GDPR. L'outsourcing trasferisce l'operatività, non l'obbligo di protezione. Per il settore bancario, DORA (Reg. UE 2022/2554) e la Circolare 285 di Banca d'Italia impongono inoltre registro dei fornitori ICT critici e monitoraggio continuo.

Un DLP tradizionale avrebbe fermato il breach Santander?

No. Il DLP perimetrale e i firewall non intervengono quando una credenziale legittima si autentica su un cloud di terze parti: il dato è già fuori dal perimetro aziendale. La protezione efficace in questo scenario è file-centric, cioè vive nel file stesso tramite cifratura nativa che persiste anche dopo l'esfiltrazione.

Cosa significa protezione file-centric in ambito bancario?

Significa cifrare il dato alla creazione, così che la protezione lo segua ovunque vada: sui server della banca, sul cloud di un fornitore, su un dispositivo remoto, condiviso con un terzo. Un file esfiltrato resta cifrato e illeggibile senza la chiave, custodita dalla banca. La sicurezza non si misura sul bloccare l'accesso, ma su cosa resta in mano a chi accede.

Perché la crittografia post-quantum è rilevante per una banca oggi?

Per la logica "harvest now, decrypt later": un attaccante può esfiltrare oggi dati cifrati e decifrarli in futuro, quando i computer quantistici renderanno vulnerabili gli algoritmi attuali. I dati bancari hanno un ciclo di vita lungo. CyberGrant cifra con CRYSTALS-Kyber, l'algoritmo riconosciuto dal NIST come standard post-quantum (FIPS 203, ML-KEM), per proteggere il dato anche da questa minaccia differita.

Come si dimostra la compliance dopo un incidente che coinvolge un fornitore?

Serve un audit trail granulare che documenti chi ha avuto accesso a quale dato, quando e da dove. Con questa tracciabilità, la notifica del data breach ex art. 33 GDPR e gli obblighi di segnalazione DORA si fondano su fatti verificabili, non su stime. La classificazione automatica del livello di riservatezza permette inoltre di sapere prima dell'incidente cosa è esposto.