Administración del servicio de protección de host

• Se aplica a:

  ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

El Servicio de protección de host (HGS) es la pieza central de la solución de tejido protegido. Su misión es garantizar que el anfitrión o la empresa —y el software de confianza en ejecución— reconozcan los hosts de Hyper-V del tejido y administrar las claves empleadas para poner en marcha máquinas virtuales blindadas. Cuando un inquilino decide confiar en usted para hospedar sus máquinas virtuales blindadas, está depositando su confianza en su configuración y administración del Servicio de protección de host. Por lo tanto, es muy importante seguir los procedimientos recomendados al administrar el Servicio de protección de host para garantizar la seguridad, disponibilidad y confiabilidad del tejido protegido. Las instrucciones de las secciones siguientes abordan los problemas operativos más comunes a los que se enfrentan los administradores de HGS.

Limitación del acceso de administrador a HGS

Como la cuestión de la seguridad de HGS es delicada, es importante velar por que sus administradores sean miembros de alta confianza de su organización e, idealmente, independientes de los administradores de los recursos del tejido. Además, se recomienda administrar HGS únicamente desde estaciones de trabajo seguras que utilicen protocolos de comunicación seguros, como WinRM a través de HTTPS.

Separación de obligaciones

Al configurar HGS, se le ofrece la opción de crear un bosque de Active Directory aislado solo para HGS o unir HGS a un dominio de confianza existente. Esta decisión, así como los roles que asigne a los administradores de su organización, determinan el límite de confianza para HGS. Aquel que tenga acceso a HGS, ya sea directamente como administrador o indirectamente como administrador de otro producto (por ejemplo, Active Directory) que pueda influir en HGS, tiene control sobre el tejido protegido. Los administradores de HGS eligen qué hosts de Hyper-V tienen autorización para ejecutar máquinas virtuales blindadas y administrar los certificados necesarios para poner en marcha máquinas virtuales blindadas. Un atacante o un administrador malintencionado que tenga acceso a HGS podría usar esta capacidad para autorizar a los hosts en riesgo a ejecutar máquinas virtuales blindadas, iniciar un ataque por denegación de servicio mediante la eliminación del material clave y mucho más.

Para evitar este riesgo, se recomienda encarecidamente limitar la superposición entre los administradores de HGS (incluido el dominio al que está unido HGS) y los entornos de Hyper-V. Al garantizar que ningún administrador tenga acceso a ambos sistemas, un atacante tendría que poner en riesgo dos cuentas diferentes de dos personas para completar su objetivo de cambiar las directivas de HGS. Esto también significa que los administradores de dominio y de empresa para los dos entornos de Active Directory no deben ser la misma persona, ni HGS debe utilizar el mismo bosque de Active Directory que sus hosts de Hyper-V. Cualquiera que pueda concederse a sí mismo acceso a más recursos plantea un riesgo para la seguridad.

Uso de Just Enough Administration

HGS incluye roles Just Enough Administration (JEA) integrados para ayudarle a administrarlo de forma más segura. JEA le ayuda porque permite delegar tareas de administrador a usuarios que no son administradores; por ello, las personas que administran directivas de HGS no necesitan ser realmente administradores de toda la máquina o el dominio. JEA funciona limitando los comandos que un usuario puede ejecutar en una sesión de PowerShell y usando una cuenta local temporal en segundo plano (única para cada sesión de usuario) para ejecutar los comandos que normalmente requieren elevación.

HGS incluye dos roles de JEA preconfigurados:

• Administradores de HGS, que permite a los usuarios administrar todas las directivas de HGS, incluida la autorización a nuevos hosts para ejecutar máquinas virtuales blindadas.
• Revisores de HGS, que solo permite a los usuarios auditar las directivas existentes. No pueden realizar ningún cambio en la configuración de HGS.

Para usar JEA, primero debe crear un nuevo usuario estándar y convertirlo en miembro del grupo de administradores o revisores de HGS. Si usó Install-HgsServer para configurar un nuevo bosque para HGS, estos grupos se denominarán "Administradores de nombre de servicio" y "Revisores de nombre de servicio", respectivamente, donde nombre de servicio es el nombre de la red del clúster de HGS. Si ha unido HGS a un dominio existente, debe hacer referencia a los nombres de grupo especificados en Initialize-HgsServer.

Creación de usuarios estándar para los roles de administrador y revisor de HGS

$hgsServiceName = (Get-ClusterResource HgsClusterResource | Get-ClusterParameter DnsName).Value
$adminGroup = $hgsServiceName + "Administrators"
$reviewerGroup = $hgsServiceName + "Reviewers"

New-ADUser -Name 'hgsadmin01' -AccountPassword (Read-Host -AsSecureString -Prompt 'HGS Admin Password') -ChangePasswordAtLogon $false -Enabled $true
Add-ADGroupMember -Identity $adminGroup -Members 'hgsadmin01'

New-ADUser -Name 'hgsreviewer01' -AccountPassword (Read-Host -AsSecureString -Prompt 'HGS Reviewer Password') -ChangePasswordAtLogon $false -Enabled $true
Add-ADGroupMember -Identity $reviewerGroup -Members 'hgsreviewer01'

Auditoría de directivas con el rol de revisor

En una máquina remota que tenga conectividad de red con HGS, ejecute los siguientes comandos en PowerShell para entrar en la sesión de JEA con las credenciales de revisor. Es importante tener en cuenta que, dado que la cuenta de revisor es simplemente un usuario estándar, no se puede usar para el control remoto habitual de Windows PowerShell, el acceso de Escritorio remoto a HGS, etc.

Enter-PSSession -ComputerName <hgsnode> -Credential '<hgsdomain>\hgsreviewer01' -ConfigurationName 'microsoft.windows.hgs'

Puede comprobar entonces qué comandos se permiten en la sesión con Get-Command y ejecutar los comandos permitidos para auditar la configuración. En el ejemplo siguiente, comprobamos qué directivas están habilitadas en HGS.

Get-Command

Get-HgsAttestationPolicy

Escriba el comando Exit-PSSession o su alias, exit, cuando haya terminado de trabajar con la sesión de JEA.

Adición de una nueva directiva a HGS mediante el rol de administrador

Para cambiar una directiva de forma efectiva, debe conectarse al punto de conexión de JEA con una identidad que pertenezca al grupo "Administradores de HGS". En el ejemplo siguiente, se muestra cómo puede copiar una nueva directiva de integridad de código en HGS y registrarla mediante JEA. La sintaxis puede ser diferente a la que está acostumbrado. Esto es para dar cabida a algunas de las restricciones de JEA, como la falta de acceso al sistema de archivos completo.

$cipolicy = Get-Item "C:\temp\cipolicy.p7b"
$session = New-PSSession -ComputerName <hgsnode> -Credential '<hgsdomain>\hgsadmin01' -ConfigurationName 'microsoft.windows.hgs'
Copy-Item -Path $cipolicy -Destination 'User:' -ToSession $session

# Now that the file is copied, we enter the interactive session to register it with HGS
Enter-PSSession -Session $session
Add-HgsAttestationCiPolicy -Name 'New CI Policy via JEA' -Path 'User:\cipolicy.p7b'

# Confirm it was added successfully
Get-HgsAttestationPolicy -PolicyType CiPolicy

# Finally, remove the PSSession since it is no longer needed
Exit-PSSession
Remove-PSSession -Session $session

Supervisión de HGS

Orígenes de eventos y reenvío

Los eventos de HGS se mostrarán en el registro de eventos de Windows en 2 orígenes:

• HostGuardianService-Attestation
• HostGuardianService-KeyProtection

Para ver estos eventos, abra Visor de eventos y vaya a Microsoft-Windows-HostGuardianService-Attestation y Microsoft-Windows-HostGuardianService-KeyProtection.

En un entorno grande, a menudo es preferible reenviar eventos a un recopilador central de eventos de Windows para facilitar el análisis de los eventos. Para obtener más información, consulte la documentación sobre el reenvío de eventos de Windows.

Uso de System Center Operations Manager

También puede usar System Center 2016 - Operations Manager para supervisar HGS y los hosts protegidos. El módulo de administración de tejido protegido cuenta con supervisores de eventos para comprobar la presencia de alguna de las habituales configuraciones erróneas que pueden provocar un tiempo de inactividad del centro de datos, como los hosts que no pasan la atestación y la notificación de errores por parte de los servidores de HGS.

Para empezar, instale y configure SCOM 2016 y descargue el módulo de administración de tejido protegido. En la guía del módulo de administración incluida se explica cómo configurar el módulo de administración y se describe el alcance de los supervisores.

Copia de seguridad y restauración de HGS

Planeamiento de recuperación ante desastres

Al elaborar los planes de recuperación ante desastres, es importante tener en cuenta los requisitos únicos del Servicio de protección de host en el tejido protegido. Si pierde alguno de los nodos de HGS (o todos ellos), es posible que se enfrente a problemas de disponibilidad inmediata que impedirán que los usuarios pongan en marcha sus máquinas virtuales blindadas. En un escenario en el que pierda todo el clúster de HGS, deberá tener copias de seguridad completas de la configuración de HGS a mano para restaurar el clúster de HGS y reanudar las operaciones normales. En esta sección se describen los pasos necesarios para prepararse para este escenario.

En primer lugar, es importante comprender de qué aspectos de HGS es importante tener copias de seguridad. HGS conserva varios fragmentos de información que le ayudan a determinar qué hosts están autorizados a ejecutar máquinas virtuales blindadas. Esto incluye:

1. Identificadores de seguridad de Active Directory para los grupos que contienen hosts de confianza (cuando se usa la atestación de Active Directory).
2. Identificadores únicos de TPM para cada host de su entorno.
3. Directivas de TPM para cada configuración única del host.
4. Directivas de integridad de código que determinan qué software se puede ejecutar en los hosts.

Para conseguir estos artefactos de atestación es necesario coordinarse con los administradores de su tejido de hospedaje, lo que puede dificultar la obtención de esta información de nuevo tras un desastre.

Además, HGS requiere acceso a 2 o más certificados usados para cifrar y firmar la información necesaria para poner en marcha una máquina virtual blindada (el protector de clave). Estos certificados son conocidos (los usan los propietarios de las máquinas virtuales blindadas para autorizar al tejido a ejecutar sus máquinas virtuales) y deben restaurarse después de un desastre para disfrutar de una experiencia de recuperación fluida. Si no restaura HGS con los mismos certificados después de un desastre, cada máquina virtual tendría que actualizarse para autorizar a las nuevas claves a descifrar su información. Por motivos de seguridad, únicamente el propietario de la máquina virtual puede actualizar la configuración de esta para autorizar estas nuevas claves; esto implica que, si no se restauran las claves después de un desastre, cada propietario debería tomar medidas para volver a ejecutar sus máquinas virtuales.

Preparación para lo peor

Para prepararse para una pérdida completa de HGS, debe seguir dos pasos:

1. Hacer una copia de seguridad de las directivas de atestación de HGS
2. Hacer una copia de seguridad de las claves de HGS

En la sección Copia de seguridad de HGS se proporcionan instrucciones sobre cómo llevar a cabo ambos pasos.

Además, se recomienda (aunque no es necesario) que realice una copia de seguridad de la lista de usuarios autorizados para administrar HGS en su dominio de Active Directory o en su propia instancia de Active Directory.

Las copias de seguridad se deben realizar periódicamente para garantizar que la información está actualizada y se almacena de forma segura para evitar alteraciones o robos.

No se recomienda realizar copias de seguridad ni intentar restaurar una imagen completa del sistema de un nodo de HGS. En caso de que haya perdido todo el clúster, el procedimiento recomendado es configurar un nuevo nodo de HGS y restaurar solo el estado de HGS, no todo el sistema operativo del servidor.

Recuperación de la pérdida de un nodo

Si pierde uno o varios nodos (pero no todos ellos) del clúster de HGS, basta con que agregue nodos al clúster siguiendo las instrucciones de la guía de implementación. Las directivas de atestación se sincronizarán automáticamente, al igual que los certificados que se proporcionaron a HGS como archivos PFX con contraseñas complementarias. En el caso de los certificados agregados a HGS mediante una huella digital (certificados respaldados por hardware y no exportables, normalmente), deberá asegurarse de que cada nodo nuevo tenga acceso a la clave privada de cada certificado.

Recuperación de la pérdida de todo el clúster

Si deja de funcionar todo el clúster de HGS y no puede volver a conectarlo, tendrá que restaurar HGS desde una copia de seguridad. La restauración de HGS a partir de una copia de seguridad implica configurar primero un nuevo clúster de HGS según las instrucciones de la guía de implementación. Se recomienda encarecidamente, aunque no es necesario, usar el mismo nombre de clúster al configurar el entorno de HGS de recuperación para ayudar con la resolución de nombres de los hosts. El uso del mismo nombre evita tener que volver a configurar hosts con nuevas direcciones URL de atestación y protección de claves. Si restauró objetos en el dominio de Active Directory que respalda HGS, se recomienda quitar los objetos que representan el clúster de HGS, los equipos, la cuenta de servicio y los grupos de JEA antes de inicializar el servidor de HGS.

Una vez que haya configurado el primer nodo de HGS (es decir, que se haya instalado e inicializado), deberá seguir los procedimientos descritos en Restauración de HGS a partir de una copia de seguridad para restaurar las directivas de atestación y las mitades públicas de los certificados de protección de claves. Deberá restaurar las claves privadas de los certificados manualmente según las instrucciones del proveedor de certificados (por ejemplo, mediante la importación del certificado en Windows o la configuración del acceso a los certificados respaldados por HSM). Una vez configurado el primer nodo, puede seguir instalando nodos adicionales en el clúster hasta que haya alcanzado la capacidad y resistencia que desee.

Copia de seguridad de HGS

El administrador de HGS debe ser responsable de realizar copias de seguridad de HGS de forma periódica. Una copia de seguridad completa contendrá material de clave confidencial que se debe proteger adecuadamente. Si una entidad que no es de confianza obtiene acceso a estas claves, podría usar ese material para configurar un entorno de HGS malintencionado con el fin de poner en riesgo las máquinas virtuales blindadas.

Copia de seguridad de las directivas de atestación Para realizar una copia de seguridad de las directivas de atestación de HGS, ejecute el siguiente comando en cualquier nodo de servidor de HGS en funcionamiento. Se le solicitará que proporcione una contraseña. Esta contraseña se usa para cifrar los certificados agregados a HGS mediante un archivo PFX (en lugar de una huella digital de certificado).

Export-HgsServerState -Path C:\temp\HGSBackup.xml

Nota

Si usa la atestación de confianza de administrador, debe realizar copias de seguridad por separado de la pertenencia a los grupos de seguridad usados por HGS para autorizar a los hosts protegidos. HGS solo realizará una copia de seguridad del SID de los grupos de seguridad, no de la pertenencia a ellos. En caso de que estos grupos se pierdan durante un desastre, deberá volver a crearlos y agregarles cada host protegido de nuevo.

Copia de seguridad de certificados

El comando Export-HgsServerState realizará una copia de seguridad de los certificados basados en PFX agregados a HGS en el momento en que se ejecute el comando. Si ha agregado certificados a HGS mediante una huella digital (típico de los certificados no exportables y con copia de seguridad de hardware), deberá realizar manualmente una copia de seguridad de las claves privadas de los certificados. Para identificar qué certificados están registrados con HGS y requieren que su copia de seguridad sea manual, ejecute el siguiente comando de PowerShell en cualquier nodo de servidor de HGS en funcionamiento.

Get-HgsKeyProtectionCertificate | Where-Object { $_.CertificateData.GetType().Name -eq 'CertificateReference' } | Format-Table Thumbprint, @{ Label = 'Subject'; Expression = { $_.CertificateData.Certificate.Subject } }

Para cada uno de los certificados de la lista, deberá realizar manualmente una copia de seguridad de la clave privada. Si usa un certificado basado en software que no es exportable, debe ponerse en contacto con la entidad de certificación para asegurarse de que tienen una copia de seguridad del certificado o pueden volver a emitirlo si se le solicita. En el caso de los certificados creados y almacenados en módulos de seguridad de hardware, debe consultar la documentación del dispositivo para obtener instrucciones sobre el planeamiento de la recuperación ante desastres.

Debe almacenar las copias de seguridad del certificado junto con las copias de seguridad de la directiva de atestación en una ubicación segura para que ambos elementos se puedan restaurar juntos.

Configuración adicional para realizar copias de seguridad

El estado del servidor de HGS de quien se ha hecho la copia de seguridad no incluirá el nombre del clúster de HGS, ninguna información de Active Directory ni ningún certificado SSL usado para proteger las comunicaciones con las API de HGS. Esta configuración es importante para la coherencia, pero no es fundamental para volver a conectar el clúster de HGS después de un desastre.

Para capturar el nombre del servicio de HGS, ejecute Get-HgsServer y anote el nombre sin formato en las direcciones URL de atestación y protección de claves. Por ejemplo, si la dirección URL de atestación es "https://hgs.contoso.com/Attestation", "hgs" es el nombre del servicio de HGS.

El dominio de Active Directory que usa HGS debe administrarse como cualquier otro dominio de Active Directory. Al restaurar HGS después de un desastre, no tendrá que volver a crear necesariamente los objetos exactos que están presentes en el dominio actual. Sin embargo, la recuperación será más fácil si realiza una copia de seguridad de Active Directory y conserva una lista de los usuarios de JEA autorizados para administrar el sistema, así como la pertenencia a los grupos de seguridad usados por la atestación de confianza de administrador para autorizar los hosts protegidos.

Para identificar la huella digital de los certificados SSL configurados para HGS, ejecute el siguiente comando en PowerShell. A continuación, puede realizar una copia de seguridad de esos certificados SSL según las instrucciones del proveedor de certificados.

Get-WebBinding -Protocol https | Select-Object certificateHash

Restauración de HGS a partir de una copia de seguridad

En los pasos siguientes se describe cómo restaurar la configuración de HGS desde una copia de seguridad. Los pasos son pertinentes tanto para situaciones en las que intenta deshacer los cambios realizados en las instancias de HGS que ya se están ejecutando como cuando se está creando un clúster de HGS nuevo tras la pérdida total del anterior.

Configuración de un clúster de HGS de reemplazo

Para poder restaurar HGS, debe tener un clúster de HGS inicializado en el que pueda restaurar la configuración. Si simplemente va a importar la configuración que se eliminó accidentalmente en un clúster existente (en ejecución), puede omitir este paso. Si se está recuperando de una pérdida completa de HGS, deberá instalar e inicializar al menos un nodo de HGS siguiendo las instrucciones de la guía de implementación.

En concreto, tendrá que:

1. Configure el dominio de HGS o una HGS a un dominio existente.
2. Inicialice el servidor de HGS mediante las claves existentes o un conjunto de claves temporales. Puede quitar las claves temporales después de importar las claves reales de los archivos de copia de seguridad de HGS.
3. Importe la configuración de HGS desde la copia de seguridad para restaurar los grupos host de confianza, las directivas de integridad de código, las bases de referencia de TPM y los identificadores de TPM.

Sugerencia

No es necesario que el nuevo clúster HGS utilice los mismos certificados, nombre de servicio o dominio que la instancia de HGS desde la que se exportó el archivo de copia de seguridad.

Importación de la configuración desde una copia de seguridad

Para restaurar las directivas de atestación, los certificados basados en PFX y las claves públicas de certificados que no son de PFX en el nodo de HGS desde un archivo de copia de seguridad, ejecute el siguiente comando en un nodo de servidor de HGS inicializado. Se le pedirá que escriba la contraseña que especificó al crear la copia de seguridad.

Import-HgsServerState -Path C:\Temp\HGSBackup.xml

Si solo desea importar directivas de atestación de confianza de administrador o directivas de atestación de confianza de TPM, puede hacerlo especificando las marcas -ImportActiveDirectoryModeState o -ImportTpmModeState en Import-HgsServerState.

Asegúrese de que esté instalada la actualización acumulativa más reciente de Windows Server 2016 antes de ejecutar Import-HgsServerState. De lo contrario, puede producirse un error de importación.

Nota

Si restaura directivas en un nodo de HGS existente que ya tiene una o varias de esas directivas instaladas, el comando import mostrará un error para cada directiva duplicada. Este es un comportamiento esperado y se puede omitir de forma segura en la mayoría de los casos.

Reinstalación de claves privadas para certificados

Si alguno de los certificados usados en la instancia de HGS desde la que se creó la copia de seguridad se agregó mediante huellas digitales, solo se incluirá la clave pública de esos certificados en el archivo de copia de seguridad. Esto significa que tendrá que instalar manualmente las claves privadas para cada uno de esos certificados (o conceder acceso a ellas) para que HGS pueda atender las solicitudes de hosts de Hyper-V. Las acciones necesarias para completar ese paso varían en función de cómo se emitiera originalmente el certificado. En el caso de los certificados respaldados por software emitidos por una entidad de certificación, deberá ponerse en contacto con esa entidad de certificación para obtener la clave privada e instalarla en cada nodo de HGS según sus instrucciones. Del mismo modo, si los certificados están respaldados por hardware, deberá consultar la documentación del proveedor del módulo de seguridad de hardware para instalar los controladores necesarios en cada nodo de HGS para conectarse a HSM y conceder a cada máquina acceso a la clave privada.

Cabe recordar que los certificados agregados a HGS mediante huellas digitales requieren la replicación manual de las claves privadas en cada nodo. Deberá repetir este paso en cada nodo adicional que agregue al clúster de HGS restaurado.

Revisión de las directivas de atestación importadas

Después de importar la configuración desde una copia de seguridad, se recomienda revisar detenidamente todas las directivas importadas que usan Get-HgsAttestationPolicy para asegurarse de que solo los hosts en los que confía para ejecutar máquinas virtuales blindadas podrán completar correctamente la atestación. Si encuentra alguna directiva que ya no coincide con su posición de seguridad, puede deshabilitarla o quitarla.

Ejecución de diagnósticos para comprobar el estado del sistema

Una vez que haya terminado de configurar y restaurar el estado del nodo de HGS, debe ejecutar la herramienta de diagnóstico de HGS para comprobar el estado del sistema. Para ello, ejecute el siguiente comando en el nodo de HGS donde restauró la configuración:

Get-HgsTrace -RunDiagnostics

Si el "Resultado general" no es "Correcto", se requieren pasos adicionales para terminar de configurar el sistema. Compruebe los mensajes notificados en las subpruebas que han producido un error para obtener más información.

Aplicación de revisiones a HGS

Es importante mantener actualizados los nodos del Servicio de protección de host mediante la instalación de la actualización acumulativa más reciente cuando salga. Si va a configurar un nuevo nodo de HGS, se recomienda encarecidamente instalar las actualizaciones disponibles antes de instalar el rol de HGS o configurarlo. Esto garantizará que las funcionalidades nuevas o modificadas surtan efecto inmediatamente.

Al aplicar revisiones al tejido protegido, se recomienda encarecidamente actualizar primero todos los hosts de Hyper-V antes de actualizar HGS. Esto es para asegurarse de que los cambios realizados en las directivas de atestación en HGS se apliquen después de actualizar los hosts de Hyper-V para proporcionar la información que necesitan. Si una actualización va a cambiar el comportamiento de las directivas, no se habilitará automáticamente para evitar la interrupción del tejido. Estas actualizaciones requieren que siga las instrucciones de la sección siguiente para activar las directivas de atestación nuevas o modificadas. Le recomendamos que lea las notas de la versión de Windows Server y las actualizaciones acumulativas que instale para comprobar si se requieren las actualizaciones de directiva.

Actualizaciones que requieren la activación de directivas

Si una actualización de HGS introduce un nuevo comportamiento en una directiva de atestación o lo cambia significativamente, se requiere un paso adicional para activar la directiva modificada. Los cambios en la directiva solo se aplican después de exportar e importar el estado de HGS. Solo debe activar las directivas nuevas o modificadas después de haber aplicado la actualización acumulativa a todos los hosts y a todos los nodos de HGS del entorno. Una vez que se haya actualizado cada máquina, ejecute los siguientes comandos en cualquier nodo de HGS para desencadenar el proceso de actualización:

$password = Read-Host -AsSecureString -Prompt "Enter a temporary password"
Export-HgsServerState -Path .\temporaryExport.xml -Password $password
Import-HgsServerState -Path .\temporaryExport.xml -Password $password

Si se introdujo una nueva directiva, se deshabilitará de forma predeterminada. Para activar la nueva directiva, primero búsquela en la lista de directivas de Microsoft (con el prefijo "HGS_") y, a continuación, actívela mediante los siguientes comandos:

Get-HgsAttestationPolicy

Enable-HgsAttestationPolicy -Name <Hgs_NewPolicyName>

Administración de directivas de atestación

HGS mantiene varias directivas de atestación que definen el conjunto mínimo de requisitos que un host debe cumplir para considerarse "correcto" y permitir la ejecución de máquinas virtuales blindadas. Microsoft define algunas de estas directivas; otras las agrega usted para definir las directivas de integridad de código permitidas, las bases de referencia de TPM y los hosts del entorno. Es necesario el mantenimiento regular de estas directivas para garantizar que los hosts pueden seguir con las actividades de atestación correctamente a medida que los actualiza y los reemplaza, y para asegurarse de que los hosts o configuraciones que no son de confianza no puedan realizar dichas actividades correctamente.

Para la atestación de confianza de administrador, solo hay una directiva que determina si un host es correcto: la pertenencia a un grupo de seguridad de confianza conocido. La atestación de TPM es más complicada e implica varias directivas para medir el código y la configuración de un sistema antes de determinar si es correcto.

Una sola instancia de HGS se puede configurar con directivas de Active Directory y TPM a la vez, pero el servicio solo comprobará las directivas para el modo actual para el que está configurado cuando un host intenta realizar la atestación. Para comprobar el modo del servidor de HGS, ejecute Get-HgsServer.

Directivas predeterminadas

Para la atestación de confianza de TPM, hay varias directivas integradas configuradas en HGS. Algunas de estas directivas están "bloqueadas", lo que significa que no se pueden deshabilitar por motivos de seguridad. En la tabla siguiente se explica el propósito de cada directiva predeterminada.

Nombre de la directiva	Propósito
Hgs_SecureBootEnabled	Requiere que los hosts tengan habilitado el arranque seguro. Esto es necesario para medir los archivos binarios de inicio y otras configuraciones bloqueadas por UEFI.
Hgs_UefiDebugDisabled	Garantiza que los hosts no tienen habilitado un depurador de kernel. Los depuradores en modo de usuario se bloquean con directivas de integridad de código.
Hgs_SecureBootSettings	Directiva negativa para garantizar que los hosts coincidan con al menos una base de referencia de TPM (definida por el administrador).
Hgs_CiPolicy	Directiva negativa para asegurarse de que los hosts usan una de las directivas de CI definidas por el administrador.
Hgs_HypervisorEnforcedCiPolicy	Requiere que el hipervisor aplique la directiva de integridad de código. Al deshabilitar esta directiva, se debilitan las protecciones frente a ataques de directiva de integridad de código en modo kernel.
Hgs_FullBoot	Garantiza que el host no se reanudó tras la suspensión o hibernación. Los hosts deben reiniciarse o apagarse correctamente para pasar esta directiva.
Hgs_VsmIdkPresent	Requiere que la seguridad basada en la virtualización se ejecute en el host. El IDK representa la clave necesaria para cifrar la información enviada de vuelta al espacio de memoria seguro del host.
Hgs_PageFileEncryptionEnabled	Requiere que los archivos de página se cifren en el host. Deshabilitar esta directiva podría dar lugar a la exposición de la información si se inspecciona un archivo de página sin cifrar para los secretos de inquilino.
Hgs_BitLockerEnabled	Requiere que BitLocker esté habilitado en el host de Hyper-V. Esta directiva está deshabilitada de forma predeterminada por motivos de rendimiento y no se recomienda habilitarla. Esta directiva no afecta al cifrado de las propias máquinas virtuales blindadas.
Hgs_IommuEnabled	Requiere que el host tenga un dispositivo IOMMU en uso para evitar ataques de acceso directo a la memoria. La deshabilitación de esta directiva y el uso de hosts sin IOMMU habilitado puede exponer los secretos de la máquina virtual del inquilino a ataques directos de memoria.
Hgs_NoHibernation	Requiere que se deshabilite la hibernación en el host de Hyper-V. Deshabilitar esta directiva podría permitir que los hosts guarden la memoria de la máquina virtual blindada en un archivo de hibernación sin cifrar.
Hgs_NoDumps	Requiere que los volcados de memoria se deshabiliten en el host de Hyper-V. Si deshabilita esta directiva, se recomienda configurar el cifrado de volcado de memoria para evitar que la memoria de máquina virtual blindada se guarde en archivos de volcado de memoria sin cifrar.
Hgs_DumpEncryption	Requiere que los volcados de memoria, si están habilitados en el host de Hyper-V, se cifren con una clave de cifrado de confianza para HGS. Esta directiva no se aplica si los volcados no están habilitados en el host. Si esta directiva y Hgs_NoDumps están deshabilitadas, la memoria de la máquina virtual blindada se podría guardar en un archivo de volcado sin cifrar.
Hgs_DumpEncryptionKey	Directiva negativa para asegurarse de que los hosts configurados para permitir volcados de memoria usan una clave de cifrado de archivos de volcado definida por el administrador conocida para HGS. Esta directiva no se aplica cuando se deshabilita Hgs_DumpEncryption.

Autorización de nuevos hosts protegidos

Para autorizar a un nuevo host a convertirse en un host protegido (para, por ejemplo, realizar atestaciones correctamente), HGS debe confiar en el host y (cuando esté configurado para usar la atestación de confianza de TPM) en el software que se ejecuta en él. Los pasos para autorizar un nuevo host difieren en función del modo de atestación para el que está configurado actualmente HGS. Para comprobar el modo de atestación del tejido protegido, ejecute Get-HgsServer en cualquier nodo de HGS.

Configuración del software

En el nuevo host de Hyper-V, asegúrese de que esté instalado Windows Server 2016 Datacenter Edition. Windows Server 2016 Standard no puede ejecutar máquinas virtuales blindadas en un tejido protegido. El host se puede instalar en Experiencia de escritorio o Server Core.

En el servidor con Experiencia de escritorio y Server Core, debe instalar los roles de servidor de Hyper-V y compatibilidad de Hyper-V con protección de host:

Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart

Atestación de confianza del administrador

Para registrar un nuevo host en HGS al usar la atestación de confianza de administrador, primero debe agregar el host a un grupo de seguridad en el dominio al que está unido. Normalmente, cada dominio tendrá un grupo de seguridad para hosts protegidos. Si ya ha registrado ese grupo con HGS, la única acción que debe realizar es reiniciar el host para actualizar su pertenencia a grupos.

Puede comprobar qué grupos de seguridad son de confianza para HGS mediante la ejecución del siguiente comando:

Get-HgsAttestationHostGroup

Para registrar un nuevo grupo de seguridad con HGS, primero capture el identificador de seguridad (SID) del grupo en el dominio del host y registre el SID con HGS.

Add-HgsAttestationHostGroup -Name "Contoso Guarded Hosts" -Identifier "S-1-5-21-3623811015-3361044348-30300820-1013"

En la guía de implementación encontrará instrucciones sobre cómo configurar la confianza entre el dominio de host y HGS.

Atestación de confianza de TPM

Cuando HGS está configurado en modo TPM, los hosts deben pasar todas las directivas bloqueadas y las directivas "habilitadas" con el prefijo "Hgs_", así como al menos una base de referencia de TPM, un identificador de TPM y una directiva de integridad de código. Cada vez que agregue un nuevo host, deberá registrar el nuevo identificador de TPM con HGS. Siempre que el host ejecute el mismo software (y tenga aplicada la misma directiva de integridad de código) y la base de referencia de TPM que otro host del entorno, no tendrá que agregar nuevas directivas ni bases de referencia de CI.

Adición del identificador de TPM para un nuevo host En el nuevo host, ejecute el siguiente comando para capturar el identificador de TPM. Asegúrese de especificar un nombre único para el host que le ayudará a buscarlo en HGS. Necesitará esta información si retira el host o quiere impedir que ejecute máquinas virtuales blindadas en HGS.

(Get-PlatformIdentifier -Name "Host01").InnerXml | Out-File C:\temp\host01.xml -Encoding UTF8

Copie este archivo en el servidor de HGS y ejecute el siguiente comando para registrar el host con HGS.

Add-HgsAttestationTpmHost -Name 'Host01' -Path C:\temp\host01.xml

Adición de una nueva base de referencia de TPM Si el nuevo host ejecuta una nueva configuración de hardware o firmware para su entorno, es posible que tenga que tomar una nueva base de referencia de TPM. Para ello, ejecute el siguiente comando en el host.

Get-HgsAttestationBaselinePolicy -Path 'C:\temp\hardwareConfig01.tcglog'

Nota

Si recibe un error que indica que el host ha producido un error en la validación y la atestación no se ha realizado correctamente, no se preocupe. Se trata de una comprobación previa para asegurarse de que el host puede ejecutar máquinas virtuales blindadas y, probablemente, significa que aún no ha aplicado una directiva de integridad de código u otra configuración necesaria. Lea el mensaje de error, realice los cambios que sugiere y vuelva a intentarlo. Como alternativa, puede omitir la validación en este momento agregando la marca -SkipValidation al comando.

Copie la base de referencia de TPM en el servidor de HGS y, a continuación, regístrela con el siguiente comando. Le recomendamos que use una convención de nomenclatura que le ayude a comprender la configuración de hardware y firmware de esta clase de host de Hyper-V.

Add-HgsAttestationTpmPolicy -Name 'HardwareConfig01' -Path 'C:\temp\hardwareConfig01.tcglog'

Adición de una nueva directiva de integridad de código Si ha cambiado la directiva de integridad de código que se ejecuta en los hosts de Hyper-V, deberá registrar la nueva directiva con HGS para que esos hosts puedan realizar correctamente la atestación. En un host de referencia, que actúa como imagen maestra para las máquinas de Hyper-V de confianza de su entorno, capture una nueva directiva de CI mediante el comando New-CIPolicy. Le recomendamos que use el nivel FilePublisher y la reserva hash para las directivas de CI de host de Hyper-V. En primer lugar, debe crear una directiva de CI en modo de auditoría para asegurarse de que todo funciona según lo previsto. Después de validar una carga de trabajo de ejemplo en el sistema, puede aplicar la directiva y copiar la versión aplicada en HGS. Para obtener una lista completa de las opciones de configuración de la directiva de integridad de código, consulte la documentación de Device Guard.

# Capture a new CI policy with the FilePublisher primary level and Hash fallback and enable user mode code integrity protections
New-CIPolicy -FilePath 'C:\temp\ws2016-hardware01-ci.xml' -Level FilePublisher -Fallback Hash -UserPEs

# Apply the CI policy to the system
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\ws2016-hardware01-ci.xml' -BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b' 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer

# Check the event log for any untrusted binaries and update the policy if necessary
# Consult the Device Guard documentation for more details

# Change the policy to be in enforced mode
Set-RuleOption -FilePath 'C:\temp\ws2016-hardare01-ci.xml' -Option 3 -Delete

# Apply the enforced CI policy on the system
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\ws2016-hardware01-ci.xml' -BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b' 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer

Una vez creada, probada y aplicada la directiva, copie el archivo binario (.p7b) en el servidor de HGS y registre la directiva.

Add-HgsAttestationCiPolicy -Name 'WS2016-Hardware01' -Path 'C:\temp\ws2016-hardware01-ci.p7b'

Adición de una clave de cifrado de volcado de memoria

Cuando la directiva Hgs_NoDumps está deshabilitada y la directiva Hgs_DumpEncryption está habilitada, se permite que los hosts protegidos tengan habilitados los volcados de memoria siempre que dichos volcados estén cifrados. Los hosts protegidos solo pasarán la atestación si tienen los volcados de memoria deshabilitados o los cifran con una clave conocida para HGS. De forma predeterminada, no hay ninguna clave de cifrado de volcado configurada en HGS.

Para agregar una clave de cifrado de volcado a HGS, use el cmdlet Add-HgsAttestationDumpPolicy para proporcionar a HGS el hash de la clave de cifrado de volcado. Si captura una base de referencia de TPM en un host de Hyper-V configurado con cifrado de volcado, el hash se incluye en el tcglog y se puede proporcionar al cmdlet Add-HgsAttestationDumpPolicy.

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey01' -Path 'C:\temp\TpmBaselineWithDumpEncryptionKey.tcglog'

Como alternativa, puede proporcionar directamente la representación de cadena del hash al cmdlet.

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey02' -PublicKeyHash '<paste your hash here>'

Asegúrese de agregar cada clave de cifrado de volcado única a HGS si decide usar claves diferentes en el tejido protegido. Los hosts que cifran volcados de memoria con una clave no conocida por HGS no pasarán la atestación.

Consulte la documentación de Hyper-V para obtener más información sobre cómo configurar el cifrado de volcado de memoria en hosts.

Comprobación de si el sistema pasó la atestación

Después de registrar la información necesaria en HGS, debe comprobar si el host pasa la atestación. En el host de Hyper-V recién agregado, ejecute Set-HgsClientConfiguration y proporcione las direcciones URL correctas para el clúster de HGS. Estas direcciones URL se pueden obtener mediante la ejecución de Get-HgsServer en cualquier nodo de HGS.

Set-HgsClientConfiguration -KeyProtectionServerUrl 'https://hgs.bastion.local/KeyProtection' -AttestationServerUrl 'https://hgs.bastion.local/Attestation'

Si el estado resultante no indica "IsHostGuarded : True", deberá solucionar los problemas de configuración. En el host que no pudo completar la atestación, ejecute el siguiente comando para obtener un informe detallado sobre los problemas que pueden ayudarle a resolver el error en la atestación.

Get-HgsTrace -RunDiagnostics -Detailed

Importante

Si usa Windows Server 2019 o Windows 10, versión 1809, y usa directivas de integridad de código, Get-HgsTrace puede devolver un error para el diagnóstico activo de la directiva de integridad de código. Puede omitir este resultado de forma segura cuando sea el único diagnóstico con errores.

Revisión de las directivas de atestación

Para revisar el estado actual de las directivas configuradas en HGS, ejecute los siguientes comandos en cualquier nodo de HGS:

# List all trusted security groups for admin-trusted attestation
Get-HgsAttestationHostGroup

# List all policies configured for TPM-trusted attestation
Get-HgsAttestationPolicy

Si encuentra una directiva habilitada que ya no cumple sus requisitos de seguridad (por ejemplo, una directiva de integridad de código antigua que ahora se considera no segura), puede deshabilitarla reemplazando el nombre de la directiva en el siguiente comando:

Disable-HgsAttestationPolicy -Name 'PolicyName'

Del mismo modo, puede usar Enable-HgsAttestationPolicy para volver a habilitar una directiva.

Si ya no necesita una directiva y desea quitarla de todos los nodos de HGS, ejecute Remove-HgsAttestationPolicy -Name 'PolicyName' para eliminar permanentemente la directiva.

Cambio de los modos de atestación

Si ha iniciado el tejido protegido mediante la atestación de confianza de administrador, es probable que quiera actualizar al modo de atestación de TPM, mucho más seguro, en cuanto tenga suficientes hosts compatibles con TPM 2.0 en su entorno. Cuando esté listo para cambiar, puede precargar todos los artefactos de atestación (directivas de CI, bases de referencia de TPM e identificadores de TPM) en HGS mientras continúa ejecutando HGS con atestación de confianza de administrador. Para ello, simplemente siga las instrucciones de la sección Autorización de nuevos hosts protegidos.

Una vez que haya agregado todas las directivas a HGS, el siguiente paso consiste en ejecutar un intento de atestación sintética en los hosts para ver si pasarían la atestación en modo TPM. Esto no afecta al estado operativo actual de HGS. Los comandos siguientes deben ejecutarse en un equipo que tenga acceso a todos los hosts del entorno y al menos a un nodo de HGS. Si el firewall u otras directivas de seguridad lo impiden, puede omitir este paso. Cuando sea posible, se recomienda ejecutar la atestación sintética para conseguir una buena pista sobre si el cambio al modo de TPM provocará tiempo de inactividad para las máquinas virtuales.

# Get information for each host in your environment
$hostNames = 'host01.contoso.com', 'host02.contoso.com', 'host03.contoso.com'
$credential = Get-Credential -Message 'Enter a credential with admin privileges on each host'
$targets = @()
$hostNames | ForEach-Object { $targets += New-HgsTraceTarget -Credential $credential -Role GuardedHost -HostName $_ }

$hgsCredential = Get-Credential -Message 'Enter an admin credential for HGS'
$targets += New-HgsTraceTarget -Credential $hgsCredential -Role HostGuardianService -HostName 'HGS01.bastion.local'

# Initiate the synthetic attestation attempt
Get-HgsTrace -RunDiagnostics -Target $targets -Diagnostic GuardedFabricTpmMode

Una vez completados los diagnósticos, revise la información de salida para determinar si algún host habría producido un error en la atestación en modo TPM. Vuelva a ejecutar los diagnósticos hasta que obtenga un resultado "correcto" para cada host y, a continuación, continúe con el cambio de HGS al modo de TPM.

El cambio al modo TPM tarda solo un segundo en completarse. Ejecute el siguiente comando en cualquier nodo de HGS para actualizar el modo de atestación.

Set-HgsServer -TrustTpm

Si tiene problemas y necesita volver al modo de Active Directory, puede hacerlo ejecutando Set-HgsServer -TrustActiveDirectory.

Una vez que haya confirmado que todo funciona según lo previsto, debe quitar todos los grupos de hosts de Active Directory de confianza de HGS y quitar la confianza entre los dominios de tejido y HGS. Si deja la confianza de Active Directory vigente, corre el riesgo de que alguien vuelva a habilitar la confianza y cambie HGS al modo de Active Directory, lo que podría permitir que el código que no es de confianza se ejecute sin comprobarse en los hosts protegidos.

Administración de claves

La solución de tejido protegido usa varios pares de claves públicas y privadas para validar la integridad de varios componentes de la solución y cifrar los secretos de inquilino. El Servicio de protección de host se configura con al menos dos certificados (con claves públicas y privadas), que se usan para firmar y cifrar las claves empleadas para poner en marcha máquinas virtuales blindadas. Esas claves deben administrarse cuidadosamente. Si un adversario adquiere la clave privada, podrá desproteger cualquier máquina virtual que se ejecute en su tejido o crear un clúster de HGS impostor que utilice políticas de atestación más débiles para eludir las protecciones establecidas. Si pierde las claves privadas durante un desastre y no las encuentra en una copia de seguridad, deberá configurar un nuevo par de claves y volver a implantar las claves en cada máquina virtual para autorizar los nuevos certificados.

En esta sección se tratan temas generales de administración de claves que le ayudarán a configurar las claves para que sean funcionales y seguras.

Adición de nuevas claves

Aunque HGS debe inicializarse con un conjunto de claves, puede agregar más de una clave de cifrado y firma a HGS. Las dos razones más comunes para agregar nuevas claves a HGS son:

1. Para admitir escenarios de "traiga su propia clave", donde los inquilinos copian sus claves privadas en el módulo de seguridad de hardware y solo autorizan a sus claves a poner en marcha las máquinas virtuales blindadas.
2. Para reemplazar las claves existentes para HGS agregando primero las nuevas claves y conservando ambos conjuntos de claves hasta que se haya actualizado la configuración de cada máquina virtual para utilizar las nuevas claves.

El proceso para agregar las nuevas claves difiere en función del tipo de certificado que use.

Opción 1: Agregar un certificado almacenado en un HSM

Nuestro enfoque recomendado para proteger las claves de HGS es usar certificados creados en un módulo de seguridad de hardware (HSM). Los HSM garantizan que el uso de las claves esté vinculado al acceso físico a un dispositivo delicado desde el punto de vista de la seguridad en el centro de datos. Cada HSM es diferente y tiene un proceso único para crear certificados y registrarlos con HGS. Los pasos siguientes están diseñados para proporcionar instrucciones generales para usar certificados respaldados por HSM. Consulte la documentación del proveedor de HSM para conocer los pasos y funcionalidades exactos.

1. Instale el software de HSM en cada nodo de HGS del clúster. En función de si tiene una red o un dispositivo HSM local, es posible que tenga que configurar HSM para conceder a la máquina acceso a su almacén de claves.

2. Cree dos certificados en el HSM con claves RSA de 2048 bits para cifrado y firma.

   1. Cree un certificado de cifrado con la propiedad de uso de clave Data Encipherment en su HSM.
   2. Cree un certificado de firma con la propiedad de uso de clave Digital Signature en su HSM.

3. Instale los certificados en el almacén de certificados local de cada nodo de HGS según las instrucciones del proveedor de HSM.

4. Si el HSM usa permisos detallados para conceder permisos específicos a aplicaciones o usuarios para usar la clave privada, deberá conceder a la cuenta de servicio administrada del grupo de HGS acceso al certificado. Para encontrar el nombre de la cuenta gMSA de HGS, ejecute (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName.

5. Agregue los certificados de firma y cifrado a HGS reemplazando las huellas digitales por las de los certificados en los siguientes comandos:

   Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"
   Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint "99887766554433221100FFEEDDCCBBAA"
   

Opción 2: Agregar certificados de software no exportables

Si tiene un certificado respaldado por software emitido por la empresa o una entidad de certificación pública que tenga una clave privada no exportable, deberá agregar el certificado a HGS mediante su huella digital.

1. Instale el certificado en la máquina según las instrucciones de la entidad de certificación.

2. Conceda a la cuenta de servicio administrada de grupo de HGS acceso de lectura a la clave privada del certificado. Para encontrar el nombre de la cuenta gMSA de HGS, ejecute (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName.

3. Registre el certificado con HGS mediante el siguiente comando y sustituya la huella digital del certificado (cambie Cifrado a Firma para certificados de firma):

   Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"
   

Importante

Deberá instalar manualmente la clave privada y conceder acceso de lectura a la cuenta de gMSA en cada nodo de HGS. HGS no puede replicar automáticamente las claves privadas para ningún certificado registrado por su huella digital.

Opción 3: Agregar certificados almacenados en archivos PFX

Si tiene un certificado respaldado por software con una clave privada exportable que se puede almacenar en el formato de archivo PFX y proteger con una contraseña, HGS puede administrar automáticamente los certificados. Los certificados agregados con archivos PFX se replican automáticamente en cada nodo del clúster de HGS y HGS protege el acceso a las claves privadas. Para agregar un nuevo certificado mediante un archivo PFX, ejecute los siguientes comandos en cualquier nodo de HGS (cambie Cifrado a Firma para certificados de firma):

$certPassword = Read-Host -AsSecureString -Prompt "Provide the PFX file password"
Add-HgsKeyProtectionCertificate -CertificateType Encryption -CertificatePath "C:\temp\encryptionCert.pfx" -CertificatePassword $certPassword

Identificación y cambio de los certificados principales Aunque HGS puede admitir varios certificados de firma y cifrado, usa un par como sus certificados "principales". Estos son los certificados que se usarán si alguien descarga los metadatos de protección de ese clúster de HGS. Para comprobar qué certificados están marcados actualmente como certificados principales, ejecute el siguiente comando:

Get-HgsKeyProtectionCertificate -IsPrimary $true

Para establecer un nuevo certificado de firma o cifrado principal, busque la huella digital del certificado deseado y márquelo como principal mediante los siguientes comandos:

Get-HgsKeyProtectionCertificate
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899" -IsPrimary
Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint "99887766554433221100FFEEDDCCBBAA" -IsPrimary

Renovación o sustitución de claves

Al crear los certificados usados por HGS, a los certificados se les asignará una fecha de expiración según la directiva de la entidad de certificación y la información de la solicitud. Normalmente, en escenarios en los que la validez del certificado es importante, como la seguridad de las comunicaciones HTTP, los certificados deben renovarse antes de que expiren para evitar una interrupción del servicio o un mensaje de error preocupante. HGS no usa certificados en ese sentido. HGS simplemente usa certificados como una manera cómoda de crear y almacenar un par de claves asimétricas. Un certificado de firma o cifrado expirado en HGS no indica una debilidad o pérdida de protección para las máquinas virtuales protegidas. Además, HGS no realiza comprobaciones de revocación de certificados. Si se revoca un certificado de HGS o el certificado de la entidad emisora, el uso del certificado de HGS no se verá afectado.

El único caso en el que debe preocuparse por un certificado HGS es si tiene motivos para creer que le han robado la clave privada. En ese caso, la integridad de las máquinas virtuales blindadas está en riesgo porque la posesión de la mitad privada del par de claves de firma y cifrado de HGS es suficiente para quitar las protecciones de blindaje en una máquina virtual o para crear un servidor de HGS falso que tenga directivas de atestación más débiles.

Si se encuentra en esa situación o se ve obligado por las normas de cumplimiento a actualizar las claves de los certificados con regularidad, los siguientes pasos describen el proceso para cambiar las claves en un servidor de HGS. Tenga en cuenta que las siguientes instrucciones representan una empresa importante que provocará una interrupción del servicio en cada máquina virtual que atienda el clúster de HGS. Se requiere un planeamiento adecuado para cambiar las claves de HGS a fin de minimizar la interrupción del servicio y garantizar la seguridad de las máquinas virtuales del inquilino.

En un nodo de HGS, realice los pasos siguientes para registrar un nuevo par de certificados de cifrado y firma. Consulte la sección sobre cómo agregar nuevas claves para obtener información detallada sobre las distintas formas de agregar nuevas claves a HGS.

1. Cree un nuevo par de certificados de cifrado y firma para el servidor de HGS. Lo ideal es que se creen en un módulo de seguridad de hardware.

2. Registre los nuevos certificados de cifrado y firma con Add-HgsKeyProtectionCertificate.

   Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint>
   Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>
   

3. Si usó huellas digitales, deberá ir a cada nodo del clúster para instalar la clave privada y conceder acceso a la clave a gMSA de HGS.

4. Convierta los nuevos certificados en los certificados predeterminados en HGS.

   Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> -IsPrimary
   Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsPrimary
   

En este momento, los datos de blindaje creados con los metadatos obtenidos del nodo de HGS usarán los nuevos certificados, pero las máquinas virtuales existentes seguirán funcionando porque los certificados anteriores siguen ahí.

Para asegurarse de que todas las máquinas virtuales existentes funcionarán con las nuevas claves, deberá actualizar el protector de claves en cada máquina virtual.

Se trata de una acción que requiere la participación del propietario de la máquina virtual (persona o entidad en posesión del protector "propietario"). Para cada máquina virtual blindada, realice los pasos siguientes:

1. Apague la máquina virtual. La máquina virtual no se puede volver a activar hasta que se hayan completado los pasos restantes o, de lo contrario, tendrá que volver a iniciar el proceso.

2. Guarde el protector de clave actual en un archivo: Get-VMKeyProtector -VMName 'VM001' | Out-File '.\VM001.kp'

3. Transferencia de KP al propietario de la máquina virtual

4. Haga que el propietario descargue la información del protector actualizada de HGS y la importe en su sistema local.

5. Lea el KP actual en la memoria, conceda al nuevo protector acceso al KP y guárdelo en un nuevo archivo ejecutando los siguientes comandos:

   $kpraw = Get-Content -Path .\VM001.kp
   $kp = ConvertTo-HgsKeyProtector -Bytes $kpraw
   $newGuardian = Get-HgsGuardian -Name 'UpdatedHgsGuardian'
   $updatedKP = Grant-HgsKeyProtectorAccess -KeyProtector $kp -Guardian $newGuardian
   $updatedKP.RawData | Out-File .\updatedVM001.kp
   

6. Vuelva a copiar el KP actualizado en el tejido de hospedaje.

7. Aplique el KP a la máquina virtual original:

   $updatedKP = Get-Content -Path .\updatedVM001.kp
   Set-VMKeyProtector -VMName VM001 -KeyProtector $updatedKP
   

8. Por último, inicie la máquina virtual y asegúrese de que se ejecuta correctamente.

   Nota

   Si el propietario de la máquina virtual establece un protector de clave incorrecto en la máquina virtual y no autoriza al tejido a ejecutar la máquina virtual, no podrá iniciar la máquina virtual blindada. Para volver al último protector de clave correcto conocido, ejecute Set-VMKeyProtector -RestoreLastKnownGoodKeyProtector.

   Una vez actualizadas todas las máquinas virtuales para autorizar las nuevas claves del protector, puede deshabilitar y quitar las claves antiguas.

9. Obtenga las huellas digitales de los certificados antiguos de Get-HgsKeyProtectionCertificate -IsPrimary $false.

10. Deshabilite cada certificado ejecutando los siguientes comandos:

    Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> -IsEnabled $false
    Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsEnabled $false
    

11. Después de asegurarse de que las máquinas virtuales aún pueden iniciarse con los certificados desactivados, quite los certificados de HGS ejecutando los siguientes comandos:

    Remove-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint>`
    Remove-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>`
    

Importante

Las copias de seguridad de las máquinas virtuales contendrán la información antigua del protector de clave que permite usar los certificados antiguos para poner en marcha la máquina virtual. Si sabe que la clave privada se ha puesto en riesgo, debe suponer que las copias de seguridad de la máquina virtual también pueden estarlo y tomar las medidas oportunas. La destrucción de la configuración de la VM desde las copias de seguridad (.vmcx) quitará los protectores de claves, a costa de tener que utilizar la contraseña de recuperación de BitLocker para poner en marcha la VM la próxima vez.

Replicación de claves entre nodos

Todos los nodos del clúster de HGS deben configurarse con los mismos certificados SSL de cifrado y firma (cuando se configuran). Esto es necesario para garantizar que los hosts de Hyper-V que llegan a cualquier nodo del clúster puedan atender sus solicitudes correctamente.

Si inicializó el servidor de HGS con certificados basados en PFX, HGS replicará automáticamente la clave pública y privada de esos certificados en todos los nodos del clúster. Solo tiene que agregar las claves en un nodo.

Si inicializó el servidor de HGS con referencias de certificado o huellas digitales, HGS solo replicará la clave pública en el certificado en cada nodo. Además, HGS no puede conceder acceso a la clave privada en ningún nodo de este escenario. Por lo tanto, es su responsabilidad:

1. Instalar la clave privada en cada nodo de HGS.
2. Conceder a la cuenta de servicio administrada (gMSA) del grupo de HGS acceso a la clave privada en cada nodo. Estas tareas agregan una carga operativa adicional, pero son necesarias para las claves con respaldo de HSM y los certificados con claves privadas no exportables.

Los certificados SSL nunca se replican en ningún formato. Es su responsabilidad inicializar cada servidor de HGS con el mismo certificado SSL y actualizar cada servidor cada vez que decida renovar o reemplazar el certificado SSL. Al reemplazar el certificado SSL, se recomienda hacerlo mediante el cmdlet Set-HgsServer.

Eliminación de la configuración de HGS

Si necesita retirar o volver a configurar de forma importante un servidor de HGS, puede hacerlo mediante los cmdlets Clear-HgsServer o Uninstall-HgsServer.

Eliminación de la configuración de HGS

Para quitar un nodo del clúster de HGS, use el cmdlet Clear-HgsServer. Este cmdlet realizará los siguientes cambios en el servidor donde se ejecuta:

• Anula los servicios de atestación y protección de claves.
• Quita el punto de conexión de administración de JEA "microsoft.windows.hgs".
• Quita el equipo local del clúster de conmutación por error de HGS.

Si el servidor es el último nodo de HGS del clúster, el clúster y su correspondiente recurso de nombre de red distribuida también se destruirán.

# Removes the local computer from the HGS cluster
Clear-HgsServer

Una vez completada la operación de borrado, el servidor de HGS se puede volver a inicializar con Initialize-HgsServer. Si usó Install-HgsServer para configurar un dominio de Active Directory Domain Services, ese dominio permanecerá configurado y operativo después de la operación de borrado.

Desinstalación de HGS

Si desea quitar un nodo del clúster de HGS y disminuir de nivel el controlador de dominio de Active Directory que se ejecuta en él, use el cmdlet Uninstall-HgsServer. Este cmdlet realizará los siguientes cambios en el servidor donde se ejecuta:

• Anula los servicios de atestación y protección de claves.
• Quita el punto de conexión de administración de JEA "microsoft.windows.hgs".
• Quita el equipo local del clúster de conmutación por error de HGS.
• Disminuye el nivel del controlador de dominio de Active Directory, si está configurado.

Si el servidor es el último nodo de HGS del clúster, también se destruirá el dominio, el clúster de conmutación por error y el recurso de nombre de red distribuida del clúster.

# Removes the local computer from the HGS cluster and demotes the ADDC (restart required)
$newLocalAdminPassword = Read-Host -AsSecureString -Prompt "Enter a new password for the local administrator account"
Uninstall-HgsServer -LocalAdministratorPassword $newLocalAdminPassword -Restart

Una vez que se haya completado la operación de desinstalación y se haya reiniciado el equipo, puede reinstalar ADDC y HGS mediante Install-HgsServer o unir el equipo a un dominio e inicializar el servidor de HGS en dicho dominio con Initialize-HgsServer.

Si ya no tiene previsto usar el equipo como un nodo de HGS, puede quitar el rol de Windows.

Uninstall-WindowsFeature HostGuardianServiceRole