La regola del tre-due-uno aiuta a verificare se tutta la protezione dei dati dipende da un’unica posizione o da un unico dispositivo. La formulazione classica è semplice: tre copie dei dati, due tipi di supporto diversi e almeno una copia fuori dalla sede principale. Contare le copie, però, non basta. Occorre capire quale guasto potrebbe colpire ciascuna copia e se questa permetterebbe di ripristinare le attività.
Secondo le linee guida del CERT negli Stati Uniti, le tre copie includono i dati attivi e due copie di backup. Non richiede tre copie in aggiunta alla copia originale. Due tipi di supporto e una copia in un sito esterno riducono la dipendenza da una singola causa di guasto.
Definire prima i dati e il risultato del ripristino
Iniziate con i sistemi aziendali anziché acquistare un disco. Identificate i file, i database, i dati di posta elettronica e le impostazioni necessari per ripristinare le operazioni importanti. Verificate che siano inclusi anche le configurazioni delle applicazioni e le informazioni necessarie per utilizzare i dati. Per i servizi SaaS, chiarite la copertura effettiva degli oggetti, delle relazioni e delle operazioni di ripristino disponibili.
Assegnate un responsabile a ciascun sistema protetto. Tale responsabile conferma l’ambito dei dati e la perdita accettabile di modifiche recenti. Il reparto IT verifica come ottenere un punto di ripristino utilizzabile e quanto tempo impiegherà per ripristinare un servizio funzionante. La regola di collocazione non imposta automaticamente RPO e RTO.
Comprendere il significato di ciascun numero
Tutte e tre le copie devono restare utilizzabili
La copia di lavoro supporta le operazioni attuali. Le copie di backup devono consentire di tornare allo stato richiesto in caso di perdita o corruzione dei dati. Avere due cartelle su un disco non fornisce una protezione indipendente contro il guasto di quel disco. Anche diversi nomi di lavoro non dimostrano che esistono diverse copie utilizzabili.
Verificare quali risorse sono effettivamente necessarie per ripristinare ogni copia. Una catena incrementale potrebbe dipendere dalla copia di backup completa originale e dai dati intermedi. Se una parte richiesta manca, la collezione di file risultante non produrrà il risultato atteso. Registrare queste dipendenze nel diagramma, anche se il software le nasconde nella sua interfaccia.
Due tipi di archiviazione riducono il rischio comune
La regola classica prevede l’utilizzo di diversi tipi di supporto. Anche gli ambienti moderni richiedono la valutazione dell’indipendenza del sistema di archiviazione. Un guasto, un errore amministrativo o la perdita dell’accesso non devono distruggere l’intero set. Due dischi in un array, due cartelle in un servizio o copie sotto un amministratore non protetto possono comportare rischi significativi.
Scegliere lo storage in base al volume, alla velocità di recupero, alla gestibilità e alle condizioni di accesso. I supporti locali, lo storage separato e le copie nel cloud hanno limiti diversi. Nastro, cloud e disco esterno non sono la scelta giusta semplicemente perché hanno nomi specifici. Considerare la compatibilità del ripristino, la manutenzione dell’attrezzatura e l’accesso alle chiavi necessarie.
Conservare una copia fuori dalla sede principale
Una copia fuori sede affronta la perdita del sito principale, come danni all’edificio o un’interruzione dell’infrastruttura. Un armadio adiacente non è un altro sito in questo scenario. Registrare la posizione effettiva dei dati e le condizioni per accedervi.
“Fuori sede” e “offline” hanno significati diversi. Lo storage remoto può rimanere continuamente accessibile tramite un account di produzione. I supporti disconnessi possono trovarsi nella stessa stanza. Verificare la posizione geografica separatamente dalla protezione contro i cambiamenti tramite reti condivise o permessi.
Non considerare la sincronizzazione come un backup
Meccanismi diversi affrontano cause diverse di perdita
|
Meccanismo |
Che cosa può offrire |
Che cosa verificare separatamente |
|---|---|---|
|
Backup |
Punti da cui ripristinare uno stato precedente |
Copertura, versioni, indipendenza e ripristino riuscito |
|
Sincronizzazione |
Mantenere allineati i file attuali tra posizioni diverse |
Se la cancellazione o la corruzione si propagano a tutte le posizioni collegate |
|
Replica |
Copiare le modifiche e fornire un ambiente di riserva |
Come viene preservata la cronologia richiesta e cosa succede alle modifiche errate |
|
Snapshot |
Lo stato di una risorsa supportata in un momento scelto |
Se il backup dipende dallo stesso spazio di archiviazione, accesso o fonte dati |
|
Ridondanza dei dischi |
Resistenza a determinati guasti hardware |
Protezione contro la cancellazione, incidenti condivisi, corruzione e indisponibilità del sito |
Il nome di un servizio di archiviazione nel cloud non dimostra che si dispone di un backup. Se la cancellazione o la crittografia si propagano a una copia collegata, è necessario un metodo separato per ottenere una versione precedente utilizzabile. Verificare la configurazione effettiva e il periodo di storico disponibile, piuttosto che semplicemente un’icona del cloud.
Mappare le copie dei propri sistemi
Copiare il modulo di valutazione e completare le informazioni relative a posizioni, dipendenze e metodi di ripristino per il vostro ambiente. Se esistono classi di dati separate, creare un diagramma per ogni classe importante. Utilizzare nomi di sistemi di archiviazione reali, piuttosto che categorie generiche, in modo che il team possa verificare ogni elemento.
Schema di tre copie con campi di verifica
|
Copia |
Dati, supporti e posizione |
Dipendenze |
Chi gestisce l’accesso |
Evidenza dell’utilizzabilità |
|---|---|---|---|---|
|
Dati di lavoro |
[Sistema, tipo di archiviazione e sede] |
[Autenticazione, rete, applicazione] |
[Responsabile del servizio] |
[Inventario dei dati e operazioni di lavoro] |
|
Backup per il ripristino ordinario |
[Dati, supporto o tipo di archiviazione separato, posizione] |
[Catena necessaria, software, chiavi] |
[Ruoli approvati] |
[Punto di ripristino ed esito della prova] |
|
Backup fuori sede |
[Dati, supporto o tipo di archiviazione, sede esterna] |
[Connettività, accesso alternativo, recupero dei dati] |
[Ruoli e limitazioni all’eliminazione] |
[Ripristino senza la sede principale] |
Dopo aver completato il modulo, ponete una domanda difficile: cosa succede a ogni riga se l’account principale viene compromesso? Quindi, testate la perdita del sito, l’indisponibilità della rete e l’eliminazione accidentale. Se ogni scenario lascia solo la speranza nello stesso servizio e amministratore, riconsiderate l’indipendenza.
Verificare anche cloud, accesso e isolamento
La resilienza del cloud non sostituisce lo storico di ripristino
Una infrastruttura distribuita fornita può aiutare a resistere ai guasti hardware. Tuttavia, la disponibilità della piattaforma non è la stessa che garantire la conservazione dello stato dei vostri dati dopo un comando di eliminazione o un errore di applicazione. Sostituite il dibattito sull’obsolescenza della regola “tre due uno” nel cloud con controlli sulle cause specifiche di perdita.
Diverse regioni, account o fornitori possono offrire livelli di separazione diversi. Nessuno garantisce l’indipendenza da solo. Verificate i permessi condivisi, i termini di conservazione, l’accesso alle chiavi, la compatibilità con l’ambiente di destinazione e il ripristino quando l’account originale non è disponibile. Non cambiate fornitori solo per aggiungere un’altra riga a una tabella se la verifica rimane impossibile.
Proteggere le copie e la possibilità di utilizzarle
Limitare i permessi per modificare o eliminare i backup, separare i ruoli amministrativi necessari e fornire un accesso di ripristino protetto. Applicare le misure di autenticazione e crittografia consolidate. Verificare dove sono memorizzati le chiavi e come i dipendenti autorizzati le otterrebbero se l’ambiente di lavoro normale non è disponibile.
Per i supporti fisici, considerare lo stoccaggio, il trasporto, il tracciamento e l’accesso a apparecchiature compatibili. Per un servizio esterno, è necessario definire chiaramente i termini di recupero dei dati, i limiti di esportazione e le dipendenze di connettività. La protezione deve coprire più del tempo in cui una copia è memorizzata: includere il trasferimento, il ripristino e la successiva gestione.
Comprendere le estensioni della regola
I modelli estesi aggiungono una copia isolata o immutabile e controlli di ripristino separati. La variante “tre due uno uno zero” di solito enfatizza questa protezione e verifica aggiuntiva, assicurando che non siano stati riscontrati errori. È un utile promemoria, non una prova che i futuri guasti non si verificheranno mai. Nomi e implementazioni possono differire tra i fornitori.
L’immutabilità limita le modifiche o l’eliminazione in determinate condizioni. Una copia offline riduce l’accessibilità alla rete. Queste proprietà sono diverse e non sostituiscono la conservazione adeguata. Scegliere politiche di blocco e periodi di conservazione separatamente. Il diagramma della copia deve solo registrare dove si applica la protezione e chi l’ha verificata.
Provare il ripristino e mantenere aggiornato lo schema
Verificare il risultato operativo, non solo lo stato del processo
Un backup di successo conferma il completamento entro l’ambito del lavoro. Per testarlo, ripristinare i dati necessari ed eseguire l’azione di lavoro concordata. Verificare le versioni, i permessi, l’integrità e la disponibilità delle dipendenze. Testare separatamente uno scenario in cui il sito principale o l’amministratore abituale non sono disponibili.
CISA raccomanda di mantenere backup offline e crittografati dei dati critici e di testare regolarmente la loro disponibilità e integrità durante il ripristino. Questo integra la pianificazione del posizionamento; non trasforma il piano in una garanzia contro ogni attacco.
Volume dei dati, larghezza di banda, velocità di recupero dei dati e preparazione dell’ambiente influiscono sulla durata. I costi possono includere la conservazione della cronologia, il recupero dei backup, la rete e la manodopera del team. Verificare queste condizioni in anticipo. Una velocità di trasferimento universale o una promessa di avviare qualsiasi sistema entro pochi minuti non sono appropriati.
Assegnare un responsabile per modifiche ed eccezioni
- Confermare l’ambito dei dati protetti e le dipendenze.
- Verificare il numero di copie effettivamente utilizzabili e le diverse cause di guasto.
- Chiarire la collocazione fuori sede e le restrizioni di accesso separate.
- Basare il programma sulle perdite di dati accettabili, piuttosto che su un programma predefinito di terzi.
- Conservare i risultati del ripristino e gli errori rilevati.
- Assegnare un responsabile della correzione, una scadenza e una nuova prova.
- Rivedere il diagramma dopo la crescita dei dati o modifiche al servizio, al sito o alle autorizzazioni.
Definire le politiche di conservazione delle versioni e i programmi di test in base alle proprie esigenze e vincoli. Backup giornalieri o test trimestrali non possono essere considerati sufficienti per ogni carico di lavoro. Anche le copie aggiuntive richiedono un controllo: una copia non supportata con una vecchia chiave o una data di cancellazione sconosciuta non migliora un piano semplicemente esistendo.
È necessario verificare la separazione e la ripristinabilità delle copie? Contattare DKs Enterprises per informazioni su backup e disaster recovery. Preparare il diagramma di posizionamento, l’elenco dei sistemi e i risultati dei test recenti per discutere del lavoro necessario.
