Backup pull-only. Perché la produzione non deve mai raggiungere i propri backup

La maggior parte dei design di backup è costruita per il guasto che tutti immaginano: un disco morto, una tabella cancellata, un aggiornamento andato male. Il guasto che chiude davvero le aziende è diverso. Qualcuno entra in un server di produzione, trova le credenziali del backup lì a portata di mano, e cancella i backup prima di cifrare tutto il resto. Questo articolo spiega come progettare backup che sopravvivono a quel giorno, con lo schema che adottiamo: il lato backup tira, la produzione non spinge mai, e le chiavi che creano i backup non possono distruggerli.

Il problema del push

Il backup più semplice è un cron job sul server che copia i dati verso una destinazione di backup. È facile da configurare, e porta con sé un difetto strutturale. Per fare push, il server di produzione ha bisogno di una rotta verso la destinazione di backup e di credenziali che possano scrivervi. Molto spesso quelle credenziali possono anche cancellare, sovrascrivere o fare prune, perché la retention deve avvenire da qualche parte e il client è il posto ovvio.

Quindi il server che state proteggendo tiene le chiavi della propria protezione. Chiunque possieda quel server possiede i suoi backup. Gli operatori di ransomware lo sanno, e la prima cosa che fa un'intrusione competente è cercare agent di backup, share di backup montate e chiavi SSH che puntano a host di storage.

Montare una share di backup sull'host di produzione è la forma peggiore di tutto questo. Una share scrivibile dalla produzione è, dal punto di vista dell'attaccante, solo altro disco da cifrare.

Girate la freccia

La soluzione è invertire la direzione della fiducia. Il sistema di backup avvia ogni connessione. Entra in produzione, prende ciò che gli serve e se ne va. La produzione non ha alcun percorso di rete verso l'infrastruttura di backup e non ne detiene credenziali.

Applicatelo dove non può essere annullato da un host compromesso: sull'appliance firewall tra le due zone, non nel firewall host del server di backup. Il set di regole è corto:

permit ip <management-subnet> host <backup-host>   ! admin access only
deny   ip any host <backup-host>                   ! production and everyone else
permit ip any any                                  ! leave other traffic alone

L'host di backup stesso ha bisogno di accesso in uscita verso la produzione sulle porte che usa per raccogliere i dati, e di nulla in ingresso se non dalla gestione. Se una connessione da un host di produzione riesce ancora, il design non è in vigore, qualunque cosa dica lo schema.

Questo è uno schema a diodo di dati nello spirito, e si mappa in modo pulito sui controlli che gli auditor chiedono: segregazione dell'infrastruttura di backup, privilegio minimo e protezione dei confini in ISO/IEC 27001, NIS2 e NIST SP 800-53.

Privilegio minimo sul lato produzione

Tirare significa comunque che l'host di backup fa login in produzione. Quel login deve essere inutile per qualsiasi cosa che non sia prendere un backup. Con SSH è semplice: date alla chiave dell'host di backup un forced command e l'opzione restrict in authorized_keys sul server di produzione.

command="rrsync -ro /srv/www",restrict ssh-ed25519 AAAA... backup-files
command="/usr/local/bin/backup-dump",restrict ssh-ed25519 AAAA... backup-db

La prima chiave può solo leggere la web root attraverso rrsync in modalità di sola lettura. La seconda può solo eseguire un wrapper di dump che avete scritto voi, che prende un dump consistente del database (per MySQL o MariaDB, da una replica o da un nodo che non riceve scritture, con --single-transaction o con uno strumento fisico come Percona XtraBackup) e lo manda in streaming sullo standard output. Nessuna delle due chiavi dà una shell, port forwarding o agent forwarding. Se l'host di backup stesso venisse compromesso, l'attaccante otterrebbe accesso in lettura ai dati di un cliente, non il controllo della produzione.

Usate chiavi separate per job separati, e chiavi separate per clienti separati. Il raggio d'impatto deve essere un job su un cliente.

Rendete il repository append-only

La seconda metà del design è ciò che accade sul lato backup. Con BorgBackup, l'archiviatore deduplicante, comprimente e cifrante, un repository può essere acceduto in modalità append-only: si possono scrivere nuovi archivi, ma i dati esistenti non possono essere cancellati o riscritti attraverso quel percorso di accesso.

Quando Borg stesso deve girare sulla sorgente (per esempio perché una web root contiene milioni di piccoli file e volete che la deduplicazione avvenga prima che i dati attraversino la rete), potete comunque lasciare il comando all'hub. L'hub apre la sessione SSH verso l'host di produzione e fornisce un tunnel inverso verso se stesso, e l'account all'altro capo di quel tunnel è bloccato sull'hub:

command="borg serve --append-only --restrict-to-repository /srv/backup/tenants/<customer>/borg",restrict ssh-ed25519 AAAA... customer-node

L'host di produzione non avvia mai nulla; risponde soltanto attraverso il tunnel che l'hub ha aperto, e solo verso il proprio repository, in modalità append-only.

La retention diventa allora un job separato e locale sull'hub:

borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6 /srv/backup/tenants/<customer>/borg
borg compact /srv/backup/tenants/<customer>/borg

Eseguitelo come job privilegiato sull'host di backup stesso, mai attraverso il percorso che la produzione può vedere. Un attaccante che cifra il server di un cliente può, al massimo, scrivere altri archivi. Non può rimuovere quelli vecchi.

Un repository, una chiave, un cliente

Su una piattaforma di backup multi-cliente, date a ogni cliente il proprio repository e la propria passphrase, con la cifratura abilitata alla creazione del repository:

borg init --encryption=repokey-blake2 /srv/backup/tenants/<customer>/borg

L'isolamento vale allora a livello crittografico, non solo nei permessi dei file: i dati di un cliente non possono essere letti con la chiave di un altro cliente, nemmeno da chi ha una shell sull'hub. La deduplicazione funziona comunque bene all'interno di un cliente, e tra i nodi web quasi identici di uno stesso cliente il secondo nodo costa quasi nulla.

Dimostratelo, non fidatevi

Un job di backup verde vi dice che il job è girato. Non vi dice che ogni macchina che conta era coperta, né che i dati tornano indietro. Tre abitudini chiudono quel divario.

• Verificate la copertura rispetto all'inventario live. Elencate cosa gira, elencate cosa ha un backup fresco su disco, e confrontate. Qualsiasi cosa che gira senza un punto di ripristino recente è un rilievo.
• Osservate la freschezza, non lo stato. Allarmate su «ore dall'ultimo archivio buono» per cliente, così un job che smette di girare in silenzio viene notato in fretta.
• Ripristinate a calendario. Estraete file, ripristinate un database in un'istanza di prova e controllatelo, regolarmente. Borg lo rende economico:

borg list /srv/backup/tenants/<customer>/borg
borg extract --dry-run /srv/backup/tenants/<customer>/borg::<archive>
borg check --verify-data /srv/backup/tenants/<customer>/borg

Anche i restore seguono la regola pull-only. L'host di backup, o un ingegnere, consegna i dati ripristinati alla produzione. Alla produzione non viene mai dato accesso al repository, nemmeno «solo per il restore».

Cosa verificare sulla vostra piattaforma

• Un qualsiasi server di produzione può aprire una connessione verso il vostro storage di backup? Provateci.
• Ci sono credenziali su un server di produzione che permettono di cancellare o fare prune dei backup?
• C'è una share di backup montata, scrivibile, su qualche host di produzione?
• Le chiavi di backup sono vincolate a un singolo comando, o danno una shell?
• Ogni cliente o sistema sta nel proprio repository cifrato con la propria chiave?
• Quando avete ripristinato qualcosa l'ultima volta, e avete controllato il risultato?

Se qualche risposta vi mette a disagio, partite dalla regola firewall. È il controllo meno costoso di questo elenco e rimuove per primo il percorso più pericoloso.

Se desiderate un secondo paio di occhi sul vostro design di backup, i nostri ingegneri sono lieti di aiutarvi. Parla con un ingegnere

Related

Correlati: Managed backup su Veeam e Borg, pull-only · Disaster recovery e repliche tra siti