Neuer Schauplatz der Cybersicherheit
Gefahrgut im Container
Fortsetzung des Artikels von Teil 1
Risiken der Registry und der Images
Ein Image aus einer Registry mit Schwachstellen kann ein Vielzahl von Sicherheitsproblemen verursachen. Über sie können Kriminelle sehr einfach Malware installieren. Haben Angreifer etwa ausgehend von einem beliebigen Anwenderrechner im Unternehmensnetz über laterale Bewegungen Zugriff zu einer privaten lokalen Registry, können sie dort nach Gutdünken ihre eigenen kompromittierten Images platzieren.
Öffentliche Registries, beispielsweise Docker Hub, bieten überprüfte, aber auch nicht überprüfte Images, die eventuell Kriminelle hochgeladen haben. Hier geben die Angreifer ihnen oft Namen, die denen einer legitimen Image ähneln. Wer zum Beispiel das Image „DotNetFramework“ sucht und auf die Schnelle aus Versehen „DotNetFramework01“ portiert, greift unter Umständen auf ein bösartiges Container-Image zurück.
Generell sollten Entwicklungsteams nur sichere, geprüfte und aktualisierte Images aus einer sicheren Quelle verwenden. Image-Sparsamkeit ist ein weiterer Weg, Sicherheit zu schaffen. Denn in einen Container gehört nur das, was eine Applikation wirklich benötigt. Selbst in einer privaten Registry sollten Anwender genau prüfen, woher die genutzten Images stammen, und ob in der Zwischenzeit Sicherheitsrisiken für diese ans Licht gekommen sind.
Ein weiterer Gefahrenschauplatz sind die Laufzeitumgebungen eines Containers. In jeder Applikation gibt es schwächere Glieder in der Sicherheitskette, die anfälligere, zum Beispiel nicht aktualisierte Applikationen enthalten können – mit unter Umständen schwerwiegenden Folgen: Stellt eine containerbasierte Applikation zum Beispiel öffentlich eine Website bereit, so können Externe über das Web direkt auf die Container zugreifen, ohne einen weiteren Zugang auf das Unternehmensnetz zu haben. Angreifer installieren dann ihre eigene Applikation – beispielsweise einen Cryptominer oder ein DDos-Tool – direkt im Container. Sie können recht einfach ein Betriebssystem-Image installieren und so ihre Angriffe ausführen. Von einem Container aus verschaffen sie sich Zugriff auf den eigentlichen Host und bewegen sich dann im Unternehmensnetz. Um derartige Risiken einzuschränken, verwenden IT-Organisationen einen robusten Laufzeitschutz, der die Prozesse und Aktivitäten innerhalb jedes Containers sowie den Container-Host selbst überwacht.
Ein Container läuft auf einem traditionellen Server mit seinem Betriebssystem. Damit betreffen die Schwachstellen des Servers ebenso die Container. Angreifer haben dann unter Umständen Zugriff auf die gesamte Applikation. Schwachstellen auf Ebene des Servers und der Container-Laufzeit oder einfache Fehlkonfigurationen können Angreifern die Möglichkeit bieten, ihre eigenen Container auszuführen oder vorhandene für ihre Zwecke auszunutzen. Unter Umständen können sie einen Host ganz lahmlegen.
Als Gegenmaßnahme sollte man nur Linux-Distributionen verwenden, die die Anbieter speziell für das Ausführen von Containern entwickelt haben. Außerdem sollten IT-Administrationsteams auf jedem Host-Server eine Reihe von Sicherheitskontrollen installieren. Produkte für Containersicherheit suchen ständig nach neuen Schwachstellen, die seit Einrichten des Hosts entstanden sind, um sie zu patchen. Sie überwachen die Risiken des genutzten Betriebssystems gemäß den Richtlinien für die Sicherheitskonfiguration.
Eine Plattform zum Orchestrieren von Containern im Cluster bietet ebenfalls ein Angriffsziel. Hier muss die Cybersicherheit den Zugriff auf die Plattform durch Dritte verhindern. Denn sollten Anmeldeinformationen der Orchestrationsplattform kompromittiert sein, so können unberechtigte Personen auf alle Ressourcen der Containerumgebung zugreifen. Ein weiteres Risiko sind über das Internet offen zugängliche verwundbare Management-Dashboards, über die Externe Zugriff auf die Orchestrierungsplattform erhalten können. Bei kleineren Container-Providern sind diese nicht unbedingt außer Reichweite.
Um den unerlaubten Zugriff zu verhindern, eignen sich rollenbasierte Zugangskontrollen. Beispielsweise erhalten Nutzer, die nur Berichte lesen sollen, keine Rechte, um die Containerumgebung zu ändern. Das Patentrezept in der IT-Sicherheit, eine sparsame Rechtevergabe, schafft auch bei Containern Sicherheit. Dienstleister wie Hoster oder IaaS-Anbieter, die Unternehmen anbieten, Container in der Provider-Infrastruktur laufen zu lassen, sollten nichts an den vorhandenen Containern ändern können.
Zusätzliche Sicherheit schafft die Kontrolle der Kommunikation zwischen Clustern zum Beispiel unter Kubernetes. Entwickler und Anbieter sollten Cluster, die untereinander eigentlich nicht kommunizieren müssten, standardmäßig voneinander isolieren. Greifen Kriminelle eine Applikation an, laufen die anderen trotzdem noch weiter. Zudem ist es schwieriger, sie angreifen.
Grundlegende Maßnahmen
Containersicherheit ist eine Frage des Risikobewusstseins. IT-Verantwortliche, die erkennen, dass Container die Angriffsfläche des Unternehmens erhöhen, sind schon auf einem guten Weg. Dabei sollten sie allgemein bewährte Grundsätze der Cybersicherheit auf Container übertragen. Dazu gehören die strikte Kontrolle jeder Modifikation und das Update von Images – genau so, wie man eine Software überprüft. Zero Trust empfiehlt sich als Sicherheitsmechanismus, um Container zusammenzustellen und zu portieren. Automatisierung spielt eine wichtige Rolle, um das Vergessen von Patches als Gefahr auszuschließen. Containerentwickler sollten wenn möglich Templates verwenden, um Richtlinien einfacher einhalten und die Konsistenz über die Containerumgebung gewährleisten zu können. Und wie überall in sicherheitsrelevanten Bereichen spielen Trainings eine wichtige Rolle, um organisatorisch auf einem Nenner zu sein. Zudem setzen viele Unternehmen bereits auf IT-Sicherheitstechnologien, die Containersicherheit explizit in ihr Angebot aufgenommen haben.
Letztlich sind Container nur eine Art der Applikation. Sie zu schützen, wie man andere IT-Ressourcen schützt, ist daher eigentlich eine Selbstverständlichkeit. Und wenn man die Grundsätze der IT-Sicherheit hier anwendet, ist das auch keine Geheimwissenschaft.
Cristian Avram ist Senior Solution Architect bei Bitdefender.
- Gefahrgut im Container
- Risiken der Registry und der Images
Lesen Sie mehr zum Thema
