Controlar el estado de los dispositivos Windows

Artículo
08/11/2023
Se aplica a:

✅ Windows 11, ✅ Windows 10

En este artículo se detalla una solución de un extremo a otro que le ayuda a proteger los recursos de alto valor mediante la aplicación, el control y la notificación del estado de los dispositivos Windows.

Introducción

En escenarios de Bring Your Own Device (BYOD), los empleados traen dispositivos disponibles comercialmente para acceder tanto a los recursos relacionados con el trabajo como a sus datos personales. Los usuarios quieren usar el dispositivo que prefieran para acceder a las aplicaciones, los datos y los recursos de la organización no solo desde la red interna, sino también desde cualquier lugar. Este fenómeno también se conoce como la consumación de TI.

Los usuarios quieren tener la mejor experiencia de productividad al acceder a aplicaciones corporativas y trabajar en datos de la organización desde sus dispositivos. Esto significa que no toleran que se les pida que escriban sus credenciales de trabajo cada vez que acceden a una aplicación o a un servidor de archivos. Desde una perspectiva de seguridad, también significa que los usuarios manipulan las credenciales corporativas y los datos corporativos en dispositivos no administrados.

Con el aumento del uso de BYOD, habrá más sistemas no administrados y potencialmente incorrectos que accedan a servicios corporativos, recursos internos y aplicaciones en la nube.

Incluso los dispositivos administrados pueden verse comprometidos y ser dañinos. Las organizaciones deben detectar cuándo se ha infringido la seguridad y reaccionar lo antes posible para proteger los recursos de alto valor.

A medida que Microsoft avanza, las inversiones en seguridad se centran cada vez más en las defensas preventivas de seguridad y también en las capacidades de detección y respuesta.

Windows es un componente importante de una solución de seguridad de un extremo a otro que se centra no solo en la implementación de defensas preventivas de seguridad, sino que agrega funcionalidades de atestación de estado del dispositivo a la estrategia de seguridad general.

Descripción de una solución de seguridad de un extremo a otro sólida

El panorama actual de amenazas informáticas está aumentando a una velocidad nunca antes detectada. La sofisticación de los ataques criminales está creciendo, y no hay duda de que el malware ahora está dirigido tanto a los consumidores como a los profesionales de todos los sectores.

Durante los últimos años, una categoría determinada de amenazas se ha convertido en frecuente: amenazas persistentes avanzadas (APT). El término APT se usa habitualmente para describir cualquier ataque que parezca dirigirse a organizaciones individuales de forma continuada. De hecho, este tipo de ataque suele implicar adversarios determinados que pueden usar los métodos o técnicas necesarios.

Con los fenómenos BYOD, un dispositivo mal mantenido representa un objetivo de elección. Para un atacante, es una manera fácil de vulnerar el perímetro de la red de seguridad, obtener acceso a y, a continuación, robar recursos de alto valor.

Los atacantes se dirigen a las personas, no específicamente por quién son, sino por para quién trabajan. Un dispositivo infectado lleva malware a una organización, incluso si la organización ha endurecido el perímetro de las redes o ha invertido en su posición defensiva. Una estrategia defensiva no es suficiente contra estas amenazas.

Un enfoque diferente

En lugar del enfoque tradicional en la prevención del peligro, una estrategia de seguridad eficaz supone que los adversarios determinados vulnerarán con éxito cualquier defensa. Significa que es necesario desplazar el foco de los controles de seguridad preventivos a la detección y respuesta a problemas de seguridad. Por lo tanto, la implementación de la estrategia de gestión de riesgos equilibra la inversión en prevención, detección y respuesta.

Dado que los dispositivos móviles se usan cada vez más para acceder a la información corporativa, se requiere alguna manera de evaluar la seguridad o el estado de los dispositivos. En esta sección se describe cómo aprovisionar la evaluación del estado de los dispositivos de forma que los recursos de alto valor se puedan proteger frente a dispositivos incorrectos.

Los dispositivos que se usan para acceder a recursos corporativos deben ser de confianza. Un enfoque de seguridad eficaz de un extremo a otro es capaz de evaluar el estado del dispositivo y usar el estado de seguridad actual al conceder acceso a un recurso de alto valor.

figura 1.

Un diseño sólido debe establecer la identidad del usuario, reforzar el método de autenticación si es necesario y aprender comportamientos como la ubicación de red desde la que el usuario se conecta regularmente. Además, un enfoque moderno debe ser capaz de liberar contenido confidencial solo si se determina que los dispositivos de usuario son correctos y seguros.

En la ilustración siguiente se muestra una solución creada para evaluar el estado del dispositivo desde la nube. El dispositivo autentica al usuario a través de una conexión a un proveedor de identidades en la nube. Si el recurso administrado contiene información extremadamente confidencial, el motor de acceso condicional del proveedor de identidades puede optar por comprobar el cumplimiento de seguridad del dispositivo móvil antes de conceder el acceso. El dispositivo del usuario puede demostrar su estado de mantenimiento que se puede enviar en cualquier momento o cuando la administración de dispositivos móviles (MDM) lo solicita.

figura 2.

Los dispositivos Windows se pueden proteger frente a rootkits y bootkits de bajo nivel mediante tecnologías de hardware de bajo nivel, como el arranque seguro de unified Extensible Firmware Interface (UEFI).

Arranque seguro es un proceso de validación de firmware que ayuda a evitar ataques de rootkit; forma parte de la especificación UEFI. La intención de UEFI es definir una forma estándar para que el sistema operativo se comunique con hardware moderno, que puede funcionar más rápido y con funciones de entrada y salida (E/S) más eficaces que los sistemas BIOS anteriores controlados por interrupciones de software.

Un módulo de atestación de estado del dispositivo puede comunicar datos de arranque medidos protegidos por un módulo de plataforma segura (TPM) a un servicio remoto. Una vez que el dispositivo se inicia correctamente, los datos de medición del proceso de arranque se envían a un servicio en la nube de confianza (Servicio de atestación de estado) mediante un canal de comunicación más seguro y resistente a alteraciones.

El servicio de atestación de estado remoto realiza una serie de comprobaciones en las medidas. Valida los puntos de datos relacionados con la seguridad, incluido el estado de arranque (arranque seguro, modo de depuración, etc.) y el estado de los componentes que administran la seguridad (BitLocker, Device Guard, etc.). A continuación, transmite el estado de mantenimiento del dispositivo mediante el envío de un blob cifrado de estado al dispositivo.

Normalmente, una solución MDM aplica directivas de configuración e implementa software en los dispositivos. MDM define la línea de base de seguridad y conoce el nivel de cumplimiento del dispositivo con comprobaciones periódicas para ver qué software está instalado y qué configuración se aplica, y determinar el estado de mantenimiento del dispositivo.

Una solución MDM pide al dispositivo que envíe información de estado del dispositivo y reenvíe el blob cifrado de estado al servicio de atestación de estado remoto. El servicio de atestación de estado remoto comprueba los datos de estado del dispositivo, comprueba que MDM se comunica con el mismo dispositivo y, a continuación, emite un informe de estado del dispositivo de vuelta a la solución MDM.

Una solución MDM evalúa las aserciones de estado y, en función de las reglas de mantenimiento que pertenecen a la organización, puede decidir si el dispositivo está en buen estado. Si el dispositivo es correcto y compatible, MDM pasa esa información al proveedor de identidades para que se pueda invocar la directiva de control de acceso de la organización para conceder acceso.

A continuación, se autoriza el acceso al contenido al nivel de confianza adecuado para cualquier estado de mantenimiento y otros elementos condicionales que indiquen.

En función de los requisitos y la confidencialidad del recurso administrado, el estado del estado del dispositivo se puede combinar con la información de identidad del usuario al procesar una solicitud de acceso. A continuación, se autoriza el acceso al contenido al nivel de confianza adecuado. El motor de acceso condicional se puede estructurar para permitir una mayor comprobación según sea necesario para la confidencialidad del recurso administrado. Por ejemplo, si se solicita acceso a datos de alto valor, es posible que sea necesario establecer una autenticación de seguridad adicional consultando al usuario para que responda a una llamada telefónica antes de conceder el acceso.

Inversiones de seguridad de Microsoft en Windows

En Windows, hay tres pilares de inversión:

Proteger identidades. Microsoft forma parte de la alianza FIDO que tiene como objetivo proporcionar un método interoperable de autenticación segura al alejarse del uso de contraseñas para la autenticación, tanto en el sistema local como en servicios como recursos locales y recursos en la nube.
Protección de la información. Microsoft está realizando inversiones para permitir que las organizaciones tengan un mejor control sobre quién tiene acceso a datos importantes y qué pueden hacer con esos datos. Con Windows, las organizaciones pueden aprovechar las directivas que especifican qué aplicaciones se consideran aplicaciones corporativas y pueden ser de confianza para acceder a datos seguros.
Resistencia a amenazas. Microsoft ayuda a las organizaciones a proteger mejor los recursos empresariales frente a las amenazas de malware y ataques mediante el uso de defensas de seguridad basadas en hardware.

Proteger, controlar e informar sobre el estado de seguridad de los dispositivos basados en Windows

Esta sección es una introducción que describe diferentes partes de la solución de seguridad de un extremo a otro que ayuda a proteger los recursos de alto valor y la información de los atacantes y el malware.

figura 3.

Número	Parte de la solución	Descripción
1	Dispositivo basado en Windows	La primera vez que se enciende un dispositivo basado en Windows, se muestra la pantalla de la experiencia integrada (OOBE). Durante la instalación, el dispositivo se puede registrar automáticamente en Microsoft Entra ID e inscribirse en MDM. Un dispositivo basado en Windows con TPM puede notificar el estado de mantenimiento en cualquier momento mediante el servicio de atestación de estado disponible con todas las ediciones admitidas de Windows.
2	Proveedor de identidades	Microsoft Entra ID contiene usuarios, dispositivos registrados y aplicación registrada del inquilino de la organización. Un dispositivo siempre pertenece a un usuario y un usuario puede tener varios dispositivos. Un dispositivo se representa como un objeto con atributos diferentes, como el estado de cumplimiento del dispositivo. Una MDM de confianza puede actualizar el estado de cumplimiento. Microsoft Entra ID es más que un repositorio. Microsoft Entra ID puede autenticar usuarios y dispositivos y también puede autorizar el acceso a los recursos administrados. Microsoft Entra ID tiene un motor de control de acceso condicional que usa la identidad del usuario, la ubicación del dispositivo y también el estado de cumplimiento del dispositivo al tomar una decisión de acceso de confianza.
3	Administración de dispositivos móviles	Windows tiene compatibilidad con MDM que permite que el dispositivo se administre de forma inmediata sin implementar ningún agente. MDM puede ser Microsoft Intune o cualquier solución MDM de terceros que sea compatible con Windows.
4	Atestación de estado remoto	Health Attestation Service es un servicio en la nube de confianza operado por Microsoft que realiza una serie de comprobaciones de estado e informa a MDM qué características de seguridad de Windows están habilitadas en el dispositivo. La comprobación de seguridad incluye el estado de arranque (WinPE, modo seguro, modos de depuración y prueba) y componentes que administran la seguridad y la integridad de las operaciones en tiempo de ejecución (BitLocker, Device Guard).
5	Recurso administrado por la empresa	El recurso administrado por la empresa es el recurso que se va a proteger. Por ejemplo, el recurso puede ser Office 365, otras aplicaciones en la nube, recursos web locales publicados por Microsoft Entra ID o incluso acceso VPN.

La combinación de dispositivos basados en Windows, proveedor de identidades, MDM y atestación remota de estado crea una sólida solución de un extremo a otro que proporciona validación del estado y el cumplimiento de los dispositivos que acceden a recursos de alto valor.

Protección de dispositivos y credenciales empresariales frente a amenazas

En esta sección se describe qué ofrece Windows en términos de defensas de seguridad y a qué control se puede medir y notificar.

Defensas de seguridad basadas en hardware de Windows

Las formas más agresivas de malware intentan insertarse en el proceso de arranque lo antes posible para que puedan tomar el control del sistema operativo de forma temprana e impedir que los mecanismos de protección y el software antimalware funcionen. Este tipo de código malintencionado a menudo se denomina rootkit o bootkit. La mejor manera de evitar tener que lidiar con malware de bajo nivel es proteger el proceso de arranque para que el dispositivo esté protegido desde el principio. Windows admite varias capas de protección de arranque. Algunas de estas características solo están disponibles si se instalan tipos específicos de hardware. Para obtener más información, consulte la sección Requisitos de hardware .

figura 4.

Windows admite características para ayudar a evitar que se cargue malware sofisticado de bajo nivel, como rootkits y bootkits, durante el proceso de inicio:

Módulo de plataforma segura. Un módulo de plataforma segura (TPM) es un componente de hardware que proporciona características de seguridad únicas.

Windows usa características de seguridad de un TPM para medir la secuencia de integridad de arranque (y en función de eso, desbloquear automáticamente las unidades protegidas por BitLocker), para proteger las credenciales o para la atestación de estado.

Un TPM implementa controles que cumplen la especificación descrita por el grupo de computación de confianza (TCG). En el momento de escribir este artículo, hay dos versiones de la especificación de TPM producidas por TCG que no son compatibles entre sí:
- La primera especificación de TPM, versión 1.2, fue publicada en febrero de 2005 por tcg y estandarizada según el estándar ISO/IEC 11889.
- La especificación de TPM más reciente, denominada TPM 2.0, se publicó en abril de 2014 y ha sido aprobada por el Comité Técnico Conjunto de ISO/IEC (JTC) como ISO/IEC 11889:2015.
Windows usa el TPM para cálculos criptográficos como parte de la atestación de estado y para proteger las claves de BitLocker, Windows Hello, tarjetas inteligentes virtuales y otros certificados de clave pública. Para obtener más información, vea Requisitos de TPM en Windows.

Windows reconoce las especificaciones de TPM de las versiones 1.2 y 2.0 generadas por TCG. Para las características de seguridad más recientes y modernas, Windows solo admite TPM 2.0.

TPM 2.0 proporciona una revisión importante de las funcionalidades a través de TPM 1.2:
- Actualización de la fuerza criptográfica para satisfacer las necesidades de seguridad modernas
  - Compatibilidad con SHA-256 para PCR
  - Compatibilidad con el comando HMAC
- Flexibilidad de algoritmos criptográficos para satisfacer las necesidades gubernamentales
  - TPM 1.2 está severamente restringido en términos de qué algoritmos puede admitir
  - TPM 2.0 puede admitir algoritmos arbitrarios con actualizaciones secundarias en los documentos de especificación de TCG.
- Coherencia entre implementaciones
  - La especificación de TPM 1.2 permite a los proveedores una gran latitud al elegir los detalles de la implementación.
  - TPM 2.0 estandariza gran parte de este comportamiento
Arranque seguro. Los dispositivos con firmware UEFI se pueden configurar para cargar solo cargadores de arranque de sistema operativo de confianza. El arranque seguro no requiere un TPM.

La protección más básica es la característica de arranque seguro, que es una parte estándar de la arquitectura UEFI 2.2+. En un equipo con BIOS convencional, cualquier persona que pueda tomar el control del proceso de arranque puede arrancar con un cargador de sistema operativo alternativo y, potencialmente, obtener acceso a los recursos del sistema. Cuando el arranque seguro está habilitado, solo puede arrancar con un cargador de sistema operativo firmado con un certificado almacenado en la base de datos de arranque seguro ueFI. Naturalmente, el certificado de Microsoft que se usa para firmar digitalmente los cargadores del sistema operativo Windows se encuentra en ese almacén, lo que permite a UEFI validar el certificado como parte de su directiva de seguridad. El arranque seguro debe estar habilitado de forma predeterminada en todos los equipos certificados para Windows en el Programa de compatibilidad de hardware de Windows.

Arranque seguro es una característica basada en firmware UEFI, que permite la firma y verificación de archivos de arranque críticos y controladores en el momento del arranque. El arranque seguro comprueba los valores de firma del Administrador de arranque de Windows, el almacén BCD, el archivo cargador del sistema operativo Windows y otros archivos DLL críticos de arranque en tiempo de arranque antes de que el sistema pueda arrancar completamente en un sistema operativo utilizable mediante directivas definidas por el OEM en tiempo de compilación. Arranque seguro evita muchos tipos de rootkit basado en arranque, malware y otros ataques relacionados con la seguridad contra la plataforma Windows. El arranque seguro protege el proceso de arranque del sistema operativo, ya sea desde el disco duro local, USB, PXE o DVD, o en un entorno de recuperación de Windows o Windows (RE) completo. El arranque seguro protege el entorno de arranque de una instalación de Windows comprobando las firmas de los componentes de arranque críticos para confirmar que la actividad malintencionada no los pone en peligro. La protección de arranque seguro finaliza después de cargar el archivo de kernel de Windows (ntoskrnl.exe).

Nota

Arranque seguro protege la plataforma hasta que se carga el kernel de Windows. A continuación, las protecciones como ELAM toman el control.
Directiva de configuración de arranque seguro. Amplía la funcionalidad de arranque seguro a la configuración crítica de Windows.

Algunos ejemplos de información de configuración protegida son la protección del bit Deshabilitar ejecución (opción NX) o la garantía de que la directiva de firma de prueba (integridad de código) no se puede habilitar. Esta acción de protección garantiza que los archivos binarios y la configuración del equipo se puedan confiar una vez completado el proceso de arranque. La directiva de configuración de arranque seguro realiza esta acción de protección con la directiva UEFI. Estas firmas para estas directivas se firman de la misma manera que los archivos binarios del sistema operativo se firman para su uso con arranque seguro.

La directiva de configuración de arranque seguro debe estar firmada por una clave privada que corresponda a una de las claves públicas almacenadas en la lista Clave de intercambio de claves (KEK). La entidad de certificación (CA) de Microsoft estará presente en la lista KEK de todos los sistemas de arranque seguro certificados por Windows. De forma predeterminada, una directiva firmada por microsoft KEK funcionará en todos los sistemas de arranque seguro. BootMgr debe comprobar la firma en la lista KEK antes de aplicar una directiva firmada. Con Windows, la directiva de configuración de arranque seguro predeterminada se inserta en bootmgr.

El cargador de arranque comprueba la firma digital del kernel de Windows antes de cargarlo. A su vez, el kernel de Windows comprueba todos los demás componentes del proceso de inicio de Windows, incluidos los controladores de arranque, los archivos de inicio y el componente ELAM. Este paso es importante y protege el resto del proceso de arranque comprobando que todos los componentes de arranque de Windows tienen integridad y pueden ser de confianza.
Early Launch Antimalware (ELAM). ELAM prueba todos los controladores antes de que se carguen e impide que se carguen controladores no aprobados.

Las aplicaciones antimalware tradicionales no se inician hasta que se han cargado los controladores de arranque, lo que ofrece a un rootkit disfrazado de controlador la oportunidad de trabajar. ELAM es un mecanismo de Windows introducido en una versión anterior de Windows que permite que el software antimalware se ejecute al principio de la secuencia de arranque. Por lo tanto, el componente antimalware es el primer componente de terceros que ejecuta y controla la inicialización de otros controladores de arranque hasta que el sistema operativo Windows esté operativo. Cuando el sistema se inicia con un entorno en tiempo de ejecución completo (acceso a la red, almacenamiento, etc.), se carga un antimalware completo.

ELAM puede cargar un controlador antimalware de Microsoft o que no sea de Microsoft antes que todos los controladores y aplicaciones de arranque que no sean de Microsoft, continuando así la cadena de confianza establecida por arranque seguro y arranque de confianza. Dado que el sistema operativo aún no se ha iniciado y porque Windows necesita arrancar lo más rápido posible, ELAM tiene una tarea sencilla: Examinar todos los controladores de arranque y determinar si está en la lista de controladores de confianza. Si no es de confianza, Windows no lo cargará.

Nota

Windows Defender, el antimalware de Microsoft incluido de forma predeterminada en Windows admite ELAM; se puede reemplazar por una solución compatible con antimalware de terceros. Se WdBoot.sys el nombre del controlador ELAM de Windows Defender. Windows Defender usa su controlador ELAM para revertir los cambios malintencionados realizados en el controlador de Windows Defender en el siguiente reinicio. Esto evita que el malware en modo kernel realice cambios duraderos en el controlador de minifiltro de Windows Defender antes de apagar o reiniciar.

El controlador firmado de ELAM se carga antes que cualquier otro controlador o aplicación de terceros, lo que permite que el software antimalware detecte y bloquee los intentos de manipulación del proceso de arranque al intentar cargar código no firmado o que no es de confianza.

El controlador ELAM es un controlador pequeño con una pequeña base de datos de directivas que tiene un ámbito reducido, centrado en los controladores que se cargan al principio del inicio del sistema. La base de datos de directivas se almacena en un subárbol del Registro que también se mide en el TPM para registrar los parámetros operativos del controlador ELAM. Microsoft debe firmar un controlador ELAM y el certificado asociado debe contener el EKU complementario (1.3.6.1.4.1.311.61.4.1).
Seguridad basada en virtualización (Hyper-V + Kernel seguro). La seguridad basada en virtualización es un nuevo límite de seguridad aplicado que permite proteger partes críticas de Windows.

La seguridad basada en virtualización aísla el código confidencial, como la integridad del código en modo kernel o las credenciales de dominio corporativo confidenciales del resto del sistema operativo Windows. Para obtener más información, consulte la sección Seguridad basada en virtualización .
Integridad de código protegida por hipervisor (HVCI). La integridad de código protegida por hipervisor es una característica de Device Guard que garantiza que solo se pueden ejecutar controladores, ejecutables y ARCHIVOS DLL que cumplan la directiva de integridad de código de Device Guard.

Cuando está habilitado y configurado, Windows puede iniciar los servicios de seguridad basados en virtualización de Hyper-V. HVCI ayuda a proteger el núcleo del sistema (kernel), los controladores con privilegios y las defensas del sistema, como las soluciones antimalware, evitando que el malware se ejecute al principio del proceso de arranque o después del inicio.

HVCI usa la seguridad basada en virtualización para aislar la integridad del código; la única forma en que la memoria del kernel puede convertirse en ejecutable es mediante una comprobación de integridad de código. Esta dependencia de verificación significa que las páginas de memoria del kernel nunca pueden ser grabables y ejecutables (W+X) y el código ejecutable no se puede modificar directamente.

Nota

Los dispositivos de Device Guard que ejecutan integridad de código en modo kernel con seguridad basada en virtualización deben tener controladores compatibles. Para obtener más información, lea la entrada de blog Compatibilidad de controladores con Device Guard en Windows .

La característica Integridad de código de Device Guard permite a las organizaciones controlar qué código es de confianza para ejecutarse en el kernel de Windows y qué aplicaciones están aprobadas para ejecutarse en modo de usuario. Se puede configurar mediante una directiva. La directiva de integridad de código de Device Guard es un archivo binario que Microsoft recomienda firmar. La firma de la directiva de integridad de código ayuda a proteger a un usuario malintencionado con privilegios de administrador que intentan modificar o quitar la directiva de integridad de código actual.
Credential Guard. Credential Guard protege las credenciales corporativas con aislamiento de credenciales basadas en hardware.

En Windows, Credential Guard tiene como objetivo proteger las credenciales corporativas del dominio contra el robo y la reutilización por parte de malware. Con Credential Guard, Windows implementó un cambio arquitectónico que impide fundamentalmente las formas actuales del ataque pass-the-hash (PtH).

Este estado sin ataques se logra mediante Hyper-V y la nueva característica de seguridad basada en virtualización para crear un contenedor protegido donde el código de confianza y los secretos están aislados del kernel de Windows. Este logro significa que, incluso si el kernel de Windows está en peligro, un atacante no tiene ninguna manera de leer y extraer los datos necesarios para iniciar un ataque ptH. Credential Guard impide este acceso no autorizado porque la memoria donde se almacenan los secretos ya no es accesible desde el sistema operativo normal, incluso en modo kernel: los controles del hipervisor que pueden acceder a la memoria.
Atestación de estado. El firmware del dispositivo registra el proceso de arranque y Windows puede enviarlo a un servidor de confianza que pueda comprobar y evaluar el estado del dispositivo.

Windows toma medidas del firmware UEFI y cada uno de los componentes de Windows y antimalware se realiza a medida que se cargan durante el proceso de arranque. Además, se toman y miden secuencialmente, no todas a la vez. Una vez completadas estas medidas, sus valores se firman digitalmente y se almacenan de forma segura en el TPM y no se pueden cambiar a menos que se restablezca el sistema.

Para obtener más información, consulte Arranque seguro y arranque medido: Protección de componentes de arranque anticipado contra malware.

Durante cada arranque posterior, se miden los mismos componentes, lo que permite comparar las medidas con una línea base esperada. Para más seguridad, los valores medidos por el TPM se pueden firmar y transmitir a un servidor remoto, que puede realizar la comparación. Este proceso, denominado atestación de estado de dispositivo remoto, permite al servidor comprobar el estado de mantenimiento del dispositivo Windows.

Aunque el arranque seguro es una forma proactiva de protección, la atestación de estado es una forma reactiva de protección de arranque. La atestación de estado se distribuye deshabilitada en Windows y está habilitada por un antimalware o un proveedor de MDM. A diferencia de Arranque seguro, la atestación de estado no detiene el proceso de arranque y entra en la corrección cuando una medida no funciona. Sin embargo, con el control de acceso condicional, la atestación de estado ayudará a evitar el acceso a recursos de alto valor.

Seguridad de virtualización

La seguridad basada en virtualización proporciona un nuevo límite de confianza para Windows y usa la tecnología de hipervisor de Hyper-V para mejorar la seguridad de la plataforma. La seguridad basada en virtualización proporciona un entorno de ejecución seguro para ejecutar código de confianza (trustlet) específico de Windows y proteger datos confidenciales.

La seguridad basada en virtualización ayuda a protegerse frente a un kernel en peligro o a un usuario malintencionado con privilegios de administrador. La seguridad basada en virtualización no está intentando proteger contra un atacante físico.

Los siguientes servicios de Windows están protegidos con seguridad basada en virtualización:

Credential Guard (aislamiento de credenciales LSA): evita los ataques de paso a hash y el robo de credenciales empresariales que se producen mediante la lectura y el volcado del contenido de la memoria lsass.
Device Guard (integridad de código de Hyper-V): Device Guard usa la nueva seguridad basada en virtualización en Windows para aislar el servicio de integridad de código del propio kernel de Windows, lo que permite al servicio usar firmas definidas por la directiva controlada por la empresa para ayudar a determinar lo que es de confianza. De hecho, el servicio integridad de código se ejecuta junto con el kernel en un contenedor protegido con hipervisor de Windows.
Otros servicios aislados: por ejemplo, en Windows Server 2016, existe la característica vTPM que permite tener máquinas virtuales cifradas (VM) en servidores.

Nota

La seguridad basada en virtualización solo está disponible con enterprise edition. La seguridad basada en virtualización requiere dispositivos con UEFI (2.3.1 o posterior) con arranque seguro habilitado, procesador x64 con extensiones de virtualización y SLAT habilitado. IOMMU, TPM 2.0. y la compatibilidad con la memoria segura sobrescrita son opcionales, pero se recomiendan.

El esquema siguiente es una vista de alto nivel de Windows con seguridad basada en virtualización.

figura 5.

Credential Guard

En Windows, cuando Credential Guard está habilitado, el servicio de subsistema de autoridad de seguridad local (lsass.exe) ejecuta un código confidencial en un modo de usuario aislado para ayudar a proteger los datos de malware que se pueden ejecutar en el modo de usuario normal. Esta ejecución de código ayuda a garantizar que los datos protegidos no se roben y se reutilicen en máquinas remotas, lo que mitiga muchos ataques de estilo PtH.

Credential Guard ayuda a proteger las credenciales cifrándolas con una clave por arranque o persistente:

La clave por arranque se usa para las credenciales en memoria que no requieren persistencia. Un ejemplo de dicha credencial sería una clave de sesión de vale de concesión de vales (TGT). Esta clave se negocia con un Centro de distribución de claves (KDC) cada vez que se produce la autenticación y se protege con una clave por arranque.
La clave persistente, o algún derivado, se usa para ayudar a proteger los elementos almacenados y recargados después de un reinicio. Esta protección está pensada para el almacenamiento a largo plazo y debe protegerse con una clave coherente. Credential Guard se activa mediante una clave del Registro y, a continuación, se habilita mediante una variable UEFI. Esta activación se realiza para protegerse frente a modificaciones remotas de la configuración. El uso de una variable UEFI implica que se requiere acceso físico para cambiar la configuración. Cuando lsass.exe detecta que el aislamiento de credenciales está habilitado, genera LsaIso.exe como un proceso aislado, lo que garantiza que se ejecuta en modo de usuario aislado. El inicio de LsaIso.exe se realiza antes de la inicialización de un proveedor de soporte técnico de seguridad, lo que garantiza que las rutinas de soporte técnico del modo seguro estén listas antes de que comience cualquier autenticación.

Device Guard

Device Guard es una característica de Windows Enterprise que permite a las organizaciones bloquear un dispositivo para ayudar a protegerlo de la ejecución de software que no es de confianza. En esta configuración, las únicas aplicaciones que se pueden ejecutar son aquellas aplicaciones de confianza para la organización.

La decisión de confianza para ejecutar código se realiza mediante la integridad de código de Hyper-V, que se ejecuta en la seguridad basada en virtualización, un contenedor protegido de Hyper-V que se ejecuta junto con Windows normal.

La integridad de código de Hyper-V es una característica que valida la integridad de un archivo de controlador o sistema cada vez que se carga en la memoria. La integridad del código detecta si se está cargando un archivo de sistema o controlador sin firmar en el kernel o si un archivo del sistema ha sido modificado por software malintencionado que está siendo ejecutado por una cuenta de usuario con privilegios de administrador. En las versiones basadas en x64 de Windows, los controladores en modo kernel deben estar firmados digitalmente.

Nota

Independientemente de la activación de la directiva de Device Guard, los controladores de Windows deben estar firmados por Microsoft y, más concretamente, por el portal WHQL (Windows Hardware Quality Labs). Además, a partir de octubre de 2015, el portal de WHQL solo aceptará envíos de controladores, incluidos envíos de controladores de modo kernel y de usuario, que tengan un certificado de firma de código de validación extendida ("EV") válido.

Con Device Guard, las organizaciones ahora pueden definir su propia directiva de integridad de código para su uso en sistemas x64 que ejecutan Windows Enterprise. Las organizaciones tienen la capacidad de configurar la directiva que determina qué es de confianza para ejecutarse. Estos incluyen controladores y archivos del sistema, y scripts y aplicaciones de escritorio tradicionales. A continuación, el sistema se bloquea para ejecutar solo las aplicaciones en las que confía la organización.

Device Guard es una característica integrada de Windows Enterprise que impide la ejecución de código y aplicaciones no deseados. Device Guard se puede configurar mediante dos acciones de regla: permitir y denegar:

Permitir limita la ejecución de aplicaciones a una lista permitida de código o editor de confianza y bloquea todo lo demás.
Denegar completa el enfoque permitir publicador de confianza bloqueando la ejecución de una aplicación específica.

En el momento de escribir este artículo, y según la última investigación de Microsoft, más del 90 % del malware no está firmado por completo. Por lo tanto, implementar una directiva básica de Device Guard puede ayudar de forma sencilla y eficaz a bloquear el malware. De hecho, Device Guard tiene el potencial de ir más allá y también puede ayudar a bloquear el malware firmado.

Device Guard debe planearse y configurarse para que sea realmente eficaz. No es solo una protección habilitada o deshabilitada. Device Guard es una combinación de características de seguridad de hardware y características de seguridad de software que, cuando se configuran juntos, pueden bloquear un equipo para ayudar a garantizar el sistema más seguro y resistente posible.

Hay tres partes diferentes que componen la solución Device Guard en Windows:

La primera parte es un conjunto base de características de seguridad de hardware introducidas con la versión anterior de Windows. TPM para operaciones criptográficas de hardware y UEFI con firmware moderno, junto con Arranque seguro, le permite controlar lo que el dispositivo se ejecuta cuando se inician los sistemas.
Después de la característica de seguridad de hardware, está el motor de integridad de código. En Windows, la integridad del código ahora es totalmente configurable y ahora reside en modo de usuario aislado, una parte de la memoria protegida por la seguridad basada en virtualización.
La última parte de Device Guard es la capacidad de administración. La configuración de integridad de código se expone a través de objetos de directiva de grupo específicos, cmdlets de PowerShell y proveedores de servicios de configuración de MDM (CSP).

Para obtener más información sobre cómo implementar Device Guard en una empresa, consulte la guía de implementación de Device Guard.

Escenarios de Device Guard

Como se describió anteriormente, Device Guard es una manera eficaz de bloquear los sistemas. Device Guard no está pensado para usarse ampliamente y puede que no siempre sea aplicable, pero hay algunos escenarios de alto interés.

Device Guard es útil y aplicable en sistemas de cargas de trabajo fijas, como cajas registradoras, máquinas de quiosco, estaciones de trabajo de Administración seguras (SAW) o escritorios bien administrados. Device Guard es muy relevante en sistemas que tienen un software bien definido que se espera que se ejecute y no cambien con demasiada frecuencia. También podría ayudar a proteger los trabajadores de la información (IW) más allá de solo las SAW, siempre y cuando se conozca lo que necesitan ejecutar y el conjunto de aplicaciones no vaya a cambiar diariamente.

Las SAW son equipos creados para ayudar a reducir significativamente el riesgo de riesgo de malware, ataques de phishing, sitios web falsos y ataques ptH, entre otros riesgos de seguridad. Aunque las SAW no se pueden considerar una solución de seguridad de "bala de plata" para estos ataques, estos tipos de clientes son útiles como parte de un enfoque de seguridad en capas y en profundidad de defensa.

Para proteger los recursos de alto valor, los SAW se usan para realizar conexiones seguras a esos recursos.

De forma similar, en estaciones de trabajo corporativas totalmente administradas, donde las aplicaciones se instalan mediante una herramienta de distribución como Microsoft Configuration Manager, Intune o cualquier administración de dispositivos de terceros, device Guard es aplicable. En ese tipo de escenario, la organización tiene una buena idea del software que está ejecutando un usuario promedio.

Podría ser difícil usar Device Guard en estaciones de trabajo corporativas y ligeramente administradas en las que el usuario normalmente puede instalar software por sí mismo. Cuando una organización ofrece una gran flexibilidad, es difícil ejecutar Device Guard en modo de cumplimiento. Sin embargo, Device Guard se puede ejecutar en modo auditoría y, en ese caso, el registro de eventos contendrá un registro de los archivos binarios que infringió la directiva de Device Guard. Cuando se usa Device Guard en el modo auditoría, las organizaciones pueden obtener datos completos sobre los controladores y las aplicaciones que los usuarios instalan y ejecutan.

Para poder beneficiarse de la protección incluida en Device Guard, la directiva de integridad de código debe crearse mediante herramientas proporcionadas por Microsoft, pero la directiva se puede implementar con herramientas de administración comunes, como directiva de grupo. La directiva de integridad de código es un documento XML codificado en binario que incluye opciones de configuración para los modos usuario y kernel de Windows, junto con restricciones en los hosts de script de Windows. La directiva de integridad de código de Device Guard restringe qué código se puede ejecutar en un dispositivo.

Nota

La directiva de Device Guard se puede firmar en Windows, lo que agrega protección adicional contra los usuarios administrativos que cambian o quitan esta directiva.

La directiva de Device Guard firmada ofrece una mayor protección contra un administrador local malintencionado que intenta derrotar a Device Guard.

Cuando se firma la directiva, el GUID de la directiva se almacena en una variable segura previa al sistema operativo UEFI que ofrece protección contra alteraciones. La única manera de actualizar la directiva de Device Guard más adelante es proporcionar una nueva versión de la directiva firmada por el mismo firmante o desde un firmante especificado como parte de la directiva de Device Guard en la sección UpdateSigner.

La importancia de firmar aplicaciones

En equipos con Device Guard, Microsoft propone moverse desde un mundo en el que las aplicaciones sin firmar se pueden ejecutar sin restricciones a un mundo en el que solo se permite ejecutar código firmado y de confianza en Windows.

Con Windows, las organizaciones harán que las aplicaciones de línea de negocio (LOB) estén disponibles para los miembros de la organización a través de la infraestructura de Microsoft Store. Más concretamente, las aplicaciones LOB estarán disponibles en una tienda privada dentro de la Microsoft Store pública. Microsoft Store firma y distribuye aplicaciones universales de Windows y aplicaciones clásicas de Windows. Todas las aplicaciones descargadas de Microsoft Store están firmadas.

En las organizaciones de hoy en día, muchas aplicaciones LOB no están firmadas. La firma de código suele considerarse un problema difícil de resolver por varias razones, como la falta de experiencia en la firma de código. Incluso si la firma de código es un procedimiento recomendado, muchas aplicaciones internas no están firmadas.

Windows incluye herramientas que permiten a los profesionales de TI tomar aplicaciones que ya se han empaquetado y ejecutarlas a través de un proceso para crear más firmas que se puedan distribuir junto con las aplicaciones existentes.

¿Por qué siguen siendo necesarias las soluciones de administración de dispositivos y antimalware?

Aunque los mecanismos allowlist son eficaces para garantizar que solo se puedan ejecutar aplicaciones de confianza, no pueden evitar el peligro de una aplicación de confianza (pero vulnerable) por contenido malintencionado diseñado para aprovechar una vulnerabilidad conocida. Device Guard no protege contra el código malintencionado en modo de usuario que se ejecuta aprovechando las vulnerabilidades.

Las vulnerabilidades son debilidades en el software que podrían permitir que un atacante ponga en peligro la integridad, la disponibilidad o la confidencialidad del dispositivo. Algunas de las peores vulnerabilidades permiten a los atacantes aprovechar el dispositivo en peligro haciendo que ejecute código malintencionado sin el conocimiento del usuario.

Es habitual que los atacantes distribuyan contenido especialmente diseñado para intentar aprovechar vulnerabilidades conocidas en el software en modo de usuario, como exploradores web (y sus complementos), máquinas virtuales Java, lectores PDF o editores de documentos. A partir de hoy, el 90 % de las vulnerabilidades detectadas afectan a las aplicaciones en modo de usuario en comparación con los controladores de modo kernel y sistema operativo que las hospedan.

Para combatir estas amenazas, la aplicación de revisiones es el control más eficaz, ya que el software antimalware forma capas complementarias de defensa.

La mayoría del software de la aplicación no tiene ninguna facilidad para actualizarse, por lo que incluso si el proveedor de software publica una actualización que corrige la vulnerabilidad, es posible que el usuario no sepa que la actualización está disponible o cómo obtenerla y, por lo tanto, sigue siendo vulnerable a ataques. Las organizaciones todavía necesitan administrar dispositivos y aplicar revisiones a las vulnerabilidades.

Las soluciones MDM se están convirtiendo en una tecnología de administración de dispositivos ligeros. Windows amplía las funcionalidades de administración que están disponibles para los MDM. Una característica clave que Microsoft ha agregado a Windows es la posibilidad de que los MDM adquieran una declaración segura del estado del dispositivo de los dispositivos administrados y registrados.

Certificación de estado del dispositivo

La atestación de estado del dispositivo usa el TPM para proporcionar medidas criptográficamente seguras y verificables de la cadena de software que se usa para arrancar el dispositivo.

En el caso de los dispositivos basados en Windows, Microsoft presenta una nueva API pública que permitirá que el software MDM acceda a un servicio de atestación remota denominado Servicio de atestación de estado de Windows. Un resultado de atestación de estado, además de otros elementos, se puede usar para permitir o denegar el acceso a redes, aplicaciones o servicios, en función de si los dispositivos demuestran ser correctos.

Para obtener más información sobre la atestación de estado del dispositivo, consulte la sección Detectar un dispositivo basado en Windows incorrecto .

Requisitos de licencia y de la edición de Windows

En la tabla siguiente se enumeran las ediciones de Windows que admiten el servicio de atestación de estado del dispositivo:

Windows Pro	Windows Enterprise	Windows Pro Education/SE	Windows Education
Sí	Sí	Sí	Sí

Los derechos de licencia del servicio de atestación de estado del dispositivo se conceden mediante las siguientes licencias:

Windows Pro/Pro Education/SE	Windows Enterprise E3	Windows Enterprise E5	Windows Education A3	Windows Education A5
Sí	Sí	Sí	Sí	Sí

Se puede obtener más información sobre las licencias de Windows en Información general sobre las licencias de Windows.

Requisitos de hardware

En la tabla siguiente se detallan los requisitos de hardware para los servicios de seguridad basados en virtualización y la característica de atestación de estado. Para obtener más información, consulte Requisitos mínimos de hardware.

Hardware	Motivación
Firmware UEFI 2.3.1 o posterior con arranque seguro habilitado	Necesario para admitir el arranque seguro de UEFI. El arranque seguro de UEFI garantiza que el dispositivo arranque solo el código autorizado. Además, se debe admitir la integridad de arranque (arranque seguro de la plataforma) siguiendo los requisitos de Especificación de compatibilidad de hardware para sistemas para Windows en la subsección : "System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby"
Las extensiones de virtualización, como Intel VT-x, AMD-V y SLAT, deben estar habilitadas	Necesario para admitir la seguridad basada en virtualización. Nota: Device Guard se puede habilitar sin usar la seguridad basada en virtualización.
Procesador X64	Necesario para admitir la seguridad basada en virtualización que usa el hipervisor de Windows. Hyper-V solo se admite en el procesador x64 (y no en x86). La protección de acceso directo a memoria (DMA) se puede habilitar para proporcionar protección de memoria adicional, pero requiere que los procesadores incluyan tecnologías de protección DMA.
IOMMU, como Intel VT-d, AMD-Vi	La compatibilidad con IOMMU en Windows mejora la resistencia del sistema frente a ataques DMA.
Módulo de plataforma segura (TPM)	Necesario para admitir la atestación de estado y necesario para otras protecciones clave para la seguridad basada en virtualización. Se admite TPM 2.0. Se agregó compatibilidad con TPM 1.2 a partir de Windows 10, versión 1607 (RS1)

En esta sección se presentó información sobre varios controles estrechamente relacionados en Windows . Las defensas de varias capas y el enfoque detallado ayudan a erradicar el malware de bajo nivel durante la secuencia de arranque. La seguridad basada en virtualización es un cambio fundamental de la arquitectura del sistema operativo que agrega un nuevo límite de seguridad. Device Guard y Credential Guard, respectivamente, ayudan a bloquear el código que no es de confianza y a proteger las credenciales de dominio corporativo contra el robo y la reutilización. En esta sección también se ha analizado brevemente la importancia de administrar dispositivos y aplicar revisiones a las vulnerabilidades. Todas estas tecnologías se pueden usar para proteger y bloquear dispositivos, a la vez que se limita el riesgo de que los atacantes los ponga en peligro.

Detección de un dispositivo basado en Windows incorrecto

A partir de hoy, muchas organizaciones solo consideran que los dispositivos son compatibles con la directiva de la empresa después de haber pasado varias comprobaciones que muestran, por ejemplo, que el sistema operativo está en el estado correcto, configurado correctamente y tiene habilitada la protección de seguridad. Desafortunadamente, con los sistemas actuales, esta forma de generación de informes no es totalmente confiable porque el malware puede suplantar una declaración de software sobre el estado del sistema. Un rootkit, o una vulnerabilidad de seguridad de bajo nivel similar, puede notificar un estado incorrecto falso a las herramientas de cumplimiento tradicionales.

El mayor desafío con los rootkits es que pueden ser indetectables para el cliente. Dado que comienzan antes de antimalware y tienen privilegios de nivel de sistema, pueden disfrazarse completamente mientras continúan teniendo acceso a los recursos del sistema. Como resultado, los equipos tradicionales infectados con rootkits parecen estar en buen estado, incluso con antimalware en ejecución.

Como se ha explicado anteriormente, la característica de atestación de estado de Windows usa el componente de hardware tpm para registrar de forma segura una medida de todos los componentes relacionados con el arranque, incluidos el firmware, el kernel de Windows e incluso los controladores de arranque temprano. Dado que la atestación de estado usa las funcionalidades de seguridad basadas en hardware de TPM, el registro de todos los componentes medidos de arranque permanece fuera del alcance de cualquier malware.

Después de que los dispositivos atestiguan un estado de arranque de confianza, pueden demostrar que no ejecutan malware de bajo nivel que podría suplantar comprobaciones de cumplimiento posteriores. La atestación de estado basada en TPM proporciona un anclaje confiable de confianza para los recursos que contienen datos de alto valor.

¿Cuál es el concepto de estado del dispositivo?

Para comprender el concepto de estado del dispositivo, es importante conocer las medidas tradicionales que los profesionales de TI han tomado para evitar la vulneración de malware. Las tecnologías de control de malware están muy centradas en la prevención de la instalación y distribución.

Sin embargo, el uso de tecnologías tradicionales de prevención de malware, como antimalware o soluciones de aplicación de revisiones, aporta un nuevo conjunto de problemas para los profesionales de TI: la capacidad de supervisar y controlar el cumplimiento de los dispositivos que acceden a los recursos de la organización.

La definición de cumplimiento de dispositivos variará en función del antimalware instalado de una organización, la configuración del dispositivo, la línea base de administración de revisiones y otros requisitos de seguridad. Pero el estado del dispositivo forma parte de la directiva de cumplimiento general del dispositivo.

El estado del dispositivo no es binario y depende de la implementación de seguridad de la organización. El servicio de atestación de estado proporciona información a la MDM sobre qué características de seguridad están habilitadas durante el arranque del dispositivo mediante TPM de hardware de confianza.

Pero la atestación de estado solo proporciona información, por lo que se necesita una solución MDM para tomar y aplicar una decisión.

Atestación de estado del dispositivo remoto

En Windows, la atestación de estado hace referencia a una característica en la que los datos de arranque medido generados durante el proceso de arranque se envían a un servicio de atestación de estado de dispositivo remoto operado por Microsoft.

Este enfoque es el más seguro disponible para que los dispositivos basados en Windows detecten cuándo están inactivas las defensas de seguridad. Durante el proceso de arranque, el registro tcg y los valores de los PCR se envían a un servicio en la nube remoto de Microsoft. Después, el servicio de atestación de estado comprueba los registros para determinar qué cambios se han producido en el dispositivo.

Un usuario de confianza como una MDM puede inspeccionar el informe generado por el servicio de atestación de estado remoto.

Nota

Para usar la característica de atestación de estado de Windows, el dispositivo debe estar equipado con un TPM discreto o de firmware. No hay ninguna restricción en ninguna edición determinada de Windows.

Windows admite escenarios de atestación de estado al permitir que las aplicaciones accedan al proveedor de servicios de configuración de atestación de estado (CSP) subyacente para que las aplicaciones puedan solicitar un token de atestación de estado. Un antimalware o un agente MDM pueden comprobar localmente la medición de la secuencia de arranque en cualquier momento.

La atestación de estado del dispositivo remoto combinada con una MDM proporciona un método con raíz de hardware para notificar el estado de seguridad actual y detectar cualquier cambio, sin tener que confiar en el software que se ejecuta en el sistema.

En el caso de que se ejecute código malintencionado en el dispositivo, se requiere el uso de un servidor remoto. Si un rootkit está presente en el dispositivo, el antimalware ya no es confiable y su comportamiento puede ser secuestrado por un código malintencionado que se ejecuta al principio de la secuencia de inicio. Esta razón es lo que hace que sea importante usar Arranque seguro y Device Guard para controlar qué código se carga durante la secuencia de arranque.

El software antimalware puede buscar para determinar si la secuencia de arranque contiene signos de malware, como un rootkit. También puede enviar el registro tcg y los PCR a un servidor de atestación de estado remoto para proporcionar una separación entre el componente de medida y el componente de verificación.

La atestación de estado registra las medidas en varios registros de configuración de plataforma tpm (PCR) y TCG durante el proceso de arranque.

figura 6.

Al iniciar un dispositivo equipado con TPM, se realiza una medición de distintos componentes. Estos componentes incluyen firmware, controladores UEFI, microcódigo de CPU y también todos los controladores de Windows cuyo tipo es Inicio de arranque. Las medidas sin procesar se almacenan en los registros de PCR de TPM, mientras que los detalles de todos los eventos (ruta de acceso ejecutable, certificación de entidad, etc.) están disponibles en el registro de TCG.

figura 7.

El proceso de atestación de estado funciona de la siguiente manera:

Se miden los componentes de arranque de hardware.
Se miden los componentes de arranque del sistema operativo.
Si Device Guard está habilitado, se mide la directiva de Device Guard actual.
Se mide el kernel de Windows.
El software antivirus se inicia como el primer controlador de modo kernel.
Se miden los controladores de inicio de arranque.
El servidor MDM a través del agente MDM emite un comando de comprobación de estado mediante el CSP de atestación de estado.
Las medidas de arranque las valida el servicio de atestación de estado.

Nota

De forma predeterminada, los últimos 100 registros de arranque del sistema y todos los registros de reanudación asociados se archivan en la carpeta %SystemRoot%\logs\measuredboot. El número de registros retenidos se puede establecer con el registro REG_DWORD valor PlatformLogRetention en la clave HKLM\SYSTEM\CurrentControlSet\Services\TPM . Un valor de 0 desactivará el archivo de registro y un valor de 0xffffffff conservará todos los registros.

En el proceso siguiente se describe cómo se envían las medidas de arranque de mantenimiento al servicio de atestación de estado:

El cliente (un dispositivo basado en Windows con TPM) inicia la solicitud con el servicio de atestación de estado del dispositivo remoto. Dado que se espera que el servidor de atestación de estado sea un servicio en la nube de Microsoft, el URI ya está aprovisionado previamente en el cliente.
A continuación, el cliente envía el registro TCG, los datos firmados de AIK (valores PCR, contador de arranque) y la información del certificado AIK.
A continuación, el servicio de atestación remota de la salud del dispositivo:
1. Comprueba que el certificado AIK lo emite una ENTIDAD de certificación conocida y de confianza y que el certificado es válido y no revocado.
2. Comprueba que la firma en las comillas PCR es correcta y coherente con el valor del registro TCG.
3. Analiza las propiedades en el registro tcg.
4. Emite el token de estado del dispositivo que contiene la información de estado, la información de AIK y la información del contador de arranque. El token de estado también contiene un tiempo de emisión válido. El token de estado del dispositivo está cifrado y firmado, lo que significa que la información está protegida y solo es accesible para emitir el servicio de atestación de estado.
El cliente almacena el blob cifrado de estado en su almacén local. El token de estado del dispositivo contiene el estado de mantenimiento del dispositivo, un identificador de dispositivo (el AIK de Windows ) y el contador de arranque.

figura 8.

Componentes de atestación de estado del dispositivo

La solución de atestación de estado del dispositivo implica diferentes componentes que son TPM, CSP de atestación de estado y el servicio de atestación de estado de Windows. Estos componentes se describen en esta sección.

Módulo de plataforma segura

En esta sección se describe cómo se usan los PCR (que contienen datos de configuración del sistema), la clave de aprobación (EK) (que actúan como tarjeta de identidad para TPM), SRK (que protegen las claves) y las AIK (que pueden notificar el estado de la plataforma) para los informes de atestación de estado.

De forma simplificada, el TPM es un componente pasivo con recursos limitados. Puede calcular números aleatorios, claves RSA, descifrar datos cortos, almacenar hashes tomados al arrancar el dispositivo.

Un TPM incorpora en un único componente:

Un generador de claves rsa de 2048 bits
Un generador de números aleatorios
Memoria no volátil para almacenar claves EK, SRK y AIK
Un motor criptográfico para cifrar, descifrar y firmar
Memoria volátil para almacenar los PCR y las claves RSA

Clave de aprobación

El TPM tiene una clave criptográfica única insertada denominada clave de aprobación. La clave de aprobación de TPM es un par de claves asimétricas (tamaño RSA de 2048 bits).

La clave pública de la clave de aprobación se usa para enviar parámetros confidenciales de forma segura, como al tomar posesión del TPM que contiene el hash de definición de la contraseña del propietario. La clave privada EK se usa al crear claves secundarias como AIK.

La clave de aprobación actúa como una tarjeta de identidad para el TPM. Para obtener más información, consulte Descripción de la clave de aprobación de TPM.

La clave de aprobación suele ir acompañada de uno o dos certificados digitales:

Un certificado lo genera el fabricante del TPM y se denomina certificado de aprobación. El certificado de aprobación se usa para demostrar la autenticidad del TPM (por ejemplo, que es un TPM real fabricado por un fabricante de chip específico) para procesos locales, aplicaciones o servicios en la nube. El certificado de aprobación se crea durante la fabricación o la primera vez que se inicializa el TPM mediante la comunicación con un servicio en línea.
El otro certificado lo genera el generador de plataformas y se denomina certificado de plataforma para indicar que un TPM específico está integrado con un dispositivo determinado. Para determinados dispositivos que usan TPM basado en firmware generado por Intel o Qualcomm, el certificado de aprobación se crea cuando el TPM se inicializa durante el OOBE de Windows.

Nota

Arranque seguro protege la plataforma hasta que se carga el kernel de Windows. A continuación, las protecciones como Arranque de confianza, Integridad de código de Hyper-V y ELAM toman el control. Un dispositivo que usa TPM de Intel o TPM qualcomm obtiene un certificado firmado en línea del fabricante que ha creado el chip y, a continuación, almacena el certificado firmado en el almacenamiento de TPM. Para que la operación se realice correctamente, si está filtrando el acceso a Internet desde los dispositivos cliente, debe autorizar las siguientes direcciones URL:

Para TPM de firmware intel: https://ekop.intel.com/ekcertservice
Para tpm de firmware qualcomm: https://ekcert.spserv.microsoft.com/

Claves de identidad de atestación

Dado que el certificado de aprobación es único para cada dispositivo y no cambia, el uso del mismo puede presentar problemas de privacidad porque teóricamente es posible realizar un seguimiento de un dispositivo específico. Para evitar este problema de privacidad, Windows emite un delimitador de atestación derivado en función del certificado de aprobación. Esta clave intermedia, que se puede dar fe de una clave de aprobación, es la clave de identidad de atestación (AIK) y el certificado correspondiente se denomina certificado AIK. Este certificado AIK lo emite un servicio en la nube de Microsoft.

Nota

Para que el dispositivo pueda notificar su estado mediante las funciones de atestación de TPM, se debe aprovisionar un certificado AIK junto con un servicio de terceros, como el servicio de CA en la nube de Microsoft. Una vez aprovisionada, la clave privada AIK se puede usar para notificar la configuración de la plataforma. Windows crea una firma sobre el estado del registro de la plataforma (y un valor de contador monotónico) en cada arranque mediante el AIK.

El AIK es un par de claves asimétricas (pública/privada) que se usa como sustituto del EK como identidad del TPM con fines de privacidad. La parte privada de un AIK nunca se revela ni se usa fuera del TPM y solo se puede usar dentro del TPM para un conjunto limitado de operaciones. Además, solo se puede usar para firmar y solo para operaciones limitadas definidas por TPM.

Windows crea AIK protegidos por el TPM, si están disponibles, que son claves de firma RSA de 2048 bits. Microsoft hospeda un servicio en la nube llamado Microsoft Cloud CA para establecer criptográficamente que se comunica con un TPM real y que el TPM posee el AIK presentado. Una vez que el servicio de CA en la nube de Microsoft haya establecido estos hechos, emitirá un certificado AIK al dispositivo basado en Windows.

Muchos dispositivos existentes que se actualizarán a Windows 10 no tendrán un TPM o el TPM no contendrá un certificado de aprobación. Para dar cabida a esos dispositivos, Windows 10 permite la emisión de certificados AIK sin la presencia de un certificado de aprobación. Estos certificados AIK no los emite Microsoft Cloud CA. Estos certificados no son tan confiables como un certificado de aprobación que se quema en el dispositivo durante la fabricación, pero proporcionará compatibilidad para escenarios avanzados como Windows Hello para empresas sin TPM.

En el certificado AIK emitido, se agrega un OID especial para atestiguar que se usó el certificado de aprobación durante el proceso de atestación. Esta información la puede usar un usuario de confianza para decidir si se rechazan los dispositivos que se atestiguan mediante certificados AIK sin un certificado de aprobación o si se aceptan. Otro escenario puede ser no permitir el acceso a recursos de alto valor desde dispositivos atestiguados por un certificado AIK que no esté respaldado por un certificado de aprobación.

Clave raíz de almacenamiento

La clave raíz de almacenamiento (SRK) también es un par de claves asimétricas (RSA con un mínimo de 2048 bits de longitud). SRK tiene un rol importante y se usa para proteger las claves de TPM, de modo que estas claves no se puedan usar sin el TPM. La clave SRK se crea cuando se toma la propiedad del TPM.

Registros de configuración de plataforma

El TPM contiene un conjunto de registros diseñados para proporcionar una representación criptográfica del software y el estado del sistema que ha arrancado. Estos registros se denominan registros de configuración de plataforma (PCR).

La medida de la secuencia de arranque se basa en el registro PCR y TCG. Para establecer una raíz estática de confianza, cuando el dispositivo se inicia, el dispositivo debe poder medir el código de firmware antes de la ejecución. En este caso, la raíz principal de confianza para la medición (CRTM) se ejecuta desde el arranque, calcula el hash del firmware y, a continuación, lo almacena expandiendo el PCR de registro[0] y transfiere la ejecución al firmware.

Los PCR se establecen en cero cuando se inicia la plataforma y es el trabajo del firmware el que inicia la plataforma para medir los componentes de la cadena de arranque y registrar las medidas en los PCR. Normalmente, los componentes de arranque toman el hash del siguiente componente que se va a ejecutar y registran las medidas en los PCR. El componente inicial que inicia la cadena de medición es de confianza implícita. Este componente es CRTM. Los fabricantes de plataformas deben tener un proceso de actualización seguro para CRTM o no permitir actualizaciones en él. Los PCR registran un hash acumulativo de los componentes que se han medido.

El valor de un PCR por sí solo es difícil de interpretar (es solo un valor hash), pero las plataformas suelen mantener un registro con detalles de lo que se ha medido y los PCR simplemente garantizan que el registro no se ha alterado. Los registros se conocen como registro TCG. Cada vez que se extiende un PCR de registro, se agrega una entrada al registro tcg. Por lo tanto, a lo largo del proceso de arranque, se crea un seguimiento del código ejecutable y los datos de configuración en el registro de TCG.

Aprovisionamiento de TPM

Para que el TPM de un dispositivo basado en Windows sea utilizable, primero debe aprovisionarse. El proceso de aprovisionamiento difiere en función de las versiones de TPM, pero, cuando se ejecuta correctamente, da lugar a que el TPM se pueda usar y que los datos de autorización del propietario (ownerAuth) del TPM se almacenen localmente en el registro.

Cuando se aprovisione el TPM, Windows intentará primero determinar los valores EK y localmente almacenados ownerAuth ; para ello, busque en el Registro en la siguiente ubicación: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement

Durante el proceso de aprovisionamiento, es posible que sea necesario reiniciar el dispositivo.

El cmdlet de PowerShell Get-TpmEndorsementKeyInfo se puede usar con privilegios administrativos para obtener información sobre la clave de aprobación y los certificados del TPM.

Si no se conoce la propiedad de TPM pero existe el EK, la biblioteca cliente aprovisionará el TPM y almacenará el valor de ownerAuth resultante en el registro si la directiva lo permite almacenará la parte pública de SRK en la siguiente ubicación: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Administración\SRKPub

Como parte del proceso de aprovisionamiento, Windows creará un AIK con tpm. Cuando se realiza esta operación, la parte pública de AIK resultante se almacena en el Registro en la siguiente ubicación: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\WindowsAIKPub

Nota

Para aprovisionar certificados AIK y filtrar el acceso a Internet, debe autorizar la siguiente dirección URL con caracteres comodín: https://\*.microsoftaik.azure.net

CSP de atestación de Windows Health

Windows contiene un proveedor de servicios de configuración (CSP) especializado para interactuar con la característica de atestación de estado. Un CSP es un componente que se conecta al cliente MDM de Windows y proporciona un protocolo publicado para cómo los servidores MDM pueden configurar la configuración y administrar dispositivos basados en Windows. El protocolo de administración se representa como una estructura de árbol que se puede especificar como URI con funciones para realizar en los URI, como "get", "set", "delete", etc.

La lista siguiente es la de las funciones realizadas por el CSP de atestación de estado de Windows:

Recopila los datos que se usan para comprobar el estado de mantenimiento de un dispositivo.
Reenvía los datos al servicio de atestación de estado
Aprovisiona el certificado de atestación de estado que recibe del servicio de atestación de estado.
Tras la solicitud, reenvía el certificado de atestación de estado (recibido del servicio de atestación de estado) y la información de tiempo de ejecución relacionada al servidor MDM para su comprobación.

Durante una sesión de atestación de estado, el CSP de atestación de estado reenvía los registros tcg y los valores de los PCR que se miden durante el arranque, mediante un canal de comunicación seguro al servicio de atestación de estado.

Cuando un servidor MDM valida que un dispositivo ha atestiguado el servicio de atestación de estado, se le proporcionará un conjunto de instrucciones y notificaciones sobre cómo se ha arrancado ese dispositivo, con la garantía de que el dispositivo no se ha reiniciado entre el momento en que atestigua su estado y la hora en que el servidor MDM lo validó.

Servicio de atestación de estado de Windows

El rol del servicio de atestación de mantenimiento de Windows es esencialmente evaluar un conjunto de datos de mantenimiento (valores de registro TCG y PCR), realizar una serie de detecciones (en función de los datos de estado disponibles) y generar blobs de estado cifrados o generar informes en servidores MDM.

Nota

Los servidores de dispositivos y MDM deben tener acceso a has.spserv.microsoft.com mediante el protocolo TCP en el puerto 443 (HTTPS).

La comprobación de que una atestación de TPM y el registro asociado son válidos realiza varios pasos:

En primer lugar, el servidor debe comprobar que los informes están firmados por AIK de confianza. Esta comprobación puede realizarse comprobando que la parte pública del AIK aparece en una base de datos de recursos, o quizás que se ha comprobado un certificado.
Una vez activada la clave, se debe comprobar la atestación firmada (una estructura de comillas) para ver si es una firma válida sobre los valores de PCR.
A continuación, se deben comprobar los registros para asegurarse de que coinciden con los valores de PCR notificados.
Por último, una solución MDM debe examinar los propios registros para ver si representan configuraciones de seguridad conocidas o válidas. Por ejemplo, una comprobación sencilla podría ser ver si se sabe que los componentes del sistema operativo inicial medidos son buenos, que el controlador ELAM es el esperado y que el archivo de directiva de controladores ELAM está actualizado. Si todas estas comprobaciones se realizan correctamente, se puede emitir una instrucción de atestación que se puede usar más adelante para determinar si se debe conceder o no acceso al cliente a un recurso.

El servicio de atestación de estado proporciona la siguiente información a una solución MDM sobre el estado del dispositivo:

Habilitación de arranque seguro
Habilitación de depuración de kernel y arranque
Habilitación de BitLocker
VSM habilitado
Medida de directiva de integridad de código de Device Guard firmada o sin firmar
ELAM cargado
Arranque en modo seguro, habilitación de DEP, habilitación de firma de prueba
El TPM del dispositivo se ha aprovisionado con un certificado de aprobación de confianza.

Para obtener información completa de las medidas, consulte Health Attestation CSP(CSP de atestación de estado).

En la lista siguiente se muestran algunos elementos clave que se pueden devolver a MDM para dispositivos basados en Windows:

Medición de PCR0
Arranque seguro habilitado
La base de datos de arranque seguro coincide con la esperada
Secure Boot dbx está actualizado
El GUID de la directiva de arranque seguro coincide con el esperado
BitLocker habilitado
Seguridad basada en virtualización habilitada
SE cargó ELAM
La versión de integridad de código está actualizada
Coincidencias de hash de directivas de integridad de código esperadas

Uso de MDM y el servicio de atestación de estado

Para que el estado del dispositivo sea relevante, la solución MDM evalúa el informe de estado del dispositivo y se configura según los requisitos de estado del dispositivo de la organización.

Una solución que usa MDM y el servicio de atestación de estado consta de tres partes principales:

Un dispositivo con la atestación de estado habilitada. Esta habilitación se realizará como parte de la inscripción con un proveedor de MDM (la atestación de estado se deshabilitará de forma predeterminada).
Una vez habilitado este servicio y cada arranque posterior, el dispositivo enviará medidas de estado al servicio de atestación de estado hospedado por Microsoft y recibirá un blob de atestación de estado a cambio.
En cualquier momento después de este ciclo, un servidor MDM puede solicitar el blob de atestación de estado del dispositivo y pedir al servicio de atestación de estado que descifre el contenido y valide que se ha atestiguado.

La interacción entre un dispositivo basado en Windows, el servicio de atestación de estado y MDM se puede realizar de la siguiente manera:

El cliente inicia una sesión con el servidor MDM. El URI del servidor MDM formaría parte de la aplicación cliente que inicia la solicitud. En este momento, el servidor MDM podría solicitar los datos de atestación de estado mediante el URI de CSP adecuado.
El servidor MDM especifica un nonce junto con la solicitud.
A continuación, el cliente envía el nonce entre comillas de AIK + el contador de arranque y la información del blob de estado. Este blob de estado se cifra con una clave pública del servicio de atestación de estado que solo el servicio de atestación de estado puede descifrar.
El servidor MDM:
1. Comprueba que el valor de nonce es el esperado.
2. Pasa los datos entre comillas, el nonce y el blob de estado cifrado al servidor del servicio de atestación de estado.
El servicio de atestación de estado:
1. Descifra el blob de estado.
2. Comprueba que el contador de arranque de la comilla es correcto mediante el AIK en el blob de estado y coincide con el valor del blob de estado.
3. Comprueba que el valor de nonce coincide con la cita y la que se pasa desde MDM.
4. Dado que el contador de arranque y el nonce se citan con el AIK del blob de estado, también demuestra que el dispositivo es el mismo que el para el que se ha generado el blob de estado.
5. Devuelve datos al servidor MDM, incluidos los parámetros de estado, la actualización, etc.

Nota

El servidor MDM (usuario de confianza) nunca realiza la validación del contador de comillas o arranque. Obtiene los datos entre comillas y el blob de estado (que está cifrado) y envía los datos al servicio de atestación de estado para su validación. De este modo, el AIK nunca es visible para la MDM, lo que soluciona los problemas de privacidad.

Establecer los requisitos para el cumplimiento de dispositivos es el primer paso para asegurarse de que los dispositivos registrados que no cumplen los requisitos de mantenimiento y cumplimiento se detectan, realizan un seguimiento y tienen acciones aplicadas por la solución MDM.

Los dispositivos que intentan conectarse a los recursos deben evaluar su estado para que se puedan detectar y notificar dispositivos incorrectos y no conformes. Para ser totalmente eficaz, una solución de seguridad de un extremo a otro debe imponer una consecuencia para los dispositivos incorrectos, como denegar el acceso a recursos de alto valor. Esa consecuencia para un dispositivo incorrecto es el propósito del control de acceso condicional, que se detalla en la sección siguiente.

Controlar la seguridad de un dispositivo basado en Windows antes de conceder acceso

La tecnología de control de acceso de hoy en día, en la mayoría de los casos, se centra en garantizar que las personas adecuadas obtengan acceso a los recursos adecuados. Si los usuarios pueden autenticarse, obtienen acceso a los recursos mediante un dispositivo que el personal y los sistemas de TI de la organización conocen poco. Quizás haya alguna comprobación, como asegurarse de que un dispositivo está cifrado antes de dar acceso al correo electrónico, pero ¿qué ocurre si el dispositivo está infectado con malware?

El proceso de atestación de estado del dispositivo remoto usa datos de arranque medidos para comprobar el estado de mantenimiento del dispositivo. A continuación, el estado del dispositivo está disponible para una solución MDM como Intune.

Nota

Para obtener la información más reciente sobre la compatibilidad con las características de Intune y Windows, consulta Novedades de Microsoft Intune.

En la ilustración siguiente se muestra cómo se espera que el servicio de atestación de estado funcione con el servicio MDM Intune basado en la nube de Microsoft.

figura 10.

A continuación, una solución MDM puede usar instrucciones de estado de mantenimiento y llevarlas al siguiente nivel mediante el acoplamiento con directivas de cliente que permitirán conceder acceso condicional en función de la capacidad del dispositivo para demostrar que está libre de malware, su sistema antimalware es funcional y actualizado, el firewall se está ejecutando y el estado de revisión de los dispositivos es compatible.

Por último, los recursos se pueden proteger denegando el acceso a los puntos de conexión que no pueden demostrar que están en buen estado. Esta característica es muy necesaria para los dispositivos BYOD que necesitan acceder a los recursos de la organización.

Compatibilidad integrada con MDM en Windows

Windows tiene un cliente MDM que se incluye como parte del sistema operativo. Este cliente MDM permite a los servidores MDM administrar dispositivos basados en Windows sin necesidad de un agente independiente.

Compatibilidad con servidores MDM que no son de Microsoft

Los servidores MDM que no son de Microsoft pueden administrar Windows mediante el protocolo MDM. El cliente de administración integrado puede comunicarse con un servidor compatible que admita el protocolo OMA-DM para realizar tareas de administración empresarial. Para obtener más información, consulte Microsoft Entra integración con MDM.

Nota

Los servidores MDM no necesitan crear ni descargar un cliente para administrar Windows. Para obtener más información, consulte Administración de dispositivos móviles.

El servidor MDM de terceros tendrá la misma experiencia de usuario de terceros coherente para la inscripción, lo que también proporciona simplicidad a los usuarios de Windows.

Administración de Windows Defender por MDM de terceros

Esta infraestructura de administración permite a los profesionales de TI usar productos compatibles con MDM como Intune, administrar la atestación de estado, Device Guard o Windows Defender en dispositivos basados en Windows, incluidos los BYOD que no están unidos a un dominio. Los profesionales de TI podrán administrar y configurar todas las acciones y configuraciones que están familiarizados con la personalización mediante Intune con Intune Endpoint Protection en sistemas operativos de nivel inferior. A los administradores que actualmente solo administran dispositivos unidos a un dominio a través de directiva de grupo les resultará fácil realizar la transición a la administración de dispositivos basados en Windows mediante MDM, ya que muchas de las configuraciones y acciones se comparten entre ambos mecanismos.

Para obtener más información sobre cómo administrar la seguridad de Windows y la configuración del sistema con una solución MDM, consulte Configuración de URI personalizada para dispositivos Windows.

Control de acceso condicional

En la mayoría de las plataformas, el registro de dispositivos Microsoft Entra se produce automáticamente durante la inscripción. La solución MDM escribe los estados del dispositivo en Microsoft Entra ID y, a continuación, los lee Office 365 (o cualquier aplicación de Windows autorizada que interactúe con Microsoft Entra ID) la próxima vez que el cliente intente acceder a una carga de trabajo compatible con Office 365.

Si el dispositivo no está registrado, el usuario recibirá un mensaje con instrucciones sobre cómo registrarse (también conocido como inscripción). Si el dispositivo no es compatible, el usuario recibirá un mensaje diferente que le redirigirá al portal web de MDM, donde podrá obtener más información sobre el problema de cumplimiento y cómo resolverlo.

Microsoft Entra ID autentica al usuario y al dispositivo, MDM administra las directivas de cumplimiento y acceso condicional, y el Servicio de atestación de estado informa sobre el estado del dispositivo de forma atestiguada.

figura 11.

Office 365 control de acceso condicional

Microsoft Entra ID aplica directivas de acceso condicional para proteger el acceso a Office 365 servicios. Un administrador de inquilinos puede crear una directiva de acceso condicional que impida que un usuario de un dispositivo no compatible acceda a un servicio de Office 365. El usuario debe cumplir las directivas de dispositivo de la empresa antes de que se pueda conceder acceso al servicio. Como alternativa, el administrador también puede crear una directiva que requiera que los usuarios solo inscriban sus dispositivos para obtener acceso a un servicio de Office 365. Las directivas se pueden aplicar a todos los usuarios de una organización o limitarse a algunos grupos de destino y mejorarse con el tiempo para incluir más grupos de destino.

Cuando un usuario solicita acceso a un servicio de Office 365 desde una plataforma de dispositivos compatible, Microsoft Entra autentica al usuario y al dispositivo desde el que el usuario inicia la solicitud; y concede acceso al servicio solo cuando el usuario se ajusta a la directiva establecida para el servicio. A los usuarios que no tienen su dispositivo inscrito se les proporcionan instrucciones de corrección sobre cómo inscribirse y ser conformes para acceder a los servicios de Office 365 corporativos.

Cuando un usuario se inscribe, el dispositivo se registra con Microsoft Entra ID y se inscribe con una solución MDM compatible como Intune.

Nota

Microsoft está trabajando con ISV MDM de terceros para admitir la inscripción de MDM automatizada y las comprobaciones de acceso basadas en directivas. Los pasos para activar la inscripción de MDM automática con Microsoft Entra ID y Intune se explican en la entrada de blog Windows, Microsoft Entra ID And Microsoft Intune: Automatic MDM Enrollment Powered By The Cloud!

Cuando un usuario inscribe un dispositivo correctamente, el dispositivo se convierte en de confianza. Microsoft Entra ID proporciona inicio de sesión único para acceder a las aplicaciones de la empresa y aplica la directiva de acceso condicional para conceder acceso a un servicio no solo la primera vez que el usuario solicita acceso, sino cada vez que el usuario solicita renovar el acceso.

Al usuario se le denegará el acceso a los servicios cuando se cambien las credenciales de inicio de sesión, se pierda o se robe un dispositivo o no se cumpla la directiva de cumplimiento en el momento de la solicitud de renovación.

En función del tipo de aplicación de correo electrónico que los empleados usan para acceder a Exchange Online, la ruta de acceso para establecer el acceso protegido al correo electrónico puede ser ligeramente diferente. Sin embargo, los componentes clave: Microsoft Entra ID, Office 365/Exchange Online y Intune son los mismos. La experiencia de TI y la experiencia del usuario final también son similares.

figura 12.

Los clientes que intenten acceder a Office 365 se evaluarán para las siguientes propiedades:

¿El dispositivo está administrado por una MDM?
¿El dispositivo está registrado con Microsoft Entra ID?
¿El dispositivo es compatible?

Para llegar a un estado compatible, el dispositivo basado en Windows debe:

Inscríbase con una solución MDM.
Regístrese con Microsoft Entra ID.
Sea compatible con las directivas de dispositivo establecidas por la solución MDM.

Nota

En la actualidad, las directivas de acceso condicional se aplican de forma selectiva a los usuarios en dispositivos iOS y Android. Para obtener más información, consulte la entrada de blog Microsoft Entra ID, Microsoft Intune y Windows: Uso de la nube para modernizar la movilidad empresarial.

Control de acceso condicional de aplicaciones locales y en la nube

El control de acceso condicional es un potente motor de evaluación de directivas integrado en Microsoft Entra ID. Proporciona a los profesionales de TI una manera sencilla de crear reglas de acceso más allá de Office 365 que evalúan el contexto del inicio de sesión de un usuario para tomar decisiones en tiempo real sobre las aplicaciones a las que deben tener acceso.

Los profesionales de TI pueden configurar directivas de control de acceso condicional para aplicaciones SaaS en la nube protegidas por Microsoft Entra ID e incluso aplicaciones locales. Las reglas de acceso de Microsoft Entra ID usan el motor de acceso condicional para comprobar el estado de cumplimiento y el estado de cumplimiento del dispositivo notificados por una solución MDM compatible como Intune con el fin de determinar si se va a permitir el acceso.

Para obtener más información sobre el acceso condicional, consulte Versión preliminar de Access condicional de Azure para aplicaciones SaaS.

Nota

El control de acceso condicional es una característica Microsoft Entra ID P1 o P2 que también está disponible con EMS. Si no tiene una suscripción Microsoft Entra ID P1 o P2, puede obtener una prueba desde el sitio de Microsoft Azure.

En el caso de las aplicaciones locales, hay dos opciones para habilitar el control de acceso condicional en función del estado de cumplimiento de un dispositivo:

En el caso de las aplicaciones locales que se publican a través de Microsoft Entra proxy de aplicación, puede configurar directivas de control de acceso condicional como lo haría para las aplicaciones en la nube. Para obtener más información, consulte Uso de Microsoft Entra proxy de aplicación para publicar aplicaciones locales para usuarios remotos.
Además, Microsoft Entra Connect sincronizará la información de cumplimiento de dispositivos de Microsoft Entra ID a AD local. ADFS en Windows Server 2016 admitirá el control de acceso condicional en función del estado de cumplimiento de un dispositivo. Los profesionales de TI configurarán directivas de control de acceso condicional en ADFS que usan el estado de cumplimiento del dispositivo notificado por una solución MDM compatible para proteger las aplicaciones locales.

figura 13.

En el proceso siguiente se describe cómo funciona Microsoft Entra acceso condicional:

El usuario ya se ha inscrito con MDM a través de Workplace Access/unión a Azure AD, que registra el dispositivo con Microsoft Entra ID.
Cuando el dispositivo se inicia o reanuda desde la hibernación, se desencadena una tarea "Tpm-HASCertRetr" para solicitar en segundo plano un blob de atestación de estado. El dispositivo envía las medidas de arranque de TPM al servicio de atestación de estado.
Health Attestation Service valida el estado del dispositivo y emite un blob cifrado en el dispositivo en función del estado de mantenimiento con detalles sobre las comprobaciones erróneas (si las hay).
El usuario inicia sesión y el agente MDM se pone en contacto con el servidor Intune/MDM.
El servidor MDM inserta nuevas directivas si está disponible y consulta el estado del blob de estado y otro estado de inventario.
El dispositivo envía un blob de atestación de estado adquirido anteriormente y también el valor del otro inventario de estado solicitado por el servidor Intune/MDM.
Intune/servidor MDM envía el blob de atestación de estado al servicio de atestación de estado para que se valide.
Health Attestation Service valida que el dispositivo que envió el blob de atestación de estado está en buen estado y devuelve este resultado al servidor Intune/MDM.
Intune/servidor MDM evalúa el cumplimiento en función del cumplimiento y del estado de atestación de estado o inventario consultado del dispositivo.
el servidor Intune/MDM actualiza el estado de cumplimiento del objeto de dispositivo en Microsoft Entra ID.
El usuario abre la aplicación e intenta acceder a un recurso administrado corporativo.
Acceso privado por notificación de cumplimiento en Microsoft Entra ID.
Si el dispositivo es compatible y el usuario está autorizado, se genera un token de acceso.
El usuario puede acceder al recurso administrado corporativo.

Para obtener más información sobre Microsoft Entra unirse, vea Microsoft Entra ID & Windows: Better Together for Work or School, a white paper.

El control de acceso condicional es un tema que es posible que muchas organizaciones y profesionales de TI no conozcan y que deberían. Los distintos atributos que describen un usuario, un dispositivo, el cumplimiento y el contexto de acceso son eficaces cuando se usan con un motor de acceso condicional. El control de acceso condicional es un paso esencial que ayuda a las organizaciones a proteger su entorno.

Conclusiones y resumen

La lista siguiente contiene puntos importantes de alto nivel para mejorar la posición de seguridad de cualquier organización. Sin embargo, los pocos objetos para llevar presentados en esta sección no deben interpretarse como una lista exhaustiva de los procedimientos recomendados de seguridad.

Comprender que ninguna solución es 100 % segura

Si los adversarios determinados con intención malintencionada obtienen acceso físico al dispositivo, podrían romper sus capas de seguridad y controlarlo.
Uso de la atestación de estado con una solución MDM

Los dispositivos que intentan conectarse a recursos de alto valor deben evaluar su estado para que los dispositivos incorrectos y no conformes puedan detectarse, notificarse y bloquearse finalmente.
Uso de Credential Guard

Credential Guard es una característica que ayuda en gran medida a proteger las credenciales de dominio corporativo frente a ataques de paso a hash.
Usar Device Guard

Device Guard es un avance real en la seguridad y una manera eficaz de ayudar a protegerse contra el malware. La característica Device Guard de Windows bloquea aplicaciones que no son de confianza (aplicaciones no autorizadas por su organización).
Firmar directiva de Device Guard

La directiva de Device Guard firmada ayuda a proteger contra un usuario con privilegios de administrador que intenta derrotar a la directiva actual. Cuando se firma una directiva, la única manera de modificar Device Guard más adelante es proporcionar una nueva versión de la directiva firmada por el mismo firmante o desde un firmante que especifique como parte de la directiva de Device Guard.
Uso de la seguridad basada en virtualización

Cuando tiene la integridad del código en modo kernel protegida por la seguridad basada en virtualización, las reglas de integridad de código se siguen aplicando incluso si una vulnerabilidad permite el acceso no autorizado a la memoria del modo kernel. Tenga en cuenta que los dispositivos de Device Guard que ejecutan la integridad del código del kernel con seguridad basada en virtualización deben tener controladores compatibles.
Inicio de la implementación de Device Guard con el modo auditoría

Implemente la directiva de Device Guard en equipos y dispositivos de destino en modo auditoría. Supervise el registro de eventos de integridad de código que indica que se habría bloqueado un programa o un controlador si Device Guard se configurara en modo de cumplimiento. Ajuste las reglas de Device Guard hasta que se alcance un alto nivel de confianza. Una vez completada la fase de prueba, la directiva de Device Guard se puede cambiar al modo de cumplimiento.
Compilación de una máquina de referencia aislada al implementar Device Guard

Dado que la red corporativa puede contener malware, debe empezar a configurar un entorno de referencia que esté aislado de la red corporativa principal. Después, puede crear una directiva de integridad de código que incluya las aplicaciones de confianza que desea ejecutar en los dispositivos protegidos.
Uso de AppLocker cuando tenga sentido

Aunque AppLocker no se considera una nueva característica de Device Guard, complementa la funcionalidad de Device Guard para algunos escenarios, como la posibilidad de denegar una aplicación universal específica de Windows para un usuario específico o un grupo de usuarios.
Bloqueo del firmware y la configuración

Una vez instalado Windows, bloquee el acceso a las opciones de arranque del firmware. Este bloqueo impide que un usuario con acceso físico modifique la configuración de UEFI, deshabilite el arranque seguro o arranque de otros sistemas operativos. Además, para protegerse frente a un administrador que intenta deshabilitar Device Guard, agregue una regla en la directiva de Device Guard actual que denegará y bloqueará la ejecución de la herramienta C:\Windows\System32\SecConfig.efi .

La atestación de estado es una característica clave de Windows que incluye componentes de cliente y nube para controlar el acceso a recursos de alto valor en función de un usuario y la identidad de su dispositivo y el cumplimiento de la directiva de gobernanza corporativa. Las organizaciones pueden elegir detectar y notificar dispositivos incorrectos, o configurar reglas de cumplimiento de estado en función de sus necesidades. La atestación de estado proporciona un modelo de seguridad de un extremo a otro y puntos de integración, que los proveedores y desarrolladores de software pueden usar para compilar e integrar una solución personalizada.

Controlar el estado de los dispositivos Windows

Introducción

Descripción de una solución de seguridad de un extremo a otro sólida

Un enfoque diferente

Inversiones de seguridad de Microsoft en Windows

Proteger, controlar e informar sobre el estado de seguridad de los dispositivos basados en Windows

Protección de dispositivos y credenciales empresariales frente a amenazas

Defensas de seguridad basadas en hardware de Windows

Seguridad de virtualización

Credential Guard

Device Guard

Escenarios de Device Guard

La importancia de firmar aplicaciones

¿Por qué siguen siendo necesarias las soluciones de administración de dispositivos y antimalware?

Certificación de estado del dispositivo

Requisitos de licencia y de la edición de Windows

Requisitos de hardware

Detección de un dispositivo basado en Windows incorrecto

¿Cuál es el concepto de estado del dispositivo?

Atestación de estado del dispositivo remoto

Componentes de atestación de estado del dispositivo

Módulo de plataforma segura

Clave de aprobación

Claves de identidad de atestación

Clave raíz de almacenamiento

Registros de configuración de plataforma

Aprovisionamiento de TPM

CSP de atestación de Windows Health

Servicio de atestación de estado de Windows

Uso de MDM y el servicio de atestación de estado

Controlar la seguridad de un dispositivo basado en Windows antes de conceder acceso

Compatibilidad integrada con MDM en Windows

Compatibilidad con servidores MDM que no son de Microsoft

Administración de Windows Defender por MDM de terceros

Control de acceso condicional

Office 365 control de acceso condicional

Control de acceso condicional de aplicaciones locales y en la nube

Conclusiones y resumen

Temas relacionados

Comentarios

Comentarios

Recursos adicionales