Anfangs ein Spielzeug für Entwickler zum Ausprobieren, haben sich Container als fester Bestandteil moderner Virtualisierungstechnik etabliert. Zur Nachbildung von Hard- und Softwareobjekten sind sie aus immer mehr Geschäftsabläufen nicht mehr wegzudenken. Gleichzeitig steigen die Herausforderungen und Risiken für Anwender im Unternehmenskontext. Im Mittelpunkt dabei: Nutzerrechte und die Behandlung von Sicherheitslücken.

Eine der größten Herausforderungen beim Containereinsatz sind die immer noch fehlenden Standards für Sicherheit und Nutzerrechte. Einen ersten Meilenstein hat hier vor rund einem Jahr die Open Container Initiative erreicht. Ziel der Initiative ist die Sicherstellung von Offenheit, Sicherheit und Rückwärtskompatibilität bei sämtlichen Containerformaten und -Engines. Als Container-Basisformat fungiert das von Docker entwickelte System, genauer dessen Laufzeitumgebung sowie zusammenhängende Spezifikationen. Zudem fließen Erfahrungen der Application-Container-Spec-Initiative Appc ein. Das Problem: Die Eruierung und Festlegung von Standards braucht Zeit. Und so dienen im Moment vor allem die von der Developer- und Container-Community erstellten Best Security Practices als Grundlage für Sicherheitsfragen und Nutzerrechte bei Container-Systemen. Die beiden Grundregeln lauten, das System stets so simpel wie möglich zu gestalten und für jeden Prozess einen eigenen Container einzusetzen.

Doch schon hier lauert der erste Fallstrick, nämlich bei der Nutzung öffentlicher Images. Diese sind in der Regel mit einer Mehrzahl von Applikationen versehen – ein komplizierter Umstand, der das Arbeiten eher erschwert als erleichtert. Als Best Practice empfiehlt sich hier die tägliche Aufbereitung und Aktualisierung sämtlicher Basis-Images von Containern, auf denen Applikationen laufen. Nur so ist das jeweils aktuellste Patch-Level gewährleistet. Um den Aufwand zu minimieren, empfiehlt die Community, in der CI/CD-Plattform Jenkins (Continous Integration/Continous Delivery) entsprechende Jobs einzurichten. Diese bringen sämtliche OS- sowie Applikations-Images regelmäßig auf den neuesten Stand.

Doch wie kam es eigentlich zur – berechtigten – Diskussion um Sicherheit und Nutzerrechte? Gängige Hardware hielt dem Tempo der modernen IT-Welt häufig nicht stand, die Cloud versprach eine Lösung. Doch selbst die virtuelle Maschine schien vielen Nutzern angesichts immer höher getakteter Digitalisierung zu schwerfällig.

Als Vorreiter bei der Lösung dieses Problems fungierte Docker: Mit dem Docker Hub avancierte die Open-Source-Software schnell zum attraktiven Spielplatz für Tüftler und Entwickler. Der Onlinedienst beinhaltet eine Registry für Docker-Images und Repositories. In einem öffentlichen Bereich laden Nutzer optional ihre selbst erstellten Images hoch und stellen sie anderen Nutzern zur Verfügung. Dazu gesellen sich immer mehr offizielle Images, etwa von Linux-Distributoren. In einem privaten Teil des Hubs sind Nutzer in der Lage, ihre Images hochzuladen und beispielsweise nur unternehmensintern zu verteilen. Der Vorteil: Diese Images sind öffentlich nicht auffindbar, was das Sicherheitsrisiko minimiert.

Rasch haben sich die Vorteile der virtuellen Leichtgewichte bewiesen, was zunehmend auch IT-Verantwortliche in Unternehmen auf ihre Möglichkeiten aufmerksam machte. Vor allem im Rahmen von DevOps und CI/CD kommen Container immer häufiger zum Einsatz. Damit wurde aber auch der Ruf nach gesetzlichen Vorgaben, Security Guidelines und Compliance laut.

Typische Fehlerquellen

Cloud und Virtualisierung genossen nicht immer den besten Ruf und sahen sich Vorwürfen mangelhafter Sicherheitsrichtlinien und -vorkehrungen ausgesetzt. Doch heute ist die Cloud Basistechnologie und flächendeckend im Einsatz. Unter anfänglicher Skepsis hatten auch die Container zu leiden. Für Anbieter und Nutzer gleichermaßen bedeutet dies: Zur Einrichtung bestimmter Sicherheitssysteme gibt es de facto keine Alternative.

Das Härten der Systeme ist dabei obligatorisch. Spezieller wird es bei der Behandlung der Images. Vor allem ein frei verfügbarer Zugriff öffnet Sicherheitslücken Tür und Tor. Je leichter der Zugang, desto mehr Images stehen auf den Plattformen für Entwickler bereit – für viele Nutzer ist es ein Muss, ihre Arbeit aus vielen Quellen speisen zu können. Doch mit der Zahl der Images steigt auch die fehlerhafter Dateien. Manchmal reicht schon ein einfacher Schreibfehler oder ein falscher Buchstabe innerhalb des Images, um Angreifern ungebetenen Einlass zu gewähren.

Es gibt zahlreiche Wege, die Sicherheit von Containern zu erhöhen. Bild: Nexinto

Docker stellt seine Software als Enterprise Edition (EE, zum Redaktionsschluss aktuell in Version 17.06.2-ee-6) und Community Edition (CE, aktuell 17.12.0-ce) zur Verfügung. Docker EE ist für unternehmenskritische Deployments optimiert und eignet sich für Plattformen wie CentOS, RHEL, Ubuntu, SUSE Linux Enterprise Server sowie Windows Server 2016. Docker EE Advanced umfasst zusätzlich sowohl Dockers Security Scanning als auch Vulnerability Monitoring.

Schon im Juli 2016 hatte der Anbieter eine neue Runde in Sachen Sicherheitsfunktionen eingeläutet. Vor allem die Zuweisung von Gruppenrechten und die Trennung zwischen routinemäßigen Containeroperationen und Root-Rechten auf dem Server-Host waren erstmals enthalten. Doch die Liste der Sicherheitsanforderungen ist lang. Wer oder was garantiert beispielsweise, dass der dem Image zugrundeliegende Code keine Fehler oder Schwachstellen aufweist?

Viele Unternehmen und IT-Verantwortliche bleiben schlicht untätig oder handeln zu spät. Dies betrifft insbesondere Sicherheitslücken in Software-Stacks und Anwendungsportfolios. Tun sich diese Lücken erst einmal auf, greifen auch alle übrigen Maßnahmen zu kurz. Denn wird der ursprüngliche Open-Source-Code nicht konsequent kontrolliert, kann man lediglich sicherstellen, dass die im Image enthaltenen Bytes diejenigen sind, welche die Entwickler ursprünglich dort eingestellt haben. Die bekannten Schwachstellen der Open-Source-Komponenten bleiben jedoch.

Secure Computing, ebenfalls ein wichtiges Element im Angebot von Docker, räumt den Nutzern mehr Kontrolle über die Applikationen im Container ein. So sind beispielsweise auf spezielle Anforderungen zugeschnittene Systemaufrufe über ein Whitelistening abrufbar. User Namespaces ermöglichen mehr Kontrolle über bestimmte Applikationen und damit verbundene Prozesse. Docker hat seine Hausaufgaben gemacht, der Handlungsspielraum, um Nutzern Rechte zuzugestehen oder eben nicht, ist heute deutlich größer. Wie die Nutzer und Verantwortlichen damit umgehen, steht freilich auf einem anderen Blatt. Denn selbst die fundiertesten Sicherheits-Updates sind unbrauchbar, wenn die zuständigen Mitarbeiter sie nicht adäquat umsetzen und laufend kontrollieren.

Abhilfe gegen Bedenken

Open-Source-Systeme haben sich in der Geschäftswelt etabliert – ebenfalls trotz anfänglicher Bedenken. Einer ähnlichen Herausforderung müssen sich Container stellen. Eine bessere Skalierbarkeit der Anwendungen, weniger Deployment-Fehler oder eine einfachere Anwendungsverwaltung, das sind die Vorteile, die sich Firmen vom Containereinsatz erhoffen. Doch es wird auch künftig viele Unternehmen geben, die auf Container verzichten, solange Standards fehlen. Die Nutzung automatisierter Werkzeuge könnte Abhilfe verschaffen und Vertrauen wecken, doch auch diese Werkzeuge gilt es regelmäßig zu kontrollieren und zu aktualisieren. Und schließlich ist Sicherheit auch eine Frage der Kommunikation. Speziell die Verbindung des Containers zum Host, zwischen einzelnen Containern oder nach außen über das Internet ist streng zu reglementieren. Über Cgroup sollten Nutzer Ressourcen wie CPU oder Memory für Container konfigurieren. So verhindern sie DoS- (Denial of Service) oder Forkbomb-Angriffe auf den Host.

Es empfiehlt sich generell, die Zahl der Container mit Internetzugang zu limitieren. Dies verringert das Risiko von DDoS-Angriffen (Distributed Denial of Service). Zudem können Namespaces einzelnen Nutzern Rollen und Rechte zuweisen. So kontrollieren und reglementieren Unternehmen die Zugriffe auf Informationen in anderen Hosts besser. IT-Verantwortliche sollten bei der Zuweisung von Rechten sehr überlegt vorgehen: Je mehr Rechte vergeben sind, umso mehr verwässert der Schutz.

Auch bei den Images hat bei unter Anbietern ein spürbares Umdenken stattgefunden. So werden viele Images mittlerweile offen abgelegt, hier gelten etwa Red Hat oder Ubuntu als Vorreiter. Nutzer können sich so einen einfachen Überblick über die Bauweise der Images verschaffen. Dies soll unliebsame Überraschungen vermeiden. Auch das Blocken bestimmter Repositories ist eine Möglichkeit, sich vor schadhaften Images zu schützen. Diese Maßnahme erfordert jedoch eine sorgfältige Erstellung entsprechender Richtlinien. Diese könnten beispielsweise nur die Anwendung selbst erstellter Images zulassen, gleichzeitig werden die eigenen Registries gepflegt.

Größtmögliche Sicherheit zu erreichen ist kein einfaches Unterfangen. Doch die Bandbreite an Sicherheits-Tools ist groß – und sie wird weiter wachsen. Einige Beispiele: Branchenprimus Red Hat unterstützt im Container-Betriebssystem Atomic Host DCI-Software (Deep Container Inspection) und das Open Security Content Automation Protocol (OpenSCAP), mit dem Container Sicherheitslösungen identifizieren. Weitere Orchestrierungs- und Management-Tools vereinfachen und automatisieren wichtige Verwaltungsprozesse. So stellt beispielsweise die Plattform Rancher bei Active Directory und LDAP Mandantenfähigkeit sicher, indem es Zugriffsrechte bestimmter Personengruppen und Umgebungen einschränkt. Die Kommunikation zwischen Containern erfolgt über IPSec-Tunnel, die das System automatisch aufbaut.

Michael Vogeler und Jan Wiescher sind Systemadministratoren und Containerexperten beim Managed Services Cloud Provider Nexinto, www.nexinto.com.