Scrivo questo post su suggerimento del nostro Presidente (del Clusit ;) ), che ritiene giustamente che un dialogo sul blog sia il modo più efficace per riflettere su quanto accaduto. Mentre lo scrivevo, Armando pubblicava il suo commento. Vedo che siamo abbastanza allineati, ma non mi sento di riscrivere tutto il mio per evitare ripetizioni. Devo premettere come ho saputo del problema di Aruba. Poco dopo le 8 di ieri una mail che stavo inviando a un collega non è stata accettata dal mailserver del mio provider, che mi ha detto che il dominio destinatario era sconosciuto. Una breve analisi mi ha rapidamente portato ad Aruba. In particolare, lo stesso dominio "aruba.it" non era risolvibile. Questo è un punto su cui tornerò dopo. Quando hanno cominiciato a girare le notizie di un problema, sapevo già che qualcosa stesse succedendo, ma non mi era chiara l'estensione. Devo chiarire anche che non conosco l'architettura dei datacenter di Aruba, né quali sono le loro scelte e strategie dal punto di vista della Business Continuity, e quindi più di tanto non posso dire. Le mie considerazioni dovrebbero però essere abbastanza generali da essere corrette nonostante questo.
Da quanto comunicato da Aruba, le fiamme si sono limitate agli UPS. Se è vero che il sistema antincendio ha funzionato abbastanza bene da evitare problemi ai server (non risultano perdite di dati), dal punto di vista di un piano di Business Continuity questo vuole dire abbastanza poco. Per evitare di addentrarmi nei principi della Business Continuity, userò un'analogia. Sappiamo che gli aeroplani di linea hanno, penso anche per obbligo, un sistema frenante ridondato. Ora, supponiamo che vi venga proposto di viaggiare su un aereo, e che in occasione di un incidente in cui il sistema frenante principale si è guastato, scopriate che il sistema frenante non è ridondato, ma il pilota è stato comunque in grado di atterrare senza incidenti. Direste che l'aereo è stato ben realizzato? No: la logica del sistema ridondato è che "il primo si può guastare", e siccome il rischio non è accettabile, se ne impone un secondo di backup a prescindere da come si potrebbe guastare il primario. La logica della Business Continuity è la stessa: si parte dalla possibilità che un componente non sia disponibile (es. i server) e ci si assicura che ci sia una soluzione alternativa, tipicamente un datacenter di backup. Aruba non ha fatto commenti riguardo all'incidente, che io sappia, ma alcuni altri invece hanno detto che il contenimento dell'incendio alla zona UPS ha dimostrato che il sistema era ben realizzato. Per quanto detto, mi sembra una conclusione azzardata. In questo incidente, quello che ci si deve realmente chiedere è: cosa sarebbe successo se l'incendio avesse interessato i server, a prescindere dal come? L'evoluzione dell'incidente non fa ben sperare, visto che una volta spento il datacenter di Arezzo si è fermato tutto. Lo stesso dominio di Aruba, come ho detto all'inizio, non era risolvibile, e se non funziona il DNS funziona davvero poco: è difficile pensare che una soluzione di backup, se disponibile, non sarebbe stata attivata. Fra l'altro, il DNS è nato per avere facilmente meccanismi di ridondanza, che sono la prassi praticamente da quando esiste questo servizio.Naturalmente qui si tratta di "sensazioni", perché come ho detto non ho informazioni dirette sull'architettura.
Quanto detto sopra ha un grosso "se": "se si vuole garantire la continuità del servizio". Ora, ho provato a dare un'occhiata a un contratto di Aruba, e c'è scritto chiaramente che non viene data alcuna garanzia sui dati, e anzi si suggerisce al cliente di farsi i propri backup. Non viene neppure data alcuna garanzia di continuità del servizio o altro. Dato che la Business Continuity costa, e non poco, sarebbe legittimo per Aruba non fornirla "gratis"; più strano però è che non abbia funzionato neppure sul loro dominio. Ci sono altri provider che offrono maggiori garanzie, anche da un punto di vista contrattuale (anche se poi si potrebbe discutere delle penali): questi altri provider ne fanno anzi motivo di vanto e non mancano di segnalarlo nel proprio marketing, e naturalmente costano di più. Quindi in pratica, si ottiene quello per cui si paga. Se si vogliono garanzie di continuità del servizio e protezione dei dati, è bene assicurarsi che siano quantomeno promesse contrattualmente. Nel frattempo, consiglio ai clienti di Aruba di seguire il consiglio di Aruba stessa,e farsi dei buoni backup. Per discorsi di class action, di cui si sente parlare, non vedo grandi prospettive, dato il contratto, ma magari dal punto di vista giuridico mi sfugge qualcosa.
Mi permetto ancora due considerazioni. La prima è che Aruba è anche un fornitore di PEC, cosa che molti hanno sottolineato, considerando particolarmente grave un disservizio in quest'area. Ho riguardato il Codice dell'Amministrazione Digitale, ma non mi pare che ci siano vincoli particolari di continuità del servizio, ce ne sono però in merito alle perdite di dati. Immagino che quando Aruba è diventata fornitore di PEC qualche controllo al riguardo sia stato fatto.
La seconda è più generale: ogni singolo cittadino e ogni singola azienda può tranquillamente decidere di non avere particolari esigenze di continuità del servizio, di protezione dei dati o anche di sicurezza dei propri pc. Queste "tante piccole insicurezze accettate" però, possono contribuire a creare un grosso problema. Il blocco di Aruba ha creato un disservizio diffuso ma di impatto tutto sommato limitato, ma se Aruba perdesse davvero i dati delle centinaia di migliaia di domini ai quali contrattualmente non fornisce garanzie, credo che sarebbe un bel problema. Allo stesso modo, molta dell'insicurezza di Internet è dovuta alla quantità enorme di pc compromessi o compromissibili che con tanta facilità vengono arruolati nelle varie botnet. Non so se ci sia modo di affrontare questo problema, ma certamente, man mano che saremo sempre più dipendenti dai sistemi informativi, diventerà sempre più grave.
Ciao Claudio, post incrociati ma direi stessa linea.
Per quanto riguarda la questione PEC e gli aspetti normativi all'accredito presso il CNIPA (ora DigitPA) in qualità di gestore la situazione è ancora più complessa.
Suggerisco una lettura della Circolare 24 novembre 2005, n. CNIPA/CR/49.
Scritto da: Armando Leotta | 03/05/2011 a 21:34
Il messaggio ufficiale è certamente molto professionale, e come fai notare tu non si parla di continuità dei servizi.
Ho letto anche i commenti dell'articolo e dei lettori, ed in entrambi i casi è da sottolineare quanto scrivi: l'essenza della business continuity è nell'accettazione che l'incidente può accadere, pertanto affermazioni del tipo "la server farm a rischio zero non esiste" e "non è colpa di nessuno e queste cose possono capitare" è un concetto molto italiano e molto da utenti ormai "addomesticati" a subire i problemi senza pretendere livelli di servizio minimali.
Non che la BC possa assicurare, a sua volta, l'assenza di questo tipo di problemi, ovviamente, ma l'impossibilità stessa di avere risposte dal DNS, che anche io ho verificato, è certamente indicativa dell'assenza dei "fondamentali" livelli minimi di servizio (per altro, poco onerosi da ottenere, almeno nel caso specifico del DNS). Questo fa pensare sopratutto ad una assenza di una politica aziendale che, anche decidendo di non garantire alcunché, lo faccia analizzando ed accettando consapevolmente i rischi e valutando, rapportando i costi ai benefici, i possibili impatti, senza trascurare quello di immagine.
Perchè se è vero che oggi parliamo di Aruba, non è certamente per puntare il dito su una specifica azienda, ma sopratutto per dare evidenza di aspetti troppo spesso trascurati. Quanti, di coloro che si sono arrabbiati, hanno a suo tempo letto veramente il contratto ed hanno, a loro volta, consapevolmente accettato la possibilità di restare a piedi?
Un'ultima considerazione: la questione della PEC è decisamente, secondo me, più rilevante. Nessun obbligo di legge impone la continuità del servizio, come dici, ma se in quella data la mia azienda avesse dovuto partecipare ad una gara in e-procurement?
Facciamo un esempio: se un ufficio delle Poste chiude anticipatamente (senza avviso) quando devo predisporre una raccomandata per una gara di appalto, accetterei un avviso del tipo: "siamo temporaneamente chiusi, d'altro canto non abbiamo un contratto che ci impegna ad essere aperti negli orari designati"? Certamente no...
Scritto da: Luca Bechelli | 03/05/2011 a 11:37
Quella appena finita appare essere una "bella" settimana per i fautori della sicurezza, intesa alla ISO27002 come integrità, riservatezza e disponibilità.
L'incidente di Aruba, l'indisponibilità di una parte del Cloud di Amazon (http://aws.amazon.com/message/65648/), e il furto di dati personali e possibilmente di carte di credito a 77 milioni di utenti Playstation (http://tinyurl.com/3dwtm9u) sono esempi importanti di violazioni di riservatezza e di disponibilità. Penso che la distanza tra la sicurezza effettivamente "realizzata" e quella che invece servirebbe, con il tempo si apra a forbice sempre di più invece che diminuire. Le aziende dovrebbero dedicarvi più attenzione e pretendere da loro stesse e dai loro fornitori maggiori garanzie. In questi ultimi mesi si parla sempre più di Cloud e per il Cloud i problemi principali sono la sicurezza e la privacy. Se tramite aziende come Aruba e Amazon l'infrastruttura si concentra sempre di più in pochi grandi siti è necessario aumentare l'attenzione e chiedere loro maggiori garanzie.
Scritto da: Alessandro Vallega | 03/05/2011 a 11:11
Sì, la comunicazione è quella nota in cui dicono appunto che il danno si è limitato agli UPS e che non ci sono state perdite di dati. Non ci sono considerazioni però riguardo al tema della Business Continuity. È vero che la sicurezza assoluta non esiste, ma un conto è aver avuto incidenti dopo aver adottato le good practice, che può succedere, altro è se l'adozione delle good practice è in dubbio. Dico "in dubbio" proprio perché Aruba al riguardo non è espressa.
Scritto da: Claudio Telmon | 01/05/2011 a 01:58
Una piccola nota, Aruba si è espressa tramite un comunicato stampa abbastanza articolato: http://bit.ly/mGbELV
Scritto da: Andrea Draghetti | 01/05/2011 a 01:10