Supply Chain Security
Containerisierte Anwendungen sichern
Fortsetzung des Artikels von Teil 1
Mythos 3 bis 4
Mythos 3: Security ist nur ein Thema für Audits.
Der Status quo ist in vielen Unternehmen immer noch, dass man Security als Blocker betrachtet, der die Entwicklung behindert. Folglich greifen viele Unternehmen das Thema Security oft erst am Ende eines Entwicklungsprozesses auf – nicht selten erst dann, wenn eine Zertifizierung oder gesetzliche Regularien es erfordern. Unter Sicherheitsaspekten ist ein solches Vorgehen problematisch und auch nicht effizient. Security ist als Teil eines ganzen Prozesses zu betrachten und auch als Projektziel zu definieren. Dabei geht es keineswegs nur um technische Fragestellungen, sondern auch um organisatorische Abhängigkeiten und eine enge Zusammenarbeit beziehungsweise geteilte Verantwortung aller Prozess-Stakeholder.
Security ist also weder ein reines Audit-Thema noch auf ein Schwachstellen-Scanning zu beschränken. Das Gebot der Stunde lautet vielmehr Security-by-Design, um eine höchstmögliche Sicherheit zu gewährleisten. Bezogen auf den Container-Bereich und das Ziel „Einmal erstellen, überall bereitstellen“ heißt das, dass im Build-Prozess ein fehlerfreies Produkt entsteht, das im Produktivbetrieb zum Einsatz kommt. Dabei muss ein Entwicklerteam auch die angestrebte Unveränderlichkeit der Container berücksichtigen. Schließlich ist die Anwendung von Patching auf aktive Container kein gangbarer Weg. Container sollte man immer neu erstellen und bereitstellen. An diesem Punkt kommen auch Shift-Left-Testing-Ansätze zum Tragen. Darunter ist die frühzeitige Durchführung von Tests im Entwicklungsprozess zu verstehen. Eine schnellere Fehlerbehebung und letztlich höhere Produktqualität sind die Konsequenzen. Im Prinzip geht es dabei um die Etablierung einer DevSecOps-Pipeline, bei der Sicherheitsaspekte in den DevOps-Prozess integriert sind. Idealerweise implementiert man die Sicherheit dabei in reproduzierbarer und automatisierbarer Form möglichst nah am Quellcode – Stichwort „Security as Code“. Damit gewinnt man auch die Geschwindigkeit, Agilität und Flexibilität, für die Dev-Ops letztlich steht.
Mythos 4: Entwickler müssen sich nicht um die Security kümmern.
Mit über einer Million Open-Source-Projekten ist es ein Leichtes für Entwickler, zu übernehmen, was andere bereits entwickelt haben, es an die geschäftlichen Anforderungen anzupassen und es schließlich in ihrer Umgebung einzusetzen. Gibt es für die Entwickler dabei jedoch keine Richtlinien, verliert man schnell den Überblick über mögliche Schwachstellen, die durch zahlreiche Versionen verschiedenster Bibliotheken im Unternehmen vorhanden sind.
In der Folge sind klare Policies und Regularien zwingend erforderlich, etwa für die Kontrolle und Automatisierung der Erstellung von Containern. Unternehmen sollten überdies auch Best Practices für die Sicherheit in der Anwendungspipeline beachten, vor allem im Hinblick auf die Integration automatischer Sicherheitstests, einschließlich Registry, IDE und CI/CD-Tools. Zur Echtzeit-Überprüfung auf bekannte Sicherheitslücken und neue Schwachstellen ist es beispielsweise möglich, Scanner mit CI zu integrieren.
Für eine hohe Sicherheit von Bedeutung sind zudem automatisierte Richtlinien, mit denen Unternehmen das Container- und Cluster-Deployment aus sicherheitstechnischer Sicht verwalten können. Dazu gehören ein richtlinienbasiertes Container Deployment, das das Herunterladen von Images aus bestimmten Registries zulässt oder ablehnt, und ein richtlinienbasiertes Multi-Cluster-Management für das Deployment oder Migrationen über verschiedene Cloud-Anbieter hinweg.
Der Lebenszyklus eines Lösungs-Stacks im Fokus
Die verschiedenen Mythen zeigen, dass das Thema Sicherheit sowohl organisatorisch als auch technisch einen deutlich höheren Stellenwert einnehmen muss, und zwar im gesamten Lifecycle einer containerisierten Anwendung, also in den Phasen „Design“, „Build“, „Run“, „Manage and Automate“ und „Adapt“.
In der Designphase geht es dabei um die Identifizierung der Sicherheitsanforderungen und in der Build-Phase um die unmittelbare Integration von Sicherheit in den Applikations-Stack. Um den Betrieb sowie die Entwicklung zu entlasten, sollten Unternehmen vertrauenswürdige Plattformen mit erweiterten Sicherheitsfunktionen nutzen, deren Basis selbst unter Betrachtung der Supply Chain Security für Betriebssystem und Plattformsoftware entwickelt wurde. Die Phase „Manage and Automate“ umfasst die Automatisierung der Systeme für Sicherheit und Compliance und „Adapt“ schließlich die regelmäßige Aktualisierung, wenn es Änderungen in der Security-Landschaft gibt.
Prinzipiell fungieren Open Source und Container-Plattformen in Kombination mit Cloud-nativen Laufzeitumgebungen heute als zentrale Innovationstreiber. Wie überall in der IT darf dabei das Thema Sicherheit nicht zu kurz kommen. Mit einem holistischen Ansatz, der die Supply Chain Security in den Vordergrund stellt und Container in allen Phasen umfasst – beim Erstellen, Bereitstellen und Ausführen –, steht einer risikominimierten Nutzung nichts im Wege. Unternehmen betrachten Security folglich nicht mehr als Blocker, sondern vielmehr als Enabler für ihre moderne IT-Infrastruktur.
Marie Innes ist Solution Architect, und Miriam Bressan ist Manager Solution Architects, beide bei Red Hat.
- Containerisierte Anwendungen sichern
- Mythos 3 bis 4
Lesen Sie mehr zum Thema
