Ransomware trifft nicht nur produktive Systeme – oft sind auch Backups, Admin-Konten und Wiederherstellungsprozesse Ziel. Resilienz entsteht, wenn Backup-Design, Restore-Tests und Verantwortlichkeiten zusammenspielen. Dieser Leitfaden zeigt, wie Sie mit wenigen, aber konsequenten Bausteinen die Chance erhöhen, nach einem Angriff kontrolliert wieder hochzufahren.
Warum Backup bei Ransomware anders gedacht werden muss
Ein Backup ist kein Selbstzweck, sondern die letzte verlässliche Option, wenn Prävention und Detektion versagen. Genau deshalb versuchen viele Täter, Backup-Umgebungen früh zu sabotieren oder zu verschlüsseln, um den Druck zur Lösegeldzahlung zu erhöhen.
Behörden und Sicherheitsorganisationen betonen seit Jahren dieselbe Kernlogik: Offline/isolierte und verschlüsselte Backups sowie regelmäßige Tests, ob sich Daten und Systeme tatsächlich wiederherstellen lassen.
Backup-Strategie: Von „Kopien“ zu einer Wiederherstellungsfähigkeit
1) Erst die Prioritäten: Was muss wie schnell zurückkommen?
Die zentrale Vorarbeit heißt: Business Impact Analysis (BIA) im kleinen Maßstab. Nicht als Großprojekt, sondern pragmatisch:
- Welche Services sind „geschäftskritisch“ (Umsatz, Produktion, Patientenversorgung, Logistik)?
- Welche Daten sind „Kronjuwelen“ (ERP, Identitäten, Kundendaten, Forschungsdaten)?
- Welche Abhängigkeiten gibt es (AD/Entra ID, DNS, Virtualisierung, Storage, VPN)?
Daraus leiten sich zwei Schlüsselwerte ab:
- RTO (Recovery Time Objective): Wie schnell muss ein System wieder laufen?
- RPO (Recovery Point Objective): Wie viel Datenverlust ist maximal akzeptabel?
NIST beschreibt genau diese Ableitung: Wiederherstellungszeit festlegen (RTO) und „maximales Alter“ von Backups (RPO) definieren.
2) Das Grundmuster: mehrere Kopien, unterschiedliche Medien, eine Kopie außerhalb
Als robuste Faustregel gilt häufig „3-2-1“: mehrere Kopien, unterschiedliche Speichermedien, eine Kopie extern/ausgelagert. NIST führt dieses Prinzip explizit als Orientierung auf.
Für Ransomware kommt ein Zusatz dazu: mindestens eine Kopie muss gegenüber Manipulation/Encryption resistent sein – etwa durch:
- Immutable/WORM (Write Once, Read Many) bzw. „Object Lock“ in kompatiblen Storage-/Cloud-Systemen
- Air Gap (physisch oder logisch getrennt, nur zeitweise verbunden)
- Backup-Tresor mit streng separierten Credentials und Netzsegment
3) Backup-Infrastruktur härten: Backups sind ein eigenes „High-Value-Asset“
ENISA formuliert dafür zwei sehr praktische Prinzipien: Zugriff auf Backups kontrollieren, begrenzen und protokollieren – und Restore-Prozesse dokumentieren und regelmäßig testen.
Konkret heißt das (technisch und organisatorisch):
- Separierte Admin-Konten für Backup-Systeme (kein „Domain Admin macht alles“)
- MFA wo möglich; „Break-Glass“-Konten streng abgesichert und überwacht
- Netzsegmentierung: Backup-Server/Repos nicht frei aus dem Office-Netz erreichbar
- Patch-/Hardening-Regime für Backup-Software, Hypervisor, Storage, Management-Interfaces
- Logging/Monitoring: ungewöhnliche Löschvorgänge, Policy-Änderungen, Massenfehler, neue „Admin“-Accounts
4) Integrität und Nachweis: „Backup vorhanden“ reicht nicht
Zwei häufige Fallen:
- Backups laufen „grün“, enthalten aber nicht die richtigen Daten.
- Backups sind vorhanden, aber nicht konsistent oder nicht in sinnvoller Reihenfolge restorebar.
ENISA empfiehlt deshalb Integritätsprüfungen (z. B. Checksums/Hashes) und regelmäßige Restore-Tests – inklusive Tests unterschiedlicher Recovery-Szenarien (Full Restore, File Restore).
5) Nicht vergessen: Schlüssel, Passwörter, Konfigurationen – offline verfügbar
In echten Krisen scheitert Restore oft an Kleinigkeiten: fehlende Schlüssel, nicht verfügbare Passwörter, nicht dokumentierte DNS-/Netz-Abhängigkeiten. NIST empfiehlt, auch Credentials, Zertifikate, Keys und notwendige Informationen offline vorzuhalten, um den Betrieb wiederherstellen zu können.
Restore-Tests: Der Unterschied zwischen Hoffnung und belastbarer Resilienz
Welche Tests Sie wirklich brauchen (und wie oft)
Ein guter Testplan ist gestuft – nicht jeder Test muss ein vollständiger DR-Drill sein:
- Wöchentlich (klein): File-/Mailbox-/Objekt-Restore (Stichprobe) in ein isoliertes Ziel
- Monatlich (mittel): Applikations-Restore eines kritischen Systems (z. B. ERP-Testinstanz) inkl. Datenkonsistenzcheck
- Quartalsweise (groß): „Kernkette“ testen (Identity → Netzwerk/DNS → Virtualisierung/Compute → Storage → wichtigste Apps)
- Jährlich (komplett): Incident-/Ransomware-Übung mit Technik + Fachbereichen (Tabletop + ausgewählte technische Wiederherstellung)
NIST betont bei Tests nicht nur „geht/geht nicht“, sondern das Messen und Lernen: Zeit zum Abruf, Restore-Dauer, Rebuild-Zeit, Rollenverständnis, Lückenanalyse.
Vor dem Restore: „Sauberkeit“ prüfen
Ein häufiger Fehler: kompromittierte Backups werden eingespielt und die Umgebung infiziert sich erneut. Entsprechend empfehlen Sicherheitsleitlinien, vor der Wiederherstellung zu verifizieren, dass Backups nicht (mehr) mit Malware belastet sind.
Praktisch: Restore zuerst in eine isolierte „Clean Room“-Umgebung, Scans/Verhaltensprüfungen, dann produktionsnaher Wiederanlauf.
Ergebnisorientierung: KPIs statt Bauchgefühl
Metriken, die Sie aus jedem Restore-Test mitnehmen sollten:
- Erreichtes RTO/RPO pro Systemklasse
- Restore-Erfolgsquote (0/1) + Fehlerursachen
- Dauer für: Identitätsdienste, Netzwerk-Basics, Kernapplikationen
- Zeit bis „Business wieder arbeitsfähig“ (nicht nur „Server online“)
ENISA beschreibt Cyber-Stresstests als Methode, Resilienz systematisch zu prüfen und z. B. „time-to-recover“ zu messen – hilfreich als Rahmen für größere Übungen.
Rollen & Verantwortlichkeiten: Ohne klare Zuständigkeit scheitert Recovery
Minimalprinzip: Verantwortung liegt nicht „nur bei IT“
Backup & Recovery ist eine unternehmensweite Fähigkeit:
- Fachbereiche definieren Kritikalität (was zuerst?)
- IT/Plattform stellt Wiederherstellung sicher (wie?)
- Security steuert Risiko, Forensik und Freigaben (wann und unter welchen Bedingungen?)
- Management entscheidet Prioritäten und ggf. Betriebsmodus (Notbetrieb)