Como criar o Controlo de Aplicações OLTP na memória e políticas de instalador gerido

Aplica-se a:SQL Server

O SQL Server compila e liga uma biblioteca de ligação dinâmica (DLL) para cada tabela e procedimento armazenado compilado nativamente, contendo a implementação nativa desses objetos em código C. Embora In-Memory DLLs OLTP sejam geradas dinamicamente, os ficheiros podem apresentar desafios em ambientes onde é necessária a aplicação da integridade do código.

O que é o HkDllGen?

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

Para assegurar a integridade do código destas DLLs, utilize o AppLocker para designar o hkdllgen.exe assinado pela Microsoft como instalador gerido e ativar a confiança no Instalador Gerido na política App Control for Business, anteriormente Windows Defender Application Control (WDAC). O Windows regista então que as DLLs geradas vieram da árvore de processos HkDllGen, permitindo que o Controlo de Aplicações confie nelas com base na origem do seu instalador gerido.

O HkDllGen é o primeiro passo para cumprir os requisitos regulamentares que incluem integridade do código para In-Memory OLTP. Neste cenário, a integridade de código garante que o Windows pode 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 na forma como foi criado.

Como funciona um instalador gerenciado?

Um instalador gerido utiliza uma coleção especial de regras no AppLocker para designar binários que a 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 qualquer processo filho iniciado por ele) e observa os arquivos que estão sendo gravados no disco. À medida que os ficheiros são escritos, é adicionada uma declaração ou etiqueta ao ficheiro, indicando que ele provém de um instalador gerido.

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

Ao usar o AppLocker, o Controlo de Aplicações para Negócios (anteriormente Windows Defender Controlo de Aplicações, ou WDAC) pode ser configurado para confiar nos ficheiros instalados por um instalador gerido, adicionando a opção Enabled:Managed Installer a uma política de Controlo de Aplicações. Quando defines essa opção, o Controlo de Aplicações verifica a informação de origem gerida do instalador ao determinar se permite a execução de um binário. Contanto que não haja regras de negação para o binário, o Controle de Aplicativo permite que ele seja executado com base puramente em sua origem de instalador gerenciado. O AppLocker também controla a execução de ficheiros executáveis a que atribui a designação de instaladores geridos, mas não oferece uma cadeia de confiança para ficheiros executáveis e DLLs como o WDAC. Este artigo explica como designar e configurar o processo HkDllGen como um instalador gerido que tanto o AppLocker como o WDAC possam usar.

Habilite o gerador de DLL Hekaton

Exemplo

Este exemplo ativa o gerador de DLLs do Hekaton utilizando sp_configure com a opção external xtp dll gen util enabled. Crie uma base de dados de testes 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 dentro do 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 ficheiro é criado juntamente com cada DLL gerada pelo HkDllGen no <path-to-data-directory>\xtp\<database_id> subdiretório. Este ficheiro capta a saída do HkDllGen e normalmente tem comprimento zero após uma compilação bem-sucedida. A sua presença indica que o gerador externo foi invocado. As DLLs geradas não são assinadas por Authenticode. Para que o Windows confie nas DLLs geradas com base na sua origem, é necessário rastrear o Instalador Gerido e uma política de Controlo de Aplicações.

As DLLs existentes não recebem informação de origem gerida do instalador retroativamente. Gerar uma nova DLL depois de o rastreamento gerido do instalador estar ativo ao validar a política.

Passos para criar In-Memory OLTP AppLocker e políticas de instalador gerido

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 gerido. No entanto, pode usar um editor XML ou de texto para converter uma política de recolha de regras EXE numa coleção de regras de instalador gerida.

Os restantes exemplos neste artigo aplicam-se ao Windows Server 2022 e ao 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 AppLocker Control do servidor, execute o seguinte comando PowerShell:

Get-AppLockerPolicy -Effective

Ou, execute o seguinte comando para guardar a saída das políticas efetivas num ficheiro XML para visualização:

Get-AppLockerPolicy -Effective -Xml > effective_app_policy.xml

Os passos seguintes explicam o processo de criação e aplicação de uma política que pode ser aplicada a um servidor local. Uma política de instalador gerida que é gerada usando estes passos pode ser fundida numa política GPO e distribuída a todas as instâncias do SQL Server num ambiente, ou aplicada à política local de um único servidor. Deve trabalhar com um administrador de domínio para aplicar a política de Integridade de Código a 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 Hekaton usando o tipo de regra Publisher, mas podes usar qualquer tipo de regra AppLocker. Talvez seja necessário reformatar o resultado 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 a ManagedInstaller
   • EnforcementMode a AuditOnly
   • BinaryVersionRange LowSection para "*" e HighSection para "*"

   Mudança:

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

   Para:

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

   Mudança:

   <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. Pode importar a política AppLocker e implementá-la com a Estratégia de Grupo, ou usar um script para implementar a política com o Set-AppLockerPolicy cmdlet, como mostrado no seguinte 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. Se implementar a política do AppLocker com um script do PowerShell, use o utilitário appidtel.exe numa linha de comandos administrativa para configurar o serviço de Identidade da Aplicação do AppLocker e o controlador de filtro do AppLocker.

   appidtel.exe start [-mionly]
   

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

Para o Controlo de Aplicações do Windows Defender (WDAC) confiar nas DLLs geradas pelo processo hkdllgen.exe, especifique a opção Ativado: Instalador Gerido na sua política de Controlo de Aplicações. Defina esta 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 WDAC Base Policy Wizard.

A começar pela política padrão do Windows, proporciona menos opções, que são removidas neste guia. Para mais informações sobre as políticas de Modo Windows Padrão e Permitir Modo Microsoft, consulte o artigo Exemplo de Política de Base de Controlo de Aplicações para Negócios.

Política de modelo base

Depois de selecionar o modelo da base de políticas do Windows, nomeie a política e escolha onde guardar a política de Controlo de Aplicações no disco.

Selecione um tipo de política

Escolha o Formato de Múltiplas Apólices e a Política Base como tipo de apólice.

Configurar modelo de política

Ative apenas as opções de Instalador Gerido, Política de Atualização sem Reiniciar, Política de Integridade do Sistema Não Assinada e Política de Integridade do Código em Modo Utilizador . Desative as outras opções das regras de política. Para alterar as definições, selecione o botão deslizante ao lado dos títulos das regras da política.

A tabela seguinte 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 Modo de Auditoria inicialmente, pois ele permite testar novas políticas do Controle de Aplicativo para Empresas antes de aplicá-las. Com o modo de auditoria, nenhuma aplicação é bloqueada. Em vez disso, a política regista um evento sempre que uma aplicação fora da política começa. 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 permitir Custom Publisher para hkdllgen.exe. Esta 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 ficheiro do Publisher utiliza propriedades na cadeia de certificados de assinatura de código para formar a base das regras de ficheiro.

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

Implante sua política de Controle de Aplicativo. Consulte Implantando políticas do Controle de Aplicativo para Empresas.

Após a criação da política, a nova política é escrita no caminho escolhido como localização do ficheiro da política. A nova versão binária do nome do ficheiro de política inclui a versão da política no final do nome do ficheiro. Pode copiar o <policy>.cip ficheiro 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, pode editar um ficheiro mais genérico <policy>.xml que gera após completar o Assistente de Políticas de Controlo de Aplicações WDAC. Este cenário pode surgir se não executar o Assistente de Políticas de Controlo de Aplicações WDAC num SQL Server, mas sim numa estação de trabalho. Por exemplo, um arquivo de política de integridade de código menos personalizado pode se parecer com:

<?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 ficheiro de política utiliza um diretório de trabalho local (por exemplo, C:\Temp) com o nome de ficheiro 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 de a regra de Instalador Gerido do AppLocker e os serviços necessários do AppLocker estarem ativos, gere uma nova DLL In-Memory OLTP utilizando o HkDllGen. O Windows acompanha a árvore de processos HkDllGen e adiciona um $KERNEL.SMARTLOCKER.ORIGINCLAIM atributo estendido aos ficheiros criados por essa árvore de processos.

Quando o Controlo de Aplicações está a operar no modo de auditoria ou de imposição com Ativado: Instalador Gerido, a Integridade do Código pode confiar na DLL gerada devido à sua origem num instalador gerido. 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 comandos 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 sozinho não confirma que o ficheiro tenha origem de instalador gerido. O mesmo atributo estendido pode registar 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 Instalador Gerido, enquanto 01 identifica a origem do Grafo de Segurança Inteligente. Para avaliar os valores restantes da afirmação de origem, consulte a referência técnica do “Instalador Gerido” e do ISG.

Remover a funcionalidade Managed Installer

Para remover a funcionalidade Instalador Gerido do dispositivo, remova a política AppLocker do Instalador Gerido do dispositivo seguindo as instruções em Eliminar uma regra do AppLocker: Apagar políticas do AppLocker num único sistema ou em sistemas remotos.

Conteúdo relacionado

• Permitir automaticamente aplicações implementadas por um instalador gerido com o App Control for Business
• In-Memory visão geral do OLTP e cenários de uso
• Um guia para processamento de consultas para tabelas Memory-Optimized
• Base de dados de exemplo para OLTP em memória
• Guia de implantação do AppLocker
• Implantando políticas do App Control for Business