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 testen, auszurollen und zu verwalten. Dabei zeichnen sie sich dadurch aus, dass sie flexibler, skalierbarer und ressourceneffizienter sind als beispielsweise virtuelle Maschinen (VMs).
Foto: Hachi888 - shutterstock.com
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, verwendete Orchestrierungs-Tools wie Kubernetes und die zugrundeliegende Infrastruktur.
Die Gefahren
Container sind größtenteils durch dieselben Risiken wie andere virtualisierte Umgebungen bedroht. Gary Duan, CTO von Kubernetes-Spezialist NeuVector, 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, 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. Zum Beispiel gelang es Forschern, die Verschlüsselung der Version 1.3 des Transport-Layer-Security (TLS)-Protokolls mithilfe eines sogenannten Bleichenbacher-Angriffs zu knacken.
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 einrichteten.
Ein solches 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 DockerHub-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. 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.
Als Kriterium für vertrauenswürdige Images nennt RedHat deren Signatur. Mit "Docker Content Trust" können Autoren ihre hochgeladenen Images signieren. Bei deren Download verifiziert die lokale Docker-Installation des Nutzers die Signatur und stellt so sicher, dass das Image aktuell ist und 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). 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 nach Schwachstellen gescannte und geprüfte Images sollten in dieses 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 zu, Richtlinien zuzuweisen und zu automatisieren, beispielsweise um Signaturen zu prüfen oder Scans zu codieren?
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 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. 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 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, 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 beispielsweise 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.