Partager via


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 compilée native et procédure stockée qui a l’implémentation native de ces objets dans le code C. Bien que les DLL OLTP In-Memory soient générées dynamiquement, les fichiers eux-mêmes peuvent fournir des défis lorsqu’il existe des exigences de conformité qui ont une application de l’intégrité du code comme critère.

Qu’est-ce que HKDLLGEN ?

Dans SQL Server 2022 (16.x) Mise à jour cumulative 17 et versions ultérieures, un composant appelé générateur de DLL Hekaton a été ajouté à la fonctionnalité OLTP In-Memory. Sans le nouveau processus de génération de DLL Hekaton (hkdllgen), le processus SQL Server principal convertit T-SQL en code C, puis lance les processus du compilateur et de l’éditeur de liens pour générer des DLL OLTP non signées In-Memory. Hkdllgen, en tant qu’application intermédiaire, valide et accepte la sortie de SQL Server, puis crée DLL signées. Pour appliquer des stratégies d’intégrité du code pour ces DLL, le processus de Hkdllgen doit être désigné comme Windows Defender Application Control (WDAC) Managed Installer.

Le générateur DLL Hekaton est la première étape pour garantir que les exigences de conformité réglementaire telles que l’intégrité du code peuvent être satisfaites avec In-Memory DLL générées par OLTP. L’intégrité du code dans ce contexte garantit que les DLL qui In-Memory OLTP générées sont approuvées par le système d’exploitation à partir du moment où elles sont créées jusqu’à ce qu’elles soient chargées et exécutées. La possibilité de désigner le composant générateur de DLL Hekaton en tant que programme d’installation managé permet au système d’intégrité du code WDAC d’approuver les DLL générées et de les utiliser.

Comment fonctionne un programme d’installation managé ?

Le programme d’installation managé utilise une collection de règles spéciale dans AppLocker pour désigner des fichiers binaires approuvés par votre organisation comme source autorisée pour l’installation de l’application. 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é.

Avec AppLocker, WDAC App Control peut être configuré pour approuver les fichiers installés par un programme d’installation géré en ajoutant l’option Enabled :Managed Installer à une stratégie App Control. Lorsque cette option est définie, App Control vérifie les informations d’origine du programme d’installation managée lors de la détermination de l’exécution ou non d’un fichier 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 de fichiers exécutables désignés comme programme d’installation managé, mais il n’offre pas de chaîne d’approbation pour les exécutables et les DLL comme WDAC. Dans cet article, nous allons découvrir comment désigner et configurer le processus de hkdllgen en tant que programme d’installation managé qui peut être utilisé par AppLocker et WDAC.

Activer le générateur de DLL Hekaton

Exemple

Dans cet exemple, sp_configure est utilisé pour activer l’option de générateur de DLL Hekaton, appelée external xtp dll gen util enabled. Une base de données de test est créée, ainsi qu’une table optimisée en 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 nouveau fichier de longueur nulle avec une extension .gen est généré pour chaque .dll dans le sous-répertoire <path-to-data-directory>\xtp\<database_id>. Les DLL sont maintenant signées.

Étapes pour créer des stratégies AppLocker OLTP et de programme d’installation managé en mémoire

L’interface utilisateur de création de stratégie AppLocker dans l’éditeur GPO (gpedit.msc) et les cmdlets PowerShell AppLocker ne peuvent pas être utilisées directement afin de créer des règles pour la collecte de règles du programme d’installation managé. Toutefois, vous pouvez utiliser un éditeur XML ou de texte pour convertir une stratégie de collection de règles EXE en collection de règles ManagedInstaller.

Essentiel

Une stratégie AppLocker doit exister avant d’ajouter l’exécutable de génération de DLL Hekaton à la configuration de la stratégie de contrôle AppLocker des serveurs, sinon, il existe un risque que les fonctions de base du système d’exploitation puissent être bloquées par Windows Defender. Pour plus d’informations sur la création, le test et la maintenance des stratégies de contrôle d’application, consultez le guide de déploiement AppLocker.

Les autres exemples s’appliquent à 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 des stratégies de contrôle AppLocker sur les serveurs, exécutez la commande PowerShell suivante :

Get-AppLockerPolicy -Effective

Ou pour enregistrer la sortie des stratégies effectives dans un fichier XML pour l’affichage :

Get-AppLockerPolicy -Effective -Xml > effective_app_policy.xml

Les étapes suivantes vous guident tout au long du processus de création et d’application d’une stratégie qui peut être appliquée à un serveur local. Une stratégie d’installation managée générée à l’aide de ces étapes peut être fusionnée dans une stratégie à l’échelle de la GPO et distribuée à tous les serveurs SQL au sein d’un environnement, ou appliquée à la stratégie locale d’un seul serveur. Nous vous recommandons d’utiliser un administrateur de domaine pour que la stratégie d’intégrité du code soit appliquée à partir du 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 DLL Hekaton à l’aide du type de règle Publisher, mais tout type de règle AppLocker peut être utilisé. 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
    $SQLPath = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\MSSQLServer\Setup' -Name 'SQLPath'
    $FullPath = Join-Path -Path $SQLPath.SQLPath -ChildPath 'Binn\xtp'
    
    # Set an environment variable for the In-memory OLTP Path
    [System.Environment]::SetEnvironmentVariable('SQLPathWithXtp', $FullPath, 'Process')
    
    # Generate an AppLocker Policy for the HKDLLGEN.EXE in the current working directory. The Get-AppLockerFileInformation cmdlet will extract the    executables publisher information as well as generate a hash for the binary.
    Get-ChildItem -Path ${env:SQLPathWithXtp}'.\hkdllgen.exe' | Get-AppLockerFileInformation | New-AppLockerPolicy -RuleType Publisher -User Everyone    -Xml > 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 à "*"

    Changez :

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

    vers :

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

    Modifier :

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

    en :

    <BinaryVersionRange LowSection="*" HighSection="*"/>
    
  3. Déployez la stratégie de configuration du programme d’installation managée AppLocker. Vous pouvez importer la stratégie AppLocker et le déployer avec la stratégie de groupe ou utiliser un script pour déployer la stratégie avec l’applet de commande Set-AppLockerPolicy, comme indiqué 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 stratégie AppLocker via un script PowerShell, utilisez l’utilitaire appidtel.exe à partir d’une invite de commandes d’administration pour configurer le service AppLocker Application Identity 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 le Contrôle d’application Windows Defender (WDAC) fasse confiance aux DLL générées par le processus hkdllgen.exe, l’option Activé : programme d’installation managé doit être spécifiée dans votre stratégie de contrôle d’application. Ce paramètre peut être défini à l’aide de l’applet de commande Set-RuleOption avec l’option 13.

Générez un fichier de stratégie d’intégrité du code à partir de l’une des stratégies basées sur l’Assistant d’application de stratégies de base WDAC.

À partie de la version Windows par défaut, la stratégie propose moins d’options, qui sont supprimées dans ce guide. Vous trouverez plus d’informations sur le mode Windows par défaut et autoriser les stratégies en mode Microsoft via l’article Exemple de contrôle d’application pour les stratégies de base d’entreprise.

Stratégie de modèle de base

Capture d’écran de Modèle de base WDAC.

Une fois le modèle de base de stratégie Windows sélectionné, attribuez un nom à la stratégie et choisissez où enregistrer la stratégie App Control sur le disque.

Sélectionner un type de stratégie

Choisissez le format de stratégie multiple et stratégie de base comme type de stratégie

capture d’écran de la fenêtre Sélectionner le type de stratégie WDAC.

Configurer un modèle de stratégie

Activez uniquement les options de règles de l'installateur géré, de politique de mise à jour sans redémarrage, de politique d'intégrité du système non signée et de politique d'intégrité du code en mode utilisateur. Désactivez les autres options de règle de stratégie. Pour ce faire, appuyez sur le bouton curseur en regard des titres des règles de stratégie.

Le tableau suivant contient une description de chaque règle de stratégie, en commençant par la colonne la plus à gauche. L’article règles de stratégie fournit une description plus complète de chaque règle de stratégie.

Option de règle Description
Installateur géré Utilisez cette option pour autoriser automatiquement les applications installées par une solution de distribution de logiciels, comme le générateur DE DLL Hekaton, qui a été défini comme programme d’installation managé.
stratégie de mise à jour sans redémarrage Utilisez cette option pour autoriser les futures mises à jour de stratégie App Control for Business à appliquer sans nécessiter de redémarrage du système.
Stratégie d’intégrité du système non signée Permet à la stratégie de rester non signée. Lorsque cette option est supprimée, la stratégie doit être signée et updatePolicySigners est ajoutée à la stratégie pour activer les futures modifications de stratégie.
Intégrité du Code en Mode Utilisateur Les stratégies App Control for Business limitent les fichiers binaires en mode noyau et en mode utilisateur. Par défaut, seuls les fichiers binaires en mode noyau sont restreints. L’activation de cette option de règle valide les exécutables et les scripts en mode utilisateur.

capture d’écran de l’écran de configuration du modèle de stratégie.

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 d’audit, aucune application n’est bloquée au lieu de cela, la stratégie journalise un événement chaque fois qu’une application en dehors de la stratégie est démarrée. 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.

capture d’écran de l’écran Règles de fichier WDAC.

(facultatif) Ajouter une règle de politique d'éditeur personnalisée qui garantit que les fichiers tels que hkdllgen.exe seront signés comme publiés par un éditeur.

Capture d’écran de l’écran de stratégie personnalisée WDAC.

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.

Capture d’écran de Règle de stratégie WDAC.

Après avoir sélectionné le bouton Créer une règle, une seule règle de signature de politique devrait être présente.

Capture d’écran de la fenêtre de la liste des règles de signature de politique WDAC.

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

Une fois la politique créée, la nouvelle politique est enregistrée à l'emplacement du fichier de politique choisi. La nouvelle version binaire du nom de fichier de stratégie comporte la version de la stratégie à la fin du nom de fichier. Le fichier .cip de la stratégie peut être copié dans le sous-répertoire C:\Windows\System32\CodeIntegrity\CiPolicies\Active sur l’instance de SQL Server.

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

Pour pouvoir créer une stratégie d’intégrité du code plus simple, un fichier policy.xml plus générique qui a été généré une fois l’Assistant Application de stratégies de contrôle des applications WDAC terminé peut être modifié. Ce scénario peut survenir si l’Assistant d’application de stratégies de contrôle des applications WDAC n’est pas exécuté sur SQL Server, mais à partir d’une station 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 n’a pas de règle d’éditeur signé et suppose que le fichier de stratégie utilise un répertoire de travail local (par exemple, C:\Temp) avec un nom de fichier de 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)
Set-CIPolicyIdInfo -FilePath C:\Temp\Hekaton_Custom_CIPolicy.xml -PolicyName "Hekaton Managed Installer Policy" -ResetPolicyID
Set-RuleOption -FilePath C:\Temp\Hekaton_Custom_CIPolicy.xml -Option 13
Set-RuleOption -FilePath C:\Temp\Hekaton_Custom_CIPolicy.xml -Option 16

# The App Control policy XML file in this example is located in the C:\Temp directory.
$AppControlPolicyXMLFile = 'C:\Temp\test\Hekaton_Custom_CIPolicy.xml'

# Retrieve the Policy ID from the App Control policy XML. This will be used as the binary file name that Code Integrity will use.
[xml]$AppControlPolicy = Get-Content -Path $AppControlPolicyXMLFile
$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.
ConvertFrom-CIPolicy -XmlFilePath $AppControlPolicyXMLFile -BinaryFilePath "C:\Windows\System32\CodeIntegrity\CiPolicies\Active\$PolicyBinary"

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
Invoke-CimMethod -Namespace root\Microsoft\Windows\CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{FilePath = "C:\Windows\System32\CodeIntegrity\CiPolicies\Active\$PolicyBinary" }

# View the current status of WDAC Code Integrity.
# If WDAC is in Audit mode the "UserModeCodeIntegrityPolicyEnforcementStatus" will have a value of "1" for Audit mode. A value of "0" signifies that Code Integrity is not active.
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Format-List *codeintegrity*

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

Une fois que l’intégrité du code fonctionne en mode Audit ou en mode Actif, les DLL générées par le générateur DE DLL Hekaton sont approuvées par Windows et ont un attribut étendu ajouté aux fichiers.

Une revendication SmartLocker est ajoutée dans le cadre des métadonnées. Vous pouvez voir cela en utilisant la commande fsutil depuis une invite de commandes d’administration. Par exemple, en sélectionnant l’un des fichiers OLTP en mémoire générés dynamiquement à partir du dossier \Data\xtp\<database_id>, puis en exécutant la commande suivante :

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

Capture d’écran de la sortie fsutil.

Supprimer la fonctionnalité Programme d’installation managée

Pour supprimer la fonctionnalité Programme d’installation managé de l’appareil, vous devez également supprimer la stratégie AppLocker associée. Pour ce faire, suivez les instructions de « Supprimer une règle AppLocker : effacer les stratégies AppLocker sur un système unique ou des systèmes distants».