All'interno di questo articolo la videointervista fra Matteo Cecchini Co-Founder e CEO di T-Consulting e Alessio Urban IT Manager e Head of Tech support in Achab che discuteranno degli aspetti da tenere in considerazione nella stesura di un piano di Disaster Recovery davvero efficace.
I nostri ospiti:
 |
| Matteo Cecchini |
| Imprenditore IT dal 2007, Matteo è prima di tutto un appassionato di tecnologia. Fin dall’adolescenza si dedica allo studio dei sistemi e del loro funzionamento, con un interesse spiccato per la Cybersecurity. Questa passione lo porta a poter contribuire - all’inizio della sua carriera - a prestigiosi progetti di digitalizzazione e di innovazione tecnologica. Nel 2007 fonda T-Consulting allo scopo di supportare con la giusta tecnologia le imprese del suo territorio, ad oggi è attivo su più fronti, come Presidente di CNA Forlì-Cesena e come membro del Consiglio Direttivo del Distretto dell'Informatica Romagnolo. |
 |
| Alessio Urban |
| In Achab S.p.A. a partire dal 2014 come Tech Support Manager, Alessio oggi è IT Manager e Head of Tech Support. È coinvolto in tutti i processi e le iniziative di pre-vendita e in quelli che consentono ai clienti di migliorare l’utilizzo dei prodotti acquistati, nonché nell’implementazione del supporto post-vendita. Inoltre, cura il reparto IT allo scopo di garantire la fruibilità e la continuità dei servizi aziendali. |
Il tema della videointervista di oggi: affrontare un'emergenza grazie ad un buon piano di Disaster Recovery
Quando parliamo di Disaster Recovery ci sono alcuni aspetti che è necessario considerare in modo prioritario, come ad esempio l’elenco di tutte le attività aziendali che a fronte di un evento negativo indichino quali sono i servizi critici e in quanto tempo si è in grado di ripristinarli. Successivamente a questa analisi gli altri aspetti da includere nel piano di ripristino sono le tempistiche e i responsabili che devono accedere ai servizi. Non bisogna dimenticare però che un piano di Disaster Recovery per essere efficace deve necessariamente prevedere dei test e delle prove, in questo modo sarà possibile affrontare con relativa tranquillità una situazione di emergenza.
Se sei interessato ad approfondire i temi trattati contattaci cliccando qui.
Transcript intervista:
MATTEO: Buongiorno a tutti e ben ritrovati! Nuovo appuntamento, nuova intervista. Oggi sono qui con Alessio Urban. Ciao Alessio!
ALESSIO: Ciao Matteo e buongiorno a tutti!
MATTEO: Ben ritrovato! Alessio è IT Manager, ma soprattutto è il responsabile del supporto tecnico di Achab. Oggi con Alessio faremo una nuova chiacchierata su un nuovo tema e il tema di oggi fondamentalmente sarà come affrontare una situazione di emergenza con un buon piano B nel cassetto che ci possa supportare a uscire da situazioni di impasse. Bene, Alessio, io direi di partire immediatamente con la nostra chiacchierata e partirei col porti una prima domanda: noi normalmente quando parliamo di minaccia Cyber, e il tema delle minacce Cyber per noi è stato un po’ il filo rosso che ha unito tutti questi appuntamenti, si parla di tecnologie, di processi, ecc., però quando si parla di Cybersecurity, ovviamente, io non posso mai avere la garanzia di un azzeramento del rischio, posso parlare solo di una mitigazione del rischio. Ho, quindi, un rischio residuo che in qualche modo devo gestire. Lo devo gestire perché comunque per quanto io possa essere bravo, per quanto possa fare cose, potrebbe arrivare il giorno in cui l’attacco si palesa e devo in qualche modo, come ci suggerisce il nostro beneamato Framework del NIST, dover passare alla parte di Recovery. Parlando di Recovery e di Disaster Recovery, quali sono dal tuo punto di vista gli elementi che dobbiamo tenere in considerazione quando ragioniamo da questo punto di vista?
ALESSIO: Allora, direi che la prima considerazione da fare è che ci vuole un piano di Disaster Recovery. Quando parliamo di piano significa che dobbiamo avere l’elenco di tutte le attività aziendali che, a fronte di un evento negativo, ci dicano quali sono i servizi critici e in quanto tempo predefinito siamo in grado di ripristinarli. Questo è il core, la base per poi costruire il nostro piano.
MATTEO: Corretto, corretto. Diciamo che all’interno di questi macroelementi, per quella che è un po’ anche la tua esperienza, qual è uno o più di uno di questi elementi che magari viene un po’ sottovalutato?
ALESSIO: Io te ne direi due: uno è sicuramente il tempo predefinito, quindi procedura e tempi, mentre l’altro sono i responsabili. Questo perché quando noi andiamo a definire i servizi che sono impattanti per il business, non sono solo loro a essere impattati, ma sono anche le persone che accedono a questi servizi. Noi dobbiamo avere ben chiaro chi sono i responsabili di questi servizi.
MATTEO: La catena di comando anche.
ALESSIO: La catena di comando! Questo perché in uno scenario di ripristino magari noi siamo in grado di tirare su il CRM e il database che c’è sotto, ma poi l’accesso a questo servizio noi non lo facciamo perché non ci compete, né conosciamo questo software. Ci vuole quindi l’informazione del responsabile che sia lì e che ci dica come verificare che questo sia veramente ripristinato.
MATTEO: Chiaro!
ALESSIO: E dall’altra parte i tempi, nel senso che dobbiamo avere tempi il più possibile certi, poi la certezza non esiste, però se noi ci siamo parlati prima e abbiamo deciso che questi servizi sono quelli core e che ci mettiamo mezz’ora per farli ripartire, faremo delle prove atte a fare in modo di rispettare questi tempi.
MATTEO: Questi 30 minuti, certo. È molto interessante quello che dici sui tempi perché molto spesso capita, almeno a me quando parlo con gli IT Manager, di focalizzarsi molto sulla parte tecnologica e meno sulla parte di analisi preliminare, cioè la parte di mappatura, come giustamente dicevi tu, dei servizi core, capire se un servizio si può permettere di avere un tempo di ripristino di 30 minuti, 1 ora, 6 ore, 2 giorni, ecc., invece si parte molto a spron battuto verso la soluzione tecnologica quando magari sarebbe opportuno tenere in considerazione, ovviamente, anche la parte tecnologica perché quello per me è lo strumento che mi consente di arrivare al risultato, ma avere ben chiari a monte quelli che sono i tempi. Il famoso discorso di RTO e RPO, quindi non solo il tempo di ripartenza, ma anche il tempo massimo di perdita dei dati che, in qualche modo, l’azienda può e deve poter sopportare. Ecco, rispetto alla parte proprio procedurale, io penso al mio piano B, penso al mio piano di Disaster Recovery, adotto magari la soluzione tecnologica ottimale, dopo di questo ne parleremo, ma rimanendo ancora un attimo sulla parte procedurale e di processo: quando, ad esempio, ragiono rispetto a quelle che possono essere le attività di test di un piano di DR, rispetto a quella che è la tua esperienza, quali sono gli elementi anche un pochino più particolari da tenere in considerazione? Mi spiego meglio, non solo il semplice fatto che una o più VM debbano ripartire. Sappiamo bene che questo non è l’unico elemento da tenere in considerazione, ma ci sono magari anche degli altri elementi collaterali legati alla rete piuttosto che ad altri aspetti. Dal tuo punto di vista, questi altri aspetti quali sono? Quali dovrebbero essere?
ALESSIO: Allora, sì, ci sono molti aspetti. La prima cosa che mi viene da dire è che la materia è complessa e per far emergere questi aspetti è necessario fare un test, ma un test zero di business continuity, non basta dire “accendo una macchina”. Gli elementi che possono emergere, e alcuni sono emersi a me quando ho fatto delle prove, sono ad esempio il password manager. Noi abbiamo milioni di password nelle aziende, ma magari noi facciamo il restore in produzione di una macchina e poi banalmente non abbiamo accesso alla password perché non è una macchina che usiamo, oppure non abbiamo accesso al CRM; le licenze, la parte di license in dei server, bisogna sapere se dipendono da MAC address su cui girano quelle macchine perché esistono dei tipi di licenze che sono legate ai MAC address; la parte di LAN e VPN e, quindi, tutta la raggiungibilità delle macchine, cioè non basta solo accendere la macchina, ma bisogna fare in modo che la macchina parli con l’infrastruttura e per parlare serve una rete, per cui questo è fondamentale. Le applicazioni, ovvero possono esserci delle applicazioni non funzionanti perché non ci sono le conoscenze di quell’applicazione. L’applicazione è importante come line of business, ma viene tirata su l’infrastruttura, viene tirata su la macchina e poi per qualche motivo l’applicazione non funziona. Bisogna avere il responsabile dell’utilizzo di quell’applicazione e dirgli che non funziona. Un altro sempre legato alla rete più pubblica che privata è l’irraggiungibilità via DNS.
MATTEO: Un classico!
ALESSIO: Bisogna pensare prima che quando noi ripristineremo una macchina in cloud dovremo essere in grado di raggiungerla in maniera veloce.
MATTEO: Sì. Questa, ad esempio, anche per mia esperienza, 9 volte su 10 è l’elemento su cui si tende a scivolare di più, cioè non ci si pensa. Il fatto che io quando vado a ripristinare una macchina che è pubblicata, devo garantire anche la raggiungibilità a livello di DNS perché magari l’IP della macchina ripristinata non è più identico a quello che era l’IP della macchina sorgente di produzione. Ottimo, ottimo. Grazie per questi spunti!
Una volta che abbiamo in qualche modo consolidato o comunque abbiamo tenuto in considerazione tutti gli elementi che fanno parte del Disaster Recovery plan e che vado a considerare a monte, devo arrivare anche a definire, a scegliere e a implementare poi dopo quella che è l’opportuna soluzione tecnologica che mi possa aiutare a portarmi a casa il risultato del mio bellissimo piano B funzionante e testato. Quando parliamo di soluzioni tecnologiche, ce ne sono sicuramente tante, non tutte sono uguali. Lato nostro, abbiamo identificato come soluzione particolarmente innovativa e particolarmente interessante Axcient. Ci vuoi parlare un po’ di questo tipo di soluzione tecnologica e quali sono anche gli elementi particolari e differenzianti di questa tecnologia?
ALESSIO: Dunque, cercherò di essere breve perché ne parlerei per un’ora e mezza, però sostanzialmente Axcient ci dà la possibilità di proteggere le macchine, avere un’immagine delle macchine protette e fare la riaccensione in cloud di queste macchine. Questo spiegato in maniera veloce. Ha diverse features molto interessanti: dall’encrypted local cache, quindi se abbiamo alcuni dati memorizzati su un NAS o su una macchina di supporto, sono criptati; abbiamo la possibilità di avere un virtual office, quindi di accendere in cloud non solo una macchina, ma ricreare l’infrastruttura dell’ufficio protetto nel cloud di Axcient; abbiamo la possibilità di avere un autoverify, cioè il fatto che automaticamente venga verificata la bontà del backup.
MATTEO: La consistenza.
ALESSIO: Esatto, la consistenza del backup.
MATTEO: È fondamentale!
ALESSIO: E una cosa che a me piace molto è la funzionalità di Air gap. L’Air gap è una funzionalità che in qualche modo inganna l’attaccante perché sappiamo che ci sono diversi attacchi (o anche errori umani, però parliamo anche di attacchi), cioè: può succedere che i backup vengano cancellati o per un errore umano, o per un attacco. L’interfaccia mostra che i backup sono stati cancellati, ma in realtà ci sono ancora sotto, cioè c’è un tempo di retention superiore alla cancellazione. Questo serve perché, se si è fatto un errore o se c’è stato un attacco si è in grado di ripristinare comunque il backup, anche se appare cancellato.
MATTEO: È fondamentale, questo lo potremmo chiamare il piano B del piano B!
ALESSIO: Esatto, il piano B del piano B.
MATTEO: Ok! È molto interessante! Dal lato nostro, un elemento che ci ha conquistato fin da subito, oltre a questa funzionalità legata alla possibilità di avere una copy air gap dei dati che è fondamentale, come dicevi tu, in caso di attacco compromissione del TenantCloud, è comunque anche la facilità di gestione di una tecnologia di questo tipo, di riaccessione, del ricreare l’ambiente di produzione in cloud, come dicevi tu la funzionalità di virtual office, e un’altra cosa, mi permetto di aggiungere, estremamente interessante che semplifica anche, da un certo punto di vista, il progetto di DR, ovvero il fatto che, una volta che io vado a riaccendere le mie risorse, le mie VM sul cloud di Axcient, fondamentalmente non mi devo preoccupare di quelle che sono le risorse computazionali che venivano utilizzate nell’ambiente di produzione perché, da un certo punto di vista, è tutto compreso nel servizio e nella soluzione. Bene, io Alessio ti ringrazio, non so se c’è qualche altro elemento che volevi aggiungere e che ti sentivi di aggiungere.
ALESSIO: No, mi sento solo di aggiungere che è fondamentale fare le prove. Questa è l’unica cosa. Non basta fare il backup, bisogna fare le prove.
MATTEO: Assolutamente sì. Grazie per aver risottolineato la cosa perché altrimenti nel momento in cui tiro fuori il famoso piano B dal cassetto e lo vado a utilizzare, se questo poi dopo non funziona, allora diventa veramente un grosso problema. Bene, io a questo punto, Alessio, ti ringrazio. Vi lascio i nostri riferimenti nel caso in cui desideraste approfondire questo tipo di tematica, come sempre! Grazie ancora a tutti, grazie Alessio di questa condivisione e di questa piacevole chiacchierata. Un saluto a tutti quanti e alla prossima!
ALESSIO: Ciao!
