Jeden Tag ein sauberes Image
Von Michael Vogeler, Nexinto
Fakt ist, dass moderne Containersysteme den klassischen virtuellen Maschinen (VM) zunehmend den Rang ablaufen. Unter dem Einfluss von Containern ändern sich die Zuständigkeiten der klassischen virtuellen Maschinen. Diese dienen in der Praxis immer häufiger als eine Art „schlanker Wirt“. Konkret stellen die VMs Compute-Ressourcen wie RAM, CPU oder Netzwerke zur Verfügung. Der Vorteil für den Nutzer liegt auf der Hand: VMs sind weniger sensibel für Angriffe von außen.
Als grundlegendes Container-Format fungiert noch immer das von Docker entwickelte System. Kernstücke sind der darin enthaltene Code der Laufzeitumgebung des Unternehmens sowie zusammenhängende Spezifikationen. Mit dem Docker Hub avancierte die Open-Source-Software schnell zu einem äußerst attraktiven Spielplatz für Tüftler und Entwickler. Der Online-Dienst beinhaltet eine Registry für Docker-Images und Repositories. In einem öffentlichen Bereich kann jeder Nutzer seine selbst erstellten Images hochladen und diese anderen Nutzern zur Verfügung stellen. Dazu gesellen sich immer mehr offizielle Images, etwa von Linux-Distributoren. In einem privaten Teil des Hubs können Nutzer ihre Images hochladen und firmenintern verteilen. Diese Images sind öffentlich nicht auffindbar – damit entfällt ein weiteres Sicherheitsrisiko.
Doch die Verwendung von Docker im Rechenzentrum wirft neue Fragen auf. Denn grundsätzlich steigt damit die Komplexität des gesamten Systems. Schließlich laufen in einem Rechenzentrum wesentlich mehr Container als klassische VMs, und es sind deutlich mehr Betriebssysteme vorhanden, die es zu patchen gilt. Aus diesem Grund werden ebenso mehr Services überwacht. Andererseits bietet ein Container auch weniger Angriffsfläche, da hier in einem geringeren Maße Software zum Einsatz kommt. Somit entsteht durch Container nicht nur ein besseres Lifecycle Management, sondern auch die Möglichkeit von automatisierten Updates im Rahmen von CI/CD-Pipelines und damit verbundenen Deployments.
Standards durchsetzen
In der jüngsten Vergangenheit hat Docker bereits Maßnahmen eingeleitet, um die Sicherheit der Container zu erhöhen. Die Plattform erlaubt heute daher das Zuweisen von Gruppenrechten und die Trennung zwischen routinemäßigen Container-Operationen und Root-Rechten auf dem Serverhost. Insgesamt überwiegen bei der Nutzung von Docker die Vorteile für den Container-Einsatz deutlich. So überzeugt das System durch eigene Security Features: Sämtliche Container erhalten einen eigenen Netzwerktrack. Zudem bedient sich das System Cgroups und Namespaces. Generell besticht Docker ebenso durch ein höheres Maß an Automatisierung, und das System ist schneller zu deployen. Außerdem bringen die Orchestrierungsfeatures von Docker Cluster weitere Security-Bausteine mit, etwa eine Netzwerk-Multi-Tenancy. Früher mussten Administratoren hier aufwendig Firewall-Zugriffe managen, heute macht das der Container-Orchestrator. Auch die automatische Konfiguration von Loadbalancern ist inzwischen eine gern genutzte Selbstverständlichkeit, ebenso die Verfügbarkeit von schnelleren Updates von Stateless Apps und Microservices in Bezug auf OS Security Patches.
Container-Risiken und Sicherheitsmaßnahmen im Überblick (Bild: Nexinto)
Und doch gibt es noch einige Stolperfallen. Diese betreffen vor allem die aufwendige Etablierung von Security-Standards in den Unternehmen und die damit verbundene Bereitstellung von personellen, organisatorischen und auch finanziellen Ressourcen. Das ist ein Aufwand, den viele Unternehmen noch scheuen und dessen Notwendigkeit häufig erst erkannt wird, wenn es zu spät ist. Vor allem kleine und mittlere Unternehmen (KMU) haben hier noch Nachholbedarf. Das Thema Digitalisierung im Mittelstand ist zwar aktueller denn je. Doch schlussendlich gibt es zur Einrichtung bestimmter Sicherheitssysteme keine Alternative.
Problemfeld Images
Eine der häufigsten Fehlerquellen bei Containern ist die Nutzung öffentlicher Images. Damit verbunden ist eine Vielzahl von Applikationen. Experten raten daher, sämtliche Basis-Images von Containern, auf denen Applikationen laufen, täglich aufzuarbeiten und zu aktualisieren. Nur so wird das jeweils aktuellste (und damit sicherste) Patch Level erzeugt. Viele Unternehmen und IT-Verantwortliche bleiben aber schlicht und ergreifend untätig oder handeln zu spät. Dies betrifft insbesondere Sicherheitslücken in Software-Stacks und Anwendungsportfolios. Tun sich diese erst einmal auf, greifen auch alle übrigen Maßnahmen zu kurz. Der ursprüngliche Open-Source-Code muss konsequent kontrolliert werden, sonst wird lediglich sichergestellt, dass die im Image enthaltenen Bits genau diejenigen sind, welche die Entwickler ursprünglich dort eingestellt haben. Die eigentlichen und bekannten Schwachstellen der Open-Source-Komponenten bleiben.
Schwarz auf Weiß
Dieser Beitrag erschien zuerst in unserer Magazinreihe „Rechenzentren und Infrastruktur“. Einen Überblick mit freien Download-Links zu sämtlichen Einzelheften bekommen Sie online im Pressezentrum des MittelstandsWiki.
Vor allem ein frei verfügbarer Zugriff auf Images bietet genug Ansatzpunkte für Sicherheitslücken. Natürlich, je barrierefreier der Zugang, desto mehr Images sind verfügbar. Doch je mehr Images vorhanden sind, desto größer ist auch die Anzahl potenziell fehlerhafter Dateien. Manchmal reicht schon ein einfacher Schreibfehler oder ein falscher Buchstabe innerhalb des Images, um Angreifern unbeabsichtigt Einlass zu gewähren. Eine Lösung wäre in diesem Fall die Bereitstellung eigener Basis-Images, welche so wenig Extrasoftware wie möglich enthalten. Doch die Entwicklung solcher Images erfordert ein höheres Maß an Automatisierung. Auch die erforderlichen Plattformen für CI/CD (Continuous Integration/Continuous Delivery) stehen in den meisten Fällen noch nicht zur Verfügung.
Sicherheitswerkzeuge nutzen
Um den Aufwand zu minimieren, empfiehlt es sich, in der CI/CD-Plattform Jenkins entsprechende Jobs einzurichten. Diese bringen sämtliche OS Images sowie Images von Applikationen regelmäßig auf den neuesten Stand. Anfällige Container werden anschließend mithilfe von Deployments oder Update-Rollouts durch gepatchte Container ausgetauscht.
Das Secure Computing von Docker räumt den Nutzern mehr Kontrolle über die Applikationen innerhalb der Container ein. So sind auf spezielle Anforderungen zugeschnittene Systemaufrufe über ein Whitelisting abrufbar. Auch die Verbindung des Containers zum Host, zwischen einzelnen Containern oder nach außen über das Internet sollten Unternehmen streng reglementieren. Auf diese Weise können etwa DDoS-Angriffe (Distributed Denial of Service) verhindert werden. Eingerichtete Namespaces weisen Rollen und Rechte einzelnen Nutzern zu. So werden Zugriffe auf Informationen in anderen Hosts besser kontrolliert, sprich: reglementiert. Als Faustregel mag gelten: „So eng wie möglich!“
Derzeit gibt es bereits eine gute Bandbreite an hilfreichen Sicherheitstools. Es empfiehlt sich der Einsatz eines Docker-relevanten Hypervisors oder Basis-OS-Hosts wie CoreOS, Atomic Host, RancherOS oder PhotonOS. Diese Betriebssysteme sind abgespeckt und bieten dadurch weniger Angriffsfläche. Ebenso unterstützt Red Hat im Container-Betriebssystem Atomic Host Software für die Deep Container Inspection (DCI) sowie das Open Security Content Automation Protocol (OpenSCAP). Auch Rancher stellt bei Active Directory und LDAP die Multi-Tenancy sicher, indem das System Zugriffsrechte bestimmter Personengruppen und Environments einschränkt. Die Kommunikation zwischen Containern erfolgt über IPSec-Tunnel, die das System automatisch aufbaut.
Mehr Eigenverantwortung
Zumindest Docker hat seine Hausaufgaben gemacht. Die aktuellen Updates erlauben einen größeren Handlungsspielraum, um Nutzern Rechte zuzugestehen oder nicht. Was die einzelnen User (und IT-Verantwortlichen in den Unternehmen) damit machen, bleibt ihnen überlassen. Doch selbst die fundiertesten Sicherheitsupdates sind unbrauchbar, wenn sie von den zuständigen Mitarbeitern nicht adäquat umgesetzt und fortwährend kontrolliert werden.
