Eine Frage des Vertrauens: Wenn gute Container schlecht werden
Autor/Redakteur: Tim Mackey, Technologie-Evangelist bei Black Duck Software/gg
Betreiber von Datacentern stehen vor doppelten Herausforderungen bei der Komplexität der Infrastruktur und der Anwendungsgeschwindigkeit, während sie sich gleichzeitig um die Einhaltung globaler Governance-Vorschriften wie der Datenschutzgrundverordnung (DSGVO) kümmern müssen. Moderne Workloads sind zunehmend containerisiert. Das bedeutet, dass neue Muster der Verwaltung und der Überwachung zur Einhaltung der Regelungen erforderlich sind. Ein Beispiel ist das Patchen von Anwendungen. Bei Bare-Metal- und virtualisierten Servern wurden Verfahren entwickelt, bei denen das Betriebssystem und die Anwendungskomponenten innerhalb dieser Server kontinuierlich aktualisiert werden, sobald Patches veröffentlicht werden. Die Containerisierung kehrt diese Praxis um. Containerisierte Anwendungen werden gepatcht, in dem das Container-Image aus gepatchten Quellen neu erstellt und anschließend wieder bereitgestellt wird. Diese eine Änderung im Prozess erfordert eine Neubewertung der Art und Weise, wie Anwendungen erstellt werden – und maßgeblich wo sich vertrauenswürdige Quelldateien befinden.
Auch kriminelle Akteure haben die Möglichkeit, KI und Machine Learning für Angriffe einzusetzen. Machine Learning eignet sich hervorragend dazu, große Datenansammlungen auszuwerten und Muster zu finden. Open-Source-Projekte sind bestens geeignet, um mit Machine Learning potenzielle Angriffsvektoren zu analysieren und zu bewerten. Da mehr KI im Cybersicherheits- und Datacenter-Betrieb eingesetzt wird, kann man davon ausgehen, dass Hacker diese Technologie ebenso einsetzen werden; sei es, um Phishing-Angriffe zu starten oder Szenarien zu testen, die von Hackern dann bei Malware- oder DDoS-Angriffen umgesetzt werden.
Was sind die Hauptmethoden, um Container zu kompromittieren?
Grundlegend ist das eine Frage des Vertrauens. Zum Beispiel werden die meisten Container-Images aus einem Quell- oder Basis-Image erzeugt. Dann werden anwendungsspezifische Komponenten hinzugefügt, um die containerisierte Anwendung zu bilden. Ohne eine Validierung des Sicherheitsstatus für ein Basis-Image können Hacker modifizierte Komponenten in Basis-Images platzieren, die dann weit verbreitet werden, wodurch ein gesamtes Container-Ökosystem gefährdet wird. Die Größe der Entwickler-Community, die Container einsetzt, wächst weiter und bietet eine zunehmende Zielgruppe für Hacker. Aus einer nicht böswilligen Perspektive betrachtet, können Basis-Images veraltete und unsichere Komponenten bündeln, insbesondere wenn das zugrundeliegende Betriebssystem nicht die aktuellste Version ist.
Sind andere Container innerhalb des Rechenzentrums gefährdet, wenn ein Container kompromittiert ist?
Wenn wir annehmen, dass ein Angreifer einen Container kompromittieren konnte, befindet er sich auf der anderen Seite der verschiedenen Perimeter des Netzwerks und kann von innen heraus angreifen. Um festzustellen, wie viele andere Container im Rechenzentrum gefährdet sind, muss man genau wissen, wie das Rechenzentrum eingerichtet ist und wie gut man sich auf Angriffe vorbereitet hat. Geringstenfalls, wenn ein Container kompromittiert wird, ist es wahrscheinlich nicht die einzige Kopie des verwendeten Container-Images. Zudem ist es wahrscheinlich, dass der gegebene Angriffsvektor ebenso in anderen Container-Images vorhanden sein kann. Aus Sicht der Abwehr besteht die zentrale Schlussfolgerung darin, dass, wenn Abwehrmaßnahmen am Perimeter heruntergenommen sind, das Potenzial für Querwirkungen innerhalb des Rechenzentrums zunimmt.
