Perché abilitare Object Lock potrebbe non proteggere i tuoi vecchi backup
Object lock, il meccanismo alla base dei backup immutabili nello storage di oggetti cloud, è uno dei controlli di sicurezza più fraintesi. Scrivendo sul blog di Backblaze, Kari Wilson, senior product marketing manager di Backblaze, descrive il divario tra l'attivazione di un interruttore object lock e la protezione effettiva dei dati. La discussione trae spunto da problemi reali che emergono nelle conversazioni tecniche con amministratori IT e architetti di sistema, dopo che la documentazione è stata letta ma prima che la configurazione sia completamente considerata affidabile.
Una delle prime confusioni è la differenza tra immutabilità e crittografia. La crittografia protegge le persone dal vedere i tuoi dati. Object lock protegge le persone dall'eliminarli. Un backup crittografato che un attaccante può cancellare non è un'opzione di ripristino. Un backup immutabile che un attaccante può leggere in chiaro è comunque un punto di ripristino utilizzabile. Entrambi contano, ma svolgono funzioni diverse. Trattarli come intercambiabili è il modo in cui le organizzazioni finiscono con lacune in una direzione o nell'altra.
Una preoccupazione correlata è che i dati immutabili saranno difficili da ripristinare. Non lo saranno. I dati immutabili rimangono completamente leggibili e scaricabili per tutto il periodo di immutabilità. Puoi ripristinarli, accedere a singoli file e caricare nuove versioni accanto a quelle protette. L'unica cosa che object lock impedisce è la modifica e l'eliminazione prima della scadenza del periodo di immutabilità. Questo è il punto.
Con Backblaze B2, object lock può essere abilitato alla creazione del bucket o aggiunto a un bucket esistente in seguito. Una volta abilitato, non può essere disattivato, quindi la modifica è permanente in quella direzione. Tuttavia, abilitare object lock su un bucket esistente non protegge retroattivamente i file già presenti al suo interno. Solo i file caricati o copiati nel bucket dopo l'abilitazione di object lock possono essere bloccati. I file che erano lì prima non sono interessati. L'implicazione pratica è chiara: se aggiungi object lock a un bucket con backup esistenti, non dare per scontato che quei file più vecchi siano ora protetti. I nuovi backup scritti dopo la modifica saranno protetti, ma qualsiasi cosa già presente nel bucket richiede l'applicazione manuale di impostazioni di blocco individuali.
C'è anche un presupposto comune che l'immutabilità sia configurata a livello di bucket. Per molte applicazioni di backup, questa è solo metà della storia. Quando si utilizza Veeam o strumenti enterprise simili, l'applicazione di backup gestisce object lock su base per-file. Il bucket deve avere object lock abilitato come capacità, ma l'applicazione controlla quali file vengono bloccati e per quanto tempo. Pensa all'impostazione del bucket come all'apertura della porta; il software di backup decide cosa passa attraverso di essa. Entrambi i lati devono essere configurati: object lock abilitato sul bucket e immutabilità abilitata nell'applicazione di backup. Uno senza l'altro non fa nulla.
Il periodo di conservazione e il periodo di immutabilità sono impostazioni separate che operano indipendentemente. Una politica di conservazione di quattro anni significa che la tua applicazione di backup conserva i dati per quattro anni. Un periodo di immutabilità di 14 giorni significa che i file non possono essere eliminati o modificati per 14 giorni dopo essere stati scritti. Una volta scaduti i 14 giorni, l'object lock viene rilasciato. Il file è ancora lì, governato dalla tua politica di conservazione, ma non è più immutabile. Le due impostazioni non devono corrispondere. Una configurazione tipica prevede una politica di conservazione lunga con una finestra di immutabilità più breve, che copre il periodo in cui è più probabile che ransomware o un attore malintenzionato tenti l'eliminazione.
Quanto dovrebbe durare il periodo di immutabilità? La raccomandazione più comune è da 7 a 14 giorni, con 14 giorni come default ragionevole per la maggior parte degli ambienti. La logica è che se un ransomware o un attacco colpisce il tuo ambiente, lo saprai entro poche ore, forse un paio di giorni. Il periodo di immutabilità non deve coprire mesi di potenziale compromissione. Deve coprire la finestra tra il momento in cui si verifica un attacco e il momento in cui lo rilevi e rispondi. I team di sicurezza che hanno testato i loro flussi di lavoro di risposta agli incidenti spesso scoprono che 7 giorni funzionano bene. Il punto è allineare il periodo con la tua capacità di rilevamento, non massimizzarlo arbitrariamente.
C'è anche un aspetto di costo facile da trascurare. Ogni volta che il software di backup scrive o rinnova un object lock, effettua una chiamata API di classe PUT per aggiornare i metadati di conservazione su quell'oggetto. Su AWS S3, quelle chiamate sono fatturate come richieste PUT standard a $0,005 per 1.000. In ambienti di grandi dimensioni con frequenti job di backup, quelle commissioni di transazione si accumulano. Backblaze B2 non addebita le richieste PUT, quindi le scritture e i rinnovi dei blocchi sono inclusi nello storage. In pratica, questo significa che finestre di immutabilità più brevi non comportano una penalità di costo su B2, e non c'è incentivo a minimizzare i rinnovi dei blocchi per ridurre la bolletta API.
Se configuri un periodo di immutabilità di 7 giorni in Veeam e poi controlli le date di scadenza effettive dei blocchi nel tuo bucket, non sorprenderti di vedere file bloccati fino al giorno 10, 14 o anche 17. Veeam aggiunge giorni extra al periodo di immutabilità oltre a quello che configuri. Questo è un comportamento intenzionale. Veeam protegge dallo scenario in cui un file viene scritto in ritardo in un job di backup e un'operazione di pulizia della conservazione proverebbe altrimenti a eliminarlo prima che il periodo di immutabilità sia completamente trascorso. I giorni extra creano un buffer. L'implicazione pratica è la pianificazione della capacità di storage: se prevedi 7 giorni di storage immutabile, potresti dover considerare più vicino a 14 giorni di dati che non possono essere eliminati in un dato momento. Pianifica per quella varianza.
Le regole del ciclo di vita a livello di bucket che eliminano automaticamente i dati in base all'età o ad altri criteri entreranno in conflitto con il modo in cui le applicazioni di backup gestiscono il proprio ciclo di vita dei dati. Quando lasci che Veeam o un'altra applicazione gestisca la tua catena di backup, quell'applicazione tiene traccia di quali file sono attivi, quali sono scaduti e quando ciascuno dovrebbe essere rimosso. Se imposti una regola del ciclo di vita del bucket che elimina i file dopo 30 giorni, e la tua applicazione di backup sta ancora facendo riferimento a un file che ha 32 giorni, hai rotto la catena. L'approccio giusto è lasciare stare le regole del ciclo di vita del bucket e lasciare che il software di backup gestisca tutta la gestione dei dati. Se la tua applicazione di backup funziona correttamente, non c'è bisogno di regole di eliminazione a livello di bucket. Se qualcosa non funziona correttamente, una regola del ciclo di vita aggraverà il problema.
Non tutti i software di backup supportano object lock. Gli strumenti di sincronizzazione consumer e le applicazioni di backup di file di base generalmente non supportano i backup immutabili. Quando incontrano un oggetto immutabile, l'operazione di scrittura per eliminarlo o modificarlo fallirà, il che interrompe il job di backup. Le applicazioni di backup enterprise come Veeam e Commvault hanno supporto nativo per object lock. Sanno come scrivere flag di immutabilità, gestire i periodi di conservazione e gestire correttamente le chiamate API S3. Se il tuo attuale strumento di backup non è nell'elenco enterprise, controlla la documentazione prima di presumere che l'immutabilità funzionerà. Una catena di backup che fallisce silenziosamente a causa di una gestione incompatibile di object lock non protegge nulla.
Una volta che un oggetto è bloccato con una data di scadenza specifica, quella data può solo essere spostata in avanti. Puoi estendere il periodo di immutabilità, ma non puoi accorciarlo. Questo è un vincolo di progettazione deliberato: l'intero valore dell'immutabilità è che non può essere indebolita retroattivamente. Se un account compromesso o un malintenzionato potesse accorciare o rimuovere il blocco, la protezione sarebbe priva di significato. Lo stesso principio si applica alle configurazioni in modalità governance rispetto alla modalità compliance. La modalità compliance rende impossibile l'eliminazione dei dati anche per gli amministratori dell'account durante il periodo di conservazione. La modalità governance consente a determinati utenti privilegiati di modificare il blocco. Per una seria protezione contro il ransomware, la modalità compliance è generalmente la scelta più forte.
Object lock impedisce a qualsiasi individuo di eliminare oggetti immutabili all'interno del tuo account. Anche un amministratore con pieni permessi non può eliminare un oggetto bloccato prima della scadenza del suo periodo di conservazione. Tuttavia, se qualcuno con accesso a livello di account elimina l'intero account, quella protezione non salva i dati. Questo vale per ogni provider di storage cloud, non solo Backblaze. Non è una lacuna in object lock, è una superficie di attacco completamente diversa. La mitigazione è la sicurezza dell'account: autenticazione a due fattori, privilegi amministrativi limitati e monitoraggio per attività insolite dell'account. Object lock e sicurezza dell'account lavorano insieme. Nessuno dei due rende l'altro ridondante.
Con Backblaze B2, l'immutabilità è inclusa come parte dell'abbonamento standard allo storage. Alcuni provider di storage addebitano separatamente le chiamate API di object lock, comprese le richieste PUT che rinnovano o scrivono i metadati del blocco. Quelle commissioni di transazione possono sommarsi significativamente in ambienti con un elevato numero di file o frequenti rinnovi dei blocchi. Con B2, paghi per lo storage che usi, incluso qualsiasi storage aggiuntivo consumato da dati che non possono essere eliminati durante il loro periodo di immutabilità. La funzionalità in sé non ha sovrapprezzo. Se abiliti il versioning insieme all'immutabilità, tutte le versioni di un file contano per il tuo utilizzo di storage, non solo quella corrente. Se un file è stato modificato 50 volte e stai memorizzando 50 versioni, paghi per tutte e 50 indipendentemente da quante di esse siano attualmente immutabili. La giusta configurazione del versioning dipende dai tuoi obiettivi di ripristino e dal tuo budget. Mantenere ogni versione indefinitamente è raramente necessario, e la maggior parte delle applicazioni di backup ti dà il controllo su quante versioni conservare.
Prima di mettere object lock in produzione, Wilson raccomanda una breve checklist. Verifica che la tua applicazione di backup abbia supporto nativo per object lock e che tu abbia abilitato l'immutabilità nelle impostazioni dell'applicazione, non solo a livello di bucket. Crea il tuo bucket con object lock abilitato anche se non prevedi di usarlo il primo giorno, perché non puoi tornare indietro e abilitarlo in seguito. Salta le regole del ciclo di vita del bucket se il tuo software di backup gestisce il ciclo di vita dei dati. Tieni conto dei giorni extra di Veeam quando pianifichi la capacità di storage, perché la finestra di blocco effettiva sarà più lunga di quella che configuri. Infine, rivedi il tuo periodo di immutabilità nel contesto della tua capacità di rilevamento degli incidenti. Una finestra di immutabilità di 30 giorni non è più sicura di una finestra di 14 giorni se il tuo team di sicurezza può rilevare un incidente entro 48 ore. Object lock è uno degli strumenti più affidabili disponibili per proteggere i dati di backup contro il ransomware, ma la maggior parte degli errori di implementazione sono facili da correggere una volta che sai dove guardare. Per i team che preferirebbero non gestire le impostazioni di object lock su più strumenti di backup, un provider europeo di infrastruttura cloud e dati gestiti come AEU Data offre backup automatizzati, storage crittografato e monitoraggio che possono ridurre queste lacune di configurazione.