Como criar políticas de Controle de Aplicativos para OLTP na memória e de instalador gerenciado

Aplica-se a:SQL Server

O SQL Server compila e vincula uma biblioteca de enlace dinâmico (DLL) para cada tabela e procedimento armazenado compilados nativamente, contendo a implementação nativa desses objetos em código C. Embora as DLLs do OLTP In-Memory sejam geradas dinamicamente, os arquivos podem apresentar desafios em ambientes em que a imposição da integridade de código é exigida.

O que é HkDllGen?

No SQL Server 2022 (16.x) Atualização Cumulativa 17 e em versões posteriores, o recurso In-Memory OLTP inclui o gerador de DLL Hekaton, ou HkDllGen. Sem o HkDllGen, o SQL Server gera o código-fonte C dentro de sqlservr.exe e inicia o compilador, que invoca o ligador para criar a DLL de OLTP na memória. Com a geração externa ativada, o SQL Server exporta metadados serializados de objetos e lança o arquivo assinado hkdllgen.exepela Microsoft . O HkDllGen valida e importa esses metadados, gera o código-fonte em C em seu próprio processo e lança o compilador e o linker.

Para garantir a integridade do código para essas DLLs, use o AppLocker para designar o instalador Microsoft-assinado hkdllgen.exe como um instalador gerenciado e habilitar a confiança do Instalador Gerenciado na política de Controle de Aplicativos para Negócios, anteriormente Windows Defender Controle de Aplicações (WDAC). O Windows então registra que as DLLs geradas vieram da árvore de processos HkDllGen, permitindo que o App Control confie nelas com base na origem gerenciada do instalador.

O HkDllGen é o primeiro passo para cumprir requisitos regulatórios que incluem integridade do código para In-Memory OLTP. Nesse cenário, a integridade do código garante que o Windows possa estabelecer uma origem confiável para cada DLL gerada e avaliar essa confiança quando o SQL Server a carregar. A DLL gerada não é assinada pelo Authenticode. O Windows confia nele com base em como foi criado.

Como funciona um instalador gerenciado?

Um instalador gerenciado utiliza uma coleção especial de regras no AppLocker para designar binários que sua organização confia como fonte autorizada para instalação de aplicações. Quando um desses binários confiáveis é executado, o Windows monitora o processo do binário (e todos os processos filho que ele inicia) e observa os arquivos que estão sendo gravados em disco. À medida que os arquivos são escritos, uma identificação ou etiqueta é adicionada ao arquivo, indicando sua origem a partir de um instalador gerenciado.

A reivindicação de origem é um atributo estendido gerenciado pelo kernel. Não é uma assinatura Authenticode e não altera o status de publicador ou assinatura da DLL gerada.

Ao usar o AppLocker, o Controle de Aplicativos para Negócios (anteriormente Windows Defender Controle de Aplicações, ou WDAC) pode ser configurado para confiar nos arquivos instalados por um instalador gerenciado, adicionando a opção Habilitado:Instalador Gerenciado a uma política de Controle de Aplicativos. Quando você configura essa opção, o App Control verifica informações gerenciadas de origem do instalador ao determinar se permite a execução de um binário. Desde que não haja regras de negação para o binário, o Controle de Aplicativo permite que ele seja executado com base apenas na origem do instalador gerenciado. O AppLocker também controla a execução de arquivos executáveis designados por ele como instaladores gerenciados, mas não oferece uma cadeia de confiança para executáveis e DLLs como o WDAC. Este artigo explica como designar e configurar o processo HkDllGen como um instalador gerenciado que tanto o AppLocker quanto o WDAC podem usar.

Habilitar o gerador de DLL Hekaton

Exemplo

Este exemplo habilita o gerador de DLL Hekaton usando sp_configure com a external xtp dll gen util enabled opção. Crie um banco de dados de teste e uma tabela otimizada para memória de teste.

1. Crie um banco de dados de teste.

   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. Crie uma tabela de teste no banco de dados de teste.

   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. Um .gen arquivo é criado junto com cada DLL gerada pelo HkDllGen no <path-to-data-directory>\xtp\<database_id> subdiretório. Este arquivo captura a saída do HkDllGen e normalmente tem comprimento zero após uma compilação bem-sucedida. Sua presença indica que o gerador externo foi invocado. As DLLs geradas não são assinadas pelo Authenticode. Para o Windows confiar nas DLLs geradas com base em sua origem, você precisa de rastreamento de Instaladores Gerenciados e uma política de Controle de Aplicativos.

DLLs existentes não recebem informações gerenciadas de origem do instalador retroativamente. Gerar uma nova DLL após o rastreamento gerenciado do instalador estar ativo ao validar a política.

Etapas para criar In-Memory OLTP AppLocker e políticas de instalador gerenciado

Você não pode usar a interface de criação de políticas do AppLocker no GPO Editor (gpedit.msc) nem os comandos PowerShell do AppLocker para criar regras para a coleção de regras do instalador gerenciado. No entanto, você pode usar um editor XML ou de texto para converter uma política de coleta de regras EXE em uma coleção de regras gerenciada para instaladores.

Os demais exemplos neste artigo se aplicam ao Windows Server 2022 e Windows 11 e versões posteriores.

Para verificar se existe pelo menos uma coleção de regras exe dentro da configuração da política de Controle do AppLocker do servidor, execute o seguinte comando PowerShell:

Get-AppLockerPolicy -Effective

Ou, execute o seguinte comando para salvar a saída das políticas efetivas em um arquivo XML para visualização:

Get-AppLockerPolicy -Effective -Xml > effective_app_policy.xml

Os passos a seguir explicam o processo de criação e aplicação de uma política que você pode aplicar a um servidor local. Uma política de instalador gerenciada gerada usando essas etapas pode ser incorporada em uma política GPO e distribuída para todas as instâncias do SQL Server dentro de um ambiente, ou aplicada à política local de um único servidor. Você deve trabalhar com um administrador de domínio para aplicar a política de Integridade de Código no nível do domínio.

1. Use New-AppLockerPolicy para criar uma regra EXE para o arquivo que você está designando como um instalador gerenciado. Este exemplo cria uma regra para o gerador de DLLs do Hekaton usando o tipo de regra Publisher, mas você pode usar qualquer tipo de regra do AppLocker. Talvez seja necessário reformatar a saída para melhorar a legibilidade.

   # 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 o AppLocker_HkDllGen_Policy.xml e altere os seguintes valores de atributo:

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

   Alteração:

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

   para:

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

   Alteração:

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

   para:

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

3. Implante a política de configuração do instalador gerenciado do AppLocker. Você pode importar a política do AppLocker e implantá-la com a Diretiva de Grupo, ou usar um script para implantar a política com o Set-AppLockerPolicy cmdlet, conforme mostrado no comando PowerShell a seguir.

   #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. Se você implantar a política do AppLocker com um script do PowerShell, use o utilitário appidtel.exe em um Prompt de Comando administrativo para configurar o serviço Identidade de Aplicativo do AppLocker e o driver de filtro do AppLocker.

   appidtel.exe start [-mionly]
   

Habilitar a opção de instalador gerenciado no Assistente de Controle de Aplicativos do Windows Defender para Empresas

Para Windows Defender Controle de Aplicações (WDAC) confiar nas DLLs geradas pelo hkdllgen.exe processo, especifique a opção Habilitado: Instalador Gerenciado na sua política de Controle de Aplicativos. Defina essa configuração usando o cmdletSet-RuleOption com a Opção 13.

Gere um arquivo de política de integridade de código a partir de uma das políticas base de modelo do WDAC Base Policy Wizard.

Começar com a política padrão do Windows oferece menos opções, que são removidas neste guia. Para mais informações sobre as políticas de modo padrão do Windows e Permitir o modo Microsoft, consulte o artigo sobre políticas base do App Control for Business de exemplo.

Política de modelo base

Depois de selecionar o modelo da base de políticas do Windows, nomeie a política e escolha onde salvar a política de Controle de Aplicativos no disco.

Selecionar um tipo de política

Escolha Multiple Policy Format e Base Policy como o tipo de política.

Configurar o modelo de política

Ative apenas as opções de regra de política Instalador Gerenciado, Política de Atualização sem Reinicialização, Política de Integridade do Sistema sem Assinatura e Integridade de Código no Modo de Usuário. Desative as outras opções de regra de política. Para alterar as configurações, selecione o botão deslizante ao lado dos títulos das regras de política.

A tabela a seguir descreve cada regra de política, começando pela coluna mais à esquerda. O artigo sobre regras de política fornece uma descrição mais detalhada de cada regra de política.

Você deve habilitar o modo de auditoria inicialmente, pois ele permite testar novas políticas de Controle de Aplicativo para Empresas antes de aplicá-las. No modo de auditoria, nenhuma aplicação é bloqueada. Em vez disso, a política registra um evento sempre que uma aplicação fora da política é iniciada. Por esse motivo, todos os modelos têm o Modo de Auditoria habilitado por padrão.

Regras de arquivo

Remova todas as Regras de Assinatura de Política da lista.

(Opcional) Adicionar uma regra de permissão do Custom Publisher para hkdllgen.exe. Essa regra utiliza informações do certificado de assinatura de código da Microsoft existente no executável para identificar e permitir versões correspondentes do HkDllGen.

O tipo de regra de arquivo do Editor utiliza propriedades da cadeia de certificados de assinatura de código para definir as regras de arquivo.

Depois de selecionar Criar Regra, deve existir uma única regra de Assinatura de Política.

Implante sua política de Controle de Aplicativo. Consulte Implantar políticas do App Control for Business.

Após a criação da política, a nova política é escrita no caminho escolhido como localização do arquivo de política. A nova versão binária do nome do arquivo de política inclui a versão da política no final do nome do arquivo. Você pode copiar o <policy>.cip arquivo para o C:\Windows\System32\CodeIntegrity\CiPolicies\Active subdiretório na instância do SQL Server.

Implantar manualmente uma política de integridade de código

Para criar uma política de Integridade do Código mais simplificada, você pode editar um arquivo mais genérico <policy>.xml que gera após completar o Assistente de Políticas de Controle de Aplicativos WDAC. Esse cenário pode ocorrer se você não executar o Assistente de Política de Controle de Aplicativos WDAC em um SQL Server, mas em uma estação de trabalho. Por exemplo, um arquivo de política de integridade de código menos personalizado pode ser semelhante a:

<?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 exemplo não tem uma regra de editor assinada e pressupõe que o arquivo de política use um diretório de trabalho local (por exemplo, C:\Temp) com um nome de arquivo 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 a política sem reinicializar o servidor e verificar o status da Integridade do Código, execute este script do 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*

Verifique se as DLLs Hekaton geradas são confiáveis pela Integridade do Código

Depois que a regra de Instalador Gerenciado do AppLocker e os serviços necessários do AppLocker estiverem ativos, gere uma nova DLL OLTP em memória usando o HkDllGen. O Windows rastreia a árvore de processos HkDllGen e adiciona um $KERNEL.SMARTLOCKER.ORIGINCLAIM atributo estendido aos arquivos criados por essa árvore de processos.

Quando o App Control está operando no modo de auditoria ou de imposição com Enabled:Managed Installer, a Integridade de Código pode considerar a DLL gerada como confiável com base em sua origem de instalador gerenciado. Para verificar se o atributo estendido foi adicionado, selecione uma DLL recém-gerada da \Data\xtp\<database_id> pasta e execute o seguinte comando a partir de um prompt de comando elevado:

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

A presença de $KERNEL.SMARTLOCKER.ORIGINCLAIM sozinha não confirma que o arquivo tem origem de instalador gerenciado. O mesmo atributo estendido pode registrar a origem do Grafo de Segurança Inteligente e como a confiança foi herdada. Na primeira linha de dados, 00 no início da segunda ULONG identifica a origem do Managed Installer, enquanto 01 identifica a origem do Intelligent Security Graph. Para avaliar os valores restantes da declaração de origem, consulte a referência técnica do Instalador Gerenciado e do ISG.

Remover o recurso Instalador Gerenciado

Para remover o recurso de Instalador Gerenciado do dispositivo, remova a política de Instalador Gerenciado do AppLocker do dispositivo seguindo as instruções da regra Excluir um AppLocker: Limpar políticas do AppLocker em um único sistema ou sistemas remotos.

Conteúdo relacionado

• Permitir automaticamente aplicativos implantados por um instalador gerenciado com o Controle de Aplicativos para Empresas
• Visão geral e cenários de uso do OLTP in-memory
• Um guia para processamento de consulta de tabelas com otimização de memória
• Banco de dados de exemplo para OLTP na memória
• Guia de implantação do AppLocker
• Implantação de políticas do Controle de Aplicativos para Negócios