Sicherheit vom Entwurf bis hin zur Runtime-Phase Security by Design – ein Kubernetes-Ansatz

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Eskenzi PR Limited

Microservice-basierte Anwendungen werden häufig über Kubernetes-verwaltete Container Cluster realisiert. Mit der Popularität von K8s geht allerdings auch die Gefahr einher, als De-facto-Standard vermehrt Angriffen ausgesetzt zu sein.

IT-Anwendungen sind heute komplexer denn je. Sie setzen sich aus einer Vielzahl von Microservices und Systemen zusammen, sie sollen Anwendungsfälle im mobilen Bereich abdecken und mit Webportalen interagieren, und sie müssen ganz selbstverständlich mit Apps anderer Anbieter kommunizieren.

Doch damit nicht genug: Wir verlangen, dass Apps immer erwartungsgemäß funktionieren und dass sie eine hohe Leistung und Verfügbarkeit bieten. Gleichzeitig müssen Integrität und Authentizität von Daten und Diensten sichergestellt sein. Um all dies zu erreichen, haben sich viele Unternehmen für Kubernetes entschieden und ihre Infrastruktur auf dieses Modell hin migriert

Ziel des Re-Designs ist es, unserer modernen Cloud-nativen und datengesteuerten Ära gerecht zu werden. Moderne DevOps-Standards einzuhalten, ist entscheidend für den Erfolg. Es gilt, einen stufenweisen Ansatz für die Bereitstellung von Anwendungen einzuführen, vom Entwurf bis zur Laufzeit.

Genau diese Phasen sind inzwischen allerdings auch ins Visier von Angreifern geraten. Daher sollten DevSecOps-Teams die mit ihren Projekten verbundenen Risiken sorgfältig analysieren und ihre Praxis so ausrichten, dass sie mögliche Gefahrenpotenziale minimiert.

Ein Katz-und-Maus-Spiel

Im vergangenen Jahr haben Angriffe auf Komponenten von Kubernetes-Umgebungen deutlich zugenommen. Das belegt unter anderem der soeben erschienene „State of Kubernetes Security Report 2021” von Red Hat.

Dazu muss man wissen: Sicherheit innerhalb von K8 ist keine lineare Angelegenheit. Kubernetes-Cluster bestehen aus vielen verschiedenen Komponenten, von denen jede ihren eigenen Sicherheitskontext aufweist – und auch hier werden sich die Angreifer immer auf das schwächste Glied der Kette konzentrieren.

Defense in depth – der koordinierte Einsatz eines komplexen und vielschichtigen Abwehrsystems – ist in dieser Situation aus unserer Sicht heute ein Muss. Wir begrenzen die Angriffsfläche, indem wir die Zahl der installierten Software- Instanzen reduzieren und gleichzeitig sicherstellen, dass die Anwendungen mit der geringstmöglichen Anzahl von Privilegien ausgeführt werden.

Angreifer haben es vor allem auf den Kubernetes-API-Server abgesehen. Das hat Konsequenzen, denn jeder Pod in einem Kubernetes-Cluster bekommt ein svc-Konto (Service-Konto) zugewiesen, das mit dem Kubernetes-API-Server kommuniziert. Deshalb sollte jedes svc-Konto nur mit der jeweils geringstmöglichen Zahl an Berechtigungen ausgestattet werden.

In den meisten Versionen mit Ausnahme von 1.5.1-1.5.x akzeptiert k8 standardmäßig API-Aufrufe von anonymen Benutzern. Angreifer könnten deshalb einfach mit Shodan nach öffentlichen, nicht authentifizierten APIs suchen. Aus diesem Grund ist es wichtig sicherzustellen, dass anonyme Authentifizierung nicht erlaubt ist.

Noch besser ist es, die API-Server-Firewall einzusetzen, um die Zahl der IP-Adressen mit Zugriffsrecht auf den API-Server einzugrenzen. Darüber hinaus ist es hilfreich, eine starke Netzwerk-Policy zu etablieren, die dafür sorgt, dass das Frontend nicht direkt mit dem Backend sprechen kann – außer, wenn dies explizit notwendig ist.

Weitere Sicherheitsmaßnahmen

Angreifer machen sich „Kubernetes-Fehler“ zunutze, um aus einzelnen Containern zu entkommen und direkten Zugriff auf den Host zu erhalten. Dann können sie Daten aus anderen Containern lesen und – noch schlimmer – Zugriff auf das Cluster bekommen. Vor diesem Hintergrund ist es wichtig, Apps innerhalb der Container als Benutzer und nicht als Root laufen zu lassen, sie nur mit Lese-Rechten auf das Root-Dateisystem auszustatten und keine neuen Privilegien für die jeweilige Anwendung zuzulassen.

Zusätzlich zu den oben genannten Maßnahmen empfiehlt es sich, die Rotation der Encryption Keys zu automatisieren. Sollten diese einmal kompromittiert werden, sind sie zumindest nur für eine kurze Zeitspanne gültig. Ergänzend zu den bereits erwähnten Best Practices muss Kubernetes sicherheitstechnisch wie jede andere Anwendung oder jedes andere Tool behandelt werden.

Das bedeutet zunächst, die Anwendung konsequent zu patchen und zu härten. Zusätzlich muss die Protokollierung (Logging) aktiviert werden. Die von Kubernetes erzeugten Logs sollten außerdem von einem MDR-Dienst rund um die Uhr überwacht und ausgewertet werden, um im Fall der Fälle rechtzeitig Abwehrmaßnahmen einzuleiten.

Die folgenden Indikatoren gehören zu denen, auf die primär zu achten ist:

• Anonyme Authentifizierung lässt sich erkennen, wenn man in den Log-Dateien nach dem Benutzernamen "system:anonymous" und der Gruppe "system:unauthenticated" fahndet.

• Jede Kompromittierung eines svc-Kontos ist ein kritisches Ereignis. Leider gibt es keine Möglichkeit, einen derartigen Fall direkt zu erkennen. Mit Techniken wie der Anomalie-Erkennung lassen sich allerdings Aktionen aufdecken, die auf einen Missbrauch hindeuten. Außerdem macht dieser Ansatz Abweichungen von der normalen Verwendung der svc-Konten sichtbar. Da diese Konten immer von automatisierten Diensten für vorgegebene Zwecke verwendet werden, müsste ihr Verhalten definierten Vorgaben gehorchen und konsistent sein. Abweichungen weisen deshalb darauf hin, dass ein Angreifer diese Konten kompromittiert hat und bereits verwendet.

• Noch etwas sollte man in den Log-Dateien suchen und inspizieren: Benutzer-Agenten. Bei normalen Aktivitäten beginnt der Benutzer-Agent mit dem Namen des Dienstes, z. B. "kube-controller-manager". Ein Angreifer dagegen verwendet bei der Interaktion mit der API native Netzwerk-Tools wie curl oder das Kubernetes-Befehlszeilen-Interface-Tool kubectl.

• Die Logs der API-Server halten überdies fest, auf welche secrets über die API zugegriffen wird. "Get" taucht auf, wenn es um ein einzelnes secret geht, und "list", wenn mit dem Befehl "get secrets" auf mehre secrets zugegriffen wird. So erfährt man, auf welche secrets die Zugriffe zielten und wer dahintersteckt.

• Auch die kontinuierliche Überwachung ist wichtig. Wir würden nach ausgehenden Verbindungen zu bestimmten IPs oder Domänen, der Verwendung sensibler Dateien wie /etc/passwd, Änderungen in bestimmten Ordnern wie /sbin und nach der Ausführung von System-Binärprogrammen wie su fahnden.

Eine Empfehlung noch: Prüfen und verifizieren Sie kontinuierlich. Tools wie Kube-bench sind von großer Bedeutung. Solche Tools achten darauf, ob Kubernetes gemäß dem CIS-Kubernetes-Benchmark sicher eingesetzt wird.

Vorbereitet sein

Wie bereits erwähnt, richten Angreifer ihr Augenmerk immer auf Fehlkonfigurationen, Schwachstellen und die Chance, Konten zu übernehmen. Vom Design über Entwicklung, Build, Deploy und Runtime für Sicherheitsfragen vorbereitet zu sein, ist integraler Bestandteil einer modernen Sicherheitspraxis.

Vor diesem Hintergrund ist es wichtig, alle Phasen rund um die Uhr im Auge zu behalten, um Sicherheitsvorfälle unterschiedlichen Ausmaßes schnell identifizieren und darauf reagieren zu können. Sie sollten deshalb jederzeit in der Lage sein, folgende Fragen zu beantworten:

• Was ist passiert?

• Wann ist es passiert?

• Von wo ist es ausgegangen?

• Wer ist involviert?

• Ist der Vorfall abgeschlossen oder nicht?

• Welche Bereichen sind sonst noch betroffen?

• Was sollten wir tun?

Moderne MDR-Services wurden entwickelt, um Sicherheitsvorfälle in modernen containerisierten Umgebungen zu identifizieren, zu analysieren, echte von falschen Bedrohungen zu unterscheiden und darauf zu reagieren – durch eine ganzheitliche Abdeckung von (Telemetrie-) Daten, Aktionen, Logs und Konfigurationen in Echtzeit. Ein derartiger plattformbasierter Service umfasst alle erforderlichen Elemente von SIEM-Systemen bis hin zu Netzwerkdaten-Analyse-Engines und Honeypots, um eine zuverlässige 24x7-Überwachung zu gewährleisten.

Ergänzend haben sich spezielle Strategien, Praktiken und Techniken bewährt, denen das „Security by Design“-Prinzip zugrunde liegt. Sie erlauben es, Anwendungen und Infrastruktur mit minimalen Ausfallzeiten, maximaler Leistung und optimaler Service-Integrität in Betrieb zu nehmen, dauerhaft zu betreiben und zu überwachen. Dem DevSecOps-Zyklus folgend legen sie den Schwerpunkt explizit auf die Sicherheit:

• Entwickeln und erstellen Sie Ihre Programmier-Lösung (SSDLC, Software Security Development Life Cycle) unter Berücksichtigung aller erforderlichen Sicherheitsstandards (Risikobewertung, Thread-Modellierung & Design-Überprüfung, statische Analyse).

• Testen Sie Ihre Anwendungslösung automatisiert (SAST, DAST) und manuell.

• Sichern Sie Ihre Infrastruktur (IaC) durch Härtung der Kubernetes-Cluster nach Best Practices.

• Überwachen Sie Ihre Cluster-Logs sorgfältig und rund um die Uhr mithilfe eines MDR-Services (Managed Detection and Response), um bereits in der Anfangsphase Anomalien oder Störungen zu diagnostizieren und entsprechende Maßnahmen zu ergreifen.

Lösungen wie die von Obrela werden als Security-Platform-as-a-Service bereitgestellt, die alle Sensordaten aus der beim Kunden installierten Technik berücksichtigt. Ein solcher 24x7-Service umfasst Resilience Operation Centers (RoCs), Threat Hunting, Security Incident Response bis zur Schließung eines Vorfalls. Solche Services sind in der Regel schon innerhalb weniger Tage in der betreffenden Umgebung einsatzbereit. Eine wichtige Voraussetzung, will man schnell und zuverlässig Schutz aufbauen.

* Christos Betsios ist Cyber Operations Officer bei Obrela, Tasos Logothetis ist beim gleichen Unternehmen als DevOps Director tätig.

(ID:47514976)