zephyr_p - stock.adobe.com
Kubernetes-Daten vor Ransomware schützen
Lesen Sie, wie Backups und Recoverys von Kubernetes-Daten aussehen sollten, damit diese einem Ransomware-Angriff standhalten oder nach einer Attacke schnell wiederherstellbar sind.
Anfang 2021 ist die erste ernsthafte Malware für Kubernetes (K8s) aufgetaucht: Siloscape zielt auf Windows-Systeme ab, agiert ausschließlich aus Containern heraus und macht sich schlecht konfigurierte Kubernetes-Cluster zunutze. Es war nur eine Frage der Zeit, bis Hacker diese Plattform anvisieren und neue Varianten entwickeln. Aber wie lassen sich Kubernetes-Daten umfassend sichern? Und was müssen Backup und Wiederherstellung bei den unterschiedlichen Distributionen leisten können, damit die Vorzüge von Kubernetes erhalten bleiben?
Siloscape sammelt Daten auf Cluster-Ebene ein und kann auf diese Weise an weitere Informationen gelangen, beispielsweise an gehostete Datenbanken, Anmelde- und andere sensible Daten. Der Schadcode kann auf diese Weise ein ganzes Cluster kompromittieren, mit Folgen für alle dort laufenden Anwendungen.
Erste Unternehmen nutzen Kubernetes-Cluster längst in der Produktion und entwickeln neuartige webfähige Applikationen darauf. Eine Ransomware-Attacke gegen diese Systeme könnte daher wichtige Prozesse und Dienste betreffen. Anfang 2021 gelang es dem Forschungsteam von Palo Alto Networks „Unit42“ in den „Command-and-Control“-Server von Siloscape einzudringen. Die Sicherheitsforscher konnten 23 Opfer und mehr als 300 an dem Angriff beteiligte Nutzer identifizieren.
Eine weitere Schadsoftware, die sich gegen Kubernetes-Cluster richtet, ist „Hildegard“. Sie wurde ebenfalls von Palo Alto Networks entdeckt und versucht, sich über so viele Container wie möglich zu verbreiten. Damit sind zwei Trends klar erkennbar: Hacker suchen gezielt nach Fehlern im Open-Source-Code und nutzen falsche und schwache Konfigurationen von Kubernetes-Umgebungen aus. Diese Einbruchswege werden relevant bleiben, da die meisten IT-Teams erst in der Praxis Schritt für Schritt lernen, wie sie die Cluster korrekt aufsetzen müssen.
Ein erster wichtiger Schritt, um sich vor den neuen Schadcodes zu schützen, ist als Best Practice lange bekannt, wird aber von vielen Benutzern vernachlässigt: Jeder Zugang zu den Systemen muss durch ein eindeutiges starkes Passwort gesichert sein. Wichtig ist zudem, kritische Daten während des Transfers zu verschlüsseln und, wenn möglich, keinen Klartext zu verwenden. Dadurch werden erste Hintertüren bereits geschlossen.
Funktionsweise und Struktur von Kubernetes beachten
Von entscheidender Bedeutung ist auch die hierarchische Sicherung von Kubernetes zu berücksichtigen. Eine ausführliche Dokumentation der Linux Foundation beschreibt, wie sich Cluster richtig konfigurieren, verwalten und sichern lassen. Die Hersteller und die Kubernetes-Community arbeiten gemeinsam daran, fehlerhafte Codes zu finden und zu patchen.
Kubernetes-Plattformen basieren auf einem Master-Slave-Modell, das sich hierarchisch aus mehreren Worker-Nodes sowie dem Cluster-Master-Node zusammensetzt. Der Pod ist die kleinste Einheit dieser Architektur und bildet einen oder mehrere Container.
Dabei laufen ein oder mehrere Pods als individuelle Prozesse auf den Nodes. Bei den Nodes einer Kubernetes-Distribution, sei es VMware, Tanzu oder Azure Kubernetes Service, handelt es sich um physische oder virtuelle Rechner. Mehrere Nodes lassen sich wiederum zu einem Cluster zusammenfassen, in dem sie von einem sogenannten Master-Node gesteuert und überwacht werden. Die Master-Nodes werden von den Administratoren konfiguriert und nehmen ihre Befehle entgegen. Alle Pods werden mit ihren Containern auf den einzelnen Worker-Nodes verwaltet.
Master und Worker-Nodes kommunizieren über definierte Prozesse, über die jede Distribution verfügt. Diese orchestrieren die Container, die automatisch eingerichtet und den benötigten Ressourcen zugewiesen werden. Über die Distributionen werden auch die jeweiligen Worker-Nodes ausgerollt und überwacht.
Um Datenbanken einbinden zu können, werden die Namespaces mit Persistent Storage Volumes, also festem Speicherplatz, verknüpft. Dies ist wichtig, um Datenbanken wie MongoDB in die Applikationsarchitektur integrieren zu können. Der Master-Node und die prozessgetriebene automatisierte Kubernetes-Orchestrierung legen den Grundstein für Cloud-native Anwendungen, die aus Microservices bestehen.
Die schlanken Container und Pods konzentrieren sich jeweils auf eine Funktion in der Applikation und lassen sich nach Bedarf verschieben, wiederverwenden und skalieren. Neue Anwendungen sind damit schneller umsetzbar und für ein Cloud-Deployment prädestiniert.
Im Betrieb lassen sich wichtige Updates und Patches einfach per Rolling-Update-Prinzip aufspielen, ohne den Betrieb der Gesamtapplikation zu gefährden. Die Architektur ist in sich redundant ausgelegt, da die Worker-Nodes und Cluster Lasten per Load Balancing verteilen und per Failover an redundante Pendants umleiten. Außerdem lassen sich Elemente von einer Cloud-Umgebung in eine andere verschieben, sofern dort die gleiche Distribution läuft.
Diese Architektur ist robust und stark ausfallsicher und damit ideal, um kritische Dienste in Cloud-Manier abzuwickeln. Trotzdem sollten Firmen eine weitere Sicherheitsschicht einziehen und die Daten in Kubernetes zusätzlich per Backup sichern. Denn so bleiben sie geschützt vor menschlichen Fehlern, Manipulationen oder systembedingten Einflüssen. Die Architektur sowie die Portabilität von Kubernetes verlangen dabei einen speziell integrierten Ansatz bei der Datensicherung und Wiederherstellung. Nur dann ist gewährleistet, dass die Backup- und Recovery-Funktionen dem Aufbau von Kubernetes bei allen Distributionen gerecht werden.
Stateless- und Stateful-Anwendungen
Ursprünglich sollten Container so wenig wie möglich mit Persistent Data operieren. Gemeint ist, dass die Daten nach dem Beenden eines Programms vorhanden bleiben und sich bei einem erneuten Aufruf rekonstruieren und anzeigen lassen.
Bei Containern sind dagegen Stateless-Anwendungen zu empfehlen. Dazu zählt beispielsweise die Anwendungslogik: Diese API speichert keine Benutzereingaben. Meldet sich ein User an, überprüft sie Angaben wie Name und Passwort danach, ob sie mit den Informationen in der Datenbank übereinstimmen.
Ist das der Fall, wird der Benutzer angemeldet, ansonsten erscheint eine Fehlermeldung. Die API, die für die Verarbeitung der Benutzereingaben zuständig ist, ist zwischen der Präsentations- und der Datenhaltungsschicht angesiedelt – also zwischen Benutzerschnittstelle und Datenbank. Da sie keinerlei Daten speichert, die später erneut gebraucht werden, wird sie als transient, zustandslos oder auch stateless bezeichnet (siehe auch Pitchers Welt: Kubernetes-Grundlagen). Der Vorteil daran: Wird der Container korrumpiert, lässt er sich einfach neu starten, ohne dass Daten verloren gehen.
Bei Stateful-Anwendungen wie einer Datenbank müssen dagegen nach einem Neustart alle bisher gespeicherten Daten vorhanden sein. Unabhängig davon, ob die Worker-Node, auf der die Anwendung läuft, abstürzt oder die Anwendung selbst neu gestartet wird: Ihre Daten werden persistent gespeichert. Damit ein Container in einem Pod Daten sichern kann, wird ihm ein Persistent Volume, also ein externes Laufwerk, zugewiesen. Dieses wird nach der Bereitstellung an einen Pod gemountet und ist unabhängig vom Kubernetes-Cluster.
Legt eine Datenbank beispielsweise ihre persistenten Daten in dem Verzeichnis /var/lib/mysql ab, wird das Persistent Volume an genau diesem Pfad gemountet. Die Daten werden also extern und nicht innerhalb des Datenbank-Containers abgelegt. Startet der Datenbank-Pod neu, wird das Persistent Volume von Kubernetes automatisch unter dem entsprechenden Pfad angehängt.
Startet Kubernetes den Datenbank-Pod auf einer anderen Worker-Node, wird das Persistent Volume automatisch an diese Maschine gehängt und steht anschließend für den Pod zur Verfügung. Spätestens jetzt sollte das Backup-Konzept eingreifen und die Maschine sichern.
Kubernetes lückenlos sichern
Die Architektur einer Kubernetes-Umgebung verändert sich dynamisch und ist als Cloud-Umgebung im Sinne einer Private-, Public-, oder Hybrid-Cloud konzipiert. Diesem Aufbau müssen Backup-Konzepte gerecht werden. Sie sollten eng mit dem Cluster verbunden sein und in einer schlanken und ressourcenschonenden Implementierung mit dem Master über die verfügbaren Automatisierungsschnittstellen kommunizieren.
Einer der Marktführer bei Kubernetes ist Red Hat Openshift, neben VMware und Tanzu. Egal, welche Backup-Lösung eingesetzt wird: Sie sollte für alle gängigen Distributionen zertifiziert sein und diese unterstützen. Dadurch lassen sich Störungen und Ausfälle vermeiden.
Wichtig ist zudem, dass die Authentifizierung der User im Backup hochsicher per Token und Zertifikat erfolgt und alle ausgetauschten Daten standardmäßig per 128 Bit verschlüsselt sind. Damit sind sie beim Transfer zwischen Clouds und hybriden Installationen vor einem Fremdzugriff geschützt.
Ein Backup-System sollte mit gängigen Standards wie Velero interagieren, jedoch auch andere intelligente Ergänzungen unterstützen. So kann die Anbindung an ein durch das Backup gesteuertes Retention-Management mit Replikationsmöglichkeit helfen, sich vor Ransomware zu schützen.
Die Anwendung der 3-2-1 Regel ist hierbei elementar und sollte auch bei der Definition der Backup-Strategie zwingend berücksichtigt werden. Die konzeptionelle Ergänzung durch einen Backup Data Mover kann ebenfalls Vorteile für die zukunftsorientierte Kubernetes-Planung haben. Denn damit sind die Backup-Storage-Ziele auf die vom Anbieter unterstützte Kompatibilität erweiterbar.
Das heißt, Kubernetes lässt sich Ende-zu-Ende in ein zentrales Backup und Recovery-Konzept einbinden. Das vermeidet unerwünschte Nebeneffekte, wie sie für Einzellösungen typisch sind. Zudem werden Kosten und Aufwände minimiert, Komplexität vermieden und das Risiko von Cyberangriffen deutlich verringert.
Namespaces sichern und Zugriffsrechte klar definieren
Namespaces sind die Bestandteile einer Kubernetes-Umgebung, die durch die integrierten Pods, Container, Konfigurationsinformationen und dem zugehörigen Storage den eigentlichen Business Value liefern. In der Praxis werden sie meist als Projekte oder Applikationen definiert.
Die Backup-Plattform sollte über eine Namespace-Schnittstelle verfügen, die im Cluster implementiert ist und dessen Performance nicht beeinträchtigt. Dadurch lassen sich das Discovery des Clusters, manuelle und geplante Backup-Abläufe sowie die Wiederherstellung der Daten selbsttätig ausführen.
Für einen ganzheitlichen Schutz muss zudem der komplette Namespace mit allen Komponenten gesichert werden. In einem Recovery-Fall kommt es darauf an, die Persistent Volumes unabhängig von den Namespaces wiederherstellen zu können, da auf dem Daten-Layer des Persistent Volume logische Fehler auftreten können.
Um die Agilität von Kubernetes beizubehalten, sollte die Backup-Lösung zudem das Wiederherstellen von Namespaces auch auf alternativen Clustern unterstützen. Die Betrachtung des Namespaces als ganzheitliches Asset ermöglicht es, die Skalier- und Portierbarkeit der Kubernetes-Umgebung zu wahren, auch wenn sie durch einen Recovery-Fall ausgelöst wird.
Damit der Backup-Dienst alle für den Betrieb essenziellen Informationen vom Kubernetes-Master erhält, sollte die Kommunikation über abgestimmte Zertifikate und Credentials erfolgen. Für die Authentifizierung empfehlen sich standardisierte Tokens und CA-Zertifikate, um den Datenaustausch nach höchsten Standards zu verschlüsseln.
Die Zugriffsrechte für die Datensicherung und -wiederherstellung sollten nur für Ressourcen der Kubernetes-Umgebung gelten, die der jeweilige User verwalten oder nutzen darf. Das bedeutet, dass ein Backup-Anwender nur die Namespaces und Persistent Storage Volumes des Clusters sehen kann, für die er eine Berechtigung hat. Auf diese Weise lassen sich Dev-, Test- und Produktionsverantwortlichkeiten separieren. Auch bei der Konfiguration empfiehlt es sich, Zugriffsrechte zu definieren, die im Backup-System über einen Rolebased Access umgesetzt werden. Dieser Ansatz stärkt die Widerstandsfähigkeit gegen Cyberattacken.
Um das Eindringen von Schadsoftware zu verhindern, sollten die eingesetzten Backup-Lösungen regelmäßig und automatisch nach neu angelegten Namespaces suchen. Dazu müssen die Kubernetes-Distributionen und das Backup-System einwandfrei zusammenarbeiten.
Perspektivisch sollten Ansätze gegeben sein, über additive Automatisierungen logische Selektionen mit der Zuordnung der richtigen Backup-Pläne intelligent neuen Namespaces zuzuweisen. In dynamisch wachsenden Kubernetes-Farmen sinkt dadurch das Risiko, ein Projekt oder eine Applikation nicht ordnungsgemäß gesichert zu haben. Zudem entlasten solche Automatismen die IT-Teams in Bezug auf Discovery und Konfiguration erheblich und beugen Datenverlusten vor. Natürlich sollten die Verantwortlichen in der Lage sein, individuelle RPOs festzulegen, die für besonders kritische Daten kürzere Backup-Intervalle durchsetzen.
Wichtig ist auch, frei festzulegen, wo sich die Daten im Ernstfall wiederherstellen lassen. Dies funktioniert im Idealfall lokationsübergreifend, setzt aber voraus, dass an den anderen Cloud-Standorten die gleiche Distribution und Softwareversion laufen. Mithilfe eines Rechtekonzepts ist es auch möglich, die Wiederherstellungsfunktionen direkt dem DevOPs-Team zuzuweisen. Auf diese Weise lassen die Entwicklungszeiten verkürzen und die Backup-Teams entlasten.
Automatische Backups vereinfachen die Sicherung
Automatismen, die durch eine enge und zertifizierte Integration aus Distribution und Backup-Konzept zustande kommen, bewahren den agilen Charakter von Kubernetes. Im täglichen Geschäft lassen sich zudem die Backup-Prozesse automatisieren und zeitgesteuert neu aufsetzen, um die Verantwortlichen zu entlasten. Durch einen Event-Alarm in der jeweiligen GUI wird der User entsprechend informiert.
„Erste Unternehmen nutzen Kubernetes-Cluster längst in der Produktion und entwickeln neuartige webfähige Applikationen darauf. Eine Ransomware-Attacke gegen diese Systeme könnte daher wichtige Prozesse und Dienste betreffen.“
Patrick Englisch, Veritas
Über weitere Funktionen wie das Throtteling lassen sich zudem klare Service Level für die Last des Clusters definieren. Kommt es zu einer temporären Überlast, kann das Backup-Konzept die Menge reduzieren und die Cycles herunterfahren – ohne Einbußen bei der Performance der Kubernetes-Applikation.
Mit NetBackup von Veritas Technologies kommen diese Vorteile auf alten sowie neuen Workloads im Unternehmen zum Tragen. Aufwand und Kosten werden reduziert, und keine wichtige Datei fällt durch das Backup-Raster. Damit sind alle kritischen Systeme lückenlos vor menschlichen Fehlern und Ransomware geschützt.
Über den Autor:
Patrick Englisch ist Director Technical Sales DACH bei Veritas Technologies und leitet alle Themen rund um den Technologievertrieb des Unternehmens im D-A-CH-Bereich. Er verfügt über mehr als 20 Jahre IT-Erfahrung und mehr als 12 Jahre Expertise im Solution Engineering und Vertrieb. Im Laufe seiner Tätigkeit hat er für namhafte Firmen zahlreiche Projekte geplant und durchgeführt.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
