Guide pratique pour créer des stratégies de contrôle des applications OLTP et de programme d’installation managé en mémoire

S’applique à :SQL Server

SQL Server compile et lie une bibliothèque de liens dynamiques (DLL) pour chaque table et procédure stockée compilée nativement, contenant l’implémentation native de ces objets en code C. Bien que In-Memory DLL OLTP soient générés dynamiquement, ces fichiers peuvent poser des défis dans des environnements où l’application de l’intégrité du code est requise.

Qu’est-ce que HkDllGen ?

Dans SQL Server 2022 (16.x) à partir de la mise à jour cumulative 17 (Cumulative Update 17) et dans les versions ultérieures, la fonctionnalité OLTP en mémoire inclut le générateur de DLL Hekaton, ou HkDllGen. Sans HkDllGen, SQL Server génère du code source C à l’intérieur de sqlservr.exe et lance le compilateur, qui invoque l’éditeur de liens pour créer la DLL OLTP en mémoire. Avec la génération externe activée, SQL Server exporte les métadonnées sérialisées des objets et lance le fichier signé hkdllgen.exepar Microsoft . HkDllGen valide et importe ces métadonnées, génère le code source C dans son propre processus, puis lance le compilateur et le lien.

Pour garantir l’intégrité du code pour ces DLL, utilisez AppLocker pour désigner le Microsoft-signé hkdllgen.exe comme un installateur géré et permettre la confiance des installateurs gérés dans la politique App Control for Business, anciennement Windows Defender Application Control (WDAC). Windows enregistre alors que les DLL générées proviennent de l’arbre de processus HkDllGen, permettant à App Control de leur faire confiance en fonction de leur origine d’installateur géré.

HkDllGen est la première étape vers le respect des exigences réglementaires incluant l’intégrité du code pour In-Memory OLTP. Dans ce scénario, l’intégrité du code garantit que Windows peut établir une origine de confiance pour chaque DLL générée et évaluer cette confiance lors du chargement de SQL Server. La DLL générée n’est pas signée par Authenticode. Windows lui fait confiance en fonction de la façon dont il a été créé.

Comment fonctionne un programme d’installation managé ?

Un installateur géré utilise une collection de règles spéciale dans AppLocker pour désigner des binaires que votre organisation a de confiance comme source autorisée pour l’installation d’applications. Quand l’un de ces fichiers binaires approuvés s’exécute, Windows surveille le processus du binaire (et tous les processus enfants qu’il lance) et surveille les fichiers écrits sur le disque. À mesure que les fichiers sont écrits, une revendication ou une balise est ajoutée au fichier comme provenant d’un programme d’installation managé.

L’indication d’origine est un attribut étendu géré par le noyau. Ce n’est pas une signature Authenticode et ne change pas le statut de l’éditeur ou de la signature de la DLL générée.

En utilisant AppLocker, App Control for Business (anciennement Windows Defender Application Control, ou WDAC) peut être configuré pour faire confiance aux fichiers qu’un installateur géré installe en ajoutant l’option Enabled :Managed Installer à une politique de contrôle d’applications. Lorsque vous activez cette option, App Control vérifie les informations d’origine des installateurs gérés lorsqu’il faut autoriser l’exécution d’un binaire. Tant qu’il n’existe aucune règle de refus pour le fichier binaire, App Control lui permet d’exécuter uniquement en fonction de son origine d’installation managée. AppLocker contrôle également l’exécution des fichiers exécutables qu’il désigne comme installateur géré, mais il n’offre pas de chaîne de confiance pour les exécutables et DLL comme WDAC. Cet article explique comment désigner et configurer le processus HkDllGen comme un installateur géré que les deux AppLocker et WDAC peuvent utiliser.

Activer le générateur de DLL Hekaton

Exemple

Cet exemple permet de générer des DLL Hekaton en utilisant sp_configure avec l’option external xtp dll gen util enabled . Créez une base de données de test et une table optimisée pour la mémoire de test.

1. Créez une base de données de test.

   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. Créez une table de test dans la base de données de test.

   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. Un .gen fichier est créé à côté de chaque DLL générée via HkDllGen dans le <path-to-data-directory>\xtp\<database_id> sous-répertoire. Ce fichier capture la sortie de HkDllGen et est normalement de longueur nulle après une compilation réussie. Sa présence indique que le générateur externe a été invoqué. Les DLL générées ne sont pas signées par Authenticode. Pour que Windows fasse confiance aux DLL générées en fonction de leur origine, il faut un suivi géré des installateurs et une politique de contrôle d’application.

Les DLL existantes ne reçoivent pas rétroactivement les informations d’origine de l’installateur géré. Générez une nouvelle DLL après que le suivi géré de l’installateur soit actif lors de la validation de la politique.

Étapes pour créer In-Memory AppLocker OLTP et des politiques d’installateur gérées

Vous ne pouvez pas utiliser l’interface de création de politiques AppLocker dans GPO Editor (gpedit.msc) ni les cmdlets PowerShell d’AppLocker pour créer des règles pour la collection de règles des installateurs gérés. Cependant, vous pouvez utiliser un éditeur XML ou texte pour convertir une politique de collection de règles EXE en une collection de règles d’installateur gérée.

Les autres exemples de cet article concernent Windows Server 2022 et Windows 11 et versions ultérieures.

Pour vérifier qu’au moins une collection de règles exe existe dans la configuration de politique AppLocker Control du serveur, exécutez la commande PowerShell suivante :

Get-AppLockerPolicy -Effective

Ou bien, exécutez la commande suivante pour enregistrer la sortie des politiques effectives dans un fichier XML pour consultation :

Get-AppLockerPolicy -Effective -Xml > effective_app_policy.xml

Les étapes suivantes expliquent le processus de création et d’application d’une politique que vous pouvez appliquer à un serveur local. Une politique d'installateur gérée générée à partir de ces étapes peut être fusionnée en une politique GPO et distribuée à toutes les instances de SQL Server dans un environnement, ou appliquée à la politique locale d'un seul serveur. Vous devriez travailler avec un administrateur de domaine pour appliquer la politique d’intégrité du code au niveau du domaine.

1. Utilisez new-AppLockerPolicy pour créer une règle EXE pour le fichier que vous concevez en tant que programme d’installation managé. Cet exemple crée une règle pour le générateur de DLL Hekaton en utilisant le type de règle Publisher, mais vous pouvez utiliser n’importe quel type de règle AppLocker. Vous devrez peut-être reformater la sortie pour la lisibilité.

   # 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. Modifiez manuellement le AppLocker_HkDllGen_Policy.xml et modifiez les valeurs d’attribut suivantes :

   • RuleCollection Type sur ManagedInstaller
   • EnforcementMode sur AuditOnly
   • BinaryVersionRange LowSection à "*" et HighSection à "*"

   Modifier :

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

   vers :

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

   Modifier :

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

   vers :

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

3. Déployez la stratégie de configuration du programme d’installation managée AppLocker. Vous pouvez soit importer la politique AppLocker et la déployer avec la Stratégie de Groupe, soit utiliser un script pour déployer la politique avec le Set-AppLockerPolicy cmdlet comme montré dans la commande PowerShell suivante.

   #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 vous déployez la politique AppLocker avec un script PowerShell, utilisez l’utilitaire appidtel.exe d’une invite de commande administrative pour configurer le service d’identité d’application AppLocker et le pilote de filtre AppLocker.

   appidtel.exe start [-mionly]
   

Activer l’option Programme d’installation managé dans l’Assistant Contrôle d’application Windows Defender pour entreprise

Pour que Windows Defender Contrôle d’application (WDAC) fasse confiance aux DLL générées par le hkdllgen.exe processus, spécifiez l’option Activé : Installateur géré dans votre politique de contrôle d’application. Définissez ce paramètre en utilisant le cmdletSet-RuleOption avec l’option 13.

Générez un fichier de stratégie d’intégrité du code à partir d’un des modèles de stratégie de base Assistant d’application de stratégies de base WDAC.

À partir de la version Windows par défaut, la stratégie propose moins d’options, qui sont supprimées dans ce guide. Pour plus d’informations sur les politiques de mode Windows par défaut et Permettre le mode Microsoft, voir l’article Exemple de politique de base de contrôle d’application pour entreprise.

Stratégie de modèle de base

Après avoir sélectionné le modèle de la base de politique Windows, nommez la politique et choisissez où sauvegarder la politique de contrôle d’application sur le disque.

Sélectionner un type de stratégie

Choisissez Format de stratégie multiple et Stratégie de base comme type de stratégie.

Configurer un modèle de stratégie

Activez uniquement les options de règles de l’Installateur Géré, Politique de mise à jour sans redémarrage, Politique d’intégrité système non signée et politique d’intégrité du code en mode utilisateur . Désactivez les autres options de règle de stratégie. Pour modifier les paramètres, sélectionnez le bouton curseur à côté des titres des règles de politique.

Le tableau suivant décrit chaque règle de politique, en commençant par la colonne la plus à gauche. L’article sur les règles de politique fournit une description plus détaillée de chaque règle de politique.

Vous devez activer mode audit initialement, car il vous permet de tester les nouvelles stratégies App Control for Business avant de les appliquer. Avec le mode audit, aucune application n’est bloquée. À la place, la politique enregistre un événement chaque fois qu’une application extérieure à la politique démarre. Pour cette raison, tous les modèles ont le mode d’audit activé par défaut.

Règles de fichier

Supprimez toutes les règles de signature de stratégie de la liste.

(Optionnel) Ajouter une règle d’autorisation d’éditeur personnalisé pour hkdllgen.exe. Cette règle utilise les informations du certificat de signature de code Microsoft existant de l'exécutable pour identifier et permettre la correspondance des versions de HkDllGen.

Le type de règle de fichier Publisher utilise des propriétés dans la chaîne de certificats de signature de code pour baser les règles de fichier.

Après avoir sélectionné Créer une règle, une seule règle de signature de politique devrait exister.

Déployez votre stratégie App Control. Consultez Déploiement des stratégies du Contrôle des applications pour entreprise.

Après la création de la politique, la nouvelle politique est écrite sur le chemin choisi comme emplacement du fichier de politique. La nouvelle version binaire du nom du fichier de politique inclut la version de la politique à la fin du nom du fichier. Vous pouvez copier le <policy>.cip fichier dans le C:\Windows\System32\CodeIntegrity\CiPolicies\Active sous-répertoire de l’instance SQL Server.

Déployer manuellement une stratégie d’intégrité du code

Pour créer une politique d’intégrité du code plus simplifiée, vous pouvez modifier un fichier plus générique <policy>.xml que vous générez après avoir complété l’Assistant de politique de contrôle d’application WDAC. Ce scénario peut survenir si vous ne lancez pas l'Assistant de politique de contrôle d'application WDAC sur un SQL Server, mais depuis un poste de travail. Par exemple, un fichier de stratégie d’intégrité du code moins personnalisé peut ressembler à ceci :

<?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>

Cet exemple ne possède pas de règle de publication signée et suppose que le fichier de politique utilise un répertoire de travail local (par exemple, C:\Temp) avec un nom de fichier .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

Pour appliquer la stratégie sans redémarrer le serveur et vérifier l’état de l’intégrité du code, exécutez ce script 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*

Vérifiez que les DLL Hekaton générées sont approuvées par l’intégrité du code

Après que la règle AppLocker Managed Installer et les services AppLocker requis soient actifs, générez une nouvelle DLL OLTP In-Memory via HkDllGen. Windows suit l’arbre de processus HkDllGen et ajoute un $KERNEL.SMARTLOCKER.ORIGINCLAIM attribut étendu aux fichiers créés par cet arbre.

Lorsque App Control fonctionne en mode audit ou application avec Enabled :Managed Installer, Code Integrity peut faire confiance à la DLL générée en fonction de son origine d’installateur géré. Pour vérifier que l’attribut étendu a été ajouté, sélectionnez une nouvelle DLL générée dans le \Data\xtp\<database_id> dossier et exécutez la commande suivante depuis une invite de commande élevée :

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

La simple présence de $KERNEL.SMARTLOCKER.ORIGINCLAIM ne confirme pas que le fichier a une origine d’installateur géré. Le même attribut étendu peut enregistrer l’origine de l’Intelligent Security Graph et la manière dont la confiance a été héritée. Dans la première ligne de données, 00 au début du second ULONG indique l’origine du programme d’installation géré, tandis que 01 indique l’origine du Graphe de sécurité intelligent. Pour évaluer les valeurs de revendication d’origine restantes, consultez la référence technique de Managed Installer et d’ISG.

Supprimer la fonctionnalité Programme d’installation managée

Pour supprimer de l’appareil la fonctionnalité de programme d’installation géré, supprimez de l’appareil la stratégie AppLocker du programme d’installation géré en suivant les instructions dans Supprimer une règle AppLocker : Effacer les stratégies AppLocker sur un seul système ou sur des systèmes distants.

Contenu connexe

• Autoriser automatiquement les applications déployées par un programme d’installation managé avec Contrôle des applications pour entreprise
• Vue d’ensemble et scénarios d’utilisation d’OLTP en mémoire
• Guide du traitement des requêtes pour les tables à mémoire optimisées
• Exemple de base de données pour OLTP en mémoire
• Guide de déploiement d’AppLocker
• Déploiement des stratégies du Contrôle des applications pour entreprise