Suchen

Schwachstellen-Management in Container-Infrastrukturen Wie man Container-Risiken minimiert

| Autor / Redakteur: Tim Mackey * / Stephan Augsten

Container stellen Software über unterschiedliche Plattformen und Infrastrukturen hinweg bereit, ohne an diese angepasst werden zu müssen. Dieser Artikel soll für Sicherheitsfragen rund um den Einsatz dieser Technologie sensibilisieren.

Firmen zum Thema

Unabhängig vom verwendeten Container-Image sollten Entwickler dem Anbieter vertrauen können, beispielsweise hinsichtlich einer schnellen Fehlerbehebung.
Unabhängig vom verwendeten Container-Image sollten Entwickler dem Anbieter vertrauen können, beispielsweise hinsichtlich einer schnellen Fehlerbehebung.
(Bild: firateskici1 - Pixabay.com. / CC0 )

Die Bereitstellung von Anwendungen gestaltet sich mit Containern wesentlich einfacher und schneller. Deshalb haben sie sich Container zu einem immer beliebteren Instrument innerhalb der modernen Softwarekonzeption entwickelt.

Wenn Entwickler ein Container-Image für ihre Anwendung erstellen, wählen sie zunächst ein so genanntes Basisimage aus einer – öffentlichen oder organisationsinternen – Bibliothek. Dieses enthält alle Daten, um eine Container-Anwendung plattformunabhängig auszuführen. Der verantwortliche Entwickler fügt dann noch anwendungsspezifische Komponenten hinzu – fertig ist die containerisierte Anwendung.

Das auf diese Weise geschaffene Image kommt dann auf den Prüfstand und wird – sofern alle Tests bestanden wurden – in eine Registry verschoben, von der aus es dann bereitgestellt werden kann. Zur besseren Illustration gehen wir im Rahmen dieses Artikels davon aus, dass der zugrundeliegende Code zum Zeitpunkt der Bereitstellung keine bekannten Schwachstellen aufweist, das Image also „sicher“ ist.

In der Realität können eben solche ursprünglich sicheren Container-Images ohne Vorwarnung unvermittelt zu unsicheren mutieren. Denn sobald eine neue Sicherheitslücke (CVE) in einem Container-Image offengelegt wird, besteht für sämtliche darauf basierenden Container das Risiko einer Kompromittierung.

Linux und Docker: Open Source als Rückgrat der Container-Technologie

Mit Linux und Docker als Rückgrat der meisten Container-Implementierungen sind Open-Source-Komponenten in einer containerisierten Anwendung praktisch garantiert. Entwickler haben die Wahl, Open-Source-Komponenten entweder direkt aus öffentlichen Repositorien zu beziehen oder eine Version aus einem intern verwalteten Repository zu verwenden.

Die Entscheidung, woher eine Komponente bezogen wird und ob die jeweilige Version lokal zwischengespeichert werden soll, wirkt sich direkt auf die Sicherheit der Anwendung aus. Von den zahllosen Images von zahllosen Entwicklern werden längst nicht alle regelmäßig aktualisiert. Deshalb bietet beispielsweise Docker sogenannte „Official Repositories” an, bei denen ein vom Unternehmen finanziertes Team auf Aktualität achtet.

Egal welches Image verwendet wird; Entwickler sollten sichergehen, dass sie dem Anbieter vertrauen können. 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.

Wie Container sicherer werden, wie man die Risiken minimiert

Nicht alle Komponenten sind vertrauenswürdig. Jede Datei, die aus einem Repositorium stammt, könnte zum Zeitpunkt des Downloads eine Schwachstelle aufweisen, auch wenn sie zum Zeitpunkt der Veröffentlichung frei von bekannten Mängeln war. Letztendlich muss jede Komponente mit der gleichen Vorsicht behandelt werden wie ein beliebiger Download aus dem Internet.

Im Gegensatz zu proprietärem Code eines bestimmten Anbieters können Open Source-Komponenten aus einer Vielzahl unabhängiger Quellen stammen, die als „Forks” bezeichnet werden. Da jeder Fork einen unabhängigen Verteilungskanal für die Komponente darstellt, können Patches, die aus einer anderen Quelle stammen als der, aus der die Komponente bezogen wurde, zu unerwartetem Anwendungsverhalten führen.

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 mit dem aktualisierten Image zu ersetzen. Dieser Paradigmenwechsel erfordert, dass Unternehmen ihre Prozesse zum Patchen und kontinuierlichen Überwachen von Software überdenken.

Das Sicherheitsmanagement der Containerinfrastruktur in einer Produktionsumgebung wird aufgrund der Größe der Implementierungen immer schwieriger. Wie können sich Unternehmen und Entwickler darauf verlassen, dass alle Container in ihrem Kubernetes- oder OpenShift-Cluster die erwarteten Aufgaben erfüllen und kein Container kompromittiert wurde?

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

  • Woher stammt das im Container verwendete Basisimage?
  • Wie ist der Zustand dieses Basisimages und wann wurde es zuletzt bewertet?
  • Verwendet das Basisimage irgendwelche zwischengespeicherten Komponenten?
  • Besteht die Möglichkeit, dass ein fremder oder nicht zugelassener Container in meiner Umgebung starten kann?
  • Besteht die Möglichkeit, dass jemand den Inhalt eines laufenden Containers ändern kann?
  • Wer hat die Berechtigungen, Container-Images zu ändern?
  • Was passiert, wenn die Registry oder das Image-Tag verschwinden und ich ein Container-Image neu erstellen muss, um es zu patchen?
  • Wenn eine Schwachstelle bekannt wird, wie werden die Auswirkungen ermittelt?
  • Wie werden Images bei neuen Sicherheitsinformationen aktualisiert und bereitgestellt?

Fazit

Für einen Sicherheitszwischenfall reicht ein einziger verwundbarer Container aus. Unternehmen benötigen deshalb Einblick in jedes eingesetzte Container-Image. Im ersten Halbjahr 2018 wurden im Schnitt fast 50 neue Sicherheitslücken (CVEs) pro Tag veröffentlicht. Traditionelle Sicherheitsmodelle, wie regelmäßige Scans, sind nicht darauf ausgelegt, mit dieser Rate Schritt zu halten.

Unternehmen sollten deshalb Container-spezifische Tools und Prozesse für das Schwachstellen-Management einsetzen. Da containerisierte Anwendungen weitgehend auf Open Source-Technologie basieren, müssen erfolgreiche Containersicherheitslösungen auf dem bewährten Open Source-Management-Paradigma aufbauen, einschließlich:

  • Erstellung eines Inventars von Open Source-Komponenten und ihrer Herkunft. Man kann nur patchen, was man kennt.
  • Zuordnung jeder Komponente zu bekannten Schwachstellen und Zusammenarbeit mit der Community um sicherzustellen, dass neue Schwachstellen schnell identifiziert werden.
  • Erstellung einer Open Source-Steuerungs-Richtlinie, die neben der IP-Konformität (Lizenzen und Copyrights) auch Sicherheitsaspekte berücksichtigt.

Tim Mackey
Tim Mackey
(Bild: Black Duck by Synopsys)

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.

* Als Technology Evangelist bei Black Duck by Synopsys ist Tim Mackey in technischen Communities gut vernetzt. Er kennt somit die aktuellsten Applikationssicherheitsprobleme und gibt diese an die Entwicklerteams weiter. Seine Spezialgebiete sind Open-Source-Sicherheit, Rechenzentrumssicherheit, Container, Virtualisierung und Cloud-Technologien.

(ID:45498208)