Pull-only-Backup. Warum die Produktion ihre eigenen Backups nie erreichen darf

Die meisten Backup-Designs sind für den Ausfall gebaut, den sich alle vorstellen: eine tote Platte, eine gelöschte Tabelle, ein misslungenes Upgrade. Der Ausfall, der Unternehmen tatsächlich beendet, ist ein anderer. Jemand gelangt auf einen Produktionsserver, findet die Backup-Zugangsdaten gleich dort liegen und löscht die Backups, bevor er alles andere verschlüsselt. Dieser Artikel erklärt, wie Sie Backups entwerfen, die diesen Tag überstehen, nach dem Muster, nach dem wir bauen: Die Backup-Seite holt ab, die Produktion schiebt nie, und die Schlüssel, die Backups erzeugen, können sie nicht zerstören.

Das Problem mit Push

Das einfachste Backup ist ein Cron-Job auf dem Server, der Daten auf ein Backup-Ziel kopiert. Es ist leicht einzurichten, und es trägt einen strukturellen Fehler. Um zu pushen, braucht der Produktionsserver eine Route zum Backup-Ziel und Zugangsdaten, die dorthin schreiben können. Sehr oft können diese Zugangsdaten auch löschen, überschreiben oder prunen, denn die Aufbewahrung muss irgendwo stattfinden, und der Client ist der naheliegende Ort.

Der Server, den Sie schützen, hält also die Schlüssel zu seinem eigenen Schutz. Wer diesen Server besitzt, besitzt auch seine Backups. Ransomware-Betreiber wissen das, und das Erste, was ein fähiger Einbruch tut, ist nach Backup-Agents, gemounteten Backup-Shares und SSH-Schlüsseln zu suchen, die auf Storage-Hosts zeigen.

Ein Backup-Share auf dem Produktionshost zu mounten ist die schlimmste Form davon. Ein Share, das aus der Produktion beschreibbar ist, ist aus Sicht des Angreifers einfach mehr Platte zum Verschlüsseln.

Drehen Sie den Pfeil um

Die Lösung ist, die Richtung des Vertrauens umzukehren. Das Backup-System initiiert jede Verbindung. Es greift in die Produktion hinein, nimmt, was es braucht, und geht wieder. Die Produktion hat keinen Netzwerkpfad zur Backup-Infrastruktur und hält keine Zugangsdaten dafür.

Setzen Sie das dort durch, wo es von einem kompromittierten Host nicht rückgängig gemacht werden kann: auf der Firewall-Appliance zwischen den beiden Zonen, nicht in der Host-Firewall des Backup-Servers. Das Regelwerk ist kurz:

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

Der Backup-Host selbst braucht ausgehenden Zugriff auf die Produktion auf den Ports, über die er Daten einsammelt, und nichts Eingehendes außer aus dem Management. Gelingt eine Verbindung von einem Produktionshost weiterhin, ist das Design nicht in Kraft, was auch immer das Diagramm sagt.

Das ist dem Geist nach ein Datendioden-Muster, und es lässt sich sauber auf die Kontrollen abbilden, nach denen Prüfer fragen: Trennung der Backup-Infrastruktur, geringste Rechte und Schutz der Grenzen in ISO/IEC 27001, NIS2 und NIST SP 800-53.

Geringste Rechte auf der Produktionsseite

Pull bedeutet weiterhin, dass sich der Backup-Host an der Produktion anmeldet. Diese Anmeldung muss für alles außer dem Erstellen eines Backups nutzlos sein. Mit SSH ist das einfach: Geben Sie dem Schlüssel des Backup-Hosts einen Forced Command und die Option restrict in der authorized_keys des Produktionsservers.

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

Der erste Schlüssel kann das Web-Root nur über rrsync im Read-only-Modus lesen. Der zweite kann nur einen Dump-Wrapper ausführen, den Sie geschrieben haben und der einen konsistenten Datenbank-Dump erstellt (für MySQL oder MariaDB von einem Replikat oder einem Knoten, der keine Writes annimmt, mit --single-transaction oder einem physischen Werkzeug wie Percona XtraBackup) und ihn auf die Standardausgabe streamt. Keiner der beiden Schlüssel gibt eine Shell, Port-Forwarding oder Agent-Forwarding. Würde der Backup-Host selbst kompromittiert, bekäme der Angreifer Lesezugriff auf die Daten eines Kunden, nicht die Kontrolle über die Produktion.

Verwenden Sie getrennte Schlüssel für getrennte Aufgaben und getrennte Schlüssel für getrennte Kunden. Der Auswirkungsradius sollte eine Aufgabe bei einem Kunden sein.

Machen Sie das Repository Append-only

Die zweite Hälfte des Designs ist, was auf der Backup-Seite geschieht. Mit BorgBackup, dem deduplizierenden, komprimierenden und verschlüsselnden Archiver, lässt sich ein Repository im Append-only-Modus ansprechen: Neue Archive können geschrieben werden, aber bestehende Daten können über diesen Zugriffspfad weder gelöscht noch überschrieben werden.

Wenn Borg selbst auf der Quelle laufen muss (zum Beispiel, weil ein Web-Root Millionen kleiner Dateien enthält und Sie die Deduplizierung haben wollen, bevor die Daten das Netzwerk durchqueren), können Sie den Hub trotzdem am Steuer lassen. Der Hub öffnet die SSH-Sitzung zum Produktionshost und stellt einen Reverse Tunnel zurück zu sich selbst bereit, und das Konto am anderen Ende dieses Tunnels ist auf dem Hub eingeschränkt:

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

Der Produktionshost initiiert nie etwas. Er spricht nur durch den Tunnel zurück, den der Hub geöffnet hat, und nur zu seinem eigenen Repository, im Append-only-Modus.

Die Aufbewahrung wird dann zu einer separaten, lokalen Aufgabe auf dem Hub:

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

Führen Sie sie als privilegierte Aufgabe auf dem Backup-Host selbst aus, nie über den Pfad, den die Produktion sehen kann. Ein Angreifer, der den Server eines Kunden verschlüsselt, kann schlimmstenfalls weitere Archive schreiben. Die alten kann er nicht entfernen.

Ein Repository, ein Schlüssel, ein Kunde

Auf einer Backup-Plattform für mehrere Kunden geben Sie jedem Kunden ein eigenes Repository und eine eigene Passphrase, mit Verschlüsselung, die beim Anlegen des Repositorys aktiviert wird:

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

Die Isolation gilt dann auf der kryptografischen Ebene, nicht nur in den Dateirechten: Die Daten eines Kunden lassen sich nicht mit dem Schlüssel eines anderen Kunden lesen, auch nicht von jemandem mit einer Shell auf dem Hub. Die Deduplizierung funktioniert innerhalb eines Kunden weiterhin gut, und zwischen den nahezu identischen Web-Knoten eines Kunden kostet der zweite Knoten fast nichts.

Beweisen Sie es, vertrauen Sie nicht darauf

Ein grüner Backup-Job sagt Ihnen, dass der Job gelaufen ist. Er sagt Ihnen nicht, dass jede Maschine, die zählt, abgedeckt war, oder dass die Daten zurückkommen. Drei Gewohnheiten schließen diese Lücke.

1. Prüfen Sie die Abdeckung gegen den laufenden Bestand. Listen Sie auf, was läuft, listen Sie auf, was ein frisches Backup auf der Platte hat, und vergleichen Sie. Alles, was ohne aktuellen Wiederherstellungspunkt läuft, ist ein Befund.
2. Beobachten Sie die Frische, nicht den Status. Alarmieren Sie auf «Stunden seit dem letzten guten Archiv» pro Kunde, damit ein Job, der stillschweigend nicht mehr läuft, schnell bemerkt wird.
3. Stellen Sie nach Plan wieder her. Extrahieren Sie Dateien, stellen Sie eine Datenbank in eine Wegwerf-Instanz wieder her und prüfen Sie sie, regelmäßig. Borg macht das billig:

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

Auch Restores folgen der Pull-only-Regel. Der Backup-Host, oder ein Ingenieur, liefert die wiederhergestellten Daten an die Produktion. Die Produktion bekommt nie Zugriff auf das Repository, auch nicht «nur für den Restore».

Was Sie auf Ihrer eigenen Plattform prüfen sollten

• Kann irgendein Produktionsserver eine Verbindung zu Ihrem Backup-Speicher öffnen? Probieren Sie es aus.
• Erlauben Zugangsdaten auf einem Produktionsserver das Löschen oder Prunen von Backups?
• Ist auf irgendeinem Produktionshost ein Backup-Share beschreibbar gemountet?
• Sind Backup-Schlüssel auf einen einzigen Befehl beschränkt, oder geben sie eine Shell?
• Liegt jeder Kunde oder jedes System in einem eigenen verschlüsselten Repository mit eigenem Schlüssel?
• Wann haben Sie zuletzt etwas wiederhergestellt, und haben Sie das Ergebnis geprüft?

Wenn Sie eine Antwort unwohl fühlen lässt, beginnen Sie mit der Firewall-Regel. Sie ist die billigste Kontrolle auf dieser Liste und entfernt den gefährlichsten Pfad zuerst.

Wenn Sie ein zweites Paar Augen auf Ihr Backup-Design möchten, helfen unsere Ingenieure gern. Mit einem Ingenieur sprechen

Related

Verwandt: Managed Backup mit Veeam und Borg, Pull-only · Disaster Recovery und standortübergreifende Replikate