L’incidente OVH: la lesson learned e gli impatti sul business

A distanza di quasi 10 anni dall’incendio di Aruba (29 aprile 2011), che è stato classificato da diversi analisti come il più grande incidente del digitale italiano, riscontriamo nell’evento che ha colpito OVH alcuni parallelismi.

Nella notte del 10 marzo 2021, alle ore 00.47, un incendio ha devastato uno dei quattro datacenter della compagnia, il SBG2, danneggiando parzialmente un secondo datacenter, il SBG1.
Fortunatamente, non vengono coinvolti i datacenter SBG3 e SBG4, i quali vengono tuttavia spenti quale misura emergenziale e precauzionale.

L’impatto dell’indisponibilità del servizio di Cloud Service Provider è stato elevato, con molti siti irraggiungibili, tra i quali si annoverano anche quelli appartenenti ad istituzioni e amministrazioni pubbliche italiane.

Un disastro che si poteva evitare?

Non si conoscono ancora, ad oggi, le cause dell’incendio, e soprattutto se tali cause siano riconducibili ad eventi di natura dolosa, colposa o indiretta.
Dalle prime ricostruzioni, tuttavia, il sospetto è che ad innescarlo siano stati due UPS (Uninterruptible Power Supply o Gruppo di Continuità), di cui uno sottoposto a manutenzione.
Se confermata tale ipotesi, si potrebbe trattare pertanto di un incendio di origine elettrica, evento che senza alcun dubbio costituisce la principale fonte di pericolo di un Datacenter moderno.

Pericoli di questo tipo sono presi in considerazione dai progettisti di Datacenter, sebbene le soluzioni per fronteggiare tale eventualità si dividano in due diverse scuole di pensiero: tra chi predilige operare in ottica di “minimizzazione degli impatti” e chi invece predilige operare in ottica di “minimizzazione della probabilità”.

Nel primo filone di pensiero, troviamo datacenter progettati con elevati livelli di ridondanza geografica, che accettano il rischio della perdita di un singolo sito (single point of failure) potendo contare su una distribuzione ampia a livello territoriale. Spesso, in tali datacenter troviamo sistemi di estinzione ad acqua, strumento senza dubbio efficace dal punto di vista estinguente, ma altrettanto impattante poiché l’utilizzo dell’acqua su apparecchiature elettriche comporta un elevato livello di danneggiamento e di perdita dei dati. Minori investimenti di sicurezza a livello di “sito”, compensati da maggior ridondanza delle infrastrutture. Tradotto in una logica risk-based: maggiore probabilità di accadimento, minori impatti.

Nel secondo filone di pensiero, troviamo datacenter che magari risultano essere meno ridondati a livello geografico, ma maggiormente resilienti in loco: strutture in cemento armato REI 120, sistemi estinguenti ad utilizzo di gas inerti (maggiormente tutelanti nei confronti sia delle persone che delle infrastrutture informatiche), sistemi di rilevazione e monitoraggio real time. Economicamente più costosi sia in termini progettuali che manutentivi, ma capaci di dare maggiori garanzie di resilienza a livello di singolo sito. E’ questo il caso di molti datacenter italiani. Tradotto in una logica risk-based: minore probabilità di accadimento mediante adozione di efficaci misure di tipo preventivo, spesso accompagnate però da una minor distribuzione geografica.

Tali argomentazioni, anche richiamate dalla società OVH a seguito dell’incidente, a poco afferiscono alla Direttiva Seveso (Direttiva 2012/18/UE, anche nota come “Seveso III”), il cui perimetro di applicazione riguarda quegli stabilimenti produttivi che possono di fatto costituire pericolo per l’ambiente circostante. La non applicabilità di tale Direttiva comporta infatti la non classificazione del sito quale “sito a rischio incidente rilevante”, laddove tale rischio è legato alla possibilità del verificarsi di un incidente all’interno di uno stabilimento che può determinare un pericolo, immediato o differito nel tempo, dovuto all’emissione nell’ambiente di sostanze pericolose.
La non applicabilità di tale Direttiva rileva ai fini della sicurezza territoriale e ambientale e non determina un maggior o minor grado di resilienza rispetto alla sicurezza delle informazioni o delle misure adottate per prevenire incidenti disastrosi.

Giovano invece, parlando di resilienza, l’adozione di misure di sicurezza preventiva e contenitiva volte ad evitare il “single point of failure” o, per i servizi maggiormente critici, il “double point of failure”.
A tal riguardo, l’adozione di un sistema di gestione ISO 22301:2019 (Societal security – Business continuity management systems) e ISO 27001:2017 (Information technology – Security techniques – Information security management systems) possono costituire elementi di valutazione idonei a fornire una certa garanzia di affidabilità nei servizi di Datacenter.

Si tratta dunque di scelte strategiche del Cloud Service Provider, di cui necessariamente il cliente deve tenere conto per una corretta e puntuale valutazione dei rischi connessi ai servizi ospitati.

Come tutelare il proprio business?

Secondo quanto sopra premesso, è opportuno fare alcune considerazioni preventive finalizzate ad una corretta valutazione del rischio.
Perché tale valutazione possa essere realmente compiuta, le imprese dovrebbero porsi alcune domande:

– Il servizio ospitato, per quanto tempo può restare indisponibile?
A tale fine, giova effettuare una valutazione degli impatti dell’indisponibilità del servizio sul business (la c.d. Business Impact Analysis o BIA).

– Qual è il rischio che tale evento di “disruption” possa accadere?
Valutato l’impatto sul business, si tratta di valutare la probabilità di accadimento, contemplando tutte le variabili di rischio (incidenti di natura dolosa, colposa, accidentale, indiretta).

– Valutato il rischio nel suo complesso, qual è il livello di resilienza atteso?
Questa variabile rientra nelle “strategie di continuità operativa” ed è fondamentale. Ho necessità di un servizio ad alta affidabilità active-active (disaster recovery “hot”)? Ho necessità di un servizio che mi dia garanzie di ripartenza nell’arco di poche ore (disaster recovery “warm”)? Ho necessità di un servizio che mi dia garanzie di ripartenza in giorni o settimane? (disaster recovery “cold”)?

L’importanza di una scelta focalizzata sulle strategie di resilienza

L’errore più comune è dare per scontata la continuità operativa.
Infatti, una maggiore o minore resilienza del servizio ospitato è una preoccupazione che deve sin dalla progettazione accompagnare le valutazioni strategiche dell’azienda (business continuity by design).

Quale contratto di hosting devo sottoscrivere?
Molto spesso, i provider offrono diversi pacchetti ai propri clienti, i quali sono capaci di dare garanzie diverse (dal backup manuale a quello automatico, dal disaster recovery a freddo ad un sistema active-active personalizzato). È fondamentale capire il livello di affidabilità offerto da ciascun pacchetto e scegliere quello maggiormente rispondente alle mie necessità, sulla base delle tre variabili sopra enunciate (tempo di indisponibilità, accettazione del rischio, grado di affidabilità atteso).
Un secondo tipo di valutazione può riguardare il possesso, da parte del provider, di adeguate certificazioni che sono sinonimo di garanzia: la compliance alla ISO 22301 e alla ISO 27001 costituisce un punto di indubbia attenzione nella scelta del Datacenter ospitante.

La continuità operativa come cultura aziendale

Non soltanto la scelta del servizio più affidabile secondo le proprie esigenze, ma è anche necessario anche adottare un adeguato piano di continuità operativa (Business Continuity Plan) e di un piano di Disaster Recovery (Disaster Recovery Plan).
Tali piani dovranno essere adottati, condivisi dal personale aziendale e continuamente testati (arrivando anche ad eseguire delle esercitazioni in “effettivo”, ossia spegnendo l’infrastruttura primaria per testare la sua corretta ripartenza sul sito secondario). Il personale dovrà inoltre essere organizzato, formato e addestrato, andando a costituire una vera e propria task force di risposta all’incident di continuità, che in gergo viene definita “Incident Response Structure”.

Gli impatti dell’incidente per GDPR e responsabilità contrattuali

Da un punto di vista privacy, la perdita di dati personali costituirebbe violazione dell’art. 32 GDPR, norma che impone a titolari e responsabili del trattamento l’adozione di «misure tecniche ed organizzative adeguate per garantire un di sicurezza adeguate per garantire un livello di sicurezza adeguato al rischio». Di conseguenza OVH – e i titolari del trattamento che hanno affidato i dati al provider – potrebbero essere soggetti a sanzioni amministrative pecuniarie fino a 10.000.000 di euro o fino al 2% del fatturato mondiale totale annuo dell’esercizio precedente, a norma dell’art. 82 GDPR.

Sempre in relazione alla possibile perdita di dati, un’altra questione estremamente rilevante potrebbe essere se sussista o meno un obbligo per OVH di garantire ai propri clienti il ripristino. Come si diceva poc’anzi, la previsione o meno di un servizio di disaster recovery dipende dagli specifici accordi contrattuali e, dunque, dal “pacchetto” acquistato. Nel caso, infatti, di un accordo contrattuale che preveda anche il servizio di ripristino, il cliente del provider potrebbe senz’altro pretenderlo e, in mancanza, chiedere un congruo risarcimento per inadempimento contrattuale; non vi sarebbe, invece, tutela nel caso in cui non si fosse acquistato anche il servizio di ripristino.

Lo stesso discorso deve essere fatto relativamente al rispetto dei tempi per la risoluzione dell’incidente, verificando nel contratto sottoscritto le limitazioni di responsabilità e la validità legale di quelle specifiche clausole.

Si tratta di aspetti estremamente importanti, poiché si ripercuotono sul cliente, ma, a cascata, anche sui clienti finali e sui rapporti contrattuali con questi ultimi.

Nella scelta di un fornitore di servizi cloud e di una specifica offerta, è dunque fondamentale capire quali servizi siano essenziali per il proprio business e valutarne attentamente la presenza nel “pacchetto” acquistato.

 

Articolo a cura di Maria Elena Iafolla e Federico Lucia