Il ransomware che il 7 ottobre ha fermato una regione di IDCF Cloud è entrato dal sistema di autenticazione del portale clienti e ha preso il controllo della piattaforma di virtualizzazione. Per l’Italia, che ha appena portato in cloud tredicimila amministrazioni, la lezione riguarda l’unità di guasto: non il data center, ma il piano di controllo.
Indice degli argomenti
L’attacco IDCF e la fragilità dei backup cloud
Alle 3:40 del 7 ottobre i server virtuali di quattro zone della Regione Est Giappone 1 di IDCF Cloud, il servizio di IDC Frontier, società del gruppo SoftBank, hanno smesso di rispondere. In giornata l’azienda ha comunicato che si trattava di un attacco ransomware e che i clienti coinvolti erano 495, tra imprese ed enti locali. Il sito della prefettura di Ibaraki è andato giù alle quattro, quello della sua polizia alle dieci.
Il giorno dopo IDC Frontier ha scritto che i dati nelle zone colpite difficilmente sarebbero stati recuperabili e che il ripristino era possibile soltanto dai backup conservati dai clienti. Un messaggio attribuito agli attaccanti sosteneva che cifrare l’intera regione avesse richiesto «esattamente sette minuti» e rivendicava la distruzione di oltre 550.000 snapshot. Sono affermazioni non verificate: l’azienda ha detto di aver visto immagini compatibili con la propria console, senza confermarne i numeri.
Il 27 ottobre IDC Frontier ha pubblicato il rapporto conclusivo. Gli attaccanti hanno sfruttato la vulnerabilità di un software open source usato dal sistema di autenticazione del portale clienti; da lì, attraverso la console di gestione, hanno ottenuto i privilegi di amministratore sulla piattaforma di virtualizzazione e hanno fermato e cifrato i server. Non risultano esfiltrazioni dai server virtuali. I dati di backup si sono rivelati recuperabili per 206 clienti su 495; gli altri sono stati accompagnati verso ambienti alternativi. L’azienda dichiara di non aver pagato né trattato.
Il piano di controllo dietro il rischio dei backup cloud
Il dettaglio decisivo è il percorso. Non c’è stato un guasto fisico, né un data center perso. L’attaccante ha conquistato lo strato che governa tutte le macchine, cioè portale, identità e console, e da lì ha agito su quattro zone in una volta. Lo conferma anche la reazione: nelle prime ore l’azienda ha sospeso per precauzione le console di gestione raggiungibili dall’esterno anche nelle regioni non colpite. In un cloud l’unità di guasto non è il data center, ma il piano di controllo che li amministra tutti.
Ridondanza geografica, siti gemelli e certificazioni di livello Tier IV proteggono da incendi, blackout e guasti hardware. Contro chi possiede le credenziali di amministrazione sono indifferenti: le copie replicate in un’altra zona sono raggiungibili dalla stessa console, e un amministratore legittimo, o chi ne ha preso il posto, può cancellarle come qualunque altra risorsa.
Gli snapshot di IDCF erano una funzione della piattaforma, gestita dalla piattaforma. Per questo, nei primi giorni, il fornitore non è stato in grado di dire ai clienti se le loro copie esistessero ancora: la risposta è arrivata una settimana dopo, e per meno della metà di loro.
Le condizioni contrattuali, per come le ha ricostruite la stampa specializzata giapponese, spiegano il resto. Le specifiche del servizio attribuiscono al cliente la responsabilità dei propri backup. Lo SLA promette il 99,999% di disponibilità mensile, ma esclude gli attacchi esterni e limita i rimborsi al 10% del canone delle macchine interessate. Le condizioni generali escludono la responsabilità per accessi non autorizzati che non si potevano prevenire con la dovuta diligenza, salvo dolo o colpa grave.
Chi aveva copie altrove ha ripartito in fretta: Six Apart, che conservava sette generazioni di backup su un altro cloud, ha trasferito i suoi 31 server presso un fornitore diverso entro la sera dell’8 ottobre. Chi si era affidato agli snapshot del fornitore ha aspettato di sapere se c’erano ancora.
Cloud della PA e concentrazione dei piani di controllo
A luglio il Dipartimento per la trasformazione digitale ha annunciato il raggiungimento degli obiettivi del PNRR sulla migrazione al cloud: circa tredicimila amministrazioni hanno completato il percorso. Oltre 280 tra amministrazioni centrali, aziende sanitarie e ospedaliere sono migrate sul Polo Strategico Nazionale; più di 12.700 comuni, enti locali e scuole su servizi cloud qualificati.
La logica era chiara e in buona parte giusta. Il censimento AgID del 2020 aveva contato 1.252 data center pubblici, quasi tutti carenti per sicurezza, affidabilità o efficienza. Concentrare su infrastrutture qualificate significa sostituire centinaia di sale server improvvisate con poche infrastrutture difese da professionisti.
Il precedente Westpole e il rischio comune
La concentrazione, però, cambia la natura del rischio: mille piccoli guasti indipendenti diventano la possibilità di un guasto comune. L’Italia lo ha già visto. Nel dicembre 2023 il ransomware che ha colpito Westpole, il fornitore dell’infrastruttura su cui PA Digitale erogava i propri servizi, ha fermato per una decina di giorni protocollo, anagrafe, albo pretorio, pagamenti online e stipendi in centinaia di enti: PA Digitale serviva circa 1.300 amministrazioni, tra cui 540 comuni.
Il ripristino è avvenuto dai backup, ma a ridosso della ripartenza l’ACN segnalava che per circa mille enti restavano da recuperare i dati dei tre giorni precedenti l’attacco.
Le regole italiane e la dipendenza dai fornitori
Il quadro regolatorio italiano valuta la sicurezza fornitore per fornitore. Il Regolamento unico per le infrastrutture digitali e i servizi cloud della PA, adottato con il decreto direttoriale n. 21007 del 27 giugno 2024, qualifica i servizi su quattro livelli, da QC1 a QC4, in funzione della classificazione di dati e servizi, ordinari, critici o strategici, che ogni amministrazione deve comunicare.
Ogni qualificazione risponde alla domanda se un servizio sia abbastanza sicuro per certi dati. Nessuna risponde alla domanda successiva: quante amministrazioni dipendono dallo stesso piano di controllo, dalla stessa console, dallo stesso sistema di identità? E la dipendenza reale può stare due livelli sotto quella contrattuale.
Il comune firma con il fornitore del software, il fornitore del software gira sull’infrastruttura di un altro: così era per Westpole, così per diversi servizi giapponesi fermati dal caso IDCF, tra cui quelli di una compagnia ferroviaria e di una catena di grandi magazzini, coinvolte attraverso fornitori esterni senza avere un contratto con IDC Frontier.
Il settore finanziario questa domanda se l’è già posta. Il regolamento DORA chiede a banche e assicurazioni di valutare il rischio di concentrazione verso i fornitori ICT (art. 29) e di tenere un registro di tutti gli accordi con loro; nel novembre 2025 le autorità europee di vigilanza hanno designato i fornitori ICT critici, ora sottoposti a sorveglianza diretta a livello europeo. Per il cloud della pubblica amministrazione, che ospita anagrafi, sanità e stipendi, una visione d’insieme delle dipendenze non è prevista dalle regole.
Perché il backup del fornitore cloud può non bastare
Il Polo Strategico Nazionale, va detto, dichiara la distribuzione su quattro data center in due regioni, Lazio e Lombardia, la replica per il disaster recovery e un servizio di protezione dei dati con una golden copy mensile analizzata per scovare malware dormiente. Sono misure serie.
La domanda che il caso IDCF impone è diversa ed è la stessa per ogni fornitore qualificato: chi ha i privilegi di amministrazione sulla piattaforma può cancellare o cifrare anche le copie? Il servizio di backup del PSN, per come è descritto pubblicamente, si gestisce da una console centralizzata. Se quella console vive nello stesso dominio di amministrazione della produzione, la copia protegge dal guasto ma non dall’avversario. Non è un giudizio sul PSN, i cui dettagli architetturali non sono pubblici: è il criterio con cui ogni amministrazione dovrebbe leggere il proprio contratto.
Copie separate e ripristino per il backup cloud della PA
Le misure sono alla portata. La prima riguarda la definizione stessa di backup: una copia conta come backup solo se sta fuori dal dominio amministrativo del fornitore che gestisce la produzione, presso un altro fornitore o su un’infrastruttura propria, con credenziali che nessuno nel fornitore primario possiede, e non modificabile per un periodo definito.
La seconda è provare il ripristino in quell’ambiente separato, non limitarsi a verificare che la copia esista: il caso IDCF mostra che la domanda «dove ricostruisco?» va risolta prima dell’incidente.
La terza è di sistema. L’ACN riceve già da ogni amministrazione l’elenco e la classificazione di dati e servizi; aggregare quelle informazioni per fornitore, piattaforma e piano di controllo, sul modello del registro previsto da DORA, permetterebbe di vedere i punti unici di guasto prima che li trovi un attaccante.
Anche la qualificazione potrebbe porre una domanda esplicita sulla separazione tra chi amministra la produzione e chi custodisce le copie.
Identità esterna, MFA e SBOM dopo l’attacco
IDC Frontier ricostruirà il portale con un fornitore di identità esterno, autenticazione a più fattori e accesso limitato agli indirizzi dei clienti, e introdurrà una SBOM aziendale per incrociare i componenti con le vulnerabilità note. Sono le misure giuste, prese dopo. La migrazione al cloud ha tolto a migliaia di comuni italiani la sala server sotto le scale; non ha tolto loro il bisogno di una copia che il fornitore non può toccare.
Partecipa alla community