Autorizzare gli host sorvegliati con l'attestazione basata su TPM

• Si applica a:

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

La modalità TPM usa un identificatore TPM (detto anche identificatore della piattaforma o chiave di verifica dell'autenticità [EKpub]) per iniziare a determinare se un particolare host è autorizzato come "sorvegliato". Questa modalità di attestazione usa misure di avvio protetto e integrità del codice per garantire che un determinato host Hyper-V sia in uno stato integro ed esegua solo codice attendibile. Per consentire all'attestazione di comprendere cos'è e non è integro, è necessario acquisire gli artefatti seguenti:

1. Identificatore TPM (EKpub)

   • Queste informazioni sono univoche per ogni host Hyper-V

2. Baseline TPM (misurazioni di avvio)

   • Questo è applicabile a tutti gli host Hyper-V eseguiti nella stessa classe di hardware

3. Criteri di integrità del codice (elenco consentito di file binari consentiti)

   • Questo è applicabile a tutti gli host Hyper-V che condividono hardware e software comuni

È consigliabile acquisire i criteri di base e CI da un "host di riferimento" rappresentativo di ogni classe univoca della configurazione hardware Hyper-V all'interno del data center. A partire da Windows Server versione 1709, i criteri di integrazione continua di esempio sono inclusi in C:\Windows\schemas\CodeIntegrity\ExamplePolicies.

Criteri di attestazione con versione

Windows Server 2019 introduce un nuovo metodo per l'attestazione, denominato attestazione v2, in cui deve essere presente un certificato TPM per aggiungere EKPub a HGS. Il metodo di attestazione v1 usato in Windows Server 2016 consente di eseguire l'override di questo controllo di sicurezza specificando il flag -Force quando si esegue Add-HgsAttestationTpmHost o altri cmdlet di attestazione TPM per acquisire gli artefatti. A partire da Windows Server 2019, l'attestazione v2 viene usata per impostazione predefinita ed è necessario specificare il flag -PolicyVersion v1 quando si esegue Add-HgsAttestationTpmHost se è necessario registrare un TPM senza un certificato. Il flag -Force non funziona con l'attestazione v2.

Un host può attestare solo se tutti gli artefatti (baseline EKPub + TPM e criteri CI) usano la stessa versione dell'attestazione. L'attestazione V2 viene tentata per prima e, in caso di errore, viene usata l'attestazione v1. Ciò significa che se è necessario registrare un identificatore TPM usando l'attestazione v1, è necessario specificare anche il flag -PolicyVersion v1 per usare l'attestazione v1 quando si acquisisce la baseline TPM e si creano i criteri di integrazione continua. Se la baseline TPM e i criteri CI sono stati creati usando l'attestazione v2 e successivamente è necessario aggiungere un host sorvegliato senza un certificato TPM, è necessario ricreare ogni artefatto con il flag -PolicyVersion v1.

Acquisire l'identificatore TPM (identificatore della piattaforma o EKpub) per ogni host

1. Nel dominio di infrastruttura, assicurarsi che il TPM in ogni host sia pronto per l'uso, ovvero il TPM viene inizializzato e la proprietà viene ottenuta. È possibile controllare lo stato del TPM aprendo la Console di gestione TPM (tpm.msc) o eseguendo Get-Tpm in una finestra di Windows PowerShell con privilegi elevati. Se il TPM non si trova nello stato Pronto, sarà necessario inizializzarlo e impostarne la proprietà. Questa operazione può essere eseguita nella Console di gestione di TPM o eseguendo Initialize-Tpm.

2. In ogni host sorvegliato, eseguire il comando seguente in una console di Windows PowerShell con privilegi elevati per ottenere il relativo EKpub. Per <HostName>, sostituire il nome host univoco con un elemento appropriato per identificare questo host, ovvero il nome host o il nome usato da un servizio di inventario dell'infrastruttura, se disponibile. Per praticità, denominare il file di output usando il nome dell'host.

   (Get-PlatformIdentifier -Name '<HostName>').InnerXml | Out-file <Path><HostName>.xml -Encoding UTF8
   

3. Ripetere i passaggi precedenti per ogni host che diventerà un host sorvegliato, assicurandosi di assegnare a ogni file XML un nome univoco.

4. Fornire i file XML risultanti all'amministratore HGS.

5. Nel dominio HGS aprire una console di Windows PowerShell con privilegi elevati in un server HGS ed eseguire il comando seguente. Ripetere il comando per ognuno dei file XML.

   Add-HgsAttestationTpmHost -Path <Path><Filename>.xml -Name <HostName>
   

   Nota

   Se si verifica un errore durante l'aggiunta di un identificatore TPM relativo a un certificato a chiave di verifica dell'autenticità (EKCert) non attendibile, assicurarsi che i certificati radice TPM attendibili siano stati aggiunti al nodo HGS. Inoltre, alcuni fornitori di TPM non usano EKCerts. È possibile verificare se un EKCert è mancante aprendo il file XML in un editor, ad esempio Blocco note e verificando la presenza di un messaggio di errore che indica che non è stato trovato alcun EKCert. Se questo è il caso e si ritiene che il TPM nel computer sia autentico, è possibile usare il parametro -Force per aggiungere l'identificatore host a HGS. In Windows Server 2019 è necessario usare anche il parametro -PolicyVersion v1 quando si usa -Force. In questo modo viene creato un criterio coerente con il comportamento di Windows Server 2016 e sarà necessario usare -PolicyVersion v1 anche quando si registrano i criteri di integrazione continua e la baseline TPM.

Creare e applicare criteri di integrità del codice

Un criterio di integrità del codice consente di garantire che possano essere eseguiti solo gli eseguibili attendibili. L'esecuzione di malware e altri file eseguibili all'esterno dei file eseguibili attendibili non viene consentita.

Ogni host sorvegliato deve avere un criterio di integrità del codice applicato per eseguire macchine virtuali schermate in modalità TPM. È possibile specificare i criteri di integrità del codice esatti attendibili aggiungendoli a HGS. I criteri di integrità del codice possono essere configurati per applicare i criteri, bloccare qualsiasi software che non sia conforme ai criteri o semplicemente controllare (registrare un evento quando viene eseguito un software non definito nei criteri).

A partire da Windows Server versione 1709, i criteri di integrità del codice di esempio sono inclusi in Windows in C:\Windows\schemas\CodeIntegrity\ExamplePolicies. Per Windows Server sono consigliati due criteri:

• AllowMicrosoft: permette tutti i file firmati da Microsoft. Questo criterio è consigliato per applicazioni server come SQL o Exchange o se il server viene monitorato dagli agenti pubblicati da Microsoft.
• DefaultWindows_Enforced: consente solo i file forniti in Windows e non consente altre applicazioni rilasciate da Microsoft, ad esempio Office. Questo criterio è consigliato per i server che eseguono solo ruoli server predefiniti e funzionalità, ad esempio Hyper-V.

È consigliabile creare prima di tutto i criteri di integrazione continua in modalità di controllo (registrazione) per verificare se manca qualcosa, quindi applicare i criteri per i carichi di lavoro di produzione host.

Se si usa il cmdlet New-CIPolicy per generare criteri di integrità del codice personalizzati, sarà necessario decidere i livelli di regole da usare. È consigliabile un livello primario di Publisher con fallback su Hash, che consente l'aggiornamento della maggior parte del software con firma digitale senza modificare i criteri di integrazione continua. È anche possibile installare un nuovo software scritto dallo stesso editore nel server senza modificare i criteri di integrazione continua. Verrà eseguito l'hashing degli eseguibili non firmati digitalmente. Gli aggiornamenti a questi file richiederanno la creazione di un nuovo criterio di integrazione continua. Per altre informazioni sui livelli delle regole dei criteri di integrazione continua disponibili, vedere Distribuire i criteri di integrità del codice: regole dei criteri e regole dei file e guida ai cmdlet.

1. Nell'host di riferimento, generare un nuovo criterio di integrità del codice. I comandi seguenti creano un criterio a livello di editore con fallback in Hash. Converte quindi il file XML nel formato di file binario Windows e il servizio Sorveglianza host deve applicare e misurare rispettivamente i criteri di integrazione continua.

   New-CIPolicy -Level Publisher -Fallback Hash -FilePath 'C:\temp\HW1CodeIntegrity.xml' -UserPEs
   
   ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\HW1CodeIntegrity.xml' -BinaryFilePath 'C:\temp\HW1CodeIntegrity.p7b'
   

   Nota

   Il comando precedente crea un criterio di integrazione continua solo in modalità di controllo. Non bloccherà l'esecuzione di file binari non autorizzati nell'host. È consigliabile usare solo i criteri applicati nell'ambiente di produzione.

2. Mantenere il file dei criteri di integrità del codice (file XML) in cui è possibile trovarlo facilmente. Sarà necessario modificare questo file in un secondo momento per applicare i criteri di integrazione continua o unire le modifiche dagli aggiornamenti futuri apportati al sistema.

3. Applicare i criteri di integrazione continua all'host di riferimento:

   1. Eseguire il comando seguente per configurare il computer in modo da usare i criteri di integrazione continua. È anche possibile distribuire i criteri di integrazione continua con Criteri di gruppo o System Center Virtual Machine Manager.

      Invoke-CimMethod -Namespace root/Microsoft/Windows/CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{ FilePath = "C:\temp\HW1CodeIntegrity.p7b" }
      

   2. Riavviare l'host per applicare i criteri.

4. Testare i criteri di integrità del codice eseguendo un carico di lavoro tipico. Ciò può includere l'esecuzione di macchine virtuali, qualsiasi agente di gestione dell'infrastruttura, agenti di backup o strumenti di risoluzione dei problemi nel computer. Controllare se sono presenti violazioni dell'integrità del codice e aggiornare i criteri di integrazione continua, se necessario.

5. Modificare i criteri di integrazione continua in modalità applicata eseguendo i comandi seguenti sul file XML dei criteri di integrazione continua aggiornato.

   Set-RuleOption -FilePath 'C:\temp\HW1CodeIntegrity.xml' -Option 3 -Delete
   
   ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\HW1CodeIntegrity.xml' -BinaryFilePath 'C:\temp\HW1CodeIntegrity_enforced.p7b'
   

6. Applicare i criteri di integrazione continua a tutti gli host (con configurazione hardware e software identici) usando i comandi seguenti:

   Invoke-CimMethod -Namespace root/Microsoft/Windows/CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{ FilePath = "C:\temp\HW1CodeIntegrity.p7b" }
   
   Restart-Computer
   

   Nota

   Prestare attenzione quando si applicano criteri di integrazione continua agli host e quando si aggiorna un software in questi computer. Qualsiasi driver in modalità kernel non conforme ai criteri di integrazione continua potrebbe impedire l'avvio del computer.

7. Specificare il file binario (in questo esempio HW1CodeIntegrity_enforced.p7b) all'amministratore del servizio Sorveglianza host.

8. Nel dominio HGS copiare i criteri di integrità del codice in un server HGS ed eseguire il comando seguente.

   Per <PolicyName>, specificare un nome per i criteri di integrazione continua che descrive il tipo di host a cui si applica. Una procedura consigliata consiste nel denominarlo come il marchio/modello del computer e qualsiasi configurazione software speciale in esecuzione su di esso. Per <Path>, specificare il percorso e il nome file dei criteri di integrità del codice.

   Add-HgsAttestationCIPolicy -Path <Path> -Name '<PolicyName>'
   

   Nota

   Se si usa un criterio di integrità del codice firmato, registrare una copia non firmata dello stesso criterio con HGS. La firma sui criteri di integrità del codice viene usata per controllare gli aggiornamenti dei criteri, ma non viene misurata nel TPM dell'host e pertanto non può essere attestata da HGS.

Acquisire la baseline TPM per ogni classe univoca di hardware

Una baseline TPM è necessaria per ogni classe univoca di hardware nell'infrastruttura del data center. Usare di nuovo un "host di riferimento".

1. Nell'host di riferimento verificare che siano installati il ruolo Hyper-V e la funzionalità Supporto per Sorveglianza host per Hyper-V.

   Avviso

   La funzionalità Supporto per Sorveglianza host per Hyper-V abilita la protezione basata sulla virtualizzazione dell'integrità del codice che potrebbe non essere compatibile con alcuni dispositivi. È consigliabile testare questa configurazione nel lab prima di abilitare la funzionalità. In caso contrario, potrebbero verificarsi errori imprevisti, incluse perdite di dati, o un errore di schermata blu (detto anche errore di arresto).

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

2. Per acquisire i criteri di base, eseguire il comando seguente in una console di Windows PowerShell con privilegi elevati.

   Get-HgsAttestationBaselinePolicy -Path 'HWConfig1.tcglog'
   

   Nota

   È necessario usare il flag x-SkipValidation se l'host di riferimento se l'avvio protetto non è abilitato, un IOMMU non è presente, la sicurezza basata su virtualizzazione non è abilitata e in esecuzione o se non sono stati applicati criteri di integrità del codice. Queste convalide sono progettate per tenere conto dei requisiti minimi di esecuzione di una macchina virtuale schermata nell'host. L'uso del flag -SkipValidation non modifica l'output del cmdlet; si limita a silenziare gli errori.

3. Fornire la baseline TPM (file TCGlog) all'amministratore HGS.

4. Nel dominio HGS copiare il file TCGlog in un server HGS ed eseguire il comando seguente. In genere, i criteri verranno denominati come la classe dell'hardware che rappresenta (ad esempio, "Revisione modello produttore").

   Add-HgsAttestationTpmPolicy -Path <Filename>.tcglog -Name '<PolicyName>'
   

Passaggio successivo

Confermare l'attestazione