Seguridad basada en virtualización (VBS)
La seguridad basada en virtualización, o VBS, usa la virtualización de hardware y el hipervisor de Windows para crear un entorno virtual aislado que se convierta en la raíz de confianza del sistema operativo que supone que el kernel se puede poner en peligro. Windows usa este entorno aislado para hospedar una serie de soluciones de seguridad, proporcionándoles una mayor protección frente a vulnerabilidades en el sistema operativo y evitando el uso de vulnerabilidades malintencionadas que intentan derrotar las protecciones. VBS aplica restricciones para proteger los recursos vitales del sistema operativo y del sistema operativo, o para proteger los recursos de seguridad, como las credenciales de usuario autenticadas.
Una solución de seguridad de ejemplo es la integridad de memoria, que protege y protege Windows mediante la ejecución de la integridad de código del modo kernel dentro del entorno virtual aislado de VBS. La integridad del código del modo kernel es el proceso de Windows que comprueba todos los archivos binarios y controladores de modo kernel antes de iniciarlos y evita que los controladores o archivos del sistema no firmados o que no sean de confianza se carguen en la memoria del sistema. La integridad de la memoria también restringe las asignaciones de memoria del kernel que podrían usarse para poner en peligro el sistema, lo que garantiza que las páginas de memoria del kernel solo se realicen ejecutables después de pasar comprobaciones de integridad de código dentro del entorno de tiempo de ejecución seguro y las páginas ejecutables nunca se puedan escribir. De este modo, incluso si hay vulnerabilidades como un desbordamiento de búfer que permiten al malware intentar modificar la memoria, no se pueden modificar las páginas de códigos ejecutables y no se puede hacer ejecutable la memoria modificada.
Nota
La integridad de la memoria se conoce a veces como integridad de código protegida por hipervisor (HVCI) o hipervisor que se aplicaba a la integridad de código y se publicó originalmente como parte de Device Guard. Device Guard ya no se usa excepto para localizar la integridad de memoria y la configuración de VBS en directiva de grupo o en el Registro de Windows.
VBS requiere que los siguientes componentes estén presentes y configurados correctamente.
Tenga en cuenta que TPM no es un requisito obligatorio, pero se recomienda encarecidamente implementar TPM.
Requisito de hardware | Detalles |
---|---|
CPU de 64 bits | La seguridad basada en virtualización (VBS) requiere el hipervisor de Windows, que solo se admite en procesadores ia de 64 bits con extensiones de virtualización, incluido Intel VT-X y AMD-v. |
Traducción de direcciones de segundo nivel (SLAT) | VBS también requiere que la compatibilidad con la virtualización del procesador incluya traducción de direcciones de segundo nivel (SLAT), ya sea Intel VT-X2 con tablas de páginas extendidas (EPT) o AMD-v con indexación de virtualización rápida (RVI). |
IOMMU o SMMUs (Intel VT-D, AMD-Vi, Arm64 SMMUs) | Todos los dispositivos de E/S capaces de DMA deben estar detrás de una IOMMU o SMMU. Se puede usar una IOMMU para mejorar la resistencia del sistema frente a ataques de memoria. |
Módulo de plataforma segura (TPM) 2.0 | Los TPM, ya sea discretos o firmware, serán suficientes. Para obtener más información, consulte Módulo de plataforma segura (TPM) 2.0. |
Compatibilidad de firmware con la protección SMM | El firmware del sistema debe cumplir las recomendaciones para proteger el código SMM descrito en la especificación de tabla de mitigaciones de seguridad (WMST) de Windows SMM. La especificación WSMT contiene detalles de una tabla ACPI que se creó para su uso con sistemas operativos Windows que admiten características de VBS. El firmware debe implementar las protecciones descritas en la especificación WSMT y establecer las marcas de protección correspondientes como se describe en la especificación para notificar el cumplimiento de estos requisitos al sistema operativo. |
Informes de memoria de unified Extensible Firmware Interface (UEFI) | El firmware UEFI debe cumplir las siguientes directrices de asignación de memoria y formato de asignación de memoria para que el firmware garantice la compatibilidad con VBS.
|
Revisión 2 de solicitud de sobrescritura de memoria segura (MOR) | Secure MOR v2 se ha mejorado para proteger la configuración de bloqueo MOR mediante una variable segura UEFI. Esto ayuda a protegerse contra ataques avanzados de memoria. Para más información, consulte Implementación de MOR segura. |
Controladores compatibles con la integridad de memoria | Asegúrese de que todos los controladores del sistema se han probado y comprobado que son compatibles con la integridad de la memoria. El Kit de controladores de Windows y el Comprobador de controladores contienen pruebas de compatibilidad de controladores con integridad de memoria. Hay tres pasos para comprobar la compatibilidad del controlador:
|
VBS funciona en máquinas virtuales que tienen compatibilidad con la virtualización anidada. Esto incluye todas las máquinas virtuales gen2 y las máquinas virtuales de Gen1 que admiten la virtualización anidada. En la tabla siguiente se detalla una lista de las series de máquinas virtuales admitidas.
Nombre de la serie de máquinas virtuales | Virtualización anidada | Generación de máquinas virtuales |
---|---|---|
Av2 | Sí | 1 (ciertos tamaños internos admiten gen 2) |
B | No | 1 y 2 |
Dsv2/Dv2/Dv3/Ev3 | Sí | 1 |
Dsv3/Ddsv3 | Sí | 1 y 2 |
Dsv4/Ddsv4 | Sí | 1 y 2 |
Esv3/Edsv3 | Sí | 1 y 2 |
Esv4/Edsv4 | Sí | 1 y 2 |
Ev4/Edv4 | Sí | Ev4 - 1 solo Edv4 -1&2 |
Dv4/Ddv4 | Sí | 1 y 2 |
Dv5/Ddv5/Dsv5/Ddsv5 | Sí | 1 y 2 |
Ev5/Edv5/Esv5/Edsv5 | Sí | 1 y 2 |
Dasv5/Dadsv5/Easv5/ Eadsv5 | Sí | 1 y 2 |
Ebsv5/Edbsv5 | Sí | 1 y 2 |
Fsv2 | Sí | 1 y 2 |
Fx | Sí | 2 |
Lsv2 | Sí | 1 y 2 |
Temas relacionados
Para obtener más información sobre Hyper-V, consulta Hyper-V en Windows Server 2016 o Introducción a Hyper-V en Windows 10. Para obtener más información sobre el hipervisor, consulta Especificaciones del hipervisor.