Ist die DevOps-Philosophie „Build to Fail“ ein Sicherheitsrisiko?

Wenn man Betteridges Gesetz der Schlagzeilen bricht, lautet die kurze Antwort: Ja. Doch wie bei allen Dingen, die heutzutage mit Technologie zu tun haben, ist die ausführliche Antwort etwas komplizierter.

Ich denke, DevOps ist mittlerweile in allen Branchen weit verbreitet. Auch wenn nicht jede Organisation jeden Aspekt dieses Ansatzes übernimmt oder die Prinzipien mit derselben Akribie verfolgt wie beispielsweise Netflix, ist es definitiv eine Sache, die passiert.

Auch wenn dies kein direkter Beweis ist, waren zwei der drei häufigsten Antworten, die wir bei der Frage an die über 3.000 Teilnehmer im Rahmen unseres State of Application Delivery 2018 erhielten, wie sich die digitale Transformation auf ihre Application auswirkt, „Einsatz von Automatisierung und Orchestrierung für IT-Systeme und -Prozesse“ und „Änderung der Art und Weise, wie wir Applications entwickeln (z. B. Umstellung auf agile Methoden)“. Für mich sind beides abgeleitete Reaktionen auf die Übernahme von zumindest Teilen eines DevOps-Ansatzes zur Entwicklung und Bereitstellung von Applications in modernen Architekturen.

Wenn Organisationen also einige der mit DevOps verbundenen Tools und Techniken übernehmen, könnte man davon ausgehen, dass sie auch andere übernehmen. Eine davon könnte sogar lauten (dramatische Musik ertönt): „Auf das Scheitern hin zielen.“

Nun ist dieser Ausdruck etwas ungenau, da niemand herumsitzt und Systeme entwickelt, die so schnell versagen können. Was sie jedoch tun, ist die Entwicklung von Systemen, die ausfallsicher sind. Das bedeutet beispielsweise, dass das System bei einem Absturz einer Instanz (eines Servers) in der Lage sein sollte, die Situation automatisch zu bewältigen, indem es die nicht mehr funktionierende Instanz entfernt und eine neue startet, die ihren Platz einnimmt.

Voilà! Zum Scheitern verurteilt.

Und obwohl dies sicherlich eine wünschenswerte Reaktion ist – insbesondere, wenn ein System stark ausgelastet und beansprucht wird – birgt dieser Ansatz auch ein Risiko, das bedacht und, so ist zu hoffen, anschließend angegangen werden muss.

Denken Sie an die Cloudflare-Sicherheitslücke Anfang 2017 . Cloudflare – das bei seiner eigenen Berichterstattung zu diesem Problem bewundernswert transparent war – weist darauf hin, dass es sich bei dem Problem im Wesentlichen um einen Speicherverlust (der zu einem potenziellen Datenverlust führte) handelte, der durch einen Defekt in einer Erweiterung eines HTTP-Parsers verursacht wurde. Kurz gesagt, ein Fehler verursachte einen Speicherverlust, der zum Absturz von Instanzen führte. Diese Instanzen wurden beendet und neu gestartet, da sie zum Scheitern verurteilt waren.    

Zur Klarstellung: Dies ist kein Beitrag, um Cloudflare wegen eines Fehlers zu verunglimpfen. Als Entwickler habe ich großes Verständnis dafür, dass die eigenen Mängel so öffentlich offengelegt werden. Weniger Verständnis habe ich für Situationen, in denen es kaum darum geht, herauszufinden, warum etwas abstürzt, Speicher verliert oder einfach ganz ausfällt.

Darum geht es im heutigen Beitrag. Denn manchmal verfolgt die DevOps-Philosophie bei ihren Anhängern einen Laissez-faire-Ansatz bei der Untersuchung von Fehlern.

Es ist völlig sinnvoll, auf den Ausfall eines Dienstes/einer App zu reagieren, indem Sie den Dienst beenden und neu starten, um die Verfügbarkeit sicherzustellen – solange Sie anschließend den Absturz untersuchen, um die Ursache dafür zu ermitteln. Apps stürzen nicht ohne Grund ab. Wenn es umfiel, wurde es von etwas gestoßen. In neun von zehn Fällen handelt es sich um einen nicht ausnutzbaren Fehler. Nichts, worüber man einen Blog-Beitrag schreiben müsste. Aber in diesem einen Fall handelt es sich um eine ernste Schwachstelle, die nur darauf wartet, ausgenutzt zu werden, und in den anderen neun Fällen ist der scheinbar vergebliche Aufwand gerechtfertigt. Denn darüber lässt sich ein Blogbeitrag schreiben.

Es ist nicht sinnvoll, es zu ignorieren.

Die Überwachung und Meldung von Fehlern und anderen Problemen ist ebenfalls eine Schlüsselkomponente eines umfassenden DevOps-Programms. Das ist das „S“ in den CAMS, das einen ganzheitlichen DevOps-Ansatz ausmacht: Kultur, Automatisierung, Messung und Teilen. Damon und John (der das Akronym im Jahr 2010 geprägt hat) sprachen nicht nur über Pizza und Bier (obwohl das ein guter Weg ist, das „C“ für „Culture of DevOps“ (DevOps-Kultur) zu fördern). Es geht auch um Daten und den Zustand von Systemen. Es geht darum, sicherzustellen, dass diejenigen Bescheid wissen, die von diesem Wissen profitieren können. Dazu gehört auch ein Systemfehler.

Ein Ausfall – insbesondere ein Absturz – darf nicht unkontrolliert bleiben. Wenn ein System in der Pipeline abstürzt, sollte jemand davon wissen und jemand sollte es überprüfen. Es zu ignorieren stellt ein Sicherheitsrisiko dar. Schlimmer noch: Es handelt sich um ein vermeidbares Risiko, da es um Ihre Umgebung, Ihre Systeme und Ihren Code geht. Sie haben die vollständige Kontrolle und somit keine Ausrede, es zu ignorieren.

Kurz gesagt: „Build to Fail“ kann für Ihre Apps – und Ihr Unternehmen – Sicherheitsrisiken bergen. Die gute Nachricht ist, dass diese Risiken völlig beherrschbar sind, wenn Sie dafür sorgen, dass die Philosophie nicht auf dem Papier als „zum Scheitern verurteilt“ gilt, sondern in der Praxis darauf ausgelegt ist, „einen Fehler zu ignorieren“.

Achten Sie auf Dinge, die abstürzen – auch wenn Sie sie neu starten, um die Verfügbarkeit hoch zu halten. Sie können sich (und Ihr Unternehmen) davor bewahren, aus den falschen Gründen auf Twitter zum Trend zu werden.