Wie Chaos Engineering Ihr Netzwerk härtet

Die alte Weisheit "never change a running system" greift nicht, wenn es um Chaos Engineering geht. Hier lautet das Motto vielmehr: "Versuchen wir, alles kaputt zu machen - einfach um zu sehen, was passiert."

Die "Chaos Community" definiert Chaos Engineering als "die Disziplin, mit einem System zu experimentieren, um Vertrauen in dessen Fähigkeit zu schaffen, auch turbulenten Bedingungen in der Produktion standzuhalten". Im Wesentlichen setzen Chaos-Engineering-Praktiker Systeme dabei einem Stresstest aus und vergleichen anschließend die gewünschten mit den tatsächlichen Ergebnissen. Das Ziel: die Resilienz zu erhöhen.

When your app passes chaos engineering tests pic.twitter.com/Q3retR0BP3

— memenetes (@memenetes) April 26, 2021

Warum Chaos Engineering Sinn macht

Für Netzwerk-Profis, deren Berufsalltag darin besteht, das Netzwerk unter allen Umständen am Laufen zu halten, mag die Idee, es ansichtlich zum Absturz zu bringen, unter Umständen absonderlich erscheinen. David Mooter, Senior Analyst bei Forrest Research, sieht im Chaos Engineering jedoch die logische Konsequenz des Umstands, dass Netzwerke zunehmend über Multi-Cloud-Plattformen verteilt sind - und immer häufiger zum Ziel von Cyberangriffen werden: "Verteilte Systeme sind für uns zu komplex, um sie vollständig zu verstehen. In der Konsequenz bedeutet das, dass sie sich unvorhergesehen verhalten werden. Moderne Resilienz-Bemühungen müssen auf dieser Annahme fußen - wir können nicht vorhersagen, wie sich unsere Systeme verhalten werden."

"Netzwerke sind nicht immer zuverlässig", weiß Nora Jones, Gründerin und CEO des Sicherheitsanbieters Jeli und Chaos-Engineering-Pionierin bei ihrem früheren Arbeitgeber Netflix. "Das Konzept, Netzwerke zu testen, ist das gleiche, das bei CPUs und anderen Dingen zum Einsatz kommt. Es geht darum, ungünstige Ereignisse zu simulieren und dabei bislang unbekannte Variablen aufzudecken. Chaos Engineering unterstützt das Continuous-Verification-Prinzip. Dieses geht davon aus, dass es eine hundertprozentige Zuverlässigkeit nicht gibt. Im Ergebnis kämpft man ständig gegen die Zeit und muss vorausdenken. Das erfordert auch eine neue Herangehensweise an das Thema Operations."

Mooter berichtet von einem Beispiel für Chaos Engineering auf Basis der Fehlkonfiguration eines Ports: "Ich habe mit einem Unternehmen zusammengearbeitet und ein einfaches Chaos-Experiment durchgeführt. Die Hypothese war, dass ein falsch konfigurierter Port von der Firewall erkannt, blockiert und anschließend protokolliert werden würde, um das Sicherheitsteam zu alarmieren."

Nachdem der falsch konfigurierte Port in regelmäßigen Abständen in die Produktion eingeführt wurde, habe sich gezeigt, dass die Firewall nur in der Hälfte der Fälle wie erwartet reagiert habe. In den anderen Fällen sei es jedoch nicht gelungen, den Port zu blockieren. Schuld sei letztendlich ein sekundäres Cloud-Konfigurations-Tool gewesen, wie Mooter offenbart: "Das Problem war, dass das zweite Tool das Sicherheitsteam nicht alarmierte, so dass die Vorfälle unbemerkt blieben. Das Experiment zeigte also nicht nur einen Fehler in der Firewall auf, sondern ließ auch Mängel erkennen, wenn es um die Fähigkeit des Security-Teams ging, einen Vorfall zu erkennen und darauf zu reagieren."

Chaos mit Methode

Chaos Engineering wäre alles andere als sinnvoll, wenn in diesem Rahmen wahllos bisher unbekannte Fehler in das Produktionsnetz eingebracht werden und dieses tatsächlich in seiner Performance einschränken oder gar zum Zusammenbruch bringen würden. Die Chaos-Engineering-Methodik sei jedoch sehr spezifisch und werde im Regelfall zunächst auf Nicht-Produktionsumgebungen angewandt, erklärt Mooter. "Es geht nicht darum, wahllos Dinge zu zerstören, sondern darum, auf intelligente Weise ein inakzeptables Risiko zu identifizieren, eine Hypothese darüber aufzustellen und diese im Rahmen eines Chaos-Experiments zu validieren."

Wie bei einem wissenschaftlichen Experiment sollte die Hypothese falsifizierbar sein, meint Mooter. "Jedes Mal, wenn ich das Experiment erfolgreich durchführe, gewinne ich mehr Vertrauen, dass meine Hypothese korrekt ist. Wenn es scheitert, habe ich neue Informationen über mein System entdeckt, mit denen ich meine falschen Annahmen korrigieren kann." Um dabei sicher sein zu können, dass alles, was schiefläuft auch auf den zuvor absichtlich eingeführten Fehler zurückzuführen ist, empfehle es sich, mit einer Test- und einer Kontrollgruppe zu arbeiten, so der Forrester-Analyst.

Einer der Hauptvorteile dieses Ansatzes bestehe darin, Probleme aufdecken zu können, bevor sie Auswirkungen auf das Business haben können, erklärt der Experte: "Nehmen wir an, Ihr Zahlungsdienst ist aufgrund obskurer Bedingungen offline. Wollen Sie das lieber in einer kontrollierten Umgebung feststellen, wo Sie den Fehler sofort abstellen können und die Mitarbeiter die Situation aktiv überwachen können - oder ziehen Sie es vor, dass der Fehler unerwartet an einem Freitagabend auftritt, wenn Ihre OT-Spezialisten gerade im Urlaub sind?"

Sie wollen weitere interessante Beiträge rund um das Thema IT-Sicherheit lesen? Unser kostenloser Newsletter liefert Ihnen alles, was Sicherheitsentscheider und -experten wissen sollten, direkt in Ihre Inbox!

Jetzt CSO-Newsletter sichern

Chaos Engineering: Best Practices

Unternehmen, die mit Chaos Engineering experimentieren wollen, können auf mehrere Best Practices zurückgreifen:

• Anwendungsentwickler einbeziehen: "Bei komplexen, verteilten Architekturen haben die Entwickler kein gutes Gespür für die Grenzen ihrer Anwendungen. Wenn Chaos Engineering Teil der Software Delivery wird, werden die Entwickler zunehmend Beispiele dafür entdecken, die ihre Annahmen widerlegen. So wird es zur Gewohnheit, die eigenen Annahmen proaktiv zu hinterfragen", meint Forrester-Mann Mooter.

• Kommunikation verbessern: "Bei Netflix, das seine eigenen Chaos-Engineering-Tools entwickelt und sie später quelloffen zur Verfügung gestellt hat, war die Grundidee, eine Zwangsfunktion für Ingenieure zu schaffen, um möglichst widerstandsfähige Systeme zu bauen", reüssiert Chaos-Pionierin Jones. "Allen war bewusst, dass Server zufällig abgeschaltet werden würden - und das System musste damit umgehen können. Doch damit nicht genug: Die Leute mussten natürlich auch wissen, mit welchen Parteien sie kommunizieren müssen, wenn es dazu kommt."

• Die richtigen Experimente wählen: "Netzwerk-Chaos-Experimente sind wohl die beliebtesten Tests, um Vorfälle zu modellieren, die in den komplexen verteilten Systemen von heute zu ungeplanten Ausfallzeiten führen", erklärt Uma Mukkara, Head of Chaos Engineering beim Tool-Anbieter Harness. Unternehmen könnten Chaos-Engineering für spezifische Experimente nutzen, etwa um die Latenz im Netzwerk zwischen zwei Diensten zu validieren oder Resilienz-Mechanismen im Code zu überprüfen.

• Sicherheitsteams einbinden: "Chaos Engineering kann auf jedes komplexe, verteilte System angewendet werden - auch auf die Netzwerksicherheit", unterstreicht Mooter. "Im Security-Bereich muss man davon ausgehen, dass Kontrollen versagen, egal wie sehr man sich um Perfektion bemüht."

Chaos Engineering: Tipps für die Praxis

Chaos-Engineering kann Risiken mit sich bringen, wie z. B. den Ausfall eines Netzwerks während einer geschäftigen oder auch nicht so geschäftigen Zeit. Deshalb empfiehlt es sich, sich an folgenden Richtlinien zu orientieren:

1. Chaos-Engineering-Projekten Grenzen setzen

"Ich glaube nicht, dass jeder Ingenieur die Rechte haben sollte, Dinge zu zerstören", offenbart Jones. "Es handelt sich um eine Disziplin - und zwar eher um eine menschliche als um eine Tool-Disziplin. Die Einführung einer angemessenen Kultur der psychologischen Sicherheit und des Lernens ist eine Voraussetzung für effektives Chaos Engineering."

2. Von bestehenden Incident-Response-Systemen lernen

Jones empfiehlt Unternehmen, sich die Zeit zu nehmen, um sicherzustellen, aus bereits erlittenen Vorfällen zu lernen: "Wenn Sie Chaos Engineering in Erwägung ziehen, gibt es garantiert eine Fülle von Informationen zu historischen Vorfällen. Erforschen Sie diese und decken Sie Muster auf - das wird Ihnen dabei helfen, zu verstehen, welche Art von Experimenten in ihrem Fall am besten geeignet ist."

3. Exit-Strategie zurechtlegen

Wichtig sei zudem, sich die Möglichkeit offenzuhalten, ein Chaos-Engineering-Projekt schnell zu beenden, meint Forrester-Analyst Mooter. "Jedes Chaos-Engineering-Experiment sollte so konzipiert sein, dass der 'Explosionsradius' möglichst minimal ist, falls etwas schief geht. Das kann auf Infrastruktur-, Anwendungs- oder Business-Ebene geschehen. Auf der Infrastrukturebene sollte der Fehler beispielsweise auf eine begrenzte Anzahl von Verbindungen beschränkt werden."

4. Chaos-Engineering-Programm föderieren

"Zentralisierte Chaos-Engineering-Teams lassen sich nicht skalieren", konstatiert der Forrester-Mann: "Wenn die Delivery Teams nicht direkt involviert sind, können sie kein Gespür für Resilienz entwickeln. Durch eine Zentralisierung lassen Sie sich den Vorteil der Kulturveränderung entgehen. Eine 'Wir-gegen-Die'-Dynamik zwischen den Chaos-Engineering- und Delivery-Teams zu schaffen, macht keinen Sinn."

5. Kultur verändern

Unternehmen, die Chaos Engineering einsetzen, müssten eine Kultur des Experimentierens schaffen, empfiehlt Mukkara. "Kein System ist zu 100 Prozent zuverlässig. Ihre Kunden erwarten jedoch, dass es verfügbar ist, wenn sie es brauchen. Sie müssen also ein System aufbauen, das häufigen Ausfällen standhalten kann - und Ihr Team darin schulen, auf unbekannte Ausfälle zu reagieren. Der erste Schritt besteht darin, mit Hilfe von Experimenten herauszufinden, wie sich das System verhält und funktioniert. Anschließend können über den Zeitverlauf immer wieder Optimierungen einfließen."

Dabei appelliert die Chaos-Engineering-Expertin auch an die Unternehmen, für Sichtbarkeit und Transparenz zu sorgen: "Berichten Sie den verschiedenen Interessengruppen über gefundene Probleme und die Zuverlässigkeitsverbesserungen, die Sie an Ihrem System vornehmen. Teilen Sie Ihre Erkenntnisse, um das Business an Bord zu holen." (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Network World.