Guida alla pianificazione di un'infrastruttura sorvegliata e macchine virtuali schermate per i provider di servizi di hosting

Questo argomento illustra le decisioni di pianificazione che dovranno essere prese per consentire l'esecuzione delle macchine virtuali schermate nell'infrastruttura. Indipendentemente dal fatto che si aggiorni un'infrastruttura Hyper-V esistente o si crei una nuova infrastruttura, l'esecuzione di macchine virtuali schermate è costituita da due componenti principali:

  • Il servizio Sorveglianza host (HGS) fornisce l'attestazione e la protezione della chiave, in modo che sia possibile assicurarsi che le macchine virtuali schermate vengano eseguite solo in host Hyper-V approvati e integri. 
  • Gli host Hyper-V approvati e integri in cui le macchine virtuali schermate (e le normali macchine virtuali) possono essere eseguite. Sono definiti host sorvegliati.

Diagramma che mostra l'attestazione e i servizi di protezione delle chiavi di H G S sono collegati agli host Hyper V sorvegliati della macchina virtuale schermata.

Decisione n. 1: Livello di attendibilità nell'infrastruttura

Il modo in cui si implementano il servizio Sorveglianza host e gli host Hyper-V sorvegliati dipenderà principalmente dal livello di attendibilità che si sta cercando di ottenere nell'infrastruttura. Il livello di attendibilità è regolato dalla modalità di attestazione. Sono presenti due opzioni che si escludono a vicenda:

  1. Attestazione TPM attendibile

    Se l'obiettivo è proteggere le macchine virtuali da amministratori dannosi o da un'infrastruttura compromessa, si userà l'attestazione TPM attendibile. Questa opzione è ideale per gli scenari di hosting multi-tenant e per asset di valore elevato negli ambienti aziendali, ad esempio controller di dominio o server di contenuto come SQL o SharePoint. I criteri di integrità del codice protetto da Hypervisor (HVCI) vengono misurati e la rispettiva validità viene imposta dal servizio Sorveglianza host prima che l'host sia autorizzato a eseguire macchine virtuali schermate.

  2. Attestazione della chiave host

    Se i requisiti sono principalmente basati sulla conformità che richiede la crittografia delle macchine virtuali sia inattive che in esecuzione, si userà l'attestazione della chiave host. Questa opzione è ideale per i data center per utilizzo generico in cui il fatto che gli amministratori dell'infrastruttura e dell'host Hyper-V abbiano accesso ai sistemi operativi guest delle macchine virtuali per la manutenzione e le operazioni quotidiane non costituisce un problema.

    In questa modalità l'amministratore dell'infrastruttura è responsabile esclusivamente dell'integrità degli host Hyper-V. Poiché il servizio Sorveglianza host non ha alcun ruolo nel decidere cosa è o non è consentito eseguire, malware e debugger funzioneranno come progettato.

    I debugger che provano a connettersi direttamente a un processo, ad esempio WinDbg.exe, vengono tuttavia bloccati per le macchine virtuali schermate perché il processo di lavoro della macchina virtuale (VMWP.exe) è di tipo PPL (Protected Process Light). Le tecniche di debug alternative, ad esempio quelle usate da LiveKd.exe, non vengono bloccate. A differenza delle macchine virtuali schermate, il processo di lavoro per le macchine virtuali supportate dalla crittografia non viene eseguito come PPL, quindi i debugger tradizionali come WinDbg.exe continueranno a funzionare normalmente.

    Una modalità di attestazione simile denominata Attestazione ritenuta attendibile dall'amministratore, basata su Active Directory, è stata deprecata a partire da Windows Server 2019.

Il livello di attendibilità scelto determinerà i requisiti hardware per gli host Hyper-V e i criteri applicati nell'infrastruttura. Se necessario, è possibile distribuire l'infrastruttura sorvegliata usando l'hardware esistente e l'attestazione ritenuta attendibile dall'amministratore e quindi convertirla in attestazione TPM attendibile quando l'hardware è stato aggiornato ed è necessario rafforzare la sicurezza dell'infrastruttura.

Decisione n. 2: Scelta tra infrastruttura Hyper-V esistente e una nuova infrastruttura Hyper-V separata

Se è disponibile un'infrastruttura esistente (Hyper-V o di altro tipo), è molto probabile che sia possibile usarla per eseguire macchine virtuali schermate insieme alle normali macchine virtuali. Alcuni clienti scelgono di integrare macchine virtuali schermate negli strumenti e nelle infrastrutture esistenti, mentre altri separano l'infrastruttura per motivi aziendali.

Pianificazione dell'amministratore del servizio Sorveglianza host per il servizio Sorveglianza host

Distribuire il servizio Sorveglianza host (HGS) in un ambiente altamente sicuro, indipendentemente dal fatto che si tratti di un server fisico dedicato, una macchina virtuale schermata, una macchina virtuale in un host Hyper-V isolato (separato dall'infrastruttura che protegge) o un host separato logicamente usando una sottoscrizione di Azure diversa.

Area Dettagli
Requisiti di installazione
  • Un server (cluster a tre nodi consigliato per la disponibilità elevata)
  • Per il fallback sono necessari almeno due server del servizio Sorveglianza host
  • I server possono essere virtuali o fisici (server fisico con TPM 2.0 consigliato, ma è supportato anche TPM 1.2)
  • Installazione di Server Core di Windows Server 2016
  • Collegamento diretto tra rete e infrastruttura che consente HTTP o la configurazione del fallback
  • Certificato HTTPS consigliato per la convalida dell'accesso
Dimensionamento Ogni nodo server del servizio Sorveglianza host di dimensioni medie (8 core/4 GB) può gestire 1.000 host Hyper-V.
Gestione Designare persone specifiche che gestiranno il servizio Sorveglianza host. Devono essere separati dagli amministratori dell'infrastruttura. Per un confronto, i cluster del servizio Sorveglianza host possono essere considerati allo stesso modo di un'autorità di certificazione (CA) in termini di isolamento amministrativo, distribuzione fisica e livello complessivo di riservatezza della sicurezza.
Active Directory per il servizio Sorveglianza host Per impostazione predefinita, il servizio Sorveglianza host installa la propria istanza interna di Active Directory per la gestione. Si tratta di una foresta autonoma e autogestita e questa è la configurazione consigliata per isolare il servizio Sorveglianza host dall'infrastruttura.

Se si ha già una foresta Active Directory con privilegi elevati usata per l'isolamento, è possibile usare tale foresta anziché la foresta predefinita del servizio Sorveglianza host. È importante che il servizio Sorveglianza host non sia aggiunto a un dominio nella stessa foresta degli host Hyper-V o degli strumenti di gestione dell'infrastruttura. Questo approccio potrebbe consentire a un amministratore dell'infrastruttura di ottenere il controllo sul servizio Sorveglianza host.
Ripristino di emergenza Sono disponibili tre opzioni:
  1. Installare un cluster del servizio Sorveglianza host separato in ogni data center e autorizzare l'esecuzione di macchine virtuali schermate sia nei data center primari che nei data center di backup. In questo modo si evita la necessità di estendere il cluster attraverso una rete WAN ed è possibile isolare le macchine virtuali in modo che vengano eseguite solo nel sito designato.
  2. Installare il servizio Sorveglianza host in un cluster esteso tra due o più data center. Ciò garantisce resilienza in caso di inattività della rete WAN, ma si avvicina ai limiti del clustering di failover. Non è possibile isolare i carichi di lavoro in un sito. Una macchina virtuale autorizzata a essere eseguita in un sito può essere eseguita in qualsiasi altro sito.
  3. Registrare l'host Hyper-V in un'altra istanza del servizio Sorveglianza host come failover.
È anche consigliabile eseguire il backup di ogni servizio Sorveglianza host esportandone la configurazione in modo che sia sempre possibile eseguire il ripristino in locale. Per altre informazioni, vedere Export-HgsServerState e Import-HgsServerState.
Chiavi del servizio Sorveglianza host Un servizio Sorveglianza host usa due coppie di chiavi asimmetriche, ovvero una chiave di crittografia e una chiave di firma, ognuna delle quali è rappresentata da un certificato SSL. Sono disponibili due opzioni per generare queste chiavi:
  1. Autorità di certificazione interna: è possibile generare queste chiavi usando l'infrastruttura PKI interna. Questa opzione è adatta per un ambiente data center.
  2. Autorità di certificazione attendibili pubblicamente: usare un set di chiavi ottenute da un'autorità di certificazione attendibile pubblicamente. Questa è l'opzione che gli host devono usare.
Si noti che, sebbene sia possibile usare certificati autofirmati, questo approccio non è consigliabile per scenari di distribuzione diversi dai lab di verifica.

Oltre ad avere chiavi del servizio Sorveglianza host, un host può usare l'approccio BYOK ("Bring Your Own Key"), in cui i tenant possono fornire le proprie chiavi in modo che alcuni tenant (o tutti) possano avere la propria chiave specifica del servizio Sorveglianza host. Questa opzione è adatta per gli host che possono fornire un processo fuori banda per i tenant per caricare le chiavi.
Archiviazione delle chiavi del servizio Sorveglianza host Per ottenere la sicurezza massima possibile, è consigliabile creare e archiviare le chiavi del servizio Sorveglianza host esclusivamente in un modulo di protezione hardware. Se non si usano moduli di protezione hardware, è consigliabile applicare BitLocker nei server del servizio Sorveglianza host.

Pianificazione dell'amministratore dell'infrastruttura per gli host sorvegliati

Area Dettagli
Hardware
Sistema operativo È consigliabile usare l'opzione Server Core per il sistema operativo host Hyper-V.
Implicazioni per le prestazioni In base ai test delle prestazioni, si prevede una differenza di densità approssimativa del 5% tra l'esecuzione di macchine virtuali schermate e macchine virtuali non schermate. Ciò significa che se un determinato host Hyper-V può eseguire 20 macchine virtuali non schermate, si prevede che possa eseguire 19 macchine virtuali schermate.

Assicurarsi di verificare le dimensioni con i carichi di lavoro tipici. Potrebbero ad esempio essere presenti outlier con carichi di lavoro di I/O orientati alla scrittura intensivi che influiranno ulteriormente sulla differenza di densità.
Considerazioni sulle succursali A partire da Windows Server versione 1709, è possibile specificare un URL di fallback per un server del servizio Sorveglianza host virtualizzato in esecuzione localmente come macchina virtuale schermata nella succursale. L'URL di fallback può essere usato quando la succursale perde la connettività ai server del servizio Sorveglianza host nel data center. Nelle versioni precedenti di Windows Server un host Hyper-V in esecuzione in una succursale richiede la connettività al servizio Sorveglianza host per l'accensione o per eseguire la migrazione in tempo reale di macchine virtuali schermate. Per altre informazioni, vedere Considerazioni sulle succursali.