Guía de planeamiento de máquinas virtuales blindadas y tejido protegido para proveedores de servicios de hosting

• Se aplica a:

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

En este tema se tratan las decisiones de planeamiento que se deben tomar para habilitar las máquinas virtuales blindadas para que se ejecuten en su tejido. Tanto si se actualiza un tejido de Hyper-V existente como si se crea un tejido, la ejecución de máquinas virtuales blindadas consta de dos componentes principales:

• El Servicio de protección de host (HGS) proporciona atestación y protección de claves para que pueda asegurarse de que las máquinas virtuales blindadas solo se ejecutarán en hosts de Hyper-V aprobados y en buen estado. 
• Los hosts de Hyper-V aprobados y en buen estado en los que se pueden ejecutar máquinas virtuales blindadas (y máquinas virtuales normales) se conocen como hosts protegidos.

Decisión 1: nivel de confianza en el tejido

La forma de implementar el Servicio de protección de host y los hosts de Hyper-V protegidos dependerá principalmente del grado de confianza que desee lograr en el tejido. El grado de confianza se rige por el modo de atestación. Hay dos opciones mutuamente excluyentes:

1. Atestación de confianza de TPM

   Si su objetivo es ayudar a proteger las máquinas virtuales de administradores malintencionados o de un tejido en peligro, deberá usar la atestación de confianza de TPM. Esta opción funciona bien para escenarios de hospedaje multiinquilino, así como para recursos de alto valor en entornos empresariales, como controladores de dominio o servidores de contenido como SQL o SharePoint. Se miden directivas de integridad de código protegidas por hipervisor (HVCI) se miden y HGS aplica su validez antes de que se permita que el host ejecutar máquinas virtuales blindadas.

2. Atestación de clave de host

   Si los requisitos están controlados principalmente por un cumplimiento que requiere que las máquinas virtuales se cifren tanto en reposo como en actividad, debe usar la atestación de clave de host. Esta opción funciona bien en aquellos centros de datos de uso general en los que no haya problemas por el hecho de que los administradores de tejido y host de Hyper-V tengan acceso a los sistemas operativos invitados de las máquinas virtuales para el mantenimiento y las operaciones diarias.

   En este modo, el administrador del tejido es el único responsable de garantizar el estado de los hosts de Hyper-V. Como HGS no participa en absoluto en la decisión de lo que se permite ejecutar, tanto el malware como los depuradores funcionarán para lo que se han diseñado.

   Sin embargo, los depuradores que intenten asociarse directamente a un proceso (como WinDbg.exe), se bloquean con las máquinas virtuales blindadas, ya que el proceso de trabajo de la máquina virtual (VMWP.exe) es un indicador de proceso protegido (PPL). Otras técnicas de depuración alternativas, como las que usa LiveKd.exe, no están bloqueadas. A diferencia de las máquinas virtuales blindadas, el proceso de trabajo de las máquinas virtuales compatibles con el cifrado no se ejecuta como un PPL, por lo que los depuradores tradicionales como WinDbg.exe seguirán funcionando con normalidad.

   Un modo de atestación similar denominado Atestación de confianza de administrador (que se basa en Active Directory) está en desuso a partir de Windows Server 2019.

El nivel de confianza que elija determinará los requisitos de hardware para los hosts de Hyper-V, así como las directivas que se aplican en el tejido. Si es necesario, puede implementar el tejido protegido mediante la atestación de confianza de administrador y del hardware existente y su posterior conversión en atestación de confianza de TPM cuando se haya actualizado el hardware y sea preciso reforzar la seguridad del tejido.

Decisión 2: tejido de Hyper-V existente frente a un nuevo tejido de Hyper-V independiente

Si tiene un tejido existente (Hyper-V o cualquier otro), es muy probable que pueda usarlo para ejecutar máquinas virtuales blindadas, junto con máquinas virtuales normales. Algunos clientes eligen integrar máquinas virtuales blindadas en sus herramientas y tejidos existentes, mientras que otros separan el tejido por motivos empresariales.

Planeamiento de los administradores de HGS para el Servicio de protección de host

Implemente el Servicio de protección de host (HGS) en un entorno muy seguro, ya sea en un servidor físico dedicado, una máquina virtual blindada, una máquina virtual que se encuentre en un host de Hyper-V aislado (separado del tejido que protege) o uno separado lógicamente mediante una suscripción de Azure diferente.

Área	Detalles
Requisitos de instalación	Un servidor (clúster de tres nodos recomendado para alta disponibilidad) Para la reserva, se requieren al menos dos servidores de HGS. Estos servidores pueden ser virtuales o físicos (se recomienda un servidor físico con TPM 2.0; también se admite TPM 1.2) La instalación de Server Core de Windows Server 2016 R2, o cualquier versión posterior Línea de visión de la red al tejido que permite HTTP o la configuración de reserva Certificado HTTPS recomendado para la validación de acceso
Ajuste de tamaño	Cada nodo de servidor HGS de tamaño medio (8 núcleos/4 GB) puede administrar 1000 hosts de Hyper-V.
Administración	Designe personas específicas para administrar HGS. Deben ser independientes de los administradores del tejido. Para la comparación, los clústeres de HGS se pueden considerar de la misma forma que una entidad de certificación (CA) en términos de aislamiento administrativo, implementación física y nivel general de confidencialidad de la seguridad.
Active Directory en Servicio de protección de host	De forma predeterminada, HGS instala su propio Active Directory interno para la administración. Se trata de un bosque autocontenido y autoadministrado, y es la configuración recomendada para ayudar a aislar HGS del tejido. Si ya tiene un bosque de Active Directory con privilegios elevados que usa para el aislamiento, puede utilizarlo, en lugar del bosque predeterminado de HGS. Es importante que HGS no esté replicado en un dominio del mismo bosque que los hosts de Hyper-V o las herramientas de administración de tejido. Si lo hace, podría permitir que un administrador de tejido obtenga control sobre HGS.
Recuperación ante desastres	Hay tres opciones: Instale un clúster de HGS independiente en cada centro de datos y autorice que las máquinas virtuales blindadas se ejecuten tanto en los centros de datos principales como en los centros de datos de copia de seguridad. Así se evita la necesidad de ampliar el clúster en una WAN y le permite aislar las máquinas virtuales, con el fin de que solo se ejecuten en el sitio designado para ellas. Instale HGS en un clúster extendido entre dos (o más) centros de datos. Esto proporciona resistencia si la WAN deja de funcionar, pero amenaza los límites de la agrupación de clústeres de conmutación por error. Las cargas de trabajo no se pueden aislar en un solo sitio; una máquina virtual autorizada para ejecutarse en un sitio puede ejecutarse en cualquier otro. Registre el host de Hyper-V con otro HGS como conmutación por error. También debería realizar una copia de seguridad de cada HGS mediante la exportación su configuración para que siempre se puedan recuperar localmente. Para más información, consulte Export-HgsServerState e Import-HgsServerState.
Claves de Servicio de protección de host	Un Servicio de protección de host usa dos pares de claves asimétricas (una clave de cifrado y una clave de firma) cada una representada por un certificado SSL. Hay dos opciones para generar estas claves: Entidad de certificación interna: puede generar estas claves mediante la infraestructura de PKI interna. Esta opción es apropiada para entornos de centro de datos. Entidades de certificación de confianza pública: use un conjunto de claves obtenidas de una entidad de certificación de confianza pública. Esta es la opción que los proveedores de servicios de hosting deben usar. Tenga en cuenta que aunque es posible usar certificados autofirmados, no se recomiendan para escenarios de implementación que no sean laboratorios de prueba de concepto. Además de tener claves HGS, los proveedores de servicios de hosting "Bring Your Own Key", donde los inquilinos pueden proporcionar sus propias claves para que algunos inquilinos (o todos) puedan tener su propia clave de HGS específica. Esta opción es adecuada para los proveedores de servicios de hosting que pueden proporcionar un proceso fuera de banda para que los inquilinos carguen sus claves.
Almacenamiento de claves de Servicio de protección de host	Para obtener la mayor seguridad posible, se recomienda crear y almacenar las claves de HGS exclusivamente en un módulo de seguridad de hardware (HSM). Si no se usa HSM, se recomienda encarecidamente aplicar BitLocker en los servidores de HGS.

Planeamiento del administrador de tejido para hosts protegidos

Área	Detalles
Hardware	Atestación de clave de host: puede usar cualquier hardware existente como host protegido. Hay algunas excepciones (para asegurarse de que el host puede usar nuevos mecanismos de seguridad a partir de Windows Server 2016, consulte Hardware compatible con la protección de la integridad del código basada en virtualización de Windows Server 2016. Atestación de confianza de TPM: puede usar cualquier hardware que tenga la calificación adicional de control de hardware siempre que esté configurado adecuadamente (consulte Configuraciones de servidor compatibles con máquinas virtuales blindadas y protección basada en virtualización de la integridad del código para la configuración específica). Esto incluye TPM 2.0 y tanto la versión 2.3.1c de UEFI como las posteriores.
SO	Se recomienda usar la opción Server Core para el sistema operativo del host de Hyper-V.
Implicaciones de rendimiento	En función de las pruebas de rendimiento, se prevé una diferencia de densidad aproximada del 5 % entre ejecutar máquinas virtuales blindadas y máquinas virtuales no blindadas, lo que significa que si un host de Hyper-V determinado puede ejecutar 20 máquinas virtuales no blindadas, se espera que pueda ejecutar 19 máquinas virtuales blindadas. Asegúrese de comprobar el ajuste de tamaño con las cargas de trabajo típicas. Por ejemplo, puede haber algunos valores atípicos con cargas de trabajo de E/S intensivas orientadas a la escritura que afectarán aún más a la diferencia de densidad.
Consideraciones sobre la sucursal	A partir de la versión 1709 de Windows Server se puede especificar una dirección URL de reserva para un servidor HGS virtualizado que se ejecute localmente como una máquina virtual blindada en la sucursal. La dirección URL de reserva se puede usar cuando la sucursal pierda la conectividad con los servidores de HGS del centro de datos. En las versiones anteriores de Windows Server, un host de Hyper-V que se ejecuta en una sucursal necesita conectividad con el Servicio de protección de host para encender o migrar máquinas virtuales blindadas en vivo. Para más información, consulte Consideraciones sobre las sucursales.