The Secure Developer: DevSecOps in Azure mit Microsofts Victoria Almazova

Im Februar dieses Jahres gründete Snyk eine neue, herstellerneutrale und sicherheitsorientierte Lerngemeinschaft: The Secure Developer. Snyk möchte Entwickler dabei unterstützen, während des gesamten Entwicklungsprozesses eine Sicherheitsmentalität zu etablieren. Die Community The Secure Developer bietet genau dafür den richtigen Ort: Hier lernen Sie auf zugängliche und positive Weise Best Practices für Sicherheit von Experten kennen.

In den vergangenen sieben Monaten hat The Secure Developer alle zwei Wochen virtuelle Sessions veranstaltet. Die Themen reichten von Microservice-Sicherheit bis hin zu proaktiven OWASP-Top-10-Maßnahmen.

Falls Sie den Nutzen einer virtuellen Session anzweifeln, möchte ich Ihnen anhand einer kürzlich abgehaltenen Session von The Secure Developer einen kurzen Einblick geben. Hoffentlich überzeugt Sie das, bei unserer nächsten virtuellen Session dabei zu sein.

DevSecOps in Azure mit Microsofts Victoria Almazova

Victoria Almazova ist Cloud Solution Architect bei Microsoft. In ihrer Rolle unterstützt sie Menschen bei der Planung, Architektur und Bereitstellung ihrer Projekte in der Azure-Cloud. Dabei behält sie stets die Sicherheit im Blick – genau darüber sprach sie in ihrer letzten Session. Victoria erläuterte ihre Vorgehensweisen für:

• die Implementierung von Azure-Sicherheit auf Abonnementebene

• die Entwicklung sicherer Anwendungen

• die sichere Bereitstellung Ihrer Anwendungen

• regelmäßige Compliance- und Sicherheitsscans in der Produktionsumgebung

Als DevOps erstmals populär wurde, stand Victoria dem Konzept skeptisch gegenüber, weil es den Anschein hatte, als würde Sicherheit dabei an den Rand gedrängt. Schließlich überzeugte sie jedoch die Idee von DevOps, da sie die Möglichkeit bot, Sicherheit ganzheitlicher zu integrieren. Victoria definierte DevOps als Zusammenspiel von Menschen, Prozessen und Technologien, das die kontinuierliche Bereitstellung von Mehrwert für Endnutzer ermöglicht. Ob man den Modebegriff „DevSecOps“ nun mag oder nicht: Sicherheit kann tatsächlich am gesamten DevOps-Prozess von Anfang bis Ende mitwirken und so das Endprodukt noch wertvoller machen.

Sicherheit in einen DevOps-Prozess zu integrieren, kann zunächst überwältigend wirken. Deshalb nennt Victoria einige Ansatzpunkte für den Einstieg.

Die Infrastruktur kann ein guter Ausgangspunkt sein. Victoria empfiehlt, Azure-Abonnements nach Projekt und Umgebung zu strukturieren. So lassen sich für jedes Projekt und jede Umgebung die richtigen Berechtigungen und Einstellungen sicherstellen. Wichtig ist auch, dass Richtlinien transparent und proaktiv sind. Außerdem schlug Victoria vor, das Azure Security Center vom ersten Tag an einzusetzen.

Abschließend betont Victoria, dass ein Ansatz mit Infrastructure as Code (IaC) für die Infrastruktur unverzichtbar ist. Falls Ihnen der Begriff nicht vertraut ist: Bei IaC wird die Infrastruktur anhand eines deklarativen Modells verwaltet. Dabei kommt dieselbe Versionsverwaltung zum Einsatz, die DevOps-Teams für Quellcode nutzen. Das IaC-Modell wirkt einer Abweichung zwischen Umgebungen entgegen und sorgt für konsistente Umgebungen.

Victorias letzter Tipp für eine sichere Infrastruktur: Aktualisierungen von Produktionsumgebungen dürfen ausschließlich über die Continuous-Integration-/Continuous-Delivery-Pipeline (CI/CD) erfolgen – niemals manuell. Die CI/CD-Pipeline ist das Herzstück von Sicherheitsinitiativen. Im Anschluss ging Victoria auf die Anwendungssicherheit ein und zeigte der Community, wie sie mit den verschiedenen Teilen der CI/CD-Pipeline zusammenhängt. Die Schritte der CI/CD-Pipeline umfassen laut Victoria:

1. Vor dem Commit

2. Commit (CI)

3. Abnahme (CD)

4. Produktion

5. Betrieb

Alle genannten Bereiche lassen sich durch Sicherheitsmaßnahmen stärken, die in den folgenden Abschnitten beschrieben werden.

Vor dem Commit

In der Phase vor dem Commit schreibt ein Entwickler neuen Code oder nimmt Änderungen an vorhandenem Code vor. Investitionen in Sicherheit zahlen sich in dieser Phase später aus, denn an diesem Punkt der Pipeline lassen sich Änderungen leichter umsetzen. Sie eignet sich gut für Threat Modeling, den Einsatz eines Sicherheits-IDE-Plugins, die Einhaltung der Secure-Coding-Standards Ihres Teams und Peer-Reviews.

Commit (CI)

In der Commit-Phase können Sie verschiedene Prozesse automatisch ausführen lassen. Zu den Sicherheitsmaßnahmen an diesem Punkt der CI/CD-Pipeline gehören statische Codeanalyse, Sicherheits-Unit-Tests und Abhängigkeitsmanagement.

Abnahme (CD)

Zu den relevanten Sicherheitsmaßnahmen in der Abnahmephase gehören IaC, Sicherheitsscans, Cloud-Konfiguration und Abnahmetests zur Sicherheit. Diese Tests können in einer QA-/Stage-Umgebung stattfinden, bevor die Änderungen in die Produktionsumgebung übernommen werden.

Produktion

Zu den wertvollen Sicherheitsmaßnahmen in der Produktionsumgebung zählen Security-Smoke-Tests, Konfigurationsprüfungen und Penetrationstests.

Betrieb

In der Betriebsphase tragen kontinuierliches Monitoring, Threat Intelligence, Penetrationstests und vorwurfsfreie Postmortems dazu bei, eine gute Sicherheitslage und -kultur zu stärken.

The Secure Developer

Victoria beendete ihre Session mit einer Demo und einer Fragerunde. Ich empfehle Ihnen, sich die vollständige Präsentation hier anzusehen. Victorias Perspektive auf die zahlreichen Möglichkeiten, mit denen Entwickler ihre Sicherheitskompetenz verbessern können, hat mir sehr gefallen – ganz gleich, ob sie ein Projekt in der Azure-Cloud oder mit einer anderen Lösung bereitstellen.

Die Community The Secure Developer möchte hervorragende Sprecherinnen und Sprecher wie Victoria Almazova sowohl für unsere virtuellen Sessions als auch für unseren Podcast gewinnen. Wenn Sie mehr über die verschiedenen Aspekte der Sicherheit erfahren möchten, freuen wir uns, wenn Sie der Community beitreten. Wir freuen uns auf Sie.