Unveränderliche Proxmox-Backups mit Wasabi und S3-Objektsperre mit Zmanda Pro

Moderne Ransomware-Familien zielen gezielt auf Backup-Infrastrukturen ab und identifizieren und löschen oder verschlüsseln Backup-Speicher, bevor sie die eigentliche Schadsoftware ausführen. Befinden sich Ihre Proxmox-Backups in einem lokalen PBS -Datenspeicher, auf den mit denselben Anmeldeinformationen wie in Ihrer Produktionsumgebung zugegriffen wird, sind sie nicht vor einem Angriff geschützt. Ein Angreifer mit Administratorrechten kann sie löschen. Ein Angreifer, der Ihren Netzwerkspeicher verschlüsselt, kann darauf zugreifen. Unveränderlichkeit ist die Gegenmaßnahme: Backup-Objekte, die während eines definierten Aufbewahrungszeitraums von niemandem, auch nicht von Ihrem eigenen Administratorkonto, gelöscht, geändert oder verschlüsselt werden können.

S3 Object Lock im Compliance-Modus ist die stärkste verfügbare Implementierung dieses Prinzips. In Kombination mit clientseitiger Deduplizierung, die den Speicherverbrauch um bis zu 90 % reduziert, der Wasabi-Integration von Proxmox Backup Server dank der nativen Object-Lock-Unterstützung von Zmanda Pro und Zero-Egress-Preisgestaltung können Sie in weniger als einer Stunde wirklich ransomware-sichere Offsite-Kopien Ihrer Proxmox-Backups konfigurieren. Dieser Beitrag zeigt Ihnen genau, wie.

Dieser Beitrag behandelt: die Funktionsweise von S3 Object Lock und warum der Compliance-Modus wichtig ist, die schrittweise Konfiguration eines Wasabi-Buckets für unveränderliche Proxmox-Backups, die Konfiguration von Zmanda Pro zur Ansprache eines Object-Lock-fähigen Buckets, die Gestaltung von Aufbewahrungsrichtlinien für Proxmox-Umgebungen und die vollständige 3-2-1-1-0-Architektur, die dadurch ermöglicht wird.

Starten Sie Ihre kostenlose Testversion

S3-Objektsperre: Governance-Modus vs. Compliance-Modus

Die Objektsperre ist eine S3-kompatible Funktion, die verhindert, dass gespeicherte Objekte für einen festgelegten Aufbewahrungszeitraum gelöscht oder überschrieben werden. Es ist entscheidend, den Unterschied zwischen den beiden Modi zu verstehen, bevor man sie konfiguriert. Die Wahl des falschen Modus macht Ihre Backups entweder anfällig für administrative Eingriffe (Governance) oder sperrt Ihre Bucket-Konfiguration dauerhaft und schwer rückgängig zu machen (Compliance).

Governance-Modus: Objekte sind für Standardbenutzer vor dem Löschen geschützt. Benutzer mit der IAM-Berechtigung „s3:BypassGovernanceRetention“ können diese Sperre jedoch aufheben und Objekte löschen. Dieser Modus eignet sich zum Schutz vor versehentlichem Löschen und für die meisten Ransomware-Angriffe , bei denen der Angreifer nicht über die erforderliche Berechtigung zum Umgehen der Sperre verfügt. Die Sperre kann aufgehoben werden, wenn Objekte vor Ablauf des Aufbewahrungszeitraums gelöscht werden müssen.

Compliance-Modus: Objekte können bis zum Ablauf der Aufbewahrungsfrist von niemandem, auch nicht vom Root-Konto, gelöscht oder geändert werden. Es gibt keinen Mechanismus, um dies zu umgehen. Weder IAM-Berechtigungen noch Kontorechte oder Support-Tickets beim Cloud-Anbieter können den Compliance-Modus vor Ablauf der Frist freischalten. Selbst wenn ein Angreifer die Anmeldeinformationen Ihres AWS- oder Wasabi-Root-Kontos kompromittiert, kann er im Compliance-Modus keine Objekte löschen. Dieser Modus bietet echten Schutz vor Ransomware.

Möchten Sie Wasabi, AWS S3 und Backblaze B2 als Proxmox-Backup-Ziele vergleichen?
Weitere Informationen im Leitfaden zur Cloud-Sicherung für Proxmox.

Konfigurieren eines Wasabi-Buckets für die Objektsperre

Bevor Sie die Wasabi-Objektsperre für Proxmox Backup Server konfigurieren, beachten Sie, dass diese bei der Bucket-Erstellung aktiviert werden muss; sie kann nicht zu einem bestehenden Bucket hinzugefügt werden. Dies ist eine permanente Einstellung auf Bucket-Ebene. Planen Sie Ihre Bucket-Struktur daher sorgfältig, bevor Sie den Bucket erstellen, da zum Aufheben der Objektsperre ein neuer Bucket erstellt und die Daten migriert werden müssen.

Schritt 1: Erstellen Sie den Bucket mit aktivierter Objektsperre.

Navigieren Sie in der Wasabi-Konsole zu Buckets → Bucket erstellen. Aktivieren Sie unter „Versionierung und Objektsperre“ sowohl die Bucket-Versionierung als auch die Objektsperre. Die Objektsperre erfordert die Versionierung; beide Einstellungen müssen aktiviert sein. Benennen Sie den Bucket entsprechend Ihrer Aufbewahrungsrichtlinie (z. B. proxmox-backup-immutable-90dDer Name sollte zukünftigen Administratoren die Absicht der Datenaufbewahrung verdeutlichen.

Schritt 2: Standardaufbewahrungsrichtlinie festlegen

Nachdem Sie den Bucket erstellt haben, navigieren Sie zu den Bucket-Eigenschaften und konfigurieren Sie die Standardaufbewahrungsrichtlinie. Stellen Sie den Modus auf „Konformität“ und die Aufbewahrungsdauer entsprechend Ihren Richtlinienanforderungen ein. Übliche Aufbewahrungsfenster für Proxmox-Backups:

• 30 Tage: Minimale Aufbewahrungsdauer, die die meisten Anforderungen an die operative Wiederherstellung erfüllt. Deckt die meisten Inkubationszeiten von Ransomware ab, in denen eine Infektion unentdeckt bleibt, bevor sie auslöst.
• 90 Tage: Geeignet für Umgebungen mit Compliance-Anforderungen oder in denen nach einem Vorfall forensische Untersuchungen den Zugriff auf historische Daten erfordern.
• 1-Jahr: Üblich in regulierten Branchen (Gesundheitswesen, Finanzwesen), wo Aufbewahrungsrichtlinien die langfristige Verfügbarkeit von Datensicherungen vorschreiben.

Die Standardaufbewahrungsrichtlinie gilt für alle neu in den Bucket geschriebenen Objekte. Für einzelne Objekte können beim Schreiben längere Aufbewahrungsfristen festgelegt werden. Die Standardrichtlinie deckt jedoch den Normalfall ab: Von Zmanda Pro erstellte Sicherungsobjekte übernehmen automatisch die Aufbewahrungsrichtlinie des Bucket-basierten Compliance-Modus.

Schritt 3: IAM-Anmeldeinformationen für den Schreibzugriff konfigurieren

Für maximale Sicherheit erstellen Sie einen dedizierten Wasabi-IAM-Benutzer für Zmanda Pro mit Schreibrechten für den unveränderlichen Bucket. Dieser Benutzer kann Objekte erstellen, aber nicht löschen oder ändern (Object Lock schützt bestehende Objekte unabhängig von den IAM-Berechtigungen). Selbst wenn diese Zugangsdaten kompromittiert werden, kann der Angreifer keine vorhandenen Sicherungsobjekte löschen; er kann lediglich neue Daten hinzufügen.

Empfohlene IAM-Richtlinie für das Zmanda Pro-Dienstkonto:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": [
        "arn:aws:s3:::proxmox-backup-immutable-90d",
        "arn:aws:s3:::proxmox-backup-immutable-90d/*"
      ]
    }
  ]
}

Auffällig abwesend: s3:DeleteObject, s3:DeleteBucket und s3:BypassGovernanceRetentionDiese Berechtigungen werden absichtlich ausgeschlossen; das für Sicherungsschreibvorgänge verwendete Dienstkonto verfügt über keinerlei Löschberechtigung.

Benötigen Sie Hilfe bei der Konfiguration einer unveränderlichen Backup-Architektur für Ihre Proxmox-Umgebung? Vereinbaren Sie eine kostenlose 30-minütige Beratung mit einem Backup-Spezialisten.

Zmanda Pro so konfigurieren, dass es auf den Objektsperr-Bucket abzielt

Zmanda Pro bietet native Unterstützung für S3 Object Lock auf Wasabi und AWS S3 und deckt dabei sowohl Governance- als auch Compliance-Modi ab. Die Konfiguration erfolgt unkompliziert über die Zmanda Pro-Konsole.

Schritt 1: Das Wasabi-Speicherziel hinzufügen

Die Einrichtung von Proxmox Backup Server Wasabi als Speicherziel beginnt in der Zmanda Pro-Konsole unter Speicher → Speicherziel hinzufügen. Wählen Sie „S3-kompatibler Speicher“ und geben Sie die Wasabi-Endpunktdetails ein:

• Endpunkt: s3.wasabisys.com (oder regionsspezifischer Endpunkt, z. B. s3.us-east-2.wasabisys.com)
• Region: Passen Sie die Region Ihres Buckets an.
• Zugriffsschlüssel-ID und geheimer Zugriffsschlüssel: die IAM-Anmeldeinformationen des oben erstellten schreibgeschützten Dienstkontos.
• Eimer: proxmox-backup-immutable-90d

Schritt 2: Aktivieren Sie die Objektsperre in den Einstellungen des Speicherziels.

Aktivieren Sie in den Einstellungen für das Speicherziel die Option „Objektsperre“ und stellen Sie den Aufbewahrungsmodus auf „Compliance“ ein. Die hier konfigurierte Aufbewahrungsdauer sollte der standardmäßigen Aufbewahrungsdauer auf Bucket-Ebene entsprechen oder kürzer sein. Zmanda Pro speichert Metadaten zur Aufbewahrung auf Objektebene für jedes in den Bucket geschriebene Sicherungsobjekt.

Schritt 3: Konfigurieren Sie eine Sicherungsrichtlinie, die auf dieses Ziel abzielt

Erstellen oder aktualisieren Sie eine Backup-Richtlinie für Ihre Proxmox-VMs und LXC-Container, die auf das Object-Lock-fähige Wasabi-Ziel abzielt. Sie können eine mehrstufige Richtlinie konfigurieren, bei der das primäre Backup-Ziel der lokale Speicher (für eine schnelle lokale Wiederherstellung) und der Object-Lock-Bucket ein sekundäres Ziel für die unveränderliche externe Kopie ist. Diese Architektur erfüllt die „1“ in der 3-2-1-1-0-Regel: eine unveränderliche Kopie, die separat von Ihrer primären Backup-Infrastruktur gespeichert wird.

Die 3-2-1-1-0-Architektur für Proxmox-Umgebungen

Die 3-2-1-1-0-Backup-Regel ist der aktuelle Goldstandard für den Datenschutz in Unternehmen:

• 3 Gesamtzahl der Datenkopien
• 2 verschiedene Speichermedientypen
• 1 Offsite-Kopie
• 1 unveränderliche (abgeschottete oder Objekt-gesperrte) Kopie
• 0 Fehler wurden beim letzten Wiederherstellungstest verifiziert.

Für eine Proxmox-Umgebung mit Zmanda Pro lässt sich diese Architektur problemlos abbilden:

• Kopie 1: Lokales Zmanda Pro-Backup auf NAS (schnelle lokale Wiederherstellung, primärer Speicher)
• Kopie 2: Zmanda Pro-Backup in einen Standard-Wasabi-Bucket (extern, veränderbar, geringere Aufbewahrungskosten)
• Kopie 3 (unveränderlich): Zmanda Pro-Backup im Object Lock Compliance-Modus-Bucket (extern, unveränderlich, kann von niemandem gelöscht werden)
• Medientypen: Lokales NAS (Festplatte) + Cloud-Objektspeicher = 2 Medientypen
• 0 Fehler: Zmanda Pro überprüft die Integrität der Datenblöcke beim Schreiben; die Wiederherstellungsvalidierung bestätigt, dass die Sicherungskette wiederherstellbar ist.

Um diese Architektur ohne Zmanda Pro nativ zu realisieren, sind folgende Schritte erforderlich: Proxmox Backup Server Wasabi-Synchronisierung via rclone, ein zweiter rclone-Job für den Object-Lock-Bucket und die unabhängige Überwachung aller drei Pfade. Keine der drei PBS-basierten Kopien verfügt über eine Integritätsprüfung zum Schreibzeitpunkt; rclone bestätigt zwar die Dateiübertragung, überprüft aber nicht die Integrität der PBS-Chunks am Zielort. Mit Zmanda Pro lässt sich dieselbe Architektur mit drei Kopien über eine einzige Konsole verwalten, mit verifizierten Schreibvorgängen an jedem Zielort und einer zentralen Überwachungsoberfläche für alle drei Pfade.

Zmanda Cloud Storage erreicht die vollständige 3-2-1-1-0-Konformität in nur zwei Konfigurationsschritten dank integrierter Unveränderlichkeitsunterstützung. Für Teams, die Wasabi oder AWS S3 direkt nutzen, bietet die oben beschriebene Object-Lock-Konfiguration die gleiche Konformität mit dem jeweiligen Anbieter. Weitere Informationen zur unveränderlichen Backup-Architektur von Zmanda Pro und den Ransomware-Schutzfunktionen von Object Lock finden Sie hier.

Sie möchten das vollständige Framework für die Aufbewahrung, Planung und Überprüfung von Proxmox-Backups?
Lesen Sie mehr Proxmox-Backup und -Wiederherstellung – Bewährte Verfahren.

Auswirkungen auf die Speicherkosten: Deduplizierung + Objektsperre

Ein Problem bei der Objektsperre sind die Speicherkosten, die durch die Aufbewahrung entstehen. Objekte unter Objektsperre können vor Ablauf des Aufbewahrungszeitraums nicht gelöscht werden, dies gilt auch für Sicherungsversionen, die normalerweise gelöscht würden. Bei einer 90-tägigen Aufbewahrung im Compliance-Modus in einer Umgebung mit 50 VMs und täglichen Backups werden 90 inkrementelle tägliche Sicherungssätze im unveränderlichen Speicherbereich angesammelt, die jeweils bis zum Ablauf ihres individuellen Aufbewahrungszeitraums geschützt sind.

Die clientseitige Deduplizierung von Zmanda Pro verändert diese Kostenberechnung grundlegend. Da die Deduplizierung vor der Übertragung erfolgt, werden nur eindeutige Datenblöcke in den Object Lock Bucket geschrieben. Zwei VMs, die ein gemeinsames Betriebssystem-Image verwenden, tragen nur eine Kopie der gemeinsamen Datenblöcke zum Bucket bei, nicht zwei. Tägliche inkrementelle Backups einer VM mit einer Änderungsrate von 5 % übertragen täglich etwa 5 % der gesamten VM-Daten, nicht eine vollständige neue Kopie. In validierten Produktionsumgebungen erzielt Zmanda Pro eine Speichereinsparung von 89 % (10:1). Das bedeutet, dass der Object Lock Bucket einer 10-TB-Proxmox-Umgebung im Laufe der Zeit nur um etwa 1 TB eindeutiger Daten wächst, nicht um 10 TB.

Bei Wasabi (6.99 $/TB/Monat ohne ausgehende Daten) sind die Speicherkosten für Proxmox Backup Server Wasabi mit clientseitiger Deduplizierung deutlich besser zu handhaben als ohne. Die Speicheroptimierung durch Deduplizierung , die Zmanda Pro anwendet, macht Langzeit-Objektsperrrichtlinien auch für KMU und mittelständische Unternehmen wirtschaftlich rentabel, die die Speicherkosten pro GB nicht in großem Umfang tragen können. Einen detaillierten Kostenvergleich für Cloud-Speicher finden Sie auf der Zmanda Cloud Storage-Seite.

Enterprise-Backup für 5.99 $/Workload/Monat. Keine versteckten Kosten pro GB.

Kostenlos Ausprobieren

Operationalisierung von unveränderlichen Backups: Wiederherstellungstests und Überwachung

Unveränderliche Backups, die noch nie in einem Wiederherstellungstest verifiziert wurden, erfüllen die Anforderung „0 verifizierte Fehler“ nur dem Namen nach. Die „0“ in 3-2-1-1-0 wird durch tatsächliche Wiederherstellungstests erreicht und nicht aus den Erfolgsprotokollen der Backup-Aufträge abgeleitet.

In Proxmox-Umgebungen erfolgt die Wiederherstellung von Testdaten aus einem durch eine Objektsperre geschützten Wasabi-Bucket über Zmanda Pro genauso wie bei anderen Wiederherstellungszielen: Wählen Sie den Wiederherstellungspunkt, das Ziel (ursprünglicher Proxmox-Host, alternativer Host oder plattformübergreifend) und führen Sie die Wiederherstellung aus. Dank der Chunk-basierten Indizierung von Zmanda Pro ist die Wiederherstellungsgeschwindigkeit unabhängig vom Alter des Wiederherstellungspunkts konstant – die ältesten und neuesten Backups werden mit identischer Geschwindigkeit wiederhergestellt, da das System nur die benötigten Chunks zusammensetzt, anstatt eine Backup-Kette erneut abzuspielen.

Die Überwachung der unveränderlichen Kopie sollte drei Dinge sicherstellen: dass die Backup-Aufträge im Object-Lock-Ziel erfolgreich abgeschlossen werden (nicht nur, dass der Object-Lock-Bucket existiert), dass die Aufbewahrungsmetadaten geschriebener Objekte der konfigurierten Richtlinie entsprechen und dass eine Testwiederherstellung aus der unveränderlichen Kopie planmäßig erfolgreich durchgeführt wird. Viele Teams testen regelmäßig lokale Wiederherstellungen, vernachlässigen aber die Prüfung der Cloud-Kopie – genau die Kopie, die Sie benötigen, falls Ihre lokale Infrastruktur kompromittiert wird. Planen Sie mindestens vierteljährlich Wiederherstellungstests vom Object-Lock-Ziel und dokumentieren Sie die Ergebnisse als Nachweis für die Einhaltung gesetzlicher Bestimmungen, falls diese einen Nachweis der Wiederherstellbarkeit von Backups erfordern.