Condividi tramite

Requisiti hardware di Microsoft Defender Credential Guard

  • Articolo

Microsoft Defender Credential Guard usa la sicurezza basata sulla virtualizzazione per isolare e proteggere i segreti (ad esempio, hash delle password NTLM e ticket di concessione ticket Kerberos) per bloccare gli attacchi pass-the-hash o pass-the-ticket (PtH). Quando Microsoft Defender Credential Guard è abilitato, NTLMv1, MS-CHAPv2, Digest e CredSSP non possono usare le credenziali di accesso. Di conseguenza, l'accesso Single Sign-On non funziona con questi protocolli. Tuttavia, le applicazioni possono richiedere le credenziali o usare le credenziali archiviate nell'insieme di credenziali di Windows che non sono protette da Microsoft Defender Credential Guard con uno di questi protocolli.

È consigliabile che le credenziali importanti, ad esempio le credenziali di accesso, non vengano usate con nessuno di questi protocolli. Se questi protocolli devono essere usati da utenti di dominio o Azure AD, è necessario effettuare il provisioning delle credenziali secondarie per questi casi d'uso.

Quando Microsoft Defender Credential Guard è abilitato, Kerberos non consente la delega Kerberos senza vincoli o la crittografia DES, non solo per le credenziali di accesso, ma anche le credenziali richieste o salvate.

Nota: a partire da Windows 10 versione 1709 e Windows Server versione 1709, quando Intel TXT o SGX sono abilitati in una piattaforma tramite BIOS, Hypervisor-Protected Code Integrity (HCVI) e Credential Guard non sono interessati e funzioneranno come previsto. HVCI e Credential Guard non sono supportati nelle versioni precedenti di Windows quando Intel TXT o SGX sono abilitati in una piattaforma tramite il BIOS.

Per una migliore comprensione delle funzionalità di Microsoft Defender Credential Guard e degli attacchi che protegge di nuovo, vedere Approfondimento su Credential Guard.

Professionisti IT: per informazioni su come distribuire Microsoft Defender Credential Guard nell'azienda, vedere Proteggere le credenziali di dominio derivate con Credential Guard.

Per consentire a un dispositivo di supportare Microsoft Defender Credential Guard, come specificato in Windows Hardware Compatibility Requirements (WHCR), l'OEM deve fornire le funzionalità hardware, software o firmware seguenti.

Requisito Dettagli
Avvio protetto L'avvio protetto basato su hardware deve essere supportato. Per altre informazioni, vedere Avvio protetto.
Configurazione e gestione dell'avvio protetto
  • È necessario essere in grado di aggiungere isv, OEM o certificato aziendale al database di avvio protetto in fase di produzione.
  • Microsoft UEFI CA deve essere rimossa dal database di avvio protetto. Il supporto per i moduli UEFI di terze parti è consentito, ma deve sfruttare i certificati forniti dall'ISV o il certificato OEM per il software UEFI specifico.
Processo di aggiornamento del firmware sicuro Come il software UEFI, il firmware UEFI può avere vulnerabilità di sicurezza. È essenziale avere la possibilità di applicare immediatamente patch a tali vulnerabilità quando vengono rilevate tramite gli aggiornamenti del firmware. Il firmware UEFI deve supportare l'aggiornamento sicuro del firmware seguendo la specifica di compatibilità hardware per i sistemi per Windows 10 in System.Fundamentals.Firmware.UEFISecureBoot.
Interfaccia UEFI (United Extensible Firmware Interface) Per altre informazioni, vedere Requisiti del firmware UEFI (United Extensible Firmware Interface).
Sicurezza basata su virtualizzazione (VBS) L'integrità del codice protetto da Hypervisor richiede la sicurezza basata su vbs. Per altre informazioni sulla sicurezza basata su virtualizzazione, vedere Sicurezza basata su virtualizzazione.You can learn more about VBS by reading Virtualization-based Security (VBS).

Hypervisor-Protected Code Integrity and Credential Guard Readiness Tool

Per determinare se un dispositivo è in grado di eseguire HVCI e Credential Guard, scaricare lo strumento di preparazione hardware HVCI e Credential Guard.