Über unsMediaKontaktImpressum
Tim Mackey 30. Januar 2018

Container und Security: IT-Sicherheit gewährleisten!

Container-Technologien sind der nächste Schritt auf dem Weg von physischen, einzeln genutzten Computerressourcen hin zu effizienteren, virtuellen Multitenant-Infrastrukturen, die in herkömmlichen IT-Umgebungen sowie in der Cloud ausgeführt werden können. Neben anderen Vorzügen sind Container ideal für Continuous Integration- und Continuous Delivery-Umgebungen geeignet, die die Entwicklung beschleunigen und den Weg zwischen Entwicklungs- und Produktionsumgebungen weiter optimieren sollen.

Die Container-Technologie ist ein Durchbruch in der ständigen Bemühung darum, die Agilität der Entwicklung zu erhöhen und Produkte schneller auf den Markt zu bringen. Geschwindigkeit und Agilität sind zwar die Schlüsselfaktoren für die Einführung von Containern in Unternehmen, dürfen jedoch nicht zu Lasten der Sicherheit gehen.

Container bieten eine effektive Möglichkeit, eine kompakte, portable Umgebung zum Ausführen von Anwendungen über gemeinsam genutzte Serverressourcen bereitzustellen. Unternehmen sollten jedoch Vorkehrungen treffen, bevor sie diesen Ansatz für die Virtualisierung auf Betriebssystemebene nutzen. Denn die typischen Sicherheitsrisiken der Container-Technologie können auf verschiedene Arten ausgenutzt werden. Schwachstellen können sich schnell vom gemeinsam genutzten Server-Kernel auf eine Ansammlung von Containern verbreiten, die auf einem Server angesiedelt sind. Nicht vertrauenswürdiger Code kann Schwachstellen in einem System ausnutzen und im schlimmsten Fall private, vertrauliche Informationen für Hacker zugänglich machen. Unternehmen, die gesetzlichen Vorgaben unterliegen, können sich keine Sicherheitsverletzungen und daraus möglicherweise resultierende Strafen – einschließlich finanzieller Verluste und Vertrauensverlust bei Kunden – leisten, die durch Angriffe auf die Datenintegrität entstehen.

Sicherheitsrisiken von Containern: Die Herausforderung annehmen!

Um sich auf die spezifischen Sicherheitsrisiken von Containern einzustellen, sind Planung, Wachsamkeit und eine effektive Lösung zur Risikominimierung erforderlich. Die Herausforderung liegt dabei auf zwei Ebenen:

  • Identifizieren von nicht vertrauenswürdigem Code, der den Einsatz von Containern kompromittieren könnte
  • Maßnahmen zur Behebung erkannter Anfälligkeitsprobleme

Container können jederzeit zur Gefahr werden – und das oft ohne Vorwarnung. Es genügt eine einzige Sicherheitslücke (CVE), die sich auf ein Image auswirkt, und alle Container, die mit diesem Image bereitgestellt werden, sind dem erhöhten Risiko einer Kompromittierung ausgesetzt. Da die Verwendung von Containern zur gängigen Praxis wird, werden bestehende Softwareentwicklungs- und Sicherheitsmethoden die Entwicklung, den Betrieb sowie die Verwaltung von Anwendungen, die durch die Containerisierung möglich werden, besser unterstützen müssen.

Einer der Vorteile der Container-Technologie ist die Kompaktheit des Bereitstellungsmodells, das durch die gemeinsame Nutzung von Ressourcen auf dem Server erreicht wird – einschließlich des Betriebssystems und in vielen Fällen Bins sowie Bibliotheken. Das Ergebnis ist ein wesentlich kleinerer Platzbedarf für die Bereitstellung getesteter Anwendungen. Aber dies macht es auch extrem wichtig, dass keine der gemeinsam genutzten Ressourcen durch schadhaften Code kontaminiert ist. Sowohl virtuelle Maschinen als auch Container sind isolierte Konstrukte, aber nur Container teilen sich Schlüsselressourcen.

Root-Rechte und Container-Technologien

Viele Container-Technologien benötigen von Grund auf Root-Rechte, um zu funktionieren. Wenn beispielsweise Anwendungen und Container mit Docker (einer der führenden Container-Technologien) verwendet werden, benötigt der Docker-Daemon Root-Rechte. Selbst wenn die Verwendung von Docker auf "vertrauenswürdige Benutzer" beschränkt ist, können potenzielle Möglichkeiten durch den Docker-Daemon ausgenutzt werden oder durch Anwendungen, die auf dem REST-Modell (Representational State Transfer) basieren, potenzielle Schwachstellen für Hacker eröffnen. Letztendlich läuft es beim Sicherheitsrisiko darauf hinaus, dass die Software im Container sauber ist und keinen bösartigen Code enthält.

Die potenziellen Sicherheitsmängel von Containern hängen oft davon ab, wie die Richtlinien, welche die Interaktionen zwischen Container und Host beeinflussen, festgelegt und verwaltet werden. Wenn eine Anwendung containerisiert wird, muss diese sich nach wie vor auf die Dienste des Betriebssystems verlassen können. Bei dieser Art der Containerisierung wird das Betriebssystem häufig in einer Host-Virtualisierungsumgebung ausgeführt, wobei sich die App im Gast-Container befindet. Diese Grenze, die es dem Gastcontainer ermöglicht, in die Umgebung des Host-Betriebssystems zu kommunizieren, führt zu Sicherheitsproblemen, wenn die Policy nicht korrekt durchgeführt wird. Mit der zunehmenden Verwendung von Open Source-Code in unternehmensweiten Anwendungen sind die Repositories, die dazu dienen, Code für Entwicklungsteams bereitzustellen, die wiederum Container-Images erstellen, nur dann sicher, wenn sie vertrauenswürdig sind. Dateien und Images aus Repositories müssen mit der gleichen Vorsicht behandelt werden, wie ein schnell gemachter Download aus dem Internet: Jeder Download sollte so behandelt werden, als ob schädliche Elemente in den Code eingebettet wären.

Bei all seinen Vorteilen überwindet die Containerisierung nicht die Notwendigkeit der Anwendungssicherheit. Da ein wesentlicher Bestandteil der meisten Anwendungssoftware Open Source-Code ist, müssen Unternehmen über Prozesse verfügen, die sicherstellen, dass Schwachstellen in Open Source, einschließlich in Containern, gepatcht werden, sobald Patches veröffentlicht werden.

Bei kommerzieller Software ist der Anbieter für Bereitstellungsrichtlinien, Benachrichtigungen über Sicherheitslücken und Lösungen für offengelegte Schwachstellen verantwortlich. Wird jedoch Open Source-Software verwendet, verschieben sich diese Verantwortlichkeiten. Als Black Duck in Audits über 1.000 kommerzielle Anwendungen analysierte, stellte sich heraus, dass die durchschnittliche Anwendung 147 spezifische Open Source-Komponenten enthielt. Dabei ist das Verfolgen jeder Variante (Fork), der Version und der Stabilität des Codes im Projekt eine gewaltige Aufgabe für Entwicklungsteams.

Die Sicherheitsrisiken, die mit der Bereitstellung von Software in Containern verbunden sind, sind in der DevOps-Community zu einem wichtigen Thema geworden: Die Operations-Teams stehen unter Druck, Sicherheitslücken in ihren Produktionsumgebungen zu identifizieren. Es kann jedoch für Unternehmen schwierig sein, die Komponenten und Abhängigkeiten in allen Container-Images zu sehen; dies wird noch schwieriger, wenn Security Governance berücksichtigt werden muss.

Kann man darauf vertrauen, dass alle Container im Kubernetes- oder OpenShift-Cluster die Aufgaben ausführen, die man erwartet?

Ein wichtiger operativer Unterschied aufgrund der Beschaffenheit von Containern besteht darin, dass Sicherheitslücken, die in containerisierten Anwendungen identifiziert werden, nicht mit herkömmlichen Patch-Management-Prozessen behoben werden. Stattdessen werden Patches für Container-Images erstellt, indem zum Beispiel das Docker-Image erneuert und dann die vorhandenen aktiven Container durch das aktualisierte Image ersetzt werden. Dieser Paradigmenwechsel erfordert häufig, dass Unternehmen sowohl ihre Patching- als auch ihre laufenden Überwachungsprozesse neu bewerten.

Die Verwaltung der Container-Infrastruktur in einer Produktionsumgebung wird aufgrund des Umfangs der Bereitstellung sogar noch schwieriger. Eines der größten Probleme ist Vertrauen – vor allem das Vertrauen in die Anwendung. Kann man darauf vertrauen, dass alle Container im Kubernetes- oder OpenShift-Cluster die Aufgaben ausführen, die man erwartet?

Minimierung der Sicherheitsrisiken bei Containern

Angesichts des Grads der Nutzung von Open Source-Technologien in der Container-Infrastruktur ist es zum Schutz der Anwendungen in der Produktion äußerst wichtig, die Transparenz der Open Source-Komponenten sicherzustellen und Schwachstellen proaktiv zu patchen, sobald sie veröffentlicht werden. Wenn man von vornherein davon ausgeht, dass Container kompromittiert werden können, sind Attacken deutlich erschwert.

Zentrale Fragen, die Operations-Teams beantworten sollten, um das Risiko zu minimieren, sind:

  • Welche Sicherheitsrisiken bestehen möglicherweise in den Basis-Images für die Anwendungen und wie oft werden diese Images aktualisiert?
  • Wenn ein Patch für ein Basis-Image ausgegeben wird, welches Risiko besteht dann bei der Verwendung dieses Patches?
  • Wie viele Patch-Versionen darf ein Projekt oder eine Komponente zurückliegen, bevor die Nutzung zu riskant wird?
  • Wie schnell ist man über Komponenten-Updates in Bezug auf Abhängigkeiten informiert, die sich direkt auf die Container auswirken?
  • Haben böswillige Akteure angesichts der Struktur einer Komponente oder eines Projekts eine einfache Möglichkeit, sich einen Vorteil zu verschaffen?

Bekannte Sicherheitslücken absichern

Container sollten kontinuierlich überwacht werden, da täglich neue Sicherheitslücken entdeckt werden. Tatsächlich hat die National Vulnerability Database im Jahr 2017 mehr als 13.400 Schwachstellen dokumentiert, was mehr als doppelt so viele wie in 2016 sind. Wenn das Operations-Team Hunderte oder Tausende von Containern gleichzeitig ausführt, wird die Identifikation und Behebung einer neu entdeckten Schwachstelle in jedem Container zu einer großen Herausforderung. Ein Image, das mit den aktuellsten Komponenten erstellt wurde, mag einige Tage oder Wochen nach seiner Erstellung keine bekannten Sicherheitslücken aufweisen, aber irgendwann werden Sicherheitslücken in einer oder mehreren Image-Komponenten entdeckt, und das Image wird nicht mehr aktuell sein. Um sicherzustellen, dass Container vor neu gemeldeten Sicherheitslücken geschützt sind, sollten Unternehmen eine Container-native Sicherheitslösung verwenden, die die Container-Umgebung überwacht und für eine präzise Ermittlung von anomalen und böswilligen Aktivitäten darin sorgt.

Jede Organisation ist anders und muss sicherstellen, dass ihre Herangehensweise an die Sicherheit von Containern an die eigene Container-Umgebung angepasst ist. Es braucht nur einen einzigen anfälligen Container aus Tausenden, um einen Sicherheitsvorfall zu verursachen, weshalb Organisationen den Einblick in jedes Container-Image gleichzeitig benötigen. Tools allein reichen nicht aus – das Unternehmen muss auch über Personen verfügen, die diese Sicherheitslücken beheben können. Tools skalieren, aber Menschen nicht.

Sobald Transparenz bezüglich aller Container vorhanden ist, sollten diese basierend auf ähnlichen Sicherheitsrisiken gruppiert werden. Durch die intelligente Gruppierung wird es Hackern erschwert, eine Kompromittierung auf andere Container-Gruppen auszuweiten, und erleichtert zeitgleich die Erkennung und Eindämmung der Sicherheitslücke.

Abschließend sollte sichergestellt werden, dass das Unternehmen proaktiv bezüglich der Containersicherheit vorgeht. Während Container die Software-Bereitstellung beschleunigen, ist es unverantwortlich, die neuen Risiken zu ignorieren, die sie der Anwendungssicherheit hinzufügen. Die effektivste Methode zur Kontrolle des mit Sicherheitslücken in Containern verbundenen Sicherheitsrisikos besteht darin, Schwachstellen in Basis-Images zu finden und zu entfernen. Der Umfang sowohl der neu offengelegten Sicherheitslücken als auch der Container, die in Produktionsumgebungen bereitgestellt werden, erfordert die Verwendung einer entsprechenden Container-Security-Lösung, die in der Lage ist, Bedrohungen für Container zu verhindern, zu erkennen und darauf zu reagieren.

Spezifische Schwachstellen-Management-Tools für Container

Man darf sich nicht auf herkömmliche Sicherheitstools verlassen, die nicht darauf ausgelegt sind, Sicherheitsrisiken zu verwalten, die mit Hunderten oder Tausenden von Container-Images verbunden sind. Regelmäßige Security-Scans der Infrastruktur berücksichtigen weder die Geschwindigkeit der Entwicklung von Container-Anwendungen noch die Anzahl der sicherheitsrelevanten Offenlegungen. Unternehmen müssen containerspezifische Schwachstellen-Management-Tools und -Prozesse implementieren, um das Risiko einer Kompromittierung zu minimieren.

Ein wesentliches Attribut jeder Container-Security-Lösung besteht in ihrer Fähigkeit, neue Pod-Deployments innerhalb des Container-Clusters zu identifizieren und automatisch den Sicherheitsstatus der Container innerhalb des Pods zu attestieren. Der gewünschte Sicherheitsstatus variiert je nach Anwendung; und Lösungen benötigen ein Policy-Framework, das die Identifikation derjenigen Container auf einen Blick ermöglicht, die gegen die Richtlinien verstoßen. Die fortschrittlichste Container-Security ermöglicht diese Durchsetzung, indem eine Methode bereitgestellt wird, die verhindert, dass Container mit Sicherheitsschwachstellen ausgeliefert werden und Container basierend auf Images identifiziert, die nach der Bereitstellung angreifbar geworden sind. Sie umfasst auch ein zentrales Reporting und die Überwachung des Compliance-Status der Images, um zu verhindern, dass nicht konforme Images ausgeführt werden, wenn bekannte Sicherheitslücken vorhanden sind.

Container beschleunigen zwar die Bereitstellung von Software, bringen aber auch neue Risiken für die Anwendungssicherheit mit sich. Die effektivste und proaktivste Methode zur Kontrolle dieses Sicherheitsrisikos besteht darin, Schwachstellen in Basis-Images zu finden und zu entfernen. Unternehmen sollten daher eine dedizierte Container-Security-Lösung verwenden, die auf die Verhinderung, Aufdeckung und Reaktion speziell auf Container ausgerichteter Bedrohungen spezialisiert ist.

Autor

Tim Mackey

Tim Mackey ist Experte für Open Source-Anwendungssicherheit, Rechenzentrum-Sicherheit, Container, Virtualisierung und Cloud-Technologien. Tim Mackey ist Sprecher bei Konferenzen wie OSCON, CloudOpen, Interop, CA World, Cloud...
>> Weiterlesen
botMessage_toctoc_comments_9210