Themen wie Ransomware, Viren und ungewollter Datenabfluss sind brandaktuell. Sie sind eine ernstzunehmende Bedrohung und Herausforderung für Unternehmen. Die Entwicklung einer Cybersecurity-Lösung ist ein „MUSS“, um Unternehmensbereiche, Daten, Prozesse und Technologien zu schützen.
Stellen Sie sich ein Unternehmen vor, dessen Prozesse größtenteils digitalisiert sind. Die Abläufe sind effizient und hochproduktiv, die Geschäftsleitung ist zufrieden. Eines Morgens jedoch trifft das Unternehmen ein Cyberangriff. Geschockt stellt das Unternehmen fest, dass es an Plänen und Maßnahmen fehlt, wie der reguläre Betrieb schnell wiederaufgenommen werden kann. Im schlimmsten Fall kommt es zum betrieblichen Stillstand.
Der Ransomware-Angriff „WannaCry“ hat vor ein paar Jahren für viel Aufsehen gesorgt. Am 17. Mai 2017 kam es zu einer Cyberattacke, welche über 300.000 Geräte in über 150 Ländern betraf. Zu den Betroffenen zählten auch einige namhafte Unternehmen.
Die Anfälligkeit für „WannaCry" basierte offensichtlich auf ungepatchten Betriebssystemen. Nun gibt es viele Anwendungsfälle, in denen Patches auf Produktivumgebungen per Definition lediglich in großen Zeitabständen umgesetzt werden können. Hier bedarf es nicht einmal höchstaktueller Zero-Day-Exploits und schnell reagierender boshafter Energie, damit sich entsprechende Software dieser Systeme bemächtigt.
Ein IT-Betrieb mit 24/7-Operations, der zum Beispiel lediglich zweimal im Jahr reguläre Wartungsfenster vorsieht und die aktuellen Sicherheitspatches als nicht ausreichend kritisch für eine Betriebsunterbrechung ansieht, ist und bleibt verwundbar für solche Cyberangriffe.
Die Praxis bietet eine einfache und vor allem mehr oder weniger universell einsetzbare Lösungsmöglichkeit: eine architektur- und infrastrukturunabhängige Spiegelung auf Datenbank- und Applikationsebene.
Diese Technologie, die in Zeiten virtueller Maschinen, Storage-Spiegelungen und unterschiedlichster Clustervarianten gerne als veraltet belächelt wird, kann hier eine ihrer nach wie vor vorhandenen Stärken ausspielen: Die logische Unabhängigkeit der zu Grunde liegenden Systemumgebungen.
Die Business-Continuity-Lösung Libelle BusinessShadow arbeitet komplett unabhängig der Produktivumgebung, ohne Shared Server, ohne Shared Storage, kurz: Shared Nothing. Durch die Spiegelung sind die aktuellen Daten ständig auf der Spiegelumgebung physikalisch vorhanden, jedoch können die Systeme losgelöst vom Produktivbetrieb gewartet und auf dem aktuellen Patchstand gehalten werden.
Gelingt ein Cyberangriff mit Ransomware auf die Produktivumgebung und ist dieser aufgrund des niedrigen Patchstandes erfolgreich, wird einfach auf das hochgepatchte Spiegelsystem umgeschaltet und dort innerhalb weniger Minuten weitergearbeitet.
Das Ergebnis: „Der Cyberangriff wurde nicht abgewehrt, lief aber ins Leere.“
Die oben beschriebene Datenspiegelung ist asynchron. Dies hat mehrere Vorteile gegenüber synchronen Spiegelungen, wie sie häufig bei Storage Spiegelungen und Clustern genutzt wird: Zum einen besteht überhaupt erst einmal die Möglichkeit, entspannt Wartungsfenster auf dem Spiegel zu nutzen, da im Gegensatz zur Synchronspiegelung kein Two-Site-Commit benötigt wird.
Zum anderen kommt das Unternehmen auch aus der Synchron-Falle heraus: Hat ein logischer Fehler den produktiven Datenbestand korrumpiert, ist automatisch auch der Datenbestand auf dem Spiegel korrupt.
Im schlechtesten Fall sorgen folgende logische Fehler zum Stopp aller Geschäftsprozesse:
Im noch schlechteren Fall, dass mit fehlerhaften Daten weitergearbeitet und dadurch ein zusätzlicher wirtschaftlicher Aufwand oder auch öffentlicher Imageschaden generiert wird.
Mit Hilfe dieser asynchronen Daten-/Applikationsspiegelung lassen sich beliebige Zeitversätze zwischen Produktiv- und Spiegelsystem definieren: Die aktuellen Produktivdaten liegen bereits physikalisch auf dem Spiegelsystem vor, werden aber in einem Zeittrichter künstlich im Wartestand gehalten und erst mit Ablauf des definierten Zeitversatzes auch logisch aktiviert. Das Spiegelsystem läuft dem Produktivsystem somit aus logischer Sicht permanent um genau diesen Zeitversatz hinterher, hat aber das Delta der Daten bereits physikalisch auf dem eigenen Storage vorliegen und kann dieses auf Wunsch ad-hoc nachziehen.
Tritt also in der Produktivumgebung ein wie auch immer gearteter logischer Fehler auf, entscheidet die organisatorisch verantwortliche Instanz den Umschaltfall, also je nach Unternehmensstruktur und –Prozessen z.B. Application Owner, DR-Beauftragter oder das IT-Management. Aus technischer Sicht wird der bestmögliche Zeitpunkt des Datenbestandes bestimmt und auf dem Spiegelsystem aktiviert.
Die Datenbank bzw. Applikation auf dem Spiegelsystem wird also auf einen beliebigen Zeitpunkt innerhalb des Zeittrichters transaktionsgenau und datenkonsistent produktiv bereitgestellt. Benutzer und andere zugreifende Applikationen melden sich neu an und können mit korrekten Daten weiterarbeiten.
Ein weiterer Vorteil dieser asynchronen Daten- und Applikationsspiegelung: eventuelle Latenzzeiten fallen nicht ins Gewicht, da das Produktivsystem nicht auf das Commit des Spiegelsystems warten muss. Somit sind auch praxistaugliche und wirtschaftlich interessante Disaster-Recovery-Konzepte mit weiten Entfernungen und geringen Volumen- und QoS-Anforderungen an die Netzwerkleitungen zwischen den Systemen möglich. Auch können die Ausfallsysteme nicht nur in eigenen Rechenzentren, sondern z.B. als Service bei einem beliebig weit entfernten „befreundeten Unternehmen“ oder Dienstleister betrieben werden, was vor allem im Mittelstand gehäuft anzutreffen ist.
Die Entfernung zwischen dem Produktiv- und dem Ausfall-Standort wird somit nicht mehr durch die Möglichkeiten der DarkFibre-, Campus- oder Metrocluster-Technologien begrenzt, die im üblichen Fall nur einige Kilometer ausmachen. Asynchrone Spiegelungen lassen sich basierend auf geschäftlichen Anforderungen und je nach Unternehmensstruktur beliebig ausbauen, auch auf unterschiedlichen tektonischen Platten. Somit sind also Disaster Recovery-Konzepte möglich, die auch im Falle großflächiger Disaster greifen und den landes-, regions- oder auch weltweiten IT-Betrieb am Laufen halten.
Zudem befreit die architekturunabhängige Daten-/Applikationsspiegelung aus dem „Single Point of Failure“-Dilemma: Neben der bereits empfohlenen Shared-Nothing-Architektur werden auch unterschiedliche Hardware-Architekturen und -Infrastrukturen in den beteiligten Umgebungen unterstützt. Hier sind neben technologischen mitunter auch wirtschaftliche Interessen zu berücksichtigen.
Bei homogenen Architekturen ist zwar der Maintenance-Aufwand geringer, dafür strahlt das Risiko bei fehlerhaften Treibern, Firmware-Patches oder Controllersoftware nicht nur auf einzelne, sondern auf alle Umgebungen aus. Darüber hinaus spielen auch kaufmännische Gedanken eine Rolle hinsichtlich der Anforderungen an Produktiv- und Notfall-Umgebungen: oft reicht es aus, wenn lediglich das produktive System auf dauerhaft performanten Betrieb ausgelegt ist. Das Ausfallsystem kann auch kleiner ausgelegt werden, es muss lediglich „gut genug“ sein für einen hoffentlich nie eintretenden, und wenn, dann lediglich temporären Einsatz.
Diese Überlegungen resultieren in der Praxis oft darin, dass im Rahmen des üblichen Hardwarezyklus das „alte“ Produktivsystem als neues Ausfallsystem weiterbetrieben wird. So entscheiden sich viele Unternehmen für den Mittelweg, zwischen homogener und heterogener Architektur, in der mindestens zwei Hardwarestandards definiert werden, häufig auch mit Komponenten unterschiedlicher Hersteller.
Sie möchten noch mehr zu verschiedenen Themen aus der IT lesen? Zum Beispiel was Hochverfügbarkeit und Business Continuity genau bedeutet? Dann besuchen Sie gerne unser Libelle IT-Glossar oder folgen Sie uns auf LinkedIn und Facebook.