Registrare il computer per il servizio Sorveglianza host

Si applica a: SQL Server 2019 (15.x) e versioni successive - Solo Windows

Questo articolo descrive come registrare computer con SQL Server per l'attestazione con il servizio Sorveglianza host (HGS).

Prima di iniziare, verificare di avere implementato almeno un computer HGS e di aver configurato il servizio di attestazione HGS. Per ulteriori informazioni, vedere Implementare il servizio Sorveglianza host per SQL Server.

Passaggio 1: Installare i componenti client di attestazione

Per consentire a un client SQL di verificare che stia comunicando con un computer con SQL Server attendibile, il computer con SQL Server deve completare l'attestazione per il servizio Sorveglianza host. Il processo di attestazione è gestito da un componente Windows facoltativo denominato client HGS. La procedura seguente consente di installare questo componente e iniziare l'attestazione.

1. Verificare che il computer con SQL Server soddisfi i prerequisiti descritti nella documentazione per la pianificazione di HGS.

2. Eseguire il comando seguente in una console di PowerShell con privilegi elevati per installare la funzionalità Supporto per Sorveglianza host per Hyper-V e i componenti di attestazione.

   Enable-WindowsOptionalFeature -Online -FeatureName HostGuardian -All
   

3. Riavviare il sistema per completare l'installazione.

Passaggio 2: Verificare che la sicurezza basata su virtualizzazione sia in esecuzione

Quando si installa la funzionalità Supporto per Sorveglianza host per Hyper-V, viene automaticamente configurata e abilitata la funzionalità di sicurezza basata sulla virtualizzazione (VBS). Le enclave per Always Encrypted di SQL Server sono protette dall'ambiente VBS ed eseguite al suo interno. VBS potrebbe non essere avviato se nel computer non è installato e abilitato un dispositivo IOMMU. Per verificare se VBS è in esecuzione, aprire lo strumento Informazioni di sistema eseguendo msinfo32.exe e individuare gli elementi Virtualization-based security nella parte inferiore del riepilogo di sistema.

Il primo elemento da controllare è Virtualization-based security, che può avere i tre valori seguenti:

• Running indica che VBS è configurato correttamente ed è stato possibile avviarlo correttamente. Se il computer mostra questo stato, è possibile procedere al passaggio 3.
• Enabled but not running indica che VBS è configurato per l'esecuzione, ma l'hardware non ha i requisiti di sicurezza minimi per eseguire VBS. Potrebbe essere necessario modificare la configurazione dell'hardware nel BIOS o UEFI per abilitare le funzionalità facoltative del processore come un'unità IOMMU o, se l'hardware non supporta effettivamente le funzionalità richieste, potrebbe essere necessario ridurre i requisiti di sicurezza di VBS. Per altre informazioni, continuare a leggere questa sezione.
• Not enabled indica che VBS non è configurato per l'esecuzione. La funzionalità Supporto per Sorveglianza host per Hyper-V abilita automaticamente VBS, quindi è consigliabile ripetere il passaggio 1 se viene visualizzato questo stato.

Se VBS non è in esecuzione nel computer, controllare le proprietà di Virtualization-based security. Confrontare i valori nell'elemento Required Security Properties con i valori nell'elemento Available Security Properties. Le proprietà richieste devono essere uguali o un subset delle proprietà di sicurezza disponibili per l'esecuzione di VBS.

Nel contesto dell'attestazione delle enclave di SQL Server, le proprietà di sicurezza hanno la priorità seguente:

• Base virtualization support è sempre obbligatorio, poiché rappresenta le funzionalità hardware minime necessarie per eseguire un hypervisor.
• Secure Boot è consigliato ma non obbligatorio per Always Encrypted di SQL Server. L'avvio protetto protegge da rootkit richiedendo l'esecuzione di un bootloader firmato da Microsoft subito dopo il completamento dell'inizializzazione UEFI. Se si usa l'attestazione TPM (Trusted Platform Module), l'abilitazione dell'avvio protetto verrà misurata e applicata indipendentemente dal fatto che VBS sia configurato per richiedere l'avvio protetto.
• DMA Protection è consigliato ma non obbligatorio per Always Encrypted di SQL Server. La protezione DMA usa un'unità IOMMU per proteggere VBS e la memoria dell'enclave da attacchi di accesso diretto alla memoria. In un ambiente di produzione è sempre necessario usare computer con protezione DMA. In un ambiente di sviluppo/test, è accettabile rimuovere il requisito per la protezione DMA. Se l'istanza di SQL Server è virtualizzata, probabilmente non sarà disponibile la protezione DMA e sarà necessario rimuovere il requisito per l'esecuzione di VBS. Vedere il modello di attendibilità per informazioni sulle garanzie di sicurezza inferiori durante l'esecuzione in una macchina virtuale.

Prima di ridurre le funzionalità di sicurezza necessarie per VBS, rivolgersi all'OEM o al provider di servizi cloud per verificare se esiste un modo per abilitare i requisiti della piattaforma mancanti in UEFI o BIOS (ad esempio, abilitazione dell'avvio protetto, Intel VT-d o AMD IOV).

Per modificare le funzionalità di sicurezza della piattaforma necessarie per VBS, eseguire il comando seguente in una console di PowerShell con privilegi elevati:

# Value 0 = No security features required
# Value 1 = Only Secure Boot is required
# Value 2 = Only DMA protection is required (default configuration)
# Value 3 = Both Secure Boot and DMA protection are required
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard -Name RequirePlatformSecurityFeatures -Value 0

Dopo aver modificato il registro, riavviare il computer con SQL Server e verificare se VBS è di nuovo in esecuzione.

Se il computer è gestito dall'azienda, è possibile che le modifiche apportate a queste chiavi del Registro di sistema vengano sostituite da Criteri di gruppo o Microsoft Endpoint Manager dopo il riavvio. Contattare l'help desk IT per verificare se vengono distribuiti criteri per la gestione della configurazione di VBS.

Passaggio 3: Configurare l'URL di attestazione

Il computer con SQL Server verrà quindi configurato con l'URL del servizio di attestazione HGS ottenuto dall'amministratore di HGS.

In una console di PowerShell con privilegi elevati, aggiornare ed eseguire il comando seguente per configurare l'URL di attestazione.

• Sostituire hgs.bastion.local con il nome del cluster HGS.
• È possibile eseguire Get-HgsServer in qualsiasi computer HGS per ottenere il nome del cluster
• L'URL di attestazione deve sempre terminare con /Attestation
• SQL Server non sfrutta le funzionalità di protezione delle chiavi di HGS, quindi specificare qualsiasi URL fittizio, ad esempio http://localhost per -KeyProtectionServerUrl

Set-HgsClientConfiguration -AttestationServerUrl "https://hgs.bastion.local/Attestation" -KeyProtectionServerUrl "http://localhost"

A meno che il computer non sia stato registrato con HGS in precedenza, il comando segnala un errore di attestazione. Questo risultato è normale.

Il campo AttestationMode nell'output del cmdlet indica la modalità di attestazione usata da HGS.

Procedere al passaggio 4A per registrare il computer in modalità TPM o al passaggio 4B per registrare il computer nella modalità con chiave host.

Passaggio 4A: Registrare un computer in modalità TPM

Preparazione

In questo passaggio si vedrà come raccogliere informazioni sullo stato del TPM del computer e registrarlo per HGS.

Se il servizio di attestazione HGS è configurato per l'uso della modalità con tasto host, procedere al Passaggio 4B.

Prima di iniziare a raccogliere le misurazioni di TPM, assicurarsi di usare una configurazione valida conosciuta del computer con SQL Server. Nel computer devono essere installati tutti i componenti hardware necessari ed è necessario che siano stati applicati gli aggiornamenti più recenti per software e firmware. HGS misura i computer rispetto a questa baseline in fase di attestazione, quindi è importante che lo stato sia il più sicuro e previsto possibile quando si raccolgono le misurazioni del TPM.

Per l'attestazione TPM vengono raccolti tre file di dati, alcuni dei quali possono essere riutilizzati in presenza di computer con configurazione identica.

È possibile configurare più di un artefatto di attestazione in HGS per supportare combinazioni miste di hardware e software. HGS richiede solo che un computer che esegue l'attestazione corrisponda a un solo criterio di ogni categoria di criteri. Ad esempio, se sono disponibili tre baseline TPM registrate in HGS, le misurazioni del computer possono corrispondere a una qualsiasi di queste baseline per soddisfare i requisiti dei criteri.

Configurare un criterio di integrità del codice

HGS richiede che a ogni computer che esegue l'attestazione in modalità TPM sia applicato di un criterio di controllo delle applicazioni di Windows Defender (WDAC). I criteri di integrità del codice WDAC limitano il software che può essere eseguito in un computer controllando ogni processo che tenta di eseguire il codice in base a un elenco di autori attendibili e hash di file. Per il caso d'uso di SQL Server, le enclave sono protette dalla sicurezza basata su virtualizzazione e non possono essere modificate dal sistema operativo host, quindi la rigidità dei criteri WDAC non influisce sulla sicurezza delle query crittografate. Di conseguenza, è consigliabile implementare un criterio in modalità di controllo ai computer con SQL Server per soddisfare i requisiti di attestazione senza imporre ulteriori restrizioni al sistema.

Se si usa già un criterio di integrità del codice WDAC personalizzato nei computer per rafforzare la configurazione del sistema operativo, è possibile passare a Raccogliere informazioni per l'attestazione TPM.

1. Sono disponibili criteri di esempio predefiniti in ogni sistema operativo Windows Server 2019, Windows 10 versione 1809 e successive. Il criterio AllowAll consente l'esecuzione di qualsiasi software nel computer senza restrizioni. Convertire il criterio in un formato binario riconosciuto dal sistema operativo e da HGS per usarlo. In una console di PowerShell con privilegi elevati, eseguire i comandi seguenti per compilare i criteri AllowAll:

   # We are changing the policy to disable enforcement and user mode code protection before compiling
   $temppolicy = "$HOME\Desktop\allowall_edited.xml"
   Copy-Item -Path "$env:SystemRoot\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml" -Destination $temppolicy
   Set-RuleOption -FilePath $temppolicy -Option 0 -Delete
   Set-RuleOption -FilePath $temppolicy -Option 3
   
   ConvertFrom-CIPolicy -XmlFilePath $temppolicy -BinaryFilePath "$HOME\Desktop\allowall_cipolicy.bin"
   

2. Seguire il materiale sussidiario nella guida alla distribuzione di Controllo di applicazioni di Windows Defender per implementare il file allowall_cipolicy.bin nei computer con SQL Server usando Criteri di gruppo. Per i computer del gruppo di lavoro, seguire lo stesso processo usando Editor Criteri di gruppo locali (gpedit.msc).

3. Eseguire gpupdate /force nei computer con SQL Server per configurare i nuovi criteri di integrità del codice, quindi riavviare i computer per applicare i criteri.

Raccogliere informazioni per l'attestazione TPM

Ripetere i passaggi seguenti per ogni computer con SQL Server che eseguirà l'attestazione per HGS:

1. Con il computer in uno stato valido conosciuto, eseguire i comandi seguenti in PowerShell per raccogliere le informazioni per l'attestazione TPM:

   # Collects the TPM EKpub and EKcert
   $name = $env:computername
   $path = "$HOME\Desktop"
   (Get-PlatformIdentifier -Name $name).Save("$path\$name-EK.xml")
   
   # Collects the TPM baseline (current PCR values)
   Get-HgsAttestationBaselinePolicy -Path "$path\$name.tcglog" -SkipValidation
   
   # Collects the applied CI policy, if one exists
   Copy-Item -Path "$env:SystemRoot\System32\CodeIntegrity\SIPolicy.p7b" -Destination "$path\$name-CIpolicy.bin"
   

2. Condividere i tre file di attestazione con l'amministratore di HGS.

Registrare il computer SQL Server in HGS

Ripetere i passaggi seguenti per ogni computer con SQL Server che eseguirà l'attestazione per HGS:

1. Copiare i file di attestazione ottenuti dall'amministratore del computer con SQL Server nel server HGS.

2. Nel server HGS, eseguire i comandi seguenti in una console di PowerShell con privilegi elevati per registrare il computer con SQL Server:

   # TIP: REMEMBER TO CHANGE THE FILENAMES
   # Registers the unique TPM with HGS (required for every computer)
   Add-HgsAttestationTpmHost -Path "C:\temp\SQL01-EK.xml"
   
   # Registers the TPM baseline (required ONCE for each unique hardware and software configuration)
   Add-HgsAttestationTpmPolicy -Name "MyHWSoftwareConfig" -Path "C:\temp\SQL01.tcglog"
   
   # Registers the CI policy (required ONCE for each unique CI policy)
   Add-HgsAttestationCiPolicy -Name "AllowAll" -Path "C:\temp\SQL01-CIpolicy.bin"
   

   Suggerimento

   Se si verifica un errore durante il tentativo di registrare l'identificatore univoco del TPM, assicurarsi di importare i certificati intermedi e radice del TPM nel computer HGS in uso.

Oltre all'identificatore della piattaforma, alla baseline del TPM e ai criteri di integrità del codice, è possibile che HGS configuri e applichi criteri predefiniti, che potrebbe essere necessario modificare. Questi criteri predefiniti vengono misurati dalla baseline TPM raccolta dal server e rappresentano una vasta gamma di impostazioni di sicurezza che devono essere abilitate per proteggere il computer. In presenza di computer senza un'unità IOMMU per la protezione da attacchi DMA (ad esempio, una macchina virtuale), sarà necessario disabilitare il criterio IOMMU.

Per disabilitare il requisito per IOMMU, eseguire il comando seguente nel server HGS:

Disable-HgsAttestationPolicy Hgs_IommuEnabled

È possibile esaminare l'elenco dei criteri e degli host TPM registrati con i comandi seguenti di PowerShell:

Get-HgsAttestationTpmHost
Get-HgsAttestationTpmPolicy

Passaggio 4B: Registrare un computer in modalità tasto host

Questo passaggio descrive il processo di generazione di una chiave univoca per l'host e la registrazione di tale chiave in HGS. Se il servizio di attestazione HGS è configurato per l'uso della modalità TPM, seguire le istruzioni nel passaggio 4A.

Generare una chiave per un computer con SQL Server

L'attestazione con tasto host funziona generando una coppia di chiavi asimmetriche nel computer con SQL Server e fornendo a HGS la metà pubblica di tale chiave.

Ripetere i passaggi seguenti per ogni computer con SQL Server che eseguirà l'attestazione per HGS:

1. Per generare la coppia di chiavi, eseguire il comando seguente in una console di PowerShell con privilegi elevati:

   Set-HgsClientHostKey
   Get-HgsClientHostKey -Path "$HOME\Desktop\$env:computername-key.cer"
   

   Se è già stata creata una chiave host e si vuole generare una nuova coppia di chiavi, usare invece i comandi seguenti:

   Remove-HgsClientHostKey
   Set-HgsClientHostKey
   Get-HgsClientHostKey -Path "$HOME\Desktop\$env:computername-key.cer"
   

2. Condividere il file del certificato con l'amministratore di HGS.

Registrare il computer SQL Server in HGS

Ripetere i passaggi seguenti per ogni computer con SQL Server che eseguirà l'attestazione per HGS:

1. Copiare il file di certificato ottenuto dall'amministratore del computer con SQL Server in un server HGS.

2. Eseguire il comando seguente in una console di PowerShell con privilegi elevati per registrare il computer con SQL Server:

   Add-HgsAttestationHostKey -Name "YourComputerName" -Path "C:\temp\yourcomputername.cer"
   

Passaggio 5: Confermare che l'host può eseguire l'attestazione correttamente

Dopo aver registrato il computer con SQL Server per HGS (Passaggio 4A per la modalità TPM, Passaggio 4B per la modalità con chiave host), è necessario verificare che sia in grado di eseguire correttamente l'attestazione.

È possibile controllare la configurazione del client di attestazione HGS ed eseguire un tentativo di attestazione in qualsiasi momento con Get-HgsClientConfiguration.

L'output del comando sarà simile al seguente:

PS C:\> Get-HgsClientConfiguration


IsHostGuarded                  : True
Mode                           : HostGuardianService
KeyProtectionServerUrl         : http://localhost
AttestationServerUrl           : http://hgs.bastion.local/Attestation
AttestationOperationMode       : HostKey
AttestationStatus              : Passed
AttestationSubstatus           : NoInformation
FallbackKeyProtectionServerUrl :
FallbackAttestationServerUrl   :
IsFallbackInUse                : False

I due campi più importanti nell'output sono AttestationStatus, che indica se il computer ha superato l'attestazione e AttestationSubStatus, in cui vengono indicati i criteri che il computer non ha soddisfatto in caso di esito negativo dell'attestazione.

Di seguito sono illustrati i valori più comuni che possono essere visualizzati in AttestationStatus:

Quando AttestationStatus indica InsecureHostConfiguration, il campo AttestationSubStatus verrà popolato con uno o più nomi dei criteri in errore. La tabella seguente illustra i valori più comuni e indica come correggere gli errori.

Passaggi successivi

• Configurare l'enclave sicura in SQL Server