Rischi e complessità nei processi di migrazione non si possono contare. Tanto che un progetto di questo tipo si può considerare riuscito non solo quando gli obiettivi vengono raggiunti nel rispetto di budget e tempi, ma soprattutto quando prima, durante e dopo la migrazione, si è in grado di offrire al cliente un’analisi completa che comprenda la valutazione dei rischi in modo da tutelare l’efficienza operativa, in ogni caso.
Significa essere consapevoli di non poter escludere al 100% i rischi, ma anche sapervi fare fronte e assicurare tempi di reazione soddisfacenti per conseguenze minime.
Attenzione ad applicazioni e dati
Sono le applicazioni e i dati a “correre i rischi” maggiori in un progetto di migrazione. Le applicazioni dipendono da diverse componenti software, l’integrità dei dati dipenderà sempre, almeno in parte, anche dal corretto funzionamento dell’applicazione.
A seconda degli scenari le applicazioni possono essere in esecuzione su tipologie di storage eterogenee, o su diversi dispositivi di archiviazione, e girare magari su server collegati in rete che potrebbero rivelare all’atto della migrazione dipendenze non documentate in modo accurato, anche per la successiva “stratificazione” di risorse e procedure accumulate negli anni.
Qui si annidano alcuni dei rischi sottovalutati che solo una precisa mappatura riuscirà a ridurre. La mappatura di risorse e dipendenze sarà quindi in ogni caso il primo passaggio da seguire e affrontare con cura.
Chi è responsabile?
Sfruttare una migrazione per spostare in cloud in parte o tutta la propria infrastruttura costringe a porsi una serie di interrogativi per comprendere dove inizi e finiscano le proprie responsabilità su dati e app, rispetto a quelle del provider (sia nel caso di una scelta di cloud pubblico, sia nel caso di una scelta di cloud ibrido) e per comprendere i benefici di una gestione “centralizzata”.
Sono tanti (i benefici), ma lo sono anche i rischi, legati alle possibili attività di sottrazione dei dati, la cui causa prima è quasi sempre una gestione delle credenziali degli utenti approssimativa o basata su password deboli.
Se la scelta del partner sarà stata effettuata con intelligenza, l’azienda beneficerà della certezza che sicurezza e aggiornamenti sono assicurati in modo omogeneo su tutte le risorse fisiche, perché è interesse primo del provider organizzare update e upgrade ottimizzati, ma non si può ignorare che policy, processi e attività diventano efficaci nel momento in cui a monte, a partire dalle applicazioni, si è proceduto con un’analisi dei rischi quanto più granulare possibile.
I rischi per le applicazioni
L’analisi dei rischi deve comprendere: la valutazione di data breaches, e della data loss, la valutazione di interfacce e Api, i rischi DoS, la possibilità di malicious insider, eventuali abusi dei servizi cloud e una corretta due diligence.
Intendiamo sottolineare che è essenziale da parte del cliente – e ovviamente deve in questo senso dimostrarsi trasparente il provider di servizi – la perfetta comprensione dell’ambiente del cloud service provider (Csp) su cui si approda.
Quando si migra non solo infrastruttura ma si sceglie una nuova piattaforma e si spostano le applicazioni (PaaS e SaaS), la comprensione delle responsabilità operative deve accompagnarsi alla valutazione su vantaggi e svantaggi di una reingegnerizzazione nativa, piuttosto che di un semplice “adattamento” del codice.
Nello specifico i rischi della migrazione dei dati prevedono oltre alla semplice perdita di informazioni, gli errori di semantica (incoerenza tra campi di partenza e destinazione), il downtime, la corruzione del dato.
Sono problemi le cui cause hanno natura molteplice. Possiamo parlare quindi di instabilità dell’applicazione, che ha comportamenti diversi on-premise e una volta migrata, parliamo di rischi legati a una non corretta orchestrazione del processo di migrazione (anche solo quindi nella scelta della sequenza temporale di cosa migrare e quando), parliamo però anche dei rischi di interferenza che occorrono quando più processi utilizzano simultaneamente un’applicazione durante la migrazione.
Una checklist per fare bene
Per questo proponiamo una sorta di semplice checklist in tre soli punti da seguire per preservarsi almeno dai rischi facilmente evitabili.
Essa comprende: la valutazione intrinseca delle applicazioni che si sta per migrare; la valutazione con attenzione di cosa accadrà a dati e Api delle applicazioni legacy che si stanno migrando; la valutazione di quali vulnerabilità potrebbero affliggere le applicazioni che si portano in cloud. Entriamo nel dettaglio.
Il primo punto richiede una valutazione accurata dei processi in gioco per una pianificazione adeguata. Si partirà quindi dai vantaggi che si otterranno anche e proprio da un punto di vista qualitativo e quantitativo (performance/disponibilità applicativa e Roi).
Qui sono da fare le valutazioni relative alla sicurezza più importanti. Può essere infatti che il ritorno degli investimenti sia misurabile solo in termini di efficienza e sicurezza, per esempio per il cambio di piattaforma, o legarsi proprio ad un aggiornamento chiave per cui si coglie la migrazione come opportunità.
Dati e Api sotto la lente
Abbiamo visto perché dati e Api sono risorse critiche. Alcune informazioni però sono più critiche rispetto ad altre o comunque hanno priorità diversa di elaborazione all’interno dell’applicazione. In questa fase il lavoro del team per “classificare” questa priorità si rivelerà funzionale poi in fase decisionale.
Una valutazione di criticità elevata potrà catalizzare maggiore attenzione, le risorse migliori e determinare quindi il progetto di un framework funzionale alla riduzione dei rischi comprensivo magari di una proiezione di come una perdita parziale dei dati potrebbe incidere sul Roi.
La valutazione delle minacce
L’abbiamo accennato. Quello che bisogna capire è come e se la tecnologia di approdo esporrà le applicazioni legacy a nuove vulnerabilità. Anche in questo caso un buon sistema è procedere con una valutazione – applicazione per applicazione – delle vulnerabilità che potrebbero essere sfruttate a fronte di quelle che erano.
Critica in questa fase è proprio la capacità di individuare l’impatto della minaccia in relazione ai danni effettivi provocabili sull’attività sia per quanto riguarda gli economics, sia per quanto riguarda la reputation.
Un modello per la sicurezza
Cerchiamo di essere chiari il più possibile. Uno scenario di sicurezza collaudato su applicazioni legacy on premise non è semplicemente “trasferibile” su un nuovo modello di cloud ibrido. Nell’execution il risultato di una migrazione può determinare un incremento di complessità per quanto riguarda la sicurezza della rete. E’ vero che la migrazione in cloud di app e dati è vista spesso come soluzione per ridurre la complessità IT.
Ed è vero che provisioning, manutenzione e applicazioni di patch hardware e software si semplificheranno. Sarà solo la cura mostrata in fase di design ad evitare che cloud e soluzioni discrete non generino anche nuovi silos, tanto più quando una singola applicazione si estende su più configurazioni cloud. Evitare nuovi silos già in fase di design è un passo importante per salvaguardare la sicurezza. E in questo il partner che si sceglie gioca un ruolo importante.
“What’s next?” quando si parla di futuro.
Non perdere tutti gli approfondimenti della Rubrica WhatsNext
© RIPRODUZIONE RISERVATA
