Suchen

Ein sicherer Hafen für Container Strategien und Technologien für die Containersicherheit

| Autor / Redakteur: Gunnar Braun * / Stephan Augsten

Hadern Unternehmen mit der Container-Einführung, liegt das nicht selten an den Sicherheitsherausforderungen, die mit dem Einsatz von Containern in Produktionsumgebungen verbunden sind. Wie bei jedem Einsatz einer neuen Technologie gilt es, die Zahl der potenziell ausnutzbaren Schwachstellen und Risiken zu senken.

Firmen zum Thema

Trotz einer gewissen Abgrenzung und anderer Vorteile gilt es auch bei Containern, bei der Sicherheit nachzuarbeiten.
Trotz einer gewissen Abgrenzung und anderer Vorteile gilt es auch bei Containern, bei der Sicherheit nachzuarbeiten.
(Bild: andasta / Unsplash)

Container haben vor inzwischen annährend fünf Jahren einen regelrechten Hype ausgelöst. Sie sind besonders bei den Unternehmen beliebt, die ihre IT-Abläufe von physischen Single-Tenant Computerressourcen auf eine effizientere, virtuelle Multi-Tenant-Infrastruktur umstellen. Das durch Docker populär gewordene Container-Framework vereinfacht und beschleunigt die Bereitstellung von Anwendungen, indem es Betriebssystemkomponenten, Anwendungen und alle Abhängigkeiten innerhalb der Ebenen in so genannten Container-Images zusammenfasst.

Aufgrund ihrer zahlreichen Vorteile bilden Container eine zusätzliche Ebene im Application Stack, und genau das erfordert eine neue Denkweise in Bezug auf die Anwendungssicherheit. In seinem Application Container Security Guide weist das NIST ausdrücklich darauf hin, dass Unternehmen ihre Sicherheitsstrategien an die neuen, dynamischen Produktionsumgebungen anpassen sollten. Container haben die Anwendungssicherheit revolutioniert.

So wie herkömmliche Anwendungen anfällig für Angriffe sind, sind das auch containerisierte Anwendungen und die Container, in denen sie gespeichert sind. Wenn Firmen eine effektive Strategie für die Containersicherheit entwickeln wollen, beginnen sie am besten damit, die Risiken zu verstehen, die Containerisierung grundsätzlich mit sich bringen kann. Dazu einige Überlegungen:

Isolierung

Die Container-Isolierung unterscheidet sich von der Isolierung bei herkömmlichen virtuellen Maschinen (VMs). In VM-Systemen gewährleisten Hypervisoren diese Isolierung und schränken so die Möglichkeiten eines Angreifers ein, sich bei Sicherheitsverletzungen zwischen VMs (und somit innerhalb der Gesamtanwendung) zu bewegen. Container-Anwendungen benötigen jedoch keine Hypervisoren; stattdessen teilen sie sich Elemente des Host-Betriebssystems.

Bei Containern ist damit zwar ein gewisses Maß an Abgrenzung gegeben, aber alle im System vorhandenen Container-Instanzen teilen sich einen Kernel. Einige Unternehmen befürchten deshalb, dass bei der Verwendung von Containern im Falle einer Sicherheitsverletzung mehr sensible Daten offengelegt werden könnten als in VM-Systemen. Die sind zwar im Vergleich zu den leichtgewichtigen Containern etwas träge, aber bei ihnen lässt sich die Reichweite eines Angreifers einschränken.

Komplexität der Laufzeitumgebung

Die Dynamik von Containern führt zu neuer Komplexität bei der Laufzeitumgebung. Teams, die für die Anwendungsbereitstellung zuständig sind, müssen diese neuartige Komplexität verstehen und verwalten. Containerisierte Anwendungen können den Host aufrufen, um Zugriff auf Ressourcen wie z.B. Dateien auf gemeinsam genutzten Speichersystemen zu erfragen. Gelingt es einem Angreifer, eine containerisierte Anwendung zu kompromittieren, erlangt er möglicherweise Zugang zu sensiblen Informationen auf den gemeinsam genutzten Systemen. Aus diesem Grund sollten betriebliche IT und IT-Sicherheit das Verhalten ihrer Container überwachen und nicht autorisierte Aktivitäten unterbinden.

Schwachstellen-Management

Die meisten Container-Images werden aus Basis-Images erstellt, bei denen es sich im Wesentlichen um begrenzte, leichtgewichtige Betriebssysteme handelt. Anwendungs-Container-Images kombinieren Basis-Images mit anwendungsspezifischen Elementen wie Frameworks, Laufzeitumgebungen und den Anwendungen selbst. Jede Ebene in einem Container-Image ist aber auch eine potenzielle Angriffsfläche. Sie kann Software-Schwachstellen aufweisen und dadurch ein Risiko für das Unternehmen bedeuten.

Es lässt sich allerdings nicht ganz so einfach herausfinden, wo genau diese Risiken liegen. Gerade wenn man bedenkt, dass einige Cluster dank Microservice-Architekturen die Größenordnung von 10.000 Images oder mehr erreicht haben. Selbst wenn ein Unternehmen alle eingesetzten Container gescannt hat, muss es sie weiterhin auf neu entdeckte Schwachstellen überwachen – und das auf jeder einzelnen Ebene.

Strategien und Technologien für die Containersicherheit

Das Absichern von Container-Clustern ist auf den ersten Blick eine überwältigende Aufgabe. Aber Sicherheitsteams, die Passwörter, Kundendaten, personenbezogene Daten und andere sensible Informationen schützen, können und sollten die mit Containern verbundenen Sicherheitsrisiken kontrollieren. Mit den richtigen Tools, Praktiken und Strategien lassen sich die oben beschriebenen Herausforderungen bei der Containersicherheit bewältigen und containerisierte Anwendungen vor Angriffen schützen.

Eine Patentlösung gibt es natürlich nicht. Daher sollten Unternehmen Techniken und Lösungen miteinander kombinieren, die ihren individuellen IT-Governance-Anforderungen am besten entsprechen. Im Folgenden sind einige wesentliche Aspekte der Containersicherheit aufgeführt, die unterschiedliche Ebenen des Container Stacks abdecken.

Sichern der Containerplattform

Bevor Sie mit der Sicherung der Container beginnen, müssen Sie sich mit der jeweiligen Containerplattform vertraut machen, z. B. Docker, Kubernetes oder OpenShift. Man kommt nicht umhin, die Konfigurationsmöglichkeiten der Plattform zu verstehen und sie entsprechend den Anforderungen des jeweiligen Unternehmens angemessen zu sichern.

Standardkonfigurationen sind oft so ausgelegt, dass sie die Benutzung erleichtern und viele Anwendungsfälle berücksichtigen. Einschließlich solcher, die in Produktionsumgebungen nicht geeignet sind (wie offene Ports und Berechtigungen zu Debugging-Zwecken). Die Konfigurationen in punkto Sicherheit zu überprüfen trägt dazu bei, die Plattform zu härten und das Prinzip der minimalen Rechtevergabe durchzusetzen.

Sichern des Hosts

Dieser Aspekt ist gleichermaßen fundamental wie offensichtlich: Wenn jemand in der Lage ist, eine Root-Shell auf dem Host-System zu starten, spielt es keine Rolle mehr, welche Sicherheitsmaßnahmen in höheren Ebenen implementiert sind. Die gute Nachricht ist, dass es sich um ein bekanntes Phänomen handelt. IT-Sicherheitsunternehmen sind damit vertraut. Die Sicherheitskriterien für Hosts mit Containern sind die gleichen wie für jedes andere exponierte oder kritische System auch.

Anwendungssicherheit bei Containern

Anwendungssicherheit sollte proaktive und reaktive Mittel einschließen. Der proaktive Teil umfasst statische und dynamische Scans, die in den Bereichen SAST, DAST, IAST und Software Composition Analysis (SCA) zu finden sind. Moderne AST-Tools sind in der Lage, Container zu scannen, und verfügen über spezielle Methoden für dieses Einsatzgebiet, wie z.B. das Erkennen der einzelnen Ebenen innerhalb eine Container-Images.

Das ist wichtig, da die Ebenen aus verschiedenen Quellen stammen können. Das macht es nötig, sie bei der Fehlerbeseitigung anders zu behandeln. Container-Laufzeit-Sicherheitslösungen tragen dazu bei, böswillige Aktivitäten in laufenden Containern in Echtzeit zu erkennen und zu blockieren. Diese funktionieren prinzipiell wie Intrusion Detection (IDS) oder Prevention Systeme (IPS) und dienen so als letzte Verteidigungslinie gegen böswillige Akteure.

Die Build-Pipeline schützen

Eine Anwendung ist nur so sicher wie der Prozess, innerhalb dessen sie entwickelt wird. Angreifer attackieren zunehmend CI/ CD-Pipelines (Continuous Integration/Continuous Delivery) und versuchen, Build-Server, Code-Repositories oder Workstations von Entwicklern zu kompromittieren. Diese Systeme werden immer komplexer. Deshalb ist es wichtig, eine sichere Zugriffskontrolle für die gesamte Pipeline zu implementieren und das Prinzip der geringsten Berechtigungen („least privilege“) konsequent anzuwenden: Überprüfen Sie sorgfältig, wer Zugriff auf welchen Teil der Pipeline (wirklich) benötigt, und weisen Sie nur die niedrigste erforderliche Berechtigungsstufe zu.

Fazit

Das Entwicklungsteam entscheidet über die Bereitstellung von Anwendungen, z.B. in Bezug auf Container-Basis-Images und Image-Konfigurationen. Das setzt voraus, dass bei der Container-Entwicklung ausreichend Kompetenzen vorhanden sind, um die Produktionssysteme korrekt abzusichern. In der Realität führt das allerdings nicht selten zu Konfigurationen, die alles andere als sicher sind.

Ein Beispiel. Das Entwicklungsteam stellt fest, dass eine interaktive SSH-Shell beim Debuggen ihrer Anwendung während der Entwicklung hilfreich ist. Dieselbe interaktive Shell kann, wenn sie in ein Produktionssystem eingebunden ist, zu einem Teil der Kill-Chain bei einem Angriff werden. Wenn dieser Container dann aufgrund von Entscheidungen im Entwicklungsprozess so konfiguriert ist, dass er mit erhöhten Berechtigungen ausgeführt wird, ist potenziell das komplette Containersystem kompromittiert.

Um diese Art von Problemen zu lösen, müssen alle Teams, von der Entwicklung bis zum Betrieb, ihre Stärken wirklich ausspielen und zusammenarbeiten. Das ordnungsgemäße Sichern von Container-Images erfordert nicht nur AppSec-Kompetenzen, sondern auch Kompetenzen im Härten von Betriebssystemen, mit denen man die Basis-Images ordnungsgemäß absichert. Dieselben Kompetenzen beim Härten von Betriebssystemen lassen sich dann auf Hostebene nutzen, um das Potenzial der Containerinfrastruktur auszuschöpfen - eine schnelle und sichere Methode zur zuverlässigen Bereitstellung von Anwendungen.

* Gunnar Braun ist Technical Account Manager bei Synopsys und unterstützt große Unternehmen bei der Erstellung von sicherer Software. Er beschäftigt sich seit 20 Jahren mit Werkzeugen für die Software-Entwicklung. Seit 5 Jahren konzentriert er sich auf den Bereich Software-Sicherheit, mit Fokus auf Integration von Werkzeugen in agile Entwicklungsprozesse.

(ID:46868217)