Die Lücke bei der Identitätswiederherstellung: Auf dem Papier sicher, in der Praxis entlarvt

Der NotPetya-Angriff auf Maersk im Jahr 2017 lehrte uns alle eine wichtige Lektion, die die Best Practices für die Cyber-Wiederherstellung maßgeblich beeinflusste. Als NotPetya das Unternehmen lahmlegte, wurde jede Kopie des Active Directory – sowohl die primäre als auch die Backup-Version – zerstört. Die Wiederherstellung begann nicht mit einem sauberen, getesteten und isolierten Wiederherstellungspunkt. Sie begann mit Glück: Ein Büro in Lagos, Nigeria, war lange genug offline gewesen, um eine intakte, vom Angriff unberührte Kopie zu erhalten. Eine Festplatte wurde mit einem Charterflugzeug zurückgebracht und lieferte Maersk einen Ausgangspunkt für den Wiederaufbau. Der grundlegende Betrieb konnte innerhalb von zwei Wochen wieder aufgenommen werden. Die vollständige Wiederherstellung dauerte fast einen Monat länger.

Diese Geschichte ist beispielhaft und verdeutlicht, dass Identität nicht einfach nur ein weiterer Workload ist, der nach einem Vorfall wiederhergestellt werden muss. Sie ist die Kontrollinstanz, die bestimmt, wer und was auf jeden einzelnen anderen Workload zugreifen kann. Wenn die Identitätsebene kompromittiert bleibt, schafft die Wiederherstellung von Daten vor der Wiederherstellung des Identitätsvertrauens lediglich den Weg des Angreifers zurück in die Umgebung.

Die Herausforderung besteht darin, dass sich heutige Cyberangriffe deutlich schneller entwickeln können als die Reaktionsfähigkeit und Ressourcen vieler Organisationen. Der Veeam-Bericht „Identity Under Attack“ und ein kürzlich von Veeam veranstaltetes Webinar zur Beschleunigung der SaaS- und Cloud-Wiederherstellung weisen beide auf eine wachsende Vertrauenslücke hin. Im Webinar hob Veeam hervor, dass 69 % der Organisationen glauben, gut auf einen Cyberangriff vorbereitet zu sein, aber nur 10 % mehr als 90 % ihrer Daten wiederherstellen können, wenn die Identität betroffen ist.

Einbrüche nicht mehr nötig …

Die Kernaussage des Berichts ist, dass die Identitätsebene die Grundlage für Cyberresilienz bildet. Solange die Identität nicht in einen vertrauenswürdigen Zustand zurückversetzt werden kann, ist keine andere Wiederherstellung vertrauenswürdig – was die Wiederherstellbarkeit der Identität zum Dreh- und Angelpunkt jeder Resilienzstrategie macht.

Eine kompromittierte Identität kann wie normale Aktivitäten aussehen, da die Anmeldeinformationen gültig sind, die Zugriffspfade autorisiert sind und die Systeme wie vorgesehen funktionieren. Das Whitepaper veranschaulicht dies anhand eines bekannten modernen Szenarios: Ein Dienstkonto authentifiziert sich von einem unbekannten Standort aus, SharePoint-Berechtigungen ändern sich, ein OAuth-Token ruft Salesforce-Datensätze ab, und eine Azure-Rollenzuweisung ermöglicht den Zugriff auf sensible Ressourcen. Es muss keine Malware auftreten. Kein Endpunkt muss aktiv werden. Der Angreifer nutzt Vertrauensbeziehungen, die das Unternehmen für legitime Zwecke eingerichtet hat. Er verwendet sie jedoch weit außerhalb ihres vorgesehenen Anwendungsbereichs.

Deshalb unterscheidet sich die Identitätswiederherstellung grundlegend von der herkömmlichen Datenwiederherstellung. Eine Dateiwiederherstellung kann auf einen Ordner, ein Postfach oder eine Anwendung beschränkt werden. Die Identitätswiederherstellung muss berücksichtigen, wie aus einer einzigen kompromittierten Anmeldeinformation drei kompromittierte Anmeldeinformationen in Active Directory, Entra ID und Okta entstehen können. Dadurch erhalten Angreifer Zugriff auf Microsoft 365, Salesforce und andere Anwendungen – und etablieren so Persistenz und Datenexfiltration in jedem Schritt. Wenn eine kompromittierte Identität bedingte Zugriffsrichtlinien ändert, langlebige Token erstellt, Dienstprinzipale ändert oder sich selbst Zugriff auf nachgelagerte Workloads gewährt, lässt die Wiederherstellung des sichtbaren Datenverlusts die zugrundeliegende Kompromittierung intakt und anfällig für weitere Angriffe.

Das Webinar beschreibt drei operative Prinzipien für die Wiederherstellung in einer solchen Umgebung. Erstens muss die Identität als sauber verifiziert werden, bevor nachgelagerte Systeme wiederhergestellt werden. Zweitens muss die Identitätswiederherstellung präzise erfolgen. Ein pauschales Rollback kann zwar schädliche Änderungen entfernen, aber auch legitime Arbeit zerstören, Integrationen unterbrechen und aufwendige Neukonfigurationen erzwingen. Teams müssen genau identifizieren, was sich geändert hat, und betroffene Objekte, Richtlinien, Benutzer, Anwendungen und Berechtigungen gezielt wiederherstellen. Drittens muss diese Präzision auf jeder Plattform gewährleistet sein, die von der kompromittierten Identität betroffen war, sodass wiederhergestellte Workloads und der wiederhergestellte Identitätsstatus konsistent sind – keine verwaisten Verweise, keine erneut eingeführten Artefakte des Angreifers – und jede Anmeldeinformation, jedes Token und jede Vertrauensbeziehung in der wiederhergestellten Umgebung als gültig bekannt ist.

Dieser letzte Punkt wird leicht unterschätzt, bis ein Vorfall im Gange ist. Die unabhängige Wiederherstellung von Plattformen ohne Abgleich der sie verbindenden Identitätsbeziehungen kann zu Abweichungen (Drift) führen. Beispielsweise können technisch wiederhergestellte Systeme nicht mehr hinsichtlich Berechtigungen, Eigentümern, Token oder Objektbeziehungen übereinstimmen. Während einer Krise erschwert die Nutzung verschiedener Backup- und Recovery-Plattformen zur Wiederherstellung von Identitätsdaten die Koordination. Dies führt zu langsameren Entscheidungen, erhöhter Verwirrung bei den Anwendern und einem höheren Risiko menschlicher Fehler – gerade dann, wenn Teams Schnelligkeit und Sicherheit benötigen.

Die Nutzung mehrerer Tools verschärft die Identitätsdrift

Fragmentierte Tools verschlimmern dieses Problem. In vielen Organisationen sind die Verantwortlichen für Backup und Recovery nach den Plattformen und Workloads getrennt, die sie schützen müssen, und jedes dieser Backup-Teams verwendet möglicherweise eine oder mehrere verschiedene Backup- und Recovery-Plattformen für seine Arbeit. Identitätssysteme fallen oft in die Lücke zwischen diesen Teams – AD gehört zum Verzeichnis-/Infrastruktur-Team, Entra ID zum M365- oder Cloud-Team, Okta zum Security- oder IAM-Team –, sodass die Identitätswiederherstellung häufig weder einen eindeutigen Verantwortlichen noch einheitliche Tools besitzt.

Jedes Team sieht möglicherweise nur einen Teil eines Vorfalls, und es besteht zudem eine Lücke im Kontextverständnis zwischen diesen Teams und dem Security Operations Team. Niemand ist in der Lage, den gesamten Pfad von der Identität bis zu den Daten zu überblicken. Daher plädiert das Webinar von Veeam für Konsolidierung – nicht aus Bequemlichkeit, sondern als Notwendigkeit für einen intelligenten Resilienzbetrieb. Es regt außerdem an, dass alle Teams ein gemeinsames Kontextverständnis gewinnen könnten, indem sie einen Data Security Posture Management (DSPM) Knowledge Graph nutzen, um diese Sichtbarkeitslücke zwischen den als kompromittiert bekannten Identitäten und Systemen sowie den betroffenen Daten zu schließen. In der Tat kann ein gemeinsames Betriebsmodell Teams dabei helfen, Produktions- und Backup-Zustände zu vergleichen, saubere Wiederherstellungspunkte zu identifizieren und die Wiederherstellung über Identitäten und zugehörige Workloads hinweg zu koordinieren.

Zudem stellt der Bericht ein hartnäckiges Missverständnis infrage: dass native Plattform-Steuerelemente eine ausreichende Wiederherstellbarkeit bieten. Die Papierkorb- und Aufbewahrungsfunktionen von Entra ID können zwar bei bestimmten Objektlöschungen helfen, stellen aber keine vollständige Wiederherstellungsstrategie dar. Wie im Webinar angemerkt wird, können Aufbewahrungsfristen begrenzt sein – oft auf nur 30 oder 90 Tage –, und einige Richtlinien bieten möglicherweise überhaupt keine sinnvolle Aufbewahrung. Hier spielt das Modell der geteilten Verantwortung (Shared Responsibility Model) eine entscheidende Rolle. Cloud-Anbieter betreiben zwar die Plattform, aber die Kunden bleiben dafür verantwortlich, ihre Identitätskonfigurationen, Berechtigungen, Richtlinien und Datenbeziehungen zu schützen und wiederherzustellen.

Es ist an der Zeit, MTTR, RPO und RTO nicht mehr als bloße Kennzahlen für das Backup-Team zu betrachten, sondern als Themen für die C-Suite und den Vorstand. Wie schnell kann eine Organisation vertrauenswürdigen Zugriff über jedes betroffene System hinweg wiederherstellen? Wie viel Identitäts- und Workload-Drift kann sie tolerieren? Was ist die maximal akzeptable Ausfallzeit oder der maximal hinnehmbare Datenverlust, wenn Authentifizierung, Autorisierung und Geschäftsdaten miteinander verflochten sind?

Zusammenführung von IT-Recovery und Security Operations

Die Beantwortung dieser Fragen erfordert eine engere Zusammenarbeit zwischen der IT-Wiederherstellung und Security Operations. Der zunehmende Einsatz von KI – sowohl intern als auch durch Angreifer – hat dazu geführt, dass CISOs persönlich dafür verantwortlich gemacht werden, wie schnell sich eine Organisation wiederherstellen lässt. Daher sollte ein berechtigtes Interesse an einer engeren Kooperation dieser Teams bestehen. Zudem profitieren SecOps- und Forensik-Teams vom Kontext aus Backups, die Zustände im Zeitverlauf bewahren, sodass nachvollzogen werden kann, was sich wann geändert hat. Recovery-Teams benötigen eine klare Kommunikation mit SecOps, um die Wiederherstellung kompromittierter Zustände zu vermeiden. Das Schaffen einer gemeinsamen Sicht auf die Umgebung – vor dem Vorfall, während der Verweildauer des Angreifers (Dwell Time) und am gewählten Wiederherstellungspunkt – verbessert die Reaktions- und Wiederherstellungszeiten. Mit der Zeit unterstützt eine solche gemeinsame Sicht eine stärker automatisierte, orchestrierte Wiederherstellung. Der erste Schritt ist jedoch einfacher: Binden Sie Recovery-Teams frühzeitig in die Incident-Response-Planung ein und testen Sie die Wiederherstellung als Teil von Incident-Response-Übungen – nicht erst im Nachgang.

Nicht-menschliche Identitäten machen diese Konvergenz noch dringlicher. Dienstkonten, API-Schlüssel, OAuth-Tokens, Service Principals und Anmeldeinformationen für Automatisierungen übersteigen die Zahl menschlicher Identitäten mittlerweile bei Weitem. Das Webinar nennt ein durchschnittliches Verhältnis von etwa 100 nicht-menschlichen Identitäten pro menschlicher Identität; in einigen Organisationen liegt es sogar bei 500:1. Diese Identitäten haben oft keinen Eigentümer, keine Verhaltens-Baseline und keinen menschlichen Benutzer, der verdächtige Aktivitäten melden könnte. Dennoch verfügen sie häufig über privilegierte Zugriffe auf kritischen Plattformen.

Wiederherstellung und Prävention gehen Hand in Hand

Der rote Faden ist klar: Die Kompromittierung von Identitäten ist ebenso sehr ein Wiederherstellungsproblem wie ein Präventionsproblem. Prävention und Erkennung bleiben wichtig, doch wenn Angreifer vom Erstzugriff innerhalb von Sekunden zur lateralen Ausbreitung übergehen können, müssen Organisationen die Geschwindigkeit steigern, mit der sie das Vertrauen in Identitäten und alle abhängigen Workloads wiederherstellen können – ohne erneut Fehler oder Lücken einzuschleusen.

Keine Organisation kann jede Identitätskompromittierung verhindern – aber sie kann im Voraus entscheiden, wie gut sie darauf reagiert. Das bedeutet: die Fähigkeit zu optimieren, genau zu bestimmen und rückgängig zu machen, was sich geändert hat; die sequenzielle Wiederherstellung über jede Plattform hinweg zu verbessern, die von einer kompromittierten Identität betroffen war; und sich mit Security Operations sowie anderen Stakeholdern auf Basis einer gemeinsamen, identitätszentrierten Sicht auf den Vorfall abzustimmen. Organisationen, die diese Fähigkeiten vor einem Angriff aufbauen und erproben, werden ihre Wiederherstellungszeiten drastisch verbessern. Diejenigen, die am Status quo festhalten, werden feststellen, dass sich ihre Wiederherstellungszeiten mit der zunehmenden Verbreitung KI-orchestrierter, autonomer Angriffe verschlechtern. Um den vollständigen Datensatz zu untersuchen, laden Sie den Veeam-Bericht „Identity Under Attack“ herunter und erfahren Sie mehr über den Ansatz von Veeam für Identitätsresilienz und Wiederherstellung.

Über Veeam

Veeam, the Data and AI Trust Company, hilft Organisationen, ihre Daten zu schützen, wiederherzustellen und zu verwalten – unabhängig davon, wo sie sich befinden. Veeam bietet Funktionen für Datenresilienz, Sicherheit und Wiederherstellung, die darauf ausgelegt sind, Unternehmen bei der Aufrechterhaltung des Betriebs zu unterstützen, eine schnelle Wiederherstellung nach Cybervorfällen zu ermöglichen und vertrauenswürdige Grundlagen für KI und die digitale Transformation zu schaffen.