Ransomware ist für viele Unternehmen nicht mehr das theoretische Schreckensszenario aus Sicherheitsvorträgen. Es ist ein sehr praktisches Betriebsproblem: Plötzlich sind Systeme verschlüsselt, Benutzerkonten nicht mehr vertrauenswürdig, Datenstände unklar und jede Stunde Ausfall kostet Geld.
In dieser Situation hilft ein Backup nur dann, wenn daraus auch ein belastbarer Wiederanlauf entsteht. Genau dort liegt in der Praxis oft der Unterschied zwischen “wir haben Sicherungen” und “wir sind wieder arbeitsfähig”.
Backup ist nur der Anfang
Ein Backup beantwortet zuerst nur eine Frage: Gibt es noch Daten aus einem früheren Zeitpunkt?
Für Recovery nach Ransomware reichen aber weitere Fragen mindestens genauso schwer:
- Welcher Datenstand ist sauber und nicht bereits kompromittiert?
- Welche Systeme müssen zuerst wieder laufen?
- Wo stehen Abhängigkeiten wie DNS, Identity Provider, Mail, Datenbanken oder Storage?
- Wer entscheidet, ob ein System wieder produktiv geschaltet wird?
- Wie wird verhindert, dass der Angreifer nach dem Restore direkt wieder Zugriff bekommt?
Wenn diese Punkte erst im Incident geklärt werden, geht wertvolle Zeit verloren.
Das größte Risiko: kompromittierte Grundlagen wiederherstellen
Bei klassischem Datenverlust ist ein Restore oft vergleichsweise klar: Datei weg, Datenbank beschädigt, VM defekt. Bei Ransomware ist die Lage schwieriger, weil nicht nur Daten betroffen sein können, sondern auch die Vertrauensbasis der Umgebung.
Typische Stolperstellen:
- alte Admin-Zugänge sind noch aktiv
- Passwörter und Tokens wurden vor der Verschlüsselung abgegriffen
- Backup-Ziele waren aus dem Produktivnetz erreichbar
- Monitoring und Logs wurden mit beschädigt oder nicht ausgewertet
- Systeme werden zu schnell wieder verbunden, bevor die Ursache verstanden ist
Deshalb reicht es nicht, einfach die letzte Sicherung zurückzuspielen. Recovery braucht einen sauberen Wiederanlaufpfad.
RTO und RPO müssen vorher realistisch sein
Zwei Kennzahlen entscheiden im Ernstfall sehr konkret:
- RPO: Wie viel Datenverlust ist maximal akzeptabel?
- RTO: Wie schnell muss ein Dienst wieder verfügbar sein?
Viele Unternehmen kennen diese Werte nur grob. Im Alltag klingt “möglichst schnell” ausreichend. Im Incident ist das zu ungenau.
Ein Warenwirtschaftssystem, Mail, Dateiserver, VPN, Telefonie und Website haben selten dieselbe Priorität. Ohne vorherige Reihenfolge wird im Stress oft an den falschen Dingen zuerst gearbeitet.
Was ein Ransomware-Recovery-Plan enthalten sollte
Ein brauchbarer Plan muss nicht aus 80 Seiten Dokumentation bestehen. Er muss aber die wichtigsten Entscheidungen vorwegnehmen.
1. Systempriorisierung
Welche Dienste sind kritisch für den Weiterbetrieb? Welche können warten? Welche Abhängigkeiten müssen zuerst stehen?
Hier gehören nicht nur Servernamen hinein, sondern auch fachliche Zusammenhänge: Buchhaltung, Produktion, Kundenkommunikation, Warenwirtschaft, Identitäten.
2. Saubere Restore-Quellen
Backups müssen getrennt genug sein, damit sie bei einem Angriff nicht einfach mitverschlüsselt oder gelöscht werden. Wichtig sind getrennte Berechtigungen, verschlüsselte Sicherungen, georedundante Ziele und regelmäßige Prüfung, ob neue Sicherungen wirklich ankommen.
Unser Beitrag zu State-of-the-Art Backups mit Puppet, Restic und georedundantem S3 beschreibt diesen technischen Unterbau genauer.
3. Wiederaufbau statt blindem Zurückrollen
Nach Ransomware ist ein frisches, gehärtetes Zielsystem oft besser als ein schneller Restore in eine möglicherweise kompromittierte Altumgebung. Das gilt besonders für zentrale Dienste wie Identity, VPN, Admin-Zugänge oder Management-Systeme.
Ein Restore sollte deshalb nicht nur Daten zurückbringen, sondern mit Härtung, Patch-Stand und Zugriffskontrolle zusammen gedacht werden.
4. Identitäten und Zugangsdaten
Ein häufiger Fehler ist, nur Server wiederherzustellen und Benutzerkonten unverändert zu lassen. Wenn Zugangsdaten abgeflossen sind, ist das gefährlich.
Zum Recovery gehören deshalb auch:
- Passwort- und Token-Rotation
- Prüfung privilegierter Konten
- MFA für kritische Zugänge
- Break-Glass-Zugänge mit klarer Dokumentation
- saubere Trennung von Admin- und Benutzerkonten
Für zentrale Anmeldung und MFA kann ein sauber betriebener Identity Provider wie Authentik ein wichtiger Baustein sein.
5. Kommunikation und Entscheidungen
Technische Wiederherstellung ist nur ein Teil des Problems. Im Ernstfall braucht es klare Ansprechpartner, Entscheidungswege und Kommunikationskanäle.
Wer informiert Kunden? Wer entscheidet über das Abschalten oder Wiederanschalten von Diensten? Wer dokumentiert Maßnahmen? Wer prüft, ob Meldepflichten greifen?
Diese Fragen gehören in den Plan, nicht in die erste Krisenbesprechung.
Restore-Tests müssen Ransomware mitdenken
Ein normaler Restore-Test ist wichtig, aber für Ransomware nicht automatisch ausreichend. Sinnvoll sind Tests, die bewusst härtere Bedingungen simulieren:
- Restore ohne Zugriff auf das normale Produktivnetz
- Wiederanlauf eines kritischen Dienstes auf frischer Infrastruktur
- Prüfung eines älteren Datenstands statt nur des letzten Backups
- Rotation betroffener Zugangsdaten nach dem Restore
- dokumentierte Messung von RTO und tatsächlichem Aufwand
Der Artikel Restore-Tests in der Praxis beschreibt passende Testszenarien für den Regelbetrieb. Für Ransomware sollte mindestens ein Teil davon als realistisches Krisenszenario geübt werden.
Monitoring entscheidet, ob Probleme früh auffallen
Ransomware-Recovery beginnt nicht erst nach der Verschlüsselung. Je früher Auffälligkeiten sichtbar werden, desto kleiner ist oft der Schaden.
Wichtige Signale sind zum Beispiel:
- ausbleibende oder ungewöhnlich große Backup-Läufe
- plötzlich stark veränderte Datenmengen
- fehlgeschlagene Login-Versuche
- neue Admin-Konten oder Rechteänderungen
- Dienste, die unerwartet nicht mehr antworten
Für Backup-Strecken ist ein reines “Job lief” zu wenig. Deshalb prüfen wir im Betrieb auch, ob im Zielsystem wirklich aktuelle Stände angekommen sind, etwa über Backup Monitoring für Restic und S3 Garage.
Was Unternehmen jetzt konkret prüfen sollten
Ein pragmatischer Einstieg ist ein kurzer Recovery-Review:
- Kritische Systeme und Abhängigkeiten auflisten
- RTO/RPO pro System realistisch festlegen
- Backup-Zugriffe und Trennung vom Produktivnetz prüfen
- letzten erfolgreichen Restore-Test bewerten
- Identity-, MFA- und Admin-Zugänge prüfen
- Kommunikations- und Entscheidungswege dokumentieren
- einen echten Restore in Testumgebung durchführen
Danach ist meist schnell klar, ob das Unternehmen wirklich recovery-fähig ist oder nur Backups besitzt.
Recovery ist laufender Betrieb, kein Notfallprojekt
Ransomware-Vorbereitung funktioniert nicht als einmalige Aktion. Neue Systeme, neue Benutzer, neue Anwendungen und geänderte Datenflüsse verändern ständig, was wiederhergestellt werden muss.
Belastbar wird das Thema erst, wenn Backup, Monitoring, Patch-Management, Identitätsmanagement und Dokumentation zusammenlaufen. Genau dafür ist ein strukturierter Betrieb wichtig: nicht spektakulär, aber im Ernstfall entscheidend.
Wenn ihr wissen wollt, wie eure Umgebung in dieser Hinsicht dasteht, ist ein Einstieg über Backup für Unternehmen, Managed IT oder einen kompakten IT-Sicherheits-Check sinnvoll.
30-Minuten Recovery-Review
Wir schauen gemeinsam auf eure Backup-Strecken, Restore-Tests, Admin-Zugänge und Wiederanlauf-Reihenfolge. Danach habt ihr eine klare Einschätzung, wo euer Recovery-Plan trägt und wo er im Ernstfall wahrscheinlich bricht.