Registrera datorn med Värdguardianstjänst

gäller för: SQL Server 2019 (15.x) och senare – endast Windows

Den här artikeln beskriver hur du registrerar SQL Server-datorer för att intyga med Host Guardian Service (HGS).

Innan du börjar, se till att du har distribuerat minst en HGS-dator och konfigurerat HGS-attesteringstjänsten. För mer information, se Distribuera Host Guardian-tjänsten för SQL Server.

Steg 1: Installera attesteringsklientkomponenterna

För att en SQL-klient ska kunna verifiera att den pratar med en tillförlitlig SQL Server-dator måste SQL Server-datorn intyga med tjänsten Värdskydd. Attesteringsprocessen hanteras av en valfri Windows-komponent som kallas HGS-klienten. Stegen nedan hjälper dig att installera den här komponenten och börja intyga.

1. Se till att SQL Server-datorn uppfyller de krav som beskrivs i HGS-planeringsdokumentet.

2. Kör följande kommando i en upphöjd PowerShell-konsol för att installera funktionen Host Guardian Hyper-V Support, som innehåller HGS-klienten och attesteringskomponenterna.

   Enable-WindowsOptionalFeature -Online -FeatureName HostGuardian -All
   

3. Starta om för att slutföra installationen.

Steg 2: Kontrollera att virtualiseringsbaserad säkerhet körs

När du installerar funktionen Host Guardian Hyper-V Support konfigureras och aktiveras virtualiseringsbaserad säkerhet (VBS). Enklaver för SQL Server Always Encrypted skyddas av och körs i VBS-miljön. VBS kanske inte startar om datorn inte har en IOMMU-enhet installerad och aktiverad. Om du vill kontrollera om VBS körs öppnar du systeminformationsverktyget genom att köra msinfo32.exe och hitta de Virtualization-based security objekten längst ned i systemsammanfattningen.

skärmbild av

Det första objektet som ska kontrolleras är Virtualization-based security, som kan ha följande tre värden:

• Running innebär att VBS är korrekt konfigurerat och kunde startas. Om datorn visar den här statusen kan du gå vidare till steg 3.
• Enabled but not running innebär att VBS är konfigurerat att köras, men maskinvaran har inte minimikraven för att köra VBS. Du kan behöva ändra konfigurationen av maskinvaran i BIOS eller UEFI för att aktivera valfria processorfunktioner som en IOMMU, eller om maskinvaran verkligen inte stöder de nödvändiga funktionerna kan du behöva sänka VBS-säkerhetskrav. Fortsätt att läsa det här avsnittet om du vill veta mer.
• Not enabled innebär att VBS inte är konfigurerat att köras. Funktionen Host Guardian Hyper-V Support aktiverar automatiskt VBS, så vi rekommenderar att du upprepar steg 1 om du ser den här statusen.

Om VBS inte körs på datorn kontrollerar du Virtualization-based security egenskaper. Jämför värdena i det Required Security Properties objektet med värdena i det Available Security Properties objektet. De nödvändiga egenskaperna måste vara lika med eller en delmängd av de tillgängliga säkerhetsegenskaperna för att VBS ska kunna köras.

När det gäller attestera SQL Server-enklaver har säkerhetsegenskaperna följande betydelse:

• Base virtualization support krävs alltid eftersom det representerar de minsta maskinvarufunktioner som krävs för att köra ett hypervisor-program.
• Secure Boot rekommenderas men krävs inte för SQL Server Always Encrypted. Säker start skyddar mot rootkits genom att kräva att en Microsoft-signerad startladdare körs omedelbart efter att UEFI-initieringen har slutförts. Om du använder TPM-attestering (Trusted Platform Module) mäts säker startaktivering och framtvingas oavsett om VBS har konfigurerats för att kräva säker start.
• DMA Protection rekommenderas men krävs inte för SQL Server Always Encrypted. DMA-skydd använder en IOMMU för att skydda VBS- och enklaverminne från direkt minnesåtkomstattacker. I en produktionsmiljö bör du alltid använda datorer med DMA-skydd. I en utvecklings-/testmiljö är det okej att ta bort kravet på DMA-skydd. Om SQL Server-instansen är virtualiserad har du förmodligen inte DMA-skydd tillgängligt och måste ta bort kravet på att VBS ska köras. Granska förtroendemodell för information om de sänkta säkerhetsgarantierna när du kör på en virtuell dator.

Innan du sänker de nödvändiga säkerhetsfunktionerna för VBS kontrollerar du med oem- eller molntjänstleverantören om det finns ett sätt att aktivera de saknade plattformskraven i UEFI eller BIOS (till exempel aktivera Säker start, Intel VT-d eller AMD IOV).

Om du vill ändra de nödvändiga plattformssäkerhetsfunktionerna för VBS kör du följande kommando i en upphöjd PowerShell-konsol:

# 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

När du har ändrat registret startar du om SQL Server-datorn och kontrollerar om VBS körs igen.

Om datorn hanteras av ditt företag kan grupprincipen eller Microsoft Endpoint Manager åsidosätta alla ändringar du gör i dessa registernycklar efter omstarten. Kontakta IT-supportavdelningen för att se om de distribuerar principer som hanterar din VBS-konfiguration.

Steg 3: Konfigurera attesterings-URL:en

Därefter konfigurerar du SQL Server-datorn med URL:en för HGS-attesteringstjänsten som du har fått från HGS-administratören.

I en upphöjd PowerShell-konsol uppdaterar och kör du följande kommando för att konfigurera attesterings-URL:en.

• Ersätt hgs.bastion.local med HGS-klusternamnet
• Du kan köra Get-HgsServer på valfri HGS-dator för att hämta klusternamnet
• Attesterings-URL:en bör alltid sluta med /Attestation
• SQL Server använder inte de viktigaste skyddsfunktionerna i HGS, så ange en dummy-URL som http://localhost till -KeyProtectionServerUrl

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

Om du inte har registrerat den här datorn med HGS tidigare rapporterar kommandot ett attesteringsfel. Det här resultatet är normalt.

Fältet AttestationMode i cmdlet-utdata anger vilket attesteringsläge som HGS använder.

Fortsätt till steg 4A för att registrera datorn i TPM-läge eller steg 4B för att registrera datorn i värdnyckelläge.

Steg 4A: Registrera en dator i TPM-läge

Förbereda

I det här steget samlar du in information om datorns TPM-tillstånd och registrerar den med HGS.

Om HGS-attesteringstjänsten är konfigurerad för att använda värdnyckelläget går du vidare till steg 4B i stället.

Innan du börjar samla in TPM-mått bör du se till att du arbetar med en känd konfiguration av SQL Server-datorn. Datorn bör ha all nödvändig maskinvara installerad och den senaste inbyggda programvaran och programuppdateringarna ska tillämpas. HGS mäter datorerna mot den här baslinjen när de intygar, så det är viktigt att vara i så säkert och avsett tillstånd som möjligt när du samlar in TPM-mätningarna.

Det finns tre datafiler som samlas in för TPM-attestering, varav vissa kan återanvändas om du har identiskt konfigurerade datorer.

Du kan konfigurera mer än en av varje attesteringsartefakt på HGS för att stödja en blandad maskin- och programvaruflotta. HGS kräver bara att en dator som intygar matchar en princip från varje principkategori. Om du till exempel har tre TPM-baslinjer registrerade på HGS kan datormåtten matcha någon av dessa baslinjer för att uppfylla principkravet.

Konfigurera en kodintegritetsprincip

HGS kräver att varje dator som intygar i TPM-läge har en WDAC-princip (Windows Defender Application Control). WDAC-kodintegritetsprinciper begränsar vilken programvara som kan köras på en dator genom att kontrollera varje process som försöker köra kod mot en lista över betrodda utgivare och fil-hashar. För SQL Server-användningsfallet skyddas enklaver av virtualiseringsbaserad säkerhet och kan inte ändras från värdoperativsystemet, så WDAC-principens strikthet påverkar inte säkerheten för krypterade frågor. Därför rekommenderar vi att du distribuerar en princip för granskningsläge till SQL Server-datorerna för att uppfylla attesteringskravet utan att införa ytterligare begränsningar för systemet.

Om du redan använder en anpassad WDAC-kodintegritetsprincip på datorerna för att härda OS-konfigurationen kan du gå vidare till Samla in TPM-attesteringsinformation.

1. Det finns färdiga exempelprinciper tillgängliga på varje Windows Server 2019, Windows 10 version 1809 och senare operativsystem. Principen AllowAll tillåter att programvara körs på datorn utan begränsningar. Konvertera principen till ett binärt formulär som förstås av operativsystemet och HGS för att använda den. I en upphöjd PowerShell-konsol kör du följande kommandon för att kompilera AllowAll-principen:

   # 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. Följ riktlinjerna i distributionsguiden Windows Defender Application Control för att distribuera allowall_cipolicy.bin-filen till SQL Server-datorerna med grupprincip. För arbetsgruppsdatorer följer du samma process med hjälp av redigeraren för lokal grupprincip (gpedit.msc).

3. Kör gpupdate /force på SQL Server-datorerna för att konfigurera den nya kodintegritetsprincipen och starta sedan om datorerna för att tillämpa principen.

Samla in information om TPM-attestering

Upprepa följande steg för varje SQL Server-dator som ska intygas med HGS:

1. Med dator i ett känt bra tillstånd kör du följande kommandon i PowerShell för att samla in TPM-attesteringsinformationen:

   # 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. Dela de tre attesteringsfilerna med HGS-administratören.

Registrera SQL Server-datorn med HGS

Upprepa följande steg för varje SQL Server-dator som ska intygas med HGS:

1. Kopiera attesteringsfilerna som du hämtade från SQL Server-datoradministratören till HGS-servern.

2. På HGS-servern kör du följande kommandon i en upphöjd PowerShell-konsol för att registrera SQL Server-datorn:

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

   Tips

   Om du stöter på ett fel när du försöker registrera den unika TPM-identifieraren kontrollerar du att du importerat TPM-mellanliggande certifikat och rotcertifikat på den HGS-dator som du använder.

Förutom plattformsidentifieraren, TPM-baslinjen och kodintegritetsprincipen finns det inbyggda principer konfigurerade och framtvingade av HGS som du kan behöva ändra. Dessa inbyggda principer mäts från den TPM-baslinje som du samlar in från servern och representerar olika säkerhetsinställningar som ska aktiveras för att skydda datorn. Om du har datorer som inte har en IOMMU närvarande för att skydda mot DMA-attacker (till exempel en virtuell dator) måste du inaktivera IOMMU-principen.

Om du vill inaktivera IOMMU-kravet kör du följande kommando på HGS-servern:

Disable-HgsAttestationPolicy Hgs_IommuEnabled

Du kan granska listan över registrerade TPM-värdar och policys med följande PowerShell-kommandon:

Get-HgsAttestationTpmHost
Get-HgsAttestationTpmPolicy

Steg 4B: Registrera en dator i värdnyckelläge

Det här steget vägleder dig genom processen för att generera en unik nyckel för värden och registrera den hos HGS. Om HGS-attesteringstjänsten är konfigurerad för att använda TPM-läge följer du riktlinjerna i steg 4A i stället.

Generera en nyckel för en SQL Server-dator

Värdnyckelattestering fungerar genom att generera ett asymmetriskt nyckelpar på SQL Server-datorn och ge HGS den offentliga hälften av den nyckeln.

Upprepa följande steg för varje SQL Server-dator som ska intygas med HGS:

1. Om du vill generera nyckelparet kör du följande kommando i en upphöjd PowerShell-konsol:

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

   Om du redan har skapat en värdnyckel och vill generera ett nytt nyckelpar använder du följande kommandon i stället:

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

2. Dela certifikatfilen med HGS-administratören.

Registrera SQL Server-datorn med HGS

Upprepa följande steg för varje SQL Server-dator som ska intygas med HGS:

1. Kopiera certifikatfilen som du hämtade från SQL Server-datoradministratören till en HGS-server.

2. Kör följande kommando i en upphöjd PowerShell-konsol för att registrera SQL Server-datorn:

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

Steg 5: Bekräfta att värden kan intyga framgångsrikt

När du har registrerat SQL Server-datorn med HGS (Steg 4A- för TPM-läge steg 4B för värdnyckelläge) bör du bekräfta att den kan bekräfta det.

Du kan kontrollera konfigurationen av HGS-attesteringsklienten och utföra ett attesteringsförsök när som helst med Get-HgsClientConfiguration.

Kommandots utdata ser ut ungefär så här:

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

De två viktigaste fälten i utdata är AttestationStatus, som anger om datorn passerade attesteringen, och AttestationSubStatus, som beskriver vilka policyer datorn inte klarade om den misslyckades med attesteringen.

De vanligaste värdena som kan visas i AttestationStatus förklaras nedan:

När AttestationStatus visar InsecureHostConfigurationfylls fältet AttestationSubStatus med ett eller flera principnamn som misslyckades. I tabellen nedan beskrivs de vanligaste värdena och hur du åtgärdar felen.

Nästa steg

• Konfigurera den säkra enklaven i SQL Server