Schwachstellenanalyse für Container und Cloud, Teil 2

Container-Sicherheit mit Twistlock

Seite: 2/2

Firmen zum Thema

Der integrierte Secrets Manager

Viele Organisationen haben eine Enterprise-Secret-Management-Plattform wie z. B. HashiCorp Vault oder CyberArk Enterprise Password Vault im Einsatz, allerdings nicht in erster Linie für Secrets, die für Container bestimmt sind, aber durchaus für andere Anwendungsfälle. Da solche Lösungen ein sicheres zentrales Speichern von Secrets und ein komfortables Audit von deren Gebrauch erlauben, würden viele Unternehmen laut Twistlock gerne eine bestehende Lösung auf Container-Umgebungen erweitern.

Die führenden Container-Orchestrierungs-Plattformen Docker Swarm und Kubernetes bieten von sich aus nativen Support für solche Secret-Distributionen. Dies erlaubt Nutzern das sichere, zentralisierte Speichern und Verwalten von Secrets wie Private Keys, Passwörtern oder Connection Strings. Von dort aus stehen sie z. B. Containern auf Abruf zur Verfügung, damit die sensiblen Informationen nicht in Images eingebettet werden müssen. So können Nutzer beispielsweise ein Docker-Compose- oder Kubernetes-Deployment-File erstellen, das ein solches Secret referenziert.

Bisher bestand eine Einschränkung von Swarm und Kubernetes allerdings darin, dass alle Secrets im Orchestrator selbst gespeichert werden. Twistlock 2.1 bringt nun erstmals einen eigenen „Secrets Manager“ mit. Dieser ermöglicht eine Integration von Twistlock mit HashiCorp und CyberArk, sodass Twistlock das sichere Verteilen von Secrets für die vom Nutzer angegebenen Container erlaubt.

Der neue Secrets Manager erlaubt das Erstellen von Secrets Rules.
Der neue Secrets Manager erlaubt das Erstellen von Secrets Rules.
(Bild: Thomas Drilling / Twistlock)

Da Twistlock die Secrets nie außerhalb solcher Lösungen speichert, mussten die Twistlock-Entwickler ein Verfahren ersinnen, das nahtlos mit den Access-Control- und Key-Rotation-Verfahren beider Lösungen integriert. Daher ist es mit Twistlock 2.1 nun möglich, dass Nutzer ihre existierende Secrets-Management Platform mit der eigenen Container-Plattform verknüpfen, um Secrets für jede gewünschte Applikation sicher bereitzustellen. Praktisch erfolgt dies über das Definieren von Secret Rules im Secrets Manager.

Bemerkenswert an dieser Herangehensweise ist, dass das Secrets-Management nicht in Twistlock selbst passiert. In ähnlicher Weise, wie die Twistlock-Entwickler bereits einige Authorization- und Security-Features für Docker und OpenShift beigetragen hatten, ist das offenbar auch beim Secrets-Management gelaufen. Die Implementation in Twistlock 2.1 setzt auf einem Open-Source-Backend auf, das Twistlock zum Docker-Projekt beigesteuert hat, um den Secrets Manager von Docker Swarm „pluggable“ zu machen.

Andere Hersteller können damit nun ihre eigenen Provider für dieses Plug-in entwickeln, damit Secrets auf sichere Weise von jedem denkbaren Secrets Manager empfangen und sicher in die gewünschten Container injiziert werden können, indem dazu die neue native Fähigkeit von Docker Swarm verwendet wird. Laut Aussage von Twistlock nutzt die Implementation in Twistlock 2.1 das gleiche Framework für das Verbinden von HashiCorp und CyberArk mit Swarm oder Kubernetes.

Vulnerability Explorer

Die meisten Container-Vulnerability-Management-Tools finden und zeigen Nutzern eine Liste der Schwachstellen in ihren Images. Die Twistlock-Entwickler weisen seit geraumer Zeit nicht nur darauf hin, was daran falsch ist, sondern liefern auch die Werkzeuge, um das Problem „von ganz vorne“ anzugehen, etwa mit der Fähigkeit, z. b. Jenkins-Builds ganz zu verhindern und Container damit vor der Ausführung zu schützen, wenn bestimme Vulnerability-Schwellwerte überschritten sind.

Der überarbeitete Vulnerability Explorer in Twistlock 2.1.
Der überarbeitete Vulnerability Explorer in Twistlock 2.1.
(Bild: Thomas Drilling / Twistlock)

So hat man in Version 2.1 weiter daran gearbeitet, dem Nutzer nicht nur eine einfache Vulnerability-Liste zu präsentieren, sondern eine Stack-gruppierte Baumansicht sämtlicher Risiken in der eigenen Umgebung. Auch das funktioniert wiederum, weil Twistlock aufgrund seiner ML-basierten Arbeitsweise sämtliche Container der Nutzer „kennt“ und dieses Wissen für die Risikobewertung einsetzt. Die Ansicht findet sich unter „Monitor / Vulnerabilities“:

Dazu ein Beispiel: angenommen, zwei Images hätten mehrere mit „high“ eingestufte Vulnerabilities. Eines der Images fungiert als Frontend für eine öffentlich zugängliche Web-Anwendung und das Andere als Caching-Layer, der nicht im Netzwerk in Erscheinung tritt. Twistlock „weiß“ wiederum, welche Images mit root-Berechtigung laufen, welchen Images Mandatory Security Profiles fehlen, welche Images Ports nach außen zugänglichen machen oder welche Images Traffic aus dem Internet empfangen.

Eine kontinuierliche, hierarchische Risikobewertung für alle identifizierten Anfälligkeiten.
Eine kontinuierliche, hierarchische Risikobewertung für alle identifizierten Anfälligkeiten.
(Bild: Thomas Drilling / Twistlock)

Twistlock zeigt aber nicht einfach nur beide Images als Liste, sondern kalkuliert eine Risikobewertung für jedes Image, deren Score jeweils exakt davon abhängt, wie der Nutzer die Images deployed hat. Twistlock visualisiert die Risikobewertung in der grafischen Oberfläche im Vulnerability Explorer, sodass der Nutzer jede vorstellbare Anfälligkeit intuitiv erfasst. Da Twistlock auch „weiß“, welche Anfälligkeit welches Packet betrifft, welches Paket in welchem Image steckt, welches Image welchem Container zugrunde liegt und welche Hosts die Container ausführen, erfasst der Nutzer mit einem Klick den gesamten Impakt über sämtliche Objekte. Die Abbildung zeigt die Images-View mit der entsprechenden Risiko-Bewertung als Baum-Hierarchie.

Vulnerability Push Alerts

Auch das Alerting wurde in Version 2.1 deutlich verbessert.
Auch das Alerting wurde in Version 2.1 deutlich verbessert.
(Bild: Thomas Drilling / Twistlock)

Schon länger unterstützt Twistlock Push-Alarme für Events. Nutzer können dazu an zentraler Stelle Alert-Profiles erstellen, die z. B. E-Mail-Adressen oder andere Kanäle bedienen. In Version 2.1 wurde das Feature laut Twistlock deutlich erweitert, z. B. um Rich-HTML-basierte Email-Alarme für die Vulnerability-Erkennung quer durch das Container-Environment. Alarme sind konfigurierbar, sodass Nutzer z. B. spezifische Alarme für ausgewählte Images definieren können, die dann z. B. nur an die Team-Manager gehen, die für diese Images verantwortlich sind, was eine weitgehenden Automatisierung des Prozesses erlaubt. So könnten etwa Development-Teams Push-Benachrichtigungen über neu gefundene Vulnerabilities in Apps erhalten, ohne dass diese selbst etwaige manuelle Scans an der Konsole auslösen müssten.

Fazit

Twistlock ist als Intrusion- und Vulnerability-Scanner, sowie als Analytics- und Überwachungstool für Container- und Cloud-Umgebungen in seiner Arbeitsweise bisher einzigartig und ähnelt einer Kombination z. B. von vRealize Operations Manager und vRealize LogInsight bei VMware vSphere. Allerdings stellen Container deutlich höhere Anforderung an eine solche Lösung, wie z. B. virtuelle Maschinen.

Machine Learning macht´s möglich, insofern ist vor allem die Enterprise-Version von Twistlock für alle Unternehmen interessant, die Container produktiv einsetzen. Es dürfen sich also für viele Unternehmen lohnen, eine Testversion der Enterprise-Edition 30 Tage auszuprobieren.

(ID:44899092)

Über den Autor

Dipl. -Ing. Thomas Drilling

Dipl. -Ing. Thomas Drilling

IT-Consultant, Trainer, Freier Journalist