Die DevOps-Pipeline absichern

Nichts ist absolut sicher, und es wird noch lange dauern, bis künstliche Intelligenz oder Automatisierung auch nur annähernd an menschlichen Einfallsreichtum und Witz herankommen. Doch Automatisierung ist ausgesprochen gut und schnell darin, bekannte Faktoren zu testen und unermüdlich verschiedene Türen auszuprobieren, bis sie eine unverschlossene findet.

7.11.2018 Göteborg, Schweden – Ein altes Sprichwort besagt, dass das Beheben eines Bugs 100 $ kostet, im Test 200 $ und 5.000 $, wenn er die Produktion erreicht hat. Es ist immer noch derselbe Bug, doch später hat er größere Auswirkungen und es sind mehr Personen beteiligt, wenn er an den Anfang der Pipeline zurückgeschoben wird. Das Hauptproblem bei Sicherheitslücken ist, dass die schlimmsten vertrauliche Daten preisgeben und euren Ruf sowie euer Geschäft ruinieren können – und zudem strafrechtliche Folgen haben können.

Für verschiedene Situationen gibt es bewährte Vorgehensweisen: von der Prüfung der Tools und des Stacks über die Absicherung der Application Supply Chain bis hin zur Erkennung von Assets, Designpatenten und mehr. Das beginnt ganz am Anfang der Pipeline mit JUnit-Tests und Komponentenanalyse und reicht bis zu kontinuierlichen Schwachstellenscans, Intrusion Detection und Übungen zur Incident Response. Diese Maßnahmen sollten umgesetzt sein – und nicht nur als manuelle Widgets, die wie Weihnachtsbäume in Las Vegas blinken und die niemand beachtet. Außerdem braucht es Quality Gates. Es sollte absolut keinen Grund geben, dass ein mangelhafter Build bis ans andere Ende der Pipeline gelangt.

Wir verfügen bereits über verschiedene Tools. Falls ihr noch keine automatisierten Sicherheitstests eingesetzt habt, solltet ihr euch ansehen, was heutzutage möglich ist. Da die Softwarequalität steigt und das Bewusstsein zunimmt, erfolgen immer mehr Angriffe über Seitenkanäle, statt dass jemand an die Haustür klopft. Den Insider-Angriffsvektor sollte man leider nie unterschätzen – ob absichtlich oder nicht. Deshalb gehen auch jeden Tag so viele mobile Geräte verloren, auf denen unsere dunkelsten Geheimnisse gespeichert sind. Und wenn ihr Dinge testet, dann testet sie realistisch: Keine Methode ist zu rigoros. Den Angreifern ist es egal, ob etwas außerhalb des Scopes lag oder erst für den nächsten Sprint vorgesehen war. Verschlüsselung für ruhende Daten zu aktivieren, in denen eure Geheimnisse liegen, ist wie eine Feuerversicherung abzuschließen, nachdem das Haus bereits abgebrannt ist.

Kurz gesagt: Vorausgesetzt, ihr habt bereits Tools im Einsatz – befolgt ihr Best Practices oder nutzt ihr tatsächlich all die kleinen, großartigen Funktionen, die einen Unterschied machen können? Nehmen wir an, wir alle verwenden irgendeine Form der Versionsverwaltung. Nutzt ihr dafür Multi-Faktor-Authentifizierung? Habt ihr über Branch Protection, signierte Commits, eine möglichst geringe Anzahl von Eigentümern, die automatische Prüfung inaktiver Konten, ein Konto-pro-Projekt-Protokoll zur Begrenzung der Auswirkungen bei einer Kompromittierung sowie die Trennung von Rollen und Aufgaben nachgedacht? So erhalten diese wunderbaren Drittanbieter-Tools nicht viel zu viele Berechtigungen. Vielleicht habt ihr auch alle Drittanbieter auf eine Allowlist gesetzt?

Ja, es gibt vieles zu bedenken. Kommt eine weitere Ebene zur Prüfung der Supply Chain hinzu, geht es auch darum, Signaturen und Zertifikate von Paketen, Dockerfiles und vielen weiteren Dingen auf ihre Integrität zu prüfen. Die Messung der Baseline-Compliance bedeutet außerdem, veraltete Algorithmen und Chiffren aus dem Release zu entfernen – zusätzlich zu Konfiguration und Abhängigkeiten. Im Grunde geht es um sehr einfache Dinge: Entwickelt keine großartige Software, nur um sie durch schlechte Komponenten, mangelhafte Konfiguration oder fehlende Updates für aktuelle Bugs und Sicherheitslücken zu ruinieren. Andernfalls ist ein Teil eurer Arbeit an großartiger Software verschwendet. Geht zuerst die leichteren Themen an. Durch Automatisierung entfallen Wiederholungen und ihr werdet deutlich produktiver. Ihr wollt nicht das nächste Equifax sein. Dennoch solltet ihr immer Notfallpläne haben: Es geht nicht darum, ob ihr gehackt werdet, sondern wann. Plant und entwerft eure Architektur so, als wäre der Ernstfall bereits eingetreten.

Sehr vieles davon lässt sich automatisieren. In eurer Pipeline, Orchestrierung und ähnlichen Bereichen sollte es immer darum gehen, proaktive Maßnahmen umzusetzen und eine gute Sicherheitslage aufrechtzuerhalten. Wenn ihr bei null anfangt, identifiziert Geheimnisse, die bei Providern oder in Vaults gespeichert werden sollten – weit entfernt von eurem Code – und automatisiert die Aktualisierung dieser Anwendungen und ihrer Plattformen. Die Anwendung von Least Privilege und einer Zero-Trust-Architektur in Design und Implementierung bringt ebenfalls viele Vorteile. Least Privilege stellt zunächst das Offensichtliche sicher. Doch wenn etwas schiefläuft, hilft es auch dabei, im Ernstfall die richtigen Bereiche abzuriegeln – selbst wenn das sehr schwierig ist und wahrscheinlich Kollateralschäden verursacht.

Zero Trust als Konzept gibt es schon lange, doch für moderne Architekturdesigns ist es weiterhin gültig. Früher gab es das sichere LAN und draußen das große, böse WAN. Hinter der äußeren Firewall wurde Systemen oft leichtfertig implizit vertraut. Vieles im Leben ist eine Illusion – manches positiv, manches negativ. Dem Datenverkehr in eurem LAN zu vertrauen, ist eine negative Illusion. Dasselbe Verteidigungsprinzip sollte auch beim Softwaredesign gelten. Denkt defensiv und setzt nichts voraus. Geht immer von Zero Trust aus und authentifiziert und prüft ausnahmslos alles. Ein häufiger Fehler ist, nicht alles zu erfassen. Was ihr nicht sehen könnt, existiert nicht. Und was ihr nicht seht, könnt ihr erst recht nicht analysieren, korrelieren oder beheben.

Außerdem ist es in der gesamten Entwicklung sehr wichtig, das Rad nicht neu zu erfinden. Ob ihr eine OAuth-Komponente oder ein API Gateway braucht: Es gibt bereits hervorragende Lösungen. Mit euren begrenzten Ressourcen solltet ihr nicht versuchen, diese nachzubauen, denn eure Fähigkeit, sie über den gesamten Lebenszyklus hinweg zu entwickeln, zu patchen und zu unterstützen, ist höchstwahrscheinlich deutlich geringer als beispielsweise die von Google. Folgt einfach diesen Best Practices, um gut zu starten. Setzt auf zentrales Logging, schützt Logs genauso sorgfältig wie eure Daten und scannt euren Traffic aktiv auf verdächtige Signaturen von Angreifern, Malware und statistische Anomalien. Denkt daran: Egress-Traffic ist genauso wichtig wie Ingress-Traffic. Genau wie bei einem guten JUnit-Test ist ein positiver Test genauso wichtig wie ein negativer – andernfalls habt ihr nur eine Seite der Medaille abgedeckt. Seid kreativ.

Lasst euch nicht überfordern: Es scheint zwar eine ganze Menge zu sein, doch letztlich läuft alles auf sehr einfache Dinge hinaus. Und zu guter Letzt: Die Compliance mit irgendeinem Framework XYZ bedeutet nicht automatisch Sicherheit. Angreifer interessieren sich keinen Deut für Standards und Zertifizierungen. Automatisiert eure Sicherheitstests und Kontrollen, damit ihr euch auf wichtigere Dinge konzentrieren und nachts etwas ruhiger schlafen könnt.