Container Compliance und Security – Eine große Herausforderung

Kubernetes und Container-basierte Architekturen werden immer mehr zum Standard für den Betrieb moderner Anwendungen. Sie bieten Flexibilität und Skalierbarkeit und unterstützen Unternehmen dabei, schneller und effizienter zu arbeiten. Doch wo neue Chancen entstehen, wachsen auch die Herausforderungen, gerade wenn es um Themen wie Compliance und Sicherheit geht. Wir kennen den Alltag von Unternehmen – ob überlastete DevOps-Teams, Budgetdruck oder hohe Anforderungen an die Sicherheit/Compliance– und wissen, dass Compliance und Security in Kubernetes-Umgebungen oft schwieriger zu erreichen sind, als es auf den ersten Blick scheint. In unserer Blogreihe „Container Compliance und Security“ nehmen wir Sie auf eine Reise in die Welt von Containern mit – und wollen ein Bewusstsein für die Relevanz von Security und Compliance schaffen.

Warum Container-Security doch mehr als nur ein „nice-to-have“ ist

Für viele Unternehmen ist Sicherheit immer noch ein Thema, das am Ende einer langen Prioritätenliste steht – zuerst werden Lösungen evaluiert, dann wird die Lernkurve beschritten. Ist man dann an einem Punkt angekommen, an dem die Mitarbeitenden sich halbwegs sicher im Umgang fühlen, so ist man schon lange mit den Lösungen in Produktion. Die Banane reift beim Kunden.

Während das bis zu einem gewissen Punkt normal und sogar noch vertretbar sein kann, muss man sich vor Augen führen, dass diejenigen, die das Produkt oder die Lösung einsetzen, oft gar nicht besser wissen was ihnen fehlt, da es ihnen ansonsten ja nicht fehlen würde. Manchmal ist es dann ein Vorfall, der sie schmerzlich daran erinnert, dass ein einziger Fehler, eine Nachlässigkeit oder Unwissenheit hohe Kosten und Imageverlust bedeuten kann. In Kubernetes-Umgebungen wächst dieses Risiko, denn Container werden schnell erstellt, verwendet und ersetzt. Doch wer kontrolliert diese Umgebungen? Wer stellt sicher, dass nur vertrauenswürdige Container verwendet werden? Woher wissen die Entwickler, dass sie ein neues Basisimage verwenden müssen, weil das alte voller Sicherheitslücken steckt. Wer hat sich mit der Servicequalität beschäftigt und wie werden Umgebungen voneinander isoliert?

Klingt erst einmal ziemlich viel und das ist es auch, wenn man diese Punkte im Nachhinein klärt. Aus unserer Sicht kann DevOps in gewissen Situationen auch “unfair” bedeuten, denn die Verantwortung wird durch den „Shift-Left“-Trend mehr in Richtung der Entwicklung abgegeben, ohne dass diese darauf vorbereitet ist.

Daher sehen wir hier zum Beispiel den Punkt des Enablements von Teams. Es gibt Lösungen, die den Druck raus nehmen und Teams befähigen die Anforderungen zu erfüllen. Allerdings sollte man nicht erwarten (das wäre der unfaire Teil), dass ein Softwareentwickler eine Zusatzausbildung als Netzwerkspezialist machen muss.

Der Status der IT-Sicherheit lässt sich gut mit dem Besuch beim Zahnarzt vergleichen, denn auch hier gilt: Vorbeugen ist besser als heilen.

Damian Izdebski, CEO der techbold technology group

Typische Herausforderungen für Unternehmen

Wir begegnen in der Praxis häufig Entwicklern und IT-Abteilungen, die sich allein gelassen fühlen, wenn es um die Sicherheit ihrer Container geht. Sie kämpfen mit dem “Shift-Left”-Ansatz, in dem Sicherheitsverantwortung frühzeitig auf die Entwicklerteams verlagert wird. Das Resultat: Überlastete Teams, die nicht nur code-, sondern auch sicherheitsorientiert arbeiten sollen, während das eigentliche Tagesgeschäft leidet. Ohne klare Sicherheitsstandards und -richtlinien droht die Gefahr, dass unsichere Container in Produktion gehen, was nicht nur das Unternehmen, sondern auch dessen Kunden gefährdet.

Unsere Lösung

Um diesen Herausforderungen zu begegnen, setzen wir auf Technologien wie Container-Image-Scanning mit Tools, die Schwachstellen in Abhängigkeiten und Images schon in der CI/CD-Pipeline erkennen. Policies und isolierte Container-Workloads durch Netzwerk-Policies verhindern zudem das seitliche Bewegen von Angriffen innerhalb des Clusters. So können Unternehmen sicherstellen, dass Container-Security nicht nur ein optionaler Zusatz, sondern ein unverzichtbarer Teil Ihres Betriebs wird. Doch auch der laufende Betrieb kann und muss kontrolliert sein um sicherzustellen, dass nicht doch irgendwo Daten abfließen und/oder unerwünschte Prozesse ausgeführt werden.

Und wenn man alles aus einer Hand haben möchte, dann bietet sich eine Lösung wie NeuVector an, um die gesamte Umgebung inkl. Laufzeit betrachten zu können. Hier mehr über Full Lifecycle Container Security erfahren!

Schwachstellen – Und warum niemand darüber spricht

In vielen Unternehmen läuft Kubernetes “irgendwie” – und das seit Jahren. Für manche ist Kubernetes fast zu einem “Set-and-Forget”-System geworden. Solange es läuft, wird wenig hinterfragt, und Sicherheits- oder Compliance-Fragen werden oft als zusätzliche Kosten angesehen, die man lieber vermeidet. Leider führt diese Haltung dazu, dass sich technische Schulden anhäufen, die zu gravierenden Problemen führen können.

Das verheerende dabei ist: oft schleichen sich diese Schulden ein, weil man es einfach nicht besser weiß. Kubernetes ist ein komplexes Gebilde und liefert von Haus aus nichts mit, was man aus der klassischen IT kennt. Monitoring, Logging, Authentifizierung, Isolation, Policies und vieles mehr muss nachgebaut werden. Auch wenn man auf gemanagte Lösungen von Cloudanbietern setzt, bleibt noch genug übrig, um kostbare Zeit und Ressourcen zu investieren um einen Stand zu erreichen, den man als zuverlässig und solide bezeichnen kann.

Eine häufige Alltagssituation bei Unternehmen

Ein klassisches Beispiel ist der DevOps-Leiter, der sich bewusst ist, dass die Software teilweise outdated ist und Best Practices ignoriert werden – aber kaum Kapazitäten hat, die Systeme auf den neuesten Stand zu bringen. Ist es dann einmal so weit, so sind die Nerven angespannt: Hat man an alles gedacht? Ist der Mitarbeiter, der Lösung XYZ beherrscht, dann auch da und nicht krank? Wie teste ich, dass meine Lösung hinterher noch genau so funktioniert wie vorher?

Auch achtet man häufig nur auf das eigene Projekt, aktualisiert Software, die man selbst programmiert hat – nicht aber das ganze drumherum. In Gesprächen mit Unternehmen erfahren wir oft, dass die eigentliche Vision einer hochperformanten, sicheren und skalierbaren Kubernetes-Umgebung von zu vielen Einzelanpassungen und Workarounds unterlaufen wird. Wie soll es auch anders sein, wenn man unterschiedlichen Teams immer wieder die selben Aufgaben übergibt, aber nicht für Standards, Best Practices oder ein homogenes Toolset sorgt, bei dem sich die Mitarbeitenden untereinander austauschen und dazu lernen können?

Ein Fazit

Container-Security ist definitiv mehr als nur ein „nive-to-have“ – für uns sogar ein „must-have“. Es gibt Schwachstellen, die unbedingt rechtzeitig berücksichtigt werden sollten – und nicht erst, wenn es zu spät ist. Um all die technischen Schulden abzubauen, empfehlen wir regelmäßige Härtungs-Checks. Nach dem Erzeugen einer Baseline ist jedes Update mess- und vergleichbar. Auch die Einführung von container-isolierenden Runtimes bietet eine zusätzliche Schutzschicht, die das Risiko eines Exploits signifikant verringert. Containerimages werden direkt beim Erstellen geprüft und vorhandene Registries selbstverständlich regelmäßig ausgewertet. Auch werden manuelle Eingriffe auf ein Minimum reduziert.

Mit diesen Best Practices wird sichergestellt, dass Kubernetes-Umgebungen sowohl sicher, als auch skalierbar bleiben. Gerne beraten wir Sie dahingehend!