Febbraio sarà sicuramente menzionato nei consueti post che, tra novembre e dicembre, si occupano di elencare e raccontare i principali disservizi degli ultimi dodici mesi. Alle 9.45 AM PST S3 (Simple Storage Service) ed altri servizi della piattaforma cloud Amazon vanno improvvisamente offline.
Ed in Rete si diffonde “il panico”, per utilizzare un’espressione cara al giornalismo “sensazionalista”: l’agitazione non è tuttavia ingiustificata, il data center che ha dato il via alla travagliata mattinata dei tecnici AWS è infatti uno dei più illustri del network AWS, sia perchè tra i primi ad essere stati costruiti dalla compagnia sia perchè situato nella strategica region US-East-1 (North Virginia). Docker, Expedia, Airbnb, Yahoo ed altri celebri brand si ritrovano così in pochi minuti a dover fronteggiare le problematiche derivanti da un improvviso “blackout” del servizio.
Anche se è superfluo ricordarlo, la maggior parte delle aziende dipende al giorno d’oggi dalla condivisione digitale di informazioni e dalle possibilità offerte dalla Rete e dalle tecnologie sfruttabili grazie ad essa (come il cloud). Se improvvisamente il meccanismo si inceppa i danni, soprattutto per aziende di respiro globale, sono considerevoli.
Cyence, startup che si occupa di quantificare i danni provocati dalle “cyber minacce”, ha dichiarato ad esempio al portale Data Center Knowledge che le compagnie presenti nell’indice S&P 500 (Standard & Poor’s) hanno perso in quattro ore di downtime circa 150 milioni di dollari; il bilancio è ancora più salato per i servizi finanziari, almeno 160 milioni di dollari, un valore che non tiene conto degli istituti di credito cooperativo (credit union), che si appoggiano notoriamente ad AWS per offrire servizi di banca multicanale etc.
Il bottone sbagliato
In base a quanto dichiarato dalla stessa Amazon alcuni giorni dopo, il disservizio non sarebbe stato causato da alcun guasto hardware o problema infrastrutturale, bensì ad un semplice errore umano. Un tecnico, che avrà ricevuto più di una semplice sanzione disciplinare, ha inavvertitamente sottratto “capacità” ad un sottosistema “cardine” del sistema che ha portato all’odissea di quattro ore. Un semplice gesto ha lasciato a terra numerose imprese per ore, oltre che a mettere a dura prova lo stesso team AWS: è infatti il caso di ricordare che fino alle 12 dello stesso giorno, il provider non è stato in grado di aggiornare la propria dashboard e pubblicare notizie riguardanti lo stato dei servizi.
Secondo John Parker (disaster recovery e data center operation management presso la ESRI), durante il downtime Amazon si è comunque dimostrata all’altezza della situazione: “sono rimasto sorpreso dal report RCA (Root Cause Analysis), ma ancora di più dal fatto che abbiano avuto il tempo di analizzare anche altri processi responsabili del rallentamento delle operazioni di risoluzione dell’imprevisto. […] Ogni compagnia dovrebbe non solo determinare [la causa del disservizio] ma guardare anche ad opportunità [che consentano di perfezionare vari processi durante un incidente, in modo di ridurre il periodo di downtime]”.
Oltre a porgere le immancabili scuse ai propri clienti, AWS ha annunciato di essere già al lavoro per scongiurare il manifestarsi di problematiche simili. Tra i provvedimenti annunciati una limitazione degli strumenti utilizzati dallo staff, in maniera tale che non sia possibile sottrarre rapidamente considerevoli risorse ai vari sottosistemi; la ripartizione di uno dei sottosistemi interessati dall’incidente in “celle” più piccole, operazione prevista per la seconda metà dell’anno ma anticipata dall’inaspettato evento.
Errori umani e soluzioni
“Fin quando saranno coinvolti degli esseri umani nessuna compagnia sarà immune ai downtime, [essendone l’errore umano la causa principale]. Ecco perchè è cruciale per le compagnie disporre di un efficace piano di gestione degli incidenti, grazie a questi è possibile [ritornare operativi molto più velocemente]” ha aggiunto Parker.
A ribadire il concetto dell’essere umano come anello debole di un sistema IT anche Kevin Mitnick, hacker professionista interpellato sempre da Data Center Knowledge ed invitato alla convention Data Center World che si svolgerà il prossimo aprile 2017: “[il mio keynote (si riferisce all’intervento di aprile ndr) dimostrerà perchè le persone sono l’anello debole della catena di sicurezza. La platea assisterà a delle dimostrazioni nelle quali saranno mostrate le più comuni combinazioni di tecniche d’hacking, di social engineering ed exploit sfruttate da me e dal mio team per bucare i sistemi dei clienti, con una percentuale di successo pari al 100%”.
All’indomani dell’incidente AWS si è discusso non solo di “errore umano” ma anche di come prevenire tali situazioni, ovvero di come non restare “completamente” a terra a seguito di disservizi come quello dello scorso febbraio. In linea di massima si è giunti alle seguenti conclusioni, probabilmente note alla maggior parte dei lettori:
- non appoggiarsi unicamente ad un unico cloud provider (strategie multi-cloud);
- disporre di efficienti piani di disaster recovery per evitare situazione in stile Delta Airlines (non disponeva di un adeguato piano di disaster recovery).
