Kurzfassung
- 3-2-1 ist die Mindestbasis, nicht das Ziel.
- Mindestens eine Kopie muss offline oder unveränderbar (immutable) sein.
- Ohne regelmäßige Restore-Tests sind Backups eine Annahme, keine Sicherheit.
- Backup-Identitäten dürfen niemals identisch mit Produktionsadmins sein.
- Kompromittierte Zugangsdaten gefährden auch Backups, besonders in der Cloud.
- Backups ersetzen weder Prävention noch eine vollständige Ransomware-Strategie.
Zielgruppe
Geschäftsführung mit Budgetverantwortung, IT-Leitung, System- und Backup-Admins sowie Security- und Datenschutzverantwortliche in kleinen und mittleren Unternehmen.
Wichtiger Hinweis
Diese Inhalte ersetzen keine rechtliche, forensische oder organisatorische Einzelfallberatung. Die konkrete Backup-Architektur muss zur Systemlandschaft, zu den Wiederanlaufzielen (RTO, RPO) und zu den Geschäftsanforderungen passen.
Das 3-2-1-Prinzip im Detail
3-2-1 ist eine bewährte Faustregel und sollte heute als Mindeststandard verstanden werden. Sie schützt gegen einfache Ausfälle, ist aber gegen gezielte Ransomware-Angriffe allein nicht ausreichend.
- Mindestens drei Kopien der Daten (Original plus zwei Sicherungen)
- Auf zwei unterschiedlichen Medien oder Technologien
- Mindestens eine Kopie räumlich getrennt (offsite oder anderer Standort)
- Erweiterung 3-2-1-1-0: eine Kopie offline oder immutable, null Fehler beim letzten Restore-Test
Offline- und Immutable-Backups
Angreifer wissen, dass Backups ihr größter Gegner sind, und gehen gezielt dagegen vor. Eine Sicherung, die im selben Netz und mit denselben Identitäten erreichbar ist wie die Produktion, ist im Ernstfall keine echte Sicherheit.
- Object-Lock, WORM oder vergleichbare Immutability auf Speichersystemen
- Air-gapped oder regelmäßig physisch getrennte Medien (Tape, Wechseldatenträger)
- Schreibschutz auf Storage-Ebene, nicht nur auf Anwendungs-Ebene
- Klare Aufbewahrungsfristen, die kein Operator kurzfristig unterlaufen kann
Restore-Tests
Ein Backup, das nicht regelmäßig wiederhergestellt wurde, ist eine unbewiesene Annahme. Erst der Restore-Test macht aus einer Sicherung eine belastbare Rückfallebene.
- Mindestens jährliche Restore-Tests für kritische Systeme, besser quartalsweise
- Realistische Szenarien testen, nicht nur Job-Statistiken prüfen
- Wiederanlaufzeiten (RTO) und Datenverlust (RPO) messen und dokumentieren
- Tests in isolierter Umgebung durchführen, nie blind in Produktion zurückspielen
- Ergebnisse, Abweichungen und Verbesserungen schriftlich festhalten
Backup-Segmentierung
Backup-Systeme verdienen eine eigene Sicherheitszone. Sie sind Hochwertziel und letzte Verteidigungslinie zugleich.
- Eigene Netzwerkzone für Backup-Server und Backup-Speicher
- Eigene Identitätsdomäne, kein gemeinsamer Domain-Admin mit Produktion
- Strikt getrennte Konten für Backup-Administration und Tagesgeschäft
- Eigenes Monitoring und Alarmierung für Backup-Jobs und Backup-Speicher
- Zugriff auf Backup-Konsolen nur über privilegierte Arbeitsplätze (PAW)
Härtung des Backup-Systems
- Multi-Faktor-Authentifizierung für alle Backup-Admins
- Regelmäßige Patches für Backup-Software und zugrundeliegende Systeme
- Logging aller administrativen Aktionen in Backup-Konsolen
- Verschlüsselung der Backup-Daten in Transit und at Rest
- Notfall-Accounts mit dokumentiertem Bruchsiegel-Verfahren
Typische Fehler
- Backups laufen, werden aber nicht überwacht
- Backup-Server hängt im gleichen Active Directory wie die Produktion
- Keine echten Restore-Tests, sondern nur Job-Statistik
- Keine getrennten Zugänge für Backup-Administration
- Cloud-Snapshots ohne Immutability
- Aufbewahrungsfristen, die kürzer sind als die typische Verweildauer der Angreifer
Warum Backups allein keine Ransomware-Strategie sind
Selbst perfekte Backups verhindern weder die Datenexfiltration noch den Vertrauensschaden. Eine tragfähige Strategie verbindet Prävention, Erkennung, Reaktion und Wiederherstellung.
- Double Extortion: Daten sind vor der Verschlüsselung längst abgeflossen
- Wiederanlauf braucht saubere Identitäten und gehärtete Systeme, nicht nur Daten
- Ohne Erkennung und Reaktion bleiben Angreifer im Netz - auch nach Restore
- Backups schützen nicht vor Reputations- und Vertragsschäden
Warum kompromittierte Zugangsdaten auch Backups gefährden
Moderne Angriffe sind Identitätsangriffe. Wer privilegierte Zugangsdaten erbeutet, kann auch Cloud-Snapshots, SaaS-Backups oder Backup-Konsolen angreifen - selbst dann, wenn die Daten ansonsten gut gesichert wären.
- Cloud-Backups mit Produktionszugangsdaten können gelöscht oder mitverschlüsselt werden
- SaaS-Daten (Mail, Kollaboration) brauchen eigene, getrennt geschützte Sicherungen
- API-Tokens und Service-Accounts mit Backup-Berechtigungen sind Hochwertziele
- MFA, Tiering und getrennte Identitätsdomänen sind Pflicht, nicht Komfort
Wiederherstellung im Ernstfall
Im Ernstfall darf das Backup nicht blind zurückgespielt werden. Vorher muss klar sein, wann der Angreifer ins Netz kam, ob die Backups davor liegen und ob die Wiederherstellungsumgebung sauber ist.
- Wiederherstellung in isolierter Umgebung beginnen
- Backup-Stände vor dem mutmaßlichen Eintrittszeitpunkt bevorzugen
- Vor Produktivschaltung auf Persistenzen und Backdoors prüfen
- Identitäten breit zurücksetzen, bevor Systeme wieder erreichbar werden