Tutto questo non sarebbe dovuto accadere

Come predisporre strategie di backup, restore e disaster recovery per proteggere dati e servizi cloud

immagine decorativa, realizzata con AI generativa, con postazioni di lavoro e personale che utilizza con terminali collegati tra loro grazie al cloud

di Daniele Pizzolli e Matteo Vabanesi, Team Cloud Italia del Dipartimento per la trasformazione digitale

“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 Google, per un “errore di configurazione” (misconfiguration), aveva inavvertitamente cancellato dal cloud l'intero account della società australiana. Una circostanza “unica nel suo genere”, mai verificatasi prima, spiegavano agli associati del fondo il CEO di Unisuper e il responsabile cloud di Mountain View. 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”.

immagine decorativa, realizzata con AI generativa, con postazioni di lavoro e personale che utilizza con terminali collegati tra loro grazie al cloud

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:

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.

immagine decorativa, realizzata con AI generativa, con postazioni di lavoro e personale che utilizza con terminali collegati tra loro grazie al cloud

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.

immagine decorativa, realizzata con AI generativa, con postazioni di lavoro e personale che utilizza con terminali collegati tra loro grazie al cloud

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:

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.

immagine decorativa, realizzata con AI generativa, con postazioni di lavoro e personale che utilizza con terminali collegati tra loro grazie al 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.

immagine decorativa, realizzata con AI generativa, con postazioni di lavoro e personale che utilizza con terminali collegati tra loro grazie al cloud

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:

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.

immagine decorativa, realizzata con AI generativa, con postazioni di lavoro e personale che utilizza con terminali collegati tra loro grazie al cloud

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.

...

Per rimanere aggiornato sui prossimi approfondimenti resta in contatto con noi su Slack Developers canale #cloud, iscriviti alla nostra mailing list e continua a seguirci sugli account Twitter di Developers Italia e Designers Italia.

Questo blog è redatto da Developers Italia