Compartir a través de

Solución de problemas del servicio de protección de host

  • Artículo

En este artículo se describen las soluciones a los problemas más comunes que surgen al implementar o poner en funcionamiento un servidor del Servicio de protección de host (HGS) en un tejido protegido.

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Si no está seguro de la naturaleza del problema, pruebe primero a ejecutar los diagnósticos de tejido protegidos en los servidores HGS y los hosts de Hyper-V para reducir las posibles causas.

Certificados

HGS requiere varios certificados para funcionar, incluido el cifrado y la firma configurados por el administrador, así como un certificado de atestación administrado por el propio HGS. Si estos certificados están configurados incorrectamente, HGS no puede atender solicitudes de hosts de Hyper-V que deseen atestiguar o desbloquear protectores de claves para máquinas virtuales blindadas. En las secciones siguientes se tratan problemas comunes relacionados con los certificados configurados en HGS.

Permisos de certificado

HGS debe poder acceder a las claves públicas y privadas de los certificados de cifrado y firma agregados a HGS mediante la huella digital del certificado. En concreto, la cuenta de servicio administrada del grupo (gMSA) que ejecuta el servicio HGS necesita acceso a las claves. Para buscar la gMSA usada por HGS, ejecute el siguiente comando en un símbolo del sistema de PowerShell con privilegios elevados en el servidor de HGS:

(Get-IISAppPool -Name KeyProtection).ProcessModel.UserName

La forma en que concede a la cuenta de gMSA el acceso para usar la clave privada depende de dónde se almacena la clave: en el equipo como un archivo de certificado local, en un módulo de seguridad de hardware (HSM) o mediante un proveedor de almacenamiento de claves de terceros personalizado.

Concesión de acceso a claves privadas respaldadas por software

Si usa un certificado autofirmado o un certificado emitido por una entidad de certificación que no está almacenado en un módulo de seguridad de hardware o un proveedor de almacenamiento de claves personalizado, puede cambiar los permisos de clave privada realizando los pasos siguientes:

  1. Abra el administrador de certificados local (certlm.msc).
  2. Expanda Certificados personales>y busque el certificado de firma o cifrado que desea actualizar.
  3. Haga clic con el botón derecho en el certificado y seleccione Todas las tareas>Administrar claves privadas.
  4. Seleccione Agregar para conceder a un nuevo usuario acceso a la clave privada del certificado.
  5. En el selector de objetos, escriba el nombre de cuenta de gMSA para HGS encontrado anteriormente y seleccione Aceptar.
  6. Asegúrese de que la gMSA tiene acceso de Lectura al certificado.
  7. Seleccione Aceptar para cerrar la ventana de permisos.

Si ejecuta HGS en Server Core o administra el servidor de forma remota, no podrá administrar claves privadas mediante el administrador de certificados local. En su lugar, debe descargar el módulo de PowerShell Herramientas de Tejido protegido, que le permitirá administrar los permisos en PowerShell.

  1. Abra una consola PowerShell elevada en la máquina de Server Core o use PowerShell Remoting con una cuenta que tenga permisos de administrador local en HGS.
  2. Ejecute los siguientes comandos para instalar el módulo de PowerShell de Herramientas de tejido protegido y conceder a la cuenta gMSA acceso a la clave privada.
$certificateThumbprint = '<ENTER CERTIFICATE THUMBPRINT HERE>'

# Install the Guarded Fabric Tools module, if necessary
Install-Module -Name GuardedFabricTools -Repository PSGallery

# Import the module into the current session
Import-Module -Name GuardedFabricTools

# Get the certificate object
$cert = Get-Item "Cert:\LocalMachine\My\$certificateThumbprint"

# Get the gMSA account name
$gMSA = (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName

# Grant the gMSA read access to the certificate
$cert.Acl = $cert.Acl | Add-AccessRule $gMSA Read Allow

Concesión de acceso a HSM o claves privadas personalizadas respaldadas por el proveedor

Si las claves privadas del certificado están respaldadas por un módulo de seguridad de hardware (HSM) o un proveedor de almacenamiento de claves personalizado (KSP), el modelo de permisos depende de su proveedor de software específico. Para obtener los mejores resultados, consulte la documentación o el sitio de soporte técnico de su proveedor para obtener información sobre cómo se controlan los permisos de clave privada para su dispositivo o software específico. En todos los casos, la gMSA usada por HGS requiere permisos de lectura en las claves privadas de cifrado, firma y certificado de comunicaciones para que pueda realizar operaciones de firma y cifrado.

Algunos módulos de seguridad de hardware no admiten la concesión de acceso a cuentas de usuario específicas a una clave privada; en su lugar, permiten que la cuenta de equipo acceda a todas las claves de un conjunto de claves específico. Para estos dispositivos, normalmente es suficiente proporcionar al equipo acceso a las claves y HGS puede aprovechar esa conexión.

Sugerencias para HSM

A continuación se sugieren opciones de configuración para ayudarle a usar con éxito las claves respaldadas por HSM con HGS basadas en las experiencias de Microsoft y sus partners. Estas sugerencias se proporcionan para su comodidad y no se garantiza que sean correctas en el momento de la lectura, ni están aprobadas por los fabricantes de HSM. Póngase en contacto con el fabricante de HSM para obtener información precisa relacionada con su dispositivo específico si tiene más preguntas.

Marca/serie HSM Sugerencia
Gemalto SafeNet Asegúrese de que la Propiedad de uso de claves en el archivo de solicitud de certificado está establecida en 0xa0, lo que permite usar el certificado para la firma y el cifrado. Además, debe conceder a la cuenta de gMSA acceso de lectura a la clave privada mediante la herramienta de administrador de certificados local (consulte los pasos anteriores).
nCipher nShield Asegúrese de que cada nodo de HGS tiene acceso al mundo de seguridad que contiene las claves de firma y cifrado. Es posible que además tenga que conceder a la gMSA acceso de lectura a la clave privada usando el administrador de certificados local (consulte los pasos anteriores).
Utimaco CryptoServers Asegúrese de que la Propiedad de uso de claves en el archivo de solicitud de certificado está establecida en 0x13, lo que permite usar el certificado para cifrar, descifrar y firmar.

Solicitudes de certificado

Si usa una entidad de certificación para emitir los certificados en un entorno de infraestructura de clave pública (PKI), debe asegurarse de que la solicitud de certificado incluye los requisitos mínimos para el uso de esas claves en HGS.

Certificados de firma

Propiedad CSR Valor obligatorio
Algoritmo RSA
Key size Al menos 2048 bits
Uso de las claves Signature/Sign/DigitalSignature

Certificados de cifrado

Propiedad CSR Valor obligatorio
Algoritmo RSA
Key size Al menos 2048 bits
Uso de las claves Encryption/Encrypt/DataEncipherment

Plantillas de Servicios de certificados de Active Directory

Si usa plantillas de certificado de Active Directory Certificate Services (ADCS) para crear los certificados, se recomienda usar una plantilla con la siguiente configuración:

Propiedad de plantilla de ADCS Valor obligatorio
Categoría del proveedor Proveedor de almacenamiento de claves
Nombre del algoritmo RSA
Tamaño mínimo de clave 2048
Propósito Firma y cifrado
Extensión de uso de claves Firma digital, cifrado de claves, cifrado de datos ("Permitir el cifrado de datos de usuario")

Desfase de tiempo

Si la hora de su servidor se ha desfasado significativamente con respecto a la de otros nodos HGS o hosts de Hyper-V de su tejido protegido, es posible que tenga problemas con la validez del certificado del firmante de atestación. El certificado de firmante de atestación se crea y renueva entre bastidores en HGS y se usa para firmar certificados sanitarios emitidos a hosts protegidos por el Servicio de atestación.

Para actualizar el certificado del firmante de atestación, ejecute el siguiente comando en un símbolo del sistema de PowerShell con privilegios elevados.

Start-ScheduledTask -TaskPath \Microsoft\Windows\HGSServer -TaskName
AttestationSignerCertRenewalTask

Como alternativa, puede ejecutar manualmente la tarea programada abriendo el Programador de tareas (taskschd.msc), navegando a biblioteca de programador>de tareas Microsoft>Windows>HGSServer y ejecutando la tarea denominada AttestationSignerCertRenewalTask.

Cambiar los modos de atestación

Si cambia HGS del modo TPM al modo de Active Directory o viceversa mediante el cmdlet Set-HgsServer, cada nodo del clúster de HGS puede tardar hasta 10 minutos en empezar a aplicar el nuevo modo de atestación.

Este es el comportamiento normal.

Se recomienda que no quite ninguna directiva que permita a los hosts del modo de atestación anterior hasta que haya comprobado que todos los hosts están atestiguando correctamente mediante el nuevo modo de atestación.

Problema conocido al cambiar de TPM a modo de AD

Si inicializó el clúster de HGS en modo TPM y más adelante cambia al modo de Active Directory, hay un problema conocido que impide que otros nodos del clúster de HGS cambien al nuevo modo de atestación. Para asegurarse de que todos los servidores HGS aplican el modo de atestación correcto, ejecute Set-HgsServer -TrustActiveDirectory en cada nodo del clúster de HGS.

Este problema no se aplica si cambia del modo TPM al modo AD y el clúster se configuró originalmente en modo AD.

Para comprobar el modo de atestación del servidor de HGS, ejecute Get-HgsServer.

Directivas de cifrado de volcado de memoria

Si está intentando configurar directivas de cifrado de volcado de memoria y no ve las directivas de volcado de memoria predeterminadas de HGS (Hgs_NoDumps, Hgs_DumpEncryption y Hgs_DumpEncryptionKey) o el cmdlet de directiva de volcado de memoria (Add-HgsAttestationDumpPolicy), es probable que no tenga instalada la actualización acumulativa más reciente.

Para corregirlo, actualice el servidor de HGS a la actualización acumulativa de Windows más reciente y active las nuevas directivas de atestación.

Asegúrese de actualizar los hosts de Hyper-V a la misma actualización acumulativa antes de activar las nuevas directivas de atestación, ya que los hosts que no tienen instaladas las nuevas funcionalidades de cifrado de volcado de memoria probablemente producirán un error en la atestación una vez activada la directiva HGS.

Mensajes de error del certificado de clave de aprobación

Al registrar un host mediante el cmdlet Add-HgsAttestationTpmHost , se extraen dos identificadores de TPM del archivo de identificador de plataforma proporcionado: el certificado de clave de aprobación (EKcert) y la clave de aprobación pública (EKpub). EKcert identifica al fabricante del TPM, proporcionando garantías de que el TPM es auténtico y fabricado a través de la cadena de suministro normal. EKpub identifica de forma única ese TPM específico y es una de las medidas que usa HGS para conceder a un host acceso para ejecutar máquinas virtuales blindadas.

Recibirá un error al registrar un host de TPM si se cumple alguna de las dos condiciones:

  • El archivo de identificador de plataforma no contiene un certificado de clave de aprobación.
  • El archivo de identificador de plataforma contiene un certificado de clave de aprobación, pero ese certificado no es de confianza en el sistema.

Algunos fabricantes de TPM no incluyen EKcerts en sus TPM.

Si sospecha que este es el caso de su TPM, confirme con su OEM que sus TPM no deben tener un EKcert y use la marca -Force para registrar manualmente el host con HGS. Si el TPM debe tener un EKcert pero no se encontró uno en el archivo de identificador de plataforma, asegúrese de que usa una consola de PowerShell de administrador (con privilegios elevados) al ejecutar Get-PlatformIdentifier en el host.

Si recibió el error de que EKcert no es de confianza, asegúrese de que ha instalado el paquete de certificados raíz de TPM de confianza en cada servidor HGS y de que el certificado raíz del proveedor de TPM está presente en el almacén "TrustedTPM_RootCA" del equipo local. Los certificados intermedios aplicables también deben instalarse en el almacén de "TrustedTPM_IntermediateCA" en el equipo local. Después de instalar los certificados raíz e intermedio, debería ser capaz de ejecutar Add-HgsAttestationTpmHost correctamente.

Privilegios de cuenta de servicio administrada de grupo (gMSA)

La cuenta de servicio HGS (gMSA utilizada para el grupo de aplicaciones del Servicio de protección de claves en IIS) necesita que se le conceda el privilegio Generar auditorías de seguridad, también conocido como SeAuditPrivilege. Si falta este privilegio, la configuración inicial de HGS se realiza correctamente y IIS se inicia, pero el servicio de protección de claves no es funcional y devuelve el error HTTP 500 ("Error del servidor en la aplicación /KeyProtection"). También puede observar los siguientes mensajes de advertencia en el registro de eventos de la aplicación.

System.ComponentModel.Win32Exception (0x80004005): A required privilege is not held by the client
at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.NativeUtility.RegisterAuditSource(String pszSourceName, SafeAuditProviderHandle& phAuditProvider)
at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.SecurityLog.RegisterAuditSource(String sourceName)

o

Failed to register the security event source.
   at System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app)
   at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
   at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
   at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
   at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)

Failed to register the security event source.
   at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.SecurityLog.RegisterAuditSource(String sourceName)
   at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.SecurityLog.ReportAudit(EventLogEntryType eventType, UInt32 eventId, Object[] os)
   at Microsoft.Windows.KpsServer.KpsServerHttpApplication.Application_Start()

A required privilege is not held by the client
   at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.NativeUtility.RegisterAuditSource(String pszSourceName, SafeAuditProviderHandle& phAuditProvider)
   at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.SecurityLog.RegisterAuditSource(String sourceName)

Además, puede observar que ninguno de los cmdlets de Key Protection Service (por ejemplo, Get-HgsKeyProtectionCertificate) funciona y, en su lugar, devuelve errores.

Para resolver este problema, debe conceder a gMSA la opción "Generar auditorías de seguridad" (SeAuditPrivilege). Para ello, puede usar la directiva de seguridad local SecPol.msc en todos los nodos del clúster de HGS o la directiva de grupo. Como alternativa, puede usar la herramienta de SecEdit.exe para exportar la directiva de seguridad actual, realizar las ediciones necesarias en el archivo de configuración (que es un texto sin formato) y después volver a importarla.

Nota

Al configurar esta configuración, la lista de principios de seguridad definidos para un privilegio invalida completamente los valores predeterminados (no concatena). Por lo tanto, al definir esta configuración de directiva, asegúrese de incluir ambos titulares predeterminados de este privilegio (servicio de red y servicio local) además de la gMSA que va a agregar.