Backup immutabili contro i ransomware
Come proteggere i backup della tua azienda dai ransomware con lo storage a oggetti immutabile?
Lo storage a oggetti immutabile protegge i backup dai ransomware rendendone impossibile l'eliminazione. Quando il blocco degli oggetti (Object Lock) è impostato su un bucket, il livello di storage rifiuta ogni richiesta di eliminazione o sovrascrittura fino alla scadenza del periodo di conservazione, incluse le richieste che utilizzano credenziali di amministratore valide.
Perché i backup sono il primo obiettivo dei moderni ransomware
Il modello di attacco deliberato: crittografare o eliminare i backup, poi la produzione
Gli operatori dei moderni ransomware hanno professionalizzato il loro playbook. Prima di attivare il payload di crittografia sulla produzione, gli attaccanti trascorrono giorni a mappare la rete alla ricerca di lacune nella sicurezza: identificando il server di backup, le credenziali dei dipendenti e le password lasciate negli script, e la policy di accesso che protegge ogni repository. Una volta ottenuto l'accesso e presa posizione, disabilitano o eliminano prima quelle copie, poi crittografano i dati di produzione.
La sequenza è deliberata. Un'azienda in grado di ripristinare i dati in poche ore ha pochi incentivi a pagare; un'azienda le cui copie sono state eliminate giorni prima non ha questa opzione, e l'attaccante conta proprio su questo. Un attacco di questo tipo non riguarda solo la crittografia dei dati, ma l'eliminazione di ogni percorso di ripristino a disposizione di un'azienda.
Ecco perché una singola credenziale compromessa rappresenta oggi il rischio maggiore in una strategia di protezione. Il controllo degli accessi e le protezioni di identità, sicurezza e operazioni costituiscono la prima linea di difesa, ma gli hacker e i tentativi di accesso non autorizzato non si fermano qui: un account con accesso in scrittura a un bucket di storage può eliminare ogni oggetto e ogni data di conservazione in pochi minuti, a meno che qualcosa nel livello di storage stesso non rifiuti tale istruzione.
Chiudi il percorso di accesso: MFA, consapevolezza sul phishing e prove di ripristino
L'immutabilità protegge la copia, ma non protegge la porta da cui è entrato l'attaccante. Quasi ogni incidente inizia con una credenziale rubata e il phishing rimane il metodo di diffusione più comune, solitamente un'email che sembra di routine. Tre controlli sono importanti attorno al livello di storage stesso.
Richiedi l'MFA sulla console di storage e su ogni account in grado di modificare una policy di conservazione. L'autenticazione a più fattori è il controllo di maggior valore in questo ambito, perché l'MFA interrompe la fase di riutilizzo delle credenziali da cui dipendono gli attacchi informatici di questo tipo, e l'MFA sulla console è rapida da implementare. Conserva le credenziali di servizio in un gestore di password, non negli script, e verifica che la rotazione delle password avvenga effettivamente. Fornisci al personale sessioni di formazione regolari sulle email sospette e sui gestori di password, in modo che un dipendente che ne riceve una la segnali invece di aprirla. Il personale che conosce il modello di minaccia è una difesa più economica di qualsiasi prodotto, e le minacce che raggiungono un dipendente informato solitamente si fermano lì, e una segnalazione del dipendente è spesso il primo segnale che un dipendente ti fornisce. Ed esegui una prova di ripristino secondo un programma regolare: l'unico modo per identificare un percorso di ripristino interrotto è esercitarlo prima che lo faccia un incidente. Traccia anche i tentativi di eliminazione sul bucket: un picco di eliminazioni rifiutate è un segnale precoce affidabile che le credenziali sono state compromesse. Traccia anche gli aggiornamenti delle policy, poiché gli aggiornamenti della conservazione sono ciò che un attaccante prova per primo.
Niente di tutto ciò sostituisce la segmentazione della rete o la protezione degli endpoint sul lato produzione, e non è un framework di sicurezza informatica completo. È il livello che impedisce a un singolo account dipendente compromesso di trasformarsi in un'interruzione a livello aziendale.
Le assicurazioni informatiche e gli audit ora richiedono copie immutabili dimostrabili
Gli assicuratori che rinnovano le polizze informatiche ora pongono domande dirette: quelle copie sono immutabili, sono logicamente isolate dalla produzione e potete dimostrare un test di ripristino riuscito? Le aziende che non possono rispondere con prove devono affrontare premi più alti o il rifiuto della polizza. La maggior parte delle aziende lo scopre al momento del rinnovo, non prima. Il primo passo è stabilire e documentare i processi di ripristino dei backup, quindi condurre test di ripristino regolari e un monitoraggio continuo per garantire che funzionino ancora man mano che l'ambiente cambia.
I requisiti di conformità si sono mossi nella stessa direzione, così come i questionari sulla sicurezza dei dati dei clienti. Che provenga dai controlli ISO 27001, da audit specifici del settore o dalla valutazione del rischio di un cliente, "abbiamo i backup" non è più una risposta accettabile. Ogni organizzazione che affronta le moderne minacce di attacco informatico ha sempre più bisogno di dimostrare che una copia di backup non può essere alterata o eliminata per un periodo di conservazione definito, indipendentemente da quali dipendenti o account ci provino.
Quella prova è importante perché un backup immutabile riduce in modo misurabile la possibilità che una credenziale compromessa distrugga sia la produzione che il suo percorso di ripristino. L'asticella si è spostata da "esiste un backup" a "possiamo dimostrare un percorso di ripristino che un attaccante non può distruggere facilmente".
Il principio 3-2-1, e perché la copia immutabile è quella che ti salva
Tre copie, due tipi di supporti, una fuori sede (e una immutabile)
La regola 3-2-1, tre copie su due tipi di supporti con una fuori sede, è stata il pilastro della protezione dei dati per un decennio e la logica regge: se un sistema o una posizione fallisce, rimane un altro percorso.
Il ransomware cambia i calcoli. Se un utente malintenzionato può raggiungere ogni copia tramite le stesse credenziali o lo stesso percorso di rete, "fuori sede" da solo non protegge la tua attività; sposta solo il rischio altrove. Ecco perché molte aziende e team di backup ora trattano la regola come 3-2-1 più una copia immutabile: un backup che sopravvive anche dopo che il resto dell'ambiente è stato compromesso.
Cosa significa realmente "immutabile" a livello di object storage
L'immutabilità non è un'impostazione all'interno del tuo software, è una garanzia applicata dal livello di storage. Con Object Lock abilitato e un periodo di conservazione impostato, il sistema rifiuta qualsiasi eliminazione o sovrascrittura fino alla scadenza di tale periodo, incluse le richieste effettuate con un accesso amministratore valido.
Non importa se la richiesta utilizza una password dipendente valida, un account compromesso o il payload del ransomware stesso: il sistema, per progettazione, non consentirà la modifica. Ciò protegge la copia dalla tecnica specifica su cui fa affidamento questo malware, utilizzando l'accesso rubato per modificare o cancellare tutto ciò che può raggiungere.
Tre modi per eseguire il backup su OVHcloud Object Storage
Per le aziende che desiderano una destinazione di Object Storage (compatibile con S3)* affidabile e sovrana per la propria strategia di conservazione, OVHcloud offre ai team di backup tre percorsi pratici, a seconda che desiderino un'opzione gestita, un flusso di lavoro fai-da-te o l'integrazione con una piattaforma esistente.
Gestito Backup nativi di OVHcloud per Instance, Volume e Databases
Per i carichi di lavoro Public Cloud, i servizi nativi di OVHcloud, Instance Backup, Volume Backup e Databases Backup, scrivono direttamente su Object Storage senza alcuna pipeline S3 da costruire o mantenere. Questo percorso è adatto ai team che desiderano una copertura con un sovraccarico operativo minimo. Se i tuoi carichi di lavoro vengono eseguiti su Kubernetes, la stessa protezione si estende ai volumi persistenti tramite Managed Kubernetes Service. Il piano di controllo, etcd incluso, è gestito da OVHcloud, quindi non è qualcosa di cui il tuo team deve eseguire il backup.
Costruiscilo tu stesso con l'API S3 (awscli, Rclone, Plakar, Restic, Duplicati)
I team con esperienza S3 possono collegare la propria pipeline a un bucket con strumenti standard: awscli o gli SDK AWS per lavori tramite script, Rclone per flussi di lavoro di sincronizzazione o strumenti open source come Plakar, Restic, Duplicati e molti altri per copie deduplicate e crittografate. Plakar è un'opzione open source sovrana senza dipendenza dagli strumenti di alcun singolo fornitore. Poiché l'API S3 è il denominatore comune, esegui i test localmente e passi alla produzione solo con una modifica dell'endpoint.
Porta il tuo strumento esistente: Veeam, HYCU, Cohesity, Veritas NetBackup, CloudCasa e molti altri strumenti.
La maggior parte degli ambienti aziendali esegue già una piattaforma di protezione. OVHcloud Object Storage è certificato Veeam Ready, con HYCU, Cohesity e Veritas NetBackup anch'essi compatibili. Per Kubernetes, Velero e CloudCasa supportano entrambi Object Storage come destinazione tramite l'API S3. L'immutabilità viene configurata nello strumento sul bucket, quindi la protezione rimane valida anche se l'applicazione è compromessa: il livello di storage applica la conservazione in modo indipendente.
La protezione a quattro livelli che si applica a tutti e tre i percorsi
Indipendentemente dal percorso scelto, il modello di sicurezza rimane lo stesso: rendi la copia impossibile da eliminare, mantieni una cronologia pulita, isolala in una seconda posizione e proteggi i dati sensibili e la loro riservatezza. Queste misure di sicurezza lavorano insieme per impedire a un singolo account dipendente compromesso di distruggere l'intero punto di ripristino.
Object Lock (WORM): non eliminabile per il periodo di conservazione
Object Lock trasforma un oggetto archiviato in qualcosa che non può essere eliminato o sovrascritto fino alla scadenza del suo periodo di conservazione, nemmeno da un account con accesso amministratore. Una volta abilitato, Object Lock è irreversibile su quel bucket per progettazione, il che lo rende efficace anche contro un utente interno. Legal Hold aggiunge un blocco a tempo indeterminato su oggetti specifici, utile quando un insieme di file deve essere conservato oltre la finestra standard. Questo controllo rende l'immutabilità reale anziché teorica, e il tuo piano di risposta agli incidenti dovrebbe documentarlo per bucket e periodo di conservazione.
Versioning: mantieni una cronologia pulita di ogni oggetto
Il versioning conserva ogni versione precedente di un file invece di sostituirlo sul posto, così un file corrotto non sovrascrive mai la propria cronologia. Se un file viene sovrascritto o alterato prima che il blocco diventi effettivo, una versione precedente pulita di quel file rimane disponibile, file per file, il che rende possibile il ripristino a livello di file. Il versioning è richiesto affinché Object Lock funzioni correttamente, quindi abilitali entrambi alla creazione del bucket. Protegge anche dall'errore umano e dall'eliminazione accidentale da parte dei dipendenti nella pipeline di backup stessa, non solo dal ransomware.
Replica asincrona S3: una copia isolata in una seconda regione
La replica asincrona S3 mantiene una copia automatizzata del bucket in una regione OVHcloud separata, indipendente dalle credenziali primarie a meno che l'accesso non venga esplicitamente concesso. Ciò fornisce la copia offsite isolata richiesta dal modello 3-2-1, senza alcun trasferimento manuale. In combinazione con Object Lock, un utente malintenzionato avrebbe bisogno delle credenziali in due regioni per raggiungere ogni copia.
Crittografia at-rest: SSE-C e chiavi gestite da OVHcloud SSE-OVHcloud
La crittografia at-rest protegge la riservatezza dei file sensibili se lo strato di archiviazione viene mai raggiunto da un estraneo, e la crittografia in transito li protegge durante il tragitto dalle tue applicazioni e database, indipendentemente dal fatto che la pipeline venga eseguita localmente o da una regione remota. OVHcloud Object Storage supporta SSE-C, dove gestisci la chiave di crittografia, e le chiavi gestite da OVHcloud SSE-OVHcloud, dove OVHcloud gestisce il ciclo di vita della chiave, offrendoti un'opzione sicura in entrambi i casi e chiudendo una vulnerabilità comune nelle pipeline fai-da-te. L'integrazione con il Key Management Service per il controllo indipendente del materiale crittografico è nella roadmap per Object Storage, quindi per ora pianifica basandoti su SSE-C. Questo strato affronta la riservatezza piuttosto che l'immutabilità, ma è comunque importante poiché le violazioni dei dati vengono giudicate in base a ciò che era leggibile: gli oggetti crittografati sono molto meno utili per un utente malintenzionato rispetto a quelli leggibili.
Per ambienti regolamentati superiori a 5 TiB, o quando desideri un secondo parere sulla progettazione di conservazione e replica, un Solutions Architect può esaminare la tua architettura, condividere un progetto di riferimento e aiutarti a proteggere la policy di conservazione richiesta da un revisore e confermare che corrisponda al tuo obiettivo di ripristino.
Ripristina senza un secondo colpo
11 nove di durabilità e un SLA di disponibilità del 99,99% su 3 AZ
Un backup che non puoi ripristinare rapidamente non è molto utile. Tutta l'infrastruttura OVHcloud Object Storage è progettata per undici nove di durabilità (99,999999999%), non solo le regioni a 3 AZ, quindi la perdita di dati dovuta a guasti hardware è straordinariamente improbabile ovunque si trovi la copia. L'SLA di disponibilità del 99,99% si applica alla modalità di distribuzione a 3 AZ. Gli amministratori hanno bisogno che la destinazione di ripristino sia presente quando si verifica un incidente di sicurezza, non solo la prova che i dati fossero al sicuro in precedenza. È anche la dimensione che i clienti valutano più positivamente: Stabilità a 4,51/5 e disponibilità a 4,50/5 nei punteggi NPS.
Nessun costo di egress sul ripristino tra i servizi OVHcloud
Il ripristino di un grande volume di dati dopo un incidente non dovrebbe aggiungere una fattura imprevedibile a un evento già costoso. Non ci sono costi di egress tra i servizi OVHcloud, pertanto il ripristino su un'istanza Public Cloud, un server Bare Metal o qualsiasi altra risorsa OVHcloud non comporta costi di trasferimento separati e il costo di un ripristino rimane prevedibile. Ciò rende il ripristino più facile da pianificare quando il tempo è la risorsa più importante.
Suddividi la conservazione in livelli per controllare i costi: Standard → Active Archive → Cold Archive
Non ogni copia necessita della stessa classe di storage per la stessa durata. Le policy di ciclo di vita spostano gli oggetti da Standard ad Active Archive per la conservazione a medio termine, poi a Cold Archive per la conservazione normativa, mentre Object Lock rimane in vigore su ogni classe.
Active Archive costa circa 4,5 € per TiB e Cold
Archive circa 1,7 € per TiB, entrambi ben al di sotto di Standard per i dati che ripristini raramente. Tale suddivisione in livelli consente alla tua azienda di mantenere una policy di conservazione immutabile pluriennale per la conformità, soddisfacendo la maggior parte dei requisiti del settore, senza pagare tariffe di storage premium per tutto il tempo. Rivedi e aggiorna regolarmente la policy di ciclo di vita man mano che cambiano i requisiti di conservazione o i volumi di dati.
Sovranità e conformità: GDPR, HDS, ISO 27701, nessuna esposizione al CLOUD Act
I dati di backup contengono spesso alcune delle informazioni più preziose e sensibili di un'azienda: dump di database, stato delle applicazioni, proprietà intellettuale, snapshot completi di sistema e talvolta dati personali coperti dal GDPR. Il luogo in cui risiedono tali dati e la giurisdizione legale applicabile sono importanti per la sovranità digitale, la protezione dei dati e per i requisiti specifici del settore come HDS o ISO 27701, anche per gli operatori di infrastrutture critiche e le industrie regolamentate.
OVHcloud Object Storage è ospitato e gestito in data center europei, senza esposizione al CLOUD Act, poiché OVHcloud non è una società soggetta ai requisiti di divulgazione di tale legge. Le certificazioni attuali includono ISO 27001, 27017, 27018 e 27701 per la gestione della privacy, con la qualifica SecNumCloud per Object Storage nella roadmap. Ciò trasforma questo storage in parte della più ampia gestione del rischio, della postura di conformità e delle operazioni aziendali dell'organizzazione, non solo in un'utility operativa.
Inizia: prova da €200, l'hub di backup e un Solutions Architect
Crea un progetto Public Cloud , abilita Object Lock e il versioning su un nuovo bucket, quindi punta il tuo strumento esistente all'endpoint ed esegui un job reale. Un credito di prova di 200 € copre quel test e il ripristino che ne dimostra il funzionamento. Per dati regolamentati o progettazione di replica multi-regione, contatta un Solutions Architect. La pagina Object Storage e l'hub Identity, Security & Operations coprono il resto.
*S3 è un marchio registrato di Amazon Technologies, Inc. I servizi OVHcloud non sono sponsorizzati o approvati da, né affiliati a, Amazon Technologies, Inc.