Siamo spiacenti, tutto questo non sarebbe dovuto accadere”. Recitava grossomodo così, la comunicazione ricevuta nei giorni scorsi dai 620 mila sottoscrittori del fondo di investimento Unisuper, dopo che, per un “errore di configurazione” (misconfiguration), il fornitore di servizi cloud aveva inavvertitamente cancellato dalla rete l’intero account della società australiana. Una circostanza “unica nel suo genere”, mai verificatasi prima, spiegava agli associati del fondo il CEO di Unisuper. Eppure a volte tutto questo succede, ed è proprio per minimizzarne gli impatti che è opportuno predisporre una strategia per il disaster recovery, con l’obiettivo di evitare disservizi e, soprattutto, di limitare qualsiasi motivo d’apprensione a persone e imprese.
Il caso Unisuper — per la cronaca finito a buon fine — può essere considerato un evento limite. Tuttavia gli imprevisti sono sempre dietro l’angolo, in particolar modo quando si parla di cloud e digitale. A volte è sufficiente una presa staccata, una procedura errata, la semplice obsolescenza dei macchinari oppure anche una piccola disattenzione, magari di un addetto alle pulizie che tocca qualcosa che non dovrebbe (caso realmente accaduto), per perdere applicativi, dati e la fiducia degli utenti, oltre che la reputazione costruita negli anni. “Prevenire”, “monitorare” e “ripristinare” diventano, così, le parole chiave per un corretto funzionamento dei sistemi per tutto il ciclo di vita dei dati all’interno delle applicazioni.
Partire dalle norme
Nella Pubblica Amministrazione alcuni processi sono ben regolati da normative e linee guida specifiche, al fine di garantire il corretto trattamento dei documenti, come nel caso della disciplina sul Protocollo informatico. Per quanto riguarda i servizi, in particolare per il backup e il ripristino di un generico servizio in cloud, è utile partire dal Codice dell’Amministrazione Digitale (CAD), che nell’articolo 51 parla della “sicurezza e disponibilità dei dati, dei sistemi e delle infrastrutture delle pubbliche amministrazioni”.
Nella Strategia Cloud Italia e nel percorso per la qualificazione dei servizi cloud per la PA, promosso dall’Agenzia per la Cybersicurezza Nazionale (ACN), si definiscono vari livelli d’importanza per i dati gestiti dalle pubbliche amministrazioni:
- dati e servizi ordinari, la cui compromissione può provocare l’interruzione di servizi dello Stato oppure un pregiudizio per il benessere economico e sociale del Paese;
- dati e servizi critici, dove un malfunzionamento può determinare un pregiudizio al mantenimento di funzioni rilevanti per la società, la salute, la sicurezza e il benessere economico e sociale del Paese;
- dati e servizi strategici, ovvero situazioni in cui eventuali problemi possono avere impatti sulla sicurezza nazionale.
Per ogni categoria di dato, i provider di infrastrutture e servizi cloud che offrono servizi alla PA devono ottenere la corrispondente qualifica da parte di ACN. Inoltre, già nelle Misure minime di sicurezza ICT per le pubbliche amministrazioni, l’Agenzia per l’Italia digitale (AgID) dettaglia le caratteristiche delle copie di sicurezza (backup) e obbliga la Pubblica Amministrazione ad “assicurarsi che i supporti contenenti almeno una delle copie non siano permanentemente accessibili dal sistema onde evitare che attacchi su questo possano coinvolgere tutte le sue copie di sicurezza”.
La (non) responsabilità dei provider
Spostare i dati in cloud non sposta, però, la responsabilità della loro tutela, anche se ne esplicita le regole del gioco. Di solito i cloud provider, nelle clausole standard dei loro contratti, non si assumono alcuna responsabilità per la perdita di dati. Come prova, ad esempio, ecco alcuni paragrafi estratti dai termini di servizio di un noto provider di servizi di cloud pubblico, riassunti e condensati per maggiore chiarezza:
Il provider non è responsabile della […] perdita di informazioni aziendali, anche qualora il provider fosse a conoscenza della possibilità di tali danni o se tale possibilità fosse ragionevolmente prevedibile.
Non bisogna stupirsi: i produttori di hardware rimborsano o sostituiscono il disco difettoso, ma non il valore dei dati che conteneva; mentre nel cloud di solito gli indennizzi riguardano solo i canoni per il servizio pagati nei 12 mesi precedenti, non certo eventuali perdite — pensiamo solo ai danni all’immagine — dovute al mancato recupero dati. Suggeriamo quindi di partire al Manuale di abilitazione al cloud, dove è possibile trovare un’introduzione a tecniche e procedure per duplicare dati su supporti differenti, in modo da minimizzare l’effetto di guasti a singoli componenti.
La vecchia regola del 3–2–1
C’è una strategia di backup che continua a resistere alla prova del tempo: è stata pensata nei primi anni Duemila dal fotografo americano Peter Krogh, ed è riassumibile in “tieni 3 copie dei dati, su 2 supporti differenti e tieni una copia fuori sede”. Il motivo è semplice: mentre si effettua una copia, due dispositivi possono essere contemporaneamente corrotti; per mantenere i dati anche in caso di disastro in sede occorre quindi una terza copia in un sito diverso, utilizzando un minimo di due supporti esterni.
La regola del 3–2–1 è molto semplice. È stata concepita prima della diffusione del cloud, e anche se non copre la totalità dei casi avversi, offre di certo dei buoni spunti per delineare una strategia di disaster recovery. Alcune indicazioni sono ad esempio riprese dalla European Union Agency for Cybersecurity (ENISA), come suggerimenti per le piccole e medie imprese. E nel tempo i consigli di Krogh sono stati arricchiti, ad esempio con la formula: 3–2–1–1–0, dove un 1 sta per la copia fuori sede, l’altro 1 sta per la copia disconnessa e 0 sta per zero errori in fase di test del recovery. Ci sono poi varianti come 4–3–2 (quattro copie di dati, in tre siti indipendenti, due disconnesse), che vengono suggerite per massimizzare l’utilizzo dei cloud provider.
In generale, quale che sia la variante, la disponibilità di un backup del quale sia possibile fare il restore, il ripristino dei dati, in un tempo ragionevole è la miglior difesa contro gli attacchi di tipo ransomware che cifrano i dati e chiedono un riscatto per ottenere una chiave di decrittazione. La raccomandazione di AgID, come del resto quella di ENISA, è di avere sempre una copia recente disconnessa e isolata dalla rete.
Come gestire in cloud il ciclo di vita dei dati
Con il progressivo affermarsi dei processi di trasformazione digitale, la maggior parte dei cloud provider ha aggiornato l’offerta dei propri servizi per migliorare la disponibilità di applicazioni utili al disaster recovery. Senza entrare troppo nello specifico:
- per lo IaaS sono disponibili volumi in alta affidabilità (ovvero duplicati su sistemi di archiviazione differenti), snapshot (fotografie) dei volumi, backup dei volumi su object storage (archiviazione basata su oggetti, dove i file sono gestiti da API, in genere per offrire ridondanza nativa e ulteriori controlli sul ciclo di vita dei dati);
- per i servizi DBaaS è possibile invece acquistare servizi specifici, dal cluster in alta affidabilità al backup automatico su region differenti, con vari livelli di granularità, a volte dettagliato fino alla singola transazione.
- per il SaaS di norma il cliente non ha visibilità sulle procedure di backup, ripristino e disaster recovery, ciò comunque non assicura che il provider non perda dati, e proprio per questo, in generale, tramite il regolamento ACN, i provider sono tenuti a fornire delle API al cliente per scaricare tutti i suoi dati in maniera interoperabile.
L’object storage può essere configurato per mantenere un certo numero di copie (versionamento) per un certo periodo di tempo, anche indefinito. Ci sono inoltre servizi di copia e sincronizzazione, attivabili per i database e per lo storage, che insistono su zone di disponibilità o regioni cloud differenti. Alcuni sistemi possono essere anche conformi all’archiviazione a lungo termine, un tema correlato al backup e al ripristino, dove, semplificando, il backup serve per recuperare i dati in uso al momento, qui ed ora; mentre l’archiviazione mira a rendere possibile il recupero dei dati che serviranno in futuro.
Cloud: la sicurezza dei backup
In ogni caso, c’è un punto a cui prestare molta attenzione: alcuni servizi cloud possono dare l’impressione di avere dei dati ridondati, e quindi disponibili in più copie indipendenti. Ma la ridondanza spesso non è sufficiente per guasti comuni. È il caso, ad esempio, dello snapshot dei volumi: se non ulteriormente specificato, lo snapshot risiede sullo stesso disco o sullo stesso gruppo di dischi del sistema originale. Un guasto fisico ai dischi o alla macchina che li ospita e, oltre ai dati, anche le copie dello snapshot saranno perse.
Per essere ragionevolmente protetti, gli snapshot dovrebbero essere trasformati in immagini e queste, a loro volta, andrebbero caricate in sistemi ridondati, per esempio nell’object storage su un’altra zona di disponibilità o su un’altra cloud region, oppure — meglio — presso un differente cloud provider. In generale, possiamo dire che i backup vanno protetti allo stesso livello dei dati che contengono. Praticamente ad ogni livello è necessaria una criptazione (ovvero la protezione dei dati tramite chiavi e password, in modo da impedire la lettura diretta dei dati a chi, senza autorizzazioni, è in possesso del dispositivo fisico) e una verifica dei contenuti tramite somme di controllo e firme digitali.
Non solo dati: le applicazioni e i vantaggi dei modelli cloud native
I dati sono considerati tra i beni più preziosi dell’economia digitale. Ciò non toglie, però, che anche programmi e configurazioni vadano protette il più possibile. A tale scopo, i cloud provider propongono a catalogo prodotti per il backup e ripristino che dispongono di connettori specifici per i vari servizi, ad esempio per fare backup e restore di un database o di un bucket di un object storage, oppure delle configurazioni di un cluster kubernetes. Alcuni sistemi di backup supportano anche la ripartenza e la riconfigurazione dei servizi su un provider diverso o su un sistema differente da quello iniziale.
A differenza delle applicazioni “tradizionali”, i programmi cloud native potrebbero non aver bisogno di alta affidabilità, disaster recovery e backup come servizi esterni o di terze parti, perché delegano e monitorano questi aspetti ai servizi cloud offerti dal provider:
- non ci sarà bisogno del disaster recovery se l’applicazione è distribuita su vari siti;
- non servirà l’alta affidabilità, intesa come replica di macchine virtuali, perché l’applicazione è orchestrata in container e utilizza database distribuiti;
- non servirà il backup perché tutti i dati sono ridondati e versionati nel database o nell’object storage.
Un’applicazione ben ingegnerizzata, con vari livelli di ridondanza, di certo sarà più resiliente di una applicazione tradizionale monolitica, ma i problemi, come abbiamo visto, capitano (in)aspettati, ed è meglio farsi trovare pronti.
Come predisporre una strategia per il disaster recovery
L’importanza di predisporre opportune strategie per backup, restore e disaster recovery dovrebbe ormai essere chiara. Scegliere però quali servizi attivare può non essere così semplice. Partiamo ad esempio dal caso peggiore: non sapere per quali elementi fare il backup, non avere certezza se funziona il restore e non aver predisposto alcun piano di disaster recovery, con i servizi che sono tutti configurati a mano.
Anzitutto, in questo caso, non ha senso acquistare un servizio di disaster recovery o di alta affidabilità pensando che possa metterci al riparo da ogni malfunzionamento. Piuttosto, il primo passo da fare sarà predisporre un backup di ogni elemento, su un sistema append-only, ovvero che non permette la cancellazione di quanto già incamerato nel backup.
Successivamente è necessario stilare una lista dei sistemi e dei servizi ordinati in base alla loro importanza. Il passo seguente è quello di implementare un sistema di backup e restore dei dati per un sottoinsieme di servizi. Ma quali servizi scegliere? E con che criterio? La risposta purtroppo non è immediata, perché la scelta va determinata tramite un’analisi dei rischi e delle conseguenze di un’eventuale indisponibilità del servizio, detto che di solito i piani di business continuity dovrebbero esaminare le minacce, prevenirne e mitigarne gli effetti, ma soprattutto fornire indicazioni su come ripartire in caso di compromissione di un servizio.
Una volta individuato il sottoinsieme, sarà poi più semplice delineare delle valutazioni su come aggiungere al sistema alta affidabilità e/o il disaster recovery su un’altra cloud region. A tale proposito è possibile seguire anche quanto suggerito dal Manuale di abilitazione al cloud alla voce “disaster recovery”. Con la consapevolezza che, nell’era della trasformazione digitale, alla celebre massima latina “verba volant, scripta manent” andrebbe forse aggiunta la locuzione “data conrumpent”: le parole volano, gli scritti rimangono, i dati (se non adeguatamente protetti e monitorati) sono destinati a corrompersi. A volte per sempre.
