Velero-Backups härten, bevor Ransomware sie findet

Velero bleibt eines der meistgenutzten Open-Source-Tools für das Sichern, Wiederherstellen und Migrieren von Kubernetes-Clusterressourcen und persistenten Volumes. Für Managed-Service-Provider, die viele Cluster betreiben, entscheidet nicht nur die Installation, sondern vor allem die Konfiguration von Velero darüber, ob ein Backup während eines Vorfalls tatsächlich nutzbar ist.

Backup-Erfolg ist nicht Restore-Erfolg

Ein fehlerfrei abgeschlossener Backup-Job belegt lediglich, dass Daten erfasst wurden – nicht, dass sie sich zurückspielen lassen. Ransomware-Akteure zielen zunehmend gezielt auf Backup-Zugangsdaten und Speicherorte, weil sie wissen, dass ein funktionierender Wiederherstellungsweg den Unterschied zwischen einem Vorfall und einem Ausfall ausmacht. Wiederherstellungstests, die planmäßig durchgeführt und als Nachweis protokolliert werden, sind die einzige zuverlässige Methode, um zu wissen, dass ein Backup im Ernstfall funktioniert.

Schwerpunkte der Härtung

• Die RBAC-Rechte für das Dienstkonto von Velero auf das beschränken, was Backup und Wiederherstellung tatsächlich benötigen – nicht standardmäßig Cluster-Admin.
• Backups im Ruhezustand verschlüsseln und mindestens eine Kopie extern oder unveränderlich aufbewahren, damit ein kompromittierter Cluster nicht auch seine eigenen Backups zerstören kann.
• Den Verwaltungspfad für den Backup-Speicher vom Workload-Netz trennen, wo immer das Storage-Backend dies erlaubt.
• Die von Velero für den Zugriff auf Objektspeicher genutzten Zugangsdaten rotieren und eingrenzen; kurzlebige Token sind langfristigen statischen Schlüsseln vorzuziehen.
• Den Wiederherstellungsweg selbst als Produktions-Admin-Fähigkeit behandeln – wer eine Wiederherstellung auslösen kann, kann in der Regel auch Produktivdaten überschreiben.

Was Velero allein nicht abdeckt

Velero sichert Kubernetes-Objekte und – mit dem passenden Plugin – Daten persistenter Volumes. Es schützt jedoch nicht von sich aus vor einem kompromittierten Cluster, das seinen eigenen Backup-Zeitplan manipuliert, und ist kein Ersatz für netzwerkbasierte Segmentierung. Die Kombination mit unveränderlichem, extern gelagertem Speicher schließt die häufigste Lücke, die MSPs in der Praxis beobachten: Backups, die zwar existieren, aber aus demselben Wirkungsbereich erreichbar bleiben wie der von ihnen geschützte Cluster.

Die entscheidende Basis ist unspektakulär: verschlüsselte und extern gelagerte Kopien, eingeschränkter Zugriff und ein Restore-Test, der tatsächlich durchgeführt wurde – nicht nur geplant ist.

Quellen: GitHub — vmware-tanzu/velero, Velero-Dokumentation.