Controllare l'integrità dei dispositivi Windows

• Si applica a:

  ✅ Windows 11, ✅ Windows 10

Questo articolo descrive in dettaglio una soluzione end-to-end che consente di proteggere gli asset di valore elevato applicando, controllando e segnalando l'integrità dei dispositivi Windows.

Introduzione

Per gli scenari Bring Your Own Device (BYOD), i dipendenti portano dispositivi disponibili in commercio per accedere sia alle risorse correlate al lavoro che ai dati personali. Gli utenti vogliono usare il dispositivo preferito per accedere alle applicazioni, ai dati e alle risorse dell'organizzazione non solo dalla rete interna, ma anche da qualsiasi luogo. Questo fenomeno è noto anche come consumerizzazione dell'IT.

Gli utenti vogliono avere la migliore esperienza di produttività quando accedono alle applicazioni aziendali e lavorano sui dati dell'organizzazione dai propri dispositivi. Ciò significa che non tollerano la richiesta di immettere le credenziali di lavoro ogni volta che accedono a un'applicazione o a un file server. Dal punto di vista della sicurezza, significa anche che gli utenti manipolano le credenziali aziendali e i dati aziendali su dispositivi non gestiti.

Con l'aumento dell'uso di BYOD, ci saranno sistemi più non gestiti e potenzialmente non integri che accedono ai servizi aziendali, alle risorse interne e alle app cloud.

Anche i dispositivi gestiti possono essere compromessi e diventare dannosi. Le organizzazioni devono rilevare quando la sicurezza è stata violata e reagire il prima possibile per proteggere gli asset di valore elevato.

Man mano che Microsoft procede, gli investimenti per la sicurezza sono sempre più incentrati sulle difese preventive della sicurezza e anche sulle funzionalità di rilevamento e risposta.

Windows è un componente importante di una soluzione di sicurezza end-to-end che si concentra non solo sull'implementazione delle difese preventive di sicurezza, ma aggiunge funzionalità di attestazione dell'integrità dei dispositivi alla strategia di sicurezza complessiva.

Descrizione di una soluzione di sicurezza end-to-end affidabile

Il panorama delle minacce informatiche di oggi sta aumentando a una velocità mai incontrata prima. La raffinatezza degli attacchi criminali sta crescendo, e non c'è dubbio che il malware ora si rivolge sia ai consumatori che ai professionisti di tutti i settori.

Negli ultimi anni, una particolare categoria di minacce è diventata prevalente: le minacce persistenti avanzate (ADT). Il termine APT viene comunemente usato per descrivere qualsiasi attacco che sembra indirizzare le singole organizzazioni su base continuativa. In realtà, questo tipo di attacco coinvolge in genere avversari determinati che possono usare qualsiasi metodo o tecnica necessaria.

Con i fenomeni BYOD, un dispositivo mal mantenuto rappresenta un obiettivo di scelta. Per un utente malintenzionato, è un modo semplice per violare il perimetro della rete di sicurezza, ottenere l'accesso e quindi rubare asset di alto valore.

Gli utenti malintenzionati prendono di mira gli utenti, non in particolare per chi sono, ma per chi lavorano. Un dispositivo infetto porta malware in un'organizzazione, anche se l'organizzazione ha indurito il perimetro delle reti o ha investito nella sua posizione difensiva. Una strategia difensiva non è sufficiente contro queste minacce.

Un approccio diverso

Invece di concentrarsi tradizionalemente sulla prevenzione della compromissione, una strategia di sicurezza efficace presuppone che gli avversari determinati violano con successo qualsiasi difesa. Significa che è necessario spostare lo stato attivo dai controlli di sicurezza preventivi al rilevamento e alla risposta ai problemi di sicurezza. L'implementazione della strategia di gestione dei rischi, quindi, bilancia gli investimenti in prevenzione, rilevamento e risposta.

Poiché i dispositivi mobili vengono sempre più usati per accedere alle informazioni aziendali, è necessario un modo per valutare la sicurezza o l'integrità dei dispositivi. Questa sezione descrive come effettuare il provisioning della valutazione dell'integrità dei dispositivi in modo che gli asset di valore elevato possano essere protetti da dispositivi non integri.

I dispositivi usati per accedere alle risorse aziendali devono essere considerati attendibili. Un approccio di sicurezza end-to-end efficiente è in grado di valutare l'integrità dei dispositivi e usare lo stato di sicurezza corrente quando si concede l'accesso a un asset di valore elevato.

Una progettazione affidabile deve stabilire l'identità dell'utente, rafforzare il metodo di autenticazione, se necessario, e apprendere comportamenti come il percorso di rete da cui l'utente si connette regolarmente. Inoltre, un approccio moderno deve essere in grado di rilasciare contenuti sensibili solo se i dispositivi utente sono determinati a essere integri e sicuri.

La figura seguente mostra una soluzione creata per valutare l'integrità dei dispositivi dal cloud. Il dispositivo autentica l'utente tramite una connessione a un provider di identità nel cloud. Se l'asset gestito contiene informazioni altamente riservate, il motore di accesso condizionale del provider di identità può decidere di verificare la conformità di sicurezza del dispositivo mobile prima che venga concesso l'accesso. Il dispositivo dell'utente è in grado di dimostrare il proprio stato di integrità che può essere inviato in qualsiasi momento o quando la gestione dei dispositivi mobili (MDM) lo richiede.

I dispositivi Windows possono essere protetti da rootkit e bootkit di basso livello usando tecnologie hardware di basso livello, ad esempio l'avvio protetto UEFI (Unified Extensible Firmware Interface).

L'avvio protetto è un processo di convalida del firmware che consente di evitare attacchi rootkit; fa parte della specifica UEFI. Lo scopo di UEFI è quello di definire un modo standard per il sistema operativo di comunicare con l'hardware moderno, che può eseguire più velocemente e con funzioni di input/output (I/O) più efficienti rispetto ai sistemi BIOS basati su interrupt software meno recenti.

Un modulo di attestazione dell'integrità dei dispositivi può comunicare dati di avvio misurati protetti da un modulo TPM (Trusted Platform Module) a un servizio remoto. Dopo l'avvio del dispositivo, i dati di misurazione del processo di avvio vengono inviati a un servizio cloud attendibile (servizio di attestazione dell'integrità) usando un canale di comunicazione più sicuro e resistente alle manomissioni.

Il servizio di attestazione dell'integrità remota esegue una serie di controlli sulle misurazioni. Convalida i punti dati correlati alla sicurezza, incluso lo stato di avvio (avvio protetto, modalità di debug e così via) e lo stato dei componenti che gestiscono la sicurezza (BitLocker, Device Guard e così via). Trasmette quindi lo stato di integrità del dispositivo inviando un BLOB crittografato per l'integrità al dispositivo.

Una soluzione MDM in genere applica i criteri di configurazione e distribuisce il software ai dispositivi. MDM definisce la baseline di sicurezza e conosce il livello di conformità del dispositivo con controlli regolari per vedere quale software è installato e quale configurazione viene applicata e determinare lo stato di integrità del dispositivo.

Una soluzione MDM chiede al dispositivo di inviare informazioni sull'integrità del dispositivo e inoltrare il BLOB crittografato per l'integrità al servizio di attestazione dell'integrità remota. Il servizio di attestazione dell'integrità remota verifica i dati sull'integrità del dispositivo, verifica che MDM comunichi con lo stesso dispositivo e quindi invia un report sull'integrità del dispositivo alla soluzione MDM.

Una soluzione MDM valuta le asserzioni di integrità e, a seconda delle regole di integrità appartenenti all'organizzazione, può decidere se il dispositivo è integro. Se il dispositivo è integro e conforme, MDM passa tali informazioni al provider di identità in modo che i criteri di controllo di accesso dell'organizzazione possano essere richiamati per concedere l'accesso.

L'accesso al contenuto viene quindi autorizzato al livello di attendibilità appropriato per qualsiasi stato di integrità e altri elementi condizionali indicati.

A seconda dei requisiti e della sensibilità dell'asset gestito, lo stato di integrità del dispositivo può essere combinato con le informazioni sull'identità utente durante l'elaborazione di una richiesta di accesso. L'accesso al contenuto viene quindi autorizzato al livello di attendibilità appropriato. Il motore di accesso condizionale può essere strutturato in modo da consentire una maggiore verifica in base alle esigenze in base alla sensibilità dell'asset gestito. Ad esempio, se viene richiesto l'accesso a dati di valore elevato, potrebbe essere necessario stabilire un'ulteriore autenticazione di sicurezza eseguendo una query sull'utente per rispondere a una chiamata telefonica prima che venga concesso l'accesso.

Investimenti per la sicurezza di Microsoft in Windows

In Windows esistono tre pilastri degli investimenti:

• Identità sicure. Microsoft fa parte dell'alleanza FIDO che mira a fornire un metodo interoperativo di autenticazione sicura, allontanandosi dall'uso delle password per l'autenticazione, sia nel sistema locale che per servizi come le risorse locali e le risorse cloud.
• Protezione dei dati. Microsoft sta effettuando investimenti per consentire alle organizzazioni di avere un controllo migliore su chi ha accesso a dati importanti e su cosa possono fare con tali dati. Con Windows, le organizzazioni possono sfruttare i criteri che specificano quali applicazioni vengono considerate applicazioni aziendali e possono essere considerate attendibili per accedere a dati sicuri.
• Resistenza alle minacce. Microsoft aiuta le organizzazioni a proteggere meglio gli asset aziendali dalle minacce di malware e attacchi usando difese di sicurezza basate sull'hardware.

Proteggere, controllare e segnalare lo stato di sicurezza dei dispositivi basati su Windows

Questa sezione è una panoramica che descrive diverse parti della soluzione di sicurezza end-to-end che consente di proteggere asset e informazioni di alto valore da utenti malintenzionati e malware.

Numero	Parte della soluzione	Descrizione
1	Dispositivo basato su Windows	La prima volta che un dispositivo basato su Windows viene acceso, viene visualizzata la schermata configurazione guidata. Durante l'installazione, il dispositivo può essere registrato automaticamente in Microsoft Entra ID e registrato in MDM. Un dispositivo basato su Windows con TPM può segnalare lo stato di integrità in qualsiasi momento usando il servizio di attestazione dell'integrità disponibile con tutte le edizioni supportate di Windows.
2	Provider di identità	Microsoft Entra ID contiene utenti, dispositivi registrati e applicazioni registrate del tenant dell'organizzazione. Un dispositivo appartiene sempre a un utente e un utente può avere più dispositivi. Un dispositivo è rappresentato come un oggetto con attributi diversi, ad esempio lo stato di conformità del dispositivo. Un MDM attendibile può aggiornare lo stato di conformità. Microsoft Entra ID è più di un repository. Microsoft Entra ID è in grado di autenticare utenti e dispositivi e può anche autorizzare l'accesso alle risorse gestite. Microsoft Entra ID dispone di un motore di controllo di accesso condizionale che usa l'identità dell'utente, la posizione del dispositivo e anche lo stato di conformità del dispositivo quando si decide di accedere in modo attendibile.
3	Gestione dispositivi mobili (MDM)	Windows offre il supporto MDM che consente di gestire il dispositivo all'avanguardia senza distribuire alcun agente. MDM può essere Microsoft Intune o qualsiasi soluzione MDM di terze parti compatibile con Windows.
4	Attestazione dell'integrità remota	Il servizio di attestazione dell'integrità è un servizio cloud attendibile gestito da Microsoft che esegue una serie di controlli di integrità e segnala a MDM quali funzionalità di sicurezza di Windows sono abilitate nel dispositivo. La verifica della sicurezza include lo stato di avvio (WinPE, modalità provvisoria, modalità di debug/test) e i componenti che gestiscono la sicurezza e l'integrità delle operazioni di runtime (BitLocker, Device Guard).
5	Asset gestito dall'organizzazione	L'asset gestito dell'organizzazione è la risorsa da proteggere. Ad esempio, l'asset può essere Office 365, altre app cloud, risorse Web locali pubblicate da Microsoft Entra ID o persino l'accesso VPN.

La combinazione di dispositivi basati su Windows, provider di identità, MDM e attestazione dell'integrità remota crea una soluzione end-to-end affidabile che fornisce la convalida dell'integrità e della conformità dei dispositivi che accedono ad asset di alto valore.

Proteggere i dispositivi e le credenziali aziendali dalle minacce

Questa sezione descrive le offerte di Windows in termini di difese di sicurezza e a quale controllo può essere misurato e segnalato.

Difese di sicurezza basate su hardware Windows

Le forme più aggressive di malware cercano di inserirsi nel processo di avvio il più presto possibile in modo che possano prendere il controllo del sistema operativo in anticipo e impedire meccanismi di protezione e software antimalware di funzionare. Questo tipo di codice dannoso viene spesso chiamato rootkit o bootkit. Il modo migliore per evitare di dover gestire il malware di basso livello è proteggere il processo di avvio in modo che il dispositivo sia protetto fin dall'inizio. Windows supporta più livelli di protezione di avvio. Alcune di queste funzionalità sono disponibili solo se sono installati tipi specifici di hardware. Per altre informazioni, vedere la sezione Requisiti hardware .

Windows supporta funzionalità che consentono di impedire il caricamento di malware sofisticati di basso livello come rootkit e bootkit durante il processo di avvio:

• Modulo piattaforma attendibile. Un modulo TPM (Trusted Platform Module) è un componente hardware che offre funzionalità di sicurezza univoche.

  Windows usa le caratteristiche di sicurezza di un TPM per misurare la sequenza di integrità di avvio (e in base a questo, sbloccare automaticamente le unità protette da BitLocker), per proteggere le credenziali o per l'attestazione dell'integrità.

  Un TPM implementa controlli che soddisfano la specifica descritta da Trusted Computing Group (TCG). Al momento della stesura di questo articolo, esistono due versioni della specifica TPM prodotte da TCG che non sono compatibili tra loro:

  • La prima specifica TPM, la versione 1.2, è stata pubblicata nel febbraio 2005 dal TCG e standardizzata in base allo standard ISO/IEC 11889.
  • La specifica TPM più recente, nota come TPM 2.0, è stata rilasciata nell'aprile 2014 ed è stata approvata dal comitato tecnico congiunto ISO/IEC (JTC) come ISO/IEC 11889:2015.

  Windows usa il TPM per i calcoli di crittografia come parte dell'attestazione dell'integrità e per proteggere le chiavi per BitLocker, Windows Hello, smart card virtuali e altri certificati di chiave pubblica. Per altre informazioni, vedere Requisiti di TPM in Windows.

  Windows riconosce le versioni 1.2 e 2.0 delle specifiche TPM prodotte dal TCG. Per le funzionalità di sicurezza più recenti e moderne, Windows supporta solo TPM 2.0.

  TPM 2.0 offre una revisione importante delle funzionalità di TPM 1.2:

  • Aggiornare la forza della crittografia per soddisfare le esigenze di sicurezza moderne

    • Supporto per SHA-256 per pcr
    • Supporto per il comando HMAC

  • Flessibilità degli algoritmi di crittografia per supportare le esigenze di enti pubblici

    • TPM 1.2 è fortemente limitato in termini di algoritmi che può supportare
    • TPM 2.0 può supportare algoritmi arbitrari con aggiornamenti secondari ai documenti delle specifiche TCG

  • Coerenza tra implementazioni

    • La specifica TPM 1.2 consente ai fornitori un'ampia latitudine nella scelta dei dettagli di implementazione
    • TPM 2.0 standardizza gran parte di questo comportamento

• Avvio protetto I dispositivi con firmware UEFI possono essere configurati per caricare solo i bootloader del sistema operativo attendibili. L'avvio protetto non richiede un TPM.

  La protezione più semplice è la funzionalità di avvio protetto, che è una parte standard dell'architettura UEFI 2.2+. In un PC con BIOS convenzionale, chiunque possa assumere il controllo del processo di avvio può eseguire l'avvio usando un caricatore del sistema operativo alternativo e potenzialmente ottenere l'accesso alle risorse di sistema. Quando l'avvio protetto è abilitato, è possibile eseguire l'avvio usando solo un caricatore del sistema operativo firmato usando un certificato archiviato nel database di avvio protetto UEFI. Naturalmente, il certificato Microsoft usato per firmare digitalmente i caricatori del sistema operativo Windows si trovano in tale archivio, che consente a UEFI di convalidare il certificato come parte dei criteri di sicurezza. L'avvio protetto deve essere abilitato per impostazione predefinita in tutti i computer certificati per Windows nel programma di compatibilità hardware di Windows.

  L'avvio protetto è una funzionalità basata su firmware UEFI, che consente la firma e la verifica dei file e dei driver di avvio critici in fase di avvio. Avvio protetto controlla i valori delle firme di Gestione avvio Windows, dell'archivio BCD, del file del caricatore del sistema operativo Windows e di altre DLL critiche di avvio in fase di avvio prima che al sistema sia consentito l'avvio completo in un sistema operativo utilizzabile usando criteri definiti dall'OEM in fase di compilazione. L'avvio protetto impedisce molti tipi di rootkit, malware e altri attacchi correlati alla sicurezza basati sull'avvio contro la piattaforma Windows. L'avvio protetto protegge il processo di avvio del sistema operativo, sia che si avvii da disco rigido locale, USB, PXE o DVD, sia in windows o ambiente di ripristino (RE) completo. L'avvio protetto protegge l'ambiente di avvio di un'installazione di Windows verificando le firme dei componenti di avvio critici per confermare che le attività dannose non le hanno compromesse. La protezione dell'avvio protetto termina dopo il caricamento del file kernel di Windows (ntoskrnl.exe).

  Nota

  Avvio protetto protegge la piattaforma fino al caricamento del kernel Windows. Quindi le protezioni come ELAM prendono il controllo.

• Criteri di configurazione dell'avvio protetto. Estende la funzionalità di avvio protetto alla configurazione di Windows critica.

  Esempi di informazioni di configurazione protette includono la protezione di Disabilita bit di esecuzione (opzione NX) o la garanzia che i criteri di firma del test (integrità del codice) non possano essere abilitati. Questa azione protettiva garantisce che i file binari e la configurazione del computer possano essere considerati attendibili al termine del processo di avvio. I criteri di configurazione dell'avvio protetto eserci ano questa azione protettiva con i criteri UEFI. Queste firme per questi criteri vengono firmate nello stesso modo in cui i file binari del sistema operativo vengono firmati per l'uso con l'avvio protetto.

  I criteri di configurazione dell'avvio protetto devono essere firmati da una chiave privata che corrisponde a una delle chiavi pubbliche archiviate nell'elenco chiave chiave di scambio (KEK). L'autorità di certificazione Microsoft (CA) sarà presente nell'elenco kek di tutti i sistemi di avvio protetto certificati windows. Per impostazione predefinita, un criterio firmato da Microsoft KEK deve funzionare in tutti i sistemi di avvio protetto. BootMgr deve verificare la firma nell'elenco kek prima di applicare un criterio firmato. Con Windows, i criteri di configurazione di avvio protetto predefiniti sono incorporati in bootmgr.

  Il bootloader verifica la firma digitale del kernel di Windows prima di caricarla. Il kernel Windows, a sua volta, verifica tutti gli altri componenti del processo di avvio di Windows, inclusi i driver di avvio, i file di avvio e il componente ELAM. Questo passaggio è importante e protegge il resto del processo di avvio verificando che tutti i componenti di avvio di Windows abbiano integrità e possano essere considerati attendibili.

• Antimalware ad esecuzione anticipata (ELAM, Early Launch Antimalware). Antimalware ad esecuzione anticipata verifica tutti i driver prima che vengano caricati e impedisce il caricamento dei driver non approvati.

  Le app antimalware tradizionali vengono avviate solo dopo il caricamento dei driver di avvio, che offre a un rootkit travestito da driver l'opportunità di lavorare. ELAM è un meccanismo di Windows introdotto in una versione precedente di Windows che consente l'esecuzione del software antimalware all'inizio della sequenza di avvio. Di conseguenza, il componente antimalware è il primo componente di terze parti a eseguire e controllare l'inizializzazione di altri driver di avvio fino a quando il sistema operativo Windows non è operativo. Quando il sistema viene avviato con un ambiente di runtime completo (accesso alla rete, archiviazione e così via), viene caricato un antimalware completo.

  ELAM può caricare un driver antimalware Microsoft o non Microsoft prima di tutti i driver e le applicazioni di avvio non Microsoft, continuando così la catena di attendibilità stabilita da Avvio sicuro e Avvio attendibile. Poiché il sistema operativo non è ancora stato avviato e Windows deve essere avviato il più rapidamente possibile, ELAM ha un'attività semplice: esaminare ogni driver di avvio e determinare se è presente nell'elenco dei driver attendibili. Se non è attendibile, Windows non lo caricherà.

  Nota

  Windows Defender, l'antimalware microsoft incluso per impostazione predefinita in Windows supporta ELAM; può essere sostituito con una soluzione compatibile con antimalware di terze parti. Il nome del driver ELAM Windows Defender è WdBoot.sys. Windows Defender usa il driver ELAM per eseguire il rollback di eventuali modifiche dannose apportate al driver Windows Defender al riavvio successivo. Ciò impedisce al malware in modalità kernel di apportare modifiche durature al driver del mini filtro di Windows Defender prima dell'arresto o del riavvio.

  Il driver firmato ELAM viene caricato prima di qualsiasi altro driver o applicazione di terze parti, che consente al software antimalware di rilevare e bloccare eventuali tentativi di manomissione del processo di avvio provando a caricare codice non firmato o non attendibile.

  Il driver ELAM è un driver di piccole dimensioni con un database di criteri di piccole dimensioni con un ambito limitato, incentrato sui driver caricati in anticipo all'avvio del sistema. Il database dei criteri viene archiviato in un hive del Registro di sistema che viene misurato anche nel TPM, per registrare i parametri operativi del driver ELAM. Un driver ELAM deve essere firmato da Microsoft e il certificato associato deve contenere l'EKU complementare (1.3.6.1.4.1.311.61.4.1).

• Sicurezza basata su virtualizzazione (Hyper-V + Kernel sicuro). La sicurezza basata sulla virtualizzazione è un nuovo limite di sicurezza applicato che consente di proteggere parti critiche di Windows.

  La sicurezza basata sulla virtualizzazione isola il codice sensibile, ad esempio l'integrità del codice in modalità kernel o le credenziali di dominio aziendali sensibili, dal resto del sistema operativo Windows. Per altre informazioni, vedere la sezione Sicurezza basata su virtualizzazione .

• Integrità del codice protetta da Hypervisor (HVCI). L'integrità del codice protetta da Hypervisor è una funzionalità di Device Guard che garantisce l'esecuzione solo di driver, eseguibili e DLL conformi ai criteri di integrità del codice di Device Guard.

  Se abilitato e configurato, Windows può avviare i servizi di sicurezza basati su virtualizzazione Hyper-V. HVCI consente di proteggere il core di sistema (kernel), i driver con privilegi e le difese di sistema, come le soluzioni antimalware, impedendo l'esecuzione di malware all'inizio del processo di avvio o dopo l'avvio.

  HVCI usa la sicurezza basata sulla virtualizzazione per isolare l'integrità del codice. L'unico modo in cui la memoria del kernel può diventare eseguibile è tramite una verifica dell'integrità del codice. Questa dipendenza dalla verifica significa che le pagine di memoria del kernel non possono mai essere scrivibili e eseguibili (W+X) e il codice eseguibile non può essere modificato direttamente.

  Nota

  I dispositivi Device Guard che eseguono l'integrità del codice in modalità kernel con sicurezza basata sulla virtualizzazione devono avere driver compatibili. Per altre informazioni, leggere il post di blog Compatibilità dei driver con Device Guard in Windows .

  La funzionalità Integrità del codice di Device Guard consente alle organizzazioni di controllare il codice considerato attendibile per l'esecuzione nel kernel di Windows e le applicazioni approvate per l'esecuzione in modalità utente. È configurabile usando un criterio. I criteri di integrità del codice di Device Guard sono un file binario che Microsoft consiglia di firmare. La firma dei criteri di integrità del codice facilita la protezione da un utente malintenzionato con privilegi di amministratore che tenta di modificare o rimuovere i criteri di integrità del codice correnti.

• Credential Guard. Credential Guard protegge le credenziali aziendali con l'isolamento delle credenziali basate su hardware.

  In Windows, Credential Guard mira a proteggere le credenziali aziendali del dominio dal furto e dal riutilizzo da parte del malware. Con Credential Guard, Windows ha implementato una modifica dell'architettura che impedisce fondamentalmente le forme correnti dell'attacco pass-the-hash (PtH).

  Questo stato senza attacchi viene ottenuto usando Hyper-V e la nuova funzionalità di sicurezza basata su virtualizzazione per creare un contenitore protetto in cui il codice e i segreti attendibili sono isolati dal kernel di Windows. Questo risultato significa che anche se il kernel di Windows è compromesso, un utente malintenzionato non ha modo di leggere ed estrarre i dati necessari per avviare un attacco PtH. Credential Guard impedisce questo accesso non autorizzato perché la memoria in cui vengono archiviati i segreti non è più accessibile dal sistema operativo normale, anche in modalità kernel: l'hypervisor controlla chi può accedere alla memoria.

• Attestazione dell'integrità. Il firmware del dispositivo registra il processo di avvio e Windows può inviarlo a un server attendibile in grado di controllare e valutare l'integrità del dispositivo.

  Windows esegue le misurazioni del firmware UEFI e ognuno dei componenti Windows e antimalware viene eseguito durante il caricamento durante il processo di avvio. Inoltre, vengono presi e misurati in sequenza, non tutti contemporaneamente. Al termine di queste misurazioni, i relativi valori vengono firmati digitalmente e archiviati in modo sicuro nel TPM e non possono essere modificati a meno che il sistema non venga reimpostato.

  Per altre informazioni, vedere Avvio protetto e avvio misurato: protezione avanzata dei componenti di avvio anticipato da malware.

  Durante ogni avvio successivo, vengono misurati gli stessi componenti, che consentono il confronto delle misurazioni con una baseline prevista. Per maggiore sicurezza, i valori misurati dal TPM possono essere firmati e trasmessi a un server remoto, che può quindi eseguire il confronto. Questo processo, denominato attestazione dell'integrità del dispositivo remoto, consente al server di verificare lo stato di integrità del dispositivo Windows.

  Sebbene l'avvio protetto sia una forma proattiva di protezione, l'attestazione dell'integrità è una forma reattiva di protezione dell'avvio. L'attestazione dell'integrità viene fornita disabilitata in Windows ed è abilitata da un antimalware o da un fornitore MDM. A differenza dell'avvio protetto, l'attestazione dell'integrità non arresterà il processo di avvio e immetti la correzione quando una misurazione non funziona. Con il controllo di accesso condizionale, tuttavia, l'attestazione dell'integrità consente di impedire l'accesso ad asset di valore elevato.

Sicurezza basata su virtualizzazione

La sicurezza basata sulla virtualizzazione offre un nuovo limite di attendibilità per Windows e usa la tecnologia hypervisor Hyper-V per migliorare la sicurezza della piattaforma. La sicurezza basata sulla virtualizzazione offre un ambiente di esecuzione sicuro per eseguire codice attendibile (trustlet) di Windows specifico e per proteggere i dati sensibili.

La sicurezza basata sulla virtualizzazione consente di proteggere da un kernel compromesso o da un utente malintenzionato con privilegi di amministratore. La sicurezza basata sulla virtualizzazione non sta tentando di proteggersi da un utente malintenzionato fisico.

I servizi Windows seguenti sono protetti con sicurezza basata sulla virtualizzazione:

• Credential Guard (LSA Credential Isolation): impedisce gli attacchi pass-the-hash e il furto di credenziali aziendali che si verifica leggendo e scaricando il contenuto della memoria lsass
• Device Guard (Integrità del codice Hyper-V): Device Guard usa la nuova sicurezza basata sulla virtualizzazione in Windows per isolare il servizio Integrità codice dal kernel di Windows stesso, che consente al servizio di usare le firme definite dai criteri controllati dall'organizzazione per determinare ciò che è attendibile. In effetti, il servizio Integrità del codice viene eseguito insieme al kernel in un contenitore protetto da hypervisor di Windows.
• Altri servizi isolati: ad esempio, in Windows Server 2016, è disponibile la funzionalità vTPM che consente di disporre di macchine virtuali crittografate nei server.

Nota

La sicurezza basata su virtualizzazione è disponibile solo con Enterprise Edition. La sicurezza basata sulla virtualizzazione richiede dispositivi con UEFI (2.3.1 o versione successiva) con avvio protetto abilitato, processore x64 con estensioni di virtualizzazione e SLAT abilitati. IOMMU, TPM 2.0. e il supporto per la memoria sicura sovrascritti sono facoltativi, ma consigliati.

Lo schema seguente è una visualizzazione generale di Windows con sicurezza basata sulla virtualizzazione.

Credential Guard

In Windows, quando Credential Guard è abilitato, il servizio sottosistema dell'autorità di sicurezza locale (lsass.exe) esegue un codice sensibile in modalità utente isolato per proteggere i dati da malware che potrebbero essere in esecuzione in modalità utente normale. Questa esecuzione del codice consente di garantire che i dati protetti non vengano rubati e riutilizzati nei computer remoti, il che riduce molti attacchi di tipo PtH.

Credential Guard consente di proteggere le credenziali crittografandole con una chiave per avvio o permanente:

• La chiave per avvio viene usata per tutte le credenziali in memoria che non richiedono la persistenza. Un esempio di tale credenziale è una chiave di sessione TGT (Ticket-Granting Ticket). Questa chiave viene negoziata con un Centro distribuzione chiavi ogni volta che si verifica l'autenticazione e viene protetta con una chiave per avvio.
• La chiave persistente, o una derivata, viene usata per proteggere gli elementi archiviati e ricaricati dopo un riavvio. Tale protezione è destinata all'archiviazione a lungo termine e deve essere protetta con una chiave coerente. Credential Guard viene attivato da una chiave del Registro di sistema e quindi abilitato tramite una variabile UEFI. Questa attivazione viene eseguita per proteggere da modifiche remote della configurazione. L'uso di una variabile UEFI implica che l'accesso fisico sia necessario per modificare la configurazione. Quando lsass.exe rileva che l'isolamento delle credenziali è abilitato, genera quindi LsaIso.exe come processo isolato, che garantisce che venga eseguito in modalità utente isolato. L'avvio di LsaIso.exe viene eseguito prima dell'inizializzazione di un provider di supporto di sicurezza, che garantisce che le routine di supporto della modalità protetta siano pronte prima dell'avvio di qualsiasi autenticazione.

Device Guard

Device Guard è una funzionalità di Windows Enterprise che consente alle organizzazioni di bloccare un dispositivo per proteggerlo dall'esecuzione di software non attendibile. In questa configurazione, le uniche applicazioni consentite per l'esecuzione sono quelle considerate attendibili dall'organizzazione.

La decisione di attendibilità per l'esecuzione del codice viene eseguita usando l'integrità del codice Hyper-V, che viene eseguita in sicurezza basata sulla virtualizzazione, un contenitore protetto Hyper-V che viene eseguito insieme a Windows normale.

Integrità del codice Hyper-V è una funzionalità che convalida l'integrità di un driver o di un file di sistema ogni volta che viene caricato in memoria. L'integrità del codice rileva se un driver non firmato o un file di sistema viene caricato nel kernel o se un file di sistema è stato modificato da software dannoso eseguito da un account utente con privilegi di amministratore. Nelle versioni basate su x64 di Windows, i driver in modalità kernel devono essere firmati digitalmente.

Nota

Indipendentemente dall'attivazione dei criteri di Device Guard, i driver Windows devono essere firmati da Microsoft e, più in particolare, dal portale WHQL (Windows Hardware Quality Labs). Inoltre, a partire da ottobre 2015, il portale WHQL accetterà solo gli invii di driver, inclusi gli invii di driver in modalità kernel e utente, che hanno un certificato di firma del codice valido per la convalida estesa ("EV").

Con Device Guard, le organizzazioni sono ora in grado di definire i propri criteri di integrità del codice da usare nei sistemi x64 che eseguono Windows Enterprise. Le organizzazioni hanno la possibilità di configurare i criteri che determinano ciò che è attendibile per l'esecuzione. Questi includono driver e file di sistema e applicazioni desktop e script tradizionali. Il sistema viene quindi bloccato per eseguire solo le applicazioni attendibili dall'organizzazione.

Device Guard è una funzionalità predefinita di Windows Enterprise che impedisce l'esecuzione di codice e applicazioni indesiderate. Device Guard può essere configurato usando due azioni delle regole: consenti e nega:

• Consenti limita l'esecuzione delle applicazioni a un elenco consentito di codice o autore attendibile e blocca tutto il resto.
• Deny completa l'approccio consenti autore attendibile bloccando l'esecuzione di un'applicazione specifica.

Al momento di questa scrittura, e secondo la ricerca più recente di Microsoft, più del 90 per cento del malware non è firmato completamente. L'implementazione di un criterio di base di Device Guard può quindi aiutare a bloccare il malware in modo semplice ed efficace. In effetti, Device Guard ha il potenziale per andare oltre e può anche aiutare a bloccare il malware firmato.

Device Guard deve essere pianificato e configurato per essere veramente efficace. Non si tratta solo di una protezione abilitata o disabilitata. Device Guard è una combinazione di funzionalità di sicurezza hardware e funzionalità di sicurezza software che, se configurate insieme, possono bloccare un computer per garantire il sistema più sicuro e resistente possibile.

Esistono tre parti diverse che costituiscono la soluzione Device Guard in Windows:

• La prima parte è un set di base di funzionalità di sicurezza hardware introdotte con la versione precedente di Windows. TPM per le operazioni di crittografia hardware e UEFI con firmware moderno, insieme all'avvio protetto, consente di controllare il dispositivo in esecuzione all'avvio dei sistemi.
• Dopo la funzionalità di sicurezza hardware, è disponibile il motore di integrità del codice. In Windows l'integrità del codice è ora completamente configurabile e ora si trova in modalità utente isolato, una parte della memoria protetta dalla sicurezza basata sulla virtualizzazione.
• L'ultima parte di Device Guard è la gestibilità. La configurazione dell'integrità del codice viene esposta tramite oggetti Criteri di gruppo specifici, cmdlet di PowerShell e provider di servizi di configurazione MDM.

Per altre informazioni su come distribuire Device Guard in un'organizzazione, vedere la guida alla distribuzione di Device Guard.

Scenari di Device Guard

Come descritto in precedenza, Device Guard è un modo efficace per bloccare i sistemi. Device Guard non è progettato per essere usato in modo ampio e potrebbe non essere sempre applicabile, ma esistono alcuni scenari di interesse elevato.

Device Guard è utile e applicabile nei sistemi di carichi di lavoro fissi, ad esempio registratori di cassa, computer in modalità tutto schermo, workstation secure Amministrazione (SAW) o desktop ben gestiti. Device Guard è molto rilevante nei sistemi con un software ben definito che dovrebbe essere eseguito e che non cambia troppo frequentemente. Potrebbe anche aiutare a proteggere gli Information Worker (IW) oltre alle sole SAW, purché ciò che devono eseguire sia noto e che il set di applicazioni non cambi su base giornaliera.

I SAW sono computer creati per ridurre significativamente il rischio di compromissione da malware, attacchi di phishing, siti Web fasulli e attacchi PtH, tra gli altri rischi per la sicurezza. Anche se le saw non possono essere considerate una soluzione di sicurezza "silver bullet" per questi attacchi, questi tipi di client sono utili come parte di un approccio a più livelli e di difesa in profondità alla sicurezza.

Per proteggere gli asset di valore elevato, le saw vengono usate per stabilire connessioni sicure a tali asset.

Analogamente, nelle workstation aziendali completamente gestite, in cui le applicazioni vengono installate usando uno strumento di distribuzione come Microsoft Configuration Manager, Intune o qualsiasi gestione di dispositivi di terze parti, è applicabile Device Guard. In questo tipo di scenario, l'organizzazione ha una buona idea del software in esecuzione da un utente medio.

Potrebbe essere difficile usare Device Guard in workstation aziendali gestite con leggerezza, in cui l'utente è in genere autorizzato a installare il software autonomamente. Quando un'organizzazione offre una grande flessibilità, è difficile eseguire Device Guard in modalità di imposizione. Tuttavia, Device Guard può essere eseguito in modalità di controllo e, in tal caso, il registro eventi conterrà un record di eventuali file binari che violano i criteri di Device Guard. Quando Device Guard viene usato in modalità di controllo, le organizzazioni possono ottenere dati avanzati sui driver e le applicazioni che gli utenti installano ed eseguono.

Prima di poter trarre vantaggio dalla protezione inclusa in Device Guard, è necessario creare i criteri di integrità del codice usando gli strumenti forniti da Microsoft, ma i criteri possono essere distribuiti con strumenti di gestione comuni, ad esempio Criteri di gruppo. I criteri di integrità del codice sono un documento XML con codifica binaria che include le impostazioni di configurazione per le modalità utente e kernel di Windows, oltre alle restrizioni per gli host script di Windows. I criteri di integrità del codice di Device Guard limitano il codice che può essere eseguito in un dispositivo.

Nota

I criteri di Device Guard possono essere firmati in Windows, che aggiunge ulteriore protezione contro la modifica o la rimozione di questo criterio da parte degli utenti amministratori.

I criteri di Device Guard firmati offrono una protezione più avanzata da un amministratore locale malintenzionato che tenta di sconfiggere Device Guard.

Quando il criterio è firmato, il GUID del criterio viene archiviato in una variabile protetta pre-sistema operativo UEFI che offre protezione dalle manomissioni. L'unico modo per aggiornare i criteri di Device Guard in un secondo momento consiste nel fornire una nuova versione dei criteri firmati dallo stesso firmatario o da un firmatario specificato come parte dei criteri di Device Guard nella sezione UpdateSigner.

L'importanza della firma delle applicazioni

Nei computer con Device Guard, Microsoft propone di passare da un mondo in cui le app non firmate possono essere eseguite senza restrizioni a un mondo in cui è consentito l'esecuzione solo di codice firmato e attendibile in Windows.

Con Windows, le organizzazioni renderanno le app line-of-business (LOB) disponibili per i membri dell'organizzazione tramite l'infrastruttura di Microsoft Store. In particolare, le app LOB saranno disponibili in un archivio privato all'interno del Microsoft Store pubblico. Microsoft Store firma e distribuisce app di Windows universali e app di Windows classiche. Tutte le app scaricate da Microsoft Store sono firmate.

Nelle organizzazioni oggi molte applicazioni LOB non sono firmate. La firma del codice viene spesso considerata un problema difficile da risolvere per vari motivi, ad esempio la mancanza di competenze per la firma del codice. Anche se la firma del codice è una procedura consigliata, molte applicazioni interne non sono firmate.

Windows include strumenti che consentono ai professionisti IT di accettare le applicazioni già incluse in un pacchetto ed eseguirle tramite un processo per creare più firme che possono essere distribuite insieme alle applicazioni esistenti.

Perché sono ancora necessarie soluzioni antimalware e di gestione dei dispositivi?

Anche se i meccanismi allowlist sono efficienti per garantire l'esecuzione solo di applicazioni attendibili, non possono impedire la compromissione di un'applicazione attendibile (ma vulnerabile) da contenuti dannosi progettati per sfruttare una vulnerabilità nota. Device Guard non protegge dal codice dannoso in modalità utente eseguito sfruttando le vulnerabilità.

Le vulnerabilità sono punti deboli del software che potrebbero consentire a un utente malintenzionato di compromettere l'integrità, la disponibilità o la riservatezza del dispositivo. Alcune delle peggiori vulnerabilità consentono agli utenti malintenzionati di sfruttare il dispositivo compromesso causando l'esecuzione di codice dannoso senza che l'utente ne sia a conoscenza.

È comune vedere gli utenti malintenzionati distribuire contenuti appositamente creati nel tentativo di sfruttare le vulnerabilità note nel software in modalità utente, ad esempio web browser (e i relativi plug-in), macchine virtuali Java, lettori PDF o editor di documenti. A partire da oggi, il 90% delle vulnerabilità individuate influisce sulle applicazioni in modalità utente rispetto ai driver del sistema operativo e della modalità kernel che le ospitano.

Per combattere queste minacce, l'applicazione di patch è il controllo più efficace, con il software antimalware che forma livelli complementari di difesa.

La maggior parte del software dell'applicazione non ha alcuna funzionalità per l'aggiornamento stesso, quindi anche se il fornitore del software pubblica un aggiornamento che corregge la vulnerabilità, l'utente potrebbe non sapere che l'aggiornamento è disponibile o come ottenerlo e quindi rimane vulnerabile agli attacchi. Le organizzazioni devono ancora gestire i dispositivi e correggere le vulnerabilità.

Le soluzioni MDM stanno diventando prevalenti come tecnologia di gestione dei dispositivi leggera. Windows estende le funzionalità di gestione che sono diventate disponibili per gli MDM. Una funzionalità chiave aggiunta da Microsoft a Windows è la possibilità per gli MDM di acquisire un'istruzione avanzata sull'integrità dei dispositivi da dispositivi gestiti e registrati.

Attestazione dell'integrità dei dispositivi

L'attestazione dell'integrità del dispositivo usa il TPM per fornire misurazioni crittograficamente forti e verificabili della catena di software usata per avviare il dispositivo.

Per i dispositivi basati su Windows, Microsoft introduce una nuova API pubblica che consentirà al software MDM di accedere a un servizio di attestazione remoto denominato Servizio attestazione integrità Windows. Un risultato dell'attestazione dell'integrità, oltre ad altri elementi, può essere usato per consentire o negare l'accesso a reti, app o servizi, a seconda che i dispositivi si rivelino integri.

Per altre informazioni sull'attestazione dell'integrità del dispositivo, vedere la sezione Rilevare un dispositivo basato su Windows non integro .

Requisiti di licenza ed edizione di Windows

La tabella seguente elenca le edizioni di Windows che supportano il servizio di attestazione dell'integrità dei dispositivi:

Windows Pro	Windows Enterprise	Windows Pro Education/SE	Windows Education
Sì	Sì	Sì	Sì

I diritti di licenza del servizio di attestazione dell'integrità dei dispositivi sono concessi dalle licenze seguenti:

Windows Pro/Pro Education/SE	Windows Enterprise E3	Windows Enterprise E5	Windows Education A3	Windows Education A5
Sì	Sì	Sì	Sì	Sì

Per ulteriori informazioni sulle licenze di Windows, vedi Panoramica delle licenze di Windows.

Requisiti hardware

La tabella seguente illustra in dettaglio i requisiti hardware sia per i servizi di sicurezza basati sulla virtualizzazione che per la funzionalità di attestazione dell'integrità. Per altre informazioni, vedere Requisiti hardware minimi.

Hardware	Motivazione
Firmware UEFI 2.3.1 o versione successiva con avvio protetto abilitato	Necessario per supportare l'avvio protetto UEFI. L'avvio protetto UEFI garantisce che il dispositivo avvii solo codice autorizzato. Inoltre, l'integrità dell'avvio (avvio protetto della piattaforma) deve essere supportata in base ai requisiti in Specifica di compatibilità hardware per i sistemi per Windows nella sottosezione "System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby"
Le estensioni di virtualizzazione, ad esempio Intel VT-x, AMD-V e SLAT, devono essere abilitate	Necessario per supportare la sicurezza basata sulla virtualizzazione. Nota: Device Guard può essere abilitato senza usare la sicurezza basata sulla virtualizzazione.
Processore X64	Necessario per supportare la sicurezza basata sulla virtualizzazione che usa Windows Hypervisor. Hyper-V è supportato solo nel processore x64 (e non in x86). La protezione DMA (Direct Memory Access) può essere abilitata per offrire una protezione aggiuntiva della memoria, ma richiede che i processori includano tecnologie di protezione DMA.
IOMMU, ad esempio Intel VT-d, AMD-Vi	Il supporto per iommu in Windows migliora la resilienza del sistema contro gli attacchi DMA.
Trusted Platform Module (TPM)	Necessario per supportare l'attestazione dell'integrità e necessario per altre protezioni chiave per la sicurezza basata sulla virtualizzazione. TPM 2.0 è supportato. Il supporto per TPM 1.2 è stato aggiunto a partire da Windows 10 versione 1607 (RS1)

In questa sezione sono state presentate informazioni su diversi controlli strettamente correlati in Windows . Le difese multilivello e l'approccio approfondito consentono di eliminare il malware di basso livello durante la sequenza di avvio. La sicurezza basata sulla virtualizzazione è una modifica fondamentale dell'architettura del sistema operativo che aggiunge un nuovo limite di sicurezza. Device Guard e Credential Guard consentono rispettivamente di bloccare il codice non attendibile e proteggere le credenziali di dominio aziendale da furti e riutilizzo. Questa sezione ha anche illustrato brevemente l'importanza della gestione dei dispositivi e dell'applicazione di patch alle vulnerabilità. Tutte queste tecnologie possono essere usate per rafforzare e bloccare i dispositivi limitando al tempo stesso il rischio che gli utenti malintenzionati li compromettano.

Rilevare un dispositivo basato su Windows non integro

A partire da oggi, molte organizzazioni considerano i dispositivi conformi ai criteri aziendali solo dopo aver superato vari controlli che mostrano, ad esempio, che il sistema operativo è nello stato corretto, configurato correttamente e che la protezione della sicurezza è abilitata. Sfortunatamente, con i sistemi di oggi, questa forma di segnalazione non è del tutto affidabile perché il malware può falsificare un'istruzione software sull'integrità del sistema. Un rootkit o un exploit di basso livello simile può segnalare un falso stato integro agli strumenti di conformità tradizionali.

La sfida più grande con i rootkit è che possono essere inosservabili per il client. Poiché iniziano prima dell'antimalware e hanno privilegi a livello di sistema, possono mascherarsi completamente continuando ad accedere alle risorse di sistema. Di conseguenza, i computer tradizionali infettati da rootkit sembrano essere integri, anche con l'antimalware in esecuzione.

Come illustrato in precedenza, la funzionalità di attestazione dell'integrità di Windows usa il componente hardware TPM per registrare in modo sicuro una misurazione di ogni componente correlato all'avvio, inclusi firmware, kernel Windows e persino driver di avvio anticipato. Poiché l'attestazione dell'integrità usa le funzionalità di sicurezza basate su hardware di TPM, il log di tutti i componenti misurati di avvio rimane fuori dalla portata di qualsiasi malware.

Dopo che i dispositivi attestano uno stato di avvio attendibile, possono dimostrare di non eseguire malware di basso livello che potrebbero falsificare i controlli di conformità successivi. L'attestazione dell'integrità basata su TPM fornisce un ancoraggio affidabile dell'attendibilità per gli asset che contengono dati di valore elevato.

Qual è il concetto di integrità del dispositivo?

Per comprendere il concetto di integrità dei dispositivi, è importante conoscere le misure tradizionali adottate dai professionisti IT per prevenire la violazione del malware. Le tecnologie di controllo del malware sono altamente incentrate sulla prevenzione dell'installazione e della distribuzione.

Tuttavia, l'uso di tecnologie tradizionali di prevenzione del malware come antimalware o soluzioni di applicazione di patch comporta un nuovo set di problemi per i professionisti IT: la possibilità di monitorare e controllare la conformità dei dispositivi che accedono alle risorse dell'organizzazione.

La definizione di conformità dei dispositivi varia in base all'antimalware installato di un'organizzazione, alle impostazioni di configurazione del dispositivo, alla baseline di gestione delle patch e ad altri requisiti di sicurezza. Ma l'integrità del dispositivo fa parte dei criteri generali di conformità del dispositivo.

L'integrità del dispositivo non è binaria e dipende dall'implementazione della sicurezza dell'organizzazione. Il servizio di attestazione dell'integrità fornisce informazioni all'MDM in cui vengono abilitate le funzionalità di sicurezza durante l'avvio del dispositivo usando TPM hardware attendibile.

Ma l'attestazione dell'integrità fornisce solo informazioni, motivo per cui è necessaria una soluzione MDM per prendere e applicare una decisione.

Attestazione dell'integrità dei dispositivi remoti

In Windows, l'attestazione dell'integrità si riferisce a una funzionalità in cui i dati di avvio misurati generati durante il processo di avvio vengono inviati a un servizio di attestazione dell'integrità del dispositivo remoto gestito da Microsoft.

Questo approccio è il più sicuro disponibile per i dispositivi basati su Windows per rilevare quando le difese di sicurezza sono inattivi. Durante il processo di avvio, il log TCG e i valori dei pcr vengono inviati a un servizio cloud Microsoft remoto. I log vengono quindi controllati dal servizio di attestazione dell'integrità per determinare quali modifiche sono state apportate nel dispositivo.

Una relying party come un MDM può esaminare il report generato dal servizio di attestazione dell'integrità remota.

Nota

Per usare la funzionalità di attestazione dell'integrità di Windows, il dispositivo deve essere dotato di un TPM discreto o firmware. Non vi è alcuna restrizione per una particolare edizione di Windows.

Windows supporta gli scenari di attestazione dell'integrità consentendo alle applicazioni di accedere al provider di servizi di configurazione dell'attestazione dell'integrità sottostante in modo che le applicazioni possano richiedere un token di attestazione dell'integrità. La misurazione della sequenza di avvio può essere controllata in qualsiasi momento in locale da un agente antimalware o MDM.

L'attestazione dell'integrità dei dispositivi remoti combinata con un MDM fornisce un metodo basato su hardware per segnalare lo stato di sicurezza corrente e rilevare eventuali modifiche, senza dover considerare attendibile il software in esecuzione nel sistema.

Nel caso in cui nel dispositivo sia in esecuzione codice dannoso, è necessario l'uso di un server remoto. Se nel dispositivo è presente un rootkit, l'antimalware non è più affidabile e il suo comportamento può essere dirottato da un codice dannoso in esecuzione all'inizio della sequenza di avvio. Questo è ciò che rende importante l'uso di Secure Boot e Device Guard, per controllare quale codice viene caricato durante la sequenza di avvio.

Il software antimalware può cercare per determinare se la sequenza di avvio contiene eventuali segni di malware, ad esempio un rootkit. Può anche inviare il log TCG e i pcr a un server di attestazione dell'integrità remota per garantire una separazione tra il componente di misurazione e il componente di verifica.

L'attestazione dell'integrità registra le misurazioni in vari registri di configurazione della piattaforma TPM (PCR) e TCG durante il processo di avvio.

Quando si avvia un dispositivo dotato di TPM, viene eseguita una misurazione di diversi componenti. Questi componenti includono firmware, driver UEFI, microcodice CPU e anche tutti i driver Windows il cui tipo è Avvio. Le misurazioni non elaborate vengono archiviate nei registri pcr TPM, mentre i dettagli di tutti gli eventi (percorso eseguibile, certificazione dell'autorità e così via) sono disponibili nel log TCG.

Il processo di attestazione dell'integrità funziona come segue:

1. I componenti di avvio hardware vengono misurati.
2. Vengono misurati i componenti di avvio del sistema operativo.
3. Se Device Guard è abilitato, vengono misurati i criteri correnti di Device Guard.
4. Viene misurato il kernel Windows.
5. Il software antivirus viene avviato come primo driver in modalità kernel.
6. Vengono misurati i driver di avvio.
7. Il server MDM tramite l'agente MDM invia un comando di controllo dell'integrità usando il CSP di attestazione dell'integrità.
8. Le misurazioni di avvio vengono convalidate dal servizio di attestazione dell'integrità

Nota

Per impostazione predefinita, gli ultimi 100 log di avvio del sistema e tutti i log di ripresa associati vengono archiviati nella cartella %SystemRoot%\logs\measuredboot. Il numero di log conservati può essere impostato con il registro REG_DWORD valore PlatformLogRetention nella chiave HKLM\SYSTEM\CurrentControlSet\Services\TPM . Il valore 0 disabiliterà l'archiviazione dei log e il valore di 0xffffffff manterrà tutti i log.

Il processo seguente descrive come le misurazioni di avvio dell'integrità vengono inviate al servizio di attestazione dell'integrità:

1. Il client (un dispositivo basato su Windows con TPM) avvia la richiesta con il servizio di attestazione dell'integrità del dispositivo remoto. Poiché si prevede che il server di attestazione dell'integrità sia un servizio cloud Microsoft, l'URI è già pre-provisioning nel client.

2. Il client invia quindi il log TCG, i dati firmati AIK (valori PCR, contatore di avvio) e le informazioni sul certificato AIK.

3. Il servizio di attestazione di integrità del dispositivo remoto:

   1. Verifica che il certificato AIK sia emesso da una CA nota e attendibile e che il certificato sia valido e non revocato.
   2. Verifica che la firma nelle virgolette PCR sia corretta e coerente con il valore del log TCG.
   3. Analizza le proprietà nel log TCG.
   4. Genera il token di integrità del dispositivo che contiene le informazioni sull'integrità, le informazioni AIK e le informazioni sul contatore di avvio. Il token di integrità contiene anche un tempo di rilascio valido. Il token di integrità del dispositivo è crittografato e firmato, il che significa che le informazioni sono protette e accessibili solo per l'emissione del servizio di attestazione dell'integrità.

4. Il client archivia il BLOB crittografato per l'integrità nell'archivio locale. Il token di integrità del dispositivo contiene lo stato di integrità del dispositivo, un ID dispositivo (Windows AIK) e il contatore di avvio.

Componenti di attestazione dell'integrità del dispositivo

La soluzione di attestazione dell'integrità dei dispositivi include diversi componenti che sono TPM, Health Attestation CSP e Windows Health Attestation Service. Questi componenti sono descritti in questa sezione.

Trusted Platform Module

Questa sezione descrive in che modo vengono usati i pcr (che contengono dati di configurazione del sistema), la chiave di approvazione (EK) (che fungono da carta di identità per TPM), SRK (che protegge le chiavi) e IAK (che possono segnalare lo stato della piattaforma) per la creazione di report di attestazione dell'integrità.

In modo semplificato, il TPM è un componente passivo con risorse limitate. Può calcolare numeri casuali, chiavi RSA, decrittografare i dati brevi, archiviare gli hash acquisiti durante l'avvio del dispositivo.

Un TPM incorpora in un singolo componente:

• Generatore di chiavi RSA a 2048 bit
• Generatore di numeri casuali
• Memoria non volatile per l'archiviazione di chiavi EK, SRK e AIK
• Motore di crittografia per crittografare, decrittografare e firmare
• Memoria volatile per l'archiviazione delle chiavi PCR e RSA

Chiave di verifica dell'autenticità

Il TPM ha una chiave di crittografia univoca incorporata denominata chiave di verifica dell'autenticità. La chiave di verifica dell'autenticità TPM è una coppia di chiavi asimmetriche (dimensione RSA 2048 bit).

La chiave pubblica della chiave di verifica viene usata per inviare parametri sensibili in modo sicuro, ad esempio quando si prende possesso del TPM che contiene l'hash di definizione della password del proprietario. La chiave privata EK viene usata durante la creazione di chiavi secondarie come gli SDK.

La chiave di verifica dell'autenticità funge da carta d'identità per il TPM. Per altre informazioni, vedere Informazioni sulla chiave di verifica dell'autenticità di TPM.

La chiave di verifica è spesso accompagnata da uno o due certificati digitali:

• Un certificato viene prodotto dal produttore del TPM ed è denominato certificato di verifica dell'autenticità. Il certificato di verifica dell'autenticità viene usato per dimostrare l'autenticità del TPM (ad esempio, che si tratta di un TPM reale prodotto da un produttore di chip specifico) per processi, applicazioni o servizi cloud locali. Il certificato di approvazione viene creato durante la produzione o la prima volta che il TPM viene inizializzato comunicando con un servizio online.
• L'altro certificato viene prodotto dal generatore di piattaforme e viene chiamato certificato della piattaforma per indicare che un TPM specifico è integrato con un determinato dispositivo. Per alcuni dispositivi che usano TPM basato su firmware prodotto da Intel o Qualcomm, il certificato di approvazione viene creato quando il TPM viene inizializzato durante la Configurazione guidata di Windows.

Nota

Avvio protetto protegge la piattaforma fino al caricamento del kernel Windows. Vengono quindi rilevate protezioni come Avvio attendibile, Integrità del codice Hyper-V ed ELAM. Un dispositivo che usa Intel TPM o Qualcomm TPM ottiene online un certificato firmato dal produttore che ha creato il chip e quindi archivia il certificato firmato nell'archiviazione TPM. Affinché l'operazione abbia esito positivo, se si filtra l'accesso a Internet dai dispositivi client, è necessario autorizzare gli URL seguenti:

• Per il TPM del firmware Intel: https://ekop.intel.com/ekcertservice
• Per Qualcomm firmware TPM: https://ekcert.spserv.microsoft.com/

Chiavi di identità di attestazione

Poiché il certificato di approvazione è univoco per ogni dispositivo e non cambia, l'utilizzo di esso può presentare problemi di privacy perché è teoricamente possibile tenere traccia di un dispositivo specifico. Per evitare questo problema di privacy, Windows rilascia un ancoraggio di attestazione derivato in base al certificato di verifica dell'autenticità. Questa chiave intermedia, che può essere attestata a una chiave di verifica dell'autenticità, è la chiave di identità di attestazione (AIK) e il certificato corrispondente è denominato certificato AIK. Questo certificato AIK viene emesso da un servizio cloud Microsoft.

Nota

Prima che il dispositivo possa segnalare l'integrità usando le funzioni di attestazione TPM, è necessario effettuare il provisioning di un certificato AIK insieme a un servizio di terze parti come il servizio CA cloud Microsoft. Dopo il provisioning, è possibile usare la chiave privata AIK per segnalare la configurazione della piattaforma. Windows crea una firma sullo stato del log della piattaforma (e un valore del contatore monotono) a ogni avvio usando AIK.

AIK è una coppia di chiavi asimmetrica (pubblica/privata) usata come sostituto di EK come identità per il TPM a scopo di privacy. La parte privata di un AIK non viene mai rivelata o usata al di fuori del TPM e può essere usata solo all'interno del TPM per un set limitato di operazioni. Inoltre, può essere usato solo per la firma e solo per operazioni limitate definite da TPM.

Windows crea gli SDK protetti dal TPM, se disponibili, che sono chiavi di firma RSA a 2048 bit. Microsoft ospita un servizio cloud denominato Microsoft Cloud CA per stabilire in modo crittografico che comunica con un TPM reale e che il TPM possiede l'AIK presentato. Dopo che il servizio CA cloud Microsoft ha stabilito questi fatti, emetterà un certificato AIK al dispositivo basato su Windows.

Molti dispositivi esistenti che verranno aggiornati a Windows 10 non avranno un TPM o il TPM non conterrà un certificato di verifica dell'autenticità. Per supportare tali dispositivi, Windows 10 consente il rilascio di certificati AIK senza la presenza di un certificato di approvazione. Tali certificati AIK non vengono rilasciati da Microsoft Cloud CA. Questi certificati non sono attendibili come un certificato di approvazione che viene masterizzato nel dispositivo durante la produzione, ma fornirà compatibilità per scenari avanzati come Windows Hello for Business senza TPM.

Nel certificato AIK rilasciato viene aggiunto un OID speciale per attestare che il certificato di verifica è stato usato durante il processo di attestazione. Queste informazioni possono essere usate da una relying party per decidere se rifiutare i dispositivi che sono attestati usando certificati AIK senza un certificato di approvazione o accettarli. Un altro scenario può essere quello di non consentire l'accesso ad asset di valore elevato da dispositivi attestati da un certificato AIK non supportato da un certificato di approvazione.

Chiave radice di archiviazione

La chiave radice di archiviazione (SRK) è anche una coppia di chiavi asimmetrica (RSA con una lunghezza minima di 2048 bit). L'SRK ha un ruolo principale e viene usato per proteggere le chiavi TPM, in modo che queste chiavi non possano essere usate senza il TPM. La chiave SRK viene creata quando viene acquisita la proprietà del TPM.

Registri di configurazione della piattaforma

Il TPM contiene un set di registri progettati per fornire una rappresentazione crittografica del software e dello stato del sistema avviato. Questi registri sono denominati registri di configurazione della piattaforma (PCR).

La misurazione della sequenza di avvio è basata sul log PCR e TCG. Per stabilire una radice statica di attendibilità, all'avvio del dispositivo, il dispositivo deve essere in grado di misurare il codice del firmware prima dell'esecuzione. In questo caso, la radice principale dell'attendibilità per la misurazione (CRTM) viene eseguita dall'avvio, calcola l'hash del firmware, quindi la archivia espandendo il registro PCR[0] e trasferisce l'esecuzione al firmware.

I PCR sono impostati su zero quando viene avviata la piattaforma ed è il processo del firmware che avvia la piattaforma per misurare i componenti nella catena di avvio e registrare le misurazioni nelle richieste di aggiornamento automatico. In genere, i componenti di avvio accettano l'hash del componente successivo che deve essere eseguito e registrano le misurazioni nelle RICHIESTE. Il componente iniziale che avvia la catena di misurazione è implicitamente attendibile. Questo componente è il CRTM. I produttori di piattaforme devono avere un processo di aggiornamento sicuro per CRTM o non consentire gli aggiornamenti. I pcr registrano un hash cumulativo dei componenti misurati.

Il valore di un PCR è difficile da interpretare (è solo un valore hash), ma le piattaforme in genere mantengono un log con i dettagli di ciò che è stato misurato e i PCR si limitano a garantire che il log non sia stato manomesso. I log vengono definiti log TCG. Ogni volta che viene estesa una richiesta PCR del registro, viene aggiunta una voce al log TCG. Pertanto, durante il processo di avvio, viene creata una traccia del codice eseguibile e dei dati di configurazione nel log TCG.

Provisioning TPM

Affinché il TPM di un dispositivo basato su Windows sia utilizzabile, è necessario eseguirne prima il provisioning. Il processo di provisioning è diverso in base alle versioni di TPM, ma, in caso di esito positivo, il TPM è utilizzabile e i dati di autorizzazione del proprietario (ownerAuth) per il TPM vengono archiviati in locale nel Registro di sistema.

Quando viene effettuato il provisioning del TPM, Windows tenterà prima di tutto di determinare i valori EK e ownerAuth archiviati localmente esaminando nel Registro di sistema il percorso seguente: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement

Durante il processo di provisioning, potrebbe essere necessario riavviare il dispositivo.

Il cmdlet Di PowerShell Get-TpmEndorsementKeyInfo può essere usato con privilegi amministrativi per ottenere informazioni sulla chiave di approvazione e sui certificati del TPM.

Se la proprietà TPM non è nota, ma il valore EK esiste, la libreria client eseguirà il provisioning del TPM e archivierà il valore ownerAuth risultante nel Registro di sistema se il criterio lo consente archivierà la parte pubblica SRK nel percorso seguente: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Amministrazione\SRKPub

Come parte del processo di provisioning, Windows creerà un AIK con il TPM. Quando viene eseguita questa operazione, la parte pubblica AIK risultante viene archiviata nel Registro di sistema nel percorso seguente: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\WindowsAIKPub

Nota

Per effettuare il provisioning dei certificati AIK e filtrare l'accesso a Internet, è necessario autorizzare l'URL con caratteri jolly seguente: https://\*.microsoftaik.azure.net

CSP di attestazione dell'integrità di Windows

Windows contiene un provider di servizi di configurazione (CSP) specializzato per l'interazione con la funzionalità di attestazione dell'integrità. Un provider di servizi di configurazione è un componente che si collega al client MDM di Windows e fornisce un protocollo pubblicato per la configurazione delle impostazioni e la gestione dei dispositivi basati su Windows da parte dei server MDM. Il protocollo di gestione è rappresentato come struttura ad albero che può essere specificata come URI con funzioni da eseguire sugli URI, ad esempio "get", "set", "delete" e così via.

L'elenco seguente è quello delle funzioni eseguite dal provider di servizi di configurazione di attestazione dell'integrità di Windows:

• Raccoglie i dati usati per verificare lo stato di integrità di un dispositivo
• Inoltra i dati al servizio di attestazione dell'integrità
• Effettua il provisioning del certificato di attestazione dell'integrità ricevuto dal servizio di attestazione dell'integrità
• Su richiesta, inoltra il certificato di attestazione integrità (ricevuto dal servizio di attestazione integrità) e le informazioni di runtime correlate al server MDM per la verifica

Durante una sessione di attestazione dell'integrità, il provider di servizi di attestazione dell'integrità inoltra i log TCG e i valori dei PCR misurati durante l'avvio, usando un canale di comunicazione sicuro al servizio di attestazione dell'integrità.

Quando un server MDM verifica che un dispositivo abbia attestato il servizio di attestazione dell'integrità, gli verrà assegnato un set di istruzioni e attestazioni sul modo in cui il dispositivo è stato avviato, con la garanzia che il dispositivo non sia stato riavviato tra il momento in cui ha attestato l'integrità e l'ora in cui il server MDM lo ha convalidato.

Servizio di attestazione integrità Windows

Il ruolo del servizio di attestazione dell'integrità di Windows consiste essenzialmente nel valutare un set di dati di integrità (valori di log TCG e PCR), eseguire una serie di rilevamenti (basati sui dati di integrità disponibili) e generare BLOB di integrità crittografati o generare report ai server MDM.

Nota

Sia il dispositivo che i server MDM devono avere accesso a has.spserv.microsoft.com usando il protocollo TCP sulla porta 443 (HTTPS).

La verifica della validità di un'attestazione TPM e del log associato comporta diversi passaggi:

1. In primo luogo, il server deve verificare che i report siano firmati da AIKs attendibili. Questa verifica può essere eseguita controllando che la parte pubblica di AIK sia elencata in un database di asset o che sia stato verificato un certificato.
2. Dopo aver controllato la chiave, è necessario verificare l'attestazione firmata (una struttura virgolette) per verificare se si tratta di una firma valida sui valori PCR.
3. Successivamente i log devono essere controllati per assicurarsi che corrispondano ai valori di PCR segnalati.
4. Infine, i log stessi devono essere esaminati da una soluzione MDM per verificare se rappresentano configurazioni di sicurezza note o valide. Ad esempio, un semplice controllo potrebbe essere quello di verificare se i componenti del sistema operativo iniziali misurati sono noti per essere buoni, che il driver ELAM è come previsto e che il file dei criteri del driver ELAM è aggiornato. Se tutti questi controlli hanno esito positivo, è possibile eseguire un'istruzione di attestazione che in un secondo momento può essere usata per determinare se al client deve essere concesso o meno l'accesso a una risorsa.

Il servizio di attestazione dell'integrità fornisce le informazioni seguenti a una soluzione MDM sull'integrità del dispositivo:

• Abilitazione dell'avvio protetto
• Abilitazione del debug di avvio e kernel
• Abilitazione di BitLocker
• VSM abilitato
• Misurazione dei criteri di integrità del codice device guard firmato o non firmato
• ELAM caricato
• Avvio in modalità provvisoria, abilitazione dep, abilitazione della firma di test
• È stato effettuato il provisioning del TPM del dispositivo con un certificato di approvazione attendibile

Per la completezza delle misurazioni, vedere Health Attestation CSP .For completeness of the measurements, see Health Attestation CSP.For completeness of the measurements, see Health Attestation CSP.

L'elenco seguente mostra alcuni elementi chiave che possono essere restituiti a MDM per i dispositivi basati su Windows:

• Misura PCR0
• Avvio protetto abilitato
• Corrispondenze previste per il database di avvio protetto
• Dbx di avvio protetto è aggiornato
• Corrisponde al GUID dei criteri di avvio protetto previsto
• BitLocker abilitato
• Sicurezza basata su virtualizzazione abilitata
• ELAM caricato
• La versione dell'integrità del codice è aggiornata
• Sono previste corrispondenze hash dei criteri di integrità del codice

Usare MDM e il servizio di attestazione dell'integrità

Per rendere rilevante l'integrità del dispositivo, la soluzione MDM valuta il report sull'integrità del dispositivo ed è configurata in base ai requisiti di integrità dei dispositivi dell'organizzazione.

Una soluzione che usa MDM e il servizio di attestazione dell'integrità è costituita da tre parti principali:

1. Un dispositivo con attestazione dell'integrità abilitata. Questa abilitazione verrà eseguita come parte della registrazione con un provider MDM (l'attestazione dell'integrità verrà disabilitata per impostazione predefinita).

2. Dopo l'abilitazione di questo servizio e ogni avvio successivo, il dispositivo invierà le misurazioni dell'integrità al servizio di attestazione integrità ospitato da Microsoft e riceverà un BLOB di attestazione dell'integrità in cambio.

3. In qualsiasi momento dopo questo ciclo, un server MDM può richiedere il BLOB di attestazione dell'integrità al dispositivo e chiedere al servizio di attestazione dell'integrità di decrittografare il contenuto e verificare che sia stato attestato.

   

L'interazione tra un dispositivo basato su Windows, il servizio di attestazione dell'integrità e MDM può essere eseguita come segue:

1. Il client avvia una sessione con il server MDM. L'URI per il server MDM fa parte dell'app client che avvia la richiesta. Il server MDM in questo momento potrebbe richiedere i dati di attestazione dell'integrità usando l'URI CSP appropriato.

2. Il server MDM specifica un nonce insieme alla richiesta.

3. Il client invia quindi il nonce tra virgolette AIK + il contatore di avvio e le informazioni sul BLOB di integrità. Questo BLOB di integrità viene crittografato con una chiave pubblica del servizio di attestazione dell'integrità che solo il servizio di attestazione dell'integrità può decrittografare.

4. Il server MDM:

   1. Verifica che il nonce sia come previsto.
   2. Passa i dati tra virgolette, il blob di integrità nonce e il BLOB di integrità crittografato al server del servizio di attestazione dell'integrità.

5. Servizio di attestazione dell'integrità:

   1. Decrittografa il BLOB di integrità.
   2. Verifica che il contatore di avvio tra virgolette sia corretto usando AIK nel BLOB di integrità e corrisponda al valore nel BLOB di integrità.
   3. Verifica che il nonce corrisponda alla virgolette e a quella passata da MDM.
   4. Poiché il contatore di avvio e il nonce sono indicati con AIK dal BLOB di integrità, dimostra anche che il dispositivo è lo stesso di quello per cui è stato generato il BLOB di integrità.
   5. Invia i dati al server MDM, inclusi parametri di integrità, aggiornamento e così via.

Nota

Il server MDM (relying party) non esegue mai la convalida dell'offerta o del contatore di avvio stesso. Ottiene i dati tra virgolette e il BLOB di integrità (crittografato) e invia i dati al servizio di attestazione dell'integrità per la convalida. In questo modo, L'AIK non è mai visibile al MDM, che risolve quindi i problemi di privacy.

L'impostazione dei requisiti per la conformità dei dispositivi è il primo passaggio per garantire che i dispositivi registrati che non soddisfano i requisiti di integrità e conformità vengano rilevati, monitorati e che vengano applicate azioni dalla soluzione MDM.

I dispositivi che tentano di connettersi alle risorse devono avere l'integrità valutata in modo che i dispositivi non integri e non conformi possano essere rilevati e segnalati. Per essere completamente efficiente, una soluzione di sicurezza end-to-end deve imporre una conseguenza per i dispositivi non integri, ad esempio rifiutando l'accesso ad asset di valore elevato. Tale conseguenza per un dispositivo non integro è lo scopo del controllo di accesso condizionale, descritto in dettaglio nella sezione successiva.

Controllare la sicurezza di un dispositivo basato su Windows prima che venga concesso l'accesso

La tecnologia di controllo di accesso di oggi, nella maggior parte dei casi, si concentra sulla garanzia che le persone giuste ottengano l'accesso alle risorse corrette. Se gli utenti possono eseguire l'autenticazione, ottengono l'accesso alle risorse usando un dispositivo di cui il personale IT e i sistemi dell'organizzazione conoscono poco. Forse c'è qualche controllo come assicurarsi che un dispositivo sia crittografato prima di concedere l'accesso alla posta elettronica, ma cosa succede se il dispositivo è infettato da malware?

Il processo di attestazione dell'integrità del dispositivo remoto usa i dati di avvio misurati per verificare lo stato di integrità del dispositivo. L'integrità del dispositivo è quindi disponibile per una soluzione MDM come Intune.

Nota

Per le informazioni più recenti sul supporto delle funzionalità di Intune e Windows, vedere Novità di Microsoft Intune.

La figura seguente mostra come si prevede che il servizio di attestazione dell'integrità funzioni con il servizio MDM Intune basato sul cloud di Microsoft.

Una soluzione MDM può quindi usare le istruzioni sullo stato di integrità e portarle al livello successivo tramite l'accoppiamento con i criteri client che consentiranno di concedere l'accesso condizionale in base alla capacità del dispositivo di dimostrare che è privo di malware, il sistema antimalware è funzionale e aggiornato, il firewall è in esecuzione e lo stato di patch dei dispositivi è conforme.

Infine, le risorse possono essere protette negando l'accesso agli endpoint che non sono in grado di dimostrare che sono integri. Questa funzionalità è molto necessaria per i dispositivi BYOD che devono accedere alle risorse dell'organizzazione.

Supporto predefinito di MDM in Windows

Windows ha un client MDM fornito come parte del sistema operativo. Questo client MDM consente ai server MDM di gestire i dispositivi basati su Windows senza richiedere un agente separato.

Supporto del server MDM non Microsoft

I server MDM non Microsoft possono gestire Windows usando il protocollo MDM. Il client di gestione predefinito è in grado di comunicare con un server compatibile che supporta il protocollo OMA-DM per eseguire attività di gestione aziendali. Per altre informazioni, vedere integrazione Microsoft Entra con MDM.

Nota

I server MDM non devono creare o scaricare un client per gestire Windows. Per altre informazioni, vedere Gestione dei dispositivi mobili.

Il server MDM di terze parti avrà la stessa esperienza utente di prima parte coerente per la registrazione, che offre anche semplicità per gli utenti di Windows.

Gestione di Windows Defender da MDM di terze parti

Questa infrastruttura di gestione consente ai professionisti IT di usare prodotti con supporto per MDM, ad esempio Intune, per gestire l'attestazione dell'integrità, Device Guard o Windows Defender nei dispositivi basati su Windows, inclusi i BYOD non aggiunti al dominio. I professionisti IT saranno in grado di gestire e configurare tutte le azioni e le impostazioni che hanno familiarità con la personalizzazione usando Intune con Intune Endpoint Protection nei sistemi operativi di livello inferiore. Gli amministratori che attualmente gestiscono solo dispositivi aggiunti a un dominio tramite Criteri di gruppo troveranno facile passare alla gestione dei dispositivi basati su Windows usando MDM perché molte delle impostazioni e delle azioni sono condivise tra entrambi i meccanismi.

Per altre informazioni su come gestire le impostazioni di sicurezza e di sistema di Windows con una soluzione MDM, vedere Impostazioni URI personalizzate per i dispositivi Windows.

Controllo dell'accesso condizionale

Nella maggior parte delle piattaforme, la registrazione del dispositivo Microsoft Entra viene eseguita automaticamente durante la registrazione. Gli stati del dispositivo vengono scritti dalla soluzione MDM in Microsoft Entra ID e quindi letti da Office 365 (o da qualsiasi app di Windows autorizzata che interagisce con Microsoft Entra ID) la volta successiva che il client tenta di accedere a un carico di lavoro compatibile con Office 365.

Se il dispositivo non è registrato, l'utente riceverà un messaggio con istruzioni su come registrarsi (noto anche come registrazione). Se il dispositivo non è conforme, l'utente riceverà un messaggio diverso che li reindirizza al portale Web MDM in cui può ottenere altre informazioni sul problema di conformità e su come risolverlo.

Microsoft Entra ID autentica l'utente e il dispositivo, MDM gestisce i criteri di conformità e accesso condizionale e il servizio di attestazione integrità segnala l'integrità del dispositivo in modo attestato.

Office 365 controllo di accesso condizionale

Microsoft Entra ID applica i criteri di accesso condizionale per proteggere l'accesso ai servizi Office 365. Un amministratore tenant può creare criteri di accesso condizionale che impediscono a un utente in un dispositivo non conforme di accedere a un servizio Office 365. L'utente deve essere conforme ai criteri del dispositivo dell'azienda prima di concedere l'accesso al servizio. In alternativa, l'amministratore può anche creare un criterio che richiede agli utenti di registrare solo i propri dispositivi per ottenere l'accesso a un servizio Office 365. I criteri possono essere applicati a tutti gli utenti di un'organizzazione o limitati a pochi gruppi di destinazione e migliorati nel tempo per includere più gruppi di destinazione.

Quando un utente richiede l'accesso a un servizio Office 365 da una piattaforma di dispositivi supportata, Microsoft Entra autentica l'utente e il dispositivo da cui l'utente avvia la richiesta e concede l'accesso al servizio solo quando l'utente è conforme al set di criteri per il servizio. Agli utenti che non hanno registrato il dispositivo vengono fornite istruzioni di correzione su come registrare e diventare conformi per accedere ai servizi di Office 365 aziendali.

Quando un utente si registra, il dispositivo viene registrato con Microsoft Entra ID e registrato con una soluzione MDM compatibile, ad esempio Intune.

Nota

Microsoft collabora con isv MDM di terze parti per supportare la registrazione MDM automatizzata e i controlli di accesso basati su criteri. I passaggi per attivare la registrazione MDM automatica con Microsoft Entra ID e Intune sono illustrati nel post di blog Windows, Microsoft Entra ID And Microsoft Intune: Automatic MDM Enrollment Powered By The Cloud!.

Quando un utente registra correttamente un dispositivo, il dispositivo diventa attendibile. Microsoft Entra ID fornisce l'accesso Single Sign-On per accedere alle applicazioni aziendali e applica i criteri di accesso condizionale per concedere l'accesso a un servizio non solo la prima volta che l'utente richiede l'accesso, ma ogni volta che l'utente richiede di rinnovare l'accesso.

All'utente verrà negato l'accesso ai servizi quando vengono modificate le credenziali di accesso, un dispositivo viene smarrito o rubato o i criteri di conformità non vengono soddisfatti al momento della richiesta di rinnovo.

A seconda del tipo di applicazione di posta elettronica usata dai dipendenti per accedere a Exchange Online, il percorso per stabilire l'accesso protetto alla posta elettronica può essere leggermente diverso. Tuttavia, i componenti chiave: Microsoft Entra ID, Office 365/Exchange Online e Intune sono gli stessi. Anche l'esperienza IT e l'esperienza dell'utente finale sono simili.

I client che tentano di accedere a Office 365 verranno valutati per le proprietà seguenti:

• Il dispositivo è gestito da un MDM?
• Il dispositivo è registrato con Microsoft Entra ID?
• Il dispositivo è conforme?

Per ottenere uno stato conforme, il dispositivo basato su Windows deve:

• Eseguire la registrazione con una soluzione MDM.
• Eseguire la registrazione con Microsoft Entra ID.
• Essere conformi ai criteri del dispositivo impostati dalla soluzione MDM.

Nota

Al momento, i criteri di accesso condizionale vengono applicati in modo selettivo agli utenti nei dispositivi iOS e Android. Per altre informazioni, vedere il post di blog Microsoft Entra ID, Microsoft Intune e Windows - Uso del cloud per modernizzare la mobilità aziendale.

Controllo dell'accesso condizionale delle app cloud e locali

Il controllo di accesso condizionale è un potente motore di valutazione dei criteri integrato in Microsoft Entra ID. Offre ai professionisti IT un modo semplice per creare regole di accesso oltre Office 365 che valutano il contesto dell'accesso di un utente per prendere decisioni in tempo reale sulle applicazioni a cui devono essere autorizzati ad accedere.

I professionisti IT possono configurare criteri di controllo di accesso condizionale per le applicazioni SaaS cloud protette da applicazioni Microsoft Entra ID e anche locali. Le regole di accesso in Microsoft Entra ID usano il motore di accesso condizionale per controllare lo stato di integrità e conformità dei dispositivi segnalato da una soluzione MDM compatibile come Intune per determinare se consentire l'accesso.

Per altre informazioni sull'accesso condizionale, vedere Access Preview condizionale di Azure per le app SaaS.

Nota

Il controllo di accesso condizionale è una funzionalità Microsoft Entra ID P1 o P2 disponibile anche con EMS. Se non si ha una sottoscrizione di Microsoft Entra ID P1 o P2, è possibile ottenere una versione di valutazione dal sito di Microsoft Azure.

Per le applicazioni locali sono disponibili due opzioni per abilitare il controllo di accesso condizionale in base allo stato di conformità di un dispositivo:

• Per le applicazioni locali pubblicate tramite il proxy dell'applicazione Microsoft Entra, è possibile configurare i criteri di controllo di accesso condizionale come per le applicazioni cloud. Per altre informazioni, vedere Uso di Microsoft Entra proxy di applicazione per pubblicare app locali per utenti remoti.
• Inoltre, Microsoft Entra Connect sincronizza le informazioni di conformità dei dispositivi da Microsoft Entra ID ad ACTIVE Directory locale. ADFS in Windows Server 2016 supporterà il controllo di accesso condizionale in base allo stato di conformità di un dispositivo. I professionisti IT configureranno i criteri di controllo di accesso condizionale in ADFS che usano lo stato di conformità del dispositivo segnalato da una soluzione MDM compatibile per proteggere le applicazioni locali.

Il processo seguente descrive come funziona l'accesso condizionale Microsoft Entra:

1. L'utente si è già registrato con MDM tramite Workplace Access/Aggiunta ad Azure AD, che registra il dispositivo con Microsoft Entra ID.
2. Quando il dispositivo viene avviato o ripreso dall'ibernazione, viene attivata un'attività "Tpm-HASCertRetr" per richiedere in background un BLOB di attestazione dell'integrità. Il dispositivo invia le misurazioni di avvio TPM al servizio di attestazione dell'integrità.
3. Il servizio di attestazione dell'integrità convalida lo stato del dispositivo e invia un BLOB crittografato al dispositivo in base allo stato di integrità con i dettagli sui controlli non riusciti (se presenti).
4. L'utente accede e l'agente MDM contatta il server Intune/MDM.
5. Se disponibile, il server MDM esegue il push di nuovi criteri ed esegue query sullo stato del BLOB di integrità e su altri stati di inventario.
6. Il dispositivo invia un BLOB di attestazione dell'integrità acquisito in precedenza e anche il valore dell'altro inventario dello stato richiesto dal server Intune/MDM.
7. Intune/server MDM invia il BLOB di attestazione dell'integrità al servizio di attestazione dell'integrità da convalidare.
8. Il servizio di attestazione dell'integrità verifica che il dispositivo che ha inviato il BLOB di attestazione dell'integrità sia integro e restituisce questo risultato al server Intune/MDM.
9. Intune/server MDM valuta la conformità in base alla conformità e allo stato di attestazione dell'inventario/integrità sottoposto a query dal dispositivo.
10. Intune/MDM server aggiorna lo stato di conformità per l'oggetto dispositivo in Microsoft Entra ID.
11. L'utente apre l'app e tenta di accedere a un asset gestito aziendale.
12. Accesso controllato dall'attestazione di conformità in Microsoft Entra ID.
13. Se il dispositivo è conforme e l'utente è autorizzato, viene generato un token di accesso.
14. L'utente può accedere all'asset gestito aziendale.

Per altre informazioni sull'aggiunta Microsoft Entra, vedere Microsoft Entra ID & Windows: Better Together for Work or School, un white paper.

Il controllo dell'accesso condizionale è un argomento che molte organizzazioni e professionisti IT potrebbero non conoscere e dovrebbero. I diversi attributi che descrivono un utente, un dispositivo, la conformità e il contesto di accesso sono potenti se usati con un motore di accesso condizionale. Il controllo dell'accesso condizionale è un passaggio essenziale che consente alle organizzazioni di proteggere l'ambiente.

Asporti e riepilogo

L'elenco seguente contiene elementi importanti per migliorare il comportamento di sicurezza di qualsiasi organizzazione. Tuttavia, i pochi takeaway presentati in questa sezione non devono essere interpretati come un elenco completo delle procedure consigliate per la sicurezza.

• Comprendere che nessuna soluzione è sicura al 100%

  Se determinati avversari con finalità dannose ottengono l'accesso fisico al dispositivo, potrebbero infine sfondare i livelli di sicurezza e controllarlo.

• Usare l'attestazione dell'integrità con una soluzione MDM

  I dispositivi che tentano di connettersi ad asset di valore elevato devono avere la valutazione dell'integrità in modo che i dispositivi non integri e non conformi possano essere rilevati, segnalati ed eventualmente bloccati.

• Usare Credential Guard

  Credential Guard è una funzionalità che consente di proteggere notevolmente le credenziali di dominio aziendale da attacchi pass-the-hash.

• Usa Device Guard

  Device Guard è un vero progresso nella sicurezza e un modo efficace per proteggere dal malware. La funzionalità Device Guard in Windows blocca le app non attendibili (app non autorizzate dall'organizzazione).

• Firmare i criteri di Device Guard

  I criteri di Device Guard firmati consentono di proteggere da un utente con privilegi di amministratore che tenta di eliminare i criteri correnti. Quando un criterio viene firmato, l'unico modo per modificare Device Guard in un secondo momento consiste nel fornire una nuova versione del criterio firmato dallo stesso firmatario o da un firmatario specificato come parte dei criteri di Device Guard.

• Usare la sicurezza basata sulla virtualizzazione

  Quando l'integrità del codice in modalità kernel è protetta dalla sicurezza basata sulla virtualizzazione, le regole di integrità del codice vengono comunque applicate anche se una vulnerabilità consente l'accesso non autorizzato alla memoria in modalità kernel. Tenere presente che i dispositivi Device Guard che eseguono l'integrità del codice kernel con sicurezza basata sulla virtualizzazione devono avere driver compatibili.

• Iniziare a distribuire Device Guard con la modalità di controllo

  Distribuire i criteri di Device Guard in computer e dispositivi di destinazione in modalità di controllo. Monitorare il registro eventi di integrità del codice che indica che un programma o un driver sarebbe stato bloccato se Device Guard fosse stato configurato in modalità di imposizione. Modificare le regole di Device Guard fino a raggiungere un livello elevato di attendibilità. Al termine della fase di test, i criteri di Device Guard possono essere passati alla modalità di imposizione.

• Creare un computer di riferimento isolato durante la distribuzione di Device Guard

  Poiché la rete aziendale può contenere malware, è consigliabile iniziare a configurare un ambiente di riferimento isolato dalla rete aziendale principale. Successivamente, è possibile creare un criterio di integrità del codice che includa le applicazioni attendibili che si desidera eseguire nei dispositivi protetti.

• Usare AppLocker quando è opportuno

  Anche se AppLocker non è considerata una nuova funzionalità di Device Guard, integra la funzionalità Device Guard per alcuni scenari come la possibilità di negare un'applicazione di Windows universale specifica per un utente specifico o un gruppo di utenti.

• Bloccare firmware e configurazione

  Dopo l'installazione di Windows, bloccare l'accesso alle opzioni di avvio del firmware. Questo blocco impedisce a un utente con accesso fisico di modificare le impostazioni UEFI, disabilitare l'avvio protetto o avviare altri sistemi operativi. Inoltre, per proteggere da un amministratore che tenta di disabilitare Device Guard, aggiungere una regola nel criterio device guard corrente che negherà e bloccherà l'esecuzione dello strumento C:\Windows\System32\SecConfig.efi .

L'attestazione dell'integrità è una funzionalità chiave di Windows che include componenti client e cloud per controllare l'accesso agli asset di valore elevato in base a un utente e all'identità del dispositivo e alla conformità ai criteri di governance aziendale. Le organizzazioni possono scegliere di rilevare e segnalare dispositivi non integri o di configurare le regole di imposizione dell'integrità in base alle proprie esigenze. L'attestazione dell'integrità fornisce un modello di sicurezza end-to-end e punti di integrazione, che fornitori e sviluppatori di software possono usare per compilare e integrare una soluzione personalizzata.

Argomenti correlati

• Proteggere le credenziali di dominio derivate con Credential Guard
• Guida alla distribuzione di Device Guard
• Panoramica della tecnologia Trusted Platform Module