Qué es Health Attestation (HA) para Windows y cómo funciona

Cuando hablamos de seguridad en Windows moderna ya no basta con tener solo antivirus y parches al día. En entornos donde los dispositivos acceden a datos muy sensibles (correo corporativo, aplicaciones críticas, información personal de clientes, etc.), hace falta una forma fiable de saber si una máquina realmente ha arrancado de forma limpia o si hay algo raro metiéndose en medio del proceso de arranque.

Ahí entra en juego Health Attestation (HA) o Device Health Attestation (DHA), una característica de Windows que se apoya en el hardware (sobre todo en el chip TPM y el firmware UEFI) para medir cómo ha arrancado el equipo, enviar esas pruebas a un servicio de validación y devolver un informe que las soluciones MDM o de gestión puedan usar para tomar decisiones: dar acceso, poner el dispositivo en cuarentena, obligar a cifrar el disco, etc.

Qué es Health Attestation (HA) para Windows y para qué sirve

Health Attestation es un mecanismo de atestación remota del estado de arranque de un dispositivo Windows. El sistema toma medidas del firmware UEFI, del cargador de arranque, del kernel, de los controladores críticos, de la política de integridad de código, de BitLocker, del Secure Boot y de otras protecciones, las guarda en el TPM y las envía a un servicio de atestación que las valida y genera un informe firmado.

Ese informe de estado (DHA-Report o certificado de atestación de estado) contiene indicadores clave: si el arranque seguro está activado, si BitLocker protege el volumen del sistema, si el modo depuración está deshabilitado, si se ha cargado un controlador ELAM, si la política de Device Guard se ha aplicado, qué versión de TPM tiene el equipo, qué valor tiene PCR0, etc. Todo ello permite a la empresa tener un “termómetro” muy fiable de la postura de seguridad del dispositivo.

Health Attestation está pensado para integrarse con soluciones de administración de dispositivos móviles (MDM) como Microsoft Intune, Citrix Endpoint Management u otras herramientas compatibles con el CSP de HealthAttestation. El flujo típico es: el MDM pide al dispositivo pruebas, el dispositivo contacta con el servicio de atestación, recibe un blob cifrado, lo reenvía al MDM y este pregunta al servicio si ese blob es válido y qué nivel de seguridad refleja.

La gran ventaja es que la decisión de confianza no se basa en lo que dice el propio sistema operativo sin más, sino en datos medidos y protegidos por hardware (TPM) que un malware en modo kernel o un rootkit no puede manipular sin dejar rastro en las mediciones de arranque.

Componentes clave: TPM, ELAM, Secure Boot y seguridad basada en virtualización

Para que Health Attestation tenga sentido, Windows se apoya en varias defensas de bajo nivel que trabajan desde el primer ciclo de arranque y que van mucho más allá del típico antivirus en segundo plano.

El Módulo de Plataforma Segura (TPM) es un chip especializado, físico o de firmware, que genera y guarda claves de cifrado, números aleatorios y registros de configuración de plataforma (PCR). Durante el arranque, el firmware y Windows van “midiento” cada componente (calculan hashes) y los van acumulando en esos PCR, además de registrar el detalle en el log TCG. Estas mediciones quedan amarradas al hardware y son la materia prima de la atestación.

Secure Boot, basado en firmware UEFI, solo permite cargar un gestor de arranque y componentes firmados por claves autorizadas en la base de datos del firmware. Si alguien intenta meter un bootkit o modificar el cargador del sistema operativo, la firma no cuadrará y el sistema no arrancará, o bien quedará reflejado en los registros medidos que luego validará el servicio de atestación.

Trusted Boot y Early Launch Antimalware (ELAM) controlan lo que pasa una vez que el cargador de arranque da el salto al kernel de Windows. Trusted Boot verifica la integridad del kernel y de los controladores de arranque, mientras que ELAM carga un mini-controlador antimalware firmado por Microsoft antes que cualquier driver de terceros, para decidir qué controlador se considera confiable y cuál no entra ni de broma.

La seguridad basada en virtualización (VBS), con tecnologías como Credential Guard y Device Guard, añade una capa más: usando Hyper-V se crea un entorno aislado donde se protegen credenciales y se hace cumplir la integridad de código del kernel (HVCI). Incluso si un atacante llega a comprometer el sistema operativo, le resulta extremadamente difícil modificar estos componentes aislados.

CSP HealthAttestation en Windows 10 y Windows 11

El “pegamento” entre el sistema operativo y el MDM es el proveedor de servicios de configuración (CSP) HealthAttestation, accesible a través de la ruta ./Vendor/MSFT/HealthAttestation. Este CSP expone una serie de nodos que permiten desencadenar atestaciones, leer estados y configurar parámetros de comunicación con el servicio de atestación.

Algunos de los nodos más relevantes del CSP HealthAttestation son:

• Status: devuelve un código numérico que indica si la recuperación del certificado de estado está sin inicializar, solicitada, completada o ha fallado por algún motivo concreto (sin nonce, sin correlación, fallo HTTP, etc.).
• Certificate: proporciona, codificado en base64, el blob de datos (DHA-Data / DHA-EncBlob) que el dispositivo ha recibido del servicio de atestación y que el MDM debe reenviar para validación.
• Nonce: valor aleatorio protegido criptográficamente que genera el servidor MDM para evitar ataques de repetición o “man in the middle”. El MDM lo escribe, el cliente lo incluye en su solicitud, y el servicio de atestación lo devuelve en el informe.
• HASEndpoint: FQDN del servicio de atestación que va a usar el cliente. Si no se cambia, apunta al servicio en la nube de Microsoft (has.spserv.microsoft.com). Si se configura un servidor DHA local o en Azure, aquí se pone su nombre.
• GetAttestReport y GetServiceCorrelationIDs: en Windows 11, estos nodos permiten obtener el token JWT con el informe de atestación y los identificadores de correlación de la sesión de Microsoft Azure Attestation (MAA), fundamentales para depurar problemas.

Windows 11 amplía el CSP de HealthAttestation con nodos pensados para integrarse directamente con Microsoft Azure Attestation. Por ejemplo, TriggerAttestation permite lanzar una atestación TPM contra un endpoint de MAA especificado, incluyendo un token de Microsoft Entra, un nonce y un vector de correlación que el servicio devolverá en el informe para poder rastrear la sesión extremo a extremo.

En todos los casos, el CSP trabaja de forma asíncrona: el MDM envía un comando Exec para disparar la atestación, consulta el nodo Status hasta que el valor indica que el certificado está listo y, a partir de ahí, recupera el blob base64 y el CorrelationId para remitirlos al servicio de atestación correspondiente.

Modos y tipos de servicio DHA: nube, local y Azure

Microsoft ofrece el servicio Device Health Attestation de varias formas según el escenario y el nivel de control que quiera la organización sobre el tratamiento de los datos de arranque medidos.

Servicio en la nube (DHA-Cloud): es el servicio público operado por Microsoft, gratuito, geográficamente balanceado y optimizado para dispositivos distribuidos globalmente. Los equipos Windows 10 y Windows 11 pueden usarlo por defecto si no se personaliza el endpoint en el CSP.

Servicio local (DHA-OnPrem): desde Windows Server 2016 existe un rol de “Atestación de estado de dispositivo” que permite levantar un servidor DHA dentro de la propia red corporativa. Esto reduce la latencia, evita que los informes de estado salgan a Internet y ofrece más control sobre certificados y cadenas de confianza TPM.

Servicio en la nube administrada (DHA-EMC o en Azure): el mismo rol de DHA-Server se puede ejecutar en una máquina virtual en Microsoft Azure u otra nube compatible, dando una solución híbrida: el servicio es propiedad de la empresa, pero corre en infraestructura cloud.

Además de dónde se ejecuta, el servicio DHA puede trabajar en distintos modos de validación de certificados TPM:

• Modo EKCert: orientado a entornos sin acceso directo a Internet. El servidor DHA mantiene un paquete de certificados raíz e intermedios de fabricantes de TPM de confianza (archivo .cab que publica Microsoft periódicamente). Las cadenas se actualizan varias veces al año.
• Modo AIKCert: pensado para dispositivos con acceso a Internet. Los equipos obtienen un certificado de clave de identidad de atestación (AIK) emitido por Microsoft, y el servidor DHA valida las atestaciones basándose en ese certificado.

En ambos modos, la idea es la misma: el servicio comprueba que el TPM es legítimo y que las mediciones de PCR y el registro TCG cuadran con lo informado en el certificado. La diferencia está en si esa confianza viene de certificados EK proporcionados por el OEM del TPM o de certificados AIK emitidos por Microsoft.

Instalación y configuración de un servidor DHA en Windows Server

Para montar un servidor DHA local hay que cumplir unos requisitos mínimos y seguir una serie de pasos relativamente estructurados. Esto es crítico si se quiere que soluciones como Citrix Endpoint Management o Intune apunten a un servicio de atestación propio.

Requisitos básicos:

• Un servidor con Windows Server 2016 (o superior), preferiblemente instalado con la opción “Experiencia de escritorio” para facilitar la administración.
• Uno o varios clientes Windows 10 o Windows 11 con TPM 1.2 o 2.0 en estado “ready” o cifrado, ejecutando compilaciones soportadas, y correctamente inscritos en la solución MDM.
• Decisión previa sobre si se usará validación EKCert o AIKCert, en función de si los dispositivos tienen salida a Internet.
• Tres certificados X.509 de empresa con clave privada exportable: SSL de DHA para proteger el canal TLS, certificado de firma de DHA para firmar digitalmente los informes y certificado de cifrado de DHA para proteger los blobs de estado.

El rol de Atestación de estado de dispositivo se instala desde el Administrador del servidor, seleccionando “Agregar roles y características”, eligiendo instalación basada en roles o características y marcando el rol de “Atestación de estado de dispositivo” (o “Atestación de mantenimiento del dispositivo” según el idioma). El asistente añadirá automáticamente las dependencias necesarias, incluido IIS.

Después hay que importar el certificado SSL al almacén adecuado y asignarlo al sitio web de DHA. Esto implica importar el .pfx al almacén de la máquina, revisar la instalación con MMC y desde IIS vincular ese certificado al binding HTTPS del sitio.

Los certificados de firma y cifrado se asocian al servicio DHA mediante PowerShell. El procedimiento típico consiste en localizar los certificados por su huella digital en LocalMachine\My, ajustar permisos sobre sus claves privadas para la cuenta del pool de aplicaciones de IIS (por defecto IIS_IUSRS) con icacls, e invocar después el cmdlet Install-DeviceHealthAttestation indicando las huellas de cifrado, firma y SSL, junto con los esquemas de autenticación soportados (AikCertificate, EkCertificate, AikPub, etc.).

Si se usa el modo EKCert, es obligatorio instalar el paquete de certificados raíz TPM de confianza. Se descarga un .cab desde la URL pública que Microsoft mantiene, se extrae en un directorio, se pueden eliminar las carpetas de fabricantes de TPM que no se consideren confiables en la organización, y se ejecuta el script setup.cmd incluido para registrar las cadenas de certificado soportadas.

Finalmente, se puede ajustar la Directiva de cadena de certificados X509ChainPolicy del servicio DHA con cmdlets como Get-DHASCertificateChainPolicy y Set-DHASCertificateChainPolicy, decidendo por ejemplo si se comprueba la revocación (RevocationMode), qué banderas de verificación se aplican o el tiempo de espera de recuperación de URLs de CRL.

Comandos de administración DHA más habituales

Una vez que el servidor DHA está en marcha, la administración diaria se hace casi siempre con un pequeño conjunto de cmdlets de PowerShell que permiten reconfigurar certificados, revisar el estado del servicio y eliminar configuraciones antiguas.

Para una configuración inicial básica se utiliza:

• Install-DeviceHealthAttestation -SigningCertificateThumbprint "<HEX>" -EncryptionCertificateThumbprint "<HEX>" -SslCertificateThumbprint "<HEX>" -Force

Si se quiere dejar el servidor “limpio” para volver a empezar o desmantelar el rol, se puede ejecutar:

• Uninstall-DeviceHealthAttestation -RemoveSslBinding -Force

La rotación de certificados de firma y cifrado también está contemplada. Se pueden consultar los certificados activos con Get-DHASActiveSigningCertificate y Get-DHASActiveEncryptionCertificate, establecer nuevos activos con Set-DHASActiveSigningCertificate o Set-DHASActiveEncryptionCertificate, y gestionar listas de certificados inactivos con Get-DHASInactiveSigningCertificate, Remove-DHASInactiveSigningCertificate y sus equivalentes para cifrado.

Respecto a la política de validación de certificados, el cmdlet clave es Set-DHASCertificateChainPolicy, que aplica un objeto de tipo X509ChainPolicy donde se han modificado propiedades como RevocationFlag, RevocationMode, VerificationFlags o UrlRetrievalTimeout. Esto es útil para adaptar la validación a entornos desconectados o con proxies restrictivos.

Qué datos comprueba el servicio de Health Attestation

El informe que genera el servicio de atestación (DHA-Report) es muy rico en señales de seguridad sobre el arranque y el entorno de ejecución temprano del dispositivo. Tanto DHA-Cloud como DHA-OnPrem emiten respuestas basadas en un esquema XML (en v3) o en tokens JWT (en el caso de Microsoft Azure Attestation) con multitud de campos.

Algunos de los campos más relevantes del informe clásico v3 son:

• Issued: fecha y hora en que se ha evaluado el certificado de estado.
• AIKPresent: indica si la atestación se ha hecho con un AIK respaldado por certificado (más confianza) o no.
• BitlockerStatus: refleja si BitLocker estaba activo en el arranque, lo que determina si los datos en disco están protegidos cuando el equipo está apagado o en hibernación.
• SecureBootEnabled: señala si el arranque seguro UEFI estaba habilitado, clave para evitar cargadores de arranque no firmados.
• BootDebuggingEnabled y OSKernelDebuggingEnabled: informan sobre si la depuración de arranque y del kernel están encendidas, algo típico en entornos de pruebas pero inaceptable en producción.
• CodeIntegrityEnabled y CodeIntegrityRevListVersion: cuentan si la integridad de código está activa y qué versión de lista de revocación se está usando.
• TestSigningEnabled: si está a true, el sistema permite controladores de prueba sin firma necesaria, abriendo una puerta a código no confiable.
• VSMEnabled: indica si el modo seguro virtual (VBS) está habilitado, condición necesaria para Credential Guard y HVCI.
• ELAMDriverLoaded: muestra si se cargó un controlador ELAM de Windows Defender durante el arranque, lo que ayuda a bloquear drivers sospechosos en fases muy tempranas.
• PCR0: valor hash del PCR [0], que suele representar la combinación de firmware y componentes de plataforma del fabricante. Muchas empresas construyen listas blancas de PCR0 aceptables.
• CIPolicy, BootRevListInfo, OSRevListInfo y SBCPHash: proporcionan información de políticas de integridad de código, listas de revocación de arranque y sistema operativo, y políticas de Secure Boot personalizadas.
• BootAppSVN y BootManagerSVN: números de versión de seguridad de la aplicación de arranque y del gestor de arranque, útiles para detectar versiones obsoletas o potencialmente vulnerables.
• TpmVersion: indica si el TPM es 1.2 o 2.0, dato que muchas organizaciones usan como criterio de cumplimiento mínimo.

Con Windows 11 y Microsoft Azure Attestation, el informe toma forma de JSON Web Token (JWT) firmado, donde se incorporan muchas de estas mismas propiedades como claims: secureBootEnabled, bitlockerEnabled, WindowsDefenderElamDriverLoaded, vbsEnabled, hvciEnabled, hashes de políticas, datos de revocación, etc. El MDM puede validar la firma del JWT y luego aplicar su lógica de negocio a partir de estos claims.

Sobre esta información es donde la solución MDM o de acceso condicional define reglas de cumplimiento. Por ejemplo: exigir BitLocker y Secure Boot para acceder a datos de alto impacto, negar el acceso si TestSigningEnabled = true, marcar para revisión manual los equipos con BootManagerRevListVersion desactualizado o denegar cualquier equipo cuyo PCR0 no coincida con una lista blanca aprobada.

Flujos de atestación en Windows 10 y Windows 11

El flujo de atestación de estado no es igual en todas las versiones de Windows, aunque la idea central se mantiene: recoger datos de arranque medido y convertirlos en una afirmación firmada sobre el estado del dispositivo.

En Windows 10, Device Health Attestation se basa en el CSP DHA y en el servicio DHA-Cloud o DHA-Server2016. Durante el arranque se miden firmware, Secure Boot, BitLocker, directivas de Device Guard, ELAM, etc. El CSP empaqueta los registros TCG y valores PCR (DHA-BootData), los envía al servicio DHA, recibe un DHA-EncBlob y lo cachea. Cuando el MDM pide una verificación, el CSP le devuelve un XML con DHA-EncBlob y DHA-SignedBlob, y el MDM publica eso al servicio DHA-Cloud o Dha-OnPrem para obtener un DHA-Report evaluado.

En Windows 11, se introduce un enfoque más flexible apoyado en Microsoft Azure Attestation (MAA). El CSP HealthAttestation incorpora el nodo TriggerAttestation, al que el MDM envía parámetros como el identificador de la parte que confía (rpID), el endpoint exacto de MAA, un nonce en hexadecimal, un token de Microsoft Entra y un vector de correlación. El dispositivo recopila las evidencias TPM, las remite a MAA, recibe un token JWT con el resultado y lo expone a través de GetAttestReport.

En ambos casos, el MDM se encarga de comprobar que el informe procede de un servicio de atestación legítimo (validando la firma o el certificado del servicio), de correlacionarlo con el dispositivo correcto mediante el nonce y el CorrelationId, y de traducir los valores brutos de seguridad a un estado de “cumple” o “no cumple” acorde a la política corporativa.

La otra pieza del puzle es el motor de acceso condicional, normalmente en Microsoft Entra ID, ADFS o soluciones equivalentes. Este motor consulta el estado de cumplimiento que ha notificado el MDM y, junto con la identidad del usuario, la ubicación, el tipo de aplicación y otros factores, decide si concede, deniega o condiciona el acceso a aplicaciones SaaS, Office 365, aplicaciones locales publicadas con proxy de aplicación, VPN, etc.

Al final, Health Attestation actúa como un “oráculo” de confianza basado en hardware: da a Intune, a Citrix Endpoint Management o a la solución que toque una visión comprobable del estado real del dispositivo, para que el control de acceso no se limite solo a “usuario y contraseña correctos”, sino también a “el dispositivo que intenta entrar está limpio y configurado como exige la empresa”.

Gracias a esta combinación de TPM, arranque medido, CSP HealthAttestation, servicios DHA/MAA y MDM con acceso condicional, Windows puede jugar en ligas de seguridad muy altas: proteger credenciales contra ataques pass-the-hash con Credential Guard, bloquear la ejecución de software no autorizado con Device Guard, garantizar que el firmware y el arranque no han sido manipulados y, sobre todo, usar todo ese contexto para decidir qué recursos se exponen y a quién. En un mundo BYOD y de trabajo híbrido, ese nivel de control fino sobre el estado del dispositivo es lo que marca la diferencia entre “tener antivirus” y disponer de una arquitectura de confianza robusta de extremo a extremo.