Container haben die Auslieferung von Software grundlegend verändert: Anwendungen wandern samt Abhängigkeiten als standardisierte Images durch die Pipeline und starten in Sekunden.
Dieselben Eigenschaften, die Container so effizient machen, verlangen jedoch ein eigenes Sicherheitsmodell. Ein verwundbares Basis-Image vervielfältigt sich mit jedem Build, und sämtliche Container eines Hosts teilen sich denselben Betriebssystem-Kernel.
Was ist Container-Sicherheit?
Container-Sicherheit bündelt alle Maßnahmen, die containerisierte Anwendungen über ihren Lebenszyklus schützen: beim Bau des Images, bei der Ablage in der Registry und im laufenden Betrieb. Der zentrale Unterschied zu klassischen Servern liegt im Prinzip der Unveränderlichkeit. Ein Container wird zur Laufzeit idealerweise nie angefasst; Korrekturen entstehen als neues Image und durchlaufen erneut alle Prüfungen der Pipeline. Sicherheit verlagert sich damit nach vorn in den Build-Prozess, wo sich Fehler am günstigsten beheben lassen.
Die Laufzeit bleibt trotzdem relevant: Erst dort zeigt sich, ob ein Container tut, was sein Image verspricht, oder ob ihn jemand zweckentfremdet. Technische Grundlage ist der offene OCI-Standard, der Aufbau und Austauschformat von Images definiert; Prüfwerkzeuge und Registries setzen darauf auf und bleiben untereinander kombinierbar.
Wie Container-Sicherheit funktioniert
Der Schutz folgt dem Weg eines Images durch die Umgebung:
- Schlanke Basis-Images: Minimale, gepflegte Images verkleinern die Angriffsfläche spürbar. Jede zusätzliche Bibliothek bringt potenzielle Schwachstellen mit, die später gescannt, bewertet und behoben werden müssen.
- Scanning in der Pipeline: Automatisierte Prüfungen untersuchen jedes Image auf bekannte Schwachstellen und blockieren kritische Funde vor dem Deployment. Eine Software-Stückliste (SBOM) dokumentiert, was genau im Image steckt.
- Registry-Schutz: In Produktion gelangen ausschließlich signierte Images aus der eigenen, zugriffsgeschützten Registry. Signaturen belegen, dass zwischen Build und Deployment niemand manipuliert hat.
- Minimale Rechte zur Laufzeit: Container laufen ohne Root-Rechte, mit schreibgeschütztem Dateisystem und ohne Durchgriff auf den Host. Was eine Anwendung nicht braucht, wird ihr gar nicht erst eingeräumt.
- Laufzeitüberwachung: Verhaltensregeln erkennen Abweichungen vom erwarteten Muster, etwa einen unerwarteten Prozessstart in einem produktiven Container. Solche Signale deuten auf die Ausnutzung einer Schwachstelle hin.
- Isolation nach Bedarf: Namespaces und Cgroups trennen Container voneinander. Wo höhere Anforderungen gelten, ergänzen Sandbox-Laufzeiten oder dedizierte Hosts die Trennung, etwa bei strikten Mandantengrenzen.
Warum Container-Sicherheit wichtig ist
- Multiplikation von Schwachstellen: Ein Fehler im Basis-Image landet in jedem daraus gebauten Dienst. Umgekehrt wirkt ein zentraler Scan entsprechend weit.
- Geteilter Kernel: Ein Kernel-Exploit aus einem Container heraus gefährdet alle Nachbarn auf demselben Host. Minimale Rechte und saubere Isolation begrenzen dieses Risiko.
- Tempo der Pipeline: Deployments im Stunden- oder Minutentakt lassen keine manuellen Freigaben zu. Prüfungen müssen automatisiert mitlaufen, um Schritt zu halten.
- Öffentliche Lieferkette: Basis-Images und Pakete stammen häufig aus öffentlichen Registries, deren Pflegezustand stark schwankt. Herkunftsnachweise werden damit zur Pflicht.
- Flüchtige Spuren: Beendete Container hinterlassen wenig forensisches Material. Protokolle und Ereignisdaten müssen den Container überleben, sonst fehlt nach Vorfällen jede Grundlage.
Typische Szenarien
Häufig beginnt das Thema mit der ersten containerisierten Kernanwendung: Der etablierte Prozess für Server-Patching passt plötzlich nicht mehr, und die Verantwortung wandert in Richtung Build-Pipeline. Ein zweites Szenario ist die Absicherung von CI/CD selbst, denn wer die Pipeline kompromittiert, verteilt Schadcode automatisiert in die Produktion.
Auch die Konsolidierung mehrerer Anwendungen auf einer gemeinsamen Plattform gehört dazu; hier entscheiden Isolation und Rechtekonzept darüber, ob sich Mandanten gegenseitig gefährden. Wird eine kritische Schwachstelle in einer weit verbreiteten Bibliothek bekannt, zeigt sich der Wert einer SBOM: Betroffene Images sind in Minuten identifiziert statt in Tagen. In regulierten Branchen kommt die Nachweispflicht hinzu: Herkunft und Prüfstand jedes Images müssen sich belegen lassen, inklusive dokumentierter Freigaben. Ergänzend begrenzt Mikrosegmentierung die Kommunikation zwischen Containern, virtuellen Maschinen und klassischen Servern; in der Praxis bieten spezialisierte Dienstleister das als verwalteten Service an, damit ein kompromittierter Dienst isoliert bleibt.
Container und virtuelle Maschinen: zwei Sicherheitsmodelle
Eine virtuelle Maschine bringt ihr eigenes Betriebssystem mit, und der Hypervisor zieht eine harte Grenze zwischen den Gästen. Container teilen sich dagegen den Kernel des Hosts; die Trennung übernehmen Mechanismen des Betriebssystems. Das macht Container leichtgewichtig und schnell, die Isolationsgrenze ist jedoch dünner als bei einer VM.
Dafür punktet das Container-Modell an anderer Stelle: Unveränderliche Images ersetzen das Patchen laufender Systeme, jede Änderung durchläuft die Pipeline samt aller Prüfungen. Virtuelle Maschinen altern im Betrieb, Container werden neu gebaut. In der Praxis kombinieren viele Umgebungen beide Modelle und trennen besonders kritische Workloads zusätzlich über VM-Grenzen. Für die Risikobewertung zählt deshalb weniger, welches Modell pauschal sicherer ist, sondern welche Isolationsgrenze ein konkreter Workload tatsächlich braucht.
Häufige Fragen
Sind Container unsicherer als virtuelle Maschinen?
Die Isolationsgrenze einer VM ist härter, weil der Hypervisor vollständige Gastsysteme trennt. Container gleichen das an anderer Stelle aus: Unveränderliche, geprüfte Images und automatisierte Pipelines senken die Zahl der Schwachstellen im Betrieb deutlich. Entscheidend ist die Konfiguration. Ein gehärteter Container ohne Root-Rechte ist einer ungepflegten VM in der Praxis meist überlegen.
Was prüft ein Image-Scan?
Der Scanner zerlegt das Image in seine Schichten und vergleicht enthaltene Pakete und Bibliotheken mit Schwachstellendatenbanken. Gute Werkzeuge bewerten zusätzlich Konfigurationsfehler, eingebettete Zugangsdaten und veraltete Basis-Images. Ergebnis ist eine nach Schweregrad und Ausnutzbarkeit priorisierte Liste, idealerweise direkt in der Pipeline, damit kritische Funde ein Deployment automatisch stoppen.
Wozu dient eine SBOM?
Eine Software-Stückliste dokumentiert maschinenlesbar, welche Komponenten in einem Image stecken. Ihr Wert zeigt sich im Ernstfall: Wird eine Schwachstelle in einer verbreiteten Bibliothek bekannt, beantwortet die SBOM in Minuten, welche Dienste betroffen sind. Zunehmend verlangen auch Kunden und Regulierung solche Nachweise über die Zusammensetzung eingesetzter Software.
Wie lassen sich Container zur Laufzeit schützen?
Grundlage sind minimale Rechte: kein Root, schreibgeschütztes Dateisystem, keine unnötigen Kernel-Fähigkeiten und kein Zugriff auf den Host. Darauf aufbauend überwacht eine Laufzeitlösung das Verhalten und meldet Abweichungen wie unerwartete Prozesse oder neue ausgehende Verbindungen. Segmentierung begrenzt zusätzlich, welche Dienste ein kompromittierter Container überhaupt erreichen könnte.
Müssen laufende Container gepatcht werden?
Nein, und genau das ist der Vorteil des Modells. Statt Pakete im laufenden Container zu aktualisieren, wird das Image neu gebaut, geprüft und ausgerollt; der alte Container verschwindet vollständig. Das hält den Zustand reproduzierbar und verhindert schleichende Abweichungen. Voraussetzung sind aktuelle Basis-Images und eine Pipeline, die Neubauten zügig in die Produktion bringt.