Bereits Kunde? Jetzt einloggen.
Lesezeit ca. 8 Min.

Docker, Kubernetes & Co.: So gestalten Sie die Container-Entwicklung sicher


TecChannel Compact - epaper ⋅ Ausgabe 2/2020 vom 31.01.2020

Software-Entwicklung in Container-Umgebungen stellt Unternehmen vor neue Security-Herausforderungen. Erfahren Sie, welche Sicherheitsmaßnahmen Ihr IT-Team umsetzen sollte.


Artikelbild für den Artikel "Docker, Kubernetes & Co.: So gestalten Sie die Container-Entwicklung sicher" aus der Ausgabe 2/2020 von TecChannel Compact. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

› Je beliebter Container im Unternehmenseinsatz werden, desto größer wird das Risiko durch gezielte Angriffe über diesen Vektor. Es gilt, die Umgebungen mit den richtigen Maßnahmen abzusichern. (Foto: Hachi888, Shutterstock.com)


Mit Containern und entsprechenden Orchestrierungs-Tools lassen sich Prozesse und Services im Unternehmen agiler und effizienter gestalten. Sie erleichtern es, Anwendungen und Microservices zu programmieren, zu ...

Weiterlesen
epaper-Einzelheft 16,99€
NEWS 14 Tage gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von TecChannel Compact. Alle Rechte vorbehalten.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 2/2020 von Forrester Cybersecurity Predictions: Ransomware und KI bestimmen in 2020 die IT-Security. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Forrester Cybersecurity Predictions: Ransomware und KI bestimmen in 2020 die IT-Security
Titelbild der Ausgabe 2/2020 von DDoS- und BGP Hijacking: Angriff auf die DNA des Internets. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
DDoS- und BGP Hijacking: Angriff auf die DNA des Internets
Titelbild der Ausgabe 2/2020 von DDoS-Attacken: Rückblick: Das waren die Angriffstaktiken 2019. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
DDoS-Attacken: Rückblick: Das waren die Angriffstaktiken 2019
Titelbild der Ausgabe 2/2020 von Cybercrime als Service: So günstig ist ein Hack im Darknet. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Cybercrime als Service: So günstig ist ein Hack im Darknet
Titelbild der Ausgabe 2/2020 von Cyber-Resilienz: Unternehmen gefährden ihre digitale Transformation. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Cyber-Resilienz: Unternehmen gefährden ihre digitale Transformation
Titelbild der Ausgabe 2/2020 von Cloud-Security: Die dynamische Multi-Cloud. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Cloud-Security: Die dynamische Multi-Cloud
Vorheriger Artikel
Cyber-Versicherung: IT-Risiken richtig versichern
aus dieser Ausgabe
Nächster Artikel Anleitung: Linux-Server rundherum effektiv absichern
aus dieser Ausgabe

... testen, auszurollen und zu verwalten. Dabei zeichnen sie sich dadurch aus, dass sie flexibler, skalierbarer und ressourceneffizienter sind als beispielsweise virtuelle Maschinen (VMs). Allerdings vergrößert die Technologie die Angriffsfläche auf Unternehmen. Sowohl während der Entwicklung, als auch bei der Integration und Bereitstellung sowie im laufenden Betrieb gilt es, Risiken zu minimieren. Das bezieht sich auf die Container selbst, ver- wendete Orchestrierungs-Tools wie Kubernetes und die Infrastruktur.

Container sind größtenteils durch dieselben Risiken wie andere virtualisierte Umgebungen bedroht. Gary Duan, CTO von Kubernetes-Spezialist NeuVector (www.neu vector.com), nennt folgende Sicherheitsprobleme:

DDoS-Attacken auf Anwendungsebene und Cross-Site-Scripting(XSS)- Angriffe auf öffentlich zugängliche Container;

› kompromittierte Container, die geschaffen wurden, um zusätzliche Malware herunterzuladen oder interne Systeme nach Schwachstellen und sensiblen Daten zu scannen;

Container Breakouts (die Isolationsschicht des Containers überwinden) um unautorisierten Zugriff auf andere Container, Host-Systeme oder Rechenzentren zu bekommen. Mitarbeiter des Privileged-Access-Spezialisten Cyberark zeigten mit ihrem Hack der Play-with-Docker-Website (www.cyberark.com/threat-researchblog/ how-i-hacked-play-with-docker-and-remotely-ran-code-on-the-host/), wie effektiv solche Angriffe sein können;

› Mechanismen, die den Container dazu zwingen, viele Systemressourcen zu verbrauchen um die Performance anderer Container zu verringern oder einen Crash zu provozieren;

› Live-Patches für Anwendungen, um schädliche Prozesse einzuführen.

Zudem gibt es Lücken in Kommunikationsprotokollen, die auch im Zusammenhang mit Containern verwendet werden. So gelang es Forschern beispielsweise, die Verschlüsselung der Version 1.3 des Transport-Layer-Security (TLS)-Protokolls mithilfe eines Bleichenbacher-Angriffs zu knacken (www.zdnet.de/88353589/neuer-angriffschwaecht- verschluesselung-per-tls-1-3/).

Des Weiteren werden regelmäßig Schwachstellen in der Verwaltungssoftware Kubernetes entdeckt. So konnten Angreifer über die Sicherheitslücke „CVE-2018-1002105“ Zugriff auf den API-Server der Software erhalten und sich so weitreichende Administratorrechte über Container Cluster verschaffen. Wenige Monate danach wurde mit „CVE-2019-5736“ ein ähnliche Anfälligkeit bekannt. Schafften es Aggressoren, einen Container in ein System einzuschleusen, konnten sie andere Container mit Malware infizieren und beliebige Befehle auf einem Host mit Root-Rechten ausführen. Um sich gegen diese Risiken abzusichern, können sich IT-Teams an den drei Phasen des Container-Lebenszyklus orientieren: Aufbau, Bereitstellung und Betrieb.

Aufbauphase

Während der Software-Entwicklung geht es nach Ausführungen des IT-Sicherheitsspezialisten Palo Alto Networks zuerst darum, festzulegen, wie der gewünschte Endzustand aussehen soll. Das bedeute, sich auf die Beseitigung von Schwachstellen, Malware und unsicherem Code zu konzentrieren. Hierzu sei es wichtig, dass Unternehmen ein offizielles Container-Register einrichten.

Ein solche Container Registry ist dazu da, vertrauenswürdige Images zu erstellen. Es gilt, einen Prozess festzulegen und automatisiert durchzusetzen, der verhindert, dass Container aus einer nicht-vertrauenswürdigen Registry bereitgestellt werden. Dabei ist zu beachten, dass viele populäre Images beispielsweise in der Docker Hub-Registry nur Root-Benutzer angeben. Viele Docker-Image-Autoren versäumen es, den Root-Zugriff zu unterbinden. Die Docker-Engine führt diese Container dann standardmäßig mit den weitreichendsten Zugriffsrechten aus, was erfolgreichen Angreifern ermöglicht, großen Schaden anzurichten.

Über denselben Weg sind auch Attacken denkbar, die „Docker Image Poisoning“ über bösartige Docker-Images von Drittanbietern ausnutzen, die in den Unternehmensservices eingebaut wurden. Der Cloud-Sicherheitsanbieter Redlock hat gezeigt, dass diese Angriffsmethode möglich ist. Laut Bleeping Computer entfernte Docker 2018 17 schädliche Images, die Schadsoftware und Backdoors in die Systeme der Nutzer einschleusten (www.bleepingcomputer.com/news/security/17-backdooreddocker- images-removed-from-docker-hub/).

Als Kriterium für vertrauenswürdige Images nennt RedHat deren Signatur. Mit „Docker Content Trust“ (https://docs.docker.com/engine/security/trust/content_trust/) können Autoren ihre hochgeladenen Images signieren. Bei deren Download verifiziert die Docker-Installation des Nutzers die Signatur und stellt so sicher, dass das Image nicht manipuliert wurde. Zudem sollte das IT-Team sich folgende Fragen stellen:

› Sind Runtime- und Betriebssystemschichten des Containers aktuell?

› Wie schnell und häufig werden die Container durch den Autor aktualisiert?

› Wird auf bekannte Probleme hin überwacht - und wenn ja, wie?

Bereitstellung

Beim Deployment geht es um die korrekte Zusammenstellung der Container. Images, die selbst zwar keine Schwachstelle haben, aber in einem unsicher konfigurierten Kubernetes-Pod bereitgestellt werden, bleiben gefährdet. Ein Pod ist eine Gruppe aus einem oder mehreren Containern mit gemeinsamem Speicher und Netzwerk sowie einem Regelwerk, wie die Container ausgeführt werden.

Für eine sichere Konfiguration sollten Sicherheitsstandards für die Orchestrierung und die Container-Engine erarbeitet und umgesetzt werden. Anhaltspunkte dafür liefern beispielsweise die Benchmarks für Docker und Kubernetes des Center for Internet Security (CIS, www.cisecurity.org/resources/). Damit lässt sich unter anderem der Zugriff von außen regulieren und verhindern, dass beispielsweise Traffic zu Kubernetes-Pods von jeder Quelle akzeptiert wird. Red Hat rät dazu, eine private Registry zu verwenden, um den Zugriff auf die Images, die das Team verwendet, zu verwalten. Nur auf Schwachstellen gescannte und geprüfte Images sollten in die- ses Verzeichnis aufgenommen werden. Über rollenbasierte Zuweisungen lässt sich der Zugang kontrollieren. Die Registry ermöglicht es, Richtlinien für gespeicherte Container Images zu automatisieren und zuzuweisen, um menschliche Fehler zu vermeiden. Zudem bietet es die Möglichkeit, Inhalte wie Image-Metadaten zu verwalten. Dazu zählen beispielsweise Informationen, um bekannte Schwachstellen zu erkennen.

Die folgenden Fragen sollten in diesem Zusammenhang beantwortet werden:

› Welche rollenbasierten Kontrollen können für das Management von Container Images genutzt werden?

› Lassen sich Images über Tagging- oder Kennzeichnungsfunktionen sortieren? Können Images separat für Entwicklung, Prüfung und Produktion als genehmigt gekennzeichnet werden?

› Bietet die Registry sichtbare Metadaten, um bekannte Schwachstellen erkennen zu können?

› Lässt die Zugriffsverwaltung die Zuweisung und Automatisierung von Richtlinien - beispielsweise um Signaturen zu überprüfen oder Scans zu codieren - zu?

Betrieb

Während des Betriebs (Laufzeit) gilt es auch, neue Lücken in laufenden Containern zu finden. Darunter fallen etwa ungewöhnliche Aktivitäten, die auf eine Zero-Day-Schwachstelle hindeuten. Dazu ist es wichtig, einen Normalzustand zu definieren, anhand dessen Abweichungen festgestellt werden können.

Laut Palo Alto Networks (www.paloaltonetworks.com) gestaltet sich die Sicherheit im Betrieb weniger komplex, wenn das Security-Team nicht erst hinzugezogen wird, wenn der Container fertiggestellt ist, sondern im Sinne des Security-by-Design-Prinzips bereits in der Aufbauphase. Werden Sicherheitsprobleme erst während der Laufzeit gesucht und behoben, treten sie wahrscheinlich immer wieder auf, weil die Fehler im zugrundeliegenden Image stecken. Auch laut Red Hat ist es wichtig, die Container gemäß Industriestandards zu managen und automatisiert nach Schwachstellen zu untersuchen. Zudem sollten dabei Richtlinien berücksichtigt werden, die im Ernstfall automatisch Rebuilds der Container auslösen. Es ist in der Regel effizienter und sicherer, einen Container neu zu bauen als ihn zu patchen.

In dieser Phase sollten IT-Teams sich an diesen drei Fragen orientieren:

› Sind Tools zur Komponentenanalyse im Einsatz, mit denen sich Probleme identifizieren lassen?

› Können Werkzeuge entwickelt werden, die eine automatische richtlinienbasierte Implementierung sicherstellen?

› Wie lässt sich das Patching ausgeführter Container vermeiden, so dass sie stattdessen per Trigger mithilfe automatischer Updates neu erstellt werden?

Infrastruktur

Neben den Containern selbst und den Orchestrierungs-Tools bietet die zugrundeliegende Infrastruktur eine Angriffsfläche, die es abzusichern gilt. Dabei sollte laut Red Hat unbedingt die vom Host-Betriebssystem bereitgestellte Isolierung geprüft werden. Um Zugriffe über andere Container oder Breakouts zu verhindern, ist darauf zu achten, dass das System eine maximale Container-Trennung ermöglicht.

Damit die Container-Plattform stabiler wird, sollten Netzwerk-Namespaces eingesetzt werden, um Anwendungen und Umgebungen zu trennen. Mit Namespaces können Administratoren mehrere virtuelle Instanzen der Ressourcen eines Hosts und eines Kernels definieren und getrennt nutzen.

Bezüglich der Infrastruktursicherheit schlägt Red Hat folgende Leitfragen vor:

› Welche Container müssen aufeinander zugreifen können? Wie können Container einander entdecken?

› Wie sollen Zugang und gemeinsame Ressourcen (beispielsweise Netzwerk und Storage) kontrolliert werden?

› Wie werden Host-Updates verwaltet? Müssen alle Container gleichzeitig aktualisiert werden?

› Wie wird der Container-Status überwacht?

› Wie lässt sich die Anwendungskapazität bedarfsabhängig skalieren?

Weitere Sicherheits-Tipps im Kubernetes-Umfeld gibt IT-Security-Expertin Chenxi Wang (https://thenewstack.io/container-security-considerations-kubernetes-deploy ment). Sie rät dazu, auf jeden Fall Linux-eigene Sicherheitsmechanismen wie SELinux und Seccomp Profiles zu nutzen. SELinux ist eine Funktion auf Kernel-Ebene. Sie reguliert Zugriffe auf Dateien und Netzwerkressourcen. Seccomp Profiles beschränkt die Anzahl an Systemaufrufen, die eine Anwendung durchführen darf. Gemeinsam ermöglichen sie eine detaillierte Kontrolle über die Workloads, die auf einem Kubernetes-Knoten laufen. „Knoten“ bezeichnet in diesem Kontext eine Maschine in Kubernetes, die die notwendigen Dienste enthält, um Kubernetes-Pods zu betreiben.

Darüber hinaus sollte die Knotenkommunikation mit einem TLS-Client-Zertifikat gesichert werden, um alle kritischen API-Zugangspunkte durchgängig mit TLS zu verschlüsseln. Allerdings darf hierbei nicht die oben erwähnte Anfälligkeit für einen Bleichenbacher-Angriff vergessen werden.

Auch der direkte Zugang zu Kubernetes-Knoten, beispielsweise via Secure-Shell- (SSH-)Protokoll, sollte eingeschränkt werden. Sind Zugriffe auf Knoten nur über Kubernetes möglich, kann das IT-Team sie dort kontrollieren und loggen. So lassen sich unbefugte Zutritte auf Host-Ressourcen verhindern.

Strategie und Kulturwandel

Container sicher im Unternehmen zu verwenden, ist nicht nur eine Frage der Technik, sondern bedeutet einen grundlegenden Kulturwandel. Laut Thomas Schumacher, Security-Spezialist beim Beratungsunternehmen Accenture (www.accenture.com/ de-de), sollte noch vor Überlegungen zur Wahl und Absicherung der Technologie ein übergeordneter Entscheidungsprozess stattfinden.

Ob und wie Container verwendet werden, lässt sich am Wert für das Business festmachen. Unternehmen sollten sich dazu fragen: „Was wollen wir erreichen?“ und darauf aufbauend „Sind Container dafür ein sinnvolles Werkzeug?“ Hier spielt auch mit hinein, ob die Organisation überhaupt in der Lage ist, die neue Technologie einzuführen und zu verwalten. „Container sind keine Firewall. Unternehmen brauchen also keine Administratoren, sondern gut geschulte Mitarbeiter, die sich mit der Technologie und ihren Anforderungen auskennen,“ fasst Schumacher zusammen.

Anschließend gilt es, eine Strategie für die Einführung zu erarbeiten. Das muss eine aktive Entscheidung des Managements sein, da damit ein grundlegender Change-Prozess einhergeht. Die Funktionsweise von Containern ist eng mit agilen DevOps-Methoden verwandt, so dass die IT-Abteilung dahingehend umgestaltet werden sollte. Dabei ist es wichtig, auch die Security-Verantwortlichen in den Wandel mit einzubeziehen und DevSecOps im Unternehmen zu realisieren.

Neue Prozesse und Governance

Sollen Container-basierte Microservices zum Einsatz kommen, müssen Betriebsprozesse um diese Services herum neu aufgebaut werden. Die etablierten Abläufe aus starren, monolithischen Softwarestrukturen funktionieren dann nicht mehr. So wird etwa klassisches Patch Management von Maschinen durch Pipeline Management abgelöst, mit dem die Veränderungen in den Containern verwaltet werden. Dazu gehören auch Sicherheitsaspekte wie Security Assessments von heruntergeladenen Images, Zugriffsrechte, Kommunikationsbeziehungen oder offene Ports.

Steht der strategische Überbau, gilt es, an die Umsetzung heranzugehen. Dazu rät Schumacher eine passende Architektur zu wählen. Darauf aufbauend sollten die notwendigen Richtlinien festgelegt werden, die das Sicherheitsniveau gewährleisten. Welche Zugriffe und Interaktionen sind für welche Container erlaubt und welche nicht? Anschließend gilt es zu erarbeiten, wie diese Richtlinien eingehalten werden können.

Dabei spielt es eine Rolle, wofür die jeweiligen Container-Anwendungen genutzt werden. In kritischen Teilen der Infrastruktur kann es beispielsweise ratsam sein, von einer Deny-all-Policy auszugehen und jede nötige Beziehung einzeln freizugeben. In anderen, weniger sensiblen Bereichen können die Entwickler von vornherein mehr Zugriffe zulassen.

Selbst entwickeln oder fremde Images verwenden?

Die Entscheidung, ob ein Unternehmen seine Container selbst entwickelt oder vorgefertigte Images verwendet, hängt laut Accenture-Berater Schumacher von den Bedürfnissen und Kapazitäten des Unternehmens ab. Hundertprozentige Eigenbauten werden häufig als sicherer empfunden als fremde Images.

Dabei sollte aber beachtet werden, dass eigene Container auch komplett selbst gepflegt und aktualisiert werden müssen. Bei Docker-Images übernehmen das die Autoren, was den Management-Aufwand für das IT-Team stark reduziert. Zudem kann es sein, dass ein Unternehmen anfangs noch keine eindeutige Vorstellung davon hat, welche Aufgaben es auf welche Art mit Containern lösen will. Investiert es dennoch in die interne Entwicklung, kann es beispielsweise passieren, dass diese Container später nicht mit steigenden Anforderungen mitskalieren. In dieser Experimentierphase können mit fremden Images schneller und einfacher Erkenntnisse gesammelt werden.

Auf der anderen Seite bedeuten fremde Images, dass zusätzliche Sicherheitsschritte in die Bereitstellungsprozesse integriert werden müssen. So sollte beispielsweise bei jeder Aktualisierung eingesetzter fremder Container ein Schwachstellen-Scan des neuen Images durchgeführt werden, bevor es in Betrieb geht.

Jens Dose ist Redakteur des CIO Magazins. Neben den Kernthemen rund um CIOs und ihre Projekte beschäftigt er sich auch mit der Rolle des CISO und dessen Aufgabengebiet.