Ransomware-Angriffe werden schneller, arbeitsteiliger und gezielter – auf Identitäten, Backups und den Wiederanlauf. Für Unternehmen reicht es deshalb nicht mehr, Daten nur zu sichern. Entscheidend ist, ob Security, Backup, Identitäten und Betriebsorganisation im Ernstfall als Einheit funktionieren – und ob sich kritische Services kontrolliert, priorisiert und mit geprüften Daten wiederherstellen lassen.

Die aktuelle Lage spricht gegen die Hoffnung, dass Ransomware und breit angelegte Cyberangriffe nachlassen. Check Point Research meldet für April 2026 weltweit durchschnittlich 2.201 Cyberangriffe pro Organisation und Woche. Das entspricht einem Plus von zehn Prozent gegenüber März und acht Prozent gegenüber dem Vorjahresmonat. Deutschland liegt mit 1.377 Angriffen pro Organisation und Woche zwar unter dem europäischen Durchschnitt von 1.848, bleibt aber deutlich im Fokus. Besonders relevant für IT-Verantwortliche ist die Kombination aus steigender Grundlast, weiterhin aktiver Ransomware und neuen Risiken durch generative KI.

Andere aktuelle Auswertungen stützen diese Einordnung aus unterschiedlichen Blickwinkeln. Sophos sieht in seinem Active-Adversary-Report 2026 eine deutliche Verschiebung beim Erstzugriff hin zu Identitäten. Kompromittierte Zugangsdaten, Brute-Force-Angriffe, Credential-Phishing, Token-Diebstahl und missbrauchte Vertrauensbeziehungen machten 2025 demnach einen großen Teil der Ursachen aus. HP bewertet KI auf Angreiferseite nüchterner, aber nicht beruhigender: Malware werde durch KI nicht automatisch besser, lasse sich aber schneller zusammenbauen, günstiger anpassen und leichter skalieren.

Trend Micro erwartet für 2026 eine stärker automatisierte Angriffsökonomie, in der KI-gestützte Kampagnen Schwachstellen, Cloud-Identitäten, Software-Lieferketten und KI-Infrastrukturen ins Visier nehmen. Der BSI-Lagebericht 2025 ordnet die IT-Sicherheitslage in Deutschland weiterhin als angespannt ein und verweist auf hohe Bedrohungen, unzureichend geschützte Angriffsflächen und anhaltenden Druck durch Ransomware.

Die Zahlen zeigen keinen singulären Ausreißer, sondern eine Lage, in der Angreifer Kampagnen anpassen, Zielgruppen wechseln und Phasen scheinbarer Entspannung taktisch nutzen können. Für Unternehmen verschiebt sich damit die Fragestellung: Es reicht nicht, einzelne Schutzmaßnahmen nachzurüsten. Entscheidend ist, ob Security, Backup, Storage, Netzwerk, Identitätsmanagement und Betriebsorganisation im Ernstfall zusammen funktionieren.

Ransomware zielt auf den Wiederanlauf

Moderne Ransomware-Kampagnen lassen sich nicht mehr sinnvoll als reine Verschlüsselungsereignisse betrachten. Der eigentliche Schaden entsteht oft dort, wo der Wiederanlauf stockt: bei kompromittierten Admin-Konten, fehlenden Systemabhängigkeiten, unklaren Restore-Punkten, nicht erreichbaren Dienstleistern oder Backup-Systemen, die selbst Teil des Angriffs geworden sind.

Für Rechenzentren ist das besonders kritisch, weil Storage-, Virtualisierungs-, Directory-, DNS- und Netzwerkdienste eng ineinandergreifen. Wird eine dieser Ebenen beschädigt oder ist ihre Integrität unklar, verzögert sich die Wiederherstellung auch dann, wenn Sicherungskopien vorhanden sind. Viele Wiederanläufe scheitern nicht an der Existenz einer Kopie, sondern an der Reihenfolge: Zuerst müssen Identitäten, Management-Zugänge, Netzwerksegmente, Storage- und Virtualisierungs-Plattformen wieder vertrauenswürdig verfügbar sein, bevor Anwendungen und Daten kontrolliert zurückkehren können.

Ransomware-Resilienz 1.0 stand für die Absicherung von Daten: Backups erstellen, Kopien schützen, Wiederherstellung ermöglichen. Ransomware-Resilienz 2.0 erweitert diesen Ansatz auf die gesamte Betriebsfähigkeit. Es geht nicht mehr nur darum, ob eine Datenkopie vorhanden und unveränderlich ist, sondern ob kritische Services nach einem Angriff in einer nachvollziehbaren Reihenfolge, mit geprüften Daten und klaren Entscheidungswegen wieder anlaufen können. Backup bleibt zentral – aber es wird Teil eines umfassenderen Betriebsmodells, das Security, Identitäten, Storage, Netzwerk, Recovery-Prozesse und Krisenorganisation verbindet.

Dazu gehören technische Abhängigkeiten ebenso wie Entscheidungswege: Welche Systeme sind geschäftskritisch, welche Datenstände gelten als vertrauenswürdig, welche Plattformen müssen zuerst verfügbar sein und wer darf im Krisenmodus welche Freigaben erteilen?

Ransomware-Resilienz entsteht nicht durch eine einzelne Sicherungskopie, sondern durch das Zusammenspiel aus Backup, Security, Identitäten, Recovery und geübten Abläufen. (speicherguide.de via DALL-E)

Immutable Backups sind Pflicht, aber nicht genug

Unveränderliche Backups, WORM-Verfahren, Object-Lock, Air-Gap-Konzepte und ausgelagerte Kopien zählen inzwischen zu den zentralen Bausteinen einer Ransomware-Strategie. Sie reduzieren das Risiko, dass Angreifer Sicherungsdaten löschen, verschlüsseln oder nachträglich manipulieren. Damit lösen sie jedoch nur einen Teil des Problems.

Eine unveränderliche Kopie beantwortet noch nicht die Frage, ob der gesicherte Datenstand sauber ist, ob Zugangsdaten kompromittiert wurden oder ob die Wiederherstellung in der richtigen Reihenfolge erfolgt. Ebenso wenig schützt Immutable-Storage automatisch vor bereits infizierten Daten, falsch gesetzten Retention-Policies, kompromittierten Backup-Servern oder fehlender Restore-Kapazität. Eine Kopie kann unveränderlich und trotzdem für den sofortigen Wiederanlauf ungeeignet sein. Das ist bitter, aber technisch leider kein Widerspruch.

Ebenso wenig ersetzt Immutable-Storage eine gehärtete Backup-Infrastruktur mit getrennten Rollen, restriktiven Berechtigungen, Multi-Faktor-Authentifizierung und sauberer Protokollierung. Für IT-Teams liegt die Herausforderung darin, Backup-Repositorys nicht als bloßes Speicherziel zu behandeln, sondern als kritische Sicherheitskomponente. Wer Wiederherstellung als Teil der Verteidigungsarchitektur versteht, prüft nicht nur, ob Daten geschrieben wurden, sondern ob sie im Ernstfall kontrolliert, überprüfbar und ohne Reinfektion nutzbar sind.

Identitäten entscheiden über den Erstzugriff

Viele Angriffe beginnen nicht mit einer spektakulären Schwachstelle, sondern mit Zugangsdaten, privilegierten Konten oder schlecht abgesicherten Fernzugriffen. Für Ransomware-Resilienz ist Identitäts-Management deshalb keine vorgelagerte Security-Disziplin, sondern ein direkter Faktor für Backup- und Recovery-Fähigkeit. Wenn Domänenkonten, Service-Accounts oder Backup-Administratoren kompromittiert sind, geraten auch Sicherungs- und Wiederherstellungsprozesse unter Druck.

Kritisch sind besonders Konten mit breiten Rechten über Virtualisierung, Storage, Verzeichnisdienste und Backup-Plattformen hinweg. Dazu zählen Domänen-Admins, Hypervisor-Admins, Storage-Admins, Backup-Admins, Service-Accounts, API-Token und Break-Glass-Konten für den Notfall. Gerade diese Notfallkonten müssen verfügbar sein, dürfen aber nicht zur bequem genutzten Hintertür werden.

In der Praxis braucht es klare Trennung von Administrationsdomänen, minimal notwendige Rechte, phishing-resistente MFA (Multi-Faktor-Authentifizierung) für privilegierte Zugriffe, regelmäßige Überprüfung von Service-Accounts und nachvollziehbare Protokollierung. Backup- und Recovery-Systeme sollten eigene administrative Vertrauenszonen nutzen. Dieselben Konten, dieselben Admin-Workstations und dieselben Authentifizierungswege wie in der produktiven Umgebung machen das Backup zur letzten Verteidigungslinie mit dem Türschlüssel unter der Fußmatte.

Auch Wiederherstellungsprozesse müssen für den Fall geplant sein, dass zentrale Identitätsdienste nicht vertrauenswürdig oder nicht verfügbar sind. Ohne diese Perspektive kann ein technisch vorhandenes Backup im Ernstfall an der Frage scheitern, wer überhaupt noch sicher darauf zugreifen darf.

Recovery muss sauber, schnell und überprüfbar sein

Bei der Wiederherstellung zählt nicht allein die Geschwindigkeit. Ein schneller Restore nützt wenig, wenn kompromittierte Systeme, persistente Schad-Software oder manipulierte Konfigurationen zurück in den Betrieb gelangen. Cyber-Recovery braucht deshalb ein anderes Qualitätsverständnis als klassisches Disaster-Recovery. Neben RTO (Recovery Time Objective) und RPO (Recovery Point Objective) rückt die Vertrauenswürdigkeit des Wiederherstellungspunkts in den Vordergrund.

Diese Vertrauenswürdigkeit lässt sich auf drei Ebenen prüfen:

Datenebene: Sind die gesicherten Daten integer und sauber? Dazu gehören Malware-Scans, Integritätsprüfungen, der Abgleich mit bekannten guten Zuständen und die Bewertung der verfügbaren Versionsstände – also die Frage, welcher Snapshot überhaupt als vertrauenswürdiger Ausgangspunkt taugt.

Systemebene: Sind die Systeme selbst in einem kontrollierten Zustand? Relevant sind Konfigurationen, Patch-Stände, Benutzerkonten, geplante Tasks, Skripte und Persistenz-Mechanismen. Verdächtige Änderungen im Vergleich zum Normzustand müssen vor der Wiederinbetriebnahme bewertet werden.

Betriebsebene: Ist der Prozess des Wiederanlaufs nachvollziehbar und freigegeben? Das betrifft Zuständigkeiten, Freigabekriterien, Protokollierung und die Reihenfolge der Wiederinbetriebnahme. Besonders anspruchsvoll sind die Abhängigkeiten zwischen Active-Directory, DNS, Datenbanken, Applikations-Servern, Storage-Systemen und Netzwerksegmenten. Werden diese nicht dokumentiert und getestet, entstehen im Ernstfall manuelle Rekonstruktionsarbeiten unter hohem Zeitdruck.

Für isolierte Recovery-Umgebungen und forensisch verwertbare Logs gilt dasselbe Prinzip: Sie sind nur dann nützlich, wenn ihre Nutzung vorab definiert und geübt wurde. Der saubere Restore ist damit nicht der schnellste Klick im Backup-Tool, sondern ein geprüfter Betriebszustand – erreicht durch eine kontrollierte Wiederinbetriebnahme priorisierter Services mit überprüfbaren Zwischenschritten.

Cyber-Recovery ist kein linearer Restore-Prozess. Entscheidend ist die kontrollierte Wiederinbetriebnahme priorisierter Services mit geprüften Daten. (speicherguide.de via DALL-E)

Ohne Notfallplan bleibt Resilienz Theorie

Technische Schutzmaßnahmen entfalten ihre Wirkung nur, wenn im Vorfall klar ist, wie sie genutzt werden. Viele Verzögerungen entstehen nicht durch fehlende Tools, sondern durch unklare Zuständigkeiten, fehlende Entscheidungsrechte, widersprüchliche Kommunikationswege oder nicht geübte Abläufe. Ein belastbarer Notfallplan muss daher über Kontaktlisten hinausgehen.

Er sollte festlegen, wer Systeme isolieren darf, wann externe Spezialisten eingebunden werden, welche Daten für die Analyse gesichert werden, wie mit Fachbereichen kommuniziert wird und welche Kriterien für Wiederanlaufentscheidungen gelten. Dazu kommen Rechts- und Compliance-Fragen: Wer bewertet mögliche Meldepflichten, wer stimmt sich mit Datenschutz, Geschäftsführung, Versicherung, Behörden oder externen Dienstleistern ab und wer entscheidet über externe Kommunikation? Solche Fragen lassen sich im laufenden Vorfall nur schwer sortieren. Dann ist meist schon genug los.

Für Rechenzentrums- und IT-Betriebsteams ist auch relevant, welche Dokumentation im Ernstfall offline verfügbar ist. Dazu zählen Netzpläne, Backup-Konfigurationen, Zugangskonzepte, Prioritätenlisten, Abhängigkeiten kritischer Anwendungen, Ansprechpartner und Notfallzugänge. Tabletop-Übungen und technische Restore-Tests decken Lücken auf, bevor sie im Krisenmodus teuer werden. Ransomware-Resilienz entsteht nicht durch Papier, sondern durch wiederholte Übung unter realistischen Annahmen.

Resilienz 2.0 verbindet Technik und Betrieb

Ransomware-Resilienz 2.0 beschreibt keinen einzelnen Produktansatz, sondern ein Betriebsmodell. Backup, Security, Storage, Netzwerk, Identitäten, Monitoring, Governance und Krisenorganisation müssen ineinandergreifen. In vielen Unternehmen sind diese Bereiche historisch getrennt gewachsen. Genau dort entstehen im Ernstfall Brüche: Security erkennt den Vorfall, Backup hält Kopien vor, der Betrieb kennt die Abhängigkeiten, das Management entscheidet über Prioritäten. Wenn diese Ebenen nicht vorbereitet zusammenspielen, kostet jede Abstimmung Zeit.

Ein resilientes Betriebsmodell definiert deshalb gemeinsame Ziele, gemeinsame Tests und gemeinsame Entscheidungswege. Der Maßstab ist nicht, ob eine einzelne Komponente technisch verfügbar ist, sondern ob kritische Services nach einem Angriff in einer nachvollziehbaren Reihenfolge und mit geprüften Daten wieder anlaufen können. Damit verschiebt sich der Fokus von Datensicherung zu Betriebsfähigkeit.

Backup bleibt zentral, aber es wird Teil einer umfassenderen Antwort auf die Frage, wie ein Unternehmen unter Angriffsdruck handlungsfähig bleibt. Der Maßstab ist nicht die Existenz einer Sicherungskopie, sondern die Fähigkeit, kritische Services kontrolliert, priorisiert und mit geprüften Daten wieder in Betrieb zu nehmen.