WannaCry? Nö, WannaSwitch und WannaWeiterarbeiten

Bislang waren Themen wie Ransomware, Viren und ungewollter Datenabfluss in erster Linie Endgeräten vorbehalten. Zuletzt haben aber Ransomware-Varianten wie WannaCry, Petya und Konsorten im betrieblichen Serverumfeld für großes Aufsehen gesorgt. Denn offensichtlich reichen physikalische und logische Zugriffskontrollen sowie die rein bauliche und netzwerktechnische Absicherung auch hoher Data-Center-Klassen nicht aus.

Namen unterschiedlichster Unternehmen aus dem Finanzumfeld, aus der Chemiebranche und vieler anderer Wirtschaftsbereiche, öffentliche und halböffentliche Institutionen geistern als vermutete und bestätigte Opfer durch die Presse. Dass darunter auch Betreiber kritischer Infrastrukturen sind, lässt tief in die bislang vollzogene Beantwortung aktueller Vorgaben wie IT-SiG & Co. blicken. Wobei sich hier die Frage stellt, inwieweit die nach bestem Wissen und Gewissen getroffenen Sicherheitsmaßnahmen überhaupt geeignet sind um den Bedrohungen durch Ransomware gerecht zu werden.

Die Anfälligkeit für WannaCry, Petya und Kollegen basiert 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. Es reicht einfach aus halbwegs aktuelle Lücken, deren Patches erst wenige Wochen oder Monate verfügbar sind, ungehemmt weiter zu nutzen. Ein IT-Betrieb mit 7x24-Operations, der vielleicht zweimal im Jahr reguläre Wartungsfenster vorsieht und die aktuellen Sicherheitspatches als nicht ausreichend kritisch für eine Betriebsunterbrechung ansieht, ist und bleibt offen für solche Angriffe.

7x24-Operations vs. permanentes Patching // Angriffsabwehr vs. entspannte Gegenreaktion

Die Praxis bietet eine vergleichsweise einfache und vor allem mehr oder weniger universell einsetzbare Lösungsmöglichkeit: die architektur- und infrastrukturunabhängige Spiegelung auf Datenbank- und Applikationsebene.

Diese Technologie, die in Zeiten virtueller Maschinen, Storagespiegelungen und unterschiedlichster Clustervarianten gerne als veraltet belächelt wird, kann hier eine ihrer nach wir vor vorhandenen Stärken ausspielen: Die logische Unabhängigkeit der zu Grunde liegenden Systemumgebungen.

Gangster gehen leer aus, trotz erfolgreicher Attacke

Die Spiegelungslösung Libelle BusinessShadow für Non-SAP und SAP®-Systeme arbeitet komplett unabhängig von der Produktivumgebung, ohne Shared Server, ohne Shared Storage, kurz: Shared Nothing. Durch die Spiegelung sind die aktuellen Daten ständig auf der Spiegelseite physikalisch vorhanden, jedoch können die Systeme losgelöst vom Produktivbetrieb gewartet und auf dem aktuellsten Patchstand gehalten werden.

Gelingt ein Angriff 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 weiter gearbeitet. Das Ergebnis: Der Angriff wurde nicht abgewehrt, lief aber ins Leere.

Vorsorge auch gegen klassische Datenkorruption

Die oben beschriebene Datenspiegelung ist asynchron. Dies hat mehrere Vorteile gegenüber synchroner Spiegelungen, wie sie häufig bei Storagespiegelungen 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. Vollzogene Ransomware-Verschlüsselungen oder -Löschungen, Virenbefall, fehlerhafte Anwendungsaktivitäten, fehlerhafte Datenimporte, böswillige manuelle Aktivitäten interner oder externer Nutzer, oder ähnliches, sind logische Fehler, die im schlechten Fall dafür sorgen, dass der Geschäftsprozess zum Stoppen kommt. 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.

Eine Technologie - weitere Anwendungsszenarien: Logische vs. physische vs. infrastrukturelle Herausforderungen

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 DR-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 DR-Konzepte möglich, die auch im Falle großflächiger Desaster 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 durchaus 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 Architekur, in der mindestens zwei Hardwarestandards definiert werden, häufig auch mit Komponenten unterschiedlicher Hersteller.