Mobile-Menu

Synology Virtual Maschine Manager Sicherer Betrieb von VMs auf Synology NAS

Von Thomas Joos 6 min Lesedauer

Anbieter zum Thema

Synology GmbH
FTAPI Software GmbH

Der Virtual Machine Manager von Synology macht aus einem NAS nicht nur Speicher, sondern auch eine Virtualisierungsplattform für Server und Arbeitsstationen. Damit produktive VMs hier sicher laufen, sind jedoch klare Regeln gefragt, von Snapshot-Strategien über Hochverfügbarkeit bis zu restriktiven Admin-Rechten.

Der Synology Virtual Machine Manager erlaubt nicht nur den Betrieb von VMs, sondern bietet mit Snapshots, Replikation und HA auch zentrale Sicherheitsfunktionen.(Bild: © Eliane - stock.adobe.com)
Der Synology Virtual Machine Manager erlaubt nicht nur den Betrieb von VMs, sondern bietet mit Snapshots, Replikation und HA auch zentrale Sicherheitsfunktionen.
(Bild: © Eliane - stock.adobe.com)

Setzen Unternehmen ein Synology-NAS ein, ist es auf dem NAS auch möglich VMs zu betreiben. Das ist auch in einem Cluster möglich, wenn zwei NAS bereitstehen. Die technische Umsetzung dazu haben wir in einem eigenen Beitrag gezeigt. Nutzen Unternehmen allerdings virtuelle Server, spielt auch die Sicherheit eine wichtige Rolle. In diesem Beitrag gehen wir darauf ein, wie VMs auf einem Synology-NAS auch sicher betrieben werden können.

Bildergalerie
Bildergalerie mit 5 Bildern

Grundsätzliche Sicherheits-Einstellungen auf einem Synology-NAS optimieren

Generell sollten die Sicherheitseinstellungen auf einem Synology-NAS ohnehin optimiert werden. Wie das geht, haben wir in einem eigenen Beitrag gezeigt. Dazu kommt die Security-Checkliste für ein Synology-NAS, die wir ebenfalls umfassend behandelt haben. Über diese Themen hinaus, gibt es vor allem beim Betrieb von VMs auf einem Synology-NAS weitere Sicherheitsoptionen, die Admins berücksichtigen sollten.

Snapshot-Verwaltung konsequent einsetzen

Ohne regelmäßige Snapshots ist jede virtuelle Maschine ein Single Point of Failure. VMM bietet dafür nicht nur manuelles Auslösen, sondern vollständige Schutzpläne mit Zeitplan- und Aufbewahrungsrichtlinien. Kritisch bleibt jedoch die Wahl des Dateisystems. Snapshots sind ausschließlich auf Btrfs-Volumes verfügbar. Auch die Gast-VM selbst muss korrekt vorbereitet sein. Der QEMU Guest Agent sollte installiert sein, um konsistente Snapshots im laufenden Betrieb zu garantieren. Fehlt er, droht Inkonsistenz, im schlimmsten Fall Datenverlust bei inkrementellen Replikationen.

Lokale Snapshots allein genügen nicht. Der Plan zum Schutz lässt sich mit Remote-Replikation koppeln, sofern zwei NAS im Cluster vorhanden sind. Für das Ziel-Volume gelten dieselben Anforderungen wie für die Quelle, Btrfs, ausreichend freier Speicher und aktivierter Speicherhost. Die Option "Übertragungsverschlüsselung" in den erweiterten Einstellungen sollte zwingend aktiv sein, um Replay-Angriffe und Man-in-the-Middle-Risiken auszuschließen.

Failover und Replikation richtig konfigurieren

Ein sauber eingerichteter Replikationsplan funktioniert nur, wenn Quelle und Ziel unabhängig voneinander erreichbar bleiben. Der VMM erlaubt maximal 32 Pläne pro Cluster. Fällt der aktive Host aus, lässt sich über ein gezieltes Failover aus dem Ziel-Snapshot eine neue VM starten, inklusive Rollentausch. Die VM muss vor dem Failover gestoppt sein. Wer HA aktiviert hat, sollte Failover nicht dem Zufall überlassen, sondern regelmäßig simulieren. Test-Failover decken Schwachstellen in Netzwerkpfaden, Lizenzbindung oder Speicheranbindung frühzeitig auf.

Hochverfügbarkeit auf belastbare Füße stellen

High Availability (HA) wird auf Host-Ebene konfiguriert, nicht innerhalb der VM. Der virtuelle Rechner benötigt dafür einen aktiven, passiven und einen Storage-Server. Der passive Server reserviert Speicher und CPU im Voraus. Wird dieser Platz anderweitig beansprucht, schlägt das Failover fehl. Wer seine Umgebung absichern will, sollte die Ressourcenzuteilung mit Blick auf HA manuell prüfen, gerade bei begrenztem RAM oder eng dimensionierten CPU-Kernen.

Übergaben finden nicht nur bei Ausfällen statt, sondern auch bei Anzeichen für instabile Hardware, etwa labilen Lüftern, hoher CPU-Last oder USV-Warnungen. Diese Schwellenwerte lassen sich nicht justieren, sollten aber regelmäßig gegen die reale Clusterlast abgeglichen werden. Die automatische Migration funktioniert nur dann zuverlässig, wenn Netzwerkschnittstellen konsistent benannt und virtuelle Switches auf allen Hosts identisch verfügbar sind. Ein inkonsistenter vSwitch-Verbund unterbricht die Kommunikation im Failover-Fall, ein Klassiker in schlecht gepflegten Umgebungen.

E-Mail-Benachrichtigungen und Monitoring aktivieren

Sicherheit ist nichts ohne Transparenz. VMM unterstützt eigene Cluster-Benachrichtigungen per SMTP, unabhängig von DSM-Benachrichtigungen. Dabei empfiehlt sich die Konfiguration mehrerer SMTP-Server auf den beteiligten Hosts. Wer redundante Pfade nutzt, reduziert das Risiko, dass Statusänderungen im Cluster unbemerkt bleiben. Zusätzlich sollte im Betreff-Präfix das NAS-Modell oder Standortkürzel ergänzt werden, um in komplexeren Umgebungen Ereignisse schneller zuzuordnen.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Praxisempfehlung: Snapshot-Politik GFS-orientiert definieren

Wer granulare Aufbewahrung benötigt, konfiguriert stündliche, tägliche, wöchentliche und monatliche Snapshots nach dem "Grandfather-Father-Son"-Prinzip. So bleiben nicht nur die letzten Änderungen verfügbar, sondern auch Referenzstände vor Wochen oder Monaten. In der Praxis bewährt sich eine Policy mit acht stündlichen, sieben täglichen, vier wöchentlichen und zwölf monatlichen Snapshots. Mehr bringt kaum Nutzen, bindet aber massiv Speicherplatz. Gesperrte Snapshots sollten nur in Ausnahmefällen verwendet werden, da sie die automatische Rotation blockieren.

Empfehlung zur Netzwerktrennung

Virtuelle Switches sollten klar segmentiert werden. Externe Netzwerke für produktive VMs, interne Switches für Management- oder Backup-Verkehr. Die MAC-Adresse der VM wird bei Wiederherstellung neu generiert, was im DHCP-Umfeld zu Konflikten führen kann. Wer feste IPs vergibt, sollte das berücksichtigen. Für Clusterkommunikation ist ein eigenes VLAN ratsam, jeder Cluster-Host muss eine statische IP besitzen.

Konsistenzprüfung, Lizenzbindung und Storage-Feinheiten

Neben dem Offensichtlichen bleiben oft jene Sicherheitslücken bestehen, die aus Vernachlässigung technischer Randbedingungen entstehen. Wer etwa Snapshots regelmäßig erstellt, aber nicht kontrolliert, ob der QEMU Guest Agent auf der Gast-VM korrekt läuft, produziert potenziell unbrauchbare Wiederherstellungspunkte. Dasselbe gilt für Dateisysteme im Gastbetriebssystem. Werden dort NTFS-Partitionen ohne „Volume Shadow Copy“-Integration betrieben, versagen Backups im Schadensfall.

Auch die Lizenzbindung an ein Synology-Konto wirkt sicherheitstechnisch unterschätzt. Wird ein Cluster durch ein neues NAS erweitert, aber der Lizenzinhaber nicht korrekt auf dem Zielsystem angemeldet, kann VMM bei der nächsten Migration willkürlich Hosts zuordnen, inklusive Kontrollverlust über das Rechte- und Rollenkonzept. Im Storage-Manager sollte zudem regelmäßig geprüft werden, ob VM-Volumes sauber getrennt von Anwendungsdaten laufen. Fehler bei der Volume-Zuordnung führen sonst dazu, dass ein Ransomware-Befall in einer einzigen VM das komplette NAS kompromittiert. Der Storage muss als Isolationsschicht begriffen und entsprechend organisiert werden.

Angriffsfläche minimieren durch restriktive Rechte und Update-Praxis

Virtuelle Maschinen auf einem Synology-NAS laufen isoliert, doch das bedeutet nicht, dass ihre Managementschnittstellen immun gegen Angriffe wären. Der Zugriff auf den Virtual Machine Manager sollte daher ausschließlich über dedizierte Administratorkonten mit Zwei-Faktor-Authentifizierung erfolgen. Gruppenrechte innerhalb von DSM sind granular genug, um VM-Verwaltung, Storage-Zugriff und Systemkonfiguration strikt zu trennen. In der Praxis wird dieser Mechanismus selten genutzt, mit dem Ergebnis, dass einzelne Benutzer weitreichende Rechte auf das komplette Host-System erhalten.

Auch die Update-Routine für den VMM selbst wird oft vernachlässigt. Gerade sicherheitsrelevante Korrekturen für die KVM-Engine, das Storage-Backend oder die Netzwerkvirtualisierung erfolgen stillschweigend über DSM- oder VMM-Updates. Wer produktive VMs betreibt, sollte daher ein kontrolliertes Patchfenster etablieren, inklusive vorheriger Snapshot-Sicherung aller VMs. Zusätzlich empfiehlt sich, die Web-Konsole des VMM nur über eine interne Admin-Netzstruktur zugänglich zu machen und das NAS in die interne PKI einzubinden, um den Verwaltungszugriff vollständig zu verschlüsseln und zu authentifizieren, jenseits des bloßen HTTPS-Zertifikats.

Integritätsprüfung und Restore-Testverfahren in produktiven Umgebungen

Sicherheit endet nicht beim Backup. Wer virtuelle Maschinen repliziert oder per Snapshot sichert, muss regelmäßig verifizieren, ob sich diese Abbilder auch vollständig und funktionsfähig wiederherstellen lassen. In produktiven Szenarien empfiehlt sich daher ein dedizierter Testhost außerhalb des Clusters, auf dem kritische VMs in regelmäßigen Abständen aus Replikaten gebootet werden.

Dabei zeigt sich häufig, dass DNS-Registrierungen fehlen, Lizenzen ablaufen oder Maschinen im Wiederherstellungszustand fehlschlagen, weil Drittanwendungen auf nicht replizierten externen Ressourcen basieren. Zusätzlich sollte das VMM-Protokollmodul aktiviert bleiben, um Änderungen an HA-Zuordnungen, Snapshot-Vorgängen und Speicherbewegungen nachvollziehbar zu machen. Wer diese Daten regelmäßig exportiert und zentral speichert, kann im Schadensfall nachvollziehen, welche VM in welchem Zustand auf welchem Host zuletzt korrekt gelaufen ist. Damit werden Wiederherstellungen reproduzierbar, ein oft übersehener Bestandteil robuster Sicherheitsarchitektur.

Bildergalerie
Bildergalerie mit 5 Bildern

Fazit

Der sichere Betrieb virtueller Maschinen auf einem Synology-NAS erfordert weit mehr als die bloße Installation des Virtual Machine Manager. Wer Snapshots automatisiert, Replikationsziele verschlüsselt, High Availability kontrolliert implementiert und den Zugriff auf Verwaltungsfunktionen systematisch beschränkt, schafft eine Virtualisierungsumgebung, die sich auch in kritischen Szenarien behauptet. Entscheidend bleibt dabei die Verbindung aus regelmäßiger Überprüfung und klarer Trennung zwischen Datenhaltung, Netzwerkzugang und Administrationsschnittstellen. So wird aus dem NAS ein verlässlicher Host für produktive VMs.

(ID:50548601)

Weiterführende Inhalte