Thought Leadership
Container haben sich als zentrales Element der modernen Software-Entwicklung und Bereitstellung etabliert. Die Vorteile der Container-Technologie sind unbestreitbar: Betriebssysteme, Applikationen und Konfigurationsdateien werden in einem einzigen Image zusammengefasst, das auf beliebigen Host-Systemen in der Cloud oder On-Premise ausgeführt werden kann.
Laut einer IDC-Studie plant mehr als die Hälfte deutscher Unternehmen, bis 2022 die überwiegende Zahl ihrer Workloads mittels Containern und nicht mehr über herkömmliche Umgebungen bereitzustellen.
Container sind wiederverwendbar, eignen sich für fast alle Aufgaben und ermöglichen schnelle und unternehmensweite Anpassungen durch einfache Verteilung eines neuen Images. In Verbindung mit DevOps wird der gesamte Prozess von der Anwendungsentwicklung bis zur Bereitstellung dramatisch beschleunigt.
Sie vereinfachen die Installation und den Betrieb von Server-Anwendungen sowie deren Management und Verteilung. Sowohl der Rollout von neuen Anwendungen als auch neuen Releases ist problematisch, da die Anwendungen von spezifischen Elementen ihrer jeweiligen Umgebung abhängen. Dazu zählen etwa lokale Einstellungen oder Funktionsbibliotheken. Oft unterscheiden sich die Einstellungen in der Entwicklungsumgebung von denen der Testumgebung und der Produktion. Was ist der Unterschied zu virtuellen Maschinen? Container machen Anwendungen per se unabhängiger von der Umgebung, in der sie ausgeführt werden. Sie agieren damit zwar ähnlich einer virtuellen Maschine (VM). Während eine VM jedoch immer ein vollständiges Betriebssystem sowie Anwendungen enthält, teilen sich mehrere Container einen Betriebssystemkern. Jede Anwendung erhält lediglich einen neuen Benutzer-Adressraum und damit auch eine komplett isolierte Umgebung.
Komplexitätssprünge implizieren Sicherheitsprobleme
Gleichzeitig entstehen durch die Container-Technologie aber auch neue, ganz spezifische Sicherheitsherausforderungen. Container verursachen einen Komplexitätssprung und verkürzen die verfügbaren Reaktionszeiten für die IT-Sicherheit. Unzählige Interdependenzen erschweren die Nachverfolgung von Angriffsvektoren und vergrößern die Angriffsoberfläche in allen Phasen der Build- und Runtime:
1. Container-Images
Entwickler nutzen oftmals Container-Images aus öffentlichen Quellen als Grundlage ihrer Arbeit. Hier können sich Malware oder hartcodierte Anweisungen zum Malware-Download einschleichen. Häufig entstehen außerdem Sicherheitsrisiken, wenn die in Containern enthaltenen Applikationen Schwachstellen aufweisen oder Standardkonfigurationen ungeprüft übernommen werden. Ein einziges kompromittiertes Image verursacht zudem überall dort Probleme, wo es eingesetzt wird. Image-Risiken müssen daher frühzeitig im Build-Prozess und in jeder Image-Iteration identifiziert werden.
2. Container-Registry
Eine Container-Registry ist ein Ort für die zentralisierte Suche, Speicherung und Verteilung von Containern. Die Registry vereinfacht die gemeinsame Nutzung von Containern und ermöglicht es Entwicklern, auf der Arbeit aller anderen Team-Mitglieder aufzubauen. Gelingt Angreifern der Zugriff auf diese Registry, ist oft eine Manipulation der Inhalte möglich, sodass kompromittierte Images unternehmensweit verteilt werden. Deshalb muss kontinuierlich verhindert werden, dass Container mit Schwachstellen bzw. manipulierte Container in die Produktionsumgebung gelangen.
3. Container-Orchestratoren
Orchestratoren wie Kubernetes oder Docker Swarm ermöglichen eine effiziente Verwaltung, Skalierung und Wartung containerisierter Applikationen. Die Werkzeuge bieten hohe Flexibilität durch vielfältige Konfigurationsoptionen. Aber diese Optionen müssen detailliert verstanden und korrekt eingerichtet werden. Fehlkonfigurationen und zu weitreichende Anwender-Berechtigungen stellen ein sehr reales Risiko dar, denn sie können Angreifern den Zugriff auf öffentlich erreichbare Server oder sogar eine Remote Code Execution ermöglichen.
4. Container-Host OS
Oftmals wird vergessen, wie wichtig der Schutz des Betriebssystems auf dem Container Host ist. Alle Host-Betriebssysteme haben Schwachstellen, aber durch entsprechende Sicherheits- und Monitoring-Werkzeuge kann dafür gesorgt werden, dass sich Container wie erwartet verhalten. Das Mounting des Root-Dateisystems auf dem Host im Read-only-Modus beschränkt zudem den Schreibzugriff für Applikationen. Angreifer haben dadurch nur begrenzte Möglichkeiten zur Einfügung bösartiger Elemente in den Container.
5. Container-Kommunikation
Einige Bereiche der Container-Kommunikation bleiben herkömmlichen Sicherheitsarchitekturen verborgen: So lässt sich zum Beispiel der ein- und ausgehende Datenverkehr von AWS EC2 Instanzen per Network Intrusion Detection gut überwachen. Der Datenverkehr zwischen Containern auf derselben EC2 Instanz kann hingegen gar nicht erfasst werden. Häufig sind Container und Microservices außerdem wenige Stunden oder sogar nur Minuten aktiv. Sicherheitsrelevante Zusammenhänge, die nicht innerhalb dieses kurzen Zeitfensters erfasst wurden, gehen verloren.
6. Container-Privilegien
Bei einem privilegierten Container sind die Grenzen zwischen Container und Host-System aufgehoben: Der Container hat Zugriff auf die volle Funktionalität des Hosts, sodass ein erfolgreicher Angriff auf einen privilegierten Container größten Schaden anrichten kann. Legitime, privilegierte Container findet man hauptsächlich in den Bereichen Systemüberwachung und Monitoring, aber auch hier setzt sich aufgrund der Gefahr immer mehr das Least-Privilege-Prinzip durch.
Grenzen herkömmlicher Sicherheitsansätze
Mit den etablierten Werkzeugen und Prozessen stößt die IT-Sicherheit in Cloud- und Container-Umgebungen immer öfter an Grenzen: Die bislang bewährten Sicherheitslösungen sind meist nicht Cloud-nativ und konzentrieren sich nur auf einen der oben genannten Aspekte. Es entstehen Informationssilos, die eine übergreifende Sichtbarkeit verhindern. Ohne automatisiert bereitgestellte Kontextinformationen können Alarme aber nicht sinnvoll priorisiert werden – die Komplexität der Infrastrukturen ist schlicht zu groß.
Die Dynamik der Container-Nutzung macht es zudem schwer, alle sicherheitsrelevanten Vorgänge durch vorausschauende Firewall/Networking-Regeln zu erfassen. Ein Beispiel: Container werden oft mit Regeln aufgebaut, die nur bestimmten Anwendertypen Zugriff gewähren. Im Laufe der Zeit werden sich aber die Definitionen und Gruppenzugehörigkeiten der Anwender wahrscheinlich ändern. Das kann zu unerwünscht weitreichenden Zugriffsberechtigungen führen. DevOps-Teams sind nicht verpflichtet, dies zu berücksichtigen, sodass Risiken entstehen. Um die Falsch-Positiv-Raten zu reduzieren, werden Regeln zudem oft für sehr genau definierte Bedrohungsszenarien geschrieben, was ihre Wirksamkeit in Produktionsumgebungen einschränkt.
Mit Prozess-Monitoring zur Baseline
Investitionen in Fachpersonal und spezialisierte Werkzeuge können diese Probleme nicht dauerhaft entschärfen, zumal durch jede zusätzliche Punktlösung weitere Komplexität entsteht. Bei Unternehmen wächst daher das Interesse an Machine-Learning- und KI-gestützten Ansätzen, die eine lückenlose Überwachung der gesamten Cloud- und Container-Kommunikation sowie automatisierte Datenanalysen ohne manuelle Eingriffe versprechen. Der Aufwand für Regeldefinition und Pflege soll so eliminiert werden können.
Die Visualisierung vereinfacht die Darstellung der Komplexität und die Abhängigkeiten der Applikationen. (Quelle: Lacework)
Um ein vollständiges Bild aller Vorgänge zu ermöglichen, konzentriert sich das Monitoring auf die laufenden Prozesse in der Infrastruktur. Prozesse bilden die kleinsten vom Betriebssystem unterstützten Einheiten und sind verantwortlich für die gesamte Kommunikation, sowohl miteinander als auch mit externen Hosts. Sie haben nachverfolgbare Startumstände, Hashwerte, Zwecke und Lebenszyklen und werden nicht zwischen unterschiedlichen Applikationen gemischt. Anders als Traffic-Monitoring erfasst Prozess-Monitoring somit die Gesamtheit der Kommunikation, auch wenn sie zwischen Containern auf demselben Host oder innerhalb einer Datei stattfindet. Log-Aufzeichnungen bleiben bestehen, selbst wenn ein Container bereits nach ein paar Minuten wieder gelöscht wird.
Auf Basis dieser Informationen erstellt verhaltensbasierte Cloud- und Container-Sicherheit sodann eine fortlaufend aktualisierte Baseline, also eine Karte der normalen Vorgänge in der Umgebung. Die Baseline gibt Auskunft darüber, wie sich ein bestimmter Container in der Vergangenheit verhalten hat, und wie sich andere, vergleichbare Container verhalten. Vor diesem Hintergrund lassen sich alle Anomalien eindeutig identifizieren.
AWS und Lacework-Experten erläutern, wie Amazon Container Services zur einfachen Bereitstellung von Anwendungen genutzt werden kann und wie Lacework die Containersicherheit automatisiert, damit das DevOps-Team schnell und gleichzeitig sicher arbeiten kann. (Quelle: Youtube Kanal DevOpsTV – Automating Container Security with AWS and Lacework)
Welche Vorteile hat verhaltensbasierte Sicherheit?
Durch das Monitoring auf Prozessebene können neu eingeführte Dateien, Hash-Werte und alle Änderungen im Zeitverlauf erfasst werden. Der kontinuierliche Abgleich der Hash-Werte mit einer kuratierten Datenbank ermöglicht die Identifikation von bekannter Malware und Schwachstellen schon in der frühen Build-Phase. Bedrohungen lassen sich so nicht nur in einem, sondern in allen betroffenen Containern erkennen.
Beim Datenverkehr zwischen Containern und mit externen Hosts zeigt der permanente Abgleich mit der etablierten Baseline zuverlässig alle verdächtigen Abweichungen auf, auch wenn sie nicht gegen vorher definierte Regeln verstoßen. Verhaltensbasierte Sicherheit schlägt zum Beispiel Alarm, wenn containerisierte Applikationen unerwartet viele Verbindungen zu neuen APIs starten oder ein Anwender plötzlich Root-Privilegien erhält und sein Verhalten von bekannten Mustern abweicht.
Auf der Orchestrierungsebene ermöglicht das Prozess-Monitoring den Blick in Cluster sowie in die Kommunikation zwischen Clustern. Visualisierungen gehen bis auf Namespace- und Pod-Level. Offene und ungeschützte API-Server oder Management-Konsolen sowie unerwartete Verbindungsversuche dorthin werden als Abweichungen von der Baseline erkannt. Weil die verhaltensbasierte Sicherheit den Normalzustand kennt, kann sie zudem viele reguläre Aktivitäten im Cloud-Datacenter als Bedrohung ausschließen, sodass sich die Belastung durch False Positives und Alarme reduziert. Das ermöglicht es der IT-Sicherheit, auch zukünftig mit Containern und DevOps Schritt zu halten.
*IDC, DevOps in Deutschland, 2020
