Registrar el equipo en Host Guardian Service

Se aplica a: SQL Server 2019 (15.x) y versiones posteriores en Windows

En este artículo se describe cómo registrar equipos SQL Server para certificarlos con el Servicio de protección de host (HGS).

Antes de empezar, asegúrese de que ha implementado al menos un equipo de HGS y ha configurado el servicio de atestación de HGS. Para más información, vea Implementación del Servicio de protección de host para SQL Server.

Paso 1: Instalación de los componentes de cliente de atestación

Para permitir que un cliente SQL compruebe que se está comunicando con un equipo que ejecuta SQL Server y es de confianza, el equipo que ejecuta SQL Server debe completar correctamente la atestación con Host Guardian Service. El proceso de atestación se administra mediante un componente de Windows opcional denominado cliente del HGS. En los pasos siguientes verá cómo instalar este componente y comenzar a realizar la atestación.

1. Asegúrese de que el equipo con SQL Server cumple los requisitos previos indicados en el documento de planificación de HGS.

2. Ejecute el siguiente comando en una consola de PowerShell con privilegios de administrador para instalar la característica de compatibilidad de Hyper-V para Host Guardian, que contiene el cliente HGS y los componentes de atestación.

   Enable-WindowsOptionalFeature -Online -FeatureName HostGuardian -All
   

3. Reinicie el equipo para completar la instalación.

Paso 2: Verificación del funcionamiento de la seguridad basada en virtualización

Al instalar la característica de compatibilidad con Hyper-V de Host Guardian, se configura y habilita automáticamente la seguridad basada en virtualización (VBS). Los enclaves para SQL Server Always Encrypted se encuentran protegidos y se ejecutan dentro del entorno SBV. Puede que la VBS no se inicie si el equipo no tiene un dispositivo IOMMU instalado y habilitado. Para comprobar si VBS está en funcionamiento, abre la herramienta de Información del Sistema ejecutando msinfo32.exe y busca los Virtualization-based security elementos que aparecen al final del Resumen del Sistema.

El primer elemento que se va a comprobar es Virtualization-based security, que puede tener los tres valores siguientes:

• Running significa que la VBS está bien configurada y se ha podido iniciar correctamente. Si el equipo muestra este estado, puede ir directamente al paso 3.
• Enabled but not running significa que la VBS está configurada para ejecutarse, pero el hardware no tiene los requisitos de seguridad mínimos para ejecutar la VBS. Es posible que tenga que cambiar la configuración del hardware en la BIOS o UEFI para habilitar características opcionales del procesador como IOMMU o, si el hardware realmente no admite las características necesarias, puede que necesite reducir los requisitos de seguridad de la VBS. Para obtener más información, siga leyendo esta sección.
• Not enabled significa que VBS no está configurada para ejecutarse. La característica de compatibilidad con Hyper-V de Host Guardian habilita automáticamente VBS, por lo que se recomienda repetir el paso 1 si ve este estado.

Si la VBS no se está ejecutando en el equipo, compruebe las propiedades de Virtualization-based security. Compare los valores del elemento Required Security Properties con los valores del elemento Available Security Properties. Las propiedades necesarias deben ser iguales a las propiedades de seguridad disponibles, o un subconjunto de ellas, para que se ejecute la VBS.

En el contexto de la certificación de enclaves de SQL Server, las propiedades de seguridad tienen la siguiente importancia:

• Siempre se requiere Base virtualization support, ya que representa las características de hardware mínimas necesarias para ejecutar un hipervisor.
• Secure Boot se recomienda pero no es obligatorio para SQL Server Always Encrypted. El arranque seguro protege contra rootkits, ya que requiere que se ejecute un cargador de arranque firmado por Microsoft inmediatamente después de que se complete la inicialización de UEFI. Si usa la atestación de módulo de plataforma segura (TPM), se medirá y aplicará la habilitación del arranque seguro independientemente de si la VBS está configurada para requerir un arranque seguro.
• DMA Protection se recomienda pero no es obligatorio para SQL Server Always Encrypted. La protección de DMA usa IOMMU para proteger la memoria de la VBS y del enclave ante ataques de acceso directo a la memoria. En un entorno de producción, siempre debe usar equipos con protección de DMA. En un entorno de desarrollo y pruebas, se admite eliminar el requisito de protección de DMA. Si la instancia de SQL Server está virtualizada, lo más probable es que no tenga disponible la protección frente a DMA y tendrá que eliminar el requisito para que se ejecute VBS. Revise el modelo de confianza para obtener información sobre las garantías de seguridad reducidas al ejecutarse en una máquina virtual.

Antes de reducir las características de seguridad necesarias de VBS, consulte al proveedor de servicios en la nube o OEM si existe una manera de habilitar los requisitos de plataforma que faltan en UEFI o BIOS (por ejemplo, para habilitar el arranque seguro, Intel VT-d o AMD IOV).

Para cambiar las características de seguridad de la plataforma necesarias para la VBS, ejecute el siguiente comando en una consola de PowerShell con privilegios elevados:

# Value 0 = No security features required
# Value 1 = Only Secure Boot is required
# Value 2 = Only DMA protection is required (default configuration)
# Value 3 = Both Secure Boot and DMA protection are required
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard -Name RequirePlatformSecurityFeatures -Value 0

Después de cambiar el registro, reinicie el equipo de SQL Server y compruebe si VBS se está ejecutando de nuevo.

Si el equipo está administrado por su empresa, la directiva de grupo o Microsoft Endpoint Manager puede invalidar cualquier cambio que se realice en estas claves del registro después de reiniciar. Contacte con el departamento de soporte técnico de TI para ver si implementan directivas que administran su configuración de VBS.

Paso 3: Configurar la URL de atestación

A continuación, configurará el equipo con SQL Server con la dirección URL del servicio de atestación de HGS, que ha obtenido del administrador de HGS.

En una consola de PowerShell con privilegios elevados, actualice y ejecute los siguientes comandos para configurar la URL de atestación.

• Reemplace hgs.bastion.local por el nombre del clúster HGS.
• Puede ejecutar Get-HgsServer en cualquier equipo HGS para obtener el nombre del clúster.
• La URL de atestación siempre debe terminar con /Attestation.
• SQL Server no utiliza las funciones de protección de claves de HGS, así que proporciona cualquier URL ficticia como http://localhost-KeyProtectionServerUrl

Set-HgsClientConfiguration -AttestationServerUrl "https://hgs.bastion.local/Attestation" -KeyProtectionServerUrl "http://localhost"

A menos que hayas registrado este equipo con HGS antes, el comando notifica un error de atestación. Este resultado es normal.

El campo AttestationMode de la salida del cmdlet indica qué modo de atestación usa HGS.

Vaya al paso 4A para registrar el equipo en modo TPM o al paso 4B para registrar el equipo en modo de clave de host.

Paso 4A: Registro de un equipo en modo TPM

Preparación

En este paso, recopilará información sobre el estado de TPM del equipo y lo registrará con HGS.

Si el servicio de atestación de HGS está configurado para usar el modo de clave de host, pase directamente a Paso 4B en su lugar.

Antes de empezar a recopilar las mediciones de TPM, asegúrese de trabajar con una configuración fiable y verificada del equipo con SQL Server. El equipo debe tener instalado todo el hardware necesario y aplicar las últimas actualizaciones de firmware y software. HGS compara los equipos con esta línea base cuando se someten a atestación, por lo que es importante que estén en el estado más seguro y previsto posible al recopilar las mediciones del TPM.

Hay tres archivos de datos recopilados para la atestación de TPM, algunos de los cuales se pueden reutilizar si tiene equipos configurados de forma idéntica.

Puede configurar más de un artefacto de atestación en HGS para prestar asistencia a una flota mixta de hardware y software. HGS solo requiere que un equipo que realiza la atestación cumpla una directiva de cada categoría de directiva. Por ejemplo, si tiene tres bases de referencia de TPM registradas en HGS, las medidas del equipo pueden coincidir con cualquiera de esas bases de referencia para cumplir el requisito de la directiva.

Configuración de una directiva de integridad de código

HGS requiere que todos los equipos que realicen la atestación en modo TPM tengan aplicada una directiva de Control de aplicaciones de Windows Defender (WDAC). Las directivas de integridad de código de WDAC restringen qué software puede ejecutarse en un equipo al comparar cada proceso que intenta ejecutar código con una lista de publicadores de confianza y hashes de archivos. En el caso de uso de SQL Server, los enclaves están protegidos por la seguridad basada en la virtualización y no se pueden modificar desde el sistema operativo del host, por lo que la rigurosidad de la directiva de WDAC no afecta a la seguridad de las consultas cifradas. Se recomienda implementar una directiva de modo auditoría en los equipos con SQL Server para cumplir el requisito de atestación sin imponer restricciones adicionales al sistema.

Si ya usa una directiva personalizada de integridad de código de WDAC en los equipos para reforzar la configuración del sistema operativo, puede pasar a Recopilar información de atestación de TPM.

1. Windows Server 2019, Windows 10 versión 1809 y los sistemas operativos posteriores disponen de directivas de ejemplo predefinidas. La directiva AllowAll permite la ejecución de cualquier software en el equipo sin restricciones. Para usar la directiva, conviértala a un formato binario que el sistema operativo y HGS entiendan. En una consola de PowerShell con privilegios elevados, ejecute los siguientes comandos para compilar la directiva AllowAll:

   # We are changing the policy to disable enforcement and user mode code protection before compiling
   $temppolicy = "$HOME\Desktop\allowall_edited.xml"
   Copy-Item -Path "$env:SystemRoot\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml" -Destination $temppolicy
   Set-RuleOption -FilePath $temppolicy -Option 0 -Delete
   Set-RuleOption -FilePath $temppolicy -Option 3
   
   ConvertFrom-CIPolicy -XmlFilePath $temppolicy -BinaryFilePath "$HOME\Desktop\allowall_cipolicy.bin"
   

2. Siga las instrucciones de la guía de implementación de Windows Defender Application Control para implementar el archivo allowall_cipolicy.bin en los equipos con SQL Server mediante la directiva de grupo. Para los equipos de un grupo de trabajo, siga el mismo proceso mediante el Editor de directivas de grupo local (gpedit.msc).

3. Ejecute gpupdate /force en los equipos son SQL Server para configurar la nueva directiva de integridad de código y después reinicie los equipos para aplicar la directiva.

Recopilar información de atestación del TPM

Repita los pasos siguientes para cada equipo con SQL Server en el que se vaya a realizar la atestación con HGS:

1. Con el equipo en un estado correcto conocido, ejecute los siguientes comandos en PowerShell para recopilar la información de atestación del TPM:

   # Collects the TPM EKpub and EKcert
   $name = $env:computername
   $path = "$HOME\Desktop"
   (Get-PlatformIdentifier -Name $name).Save("$path\$name-EK.xml")
   
   # Collects the TPM baseline (current PCR values)
   Get-HgsAttestationBaselinePolicy -Path "$path\$name.tcglog" -SkipValidation
   
   # Collects the applied CI policy, if one exists
   Copy-Item -Path "$env:SystemRoot\System32\CodeIntegrity\SIPolicy.p7b" -Destination "$path\$name-CIpolicy.bin"
   

2. Comparta los tres archivos de atestación con el administrador de HGS.

Registro del equipo SQL Server con HGS

Repita los pasos siguientes para cada equipo con SQL Server en el que se vaya a realizar la atestación con HGS:

1. Copie en el servidor HGS los archivos de atestación que obtuvo del administrador del equipo de SQL Server.

2. En el servidor HGS, ejecute los siguientes comandos en una consola PowerShell avanzada para registrar el equipo con SQL Server:

   # TIP: REMEMBER TO CHANGE THE FILENAMES
   # Registers the unique TPM with HGS (required for every computer)
   Add-HgsAttestationTpmHost -Path "C:\temp\SQL01-EK.xml"
   
   # Registers the TPM baseline (required ONCE for each unique hardware and software configuration)
   Add-HgsAttestationTpmPolicy -Name "MyHWSoftwareConfig" -Path "C:\temp\SQL01.tcglog"
   
   # Registers the CI policy (required ONCE for each unique CI policy)
   Add-HgsAttestationCiPolicy -Name "AllowAll" -Path "C:\temp\SQL01-CIpolicy.bin"
   

   Sugerencia

   Si se produce un error al intentar registrar el identificador de TPM único, asegúrese de que ha importado los certificados intermedios y raíz de TPM en el equipo HGS que está usando.

Además del identificador de plataforma, la base de referencia de TPM y la directiva de integridad de código, hay directivas integradas configuradas y aplicadas por HGS que es posible que deba cambiar. Estas directivas integradas se miden a partir de la base de referencia de TPM que se recopila del servidor y representan varias opciones de configuración de seguridad que deben habilitarse para proteger el equipo. Si tiene equipos en los que no haya una IOMMU para protegerlos de ataques DMA (por ejemplo, una máquina virtual), tendrá que deshabilitar la directiva IOMMU.

Para deshabilitar el requisito de IOMMU, ejecute el siguiente comando en el servidor HGS:

Disable-HgsAttestationPolicy Hgs_IommuEnabled

Puede revisar la lista de hosts y directivas de TPM registrados con los siguientes comandos de PowerShell:

Get-HgsAttestationTpmHost
Get-HgsAttestationTpmPolicy

Paso 4B: Registro de un equipo en modo de clave de host

Este paso le guiará por el proceso de generar una clave única para el host y registrarla en HGS. Si el servicio de atestación de HGS está configurado para usar el modo TPM, siga las instrucciones del paso 4A.

Generar una clave para un equipo con SQL Server

La atestación de la clave de host funciona generando un par de claves asimétricas en el equipo que ejecuta SQL Server y proporcionando a HGS la parte pública de ese par de claves.

Repita los pasos siguientes para cada equipo con SQL Server en el que se vaya a realizar la atestación con HGS:

1. Para generar el par de claves, ejecute el comando siguiente en una consola de PowerShell con privilegios elevados:

   Set-HgsClientHostKey
   Get-HgsClientHostKey -Path "$HOME\Desktop\$env:computername-key.cer"
   

   Si ya ha creado una clave de host y quiere generar un nuevo par de claves, use los comandos siguientes:

   Remove-HgsClientHostKey
   Set-HgsClientHostKey
   Get-HgsClientHostKey -Path "$HOME\Desktop\$env:computername-key.cer"
   

2. Comparta el archivo de certificado con el administrador de HGS.

Registro del equipo SQL Server con HGS

Repita los pasos siguientes para cada equipo con SQL Server en el que se vaya a realizar la atestación con HGS:

1. Copie el archivo del certificado que obtuvo del administrador del equipo de SQL Server a un servidor HGS.

2. Ejecute el siguiente comando en una consola PowerShell avanzada para registrar el equipo con SQL Server:

   Add-HgsAttestationHostKey -Name "YourComputerName" -Path "C:\temp\yourcomputername.cer"
   

Paso 5: Confirmar que el host puede realizar la atestación correctamente

Una vez que haya registrado el equipo de SQL Server con HGS (Paso 4A para el modo TPM, Paso 4B para el modo de clave de host), debe confirmar que puede realizar correctamente la atestación.

Puede comprobar la configuración del cliente de atestación de HGS y realizar un intento de atestación en cualquier momento con Get-HgsClientConfiguration.

La salida del comando será similar a esta:

PS C:\> Get-HgsClientConfiguration


IsHostGuarded                  : True
Mode                           : HostGuardianService
KeyProtectionServerUrl         : http://localhost
AttestationServerUrl           : http://hgs.bastion.local/Attestation
AttestationOperationMode       : HostKey
AttestationStatus              : Passed
AttestationSubstatus           : NoInformation
FallbackKeyProtectionServerUrl :
FallbackAttestationServerUrl   :
IsFallbackInUse                : False

Los dos campos más importantes de la salida son AttestationStatus, que indica si el equipo ha pasado la atestación, y AttestationSubStatus, que explica en qué directivas se produjo el error del equipo en caso de error en la atestación del equipo.

A continuación se explican los valores más comunes que pueden aparecer en AttestationStatus:

Cuando AttestationStatus muestra InsecureHostConfiguration, el campo AttestationSubStatus se rellenará con uno o varios nombres de directivas que han fallado. En la tabla siguiente se explican los valores más comunes y cómo corregirlos.

Contenido relacionado

• Configuración del enclave seguro en SQL Server