So können Unternehmen Container-basierte Lösungen sicher einsetzenStrategisch bedeutsam für den Unternehmenserfolg

Container erfreuen sich völlig zurecht hoher Beliebtheit. Da Container-Deployments zunehmend strategische Bedeutung für den Unternehmenserfolg haben, müssen bestehende Softwareentwicklungs- und Sicherheitsmethoden nicht nur die Entwicklung, sondern auch den Betrieb und die Verwaltung von Anwendungen besser unterstützen.

Wenn Entwickler ein Container-Image für ihre Anwendung erstellen, wählen sie zunächst aus einer Bibliothek potenzieller Images ein sogenanntes Basis-Image aus. Diese Bibliothek kann öffentlich oder unternehmensintern sein, die Auswahl erfolgt in der Regel nur aufgrund von Funktionalität. Das Basis-Image enthält grundlegende Funktionen zum Ausführen einer generischen Container-Anwendung.

Danach fügt der Entwickler dieser Grundlage anwendungsspezifische Komponenten hinzu. Das auf diese Weise geschaffene Image wird getestet und – wenn alle Tests bestanden wurden – in eine Registry verschoben, von der aus es dann bereitgestellt werden kann. Im weiteren wird davon ausgegangen, dass jedes Image, das sich in einer Registry befindet, zum Zeitpunkt der Erstellung keine Sicherheitsschwachstellen aufweist.
Allerdings verwandeln sich eben solche „guten“ Container-Images oft und ohne Vorwarnung in „schlechten“ Code. Denn sobald eine neue Sicherheitslücke (CVE) für eine Komponente in einem Container-Image offengelegt wird, besteht für sämtliche auf diesem Image basierenden Container das Risiko einer Kompromittierung.

Mit Linux und Docker als Rückgrat von Container-Implementierungen enthalten die allermeisten containerisierten Anwendungen garantiert Open-Source-Komponenten. Entwickler haben die Wahl, bestimmte Open-Source-Komponenten entweder direkt aus öffentlichen Repositorien zu beziehen oder eine Version von einem intern verwalteten Repositorium zu verwenden.

Die Entscheidung, woher eine Komponente bezogen wird, und ob diese Version auch lokal zwischengespeichert werden soll, wirkt sich direkt auf die Sicherheit der Anwendung aus. Das Problem ist, dass nicht alle Komponenten vertrauenswürdig sind. Jede Datei und jedes Image, das aus einem Repositorium stammt, kann zum Zeitpunkt des Herunterladens eine Schwachstelle aufweisen, selbst wenn sie zum Zeitpunkt der Veröffentlichung der Komponente keine aufwiesen. Folglich muss jede Komponente mit der gleichen Vorsicht behandelt werden, die auch für einen x-beliebigen Download aus dem Internet gelten. Da jede „Gabelung“ einer Komponente faktisch einen eigenständigen Vertriebskanal darstellt, können Patches von fremden Gabelungen zu unerwarteten Änderungen des Anwendungsverhaltens führen.

Open Source ändert die Spielregeln

Die Sicherung von Open Source-Software erfordert grundsätzlich andere Prozesse als proprietäre oder kommerzielle Software. Bei kommerzieller Software gibt der Anbieter Hinweise zur Bereitstellung, informiert Kunden über Sicherheitsschwachstellen und stellt sämtliche Patches bereit.

Bei Open Source-Komponenten hingegen werden Änderungen im Anwendungslebenszyklus in der Regel nicht an die Nutzer kommuniziert, es sei denn, sie engagieren sich proaktiv in der Community, die diese Komponente unterstützt. Anders ausgedrückt: Wenn man Open Source-Software verwendet und nicht aktiv mit der Community zusammenarbeitet, ist es sehr schwierig zu erfahren, wann neue Versionen, Patches, Sicherheitsupdates oder andere Änderungen erscheinen.

Containerisierte Anwendungen sollten daher nicht mit herkömmlichen Patch-Management-Prozessen gepatcht werden. Stattdessen ist es ratsam, das Image neu zu erstellen und dann systematisch alle laufenden Container durch das aktualisierte Image zu ersetzen. Dieser Paradigmenwechsel erfordert, dass Unternehmen ihre Prozesse zum Patchen und Monitoring von Software neu gestalten.

Das Sicherheitsmanagement der Containerinfrastruktur in einer Produktionsumgebung wird aufgrund der Größe der Implementierungen immer schwieriger. Container-Orchestrierungssysteme wie Kubernetes werden routinemäßig mit Clustern getestet, die aus Tausenden von Rechenknoten bestehen und in der Lage sind, Hunderte von Containern auszuführen. Eine gut funktionierende Infrastruktur in dieser Größenordnung erfordert ein hohes Maß an Vertrauen. Das heißt, dass darauf vertraut werden kann, dass alle Container im Kubernetes- oder Red Hat OpenShift-Cluster die gewünschten Aufgaben ausführen und dass keine Gefährdung vorliegt.

Betriebsteams können das Risiko von containerisierten Anwendungen minimieren, indem sie die folgenden Fragen beantworten:

• Woher stammt das im Container verwendete Basis-Image?
• Wie ist der Zustand dieses Basis-Images und wann wurde es zuletzt geprüft?
• Wurden beim Erstellen des Images zwischengespeicherte Komponenten verwendet?
• Wenn der Container intern erstellt wurde, wie lautet das Vertrauensmodell für die Build-Umgebung?
• Kann ein fremder Container in meiner Umgebung gestartet werden?
• Kann jemand den Inhalt eines laufenden Containers ändern?
• Wer hat die Berechtigung, Container-Images zu ändern?
• Was passiert, wenn das Register des Basis-Images verschwindet und ein Container-Image neu erstellt werden muss, um es zu patchen?
• Was passiert, wenn das Tag des Basis-Images nicht mehr angezeigt wird und man ein Container-Image neu erstellen muss?
• Wie werden die Auswirkungen ermittelt, wenn eine neue Schwachstelle bekannt wird?
• Wie werden Images bei neu bekannt gewordenen Schwachstellen aktualisiert und bereitgestellt?

Container können nicht auf eine „set it and forget it“-Weise gesichert werden. Sie müssen kontinuierlich überwacht werden, da täglich neue Sicherheitslücken entdeckt werden. Wenn ein Betriebsteam für mehrere tausend Container gleichzeitig verantwortlich ist, stellt das Finden und Beheben neuer Schwachstellen eine große Herausforderung dar.

Ein Image, das mit frisch aktualisierten Komponenten erstellt wurde, ist möglicherweise für ein paar Tage oder Wochen frei von bekannten Schwachstellen. Es werden jedoch früher oder später Sicherheitslücken in einer oder mehreren Image-Komponenten auftreten. Somit ist das Image nicht mehr auf dem neuesten Stand und nicht mehr richtig gesichert. Um sicherzustellen, dass Container vor neuen Schwachstellen geschützt sind, sollten Unternehmen eine container-native Sicherheitslösung verwenden mit der die Containerumgebung aktiv überwacht werden kann.

Zum Kontext: In 2018 wurden im Schnitt fast 45 neue Sicherheitslücken (CVEs) pro Tag veröffentlicht. Traditionelle Sicherheitsmodelle wie regelmäßige Scans sind nicht darauf ausgelegt, mit dieser hohen Rate Schritt zu halten. Unternehmen sollten deshalb Container-spezifische Tools und Prozesse für das Schwachstellenmanagement einsetzen, um das Risiko von einer Kompromittierung zu minimieren.

Eine Container-Sicherheitslösung für Unternehmen sollten zumindest die folgenden Attribute aufweisen:

• Sie sollte die Tatsache nutzen können, dass jeder ausgeführte Container einem Basis-Image entstammt. Die Bewertung der Risiken in diesem Image trägt dazu bei, die Risiken in allen Repliken einschätzen zu können.
• Sie sollte die Risiken in allen im Cluster eingesetzten Container-Images ohne manuelles Zutun bewerten können.
• Sie sollte ein Container-Image bewerten können, ohne dass dazu eine Änderung am Image erforderlich wird.
• Sie sollte der Orchestrierungslösung die Sicherheits- und Risikometadaten zur Verfügung stellen können, ohne dass der Betreiber erst neue Tools erlernen muss.

Da containerisierte Anwendungen größtenteils Open Source sind, bauen erfolgreiche Lösungen für das Containersicherheits-Management auf bewährten Open-Source-Verwaltungsparadigmen auf. Das Verwalten von Open Source erfordert vollständige Transparenz, da Probleme genau dann auftreten können, wenn man am wenigsten damit rechnet.

Unternehmen sollten deshalb eine Reihe bewährter Schritte zum Verwalten von Open-Source-Komponenten beachten:

• Erstellung eines Inventars der Open-Source-Komponenten, einschließlich ihrer Herkunft. Man kann nur patchen, was man kennt.
• Jede Komponente sollte auf bekannte Schwachstellen untersucht werden. Zudem sollte mit der Community zusammengearbeitet werden um sicherzustellen, dass neue Schwachstellen schnellstmöglich identifiziert werden.
• Erstellung einer Open-Source-Governance-Richtlinie, die neben lizenz- und urheberrechtlicher Compliance auch Sicherheitsaspekte umfasst.
• Investition in geeignete Tools, um über neue Open-Source-Probleme auf dem Laufenden zu bleiben.

Container haben die Bereitstellung und Verteilung von Software einfacher und effizienter gemacht. Sie stellen aber auch eine besondere Herausforderung in puncto Sicherheit dar. Ein Container-Image ist im Grunde genommen nur ein Softwarepaket, das gesichert werden muss. Container benötigen geeignete Bereitstellungsprozesse, um sicherzustellen, dass Schwachstellen in Open Source-Komponenten so schnell wie möglich identifiziert, bewertet und gepatcht werden.

Tim Mackey ist Principal Security Strategist bei Synopsys CyRC (Cybersecurity Research Center)

Synopsys