En vSphere 7.0 Update 2 y versiones posteriores, las máquinas virtuales cifradas y los TPM virtuales pueden seguir funcionando opcionalmente incluso cuando el servidor de claves está desconectado temporalmente o no está disponible. Los hosts ESXi pueden conservar las claves de cifrado para continuar con el cifrado y las operaciones de vTPM.
Antes de vSphere 7.0 Update 2, las máquinas virtuales cifradas y los vTPM requieren que el servidor de claves esté siempre disponible para funcionar. En vSphere 7.0 Update 2 y versiones posteriores, los dispositivos cifrados pueden funcionar incluso cuando se interrumpe el acceso a un servidor de claves.
A partir de vSphere 7.0 Update 3, los clústeres de vSAN cifrados también pueden funcionar incluso cuando se interrumpe el acceso a un proveedor de claves.
Persistencia de claves en el host ESXi
Cuando se utiliza un proveedor de claves estándar, el host de ESXi se basa en vCenter Server para administrar las claves de cifrado. Cuando se utiliza un proveedor de claves de confianza, el host de ESXi se basa directamente en los hosts de Trust Authority para las claves, y vCenter Server no está involucrado.
Independientemente del tipo de proveedor de claves, el host ESXi obtiene las claves inicialmente y las conserva en su memoria caché de claves. Si el host ESXi se reinicia, pierde su memoria caché de claves. El host ESXi vuelve a solicitar las claves, ya sea del servidor de claves (proveedor de claves estándar) o de los hosts de Trust Authority (proveedor de claves de confianza). Cuando el host ESXi intenta obtener claves y el servidor de claves está sin conexión o no se puede acceder a él, los vTPM y el cifrado de cargas de trabajo no pueden funcionar. Para las implementaciones de tipo Edge, en las que normalmente no se implementa un servidor de claves en el sitio, la pérdida de conectividad con un servidor de claves puede provocar un tiempo de inactividad innecesario para las cargas de trabajo cifradas.
En vSphere 7.0 Update 2 y versiones posteriores, las cargas de trabajo cifradas pueden seguir funcionando incluso cuando el servidor de claves está sin conexión o no se puede acceder a él. Si el host ESXi tiene un TPM, las claves de cifrado se conservan en el TPM después de reiniciar. Por lo tanto, incluso si un host ESXi se reinicia, no es necesario que solicite claves de cifrado. Además, las operaciones de cifrado y descifrado pueden continuar cuando el servidor de claves no está disponible, ya que las claves han persistido en el TPM. Básicamente, cuando el servidor de claves o los hosts de Trust Authority no están disponibles, puede seguir ejecutando cargas de trabajo cifradas "sin servidor de claves". Además, los vTPM también pueden seguir funcionando aunque no se pueda acceder al servidor de claves.
Persistencia de claves y vSphere Native Key Provider
Cuando se utiliza un vSphere Native Key Provider, vSphere genera las claves de cifrado y no se requiere ningún servidor de claves. Los hosts ESXi obtienen una clave de derivación de claves (Key Derivation Key, KDK), que se utiliza para derivar otras claves. Después de recibir el KDK y generar otras claves, los hosts ESXi no necesitan acceso a vCenter Server para realizar operaciones de cifrado. Básicamente, vSphere Native Key Provider siempre se ejecuta "sin servidor de claves".
El KDK persiste en un host ESXi de forma predeterminada incluso después del reinicio, e incluso cuando vCenter Server no está disponible después de que se reinicie el host.
Puede activar la persistencia de claves con vSphere Native Key Provider, pero normalmente no es necesario. Los hosts ESXi tienen acceso completo al proveedor de claves nativo de vSphere; por lo que la persistencia adicional de las claves es redundante. Un caso práctico para activar la persistencia de claves con vSphere Native Key Provider es cuando también se configuró un proveedor de claves estándar (servidor KMIP externo).
Cómo configurar la persistencia de claves
Para habilitar o deshabilitar la persistencia de claves, consulte Habilitar y deshabilitar la persistencia de claves en un ESXi host.