Business continuity

Per business continuity si intende la capacità che ha un'azienda a garantire la continuità di lavoro ai propri clienti.

Quando si sviluppa una applicazione client server, molto spesso ci si affida a datacenter locali che possono dare vita ad interruzioni di servizio se non è stato fatto un adeguato piano di business continuity.

Quando un azienda viene danneggiata per un atto di vandalismo, per una rottura del server di dominio o del server dati o a seguito di un incendio o evento naturale, è molto frequente che anche avendo una copia dei dati non è possibile assicurare la continuità immediata delle attività a causa del danno cagionato al personale, alle installazioni e a tutti gli altri apparati informatici.

Molto spesso infatti occorrono delle ore prima di poter ripristinare la situazione ordinaria e tornare a lavorare.

Pur predisponendo server di backup domain controller e repliche dei dati non vengono neanche effettuati dei test per verificare che tutto funzioni.

Noi di Micropedia abbiamo superato da tempo queste logiche, affidandoci a servizi esterni per la gestione della business continuity.

Attualmente sviluppiamo esclusivamente web application con database Sql server o MySql.

La nostra mission da quando abbiamo abbandonato le applicazioni desktop è appunto quella di garantire al cliente di lavorare sempre, senza intervento umano da parte nostra.

I nostri server sono infatti ubicati in Germania da Contabo, la migliore server farm d'Europa e precisamente in un datacenter di Francoforte.

I server sono ridondati secondo le specifiche ISO 22301 in maniera tale che qualsiasi evento dovesse verificarsi al server principale, immediatamente al suo posto si renderebbe disponibile agli utenti una copia immagine speculare dell'ultima operazione in maniera completamente trasparente all'utente.

In buon sostanza il server avrebbe anche lo stesso indirizzo IP e  nome dominio del principale, cosa che permette di continuare a lavorare senza problemi, avendo tutto il tempo di sistemare la situazione sul server principale danneggiato.

Per quanto riguarda i backup dei database quelli li facciamo comunque in un area FTP differentemente collocata dal punto di vista geografico. Anche il server in mirroring si trova ubicato in un datacenter differente.

Molti avendo un sistema di server in replica trascurano il fatto di fare comunque delle copie esterne delle basedati, ma è un ulteriore punto a favore di un eventuale disaster recovery poter avere una copia esterna ed autonoma dei dati perchè non si sa mai in che modo potrebbe avvenire il databreach: come vedremo in seguito un ransomware può rendere vano il nostro lavoro.

Nel caso in cui il problema sia ad esempio un incendio, pur avendo un ottimo piano di business continuity prenderebbero fuoco sia il server principale che il server mirror e quindi il piano d'azione escogitato sarebbe inutile. Avere un CED all'interno dell'azienda per noi è diventato inutile e costoso.

Molto spesso la business continuity viene confusa col disaster recovery, ma non sono la stessa cosa: la Business Continuity è la strategia più ampia che ha l’obiettivo di assicurare la “sopravvivenza” di tutte le funzioni essenziali dell’organizzazione mentre il Disaster Recovery è la strategia che ha come obiettivo la salvaguardia di funzioni specifiche dell’organizzazione ed è solo una parte di un piano di Business Continuity.

Per elaborare un corretto piano di business continuity occorre curare i seguenti aspetti:

• • Fare una analisi di tutte le principali minacce organizzative
  • Verificare lo skill dei propri dipendenti IT: molte aziende hanno al proprio interno personale IT non aggiornato e quindi impreparato a gestire problematiche come la business continuity
  • Schema dell'architettura di tutti i server interni ed esterni dell'organizzazione
  • Un elenco delle principali arrività da realizzare per mantenere fluidi i processi aziendali in caso di disaster recovery
    
  • Informazione scritta sull'ubicazione dei software, dei dati e dove vengono effettuati tutti i backup
    
  • Recapiti telefonici di tutti i soggetti coinvolti in un eventuale ripristino da una situazione di disaster recovery e loro reperibilità nelle 24 ore
    

Un'azienda che ha al suo interno il datacenter non puo' fare a meno di avere anche un gruppo elettrogeno, perchè mentre coi server in cloud basterebbe anche un cellulare per continuare a lavorare, in caso di assenza di energia elettrica la produzione si interromperebbe.

Finora abbiamo parlato di disaster recovery da problematiche abbastanza semplici da definire e circoscrivere, ma nel caso ad esempio di un attacco informatico o da un virus che agisce sui dati crittografandoli come il Cryptolocker, bisogna prendere ulteriori accorgimenti per evitare che la copia dei dati istantanea su più server diventi un'arma a doppio taglio.

Se il cluster non viene predisposto correttamente infatti il virus si propagherebbe anche sui cloni, azzerando di fatto la business continuity.

Questo problema nell'era del GDPR causerebbe anche l'apertura di un data breach con tantissime conseguenze anche di natura penale per gli amministratori.

Per capire meglio come affrontare un data breach in caso di attacco ransomware, vi citiamo questo interessante articolo di Achab, che hanno risolto il problema con  i servizi di business continuity di Datto.

A proposito di business continuity Assintel ha realizzato anche un interessante web binar sulla Business Continuity Management che vi invitiamo a vedere:

Marco Ilardi

Micropedia srl