Welche Praktiken sind besonders wichtig?
Beginnen Sie mit vertrauenswürdigen, minimalen Basis-Images
Verwenden Sie gut gepflegte Basis-Images, die nur die Pakete, Bibliotheken und Dienstprogramme enthalten, die die Anwendung benötigt. Dies verringert die Angriffsfläche und erleichtert das Patchen.
Images und Abhängigkeiten vor der Bereitstellung untersuchen
Bei der Untersuchung sollten bekannte Schwachstellen, offengelegte vertrauliche Informationen und offensichtliche Fehlkonfigurationen identifiziert werden, bevor Artefakte in der Pipeline weitergereicht werden. Dies bildet zwar nicht die gesamte Container Security ab, ist aber dennoch eine der praktischsten Maßnahmen, um vermeidbare Risiken frühzeitig zu reduzieren.
Kubernetes-Manifeste und Infrastruktur as Code (IaC) als sicherheitskritische Artefakte behandeln
Workload-Definitionen (z. B. Kubernetes, Pods und Berechtigungen), Helm-Charts (paketierte Kubernetes-Konfigurationen), Terraform (Infrastrukturbereitstellung, d. h. Cloud-Ressourcen und Netzwerke) und andere Bereitstellungsartefakte (beliebige Konfigurationen zum Einrichten von Systemen) können lange vor der Laufzeit Berechtigungs-, Netzwerk- und Expositionsprobleme verursachen.
Das Prinzip der geringsten Rechte im Cluster durchsetzen
Kubernetes-RBAC sollte für Benutzer, Dienstkonten und Workloads sorgfältig konzipiert werden. Übermäßig weitreichender Zugriff erhöht das Risiko von Missbrauch und Rechteausweitung.
Zulassungssteuerung und Richtliniendurchsetzung nutzen
Sicherheitsregeln sind effektiver, wenn sie bei der Bereitstellung automatisch durchgesetzt werden. Zulassungssteuerungen können riskante Ressourcen blockieren, bevor sie für den Cluster zugelassen werden, während Richtlinien-Engines dabei helfen, Anforderungen team- und umgebungsübergreifend zu standardisieren.
Netzwerke segmentieren, um den Schadensradius zu begrenzen
Netzwerkrichtlinien sollten die tatsächliche Kommunikation von Anwendungen widerspiegeln und zugleich unnötigen Ost-West-Datenverkehr begrenzen.
Laufzeitverhalten überwachen
Untersuchungen während des Builds erfassen nicht jedes Laufzeitproblem. Teams benötigen weiterhin Einblick in das Prozessverhalten, Verbindungen, den Ressourcenverbrauch, Richtlinienabweichungen und verdächtige Aktivitäten in laufenden Containern. Daher sollte die Laufzeitüberwachung über den Image-Status hinausgehen und auch laufende Anwendungen, Orchestrator-Aktivitäten und die Kommunikation zwischen Containern abdecken.
Genügend Logs für Untersuchungen erfassen
Container- und Kubernetes-Umgebungen erzeugen Logs auf mehreren Ebenen. Diese Telemetriedaten sind für den Fund und die Untersuchung nach einem Vorfall wichtig.
Wie sollten DevSecOps-Teams diese Kontrollen anwenden, ohne die Bereitstellung zu verlangsamen?
Der effektivste Ansatz besteht darin, die richtige Kontrolle in der richtigen Phase einzusetzen.
In der Build-Phase liegt der Schwerpunkt auf Image-Hygiene, der Untersuchung von Abhängigkeiten, dem Fund von Geheimnissen und der Softwareherkunft.
In der Bereitstellungsphase liegt der Schwerpunkt auf der Validierung von Manifesten, der Richtliniendurchsetzung und der Zulassungssteuerung.
Zur Laufzeit liegt der Schwerpunkt auf der Überwachung des Verhaltens, der Alarmierung, dem Fund von Abweichungen und der Untersuchungsbereitschaft.
Ein mehrstufiger Ansatz ist wichtig, da nicht jedes Problem in dasselbe Gate gehört. Einige Prüfungen sollten die Bereitstellung blockieren, während andere eine Überprüfung, Behebung oder Laufzeitüberwachung auslösen sollten. Erfahrene Teams unterscheiden zwischen zwingend zu behebenden Verstößen und Problemen mit geringerem Risiko, damit Sicherheitsvorgaben durchsetzbar bleiben, ohne zum Engpass zu werden. Ein mehrstufiger Ansatz funktioniert am besten, wenn Teams Quality Gates für Images und Infrastrukturcode einsetzen und diese über den gesamten Lebenszyklus hinweg mit Laufzeitprüfungen und Compliance-Kontrollen kombinieren.
Wie sieht gute Praxis im täglichen Betrieb aus?
In gut verwalteten Umgebungen ist Container Security kein separates Ereignis am Ende des Release-Zyklus, sondern fester Bestandteil der Entwicklung und Auslieferung von Software. Entwickler wissen, welche Basis-Images freigegeben sind, CI-Pipelines führen Prüfungen automatisch durch, Plattformteams definieren klare Leitplanken für Cluster und Sicherheitsteams analysieren Trends, Ausnahmen und wiederkehrende Schwachstellen, anstatt sich ausschließlich auf punktuelle Überprüfungen zu verlassen.
Dieser Betriebsrhythmus ist wichtig, da DevSecOps erfolgreich ist, wenn die Kontrollen vorhersehbar sind. Teams akzeptieren Sicherheitsanforderungen deutlich eher, wenn diese in Tools und Workflows integriert sind, anstatt erst in einer späten Phase als Einwände vorgebracht zu werden.
Was sollten Teams regelmäßig überprüfen?
Gute Programme für Container Security werden kontinuierlich gepflegt und nicht nur eingeführt. Teams sollten regelmäßig überprüfen:
- welche Images freigegeben sind und noch verwendet werden
- ob alte Schwachstellen in neue Builds übernommen werden
- ob Ausnahmen von Sicherheitsrichtlinien im Laufe der Zeit zunehmen
- ob Dienstkonten und Rollen weiterhin übermäßig viele Berechtigungen haben
- ob Netzwerkrichtlinien weiterhin der tatsächlichen Kommunikation zwischen Workloads entsprechen
- ob Laufzeitwarnmeldungen zu sinnvollen Untersuchungen führen oder lediglich unnötiges Rauschen erzeugen
- ob die Protokollierung für die Reaktion auf Sicherheitsvorfälle und deren Nachbereitung ausreicht.
Diese Prüfpunkte helfen, ein schleichendes Abweichen von den Kontrollen zu verhindern – ohne sie können selbst sinnvolle Sicherheitsrichtlinien veralten oder uneinheitlich angewendet werden.
Wo Unternehmen Fehler machen
Ein häufiger Fehler besteht darin, Sicherheit zu weit nach links zu verlagern und anzunehmen, dass die Laufzeit keine Rolle mehr spielt. Der Shift-left-Ansatz ist sinnvoll, doch Container sind dynamisch. Daher bleibt die Laufzeittransparenz wichtig, um verdächtiges Verhalten, missbräuchlich verwendete Berechtigungen und Kontrollversagen zu erkennen, die erst nach der Bereitstellung auftreten.
Ein weiterer Fehler besteht darin, Sicherheitsrichtlinien als externen Prüfschritt zu behandeln, statt sie im Auslieferungsprozess zu verankern. Wenn Entwickler erst am Ende des Prozesses von Verstößen erfahren, wird deren Behebung langsamer und konfliktträchtiger.
Ein dritter Fehler besteht darin, Container zu sichern, ohne die sie umgebende Plattform abzusichern. DevSecOps-Teams können die Qualität von Images verbessern, doch die Zugriffskontrolle auf Clusterebene, Zulassungsrichtlinien, Protokollierung und Segmentierung erfordern weiterhin eine enge Abstimmung mit den Plattform- und Sicherheitsteams.
Was sollte eine praxistaugliche DevSecOps-Checkliste enthalten?
Eine praxistaugliche Checkliste umfasst in der Regel:
- Freigegebene Basis-Images und Nachverfolgbarkeit der Image-Herkunft
- Untersuchung von Images und Abhängigkeiten in der CI
- Fund von Geheimnissen vor dem Merge oder Build
- Überprüfung von Manifesten und IaC auf Sicherheitseinstellungen
- Konzeption von RBAC und Dienstkonten nach dem Prinzip der geringsten Berechtigungen
- Zulassungskontrolle zur Durchsetzung von Leitplanken für die Bereitstellung
- Netzwerkrichtlinien zur Isolierung von Workloads
- Laufzeitüberwachung der Container- und Clusteraktivitäten
- Zentralisierte Protokollierung und Bereitschaft zu Untersuchungen
- Regelmäßige Überprüfung von Richtlinien, Ausnahmen und veralteten Regeln.
Wichtigste Erkenntnis
Eine Best Practice für Container Security für DevSecOps-Teams ist ein Bereitstellungsmodell: Eingaben absichern, Leitplanken für die Bereitstellung durchsetzen, das Laufzeitverhalten überwachen und die Feedbackschleife so kurz halten, dass Entwicklerteams Probleme beheben können, bevor sie zu einem Risiko für den Produktivbetrieb werden.
Integrieren Sie Container Security in Ihre DevSecOps-Pipeline
Wirksames DevSecOps setzt Sicherheitskontrollen voraus, die in den Softwareentwicklungsprozess integriert sind. Kaspersky Container Security unterstützt Teams dabei, Container-Images zu überprüfen, Schwachstellen in laufenden Containern zu erkennen, den Ressourcenverbrauch und die Kommunikation zu überwachen sowie Sicherheits- und Compliance-Prüfungen zu automatisieren.
Quellen und weiterführende Literatur:
