Lassen Sie sich diesen Blog-Artikel von einer Künstlichen Intelligenz vorlesen.
Backups sollen nach einem Cyberangriff den Weg zurück in den Betrieb ermöglichen. Ob das gelingt, zeigt sich erst beim Restore. Denn auch Sicherungen können angegriffen werden oder einen bereits kompromittierten Datenstand enthalten. Eine funktionierende Wiederherstellung braucht deshalb mehr als vorhandene Datenkopien. Sie muss vorbereitet und getestet sein. Wie das in der Praxis aussieht und welche Rolle RPO, RTO, MTPD und geschützte Recovery Points dabei spielen, zeigt dieser Beitrag.
Die Wiederherstellung beginnt vor dem Restore
Ein Backup garantiert noch keinen Wiederanlauf
Auch das Backup kann zum Angriffsziel werden
Welcher Datenstand ist vertrauenswürdig?
Wiederherstellung lässt sich testen
Backup & Recovery in hybriden IT-Umgebungen
Backup & Recovery mit ACP
Die Wiederherstellung beginnt vor dem Restore
Ein Cyberangriff kann zentrale Anwendungen lahmlegen, Daten verschlüsseln oder den Zugriff auf ganze IT-Umgebungen blockieren. Nach einem solchen Angriff müssen geschäftskritische Systeme möglichst schnell wieder verfügbar sein. Dafür braucht es einen vertrauenswürdigen Datenstand und einen klaren Wiederherstellungsplan.
Die Wiederherstellung beginnt allerdings nicht erst mit dem Restore. Bereits während der Untersuchung eines Sicherheitsvorfalls muss geklärt werden, welche Systeme betroffen sind, wie weit sich der Angriff ausgebreitet hat und ob Angreifer weiterhin Zugriff auf die Infrastruktur besitzen. Diese Erkenntnisse beeinflussen, welche Sicherungen für die Wiederherstellung infrage kommen und unter welchen Bedingungen Systeme wieder in Betrieb genommen werden können. Backup & Recovery sind damit eng mit Incident Response und den Maßnahmen zur Absicherung der IT verbunden.
Ein Backup garantiert noch keinen Wiederanlauf
Für eine erfolgreiche Wiederherstellung muss die Sicherung intakt sein. Der gewählte Recovery Point darf keine Hinweise auf eine Kompromittierung aufweisen. Zudem müssen die benötigten Anwendungen in der richtigen Reihenfolge wieder in Betrieb gehen.
Backup und Recovery erfüllen unterschiedliche Aufgaben. Das Backup stellt Datenkopien bereit. Recovery beschreibt den Weg von diesen Kopien zurück zu einem funktionsfähigen IT-Betrieb. Für den Wiederanlauf braucht es eine festgelegte Reihenfolge, die auch kritische Systemabhängigkeiten und mögliche Single Points of Failure (SPoF) berücksichtigt. Ein ERP-System nützt beispielsweise wenig, solange die benötigten Identitäts- und Authentifizierungsdienste fehlen. Ein Recovery-Plan sollte deshalb dokumentieren, welche Anwendungen zuerst wiederhergestellt werden müssen, von welchen Systemen sie abhängen und welche Komponenten bei einem Ausfall den gesamten Wiederanlauf blockieren können.
Aus den Anforderungen der Geschäftsprozesse lassen sich konkrete Wiederherstellungsziele ableiten. Das Recovery Point Objective (RPO) beschreibt den maximal tolerierbaren Datenverlust, während das Recovery Time Objective (RTO) festlegt, innerhalb welcher Zeit ein System wieder verfügbar sein soll. Die Maximum Tolerable Period of Disruption (MTPD), auch als Maximum Acceptable Outage (MAO) bezeichnet, definiert die längste tolerierbare Unterbrechung eines Geschäftsprozesses, bevor die Auswirkungen für das Unternehmen nicht mehr tragbar sind. Das RTO muss entsprechend unterhalb dieser Grenze liegen, damit ausreichend Zeit für die Wiederaufnahme und Stabilisierung des Geschäftsbetriebs bleibt. Bis zur vollständigen Wiederherstellung können im Rahmen der Business-Continuity-Planung festgelegte Ersatzverfahren oder alternative Arbeitsabläufe helfen, besonders kritische Geschäftsprozesse aufrechtzuerhalten.
Auch das Backup kann zum Angriffsziel werden
Wer Zugriff auf die Backup-Infrastruktur erhält, kann unter Umständen Sicherungen manipulieren oder löschen und den Zugriff darauf blockieren. Backup-Systeme und privilegierte Konten müssen deshalb so abgesichert sein, dass eine kompromittierte Produktivumgebung nicht automatisch den Zugriff auf die Sicherungen eröffnet.
Auch die Storage-Ebene gehört in die Sicherheitsarchitektur: Werden dort gespeicherte Recovery Points manipuliert oder gelöscht, kann selbst eine funktionierende Backup-Software keine vertrauenswürdige Wiederherstellung mehr gewährleisten. Ein verbreitetes Modell für die Datensicherung ist die 3-2-1-1-0-Regel: drei Sicherungskopien auf mindestens zwei unterschiedlichen Speichermedien, davon eine an einem externen Standort. Eine weitere Kopie sollte offline oder durch einen Air-Gap vom produktiven System getrennt sein. Die Null steht für fehlerfreie Backups, deren Wiederherstellbarkeit durch regelmäßige Tests und Prüfungen sichergestellt werden soll.
Unveränderliche Sicherungen schützen bestehende Recovery Points innerhalb der festgelegten Schutzfrist vor nachträglicher Veränderung oder Löschung. Wie weit dieser Schutz reicht, hängt von der jeweiligen technischen Implementierung ab. Angreifer mit weitreichenden administrativen Rechten können beispielsweise versuchen, zukünftige Sicherungen zu verhindern oder Schutzkonfigurationen zu verändern. Getrennte Sicherheitsdomänen und restriktiv vergebene Rechte begrenzen diese Risiken.
Welcher Datenstand ist vertrauenswürdig?
Ein technisch intaktes Backup kann Schadsoftware oder bereits manipulierte Daten enthalten. Wird ein solcher Stand ungeprüft zurückgespielt, kann die kompromittierte Umgebung erneut entstehen. Vor dem Restore muss daher geprüft werden, welcher Recovery Point verwendet werden kann. Eine isolierte Recovery-Umgebung erlaubt diese Prüfung außerhalb der betroffenen Infrastruktur. Malware-Scans und Anomalieanalysen können je nach eingesetzter Lösung Hinweise auf kompromittierte Sicherungen liefern. Auch die Suche nach Indicators of Compromise kann dabei helfen.
Die Auswahl des Recovery Points hängt außerdem von den Erkenntnissen aus der Untersuchung des Sicherheitsvorfalls ab. Ist beispielsweise unklar, seit wann ein Angreifer Zugriff auf bestimmte Systeme hatte, muss dieser Zeitraum bei der Wiederherstellung berücksichtigt werden. Auch die Zielumgebung muss überprüft werden. Nach einer weitreichenden Kompromittierung kann es notwendig sein, betroffene Systeme neu aufzusetzen, Zugangsdaten zu erneuern und Sicherheitslücken zu schließen, bevor Anwendungen wieder mit dem Produktivnetz verbunden werden. Die Wiederherstellung muss deshalb eng zwischen Security-Teams und Recovery-Verantwortlichen abgestimmt werden.
Wiederherstellung lässt sich testen
Ein Recovery-Plan lässt sich vor einem Ernstfall überprüfen. Ein erfolgreicher File-Restore genügt dafür nicht. Bei geschäftskritischen Anwendungen sollte getestet werden, ob sie zusammen mit ihren Abhängigkeiten innerhalb der vorgesehenen Zeit wieder in Betrieb gehen. Zum Test gehören auch die organisatorischen Abläufe. Wer legt die Reihenfolge der Systeme fest? Wer kann auf die Backup-Umgebung zugreifen, wenn der zentrale Identity-Service nicht verfügbar oder kompromittiert ist? Wo liegen Runbooks und Zugangsdaten, wenn Teile der gewohnten Infrastruktur ausfallen? Solche Tests zeigen, ob RTO, MTPD und RPO realistisch sind und ob im Recovery-Plan Abhängigkeiten fehlen. Erkannte Schwachstellen lassen sich so beheben, bevor der Plan im Ernstfall benötigt wird.
Backup & Recovery in hybriden IT-Umgebungen
Welche Backup- und Recovery-Architektur geeignet ist, hängt von der vorhandenen IT-Landschaft, den geschäftskritischen Prozessen und den jeweiligen Workloads ab. Hinzu kommen die Anforderungen an die Wiederherstellungszeit, die maximal tolerierbare Ausfallzeit und den zulässigen Datenverlust.
Geschäftskritische Daten liegen heute oft verteilt: im eigenen Rechenzentrum, in der Public Cloud oder in SaaS-Anwendungen wie Microsoft 365. Für Backup und Recovery entstehen damit unterschiedliche Anforderungen an Sicherung und Wiederherstellung. Im Ernstfall müssen auch Verbindungen zwischen diesen Umgebungen berücksichtigt werden. Eine Anwendung kann beispielsweise in der Cloud betrieben werden, während benötigte Identitätsdienste oder andere abhängige Systeme im eigenen Rechenzentrum liegen. Für SaaS-Daten wiederum gelten eigene Sicherungs- und Wiederherstellungswege.
Die im Rahmen einer Business Impact Analysis (BIA) identifizierten kritischen Geschäftsprozesse und ihre Abhängigkeiten bilden eine wichtige Grundlage für den Recovery-Plan. Dieser sollte dokumentieren, wo Anwendungen und Daten liegen, welche Systeme für ihren Betrieb benötigt werden und in welcher Reihenfolge sie über die verschiedenen Umgebungen hinweg wiederhergestellt werden müssen.
Backup & Recovery mit ACP
Von der Analyse bestehender Backup-Infrastrukturen über die Entwicklung geeigneter Recovery-Konzepte bis zur technischen Umsetzung und zum laufenden Betrieb: ACP begleitet Unternehmen bei der Vorbereitung ihrer Wiederherstellung auf unterschiedliche Ausfallszenarien.
In Zusammenarbeit mit etablierten Technologiepartnern entwickelt ACP herstellerübergreifende Lösungen für On-Premises- und Cloud-Umgebungen. Das Leistungsspektrum umfasst die Absicherung geschäftskritischer Daten und Microsoft-365-Umgebungen, den Schutz von Recovery Points, die Planung und Überprüfung von Wiederherstellungsprozessen sowie Managed Backup Services.
Nach einem Cyberangriff müssen verbliebene Angreiferzugänge beseitigt sein, bevor betroffene Systeme wieder in Betrieb genommen werden. Ergänzend zu Backup & Recovery bietet ACP Lösungen für Endpoint Security, Identity Security und Managed Security. Über ein Security Operations Center können sicherheitsrelevante Ereignisse kontinuierlich überwacht und analysiert werden.
Sie möchten Ihre Backup- und Recovery-Strategie überprüfen?
-1.png?width=238&height=69&name=acp_itforinnovators_logo_RGB%20(1)-1.png "ACP Gruppe | IT for Innovators"){kind=logo}
