Planificación de la atestación del Servicio de protección de host
Se aplica a: 
SQL Server 2019 (15.x) y versiones posteriores: solo Windows
La atestación es un flujo de trabajo que permite a una aplicación cliente verificar que se comunica con un enclave de confianza dentro del proceso de SQL Server cuando se usa Always Encrypted con enclaves seguros.
En SQL Server, Always Encrypted con enclaves seguros usa enclaves de seguridad basados en virtualización (VBS) (también conocidos como enclaves de modo seguro virtual o VSM), una tecnología basada en software que se apoya en el hipervisor de Windows y no requiere ningún hardware especial. La atestación de un enclave VBS implica verificar que tanto el código dentro del enclave es válido como que el equipo que aloja SQL Server es de confianza. La atestación logra este objetivo mediante la introducción de un tercero que puede validar la identidad (y, opcionalmente, la configuración) del equipo con SQL Server. Antes de que SQL Server pueda usar un enclave para ejecutar una consulta, debe proporcionar información al servicio de atestación sobre su entorno operativo para obtener un certificado de mantenimiento. Este certificado de mantenimiento se envía al cliente, que puede comprobar de forma independiente su autenticidad con el servicio de atestación. Una vez que el cliente confía en el certificado de mantenimiento, sabe que está hablando con un enclave de VBS de confianza y emitirá la consulta que usará dicho enclave.
La atestación es fundamental para detectar algunos ataques de administradores de SO malintencionados, por ejemplo, ataques que implican la manipulación de la biblioteca de SQL Server que se ejecuta dentro del enclave. Si no le preocupan este tipo de ataques (por ejemplo, si usa Always Encrypted con enclaves seguros en un entorno que no es de producción), consulte Planear Always Encrypted con enclaves seguros en SQL Server sin atestación.
El rol de Servicio de protección de host (HGS) en Windows Server 2019 o posterior proporciona capacidades de atestación remota para Always Encrypted con enclaves de VBS. Este artículo es una guía sobre las decisiones y los requisitos previos a la implementación a fin de usar Always Encrypted con los enclaves de VBS y la atestación de HGS.
Nota:
Cuando SQL Server se implementa en una máquina virtual, los enclaves SBV ayudan a proteger sus datos de ataques dentro de la máquina virtual. Sin embargo, no proporcionan ninguna protección contra los ataques que usan cuentas privilegiadas del sistema que se originan en el host. Por ejemplo, un volcado de memoria de la máquina virtual generado en el equipo host puede contener la memoria del enclave.
Información general sobre la arquitectura
El Servicio de protección de host (HGS) es un servicio web en clúster que se ejecuta en Windows Server 2019 o posterior. En una implementación típica, habrá de 1 a 3 servidores HGS, al menos un equipo que ejecute SQL Server y un equipo que ejecute una aplicación cliente o herramientas, como SQL Server Management Studio. Puesto que el HGS es responsable de determinar qué equipos que ejecutan SQL Server son de confianza, requiere un aislamiento físico y lógico de la instancia de SQL Server que está protegiendo. Si los mismos administradores tienen acceso a HGS y a un equipo SQL Server, podrían configurar el servicio de atestación para permitir que un equipo malicioso ejecute SQL Server, lo que les permitiría comprometer el enclave SBV.
Dominio de HGS
La configuración de HGS creará automáticamente un nuevo dominio de Active Directory para los servidores HGS, los recursos de clúster de conmutación por error y las cuentas de administrador.
No es necesario que el equipo que ejecuta SQL Server esté en un dominio, pero si lo está, debería ser un dominio diferente del que usa el servidor HGS.
Alta disponibilidad
La característica de HGS instala y configura automáticamente un clúster de conmutación por error. En un entorno de producción, se recomienda usar tres servidores HGS para lograr alta disponibilidad. Consulte la documentación del clúster de conmutación por error para obtener información sobre cómo se determina el cuórum de clúster y sobre las configuraciones alternativas, como los clústeres de dos nodos con un testigo externo.
No es necesario el almacenamiento compartido entre los nodos de HGS. Una copia de la base de datos de atestación se almacena en cada servidor HGS y se replica automáticamente a través de la red mediante el servicio de clúster.
Conectividad de red
Es necesario que tanto el cliente SQL como SQL Server puedan comunicarse con HGS a través de HTTP. Configure HGS con un certificado TLS para cifrar todas las comunicaciones entre el cliente SQL y HGS, así como entre SQL Server y HGS. Esta configuración ayuda a protegerse de ataques de tipo "Man in the middle" y garantiza que se comunica con el servidor HGS correcto.
Los servidores HGS requieren conectividad entre cada nodo del clúster para garantizar que la base de datos del servicio de atestación permanece sincronizada. Se trata de un procedimiento recomendado de clúster de conmutación por error para conectar los nodos HGS en una red para la comunicación del clúster y usar una red independiente para que otros clientes se comuniquen con HGS.
Modos de atestación
Cuando un equipo que ejecuta SQL Server intenta atestiguar con HGS, primero preguntará a HGS cómo debe atestiguar. HGS admite dos modos de atestación para su uso con SQL Server:
| Modo de atestación | Explicación |
|---|---|
| TPM | La atestación del Módulo de plataforma segura (TPM) proporciona la mayor garantía sobre la identidad y la integridad del equipo que realiza la atestación con HGS. Es necesario que los equipos que ejecutan SQL Server tengan instalada la versión 2.0 de TPM. Cada chip TPM contiene una identidad única e inmutable (clave de aprobación) que se puede usar para identificar un equipo determinado. Los TPM también miden el proceso de arranque del equipo y almacenan los valores hash de las medidas que afectan a la seguridad en los registros de configuración de la plataforma (PCR) que se pueden leer, pero que el sistema operativo no puede modificar. Estas medidas se utilizan durante la atestación para proporcionar una prueba criptográfica de que un equipo está en la configuración de seguridad que dice estar. |
| Clave de host | La atestación de clave de host es una forma más sencilla de atestación que solo comprueba la identidad de un equipo mediante un par de claves asimétricas. La clave privada se almacena en el equipo que ejecuta SQL Server y la clave pública se proporciona a HGS. No se mide la configuración de seguridad del equipo y no es necesario un chip TPM 2.0 en el equipo que ejecuta SQL Server. Es importante proteger la clave privada instalada en el equipo con SQL Server, ya que cualquier persona que obtenga esta clave puede suplantar a un equipo legítimo con SQL Server y al enclave de VBS que se ejecuta dentro de SQL Server. |
En general, se proponen las recomendaciones siguientes:
- Para los servidores físicos de producción, recomendamos usar la atestación TPM por las garantías adicionales que proporciona.ido a las garantías adicionales que proporciona.
- Para los servidores de producción virtuales, se recomienda la atestación de clave de host porque la mayoría de las máquinas virtuales no tienen TPM virtuales ni arranque seguro. Si va a usar una máquina virtual con seguridad mejorada, como un máquina virtual blindada local, puede usar el modo TPM. En todas las implementaciones virtualizadas, el proceso de atestación solo analiza el entorno de la máquina virtual, no la plataforma de virtualización subyacente.
- Para escenarios de desarrollo y pruebas, se recomienda la atestación de clave de host porque es más fácil de configurar.
Modelo de confianza
En el modelo de confianza del enclave de VBS, las consultas y los datos cifrados se evalúan en un enclave basado en software para protegerlo del sistema operativo del host. El acceso a este enclave está protegido por el hipervisor de la misma manera que dos máquinas virtuales que se ejecutan en el mismo equipo no pueden tener acceso a la memoria de los demás.
Para que un cliente confíe en que se comunica con una instancia legítima de SBV, debe usar una atestación basada en TPM que establezca una raíz de confianza de hardware en el equipo con SQL Server.
Las medidas de TPM que se capturan durante el proceso de arranque incluyen la clave de identidad única de la instancia de VBS, lo que garantiza que el certificado de mantenimiento solo sea válido en ese equipo exacto. Además, cuando un TPM está disponible en un equipo que ejecuta VBS, el TPM protege la parte privada de la clave de identidad de VBS, lo que impide que alguien intente suplantar a esa instancia de VBS.
El arranque seguro es obligatorio con la atestación de TPM para garantizar que UEFI ha cargado un cargador de arranque legítimo firmado por Microsoft y que ningún rootkit haya interceptado el proceso de arranque del hipervisor. Además, se requiere un dispositivo IOMMU de forma predeterminada para asegurarse de que los dispositivos de hardware con acceso directo a memoria no puedan inspeccionar o modificar la memoria del enclave.
Todas estas protecciones asumen que el equipo que ejecuta SQL Server es una máquina física. Si virtualiza el equipo que ejecuta SQL Server, ya no puede garantizar que la memoria de la máquina virtual sea segura contra la inspección por parte del hipervisor o del administrador del hipervisor. Un administrador del hipervisor podría, por ejemplo, volcar la memoria de la máquina virtual y acceder a la versión en texto no cifrado de la consulta y los datos del enclave. Del mismo modo, aunque la máquina virtual tenga un TPM virtual, solo puede medir el estado y la integridad del sistema operativo de la máquina virtual y el entorno de arranque. No puede medir el estado del hipervisor que controla la máquina virtual.
Sin embargo, incluso cuando SQL Server se encuentra virtualizado, el enclave sigue protegido contra ataques originados en el sistema operativo de la máquina virtual. Si confía en el hipervisor o en el proveedor de nube y le preocupan principalmente los ataques a datos confidenciales por parte de administradores de bases de datos y del sistema operativo, SQL Server virtualizado puede satisfacer sus necesidades.
De igual modo, la atestación de tecla del host sigue siendo valiosa en situaciones en las que no se ha instalado un módulo TPM 2.0 en el equipo que ejecuta SQL Server o en escenarios de desarrollo/prueba en los que la seguridad no es primordial. Puedes usar muchas de las características de seguridad mencionadas, como Secure Boot y un módulo TPM 1.2, para proteger mejor SBV y el sistema operativo en su conjunto. Pero, dado que no hay forma de que HGS compruebe que el equipo tiene esta configuración habilitada con la atestación de clave de host, el cliente no está seguro de que el host realmente use todas las protecciones disponibles.
Requisitos previos
Requisitos previos del servidor HGS
Los equipos que ejecutan el rol del Servicio de protección de host deben cumplir los siguientes requisitos:
| Componente | Requisito |
|---|---|
| Sistema operativo | Windows Server 2019 o posterior, edición Standard o Datacenter |
| CPU | 2 núcleos (mín), 4 núcleos (recomendado) |
| RAM | 8 GB (mín) |
| NIC | Dos NIC con direcciones IP estáticas recomendadas (una para el tráfico de clúster, una para el servicio de HGS) |
HGS es un rol enlazado a la CPU debido al número de acciones que requieren cifrado y descifrado. El uso de procesadores modernos con capacidades de aceleración criptográfica mejorará el rendimiento de HGS. Los requisitos de almacenamiento para los datos de atestación son mínimos, en el intervalo de 10 KB a 1 MB por equipo único que realiza la atestación.
No una los equipos HGS a un dominio antes de empezar.
Requisitos previos del equipo con SQL Server
Los equipos que ejecuten SQL Server deben cumplir tanto los requisitos de instalación de SQL Server como los requisitos de hardware de Hyper-V.
Estos requisitos incluyen:
- SQL Server 2019 (15.x) o versión posterior
- Windows 10, versión 1809 o posterior: Enterprise Edition, Windows 11 o posterior: Enterprise Edition, Windows Server 2019 o posterior: Datacenter Edition. Otras ediciones de Windows 10/11 y Windows Server no admiten la atestación con HGS.
- Compatibilidad de CPU con tecnologías de virtualización:
- Intel VT-x con tablas de página extendida.
- AMD-V con indexación de virtualización rápida.
- Si se ejecuta SQL Server en una máquina virtual:
- En Azure, use un tamaño de VM de generación 2 (recomendado) o un tamaño de VM de generación 1 con la virtualización anidada habilitada. Compruebe la documentación de tamaños de VM individuales para determinar qué tamaños de VM de generación 1 admiten la virtualización anidada.
- En Hyper-V 2016 o versiones posteriores (fuera de Azure), asegúrese de que la máquina virtual es una máquina virtual de generación 2 (recomendada) o una máquina virtual de generación 1 con la virtualización anidada habilitada. Para obtener más información, consulte ¿Debería crear una máquina virtual de generación 1 o 2 en Hyper-V? y Configuración de la virtualización anidada.
- En VMware vSphere 6.7 o posterior, habilite la compatibilidad con la seguridad basada en virtualización en la máquina virtual, como se describe en la documentación de VMware.
- Es posible que otros hipervisores y nubes públicas admitan funciones de virtualización anidada que también permitan Always Encrypted con enclaves de VBS. Consulte la documentación de la solución de virtualización para obtener instrucciones relativas a la compatibilidad y configuración.
- Si tiene previsto usar la atestación de TPM, necesitará un chip TPM 2.0 rev 1.16 listo para su uso en el servidor. En este momento, la atestación de HGS no funciona con los chips TPM 2.0 rev 1.38. Además, el TPM debe tener un certificado de clave de aprobación válido.
Roles y responsabilidades al configurar la atestación con HGS
Configurar la atestación con HGS implica configurar componentes de diferentes tipos: HGS, equipos con SQL Server, instancias de SQL Server y aplicaciones que activan la atestación de enclaves. Los usuarios realizan la configuración de los componentes de cada tipo y asumen uno de los roles siguientes:
- Administrador de HGS: implementa HGS, registra los equipos con SQL Server con HGS y comparte la URL de certificación de HGS con los administradores de equipos con SQL Server y los administradores de aplicaciones cliente.
- Administrador de equipos con SQL Server: instala los componentes del cliente de atestación, habilita SBV en los equipos con SQL Server, proporciona al administrador de HGS la información necesaria para registrar los equipos con SQL Server con HGS, configura la URL de atestación en los equipos con SQL Server y verifica que los equipos con SQL Server puedan atestar correctamente con HGS.
- DBA: configura enclaves seguros en instancias de SQL Server.
- Administrador de aplicaciones: configura la aplicación con la dirección URL de atestación obtenida del administrador de HGS.
En entornos de producción (donde se controlan datos confidenciales reales), es importante que la organización se adhiera a la separación de roles al configurar la atestación, donde cada rol distinto es asumido por usuarios diferentes. En concreto, si el objetivo de implementar Always Encrypted en la organización es reducir el área expuesta a ataques asegurándose de que los administradores de los equipo con SQL Server y los DBA no puedan acceder a los datos confidenciales, los administradores de SQL Server y los DBA no deben controlar los servidores HGS.
Consideraciones sobre el entorno de pruebas o desarrollo
Si usa Always Encrypted con enclaves SBV en un entorno de prueba o desarrollo y no necesita alta disponibilidad ni una protección fuerte del equipo que ejecuta SQL Server, puede hacer alguna o todas las concesiones siguientes para una implementación simplificada:
- Uso de Always Encrypted con enclaves seguros sin atestación - vea Planear Always Encrypted con enclaves seguros en SQL Server sin atestación.
- Alternativamente:
- Implemente solo un nodo de HGS. Aunque HGS instala un clúster de conmutación por error, no es necesario agregar nodos adicionales si la alta disponibilidad no es un problema.
- Use el modo de clave de host en lugar del modo TPM para obtener una experiencia de instalación más sencilla.
- Virtualice HGS o el SQL Server para guardar recursos físicos.
- Ejecute SSMS u otras herramientas para configurar Always Encrypted con enclaves seguros en el mismo equipo que SQL Server. Esto deja las claves maestras de columna en el mismo equipo que SQL Server, así que no lo haga en un entorno de producción.