Backup μόνο με pull. Γιατί η παραγωγή δεν πρέπει ποτέ να φτάνει τα δικά της backups

Τα περισσότερα σχέδια backup είναι χτισμένα για την αποτυχία που φαντάζονται όλοι: έναν νεκρό δίσκο, έναν διαγραμμένο πίνακα, μια χαλασμένη αναβάθμιση. Η αποτυχία που πραγματικά τελειώνει εταιρείες είναι διαφορετική. Κάποιος μπαίνει σε έναν server παραγωγής, βρίσκει τα διαπιστευτήρια του backup να κάθονται εκεί ακριβώς, και διαγράφει τα backups πριν κρυπτογραφήσει όλα τα υπόλοιπα. Αυτό το άρθρο εξηγεί πώς σχεδιάζετε backups που επιβιώνουν από εκείνη τη μέρα, με το μοτίβο στο οποίο χτίζουμε: η πλευρά του backup κάνει pull, η παραγωγή δεν κάνει ποτέ push, και τα κλειδιά που δημιουργούν backups δεν μπορούν να τα καταστρέψουν.

Το πρόβλημα με το push

Το απλούστερο backup είναι ένα cron job στον server που αντιγράφει δεδομένα σε έναν προορισμό backup. Στήνεται εύκολα, και κουβαλά ένα δομικό ελάττωμα. Για να κάνει push, ο server παραγωγής χρειάζεται διαδρομή προς τον προορισμό backup και διαπιστευτήρια που μπορούν να γράψουν σε αυτόν. Πολύ συχνά αυτά τα διαπιστευτήρια μπορούν επίσης να διαγράψουν, να αντικαταστήσουν ή να κάνουν prune, γιατί η διατήρηση πρέπει να γίνεται κάπου και ο client είναι η προφανής θέση.

Άρα ο server που προστατεύετε κρατά τα κλειδιά της δικής του προστασίας. Όποιος κατέχει αυτόν τον server κατέχει και τα backups του. Οι χειριστές ransomware το ξέρουν, και το πρώτο πράγμα που κάνει μια ικανή εισβολή είναι να ψάξει για backup agents, προσαρτημένα backup shares και κλειδιά SSH που δείχνουν σε hosts αποθήκευσης.

Η προσάρτηση ενός backup share στον host παραγωγής είναι η χειρότερη μορφή αυτού. Ένα share που είναι εγγράψιμο από την παραγωγή είναι, από τη σκοπιά του επιτιθέμενου, απλώς περισσότερος δίσκος για κρυπτογράφηση.

Γυρίστε το βέλος ανάποδα

Η λύση είναι να αντιστρέψετε την κατεύθυνση της εμπιστοσύνης. Το σύστημα backup ξεκινά κάθε σύνδεση. Φτάνει μέσα στην παραγωγή, παίρνει ό,τι χρειάζεται και φεύγει. Η παραγωγή δεν έχει διαδρομή δικτύου προς την υποδομή backup και δεν κρατά διαπιστευτήρια γι' αυτήν.

Επιβάλετέ το εκεί όπου δεν μπορεί να αναιρεθεί από έναν παραβιασμένο host: στη συσκευή firewall ανάμεσα στις δύο ζώνες, όχι στο host firewall του backup server. Το σύνολο κανόνων είναι σύντομο:

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

Ο ίδιος ο backup host χρειάζεται εξερχόμενη πρόσβαση προς την παραγωγή στις θύρες που χρησιμοποιεί για να συλλέγει δεδομένα, και τίποτα εισερχόμενο εκτός από τη διαχείριση. Αν μια σύνδεση από host παραγωγής εξακολουθεί να πετυχαίνει, ο σχεδιασμός δεν είναι σε ισχύ, ό,τι κι αν λέει το διάγραμμα.

Αυτό είναι ένα μοτίβο data-diode στο πνεύμα του, και αντιστοιχεί καθαρά στους ελέγχους για τους οποίους ρωτούν οι ελεγκτές: διαχωρισμός της υποδομής backup, ελάχιστο προνόμιο και προστασία ορίων σε ISO/IEC 27001, NIS2 και NIST SP 800-53.

Ελάχιστο προνόμιο από την πλευρά της παραγωγής

Το pull εξακολουθεί να σημαίνει ότι ο backup host συνδέεται στην παραγωγή. Αυτή η σύνδεση πρέπει να είναι άχρηστη για οτιδήποτε εκτός από τη λήψη backup. Με SSH αυτό είναι απλό: δώστε στο κλειδί του backup host μια forced command και την επιλογή restrict στο authorized_keys του server παραγωγής.

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

Το πρώτο κλειδί μπορεί μόνο να διαβάσει το web root μέσω rrsync σε read-only mode. Το δεύτερο μπορεί μόνο να τρέξει έναν dump wrapper που γράψατε εσείς, ο οποίος παίρνει ένα συνεπές dump βάσης δεδομένων (για MySQL ή MariaDB, από replica ή κόμβο που δεν δέχεται writes, με --single-transaction ή με φυσικό εργαλείο όπως το Percona XtraBackup) και το στέλνει στο standard output. Κανένα από τα δύο κλειδιά δεν δίνει shell, port forwarding ή agent forwarding. Αν παραβιαζόταν ο ίδιος ο backup host, ο επιτιθέμενος θα αποκτούσε πρόσβαση ανάγνωσης στα δεδομένα ενός πελάτη, όχι έλεγχο της παραγωγής.

Χρησιμοποιήστε ξεχωριστά κλειδιά για ξεχωριστές εργασίες, και ξεχωριστά κλειδιά για ξεχωριστούς πελάτες. Η ακτίνα επίπτωσης πρέπει να είναι μία εργασία σε έναν πελάτη.

Κάντε το repository append-only

Το δεύτερο μισό του σχεδιασμού είναι τι συμβαίνει στην πλευρά του backup. Με το BorgBackup, τον archiver με deduplication, συμπίεση και κρυπτογράφηση, ένα repository μπορεί να προσπελαστεί σε append-only mode: νέα archives μπορούν να γραφτούν, αλλά τα υπάρχοντα δεδομένα δεν μπορούν να διαγραφούν ή να ξαναγραφτούν μέσω αυτής της διαδρομής πρόσβασης.

Όταν το ίδιο το Borg πρέπει να τρέξει στην πηγή (για παράδειγμα, επειδή ένα web root έχει εκατομμύρια μικρά αρχεία και θέλετε το deduplication να γίνει πριν τα δεδομένα διασχίσουν το δίκτυο), μπορείτε και πάλι να κρατήσετε το hub στο τιμόνι. Το hub ανοίγει το SSH session προς τον host παραγωγής και παρέχει ένα reverse tunnel πίσω στον εαυτό του, και ο λογαριασμός στην άλλη άκρη αυτού του tunnel είναι κλειδωμένος στο hub:

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

Ο host παραγωγής δεν ξεκινά ποτέ τίποτα. Μιλά μόνο πίσω μέσω του tunnel που άνοιξε το hub, και μόνο προς το δικό του repository, σε append-only mode.

Η διατήρηση γίνεται τότε ξεχωριστή, τοπική εργασία στο hub:

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

Τρέξτε την ως προνομιούχα εργασία στον ίδιο τον backup host, ποτέ μέσω της διαδρομής που βλέπει η παραγωγή. Ένας επιτιθέμενος που κρυπτογραφεί τον server ενός πελάτη μπορεί, στη χειρότερη περίπτωση, να γράψει περισσότερα archives. Δεν μπορεί να αφαιρέσει τα παλιά.

Ένα repository, ένα κλειδί, ένας πελάτης

Σε μια πλατφόρμα backup πολλών πελατών, δώστε σε κάθε πελάτη δικό του repository και δική του passphrase, με κρυπτογράφηση ενεργοποιημένη κατά τη δημιουργία του repository:

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

Η απομόνωση ισχύει τότε στο κρυπτογραφικό επίπεδο, όχι μόνο στα δικαιώματα αρχείων: τα δεδομένα ενός πελάτη δεν μπορούν να διαβαστούν με το κλειδί άλλου πελάτη, ακόμα και από κάποιον με shell στο hub. Το deduplication εξακολουθεί να δουλεύει καλά μέσα σε έναν πελάτη, και ανάμεσα στους σχεδόν πανομοιότυπους web κόμβους ενός πελάτη ο δεύτερος κόμβος δεν κοστίζει σχεδόν τίποτα.

Αποδείξτε το, μην το εμπιστεύεστε

Μια πράσινη εργασία backup σάς λέει ότι η εργασία έτρεξε. Δεν σας λέει ότι καλύφθηκε κάθε μηχάνημα που μετράει, ούτε ότι τα δεδομένα επιστρέφουν. Τρεις συνήθειες κλείνουν αυτό το κενό.

1. Ελέγξτε την κάλυψη έναντι της ζωντανής απογραφής. Καταγράψτε τι τρέχει, καταγράψτε τι έχει φρέσκο backup στον δίσκο, και συγκρίνετε. Οτιδήποτε τρέχει χωρίς πρόσφατο σημείο επαναφοράς είναι εύρημα.
2. Παρακολουθήστε τη φρεσκάδα, όχι την κατάσταση. Βάλτε συναγερμό στις «ώρες από το τελευταίο καλό archive» ανά πελάτη, ώστε μια εργασία που σταματά σιωπηλά να τρέχει να γίνεται αντιληπτή γρήγορα.
3. Κάντε restore σε πρόγραμμα. Εξαγάγετε αρχεία, κάντε restore μια βάση δεδομένων σε ένα πρόχειρο instance και ελέγξτε την, τακτικά. Το Borg το κάνει φθηνό:

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

Τα restores ακολουθούν επίσης τον κανόνα του pull. Ο backup host, ή ένας μηχανικός, παραδίδει τα επαναφερμένα δεδομένα στην παραγωγή. Στην παραγωγή δεν δίνεται ποτέ πρόσβαση στο repository, ούτε «μόνο για το restore».

Τι να ελέγξετε στη δική σας πλατφόρμα

• Μπορεί κάποιος server παραγωγής να ανοίξει σύνδεση προς τον αποθηκευτικό χώρο των backups σας; Δοκιμάστε το.
• Επιτρέπουν διαπιστευτήρια σε server παραγωγής τη διαγραφή ή το prune των backups;
• Υπάρχει backup share προσαρτημένο, εγγράψιμο, σε κάποιον host παραγωγής;
• Είναι τα κλειδιά backup περιορισμένα σε μία εντολή, ή δίνουν shell;
• Είναι κάθε πελάτης ή σύστημα σε δικό του κρυπτογραφημένο repository με δικό του κλειδί;
• Πότε κάνατε τελευταία φορά restore κάτι, και ελέγξατε το αποτέλεσμα;

Αν κάποια απάντηση σας κάνει να νιώθετε άβολα, ξεκινήστε από τον κανόνα του firewall. Είναι ο φθηνότερος έλεγχος σε αυτή τη λίστα και αφαιρεί πρώτη την πιο επικίνδυνη διαδρομή.

Αν θέλετε ένα δεύτερο ζευγάρι μάτια στον σχεδιασμό των backups σας, οι μηχανικοί μας θα χαρούν να βοηθήσουν. Μιλήστε με έναν μηχανικό

Related

Σχετικά: Managed backup σε Veeam και Borg, μόνο με pull · Disaster recovery και replicas μεταξύ sites