Cómo crear directivas de control de aplicaciones de In-Memory OLTP y de instalador administrado

Se aplica a:SQL Server

SQL Server compila y enlaza una biblioteca de enlace dinámico (DLL) para cada tabla y procedimiento almacenado compilado nativamente, que contiene la implementación nativa de esos objetos en código C. Aunque In-Memory DLL OLTP se generan dinámicamente, los archivos pueden presentar desafíos en entornos donde se requiere la aplicación de la integridad del código.

¿Qué es HkDllGen?

En SQL Server 2022 (16.x), a partir de la Actualización acumulativa 17 y en versiones posteriores, la característica OLTP en memoria incluye el generador de DLL de Hekaton, o HkDllGen. Sin HkDllGen, SQL Server genera código fuente C dentro sqlservr.exe y lanza el compilador, que invoca el enlazador para crear la DLL OLTP In-Memory. Con la generación externa activada, SQL Server exporta metadatos serializados de objetos y lanza el archivo firmado hkdllgen.exepor Microsoft. HkDllGen valida e importa esos metadatos, genera el código fuente en C en su propio proceso y lanza el compilador y el enlazador.

Para aplicar la integridad del código a estas DLL, utiliza AppLocker para designar hkdllgen.exe como instalador administrado firmado por Microsoft y para habilitar la confianza del instalador administrado en la directiva App Control for Business, anteriormente Windows Defender Application Control (WDAC). Windows entonces registra que las DLLs generadas provienen del árbol de procesos HkDllGen, permitiendo que Control de Aplicaciones confíe en ellas basándose en su origen gestionado en el instalador.

HkDllGen es el primer paso para cumplir con los requisitos regulatorios que incluyen la integridad del código para In-Memory OLTP. En este escenario, la integridad del código garantiza que Windows pueda establecer un origen confiable para cada DLL generada y evaluar esa confianza cuando SQL Server la carga. La DLL generada no está firmada por Authenticode. Windows confía en él según cómo fue creado.

¿Cómo funciona un instalador administrado?

Un instalador gestionado utiliza una colección especial de reglas en AppLocker para designar binarios en los que tu organización confía como fuente autorizada para la instalación de aplicaciones. Cuando se ejecuta uno de estos archivos binarios de confianza, Windows supervisa el proceso del binario (y los procesos secundarios que inicia) y supervisa los archivos que se escriben en el disco. A medida que se escriben los archivos, se agrega una notificación o etiqueta al archivo, indicando que se originan de un instalador administrado.

La reivindicación de origen es un atributo extendido gestionado por el núcleo. No es una firma Authenticode y no cambia el estado de publicación o firma de la DLL generada.

Al usar AppLocker, el Control de Aplicaciones para Empresas (anteriormente Windows Defender Control de Aplicaciones, o WDAC) puede configurarse para confiar en los archivos que instala un instalador gestionado añadiendo la opción Habilitado:Instalador Gestionado a una política de Control de Aplicaciones. Cuando configuras esa opción, Control de la Aplicación comprueba la información gestionada del origen del instalador al determinar si permitir que un binario se ejecute. Siempre que no haya reglas de denegación para el binario, El control de aplicaciones le permite ejecutarse basándose exclusivamente en su origen del instalador administrado. AppLocker también controla la ejecución de los archivos ejecutables que designa como instalador administrado, pero no ofrece una cadena de confianza para ejecutables y DLLs como la que proporciona WDAC. Este artículo explica cómo designar y configurar el proceso de HkDllGen como un instalador gestionado que tanto AppLocker como WDAC puedan utilizar.

Habilitación del generador de DLL de Hekaton

Ejemplo

Este ejemplo habilita el generador de DLL Hekaton usando sp_configure con la external xtp dll gen util enabled opción. Crea una base de datos de pruebas y una tabla optimizada para memoria de prueba.

1. Cree una base de datos de prueba.

   USE master;
   GO
   
   EXECUTE sp_configure 'external xtp dll gen util enabled', 1;
   RECONFIGURE;
   GO
   
   CREATE DATABASE HekatonDbForTesting ON
   PRIMARY (
       NAME = N'HekatonDbForTesting_Data',
       FILENAME = N'<path-to-data-directory>\HekatonDbForTesting_Data.mdf'
   ),
   FILEGROUP [HekatonDbForTestin_XTP_FG] CONTAINS MEMORY_OPTIMIZED_DATA (
       NAME = HekatonDbForTesting_XTP_CHKPOINT,
       FILENAME = N'<path-to-data-directory>\HekatonDbForTesting_XTP_CHKPOINT'
   )
   LOG ON (
       NAME = N'HekatonDbForTesting_log',
       FILENAME = N'<Path_To_Log_Directory>\HekatonDbForTesting_Log.ldf'
   );
   GO
   

2. Cree una tabla de prueba dentro de la base de datos de prueba.

   USE HekatonDbForTesting;
   GO
   
   CREATE TABLE dbo.TestCustomerTable
   (
       CustomerId INT NOT NULL
           PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1000000),
       FirstName NVARCHAR (50) NOT NULL,
       LastName NVARCHAR (50) NOT NULL
   )
   WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);
   GO
   

3. Se crea un .gen archivo junto a cada DLL generada por HkDllGen en el <path-to-data-directory>\xtp\<database_id> subdirectorio. Este archivo captura la salida de HkDllGen y normalmente es de longitud cero tras una compilación exitosa. Su presencia indica que se activó el generador externo. Las DLLs generadas no están firmadas por Authenticode. Para que Windows confíe en las DLLs generadas según su origen, necesitas el seguimiento de instaladores gestionados y una política de Control de Aplicaciones.

Las DLLs existentes no obtienen información gestionada del origen del instalador de forma retroactiva. Genera una nueva DLL después de que el seguimiento gestionado del instalador esté activo al validar la política.

Pasos para crear In-Memory OLTP AppLocker y políticas de instalador gestionado

No puedes usar la interfaz de creación de políticas de AppLocker en GPO Editor (gpedit.msc) ni los comandos PowerShell de AppLocker para crear reglas para la colección de reglas gestionada del instalador. Sin embargo, puedes usar un editor XML o de texto para convertir una política de colección de reglas EXE en una colección de reglas gestionada por instaladores.

Los ejemplos restantes en este artículo se aplican a Windows Server 2022 y Windows 11 y versiones posteriores.

Para verificar que al menos existe una colección de reglas exe dentro de la configuración de políticas de control de AppLocker del servidor, ejecute el siguiente comando PowerShell:

Get-AppLockerPolicy -Effective

O bien, ejecuta el siguiente comando para guardar la salida de las políticas efectivas en un archivo XML para su visualización:

Get-AppLockerPolicy -Effective -Xml > effective_app_policy.xml

Los siguientes pasos explican el proceso de creación y aplicación de una política que puedes aplicar a un servidor local. Una política de instalador gestionado generada mediante estos pasos puede fusionarse en una política de GPO y distribuirse a todas las instancias de SQL Server dentro de un entorno, o aplicarse a la política local de un solo servidor. Deberías trabajar con un administrador de dominio para aplicar la política de Integridad de Código desde el nivel de dominio.

1. Utilice New-AppLockerPolicy para crear una regla EXE para el archivo que va a designar como instalador administrado. Este ejemplo crea una regla para el generador de DLL de Hekaton usando el tipo de regla Publisher, pero puedes usar cualquier tipo de regla AppLocker. Es posible que tenga que volver a formatear la salida para mejorar la legibilidad.

   # Change the current working path of the PowerShell command line or ISE to
   # something other than the default (that is, C:\Temp). Retrieve SQL Server Path.
   $sqlPathParams = @{
      Path = 'HKLM:\SOFTWARE\Microsoft\MSSQLServer\Setup'
      Name = 'SQLPath'
   }
   $SQLPath = Get-ItemProperty @sqlPathParams
   
   $joinPathParams = @{
      Path = $SQLPath.SQLPath
      ChildPath = 'Binn\xtp'
   }
   $FullPath = Join-Path @joinPathParams
   
   # Set an environment variable for the In-memory OLTP Path.
   [System.Environment]::SetEnvironmentVariable('SQLPathWithXtp', $FullPath, 'Process')
   
   # Generate an AppLocker Policy for hkdllgen.exe in the current working directory.
   # The Get-AppLockerFileInformation cmdlet extracts the executable's publisher
   # information, and generates a hash for the binary.
   $hkDllGenPath = Join-Path -Path $env:SQLPathWithXtp -ChildPath 'hkdllgen.exe'
   
   $newPolicyParams = @{
      RuleType = 'Publisher'
      User = 'Everyone'
      Xml = $true
   }
   Get-ChildItem -Path $hkDllGenPath |
   Get-AppLockerFileInformation |
   New-AppLockerPolicy @newPolicyParams > AppLocker_HkDllGen_Policy.xml
   

2. Edite manualmente el AppLocker_HkDllGen_Policy.xml y cambie los siguientes valores de atributo:

   • RuleCollection Type a ManagedInstaller
   • EnforcementMode a AuditOnly
   • BinaryVersionRange LowSection a "*" y HighSection a "*"

   Cambio:

   <RuleCollection Type="Exe" EnforcementMode="NotConfigured">
   

   a:

   <RuleCollection Type="ManagedInstaller" EnforcementMode="AuditOnly">
   

   Cambio:

   <BinaryVersionRange LowSection="2022.160.4175.1" HighSection="2022.160.4175.1"/>
   

   a:

   <BinaryVersionRange LowSection="*" HighSection="*"/>
   

3. Implemente la directiva de configuración del instalador administrado de AppLocker. Puedes importar la política de AppLocker y desplegarla con la Directiva de Grupo, o usar un script para desplegar la política con el Set-AppLockerPolicy cmdlet como se muestra en el siguiente comando PowerShell.

   #Enable the AppLocker Policy and merge with the existing policy that exists on the system.
   Set-AppLockerPolicy -XmlPolicy .\AppLocker_HkDllGen_Policy.xml -Merge -ErrorAction SilentlyContinue
   

4. Si despliegas la política de AppLocker con un script de PowerShell, utiliza la appidtel.exe utilidad de un símbolo de la línea de comandos administrativa para configurar el servicio de Identidad de Aplicación de AppLocker y el controlador de filtro de AppLocker.

   appidtel.exe start [-mionly]
   

Habilitar la opción del instalador administrado en el Asistente para el Control de aplicaciones de Windows Defender para empresas

Para que Windows Defender Control de Aplicaciones (WDAC) confíe en las DLLs generadas por el hkdllgen.exe proceso, especifica la opción Habilitado: Instalador Gestionado en tu política de Control de Aplicaciones. Define esta configuración usando el cmdletSet-RuleOption con la Opción 13.

Genere un archivo de directiva de integridad del código a partir de una de las directivas base de plantilla del Asistente para directivas base de WDAC.

Partir de la directiva Windows predeterminado ofrece menos opciones, que se han omitido en esta guía. Para obtener más información sobre las políticas del modo Windows predeterminado y permitir el modo Microsoft, consulte el artículo de ejemplo de políticas de base de control de aplicaciones para negocio.

Directiva de plantilla base

Después de seleccionar la plantilla de la base de políticas de Windows, nombra la política y elige dónde guardar la política de Control de Aplicaciones en el disco.

Selección de un tipo de directiva

Selecciona Formato de póliza múltiple y Póliza base como tipo de política.

Configuración de la plantilla de directiva

Activa solo las opciones de reglas de Instalador Gestionado, Política de Actualización sin Reiniciar, Política de Integridad del Sistema Sin Firmar y Política de Integridad del Código en Modo de Usuario . Deshabilite las demás opciones de reglas de directiva. Para cambiar la configuración, selecciona el botón deslizante junto a los títulos de las reglas de política.

La siguiente tabla describe cada regla de política, comenzando por la columna más a la izquierda. El artículo sobre reglas de política ofrece una descripción más detallada de cada regla de política.

Se recomienda habilitar inicialmente el modo de auditoría, ya que permite probar las nuevas directivas de App Control for Business antes de aplicarlas. Con el modo de auditoría, ninguna aplicación está bloqueada. En su lugar, la política registra un evento cada vez que se inicia una aplicación fuera de la política. Por este motivo, todas las plantillas tienen habilitado el modo de auditoría de forma predeterminada.

Reglas de archivo

Elimina todas las reglas de firma de directivas de la lista.

(Opcional) Añadir una regla de permiso de Custom Publisher para hkdllgen.exe. Esta regla utiliza información del certificado de firma de código de Microsoft existente en el ejecutable para identificar y permitir versiones coincidentes de HkDllGen.

El tipo de regla de archivo Editor utiliza las propiedades de la cadena del certificado de firma de código como base para las reglas de archivo.

Después de seleccionar Crear regla, debería existir una única regla de Firma de Políticas.

Implemente su directiva de App Control. Consulte Implementación de directivas de App Control for Business.

Una vez creada la política, la nueva política se escribe en la ruta que se eligió como ubicación del archivo de política. La nueva versión binaria del nombre del archivo de política incluye la versión de política al final del nombre del archivo. Puedes copiar el <policy>.cip archivo al C:\Windows\System32\CodeIntegrity\CiPolicies\Active subdirectorio en la instancia de SQL Server.

Implementar manualmente una directiva de integridad de código

Para crear una política de Integridad del Código más ágil, puedes editar un archivo más genérico <policy>.xml que generes tras completar el Asistente de Política de Control de Aplicaciones WDAC. Este escenario puede ocurrir si no ejecutas el Asistente de Política de Control de Aplicaciones WDAC en un SQL Server, sino desde una estación de trabajo. Por ejemplo, un archivo de directiva de integridad de código menos personalizado podría ser similar al siguiente:

<?xml version="1.0" encoding="utf-8"?>
<SiPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="urn:schemas-microsoft-com:sipolicy" PolicyType="Base Policy">
  <VersionEx>10.0.5.0</VersionEx>
  <PlatformID>{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}</PlatformID>
  <PolicyID>{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}</PolicyID>
  <BasePolicyID>{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}</BasePolicyID>
  <Rules>
    <Rule>
      <Option>Enabled:Unsigned System Integrity Policy</Option>
    </Rule>
    <Rule>
      <Option>Enabled:UMCI</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Audit Mode</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Managed Installer</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Update Policy No Reboot</Option>
    </Rule>
  </Rules>
  <EKUs>
    <!--EKU ID-->
  </EKUs>
  <FileRules>
    <!--FileAttrib ID -->
  </FileRules>
  <Signers />
  <SigningScenarios>
    <SigningScenario ID="ID_SIGNINGSCENARIO_KMCI" FriendlyName="Kernel Mode Signing Scenario" Value="131">
      <ProductSigners />
    </SigningScenario>
    <SigningScenario ID="ID_SIGNINGSCENARIO_UMCI" FriendlyName="User Mode Signing Scenario" Value="12">
      <ProductSigners />
    </SigningScenario>
  </SigningScenarios>
  <UpdatePolicySigners />
  <HvciOptions>0</HvciOptions>
</SiPolicy>

Este ejemplo no tiene una regla de editor firmada y asume que el archivo de política utiliza un directorio de trabajo local (por ejemplo, C:\Temp) con un nombre de archivo de Hekaton_Custom_CIPolicy.xml.

$policyPath = 'C:\Temp\Hekaton_Custom_CIPolicy.xml'

# Create Windows Defender Application Control (WDAC)
# policy and set Option 13 (Enabled:Managed Installer)
# and Option 16 (Enabled:Update Policy No Reboot)
$policyIdParams = @{
    FilePath = $policyPath
    PolicyName = 'Hekaton Managed Installer Policy'
    ResetPolicyID = $true
}
Set-CIPolicyIdInfo @policyIdParams

$option13Params = @{
    FilePath = $policyPath
    Option = 13
}
Set-RuleOption @option13Params

$option16Params = @{
    FilePath = $policyPath
    Option = 16
}
Set-RuleOption @option16Params

# Retrieve the Policy ID from the App Control policy XML.
# Code Integrity uses this ID as the binary file name.
[xml]$AppControlPolicy = Get-Content -Path $policyPath
$PolicyID = $AppControlPolicy.SiPolicy.PolicyID
$PolicyBinary = $PolicyID + '.cip'

# Convert the App Control policy XML to binary format and
# save it into the Active Code Integrity path.
$convertParams = @{
    XmlFilePath = $policyPath
    BinaryFilePath = "C:\Windows\System32\CodeIntegrity\CiPolicies\Active\$PolicyBinary"
}
ConvertFrom-CIPolicy @convertParams

Para aplicar la directiva sin reiniciar el servidor y comprobar el estado de integridad de código, ejecute este script de PowerShell:

# Refresh the Code Integrity policy without a reboot of the system
$updateCiParams = @{
    Namespace  = 'root\Microsoft\Windows\CI'
    ClassName  = 'PS_UpdateAndCompareCIPolicy'
    MethodName = 'Update'
    Arguments  = @{ FilePath = "C:\Windows\System32\CodeIntegrity\CiPolicies\Active\$PolicyBinary" }
}
Invoke-CimMethod @updateCiParams

# View the current status of WDAC Code Integrity. If WDAC is in Audit mode
# the "UserModeCodeIntegrityPolicyEnforcementStatus" has a value of "1"
# for Audit mode. A value of "0" mean that Code Integrity is not active.
$deviceGuardParams = @{
    ClassName = 'Win32_DeviceGuard'
    Namespace = 'root\Microsoft\Windows\DeviceGuard'
}
Get-CimInstance @deviceGuardParams | Format-List *codeintegrity*

Compruebe que los archivos DLL de Hekaton generados son de confianza para la integridad de código.

Después de que la regla de instalador gestionado de AppLocker y los servicios requeridos de AppLocker estén activos, genera una nueva DLL OLTP In-Memory a través de HkDllGen. Windows rastrea el árbol de procesos HkDllGen y añade un $KERNEL.SMARTLOCKER.ORIGINCLAIM atributo extendido a los archivos creados por ese árbol de procesos.

Cuando Control de Aplicaciones opera en modo de auditoría o aplicación con Habilitado:Instalador Gestionado, Integridad del Código puede confiar en la DLL generada según su origen de instalador gestionado. Para verificar que se ha añadido el atributo extendido, selecciona una DLL recién generada de la \Data\xtp\<database_id> carpeta y ejecuta el siguiente comando desde un símbolo elevado:

fsutil file queryea "D:\SQL\MSSQL17.MSSQLSERVER\MSSQL\DATA\xtp\5\xtp_t_5_64719283_196202718557591_1.dll"

La presencia de $KERNEL.SMARTLOCKER.ORIGINCLAIM por sí sola no confirma que el archivo tenga un origen gestionado en el instalador. El mismo atributo extendido puede registrar el origen del Grafo de Seguridad Inteligente y cómo se heredó la confianza. En la primera fila de datos, 00 al principio de la segunda ULONG identifica el origen del instalador administrado, mientras que 01 identifica el origen del gráfico de seguridad inteligente. Para evaluar los valores restantes de notificación de origen, consulte la referencia técnica del instalador administrado y de ISG.

Quitar la función del Instalador Administrado

Para quitar la característica Instalador administrado del dispositivo, quite la directiva de AppLocker del Instalador administrado del dispositivo siguiendo las instrucciones de Eliminar una regla de AppLocker: borrar las directivas de AppLocker en un único sistema o en sistemas remotos.

Contenido relacionado

• Permitir automáticamente las aplicaciones implementadas por un instalador administrado con Control de aplicaciones para empresas
• Información general y escenarios de uso de OLTP en memoria
• Guía del procesamiento de consultas para tablas con optimización para memoria
• Base de datos de ejemplo para OLTP en memoria
• Guía de implementación de AppLocker
• Implementación de políticas de App Control para negocios