Cloud-Security-Grundlagen, Teil 3: Entwickler stärken

In unserem vorherigen Blogbeitrag zu den 5 Grundlagen der Cloud-Sicherheit haben wir uns mit dem Nutzen von Prävention und sicherem Design beschäftigt. Wenn Sie Ressourcenbeziehungen abbilden und während der gesamten Entwicklung Sicherheitsleitplanken durchsetzen, lässt sich die Angriffsfläche erheblich verkleinern. Doch wer setzt diese Leitplanken durch, wenn Ihr Sicherheitsteam mit anderen Aufgaben beschäftigt ist? Hier sollten Entwickler einspringen können. Sehen wir uns also ein weiteres wichtiges Element der Cloud-Sicherheit an: Entwickler stärken. 

2013 schrieben Gene Kim, Kevin Behr und George Spafford das Buch über DevOps: The Phoenix Project. Ziel des Buchs war es, DevOps zu fördern. Doch ihre Arbeit war weitsichtiger, als die Autoren ahnten – besonders im Hinblick auf Cloud-Sicherheit. 

DevOps sollte IT-Betriebsteams besser in den Softwareentwicklungslebenszyklus (SDLC) integrieren und Teams dazu befähigen, bessere Infrastruktur schneller zu erstellen und bereitzustellen. Die IT-Betriebsteams lernten, die Herausforderungen der Entwicklung zu verstehen. Noch wichtiger war vielleicht, dass Entwickler lernten, Anwendungen und Infrastruktur gemeinsam ganzheitlicher zu planen und zu entwickeln.

Wahrscheinlich haben Sie inzwischen auch einen neuen Begriff gehört: DevSecOps. Er ist aus vielen Gründen entstanden, von denen einer besonders hervorsticht. Gene Kim erklärt:

In einem typischen Technologieunternehmen beträgt das Verhältnis zwischen Mitarbeitern in Entwicklung, Betrieb und Informationssicherheit 100:10:1. Ist die Informationssicherheit derart unterbesetzt, kann sie ohne Automatisierung und die Integration von Informationssicherheit in den Arbeitsalltag von Entwicklung und Betrieb nur Compliance-Prüfungen durchführen – das Gegenteil von Security Engineering.

Dieses Verhältnis zeigt im Grunde die oberste Priorität vieler Unternehmen: Software entwickeln – nicht sie absichern. Die Lösung besteht darin, Entwickler zu befähigen, Security Engineering in ihre Entwicklungs-Workflows zu integrieren.

In diesem Artikel stellen wir drei Prinzipien vor, mit denen Cloud-Verantwortliche ihre Entwickler stärken und die Sicherheitslage verbessern sowie die Kosten senken können.

1. Infrastruktur nach Möglichkeit als Code verwalten

Software hat nicht nur die Welt erobert – sie hat auch die Cloud erobert.

Cloud-Infrastruktur kann heute zu 100 % aus Software bestehen. Für Cloud-Kunden ist Cloud-Infrastruktur tatsächlich zu 100 % Software. Mit Infrastructure-as-Code-Tools wie Terraform und AWS CloudFormation können Entwickler Cloud-Umgebungen programmatisch erstellen und verwalten.

Früher war Cloud-Sicherheit – wie die meisten Sicherheitsfunktionen – eine isolierte Aufgabe. Sicherheitsteams waren auf Cloud-Security-Posture-Management-Tools angewiesen, mit denen sie laufende Umgebungen scannten, die von Engineering-Teams bereitgestellt wurden. Anschließend ermittelten die Sicherheitsteams Fehlkonfigurationen, priorisierten sie nach Schweregrad und wiesen DevOps-Teams Aufgaben zur Behebung zu.

Doch ein großes Problem wurde deutlich: Fehlkonfigurationen und andere Sicherheitsprobleme lassen sich erst im Nachhinein erkennen. Eine IBM-Studie aus dem Jahr 2017 nannte einen Grund, warum das problematisch ist: „Die Behebung eines Softwarefehlers, der während der Testphase entdeckt wird, kann bis zu 15-mal mehr kosten als die Behebung desselben Fehlers in der Entwurfsphase.“

Infrastructure as Code verändert die Herangehensweise. Wenn Entwicklungsteams die Konfiguration ihrer Cloud-Umgebungen per Code festlegen können, können Unternehmen den Ansatz „Shift Left“ verfolgen – also Sicherheitsaufgaben früher im SDLC für Cloud-Infrastruktur erledigen.

Sicherheitsprüfungen können dann vor der Bereitstellung stattfinden. Das Ergebnis: weniger Fehlkonfigurationen zur Laufzeit, weniger bereitgestellte Fehler und eine deutlich bessere Sicherheitslage – und das viel früher.

2. Integrationen in Entwickler-Tools priorisieren

Sicherheit hat bei Entwicklern manchmal einen schlechten Ruf, weil Unternehmen sie oft als Reihe zusätzlicher Schritte ans Ende des SDLC setzen. Dadurch müssen Entwickler viel manuelle Arbeit leisten. Fehler und andere Schwachstellen lassen sich in späteren Phasen nicht nur schwerer erkennen, sondern auch schwieriger identifizieren und beheben. Häufig ist dafür eine zeitaufwendige und kostspielige Nacharbeit nötig.

Entscheidend ist, Tools mit umfassenden, relevanten Integrationen zu finden und diese zu nutzen, um Sicherheitsfunktionen in den Entwicklungs-Workflow einzubinden. Ziel ist nicht, die Arbeitsweise von Entwicklern zu verändern, sondern Sicherheit in die Art und Weise einzubetten, wie Entwickler bereits arbeiten.

Konzentrieren Sie sich darauf, Sicherheitsprüfungen in Entwickler-Tools, Quellcode-Repositories und CI/CD-Toolchains zu integrieren. Berücksichtigen Sie bei der Auswahl von Sicherheitstools außerdem sowohl die Bandbreite der verfügbaren Integrationen als auch deren Qualität. Beides ist nötig, damit Sicherheit zu einem festen Bestandteil des Entwicklungs-Workflows wird. Sicherheitstools für Entwickler sind nur dann gut, wenn Ihre Entwickler sie auch nutzen.

3. Entwickler mit hilfreichen Anleitungen unterstützen

DevSecOps bietet mehr als einen zusätzlichen Vorteil. Wenn Entwickler Infrastruktur als Code und eng integrierte Sicherheitstools zur Verfügung haben, können sie ihre Fähigkeiten im Security Engineering kontinuierlich ausbauen. Wenn Sie Entwickler stärken und ihnen die Tools an die Hand geben, diese Möglichkeiten zu nutzen, können ihre Kompetenzen skalieren.

Mit Infrastructure as Code können Entwickler lernen, Umgebungen zu schaffen, die bereits auf architektonischer Ebene sicher sind. Und wenn Unternehmen DevSecOps-Ansätze in ihre Cloud-Sicherheitsprogramme integrieren, erhalten Entwickler beim Programmieren automatisch Sicherheitsfeedback und Anleitungen.

So verbessern Entwickler mit der Zeit ihre Fähigkeiten im Security Engineering und führen während der Entwicklung letztlich weniger Probleme ein. Selbst wenn zur Laufzeit Probleme auftreten, können Entwickler besser erkennen, an welcher Stelle der Infrastruktur sie Korrekturen vornehmen müssen.

Entscheidend ist, dass Sicherheitsteams als interne Tool-Anbieter für Entwickler agieren. Am besten arbeiten sie eng mit Entwicklungs- und Cloud-Engineering-Teams zusammen, um deren Anwendungsfälle und Workflows zu verstehen. Darauf aufbauend können Sicherheitsteams Tools entwickeln, kaufen und integrieren, die hilfreiches, zeitnahes Feedback und konkrete Hinweise zur Behebung liefern.

Früher, schneller, besser, stärker

Je früher Sie Fehlkonfigurationen, Fehler und Schwachstellen beheben, desto besser.

FormHero hatte neben einem zehnköpfigen Entwicklungsteam nur eine Vollzeitkraft für Sicherheit und stellte fest, dass dieses Prinzip stimmt, als das Unternehmen nach Tools suchte, um die Zeit bis zur Behebung zu verkürzen.

Ryan Kimber, Gründer und CEO, sagt: „Wenn Sie Probleme nicht während des Entwickler-Workflows angehen, sondern sie erst in der Qualitätssicherung entdecken und beheben, dauert die Korrektur zehnmal länger.“

Mit Infrastructure as Code, eng integrierten Sicherheitstools und automatischen Entwickleranleitungen können Cloud-Verantwortliche diese zehnfache Verbesserung erzielen und auf ihre Cloud-Umgebungen skalieren – für mehr Sicherheit zu geringeren Kosten.