Es esencial comprender los flujos de proceso de vSphere Trust Authority para saber cómo configurar y administrar la infraestructura de confianza.
Cómo configurar vSphere Trust Authority
vSphere Trust Authority no está activado de forma predeterminada. Debe configurar manualmente vSphere Trust Authority en el entorno. Consulte Configurar vSphere Trust Authority.
Cuando se configura vSphere Trust Authority, se deben especificar las versiones del software ESXi que acepta el servicio de atestación, así como los módulos de plataforma de confianza (Trusted Platform Modules, TPM) en los que se puede confiar.
TPM y atestación
En esta guía, se utilizan las siguientes definiciones al describir los TPM y la atestación.
| Término | Definición |
|---|---|
| Clave de aprobación (EK) | Un TPM se genera con un par de claves pública/privada de RSA integradas en el hardware, lo que se denomina clave de aprobación (Endorsement Key, EK). La EK es única para un TPM en particular. |
| Clave pública EK | La parte pública del par de claves EK. |
| Clave privada de EK | La parte privada del par de claves EK. |
| Certificado de EK | La clave pública EK envuelta con una firma. El certificado de EK lo crea el fabricante del TPM que utiliza su clave privada de la entidad de certificación para firmar la clave pública EK. No todos los TPM contienen un certificado de EK. En este caso, la clave pública EK no está firmada. |
| Atestación de TPM | La capacidad del servicio de atestación para comprobar el software que se ejecuta en un host remoto. La atestación de TPM se realiza a través de mediciones criptográficas que realiza el TPM mientras el host remoto se inicia y se retransmite al servicio de atestación cuando se solicita. El servicio de atestación establece una relación de confianza en el TPM a través de la clave pública EK o el certificado de EK. |
Configurar la confianza del TPM en los hosts de confianza
Un host ESXi de confianza debe contener un TPM. Un TPM se genera con un par de claves pública/privada integradas en el hardware, lo que se denomina clave de aprobación (Endorsement Key, EK). Aunque TPM 2.0 permite muchos pares de clave/certificado, el más común es un par de claves RSA-2048. Cuando una CA firma una clave pública EK de TPM, el resultado es el certificado de EK. Por lo general, el fabricante del TPM genera previamente al menos una EK, firma la clave pública con una entidad de certificación e inserta el certificado firmado en la memoria no volátil del TPM.
Puede configurar el servicio de atestación para que confíe en los TPM de la siguiente manera:
- Confiar en todos los certificados de CA con los que el fabricante firmó el TPM (la clave pública EK). La configuración predeterminada del servicio de atestación es confiar en los certificados de CA. En este enfoque, el mismo certificado de CA abarca varios hosts ESXi y, por lo tanto, reduce la sobrecarga administrativa.
- Confiar en el certificado de CA de TPM y la clave pública EK del host ESXi. La clave puede ser el certificado de EK o la clave pública EK. Aunque este enfoque proporciona más seguridad, requiere que vuelva a configurar la información sobre cada host de confianza.
- Algunos TPM no contienen un certificado de EK. En este caso, se confía en la clave pública EK.
La decisión de confiar en todos los certificados de CA del TPM es una operación adecuada. Solo se configuran certificados nuevos cuando se agrega una nueva clase de hardware al centro de datos. Al confiar en los certificados de EK individuales, puede limitar el acceso a hosts ESXi específicos.
También puede decidir no confiar en certificados de CA del TPM. A pesar de que es una situación poco común, puede utilizar esta configuración cuando una CA no firma una EK. Actualmente, esta funcionalidad no está totalmente implementada.
Atestar TPM
Para comenzar el proceso de atestación, el host ESXi de confianza en el clúster de confianza envía la clave pública EK y el certificado de EK preconfigurados al servicio de atestación en el clúster de Trust Authority. Cuando el servicio de atestación recibe la solicitud, busca la EK en su configuración, que puede ser la clave pública EK o el certificado de EK, o ambos, según la configuración. Si no hay casos válidos, el servicio de atestación rechaza la solicitud de atestación.
La EK no se utiliza directamente para la firma, por lo que se negocia una clave de atestación (AK o AIK). El protocolo de negociación garantiza que una AK recién creada se enlace a la EK comprobada anteriormente, lo que impide una situación de "man-in-the-middle" o una suplantación. Una vez que se negocia una AK, se vuelve a utilizar en solicitudes de atestación futuras, en lugar de generar una nueva cada vez.
El host ESXi de confianza lee los valores de oferta y PCR del TPM. La oferta está firmada por la AK. El host ESXi de confianza también lee el registro de eventos de TCG, que incluye todos los eventos que dieron como resultado el estado actual del PCR. Esta información del TPM se envía al servicio de atestación para su validación. El servicio de atestación verifica los valores de PCR mediante el registro de eventos.
Cómo funcionan los proveedores de claves con los servidores de claves
El servicio de proveedor de claves utiliza el concepto de proveedor de claves de confianza para ocultar las características del servidor de claves del resto del software del centro de datos. Cada proveedor de claves de confianza tiene una sola clave de cifrado principal configurada y hace referencia a uno o varios servidores de claves. La clave de cifrado principal está presente en los servidores de claves. Como parte de la configuración de vSphere Trust Authority, debe proporcionar la clave principal como una actividad independiente y activarla. El servicio de proveedor de claves puede tener varios proveedores de claves de confianza configurados. Cada proveedor de claves de confianza utiliza una clave principal diferente, pero puede hacer referencia al mismo servidor de claves de respaldo.
Cuando se agrega un nuevo proveedor de claves de confianza, el administrador de Trust Authority debe especificar el servidor de claves y un identificador de clave existente en ese servidor de claves.
En la siguiente figura, se muestra la relación entre el servicio de proveedor de claves y los servidores de claves.
Después de configurar un proveedor de claves de confianza para un clúster de confianza, el servicio de proveedor de claves puede aceptar solicitudes para ejecutar operaciones criptográficas en ese proveedor de claves de confianza. Por ejemplo, en esta figura, se configuran tres proveedores de claves de confianza, dos para KMS-1 y otro para KMS-2. El host de confianza solicita una operación de cifrado para key-provider-2. El host de confianza solicita una clave de cifrado que se generará y devolverá, y utiliza esta clave de cifrado para realizar operaciones de cifrado.
El servicio de proveedor de claves utiliza la clave principal a la que hace referencia el key-provider-2 para cifrar los datos en texto sin formato especificados y devolver el texto cifrado correspondiente. Más adelante, el host de confianza puede proporcionar el mismo texto cifrado a una operación de descifrado y recuperar el texto sin formato original.
Autenticación y autorización de vSphere Trust Authority
Las operaciones administrativas de vSphere Trust Authority requieren un usuario que sea miembro del grupo de TrustedAdmins. No es suficiente tener solo privilegios de administrador de Trust Authority para realizar todas las operaciones administrativas que implican a los hosts ESXi. Para obtener más información, consulte Requisitos previos y privilegios necesarios para vSphere Trust Authority.
Agregar un host de confianza a un clúster de confianza
Los pasos para agregar hosts ESXi inicialmente al clúster de confianza se describen en Configurar vSphere Trust Authority.
Más adelante, si desea agregar hosts ESXi al clúster de confianza, el flujo de trabajo es diferente. Consulte Agregar y eliminar hosts de vSphere Trust Authority.
Cuando se agregan inicialmente hosts ESXi al clúster de confianza, se debe recopilar la siguiente información:
- Certificado de TPM para cada tipo de hardware en el clúster
- Imagen de ESXi de cada versión de ESXi en el clúster
- Información principal de vCenter Server
Si más tarde agregan hosts ESXi a un clúster de confianza, es posible que necesite recopilar información adicional. Es decir, si los hosts ESXi nuevos difieren en el hardware o la versión de ESXi de los hosts originales, debe recopilar la información del nuevo host ESXi e importarla en el clúster de Trust Authority. Solo debe recopilar la información principal de vCenter Server una vez por sistema vCenter Server.
