Lieber WannaSwitch statt WannaCry

Schadsoftware wie Ransomware, Viren und ungewollter Datenabfluss waren bislang vor allem Endgeräten vorbehalten. Zuletzt haben aber Ransomware-Varianten wie WannaCry und Petya auch im betrieblichen Server-Umfeld für großes Aufsehen gesorgt, weil physikalische und logische Zugriffskontrollen sowie rein bauliche und netzwerktechnische Absicherungen auch hoher Data-Center-Klassen offensichtlich nicht ausreichen.

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 schon aus, halbwegs aktuelle Lücken (deren Patches erst wenige Wochen oder Monate verfügbar sind) ungehemmt auszunutzen. Ein Rechenzentrum im 7-x-24-Betrieb, das vielleicht zweimal im Jahr reguläre Wartungsfenster vorsieht und die aktuellen Sicherheits-Patches als nicht ausreichend kritisch für eine Betriebsunterbrechung ansieht, ist und bleibt offen für solche Angriffe.

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, ob die nach bestem Wissen und Gewissen getroffenen Sicherheitsmaßnahmen überhaupt geeignet sind, den Bedrohungen durch Ransomware gerecht zu werden. Zwei Spannungsfelder gilt es aufzulösen:

• 7-x-24-IT-Betrieb vs. permanentes Patching
• Angriffsabwehr vs. entspannte Gegenreaktion

Dafür gibt es einen vergleichsweise einfachen – und vor allem mehr oder weniger universell einsetzbaren Ansatz: die architektur- und infrastrukturunabhängige Spiegelung auf Datenbank- und Applikationsebene.

Diese Methode, die in Zeiten virtueller Maschinen, Storage-Spiegelungen und unterschiedlichster Clustervarianten gerne als veraltet belächelt wird, kann gerade auch bei Ransomware-Attacken ihre Stärke ausspielen: die logische Unabhängigkeit der zugrunde liegenden Systemumgebungen.

Gangster gehen leer aus, trotz erfolgreicher Attacke

Das Opfer einer Ransomware-Attacke wollte ein Libelle-Anwender nicht spielen. Deshalb übte dieser den Ernstfall. (Das Unternehmen ist ein namhafter Lebensmittelhersteller und darf leider nicht genannt werden, weil diese Branche permanent Erpressungsversuchen und anderen Attacken ausgesetzt ist.)

Der Unternehmenserfolg dieser Firma basiert auf der Produktqualität und auf der 7-x-24-Verfügbarkeit einer großen Zahl von MS-SQL-Datenbanken. Diese permanent zu patchen, dafür ständig den Betrieb zu unterbrechen, ist im Unternehmensalltag nicht realisierbar.

Deshalb hat man sich für einen anderen Weg entschieden: Die produktiven Systeme laufen „as is“. Die aktuellen Daten werden per Daten- und Applikationsspiegelung permanent von der Produktiv- auf eine sogenannte Spiegelumgebung übertragen.

Es wird auch regelmäßig und aktuell gepatcht, jedoch nicht in den produktiven Umgebungen, sondern auf den Spiegelsystemen. 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 Spiegelseite physikalisch vorhanden, jedoch können die Systeme losgelöst vom Produktivbetrieb gewartet und auf dem aktuellsten Patch-Stand gehalten werden.

Gelingt ein Angriff mit Ransomware auf die Produktivumgebung und ist dieser aufgrund des niedrigen Patch-Standes erfolgreich, wird einfach auf das hochgepatchte Spiegelsystem umgeschaltet und dort innerhalb weniger Minuten weitergearbeitet. 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 synchronen Spiegelungen, wie sie häufig bei Storage- und Clusterlösungen genutzt werden: 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 das Unternehmen stillsteht.

Im noch schlechteren Fall, dass mit fehlerhaften Daten weitergearbeitet und dadurch ein zusätzlicher wirtschaftlicher Aufwand oder auch öffentlicher Imageschaden generiert wird.

Mithilfe dieser asynchronen Daten- und 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. SAP-Verantwortlicher, Application Owner, DR-Beauftragter oder IT-Leiter.

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 ist die deutliche Reduktion der Latenzzeiten, da das Produktivsystem nicht auf das Commit des Spiegelsystems warten muss.

Somit sind auch praxistaugliche und wirtschaftlich interessante DR-Konzepte (Desaster Recovery) über große Entfernungen und mit geringen Volumen- und QoS-Anforderungen (Quality of Service) an die Netzwerkleitungen zwischen den Systemen möglich.

Herausforderungen: logisch, physisch, infrastrukturell

Die Ausfallsysteme können 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- und 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 Architektur, in der mindestens zwei Hardwarestandards definiert werden, häufig auch mit Komponenten unterschiedlicher Hersteller.