Da sempre, il disaster recovery è un pilastro delle misure di continuità del business. Il fatto che in questo periodo sia sotto i riflettori dipende da un insieme di fattori: l’aumento costante delle minacce informatiche, la crescita esponenziale del costo del downtime, la sempre maggiore centralità di sistemi e infrastrutture IT per il business e un framework normativo – europeo e nazionale – sempre più rigido sui fronti della sicurezza e della resilienza.
Il caso più emblematico è rappresentato dalla Direttiva NIS2, che indica esplicitamente (Art 21, lettera c) l’obbligo di adottare “misure di continuità operativa, come il ripristino in caso di disastro” per essere conformi ed evitare sanzioni. L’effetto della norma coinvolge non solo le aziende destinatarie di NIS2, ma anche i loro fornitori, partner e terze parti, che se vogliono continuare a collaborare con queste realtà devono alzare le proprie capacità di resilienza.
Indice degli argomenti
DRaaS: progettazione su misura e obiettivi di ripristino
Da anni, le aziende guardano con interesse al disaster recovery as a Service (DRaaS) anche per soddisfare requisiti normativi sempre più stringenti. Il modello cloud porta con sé flessibilità, scalabilità e un approccio pay per use che consente anche alle realtà con budget limitati di accedere a soluzioni e tecnologie allo stato dell’arte.
Per quanto il paradigma cloud possa far sembrare tutto più immediato, il disaster recovery resta un ambito critico, da affrontare con metodo e competenze dedicate, poiché un ambiente DRaaS va progettato su misura, deve essere coerente con i processi e i sistemi aziendali, va validato con test periodici e affiancato da un piano operativo chiaro, definito insieme al cloud provider.
Il nodo critico di RPO e RTO: definire i parametri di continuità
Come progettare, dunque, una soluzione DRaaS su misura? Marco Ziglioli, Pre Sales Engineer di CDLAN, cloud provider italiano specializzato in soluzioni per la resilienza e la continuità operativa, spiega che i primi aspetti da valutare sono «la sorgente dei dati, l’hypervisor sul quale risiedono le virtual machine, le risorse di computing, la quantità di RAM e lo spazio di archiviazione necessari, nonché la definizione di RPO e RTO».
Le aziende faticano molto a definire RPO (Recovery Point Objective) e RTO (Recovery Time Objective), motivo per cui il partner deve agire fin da subito in modalità consulenziale per evitare che vengano sottostimati o sovrastimati: «nel primo caso, le aziende sottostimano RPO e RTO per contenere i costi, trovandosi però in caso di ripartenza una mancanza di dati significativi; nell’altro, le aziende pensano che finestre di backup super stringenti, retention infinite e tempi di rispristino praticamente istantanei possano essere la miglior soluzione. Questo, purtroppo, non è sempre vero perché da un lato impegna una grande quantità di risorse economiche, dall’altro potrebbe comportare confusione in fase di ripartenza dovendo identificare tra troppi restore point quello adeguato al caso specifico». Considerando che RPO e RTO non sono parametri assoluti ma variano in base a ogni applicativo, diventa ancor più centrale la capacità di definire le priorità.
Architetture vincenti: DRaaS e strategie di cloud ibrido
Se fino a pochi anni fa i modelli IT erano tutto sommato lineari, oggi lo scenario è diverso e nelle architetture moderne convivono ambienti privati e pubblici di diversi fornitori in una logica nativamente ibrida.
È chiaro che, in contesti come questi, progettare una soluzione DRaaS risulti non poco complesso e rappresenti una sfida per le aziende: Ziglioli spiega che, in questi casi, il partner deve agire come un architetto del DR e integrare diverse componenti per garantire la protezione di tutti gli asset aziendali. «Vedo due approcci principali: costruire un servizio di DR per ogni servizio o gruppo di servizi erogati da una specifica piattaforma (on premise, public cloud, cloud privati, ecc.), oppure eleggere un unico servizio di disaster recovery in grado di consolidare tutti i servizi erogati dalle varie piattaforme in uso».
Il primo approccio è concettualmente più semplice ma la procedura di attivazione è più complessa e questo avrà conseguenze sia sulla fase di testing e di valutazione che sull’effettivo ripristino in caso di necessità; il secondo caso è più complesso da progettare, ma l’attivazione sia in termini procedurali che tecnici sarà più semplice. Ancora una volta, le chiavi sono la personalizzazione e la capacità di modellare la soluzione sulle effettive esigenze dell’IT e del business.
«Esiste infine un terzo approccio – prosegue Ziglioli – variazione del secondo, che prevede un consolidamento dell’ambiente ibrido multicloud su un’unica piattaforma, sia essa on premises, cloud pubblico o privato dalla quale, poi, procedere alla realizzazione del servizio di disaster recovery. Questo terzo approccio garantisce le migliori performance in termini di RTO ed RPO e, al contempo, procedure di testing ed attivazioni più snelle e semplici. Ha purtroppo l’effetto collaterale di non poter essere sempre applicabile e, in ogni caso, di richiedere una reingegnerizzazione delle modalità di erogazione dei servizi».
Il testing: l’unico vero metro di misura
Per affrontare con successo le avversità ed essere conformi alla normativa, la tecnologia non basta: c’è bisogno di un piano di DR fatto di ruoli, responsabilità, procedure e modelli di comunicazione. Tra le best practice note, ce n’è una che nella realtà è spesso mancante: il test periodico del piano.
“Molte aziende – spiega Ziglioli – commettono l’errore di implementare una soluzione DR e un piano dettagliato ed efficace sulla carta, per poi non testarlo mai. I test periodici (almeno due volte l’anno) sono fondamentali per verificare l’efficacia del piano, garantire la funzionalità della soluzione, formare il personale e verificare l’attualità del piano stesso. I clienti di CDLAN, ad esempio, possono testare il proprio ambiente di DR ogni volta che lo ritengono necessario, essendo completamente disaccoppiato da quello di produzione sia per locazione geografica che logicamente”.
Scegliere il partner giusto per semplificare la messa in opera e la compliance
Abbiamo già visto quanto sia centrale il ruolo del partner, soprattutto sotto il profilo consulenziale e per tradurre requisiti normativi in scelte operative. Non che la tecnologia vada sottovalutata, ma è proprio la spinta normativa degli ultimi anni a rendere sempre più importante un approccio multidisciplinare, in cui l’esperienza tecnica si intreccia con competenze di governance, compliance e gestione del rischio.
Dalla conversazione con Ziglioli emerge con chiarezza il valore della semplificazione. Un buon partner, infatti, non si limita a fornire strumenti tecnologici, ma aiuta l’azienda a fare ordine in ecosistemi IT complessi, a interpretare correttamente le esigenze operative e i requisiti normativi, facendo confluire tutti questi elementi in una soluzione unica e coerente. Non a caso, parlando di CDLAN, Ziglioli sottolinea la capacità di combinare “tecnologia all’avanguardia, un’infrastruttura robusta e un supporto completo, che confluiscono in un servizio DRaaS completamente gestito”.
CDLAN eroga le sue soluzioni DRaaS attraverso la propria infrastruttura di data center presenti in Italia e progettati per garantire livelli elevati di affidabilità e disponibilità. Il data center C21 di Milano, in particolare, è Tier 4 compliant e rappresenta uno dei punti di forza architetturali del servizio, ma a fare la differenza è anche un modello di supporto operativo basato sull’affiancamento costante: “Il nostro team monitora proattivamente l’ambiente, effettua controlli di routine e interviene tempestivamente per risolvere qualsiasi anomalia, assicurando che la replica dei dati funzioni sempre in modo ottimale. In più, assicuriamo un filo diretto con i nostri tecnici: quando un cliente ci contatta, parla direttamente con chi opera sulle nostre infrastrutture proprietarie. Questo significa tempi di risposta più rapidi, maggiore efficacia negli interventi e la certezza di avere sempre un supporto competente e immediato”.
