Un sistemaCloud che funziona davvero

Il cloud deve offrirci flessibilità, oltre a:

• Servizi di eccellenza.
• Innovazione nel cloud.
• Nessuna dipendenza da un unico fornitore.

Ma quando si verifica un incidente informatico, quella flessibilità spesso si trasforma in complessità. In questa puntata di STRIVE, ho incontrato Akshay Joshi, Senior Director of Product Management – la cui carriera spazia da IBM ad AWS, Microsoft, Clumio e ora Commvault – per fare il punto su una scomoda verità: la maggior parte delle organizzazioni pensa di essere pronta per il cloud. Finché non si scopre che non lo è. Guarda l’episodio completo.

Punti chiave: Cosa richiede realmente il cloud

• Il backup a livello di servizio non equivale al ripristino a livello di applicazione. Proteggere le singole fonti di dati non equivale a ripristinare un ecosistema di applicazioni sincronizzate.
• La complessità del ripristino aumenta quando si ha a che fare con più cloud. Punti di ripristino diversi, account diversi, team di amministratori diversi: ognuno di questi fattori crea ostacoli proprio quando il tempo è fondamentale.
• Gli strumenti nativi degli hyperscaler sono necessari, ma non sufficienti. Garantiscono la protezione all’interno del proprio cloud, ma non consentono l’orchestrazione tra diversi cloud.
• L’isolamento è il primo anello di una catena di eventi informatici. Più ampio è l’ambiente interessato, più difficile è contenerne l’impatto.
• La resilienza deve essere integrata fin dalla fase di progettazione, non aggiunta in un secondo momento. La mappatura delle dipendenze e la pianificazione del ripristino dovrebbero iniziare già in fase di progettazione dell’applicazione, non dopo la sua implementazione.
• L’automazione basata sull’intelligenza artificiale offre maggiori potenzialità, ma comporta anche nuovi rischi. I flussi di lavoro basati su agenti richiedono controlli rigorosi delle autorizzazioni e una governance rigorosa.

Il divario tra teoria e realtà

A prima vista, il Recovery sembra semplice: fino a che punto bisogna effettuare il Recovery? Cosa bisogna effettuare? Dove bisogna effettuare il Recovery? Ma, come spiega Akshay, ciascuna di queste domande si complica in un mondo multi-cloud. Servizi diversi possono avere punti di Recovery diversi. Alcuni microservizi potrebbero essere interessati, mentre altri no. Il Recovery potrebbe richiedere una riprogettazione se effettuato a livello interregionale o tra account diversi.

Ciò che sulla carta sembra semplice, nella pratica si rivela estremamente complesso. E quando il ransomware colpisce, i team non consultano con calma le procedure standard, ma vanno nel panico.

Il primo tassello: l’isolamento

Ogni vettore di minaccia cresce in proporzione alla complessità dell’ambiente cloud: diversifica l’infrastruttura, ma amplia anche l’ambito operativo.

Backup a livello di servizio vs. Ripristino a livello di applicazione

È proprio qui che la maggior parte delle organizzazioni incontra difficoltà. Ecco cosa sostengono:

• Dati di Azure con Azure Backup
• Dati AWS con AWS Backup
• Cloud di Google Cloud con uno strumento separato

Presi singolarmente, i singoli servizi potrebbero essere protetti. Nel loro insieme, l’applicazione potrebbe non essere ripristinabile in uno stato sincronizzato. Gli strumenti nativi non comunicano tra i vari cloud. Non sono intrinsecamente orientati all’orchestrazione nel cloud. Non sono ottimizzati per garantire il tempo di ripristino (RTO) o il punto di ripristino (RPO) su larga scala nel cloud.

E quando il ripristino dipende dall’allineamento di più fonti di dati tra diversi hyperscaler, l’orchestrazione fa la differenza tra ore e giorni. È proprio per questo che esistono strategie di ripristino unificate: non per sostituire gli hyperscaler, ma per coordinarli.

La mappatura delle dipendenze non è più facoltativa

Si parla di mappatura delle dipendenze delle applicazioni da oltre un decennio. Ma in un mondo multi-cloud, non è più un “plus”. Le applicazioni ora si estendono su più hyperscaler, più team DevOps, più domini amministrativi e più strumenti di backup di diversi fornitori.

La frammentazione delle responsabilità rallenta il Recovery. La frammentazione dei fornitori complica l’orchestrazione. I silos operativi causano ritardi nel momento peggiore possibile. La resilienza deve essere integrata fin dall’inizio, non aggiunta a posteriori dopo l’implementazione.

Anteprima: Perché il cloud fallisce senza una mappatura delle dipendenze

In questo estratto della conversazione STRIVE, Akshay spiega perché rendere operativa la resilienza già in fase di progettazione sia fondamentale per far fronte agli attacchi informatici reali.

Progettare per il ripristino – Non solo per la protezione

Uno dei punti salienti di questo episodio: le applicazioni moderne dovrebbero essere progettate non solo in funzione delle prestazioni e della scalabilità, ma anche della capacità di ripristino. Ciò significa che:

• Prestare la stessa attenzione all’RTO quanto all’RPO.
• Progettare tenendo conto del cloud.
• Migliorare la visibilità ove possibile.
• Ridurre la frammentazione dei fornitori e delle attività amministrative.
• Verificare il ripristino in diversi ambienti.

La velocità di Recovery incide sui ricavi. La chiarezza di Recovery incide sulla reputazione. I tempi di inattività incidono sulla fiducia dei clienti. L’innovazione multi-cloud deve essere accompagnata da una disciplina di Recovery multi-cloud.

Il livello di intelligenza artificiale e automazione

Nessuna discussione è completa senza affrontare il tema dell’IA. I flussi di lavoro basati su agenti sono sempre più integrati nelle piattaforme SaaS aziendali. Ma l’automazione introduce nuove considerazioni:

• Di quali autorizzazioni dispongono gli agenti?
• Con quale frequenza vengono eseguiti i backup?
• Quali sono le implicazioni in termini di costi derivanti dalle decisioni relative all’automazione?
• Gli agenti sono considerati identità con accesso regolamentato?

L’intelligenza artificiale può rafforzare la resilienza, ma senza adeguate misure di sicurezza può anche amplificare i rischi. La chiave sta nella delega controllata.

Perché abbiamo avuto questa conversazione su STRIVE

STRIVE non mira a ripetere ciò che tutti già sanno. Si tratta piuttosto di affrontare le lacune che emergono durante i veri e propri incidenti informatici. Il multi-cloud non accenna a rallentare. Tuttavia, se le strategie di ripristino non si evolveranno di pari passo con l’architettura, la complessità finirà per superare la capacità di preparazione.

Ecco perché questa discussione è importante. Ed è per questo che abbiamo coinvolto Akshay, una persona che ha lavorato con diversi hyperscaler e ne comprende sia i punti di forza che i limiti.

Guarda l’episodio completo

Nell’episodio completo di STRIVE scoprirai:

• Il vero divario tra il backup a livello di servizio e il ripristino a livello di applicazione.
• Perché l’isolamento è il primo anello della catena degli attacchi ransomware.
• In che modo la frammentazione dei fornitori complica l’orchestrazione.
• Su cosa devono trovare un accordo i CISO e i responsabili DevOps.
• Come l’intelligenza artificiale cambia l’equazione della resilienza.

Guardalo subito. Se utilizzi AWS, Azure o Google Cloud, questa conversazione è fondamentale.

Domande frequenti

D: Perché il backup nativo degli hyperscaler non è sufficiente?

R: Gli strumenti nativi proteggono i dati all’interno di un determinato cloud, ma non coordinano il ripristino tra diversi cloud; i cloud richiedono un ripristino coordinato tra servizi e fornitori.

D: Qual è la principale lacuna nel cloud?

R: Il divario tra il modo in cui vengono eseguiti i backup (per singolo servizio) e il modo in cui deve avvenire il ripristino (a livello di applicazione).

D: Cosa significa «apertura ambientale»?

R: Si riferisce alla varietà di account, cloud, identità e servizi presenti in un ambiente. Man mano che tale varietà aumenta, il rischio e la complessità crescono in modo proporzionale.

D: Perché la mappatura delle dipendenze è fondamentale?

R: Le applicazioni si estendono ormai su più cloud e team. Senza una mappatura delle dipendenze dei servizi, la sequenza di ripristino diventa una questione di congetture.

D: In che modo l’intelligenza artificiale influisce sul ripristino di emergenza?

R: I flussi di lavoro basati sull’intelligenza artificiale possono aiutare ad automatizzare le decisioni relative al backup e al ripristino, ma richiedono rigorosi controlli degli accessi, una gestione dei costi e un’adeguata supervisione.

D: Da dove dovrebbero iniziare le organizzazioni per migliorare il cloud?

R: Iniziando a valutare:

• • L’allineamento del ripristino a livello di applicazione.
  • Opportunità di consolidamento dei fornitori.
  • La sincronizzazione tra i team.
  • La strategia di isolamento in caso di incidenti.
  • Frequenzacloud.

Chris Mierzwa è direttore senior del marketing di portafoglio presso Commvault.