Die 3-2-1-Backup-Regel (drei Kopien, zwei Medientypen, eine extern) schützt vor den Ausfällen, für die sie geschrieben wurde: ein defektes Disk-Array, ein korruptes Volume, ein überfluteter Serverraum. Sie wurde nie für einen Gegner entworfen, der den Backup-Katalog ausfindig macht, die Repositorys löscht und erst dann die Produktion verschlüsselt. Die erweiterte 3-2-1-1-0-Regel soll diese Lücke schließen.
Die Erweiterung fügt eine Kopie hinzu, die offline, per Air Gap getrennt oder unveränderlich ist, sowie die Anforderung von null Fehlern nach der Wiederherstellungsverifizierung. Beides erzwingt zwei Fragen, die die ursprüngliche Regel nie gestellt hat: Kann ein Angreifer mit Administratorzugangsdaten jede Kopie zerstören, und weiß tatsächlich jemand, dass die Backups sich wiederherstellen lassen? Dieser Artikel erklärt jede Ziffer, wie unveränderlicher Objektspeicher die zusätzliche Kopie abdeckt, was "null Fehler" in der Praxis bedeutet, und schließt mit einem Beispiel-Layout und einer Checkliste.
Die 3-2-1-1-0-Regel legt fünf Mindestbedingungen für eine Backup-Strategie fest: drei Kopien der Daten, auf zwei Speichertechnologien, eine Kopie extern, eine Kopie, die offline, per Air Gap getrennt oder unveränderlich ist, und null Fehler bei der Verifizierung. Die ersten drei Ziffern sind die klassische Regel; die letzten beiden kamen hinzu, als Ransomware zum dominierenden Wiederherstellungsszenario wurde.
Die naive Lesart ist, dass es einfach mehr Kopien bedeutet. Wenn jede Kopie mit denselben Zugangsdaten gelöscht werden kann, bringt eine vierte Kopie wenig. Die zusätzliche "1" verdient ihren Platz durch Unabhängigkeit von der Steuerungsebene, die überall sonst verwendet wird; die "0" ersetzt die Annahme, dass Backups funktionieren, durch den Nachweis, dass sie es tun.
Produktion plus mindestens zwei Backups, damit ein einzelnes Ereignis wie ein Controller-Fehler nicht die Daten und ihr einziges Backup gemeinsam zerstören kann. Heute ist das üblicherweise ein primäres Repository vor Ort für schnelle Wiederherstellungen plus eine zweite Kopie in einem anderen Repository oder einem Objektspeicher.
Die Backup-Kopien sollten keine gemeinsame Fehlerursache teilen: denselben Firmware-Bug, dieselbe Dateisystemkorruption oder dasselbe Administratorkonto, das beide löschen kann. Historisch bedeutete das Festplatte und Band; heute bedeutet es häufiger ein Block- oder Datei-Repository plus einen S3-Objektspeicher.
Schutz vor Feuer, Hochwasser, Stromausfall oder regionalem Ausfall, typischerweise erfüllt durch Replikation in ein sekundäres Rechenzentrum oder einen Kopierjob in eine Colocation-Einrichtung oder Public Cloud. Extern bedeutet nicht vor Ransomware geschützt: Ein Replikat, das Löschungen von der Quelle übernimmt, bleibt exponiert.
Das ist die Ransomware-Ziffer. Sie schützt vor einem Angreifer, der Backup-Server, Hypervisor oder Domäne kompromittiert hat und legitime Zugangsdaten besitzt. Die Kopie muss eine sein, die diese Zugangsdaten nicht verändern oder löschen können:
Der Fehler ist hier still: Ein Job kann Erfolg melden, während er ein Image schreibt, das sich nicht einhängen lässt, oder eine virtuelle Maschine, die nicht bootet. Die Anforderung ist, dass die Verifizierung, nicht der Jobstatus, null Fehler meldet.
| Ziffer | Adressierte Bedrohung | Gängige Umsetzungen | Typischer Fehler |
|---|---|---|---|
| 3 Kopien | Ein Ausfall zerstört Daten und ihr einziges Backup | Produktion plus primäres Repository plus sekundäre Kopie | Snapshots des Produktions-Arrays als Kopie zählen |
| 2 Technologien | Gemeinsame Fehlerursache über Kopien hinweg | Block- oder Datei-Repository plus S3-Objektspeicher; Festplatte plus Band | Zwei Repositorys auf derselben Plattform und demselben Admin-Konto |
| 1 extern | Standortverlust, regionaler Ausfall | Sekundäres Rechenzentrum, Colocation, Cloud-Objektspeicher | Replikation, die Löschungen getreu weitergibt |
| 1 offline / unveränderlich | Angreifer mit Backup- oder Domänen-Admin-Zugangsdaten | Ausgeworfenes Band, Ziel im isolierten Netz, S3 Object Lock im Compliance-Modus | Governance-Modus oder Aufbewahrung kürzer als die Verweildauer des Angreifers |
| 0 Fehler | Stille Korruption, nicht wiederherstellbare Backups | Integritätsscans, Boot-Verifizierung, geplante Testwiederherstellungen | "Job abgeschlossen" als Nachweis der Wiederherstellbarkeit werten |
Band bleibt eine legitime Offline-Kopie, bringt aber Logistik mit sich, für die viele Teams nicht mehr besetzt sind: Wartung der Library, Medienrotation, Transport zum Tresor und Wiederherstellungen, die auf die richtige Kassette warten. Ein Air Gap vermeidet das Medien-Handling, hängt aber weiterhin von Disziplin bei der Zeitplanung ab. Unveränderlicher Objektspeicher erreicht dasselbe Ergebnis, indem er die Kopie für einen definierten Zeitraum logisch unlöschbar macht, statt sie physisch zu trennen.
Wenn die Backup-Anwendung ein Objekt mit einer Aufbewahrungsfrist im Compliance-Modus schreibt, verweigert der Speicher jedes Löschen oder Überschreiben bis zum Ablauf dieser Frist, unabhängig davon, wer es anfordert. Ein kompromittierter Backup-Server kann weiterhin Löschbefehle absetzen; er erhält lediglich Fehlermeldungen. Da die Aufbewahrung auf Speicherebene durchgesetzt wird, entfernt sie auch das Umkonfigurieren oder Deinstallieren der Backup-Anwendung nicht.
Daraus folgen mehrere Designkonsequenzen. Das Konto, das die Backup-Anwendung verwendet, sollte nur Schreibberechtigungen besitzen, damit seine Kompromittierung keine Bucket-Richtlinien ändern kann. Die Speicheradministration sollte eine separate Identität mit Multi-Faktor-Authentifizierung verwenden, die bei anderen Personen liegt als die Backup-Administration. Die Aufbewahrung sollte die wahrscheinliche Verweildauer des Angreifers übersteigen, da ein Eindringling, der wochenlang präsent ist, eine kurze Frist einfach aussitzt. Die wichtigsten Backup-Anwendungen, darunter Veeam, Commvault, Rubrik, Cohesity und HYCU, schreiben direkt in Buckets mit aktiviertem Object Lock; in Veeam-Terminologie ist das ein unveränderlicher Capacity Tier eines Scale-out Backup Repository oder ein direktes Objektspeicher-Repository. An einem zweiten Standort bereitgestellt, deckt dasselbe Ziel auch die zweite Technologie und die externe Kopie ab.
Eine praktikable Interpretation hat drei Ebenen.
Die Backup-Anwendung oder das Speichersystem liest gespeicherte Daten zurück und vergleicht sie mit den beim Schreiben erfassten Prüfsummen, um Bit Rot und unvollständige Schreibvorgänge zu erkennen, bevor eine Wiederherstellung davon abhängt. Objektspeicher tun dies in der Regel kontinuierlich.
Die meisten Enterprise-Backup-Anwendungen können einen Wiederherstellungspunkt in einer isolierten Umgebung einhängen, booten und nach Zeitplan Prüfungen auf Anwendungsebene ausführen. Ein Fehler in diesem Bericht bedeutet, dass das Backup nicht als gut gezählt wird, unabhängig davon, was der Jobstatus gesagt hat.
Automatisierte Prüfungen beweisen, dass die Daten lesbar sind; eine Testwiederherstellung beweist, dass Menschen, Verfahren und Infrastruktur einen Dienst innerhalb der Zielzeit zurückbringen können. Sie sollte gezielt aus der unveränderlichen Kopie erfolgen, da eine Wiederherstellung aus dem primären Repository nichts über die Kopie aussagt, auf die es bei einem Angriff ankommt. Null Fehler bedeutet nicht, dass nie ein Problem gefunden wird; es bedeutet, dass jedes gefundene Problem behoben und die betroffenen Backups erneut verifiziert werden.
Angenommen, eine Organisation betreibt rund 400 virtuelle Maschinen an zwei Standorten, hält etwa 150 TB Primärdaten und strebt an, Kerndienste innerhalb von 24 Stunden nach einem Ransomware-Ereignis wiederherzustellen. Die Zahlen dienen der Veranschaulichung; die Form des Designs ist der Punkt.
Das ergibt drei Kopien, zwei Technologien, eine externe Kopie und eine unveränderliche Kopie. Die "0" wird erfüllt durch wöchentliche automatisierte Boot-Verifizierung der 40 kritischsten virtuellen Maschinen, kontinuierliche Integritätsprüfung in beiden Repositorys und eine quartalsweise vollständige Wiederherstellung einer Geschäftsanwendung aus der Kopie an Standort B unter Ausschluss des primären Repositorys. Zwei Details werden oft übersehen: Die administrativen Zugangsdaten des Objektspeichers liegen beim Infrastrukturteam statt beim Backup-Team, und die 30-tägige Aufbewahrung spiegelt einen Incident-Plan wider, der davon ausgeht, dass ein Angreifer vor der Entdeckung mehrere Wochen präsent sein kann.
Scality ARTESCA ist S3-Objektspeicher, der für Backup entwickelt wurde, verfügbar als Software oder Hardware-Appliance, von einigen zehn Terabyte bis zu Petabytes. Es unterstützt S3 Object Lock, sodass Wiederherstellungspunkte vor Ablauf ihrer Aufbewahrungsfrist weder gelöscht noch überschrieben werden können, was die vierte Ziffer der Regel verlangt.
ARTESCA ist mit den wichtigsten Backup-Anwendungen validiert, darunter Veeam, Commvault, Cohesity, Rubrik, HYCU, Veritas, Zerto, Acronis und IBM, sodass die unveränderliche Kopie als Repository innerhalb der Werkzeuge hinzugefügt werden kann, die ein Team bereits betreibt. Seine Funktionen für Sicherheit und Cyber-Resilienz adressieren die Konfigurationsdetails, etwa getrennte administrative Identitäten und Multi-Faktor-Authentifizierung, die entscheiden, ob die Unveränderlichkeit in der Praxis standhält.
Die praktische Schlussfolgerung: Erfüllen Sie die unveränderliche "1", indem Sie der bereits genutzten Backup-Anwendung ein Repository mit aktiviertem Object Lock hinzufügen, und beweisen Sie dann die "0", indem Sie nach Zeitplan aus diesem Repository wiederherstellen.