Veeam Backup & Replication bietet zwei etablierte Wege, Backup-Daten unveränderlich zu machen: ein Hardened Linux Repository, bei dem das Betriebssystem die Backup-Dateien schützt, und ein S3-kompatibles Objektspeicher-Repository mit Object Lock, bei dem die Speicherplattform das Löschen bis zum Ablauf einer Aufbewahrungsfrist verweigert. Beide hindern einen Ransomware-Akteur oder einen unredlichen Administrator daran, Wiederherstellungspunkte zu vernichten. Sie unterscheiden sich darin, wer den Schutz durchsetzt, wie viel Infrastruktur das Backup-Team betreibt und wie sich jedes Modell verhält, wenn Datenvolumen und Aufbewahrungsfenster wachsen.
Die Wahl ist wichtiger als früher. Angreifer nehmen die Backup-Infrastruktur früh ins Visier, und Unveränderlichkeit hat sich von einem optionalen Härtungsschritt zu einer Grunderwartung in Sicherheitsprüfungen und Fragebögen von Cyber-Versicherern entwickelt. Dieser Artikel vergleicht die beiden Modelle danach, wo die Unveränderlichkeit durchgesetzt wird, nach Betriebsaufwand, Scale-out-Pfad, Multi-Site-Optionen, Wiederherstellungsverhalten, Kosten und danach, was ein kompromittierter Backup-Server noch tun kann, und betrachtet anschließend den gemeinsamen Betrieb beider Modelle.
Was bedeutet Unveränderlichkeit im Veeam-Kontext?
In Veeam-Terminologie bedeutet Unveränderlichkeit, dass ein Wiederherstellungspunkt für einen definierten Zeitraum weder verändert noch gelöscht werden kann, auch nicht von einem Konto mit vollen Rechten in der Veeam-Konsole. Sich allein auf Zugriffskontrolle zu verlassen, ist die naive Antwort: Sie scheitert, sobald ein Angreifer diese Zugangsdaten erlangt, und genau darauf zielen Ransomware-Kampagnen ab.
Unveränderlichkeit muss daher an einer Stelle durchgesetzt werden, die der Backup-Server nicht außer Kraft setzen kann. Das Hardened Linux Repository legt diesen Durchsetzungspunkt in das Dateisystem eines Linux-Hosts, den das Backup-Team kontrolliert. Ein S3-Object-Lock-Repository legt ihn in die Speicherplattform, die auf jedes Objekt eine Aufbewahrungsregel anwendet und Lösch- oder Überschreibanfragen bis zum Ablauf der Regel zurückweist.
Wie funktioniert ein Hardened Linux Repository?
Ein Hardened Repository ist ein Linux-Server mit direkt angeschlossenem Blockspeicher, der mit XFS formatiert ist. Veeam schreibt Backup-Dateien darauf und setzt für jede Datei das Immutable-Attribut des Dateisystems für die konfigurierte Aufbewahrungsfrist. Solange das Attribut gesetzt ist, kann die Datei weder gelöscht, umbenannt noch verändert werden, auch nicht von root, bis ein geplanter Prozess auf dem Repository es entfernt.
Zwei Designentscheidungen machen das glaubwürdig. Das Repository wird in Veeam mit Einmal-Zugangsdaten registriert, sodass der Backup-Server keinen dauerhaften privilegierten Login auf dem Host hält. Und der Host soll isoliert sein: keine Passwortanmeldung aus der Ferne, keine Mitgliedschaft in einer Verzeichnisdomäne, eingeschränktes SSH und Behandlung als Appliance statt als Allzweckserver.
Was das Backup-Team übernimmt
Das Backup-Team wird zum Eigentümer eines kleinen, sicherheitskritischen Linux-Bestands. Jemand muss das OS-Image härten, Kernel- und Paket-Updates einspielen, auf Abweichungen überwachen, Festplatten tauschen und den physischen Zugang kontrollieren. Nichts davon ist schwierig, aber alles davon ist wiederkehrend, und die Garantie der Unveränderlichkeit hängt davon ab, dass es konsequent erledigt wird.
Die Skalierung erfolgt als Scale-up: Festplatten hinzufügen oder den Host durch einen größeren ersetzen. Mehrere Hardened Repositorys können als Performance Extents in einem Scale-out Backup Repository gruppiert werden, aber jedes bleibt ein unabhängiger Host mit eigenem Patching, eigener Fehlerdomäne und eigener Kapazitätsgrenze.
Wie funktioniert S3 Object Lock als Veeam-Repository?
Bei Objektspeicher schreibt Veeam Backup-Daten als Objekte in einen Bucket mit aktivierter Versionierung und aktiviertem Object Lock und setzt für jedes Objekt ein Retain-Until-Datum. Die Plattform setzt dieses Datum durch: Lösch- oder Überschreibanfragen vor Ablauf werden unabhängig von den vorgelegten Zugangsdaten verweigert. Veeam verlängert die Aufbewahrungsdaten für Objekte, die noch von aktiven Wiederherstellungspunkten benötigt werden, sodass Administratoren nie einzelne Objekte anfassen.
Objektspeicher dient Veeam in zwei Rollen. Als Capacity Tier in einem Scale-out Backup Repository empfängt er Kopien oder ausgelagerte Wiederherstellungspunkte aus einem Performance Tier, typischerweise für längere Aufbewahrung oder externen Schutz. Als Direct-to-Object Performance Tier empfängt er primäre Backups direkt aus den Jobs. Der Mechanismus der Unveränderlichkeit ist in beiden Rollen identisch.
Wohin sich der Betriebsaufwand verlagert
Das Backup-Team patcht keinen Linux-Host mehr, um die Unveränderlichkeit zu erhalten. Der Härtungsaufwand verlagert sich auf das Zugriffsmodell der Speicherplattform: ein dedizierter Veeam-Benutzer, Bucket-Richtlinien nach dem Prinzip der minimalen Rechte, MFA für administrativen Zugang und Trennung von Backup- und Speicheradministration. Ein On-Premises-Objektspeicher hat weiterhin Hosts, die aktualisiert werden müssen, aber diese Arbeit gehört zur Speicherebene und schwächt die Sperre nicht, wenn sie einmal ausbleibt.
Die Skalierung erfolgt horizontal. Objektspeicher wächst durch Hinzufügen von Knoten oder Laufwerken zu einem einzigen Namespace, sodass ein Bucket von einigen zehn Terabyte auf Petabytes wachsen kann, ohne Repositorys neu zu architektieren oder Daten zwischen Hosts zu migrieren.
Was kann ein kompromittierter Backup-Server in jedem Modell tun?
Im Modell des Hardened Repository kann ein kompromittierter Veeam-Server Backup-Jobs löschen, Aufbewahrungsrichtlinien ändern und künftige Backups stoppen. Er kann keine Dateien löschen oder verändern, die das Immutable-Attribut tragen. Erlangt der Angreifer jedoch zusätzlich root auf dem Linux-Host, über eine separate Schwachstelle, eine schwache SSH-Konfiguration oder physischen Zugang, kann das Attribut entfernt und die Daten vernichtet werden. Das Hardened Repository ist nur so stark wie die Linux-Härtung um es herum.
Im Object-Lock-Modell kann ein kompromittierter Veeam-Server künftige Backups auf dieselbe Weise stören, aber die Aufbewahrung bereits gesperrter Objekte nicht verkürzen. Bei Sperrung im Compliance-Stil kann selbst der Speicheradministrator eine Sperre nicht vor Ablauf entfernen. Der Angreifer müsste die Speicherplattform selbst kompromittieren: ein separates System mit separaten Zugangsdaten und idealerweise einem separaten Team. Diese Funktionstrennung ist das zentrale Sicherheitsargument für Object Lock.
Wie vergleichen sich Wiederherstellungsverhalten, Multi-Site-Optionen und Kosten?
Wiederherstellungsverhalten
Wiederherstellungen aus einem Hardened Repository verhalten sich wie bei jedem blockbasierten Repository: schneller wahlfreier Zugriff und Unterstützung für Instant Recovery. Wiederherstellungen aus Objektspeicher hängen von der Plattform ab. Ein gut dimensionierter On-Premises-Objektspeicher liefert hohen Durchsatz über ein lokales Netz und unterstützt Instant Recovery und Wiederherstellungen auf Dateiebene direkt. Objektspeicher in einer Hyperscale-Cloud kann große Wiederherstellungen mit Egress-Gebühren und Bandbreitenlimits belasten, was vor einer langen Aufbewahrung dort modelliert werden sollte.
Multi-Site- und geografische Optionen
Ein Hardened Repository ist eine Maschine an einem Standort; externer Schutz bedeutet einen zweiten gehärteten Host an anderer Stelle plus einen Backup Copy Job. Objektspeicherplattformen replizieren typischerweise zwischen Standorten oder Buckets, und manche spannen einen einzigen Namespace über mehrere Standorte, sodass die Speicherebene die zweite unveränderliche Kopie erzeugen kann statt zusätzlicher Veeam-Jobs und Hosts.
Kostenprofil
Ein Hardened Repository ist günstig im Einstieg: ein Server, Laufwerke und eine Linux-Distribution. Seine Kostenkurve steigt mit der Größe an, weil jeder Host Hardware, Rackplatz und Administrationszeit hinzufügt. Objektspeicher hat für eine kleine Bereitstellung einen höheren Einstiegspunkt, flacht aber mit wachsender Kapazität ab, insbesondere wenn Erasure Coding die Spiegelung ersetzt und eine Plattform die Aufbewahrung übernimmt, die sonst mehrere Hosts erfordern würde. Angenommen, eine Organisation muss 90 Tage unveränderliche Wiederherstellungspunkte für 400 TB Quelldaten vorhalten; eine Speicherplattform gegenüber einer Flotte gehärteter Server wird dann ebenso zu einer Frage der Betriebskosten wie der Hardware.
Entscheidungstabelle: Hardened Repository oder Object Lock?
| Dimension | Hardened Linux Repository | S3-Object-Lock-Repository |
|---|---|---|
| Wo Unveränderlichkeit durchgesetzt wird | XFS-Immutable-Attribut auf einem Linux-Host, den das Backup-Team betreibt | Aufbewahrungsregel, durchgesetzt von der Objektspeicherplattform |
| Betriebsaufwand | OS-Härtung, Patching, physische Sicherheit pro Host | Zugriffsrichtlinien auf Speicherebene; Host-Wartung liegt beim Speicherteam |
| Scale-out-Pfad | Scale-up pro Host; mehr Hosts als SOBR-Extents | Knoten oder Laufwerke zu einem einzigen Namespace hinzufügen |
| Multi-Site-Optionen | Zweiter Host plus Backup Copy Jobs | Plattformreplikation oder gestretchte Buckets |
| Wiederherstellungsverhalten | Lokale Wiederherstellungen mit Blockgeschwindigkeit, Instant Recovery | Schnell auf lokalem Objektspeicher; Egress- und Bandbreitenaspekte in der Public Cloud |
| Kostenprofil | Niedrige Einstiegskosten, steigen mit der Host-Anzahl | Höherer Einstiegspunkt, flacht bei Skalierung ab |
| Kompromittierter Backup-Server | Kann gesperrte Dateien nicht löschen; root auf dem Host könnte es | Kann Sperren nicht verkürzen; erfordert separate Kompromittierung der Speicherplattform |
| Beste Eignung | Kurzfristige lokale Aufbewahrung, kleinere Standorte, schnelle operative Wiederherstellungen | Lange Aufbewahrung, externe Kopien, große oder wachsende Bestände |
Warum viele Organisationen beides betreiben
Die beiden Modelle schließen sich nicht gegenseitig aus, und das Scale-out Backup Repository ist darauf ausgelegt, sie zu kombinieren. Ein gängiges Muster nutzt ein Hardened Repository als Performance Tier für aktuelle Wiederherstellungspunkte, wo schnelle lokale Wiederherstellungen am wichtigsten sind, und einen Object-Lock-Bucket als Capacity Tier für längere Aufbewahrung und die externe Kopie. Unveränderlichkeit gilt auf beiden Stufen, sodass ein kurzes Fenster auf dem gehärteten Host ältere Daten nicht ungeschützt lässt.
Fragen, die bei der Aufteilung helfen:
- Wie lange müssen Wiederherstellungspunkte unveränderlich bleiben, und kann ein einzelner gehärteter Host diesen Zeitraum bequem speichern?
- Wer patcht und überwacht den gehärteten Host, und ist diese Rolle dokumentiert und besetzt?
- Ist eine externe unveränderliche Kopie durch Richtlinie, Regulierung oder Versicherer vorgeschrieben, und wie wird sie erzeugt?
- Sind Backup- und Speicheradministration getrennt, damit eine kompromittierte Rolle die Kontrollen der anderen nicht aufheben kann?
- Welchen Wiederherstellungsdurchsatz benötigt der größte Workload, und wo müssen diese Daten liegen, um ihn zu erreichen?
- Wie stark werden die Daten über die Aufbewahrungsdauer wachsen, und welches Modell fängt das mit der geringsten Neuarchitektur auf?
Wie Scality ARTESCA als Object-Lock-Ziel für Veeam passt
Scality ARTESCA ist S3-Objektspeicher, der für Backup entwickelt wurde und mit Veeam als Object-Lock-Repository sowohl für Direct-to-Object- als auch für Capacity-Tier-Einsatz validiert ist. Die Unveränderlichkeit wird von der Plattform durchgesetzt, sodass ein kompromittierter Veeam-Server die Aufbewahrung gesperrter Objekte nicht verkürzen oder entfernen kann. Das Sicherheitsmodell ist auf der ARTESCA-Seite zu Sicherheit und Cyber-Resilienz beschrieben.
ARTESCA ist als Software oder Hardware-Appliance verfügbar und skaliert von einigen zehn Terabyte bis zu Petabytes in einem einzigen Namespace, was zu den Rollen für lange Aufbewahrung und externe Kopien passt, in denen eine Flotte von Hardened Repositorys schwer zu verwalten wird. Hinweise zur Dimensionierung einer Object-Lock-Stufe finden sich im Beitrag zur Dimensionierung von Backup-Repositorys, und die Liste der validierten Backup-Anwendungen steht auf der Seite zur Backup-Kompatibilität.
Welches Modell auch gewählt wird, der praktische Schritt ist derselbe: Legen Sie fest, wer für den Durchsetzungspunkt verantwortlich ist, dokumentieren Sie es und testen Sie eine Wiederherstellung aus unveränderlichen Daten, bevor ein Vorfall die Frage erzwingt.