Die Container-Technologie erfreut sich steigender Beliebtheit. Das ist kein Wunder, schließlich wandern immer mehr Daten und Workloads in Cloud-Infrastrukturen. Das tun sie meistens in Form eines Containers, der sicherstellt, dass das in ihm gebündelte Softwarepaket nach dem Umzug in die Cloud weiterhin stabil läuft. Die Containerisierung von Software gilt als zuverlässige Technologie, um Applikationen und Services sicher auszurollen. Container-Plattformen wie Docker und Singularity erlauben die Implementierung von Best-Practice-Sicherheitsrichtlinien für einzelne Applikationen. Sie schaffen so leicht konfigurierbare Ökosysteme, um containerisierte Lösungen zu entwickeln und auszurollen. Die manuelle Konfiguration beziehungsweise Überwachung von Sicherheitseinstellungen wird überflüssig.

Weil die Container-Technologien jede Menge Komplexität - die üblicherweise in der Absicherung von Applikationen und Services steckt - abstrahiert, wird das von einigen Security Teams fälschlicherweise als Security-Freibrief interpretiert. Das Problem daran ist, dass auch die Container-Implementierung kein idiotensicheres Unterfangen darstellt: Fehler, die an dieser Stelle begangen werden, können zu neuen, mitunter schwerwiegenden Sicherheitsproblemen führen. Wir sagen Ihnen, welche Fehler Sie im Zusammenhang mit Container Security unbedingt vermeiden sollten.

1. Zu viel Container-Fokus

"Der gängigste Fehler beim Versuch sichere Container zu implementieren, besteht darin, sich zu sehr auf den Container zu fokussieren", weiß Cole McKnight, Cloud-Architekt an der Clemson University. Best Practices im Sinne der Container-Sicherheit zu befolgen sei wichtig, so der Experte, aber viele Softwareentwickler konzentrierten sich zu sehr auf die Sicherheit des Images und ließen die Laufzeitumgebung außen vor.

"Ein Container kann in sich so gut abgesichert sein, wie er will - das nützt nichts, wenn er über den Host kompromittiert werden kann", weiß McKnight. "Jeder Rechner, der eine Container-Plattform hostet, muss auf jedem einzelnen angreifbaren Layer abgesichert werden."

Die Container-Engine und die Orchestrierungsplattform müssen so konfiguriert werden, dass die integrierten Container-Sicherheitsfunktionen greifen. "Container-Sicherheit fängt beim Betriebssystem und dem Netzwerk des Hosts an", konstatiert McKnight.

2. Fehlannahmen über Code Libraries

Viele Unternehmen gehen beim Deployment von Containern wie selbstverständlich davon aus, dass die Quellcode-Bibliotheken, die sie zum Einsatz bringen möchten, automatisch sicher sind. Eine verhängnisvolle Fehlannahme, wie Tony Asher, unabhängiger Security-Berater, weiß: "Das schließt auch Libraries in der Entwicklungssuite mit ein. Noch kritischer sind nur Drittanbieter-Libraries, die oft importiert werden, um Entwicklungszeit einzusparen."

Diese Code-Bibliotheken sind potenziell von Schwachstellen behaftet und können - falls eine solche Sicherheitslücke ausgenutzt wird - ein enormes Sicherheitsrisiko für Unternehmen darstellen. Berater Asher empfiehlt deswegen, die Zahl der eingesetzten Bibliotheken auf das Minimum zu reduzieren, das zum erfolgreichen Deployment des Containers nötig ist. Ein Schwachstellen-Scan des Codes und ein Security-Review-Prozess bei Drittanbieter-Bibliotheken sind unabdingbar, wenn es nach dem Experten geht.

Einen formalen Review-Prozess für sichere Architekturen aufzusetzen, kann sich für Unternehmen auf lange Sicht lohnen: Hierbei sollten bestimmte Container, die Risikokriterien erfüllen, von mehreren Experten beurteilt werden. Das hilft dabei, sicherzustellen beziehungsweise zu dokumentieren, dass alle relevanten Risiken in Betracht gezogen wurden.

3. Unnötige Berechtigungen

Es ist gängige Praxis, dass Container mit zu vielen Berechtigungen ausgestattet werden. Dieser Umstand kann von Angreifern ausgenutzt werden: "Setzen Sie auf das Least-Privilege-Prinzip - überwachen Sie dabei aber die Laufzeitumgebung, um sicherzugehen, dass an dieser Stelle kein unbefugter Zugriff möglich ist", empfiehlt Jay Leek, Partner beim Venture-Capital-Unternehmen ClearSky.

Zwar sei es Usus, Container in der Laufzeitumgebung mit Berechtigungen auszustatten, so Cole McKnight. Dies könne aber je nach Software Stack des Hosts unterschiedliche Folgen haben, so der Experte: "Unnötige Berechtigungen innerhalb der Host-Umgebungen können zu Eskalationen führen, die nicht nur in der Kompromittierung des Containers, sondern auch der des Host-Systems enden kann. Ein Container sollte grundsätzlich so aufgebaut sein, dass er über keine unnötigen Berechtigungen in der Host-Umgebung verfügt." Die Rechtevergabe sollte bei Containern deshalb nur sehr granular vorgenommen werden.

4. Zuviel Sichtbarkeit

Ganz ähnlich sollten auch solche Container aufgebaut werden, die im Produktivbetrieb öffentlichen Netzwerken ausgesetzt werden müssen. Nur absolut notwendige Kommunikationskanäle sollten in so einem Fall geöffnet werden.

Bei der Implementierung des Containers selbst müssen zudem zahlreiche Gegebenheiten bedacht werden, wie McKnight weiß: "Container werden durch eine Reihe von Befehlen erzeugt, die in der Image-Spezifikation definiert und bei Erzeugung des Images mit Root-Berechtigungen ausgestattet sind. Viele Entwickler begehen den Fehler, diese Berechtigungen intakt zu lassen, wenn der Container in den Produktivbetrieb geht."

Wird ein Prozess innerhalb des Containers, der mit Root-Berechtigungen ausgeführt wird, in der Laufzeit ausgenutzt, sind die Daten und die Software innerhalb des Containers kompromittiert. Um dieses Problem zu vermeiden, sollten Befehle, die innerhalb des Containers ablaufen müssen, nur von Benutzern ohne Berechtigungen durchgeführt werden können.

Auf Netzwerkseite sollten Sie insbesondere bedenken, welche Prozesse und Daten eines Containers mit anderen Entitäten in Berührung kommen - jede Interaktion zwischen dem Container und externen Datenträgern, Netzwerken und Prozessen sollte einer Prüfung unterzogen werden.

5. Image-basierte Nachlässigkeiten

Ein weiterer Faktor, den Unternehmen beim Deployment von Containern regelmäßig außer Acht lassen, ist das Image, auf dem diese basieren. Besonders Images, die von Dritten bereitgestellt werden, werden oft nur nachlässig überprüft. Bevor Sie einen Container aus einer öffentlichen Registry deployen oder diese als Basis-Image nutzen, empfiehlt sich ein Scan auf Malware und Schwachstellen. Zusätzlich sollte auch ein erfahrener Softwareentwickler einen Blick auf das Image werfen.

"Davon auszugehen, dass öffentlich verfügbare Images per se sicher sind, kann sehr gefährlich sein - insbesondere, wenn solche Images die Grundlage für weitere bilden sollen", gibt McKnight zu bedenken.

6. Mangelnder Prinzipienrespekt

Die Unveränderbarkeit von Images ist eines der Grundprinzipien von Docker, Kubernetes und anderen Container-Lösungen. "Wenn Systeme und Daten über das Internet - ein 'untrusted medium' - ausgerollt werden sollen, muss ein Prozess vorhanden sein, der die Integrität sicherstellt", so McKnight.

Unveränderbare Images bieten eine Reihe von Vorteilen: Sie sind vorhersehbar, skalierbar und automatisch wiederherstellbar - und sorgen für Integrität. Wird dieses Prinzip über Bord geworfen, besteht die Gefahr, dass kriminelle Akteure den Container mit Hilfe von Schadcode kompromittieren können. Dieses Risiko lässt sich nur durch die Überwachung der Integrität der Container minimieren.

"Verbessern und korrigieren sie die Deployment Pipeline, um Veränderungen an produktiven Containern zu verhindern", empfiehlt Asher und fügt hinzu: "Veränderungen sollten ausschließlich in Qualitätssicherungs- und Test-Umgebungen durchgeführt werden. Nach Abschluss müssen die alten Images durch neue, unveränderliche ersetzt werden." (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.