Guida alla distribuzione di Device Guard

Articolo
04/01/2016

Microsoft Device Guard è un set di funzionalità hardware e software per la protezione avanzata dell'integrità del sistema, che rivoluziona la sicurezza del sistema operativo Windows. Windows 10 utilizza Device Guard, l'integrità del codice e funzionalità hardware avanzate, tra cui le estensioni di virtualizzazione della CPU, Trusted Platform Module e SLAT (Second-Level Address Translation), per offrire agli utenti una sicurezza moderna e completa. Questa guida illustra le singole funzionalità di Device Guard e il modo in cui pianificarne l'uso, configurarle e distribuirle.

Introduzione a Device Guard

Oggi le minacce per la sicurezza sono più distruttive che mai. Gli attacchi informatici moderni sono finalizzati alla generazione di ricavi, al furto di proprietà intellettuale e alla riduzione del livello delle prestazioni del sistema bersaglio, che si traducono in perdite finanziarie. Molti pirati informatici sono sponsorizzati da stati-nazione con motivazioni ignote e grandi budget dedicati al terrorismo informatico. Queste minacce possono penetrare in un'azienda anche attraverso un semplice messaggio di posta elettronica, danneggiandone per sempre la reputazione in termini di protezione delle risorse software interne e con un impatto finanziario devastante. Windows 10 introduce diverse nuove funzionalità di sicurezza che contribuiscono a contrastare un'elevata percentuale delle minacce note di oggi.

Si stima che ogni giorno vengano individuate più di 300.000 nuove varianti di malware. Sfortunatamente, le aziende usano ancora un metodo antiquato per individuare il software nocivo. Di fatto, i PC attuali considerano attendibile tutto ciò che viene eseguito finché le firme antimalware non determinano che esiste un rischio. A questo punto il software antimalware tenta di pulire il PC, spesso dopo che gli effetti del software dannoso sono già stati notati. Il sistema basato sulla firma è incentrato sulla reazione a un'infezione e sulla futura difesa da quella specifica infezione. In questo modello, il sistema che gestisce il rilevamento del malware si basa sull'individuazione di software dannoso e sul successivo invio al client di una firma per la correzione, il che implica che prima deve essere stato infettato un computer. Il tempo trascorso tra il rilevamento del malware e l'emissione di una firma per il client può fare la differenza tra mantenere la sicurezza e perdere dati.

Oltre alle soluzioni antimalware, esistono tecnologie che prevedono l'inserimento in un elenco di elementi consentiti, tra cui AppLocker. Queste tecnologie eseguono regole per le singole istanze o regole generali di assenso o negazione per le applicazioni in esecuzione. Anche se questo approccio è maggiormente preventivo rispetto al rilevamento basato sulla firma, richiede notevoli attività di manutenzione. In Windows 10 queste applicazioni sono più efficaci quando vengono distribuite insieme a Microsoft Device Guard.

Device Guard rappresenta una rottura rispetto al modello attuale che prevede prima il rilevamento e poi il blocco, permettendo solo l'esecuzione delle applicazioni attendibili. Questa metodologia è coerente con l'efficace strategia di prevenzione per la sicurezza dei cellulari. Con Device Guard, Microsoft ha cambiato le modalità di gestione delle applicazioni non attendibili da parte del sistema operativo Windows, rendendo le difese molto difficili da penetrare per il malware. Questo nuovo modello basato sulla prevenzione anziché sul rilevamento fornisce ai client Windows la sicurezza necessaria per le minacce moderne e, non appena implementato, rende completamente obsoleta la maggior parte delle attuali minacce.

Le funzionalità di Device Guard rivoluzionano la sicurezza del sistema operativo Windows sfruttando le nuove opzioni di sicurezza basata su virtualizzazione e il modello dei sistemi operativi per dispositivi mobili, che non considera attendibile alcun elemento. In questo modo, rafforza notevolmente lo scudo difensivo. Usando criteri di integrità del codice configurabili, le organizzazioni possono scegliere con precisione le applicazioni di cui consentire l'esecuzione nell'ambiente. L'integrità del codice configurabile non è limitata alle applicazioni di Windows Store e può essere usata con le applicazioni Win32 esistenti, firmate o non firmate, senza bisogno di ricreare il pacchetto dell'applicazione. In più, l'integrità del codice configurabile può essere distribuita come singola funzionalità nelle organizzazioni che non possiedono l'hardware richiesto per Device Guard. Oltre all'integrità del codice, Windows 10 sfrutta funzionalità hardware avanzate, tra cui estensioni di virtualizzazione della CPU, unità di gestione della memoria di input/output (IOMMU), Trusted Platform Module (TPM) e SLAT (Second-Level Address Translation), per offrire agli utenti una sicurezza moderna e completa. Device Guard, insieme all'integrità del codice configurabile e a Credential Guard, sarà tra le distribuzioni di sicurezza lato client più efficaci che un'organizzazione possa implementare oggi. In questa guida scoprirai le singole funzionalità di Device Guard e il modo in cui pianificarne l'uso, configurarle e distribuirle. Device Guard con l'integrità del codice configurabile è inteso per la distribuzione insieme ad altre funzionalità di Windows per la riduzione dei rischi, come Credential Guard e AppLocker.

Panoramica di Device Guard

Device Guard è un set di funzionalità hardware e software per la protezione avanzata dell'integrità del sistema. Queste funzionalità rivoluzionano la sicurezza del sistema operativo Windows sfruttando le nuove opzioni di sicurezza basata su virtualizzazione e il modello dei sistemi operativi per dispositivi mobili, che non considera attendibile alcun elemento. Una funzionalità fondamentale di questo modello è l'integrità del codice configurabile, che permette alle organizzazioni di scegliere il software o l'autore di software attendibile a cui consentire l'esecuzione di codice nei propri computer client, esattamente ciò che ha decretato il successo della sicurezza per i telefoni cellulari. In più, Device Guard offre alle organizzazioni un modo per firmare le applicazioni line-of-business (LOB) esistenti, in modo da considerare attendibile il proprio codice senza bisogno di ricreare il pacchetto dell'applicazione. Questo stesso metodo di firma offre alle organizzazioni anche uno strumento per considerare attendibili singole applicazioni di terze parti. Device Guard, insieme all'integrità del codice configurabile, a Credential Guard e ad AppLocker, rappresenta la linea di difesa più completa che qualunque prodotto Microsoft abbia mai offerto a un client Windows.

Alla base di queste nuove offerte per la sicurezza dei client ci sono funzionalità hardware avanzate, come le estensioni di virtualizzazione della CPU, le unità IOMMU e SLAT. Integrando ulteriormente queste funzionalità hardware nel sistema operativo principale, Windows 10 le sfrutta in nuovi modi. Ad esempio, la stessa tecnologia hypervisor di tipo 1 usata per l'esecuzione di macchine virtuali in Microsoft Hyper-V viene usata per isolare i servizi di Windows di base in un contenitore protetto, basato sulla virtualizzazione. Questo è solo un esempio di come Windows 10 integra funzionalità hardware avanzate più in profondità nel sistema operativo, per offrire agli utenti una sicurezza moderna e completa. Queste funzionalità hardware sono ora disponibili nei PC destinati ai mercati consumer ed enterprise e sono illustrate in dettaglio nella sezione Considerazioni sull'hardware.

A parte queste nuove funzionalità, alcuni componenti di Device Guard sono strumenti o tecnologie esistenti che sono state incluse in questa offerta di sicurezza strategica per offrire ai clienti il sistema operativo Windows più sicuro possibile. Device Guard è considerato un set di funzionalità di sicurezza client da usare in combinazione con le altre caratteristiche di mitigazione dei rischi disponibili nel sistema operativo Windows, alcune delle quali sono menzionate in questa guida. Oltre a offrire una panoramica di ogni funzionalità, questa guida ne illustra la configurazione e la distribuzione.

Integrità del codice configurabile

Il sistema operativo Windows prevede due modalità operative: modalità utente e modalità kernel. La base del sistema operativo viene eseguita in modalità kernel, che è quella in cui Windows interagisce direttamente con le risorse hardware. La modalità utente è principalmente responsabile dell'esecuzione delle applicazioni e della trasmissione di informazioni relative alle richieste di risorse hardware da e verso la modalità kernel. Ad esempio, quando un'applicazione in esecuzione in modalità utente ha bisogno di memoria aggiuntiva, il processo in modalità utente deve richiedere le risorse dalla modalità kernel, non direttamente dalla RAM.

L'integrità del codice è il componente del sistema operativo che verifica che il codice eseguito da Windows sia attendibile e sicuro. Come il sistema operativo, l'integrità del codice di Windows prevede due componenti principali: integrità del codice in modalità kernel e integrità del codice in modalità utente. L'integrità del codice in modalità kernel è stata usata nelle versioni recenti del sistema operativo Windows per proteggere la modalità kernel dall'esecuzione di driver non firmati. I driver non sono però l'unica strada che il malware può percorrere per penetrare nello spazio kernel del sistema operativo. In Windows 10, tuttavia, Microsoft ha innalzato lo standard per il codice in modalità kernel già nella versione predefinita, offrendo inoltre alle aziende la possibilità di impostare i propri standard di integrità del codice in modalità kernel e utente. A partire dal servizio di integrità del codice stesso e continuando con i criteri usati dai client Windows per verificare se l'esecuzione di un'applicazione può essere consentita, Microsoft ha reso Windows 10 più sicuro rispetto a tutte le precedenti versioni di Windows. Finora l'integrità del codice in modalità utente è stata disponibile solo in Windows RT e nei dispositivi Windows Phone, che sono per questo particolarmente resistenti alle infezioni da virus e malware. In Windows 10 sono disponibili gli stessi elevati standard di integrità del codice in modalità utente.

Tradizionalmente, la maggior parte del malware è privo di firma. Con la semplice distribuzione di criteri di integrità del codice, le organizzazioni saranno immediatamente in grado di proteggersi dal malware non firmato, che attualmente è ritenuto responsabile di oltre il 95% degli attacchi. Usando i criteri di integrità del codice, un'azienda può selezionare con precisione i file binari di cui consentire l'esecuzione sia in modalità utente che in modalità kernel, dal livello di firmatario al livello di hash. Quando vengono applicati questi criteri, la modalità utente di Windows funziona come un cellulare, permettendo di considerare attendibili ed eseguire solo applicazioni o firme specifiche. Questa sola funzionalità trasforma radicalmente la sicurezza all'interno di un'azienda. Questa sicurezza aggiuntiva non è limitata alle app di Windows e non richiede di riscrivere un'applicazione per renderla compatibile con le applicazioni non firmate esistenti. Si può implementare l'integrità del codice configurabile senza abilitare Device Guard, ma questa funzionalità è pensata per l'uso combinato quando l'hardware supportato è disponibile. Per altre informazioni su come configurare, distribuire e gestire i criteri di integrità del codice, vedi la sezione Criteri di integrità del codice.

Funzionalità di sicurezza hardware e sicurezza basata su virtualizzazione

Le funzionalità di base e la protezione di Device Guard iniziano a livello hardware. I dispositivi con processori dotati di tecnologie SLAT ed estensioni di virtualizzazione, ad esempio Intel Virtualization Technology (VT-x) e AMD-V, potranno sfruttare i vantaggi delle funzionalità di sicurezza basata su virtualizzazione che migliorano la sicurezza di Windows. Device Guard usa la sicurezza basata su virtualizzazione per isolare i servizi di Windows di base essenziali per la sicurezza e l'integrità del sistema operativo. L'isolamento rimuove le vulnerabilità di questi servizi sia in modalità kernel che in modalità utente, creando una barriera impenetrabile per la maggior parte del malware di oggi. Uno di questi servizi isolati, il servizio di integrità del codice di Windows, controlla la funzionalità di integrità del codice configurabile in modalità kernel di Device Guard. Questo impedisce che un codice eventualmente penetrato nelle operazioni in modalità kernel possa compromettere il servizio di integrità del codice.

Un'altra funzionalità di Windows 10 che impiega la sicurezza basata su virtualizzazione è Credential Guard. Credential Guard offre maggiore protezione agli utenti del dominio di Active Directory archiviando le credenziali di dominio all'interno del contenitore di virtualizzazione che ospita i servizi di sicurezza di Windows, ad esempio quello di integrità del codice. Isolando le credenziali di dominio dalla modalità utente attiva e dalla modalità kernel, il rischio che siano rubate è molto inferiore. Per altre informazioni sul modo in cui Credential Guard integra Device Guard, vedi la sezione Device Guard con Credential Guard. Per informazioni su come abilitare Credential Guard, vedi la sezione Abilitare Credential Guard.

Device Guard con AppLocker

Anche se AppLocker non è considerato una nuova funzionalità di Device Guard, può integrarlo quando non è possibile implementare completamente l'integrità del codice imposta o quando le funzionalità di Device Guard non coprono ogni scenario desiderato. Esistono molti scenari in cui è utile usare i criteri di integrità del codice insieme alle regole di AppLocker. Come procedura consigliata, imponi i criteri di integrità del codice al livello più restrittivo possibile per l'organizzazione e quindi usa AppLocker per ottimizzare le restrizioni e aumentare ulteriormente il livello di sicurezza.

Nota Un esempio in cui le funzionalità di Device Guard hanno bisogno dell'integrazione di AppLocker è quando l'organizzazione vuole limitare le applicazioni universali. Le applicazioni universali sono già state convalidate da Microsoft per garantirne l'attendibilità, ma un'organizzazione potrebbe non voler permettere l'esecuzione nel suo ambiente di specifiche applicazioni universali. A questo scopo, puoi usare una regola di AppLocker.

AppLocker e Device Guard dovrebbero essere eseguiti insieme. Questo offrirà alla tua organizzazione il meglio di entrambe le funzionalità e la sicurezza più completa per il maggior numero possibile di dispositivi. Oltre a queste funzionalità, Microsoft consiglia di continuare a usare una soluzione antivirus aziendale, per disporre di un portfolio di prodotti di sicurezza a tutto tondo.

Device Guard con Credential Guard

Anche se Credential Guard non è una funzionalità di Device Guard, probabilmente molte organizzazioni distribuiranno entrambi i prodotti, per una maggiore protezione contro il furto di credenziali. Come la protezione basata su virtualizzazione dell'integrità del codice in modalità kernel, Credential Guard sfrutta la tecnologia hypervisor per proteggere le credenziali di dominio. Questa misura di prevenzione è progettata per impedire l'uso delle tecniche Pass-the-Hash o Pass-The-Ticket. Utilizzando l'autenticazione a più fattori con Credential Guard, le organizzazioni possono ottenere un'ulteriore protezione dalle minacce di questo tipo. Per informazioni su come distribuire Credential Guard nei client Windows 10 Enterprise, vedi la sezione Abilitare Credential Guard. Oltre ad abilitare Credential Guard sul lato client, le organizzazioni possono distribuire misure di prevenzione a livello di Autorità di certificazione (CA) e di controller di dominio, per contribuire ad evitare il furto di credenziali. Microsoft rilascerà dettagli su queste ulteriori misure di prevenzione in futuro.

Gestibilità unificata

Puoi gestire facilmente le funzionalità di Device Guard usando i familiari strumenti aziendali e di gestione dei client che i professionisti IT usano quotidianamente. Usa gli strumenti di gestione seguenti per abilitare e gestire Device Guard:

Criteri di gruppo. Windows 10 offre un modello amministrativo per configurare e distribuire i criteri di integrità del codice configurabili per la tua organizzazione. Questo modello permette anche di specificare le funzionalità di sicurezza basata su hardware da abilitare e distribuire. Grazie alla possibilità di gestire queste impostazioni insieme agli oggetti Criteri di gruppo esistenti, implementare le funzionalità di Device Guard è molto semplice. Oltre che per gestire l'integrità del codice e le funzionalità di sicurezza basata su hardware, puoi usare Criteri di gruppo per semplificare la gestione dei file di catalogo. Per altre informazioni sui file di catalogo, vedi la sezione File di catalogo.
Microsoft System Center Configuration Manager. Puoi usare System Center Configuration Manager per semplificare la distribuzione e la gestione di file di catalogo, criteri di integrità del codice e funzionalità di sicurezza basata su hardware, oltre che per implementare il controllo della versione. Per altre informazioni su come distribuire i file di catalogo usando System Center Configuration Manager, vedi la sezione Distribuire i file di catalogo con System Center Configuration Manager.
Microsoft Intune. In una versione futura di Microsoft Intune, le organizzazioni potranno usare Intune per la distribuzione e la gestione dei criteri di integrità di codice e dei file di catalogo.
Windows PowerShell. Windows PowerShell viene usato principalmente per creare i criteri di integrità del codice ed eseguirne la manutenzione. Questi criteri rappresentano il componente più potente di Device Guard. Per istruzioni dettagliate sulla creazione, il controllo, la manutenzione, l'imposizione e la distribuzione di criteri di integrità del codice, vedi la sezione Criteri di integrità del codice.

Queste opzioni ti permettono di gestire Device Guard con gli stessi strumenti che usi normalmente per gestire le soluzioni di gestione aziendale esistenti. Per altre informazioni su come gestire e distribuire le funzionalità hardware e di integrità del codice di Device Guard nella tua organizzazione, vedi la sezione Distribuzione di Device Guard.

Pianificare per Device Guard

Questa sezione illustra gli argomenti seguenti:

Prepararsi alla distribuzione dei criteri di integrità del codice a livello aziendale. La distribuzione di Device Guard nell'organizzazione richiede un approccio pianificato. In questa sezione troverai consigli generali su come prepararti alla distribuzione dei criteri di integrità del codice nella tua organizzazione.
Scenari di distribuzione di Device Guard. Quando pianifichi la distribuzione di Device Guard, Microsoft consiglia di definire le categorie dei singoli dispositivi presenti nella tua organizzazione in uno scenario di distribuzione. Questi scenari ti forniranno una roadmap per la distribuzione di Device Guard.
Adozione della firma del codice. La firma del codice è importante nell'ottica della sicurezza fornita da Device Guard. Questa sezione descrive le opzioni per la firma del codice e i vantaggi e svantaggi di ogni metodo.
Considerazioni sull'hardware. Alcune funzionalità di Device Guard richiedono hardware avanzato. Questa sezione descrive i requisiti di ognuna di tali funzionalità e le caratteristiche da cercare nel prossimo aggiornamento dell'hardware.

Prepararsi alla distribuzione dei criteri di integrità del codice a livello aziendale

Le aziende che intendono adottare Device Guard non devono aspettarsi che sia possibile distribuire le funzionalità nell'intera organizzazione nel giro di una notte. L'implementazione di Device Guard richiede una pianificazione attenta dell'impatto sia sugli utenti finali che sui professionisti IT. Inoltre, la distribuzione delle funzionalità di Device Guard a livello aziendale richiede un approccio pianificato e in più fasi, per verificare che i sistemi degli utenti finali siano pronti per l'applicazione delle nuove restrizioni di sicurezza. Per prepararti alla distribuzione di Device Guard nella tua azienda, devo completare le attività generali illustrate di seguito:

Raggruppare i dispositivi in funzioni simili. Suddividi i computer in base ai gruppi descritti nella sezione Scenari di distribuzione di Device Guard. Questo sarà il punto di partenza della roadmap per la distribuzione di Device Guard e ti permetterà di creare gruppi di implementazioni più semplici e più complesse. Fatto questo, valuta la quantità di criteri di Device Guard necessari. La soluzione più semplice consiste nel bloccare l'intera organizzazione, ma questo potrebbe non soddisfare le esigenze dei singoli reparti.

Per individuare il numero appropriato di criteri per la tua organizzazione, prova a separare i gruppi definiti in reparti o ruoli. Quindi, poniti qualche domanda: di quale software ha bisogno ogni reparto o ruolo per svolgere il proprio lavoro? Dovrebbero avere la possibilità di installare ed eseguire software di altri reparti? Occorre creare un criterio di integrità del codice di base allineato al nostro catalogo applicazioni? Gli utenti dovrebbero avere la possibilità di installare qualsiasi applicazione oppure scegliere solo da un elenco di applicazioni consentite? Permettiamo agli utenti di usare dispositivi personali? Queste domande ti aiuteranno a individuare il numero di criteri necessari per la tua organizzazione. Infine, prova a stabilire quali persone o reparti avrebbero bisogno di privilegi più elevati. Ad esempio, il reparto x dovrebbe poter installare ed eseguire l'applicazione xyz, anche se non è consentito a nessun altro reparto? Se la risposta è sì ed è giustificabile, per quel gruppo ti servirà un criterio di integrità del codice secondario. In caso contrario, probabilmente potrai unire vari criteri per semplificare la gestione. Per altre informazioni sui criteri di integrità del codice configurabili, vedi la sezione Criteri di integrità del codice.
Creare criteri di integrità del codice da PC di riferimento. Dopo aver creato i gruppi di dispositivi, puoi creare criteri di integrità del codice allineati ai gruppi, come faresti per gestire le immagini aziendali. Una volta separati i gruppi e configurati PC di riferimento che riproducono il software e l'hardware necessari per i singoli gruppi, crea criteri di integrità del codice per ognuno di essi. Dopo la creazione, potrai unire i criteri di integrità del codice per creare un criterio master oppure gestirli e distribuirli singolarmente. Per istruzioni dettagliate su come creare criteri di integrità del codice, vedi la sezione Creare criteri di integrità del codice da PC di riferimento.
Controllare e unire i criteri di integrità del codice. Microsoft consiglia di testare i criteri di integrità del codice in modalità di controllo prima di imporli. La modalità di controllo permette agli amministratori di eseguire i criteri di integrità del codice in un sistema senza effettivamente bloccare alcunché. Anziché non consentire l'esecuzione delle applicazioni, vengono registrati eventi con le singole eccezioni ai criteri. In questo modo è possibile evidenziare facilmente i problemi non individuati durante l'analisi iniziale. Puoi creare criteri di integrità del codice aggiuntivi usando gli eventi di controllo e unirli ai criteri esistenti. Per altre informazioni sul controllo dei criteri di integrità del codice, vedi la sezione Controllare i criteri di integrità del codice.
Individuare le applicazioni line-of-business attualmente non firmate e creare un file di catalogo. I file di catalogo permettono alle organizzazioni di firmare le applicazioni che attualmente non posseggono file binari con firma digitale o applicazioni a cui un cliente vorrà probabilmente aggiungere una firma secondaria. Può trattarsi di applicazioni interne o di terzi parti e il processo non richiede la ricreazione del pacchetto dell'applicazione. Quando crei criteri di integrità del codice a un livello della regola superiore ai valori hash, non individuerai le applicazioni non firmate. Per includere queste applicazioni nei criteri di integrità del codice devi semplicemente creare, firmare e distribuire un file di catalogo. Per informazioni sui file di catalogo, vedi la sezione File di catalogo.
Abilitare le funzionalità di sicurezza hardware desiderate. Ogni tipo di dispositivo descritto nella sezione Scenari di distribuzione di Device Guard utilizza configurazioni di integrità software e hardware differenti. Devi valutare le funzionalità di sicurezza basata su hardware separatamente dai criteri di integrità del codice, perché forniscono funzionalità complementari. Per informazioni su come configurare le funzionalità di sicurezza basata su hardware di Device Guard, vedi la sezione Configurare le funzionalità di sicurezza basata su hardware.
Distribuire i criteri di integrità di codice e i file di catalogo. Dopo aver creato e firmato i file di catalogo necessari e creato e controllato i criteri di integrità del codice, sei pronto per distribuirli in più fasi. Microsoft consiglia vivamente di distribuire questi componenti a un gruppo di utenti di test, anche dopo il test e l'esame da parte dell'organizzazione IT. Questo offrirà una convalida finale della qualità prima della distribuzione su larga scala dei criteri e dei file di catalogo. Per informazioni su come distribuire i file di catalogo usando Criteri di gruppo, vedi la sezione Distribuire i file di catalogo con Criteri di gruppo. Per altre informazioni su come distribuire i criteri di integrità del codice, vedi la sezione Distribuire i criteri di integrità del codice con Criteri di gruppo.

Scenari di distribuzione di Device Guard

Per semplificare la distribuzione di Device Guard nell'organizzazione, Microsoft consiglia di raggruppare i dispositivi negli scenari descritti in questa sezione. Device Guard non è una funzionalità che le organizzazioni possono semplicemente attivare. In genere, infatti, richiede un approccio di implementazione in più fasi. Per capire dove si inseriscono questi scenari nell'ambito di un approccio complessivo alla distribuzione di Device Guard, vedi la sezione Prepararsi alla distribuzione dei criteri di integrità del codice a livello aziendale.

Dispositivi con carico di lavoro fisso

Gli elenchi di applicazioni approvate nei dispositivi con carico di lavoro fisso cambiano raramente, poiché questi eseguono ogni giorno le stesse attività. Esempi di dispositivi di questo tipo sono chioschi multimediali, sistemi POS e PC di call center. Questi dispositivi possono usare facilmente tutte le funzionalità di Device Guard e richiedono poche attività di gestione o modifica dei criteri. L'implementazione di Device Guard in questi dispositivi è semplice e richiede poca amministrazione. Con Device Guard completamente implementato, gli utenti possono eseguire solo le applicazioni che il reparto IT installa, gestisce e considera attendibili.

I componenti di Device Guard applicabili ai dispositivi con carico di lavoro fisso includono:

Sicurezza basata su virtualizzazione dell'integrità del codice in modalità kernel

Criteri imposti di integrità del codice in modalità utente

Dispositivi completamente gestiti

I dispositivi completamente gestiti sono quelli per cui il reparto IT limita il software che è possibile installare ed eseguire, ma consente agli utenti di richiedere l'installazione di software aggiuntivo o fornisce un elenco di software approvato in un catalogo applicazioni. Esempi di dispositivi di questo tipo sono i computer desktop e portatili bloccati di proprietà dell'azienda. Con questi dispositivi, stabilisci un criterio di integrità del codice iniziale e imponi l'applicazione. Il reparto IT gestisce i criteri e aggiorna i dispositivi quando nuove applicazioni vengono approvate o aggiunte al catalogo di System Center Configuration Manager.

I componenti di Device Guard applicabili ai dispositivi completamente gestiti includono:

Sicurezza basata su virtualizzazione dell'integrità del codice in modalità kernel
Criteri imposti di integrità del codice in modalità utente

In questo scenario viene fornito un elenco di applicazioni attendibili e i criteri di attendibilità vengono nuovamente valutati quando un utente richiede una nuova applicazione. Quando un'applicazione è considerata attendibile per tutti questi dispositivi, le nuove richieste dell'applicazione da parte degli utenti non richiedono l'aggiornamento dei criteri (allineamento con il catalogo applicazioni). Puoi anche abbinare i criteri a un processo di caricamento per le nuove applicazioni da aggiungere al catalogo applicazioni centrale. L'implementazione iniziale di Device Guard nei dispositivi completamente gestiti è semplice, ma comporta un ulteriore carico amministrativo associato alla gestione delle firme attendibili delle nuove applicazioni richieste e approvate.

Dispositivi poco gestiti

I dispositivi poco gestiti sono computer di proprietà dell'azienda su cui gli utenti hanno il controllo completo, anche sull'installazione di applicazioni. Questi dispositivi eseguono la soluzione antivirus e gli strumenti di gestione client dell'organizzazione, ma non hanno restrizioni rispetto alle richieste di software e non sono vincolati al rispetto di criteri di conformità.

I componenti di Device Guard applicabili ai dispositivi poco gestiti includono:

Sicurezza basata su virtualizzazione dell'integrità del codice in modalità kernel
Criteri di integrità del codice in modalità utente in modalità di controllo

Bring Your Own Device (BYOD)

Device Guard non è un buon sistema per gestire i dispositivi in un modello Bring Your Own Device (BYOD). Quando i dipendenti sono autorizzati a usare dispositivi personali, la gestione delle applicazioni in modalità utente su di essi può renderne difficile l'utilizzo quando non sono al lavoro. In più, da un punto di vista amministrativo non è semplice gestire le funzionalità di Device Guard. Per i dispositivi in questo gruppo, valuta funzionalità alternative di sicurezza e protezione avanzata con soluzioni di accesso condizionale basato su MDM, ad esempio Microsoft Intune.

Adozione della firma del codice

La firma del codice è essenziale per l'implementazione corretta dei criteri di integrità del codice configurabili. Questi criteri possono considerare attendibili i certificati di firma sia di clienti che di fornitori di software indipendenti. In Windows 10, tutte le applicazioni di Windows Store sono firmate. Inoltre, puoi facilmente considerare attendibile qualsiasi altra applicazione firmata aggiungendo il certificato di firma ai criteri di integrità del codice.

Per quanto riguarda le applicazioni non firmate, i clienti hanno svariate opzioni per firmarle in modo che i criteri di integrità del codice possano considerarle attendibili. La prima opzione è il metodo tradizionale della firma del codice incorporata. Le organizzazioni che hanno team di sviluppo interni possono incorporare la firma del codice binario nel processo di sviluppo delle applicazioni e quindi aggiungere semplicemente il certificato di firma ai criteri di integrità del codice. La seconda opzione per firmare applicazioni non firmate consiste nell'usare i file di catalogo. In Windows 10, i clienti hanno la possibilità di creare file di catalogo durante il monitoraggio dell'installazione e dell'esecuzione iniziale di un'applicazione. Per altre informazioni su come firmare applicazioni line-of-business o di terze parti esistenti, vedi la sezione Applicazioni line-of-business esistenti.

Applicazioni line-of-business esistenti

Finora, considerare attendibili le applicazioni line-of-business esistenti firmate da un'origine diversa da Windows Store oppure completamente prive di firma era una procedura piuttosto difficile. Con Windows 10, aggiungere la firma alle applicazioni line-of-business e di terze parti esistenti è più semplice. Questo nuovo metodo di firma non richiede di ricreare il pacchetto delle applicazioni. Con i file di catalogo, gli amministratori possono firmare queste applicazioni non firmate semplicemente monitorando un'installazione e l'avvio iniziale. Usando queste informazioni di monitoraggio, l'amministratore può generare un file di catalogo. I file di catalogo sono semplicemente elenchi di hash SHA2 (Secure Hash Algorithm 2) dei file binari individuati. I valori hash di questi file binari vengono aggiornati ogni volta che viene aggiornata un'applicazione, quindi richiedono un file di catalogo aggiornato. Per semplificare l'amministrazione, valuta la possibilità di incorporare la firma del codice nel processo di sviluppo delle applicazioni. Per altre informazioni su come generare file di catalogo, vedi la sezione File di catalogo.

Nota

I file di catalogo sono elenchi dei valori hash di singoli file binari. Se l'applicazione analizzata viene aggiornata, dovrai creare un nuovo file di catalogo. Detto ciò, la firma dei file binari è comunque consigliata per tutte le applicazioni future, in modo che i file di catalogo non siano necessari.

Quando crei un file di catalogo, devi firmarlo usando l'infrastruttura a chiave pubblica (PKI) aziendale o un certificato di firma del codice acquistato. Dopo la firma, i criteri di integrità del codice possono considerare attendibili il firmatario o il certificato di firma di questi file. Per informazioni sulla firma dei file di catalogo, vedi la sezione File di catalogo.

Sviluppo di applicazioni

Anche se è possibile firmare le applicazioni interne dopo la creazione del pacchetto usando i file di catalogo, Microsoft consiglia di incorporare la firma del codice nel processo di sviluppo delle applicazioni. Quando firmi le applicazioni, aggiungi semplicemente il certificato di firma del codice usato per firmare le applicazioni ai criteri di integrità del codice. Questo garantisce che i criteri di integrità del codice considereranno attendibile qualsiasi applicazione futura firmata con quel certificato. Incorporare la firma del codice nel processo di sviluppo delle applicazioni interne sarà utile alla tua organizzazione IT nelle fasi di implementazione dei criteri di integrità del codice.

Considerazioni sull'hardware

Un'attenta valutazione dei fornitori di hardware a cui rivolgersi e degli specifici modelli da acquistare durante il prossimo aggiornamento dell'hardware è fondamentale per il successo dell'implementazione di Device Guard nella tua organizzazione. In linea con il ciclo di vita dell'hardware corrente, considera il processo illustrato nella sezione Prepararsi alla distribuzione dei criteri di integrità del codice a livello aziendale per stabilire l'ordine di sostituzione dell'hardware più appropriato nella tua organizzazione. Device Guard deve essere distribuito in fasi, quindi hai tempo per pianificare l'implementazione con metodo.

Per implementare le varie funzionalità di Device Guard sono necessarie funzionalità hardware diverse. Probabilmente nell'hardware corrente sarà possibile abilitare alcune funzionalità e non altre. Tuttavia, per le organizzazioni che vogliono implementare la versione completa di Device Guard, saranno necessarie svariate funzionalità hardware avanzate. Per altre informazioni sulle funzionalità hardware necessarie per i componenti di Device Guard, vedi la tabella seguente.

Requisito	Descrizione
Windows 10 Enterprise	Il PC deve eseguire Windows 10 Enterprise.
Firmware UEFI versione 2.3.1 o successiva e Avvio protetto	Per verificare che il firmware usi UEFI versione 2.3.1 o successiva e Avvio protetto, puoi eseguire la convalida rispetto al requisito System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby del programma di compatibilità hardware Windows.
Estensioni di virtualizzazione	Le estensioni di virtualizzazione seguenti sono necessarie per supportare la sicurezza basata su virtualizzazione: Intel VT-x o AMD-V Conversione indirizzi di secondo livello
Blocco del firmware	La configurazione del firmware deve essere bloccata per impedire l'avvio di altri sistemi operativi e per impedire modifiche alle impostazioni UEFI. Devi anche disabilitare i metodi di avvio diversi dall'avvio dal disco rigido.
Architettura x64	Le funzionalità usate dalla sicurezza basata su virtualizzazione in Windows Hypervisor possono essere eseguite solo su un PC a 64 bit.
IOMMU (unità di gestione della memoria di input/output) VT-d o AMD-Vi	In Windows 10 una IOMMU migliora la resilienza del sistema agli attacchi contro la memoria. ¹
Processo di aggiornamento sicuro del firmware	Per verificare che il firmware sia conforme al processo di aggiornamento sicuro del firmware, puoi eseguire la convalida rispetto al requisito System.Fundamentals.Firmware.UEFISecureBoot del programma di compatibilità hardware Windows.

Distribuzione di Device Guard

Questa sezione illustra gli argomenti seguenti:

Configurare le funzionalità di sicurezza basata su hardware. Questa sezione spiega come abilitare le funzionalità di sicurezza basata su hardware in Device Guard. Verificherai inoltre che le funzionalità siano abilitate usando Windows Management Infrastructure (WMI) e Msinfo32.exe.
File di catalogo. In questa sezione imparerai a creare, firmare e distribuire file di catalogo. Per distribuire i file di catalogo userai Criteri di gruppo e System Center Configuration Manager. Inoltre, userai System Center Configuration Manager per eseguire l'inventario dei file di catalogo distribuiti ai fini della creazione di report.
Criteri di integrità del codice. Questa sezione contiene informazioni su come creare, controllare, gestire, unire, distribuire e rimuovere criteri di integrità del codice configurabili firmati e non firmati.

Configurare le funzionalità di sicurezza basata su hardware

Le funzionalità di sicurezza basata su hardware rappresentano gran parte delle offerte di sicurezza di Device Guard. La sicurezza basata su virtualizzazione potenzia la funzionalità più importante di Device Guard, ossia l'integrità del codice configurabile. La configurazione delle funzionalità di sicurezza basata su hardware in Device Guard prevede tre passaggi:

Verificare che i requisiti hardware siano soddisfatti e abilitati. Verifica che i computer client posseggano l'hardware necessario per eseguire queste funzionalità. Un elenco di requisiti per le funzionalità di sicurezza basata su hardware è disponibile nella sezione Considerazioni sull'hardware. In più, se stai cercando nuovo hardware, valuta i dispositivi descritti nella sezione Dispositivi pronti per Device Guard.
Abilitare le funzionalità di Windows necessarie. Le funzionalità di Windows necessarie per la sicurezza basata su hardware si possono abilitare in vari modi. Per informazioni sulle funzionalità di Windows necessarie, vedi la sezione Funzionalità di Windows necessarie per la sicurezza basata su hardware.
Abilitare le funzionalità desiderate. Una volta abilitati l'hardware e le funzionalità di Windows necessarie, sei pronto per abilitare le funzionalità di sicurezza basata su hardware desiderate. Per l'avvio protetto UEFI, vedi la sezione Abilitare l'avvio protetto UEFI. Per informazioni su come abilitare la protezione basata su virtualizzazione dell'integrità del codice in modalità kernel, vedi la sezione Abilitare la protezione basata su virtualizzazione dell'integrità del codice in modalità kernel. Infine, per informazioni su come abilitare Credential Guard, vedi la sezione Abilitare Credential Guard.

Funzionalità di Windows necessarie per la sicurezza basata su virtualizzazione

Oltre ai requisiti hardware descritti nella sezione Considerazioni sull'hardware, prima di abilitare la sicurezza basata su virtualizzazione devi abilitare alcune funzionalità del sistema operativo: Microsoft Hyper-V e la modalità utente isolato (figura 1).

Nota

Puoi configurare queste funzionalità manualmente tramite Windows PowerShell o Gestione e manutenzione immagini distribuzione. Per informazioni specifiche su questi metodi, vedi la documentazione di Credential Guard.

Figura 1

Figura 1. Abilitare le funzionalità del sistema operativo per la sicurezza basata su virtualizzazione

Dopo aver abilitato queste funzionalità, puoi configurare le funzionalità di sicurezza basata su hardware che preferisci. Per informazioni su come abilitare la protezione basata su virtualizzazione dell'integrità del codice in modalità kernel, vedi la sezione Abilitare la protezione basata su virtualizzazione dell'integrità del codice in modalità kernel. Per informazioni su come abilitare l'avvio protetto UEFI, vedi la sezione Abilitare l'avvio protetto UEFI. Infine, per altre informazioni su come abilitare Credential Guard, vedi la sezione Abilitare Credential Guard.

Abilitare l'avvio protetto UEFI

Prima di dare inizio a questo processo, verifica che il dispositivo di destinazione soddisfi i requisiti hardware per l'avvio protetto UEFI esposti nella sezione Considerazioni sull'hardware. L'avvio protetto UEFI si può configurare in due modi, ovvero configurando manualmente le chiavi del Registro di sistema appropriate oppure tramite Criteri di gruppo. Completa la procedura seguente per configurare manualmente l'avvio protetto UEFI in un computer che esegue Windows 10:

Nota

Esistono due livelli di sicurezza della piattaforma per l'avvio protetto, Avvio protetto e Avvio protetto e protezione DMA. La protezione DMA offre una protezione aggiuntiva per la memoria, ma verrà abilitata solo nei sistemi i cui processori includono tecnologie di protezione DMA (IOMMU). In assenza di unità IOMMU e con la protezione DMA disabilitata, i clienti non saranno protetti dagli attacchi basati su driver.

Vai alla sottochiave del Registro di sistema HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard.
Imposta il valore EnableVirtualizationBasedSecurity DWORD su 1.
Imposta il valore RequirePlatformSecurityFeatures DWORD come appropriato:
- Imposta questo valore su 1 per abilitare l'opzione Avvio protetto.
- Imposta questo valore su 2 per abilitare l'opzione Avvio protetto e protezione DMA.
Riavvia il computer client.

Eseguire questi passaggi manualmente in ogni computer protetto dell'azienda, tuttavia, richiede molto tempo. Criteri di gruppo offre un modo molto più semplice per distribuire l'avvio protetto UEFI nell'organizzazione. Questo esempio crea un'unità organizzativa (OU) di test denominata DG Enabled PCs. Se preferisci collegare il criterio a un'unità organizzativa esistente e quindi definire l'ambito dell'oggetto Criteri di gruppo usando gruppi di sicurezza del computer denominati in modo appropriato, puoi senz'altro farlo.

Nota

Microsoft consiglia di abilitare questa funzionalità in un gruppo di computer di test prima di distribuirla nei computer attualmente distribuiti agli utenti.

Usare Criteri di gruppo per distribuire l'avvio protetto

Per creare un nuovo oggetto Criteri di gruppo, fai clic con il pulsante destro del mouse sull'unità organizzativa a cui vuoi collegare l'oggetto e scegli Crea un oggetto Criteri di gruppo in questo dominio e crea qui un collegamento.

Figura 2. Creare un nuovo oggetto Criteri di gruppo collegato all'unità organizzativa
Assegna al nuovo oggetto Criteri di gruppo il nome Contoso Secure Boot GPO Test. Questo esempio usa Contoso Secure Boot GPO Test come nome dell'oggetto Criteri di gruppo. Puoi scegliere qualsiasi nome per questo esempio. Idealmente, il nome deve essere in linea con la convenzione di denominazione degli oggetti Criteri di gruppo esistente.
Per aprire l'Editor Gestione Criteri di gruppo, fai clic con il pulsante destro del mouse sul nuovo oggetto Criteri di gruppo e scegli Modifica.
Nell'oggetto Criteri di gruppo selezionato passa a Configurazione computer\Modelli amministrativi\Sistema\Device Guard. Quindi, fai clic con il pulsante destro del mouse su Attiva sicurezza basata su virtualizzazione e scegli Modifica.

Figura 3. Abilitare la sicurezza basata su virtualizzazione
Seleziona l'opzione Abilitato e quindi seleziona Avvio protetto e protezione DMA dall'elenco Seleziona il livello di sicurezza della piattaforma.

Figura 4. Abilitare l'avvio protetto

Nota

L'avvio protetto di Device Guard offre le massime prestazioni se combinato con la protezione DMA. Se il tuo hardware contiene le unità IOMMU necessarie per la protezione DMA, assicurati di selezionare il livello di sicurezza della piattaforma Avvio protetto e protezione DMA. Se l'hardware non contiene unità IOMMU, usando l'avvio protetto senza protezione DMA avrei comunque a disposizione svariate misure di prevenzione.
Chiudi l'Editor Gestione criteri di gruppo e quindi riavvia il computer di test Windows 10. Una volta configurata questa impostazione, l'avvio protetto UEFI verrà abilitato dopo il riavvio.
Controlla nel log degli eventi del computer di test gli eventi relativi agli oggetti Criteri di gruppo di Device Guard.

I criteri di Device Guard elaborati vengono registrati nel Visualizzatore eventi in Registri applicazioni e servizi\Microsoft\Windows\DeviceGuard-GPEXT\Operational. Quando il criterio Attiva sicurezza basata su virtualizzazione viene elaborato correttamente viene registrato l'ID evento 7000, che contiene le impostazioni selezionate nel criterio.

Abilitare la sicurezza basata su virtualizzazione dell'integrità del codice in modalità kernel

Prima di dare inizio a questo processo, verifica che il computer desiderato soddisfi i requisiti hardware per la sicurezza basata su virtualizzazione esposti nella sezione Considerazioni sull'hardware e abilita le funzionalità di Windows descritte nella sezione Funzionalità di Windows necessarie per la sicurezza basata su virtualizzazione. Se l'esito è positivo, puoi abilitare la sicurezza basata su virtualizzazione dell'integrità del codice in modalità kernel in due modi, ovvero configurando manualmente le sottochiavi del Registro di sistema appropriate oppure tramite Criteri di gruppo.

Nota

Tutti i driver nel sistema devono essere compatibili con la protezione basata su virtualizzazione dell'integrità del codice. In caso contrario, possono verificarsi errori di sistema. Microsoft consiglia di abilitare questa funzionalità in un gruppo di computer di test prima di distribuirla nei computer distribuiti.

Per configurare manualmente la protezione basata su virtualizzazione dell'integrità del codice:

Vai alla sottochiave del Registro di sistema HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard.
Imposta il valore HypervisorEnforcedCodeIntegrity DWORD su 1.
Riavvia il computer client.

Eseguire questi passaggi manualmente in ogni computer protetto dell'azienda richiede molto tempo. Per distribuire rapidamente la protezione basata su virtualizzazione dell'integrità del codice in modalità kernel, usa Criteri di gruppo. Questo esempio crea un'unità organizzativa di test denominata DG Enabled PCs, che userai per collegare l'oggetto Criteri di gruppo. Se preferisci collegare il criterio a un'unità organizzativa esistente anziché creare una OU di test e definire l'ambito del criterio usando gruppi di sicurezza del computer denominati in modo appropriato, non ci sono problemi.

Nota

Microsoft consiglia di abilitare questa funzionalità in un gruppo di computer di test prima di distribuirla nei computer attualmente distribuiti agli utenti. Se non testata, questa funzionalità può causare instabilità del sistema ed errori del sistema operativo client.

Per configurare la virtualizzazione del servizio di integrità del codice in modalità kernel usando Criteri di gruppo:

Crea un nuovo oggetto Criteri di gruppo: fai clic con il pulsante destro del mouse sull'unità organizzativa a cui vuoi collegare l'oggetto e scegli Crea un oggetto Criteri di gruppo in questo dominio e crea qui un collegamento.

Figura 5. Creare un nuovo oggetto Criteri di gruppo collegato all'unità organizzativa
Assegna al nuovo oggetto Criteri di gruppo il nome Contoso VBS CI Protection GPO Test.

Questo esempio usa Contoso VBS CI Protection GPO Test come nome dell'oggetto Criteri di gruppo. Per questo esempio puoi scegliere il nome che preferisci. Idealmente, il nome deve essere in linea con la convenzione di denominazione degli oggetti Criteri di gruppo esistente.
Apri l'Editor Gestione Criteri di gruppo: fai clic con il pulsante destro del mouse sul nuovo oggetto Criteri di gruppo e scegli Modifica.
Nell'oggetto Criteri di gruppo selezionato passa a Configurazione computer\Modelli amministrativi\Sistema\Device Guard. Quindi, fai clic con il pulsante destro del mouse su Attiva sicurezza basata su virtualizzazione e scegli Modifica.

Figura 6. Abilitare la sicurezza basata su virtualizzazione
Seleziona l'opzione Abilitato e quindi seleziona la casella di controllo Abilita protezione basata su virtualizzazione dell'integrità del codice.

Figura 7. Abilitare la sicurezza basata su virtualizzazione dell'integrità del codice in modalità kernel
Chiudi l'Editor Gestione criteri di gruppo e quindi riavvia il computer di test Windows 10. Con questa impostazione configurata, la sicurezza basata su virtualizzazione dell'integrità del codice in modalità kernel verrà applicata dopo il riavvio.
Controlla nel log degli eventi del client di test gli eventi relativi agli oggetti Criteri di gruppo di Device Guard.

I criteri di Device Guard elaborati vengono registrati nel Visualizzatore eventi in Registri applicazioni e servizi\Microsoft\Windows\DeviceGuard-GPEXT\Operational. Quando il criterio Attiva sicurezza basata su virtualizzazione viene elaborato correttamente viene registrato l'ID evento 7000, che contiene le impostazioni selezionate nel criterio.

Abilitare Credential Guard

Credential Guard offre un ulteriore livello di protezione delle credenziali specifico per gli utenti di dominio, archiviando le credenziali all'interno del contenitore virtualizzato e quindi isolandole dal sistema operativo sia in modalità kernel che in modalità utente. In questo modo, ottenere accesso alle credenziali è difficile anche per un sistema compromesso. Per evitare il furto di credenziali, oltre ad abilitare Credential Guard sul lato client puoi distribuire misure di prevenzione aggiuntive a livello di Autorità di certificazione (CA) e di controller di dominio. Microsoft rilascerà dettagli su queste ulteriori misure di prevenzione in futuro.

Prima di dare inizio a questo processo, verifica che il sistema desiderato soddisfi i requisiti hardware per la sicurezza basata su virtualizzazione esposti nella sezione Considerazioni sull'hardware e di aver abilitato le funzionalità di Windows descritte nella sezione Funzionalità di Windows necessarie per la sicurezza basata su virtualizzazione. Se l'esito è positivo, puoi abilitare Credential Guard configurando manualmente le sottochiavi del Registro di sistema appropriate oppure tramite Criteri di gruppo.

Per configurare manualmente la sicurezza basata su virtualizzazione di Credential Guard:

Vai alla sottochiave del Registro di sistema HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
Imposta il valore LsaCfgFlags DWORD su 1.
Riavvia il computer client.

Per evitare inutili perdite di tempo eseguendo distribuzioni manuali, usa Criteri di gruppo per distribuire Credential Guard nell'organizzazione. Questo esempio crea un'unità organizzativa di test denominata DG Enabled PCs. Per abilitare Credential Guard, puoi creare un collegamento a qualsiasi unità organizzativa e quindi definire l'ambito di applicazione dell'oggetto Criteri di gruppo usando i gruppi di sicurezza.

Nota

Microsoft consiglia di abilitare Credential Guard prima di aggiungere un computer al dominio, per garantire la protezione di tutte le credenziali. Impostare le sottochiavi appropriate del Registro di sistema durante il processo di creazione dell'immagine è il metodo ideale per ottenere la massima protezione.

Per abilitare Credential Guard usando Criteri di gruppo:

Crea un nuovo oggetto Criteri di gruppo: fai clic con il pulsante destro del mouse sull'unità organizzativa a cui vuoi collegare l'oggetto e scegli Crea un oggetto Criteri di gruppo in questo dominio e crea qui un collegamento.

Figura 8. Creare un nuovo oggetto Criteri di gruppo collegato all'unità organizzativa
Assegna al nuovo oggetto Criteri di gruppo il nome Contoso Credential Guard GPO Test.

Questo esempio usa Contoso Credential Guard GPO Test come nome dell'oggetto Criteri di gruppo. Per questo esempio puoi scegliere il nome che preferisci. Idealmente, il nome deve essere in linea con la convenzione di denominazione degli oggetti Criteri di gruppo esistente.
Apri l'Editor Gestione Criteri di gruppo: fai clic con il pulsante destro del mouse sul nuovo oggetto Criteri di gruppo e scegli Modifica.
Nell'oggetto Criteri di gruppo selezionato passa a Configurazione computer\Modelli amministrativi\Sistema\Device Guard. Fai clic con il pulsante destro del mouse su Attiva sicurezza basata su virtualizzazione e scegli Modifica.

Figura 9. Abilitare la sicurezza basata su virtualizzazione
Seleziona l'opzione Abilitato e quindi seleziona la casella di controllo Abilita controllo credenziali.

Figura 10. Abilitare Credential Guard
Chiudi l'Editor Gestione criteri di gruppo e riavvia il computer di test Windows 10.

Nota

Il livello di sicurezza della piattaforma predefinito è Avvio protetto. Se nei computer protetti sono disponibili unità IOMMU, è consigliabile selezionare Avvio protetto e protezione DMA per ottimizzare le misure di prevenzione disponibili tramite Credential Guard.
Controlla nel log degli eventi del client di test gli eventi relativi agli oggetti Criteri di gruppo di Device Guard.

Nota

Tutti i criteri di Device Guard elaborati vengono registrati nel Visualizzatore eventi in Registri applicazioni e servizi\Microsoft\Windows\DeviceGuard-GPEXT\Operational.

Per altre informazioni sul funzionamento di Credential Guard e sulle altre opzioni di configurazione disponibili, vedi la documentazione di Credential Guard.

Convalidare le funzionalità di sicurezza basata su hardware di Device Guard

Windows 10 e Windows Server 2016 e versioni successive hanno una classe WMI per le proprietà e le funzionalità correlate a Device Guard, ovvero Win32_DeviceGuard. È possibile eseguire query su questa classe da una sessione di Windows PowerShell con privilegi elevati, usando il comando seguente:

Get-CimInstance –ClassName Win32_DeviceGuard –Namespace root\Microsoft\Windows\DeviceGuard

Nota

La classe WMI Win32_DeviceGuard è disponibile solo nell'edizione Enterprise di Windows 10.

L'output di questo comando fornisce dettagli sulle funzionalità di sicurezza basata su hardware disponibili e sul relativo stato di abilitazione. Per informazioni dettagliate sul significato di ogni proprietà, vedi la tabella 1.

Tabella 1. Proprietà di Win32_DeviceGuard

Proprietà	Descrizione	Valori validi
AvailableSecurityProperties	Questo campo consente di enumerare le proprietà di sicurezza appropriate per Device Guard e il relativo stato.	0. Se presente, nel dispositivo non esistono proprietà appropriate. 1.Se presente, il supporto per gli hypervisor è disponibile. 2. Se presente, l'avvio protetto è disponibile. 3. Se presente, la protezione DMA è disponibile.
InstanceIdentifier	Una stringa univoca di un particolare dispositivo.	Determinati da WMI.
RequiredSecurityProperties	Questo campo descrive le proprietà di sicurezza necessarie per abilitare la sicurezza basata su virtualizzazione.	0. Non ci sono altri requisiti. 1. Se presente, è necessario l'avvio protetto. 2. Se presente, è necessaria la protezione DMA. 3. Se presente, sono necessari sia l'avvio protetto che la protezione DMA.
SecurityServicesConfigured	Questo campo indica se Credential Guard o il servizio di integrità del codice applicata da hypervisor è stato configurato.	0. Nessun servizio configurato. 1. Se presente, Credential Guard è configurato. 2. Se presente, il servizio di integrità del codice applicata da hypervisor è configurato.
SecurityServicesRunning	Questo campo indica se Credential Guard o il servizio di integrità del codice applicata da hypervisor è in esecuzione.	0. Nessun servizio in esecuzione. 1.Se presente, Credential Guard è in esecuzione. 2. Se presente, il servizio di integrità del codice applicata da hypervisor è in esecuzione.
Version	Questo campo elenca la versione di questa classe WMI.	Oggi l'unico valore valido è 1.0.
VirtualizationBasedSecurityStatus	Questo campo indica se la sicurezza basata su virtualizzazione è abilitata e in esecuzione.	0. La sicurezza basata su virtualizzazione non è abilitata. 1. La sicurezza basata su virtualizzazione è abilitata, ma non in esecuzione. 2. La sicurezza basata su virtualizzazione è abilitata e in esecuzione.
PSComputerName	Questo campo elenca il nome computer.	Tutti i valori validi per il nome computer.

Un altro metodo per determinare le funzionalità di Device Guard disponibili e abilitate consiste nell'eseguire msinfo32.exe da una sessione di PowerShell con privilegi elevati. Quando esegui questo programma, le proprietà di Device Guard vengono visualizzate in fondo alla sezione Risorse di sistema, come illustrato nella figura 11.

Figura 11

Figura 11. Proprietà di Device Guard in Risorse di sistema

File di catalogo

Per l'applicazione di Device Guard a un sistema è necessario che tutte le applicazioni attendibili siano firmate o che gli hash dei file binari siano stati aggiunti ai criteri di integrità del codice. Per molte organizzazioni questo può diventare un problema, considerando il numero di applicazioni line-of-business non firmate. Per evitare di dover ricreare tutti i pacchetti e firmare le applicazioni, Windows 10 include uno strumento di controllo dei pacchetti che monitora i processi di installazione di tutti i file binari distribuiti ed eseguiti. Se lo strumento individua file di questo tipo, li elenca in dettaglio in un file di catalogo. Questi file catalogo ti offrono un modo per considerare attendibili le applicazioni non firmate esistenti, sviluppate internamente o da terze parti, nonché le applicazioni firmate per cui non vuoi considerare attendibile il firmatario, bensì la specifica applicazione. Una volta creati questi file, è possibile firmarli, aggiungere i certificati di firma ai criteri di integrità del codice esistenti e quindi distribuire i file di catalogo ai client.

Nota

Per creare e usare file di catalogo è necessaria l'edizione Enterprise di Windows 10 o Windows Server 2016.

Creare file di catalogo

La creazione di file di catalogo è il primo passaggio per aggiungere un'applicazione non firmata ai criteri di integrità del codice. Per creare un file di catalogo, copia ognuno dei comandi seguenti in una sessione di Windows PowerShell con privilegi elevati e quindi completa i passaggi:

Nota

Stabilire una convenzione di denominazione renderà più semplice individuare i file di catalogo distribuiti. In questa guida, userai la convenzione di denominazione *-Contoso.cat. Per altre informazioni sui motivi per cui questa procedura è utile per rilevare i file di catalogo o eseguirne l'inventario, vedi la sezione Inventario dei file di catalogo con System Center Configuration Manager.

Assicurati che un criterio di integrità del codice sia attualmente in esecuzione in modalità di controllo.

Lo strumento di controllo dei pacchetti non sempre rileva i file di installazione che sono stati rimossi dal computer durante il processo di installazione. Per assicurarti che anche questi file binari siano considerati attendibili, è necessario distribuire i criteri di integrità del codice che hai creato e controllato nelle sezioni Creare criteri di integrità del codice da PC di riferimento e Controllare i criteri di integrità del codice nel sistema in cui esegui lo strumento di controllo dei pacchetti.

Nota

Questo processo non deve essere eseguito in un sistema in cui è in esecuzione un criterio di Device Guard imposto, ma solo con un criterio in modalità di controllo. Se attualmente è imposto un criterio, non riuscirai ad installare ed eseguire l'applicazione.
Avvia lo strumento di controllo dei pacchetti e analizza l'unità C:

PackageInspector.exe Start C:

Nota

Lo strumento di controllo dei pacchetti può monitorare le installazioni in qualsiasi unità locale. In questo esempio installeremo l'applicazione sull'unità C, ma si può usare qualsiasi altra unità.
Copia il supporto di installazione nell'unità C.

Copiando il supporto di installazione nell'unità C, ti assicuri che lo strumento di controllo dei pacchetti rilevi e cataloghi anche il programma di installazione stesso. Se non esegui questo passaggio, i futuri criteri di integrità del codice potrebbero consentire l'esecuzione dell'applicazione, ma non l'installazione.
Installa e avvia l'applicazione.

Installa l'applicazione nell'unità C. Al termine dell'installazione, avvia l'applicazione e verifica che tutti gli aggiornamenti del prodotto siano stati installati e che tutto il contenuto scaricabile sia stato intercettato durante l'analisi. Al termine, chiudi e riapri l'applicazione per assicurarti che l'analisi abbia rilevato tutti i file binari.

Nota

Tutti i file binari eseguiti durante l'esecuzione dello strumento di controllo dei pacchetti verranno acquisiti nel catalogo. Accertati quindi di non eseguire ulteriori installazioni o aggiornamenti durante l'analisi, per ridurre al minimo il rischio di considerare attendibili file binari non corretti. In alternativa, se vuoi aggiungere più applicazioni a un singolo file di catalogo, puoi semplicemente ripetere il processo di installazione e avvio durante l'esecuzione dell'analisi corrente.
Interrompi l'analisi e quindi genera i file di definizione e di catalogo. Al termine dell'installazione e della configurazione iniziale dell'applicazione, interrompi l'analisi dello strumento di controllo dei pacchetti e genera i file di definizione e di catalogo sul desktop usando i comandi seguenti:

$ExamplePath=$env:userprofile+"\Desktop"

$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"

$CatDefName=$ExamplePath+"\LOBApp.cdf"

PackageInspector.exe Stop C: -Name $CatFileName -cdfpath $CatDefName

Nota

Questa analisi cataloga i valori hash di tutti i file binari individuati. Se le applicazioni analizzate vengono aggiornate, ripeti questo processo per considerare attendibili i nuovi valori hash dei file binari.

Al termine, i file verranno salvati sul desktop. Per considerare attendibile questo file di catalogo all'interno di un criterio di integrità del codice, occorre prima firmarlo. Fatto questo, sarà possibile includere il certificato di firma nel criterio e distribuire il file di catalogo ai singoli computer client. I file di catalogo possono essere firmati usando un certificato e SignTool.exe, uno strumento gratuito disponibile in Windows SDK. Per altre informazioni su come firmare i firma dei file di catalogo con SignTool.exe, vedi la sezione Firma di file di catalogo con SignTool.exe.

Firma di file di catalogo con SignTool.exe

Con Device Guard, firmare e considerare attendibili le applicazioni line-of-business non firmate esistenti è molto semplice. In questa sezione firmerai un file di catalogo generato nella sezione precedente usando PackageInspector.exe. Per altre informazioni su come creare file di catalogo, vedi la sezione Creare file di catalogo. Per questo esempio avrai bisogno di:

SignTool.exe, disponibile nel Windows Software Development Kit (SDK) per Windows 7 o versioni successive
Il file di catalogo che hai generato nella sezione Creare file di catalogo o un altro file di catalogo
Certificato di firma del codice dell'Autorità di certificazione (CA) interna o un certificato di firma del codice acquistato.

Se non hai un certificato di firma del codice, vedi la sezione Creare un certificato di firma del codice per Device Guard per la descrizione dettagliata di come crearne uno. Oltre a usare il certificato creato nella sezione Creare un certificato di firma del codice per Device Guard, questo esempio firma il file di catalogo che hai creato nella sezione Creare file di catalogo. Se usi un altro certificato o file di catalogo, aggiorna i passaggi seguenti con il certificato e le variabili appropriate. Per firmare il file di catalogo esistente, copia ognuno dei comandi seguenti in una sessione di Windows PowerShell con privilegi elevati:

Inizializza le variabili che verranno usate:
```
$ExamplePath=$env:userprofile+"\Desktop"

$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"
```
Nota

In questo esempio si usa il file di catalogo creato nella sezione Creare file di catalogo. Se vuoi firmare un altro file di catalogo, assicurati di aggiornare le variabili $ExamplePath e $CatFileName con le informazioni corrette.
Importa il certificato di firma del codice. Importa il certificato di firma del codice che verrà usato per firmare il file di catalogo nell'archivio personale dell'utente che firma. In questo esempio userai il certificato che hai creato nella sezione Creare un certificato di firma del codice per Device Guard.
Firma il file di catalogo con Signtool.exe:
```
<Path to signtool.exe> sign /n "ContosoDGSigningCert" /fd sha256 /v $CatFileName
```
Nota

La variabile <Path to signtool.exe> deve corrispondere al percorso completo dell'utilità Signtool.exe. ContosoDGSigningCert è il nome soggetto del certificato che userai per firmare il file di catalogo. Questo certificato deve essere importato nel tuo archivio certificati personale, nel computer in cui vuoi firmare il file di catalogo.

Nota

Per altre informazioni su Signtool.exe e su tutte le altre opzioni, visita la pagina dedicata allo strumento di firma (SignTool.exe) su MSDN.
Verifica la firma digitale del file di catalogo. Fai clic con il pulsante destro del mouse sul file di catalogo e quindi scegli Proprietà. Nella scheda Firme digitali verifica che sia presente il tuo certificato di firma con un algoritmo sha256, come illustrato nella figura Figure 12.

Figura 12. Verificare che il certificato di firma sia presente
Copia il file di catalogo in C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}.

A scopi di test, puoi copiare manualmente i file di catalogo firmati nella cartella desiderata. Per le implementazioni su larga scala, Microsoft consiglia di usare le preferenze file di Criteri di gruppo per copiare i file di catalogo appropriati in tutti i computer desiderati oppure un prodotto per la gestione di sistemi aziendali, ad esempio System Center Configuration Manager. Questo semplificherà anche la gestione delle versioni dei cataloghi.

Distribuire i file di catalogo con Criteri di gruppo

Per semplificare la gestione dei file di catalogo, puoi usare le preferenze di Criteri di gruppo per distribuire i file di catalogo ai PC appropriati nell'organizzazione. La procedura seguente ti guida nella distribuzione di un file di catalogo firmato, denominato LOBApp-Contoso.cat, in un'unità organizzativa di test denominata DG Enabled PCs, usando un oggetto Criteri di gruppo denominato Contoso DG Catalog File GPO Test.

Nota

Questa procedura richiede che tu abbia già creato un file di catalogo firmato e disponga di un PC client Windows 10 in cui testare una distribuzione di Criteri di gruppo. Per altre informazioni su come creare e firmare un file di catalogo, vedi la sezione File di catalogo.

Per distribuire un file di catalogo con Criteri di gruppo:

Da un controller di dominio o da un PC client in cui è installato Strumenti di amministrazione remota del server, apri Console Gestione Criteri di gruppo eseguendoGPMC.MSC oppure cercando Gestione Criteri di gruppo.
Crea un nuovo oggetto Criteri di gruppo: fai clic con il pulsante destro del mouse sull'unità organizzativa DG Enabled PCs e scegli Crea un oggetto Criteri di gruppo in questo dominio e crea qui un collegamento, come illustrato nella figura 13.

Nota

L'unità organizzativa DG Enabled PCs è solo un esempio di dove collegare l'oggetto Criteri di gruppo di test che hai creato in questa sezione. Puoi usare qualsiasi nome di unità organizzativa. Inoltre, puoi filtrare in base ai gruppi di sicurezza se intendi usare opzioni di ripartizione dei criteri in base alla strategia discussa in Prepararsi alla distribuzione dei criteri di integrità del codice a livello aziendale.

Figura 13. Creare un nuovo oggetto Criteri di gruppo
Assegna al nuovo oggetto Criteri di gruppo il nome Contoso DG Catalog File GPO Test.

Questo esempio usa Contoso DG Catalog File GPO Test come nome dell'oggetto Criteri di gruppo. Per questo esempio puoi scegliere il nome che preferisci.
Apri l'Editor Gestione Criteri di gruppo: fai clic con il pulsante destro del mouse sul nuovo oggetto Criteri di gruppo e scegli Modifica.
Nell'oggetto Criteri di gruppo selezionato passa a Configurazione computer\Preferenze\Impostazioni di Windows\File. Fai clic con il pulsante destro del mouse su File, scegli Nuovo, e quindi fai clic su File, come illustrato nella figura 14.

Figura 14. Creare un nuovo file
Configura la condivisione del file di catalogo.

Per usare questa impostazione per la distribuzione coerente di LOBApp-Contoso.cat, il file di origine deve trovarsi in una condivisione accessibile per l'account computer di ogni computer distribuito. Questo esempio usa una condivisione in un computer client Windows 10 denominata \\Contoso-Win10\Share. Il file di catalogo da distribuire viene copiato in questa condivisione.
Per mantenere coerenti le versioni, nella finestra di dialogo Nuove proprietà file (figura 15) seleziona Sostituisci nell'elenco Azione, in modo che sia sempre usata la versione più recente.

Figura 15. Impostare le nuove proprietà file
Nella casella File di origine digita il nome della condivisione accessibile, includendo il nome del file di catalogo (ad esempio, \\Contoso-Win10\share\LOBApp-Contoso.cat).
Nella casella File di destinazione digita C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\LOBApp-Contoso.cat.

Nota

Non è necessario usare il nome LOBApp-Contoso.cat per il file di catalogo. Questo nome è stato usato nella sezione Creare file di catalogo e quindi è stato usato anche qui.
Nella scheda Comuni della finestra di dialogo Nuove proprietà file seleziona l'opzione Rimuovi elemento quando non viene più applicato. Questo garantisce che il file di catalogo venga rimosso da tutti i sistemi, qualora questa applicazione non fosse più considerata attendibile.
Fai clic su OK per completare la creazione del file.
Chiudi l'Editor Gestione criteri di gruppo e quindi aggiorna il criterio nel computer di test Windows 10 eseguendo GPUpdate.exe. Dopo l'aggiornamento del criterio, verifica la presenza del file di catalogo in C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} nel computer Windows 10.

Distribuire i file di catalogo con System Center Configuration Manager

In alternativa a Criteri di gruppo, puoi usare System Center Configuration Manager per distribuire i file di catalogo nei computer gestiti del tuo ambiente. Questo approccio può semplificare la distribuzione e la gestione di più file di catalogo, oltre che fornire informazioni sul catalogo distribuito in ogni client o raccolta. Oltre che per la distribuzione di questi file, System Center Configuration Manager può essere usato per fare l'inventario dei file di catalogo attualmente distribuiti, per la creazione di report e la conformità. Esegui i passaggi seguenti per creare un nuovo pacchetto di distribuzione per i file di catalogo:

Nota

L'esempio seguente usa come origine per i file di catalogo una condivisione di rete denominata \\Shares\CatalogShare. Se hai file di catalogo specifici per raccolta o preferisci distribuirli separatamente, usa la struttura di cartelle più adatta alla tua organizzazione.

Apri la console di Configuration Manager e seleziona l'area di lavoro Raccolta software.
Passa a Panoramica\Gestione applicazioni, fai clic con il pulsante destro del mouse su Pacchetti e scegli Crea pacchetto.
Assegna il nome al pacchetto, imposta come produttore la tua organizzazione e seleziona un numero di versione appropriato (figura 16).

Figura 16. Specificare le informazioni sul nuovo pacchetto
Fai clic su Avanti e seleziona Programma standard come tipo di programma.
Nella pagina Programma standard seleziona un nome e quindi imposta la proprietà Riga di comando su XCopy \\Shares\CatalogShare C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} /H /K /E /Y.
Nella pagina Programma standard seleziona le opzioni seguenti (figura 17):
- In Nome digita Contoso Catalog File Copy Program.
- In Riga di comando passa al percorso del programma.
- In Cartella Esecuzione automatica digita C:\Windows\System32.
- Nell'elenco Esegui seleziona Nascosto.
- Nell'elenco Requisiti per esecuzione programma seleziona Indipendentemente dalla connessione degli utenti.
- Nell'elenco Modalità unità seleziona Viene eseguito con nome UNC.
Figura 17. Specificare le informazioni sul programma standard
Accetta le impostazioni predefinite per il resto della procedura guidata e quindi chiudi la procedura guidata.

Dopo aver creato il pacchetto di distribuzione, distribuiscilo in una raccolta in modo che i client ricevano i file di catalogo. In questo esempio distribuirai il pacchetto appena creato in una raccolta di test:

Nell'area di lavoro Raccolta software passa a Panoramica\Gestione applicazioni\Pacchetti, fai clic con il pulsante destro del mouse sul pacchetto del file di catalogo appena creato e quindi scegli Distribuisci.
Nella pagina Generale seleziona la raccolta di test in cui verranno distribuiti i file di catalogo e quindi fai clic su Avanti.
Nella pagina Contenuto fai clic su Aggiungi per selezionare il punto di distribuzione che servirà il contenuto alla raccolta selezionata e quindi fai clic su Avanti.
Nella pagina Impostazioni distribuzione seleziona Richiesto nella casella Scopo.
Nella pagina Pianificazione fai clic su Nuova.
Nella finestra di dialogo Pianificazione assegnazione seleziona Assegna subito dopo questo evento, imposta il valore su Appena possibile e quindi fai clic su OK.
Nella pagina Pianificazione fai clic su Avanti.
Nella pagina Esperienza utente (figura 18) imposta le opzioni seguenti e quindi fai clic su Avanti:
- Seleziona la casella di controllo Installazione software.
- Seleziona la casella di controllo Invia modifiche alla scadenza o in una finestra di manutenzione (riavvio necessario).
Figura 18. Specificare l'esperienza utente
Nella pagina Punti di distribuzione, nella casella Opzioni di distribuzione, seleziona Esegui programma dal punto di distribuzione e quindi fai clic su Avanti.
Nella pagina Riepilogo verifica i dettagli e fai clic su Avanti.
Chiudi la procedura guidata.

Inventario dei file di catalogo con System Center Configuration Manager

Una volta distribuiti i file di catalogo nel tuo ambiente, usando Criteri di gruppo oppure System Center Configuration Manager, puoi eseguirne l'inventario con la funzionalità di inventario software di System Center Configuration Manager. La procedura seguente ti guida nell'abilitazione dell'inventario software per individuare i file di catalogo presenti nei sistemi gestiti attraverso la creazione e la distribuzione di un nuovo criterio di impostazioni client.

Nota

L'uso di una convenzione di denominazione standard per i file di catalogo semplifica notevolmente il processo di inventario dei file di catalogo. In questo esempio, a tutti i nomi di file di catalogo è stato aggiunto -Contoso.

Apri la console di Configuration Manager e seleziona l'area di lavoro Amministrazione.
Passa a Panoramica\Impostazioni client, fai clic con il pulsante destro del mouse su Impostazioni client e quindi scegli Crea impostazioni dispositivo client personalizzate.
Assegna un nome al nuovo criterio e seleziona la casella di controllo Inventario software nell'elenco Seleziona e quindi configura le impostazioni personalizzate per i dispositivi client, come illustrato nella figura 19.

Figura 19. Selezionare le impostazioni personalizzate
Nel riquadro di spostamento fai clic su Inventario software e quindi su Imposta tipi, come illustrato nella figura 20.

Figura 20. Configurare l'inventario software
Nella finestra di dialogo Configura impostazione client fai clic sul pulsante Avvia per aprire la finestra di dialogo Proprietà file in inventario.
Nella casella Nome digita *Contoso.cat e quindi fai clic su Imposta.

Nota

*Contoso.cat è la convenzione di denominazione usata in questo esempio. Dovrebbe riprodurre la convenzione di denominazione che usi per i tuoi file di catalogo.
Nella finestra di dialogo Proprietà percorso seleziona Nome percorso o variabile e quindi digita C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} nella casella, come illustrato nella figura 21.

Figura 21. Impostare le proprietà del percorso
Fai clic su OK.
Ora che hai creato il criterio di impostazioni client, fai clic con il pulsante destro del mouse sul nuovo criterio, scegli Distribuisci e quindi scegli la raccolta in cui vuoi inventariare i file di catalogo.

Al momento del successivo ciclo di inventario software, quando i client di destinazione riceveranno il nuovo criterio di impostazioni client, potrai vedere i file in inventario nei report predefiniti di System Center Configuration Manager o in Esplora inventario risorse. Per visualizzare i file in inventario in un client all'interno di Esplora inventario risorse, procedi come segue:

Apri la console di Configuration Manager e seleziona l'area di lavoro Asset e conformità.
Passa a Panoramica\Dispositivi e cerca il dispositivo in cui vuoi visualizzare i file in inventario.
Fai clic con il pulsante destro del mouse sul computer, scegli Avvia e quindi fai clic su Esplora inventario risorse.
In Esplora inventario risorse passa a Software\Dettagli file per vedere i file di catalogo in inventario.

Nota

Se in questa visualizzazione non compare nulla, passa a Software\Ultima analisi software in Esplora inventario risorse per verificare che il client abbia completato di recente un'analisi dell'inventario software.

Criteri di integrità del codice

I criteri di integrità del codice stabiliscono gli standard in base a cui un computer che esegue Windows 10 determina se un'applicazione è attendibile e può essere eseguita. Per una panoramica sull'integrità del codice, vedi la sezione Integrità del codice configurabile.

Oggi nelle organizzazioni IT è prassi comune creare un'immagine di riferimento che rappresenta un sistema con configurazione ottimale e usarla per clonare altre risorse aziendali. I criteri di integrità del codice seguono una metodologia simile, che inizia con la creazione di un PC di riferimento. Come per la creazione di immagini, puoi creare più PC di riferimento in base al modello, al reparto, al set di applicazioni e così via. Anche se a livello teorico la creazione di criteri di integrità del codice è simile alla creazione di immagini, questi criteri devono essere gestiti in modo indipendente. Valuta la necessità di criteri di integrità del codice aggiuntivi in base a ciò che occorre permettere di installare ed eseguire e a chi.

Nota

Ogni computer può avere un solo criterio di integrità del codice alla volta. In qualunque modo tu distribuisca il criterio, questo viene rinominato in SIPolicy.p7b e copiato in C:\Windows\System32\CodeIntegrity. Tienilo a mente quando crei i tuoi criteri di integrità del codice.

Facoltativamente, i criteri di integrità del codice possono essere allineati al catalogo di software e a tutte le applicazioni approvate dal reparto IT. Un metodo semplice per implementare i criteri di integrità del codice consiste nell'usare immagini esistenti per creare un criterio di integrità del codice master. A questo scopo, devi creare un criterio di integrità del codice da ogni immagine e quindi unire i criteri. In questo modo sarà consentita l'esecuzione di tutto ciò che è installato nelle immagini, nel caso in cui le applicazioni fossero installate in un computer basato su un'immagine diversa. In alternativa, puoi scegliere di creare un criterio per le applicazioni di base e aggiungere criteri in base al ruolo del computer o al reparto. Le organizzazioni hanno varie opzioni fra cui scegliere per creare, unire, eseguire la manutenzione e gestire i propri criteri.

Nota

La sezione seguente presuppone che distribuirai i criteri di integrità del codice nell'ambito della distribuzione di Device Guard. In alternativa, l'integrità del codice configurabile è disponibile senza abilitare Device Guard.

Regole dei criteri di integrità del codice

I criteri di integrità del codice sono costituiti da vari componenti. I due componenti principali, che sono configurabili, sono denominati regole dei criteri e regole dei file. Le regole dei criteri di integrità del codice sono opzioni che il creatore può specificare per il criterio. Queste opzioni includono l'abilitazione della modalità di controllo, dell'integrità del codice in modalità utente e così via. Puoi modificare queste opzioni in un criterio di integrità del codice nuovo o esistente. Le regole dei file sono il livello a cui l'analisi dei criteri di integrità del codice associa l'attendibilità di ogni file binario. Ad esempio, il livello Hash elencherà in dettaglio ogni hash individuato nel sistema all'interno del criterio di integrità del codice generato. In questo modo, quando un file binario si prepara all'esecuzione, il servizio di integrità del codice convaliderà il suo valore hash rispetto agli hash attendibili trovati nel criterio di integrità del codice. In base a tale risultato, l'esecuzione del file binario verrà consentita o negata.

Per modificare le opzioni delle regole di un criterio di integrità del codice esistente, usa il cmdlet di Windows PowerShell Set-RuleOption. Ecco alcuni esempi di come usare questo cmdlet per aggiungere e rimuovere un'opzione della regola in un criterio di integrità del codice esistente:

Per abilitare l'integrità del codice in modalità utente, aggiungi l'opzione della regola 0 a un criterio esistente eseguendo il comando seguente:

Set-RuleOption -Option 0 -FilePath <Path to policy>
Per disabilitare l'integrità del codice in modalità utente in un criterio di integrità del codice esistente, rimuovi l'opzione della regola 0 eseguendo il comando seguente:

Set-RuleOption -Option 0 -FilePath <Path to policy> -Delete

All'interno di un criterio di integrità del codice puoi impostare diverse opzioni delle regole. La tabella 2 contiene un elenco delle regole e del relativo significato.

Tabella 2. Criteri di integrità del codice - opzioni delle regole dei criteri

Opzione della regola	Descrizione
0 Enabled:UMCI	I criteri di integrità del codice limitano i file binari sia in modalità kernel che in modalità utente. Per impostazione predefinita, sono limitati solo i file binari in modalità kernel. Abilitando questa opzione della regola vengono convalidati script ed eseguibili in modalità utente.
1 Enabled:Boot Menu Protection	Questa opzione non è attualmente supportata.
2 Required:WHQL	Per impostazione predefinita, l'esecuzione dei driver legacy non firmati da WHQL ( Windows Hardware Quality Labs ) è consentita. Abilitando questa regola, tutti i driver eseguiti devono essere firmati da WHQL e il supporto dei driver legacy viene rimosso. In futuro, tutti i nuovi driver compatibili con Windows 10 dovranno essere certificati da WHQL.
3 Enabled:Audit Mode (impostazione predefinita)	Abilita l'esecuzione dei file binari al di fuori del criterio di integrità del codice, ma registra ogni occorrenza nel registro eventi CodeIntegrity, che può essere usato per aggiornare il criterio esistente prima dell'imposizione. Per imporre un criterio di integrità del codice, rimuovi questa opzione.
4 Disabled:Flight Signing	Se abilitata, i criteri di integrità del codice non considereranno attendibili i file binari firmati in versione di anteprima. Può essere usata in uno scenario in cui le organizzazioni vogliono eseguire solo file binari rilasciati, non build in versione di anteprima.
5 Enabled:Inherent Default Policy	Questa opzione non è attualmente supportata.
6 Enabled:Unsigned System Integrity Policy (impostazione predefinita)	Consente che il criterio resti senza firma. Quando questa opzione viene rimossa, il criterio deve essere firmato con un certificato aggiunto alla sezione UpdatePolicySigners del criterio stesso, per abilitare le future modifiche.
7 Allowed:Debug Policy Augmented	Questa opzione non è attualmente supportata.
8 Required:EV Signers	Questa regola richiede che i driver, oltre a essere firmati da WHQL, siano stati inviati da un partner con certificato di convalida estesa. Tutti i driver futuri di Windows 10 e versioni successive soddisferanno questo requisito.
9 Enabled:Advanced Boot Options Menu	Il menu delle opzioni prima dell'avvio F8 è disabilitato per impostazione predefinita per tutti i criteri di integrità del codice. Impostando questa opzione della regola, gli utenti fisicamente presenti possono visualizzare il menu F8.
10 Enabled:Boot Audit on Failure	Usato quando il criterio di integrità del codice è in modalità di imposizione. In caso di errore di un driver in fase di avvio, il criterio di integrità del codice viene posto in modalità di controllo, per permettere il caricamento di Windows. Gli amministratori possono verificare il motivo dell'errore nel registro eventi CodeIntegrity.

I livelli delle regole dei file permettono agli amministratori di specificare il livello di attendibilità delle applicazioni. Il livello di attendibilità va da basso, come il valore hash di ogni file binario, ad elevato, come il certificato PCA. I livelli delle regole dei file si specificano sia quando crei un nuovo criterio di integrità di codice da un'analisi, sia quando lo crei dagli eventi di controllo. Inoltre, per combinare i livelli delle regole di più criteri, puoi unire i criteri. Quando unisci criteri di integrità del codice, le rispettive regole dei file vengono combinate. Ogni livello delle regole dei file presenta vantaggi e svantaggi. Usa la tabella 3 per selezionare il livello di protezione appropriato per le risorse amministrative disponibili e lo scenario di distribuzione di Device Guard.

Tabella 3. Criteri di integrità del codice - Livelli delle regole dei file

Livello regola	Descrizione
Hash	Specifica i singoli valori hash per ogni file binario individuato. Anche se si tratta di un livello specifico, può aumentare il carico amministrativo per la necessità di mantenere aggiornati i valori hash delle versioni correnti dei prodotti. Ogni volta che un file binario viene aggiornato il valore hash cambia, pertanto è necessario aggiornare i criteri.
FileName	Specifica i nomi dei singoli file binari. Anche se i valori hash di un'applicazione cambiano quando viene aggiornata, in genere i nomi del file restano invariati. Questo livello offre una protezione meno specifica rispetto al livello Hash, ma in genere non richiede l'aggiornamento dei criteri quando un file binario viene modificato.
SignedVersion	Combina la regola Publisher con un numero di versione del file. Questa opzione consente l'esecuzione di tutti i file dell'autore specificato con versione file uguale o superiore al numero di versione specificato.
Publisher	È una combinazione del certificato PCA e del nome comune (CN) sul certificato foglia. Nello scenario in cui si usa un certificato PCA per firmare applicazioni di più aziende, come VeriSign, questo livello della regola consente alle organizzazioni di considerare attendibile il certificato PCA, ma solo per l'azienda il cui nome è presente sul certificato foglia (ad esempio Intel per i driver di dispositivo). Questo livello considera attendibile un certificato con un lungo periodo di validità, ma solo se combinato con un certificato foglia attendibile.
FilePublisher	È una combinazione dei livelli Publisher e SignedVersion. Vengono considerati attendibili tutti i file firmati dell'autore attendibile con versione uguale o successiva a quella specificata.
LeafCertificate	Aggiunge firmatari attendibili a livello di certificato di firma singolo. Il vantaggio dell'uso di questo livello rispetto al livello di singolo hash è che le nuove versioni del prodotto avranno valori hash diversi, ma in genere lo stesso certificato di firma. Usando questo livello, per eseguire la nuova versione dell'applicazione non è necessario l'aggiornamento dei criteri. I certificati foglia, tuttavia, hanno un periodo di validità molto più breve rispetto ai certificati PCA, quindi occorre considerare il carico amministrativo associato all'aggiornamento dei criteri di integrità del codice alla scadenza.
PcaCertificate	Aggiunge ai firmatari il certificato più elevato della catena di certificati. Si tratta in genere di un certificato immediatamente al di sotto del certificato radice, dato che l'analisi non convalida gli elementi al di sopra della firma presentata mediante connessione online o controllo degli archivi radice locali.
RootCertificate	Attualmente non supportato.
WHQL	Considera attendibili i file binari convalidati e firmati da WHQL. È principalmente per i file binari del kernel.
WHQLPublisher	È una combinazione della firma WHQL e del nome comune (CN) sul certificato foglia ed è principalmente per i file binari del kernel.
WHQLFilePublisher	Specifica che i file binari devono essere convalidati e firmati da WHQL, devono avere un autore specifico (WHQLPublisher) e che il file binario deve essere della versione specificata o successiva. È principalmente per i file binari del kernel.

Nota

Quando crei criteri di integrità del codice con il cmdlet New-CIPolicy, puoi specificare un livello primario delle regole dei file includendo il parametro –Level. Per i file binari individuati che non possono essere considerati attendibili in base ai criteri del livello primario delle regole dei file, usa il parametro –Fallback. Ad esempio, se il livello primario delle regole dei file è PCACertificate, ma vuoi considerare attendibili anche le applicazioni non firmate, usando il livello delle regole Hash come fallback verranno aggiunti i valori hash dei file binari che non posseggono un certificato di firma.

Creare criteri di integrità del codice da PC di riferimento

La procedura per creare un criterio di integrità del codice di riferimento da un sistema di riferimento è semplice. Questa sezione descrive la procedura necessaria per creare correttamente un criterio di integrità del codice con Windows PowerShell. Per questo esempio, prima di tutto devi inizializzare le variabili da usare durante il processo di creazione. Anziché usare variabili, puoi semplicemente usare nel comando i percorsi file completi. In seguito, creerai il criterio di integrità del codice analizzando il sistema per individuare le applicazioni installate. Dopo la creazione, il file di criteri viene convertito in formato binario in modo che Windows possa utilizzarne il contenuto.

Nota

Prima di iniziare questa procedura, verifica che il PC di riferimento sia privo di virus e malware. Prima di creare questo criterio, è necessario verificare che ogni componente software installato sia attendibile. Prima di creare il criterio di integrità del codice, assicurati anche che tutto il software che vuoi analizzare sia installato nel sistema.

Per creare un criterio di integrità del codice, copia ognuno dei comandi seguenti in una sessione di Windows PowerShell con privilegi elevati, in quest'ordine:

Inizializza le variabili che userai:

$CIPolicyPath=$env:userprofile+"\Desktop\"

$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

$CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"
Crea un nuovo criterio di integrità del codice analizzando il sistema per individuare le applicazioni installate:

New-CIPolicy -Level PcaCertificate -FilePath $InitialCIPolicy –UserPEs 3> CIPolicyLog.txt

Nota

Specificando il parametro –UserPEs, l'opzione della regola 0 Enabled:UMCI viene aggiunta automaticamente al criterio di integrità del codice. Se non specifichi questo parametro, usa il comando seguente per abilitare l'integrità del codice in modalità utente:

Set-RuleOption -Option 0 -FilePath $InitialCIPolicy

Nota

Puoi aggiungere il parametro –Fallback per rilevare le applicazioni non individuate tramite il livello primario delle regole dei file specificato dal parametro –Level. Per altre informazioni sulle opzioni dei livelli delle regole dei file, vedi la sezione Regole dei criteri di integrità del codice.

Nota

Se vuoi specificare che l'analisi dei criteri di integrità del codice cerchi solo in un'unità specifica, puoi farlo usando il parametro –ScanPath. Senza questo parametro, come illustrato nell'esempio, verrà analizzato l'intero sistema.
Convertire il criterio di integrità del codice in un formato binario:

ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin

Dopo aver completato questi passaggi, il file binario di Device Guard (DeviceGuardPolicy.bin) e il file xml originale (InitialScan.xml) saranno disponibili sul tuo desktop. Puoi usare la versione binaria come criterio di integrità del codice o firmarla per una maggiore sicurezza.

Nota

Microsoft consiglia di conservare il file .xml originale del criterio, per usarlo quando avrai bisogno di unirlo a un altro criterio oppure di aggiornare le opzioni delle regole. In caso contrario, per la manutenzione dovrai creare un nuovo criterio da una nuova analisi. Per altre informazioni sull'unione dei criteri di integrità del codice, vedi la sezione Unire i criteri di integrità del codice.

Microsoft consiglia di eseguire tutti i criteri di integrità del codice in modalità di controllo prima di imporli. In questo modo, gli amministratori potranno individuare eventuali problemi relativi al criterio senza visualizzare finestre di dialogo con messaggi di errore. Per informazioni su come controllare i criteri di integrità del codice, vedi la sezione Controllare i criteri di integrità del codice.

Controllare i criteri di integrità del codice

Quando i criteri di integrità del codice vengono eseguiti in modalità di controllo, permettono agli amministratori di individuare tutte le applicazioni eventualmente non rilevate durante l'analisi iniziale e di identificare le nuove applicazioni installate ed eseguite dopo la creazione del criterio originale. Quando un criterio di integrità del codice è in esecuzione in modalità di controllo, tutti i file binari che vengono eseguiti, ma la cui esecuzione sarebbe stata bloccata in caso di imposizione del criterio, vengono registrati nel registro eventi Registri applicazioni e servizi\Microsoft\CodeIntegrity\Operational. Dopo la convalida, sarà possibile aggiungere facilmente questi file binari a un nuovo criterio di integrità del codice. Una volta creato il nuovo criterio di eccezione, potrai unirlo ai criteri di integrità del codice esistenti.

Nota

Prima di iniziare questa procedura, devi creare un criterio di integrità del codice in formato binario. Se non l'hai già fatto, vedi la sezione Creare criteri di integrità del codice per istruzioni dettagliate.

Per controllare un criterio di integrità del codice con l'Editor Criteri di gruppo locali:

Copia il file DeviceGuardPolicy.bin che hai creato nella sezione Creare criteri di integrità del codice da PC di riferimento in C:\Windows\System32\CodeIntegrity.
Nel sistema che vuoi eseguire in modalità di controllo apri l'Editor Criteri di gruppo locali eseguendo GPEdit.msc.
Passa a Configurazione computer\Modelli amministrativi\Sistema\Device Guard e seleziona Distribuisci criteri di integrità del codice. Abilita questa impostazione usando il percorso del file C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin, come illustrato nella figura 22.

Nota

Non è necessario usare il nome criterio DeviceGuardPolicy.bin. Questo è semplicemente il nome che è stato usato nella sezione Creare criteri di integrità del codice da PC di riferimento e quindi viene usato anche qui. Inoltre, non è necessario copiare questo file di criteri in tutti i sistemi. In alternativa, puoi copiare i criteri di integrità del codice in una condivisione file accessibile a tutti gli account computer.

Nota

Tutti i criteri che selezionerai qui verranno rinominati in SIPolicy.p7b quando verranno distribuiti nei singoli computer.

Figura 22. Distribuire il criterio di integrità del codice

Nota

Puoi aver notato che l'impostazione dell'oggetto Criteri di gruppo fa riferimento a un file .p7b e questo criterio usa un file .bin. Indipendentemente dal tipo (.bin, .p7b o .p7), quando vengono distribuiti nei computer Windows 10 tutti i criteri vengono rinominati in SIPolicy.p7b. Microsoft consiglia di usare nomi descrittivi per i tuoi criteri di integrità del codice e consentire al sistema di convertire automaticamente i nomi. Così facendo, i criteri saranno facilmente distinguibili quando vengono visualizzati in una condivisione o in qualsiasi repository centrale.
Riavvia il sistema di riferimento per rendere effettivo il criterio di integrità del codice.
Controlla il registro eventi CodeIntegrity. In modalità di controllo, le eccezioni al criterio di integrità del codice distribuito saranno registrate nel registro eventi Registri applicazioni e servizi\Microsoft\CodeIntegrity\Operational, come illustrato nella figura 23.

Figura 23. Eccezioni al criterio di integrità del codice distribuito
Convalida le eccezioni al criterio di integrità del codice.

Dopo aver eseguito un criterio di integrità del codice in modalità di controllo, Microsoft consiglia di esaminare e convalidare tutte le eccezioni registrate. Oltre a individuare quale applicazione sta causando l'eccezione e a verificare che sia opportuno aggiungerla al criterio di integrità del codice, assicurati di controllare il livello di file da usare per considerare attendibile ogni applicazione Anche se il livello Hash intercetta tutte le eccezioni, potrebbe non rappresentare il modo migliore per considerare attendibili tutte le eccezioni. Per informazioni sui livelli delle regole dei file e il relativo scopo, vedi la sezione Regole dei criteri di integrità del codice.
Crea criteri di integrità del codice dagli eventi di controllo.

Per informazioni su come creare criteri di integrità del codice da eventi di controllo, vedi la sezione Creare criteri di integrità del codice da PC di riferimento.

Nota

Un metodo alternativo per testare i criteri consiste nel rinominare il file di test in SIPolicy.p7b e copiarlo in C:\Windows\System32\CodeIntegrity, anziché distribuirlo con il criterio del computer locale.

Creare un criterio di integrità del codice di controllo

Quando esegui i criteri di integrità del codice in modalità di controllo, convalida tutte le eventuali eccezioni e stabilisci se sarà necessario aggiungerle al criterio di integrità del codice che vuoi controllare. Usa il sistema come di consueto per assicurarti che tutte le eventuali eccezioni siano rilevate. Quando sei pronto per creare un criterio di integrità del codice dagli eventi di controllo, esegui la procedura seguente in una sessione di Windows PowerShell con privilegi elevati:

Inizializza le variabili che verranno usate:

$CIPolicyPath=$env:userprofile+"\Desktop\"

$CIAuditPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"
Analizza i risultati del controllo.

Prima di creare un criterio di integrità del codice da eventi di controllo, Microsoft consiglia di analizzare ogni eccezione, come descritto nei passaggi 5 e 6 della sezione Controllare i criteri di integrità del codice.
Genera un nuovo criterio di integrità del codice dagli eventi di controllo registrati:

New-CIPolicy -Audit -Level Hash -FilePath $CIAuditPolicy –UserPEs 3> CIPolicylog.txt

Nota

Quando crei criteri dagli eventi di controllo, valuta attentamente il livello delle regole dei file che scegli di considerare attendibile. In questo esempio userai il livello Hash, che deve essere usato come ultima risorsa.

Dopo aver completato questi passaggi, il file XML del criterio di controllo di Device Guard (DeviceGuardAuditPolicy.xml) sarà disponibile sul desktop. Puoi usare questo file per aggiornare il criterio di integrità del codice esistente che hai eseguito in modalità di controllo unendo i due criteri. Per istruzioni su come unire questo criterio di controllo con il criterio di integrità del codice esistente, vedi la sezione Unire i criteri di integrità del codice.

Nota

Potresti aver notato che non hai generato una versione binaria di questo criterio come hai fatto nella sezione Creare criteri di integrità del codice da PC di riferimento. Il motivo è che i criteri di integrità del codice creati da un log di controllo non sono progettati per essere eseguiti come criteri autonomi, ma per aggiornare i criteri di integrità del codice esistenti.

Unire i criteri di integrità del codice

Quando si sviluppi i criteri di integrità del codice, ti capiterà di dover unire due criteri. Un esempio comune è quando viene creato e controllato un criterio di integrità del codice iniziale. Un altro esempio è quando crei un singolo criterio master usando più criteri di integrità del codice creati in precedenza da PC di riferimento. Poiché ogni computer Windows 10 può avere un solo criterio di integrità del codice, è importante gestire i criteri in modo corretto. In questo esempio, gli eventi di controllo sono stati salvati in un criterio di integrità del codice secondario che unirai al criterio iniziale.

Nota

L'esempio seguente usa i file XML dei criteri di integrità del codice che hai creato nelle sezioni Creare criteri di integrità del codice da PC di riferimento e Controllare i criteri di integrità del codice. Puoi comunque seguire la procedura con qualsiasi coppia di criteri di integrità del codice tu voglia combinare.

Per unire due criteri di integrità del codice, esegui la procedura seguente in una sessione di Windows PowerShell con privilegi elevati:

Inizializza le variabili che verranno usate:

$CIPolicyPath=$env:userprofile+"\Desktop\"

$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

$AuditCIPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"

$MergedCIPolicy=$CIPolicyPath+"MergedPolicy.xml"

$CIPolicyBin=$CIPolicyPath+"NewDeviceGuardPolicy.bin"

Nota

Le variabili in questa sezione prevedono di trovare sul tuo desktop un criterio iniziale denominato InitialScan.xml e un criterio di integrità del codice di controllo denominato DeviceGuardAuditPolicy.xml. Se vuoi unire altri criteri di integrità del codice, aggiorna le variabili di conseguenza.
Unisci due criteri per creare un nuovo criterio di integrità del codice:

Merge-CIPolicy -PolicyPaths $InitialCIPolicy,$AuditCIPolicy -OutputFilePath $MergedCIPolicy
Converti il criterio di integrità del codice unito in formato binario:

ConvertFrom-CIPolicy $MergedCIPolicy $CIPolicyBin

Ora che hai creato un nuovo criterio di integrità del codice denominato NewDeviceGuardPolicy.bin, puoi distribuirlo nei sistemi manualmente oppure usando Criteri di gruppo o altre soluzioni Microsoft di gestione client. Per informazioni su come distribuire il nuovo criterio con Criteri di gruppo, vedi la sezione Distribuire e gestire i criteri di integrità del codice con Criteri di gruppo.

Imporre i criteri di integrità del codice

Tutti i criteri di integrità del codice vengono creati con la modalità di controllo abilitata. Dopo aver completato la distribuzione e il test di un criterio di integrità del codice in modalità di controllo, sei pronto per testarlo in modalità di imposizione. Esegui le operazioni seguenti in una sessione di Windows PowerShell con privilegi elevati:

Nota

Tutti i criteri di integrità del codice vanno prima testati in modalità di controllo. Per informazioni sul controllo dei criteri di integrità del codice, vedi la sezione Controllare i criteri di integrità del codice.

Inizializza le variabili che verranno usate:

$CIPolicyPath=$env:userprofile+"\Desktop\"

$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

$EnforcedCIPolicy=$CIPolicyPath+"EnforcedPolicy.xml"

$CIPolicyBin=$CIPolicyPath+"EnforcedDeviceGuardPolicy.bin"

Nota

Il criterio di integrità del codice iniziale a cui fa riferimento questa sezione è stato creato nella sezione Creare criteri di integrità del codice da PC di riferimento. Se usi un criterio di integrità del codice diverso, aggiorna le variabili CIPolicyPath e InitialCIPolicy.
Copia il file iniziale per conservare una copia originale:

cp $InitialCIPolicy $EnforcedCIPolicy
Rimuovi l'opzione della regola in modalità di controllo:

Set-RuleOption -Option 3 -FilePath $EnforcedCIPolicy -Delete

Nota

Anziché aggiungere un'opzione Enforced, i criteri di integrità del codice vengono imposti in modo implicito se non è presente l'opzione Audit Mode Enabled.
Converti il nuovo criterio di integrità del codice in formato binario:

ConvertFrom-CIPolicy $EnforcedCIPolicy $CIPolicyBin

Nota

Microsoft consiglia vivamente di abilitare le opzioni delle regole 9 e 10 prima di eseguire per la prima volta qualsiasi criterio imposto. Se sono già presenti nel criterio, non rimuoverle. Questo consente l'avvio di Windows anche se il criterio di integrità del codice blocca l'esecuzione di un driver in modalità kernel e in più offre agli amministratori un prompt dei comandi prima dell'avvio. Quando sarai pronto per la distribuzione aziendale, potrai rimuovere queste opzioni.

Ora che il criterio è stato imposto, puoi distribuirlo nei computer di test. Rinomina il criterio in SIPolicy.p7b e copialo in C:\Windows\System32\CodeIntegrity per il test oppure distribuiscilo mediante Criteri di gruppo seguendo le istruzioni nella sezione Distribuire e gestire i criteri di integrità del codice con Criteri di gruppo o mediante un software di gestione client seguendo le istruzioni nella sezione "Distribuzione e gestione dei criteri di integrità del codice con soluzioni Microsoft di gestione client".

Firma dei criteri di integrità del codice con SignTool.exe

I criteri di integrità del codice firmati offrono alle organizzazioni il massimo livello di protezione da malware disponibile in Windows 10. In aggiunta alle regole imposte nel criterio stesso, i criteri firmati non possono essere modificati o eliminati da un utente o un amministratore del computer. Questi criteri sono progettati per impedire la manomissione da parte degli amministratori e l'accesso tramite exploit alla modalità kernel. Tenendo conto di questo aspetto, rimuovere criteri di integrità del codice firmati è molto più difficile rispetto a quelli non firmati. Prima di firmare e distribuire un criterio di integrità del codice firmato, Microsoft consiglia di controllare il criterio per individuare eventuali applicazioni bloccate la cui esecuzione deve invece essere consentita. Per altre informazioni sul controllo dei criteri di integrità del codice, vedi la sezione Controllare i criteri di integrità del codice.

Firmare i criteri di integrità del codice con un certificato generato da un'Autorità di certificazione (CA) interna o un certificato di firma del codice acquistato è molto semplice. Se attualmente non hai un certificato di firma del codice esportato in formato .pfx (contenente chiavi private, estensioni e certificati radice), vedi Creare un certificato di firma del codice per Device Guard per crearne uno con la CA della tua azienda. Prima di firmare criteri di integrità del codice per la prima volta, assicurati di abilitare le opzioni delle regole 9 e 10 per lasciare le opzioni di risoluzione dei problemi a disposizione di chi si occupa del test. Dopo la convalida e quando sarai pronto per la distribuzione aziendale, potrai rimuovere queste opzioni. Per informazioni su come aggiungere opzioni delle regole, vedi la sezione Regole dei criteri di integrità del codice.

Nota

Firmare i criteri di integrità del codice è l'ultimo passaggio in una distribuzione dell'integrità del codice. Rimuovere un criterio di integrità del codice firmato è molto più difficile rispetto a rimuoverne uno non firmato. Prima di distribuire un criterio di integrità del codice firmato nei computer client distribuiti, assicurati di testarne gli effetti su un subset di computer.

Per firmare un criterio di integrità del codice con SignTool.exe sono necessari i componenti seguenti:

SignTool.exe, disponibile in Windows SDK per Windows 7 o versioni successive
File in formato binario del criterio di integrità del codice che hai creato nella sezione Creare criteri di integrità del codice da PC di riferimento o di un altro criterio di integrità del codice creato da te
Un certificato di firma del codice della CA interna o un certificato di firma del codice acquistato

Se non hai un certificato di firma del codice, vedi la sezione Creare un certificato di firma del codice per Device Guard per istruzioni su come crearne uno. Se usi un certificato o un criterio di integrità del codice alternativo, aggiorna i passaggi seguenti con il certificato e le variabili appropriate in modo che i comandi funzionino correttamente. Per firmare il criterio di integrità del codice esistente, copia ognuno dei comandi seguenti in una sessione di Windows PowerShell con privilegi elevati:

Inizializza le variabili che verranno usate:

$CIPolicyPath=$env:userprofile+"\Desktop\" $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml" $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"

Nota

Questo esempio usa il criterio di integrità del codice creato nella sezione Creare criteri di integrità del codice da PC di riferimento. Se vuoi firmare un altro criterio, assicurati di aggiornare le variabili $CIPolicyPath e $CIPolicyBin con le informazioni corrette.
Importa il certificato di firma del codice in formato .pfx. Importa il certificato di firma del codice che userai per firmare il criterio di integrità del codice nell'archivio personale dell'utente firmatario nel computer che userai per la firma. In questo esempio userai il certificato creato nella sezione Creare un certificato di firma del codice per Device Guard.
Esporta il certificato di firma del codice in formato .cer. Dopo l'importazione del certificato di firma del codice, esporta la versione .cer sul tuo desktop. Questa versione sarà aggiunta al criterio in modo che sia possibile aggiornarlo in seguito.
Passa al desktop come directory di lavoro:

cd $env:USERPROFILE\Desktop
Aggiungi un certificato firmatario per l'aggiornamento al criterio di integrità del codice:

Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update

Nota

<Path to exported .cer certificate> deve essere il percorso completo del certificato che hai esportato al passaggio 3.

Nota

L'aggiunta di firmatari per l'aggiornamento è essenziale per poter modificare o disabilitare il criterio in futuro. Per altre informazioni su come disabilitare i criteri di integrità del codice firmati, vedi la sezione Disabilitare criteri di integrità del codice firmati in Windows.
Rimuovi l'opzione della regola che consente i criteri non firmati:

Set-RuleOption -Option 6 -FilePath $InitialCIPolicy -Delete
Converti il criterio in formato binario:

ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin
Firma il criterio di integrità del codice usando SignTool.exe:

<Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin

Nota

La variabile <Path to signtool.exe> deve corrispondere al percorso completo dell'utilità SignTool.exe. ContosoDGSigningCert è il nome soggetto del certificato che verrà usato per firmare il criterio di integrità del codice. Devi importare questo certificato nel tuo archivio certificati personale nel computer che usi per firmare il criterio.
Convalida il file firmato. Al termine, i comandi devono generare un file di criteri firmato denominato DeviceGuardPolicy.bin.p7 sul desktop. Puoi distribuire questo file con la stessa procedura usata per distribuire un criterio imposto o non imposto. Per informazioni su come distribuire i criteri di integrità del codice, vedi la sezione Distribuire e gestire i criteri di integrità del codice con Criteri di gruppo.

Disabilitare i criteri di integrità codice non firmati

Può arrivare il momento in cui un amministratore vuole disabilitare un criterio di integrità del codice. Per i criteri di integrità del codice non firmati, la procedura è semplice. I criteri non firmati si possono disabilitare in due modi, in base al modo in cui sono stati distribuiti. Se un criterio di integrità del codice è stato abilitato e copiato manualmente nel percorso della cartella CodeIntegrity, basta eliminare il file e riavviare il computer. I criteri di integrità del codice in esecuzione possono trovarsi nei percorsi seguenti:

<Partizione di sistema EFI>\Microsoft\Boot\
<Volume sistema operativo>\Windows\System32\CodeIntegrity\

Se il criterio di integrità del codice è stato distribuito tramite Criteri di gruppo, devi disabilitare l'oggetto Criteri di gruppo che sta attualmente abilitando e distribuendo il criterio. Fatto questo, al successivo riavvio del computer il criterio di integrità del codice sarà disabilitato.

Disabilitare criteri di integrità del codice firmati in Windows

I criteri firmati proteggono Windows dalla manipolazione da parte degli amministratori, oltre che dal malware che dovesse ottenere accesso al sistema a livello amministrativo. Per questo motivo, i criteri di integrità del codice firmati sono volutamente più difficili da rimuovere dei criteri non firmati. Si proteggono intrinsecamente dalla modifica o dalla rimozione e pertanto sono difficili da rimuovere anche per gli amministratori. Se il criterio di integrità del codice firmato è stato abilitato e copiato manualmente nella cartella CodeIntegrity, per rimuovere il criterio devi eseguire i passaggi seguenti:

Nota

Come riferimento, i criteri di integrità del codice firmati vanno sostituiti e rimossi dai percorsi seguenti:

<Partizione di sistema EFI>\Microsoft\Boot\
<Volume sistema operativo>\Windows\System32\CodeIntegrity\

Sostituisci il criterio esistente con un altro criterio firmato che abbia l'opzione della regola 6 Enabled: Unsigned System Integrity Policy abilitata.

Nota

Perché questo criterio diventi effettivo, deve essere firmato con un certificato precedentemente aggiunto alla sezione UpdatePolicySigners del criterio firmato originale che vuoi sostituire.
Riavvia il computer client.
Verifica la presenza del nuovo criterio firmato nel client.

Nota

Se il criterio firmato che contiene l'opzione della regola 6 non è stato elaborato nel client, l'aggiunta di un criterio non firmato può causare errori di avvio.
Elimina il nuovo criterio.
Riavvia il computer client.

Se il criterio di integrità del codice firmato è stato distribuito tramite Criteri di gruppo, devi eseguire i passaggi seguenti:

Sostituisci il criterio esistente nell'oggetto Criteri di gruppo con un altro criterio firmato che abbia l'opzione della regola 6 Enabled: Unsigned System Integrity Policy abilitata.

Nota

Perché questo criterio diventi effettivo, deve essere firmato con un certificato precedentemente aggiunto alla sezione UpdatePolicySigners del criterio firmato originale che vuoi sostituire.
Riavvia il computer client.
Verifica la presenza del nuovo criterio firmato nel client.

Nota

Se il criterio firmato che contiene l'opzione della regola 6 non è stato elaborato nel client, l'aggiunta di un criterio non firmato può causare errori di avvio.
Disabilita l'oggetto Criteri di gruppo.
Elimina il nuovo criterio.
Riavvia il computer client.

Disabilitare criteri di integrità del codice firmati nel BIOS

Può capitare che i criteri di integrità del codice firmati causino un errore di avvio. Poiché i criteri di integrità del codice si applicano ai driver in modalità kernel, è importante che siano accuratamente testati per ogni configurazione hardware e software prima di essere imposti e firmati. I criteri di integrità del codice firmati vengono convalidati nella sequenza prima dell'avvio usando l'avvio protetto. Quando disabiliti la funzionalità di avvio protetto nel BIOS e quindi elimini il file dai percorsi seguenti nel disco del sistema operativo, il sistema può avviarsi in Windows:

<Partizione di sistema EFI>\Microsoft\Boot\
<Volume sistema operativo>\Windows\System32\CodeIntegrity\

Distribuire e gestire i criteri di integrità del codice con Criteri di gruppo

Criteri di gruppo permette di distribuire e gestire facilmente i criteri di integrità del codice. In Windows Server 2016 sarà disponibile un modello amministrativo che semplifica la distribuzione delle funzionalità di sicurezza basata su hardware di Device Guard e dei criteri di integrità del codice. La procedura seguente ti guida nella distribuzione di un criterio di integrità del codice denominato DeviceGuardPolicy.bin in un'unità organizzativa di test denominata DG Enabled PCs usando un oggetto Criteri di gruppo denominato Contoso GPO Test.

Nota

Questa procedura richiede che tu abbia già creato un criterio di integrità del codice e disponga di un PC client Windows 10 in cui testare una distribuzione di Criteri di gruppo. Per altre informazioni su come creare un criterio di integrità del codice, vedi la sezione Creare criteri di integrità del codice da PC di riferimento.

Nota

Al momento della distribuzione, i criteri di integrità del codice firmati possono causare errori di avvio. Microsoft consiglia di testare accuratamente i criteri di integrità del codice firmati su tutte le piattaforme hardware prima della distribuzione aziendale.

Per distribuire e gestire un criterio di integrità del codice con Criteri di gruppo:

In un controller di dominio in un computer client in cui è installato Strumenti di amministrazione remota del server apri la console Gestione Criteri di gruppo eseguendo GPMC.MSC o cercando "Gestione Criteri di gruppo" in Windows Search.
Crea un nuovo oggetto Criteri di gruppo: fai clic con il pulsante destro del mouse sull'unità organizzativa DG Enabled PCs e scegli Crea un oggetto Criteri di gruppo in questo dominio e crea qui un collegamento, come illustrato nella figura 24.

Nota

L'unità organizzativa DG Enabled PCs è solo un esempio di dove collegare l'oggetto Criteri di gruppo di test creato in questa sezione. Puoi usare qualsiasi nome di unità organizzativa. Inoltre, puoi filtrare in base ai gruppi di sicurezza se intendi usare opzioni di ripartizione dei criteri in base alla strategia discussa in Prepararsi alla distribuzione dei criteri di integrità del codice a livello aziendale.

Figura 24. Creare un oggetto Criteri di gruppo
Assegna al nuovo oggetto Criteri di gruppo il nome Contoso GPO Test. Questo esempio usa Contoso GPO Test come nome dell'oggetto Criteri di gruppo. Per questo esempio puoi scegliere qualsiasi nome tu voglia.
Apri l'Editor Gestione Criteri di gruppo: fai clic con il pulsante destro del mouse sul nuovo oggetto Criteri di gruppo e scegli Modifica.
Nell'oggetto Criteri di gruppo selezionato passa a Configurazione computer\Modelli amministrativi\Sistema\Device Guard. Quindi, fai clic con il pulsante destro del mouse su Distribuisci criteri di integrità del codice e scegli Modifica.

Figura 25. Modificare il criterio di integrità del codice
Nella finestra di dialogo Distribuisci criteri di integrità del codice seleziona l'opzione Abilitato e quindi specifica il percorso di distribuzione del criterio di integrità del codice.

In questa impostazione devi specificare il percorso locale in cui si troverà il criterio nel computer client oppure un percorso UNC (Universal Naming Convention) in cui i computer client cercheranno per recuperare la versione più recente del criterio. Questo esempio ha copiato il file DeviceGuardPolicy.bin nel computer di test, abiliterà questa impostazione e userà il percorso file C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin, come illustrato nella figura 26.

Nota

Non è necessario usare il nome criterio DeviceGuardPolicy.bin. Questo è semplicemente il nome che è stato usato nella sezione Creare criteri di integrità del codice da PC di riferimento e quindi viene usato anche qui. Inoltre, non è necessario copiare questo file di criteri in tutti i computer. In alternativa, puoi copiare i criteri di integrità del codice in una condivisione file accessibile agli account computer. Tutti i criteri selezionati qui verranno rinominati in SIPolicy.p7b quando verranno distribuiti nei singoli computer.

Figura 26. Abilitare il criterio di integrità del codice

Nota

Puoi aver notato che l'impostazione dell'oggetto Criteri di gruppo fa riferimento a un file .p7b e questo esempio usa un file .bin per il criterio. Indipendentemente dal tipo (.bin, .p7b o .p7), quando vengono distribuiti nei computer client Windows 10 tutti i criteri vengono rinominati in SIPolicy.p7b. Assegna ai criteri di integrità del codice nomi descrittivi e permetti al sistema di convertirli automaticamente, in modo che sia facile distinguerli quando vengono visualizzati in una condivisione o in qualsiasi repository centrale.
Chiudi l'Editor Gestione criteri di gruppo e quindi riavvia il computer di test Windows 10. Riavviando il computer client, il criterio di integrità del codice viene aggiornato. Per informazioni sul controllo dei criteri di integrità del codice, vedi la sezione Controllare i criteri di integrità del codice.

Creare un certificato di firma del codice per Device Guard

Per firmare internamente file di catalogo o criteri di integrità del codice, avrai bisogno di un certificato di firma del codice emesso da un'Autorità di certificazione pubblica o di un'Autorità di certificazione interna. Se hai acquistato un certificato di firma del codice, puoi ignorare questa procedura e passare alle sezioni che illustrano i passaggi per firmare file di catalogo e criteri di integrità del codice. Se non hai acquistato un certificato, ma hai una CA interna, esegui questi passaggi per creare un certificato di firma del codice:

Apri lo snap-in di MMC Autorità di certificazione e seleziona la CA emittente.
Dopo la connessione, fai clic con il pulsante destro del mouse su Modelli di certificato e quindi scegli Gestisci per aprire la console Modelli di certificato.

Figura 27. Gestire i modelli di certificato
Nel riquadro di spostamento fai clic con il pulsante destro del mouse sul certificato di firma del codice e scegli Duplica modello.
Nella scheda Compatibilità deseleziona la casella di controllo Mostra modifiche risultanti. Seleziona Windows Server 2012 nell'elenco Autorità di certificazione e quindi seleziona Windows 8/Windows Server 2012 nell'elenco Destinatario certificato.
Nella scheda Generale specifica Nome visualizzato modello e Nome modello. Questo esempio usa DG Catalog Signing Certificate.
Nella scheda Gestione richiesta seleziona la casella di controllo Rendi la chiave privata esportabile.
Nella scheda Estensioni seleziona la casella di controllo Limitazioni di base e quindi fai clic su Modifica.
Nella finestra di dialogo Modifica estensione limitazioni di base seleziona la casella di controllo Attiva l'estensione, come illustrato nella figura 28.

Figura 28. Abilitare le limitazioni nel nuovo modello
Se i certificati rilasciati devono essere approvati da un gestore certificati, nella scheda Requisiti di rilascio seleziona Approvazione gestore certificati CA.
Nella scheda Nome soggetto seleziona Inserisci nella richiesta.
Nella scheda Sicurezza verifica che ogni account usato per richiedere il certificato abbia il diritto di registrarlo.
Fai clic su OK per creare il modello e quindi chiudi la console Modelli di certificato.

Una volta creato il modello di certificato, devi pubblicarlo nell'archivio di modelli pubblicati della CA. A questo scopo, esegui i passaggi seguenti:

Nello snap-in di MMC Autorità di certificazione fai clic con il pulsante destro del mouse su Modelli di certificato, scegli Nuovo e quindi fai clic su Modello di certificato da rilasciare, come illustrato nella figura 29.

Viene visualizzato un elenco dei modelli disponibili per il rilascio, compreso il modello che hai appena creato.

Figura 29. Selezionare il nuovo modello di certificato da rilasciare
Seleziona il certificato di firma DG Catalog e quindi fai clic su OK.

Ora che il modello è disponibile per il rilascio, devi richiederne uno dal computer Windows 10 che usi per creare e firmare i file di catalogo. Per iniziare, apri MMC ed esegui i passaggi seguenti:

In MMC scegli Aggiungi/Rimuovi snap-in dal menu File. Fai doppio clic su Certificati e quindi seleziona Account dell'utente.
Nello snap-in Certificati fai clic con il pulsante destro del mouse sulla cartella dell'archivio personale, scegli Tutte le attività e quindi fai clic su Richiedi nuovo certificato.
Fai clic su Avanti due volte per ottenere l'elenco di selezione certificato.
Nell'elenco Richiedi certificato seleziona il certificato di firma del codice appena creato e quindi seleziona il testo blu che richiede ulteriori informazioni, come illustrato nella figura 30.

Figura 30. Ottenere ulteriori informazioni per il certificato di firma del codice
Nella finestra di dialogo Proprietà certificato, per Tipo, seleziona Nome comune. Per Valore, seleziona ContosoDGSigningCert e quindi fai clic su Aggiungi. Dopo l'aggiunta, fai clic su OK.
Esegui la registrazione e concludi.

Nota

Se i certificati rilasciati devono essere approvati da un gestore certificati e nel modello hai selezionato la richiesta di approvazione da parte del gestore certificati CA, la richiesta dovrà essere approvata nella CA prima del rilascio al client.

Questo certificato deve essere installato nell'archivio personale dell'utente nel computer che firmerà i file di catalogo e i criteri di integrità del codice. Se la firma avverrà nel computer in cui hai appena richiesto il certificato, l'esportazione del certificato in un file PFX non sarà necessaria, perché è già presente nel tuo archivio personale. Se la firma avverrà in un altro computer, dovrai esportare il certificato in formato .pfx con le chiavi e le proprietà necessarie. A questo scopo, esegui i passaggi seguenti:

Fai clic con il pulsante destro del certificato, scegli Tutte le attività e fai clic su Esporta.
Fai clic su Avanti e quindi seleziona Sì, esporta la chiave privata.
Scegli le impostazioni predefinite e quindi seleziona Esporta tutte le proprietà estese.
Imposta una password, seleziona un percorso di esportazione e quindi seleziona DGCatSigningCert.pfx come nome del file.

Dopo l'esportazione del certificato, importalo nell'archivio personale dell'utente che firmerà il file di catalogo o i criteri di integrità del codice nello specifico computer che verrà usato per la firma.