Container werden im Lebenszyklus einer Anwendung häufig eingesetzt, da sie deren zuverlässige Ausführung in verschiedenen Rechnerumgebungen ermöglichen. „Also auf meinem Rechner funktioniert es“ und ähnliche Probleme gehören damit der Vergangenheit an. Ziel der Container-Sicherheit ist es, Container in jeder Phase der App-Entwicklung vor Sicherheitskompromittierungen zu schützen.

In diesem Artikel werden das Konzept und die Herausforderungen der Container-Sicherheit sowie Best Practices für die Entwicklung sicherer containerisierter Anwendungen behandelt.

Was ist Container-Sicherheit?

Container-Sicherheit ist der kontinuierliche Kontrollvorgang zum Schutz containerisierter Umgebungen vor Sicherheitsrisiken. Solche Umgebungen umfassen nicht nur Container und die darin ausgeführten Anwendungen, sondern auch die zugrunde liegende Infrastruktur wie die Container-Laufzeit, den Kernel und das Host-Betriebssystem.

Laut der CNCF Annual Survey 2021 ist bei 93 % der befragten Unternehmen der Einsatz von Containern in der Produktion bereits erfolgt oder geplant. Dieser Trend geht mit der Umstellung von Unternehmen auf cloudnative Architekturen und den Anforderungen an eine schnellere Anwendungsbereitstellung einher. Somit ist die Integration von Best Practices für Container-Sicherheit in den gesamten DevOps-Lebenszyklus von entscheidender Bedeutung, um sichere Container-Anwendungen zu gewährleisten und schwerwiegende Sicherheitskompromittierungen und deren Folgen zu verhindern.

Sicherheitsprobleme von Containern

Container bieten viele Vorteile bei der Beschleunigung der Anwendungsbereitstellung: So ermöglichen sie etwa die Portabilität zwischen verschiedenen Plattformen und die Ausführung von Prozessen in isolierten Umgebungen durch eigenständige Anwendungen bei gleichzeitiger Nutzung des zugrunde liegenden Kernels. Container verfügen jedoch nicht über eigene Sicherheitsfunktionen, sondern erhalten über das Host-Betriebssystem Zugriff auf die Hardware. Einem einzelnen Container können auch mehrere Container-Images zugrunde liegen. Dadurch entstehen neue Angriffsflächen, die einzigartige Sicherheitsherausforderungen mit sich bringen. Einige davon werden wir im Folgenden besprechen.

Fehlkonfigurationen bei Containern

Viele Entwicklungsteams erliegen im Zusammenhang mit Containern dem Irrtum, ihre Arbeit wäre mit der Einrichtung erledigt. Dabei könnte es unsichere Standardkonfigurationen geben, die ihnen möglicherweise nicht bekannt sind. Zu den häufigsten Fehlern bei der Sicherheitskonfiguration gehören:

• Offengelegte unsichere Ports, die für die Anwendung nicht erforderlich sind
• Kompromittierte Secrets und Anmeldedaten wie Kennwörter und Authentifizierungs-Tokens
• Zu großzügige Berechtigungen für die Container-Laufzeit, z. B. die Ausführung von Containern als Stamm

Wenn diese Fehlkonfigurationen nicht vor der Bereitstellung überprüft werden, können sie die Sicherheit der Container kompromittieren oder sich für Rechteausweitung angreifbar machen.

Schwachstellen in der Container-Infrastruktur

Ein Container-Infrastruktur-Stack besteht in der Regel aus Anwendungs-Code, Konfigurationen, Bibliotheken und Paketen, die in ein Container-Image integriert sind. Dieses wird über eine Container-Laufzeit innerhalb eines Containers auf dem Kernel des Host-Betriebssystems ausgeführt.

In jeder Phase des Container-Lebenszyklus können potenziell Sicherheitslücken in der Container-Infrastruktur entstehen, wodurch die Angriffsfläche vergrößert wird, die während der Laufzeit ausgenutzt werden kann. Schwachstellen können auch von externen Abhängigkeiten geerbt werden, die in das Container-Image integriert sind, oder sogar in der Host- und Container-Laufzeit innerhalb des Stacks vorhanden sein.

Container-Images können als Teil der Anwendung außerdem Sicherheitslücken von Open‑Source-Bibliotheken und -Paketen erben, was sie anfällig für Angriffe macht. Entwicklungsteams können Container-Images anhand von Basis-Images aus Container-Registrierungen von Drittanbietern erstellen. Möglicherweise enthalten diese unbeabsichtigt Sicherheitslücken oder wurden von Hackern absichtlich durch ein kompromittiertes Image ersetzt.

Schließlich können Container und Hosts Schwachstellen enthalten, die über Netzwerke, Hosts und Endgeräte ausgenutzt werden können, wenn der Container auf dem Kernel des Host-Betriebssystems ausgeführt wird. Insbesondere Container‑Escape-Schwachstellen im Host-Kernel und in der Container-Laufzeit könnten Angriffsvektoren Tür und Tor öffnen. Diese nutzen über lokale Rechteausweitung Host-Schwachstellen aus und führen laterale Netzwerkbewegungen durch, wodurch Ihre gesamte Cloud-Infrastruktur gefährdet wird.

Einblick in Container-Workloads

Der Einblick in Container-Workloads stellt die größte Herausforderung der Container-Sicherheit dar. Da Container-Workloads sehr dynamisch und in der Regel kurzlebig sind, kann es für Sicherheitsteams schwierig sein, Anomalien in der Container-Aktivität zu überwachen und zu verfolgen.

Probleme mit der Container-Sicherheit können sich schnell über Container und Anwendungen ausbreiten. Daher ist es wichtig, sowohl auf Containern als auch auf Hosts Einblick in die Laufzeitinformationen zu haben, damit Schutzvorrichtungen Schwachstellen in containerisierten Umgebungen erkennen und beheben können.

Probleme beim Sichern von CI/CD-Pipelines

Container-Sicherheit erfordert die Sicherung aller Phasen der CI/CD-Pipeline: vom Anwendungs-Code über die Container-Workload bis hin zur Infrastruktur. In der Entwicklung wird sich Sicherheitsaspekten allerdings in der Regel gegen Ende des Lebenszyklus einer Anwendung gewidmet. So bleibt oft nur wenig Zeit für Sicherheitstests, da Entwicklungsteams sich beeilen müssen, enge Zeitpläne für die Anwendungsbereitstellung einzuhalten.

7 Best Practices der Container-Sicherheit

Glücklicherweise gibt es etablierte Methoden, um die oben genannten Herausforderungen zu meistern und die Sicherheit Ihrer containerisierten Umgebung und des Anwendungszyklus in jeder Phase zu optimieren.

1. Images sichern

Wenn Sie Container-Anwendungen mit Basis-Images aus einer externen Container-Registrierung entwickeln, sollten Sie Images aus vertrauenswürdigen Quellen beziehen und in einer sicheren privaten Registrierung speichern, um das Risiko von Manipulationen zu minimieren. Die Angreifenden können auch Images in vertrauenswürdigen Registrierungen kompromittieren. Denken Sie daher daran, die Image-Signaturen mit Notary oder ähnlichen Tools zu prüfen.

Außerdem können Image-Tags geändert werden, was beispielsweise dazu führt, dass mehrere Images zu unterschiedlichen Zeitpunkten als aktuelle Version getaggt sein können. Verwenden Sie feste Image-Tags, die unveränderlich sind (zum Beispiel den Image-Digest), um konsistente automatisierte Builds sicherzustellen und Angriffe zu verhindern, welche die Veränderlichkeit von Tags ausnutzen.

2. Secrets sicher verwalten

Vermeiden Sie es, Secrets und Anmeldedaten in Code- oder Konfigurationsdateien, einschließlich einer Dockerfile, zu speichern. Andernfalls werden diese sensiblen Daten in Container kopiert und in Zwischenschichten von Containern zwischengespeichert, selbst wenn der Container entfernt wird. Eine gängige, bewährte Methode zur sicheren Speicherung und Verwaltung von Secrets und Anmeldedaten ist die Verwendung eines dedizierten Secret-Managers wie Vault oder AWS Secrets Manager.

3. Container-Berechtigungen zur Laufzeit einschränken

Das Least Privilege-Prinzip besagt, dass Nutzenden nur die geringstmöglichen Berechtigungen gewährt werden, die sie zum Ausführen einer bestimmten Aufgabe benötigen. Dies ist ein zentraler Aspekt der Sicherheit, der auch für die Container-Sicherheit zur Laufzeit gilt.

Container werden in der Regel als Nutzer mit Stammberechtigungen ausgeführt, um verschiedene Systemvorgänge innerhalb des Containers zu ermöglichen, wie zum Beispiel die Installation von Paketen und Lese-/Schreibvorgänge für Systemkonfigurationsdateien. Das Ausführen von Containern mit Stammberechtigungen stellt jedoch ein großes Sicherheitsrisiko dar, da es Angreifenden ermöglicht, die Rechteausweitung innerhalb des Containers auszunutzen, wenn die Container-Laufzeit kompromittiert ist.

Daher ist es wichtig, die Container-Berechtigungen zur Laufzeit einzuschränken, um Schwachstellen im Host-Kernel und zur Container-Laufzeit zu minimieren. Dies können Sie erreichen, indem Sie Container im Rootless-Modus ausführen, sodass Sie sie als Nutzer ohne Stammberechtigungen ausführen können. Oder beschränken Sie die Funktionen des Linux-Kernels auf die explizit benötigten Funktionen. Streichen Sie dazu alle Standardfunktionen und fügen Sie nur diejenigen hinzu, die für die Container-Workload erforderlich sind.

4. Fehlerhafte Sicherheitskonfigurationen identifizieren und korrigieren

Durch die Identifizierung von Fehlern in der Sicherheitskonfiguration beim Erstellen von Container-Images können Sie Schwachstellen vor der Bereitstellung von Container-Anwendungen in der Produktion beheben. Dieser Vorgang beinhaltet die Überprüfung von Konfigurationsparametern mittels statischer Konfigurationsanalyse, was bei manueller Durchführung mühsam und anfällig für menschliche Fehler sein kann.

Cloud-Sicherheitstools wie die Sicherheitsverwaltung für Cloud-Umgebungen (CSPM, Cloud Security Posture Management) mit CrowdStrike Falcon Horizon™ vereinfachen die Verwaltung von Sicherheitskonfigurationen. Sie vergleichen Konfigurationen mit Benchmarks und bieten angeleitete Maßnahmen zur Behebung der Probleme. So können Entwicklungsteams die Sicherheitsrisiken mindern, die die entdeckten Fehlkonfigurationen bergen.

5. Scans und Verwaltung von Schwachstellen automatisieren

Durch die Automatisierung von Schwachstellen-Scans und -Verwaltung in der CI/CD-Pipeline können Sie Sicherheitslücken in jeder Phase des Container-Lebenszyklus erkennen und Sicherheitsrisiken mindern, bevor sie auftreten.

Beim Code-Scanning wird der Anwendungs-Code auf Sicherheitslücken und Programmierungsfehler analysiert. Über statische Anwendungssicherheitstests (SAST, Static Application Security Testing) werden Schwachstellen im Anwendungs-Code aufgedeckt. Die Software-Kompositionsanalyse (SCA, Software Composition Analysis) bietet Einblick in Open‑Source-Komponenten der erstellten Anwendung. Dazu werden eine Software-Stückliste (SBOM, Software Bill of Materials) generiert und Komponenten mit Datenbanken bekannter Open‑Source-Schwachstellen abgeglichen.

Das Image-Scanning umfasst die Analyse des Inhalts und Erstellungsprozesses von Container-Images auf Schwachstellen. Das ist über statische Analysetools wie Clair möglich, die jede Ebene auf bekannte Sicherheitslücken scannen. Oder aber über dynamische Analysetools wie CrowdStrike Container Security: Diese Lösung erkennt Sicherheitsrisiken, indem sie das Verhalten eines Containers während der Ausführung verfolgt.

Zu guter Letzt werden beim Host-Scanning die Komponenten des Container-Hosts, einschließlich des Host-Kernels und des Betriebssystems, auf Laufzeitschwachstellen und Fehlkonfigurationen untersucht. Hierzu nutzen Entwicklungsteams dynamische Anwendungssicherheitstests (DAST, Dynamic Application Security Testing). Dabei handelt es sich um einen Blackbox-Test, der Schwachstellen durch simulierte Angriffe auf die containerisierte Anwendung erkennt.

6. Echtzeit-Protokollierung, -Überwachung und -Benachrichtigungen einrichten

Um den Einblick in Container-Workloads zu verbessern, ist der Einsatz von Tools erforderlich, die Ereignisprotokollierung, Überwachung und Tests auf Schwachstellen in Echtzeit und in jeder Komponente der Container-Umgebung ermöglichen. Damit können Sie Protokolle und Kennzahlen aus verschiedenen Quellen im Container-Stack prüfen und die Container-Details und -Aktivitäten auf anomales Verhalten im System analysieren. So lassen sich Bedrohungen für die Container-Sicherheit aufdecken.

Die Einrichtung von Echtzeit-Protokollierung, -Überwachung und -Benachrichtigungen verschafft Ihnen kontinuierliche Einblicke, Bedrohungserkennung und Compliance-Überwachung. Das trägt dazu bei, dass Schwachstellen und Fehlkonfigurationen gleich nach deren Erkennen behoben werden.

7. Einen Shift‑Left-Ansatz für Sicherheit einführen

Bei einem sogenannten Shift‑Right-Ansatz wird die Sicherheit von CI/CD-Pipelines erst im Nachhinein berücksichtigt. Vorausschauender ist es jedoch, Sicherheitsmaßnahmen zeitlich nach vorne („nach links“) zu verlagern.

Der Shift‑Left-Ansatz in der Sicherheit bezieht sich auf ein Verfahren, bei dem Sicherheitsmaßnahmen in die frühesten Phasen der Anwendungsentwicklung verlagert werden. Dadurch können Entwicklungsteams sichere Container-Anwendungen bereitstellen, ohne den Entwicklungsprozess zu verlangsamen, da sie Zeit haben, Probleme und Schwachstellen so früh wie möglich zu erkennen und zu beheben. Die Integration von Schwachstellen-Scans in jede Phase der CI/CD-Pipeline führt zu weniger Produktionsproblemen. Zudem ermöglicht sie DevOps- und Sicherheitsteams, parallel zu arbeiten. Im Ergebnis wird die Anwendungsbereitstellung beschleunigt, ohne die Container-Sicherheit zu beeinträchtigen.

Fazit

Bei der Implementierung von Best Practices für die Container-Sicherheit ist jede Phase des Container-Lebenszyklus zu sichern – angefangen beim Anwendungs-Code bis hin zur Container-Laufzeit. Container-Sicherheit ist ein kontinuierlicher Prozess und Sicherheitsbedrohungen entwickeln sich im Laufe der Zeit weiter. Daher können Sie einige dieser Verfahren auch schrittweise umsetzen. Integrieren Sie dazu einfach die Produkte und Dienste für Container-Sicherheit von CrowdStrike.