Docker-Sicherheit im Mittelstand: Wie Sie Container produktiv und sicher betreiben

Container haben in den vergangenen Jahren auch im Mittelstand Fuß gefasst. Was meist als pragmatisches Werkzeug für ein internes Tool oder eine Testumgebung beginnt, wandert mit der Zeit fast unbemerkt in den Produktivbetrieb. Genau hier setzt das Problem an, das wir bei Audits von Server-Umgebungen regelmäßig sehen: Die Container laufen, sie tun ihren Dienst - aber ein Sicherheitskonzept hat nie jemand geschrieben.

Das ist nachvollziehbar. Docker macht es leicht, etwas zum Laufen zu bringen. Es macht es aber nicht automatisch sicher. Ein Container isoliert eine Anwendung, doch diese Isolation ist kein Schutzwall, sondern eine technische Trennung mit klar definierten Grenzen - und diese Grenzen lassen sich durch Fehlkonfiguration aushebeln. Wir beschreiben hier die Punkte, an denen wir bei der Härtung von Container-Umgebungen für KMU am häufigsten ansetzen.

Warum Container nicht von Haus aus sicher sind

Der häufigste Irrtum, dem wir begegnen: "Es läuft ja in einem Container, da kann nichts passieren." Tatsächlich ist die Standardkonfiguration vieler Setups deutlich offener, als die Verantwortlichen annehmen. Vier Muster sehen wir besonders oft:

• Container mit Host-Zugriff. Ein einziges falsch gesetztes Flag - etwa --privileged oder ein gemountetes Docker-Socket - und der Container hat praktisch Vollzugriff auf den Host. Wer in einen solchen Container einbricht, steht auf dem ganzen Server.
• Unsichere Images aus dem Netz. Ein beliebiges Image vom Docker Hub zu ziehen ist bequem. Doch viele öffentliche Images sind veraltet, schlecht gepflegt oder schlicht mit Schadcode bestückt. Was Sie nicht selbst geprüft haben, läuft auf gut Glück.
• Fehlende Updates. Ein Image, das vor einem Jahr gebaut wurde, enthält die Schwachstellen von vor einem Jahr. Container werden gern als "einmal gebaut, läuft für immer" behandelt - und genau das macht sie zu einem Sammelbecken bekannter CVEs.
• Geheimnisse im Image oder im Git. Passwörter, API-Keys und Datenbank-Zugangsdaten, die direkt ins Image gebacken oder ins Repository eingecheckt werden, sind einer der häufigsten Funde. Sie liegen damit in jeder Kopie des Images und in der gesamten Git-Historie.

Sichere Images und eine eigene Registry

Die Grundlage jeder vernünftigen Container-Strategie sind die Images selbst. Hier lohnt sich Disziplin, weil ein sauberes Image-Konzept später viele Probleme gar nicht erst entstehen lässt.

Setzen Sie auf eigene Basis-Images oder vertrauenswürdige offizielle. Reduzieren Sie die Zahl der Quellen, denen Sie vertrauen müssen, auf ein Minimum. Ein schlankes, selbst gepflegtes Basis-Image schlägt eine bunte Sammlung fremder Images aus zweifelhaften Quellen.

Scannen Sie Images regelmäßig auf Schwachstellen. Werkzeuge wie Trivy lassen sich in wenigen Minuten in den Build-Prozess integrieren und melden bekannte CVEs, bevor das Image in Produktion geht. Wichtig ist nicht der einmalige Scan, sondern der wiederkehrende - Schwachstellen werden auch in bereits laufenden Images nachträglich bekannt.

Betreiben Sie eine private Registry mit Zugriffskontrolle. Wer kontrolliert, welche Images überhaupt im Unternehmen verteilt werden, hat einen klaren Überblick über Versionen und Herkunft. Das ist gleichzeitig die Voraussetzung dafür, im Ernstfall schnell sagen zu können, wo ein verwundbares Image überall läuft.

Halten Sie Geheimnisse aus dem Image heraus. Zugangsdaten gehören in ein Secret-Management oder zur Laufzeit injizierte Umgebungsvariablen - niemals ins Dockerfile und niemals ins Git-Repository.

Den Linux-Host härten

Ein Container ist nur so sicher wie der Host, auf dem er läuft. Bei der Absicherung von Server- und Netzwerk-Infrastruktur ist der Host-Betrieb für uns deshalb ein eigener Prüfpunkt.

• Minimal gehärtete Hosts. Auf einem Container-Host läuft idealerweise nur das, was er für den Containerbetrieb braucht. Jeder zusätzliche Dienst ist eine zusätzliche Angriffsfläche.
• Ressourcen-Limits pro Container. Wer CPU- und RAM-Grenzen setzt, verhindert, dass ein einzelner außer Kontrolle geratener Container - ob durch Fehler oder Angriff - den gesamten Host lahmlegt.
• Rootless betreiben oder Rechte einschränken. Container müssen in den seltensten Fällen als Root laufen. Rootless-Docker oder zumindest ein dedizierter, eingeschränkter Benutzer reduziert den Schaden, den ein kompromittierter Container anrichten kann, drastisch.
• Netzwerk segmentieren. Container-Netzwerke gehören mit Firewall-Regeln und sinnvollen Segmenten versehen. Nicht jeder Container muss mit jedem reden können, und schon gar nicht jeder muss aus dem Internet erreichbar sein.

Monitoring und Logging - auch in kleinen Umgebungen

Ein Argument, das wir bei KMU oft hören: "Für unsere drei Container brauchen wir doch kein Monitoring." Das Gegenteil ist der Fall. Gerade in kleinen Umgebungen fällt ein Problem ohne Überwachung erst auf, wenn der Schaden bereits sichtbar ist.

• Zentrale Logs für Container und Host. Logs, die nur im Container liegen, sind nach dessen Neustart verschwunden. Eine zentrale Sammlung sorgt dafür, dass Sie im Nachhinein nachvollziehen können, was passiert ist.
• Ressourcennutzung und Fehler im Blick. Auffällige CPU-Last oder ungewöhnlicher Netzwerkverkehr sind oft die ersten Anzeichen eines Problems - lange bevor ein Dienst ausfällt.
• Alarmierung bei verdächtigem Verhalten. Ein simpler Alert, der meldet, wenn ein Container neu startet, ungewöhnlich viel Traffic erzeugt oder unerwartet endet, ist auch in kleinen Setups schnell eingerichtet und enorm wertvoll.
• Regelmäßige Sichtung der laufenden Container. Was läuft eigentlich gerade, in welcher Version, seit wann? Diese Frage sollten Sie jederzeit beantworten können.

Aus der Praxis: ein Produktionsbetrieb im Salzburger Land

Ein Beispiel, das stellvertretend für viele steht: Ein Produktionsbetrieb mit rund 35 Mitarbeitenden hatte über die Jahre mehrere selbst entwickelte Tools in Docker-Containern in Betrieb genommen - verteilt über verschiedene Server, ohne Konzept und ohne dass jemand den Gesamtüberblick hatte. Es funktionierte, bis es das nicht mehr tat: vereinzelte Ausfälle, unklare Versionsstände, niemand konnte verlässlich sagen, welches Image woher kam.

Wir haben die Umgebung konsolidiert, die Linux-Hosts gehärtet, eine private Registry eingeführt und ein schlankes Monitoring etabliert. Das Ergebnis war kein Hochsicherheits-Setup mit Enterprise-Overhead, sondern ein transparenter, kontrollierbarer Betrieb: weniger Ausfälle, klare Versionsstände und die Gewissheit, im Ernstfall handlungsfähig zu sein. Genau diese Balance - ausreichend Sicherheit ohne überzogenen Aufwand - ist für die meisten KMU der richtige Weg.

Brauchen Sie dafür Kubernetes?

Die kurze Antwort: meistens nicht. Für viele mittelständische Umgebungen ist klassisches Docker oder eine einfache Orchestrierung mit Docker Compose völlig ausreichend. Kubernetes spielt seine Stärken erst bei großen, komplexen und stark skalierenden Umgebungen aus - und bringt einen Betriebsaufwand mit, der für drei oder fünf Container in keinem Verhältnis steht. Die Frage, welches Werkzeug zum Bedarf passt, klären wir im Rahmen unserer IT-Consulting-Beratung nüchtern entlang der tatsächlichen Anforderungen, nicht entlang dessen, was gerade modern klingt.

Der nächste Schritt

Container sind ein starkes Werkzeug, auch für KMU. Das Risiko, das mit ungeplantem Wildwuchs einhergeht, lässt sich mit überschaubarem Aufwand deutlich reduzieren: geprüfte Images, gehärtete Hosts, begrenzte Rechte, Monitoring. Keiner dieser Schritte erfordert ein großes Budget oder ein eigenes DevOps-Team.

Wenn Ihre Container-Umgebung über die Jahre gewachsen ist und Sie nicht mehr sicher sagen können, was wo und in welcher Version läuft, ist eine Bestandsaufnahme der sinnvolle erste Schritt. Wir prüfen Docker- und Container-Umgebungen als Teil unserer IT-Security-Beratung - mit Fokus auf konkrete, umsetzbare Maßnahmen statt auf Berichte, die in der Schublade landen. Für Kunden im Berchtesgadener und Salzburger Land sind wir dabei auch vor Ort.

---