Compartir vía

Registro del equipo con el servicio de protección de host

  • Artículo

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

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

Nota:

El proceso de registro de un servidor SQL Server en HGS requiere un esfuerzo conjunto del administrador de HGS y del administrador de equipo con SQL Server. Vea Roles y responsabilidades al configurar la atestación con 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

Nota:

Este paso lo debe realizar el administrador del equipo con SQL Server.

Para permitir que un cliente SQL compruebe que se comunica con un equipo con SQL Server de confianza, el equipo con SQL Server debe realizar correctamente la atestación con el servicio de protección de host. 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 elevados para instalar la característica de compatibilidad de Hyper-V de protección de host, que contiene los componentes de cliente de HGS y 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

Nota:

Este paso lo debe realizar el administrador del equipo con SQL Server.

Al instalar la característica de compatibilidad de Hyper-V de protección de host, 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 se está ejecutando VBS, abra la herramienta de información del sistema mediante la ejecución de msinfo32.exe y busque los elementos Virtualization-based security hacia la parte inferior del Resumen del sistema.

Captura de pantalla de Información del sistema en la que se muestra el estado y la configuración de la seguridad basada en la virtualización

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 de Hyper-V de protección de host habilita automáticamente la VBS. Por lo tanto, si ve este estado, es recomendable que repita el paso 1.

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 disponga de protección DMA y tendrá que eliminar el requisito de que se ejecute SBV. 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

Nota:

Este paso lo debe realizar el administrador del equipo con SQL Server.

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 se beneficia de las características de protección de claves de HGS. Por lo tanto, indique cualquier URL ficticia, como http://localhost hasta -KeyProtectionServerUrl.
Set-HgsClientConfiguration -AttestationServerUrl "https://hgs.bastion.local/Attestation" -KeyProtectionServerUrl "http://localhost"

A menos que haya registrado este equipo con HGS antes, el comando informa de un error en la 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

Nota:

Este paso lo realizan conjuntamente el administrador del equipo con SQL Server y el administrador de HGS. Vea las notas siguientes para obtener más información.

Preparación

Nota:

Esta acción la debe realizar el administrador del equipo con SQL Server.

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, vaya al paso 4B.

Antes de empezar a recopilar las medidas de TPM, asegúrese de que está trabajando en una configuración correcta conocida del equipo de SQL Server. El equipo debe tener instalado todo el hardware necesario y aplicar las últimas actualizaciones de firmware y software. HGS mide los equipos comparándolos con esta base de referencia al realizar la atestación, por lo que es importante tener el estado más seguro e intencionado posible al recopilar las medidas de 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.

Artefacto de atestación ¿Qué mide? Unicidad
Identificador de plataforma La clave de aprobación pública en el TPM del equipo y el certificado de clave de aprobación del fabricante del TPM. 1 para cada equipo
Base de referencia de TPM Los registros de control de plataforma (PCR) del TPM que miden el firmware y la configuración del sistema operativo cargados durante el proceso de arranque. Algunos ejemplos son el estado de arranque seguro y si los volcados de memoria están cifrados. Una base de referencia por configuración única de equipo (si el hardware y el software son idénticos, pueden usar la misma base de referencia)
Directiva de integridad de código La directiva de Windows Defender Application Control en la que confía para proteger los equipos Uno por directiva de integración continua única implementada en los equipos.

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 la atestación de un equipo coincida con una directiva de cada categoría de directivas. 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

Nota:

Los siguientes pasos se deben realizar por el administrador del equipo con SQL Server.

HGS requiere que todos los equipos que se comparan en el modo TPM tengan aplicada una directiva de control de aplicaciones de Windows Defender (WDAC). Las directivas de integridad de código de WDAC restringen el software que se puede ejecutar en un equipo comprobando cada proceso que intenta ejecutar código en una lista de editores de confianza y hashes de archivo. 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 de integridad de código de WDAC personalizada en los equipos para proteger la configuración del sistema operativo, puede ir a la sección Recopilación de información sobre la 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, ejecute los comandos siguientes 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. En el caso de los equipos del grupo de trabajo, siga el mismo proceso con el editor de la directiva 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.

Recopilación de información sobre la atestación de TPM

Nota:

Los siguientes pasos se deben realizar por el administrador del equipo con SQL Server.

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 buen estado, ejecute los siguientes comandos en PowerShell para recopilar la información de atestación de 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

Nota:

Los pasos siguientes los debe realizar el administrador de 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 los archivos de atestación, que obtuvo del administrador del equipo con SQL Server en el servidor HGS.

  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 que no dispongan de la directiva IOMMU para protegerse frente a ataques de DMA (por ejemplo, una máquina virtual), deshabilite dicha directiva.

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

Disable-HgsAttestationPolicy Hgs_IommuEnabled

Nota:

Si deshabilita la directiva IOMMU, las directivas IOMMU no serán necesarias para ningún equipo que realice la atestación con HGS. La directiva IOMMU no se puede deshabilitar para un solo equipo.

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

Nota:

Este paso lo realizan conjuntamente el administrador del equipo con SQL Server y el administrador de HGS. Vea las notas siguientes para obtener más información.

En este paso, seguirá el proceso de generación de una clave única para el host y de su registro con 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

Nota:

Esta parte se debe realizar conjuntamente por el administrador de equipo con SQL Server.

La atestación de tecla del host funciona generando un par de claves asimétricas en el equipo con SQL Server y proporcionando a HGS la mitad pública de dicha clave.

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

Nota:

Los pasos siguientes los debe realizar el administrador de 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 de certificado, que obtuvo del administrador del equipo con SQL Server, en 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: Confirmación de que el hoste puede atestiguar correctamente

Nota:

Este paso lo debe realizar el administrador del equipo con SQL Server.

Una vez que haya registrado el equipo con SQL Server con HGS (paso 4A para el modo TPM, paso 4B para el modo de tecla del host), debería confirmar que puede atestiguar correctamente.

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:

AttestationStatus Explicación
Expirada El host ha pasado la atestación, pero el certificado de mantenimiento que se emitió ha expirado. Asegúrese de que la hora del host y del HGS están sincronizadas.
InsecureHostConfiguration El equipo no cumplía una o más directivas de atestación configuradas en el servidor HGS. Para obtener más información, vea AttestationSubStatus.
NoConfigurado El equipo no está configurado con una dirección URL de atestación. Configurar la URL de atestación
Aprobada El equipo superó la atestación y es de confianza para ejecutar enclaves de SQL Server.
TransientError No se ha podido realizar el intento de atestación debido a un error temporal. Este error suele significar que se ha producido un problema al contactar con HGS a través de la red. Compruebe la conexión de red y asegúrese de que el equipo pueda resolver el nombre del servicio HGS y redirigirlo.
TpmError El dispositivo TPM del equipo ha detectado un error durante el intento de atestación. Consulte los registros de TPM para obtener más información. La eliminación del TPM puede resolver el problema, pero antes de hacerlo debe asegurarse de suspender BitLocker y otros servicios que dependan del TPM.
UnauthorizedHost HGS no conoce la clave del host. Siga las instrucciones del paso 4B para registrar el equipo con HGS.

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

AttestationSubStatus Qué significa y qué hay que hacer
CodeIntegrityPolicy La directiva de integridad de código del equipo no está registrada en el HGS o en estos momentos el equipo no está utilizando una directiva de integridad de código. Encontrará una guía en Configuración de una directiva de integridad de código.
DumpsEnabled El equipo está configurado para permitir volcados de memoria, pero la directiva Hgs_DumpsEnabled no permite los volcados. Para continuar, deshabilite los volcados en este equipo o deshabilite la directiva Hgs_DumpsEnabled.
FullBoot El equipo se ha reanudado de un estado de suspensión o hibernación, lo que provoca cambios en las mediciones del TPM. Reinicie el equipo para generar medidas de TPM limpias.
HibernationEnabled El equipo está configurado para permitir la hibernación con archivos de hibernación sin cifrar. Para resolver este problema, deshabilite la hibernación en el equipo.
HypervisorEnforcedCodeIntegrityPolicy El equipo no está configurado para usar una directiva de integridad de código. Vaya a Directiva de grupo o Directiva de grupo local > Configuración del equipo > Plantillas administrativas > Sistema > Device Guard > active Seguridad basada en la virtualización > Protección basada en la virtualización de la integridad del código. Este elemento de directiva debe estar "Habilitado sin el bloqueo UEFI".
Iommu Este equipo no tiene ningún dispositivo IOMMU habilitado. Si es un equipo físico, habilite IOMMU en el menú de configuración de UEFI. Si se trata de una máquina virtual y no tiene IOMMU disponible, ejecute Disable-HgsAttestationPolicy Hgs_IommuEnabled en el servidor de HGS.
SecureBoot El arranque seguro no está habilitado en este equipo. Habilite el arranque seguro en el menú de configuración de UEFI para resolver este error.
VirtualSecureMode La seguridad basada en la virtualización no se está ejecutando en este equipo. Siga las instrucciones del Paso 2: Compruebe que VBS se está ejecutando en el equipo.

Pasos siguientes