Acerca del módulo de plataforma de confianza virtual

Un módulo de plataforma de confianza virtual (vTPM) es una representación basada en software de un chip físico de módulo de plataforma de confianza (TPM) 2.0. Con la función vTPM, puedes agregar un criptoprocesador virtual TPM 2.0 a una máquina virtual. Google Cloud VMware Engine admite vTPMs.

Puedes usar el proveedor de claves predeterminado, Cloud Key Management Service o un KMS externo para crear vTPMs. Google recomienda que configures el proveedor de claves como el proveedor de claves predeterminado en vCenter antes de crear un vTPM.

Cómo agregar vTPMs a las VMs

Para agregar vTPMs a las VMs, agrega el dispositivo virtual "Módulo de plataforma de confianza" a la VM. Consulta Preguntas y respuestas sobre vSphere Virtual TPM (vTPM) para obtener más información.

vTPM y encriptación de VM para VMs de cargas de trabajo

Las VMs de cargas de trabajo usan una semilla interna almacenada dentro del módulo de plataforma de confianza virtual (vTPM) para encriptar los datos de la carga de trabajo. Cuando agregas un vTPM, el sistema encripta los archivos de inicio de la VM de forma predeterminada, pero no incluye los discos de la máquina virtual (VMDKs). Para encriptar los VMDKs, debes encriptarlos por separado.

Almacenamiento de datos y requisitos previos

El sistema almacena los datos de vTPM en el archivo NVRAM del directorio principal de la VM, junto con otros metadatos de la VM. Para usar vTPM, debes cumplir con el siguiente requisito:

  • Configurar un proveedor de claves: Debes configurar un proveedor de claves porque la funcionalidad de vTPM requiere la encriptación de VM. La encriptación de VM protege los datos de vTPM en el directorio principal de la VM.

Consideraciones clave para volver a generar claves de VMs con vTPM

Volver a generar claves de una VM con un dispositivo vTPM solo actualiza la clave de encriptación que protege los datos de vTPM en el directorio principal de la VM. No puedes cambiar la semilla dentro de un vTPM después de la creación de instancias.

  • Cuando agregas un dispositivo vTPM a una VM, el dispositivo genera una semilla interna. Las aplicaciones que se ejecutan en el sistema operativo invitado pueden usar esta semilla para generar secretos o claves de encriptación para proteger los datos de la aplicación.
  • Por separado, habilitar vTPM en una VM requiere la encriptación de archivos de VM que usa un proveedor de claves externo. La encriptación de VMDK es opcional y está inhabilitada de forma predeterminada.
  • La clave de encriptación del proveedor de claves externo encripta los archivos de la VM (y los VMDKs, si habilitaste la encriptación). Esta clave está separada de la semilla almacenada en el dispositivo vTPM o de las claves que generan las aplicaciones mediante esa semilla.
  • Debes configurar el proveedor de claves externo como el proveedor de claves predeterminado en vCenter.
  • Volver a encriptar una VM con un dispositivo vTPM vuelve a encriptar los archivos de la VM (y los VMDKs, si habilitaste la encriptación) con una nueva clave de encriptación del proveedor de claves externo. Esta operación no afecta la semilla ni los secretos almacenados en el dispositivo vTPM.

Requisito para máquinas virtuales encriptadas

Puedes administrar las claves de encriptación para las VMs con el proveedor predeterminado Google-owned and managed key o Cloud Key Management Service.

Si habilitas la encriptación de VM (o vTPM) para cualquier VM en tu nube privada y usas un KMS para administrar las claves de encriptación, debes volver a encriptar (volver a generar claves de forma superficial) cada VM después de rotar tu clave de KMS.

Volver a generar claves de forma superficial reemplaza solo la clave de encriptación de claves (KEK) y no cambia la clave de encriptación de datos (DEK) de las VMs. Por lo general, se activa la regeneración de claves superficial con la acción Volver a encriptar en vSphere Client.

Durante esta operación, el sistema vuelve a encapsular (volver a encriptar) la DEK existente con una KEK nueva. Este proceso es rápido porque no vuelve a escribir datos reales en el disco; en cambio, solo actualiza el paquete de claves pequeño que contiene la DEK encriptada. Para obtener más información, consulta la siguiente documentación de VMware:

Riesgos de no volver a generar claves de VMs encriptadas

Si no vuelves a generar claves de VMs encriptadas antes de borrar la versión de clave de KMS rotada (antigua), puedes causar los siguientes problemas:

  • vMotions fallidos: Los hosts ESXi no pueden desencriptar las DEKs de VM durante vMotion si reinicias los hosts de destino o los agregas al clúster después de la rotación de claves de KMS, pero antes de realizar el cambio de combinaciones de la VM.
  • Errores de encendido: Si un host se reinicia o borra su caché de claves local, no puede volver a adquirir claves del KMS. Si borraste las claves necesarias del KMS, el host no puede desencriptar la DEK, lo que impide que se enciendan las VMs encriptadas.

Pasos para realizar una operación de regeneración de claves en VMs de cargas de trabajo

  1. En vSphere Client, haz clic con el botón derecho en la VM.
  2. Selecciona Políticas de VM > Volver a encriptar.
  3. Confirma la solicitud de volver a encriptar en el diálogo que aparece.
  4. Espera a que se complete la tarea.
  5. Para verificar la regeneración de claves, migra la VM a un host que reiniciaste o agregaste al clúster después de la rotación de claves de KMS.