Informationen zum Virtual Trusted Platform Module

Ein Virtual Trusted Platform Module (vTPM) ist eine softwarebasierte Darstellung eines physischen Trusted Platform Module (TPM) 2.0 Chips. Mit der vTPM-Funktion können Sie einer virtuellen Maschine einen virtuellen TPM 2.0-Kryptoprozessor hinzufügen. Google Cloud VMware Engine unterstützt vTPMs.

Sie können vTPMs mit dem Standardschlüsselanbieter, dem Cloud Key Management Service oder einem externen KMS erstellen. Google empfiehlt, den Schlüsselanbieter in vCenter als Standardschlüsselanbieter zu konfigurieren, bevor Sie ein vTPM erstellen.

VMs vTPMs hinzufügen

Sie können VMs vTPMs hinzufügen, indem Sie der VM das virtuelle Gerät „Trusted Platform Module“ hinzufügen. Weitere Informationen finden Sie unter Fragen und Antworten zu vSphere Virtual TPM (vTPM).

vTPM und VM-Verschlüsselung für Arbeitslast-VMs

Arbeitslast-VMs verwenden einen internen Seed, der im Virtual Trusted Platform Module (vTPM) gespeichert ist, um Arbeitslastdaten zu verschlüsseln. Wenn Sie ein vTPM hinzufügen, verschlüsselt das System standardmäßig die VM-Home-Dateien, aber nicht die VM-Laufwerke (VMDKs). Wenn Sie die VMDKs verschlüsseln möchten, müssen Sie sie separat verschlüsseln.

Datenspeicherung und Voraussetzungen

Das System speichert vTPM-Daten in der NVRAM-Datei im Home-Verzeichnis der VM zusammen mit anderen VM-Metadaten. Um vTPM zu verwenden, müssen Sie die folgende Voraussetzung erfüllen:

  • Schlüsselanbieter konfigurieren: Sie müssen einen Schlüsselanbieter konfigurieren, da für die vTPM Funktionalität die VM-Verschlüsselung erforderlich ist. Die VM-Verschlüsselung schützt die vTPM-Daten im Home-Verzeichnis der VM.

Wichtige Überlegungen zum erneuten Verschlüsseln von VMs mit vTPM

Wenn Sie eine VM mit einem vTPM-Gerät neu verschlüsseln, wird nur der Verschlüsselungsschlüssel aktualisiert, der die vTPM-Daten im Home-Verzeichnis der VM schützt. Sie können den Seed in einem vTPM nach der Instanziierung nicht mehr ändern.

  • Wenn Sie einer VM ein vTPM-Gerät hinzufügen, generiert das Gerät einen internen Seed. Anwendungen, die auf dem Gastbetriebssystem ausgeführt werden, können diesen Seed verwenden, um Secrets oder Verschlüsselungsschlüssel zum Schutz von Anwendungsdaten zu generieren.
  • Außerdem ist für die Aktivierung von vTPM auf einer VM die VM-Dateiverschlüsselung mit einem externen Schlüsselanbieter erforderlich. Die VMDK-Verschlüsselung ist optional und standardmäßig deaktiviert.
  • Der Verschlüsselungsschlüssel des externen Schlüsselanbieters verschlüsselt die VM-Dateien (und die VMDKs, wenn Sie die Verschlüsselung aktiviert haben). Dieser Schlüssel ist unabhängig vom Seed, der im vTPM-Gerät gespeichert ist, oder den Schlüsseln, die von Anwendungen mit diesem Seed generiert werden.
  • Sie müssen den externen Schlüsselanbieter in vCenter als Standardschlüsselanbieter konfigurieren.
  • Wenn Sie eine VM mit einem vTPM-Gerät neu verschlüsseln, werden die VM-Dateien (und VMDKs, wenn Sie die Verschlüsselung aktiviert haben) mit einem neuen Verschlüsselungsschlüssel des externen Schlüsselanbieters neu verschlüsselt. Diese Aktion hat keine Auswirkungen auf den Seed oder die Secrets, die im vTPM-Gerät gespeichert sind.

Anforderung für verschlüsselte virtuelle Maschinen

Sie können Verschlüsselungsschlüssel für VMs mit dem Standard Google-owned and managed key schlüsselanbieter oder dem Cloud Key Management Service verwalten.

Wenn Sie die VM-Verschlüsselung (oder vTPM) für VMs in Ihrer privaten Cloud aktivieren und ein KMS zum Verwalten von Verschlüsselungsschlüsseln verwenden, müssen Sie jede VM neu verschlüsseln (flacher Schlüsselaustausch), nachdem Sie Ihren KMS-Schlüssel rotiert haben.

Bei einem flachen Schlüsselaustausch wird nur der Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) ersetzt und der Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) der VMs nicht geändert. Normalerweise lösen Sie einen flachen Schlüsselaustausch mit der Aktion Neu verschlüsseln im vSphere Client aus.

Bei dieser Aktion wird der vorhandene DEK mit einem neuen KEK neu verpackt (neu verschlüsselt). Dieser Vorgang ist schnell, da keine tatsächlichen Daten auf dem Laufwerk neu geschrieben werden. Stattdessen wird nur das kleine Schlüsselpaket aktualisiert, das den verschlüsselten DEK enthält. Weitere Informationen finden Sie in der folgenden VMware-Dokumentation:

Risiken, wenn verschlüsselte VMs nicht neu verschlüsselt werden

Wenn Sie verschlüsselte VMs nicht neu verschlüsseln, bevor Sie die rotierte (alte) KMS-Schlüsselversion löschen, kann dies zu folgenden Problemen führen:

  • Fehlerhafte vMotions: ESXi-Hosts können VM-DEKs während vMotion nicht entschlüsseln, wenn Sie die Zielhosts neu starten oder sie dem Cluster nach der KMS-Schlüsselrotation, aber vor dem VM-Schlüsselaustausch hinzufügen.
  • Fehler beim Einschalten: Wenn ein Host neu gestartet wird oder seinen lokalen Schlüsselspeicher leert, kann er keine Schlüssel mehr vom KMS abrufen. Wenn Sie die erforderlichen Schlüssel aus dem KMS gelöscht haben, kann der Host den DEK nicht entschlüsseln, wodurch verhindert wird, dass verschlüsselte VMs eingeschaltet werden.

Schritte zum Ausführen eines Schlüsselaustauschs für Arbeitslast-VMs

  1. Klicken Sie im vSphere Client mit der rechten Maustaste auf die VM.
  2. Wählen Sie VM-Richtlinien > Neu verschlüsseln aus.
  3. Bestätigen Sie die Neuverschlüsselungsanfrage im angezeigten Dialogfeld.
  4. Warten Sie, bis die Aufgabe abgeschlossen ist.
  5. Prüfen Sie den Schlüsselaustausch, indem Sie die VM zu einem Host migrieren, den Sie nach der KMS-Schlüsselrotation neu gestartet oder dem Cluster hinzugefügt haben.