Die folgenden empfohlenen Vorgehensweisen für die Verschlüsselung von virtuellen Maschinen sollten zwecks Vermeidung späterer Probleme befolgt werden, zum Beispiel wenn Sie ein vm-support-Paket erstellen.
Allgemeine empfohlene Vorgehensweisen
Um Probleme zu vermeiden, befolgen Sie diese allgemeinen Best Practices.
- Verschlüsseln Sie keine virtuellen Maschinen der vCenter Server Appliance.
- Wenn Ihr ESXi-Host fehlschlägt, rufen Sie schnellstmöglich das Support-Paket ab. Sie benötigen den Hostschlüssel zum Generieren eines Support-Pakets mit einem Kennwort oder zum Entschlüsseln des Core-Dumps. Wenn der Host neu gestartet wird, ändert sich der Hostschlüssel möglicherweise. Ist dies der Fall, können Sie mit diesem Hostschlüssel kein Support-Paket mehr mit einem Kennwort generieren bzw. keine Core-Dumps im Support-Paket entschlüsseln.
- Verwalten Sie die Namen von Schlüsselanbietern sorgfältig. Wenn sich der Name des Schlüsselanbieters für einen bereits verwendeten Schlüsselserver ändert, wechseln VMs, die mit Schlüsseln aus diesem Schlüsselserver verschlüsselt sind, beim Einschalten oder bei der Registrierung in einen gesperrten Zustand. Entfernen Sie in diesem Fall den Schlüsselserver aus dem vCenter Server und fügen Sie ihn mit dem Schlüsselanbieternamen hinzu, den Sie anfänglich verwendet haben.
- Bearbeiten Sie keine VMX-Dateien und VMDK-Deskriptordateien. Diese Dateien enthalten das Verschlüsselungspaket. Möglicherweise kann die virtuelle Maschine nach Ihren Änderungen nicht mehr wiederhergestellt werden und dieses Wiederherstellungsproblem kann nicht behoben werden.
- Der vSphere-Prozess zur Verschlüsselung virtueller Maschinen verschlüsselt die Daten auf dem Host, bevor die Daten in den Speicher geschrieben werden. Die Effektivität von Back-End-Speicherfunktionen wie Deduplizierung, Komprimierung, Replizierung usw. kann beeinträchtigt werden, wenn virtuelle Maschinen auf diese Weise verschlüsselt werden.
- Wenn Sie mehrere Verschlüsselungsebenen verwenden, z. B. die Verschlüsselung virtueller Maschinen von vSphere und In-Guest-Verschlüsselung (BitLocker, dm-crypt usw.), kann dies die Gesamtleistung der virtuellen Maschinen beeinträchtigen, da die Verschlüsselungsprozesse zusätzliche CPU- und Arbeitsspeicherressourcen verwenden.
- Sorgen Sie dafür, dass replizierte Kopien von virtuellen Maschinen, die über die Verschlüsselung virtueller Maschinen von vSphere verschlüsselt wurden, in der Wiederherstellungs-Site Zugriff auf die Verschlüsselungsschlüssel haben. Für Standardschlüsselanbieter ist dies Teil des Designs des Schlüsselverwaltungssystems außerhalb von vSphere. Stellen Sie für vSphere Native Key Provider sicher, dass eine Sicherungskopie des Schlüssels von Native Key Provider vorhanden ist und vor Verlust geschützt ist. Weitere Informationen finden Sie unter Sichern eines vSphere Native Key Providers.
- Die Verschlüsselung ist CPU-intensiv. Mit AES-NI wird die Verschlüsselungsleistung deutlich gesteigert. Aktivieren Sie AES-NI im BIOS.
Empfohlene Vorgehensweisen für verschlüsselte Core-Dumps
Befolgen Sie diese empfohlenen Vorgehensweisen, damit keine Probleme auftreten, wenn Sie einen Core-Dump zwecks Problemdiagnose untersuchen möchten.
- Erstellen Sie eine Richtlinie bezüglich Core-Dumps. Core-Dumps sind verschlüsselt, da sie vertrauliche Informationen wie etwa Schlüssel enthalten können. Wenn Sie einen Core-Dump entschlüsseln, gehen Sie sehr sorgfältig mit den enthaltenen vertraulichen Informationen um. ESXi- Core-Dumps können Schlüssel für den ESXi-Host und die sich darauf befindlichen virtuellen Maschinen enthalten. Sie sollten den Hostschlüssel ändern und verschlüsselte virtuelle Maschinen erneut verschlüsseln, nachdem Sie einen Core-Dump entschlüsselt haben. Beide Aufgaben können mit der vSphere API durchgeführt werden.
Weitere Informationen finden Sie unter vSphere VM-Verschlüsselung und Core-Dumps.
- Verwenden Sie immer ein Kennwort, wenn Sie ein vm-support-Paket erfassen. Sie können das Kennwort angeben, wenn Sie das Support-Paket vom vSphere Client generieren oder den vm-support-Befehl verwenden.
Das Kennwort verschlüsselt Core-Dumps erneut, die interne Schlüssel zur Verwendung von auf diesem Kennwort basierenden Schlüsseln verwenden. Sie können das Kennwort zu einem späteren Zeitpunkt zum Entschlüsseln und Verschlüsseln von Core-Dumps verwenden, die möglicherweise im Support-Paket enthalten sind. Nicht verschlüsselte Core-Dumps und Protokolle sind bei Verwendung der Kennwortoption nicht betroffen.
- Das von Ihnen während der vm-support-Paketerstellung angegebene Kennwort wird in vSphere-Komponenten nicht dauerhaft gespeichert. Sie müssen Ihre Kennwörter für Support-Pakete selbst speichern bzw. diese notieren.
- Bevor Sie den Hostschlüssel ändern, generieren Sie ein vm-support-Paket mit einem Kennwort. Sie können das Kennwort später für den Zugriff auf alle Core-Dumps verwenden, die ggf. mit dem alten Hostschlüssel verschlüsselt wurden.
Empfohlene Vorgehensweisen bei der Verwaltung des Lebenszyklus von Schlüsseln
- Sie müssen die entsprechenden Richtlinien erstellen und anwenden, die eine Schlüsselserver-Verfügbarkeit sicherstellen.
Wenn der Schlüsselserver nicht verfügbar ist, sind VM-Vorgänge nicht möglich, bei denen vCenter Server den Schlüssel vom Schlüsselserver abrufen muss. Laufende virtuelle Maschinen werden daher fortwährend ausgeführt und Sie können sie ausschalten, einschalten und neu konfigurieren. Sie können eine virtuelle Maschine jedoch nicht auf einen Host verlagern, der nicht über die Schlüsselinformationen verfügt.
Die meisten Schlüsselserver-Lösungen beinhalten HA (High Availability)-Funktionen. Sie können den vSphere Client oder die API verwenden, um einen Schlüsselanbieter und die verbundenen Schlüsselserver anzugeben.
Hinweis: Ab Version 7.0 Update 2 können verschlüsselte virtuelle Maschinen und virtuelle TPMs auch dann weiterhin funktionieren, wenn der Schlüsselserver vorübergehend offline oder nicht verfügbar ist. Die ESXi-Hosts können die Verschlüsselungsschlüssel beibehalten, um die Verschlüsselung und vTPM-Vorgänge fortzusetzen. Weitere Informationen hierzu finden Sie unter Schlüsselpersistenz – Übersicht. - Sie müssen die Schlüssel speichern und eine Standardisierung durchführen, wenn sich die Schlüssel für vorhandene virtuelle Maschinen nicht im aktiven Zustand befinden.
Der KMIP-Standard definiert die folgenden Zustände für Schlüssel.
- Voraktiv
- Aktiv
- Deaktiviert
- Manipuliert
- Zerstört
- Zerstört/Manipuliert
Bei der Verschlüsselung der virtuellen vSphere-Maschinen werden nur aktive Schlüssel verwendet. Wenn ein Schlüssel voraktiv ist, wird dieser über die Funktion „Verschlüsselung der virtuellen vSphere-Maschine“ aktiviert. Wenn der Schlüsselzustand „Deaktiviert“, „Manipuliert“, „Zerstört“ oder „Zerstört/Manipuliert“ ist, können Sie eine virtuelle Maschine oder Festplatte nicht mit diesem Schlüssel verschlüsseln.
Für Schlüssel, die andere Zustände aufweisen, werden virtuelle Maschinen unter Verwendung dieser Schlüssel weiterhin ausgeführt. Ob ein Klon- oder Migrationsvorgang erfolgreich ist, hängt davon ab, ob sich der Schlüssel bereits auf dem Host befindet.- Wenn sich der Schlüssel auf einem Zielhost befindet, wird der Vorgang erfolgreich ausgeführt, auch wenn der Schlüssel auf dem Schlüsselserver nicht aktiv ist.
- Wenn sich die erforderlichen Schlüssel für die virtuellen Maschinen und die virtuellen Festplatten nicht auf dem Zielhost befinden, muss vCenter Server die Schlüssel vom Schlüsselserver abrufen. Wenn es sich bei dem Schlüsselzustand um „Deaktiviert“, „Manipuliert“, „Zerstört“ oder „Zerstört/Manipuliert“ handelt, zeigt vCenter Server eine Fehlermeldung an und der Vorgang wird nicht erfolgreich durchgeführt.
Ein Klon- oder Migrationsvorgang wird erfolgreich durchgeführt, wenn sich der Schlüssel bereits auf dem Host befindet. Der Vorgang schlägt fehl, wenn vCenter Server die Schlüssel vom Schlüsselserver abruft.
Wenn ein Schlüssel nicht aktiv ist, führen Sie eine erneute Verschlüsselung unter Verwendung der API durch. Weitere Informationen finden Sie im Programmierhandbuch zum vSphere Web Services SDK.
- Entwickeln Sie Richtlinien für die Schlüsselrotation, sodass Schlüssel nach einer bestimmten Zeit stillgelegt und ein Rollover durchgeführt wird.
- Vertrauenswürdiger Schlüsselanbieter: Ändern Sie den primären Schlüssel eines vertrauenswürdigen Schlüsselanbieters.
- vSphere Native Key Provider: Ändern Sie die
key_id
eines vSphere Native Key Provider.
Empfohlene Vorgehensweisen für das Sichern und Wiederherstellen
- Es werden nicht alle Sicherungsarchitekturen unterstützt. Weitere Informationen hierzu finden Sie unter Interoperabilität bei der Verschlüsselung von virtuellen Maschinen.
- Erstellen Sie Richtlinien für Wiederherstellungsvorgänge. Da die Sicherung immer auf Klartextdaten beruht, sollten Sie virtuelle Maschinen direkt nach Beendigung der Wiederherstellung verschlüsseln. Sie können angeben, dass die virtuelle Maschine als Teil des Wiederherstellungsvorgangs verschlüsselt wird. Wenn möglich, verschlüsseln Sie die virtuelle Maschine als Teil des Wiederherstellungsvorgangs, um die Offenlegung von vertraulichen Informationen zu vermeiden. Um die Verschlüsselungsrichtlinie für Festplatten zu ändern, die mit der virtuellen Maschine verbunden sind, ändern Sie die Speicherrichtlinie für diese Festplatte.
- Da die VM-Home-Dateien verschlüsselt sind, stellen Sie sicher, dass die Verschlüsselungsschlüssel zum Zeitpunkt der Wiederherstellung verfügbar sind.
Empfohlene Vorgehensweisen für die Leistung
- Die Verschlüsselungsleistung richtet sich nach der CPU- und Speicherkapazität.
- Die Verschlüsselung von vorhandenen virtuellen Maschinen nimmt mehr Zeit in Anspruch als die Verschlüsselung einer virtuellen Maschine bei deren Erstellung. Verschlüsseln Sie also eine virtuelle Maschine wenn möglich bei deren Erstellung.
Empfohlene Vorgehensweisen für Speicherrichtlinien
Details zur Anpassung von Speicherrichtlinien finden Sie in der vSphere-Speicher-Dokumentation.
Entfernen von Verschlüsselungsschlüsseln – Best Practices
Um sicherzustellen, dass Verschlüsselungsschlüssel aus einem Cluster entfernt werden, starten Sie nach dem Löschen, Aufheben der Registrierung oder Verschieben der verschlüsselten virtuellen Maschine in einen anderen vCenter Server die ESXi-Hosts im Cluster neu.