Table of contents
TOC
Comprimi il sommario
Espandi il sommario

Distribuire i criteri di integrità del codice: regole dei criteri e regole dei file

Brian Lich|Ultimo aggiornamento: 14/03/2017
|
1 Collaboratore

Si applica a

  • Windows 10
  • Windows Server 2016

I criteri di integrità del codice consentono di controllare un computer che esegue Windows 10 specificando se un driver o un'applicazione sia attendibile ed è possibile eseguirli. Per una panoramica dell'integrità del codice, consultare:

Se conosci già le nozioni di base dei criteri di integrità del codice e vuoi conoscere le procedure per creare, controllare e unire i criteri di integrità del codice, vedi Distribuire i criteri di integrità del codice: passaggi.

Questo argomento include le sezioni seguenti:

Panoramica del processo di creazione dei criteri di integrità del codice

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 computer di riferimento. Come per la creazione di immagini, puoi creare più computer 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. Per altri dettagli su come eseguire questa valutazione, vedi la procedura di pianificazione in Pianificazione e avvio del processo di distribuzione di Device Guard.

Nota  Ogni computer può avere un solo criterio di integrità del codice alla volta. In qualunque modo venga distribuito questo criterio, viene rinominato in SIPolicy.p7b e copiato in C:\Windows\System32\CodeIntegrity e, per i computer UEFI, in <Partizione di sistema EFI>\Microsoft\Boot. Tenerlo a mente per la creazione dei 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, se le applicazioni sono 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.

Se prevedi di usare una CA interna per firmare i file di catalogo o i criteri di integrità del codice, vedi la procedura in Facoltativo: creare un certificato di firma del codice per i criteri di integrità del codice.

Regole dei criteri di integrità del codice

I criteri di integrità del codice includono le regole dei criteri, che controllano opzioni come la modalità di controllo oppure se l'integrità del codice in modalità utente è abilitata in un criterio di integrità del codice. Puoi modificare queste opzioni in un criterio di integrità del codice nuovo o esistente. Per informazioni sulle regole dei file, che specificano il livello a cui le applicazioni verranno identificate e considerate attendibili, vedi la sezione successiva Livelli delle regole dei file di integrità del codice.

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

  • Per verificare che UMCI sia abilitato per un criterio di integrità del codice creato mediante l'opzione -UserPEs (modalità utente), aggiungere l'opzione della regola 0 a un criterio esistente eseguendo il comando seguente:

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

    È stato creato un criterio senza svuotare l'opzione -UserPEs dagli eseguibili in modalità utente, ovvero le applicazioni. Se si abilita UMCI (opzione 0) per tale criterio, quindi si tenta di eseguire un'applicazione, Device Guard osserverà che l'applicazione non è presente nel relativo elenco (privo di applicazioni) e risponderà. In modalità di controllo, la risposta registra un evento e, in modalità di imposizione, la risposta blocca l'applicazione. Per creare un criterio che includa eseguibili in modalità utente (applicazioni), quando si esegue New-CIPolicy, includere l'opzione -UserPEs.

  • Per disabilitare l'integrità del codice in modalità utente in un criterio di integrità del codice esistente, eliminare l'opzione della regola 0 eseguendo il comando seguente:

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

All'interno di un criterio di integrità del codice puoi impostare diverse opzioni delle regole. Per visualizzare un elenco di opzioni delle regole, puoi digitare Set- RuleOption -Help in una sessione di Windows PowerShell. La tabella 2 descrive ogni opzione delle regole.

Nota  Enabled:Audit Mode è un'importante opzione delle regole. Ti consigliamo di usare questa opzione per un certo periodo con tutti i nuovi criteri di integrità del codice, perché ti consente di testarli prima di imporli. Con la modalità di controllo, nessuna applicazione viene bloccata: il criterio si limita a registrare un evento ogni volta che viene avviata un'applicazione al di fuori del criterio. Per espandere il criterio in modo che (se imposto) consenta queste applicazioni, puoi usare i comandi di Windows PowerShell per acquisire le informazioni sul criterio necessarie dal registro eventi e quindi unire tali informazioni nel criterio esistente.

La modalità (modalità di controllo o modalità di imposizione) viene impostata includendo o eliminando Enabled:Audit Mode nei criteri di integrità del codice. Quando questa opzione viene eliminata, il criterio viene eseguito nella modalità di imposizione.

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

Opzione della regolaDescrizione
0 Enabled:UMCII 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 ProtectionQuesta opzione non è attualmente supportata.
2 Required:WHQLPer 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 dei criteri 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 iniziare a imporre un criterio di integrità del codice, elimina questa opzione.
4 Disabled:Flight SigningSe 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 PolicyQuesta 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 AugmentedQuesta opzione non è attualmente supportata.
8 Required:EV SignersQuesta 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 MenuIl 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 FailureUsato 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.

Livelli delle regole dei file di integrità del codice

I livelli delle regole dei file permettono agli amministratori di specificare il livello di attendibilità delle applicazioni. Il livello di attendibilità va da ottimizzato, come il valore hash di ogni file binario, a generale, come il certificato CA. Specifichi i livelli delle regole dei file 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. Se uniti, i criteri di integrità del codice combinano le regole dei file, in modo che tutte le applicazioni consentite da uno dei criteri originali saranno consentite anche dal criterio combinato.

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 regolaDescrizione
HashSpecifica 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.
FileNameSpecifica 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.
SignedVersionCombina la regola Publisher con un numero di versione. Questa opzione consente l'esecuzione di tutti i file dell'autore specificato con versione uguale o superiore al numero di versione specificato.
PublisherÈ una combinazione del livello PcaCertificate (in genere un solo certificato sotto la radice) e del nome comune (CN) del certificato foglia. Questo livello della regola consente alle organizzazioni di considerare attendibile un certificato da una CA principale (ad esempio, Symantec), ma solo se il certificato foglia proviene da una società specifica (ad esempio Intel, per i driver di dispositivo).
FilePublisherÈ una combinazione dell'attributo "FileName" del file firmato, più "Publisher" (certificato PCA con CN della foglia), più un numero di versione minimo. Questa opzione considera attendibili i file specifici dell'autore specificato con versione uguale o superiore al numero di versione specificato.
LeafCertificateAggiunge 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 CA, quindi occorre considerare il carico amministrativo associato all'aggiornamento dei criteri di integrità del codice alla scadenza.
PcaCertificateAggiunge ai firmatari il certificato disponibile 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 là dei certificati inclusi nella firma fornita perché non passa alla modalità online né controlla gli archivi radice locali.
RootCertificateAttualmente non supportato.
WHQLConsidera 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.
WHQLFilePublisherSpecifica 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 si creano criteri di integrità del codice con il cmdlet New-CIPolicy, è possibile 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.

Esempio di livelli delle regole dei file in uso

Prendiamo ad esempio in considerazione alcuni professionisti IT che lavorano in un reparto dove sono in esecuzione molti server. Decidono di eseguire nei server aziendali solo software firmato dai provider del software e dei driver che usano, vale a dire le società che forniscono il loro hardware, il sistema operativo, il software antivirus e altre applicazioni importanti. I professionisti IT sanno che i server eseguono anche un'applicazione scritta internamente che non è firmata, ma viene raramente aggiornata, e vogliono consentirne l'esecuzione.

Per creare i criteri di integrità del codice, creano un server di riferimento sul loro hardware standard e installano tutto il software in esecuzione nei server. Quindi eseguono New-CIPolicy con -Level Publisher (per consentire il software dei loro provider software, gli "Autori") e -Fallback Hash (per consentire l'applicazione interna non firmata). Abilitano il criterio in modalità di controllo e raccolgono le informazioni su tutto il software necessario non incluso nel server di riferimento. Uniscono i criteri di integrità del codice al criterio originale per consentire l'esecuzione del software aggiuntivo. Quindi abilitano i criteri di integrità del codice in modalità di imposizione per i server.

Nell'ambito delle normali operazioni installano infine gli aggiornamenti software o eventualmente aggiungono applicazioni degli stessi provider software. Dal momento che l'"Autore" resta lo stesso per questi aggiornamenti e applicazioni software, non sarà necessario aggiornare i criteri di integrità del codice. Qualora l'applicazione non firmata scritta internamente debba essere aggiornata, dovranno aggiornare anche i criteri di integrità del codice in modo che il valore hash dei criteri corrisponda a quello dell'applicazione interna aggiornata.

Potrebbero inoltre scegliere di creare un catalogo che acquisisca le informazioni sull'applicazione interna non firmata, quindi firmare e distribuire il catalogo. L'applicazione interna potrebbe quindi essere gestita dai criteri di integrità del codice allo stesso modo di qualsiasi altra applicazione firmata. Un aggiornamento dell'applicazione interna richiederebbe solo la rigenerazione, la firma e la distribuzione del catalogo (non sarebbe necessario alcun riavvio).

Argomenti correlati

© 2017 Microsoft