Piano di ripristino dopo un disastro per DevOps

Un piano di disaster recovery ben progettato è fondamentale per mitigare i rischi, riprendersi rapidamente dai fallimenti e garantire l’integrità dei tuoi dati e dell’infrastruttura.

Ci sono Miti Relativi al DR in DevOps?

Alcune organizzazioni ancora erroneamente assumono che gli strumenti DevOps, come GitHub, GitLab, Bitbucket, Azure DevOps o Jira, dispongano di un ripristino di emergenza integrato e onnicomprensivo. Tuttavia, non dovremmo dimenticare i modelli di responsabilità condivisa, che chiariscono esplicitamente che mentre i fornitori proteggono la propria infrastruttura e gestiscono senza intoppi i propri servizi, gli utenti devono salvaguardare i propri dati dell’account. 

Ad esempio, prendiamo in considerazione la citazione delle Pratiche di Sicurezza di Atlassian:

“Per Bitbucket, i dati sono replicati in una diversa regione AWS, e backup indipendenti sono effettuati giornalmente in ciascuna regione. Non utilizziamo questi backup per ripristinare modifiche distruttive initiate dal cliente, come campi sovrascritti tramite script o problemi, progetti o siti eliminati. Per evitare la perdita di dati, consigliamo di effettuare regolari backup.”

Potresti trovare gli stessi consigli in qualsiasi modello di responsabilità condivisa di un fornitore SaaS. E errori in quest’area possono portare a gravi interruzioni, inclusa la perdita di dati di codice sorgente critico o metadati, danni alla reputazione e perdite finanziarie.

Sfide Uniche per l’Ecosistema DevOps

Mentre sviluppi il tuo piano di ripristino di emergenza per la tua piattaforma DevOps, vale la pena considerare le sfide che i DevOps affrontano da questo punto di vista.

Le ecosystem DevOps hanno sempre un’architettura complessa, come pipeline e ambienti interconnessi (es. integrazione tra GitHub e Jira). Pertanto, un singolo guasto, sia esso dovuto a un artefatto corrotto o a un attacco ransomware, può propagarsi nell’intero sistema. 

Inoltre, lo sviluppo rapido dei DevOps comporta cambiamenti costanti, che possono complicare i controlli di coerenza e integrità dei dati durante il processo di ripristino.

Un’altra problematica riguarda le politiche di conservazione dei dati. Gli strumenti SaaS spesso impongono periodi di conservazione limitati – di solito variano da 30 a 365 giorni. Quindi, ad esempio, se elimini accidentalmente il tuo repository senza averne una copia di backup, potresti perderlo per sempre. 

Perché il Ripristino di Emergenza è un Imperativo dei DevOps

La criticità dei dati è importante, ma non è l’unico motivo per cui le organizzazioni devono sviluppare e migliorare i loro meccanismi di Ripristino di Emergenza. Un piano efficace di ripristino di emergenza può aiutare le organizzazioni:

• Attenuare i rischi, poiché le interruzioni di servizio, i cyberattacchi e le cancellazioni accidentali possono portare a tempi di inattività prolungati e perdita di dati.

Fatti e statistiche: Nel 2023, gli incidenti che hanno impattato gli utenti di GitHub sono cresciuti di oltre il 21% rispetto al 2022. Per quanto riguarda GitLab, circa il 32% degli eventi è stato riconosciuto come avendo un impatto sulle prestazioni del servizio e sugli utenti interessati. (Statistiche tratte dal Rapporto sullo stato delle minacce DevOps).

• Allinearsi ai requisiti di conformità e regolamentazione — ad esempio, ISO 20071, GDPR o NIS 2 impongono alle organizzazioni di avere meccanismi robusti di protezione e ripristino dei dati. La mancata conformità può comportare pesanti sanzioni e conseguenze legali.

Nota: Nel dicembre 2024 è entrato in vigore il Regolamento sull’adattamento cibernetico dell’UE. Ciò significa che entro dicembre 2027, le organizzazioni che forniscono prodotti e servizi digitali e operano nell’Unione europea dovrebbero adattare la propria protezione dei dati e la gestione degli incidenti ai requisiti legislativi.

• Ridurre o eliminare il costo dell’inattività, poiché ogni minuto di indisponibilità del sistema equivale a una perdita di ricavi. Il costo medio dell’inattività può superare i $ 9.000 al minuto, rendendo essenziale un ripristino rapido.

Linee guida per la creazione di un solido piano di ripristino di emergenza

Non è cruciale che il tuo piano di ripristino di emergenza preveda qualsiasi possibile scenario di disastro e fornisca a te e al tuo team tutti i passaggi necessari per affrontare rapidamente l’evento di fallimento? Scopriamo insieme i componenti di un efficace DRP…

Valutare tutti i componenti critici

Dovresti identificare gli asset DevOps più critici. Questi possono includere repository di codice sorgente, metadati, pipeline CI/CD, artefatti di build, file di gestione della configurazione, ecc. È necessario sapere quali dati sono prioritari da ripristinare in caso di guasto.

Implementare le Migliori Pratiche di Backup

È impossibile recuperare i dati senza una strategia di backup ben organizzata. Pertanto, è importante seguire le migliori pratiche di backup per garantire di poter ripristinare i tuoi dati critici in caso di guasto, inclusi un’interruzione del servizio, un’interruzione dell’infrastruttura, un attacco ransomware, l’eliminazione accidentale, ecc.

Per questo motivo, la tua soluzione di backup dovrebbe consentirti di:

• Automatizzare i tuoi backup, pianificandoli con l’intervallo più appropriato tra le copie di backup, in modo che nessun dato venga perso in caso di guasto,
• Fornire una conservazione a lungo termine o addirittura illimitata, che ti aiuterà a ripristinare i dati da qualsiasi punto nel tempo,
• Applicare la regola di backup 3-2-1 e assicurare la replica tra tutti gli archivi, in modo che in caso di guasto di una delle posizioni di backup, tu possa eseguire il backup da un’altra posizione,
• Protezione contro il ransomware, che include la crittografia AES con la tua chiave di crittografia, backup immutabili, ripristino e capacità di disaster recovery (ripristino a un punto nel tempo, ripristino completo e granulare, ripristino su più destinazioni, come una macchina locale, lo stesso o nuovo account, o crossover tra qualsiasi di GitHub, GitLab, Bitbucket e Azure DevOps).

Definire i Tuoi Metriche di Recupero

È fondamentale per un’organizzazione stabilire i propri obiettivi misurabili, come RTO o RPO.

• L’Obiettivo di Tempo di Recupero (RTO) si riferisce a quanto rapidamente i sistemi della tua azienda dovrebbero essere operativi dopo che si verifica un disastro. Ad esempio, se la tua organizzazione stabilisce il proprio RTO a 8 ore, allora in quelle 8 ore dovrebbe riprendere il proprio flusso di lavoro normale dopo un evento disastroso. Di solito, più basso è l’RTO che l’organizzazione stabilisce, meglio è preparata per un guasto.
• L’Obiettivo di Punto di Recupero (RPO) indica la perdita di dati accettabile misurata nel tempo che l’azienda può sopportare. Ad esempio, se l’azienda può facilmente sopravvivere senza 3 ore di dati, allora il suo RPO è di 3 ore. Più basso è l’RPO che hai, più frequenti dovrebbero essere i backup della tua organizzazione.

Testa e Valida Regolarmente le Tue Operazioni di Backup e Ripristino

Con ripristini di test regolari, puoi garantire l’integrità del tuo backup e avere la tranquillità che, in caso di guasto, puoi recuperare rapidamente i tuoi dati.

Inoltre, vale la pena simulare i guasti. Questo aiuterà la tua organizzazione a valutare l’efficacia del suo DRP di fronte a interruzioni simulate, attacchi ransomware o altri disastri.

Forma il Tuo Team

Il panico è il peggiore in caso di disastro. Pertanto, ogni membro del tuo team dovrebbe capire cosa dovrebbe fare in una situazione del genere. Stabilisci responsabilità e ruoli su chi dovrebbe eseguire le operazioni di ripristino e chi dovrebbe comunicare riguardo al disastro.

La tua organizzazione dovrebbe avere un piano di comunicazione per i disastri ben strutturato che indichi la strategia di comunicazione e le persone responsabili di informare le parti interessate e altre parti potenzialmente colpite, e modelli per tale comunicazione.

Studi di caso di DRP in DevOps

Analizziamo i casi di come un DRP può aiutare a evitare le conseguenze devastanti dei disastri:

Interruzioni del servizio

Una grande azienda digitale si affida completamente a GitHub (potrebbe esserci un altro fornitore di servizi, come GitLab, Atlassian o Azure DevOps). Improvvisamente, l’azienda si rende conto che il fornitore di servizi sta vivendo un’interruzione… eppure, l’azienda deve continuare le proprie operazioni il più velocemente possibile, considerando che il costo medio del tempo di inattività è di $9.000 al minuto.

Avendo un DRP completo, l’organizzazione ripristina i dati dalla copia di backup più recente, utilizzando il ripristino in un punto temporale, su GitLab (o Bitbuket o Azure DevOps). Così, l’organizzazione riprende rapidamente le proprie operazioni, elimina la perdita di dati e garantisce un tempo di inattività minimo.

Suggerimento: In una situazione del genere, la soluzione di backup dovrebbe consentirti anche di ripristinare i tuoi dati sul tuo computer locale per riprendere la continuità aziendale il più rapidamente possibile. 

Errore umano vs. Tempo di inattività dell’infrastruttura

Un programmatore invia dati errati e sovrascrive accidentalmente file critici. L’intera situazione paralizza il flusso di lavoro dell’azienda e porta al tempo di inattività. 

Fortunatamente, il DRP dell’organizzazione prevede una situazione del genere, seguendo la regola di backup 3-2-1. Così, il team IT dell’azienda esegue il backup da un altro archivio per garantire la continuità aziendale.

Attacco ransomware

Una software company di medie dimensioni affronta un attacco di ransomware che crittografa i suoi repository Git primari. Avendo implementato un DRP efficiente con backup automatizzati e funzionalità anti-ransomware, come backup immutabili, l’azienda riesce a ripristinare i suoi dati dal momento in cui non erano corrotti.

Il risultato? L’azienda riprende le sue operazioni entro poche ore, evitando una richiesta di riscatto da milioni di dollari e riducendo al minimo i tempi di inattività.

Lezione da imparare

Un piano di ripristino da disastro è una necessità strategica per le organizzazioni oggigiorno. Oltre a proteggere i dati, aiuta le organizzazioni a garantire la conformità, a costruire la fiducia dei clienti e a ridurre i rischi finanziari.

La strategia di backup dovrebbe diventare la base completa di qualsiasi DRP, anche il più esigente. Pertanto, è necessario:

• Impostare politiche di backup per automatizzare i processi di backup entro i tempi di ripristino e di ripresa più esigenti,
• Mantenere i dati in più posizioni, rispettando la regola del backup 3-2-1,
• Avere meccanismi di protezione ransomware sicuri,
• Monitorare le prestazioni dei backup tramite dashboard basate sui dati, notifiche Slack/email, SLA, report di conformità, ecc.,
• Eseguire test di ripristino,
• Ripristinare i dati in caso di guasto poiché la soluzione prevede qualsiasi scenario di DR e fornisce robuste capacità di ripristino, compreso il ripristino completo dei dati, il ripristino granulare, il ripristino al momento dell’evento, il ripristino nello stesso account o in un nuovo account, il ripristino nella propria istanza locale e
• Garantire la conformità e la resilienza informatica.