Il 3 marzo 2026 ci siamo svegliati con una frase che, fino a ieri, sembrava appartenere più a un wargame che a un bollettino tecnico: due data center AWS negli Emirati Arabi Uniti “colpiti direttamente” da droni, con danni strutturali e interruzione dell’energia. Un terzo sito in Bahrain avrebbe subito effetti di un attacco nelle vicinanze, con impatti fisici alle infrastrutture.
Non è solo “un outage”. È un cambio di fase.
Perché quando il cloud va in crisi, tendiamo a pensarla così: incident, post-mortem, patch, e via. Un problema di affidabilità. Un tema di cybersecurity. Qualcosa che si risolve con ridondanza logica, procedure, certificazioni.
E invece qui la domanda è più brutale: cosa succede quando il data center entra nello scenario di guerra come bersaglio fisico?
Indice degli argomenti
Attacchi ai datacenter, la vulnerabilità di cui parliamo poco: non è cyber, è “geopolitica applicata all’infrastruttura”
Quando si parla di cloud, si sente spesso questa frase: “tanto è tutto ridondato”.
Sì. Ridondato rispetto ai guasti “normali”: un rack che salta, un UPS che si scarica, una linea che cade, persino l’errore umano. Ridondanza di zona, di regione, di rete. Il cloud iperscalabile nasce per assorbire l’imprevisto operativo.
Ma non nasce per assorbire un attacco militare.
Lo dicono, di fatto, anche le cronache: l’evento ha generato power disruption, attivazioni di sistemi antincendio e persino danni da acqua legati alle procedure di spegnimento. Non stiamo parlando di “latency”, di informatica; stiamo parlando di corpi reale e non virtuali. Di posti dove sono localizzati i dati, fisicamente e non nel cloud.
Ed è qui che la mente fa un click: un data center non è una nuvola. È una fabbrica.
Una fabbrica di calcolo. Che ha bisogno di energia, raffreddamento, connettività, persone, logistica. E quindi, in uno scenario di conflitto, diventa automaticamente un candidato naturale per entrare nella lista dei “punti critici”, dei luoghi da danneggiare, delle infrastrutture da disattivare.
Il nuovo ordine delle priorità militari (e il problema è che ha senso), datacenter minacciati
Fino a ieri, l’immaginario era: superiorità aerea → infrastrutture energetiche → telecomunicazioni → nodi logistici.
Oggi si aggiunge una riga, e non è fantascienza: superiorità aerea → spegnere il cervello digitale dell’avversario.
Perché colpire un data center civile?
Perché dentro ci vive la continuità operativa di tutto ciò che conta:
- servizi finanziari e pagamenti,
- logistica e supply chain,
- piattaforme di comunicazione,
- sistemi aziendali,
- servizi pubblici digitali (diretti o indiretti),
- e, sempre di più, capacità di calcolo per analytics e AI.
Non serve “spegnere internet”. Basta rendere inaffidabile il territorio.
E infatti AWS, secondo quanto riportato, avrebbe invitato i clienti nell’area a fare backup immediati e spostare i sistemi verso altre regioni (USA, Europa, Asia…), proprio per l’“imprevedibilità” del contesto e impossibilità di garantire il servizio. Servizio che non è nazionale iraniano, ma sovranazionale mondiale, visto che le Big Tech ormai operano come veri e propri enti sovranazionali.
Questa frase, per chi governa servizi digitali, è una sirena: non è più solo DR (Disaster Recovery). È Geo-Political Recovery.
“Critical infrastructure” non è più una metafora: è un’etichetta operativa
Negli ultimi anni l’Europa ha iniziato a ragionare in modo più sistemico su cosa significhi “infrastruttura critica” e, soprattutto, su cosa significhi resilienza (non solo sicurezza). La Direttiva CER (Critical Entities Resilience) mette proprio questo tema sul tavolo: resilienza rispetto a tutti gli hazard, naturali e antropici, accidentali o intenzionali.
E la NIS2, pur centrata sulla sicurezza cyber, spinge verso un approccio di governance e gestione del rischio più maturo, dentro settori critici e filiere digitali.
Il punto è: abbiamo progettato (e normato) molto la cybersicurezza. Molto meno la “war-sicurezza” delle infrastrutture digitali.
Oggi la realtà ci costringe a un aggiornamento mentale: la resilienza cloud è anche resilienza geopolitica.
Attacchi ai datacenter, lezioni per il futuro
Qui evito la checklist sterile. Però tre idee operative, sì, perché sono le tre domande che dovremmo farci già domani mattina.
1) Ridondanza non è “multi-AZ”. È multi-regione vera
Se un’intera area geografica diventa instabile, la domanda non è “quanti Availability Zone ho”. È: posso spostare davvero il carico altrove continuando a far funzionare i miei sistemi?
Multi-region non è uno slogan. È architettura, dati, rete, identità, osservabilità, e soprattutto disciplina: test periodici, failover provati, costi accettati.
2) Backup non è un verbo. È un piano di fuga
“Fate subito il backup” suona bene. Ma in emergenza scopri due cose:
- che il backup non è ripristinabile nei tempi che credevi,
- che il ripristino dipende da altri servizi (IAM, KMS, DNS, connettività) anch’essi sotto stress.
Il backup serio, oggi, deve includere immutabilità, separazione geografica, e procedure di restore provate. Non “abbiamo uno snapshot e poi vediamo quando capita qualcosa”.
3) La supply chain digitale è un grafo, non una lista fornitori
Molti non sanno davvero “cosa cade” se cade una regione cloud: applicazioni, API, log, integrazioni, identity provider, sistemi di pagamento, strumenti interni.
Serve una cosa che sembra noiosa finché non serve: mappatura delle dipendenze e runbook di crisi. Non per essere perfetti. Per essere veloci quando il tempo non c’è. Serve di sapere dove sono i miei dati e le mie applicazioni, da quali servono dipendendo e come il mio ecosistema dati si è ramificato andando in cloud nel tempo. E addirittura servirebbe di conoscere anche quello dei fornitori.
Per la PA (e per chi eroga servizi essenziali): le necessità
Se digitalizzi un servizio pubblico o essenziale, stai facendo una promessa: continuità.
Finché la minaccia era “solo” cyber, la risposta era: hardening, SOC, incident response.
Da oggi si aggiunge una dimensione: continuità in condizioni estreme.
Questo non significa bunkerizzare tutto. Significa, più concretamente:
- sapere quali servizi devono reggere (e quali possono degradare),
- prevedere degraded mode (servizio minimo),
- avere canali alternativi quando il digitale “core” è instabile,
- e, soprattutto, smettere di confondere “cloud” con “assenza di territorio”.
Perché il territorio, improvvisamente, è tornato a bussare alla porta.
E la porta, nel nostro caso, è un data center.
E alla fine bisogna diventare prepper digitali, ma non solo per se stessi, anche per la propria azienda o ente. Ovvero essere pronti a tutto e tornare a pratiche magari “antiche” come i servizi on premise in caso di emergenza, ma necessarie per una sopravvivenza in caso di eventi estremi, naturali o geopolitici.
Partecipa alla community