Se lavorate nel settore delle operazioni IT o della protezione dei dati, la settimana appena trascorsa è sembrata un vero e proprio stress test in condizioni reali — anche se i vostri server hanno continuato a funzionare senza intoppi.
Nel giro di 48 ore, due enormi interruzioni di servizio, non correlate tra loro, hanno paralizzato il commercio e i trasporti moderni. Innanzitutto, un’interruzione globale di Microsoft 365 ha impedito a milioni di lavoratori della conoscenza di accedere a Outlook, Teams e Copilot. Quasi immediatamente dopo, un guasto alle comunicazioni ha bloccato i voli in tutti gli Stati Uniti, mentre la Federal Aviation Administration (FAA) emanava un ordine di fermo a terra a livello nazionale.
A prima vista, questi due ambienti non potrebbero essere più diversi. Uno è una piattaforma SaaS nativa per il cloud su scala globale, basata su moderni microservizi; l’altro si basa in gran parte su hardware legacy ormai obsoleto e su un’infrastruttura di telecomunicazioni vecchia di decenni. Eppure, osservando entrambi gli scenari dal punto di vista di un amministratore senior addetto al backup, gli insegnamenti fondamentali sono sorprendentemente identici.
Nessuna delle due interruzioni è stata causata da una sofisticata banda di ransomware sostenuta da uno Stato-nazione. Una è derivata dalla complessità delle moderne infrastrutture cloud e delle relative configurazioni; l’altra è stata causata dal sovraccarico di traffico e dalle incongruenze nei dati dei router sulle linee legacy. Insieme, mettono a nudo i punti ciechi più pericolosi nell’attuale resilienza aziendale.
La lezione di M365: la disponibilità del SaaS non equivale alla recuperabilità dei dati
Per anni, gli amministratori dei backup hanno combattuto una battaglia in salita contro un mito radicato tra i vertici aziendali: «Siamo passati a Microsoft 365, quindi ora è Microsoft a gestire i nostri backup».
Microsoft gestisce una delle architetture cloud più resilienti al mondo, dotata di geo-ridondanza nativa in tutte le regioni globali. Tuttavia, la disponibilità della piattaforma non equivale alla continuità operativa né alla recuperabilità indipendente.
Quando un importante fornitore SaaS smette di funzionare, le organizzazioni prive di backup SaaS indipendenti e di terze parti si rendono conto di non avere alcun accesso fuori banda alla propria linfa vitale operativa. Se Exchange o SharePoint sono irraggiungibili per ore, i vostri team legali, finanziari o di risposta agli incidenti possono ancora cercare, esportare e accedere a e-mail e contratti storici critici? Se i vostri dati risiedono esclusivamente all’interno dell’ecosistema del fornitore, la risposta è no.
Questa è esattamente la lacuna che SaaSRecover di Commvault colma per M365: una protezione indipendente e di terze parti per Exchange Online, OneDrive, SharePoint e Teams con opzioni di ripristino flessibili, tra cui il ripristino a un punto nel tempo, in loco, fuori sede e l’esportazione in formato PST/CAB. I backup vengono eseguiti ogni 8 ore con una pianificazione incrementale permanente, mentre il blocco di conformità garantisce l’immutabilità, impedendo che i dati vengano eliminati o che il periodo di conservazione venga ridotto.
A peggiorare la situazione, questa settimana è emersa una classica trappola operativa: archiviare i propri piani di risposta agli incidenti (IR) proprio all’interno della piattaforma che si è appena bloccata. Se i manuali di ripristino di emergenza, i numeri di escalation dei fornitori e gli schemi di comunicazione di emergenza si trovano all’interno di SharePoint o Teams, non è possibile consultare il manuale che indica cosa fare quando M365 è offline.
La lezione della FAA: debito tecnico e la trappola della gestione del cambiamento
Mentre l’interruzione di M365 ha messo in luce i limiti dell’astrazione cloud su larga scala, il “ground stop” della FAA ha dimostrato l’estremo opposto: il rischio crescente derivante dal rinvio della modernizzazione.
Ogni dirigente senior nel settore delle infrastrutture conosce bene il ciclo di bilancio del «mantenere il sistema in funzione». Quando i fondi scarseggiano, le organizzazioni si limitano ad applicare patch ai sistemi obsoleti anziché riprogettarli. Nel mondo dei backup, ciò si traduce nel mantenere in funzione array di dischi non più supportati, server multimediali senza patch o percorsi di rete instabili «solo per un altro anno fiscale». Alla fine, il debito tecnico arriva a scadenza — di solito nel momento peggiore possibile.
Inoltre, entrambi gli eventi mettono in luce una scomoda verità che ogni amministratore esperto conosce bene: la gestione ordinaria delle modifiche rappresenta una minaccia statistica maggiore per l’uptime rispetto agli attacchi informatici. Che si tratti di un piccolo aggiornamento del router, di una configurazione errata del DNS o di un picco di traffico non isolato che si propaga a cascata lungo percorsi ridondanti, le modifiche interne aggirano sistematicamente le misure di sicurezza ad alta disponibilità progettate proprio per prevenirle. Se un singolo collo di bottiglia di rete o un errore di configurazione può mettere fuori uso sia il percorso primario che quello secondario, non si dispone di un vero isolamento: si hanno semplicemente due modi per fallire contemporaneamente.
Ecco perché Commvault AirGap è fondamentale. Garantisce un vero isolamento: comunicazione in uscita unidirezionale solo dal cluster AirGap, replica pull-based, esposizione minima delle porte e isolamento immediato al completamento della replica. La logica di controllo risiede all’interno del cluster AirGap, non nel CommServe: in questo modo, un guasto sul lato di produzione non può propagarsi al livello di Recovery.
Nessuno dei guasti di questa settimana ha coinvolto l’intelligenza artificiale, e vale la pena dirlo chiaramente. Ma guardate cosa li ha causati: una modifica apportata di proposito da qualcuno, all’interno di un sistema troppo complesso perché una sola persona possa tenerne traccia mentalmente. Ora pensate a chi apporterà modifiche nel vostro ambiente il prossimo anno. Gli agenti stanno già modificando le configurazioni, concedendo accessi e spostando dati, e lo fanno più velocemente di quanto qualsiasi comitato consultivo sulle modifiche possa esaminare. Il tipo di guasto di questa settimana è quello che vedremo di nuovo, tranne per il fatto che la modifica avverrà in pochi secondi e nessuno avrà aperto un ticket al riguardo. Ecco perché l’individuazione e il rollback devono essere continui piuttosto che programmati.
Come si svolge il Recovery continuo il lunedì mattina?
Non occorre una revisione radicale del budget per mettere in pratica gli insegnamenti tratti dai due guasti di questa settimana. Utilizzate questi eventi come catalizzatore per verificare quattro aree critiche della vostra strategia di resilienza. Non si tratta di semplici precauzioni: ecco come si presenta il “Recovery continuo” dalla console:
- Spostate i vostri runbook fuori banda— Estraete i vostri piani di disaster recovery, gli schemi di rete, i contatti dell’assistenza dei fornitori e le credenziali di emergenza da M365 e SharePoint. Conservatene una copia immutabile e offline — oppure archiviateli in un repository completamente indipendente che non dipenda dal vostro tenant cloud principale. Il compliance lock e l’AirGap di Commvault garantiscono proprio quel livello di archiviazione immutabile e isolata.
- Disconnettere l’autenticazione del backup dall’SSO di produzione— Disporre di un backup di terze parti indipendente per M365 è ottimo, a meno che il portale di backup non si affidi esclusivamente al Single Sign-On di Entra ID (Azure AD) per consentire l’accesso. Assicuratevi che i vostri amministratori di backup dispongano di credenziali locali di emergenza dedicate e protette dall’autenticazione a più fattori (MFA), in modo da poter comunque accedere ed esportare i dati in caso di interruzione del servizio del provider di identità.
- Verificate l’isolamento del vostro raggio d’azione— Esaminate attentamente i piani di rete e di gestione che collegano il vostro ambiente di produzione allo storage di backup. Verificate che un errore di routing a cascata, un guasto DNS o una tempesta di broadcast in produzione non possano saturare o interrompere l’accesso al vostro livello di ripristino. È qui che Commvault Cleanroom aggiunge valore: fornisce un ambiente di ripristino isolato, sia basato su cloud in AWS/Azure sia on-premise con un vault Commvault Grid (precedentemente HyperScale X) in air-gap, dove è possibile ripristinare e convalidare i dati senza rischiare una reinfezione dell’ambiente di produzione.
- Eliminate il vostro “debito di backup dell’era FAA”: individuate l’hardware o il software legacy più vecchio e vulnerabile nel vostro stack di protezione dei dati. Sfruttate le notizie di questa settimana per elaborare un business case chiaro da presentare alla dirigenza: ripagare il debito tecnico ora è di gran lunga più economico che dover giustificare un’interruzione prolungata in seguito. Il consolidamento su una piattaforma unificata e integrata riduce il debito tecnico e abbassa il rischio di errore umano.
Riflessione finale
Anche i giganti della tecnologia e le agenzie federali, con ingegneri di livello mondiale, si trovano ad affrontare casi limite dal punto di vista dell’architettura. Il punto non è attribuire colpe. È che le ore più difficili arrivano dopo l’allarme, quando si cerca di capire cosa è cambiato e di cosa ci si può ancora fidare. La resilienza consiste nel riuscire a rispondere rapidamente a questa domanda, ogni volta, perché si era già in allerta.
