Schwachstellenanalyse für Container und Cloud, Teil 2

Container-Sicherheit mit Twistlock

| Autor / Redakteur: Thomas Drilling / Stephan Augsten

Der überarbeitete Vulnerability Explorer von Twistlock 2.1 zeigt sämtliche Risiken in der eigenen Container-Umgebung.
Der überarbeitete Vulnerability Explorer von Twistlock 2.1 zeigt sämtliche Risiken in der eigenen Container-Umgebung. (Bild: Thomas Drilling / Twistlock)

Das Twistlock-Framework verspricht einen integrierten Ansatz, um Container-Sicherheit zu gewährleisten und zu überwachen. Denn im Gegensatz zum traditionellen Vorgehen klinkt sich Twistlock vollständig in die Continuous-Integration-Pipelines z. B. mit Jenkins ein und interagiert nativ mit Docker oder Kubernetes.

Das Unternehmen Twistlock ist mit der Twistlock Container Security Suite seit 2015 am Markt. Der Markt giert offenbar nach entsprechenden Lösungen: In vier Finanzierungrunden wurden 30 Millionen US-Dollar Risiko-Kapital eingesammelt. Inzwischen sitzen fünf Investoren im von Vice President Dima Stopel und CEO Ben Bernstein gegründeten Unternehmen, das heute rund 50 Mitarbeiter beschäftigt.

Das Twistlock-Framework versteht sich als Schwachstellen-Management-Suite für Container. Twistlock kümmert sich dabei nicht nur um das Härten von Containern und Images, sondern auch der Umgebung, in der die Container laufen. Konkret untersucht Twistlock Container auf Exploits sowie auf Anwendungs- oder Konfigurationsfehler und überwacht die Container-Aktivitäten. Dabei erkennt Twistlock Verstöße gegen Sicherheitsrichtlinien, meldet sie und greift bei Bedarf korrigierend ein.

Twistlock unter der Haube

Das Unternehmen Twistlock berät nicht nur Unternehmen beim Absichern ihrer Container-Umgebungen. Mit der Twistlock-Plattform steht auch eine Lösung bereit, die sich um Laufzeitschutz (Runtime Defense), Schwachstellen-Management (Vulnerability Management), Sicherheitsanalysen (Security Analytics), Zugriffskontrolle (Access Control) und vieles mehr kümmert.

Das Besondere dabei ist, dass Twistlock weder Hosts noch den Container Daemon oder die Anwendung selbst anfasst. Trotzdem erkennt Twistlock Schwachstellen auch innerhalb des Linux Distribution Layers, in Bibliotheken und laut Hersteller sogar in App Frameworks wie Node.js oder in selbstgebauten Applikationen. Zudem ergänzt Twistlock die eigene Container-Umgebung um Authentifizierungs- und Autorisierungsmechanismen.

Damit können Entwickler ihre Umgebung besser kontrollieren als mit den hauseigenen Möglichkeiten. Die Authentifizierungs- und Autorisierungsmechanismen integrieren sich auf Wunsch nahtlos mit Kerberos oder LDAP. Im Detail verwendet Twistlock Machine Learning, sodass sich Anwendungen in Echtzeit und automatisch kategorisieren lassen. Daraus generiert Twistlock dann ein Security-Modell, das auf von Twistlock gepflegten Whitelists basiert.

Ebenen der Container-Sicherheit

Schwachstellenanalyse für Container und Cloud, Teil 1

Ebenen der Container-Sicherheit

04.10.17 - Das Absichern von Container-Umgebungen ist eine nicht zu unterschätzende Angelegenheit. Dabei legen Betreiber von Container-Plattformen ihren Fokus eher darauf, die Container-Integrität und die Container Herkunft zu überwachen und zu kontrollieren. lesen

Continuous Delivery

Das Besondere an Twistlock ist, dass die Lösung den kompletten Entwicklungszyklus einer Continuous-Delivery-Pipeline „begleitet“, während beispielsweise Firewalls im Prinzip nur reine Operations-Werkzeuge sind. Statische Codescanner hingegen werden vorzugsweise nur von Entwicklern eingesetzt. Twistlock vereint alle Aspekte in einem Tool, indem es sich als Plug-in z. B. in die Pipeline von Jenkins einklinkt und so einem DevOps-Ansatz ermöglicht.

Twistlock ist in einer für bis zu zehn Repositories und zwei Hosts kostenlosen Developer- und in einer Enterprise-Edition verfügbar. Während sich Policies in der Developer-Edition nur manuell anlegen lassen, Integriert die hier beschriebene Enterprise Edition eine vollautomatische Absicherung via Machine Learning. Die neue Version 2.1 bringt unter anderem erstmals eine Cloud Native App Firewall mit.

Cloud Native App Firewall

Traditionelle Web App Firewall (WAF) agieren stets von der eigentlichen Applikation separiert und „beanspruchen“ zudem immer mindestens zwei „menschliche Ressourcen“. Angenommen ein Entwickler betreibt Wordpress auf Basis einer virtuellen Machine und möchte Traffic zur/von der VM filtern, muss er sein Security-Team bitten, dass dieses ihre WAF passend konfiguriert. Je nach Komplexität des Szenarios müssen ggf. Load Balancer angepasst werden – und möchte man eine andere VM konfigurieren, geht das Spiel von vorne los.

In einem Cloud-native-Szenario hingegen wird die entsprechende App von vornherein im Container entwickelt. Zusammen mit einem Orchestrator werden Annahmen wie die im Beispiel genannte aber zunehmen schwieriger zu verwalten. So hat die App im Container-Environment möglicherweise nicht immer die gleiche IP und hat der Nutzer selbst nicht die volle Kontrolle über die Routing-Topologie, lassen sich auch zugehörige Load Balancer oder Application Filter nicht anpassen. Hinzu kommt, dass sich jedes Mal, wenn eine neue App ausgerollt wird, erneut Operatoren, Entwickler und Security-Team „abstimmen“ müssen.

Die neue Cloud Native App Firewall in Twistlock 2.1.
Die neue Cloud Native App Firewall in Twistlock 2.1. (Bild: Thomas Drilling / Twistlock)

Da aber Twistlock sämtliche Apps auf den Container-Host und den Traffic zu sämtlichen Apps permanent „im Blick” hat, lässt sich der geschilderte Workflow dramatisch vereinfachen. Die neue Cloud Native App Firewall (CNAF) kombiniert dieses Wissen in Bezug auf Platzierung und Visibilität derart, dass sich Anwendungen mit einem Minimum menschlicher Interaktion automatisch schützen lassen.

Die Architektur des Twistlock Defenders.
Die Architektur des Twistlock Defenders. (Bild: Twistlock)

Aktiviert der Nutzer CNAF im oben skizzierten Wordpress-Beispiel, kennt Twistlock automatisch sämtliche „Ausführungsorte” und re-routet eingehenden Traffic zu diesen Containern automatisch über den „Twistlock-Defender“. Dieser weist dem Traffic einen hoch priorisierten applikationsspezifischen Layer-7-Filter zu, der dafür sorgt, dass nur „sauberer“ Traffic zum Container gelangt. Das funktioniert, laut Twistlock, ohne dass Entwickler irgendwelche Änderungen an ihren Images, Containern oder der Container-Architektur vornehmen müssen.

Die Wirksamkeit der CNAF im Twistlock-Monitor.
Die Wirksamkeit der CNAF im Twistlock-Monitor. (Bild: Thomas Drilling / Twistlock)

Twistlock lernt auf Basis seiner ML-Engine dynamisch, wo die entsprechenden Filter anzuwenden sind, filtert den Applikations-Traffic transparent gegen verbreitete Angriffsmuster wie SQL Injection oder Cross Site Scripting, blockt ebenfalls transparent Anfragen von bösartigen Endpoints und stellt sicher, dass nur sauberer Traffic die Applikation erreicht. All das funktioniert, ohne irgendwelche externe Geräte konfigurieren oder IP-Adressen eintragen zu müssen. Das Ergebnis lässt sich in der Twistlock-GUI unter „Monitor / Runtime“ beobachten.

Inhalt des Artikels:

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44899092 / Container & Virtualisierung)