Bundesamt für Sicherheit in der Informationstechnik

M 4.413 Sicherer Einsatz von Virtualisierung mit Hyper-V

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator, Fachverantwortliche, Leiter IT

Die Grundlage für den sicheren Einsatz von Virtualisierung mit Hyper-V bilden die Umsetzung der Planungsmaßnahmen (siehe M 2.490 Planung des Einsatzes von Virtualisierung mit Hyper-V ) und des Bausteins B 3.40Y Virtualisierung, hier insbesondere der Maßnahmen M 4.v7 Sicherer Betrieb von virtuellen Infrastrukturen und M 5.154 Sichere Konfiguration eines Netzes für virtuelle Infrastrukturen Die vorliegende Maßnahme zeigt die darauf aufsetzenden Hyper-V-spezifischen Punkte auf. Das Schwergewicht liegt auf den folgenden Punkten:

  • Wirksame Umsetzung der geplanten Berechtigungskonzepte
  • Härtung der Management-Instanz

Die Gäste selbst benötigen nur wenige Hyper-V-spezifische Anpassungen.

Für die Absicherung der Management-Instanz und der Konfiguration sowie für die Umsetzung der Berechtigungen bietet Microsoft mit dem Hyper-V Security Guide und den dort referenzierten Online-Ressourcen eine ausführliche Dokumentation an, die unbedingt genutzt werden sollte.

Management-Instanz

Die Grundlage für eine Härtung der Management-Instanz bildet die Reduzierung der Angriffsfläche durch eine Basis mit reduzierter Funktionalität (siehe M 2.490 Planung des Einsatzes von Virtualisierung mit Hyper-V ). Dazu eignen sich insbesondere Server Core (siehe M 4.416 Einsatz von Windows Server Core ), beziehungsweise der Stand-alone Hyper-V-Server.

Ohne eine solche Basis sollte zumindest der Einsatz der SSLF-Baseline (Specialized Security Limited Functionality) erfolgen. Sie kann auch zusätzlich angewandt werden.

Die SSLF-Baseline muss vor der Installation der Hyper-V-Rolle angewendet werden, sonst sind nach dem Einsatz der SSLF-Baseline Korrekturen notwendig, die in Microsofts Hyper-V Security Guide beschrieben sind.

Für die Management-Instanz gilt der Grundsatz: Es dürfen keine weiteren Dienste und Anwendungen betrieben werden. Ausnahmen gelten prinzipiell für Sicherheitssoftware wie Anti-Virus-Scanner, Host-IDS und standardmäßig genutzte Infrastrukturdienste (Zeitsynchronisierung), Remote-Management- und Softwarepflege-Werkzeuge. Nach Möglichkeit sollte auch auf diese Ausnahmen verzichtet werden.

Wird ein Anti-Virus-Scanner mit Echtzeit-Prüfung verwendet, sollten unbedingt alle Hyper-V-Ressourcen vom Scan ausgenommen werden, um Fehlalarme (Ausfälle von Gästen) und Performance-Einbußen zu vermeiden. Ein Virenschutz dieser Ressourcen muss durch Anti-Virus-Scanner in den Gastsystemen realisiert werden.

Für die Dekommissionierung von Gastsystemen sollten Tools zur sicheren Löschung der VHD-Dateien vorgehalten werden (siehe M 2.433 Überblick über Methoden zur Löschung und Vernichtung von Daten ).

Hyper-V-Konfiguration

Standardmäßig gibt es keine Limits für die CPU -Nutzung der Gäste, die sich denselben Kern teilen. Ohne Limits auf die CPU-Nutzung können einzelne Gäste Störungen anderer Dienste verursachen, indem sie die insgesamt verfügbare Rechenkapazität vollständig ausnutzen. Da die CPU-Anforderungen nicht immer vollständig im Voraus bekannt sind, sollte die CPU-Last der Gäste einem durchgängigen Monitoring unterliegen.

Mit Hyper-V lassen sich für die CPU-Nutzung Limits setzen (feste Grenze) oder Prioritäten einteilen (relative Gewichtung). Beide Möglichkeiten können nicht das "Aushungern" eines Systems vermeiden; dies ist nur durch das Setzen einer absoluten Reserve (Virtual Machine Reserve) möglich. Für kritische Services sollte diese Option genutzt werden.

Bei Host-Systemen mit vielen CPUs/Kernen ist diese Problematik weniger ausgeprägt, da eine implizite Einschränkung über die Zahl der virtuellen CPUs pro VM existiert.

Um eine ausreichende Trennung der Gäste sicherzustellen, muss bei der Konfiguration darauf geachtet werden, keine Überschneidungen im Zugriff für physische Ressourcen zuzulassen. Es darf keinen gemeinsamen Zugriff auf virtuelle Speichermedien (Virtual Hard Disks/VHDs) oder physische Devices des Hosts (USB-Stick, DVD-Laufwerk) geben.

Bei einer Serversicherung über den Hyper-V VSS Writer wird die Konfiguration des virtuellen Netzes und der virtuellen Netzkomponenten nicht mitgesichert. Die Netz-Konfiguration sollte daher so dokumentiert werden, dass im Notfall eine Wiederherstellung aus der Dokumentation möglich ist.

Berechtigungen

Häufig sollen die Administratoren der Gastsysteme ihre IT-Systeme selbstständig herunter- und hochfahren und auf die Konsole zugreifen können, ohne dabei Einfluss auf andere Systeme und Netze zu haben (siehe M 2.446 Aufteilung der Administrationstätigkeiten bei Virtualisierungsservern ).

Um dies umzusetzen, dürfen für Hyper-V im Autorisierungs-Manager nur Berechtigungen für folgende Vorgänge vergeben werden:

  • Keine Berechtigungen für Hyper-V-Service- und Netzwerk-Vorgänge außer "Read"-Vorgänge
  • Für VM-Operationen keine Berechtigungen außer:

Alle weiteren Berechtigungen können die Trennung zwischen den Systemen beeinträchtigen und benötigen eine auf die spezifische Umgebung angepasste Sicherheitsbetrachtung.

Gastsystemkonfiguration

Die Maßnahme M 4.348 Zeitsynchronisation in virtuellen IT-Systemen fordert die Zeitsynchronisation der Gäste, um die durch die Virtualisierung erzeugte lastabhängige Drift auszugleichen. Ohne eine Zeitsynchronisation sind die Gastsysteme auf die Timer-Interrupts der virtuellen CPU angewiesen. Damit laufen die Uhren der VM mit steigender Last anderer Systeme ungenauer. Für Hyper-V kommt die Problematik des Supports verschiedener Zeitzonen in Gästen (Windows erwartet, dass die RTC mit lokaler Zeit läuft) sowie von Suspend- und Resume-Events hinzu. Werden Snapshots reaktiviert, zum Beispiel nach dem Bewegen einer VM auf einen anderen Server, läuft das Gastsystem mit einer falschen Uhrzeit und benötigt mitunter lange, um sich aus einer externen Quelle neu zu synchronisieren. Um die Synchronisation zu ermöglichen, bietet Microsoft einen Synchronisierungsservice als Teil der "Hyper-V Integration Services" an, der im Gastsystem installiert werden muss. Über diesen Dienst wird die Systemzeit des Gastes mit der Uhr des Host-Systems abgeglichen; außerdem werden bei virtualisierungsbedingten Zeitsprüngen (Suspend/Resume) die Uhren sofort korrigiert. Das Hostsystem sollte sich dabei mit einer zuverlässigen Netzzeit synchronisieren (siehe M 4.227 Einsatz eines lokalen NTP-Servers zur Zeitsynchronisation ).

Probleme können auftreten, wenn Hostsysteme oder Gäste Mitglieder von Domänen oder gar von unterschiedlichen Domänen sind. Dann werden die Uhren gleichzeitig über das Netz und lokal korrigiert. Dies führt zu häufigen geringen Abweichungen. Insbesondere bei Active Directory-Servern als Gastsystem kann dies zu Problemen mit der Replikation führen. In diesem Fall sollte die Synchronisation mit dem Host deaktiviert werden. Dabei geht allerdings die Fähigkeit verloren, nach einem Wiederanlauf der virtuellen Maschine schnell die ursprüngliche Zeit wiederherzustellen.

Es ist möglich, auf einem Windows-Gast die Synchronisierung bei installierten "Integration Services" mit dem Host nur teilweise zu deaktivieren, ohne das Setzen der Zeit nach dem Boot und bei Suspend-/Resume-Ereignissen zu beeinflussen. Dazu dient das Kommando

reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t reg_dword /d 0

Anschließend muss im Gast eine externe Zeitquelle konfiguriert werden.

Wann immer mit einer externen Zeitquelle synchronisiert wird, sollte ein relativ kurzes Synchronisierungsintervall gewählt werden (alle 10-20 Minuten), um die situationsbedingt hohe Drift kompensieren zu können.

Prüffragen:

  • Ist die Management-Instanz des Hyper-V-Servers als minimales System ausgelegt (durch den Einsatz von Server Core) bzw. mit einer SSLF-Baseline gehärtet?

  • Werden keine weiteren Dienste durch die Hyper-V-Management-Instanz angeboten?

  • Sind Hyper-V-Ressourcen vom Virenscan ausgenommen?

  • Sind die CPU-Anforderungen von kritischen Diensten in Hyper-V-Systemen in ausreichende CPU-Reservierungen umgesetzt worden?

  • Wird die virtuelle Netzwerk-Konfiguration von Hyper-V separat gesichert und dokumentiert?

  • Sind physische Speichermedien (für den direkten Zugriff) jeweils nur einer einzigen VM unter Hyper-V zugeordnet?

Stand: 13. EL Stand 2013