Condividi tramite


Come creare In-Memory criteri di controllo app OLTP e programma di installazione gestito

si applica a:SQL Server

SQL Server compila e collega una libreria a collegamento dinamico (DLL) per ogni tabella compilata nativa e stored procedure che include l'implementazione nativa di tali oggetti nel codice C. Anche se le DLL OLTP In-Memory vengono generate in modo dinamico, i file stessi potrebbero presentare alcune problematiche quando esistono requisiti di conformità con l'imposizione dell'integrità del codice come criterio.

Che cos'è HKDLLGEN?

In SQL Server 2022 (16.x) Aggiornamento cumulativo 17 e versioni successive è stato aggiunto un componente noto come generatore dll Hekaton alla funzionalità OLTP In-Memory. Senza il nuovo processo di generazione dll hekaton (hkdllgen), il processo principale di SQL Server converte T-SQL nel codice C e quindi avvia i processi del compilatore e del linker per generare DLL OLTP non firmate In-Memory. Hkdllgen, come applicazione intermedia, convalida e accetta l'output da SQL Server e quindi crea DLL firmate. Per applicare i criteri di integrità del codice per queste DLL, il processo di Hkdllgen deve essere designato come Windows Defender Application Control (WDAC) Programma di installazione gestito.

Il generatore di DLL Hekaton è il primo passo per garantire che i requisiti di conformità alle normative, ad esempio l'integrità del codice possano essere soddisfatti con dll generate In-Memory OLTP. L'integrità del codice in questo contesto assicura che le DLL In-Memory generate da OLTP siano considerate attendibili dal sistema operativo dal momento in cui vengono create fino a quando non vengono caricate ed eseguite. La possibilità di designare il componente generatore dll Hekaton come programma di installazione gestito consente al sistema di integrità del codice WDAC di considerare attendibili le DLL generate e di usarle.

Come funziona un programma di installazione gestito?

Il programma di installazione gestito usa una raccolta di regole speciale in AppLocker per designare i file binari considerati attendibili dall'organizzazione come origine autorizzata per l'installazione dell'applicazione. Quando uno di questi file binari attendibili viene eseguito, Windows monitora il processo del file binario (e tutti i processi figlio che avvia) e controlla la scrittura dei file su disco. Quando vengono scritti i file, un'attestazione o un tag viene aggiunto al file come originato da un programma di installazione gestito.

Con AppLocker, il Controllo di App WDAC può essere configurato per ritenere attendibili i file installati da un programma di installazione gestito, aggiungendo l'opzione Enabled:Managed Installer a un criterio di App Control. Quando questa opzione è impostata, Controllo app controlla la presenza di informazioni sull'origine del programma di installazione gestito per determinare se consentire o meno l'esecuzione di un file binario. Se non sono presenti regole di negazione per il file binario, Controllo app consente l'esecuzione esclusivamente in base all'origine del programma di installazione gestito. AppLocker controlla anche l'esecuzione di file eseguibili designati come programma di installazione gestito, ma non offre una catena di attendibilità per file eseguibili e DLL come WDAC. In questo articolo viene illustrato come designare e configurare il processo di hkdllgen come programma di installazione gestito che può essere usato sia da AppLocker che da WDAC.

Abilitare il generatore di DLL Hekaton

Esempio

In questo esempio, sp_configure viene usato per abilitare l'opzione del generatore dll Hekaton, denominata external xtp dll gen util enabled. Viene creato un database di test, insieme a una tabella ottimizzata per la memoria di test.

  1. Creare un database di 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. Creare una tabella di test all'interno del database di 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. Viene generato un nuovo file di lunghezza zero con estensione .gen per ogni .dll all'interno della sottodirectory <path-to-data-directory>\xtp\<database_id>. Le DLL sono ora firmate.

Procedura per creare i criteri In-Memory OLTP AppLocker e Installer Gestito

L'interfaccia utente di creazione dei criteri di AppLocker nell'editor degli oggetti Criteri di gruppo (gpedit.msc) e i cmdlet di PowerShell di AppLocker non possono essere usati direttamente per creare regole per la raccolta di regole del programma di installazione gestito. Tuttavia, è possibile usare un editor di testo o XML per convertire un criterio di raccolta regole EXE in una raccolta di regole ManagedInstaller.

Importante

Un criterio di AppLocker deve esistere prima di aggiungere l'eseguibile Hekaton DLL Generation alla configurazione dei criteri di controllo di AppLocker di un server, altrimenti c'è il rischio che le funzioni di base del sistema operativo vengano bloccate da Windows Defender. Per altre informazioni sulla creazione, il test e la manutenzione dei criteri di controllo delle applicazioni, vedere la guida alla distribuzione di AppLocker .

Gli esempi rimanenti si applicano a Windows Server 2022 e windows 11 e versioni successive.

Per verificare che nella configurazione dei criteri di controllo di AppLocker sia presente almeno un exe raccolta regole, eseguire il comando PowerShell seguente:

Get-AppLockerPolicy -Effective

In alternativa, per salvare l'output dei criteri effettivi in un file XML per la visualizzazione:

Get-AppLockerPolicy -Effective -Xml > effective_app_policy.xml

La procedura seguente illustra il processo di creazione e applicazione di un criterio che può essere applicato a un server locale. Un criterio del programma di installazione gestito generato tramite questi passaggi può essere unito a un criterio a livello di oggetto Criteri di gruppo e distribuito a tutti i server SQL all'interno di un ambiente o applicato ai criteri locali di un singolo server. È consigliabile collaborare con un amministratore di dominio per applicare i criteri di integrità del codice a livello di dominio.

  1. Usare New-AppLockerPolicy per creare una regola EXE per il file che hai designato come programma di installazione gestito. Questo esempio crea una regola per il generatore di DLL di Hekaton utilizzando il tipo di regola Publisher, ma è possibile utilizzare qualsiasi tipo di regola di AppLocker. Potrebbe essere necessario riformattare l'output per la leggibilità.

    #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. Modificare manualmente il AppLocker_HKDLLGEN_Policy.xml e modificare i valori di attributo seguenti:

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

    Cambiare:

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

    A:

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

    Cambiare:

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

    A:

    <BinaryVersionRange LowSection="*" HighSection="*"/>
    
  3. Distribuire i criteri di configurazione del programma di installazione gestito di AppLocker. È possibile importare i criteri di AppLocker e distribuirli con Criteri di gruppo oppure usare uno script per distribuire il criterio con il cmdlet Set-AppLockerPolicy, come illustrato nel comando di PowerShell seguente.

    #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 si distribuiscono i criteri di AppLocker tramite uno script di PowerShell, usare l'utilità appidtel.exe da un prompt dei comandi amministrativo per configurare il servizio identità dell'applicazione AppLocker e il driver di filtro AppLocker.

    appidtel.exe start [-mionly]
    

Abilitare l'opzione del programma di installazione gestito nella Configurazione guidata di controllo applicazioni di Windows Defender per le aziende

Perché Windows Defender Application Control (WDAC) si fidi delle DLL generate dal processo di hkdllgen.exe, l'opzione Enabled: Managed Installer deve essere specificata nei criteri di controllo delle applicazioni. Questa impostazione può essere definita usando il cmdlet Set-RuleOption con l'opzione 13.

Generare un file di criteri di integrità del codice da una delle Guidata criteri di base WDAC criteri di base dei modelli.

A partire dal criterio di Predefinita di Windows sono disponibili meno opzioni, che vengono rimosse in questa guida. Altre informazioni sui criteri predefiniti di Windows e sulla modalità Consenti Microsoft sono accessibili tramite l'articolo Criteri di base di Esempio di Controllo app per le aziende.

Politica del modello di base

Screenshot della schermata Modello Base WDAC.

Dopo aver selezionato il modello di base dei criteri di Windows, assegnare un nome al criterio e scegliere dove salvare i criteri di Controllo app su disco.

Selezionare un tipo di politica

Scegliere il formato a polizza multipla e la polizza di base come tipo di polizza.

screenshot della schermata di selezione del tipo di criterio WDAC.

Configurare il modello di criteri

Abilitare solo il programma di installazione gestito, i criteri di aggiornamento senza riavviare, i criteri di integrità del sistema non firmati e le opzioni delle regole dei criteri di integrità del codice in modalità utente. Disabilitare le altre opzioni della regola dei criteri. Questo può essere fatto premendo il pulsante del dispositivo di scorrimento accanto ai titoli delle regole delle politiche.

La tabella seguente contiene una descrizione di ogni regola dei criteri, a partire dalla colonna più a sinistra. L'articolo delle regole delle politiche fornisce una descrizione più completa di ogni regola delle politiche.

Opzione regola Descrizione
Programma di installazione gestito Usare questa opzione per consentire automaticamente alle applicazioni installate da una soluzione di distribuzione software, come il generatore di DLL Hekaton, definito come installer gestito.
Politica di aggiornamento senza riavviare Usare questa opzione per consentire l'applicazione degli aggiornamenti futuri dei criteri di Controllo app per le aziende senza richiedere un riavvio del sistema.
Politica di integrità del sistema non firmata Consente alla politica di rimanere non firmata. Quando questa opzione viene rimossa, il criterio deve essere firmato e avere UpdatePolicySigners aggiunto al criterio per abilitare le modifiche future del criterio.
Integrità del Codice in Modalità Utente I criteri di Controllo app per le aziende limitano sia i file binari in modalità kernel che in modalità utente. Per impostazione predefinita, solo i file binari in modalità kernel sono limitati. L'abilitazione di questa opzione di regola convalida gli script e i file eseguibili in modalità utente.

screenshot della schermata Configura modello di criteri.

Devi abilitare inizialmente la modalità di Audit, perché consente di testare i nuovi criteri di Controllo delle App per le Aziende prima di applicarli. Con la modalità di controllo, nessuna applicazione viene bloccata, ma i criteri registrano un evento ogni volta che viene avviata un'applicazione all'esterno dei criteri. Per questo motivo, per impostazione predefinita è abilitata la modalità di controllo per tutti i modelli.

Regole del file

Rimuovere tutte le regole di firma dei criteri dall'elenco.

screenshot della schermata Regole file WDAC.

(facoltativo) Aggiungere una regola dei criteri personalizzata per Publisher che garantisca che i file, come hkdllgen.exe, vengano firmati come Publisher.

Screenshot della schermata Criteri personalizzati WDAC.

Il tipo di regola file dell'editore utilizza le proprietà nella catena di certificati di firma del codice per stabilire le regole dei file.

Screenshot della schermata della regola della Policy WDAC.

Dopo aver selezionato il pulsante Crea regola, dovrebbe esistere una sola regola di firma della policy.

Screenshot della schermata della lista delle regole di firma della politica WDAC.

Distribuire la politica di App Control. Vedere Deploying App Control for Business policies.see Deploying App Control for Business policies.

Dopo aver creato la politica, la nuova politica viene scritta nel percorso scelto come Percorso del file della politica. La nuova versione binaria del nome del file di criteri ha la versione dei criteri aggiunta alla fine del nome del file. Il file policy con estensione .cip può essere copiato nella sottodirectory C:\Windows\System32\CodeIntegrity\CiPolicies\Active nell'istanza di SQL Server.

Distribuire manualmente un criterio di integrità del codice

Per creare un criterio di integrità del codice più semplificato, è possibile modificare un file di criterio più generico .xml generato dopo il completamento della Creazione guidata criteri di controllo delle app WDAC. Questo scenario può verificarsi se la Creazione guidata criteri di controllo app WDAC non viene eseguita su un SQL Server, ma da una workstation. Ad esempio, un file di criteri di integrità del codice meno personalizzato potrebbe essere simile al seguente:

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

In questo esempio non è presente una regola di pubblicazione firmata e si presuppone che il file di criteri usi una directory di lavoro locale (ad esempio, C:\Temp) con un nome file di 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"

Per applicare i criteri senza riavviare il server e controllare lo stato dell'integrità del codice, eseguire questo script di 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*

Verificare che le DLL Hekaton generate siano attendibili secondo l'integrità del codice

Quando l'integrità del codice opera in modalità di audit o attiva, le DLL generate dal generatore di DLL Hekaton sono considerate attendibili da Windows, e ai file viene aggiunto un attributo esteso.

Viene aggiunta un'attestazione Smartlocker come parte dei metadati. Questa operazione può essere visualizzata usando il comando fsutil da un prompt dei comandi amministrativo. Ad esempio, selezionando uno dei file OLTP in memoria generati dinamicamente dalla cartella \Data\xtp\<database_id> ed eseguendo il comando seguente:

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

Screenshot dell'output fsutil.

Rimuovere la funzionalità Del programma di installazione gestito

Per rimuovere la funzionalità Programma di installazione gestito dal dispositivo, è necessario rimuovere il criterio AppLocker del programma di installazione gestito dal dispositivo seguendo le istruzioni riportate in Eliminare una regola di AppLocker: Cancellare i criteri di AppLocker in un singolo sistema o sistemi remoti.