Quali sono le differenze di protezione tra il backup in outsourcing e il disaster recovery gestito?

Negli ultimi dieci anni circa, le soluzioni IT si sono orientate verso il modello "as a Service". Le soluzioni di backup e di disaster recovery non fanno eccezione.

Il backup come servizio è noto anche come Backup as a Service (BaaS) e il Disaster Recovery as a Service è noto anche come Disaster Recovery as a Service (DRaaS). Questi servizi si riferiscono a soluzioni fornite da fornitori di servizi alle aziende.

Ciò significa che i team IT dell'azienda non devono installare e mantenere le soluzioni localmente nei propri data center. Le offerte dei fornitori di servizi possono includere anche la gestione dei test (riavvio, disaster recovery, rete) e la manutenzione dei servizi operativi .

I reparti IT sono al centro della scelta di queste soluzioni. Prima di prendere una decisione, devono comprendere le diverse opzioni offerte e le implicazioni per la protezione dei loro dati. Questi due metodi di protezione, spesso percepiti come simili, non coprono gli stessi scenari di rischio.

Definizione di backup come servizio (BaaS)

Sempre più fornitori di servizi offrono soluzioni di Backup as a Service. Queste corrispondono all' acquisto di un servizio di backup online, generalmente in un cloud (pubblico, privato o privato).

Le soluzioni BaaS possono coprire diverse aree:

• backup di file e cartelle
• backup di un intero disco
• backup di applicazioni (Domain Controller, Exchange) o database (SQL server, PostgreSQL, Oracle, ecc.).

I recenti sviluppi del BaaS hanno reso possibile automatizzare i test per il ripristino o il riavvio dei server (completo o parziale). Questi test possono essere eseguiti manualmente o tramite API o automi.

Definizione di Disaster Recovery as a Service (DRaaS)

Il concetto di Business Disaster Recovery Plan as a Service è più recente, ma si sta espandendo rapidamente per rispondere a nuove problematiche, come le minacce informatiche.

Si tratta di un servizio completo fornito e amministrato da un fornitore, basato sul modello del cloud e che offre un tempo di ripristino garantito (RTO).

Queste soluzioni sfruttano i principali vantaggi del cloud (elasticità, pay-per-use) e quindi riducono i costi associati alle dimensioni dell'infrastruttura.

I perimetri affrontati da queste soluzioni DRaaS sono potenzialmente molto diversi:

• In termini di OS coperti: mentre le architetture x86 sono sempre coperte, gli OS più rari (OS400, Unix proprietario, ecc.) sono supportati solo raramente.
  
  
• Tempi di RTO (riavvio in caso di attivazione del DRP): le tecnologie utilizzate possono essere molto diverse, consentendo RTO da poche decine di minuti (si parla di Continuity Plan piuttosto che di Recovery Plan) a qualche ora.
  
  
• I servizi forniti: si può trattare di un DRP parzialmente gestito (il cliente è responsabile del mantenimento delle condizioni operative e dell'esecuzione dei test DRP in autonomia) o di un DRP completamente gestito dal fornitore (test regolari di riavvio dei server, monitoraggio dei backup del cloud, ecc.)

Questi diversi elementi sono importanti da tenere in considerazione nella scelta della soluzione. Per questo motivo è necessario effettuare un' analisi preventiva , per capire di cosa avete bisogno in termini di server da proteggere, tempi di riavvio e freschezza dei dati.e freschezza dei dati (RTO e RPO) e, infine, i requisiti di gestione, in base alla disponibilità e alle competenze dei vostri team tecnici.

I rischi coperti e non coperti da queste due soluzioni

Per comprendere appieno la differenza tra questi due servizi, dobbiamo innanzitutto esaminare i diversi rischi che ciascuna delle due soluzioni affronta.

Analizzeremo diversi tipi di rischio che devono essere coperti dal backup (BaaS) e dal disaster recovery (DRaaS), suddivisi in famiglie.

Scenari di rischio: perdita o corruzione dei dati

Perdita o corruzione di file: può essere dovuta a un errore dell'utente/computer, a un problema hardware o a un errore procedurale.

Domande da porre in relazione allo scenario di rischio:

• Storage di backup nel cloud:
  • Quante repliche dei dati di backup vengono eseguite nel cloud (1, 2 o 3 repliche?)?
  • Le repliche dei backup nel cloud vengono eseguite su diversi DC remoti?
• Possibilità o meno di avere periodi di conservazione dei backup diversi:
• Per tipo di file,
• Mantenendo N versioni di ogni file.

Scenari di rischio: perdita o danneggiamento del sistema operativo (OS) o del database

Domande da porre in relazione allo scenario di rischio:

• Esistono meccanismi per il backup dei sistemi operativi Linux in contesti infrastrutturali in cui non è possibile utilizzare i meccanismi dell'hypervisor (tipicamente in cloud pubblici o privati)?
• La soluzione ha la capacità di eseguire il backup solo di alcuni dischi/partizioni della macchina per limitare la quantità di dati da sottoporre a backup e accelerare il ripristino?

Scenari di rischio: indisponibilità completa di uno o più server

Domande da porre in relazione allo scenario di rischio:

• Senza test, non c'è salvezza: la soluzione ha tenuto conto della necessità di eseguire regolarmente test di riavvio del server (completamente automatici o manuali)? Si raccomanda una frequenza minima di test di riavvio annuale.
• Quali sono i tempi di fornitura dell'infrastruttura IT in loco: spesso non sono compatibili con le esigenze aziendali (soprattutto in questo momento di carenza di componenti) e quindi non consentono di ricreare un'infrastruttura in loco in tempi accettabili.

Scenari di rischio: indisponibilità del data center

Completa indisponibilità del data center, sia a seguito di un disastro (incendio, tempesta, alluvione, attentato, ecc.), sia a causa dell'indisponibilità a lungo termine della rete o dei fluidi (elettricità, aria condizionata, ecc.).

Domande da porre sullo scenario di rischio:

Senza un test DRP non c'è salvezza, quindi è necessario verificare che vengano eseguiti regolarmente test DRP: si raccomanda una frequenza di test semestrale o inferiore.

I test DRP devono riguardare il ripristino dell'infrastruttura, i test di rete, la riconnessione degli utenti e i test funzionali dello spazio di ripristino da parte dell'utente finale.

Scenario di rischio: ransomware su un file server o su server OS

Infezione da ransomware tramite software dannoso propagato via e-mail, sfruttando una vulnerabilità.

Domande da porre sullo scenario di rischio:

• La soluzione scelta tiene conto della tenuta stagna contro un attacco ransomware? Lo spazio di backup non deve essere facilmente accessibile dal ransomware (ad es. punto di montaggio di Windows, ecc.).
• Il tempo necessario per riportare in linea tutti i backup del cloud attraverso la rete deve corrispondere alle esigenze aziendali. La domanda da porsi è: la soluzione consente di riportare i dati in locale tramite box specializzati (tipo NAS, disco SSD, ecc.) del fornitore di servizi?

Scenari di rischio: attacco informatico sofisticato che combina diversi meccanismi di attacco

Attacco costruito che consente all'aggressore di assumere il controllo dell'infrastruttura del cliente con diritti privilegiati.

Punti da tenere d'occhio: l'impermeabilità dei backup nel cloud è diventata un problema importante in caso di attacco informatico sofisticato.

Scenari di rischio: minaccia persistente avanzata o attacco dormiente

Infezione da parte di una APT o di un malware dormiente che può essere attivato diversi mesi dopo l'infezione e che richiede una lunga conservazione dei dati del sistema operativo (più di 6 mesi).

Domande da porre in relazione allo scenario di rischio:

• In questo caso si tratta di archiviare le macchine virtuali per lunghi periodi (1 mese per 24 mesi, ad esempio).
• La soluzione di ricostruire completamente il sistema operativo a volte non è disponibile.

In sintesi, i 3 buoni consigli

1 - Comprendere le sfide aziendali

Il primo consiglio, come per molti progetti IT, è quello di comprendere appieno le sfide che l'azienda deve affrontare:

• le loro esigenze in termini di backup (profondità dei backup, meccanismi di archiviazione dei dati, ecc,)
• le loro esigenze in termini di applicazioni critiche da riavviare in caso di disastro o attacco informatico:
  • stabilire le priorità (RTO),
  • definire la freschezza dei dati richiesti (essenzialmente database).

2 - Identificare gli scenari di rischio da coprire

Occorre poi identificare gli scenari di rischio da coprire per le attività e le infrastrutture aziendali (perdita di dati, ransomware, perdita del data center):

• Questa mappatura dei rischi rivelerà inevitabilmente una tendenza: o una soluzione BaaS è sufficiente, o c'è bisogno di DRaaS;
• far convalidare la copertura dei rischi dal management. Nonostante la loro scarsa comprensione quando si tratta di Backup e DRP, la copertura del rischio IT è un problema importante di cui il management è ben consapevole. Sebbene possano non capire nulla di Backup e DRP, sono sempre più consapevoli dei rischi IT che devono essere coperti.

3 - Identificare ed esprimere i requisiti

Una volta identificati i rischi da coprire, è il momento di identificare i requisiti della soluzione:

• Innanzitutto, le aspettative del fornitore di servizi: volete una soluzione parzialmente gestita o una soluzione completamente gestita con impegni contrattuali?
• Se è necessario un backup:
  • Qual è l'ambito da coprire: sistemi operativi, tipi di DBMS, ecc.
  • Come devono essere caricati inizialmente i dati (disponibilità di un'appliance dedicata)?
• In caso di piano di disaster recovery:
  • Quali server devono essere protetti in caso di disastro e per quali è sufficiente una soluzione di backup?
  • Quali sono i requisiti di rete specifici: come si riconnettono i siti (MPLS, SD-Wan), gli utenti mobili (SSL VPN, ecc.)?
  • Quali sono le specifiche in termini di sicurezza: le soluzioni di sicurezza necessarie in caso di back-up?