Gestire il servizio Sorveglianza host

• Si applica a:

  ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

Il servizio Sorveglianza host (HGS) è l’elemento centrale della soluzione Infrastruttura sorvegliata. È responsabile di garantire che gli host Hyper-V nell’infrastruttura siano noti al provider dei servizi di hosting o all'azienda e che eseguono software attendibile e di gestire le chiavi utilizzate per avviare le macchine virtuali schermate. Quando un tenant decide di affidare l'hosting delle sue macchine virtuali schermate, si affida alla configurazione e alla gestione del Servizio Sorveglianza host. Pertanto, è fondamentale seguire le procedure consigliate nella gestione del Servizio Sorveglianza host per garantire sicurezza, disponibilità e attendibilità di Infrastruttura sorvegliata. Le indicazioni contenute nelle sezioni seguenti affrontano i problemi operativi più comuni che gli amministratori di HGS si trovano ad affrontare.

Limitare l'accesso degli amministratori a HGS

A causa della natura sensibile della sicurezza di HGS, è importante assicurarsi che gli amministratori siano membri fidati dell’organizzazione e, idealmente, separati dagli amministratori delle risorse infrastruttura. Inoltre, si consiglia di gestire HGS solo da postazioni di lavoro sicure, utilizzando protocolli di comunicazione sicuri, come WinRM su HTTPS.

Separazione dei compiti

Quando si configura HGS, è possibile creare una foresta Active Directory isolata solo per HGS o aggiungere HGS a un dominio esistente e attendibile. Questa decisione e i ruoli assegnati agli amministratori dell'organizzazione determinano il limite attendibilità di HGS. Chiunque abbia accesso a HGS, direttamente come amministratore o indirettamente come amministratore di qualcos'altro (ad esempio Active Directory) che può influire su HGS, ha il controllo sull’infrastruttura sorvegliata. Gli amministratori di HGS scelgono quali host Hyper-V sono autorizzati a eseguire le macchine virtuali schermate e gestiscono i certificati necessari per avviare tali macchine virtuali schermate. Un utente o un amministratore malintenzionato che ha accesso a HGS può utilizzare tale potere per autorizzare host compromessi a eseguire macchine virtuali schermate, avviare un attacco Denial of Service rimuovendo materiale chiave e altro.

Per evitare questo rischio, si consiglia vivamente di limitare la sovrapposizione tra gli amministratori degli ambienti HGS (compreso il dominio a cui HGS è stato aggiunto) e Hyper-V. Assicurandosi che nessun amministratore abbia accesso a entrambi i sistemi, un utente malintenzionato dovrebbe compromettere due diversi account di due utenti per completare il suo tentativo di modifica dei criteri HGS. Ciò significa anche che gli amministratori del dominio e dell'azienda per i due ambienti Active Directory non devono essere la stessa persona, né HGS deve usare la stessa foresta Active Directory degli host Hyper-V. Chiunque possa autorizzarsi da solo l'accesso a più risorse rappresenta un rischio per la sicurezza.

Uso di JEA (Just Enough Administration)

HGS viene fornito con ruoli Just Enough Administration (JEA) integrati per permettere una gestione più sicura. JEA permette di delegare le attività di amministrazione a utenti non amministratori, il che significa che le persone che gestiscono i criteri HGS non devono necessariamente essere amministratori dell'intera macchina o dominio. JEA opera limitando i comandi che un utente può eseguire in una sessione PowerShell e utilizzando un account locale temporaneo con funzionamento dettagliato (univoco per ogni sessione utente) per eseguire i comandi che normalmente richiedono l'elevazione.

HGS viene fornito con 2 ruoli JEA preconfigurati:

• Amministratori HGS, che permette agli utenti di gestire tutti i criteri di HGS, compresa l'autorizzazione di nuovi host per l'esecuzione di macchine virtuali schermate.
• Revisori HGS, che permette agli utenti solo di verificare i criteri esistenti. Entrambi i ruoli non possono apportare modifiche alla configurazione di HGS.

Per utilizzare JEA, è necessario creare un nuovo utente standard e renderlo membro del gruppo Amministratori HGS o Revisori HGS. Se si è usato Install-HgsServer per configurare una foresta per HGS, questi gruppi saranno denominati rispettivamente "Amministratoriservicename" e " Revisoriservicename", dove servicename è il nome della rete del cluster HGS. Se si è aggiunto HGS a un dominio esistente, occorre fare riferimento ai nomi dei gruppi specificati in Initialize-HgsServer.

Creare utenti standard per i ruoli di amministratore e revisore di HGS

$hgsServiceName = (Get-ClusterResource HgsClusterResource | Get-ClusterParameter DnsName).Value
$adminGroup = $hgsServiceName + "Administrators"
$reviewerGroup = $hgsServiceName + "Reviewers"

New-ADUser -Name 'hgsadmin01' -AccountPassword (Read-Host -AsSecureString -Prompt 'HGS Admin Password') -ChangePasswordAtLogon $false -Enabled $true
Add-ADGroupMember -Identity $adminGroup -Members 'hgsadmin01'

New-ADUser -Name 'hgsreviewer01' -AccountPassword (Read-Host -AsSecureString -Prompt 'HGS Reviewer Password') -ChangePasswordAtLogon $false -Enabled $true
Add-ADGroupMember -Identity $reviewerGroup -Members 'hgsreviewer01'

Verificare i criteri con il ruolo di revisore

Su un computer remoto dotato di connettività di rete a HGS, eseguire i seguenti comandi in PowerShell per entrare nella sessione JEA con le credenziali di revisore. È importante notare che, poiché l'account di revisore è solo un utente standard, non può essere utilizzato per la normale comunicazione remota di Windows PowerShell, per l'accesso a HGS da desktop remoto, ecc.

Enter-PSSession -ComputerName <hgsnode> -Credential '<hgsdomain>\hgsreviewer01' -ConfigurationName 'microsoft.windows.hgs'

È quindi possibile verificare quali comandi sono consentiti nella sessione con Get-Command ed eseguire qualsiasi comando consentito per verificare la configurazione. Nell'esempio seguente, stiamo verificando quali criteri sono abilitati su HGS.

Get-Command

Get-HgsAttestationPolicy

Digitare il comando Exit-PSSession o il suo alias, exit, una volta terminata la sessione JEA.

Aggiungere un nuovo criterio a HGS usando il ruolo di amministratore

Per modificare effettivamente un criterio, è necessario connettersi all'endpoint JEA con un'identità appartenente al gruppo 'hgsAdministrators'. Nell'esempio che segue, mostriamo come è possibile copiare un nuovo criterio di integrità del codice in HGS e registrarlo utilizzando JEA. La sintassi potrebbe essere diversa da quella a cui si è abituati. Questo per tenere conto di alcune restrizioni di JEA, come il fatto di non avere accesso all'intero file system.

$cipolicy = Get-Item "C:\temp\cipolicy.p7b"
$session = New-PSSession -ComputerName <hgsnode> -Credential '<hgsdomain>\hgsadmin01' -ConfigurationName 'microsoft.windows.hgs'
Copy-Item -Path $cipolicy -Destination 'User:' -ToSession $session

# Now that the file is copied, we enter the interactive session to register it with HGS
Enter-PSSession -Session $session
Add-HgsAttestationCiPolicy -Name 'New CI Policy via JEA' -Path 'User:\cipolicy.p7b'

# Confirm it was added successfully
Get-HgsAttestationPolicy -PolicyType CiPolicy

# Finally, remove the PSSession since it is no longer needed
Exit-PSSession
Remove-PSSession -Session $session

Monitoraggio di HGS

Origini eventi e inoltro

Gli eventi di HGS vengono visualizzati nel registro eventi di Windows in due origini:

• HostGuardianService-Attestation
• HostGuardianService-KeyProtection

È possibile visualizzare questi eventi avviando Visualizzatore eventi e passando a Microsoft-Windows-HostGuardianService-Attestation e Microsoft-Windows-HostGuardianService-KeyProtection.

In un ambiente di grandi dimensioni, spesso è preferibile inoltrare gli eventi a Raccolta eventi Windows centrale per facilitare l'analisi degli eventi. Per ulteriori informazioni, consultare la documentazione sull'inoltro degli eventi di Windows.

Uso del System Center Operations Manager

È inoltre possibile utilizzare System Center 2016 - Operations Manager per monitorare HGS e gli host sorvegliati. Il pacchetto di gestione dell’infrastruttura sorvegliata dispone di monitor di eventi per verificare la presenza di errori comuni di configurazione che possono portare a tempi di inattività del data center, tra cui host che non superano l'attestazione e server HGS che segnalano errori.

Per iniziare, installare e configurare SCOM 2016 e scaricare il management pack di infrastruttura sorvegliata. La guida al management pack inclusa spiega come configurare il management pack e comprendere l'ambito dei suoi monitoraggi.

Backup e ripristino di HGS

Pianificazione del ripristino di emergenza

Nel redigere i piani di ripristino di emergenza, è importante considerare i requisiti univoci del servizio di Sorveglianza host nell’infrastruttura sorvegliata. Se si perdono alcuni o tutti i nodi HGS, si possono verificare problemi di disponibilità immediata che impediscono agli utenti di avviare le loro macchine virtuali schermate. In caso di perdita dell'intero cluster HGS, è necessario disporre di backup completi della configurazione HGS per ripristinare il cluster HGS e riprendere le normali operazioni. Questa sezione illustra i passaggi necessari per prepararsi a questo scenario.

Innanzitutto, è importante capire quali sono gli elementi di HGS di cui è importante eseguire il backup. HGS conserva diverse informazioni che gli permettono di determinare quali host sono autorizzati a eseguire le macchine virtuali schermate. Sono inclusi:

1. Identificatori di sicurezza di Active Directory per i gruppi contenenti host attendibili (quando si utilizza l'attestazione di Active Directory);
2. Identificatori TPM univoci per ogni host dell'ambiente personale;
3. Criteri TPM per ogni configurazione univoca di host; e
4. Criteri di integrità del codice che determinano quale software è consentito eseguire sugli host.

Per ottenere questi elementi di attestazione è necessario coordinarsi con gli amministratori dell’infrastruttura di hosting, rendendo potenzialmente difficile ottenere nuovamente queste informazioni dopo un'emergenza.

Inoltre, HGS richiede l'accesso a due o più certificati utilizzati per crittografare e firmare le informazioni necessarie per l'avvio di una macchina virtuale schermata (protezione con chiave). Questi certificati sono ben noti (utilizzati dai proprietari delle macchine virtuali schermate per autorizzare l'infrastruttura a eseguire le loro macchine virtuali) e devono essere ripristinati dopo un’emergenza per un'esperienza di ripristino senza problemi. Se non si ripristina HGS con gli stessi certificati dopo un’emergenza, ogni macchina virtuale dovrà essere aggiornata per autorizzare le nuove chiavi a decrittografare le informazioni. Per motivi di sicurezza, solo il proprietario della macchina virtuale può aggiornare la configurazione della stessa per autorizzare le nuove chiavi; pertanto, se non si ripristinano le chiavi dopo un’emergenza, ogni proprietario della macchina virtuale dovrà intervenire per far funzionare nuovamente le proprie macchine virtuali.

Prepararsi allo scenario peggiore

Per prepararsi a una perdita completa di HGS, è necessario eseguire due operazioni:

1. Eseguire il backup dei criteri di attestazione di HGS
2. Eseguire il backup delle chiavi di HGS

Le indicazioni su come eseguire entrambe le operazioni sono fornite nella sezione Backup di HGS.

Si consiglia inoltre, ma non è obbligatorio, di eseguire il backup dell'elenco degli utenti autorizzati a gestire HGS nel dominio Active Directory o in Active Directory stesso.

I backup devono essere eseguiti regolarmente per garantire che le informazioni siano aggiornate e conservate in modo sicuro per evitare manomissioni o furti.

Non è consigliabile eseguire il backup o tentare di ripristinare un'intera immagine di sistema di un nodo HGS. Nel caso in cui si sia perso l'intero cluster, la procedura consigliata è di impostare un nuovo nodo HGS nuovo e ripristinare solo lo stato HGS, non l'intero sistema operativo del server.

Ripristino della perdita di un nodo

Se si perdono uno o più nodi (ma non tutti i nodi) del cluster HGS, è possibile semplicemente aggiungere dei nodi al cluster seguendo le indicazioni della guida alla distribuzione. I criteri di attestazione si sincronizzeranno automaticamente, così come i certificati forniti a HGS come file PFX con le relative password. Per i certificati aggiunti a HGS utilizzando un’identificazione personale (in genere, certificati non esportabili e certificati con supporto hardware), è necessario assicurarsi che ogni nuovo nodo abbia accesso alla chiave privata di ciascun certificato.

Recupero dalla perdita dell'intero cluster

Se l'intero cluster HGS è inattivo e non si riesce a riportarlo di nuovo online, è necessario ripristinare HGS da un backup. Il ripristino di HGS da un backup comporta innanzitutto la creazione di un nuovo cluster HGS secondo le indicazioni della guida alla distribuzione. Si consiglia fortemente, ma non è obbligatorio, di utilizzare lo stesso nome del cluster quando si configura l'ambiente HGS di ripristino, per facilitare la risoluzione dei nomi da parte degli host. L'uso dello stesso nome evita di dover riconfigurare gli host con nuovi URL di attestazione e protezione delle chiavi. Se si sono ripristinati gli oggetti nel dominio Active Directory che supporta HGS, si consiglia di rimuovere gli oggetti che rappresentano il cluster HGS, i computer, l'account di servizio e i gruppi JEA prima di inizializzare il server HGS.

Una volta configurato il primo nodo HGS (ad esempio, è stato installato e inizializzato), si seguirà la procedura descritta in Ripristino di HGS da un backup per ripristinare i criteri di attestazione e le metà pubbliche dei certificati di protezione delle chiavi. È necessario ripristinare manualmente le chiavi private dei certificati seguendo le indicazioni del proprio Provider Certificate (ad esempio, importando il certificato in Windows o configurando l'accesso ai certificati supportati da HSM). Dopo la configurazione del primo nodo, è possibile continuare a installare altri nodi nel cluster fino a raggiungere la capacità e la resilienza desiderate.

Backup di HGS

L'amministratore di HGS deve essere responsabile del backup di HGS su base regolare. Un backup completo contiene materiale chiave riservato che deve essere protetto in modo appropriato. Se un'entità non attendibile dovesse accedere a queste chiavi, potrebbe utilizzare tale materiale per creare un ambiente HGS dannoso allo scopo di compromettere le macchine virtuali schermate.

Backup dei criteri di attestazione Per eseguire il backup dei criteri di attestazione di HGS, eseguire il seguente comando su qualsiasi nodo server HGS di lavoro. Sarà richiesto di fornire una password. Questa password viene utilizzata per crittografare tutti i certificati aggiunti a HGS utilizzando un file PFX (invece di un’identificazione personale del certificato).

Export-HgsServerState -Path C:\temp\HGSBackup.xml

Nota

Se si utilizza l'attestazione ritenuta attendibile dall'amministratore, è necessario eseguire separatamente il backup dell'appartenenza ai gruppi di sicurezza utilizzati da HGS per autorizzare gli host sorvegliati. HGS eseguirà il backup solo del SID dei gruppi di sicurezza, non dei membri al loro interno. Nel caso in cui questi gruppi vadano persi durante un’emergenza, sarà necessario ricreare i gruppi e aggiungere nuovamente ogni host sorvegliato.

Backup di certificati

Il comando Export-HgsServerState esegue il backup di tutti i certificati basati su PFX aggiunti a HGS al momento dell'esecuzione del comando. Se i certificati sono stati aggiunti a HGS utilizzando un’identificazione personale (tipica dei certificati non esportabili e supportati da hardware), è necessario eseguire manualmente il backup delle chiavi private dei certificati. Per individuare quali certificati sono registrati con HGS e devono essere sottoposti a backup manuale, eseguire il seguente comando PowerShell su qualsiasi nodo server HGS di lavoro.

Get-HgsKeyProtectionCertificate | Where-Object { $_.CertificateData.GetType().Name -eq 'CertificateReference' } | Format-Table Thumbprint, @{ Label = 'Subject'; Expression = { $_.CertificateData.Certificate.Subject } }

Per ciascuno dei certificati elencati, è necessario eseguire manualmente il backup della chiave privata. Se si utilizza un certificato basato su software non esportabile, è necessario contattare l'autorità di certificazione per assicurarsi che disponga di un backup del certificato e/o che possa riemetterlo su richiesta. Per i certificati creati e memorizzati nei moduli security hardware, è necessario consultare la documentazione del dispositivo per avere indicazioni sulla pianificazione del ripristino di emergenza.

I backup dei certificati devono essere conservati insieme ai backup dei criteri di attestazione in un luogo sicuro, in modo da poterli ripristinare insieme.

Configurazione aggiuntiva per il backup

Il backup dello stato del server HGS non includerà il nome del cluster HGS, le informazioni di Active Directory o i certificati SSL utilizzati per proteggere le comunicazioni con le API HGS. Queste impostazioni sono importanti per la coerenza, ma non sono fondamentali per riportare il cluster HGS online dopo un’emergenza.

Per acquisire il nome del servizio HGS, eseguire Get-HgsServer e annotare il nome flat negli URL di attestazione e protezione delle chiavi. Ad esempio, se l'URL di attestazione è "https://hgs.contoso.com/Attestation", "hgs" è il nome del servizio HGS.

Il dominio Active Directory usato da HGS deve essere gestito come qualsiasi altro dominio Active Directory. Quando si ripristina HGS dopo un’emergenza, non è necessario ricreare esattamente gli oggetti presenti nel dominio corrente. Tuttavia, il ripristino sarà più semplice se si esegue il backup di Active Directory e si conserva un elenco degli utenti JEA autorizzati a gestire il sistema, nonché l'appartenenza a qualsiasi gruppo di sicurezza usato dall'attestazione ritenuta attendibile dall'amministratore per autorizzare gli host sorvegliato.

Per identificare l’identificazione personale dei certificati SSL configurati per HGS, eseguire il seguente comando in PowerShell. È quindi possibile eseguire il backup dei certificati SSL secondo le istruzioni del proprio Provider Certificate.

Get-WebBinding -Protocol https | Select-Object certificateHash

Ripristino di HGS da un backup

I passaggi seguenti descrivono come ripristinare le impostazioni di HGS da un backup. I passaggi sono applicabili sia alle situazioni in cui si cerca di annullare le modifiche apportate alle istanze HGS già in esecuzione, sia per la creazione di un nuovo cluster HGS dopo la perdita completa di quello precedente.

Impostare un cluster HGS sostitutivo

Prima di poter ripristinare HGS, è necessario disporre di un cluster HGS inizializzato su cui ripristinare la configurazione. Se si stanno semplicemente importando le impostazioni eliminate accidentalmente in un cluster esistente (in esecuzione), è possibile saltare questo passaggio. Se si sta ripristinando una perdita completa di HGS, è necessario installare e inizializzare almeno un nodo HGS seguendo le indicazioni della guida alla distribuzione.

In particolare, sarà necessario:

1. Configurare il dominio HGS o aggiungere HGS a un dominio esistente
2. Inizializzare il server HGS utilizzando le chiavi esistenti o un set di chiavi temporanee. È possibile rimuovere le chiavi temporanee dopo aver importato le chiavi effettive dai file di backup di HGS.
3. Importare le impostazioni HGS dal backup per ripristinare i gruppi di host attendibili, i criteri di integrità del codice, le baseline TPM e gli identificatori TPM

Suggerimento

Non è necessario che il nuovo cluster HGS utilizzi gli stessi certificati, nome di servizio o dominio dell'istanza HGS da cui è stato esportato il file di backup.

Importare le impostazioni da un backup

Per ripristinare i criteri di attestazione, i certificati basati su PFX e le chiavi pubbliche dei certificati non PFX nel nodo HGS da un file di backup, eseguire il seguente comando su un nodo server HGS inizializzato. Verrà richiesto di inserire la password specificata al momento della creazione del backup.

Import-HgsServerState -Path C:\Temp\HGSBackup.xml

Se si desidera importare solo i criteri di attestazione ritenuta attendibile dall'amministratore o i criteri di attestazione con attendibilità TPM, è possibile farlo specificando i flag -ImportActiveDirectoryModeState o -ImportTpmModeState a Import-HgsServerState.

Assicurarsi che l'ultimo aggiornamento cumulativo per Windows Server 2016 sia installato prima di eseguire il punto Import-HgsServerState. In caso contrario, potrebbe verificarsi un errore di importazione.

Nota

Se si ripristinano i criteri su un nodo HGS esistente in cui sono già installati uno o più criteri, il comando Import mostrerà un errore per ogni criterio duplicato. Questo è un comportamento previsto e può essere tranquillamente ignorato nella maggior parte dei casi.

Reinstallare le chiavi private dei certificati

Se uno qualsiasi dei certificati usati su HGS da cui è stato creato il backup è stato aggiunto usando l’identificazione personale, solo la chiave pubblica di tali certificati sarà inclusa nel file di backup. Ciò significa che è necessario installare manualmente e/o concedere l'accesso alle chiavi private per ciascuno di questi certificati prima che HGS possa servire le richieste degli host Hyper-V. Le azioni necessarie per completare questo passaggio variano a seconda del modo in cui il certificato è stato originariamente rilasciato. Per i certificati supportati da software rilasciati da un'autorità di certificazione, si dovrà contattare la propria autorità di certificazione per ottenere la chiave privata e installarla su ogni nodo HGS secondo le relative istruzioni. Analogamente, se i certificati sono supportati da hardware, è necessario consultare la documentazione del fornitore del modulo security hardware per installare i driver necessari su ogni nodo HGS per connettersi all'HSM e garantire a ogni macchina l'accesso alla chiave privata.

Come promemoria, i certificati aggiunti a HGS utilizzando le identificazioni personali richiedono la replica manuale delle chiavi private a ciascun nodo. È necessario ripetere questo passaggio su ogni altro nodo aggiunto al cluster HGS ripristinato.

Revisione dei criteri di attestazione importati

Dopo aver importato le impostazioni da un backup, si consiglia di esaminare attentamente tutti i criteri importati utilizzando Get-HgsAttestationPolicy per assicurarsi che solo gli host attendibili per eseguire le macchine virtuali schermate siano in grado di eseguire correttamente le attestazioni. Se si trovano criteri che non corrispondono più alla propria postura di sicurezza, è possibile disattivarli o rimuoverli.

Eseguire la diagnostica per controllare lo stato del sistema

Dopo aver completato la configurazione e il ripristino dello stato del nodo HGS, è necessario eseguire lo strumento di diagnostica HGS per verificare lo stato del sistema. A tal fine, eseguire il seguente comando sul nodo HGS in cui è stata ripristinata la configurazione:

Get-HgsTrace -RunDiagnostics

Se il "Risultato complessivo" non è "Superato", sono necessari ulteriori passaggi per completare la configurazione del sistema. Per ulteriori informazioni, controllare i messaggi riportati nei subtest non riusciti.

Applicazione di patch a HGS

È importante mantenere aggiornati i nodi del servizio Sorveglianza host installando l'ultimo aggiornamento cumulativo quando si rende disponibile. Se si sta configurando un nuovo nodo HGS, si consiglia di installare tutti gli aggiornamenti disponibili prima di installare il ruolo HGS o di configurarlo. In questo modo, tutte le funzionalità nuove o modificate avranno effetto immediato.

Quando si esegue la patch all’infrastruttura sorvegliata, si consiglia vivamente di aggiornare tutti gli host Hyper-V prima di aggiornare HGS. Questo per garantire che eventuali modifiche ai criteri di attestazione su HGS vengano apportate dopo che gli host Hyper-V sono stati aggiornati per fornire le informazioni necessarie. Se un aggiornamento modifica il comportamento dei criteri, questi non verranno automaticamente attivati per evitare di interrompere le attività dell'infrastruttura. Per attivare i criteri di attestazione nuovi o modificati, tali aggiornamenti richiedono di seguire le indicazioni riportate nella sezione seguente. Si consiglia di leggere le note sulla versione di Windows Server e di tutti gli aggiornamenti cumulativi installati per verificare se gli aggiornamenti dei criteri sono necessari.

Aggiornamenti che richiedono l'attivazione dei criteri

Se un aggiornamento per HGS introduce o modifica in modo significativo il comportamento di un criterio di attestazione, è necessario un passaggio aggiuntivo per attivare il criterio modificato. Le modifiche ai criteri vengono applicate solo dopo aver esportato e importato lo stato di HGS. È necessario attivare i criteri nuovi o modificati solo dopo aver applicato l'aggiornamento cumulativo a tutti gli host e a tutti i nodi HGS dell'ambiente personale. Una volta che ogni macchina è stata aggiornata, eseguire i seguenti comandi su qualsiasi nodo HGS per attivare il processo di aggiornamento:

$password = Read-Host -AsSecureString -Prompt "Enter a temporary password"
Export-HgsServerState -Path .\temporaryExport.xml -Password $password
Import-HgsServerState -Path .\temporaryExport.xml -Password $password

Se è stato introdotto un nuovo criterio, questo sarà disabilitato per impostazione predefinita. Per attivare il nuovo criterio, individuarlo nell'elenco dei criteri Microsoft (con il prefisso "HGS_") e attivarlo con i seguenti comandi:

Get-HgsAttestationPolicy

Enable-HgsAttestationPolicy -Name <Hgs_NewPolicyName>

Gestione dei criteri di attestazione

HGS mantiene diversi criteri di attestazione che definiscono l'insieme minimo di requisiti che un host deve soddisfare per essere considerato "integro" e permettere l'esecuzione di macchine virtuali schermate. Alcuni di questi criteri sono definiti da Microsoft, altri sono aggiunti dall'utente per definire i criteri di integrità del codice, le baseline TPM e gli host consentiti nell’ambiente personale. La manutenzione periodica di questi criteri è necessaria per garantire che gli host possano continuare a eseguire correttamente l’attestazione man mano che si aggiornano e si sostituiscono e per assicurare che gli host o le configurazioni non attendibili non possano eseguire attestazioni.

Per l'attestazione ritenuta attendibile dall'amministrazione, c'è solo un criterio che determina se un host è integro: l'appartenenza a un gruppo di sicurezza noto e attendibile. L'attestazione TPM è più complicata e prevede vari criteri per misurare il codice e la configurazione di un sistema prima di determinare se è integro.

Un singolo HGS può essere configurato con entrambi i criteri Active Directory e TPM contemporaneamente, ma il servizio verificherà solo i criteri per la modalità corrente per cui è configurato quando un host tenta di eseguire un'attestazione. Per verificare la modalità del proprio server HGS, eseguire Get-HgsServer.

Criteri predefiniti

Per l'attestazione basata sul TPM, ci sono diversi criteri integrati configurati su HGS. Alcuni di questi criteri sono "bloccati", ovvero non possono essere disattivati per motivi di sicurezza. La tabella seguente spiega lo scopo di ciascun criterio predefinito.

Nome criteri	Ambito
Hgs_SecureBootEnabled	Richiede che gli host abbiano abilitato l’avvio protetto. Questo è necessario per misurare i binari di avvio e altre impostazioni bloccate dall'UEFI.
Hgs_UefiDebugDisabled	Assicura che gli host non abbiano un debugger del kernel abilitato. I debugger in modalità utente sono bloccati dai criteri di integrità del codice.
Hgs_SecureBootSettings	Criterio negativo per garantire che gli host corrispondano ad almeno una baseline TPM (definita dall'amministratore).
Hgs_CiPolicy	Criterio negativo per garantire che gli host utilizzino uno dei criteri CI definiti dall'amministratore.
Hgs_HypervisorEnforcedCiPolicy	Richiede che il criterio di integrità del codice sia applicato dall'hypervisor. La disattivazione di questo criterio indebolisce le protezioni contro gli attacchi ai criteri di integrità del codice in modalità kernel.
Hgs_FullBoot	Assicura che l'host non sia stato riattivato dalla sospensione o dall'ibernazione. Gli host devono essere correttamente riavviati o spenti per superare questo criterio.
Hgs_VsmIdkPresent	Richiede che la sicurezza basata sulla virtualizzazione sia in esecuzione sull'host. L'IDK rappresenta la chiave necessaria per crittografare le informazioni inviate allo spazio di memoria sorvegliato dell'host.
Hgs_PageFileEncryptionEnabled	Richiede che i file di pagina siano crittografati sull'host. La disattivazione di questo criterio potrebbe comportare l'esposizione di informazioni se un file di paging non crittografato viene esaminato alla ricerca di segreti del tenant.
Hgs_BitLockerEnabled	Richiede che BitLocker sia abilitato sull'host Hyper-V. Questo criterio è disattivato per impostazione predefinita per motivi di prestazioni e non è consigliabile attivarlo. Questo criterio non influisce sulla crittografia delle macchine virtuali schermate.
Hgs_IommuEnabled	Richiede che l'host disponga di un dispositivo IOMMU in uso per prevenire attacchi di accesso diretto alla memoria. La disattivazione di questo criterio e l'utilizzo di host senza un dispositivo IOMMU abilitato può esporre i segreti delle macchine virtuali dei tenant ad attacchi diretti alla memoria.
Hgs_NoHibernation	Richiede che l'ibernazione sia disabilitata sull'host Hyper-V. La disabilitazione di questo criterio potrebbe consentire agli host di salvare la memoria delle macchine virtuali schermate in un file ibernazione non crittografato.
Hgs_NoDumps	Richiede che i dump della memoria siano disabilitati sull'host Hyper-V. Se si disattiva questo criterio, si consiglia di configurare la crittografia dei dump per evitare che la memoria della macchina virtuale schermata venga salvata in file di crash dump non crittografati.
Hgs_DumpEncryption	Richiede che i dump di memoria, se abilitati sull'host Hyper-V, siano crittografati con una chiave di crittografia HGS attendibile. Questo criterio non si applica se i dump non sono abilitati sull'host. Se questo criterio e Hgs_NoDumps sono entrambi disattivati, la memoria della macchina virtuale schermata potrebbe essere salvata in un file di dump non crittografato.
Hgs_DumpEncryptionKey	Criterio negativo per garantire che gli host configurati per consentire che i dump di memoria utilizzino una chiave di crittografia del file di dump definita dall'amministratore e nota a HGS. Questo criterio non si applica quando Hgs_DumpEncryption è disattivato.

Autorizzazione di nuovi host sorvegliati

Per autorizzare un nuovo host a diventare un host sorvegliato (ad esempio, eseguire correttamente attestazioni), HGS deve ritenere l'host attendibile e (se configurato per usare l'attestazione TPM) del software in esecuzione su di esso. I passaggi per autorizzare un nuovo host sono diversi a seconda della modalità di attestazione per cui HGS è attualmente configurato. Per verificare la modalità di attestazione dell’infrastruttura sorvegliata, eseguire Get-HgsServer su qualsiasi nodo HGS.

Configurazione software

Sul nuovo host Hyper-V, assicurarsi che sia installato Windows Server 2016 Datacenter Edition. Windows Server 2016 Standard non può eseguire macchine virtuali schermate in un'infrastruttura sorvegliata. Sull'host può essere installato Esperienza desktop o Server Core.

Sui server con Esperienza desktop e Server Core, è necessario installare i ruoli del server Hyper-V e Supporto per Sorveglianza host per Hyper-V:

Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart

Attestazione ritenuta attendibile dall'amministratore

Per registrare un nuovo host in HGS quando si utilizza l'attestazione ritenuta attendibile dall'amministratore, è necessario prima aggiungere l'host a un gruppo di sicurezza nel dominio a cui è stato aggiunto. In genere, ogni dominio dispone di un gruppo di sicurezza per gli host sorvegliati. Se il gruppo è già stato registrato in HGS, l'unica azione da compiere è riavviare l'host per aggiornare l'appartenenza al gruppo.

È possibile verificare quali gruppi di sicurezza sono attendibili per HGS eseguendo il seguente comando:

Get-HgsAttestationHostGroup

Per registrare un nuovo gruppo di sicurezza con HGS, acquisire prima l'identificatore di sicurezza (SID) del gruppo nel dominio dell'host e registrare il SID con HGS.

Add-HgsAttestationHostGroup -Name "Contoso Guarded Hosts" -Identifier "S-1-5-21-3623811015-3361044348-30300820-1013"

Le istruzioni su come impostare l’attendibilità tra il dominio dell'host e HGS sono disponibili nella guida alla distribuzione.

Attestazione con attendibilità TPM

Quando HGS è configurato in modalità TPM, gli host devono superare tutti i criteri bloccati e i criteri "abilitati" con il prefisso "Hgs_", nonché almeno una baseline TPM, un identificatore TPM e un criterio di integrità del codice. Ogni volta che si aggiunge un nuovo host, è necessario registrare il nuovo identificatore TPM con HGS. Finché l'host esegue lo stesso software (e dispone dello stesso criterio di integrità del codice applicato) e la stessa baseline TPM di un altro host nell’ambiente personale, non sarà necessario aggiungere nuovi criteri o baseline CI.

Aggiunta dell'identificatore TPM per un nuovo host Sul nuovo host, eseguire il seguente comando per acquisire l'identificatore TPM. Assicurarsi di specificare un nome univoco per l'host che consenta di cercarlo in HGS. Queste informazioni sono necessarie se si disattiva l'host o se si vuole evitare che esegua macchine virtuali schermate in HGS.

(Get-PlatformIdentifier -Name "Host01").InnerXml | Out-File C:\temp\host01.xml -Encoding UTF8

Copiare questo file sul server HGS, quindi eseguire il seguente comando per registrare l'host con HGS.

Add-HgsAttestationTpmHost -Name 'Host01' -Path C:\temp\host01.xml

Aggiunta di una nuova baseline TPM Se il nuovo host esegue una nuova configurazione hardware o firmware per l’ambiente personale, potrebbe essere necessario usare una nuova baseline TPM. A tal fine, eseguire il seguente comando sull'host.

Get-HgsAttestationBaselinePolicy -Path 'C:\temp\hardwareConfig01.tcglog'

Nota

Se si visualizza un errore che indica che l'host non ha superato la convalida e non sarà in grado di eseguire attestazioni, non preoccuparsi. Si tratta di un controllo prerequisiti per assicurarsi che l'host sia in grado di eseguire le macchine virtuali schermate e probabilmente significa che non è stato ancora applicato un criterio di integrità del codice o un'altra impostazione necessaria. Leggere il messaggio di errore, apportare le modifiche suggerite e riprovare. In alternativa, è possibile saltare la convalida aggiungendo il flag -SkipValidation al comando.

Copiare la baseline TPM sul server HGS, quindi registrarla con il seguente comando. Si consiglia di usare una convenzione di denominazione che permetta di comprendere la configurazione hardware e firmware di questa classe di host Hyper-V.

Add-HgsAttestationTpmPolicy -Name 'HardwareConfig01' -Path 'C:\temp\hardwareConfig01.tcglog'

Aggiunta di un nuovo criterio di integrità del codice Se si è modificato il criterio di integrità del codice in esecuzione sugli host Hyper-V, è necessario registrare il nuovo criterio con HGS prima che tali host possano eseguire correttamente attestazioni. Su un host di riferimento, che funge da immagine master per le macchine Hyper-V fidate dell'ambiente personale, acquisire un nuovo criterio CI usando il comando New-CIPolicy. Si consiglia di utilizzare il livello FilePublisher e il fallback Hash per i criteri CI dell'host Hyper-V. È necessario creare prima un criterio CI in modalità di controllo per assicurarsi che tutto funzioni come previsto. Dopo aver convalidato un carico di lavoro campione sul sistema, è possibile applicare il criterio e copiare la versione applicata in HGS. Per un elenco completo delle opzioni di configurazione dei criteri di integrità del codice, consultare la documentazione di Device Guard.

# Capture a new CI policy with the FilePublisher primary level and Hash fallback and enable user mode code integrity protections
New-CIPolicy -FilePath 'C:\temp\ws2016-hardware01-ci.xml' -Level FilePublisher -Fallback Hash -UserPEs

# Apply the CI policy to the system
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\ws2016-hardware01-ci.xml' -BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b' 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer

# Check the event log for any untrusted binaries and update the policy if necessary
# Consult the Device Guard documentation for more details

# Change the policy to be in enforced mode
Set-RuleOption -FilePath 'C:\temp\ws2016-hardare01-ci.xml' -Option 3 -Delete

# Apply the enforced CI policy on the system
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\ws2016-hardware01-ci.xml' -BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b' 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer

Una volta creato, testato e applicato il criterio, copiare il file binario (.p7b) sul server HGS e registrare il criterio.

Add-HgsAttestationCiPolicy -Name 'WS2016-Hardware01' -Path 'C:\temp\ws2016-hardware01-ci.p7b'

Aggiunta di una chiave di crittografia del dump della memoria

Quando il criterio Hgs_NoDumps è disabilitato e il criterio Hgs_DumpEncryption è abilitato, agli host sorvegliati è consentito attivare i dump di memoria (compresi i crash dump), purché tali dump siano crittografati. Gli host sorvegliati superreranno l'attestazione solo se hanno disabilitato i dump di memoria o li stanno crittografando con una chiave nota a HGS. Per impostazione predefinita, non sono configurate chiavi di crittografia dei dump su HGS.

Per aggiungere una chiave di crittografia del dump a HGS, usare il comando Add-HgsAttestationDumpPolicy per fornire a HGS l'hash della chiave di crittografia del dump. Se si acquisisce una baseline TPM su un host Hyper-V configurato con la crittografia dei dump, l'hash viene incluso nel tcglog e può essere fornito al cmdlet Add-HgsAttestationDumpPolicy.

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey01' -Path 'C:\temp\TpmBaselineWithDumpEncryptionKey.tcglog'

In alternativa, è possibile fornire direttamente la rappresentazione in stringa dell'hash al cmdlet.

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey02' -PublicKeyHash '<paste your hash here>'

Assicurarsi di aggiungere ogni chiave di crittografia di dump univoca a HGS se si sceglie di usare chiavi diverse per l'infrastruttura sorvegliata. Gli host che crittografano i dump di memoria con una chiave sconosciuta a HGS non supereranno l'attestazione.

Per ulteriori informazioni sulla configurazione della crittografia dei dump sugli host, consultare la documentazione di Hyper-V.

Verificare se il sistema ha superato l'attestazione

Dopo aver registrato le informazioni necessarie presso HGS, è necessario verificare se l'host supera l'attestazione. Sull'host Hyper-V appena aggiunto, eseguire Set-HgsClientConfiguration e fornire gli URL corretti per il cluster HGS. Questi URL possono essere ottenuti eseguendo Get-HgsServer su qualsiasi nodo HGS.

Set-HgsClientConfiguration -KeyProtectionServerUrl 'https://hgs.bastion.local/KeyProtection' -AttestationServerUrl 'https://hgs.bastion.local/Attestation'

Se lo stato risultante non indica "IsHostGuarded : True", è necessario risolvere il problema di configurazione. Sull'host che non ha eseguito correttamente l'attestazione, eseguire il seguente comando per ottenere un report dettagliato sui problemi che possono contribuire a risolvere l'attestazione non eseguita correttamente.

Get-HgsTrace -RunDiagnostics -Detailed

Importante

Se si utilizza Windows Server 2019 o Windows 10, versione 1809 e si utilizzano i criteri di integrità del codice, è possibile che Get-HgsTrace restituisca un errore per la diagnostica attiva dei Criteri di integrità del codice. Si può tranquillamente ignorare questo risultato quando è la sola diagnostica errata.

Esaminare i criteri di attestazione

Per esaminare lo stato attuale dei criteri configurati su HGS, eseguire i seguenti comandi su qualsiasi nodo HGS:

# List all trusted security groups for admin-trusted attestation
Get-HgsAttestationHostGroup

# List all policies configured for TPM-trusted attestation
Get-HgsAttestationPolicy

Se si trova un criterio abilitato che non soddisfa più i requisiti di sicurezza (ad esempio un vecchio criterio di integrità del codice che ora è considerato non sicuro), è possibile disabilitarlo sostituendo il nome del criterio nel comando seguente:

Disable-HgsAttestationPolicy -Name 'PolicyName'

Allo stesso modo, si può usare Enable-HgsAttestationPolicy per riabilitare un criterio.

Se non si ha più bisogno di un criterio e si desidera rimuoverlo da tutti i nodi HGS, eseguire Remove-HgsAttestationPolicy -Name 'PolicyName' per eliminare definitivamente il criterio.

Modifica delle modalità di attestazione

Se si è iniziata l'infrastruttura sorvegliata utilizzando l'attestazione ritenuta attendibile dall'amministratore, è probabile che si voglia passare alla modalità di attestazione TPM, molto più attendibile, non appena si dispone di un numero sufficiente di host compatibili con TPM 2.0 nell'ambiente personale. Quando si è pronti per il passaggio, è possibile precaricare tutti gli elementi di attestazione (criteri CI, baseline TPM e identificatori TPM) in HGS, continuando a eseguire HGS con l'attestazione ritenuta attendibile dall'amministratore. A tal fine, è sufficiente seguire le istruzioni riportate nella sezione Autorizzazione di un nuovo host sorvegliato.

Una volta aggiunti tutti i criteri a HGS, il passaggio successivo consiste nell'eseguire un tentativo di attestazione sintetica sugli host per verificare se superano l'attestazione in modalità TPM. Ciò non influisce sull'attuale stato operativo di HGS. I comandi seguenti devono essere eseguiti su una macchina che abbia accesso a tutti gli host dell'ambiente personale e ad almeno un nodo HGS. Se il firewall o altri criteri di sicurezza lo impediscono, è possibile saltare questo passaggio. Se possibile, si consiglia di eseguire l'attestazione sintetica per avere una buona indicazione se il passaggio alla modalità TPM comporterà tempi di inattività per le macchine virtuali.

# Get information for each host in your environment
$hostNames = 'host01.contoso.com', 'host02.contoso.com', 'host03.contoso.com'
$credential = Get-Credential -Message 'Enter a credential with admin privileges on each host'
$targets = @()
$hostNames | ForEach-Object { $targets += New-HgsTraceTarget -Credential $credential -Role GuardedHost -HostName $_ }

$hgsCredential = Get-Credential -Message 'Enter an admin credential for HGS'
$targets += New-HgsTraceTarget -Credential $hgsCredential -Role HostGuardianService -HostName 'HGS01.bastion.local'

# Initiate the synthetic attestation attempt
Get-HgsTrace -RunDiagnostics -Target $targets -Diagnostic GuardedFabricTpmMode

Al termine della diagnostica, esaminare le informazioni fornite per determinare se qualche host non ha superato l'attestazione in modalità TPM. Eseguire nuovamente la diagnostica fino a ottenere un "superato" da ogni host, quindi procedere a passare HGS in modalità TPM.

Il passaggio alla modalità TPM richiede solo un attimo per essere completato. Eseguire il seguente comando su qualsiasi nodo HGS per aggiornare la modalità di attestazione.

Set-HgsServer -TrustTpm

Se si verificano problemi e si deve tornare alla modalità Active Directory, è possibile farlo eseguendo Set-HgsServer -TrustActiveDirectory.

Una volta confermato che tutto funziona come previsto, è necessario rimuovere tutti i gruppi di host Active Directory attendibili da HGS e rimuovere l’attendibilità tra i domini HGS e l’infrastruttura. Se si lascia l’attendibilità di Active Directory, si rischia che qualcuno riattivi l’attendibilità e commuti HGS in modalità Active Directory, che potrebbe permettere l'esecuzione di codice non attendibile sugli host sorvegliati.

Gestione delle chiavi

La soluzione di infrastruttura sorvegliata utilizza diverse coppie di chiavi pubbliche/private per convalidare l'integrità dei vari componenti della soluzione e crittografare i segreti dei tenant. Il servizio Sorveglianza host è configurato con almeno due certificati (con chiavi pubbliche e private), che vengono utilizzati per firmare e crittografare le chiavi utilizzate per avviare le macchine virtuali schermate. Queste chiavi devono essere gestite con attenzione. Se la chiave privata viene acquisita da un antagonista, questi sarà in grado di annullare la schermatura di tutte le macchine virtuali in esecuzione sull'infrastruttura o di creare un cluster HGS impostore che utilizza criteri di attestazione più deboli per aggirare le protezioni predisposte. Nel caso in cui si perdano le chiavi private durante un’emergenza e non si riesca a trovarle in un backup, sarà necessario impostare una nuova coppia di chiavi e far riconnettere ogni macchina virtuale per autorizzare i nuovi certificati.

Questa sezione tratta argomenti generali sulla gestione delle chiavi per permettere di configurarle in modo che siano funzionali e sicure.

Aggiunta di nuove chiavi

Sebbene HGS debba essere inizializzato con un solo set di chiavi, è possibile aggiungere più di una chiave di crittografia e di firma a HGS. I due motivi più comuni per cui si aggiungono nuove chiavi a HGS sono:

1. Per supportare gli scenari "usa la chiave che preferisci", in cui i tenant copiano le loro chiavi private nel modulo security hardware e autorizzano le loro chiavi solo per avviare le loro macchine virtuali schermate.
2. Sostituire le chiavi esistenti per HGS aggiungendo prima le nuove chiavi e conservando entrambi i set di chiavi fino a quando la configurazione di ogni VM non è stata aggiornata per utilizzare le nuove chiavi.

Il processo di aggiunta delle nuove chiavi varia a seconda del tipo di certificato utilizzato.

Opzione 1: Aggiunta di un certificato memorizzato in un HSM

L'approccio consigliato per proteggere le chiavi HGS consiste nell'utilizzare certificati creati in un modulo security hardware (HSM). Gli HSM garantiscono che l'uso delle chiavi sia legato all'accesso fisico a un dispositivo sensibile alla sicurezza nel datacenter. Ogni HSM è diverso e ha un processo univoco per creare i certificati e registrarli con HGS. I passaggi che seguono hanno lo scopo di fornire una guida generica per l'utilizzo dei certificati supportati da HSM. Consultare la documentazione del proprio fornitore di HSM per conoscere i passaggi e le funzionalità corrette.

1. Installare il software HSM su ogni nodo HGS del cluster. A seconda che si disponga di un dispositivo HSM di rete o locale, potrebbe essere necessario configurare l’HSM per concedere alla macchina l'accesso al suo archivio chiavi.

2. Creare due certificati in HSM con chiavi RSA a 2048 bit per la crittografia e la firma

   1. Creare un certificato di crittografia con la proprietà di utilizzo della Crittografia dati in HSM
   2. Creare un certificato di firma con la proprietà di utilizzo della chiave di Firma digitale in HSM

3. Installare i certificati nell'archivio certificati locale di ciascun nodo HGS seguendo le indicazioni del fornitore dell'HSM.

4. Se l'HSM utilizza autorizzazioni granulari per concedere ad applicazioni o utenti specifici l’autorizzazione di usare la chiave privata, è necessario concedere al proprio account di servizio gestito dal gruppo HGS l'accesso al certificato. È possibile trovare il nome dell'account HGS gMSA eseguendo (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName

5. Aggiungere i certificati di firma e di crittografia a HGS sostituendo le identificazioni personali con quelle dei propri certificati nei seguenti comandi:

   Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"
   Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint "99887766554433221100FFEEDDCCBBAA"
   

Opzione 2: aggiunta di certificati software non esportabili

Se si dispone di un certificato supportato da software rilasciato dalla propria azienda o da un'autorità di certificazione pubblica che dispone di una chiave privata non esportabile, è necessario aggiungere il certificato a HGS utilizzando la sua identificazione personale.

1. Installare il certificato sulla macchina seguendo le istruzioni dell'autorità di certificazione.

2. Concedere all'account del servizio gestito dal gruppo HGS l'accesso in lettura alla chiave privata del certificato. È possibile trovare il nome dell'account HGS gMSA eseguendo (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName

3. Registrare il certificato con HGS utilizzando il seguente comando e sostituendo l'impronta del certificato (cambiare Crittografia in Firma per i certificati di firma):

   Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"
   

Importante

È necessario installare manualmente la chiave privata e concedere l'accesso in lettura all'account gMSA su ogni nodo HGS. HGS non è in grado di replicare automaticamente le chiavi private per qualsiasi certificato registrato con la propria identificazione personale.

Opzione 3: aggiunta di certificati memorizzati in file PFX

Se si dispone di un certificato supportato da un software con una chiave privata esportabile che può essere memorizzata nel formato file PFX e protetta con una password, HGS può gestire automaticamente i certificati in modo autonomo. I certificati aggiunti con i file PFX vengono replicati automaticamente su ogni nodo del cluster HGS e HGS protegge l'accesso alle chiavi private. Per aggiungere un nuovo certificato utilizzando un file PFX, eseguire i seguenti comandi su qualsiasi nodo HGS (cambiare Crittografia in Firma per firmare i certificati):

$certPassword = Read-Host -AsSecureString -Prompt "Provide the PFX file password"
Add-HgsKeyProtectionCertificate -CertificateType Encryption -CertificatePath "C:\temp\encryptionCert.pfx" -CertificatePassword $certPassword

Individuazione e modifica dei certificati primari Sebbene HGS possa supportare più certificati di firma e crittografia, utilizza una coppia di certificati "primari". Questi sono i certificati che verranno usati se qualcuno scarica i metadati del sorvegliante per quel cluster HGS. Per verificare quali certificati sono attualmente contrassegnati come certificati primari, eseguire il seguente comando:

Get-HgsKeyProtectionCertificate -IsPrimary $true

Per impostare un nuovo certificato primario di crittografia o di firma, trovare l'identificazione personale del certificato desiderato e contrassegnarlo come primario utilizzando i seguenti comandi:

Get-HgsKeyProtectionCertificate
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899" -IsPrimary
Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint "99887766554433221100FFEEDDCCBBAA" -IsPrimary

Rinnovo o sostituzione delle chiavi

Quando si creano i certificati utilizzati da HGS, ai certificati viene assegnata una data di scadenza in base ai criteri dell'autorità di certificazione e alle informazioni necessarie. Normalmente, in scenari in cui la validità del certificato è essenziale, come la sicurezza delle comunicazioni HTTP, i certificati devono essere rinnovati prima della loro scadenza per evitare un'interruzione del servizio o un preoccupante messaggio di errore. HGS non usa certificati in tal senso. HGS usa semplicemente i certificati come un modo conveniente per creare e memorizzare una coppia di chiavi asimmetriche. Un certificato di crittografia o di firma scaduto su HGS non indica un unto debole o una perdita di protezione per le macchine virtuali schermate. Inoltre, i controlli di revoca dei certificati non vengono eseguiti da HGS. L'eventuale revoca di un certificato di HGS o dell'autorità di rilascio non influisce sull'uso del certificato da parte di HGS.

L'unico caso in cui ci si deve preoccupare di un certificato HGS è se si ha motivo di credere che la sua chiave privata sia stata rubata. In tal caso, l'integrità delle macchine virtuali schermate è a rischio, perché il possesso della metà privata della coppia di chiavi di crittografia e di firma di HGS è sufficiente a rimuovere le protezioni di protezione di una macchina virtuale o a creare un falso server HGS con criteri di attestazione più deboli.

Se ci si trova in questa situazione o se gli standard di conformità impongono di aggiornare regolarmente le chiavi dei certificati, i passaggi seguenti illustrano il processo di modifica delle chiavi su un server HGS. Si noti che la seguente guida rappresenta un impegno significativo che comporterà un'interruzione del servizio per ogni macchina virtuale servita dal cluster HGS. È necessario pianificare adeguatamente la modifica delle chiavi HGS per ridurre al minimo le interruzioni del servizio e garantire la sicurezza delle macchine virtuali dei tenant.

Su un nodo HGS, eseguire le seguenti operazioni per registrare una nuova coppia di certificati di crittografia e di firma. Per informazioni dettagliate sui vari modi di aggiungere nuove chiavi a HGS, consultare la sezione sull'aggiunta di nuove chiavi.

1. Creare una nuova coppia di certificati di crittografia e firma per il server HGS. Idealmente, questi saranno creati in un modulo security hardware.

2. Registrare i nuovi certificati di crittografia e di firma con Add-HgsKeyProtectionCertificate

   Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint>
   Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>
   

3. Se si utilizza l’identificazione personale, è necessario andare su ogni nodo del cluster per installare la chiave privata e concedere a HGS gMSA l'accesso alla chiave.

4. Rendere i nuovi certificati i certificati predefiniti in HGS

   Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> -IsPrimary
   Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsPrimary
   

A questo punto, i dati di schermatura creati con i metadati ottenuti dal nodo HGS useranno i nuovi certificati, ma le macchine virtuali esistenti continueranno a funzionare perché i vecchi certificati sono ancora presenti.

Per garantire che tutte le macchine virtuali esistenti funzionino con le nuove chiavi, è necessario aggiornare la protezione con chiave su ogni macchina virtuale.

Si tratta di un'azione che richiede il coinvolgimento del proprietario della macchina virtuale (persona o persona giuridica in possesso del sorvegliante "proprietario"). Per ogni macchina virtuale schermata, eseguire le seguenti operazioni:

1. Arrestare la VM. La macchina virtuale non può essere riavviata finché non sono stati completati gli altri passaggi, altrimenti si dovrà ricominciare il processo da capo.

2. Salvare la protezione con chiave corrente in un file: Get-VMKeyProtector -VMName 'VM001' | Out-File '.\VM001.kp'

3. Trasferire la protezione con chiave al proprietario della macchina virtuale

4. Chiedere al proprietario di scaricare le informazioni aggiornate sul sorvegliante da HGS e di importarle nel proprio sistema locale.

5. Leggere la protezione con chiave corrente in memoria, concedere al nuovo sorvegliante l'accesso alla protezione con chiave e salvarlo in un nuovo file eseguendo i seguenti comandi:

   $kpraw = Get-Content -Path .\VM001.kp
   $kp = ConvertTo-HgsKeyProtector -Bytes $kpraw
   $newGuardian = Get-HgsGuardian -Name 'UpdatedHgsGuardian'
   $updatedKP = Grant-HgsKeyProtectorAccess -KeyProtector $kp -Guardian $newGuardian
   $updatedKP.RawData | Out-File .\updatedVM001.kp
   

6. Copiare la protezione con chiave aggiornata nell'infrastruttura di hosting.

7. Applicare la protezione con chiave alla macchina virtuale originale:

   $updatedKP = Get-Content -Path .\updatedVM001.kp
   Set-VMKeyProtector -VMName VM001 -KeyProtector $updatedKP
   

8. Infine, avviare la macchina virtuale e assicurarsi che venga eseguita correttamente.

   Nota

   Se il proprietario della macchina virtuale imposta una protezione chiave errata sulla macchina virtuale e non autorizza l'infrastruttura a eseguire la macchina virtuale, non sarà possibile avviare la macchina virtuale schermata. Per tornare all'ultima protezione con chiave nota, eseguire Set-VMKeyProtector -RestoreLastKnownGoodKeyProtector

   Una volta che tutte le macchine virtuali sono state aggiornate per autorizzare le nuove chiavi sorveglianti, è possibile disattivare e rimuovere le vecchie chiavi.

9. Ottenere le identificazioni personali impronte dei vecchi certificati da Get-HgsKeyProtectionCertificate -IsPrimary $false

10. Disattivare ciascun certificato eseguendo i seguenti comandi:

    Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> -IsEnabled $false
    Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsEnabled $false
    

11. Dopo essersi assicurati che le macchine virtuali siano ancora in grado di avviarsi con i certificati disabilitati, rimuovere i certificati da HGS eseguendo i seguenti comandi:

    Remove-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint>`
    Remove-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>`
    

Importante

I backup delle macchine virtuali conterranno le informazioni della vecchia protezione con chiave che permettono di utilizzare i vecchi certificati per l'avvio della macchina virtuale. Se si è consapevoli che la propria chiave privata è stata compromessa, si deve presumere che anche i backup della macchina virtuale possano essere compromessi e prendere le misure del caso. Eliminando definitivamente la configurazione della macchina virtuale dai backup (.vmcx) si rimuove la protezione con chiave, a costo di dover utilizzare la password di ripristino BitLocker per avviare la macchina virtuale la volta successiva.

Replica delle chiavi tra i nodi

Ogni nodo del cluster HGS deve essere configurato con gli stessi certificati di crittografia, firma e (se configurati) SSL. Questo è necessario per garantire che gli host Hyper-V che si rivolgono a qualsiasi nodo del cluster possano ricevere correttamente le loro richieste.

Se il server HGS è stato inizializzato con certificati basati su PFX, HGS replicherà automaticamente sia la chiave pubblica che quella privata di tali certificati su ogni nodo del cluster. È sufficiente aggiungere le chiavi su un solo nodo.

Se si è inizializzato il server HGS con riferimenti al certificato o identificazione personale, HGS replicherà a ogni nodo solo la chiave pubblica del certificato. Inoltre, in questo scenario HGS non può concedere a se stesso l'accesso alla chiave privata su nessun nodo. Pertanto, è responsabilità dell'utente:

1. Installare la chiave privata su ogni nodo HGS
2. Concedere all'account del servizio gestito dal gruppo HGS (gMSA) l'accesso alla chiave privata su ogni nodo. Queste attività aggiungono un ulteriore onere operativo, ma sono necessarie per le chiavi supportate da HSM e i certificati con chiavi private non esportabili.

I certificati SSL non vengono mai replicati in nessuna forma. È responsabilità dell'utente inizializzare ogni server HGS con lo stesso certificato SSL e aggiornare ogni server ogni volta che si decide di rinnovare o sostituire il certificato SSL. Per sostituire il certificato SSL, si consiglia di utilizzare il cmdlet Set-HgsServer.

Annullamento della configurazione di HGS

Se è necessario disattivare o riconfigurare in modo significativo un server HGS, è possibile farlo utilizzando i cmdlet Clear-HgsServer o Uninstall-HgsServer.

Cancellazione della configurazione di HGS

Per rimuovere un nodo dal cluster HGS, utilizzare il cmdlet Clear-HgsServer. Questo cmdlet apporta le seguenti modifiche al server in cui viene eseguito:

• Annulla la registrazione dei servizi di attestazione e protezione delle chiavi
• Rimuove l'endpoint di gestione JEA "microsoft.windows.hgs"
• Rimuove il computer locale dal cluster di failover HGS

Se il server è l'ultimo nodo HGS del cluster, anche il cluster e la risorsa del nome di rete corrispondente verranno eliminati definitivamente.

# Removes the local computer from the HGS cluster
Clear-HgsServer

Al termine dell'operazione di eliminazione, il server HGS può essere reinizializzato con Initialize-HgsServer. Se si è utilizzato Install-HgsServer per impostare un dominio Active Directory Domain Services, tale dominio rimarrà configurato e operativo dopo l'operazione di eliminazione.

Disinstallazione di HGS

Se si desidera rimuovere un nodo dal cluster HGS e abbassare di livello il controller di dominio Active Directory in esecuzione su di esso, utilizzare il cmdlet Uninstall-HgsServer. Questo cmdlet apporta le seguenti modifiche al server in cui viene eseguito:

• Annulla la registrazione dei servizi di attestazione e protezione delle chiavi
• Rimuove l'endpoint di gestione JEA "microsoft.windows.hgs"
• Rimuove il computer locale dal cluster di failover HGS
• Abbassa di livello il controller di dominio di Active Directory, se configurato

Se il server è l'ultimo nodo HGS del cluster, verranno eliminati definitivamente anche il dominio, il cluster di failover e la risorsa Distributed Network Name del cluster.

# Removes the local computer from the HGS cluster and demotes the ADDC (restart required)
$newLocalAdminPassword = Read-Host -AsSecureString -Prompt "Enter a new password for the local administrator account"
Uninstall-HgsServer -LocalAdministratorPassword $newLocalAdminPassword -Restart

Una volta completata l'operazione di disinstallazione e riavviato il computer, è possibile reinstallare ADDC e HGS utilizzando Install-HgsServer o aggiungere il computer a un dominio e inizializzare il server HGS in tale dominio con Initialize-HgsServer.

Se non si intende più utilizzare il computer come nodo HGS, è possibile rimuovere il ruolo da Windows.

Uninstall-WindowsFeature HostGuardianServiceRole