Quale livello di backup dovrebbe gestire le chiavi di crittografia: client, repository o destinazione off-site?
Per la maggior parte dei backup di home server, l’applicazione o il client di backup dovrebbe controllare la crittografia necessaria per leggere il backup, mentre la crittografia del provider di archiviazione off-site dovrebbe essere considerata un livello aggiuntivo. In questo modo, la compromissione del cloud o dell’archiviazione remota non espone automaticamente i contenuti del backup, preservando al contempo un formato di backup che può ancora deduplicare, verificare e ripristinare i dati in modo efficiente.
La distinzione importante non è semplicemente «crittografia lato client o lato server». Devi decidere quale dominio di errore è responsabile del segreto di decrittografia. Se l’unica chiave esiste sul server di origine, un’origine guasta o crittografata da un ransomware può compromettere la possibilità di ripristino. Se la destinazione off-site possiede l’unica chiave realmente significativa, l’operatore della destinazione o un account della destinazione compromesso potrebbe rimanere all’interno del perimetro di fiducia. La progettazione migliore separa i dati di backup, le credenziali del repository e le chiavi di ripristino.
Esistono tre punti diversi in cui può risiedere la crittografia
L’espressione «backup crittografato» nasconde diverse architetture. I file di origine possono essere crittografati prima che il software di backup li veda. Il software di backup può crittografare il formato del proprio repository prima di inviare gli oggetti a un’archiviazione locale o remota. Oppure il sistema di archiviazione di destinazione può ricevere i dati e crittografarli quando sono inattivi, utilizzando il proprio livello di gestione delle chiavi.
| Livello | Chi esegue la crittografia? | Chi deve conservare un segreto di ripristino? | Principale vantaggio | Principale svantaggio |
|---|---|---|---|---|
| Pre-crittografia lato client | Applicazione di origine o strumento di crittografia | Proprietario della chiave: client/utente | Forte separazione dal repository di backup e dal provider | Può ridurre la deduplicazione ottimizzata per i backup, la visibilità dei metadati e la praticità dei ripristini granulari |
| Crittografia del repository di backup | Software di backup prima dell’archiviazione | Titolare della chiave/passphrase del repository | Il miglior equilibrio tra riservatezza e funzionalità di backup | La perdita della chiave o della passphrase può rendere il repository completamente illeggibile |
| Crittografia della destinazione off-site | Servizio cloud/NAS/di archiviazione | Chiave della destinazione gestita dal provider, dal KMS o dal cliente | Protezione semplice per i dati inattivi | La destinazione rimane parte del perimetro di fiducia della decrittografia |
La crittografia a livello di repository è solitamente l’impostazione predefinita migliore
Gli strumenti di backup moderni sono progettati per crittografare i dati come parte del formato del repository. La documentazione sulla crittografia di restic considera la crittografia una funzionalità fondamentale del repository e supporta più chiavi di accesso e password. Analogamente, Kopia descrive i propri repository come sistemi che aggiungono crittografia e deduplicazione a backend di storage come filesystem, S3 e archivi di oggetti cloud.
Borg rende il modello di attendibilità particolarmente esplicito. La sua documentazione sulla sicurezza presuppone che l'ambiente client sia affidabile e che il repository possa essere ostile. Borg esegue la crittografia localmente, così un repository remoto non riceve i file in chiaro né la chiave di backup non crittografata.
Questo approccio è interessante per un NAS domestico perché l'applicazione di backup può ancora vedere i file originali durante la creazione del backup. Può eseguire suddivisione in blocchi, deduplicazione, compressione, gestione dei metadati degli snapshot, verifica e ripristini selettivi prima o insieme alla crittografia. La destinazione di storage riceve oggetti del repository crittografati invece di normali file leggibili.
Non confondere la chiave del repository con la credenziale di storage
Una chiave di accesso a un bucket cloud, una chiave privata SFTP, la password di un NAS remoto e una chiave di decrittografia del backup sono segreti diversi, anche quando uno script di automazione ne richiede l'uso congiunto. La credenziale di storage risponde alla domanda «questo client può leggere o scrivere gli oggetti del repository?». La chiave del repository risponde alla domanda «questi oggetti possono essere decrittografati e trasformati in dati di backup?».
Separare questi elementi è importante durante un incidente. Un aggressore che ruba una credenziale di un bucket con autorizzazioni di scrittura non dovrebbe ottenere automaticamente il segreto di decrittografia del repository. Al contrario, il possesso della passphrase del backup non dovrebbe necessariamente concedere l'accesso amministrativo all'account di storage off-site.
La guida di ZimaSpace sulla verifica di ogni chiave necessaria per un ripristino crittografato è un utile complemento, perché considera l'accesso al repository, la crittografia del backup, lo storage di destinazione, i segreti dei container e i segreti a livello applicativo come dipendenze di ripristino separate.
La precrittografia lato client è la scelta migliore per dati circoscritti e altamente sensibili
Crittografare i file prima che l’applicazione di backup li legga può essere sensato quando un determinato set di dati deve rimanere opaco persino agli strumenti di backup o agli amministratori normalmente autorizzati. Tra gli esempi figurano un piccolo archivio legale, un database di password esportato, un insieme di chiavi private o un contenitore crittografato controllato dal cliente.
Il compromesso è che una crittografia eseguita troppo presto può nascondere la struttura che il sistema di backup sfrutterebbe altrimenti. Se ogni file modificato diventa un output crittografato completamente diverso, la compressione e la deduplicazione possono diventare meno efficaci. Anche l’esplorazione granulare dei file può trasformarsi in un ripristino in due passaggi: recuperare prima l’oggetto crittografato, quindi sbloccarlo con un altro strumento.
Per questo motivo, la precrittografia dell’intero set di dati è solitamente un’architettura di backup domestico predefinita più debole rispetto all’uso di uno strumento di backup con crittografia nativa autenticata del repository. Usala quando hai deliberatamente bisogno di un secondo perimetro di fiducia attorno a un sottoinsieme di dati.
La crittografia lato server fuori sede protegge l’archiviazione, non l’intero modello di fiducia del backup
I servizi di archiviazione di oggetti nel cloud crittografano comunemente i dati a riposo. Amazon S3, ad esempio, applica la crittografia lato server per impostazione predefinita e supporta chiavi KMS gestite da AWS o dal cliente. La sua documentazione SSE-KMS descrive come S3 esegua la crittografia sulla destinazione, mentre AWS KMS controlla le chiavi e le autorizzazioni.
Anche Backblaze B2 supporta SSE-B2, gestita dal provider, e SSE-C, gestita dal cliente. La sua documentazione sulla crittografia lato server specifica che SSE protegge i dati dei file a riposo e che la perdita di una chiave SSE-C gestita dal cliente rende i dati irrecuperabili.
La crittografia lato server è preziosa. Aiuta a proteggere i supporti fisici e l’infrastruttura di archiviazione, mentre le policy KMS gestite dal cliente possono creare solidi controlli organizzativi. Tuttavia, se il servizio di destinazione può decrittografare i dati ogni volta che riceve una richiesta di archiviazione autorizzata, la destinazione rientra ancora nel perimetro di riservatezza. Questo è diverso dal caricare un repository Borg, restic o Kopia già crittografato prima di raggiungere il provider.
Usa la crittografia fuori sede come difesa in profondità
La risposta pratica è spesso «entrambi». Lascia che l'applicazione di backup crittografi i contenuti del repository prima del caricamento, quindi lascia abilitata la normale crittografia a riposo della destinazione come ulteriore controllo. I due livelli proteggono da eventi diversi.
| Errore o minaccia | Crittografia del repository | Crittografia lato server della destinazione |
|---|---|---|
| Esposizione del disco/supporto cloud | Protegge i contenuti | Protegge i contenuti |
| Il provider di storage può leggere gli oggetti autorizzati | Può mantenere il provider al di fuori del perimetro di fiducia del testo in chiaro | Di solito non da sola |
| Credenziale del bucket rubata | I dati possono rimanere illeggibili senza la chiave del repository | Le letture autorizzate possono comunque attivare la decrittografia |
| Passphrase/chiave di backup persa | Può rendere irrecuperabile il repository | Non recupera la chiave del repository |
| Chiave di archiviazione gestita dal provider persa | Il livello del repository non può recuperare i dati di destinazione non disponibili | Si applica la politica di ripristino del provider/KMS |
La chiave deve sopravvivere alla macchina che protegge
La regola più importante per la posizione delle chiavi è semplice: non conservare l'unica copia di ripristino del segreto di crittografia sul server di cui stai eseguendo il backup. La guida all'inizializzazione del repository aggiornata di Borg raccomanda esplicitamente di conservare una copia di backup della chiave Borg al di fuori sia del repository sia del sistema che crea i backup.
La stessa logica si applica alle password di restic, alle password dei repository Kopia, alle chiavi age, al materiale di ripristino LUKS, all'amministrazione del KMS cloud e alle chiavi master delle applicazioni. Un repository crittografato alla perfezione è inutile se l'unico segreto di decrittografia scompare insieme all'unità di avvio guasta.
Per una famiglia o un piccolo laboratorio, conserva almeno una copia di ripristino offline o in un sistema di credenziali separato che non dipenda dal funzionamento del NAS. Poi esegui un test di ripristino su una macchina pulita. Una password scritta che non è mai stata usata per aprire il repository dimostra che la documentazione esiste, non che il ripristino sia possibile.
Quale livello dovrebbe gestire la chiave nelle configurazioni comuni dei server domestici?
NAS domestico con backup su storage a oggetti
Usa la crittografia nativa del repository in restic, Borg, Kopia o in uno strumento di backup comparabile prima che i dati lascino il NAS. Conserva la chiave o la passphrase del repository al di fuori del NAS. Lascia abilitata la crittografia del bucket come ulteriore livello di difesa. In questo modo la destinazione cloud non sarà l'unico controllo di riservatezza.
NAS domestico con backup su un server remoto di un amico
Preferisci la crittografia lato client/del repository, con la chiave dei dati in chiaro non archiviata sul server dell’amico. L’host remoto può conservare oggetti opachi del repository e applicare autorizzazioni di scrittura limitate. Questo è particolarmente utile perché il controllo fisico e amministrativo della macchina remota appartiene a un dominio di guasto diverso.
Disco di backup locale conservato nella stessa abitazione
La crittografia del repository protegge comunque la riservatezza se il disco viene perso o rubato. La crittografia dell’intero disco di backup può essere un utile secondo livello di protezione, ma non permettere che la chiave di sblocco del disco diventi l’unico modo per accedere al repository di backup.
Backup cloud gestito con funzionalità di recupero del provider
La crittografia gestita dal provider può essere una scelta ragionevole quando la semplicità e il recupero assistito dal fornitore sono più importanti che mantenere il provider al di fuori del perimetro di attendibilità dei dati in chiaro. Tieni presente che si tratta di una decisione di sicurezza diversa dalla crittografia lato client in stile zero-knowledge.
Non inserire tutti i segreti del backup in un unico file di automazione
Un processo di backup non presidiato necessita di credenziali, ma la praticità può annullare i confini di sicurezza. Le indicazioni di restic per l’automazione avvertono che il modo in cui vengono fornite le password può esporre le credenziali e raccomandano di proteggere con attenzione i file delle password.
Per un server domestico, separare almeno questi ruoli quando possibile:
- Una credenziale con ambito limitato che possa raggiungere la destinazione del backup.
- La password o la chiave di decrittografia del repository.
- Una copia offline della password/chiave di recupero.
- Credenziali amministrative che possono eliminare criteri di conservazione, bucket o account remoti.
Questa separazione è più importante che decidere se un segreto specifico debba essere archiviato in un file, una variabile d’ambiente, un gestore di password, un token hardware o un KMS. L’architettura dovrebbe impedire che una singola credenziale di automazione sottratta possa contemporaneamente leggere i dati in chiaro, eliminare il repository e distruggere l’unica chiave di recupero.
La crittografia non sostituisce l’immutabilità né i test di ripristino
Riservatezza, integrità, resistenza alla cancellazione e recuperabilità sono obiettivi distinti. Un repository crittografato può comunque essere eliminato. Un bucket immutabile può comunque contenere backup la cui chiave di decrittografia è andata persa. Un processo di backup completato con successo può comunque fallire durante il ripristino.
Il confronto di ZimaSpace tra un server di backup remoto e l'archiviazione di oggetti cloud per i backup delle VM arriva alla stessa conclusione operativa: l'etichetta della destinazione conta meno del fatto che sia stato testato un ripristino reale.
Matrice decisionale
| Priorità | Proprietà delle chiavi preferita |
|---|---|
| Impedire all'amministratore del cloud/remoto di accedere ai dati in chiaro | Client o repository di backup crittografato |
| Preservare la deduplicazione e i ripristini consapevoli del backup | Crittografia nativa del repository |
| Minore complessità operativa | Crittografia della destinazione gestita dal provider, accettando una fiducia più ampia |
| Difesa approfondita | Crittografia del repository + crittografia lato server della destinazione |
| Proteggere separatamente un piccolo sottoinsieme estremamente sensibile | Pre-crittografia lato client + backup nel repository normale |
| Ripristino d'emergenza dopo la perdita dell'origine | Qualsiasi modello con una copia indipendente e testata della chiave per il ripristino |
Verdetto finale
Per la maggior parte dei sistemi di backup self-hosted, lascia che sia il client di backup o il formato del repository a gestire il confine di crittografia dei contenuti, e lascia che la destinazione remota crittografi nuovamente i dati a riposo. In questo modo conservi funzioni di backup come la deduplicazione e la verifica, riducendo al contempo quanto devi fidarti del sistema di archiviazione remoto per i dati in chiaro.
Il piano di gestione delle chiavi è completo solo quando il segreto di decrittografia sopravvive alla perdita del server di origine, della destinazione di archiviazione e della normale workstation dell'amministratore. Verifica questa ipotesi da una macchina pulita prima di considerare il backup ripristinabile.
Domande frequenti
La crittografia lato server del cloud è sufficiente per i backup domestici?
Protegge i dati a riposo, ma di solito mantiene il servizio di archiviazione all'interno del confine di attendibilità della decrittografia. Usa anche la crittografia nativa del backup quando non vuoi che il provider o una credenziale di archiviazione sottratta siano sufficienti per accedere ai dati in chiaro.
La chiave del repository deve essere memorizzata all'interno del repository?
Alcuni formati di backup memorizzano nel repository un oggetto chiave crittografato, ma il ripristino dipende comunque da un altro segreto, ad esempio una passphrase complessa. Conserva il materiale di ripristino indipendente al di fuori sia del repository sia del sistema di origine.
La crittografia dei file prima del backup migliora la sicurezza?
Può creare un ulteriore confine di attendibilità per sottoinsiemi sensibili, ma crittografare tutto prima che lo strumento di backup lo rilevi può ridurre la deduplicazione, la compressione, la visibilità dei metadati e la praticità del ripristino.
Qual è il test più importante per la gestione delle chiavi?
Ripristina da una macchina pulita dopo aver simulato l'indisponibilità completa del NAS originale. Se non riesci a individuare ogni credenziale e a decrittografare dati rappresentativi, il piano delle chiavi è incompleto.
Prodotti consigliati
Confronti tra prodotti
Altro da leggere
Home Assistant può sostituire openHAB per il controllo dei dispositivi in tutta la casa?
Home Assistant può sostituire openHAB solo quando ogni dispositivo e automazione essenziale supera un test parallelo di migrazione e rollback.
Mini PC vs server a scheda singola vs NAS per Home Assistant
Scegli una SBC per un dispositivo compatto ed efficiente, un mini PC per una maggiore flessibilità e capacità, oppure un NAS solo quando le...
Come scegliere tra un server dedicato per Home Assistant e un host condiviso per app
Scegli un hosting dedicato per isolare più facilmente i guasti; scegli un hosting condiviso quando l’isolamento, le finestre di manutenzione e il ripristino sono...
