Wie erstellt man In-Memory OLTP App Control und verwaltete Installationsrichtlinien

Gilt für:SQL Server

Der SQL Server kompiliert und verknüpft für jede nativ kompilierte Tabelle und gespeicherte Prozedur eine dynamische Link-Bibliothek (DLL), die die native Implementierung dieser Objekte im C-Code enthält. Obwohl In-Memory OLTP-DLLs dynamisch generiert werden, können die Dateien in Umgebungen, in denen die Durchsetzung der Codeintegrität erforderlich ist, Herausforderungen darstellen.

Was ist HkDllGen?

In SQL Server 2022 (16.x) Cumulative Update 17 und späteren Versionen enthält die In-Memory OLTP-Funktion den Hekaton-DLL-Generator oder HkDllGen. Ohne HkDllGen generiert SQL Server den C-Quellcode innerhalb von sqlservr.exe und startet den Compiler, der den Linker aufruft, um die In-Memory OLTP-DLL zu erstellen. Mit aktivierter externer Generierung exportiert SQL Server serialisierte Objektmetadaten und startet das von Microsoft signierte hkdllgen.exe. HkDllGen validiert und importiert diese Metadaten, erzeugt die C-Quelle in einem eigenen Prozess und startet den Compiler und Linker.

Um die Code-Integrität dieser DLLs zu gewährleisten, verwenden Sie AppLocker, um das Microsoft-signed hkdllgen.exe als verwalteten Installer zu benennen und Managed Installer Trust in der App Control for Business-Richtlinie zu aktivieren, früher Windows Defender Application Control (WDAC). Windows zeichnet dann auf, dass die generierten DLLs aus dem HkDllGen-Prozessbaum stammen, sodass App Control ihnen basierend auf ihrem Ursprung des verwalteten Installers vertrauen kann.

HkDllGen ist der erste Schritt zur Erfüllung regulatorischer Anforderungen, die die Code-Integrität für In-Memory OLTP umfassen. In diesem Szenario stellt die Codeintegrität sicher, dass Windows für jede generierte DLL einen vertrauenswürdigen Ursprung festlegen und diese Vertrauensstellung bewerten kann, wenn SQL Server sie lädt. Die generierte DLL ist nicht authenticode-signiert. Windows vertraut ihm basierend darauf, wie er erstellt wurde.

Wie funktioniert ein verwaltetes Installationsprogramm?

Ein verwalteter Installer verwendet eine spezielle Regelsammlung in AppLocker , um Binärdateien zu bestimmen, denen Ihre Organisation als autorisierte Quelle für die Anwendungsinstallation vertraut. Wenn eine dieser vertrauenswürdigen Binärdateien ausgeführt wird, überwacht Windows den Prozess der Binärdatei (und alle untergeordneten Prozesse, die es startet) und überwacht, ob Dateien auf den Datenträger geschrieben werden. Während Dateien geschrieben werden, wird ihnen ein Anspruch oder Tag von einem verwalteten Installationsprogramm hinzugefügt.

Die Ursprungsbehauptung ist ein vom Kernel verwaltetes erweitertes Attribut. Es handelt sich nicht um eine Authenticode-Signatur und ändert weder den Publisher noch den Signierungsstatus der generierten DLL.

Mit AppLocker kann App Control for Business (früher Windows Defender Application Control oder WDAC) so konfiguriert werden, dass Dateien, die von einem verwalteten Installationsprogramm installiert werden, als vertrauenswürdig eingestuft werden, indem einer App Control-Richtlinie die Option Enabled:Managed Installer hinzugefügt wird. Wenn Sie diese Option setzen, prüft App Control die Herkunftsinformationen des verwalteten Installers, um zu entscheiden, ob eine Binärdatei ausgeführt werden darf. Solange es keine Ablehnungsregeln für die Binärdatei gibt, erlaubt die App-Kontrolle die Ausführung rein basierend auf ihrem verwalteten Installationsursprung. AppLocker steuert außerdem die Ausführung ausführbarer Dateien, die es als verwalteten Installer bezeichnet, bietet aber keine Vertrauenskette für ausführbare Dateien und DLLs wie WDAC an. Dieser Artikel erklärt, wie man den HkDllGen-Prozess als verwalteten Installer anweist und konfiguriert, den sowohl AppLocker als auch WDAC verwenden können.

Aktivieren des Hekaton DLL-Generators

Beispiel

Dieses Beispiel aktiviert den Hekaton-DLL-Generator durch Verwendung von sp_configure mit der Option external xtp dll gen util enabled. Erstellen Sie eine Testdatenbank und eine testspeicheroptimierte Tabelle.

1. Erstellen Sie eine Testdatenbank.

   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. Erstellen Sie eine Testtabelle in der Testdatenbank.

   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. Eine Datei wird zusammen mit jeder durch HkDllGen generierten .gen DLL im <path-to-data-directory>\xtp\<database_id> Unterverzeichnis erstellt. Diese Datei erfasst HkDllGen-Ausgabe und ist normalerweise von null Länge nach einer erfolgreichen Kompilierung. Sein Vorhandensein deutet darauf hin, dass der externe Generator aktiviert wurde. Die generierten DLLs sind nicht von Authenticode signiert. Damit Windows den generierten DLLs basierend auf ihrem Ursprung vertraut, benötigt man Managed Installer Tracking und eine App Control-Policy.

Bestehende DLLs werden nicht rückwirkend mit Informationen zur Herkunft des verwalteten Installationsprogramms versehen. Generiere eine neue DLL, nachdem das Managed Installer Tracking beim Validieren der Policy aktiv ist.

Schritte zur Erstellung In-Memory OLTP AppLocker und verwalteter Installationsrichtlinien

Man kann die AppLocker-Richtlinienerstellungsoberfläche im GPO Editor (gpedit.msc) oder die AppLocker-PowerShell-Kommandos nicht verwenden, um Regeln für die verwaltete Installer-Regelsammlung zu erstellen. Sie können jedoch einen XML- oder Texteditor verwenden, um eine EXE-Regelsammlungsrichtlinie in eine verwaltete Installationsregelsammlung umzuwandeln.

Die übrigen Beispiele in diesem Artikel gelten für Windows Server 2022 und Windows 11 und spätere Versionen.

Um zu überprüfen, dass zumindest eine exe-Regelsammlung innerhalb der AppLocker Control Policy-Konfiguration des Servers existiert, führen Sie folgenden PowerShell-Befehl aus:

Get-AppLockerPolicy -Effective

Oder führen Sie folgenden Befehl aus, um die Ausgabe der effektiven Richtlinien in eine XML-Datei zur Anzeige zu speichern:

Get-AppLockerPolicy -Effective -Xml > effective_app_policy.xml

Die folgenden Schritte zeigen den Prozess zur Erstellung und Anwendung einer Richtlinie, die Sie auf einen lokalen Server anwenden können. Eine verwaltete Installationsrichtlinie, die mit diesen Schritten generiert wird, kann in eine GPO-weite Richtlinie integriert und an alle SQL Server-Instanzen innerhalb einer Umgebung verteilt oder auf die lokale Richtlinie eines einzelnen Servers angewendet werden. Du solltest mit einem Domänenadministrator zusammenarbeiten, um die Code-Integritätsrichtlinie von der Domänenebene aus anzuwenden.

1. Verwenden Sie New-AppLockerPolicy-, um eine EXE-Regel für die Datei zu erstellen, die Sie als verwaltetes Installationsprogramm entwerfen. Dieses Beispiel erstellt eine Regel für den Hekaton-DLL-Generator mit dem Publisher-Regeltyp, aber du kannst jeden AppLocker-Regeltyp verwenden. Möglicherweise müssen Sie die Ausgabe zur Lesbarkeit neu formatieren.

   # 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. Bearbeiten Sie die AppLocker_HkDllGen_Policy.xml manuell, und ändern Sie die folgenden Attributwerte:

   • RuleCollection Type auf ManagedInstaller
   • EnforcementMode auf AuditOnly
   • BinaryVersionRange LowSection bis "*" und HighSection bis "*"

   Veränderung:

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

   in:

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

   Veränderung:

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

   in:

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

3. Stellen Sie die Konfigurationsrichtlinie für verwaltete Installationsprogramme von AppLocker bereit. Sie können entweder die AppLocker-Richtlinie importieren und mit der Group Policy bereitstellen, oder ein Skript verwenden, um die Policy mit dem Set-AppLockerPolicy Cmdlet zu deployen, wie im folgenden PowerShell-Befehl gezeigt.

   #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. Wenn Sie die AppLocker-Richtlinie mit einem PowerShell-Skript bereitstellen, verwenden Sie das appidtel.exe Dienstprogramm aus einer administrativen Eingabeaufforderung, um den AppLocker Application Identity-Service und den AppLocker-Filtertreiber zu konfigurieren.

   appidtel.exe start [-mionly]
   

Aktivieren der Option "Verwaltetes Installationsprogramm" im Windows Defender-Anwendungssteuerungs-Assistenten für Unternehmen

Damit Windows Defender Application Control (WDAC) den durch den Prozess hkdllgen.exe generierten DLL-Dateien vertraut, legen Sie in Ihrer App Control-Richtlinie die Option Enabled: Managed Installer fest. Definiere diese Einstellung mit dem Set-RuleOption cmdlet mit Option 13.

Generieren Sie eine Codeintegritätsrichtliniendatei anhand einer der Basisrichtlinienvorlagen des WDAC-Basisrichtlinienassistenten.

Ab der Richtlinie Standard-Windows stehen weniger Optionen zur Verfügung, die in diesem Handbuch entfernt werden. Weitere Informationen zu den Richtlinien zum Standard-Windows-Modus und zum Erlauben von Microsoft Mode finden Sie im Artikel zur Beispiel-App-Steuerung für Business-Basisrichtlinien.

Basisvorlagenrichtlinie

Nachdem du die Windows-Richtlinienbasis-Vorlage ausgewählt hast, benennen Sie die Richtlinie und wählen Sie aus, wo Sie die App Control-Richtlinie auf der Festplatte speichern möchten.

Auswählen eines Richtlinientyps

Wählen Sie das Multiple Policy Format und die Basisrichtlinie als Policytyp.

Richtlinienvorlage konfigurieren

Aktivieren Sie nur die Regeloptionen Managed Installer, Update Policy without Rebooting, Unsigned System Integrity Policy und User Mode Code Integrity. Deaktivieren Sie die anderen Richtlinienregeloptionen. Um die Einstellungen zu ändern, wählen Sie den Schieberegler neben den Richtlinienregeltiteln.

Die folgende Tabelle beschreibt jede Richtlinienregel, beginnend mit der linkesten Spalte. Der Artikel über Richtlinienregeln bietet eine detailliertere Beschreibung jeder Richtlinienregel.

Sie sollten zunächst Überwachungsmodus aktivieren, da sie es Ihnen ermöglicht, neue App Control for Business-Richtlinien zu testen, bevor Sie sie erzwingen. Im Audit-Modus wird keine Anwendung blockiert. Stattdessen protokolliert die Richtlinie ein Ereignis, wann immer eine Anwendung außerhalb der Richtlinie startet. Aus diesem Grund sind alle Vorlagen standardmäßig im Überwachungsmodus aktiviert.

Dateiregeln

Entferne alle Regeln zur Unterzeichnung von Richtlinien aus der Liste.

(Optional) Fügen Sie eine benutzerdefinierte Publisher-Permit-Regel für hkdllgen.exehinzu. Diese Regel nutzt Informationen aus dem bestehenden Microsoft-Code-Signing-Zertifikat der ausführbaren Datei, um übereinstimmende Versionen von HkDllGen zu identifizieren und zu ermöglichen.

Der Publisher-Dateiregeltyp verwendet Eigenschaften in der Codesignaturzertifikatskette, um Dateiregeln zu basisieren.

Nachdem du die Regel erstellen ausgewählt hast, sollte eine einzige Policy Signing-Regel existieren.

Stellen Sie Ihre App Control-Richtlinie bereit. Weitere Informationen finden Sie unter Bereitstellen von App Control for Business-Richtlinien.

Nachdem die Policy erstellt wurde, wird die neue Policy auf den Pfad geschrieben, der als Policy-Dateistandort gewählt wurde. Die neue Binärversion des Richtlinien-Dateinamens enthält die Richtlinienversion am Ende des Dateinamens. Du kannst die <policy>.cip Datei in das C:\Windows\System32\CodeIntegrity\CiPolicies\Active Unterverzeichnis der SQL Server-Instanz kopieren.

Manuelles Bereitstellen einer Codeintegritätsrichtlinie

Um eine schlankere Code-Integritätsrichtlinie zu erstellen, können Sie eine generischere <policy>.xml Datei bearbeiten, die Sie nach Abschluss des WDAC App Control Policy Wizard erstellen. Dieses Szenario kann auftreten, wenn Sie den WDAC App Control Policy Wizard nicht auf einem SQL Server ausführen, sondern von einer Arbeitsstation aus. Beispielsweise könnte eine weniger angepasste Code-Integritätsrichtlinien-Datei wie folgt aussehen:

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

Dieses Beispiel hat keine signierte Publisher-Regel und geht davon aus, dass die Policy-Datei ein lokales Arbeitsverzeichnis verwendet (zum Beispiel C:\Temp) mit dem Dateinamen .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

Um die Richtlinie anzuwenden, ohne den Server neu zu starten und den Status der Codeintegrität zu überprüfen, führen Sie dieses PowerShell-Skript aus:

# 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*

Überprüfen, ob die generierten Hekaton-DLLs durch Codeintegrität vertrauenswürdig sind

Nachdem die AppLocker-Managed-Installer-Regel und die erforderlichen AppLocker-Dienste aktiv sind, generieren Sie über HkDllGen eine neue In-Memory-OLTP-DLL. Windows verfolgt den HkDllGen-Prozessbaum und fügt Dateien, die von diesem Prozessbaum erstellt werden, ein erweitertes $KERNEL.SMARTLOCKER.ORIGINCLAIM Attribut hinzu.

Wenn App Control im Audit- oder Durchsetzungsmodus mit Enabled:Managed Installer läuft, kann Code Integrity der generierten DLL basierend auf ihrem Ursprung des verwalteten Installers vertrauen. Um zu überprüfen, ob das erweiterte Attribut hinzugefügt wurde, wählen Sie eine neu generierte DLL aus dem \Data\xtp\<database_id> Ordner aus und führen Sie folgenden Befehl aus einer erhöhten Eingabeaufforderung aus:

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

Das bloße Vorhandensein von $KERNEL.SMARTLOCKER.ORIGINCLAIM belegt nicht, dass die Datei aus einem verwalteten Installationsprogramm stammt. Dasselbe erweiterte Attribut kann den Ursprung des Intelligent Security Graph und wie Vertrauen geerbt wurde, aufzeichnen. In der ersten Datenzeile kennzeichnet 00 am Anfang des zweiten ULONG die Herkunft aus Managed Installer, während 01 die Herkunft aus Intelligent Security Graph kennzeichnet. Informationen zur Bewertung der verbleibenden Origin-Claim-Werte finden Sie in der technischen Referenz zu Managed Installer und ISG.

"Funktion 'Verwaltetes Installationsprogramm entfernen'"

Um die Funktion Managed Installer vom Gerät zu entfernen, entfernen Sie die Managed Installer AppLocker-Richtlinie vom Gerät, indem Sie die Anweisungen in der Delete an AppLocker-Regel befolgen: AppLocker-Richtlinien auf einem einzelnen System oder entfernten Systemen löschen.

Verwandte Inhalte

• Automatisches Zulassen von Apps, die von einem verwalteten Installationsprogramm mit App Control for Business bereitgestellt werden
• Übersicht über In-Memory OLTP und Verwendungsszenarios
• Anleitung zur Abfrageverarbeitung für speicheroptimierte Tabellen
• Beispieldatenbank für IN-Memory-OLTP
• Leitfaden zur AppLocker-Bereitstellung
• Bereitstellen von App Control for Business-Richtlinien.