Alles ist verbunden – Multiple Single Points of Failure

Von großen – im Sinn von weitreichenden – Cloudausfällen war an dieser Stelle und in den Weiten des Internets in letzter Zeit häufig zu hören. Denn je mehr der Markt reift (sprich, je mehr Unternehmen relevante Teile ihrer Infrastruktur in die Wolke verlagern) und je mehr sich der Kuchen des Cloud-Geschäfts im Wesentlichen auf eine Handvoll großer Cloudanbieter und ein paar Dutzend Security-Services-Anbieter verteilt, desto größer kann der Impact eines einzelnen Zwischenfalls sein. Nun war Cloudflare an der Reihe, dies am eigenen Astralleib zu erfahren: Ein harmlos erscheinender regulärer Ausdruck, der weltweit bösartiges „Inline“-JavaScript herausfiltern sollte, brachte die Prozessorlast sämtlicher Filter auf 100 %, sodass bei den vielen Cloudflare-Kunden für eine halbe Stunde nichts mehr ging. Dann war das Problem erkannt und die Funktion gekillt – im Gegensatz zu Google im Mai konnte Cloudflare die Managementinterfaces nämlich ohne Probleme erreichen. Hatte der DDoS- und Websecurity-Spezialist aus Kalifornien schlampig gearbeitet? Ja und nein, die neue Funktion war zwar per Knopfdruck sofort weltweit, aber immerhin nur im Testmodus ausgespielt worden, der nichts hätte blocken sollen. <Ironie>Dass die Komplexitätstheorie bei den seit Jahrzehnten als mögliche Ressourcenmonster verrufenen RegExen einen Strich durch die Rechnung machen würde, konnte ja niemand ahnen … </Ironie>

In einer überraschenden Fügung des Schicksals hätte der Ausfall beinahe ein längst in eine dunkle Flasche verbanntes Monster wiederbelebt: 2017 hatte der junge Malware-Forscher Marcus “MalwareTech” Hutchins in einem heldenhaften Einsatz (siehe Lesetipps am Ende dieses Digests) per „Sinkhole“, also eine geistesgegenwärtig reservierte Domain, der Welt den größten Teil der ersten WannaCry-Angriffswelle erspart. Diese Sinkhole-Domain erhält bis heute riesige Mengen an Anfragen von schlummernden WannaCry-Infektionen, die nachfragen, wann sie denn nun endlich losschlagen sollen.Später wurde ebendiese pro bono (und natürlich für den Werbeeffekt) von Cloudflare übernommen – und war seither nie down. Um ein Haar hätte der Cloudflare-Ausfall also ein Heer von Schläfern erweckt, die Schäden von hunderten Millionen hätten verursachen können. Glücklicherweise genügte die immerhin noch ausgelieferte Fehlermeldung (HTTP-Code 502), um die Viren zu beruhigen. Sie schlummern also weiter auf unseren ungepatchten Systemen und laben sich an unseren technischen Altlasten …

HiSolutions Research

Paging Münchhausen – Cloud braucht Cloud

Am 2. Juni standen weite Teile der Google Cloud für bis zu vier Stunden still. Dass Google damit die Jahres-SLAs gerissen hat, ist nur ein Teil des Problems, schließlich kamen und kommen Downtimes auch in selbstbetriebener IT immer wieder vor. Bedenklich ist vielmehr, dass es zu einem derart langen länderübergreifenden Ausfall kommen konnte, obwohl Google derart viel in Redundanz, Notfallplanung und Desaster Recovery investiert. Und zwar technisch wie konzeptionell. Nach ersterem Maßstab hat sich der Betreiber nicht viel vorzuwerfen, denn der Root-Cause war eine schwer vorauszusehende Interaktion drei verschiedener Bugs. Das Problem war schnell erkannt, verstanden und die Lösung schnell entworfen.

Allerdings gibt es zwei große Lessons Learned hier (für Google wie für die Kunden der großen Cloudanbieter): Erstens, die komplexen internen Abhängigkeiten der Gesamtsysteme, die Cloud-Dienste/-Rechenzentren/-Angebote darstellen, sind noch nicht ausreichend verstanden. Denn erst beim Incident-Handling fiel auf, dass man zur Behebung des Problems die, *tada*, Google Cloud benötigt, welche ja gerade nicht verfügbar war. Es fehlt also noch die Fähigkeit eines Baron Münchhausen, sich am eigenen Schopf aus dem Sumpf zu ziehen, sogenanntes Bootstrapping, im Energiesektor als Schwarzstartfähigkeit bekannt. Eine solche vorrätig zu halten, kostet Geld, was dem Kostendruck in der Cloud zuwiderläuft.

Das zweite Thema ist noch eine Ebene prinzipieller: Die großen Kosten- und Effizienzvorteile erzielt man im Cloud-Computing durch weitgehende Automatisierung – und die braucht als Basis Mono- oder zumindest Oligokulturen. Wie in der industriellen Landwirtschaft steigt mit der Effizienz hierbei auch das Risiko, dass ein einzelner Schädling/eine einzelne Schwachstelle/Bug/Fehlkonfiguration ganze Landstriche verwüsten und Hungersnöte auslösen kann. Meist wird man dies mittels viel Chemie unter Kontrolle halten können – was aber wieder nur das Risiko konzentriert und vertagt.

Sicher ist: Das dicke Ende kommt noch – und wir tun uns auf Dauer keinen Gefallen, wenn wir die Auseinandersetzung damit einfach nur in die Zukunft verschieben.

Zum Thema Cloud Security empfehle ich unseren aktuellen Webcast „Wege in die Cloud – aber sicher!”