Informazioni sulle regole dei criteri e sulle regole dei file di Controllo app per le aziende
Nota
Alcune funzionalità di Controllo app per le aziende sono disponibili solo in versioni specifiche di Windows. Altre informazioni sulla disponibilità delle funzionalità di Controllo app.
Controllo app per le aziende può controllare le esecuzioni nei dispositivi Windows impostando criteri che specificano se un driver o un'applicazione è attendibile. Un criterio include regole di criteri che controllano opzioni come la modalità di controllo e regole di file (o livelli di regole file) che specificano come identificare le applicazioni attendibili dall'organizzazione.
Regole dei criteri di Controllo app per le aziende
Per modificare le opzioni delle regole dei criteri di un xml dei criteri di controllo app esistente, usare la Creazione guidata criteri di controllo app o il cmdlet Di PowerShell Set-RuleOption .
È possibile impostare diverse opzioni delle regole all'interno di un criterio di Controllo app. La tabella 1 descrive ogni opzione di regola e indica se i criteri supplementari possono impostarli. Alcune opzioni delle regole sono riservate per il lavoro futuro o non sono supportate.
Nota
È consigliabile usare la modalità Enabled:Audit inizialmente perché consente di testare i nuovi criteri di Controllo app prima di applicarli. Con la modalità di controllo, le applicazioni vengono eseguite normalmente, ma Controllo app registra gli eventi ogni volta che viene eseguito un file non consentito dai criteri. Per consentire questi file, è possibile acquisire le informazioni sui criteri dal registro eventi e quindi unire tali informazioni nei criteri esistenti. Quando la modalità Enabled:Audit viene eliminata, i criteri vengono eseguiti in modalità applicata.
Alcune app possono comportarsi in modo diverso anche quando i criteri sono in modalità di controllo. Quando un'opzione può modificare i comportamenti in modalità di controllo, come indicato nella tabella 1. Quando si distribuiscono aggiornamenti significativi nei criteri di controllo delle app, è consigliabile testare sempre accuratamente le app.
Tabella 1. Criteri di Controllo app per le aziende - Opzioni delle regole dei criteri
| Opzione della regola | Descrizione | Opzione supplementare valida |
|---|---|---|
| 0 Enabled:UMCI | I criteri di Controllo app 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. | No |
| 1 Enabled:Boot Menu Protection | Questa opzione non è attualmente supportata. | No |
| 2 Required:WHQL | Per impostazione predefinita, i driver del kernel non firmati da Windows Hardware Quality Labs (WHQL) possono essere eseguiti. L'abilitazione di questa regola richiede che ogni driver sia firmato WHQL e rimuova il supporto dei driver legacy. I driver del kernel creati per Windows 10 devono essere certificati WHQL. | No |
| 3 Enabled:Audit Mode (impostazione predefinita) | Indica a Controllo app di registrare informazioni su applicazioni, file binari e script che sarebbero stati bloccati, se i criteri sono stati applicati. È possibile usare questa opzione per identificare il potenziale impatto dei criteri di controllo delle app e usare gli eventi di controllo per perfezionare i criteri prima dell'imposizione. Per applicare un criterio di Controllo app, eliminare questa opzione. | No |
| 4 Disabled:Flight Signing | Se abilitata, i file binari delle build di Windows Insider non sono attendibili. Questa opzione è utile per le organizzazioni che vogliono eseguire solo i file binari rilasciati, non le build di Windows non definitive. | No |
| 5 Enabled:Inherit Default Policy | Questa opzione è riservata per uso futuro e attualmente non ha alcun effetto. | Sì |
| 6 Enabled:Unsigned System Integrity Policy (impostazione predefinita) | Consente che il criterio resti senza firma. Quando questa opzione viene rimossa, i criteri devono essere firmati e devono essere firmati anche eventuali criteri supplementari. I certificati attendibili per gli aggiornamenti futuri dei criteri devono essere identificati nella sezione UpdatePolicySigners. I certificati considerati attendibili per i criteri supplementari devono essere identificati nella sezione SupplementalPolicySigners. | Sì |
| 7 Allowed:Debug Policy Augmented | Questa opzione non è attualmente supportata. | Sì |
| 8 Required:EV Signers | Questa opzione non è attualmente supportata. | No |
| 9 Enabled:Advanced Boot Options Menu | Il menu di preavvolto F8 è disabilitato per impostazione predefinita per tutti i criteri di Controllo app. Impostando questa opzione della regola, gli utenti fisicamente presenti possono visualizzare il menu F8. | No |
| 10 Enabled:Boot Audit on Failure | Usato quando i criteri di Controllo app sono in modalità di imposizione. Quando un driver critico per l'avvio non riesce durante l'avvio, i criteri di controllo delle app vengono inseriti in modalità di controllo in modo che Windows venga caricato. Gli amministratori possono verificare il motivo dell'errore nel registro eventi CodeIntegrity. | No |
| 11 Disabled:Script Enforcement | Questa opzione disabilita le opzioni di imposizione degli script, che riguardano PowerShell, Windows Based Script Host (wscript.exe), Windows Console Based Script Host (cscript.exe), i file HTA eseguiti in Microsoft HTML Application Host (mshta.exe) e MSXML. Alcuni host di script possono comportarsi in modo diverso anche quando i criteri sono in modalità di controllo. Per altre informazioni sull'imposizione degli script, vedere Applicazione di script con controllo app. NOTA: questa opzione non è supportata in Windows Server 2016 o Windows 10 1607 LTSB e non deve essere usata in tali sistemi operativi. |
No |
| 12 Required:Enforce Store Applications | Se questa opzione della regola è abilitata, i criteri di Controllo app si applicano anche alle applicazioni di Windows universale. | No |
| 13 Enabled:Managed Installer | Usare questa opzione per consentire automaticamente le applicazioni installate da un programma di installazione gestito. Per altre informazioni, vedere Autorizzare le app distribuite con un programma di installazione gestito di Controllo app | Sì |
| 14 Enabled:Intelligent Security Graph Authorization | Usare questa opzione per consentire automaticamente alle applicazioni con reputazione "nota" come definito da Intelligent Security Graph (ISG) di Microsoft. | Sì |
| 15 Enabled:Invalidate EAs on Reboot | Quando si usa l'opzione Intelligent Security Graph (14), Controllo app imposta un attributo di file esteso che indica che il file è stato autorizzato a essere eseguito. Questa opzione fa sì che Controllo app riconvalidi periodicamente la reputazione per i file precedentemente autorizzati dall'ISG. | No |
| 16 Enabled:Update Policy No Reboot | Usare questa opzione per consentire l'applicazione di futuri aggiornamenti dei criteri di Controllo app senza richiedere un riavvio del sistema. NOTA: questa opzione è supportata solo in Windows 10, versione 1709 e successive o Windows Server 2019 e versioni successive. |
No |
| 17 Abilitato:Consenti criteri supplementari | Usare questa opzione in un criterio di base per consentire ai criteri supplementari di espanderla. NOTA: questa opzione è supportata solo in Windows 10, versione 1903 e successive o Windows Server 2022 e versioni successive. |
No |
| 18 Disabilitato:Runtime FilePath Rule Protection | Questa opzione disabilita il controllo di runtime predefinito che consente solo regole FilePath per i percorsi scrivibili solo da un amministratore. NOTA: questa opzione è supportata solo in Windows 10, versione 1903 e successive o Windows Server 2022 e versioni successive. |
Sì |
| 19 Abilitato:Sicurezza dinamica del codice | Abilita l'imposizione dei criteri per le applicazioni .NET e le librerie caricate in modo dinamico. NOTA: questa opzione è supportata solo in Windows 10, versione 1803 e successive o Windows Server 2019 e versioni successive. NOTA: questa opzione viene sempre applicata se i criteri UMCI del controllo app lo abilitano. Non è disponibile alcuna modalità di controllo per la protezione avanzata della sicurezza del codice dinamico .NET. |
No |
| 20 Abilitato:Revocato scaduto come non firmato | Usare questa opzione per considerare i file binari firmati con certificati revocati o i certificati scaduti con l'EKU di firma a durata nella firma, come "file binari non firmati" per processi/componenti in modalità utente, in scenari di firma aziendale. | No |
| Enabled:Developer Mode Dynamic Code Trust | Usare questa opzione per considerare attendibili le app UWP sottoposte a debug in Visual Studio o distribuite tramite il portale del dispositivo quando la modalità sviluppatore è abilitata nel sistema. | No |
Livelli di regole file di Controllo app per le aziende
I livelli delle regole dei file permettono agli amministratori di specificare il livello di attendibilità delle applicazioni. Questo livello di attendibilità può essere granulare come l'hash di ogni file binario o generale come un certificato CA. Per creare e modificare i criteri, è necessario specificare i livelli delle regole di file quando si usano i cmdlet PowerShell per il controllo app o la Creazione guidata controllo app.
Ogni livello di regola del file presenta vantaggi e svantaggi. Usare la tabella 2 per selezionare il livello di protezione appropriato per le risorse amministrative disponibili e lo scenario di distribuzione di Controllo app.
Nota
Le regole basate sul firmatario di Controllo app funzionano solo con la crittografia RSA con una lunghezza massima della chiave di 4096 bit. Gli algoritmi ECC, ad esempio ECDSA, non sono supportati. Se si tenta di consentire i file in base alla firma in base alle firme ECC, verrà visualizzato VerificationError = 23 negli eventi di informazioni sulla firma 3089 corrispondenti. I file possono essere consentiti invece da regole di hash o di attributi di file o usando altre regole del firmatario se il file è firmato anche con firme usando RSA.
Tabella 2. Criteri di Controllo app per le aziende - Livelli di regole file
| Livello regola | Descrizione |
|---|---|
| Hash | Specifica i singoli valori hash dell'immagine Authenticode/PE per ogni file binario individuato. Questo livello è il livello più specifico e richiede maggiore impegno per mantenere i valori hash delle versioni del prodotto correnti. Ogni volta che un file binario viene aggiornato il valore hash cambia, pertanto è necessario aggiornare i criteri. |
| FileName | Specifica il nome file originale per ogni file binario. Anche se i valori hash di un'applicazione cambiano quando viene aggiornata, in genere i nomi del file restano invariati. Questo livello offre una sicurezza meno specifica rispetto al livello hash, ma in genere non richiede un aggiornamento dei criteri quando viene modificato un file binario. Per impostazione predefinita, questo livello usa l'attributo OriginalFileName dell'intestazione della risorsa del file. Utilizzare -SpecificFileNameLevel per scegliere un attributo alternativo, ad esempio ProductName. |
| FilePath | A partire da Windows 10 versione 1903, questo livello consente l'esecuzione di file binari da percorsi di file specifici. Le regole FilePath si applicano solo ai file binari in modalità utente e non possono essere usate per consentire i driver in modalità kernel. Altre informazioni sulle regole a livello di FilePath sono disponibili più avanti in questo articolo. |
| SignedVersion | Questo livello combina la regola del server di pubblicazione con un numero di versione. Consente l'esecuzione di qualsiasi elemento dal server di pubblicazione specificato con una versione in corrispondenza o superiore al numero di versione specificato. |
| Pubblicato da | Questo livello combina il livello PcaCertificate (in genere un certificato sotto la radice) e il nome comune (CN) del certificato foglia. È possibile usare questo livello di regola per considerare attendibile un certificato emesso da una ca specifica e rilasciato a una società specifica considerata attendibile (ad esempio Intel, per i driver di dispositivo). |
| FilePublisher | Questo livello combina l'attributo "FileName" del file firmato, più "Publisher" (certificato PCA con CN di 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. Per impostazione predefinita, questo livello usa l'attributo OriginalFileName dell'intestazione della risorsa del file. Utilizzare -SpecificFileNameLevel per scegliere un attributo alternativo, ad esempio ProductName. |
| LeafCertificate | Aggiunge firmatari attendibili a livello di certificato di firma singolo. Il vantaggio dell'uso di questo livello rispetto al singolo livello hash è che le nuove versioni del prodotto hanno valori hash diversi, ma in genere lo stesso certificato di firma. Quando si usa questo livello, non è necessario alcun aggiornamento dei criteri per eseguire la nuova versione dell'applicazione. Tuttavia, i certificati foglia hanno in genere periodi di validità più brevi rispetto ad altri livelli di certificato, quindi i criteri di controllo app devono essere aggiornati ogni volta che questi certificati cambiano. |
| PcaCertificate | Aggiunge ai firmatari il certificato disponibile più elevato della catena di certificati. Questo livello è in genere un certificato sotto la radice perché l'analisi non risolve la catena di certificati completa tramite gli archivi radice locali o con un controllo online. |
| RootCertificate | Non supportato. |
| WHQL | Considera attendibili solo i file binari inviati a Microsoft e firmati da Windows Hardware Qualification Lab (WHQL). Questo livello è principalmente per i file binari del kernel. |
| WHQLPublisher | Questo livello combina il livello WHQL e il cn nel certificato foglia ed è principalmente per i file binari del kernel. |
| WHQLFilePublisher | Questo livello combina l'attributo "FileName" del file firmato, più "WHQLPublisher", più un numero di versione minimo. Questo livello è principalmente per i file binari del kernel. Per impostazione predefinita, questo livello usa l'attributo OriginalFileName dell'intestazione della risorsa del file. Utilizzare -SpecificFileNameLevel per scegliere un attributo alternativo, ad esempio ProductName. |
Nota
Quando si creano criteri di Controllo app con New-CIPolicy, è possibile specificare un livello di regola del file primario, 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 della regola del file primario è PCACertificate, ma si vuole considerare attendibili anche le applicazioni non firmate, l'uso del livello di regola Hash come fallback aggiunge i valori hash dei file binari che non avevano un certificato di firma.
Nota
Se applicabile, i numeri di versione minima e massima in una regola di file vengono indicati rispettivamente come MinimumFileVersion e MaximumFileVersion nel codice XML dei criteri.
- Specificati sia MinimumFileVersion che MaximumFileVersion: per le regole Allow sono consentiti file con versione maggiore o uguale a MinimumFileVersion e minore o uguale a MaximumFileVersion. Per le regole deny, il file con versione maggiore o uguale a MinimumFileVersion e minore o uguale a MaximumFileVersion viene negato.
- MinimumFileVersion specificato senza MaximumFileVersion: per le regole Consenti, è consentito l'esecuzione di file con versione maggiore o uguale alla versione specificata. Per le regole di negazione, il file con versione minore o uguale alla versione specificata viene bloccato.
- MaximumFileVersion specificato senza MinimumFileVersion: per le regole Allow è consentito l'esecuzione di file con versione minore o uguale alla versione specificata. Per le regole deny, il file con versione maggiore o uguale alla versione specificata viene bloccato.
Esempio di livelli delle regole dei file in uso
Si consideri, ad esempio, un professionista IT in un reparto che esegue molti server. Vogliono eseguire solo software firmato dalle aziende che forniscono il loro hardware, sistema operativo, antivirus e altro software importante. 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 controllo delle app, creano un server di riferimento nell'hardware standard e installano tutto il software che i server sono noti per l'esecuzione. 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). Distribuiscono i criteri in modalità di controllo per determinare il potenziale impatto dell'applicazione dei criteri. Con l'aiuto dei dati di controllo, aggiornano i criteri di controllo delle app per includere qualsiasi altro software che vogliono eseguire. Abilitano quindi i criteri di controllo delle app in modalità applicata per i server.
Come parte delle normali operazioni, alla fine installeranno gli aggiornamenti software o potrebbero aggiungere software dagli stessi provider di software. Poiché il "server di pubblicazione" rimane lo stesso per gli aggiornamenti e il software, non è necessario aggiornare i criteri di controllo delle app. Se l'applicazione interna non firmata viene aggiornata, deve anche aggiornare i criteri di Controllo app per consentire la nuova versione.
Ordine di precedenza delle regole di file
Controllo app ha una logica di conflitto di regole file predefinita che si traduce in ordine di precedenza. Prima di tutto elabora tutte le regole di negazione esplicite trovate. Elabora quindi tutte le regole di autorizzazione esplicite. Se non esiste alcuna regola negata o consentita, Controllo app verifica la presenza di un'attestazione del programma di installazione gestita , se consentita dai criteri. Infine, Controllo app torna all'ISG se consentito dai criteri.
Nota
Per semplificare il ragionamento sui criteri di controllo delle app, è consigliabile mantenere criteri ALLOW e DENY separati nelle versioni di Windows che supportano più criteri di Controllo app.
Usare -SpecificFileNameLevel con regole di livello FileName, FilePublisher o WHQLFilePublisher
Per impostazione predefinita, i livelli di regola FileName, FilePublisher e WHQLFilePublisher usano l'attributo OriginalFileName dall'intestazione della risorsa del file. È possibile usare un attributo di intestazione di risorsa alternativo per le regole impostando -SpecificFileNameLevel. Ad esempio, uno sviluppatore di software potrebbe usare lo stesso ProductName per tutti i file binari che fanno parte di un'app. Usando -SpecificFileNameLevel, è possibile creare una singola regola per coprire tutti i file binari nei criteri anziché le singole regole per ogni file.
La tabella 3 descrive le opzioni disponibili per gli attributi dell'intestazione della risorsa che è possibile impostare con -SpecificFileNameLevel.
Tabella 3. Opzioni -SpecificFileNameLevel
| Valore SpecificFileNameLevel | Descrizione |
|---|---|
| FileDescription | Specifica la descrizione del file fornita dallo sviluppatore del file binario. |
| InternalName | Specifica il nome interno del file binario. |
| OriginalFileName | Specifica il nome del file originale, o il nome con cui il file è stato creato per la prima volta, del file binario. |
| PackageFamilyName | Specifica il nome della famiglia di pacchetti del file binario. Il nome della famiglia di pacchetti è costituito da due parti: il nome del file e l'ID editore. |
| ProductName | Specifica il nome del prodotto con cui viene fornito il file binario. |
| Percorso file | Specifica il percorso del file binario. |
Altre informazioni sulle regole del percorso file
Le regole di percorso file non offrono le stesse garanzie di sicurezza offerte dalle regole esplicite del firmatario, poiché si basano sulle autorizzazioni di accesso modificabili. Le regole filepath sono più adatte per gli ambienti in cui la maggior parte degli utenti è in esecuzione come standard anziché come amministratore. Le regole di percorso sono più adatte per consentire percorsi che si prevede rimangano solo scrivibili dall'amministratore. È possibile evitare le regole di percorso per le directory in cui gli utenti standard possono modificare gli elenchi di controllo di accesso nella cartella.
Percorsi file scrivibili dall'utente
Per impostazione predefinita, Controllo app esegue un controllo di scrivibilità utente in fase di esecuzione che garantisce che le autorizzazioni correnti nel percorso file specificato consentano l'accesso in scrittura solo agli utenti amministratori.
È disponibile un elenco definito di SID riconosciuti dal controllo app come amministratori. Se un percorso file consente autorizzazioni di scrittura per qualsiasi SID non incluso in questo elenco, il percorso file viene considerato scrivibile dall'utente, anche se il SID è associato a un utente amministratore personalizzato. Per gestire questi casi speciali, è possibile eseguire l'override del controllo delle regole di runtime di Controllo app con l'opzione Disabled:Runtime FilePath Rule Protection descritta in precedenza.To handle these special cases, you can override App Control's runtime admin-writeable check with the Disabled:Runtime FilePath Rule Protection option described earlier.
L'elenco dei SID di amministrazione noti di Controllo app è:
S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-16855971119-444378811-2746676523.
Quando le regole del percorso file vengono generate usando New-CIPolicy, viene generata una regola di percorso completa univoca per ogni file individuato nei percorsi analizzati. Per creare regole che consentano invece tutti i file in un percorso di cartella specificato, usare New-CIPolicyRule per definire regole contenenti caratteri jolly, usando l'opzione -FilePathRules .
Uso di caratteri jolly nelle regole del percorso file di Controllo app
I caratteri jolly seguenti possono essere usati nelle regole del percorso dei file di Controllo app:
| Carattere jolly | Significato | Sistemi operativi supportati |
|---|---|---|
* |
Corrisponde a zero o più caratteri. | Windows 11, Windows 10 e Windows Server 2022 |
? |
Corrisponde a un singolo carattere. | solo Windows 11 |
È anche possibile utilizzare le macro seguenti quando il volume esatto può variare: %OSDRIVE%, , %WINDIR%%SYSTEM32%. Queste macro possono essere usate in combinazione con i caratteri jolly sopra indicati.
Nota
In Windows 11 è possibile usare uno o più caratteri jolly in qualsiasi punto all'interno di una regola di percorso file.
In tutte le altre versioni di Windows e Windows Server è consentito un solo carattere jolly per ogni regola di percorso e deve trovarsi all'inizio o alla fine di una regola di percorso.
Regole di filepath di esempio con caratteri jolly
| Esempi | Descrizione | Sistemi operativi supportati |
|---|---|---|
|
C:\Windows\* D:\EnterpriseApps\MyApp\* %OSDRIVE%\Windows\* |
I caratteri jolly posizionati alla fine di un percorso autorizzano tutti i file nel percorso immediato e le relative sottodirectory in modo ricorsivo. | Windows 11, Windows 10 e Windows Server 2022 |
| *\bar.exe | I caratteri jolly posizionati all'inizio di un percorso consentono il nome file specificato esatto in qualsiasi percorso. | Windows 11, Windows 10 e Windows Server 2022 |
|
C:\*\CCMCACHE\*\7z???? -x64.exe %OSDRIVE%\*\CCMCACHE\*\7z???? -x64.exe |
I caratteri jolly usati al centro di un percorso consentono tutti i file che corrispondono a tale modello. Valutare attentamente tutte le corrispondenze possibili, in particolare se il criterio disabilita il controllo scrivibile dall'amministratore con l'opzione Disabled:Runtime FilePath Rule Protection . In questo esempio, entrambi questi percorsi ipotetici corrisponderebbero:C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe C:\USERS\AppControlUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe |
solo Windows 11 |
Senza un carattere jolly, la regola filepath consente solo un file specifico (ad esempio C:\foo\bar.exe).
Nota
Quando si creano criteri di Controllo app con Configuration Manager, è disponibile un'opzione per creare regole per file e cartelle specificati. Queste regole non sono regole filepath di Controllo app. Piuttosto, Configuration Manager esegue un'analisi una tantum dei file e delle cartelle specificati e compila le regole per tutti i file binari presenti in tali posizioni al momento dell'analisi. Le modifiche ai file e alle cartelle specificate dopo l'analisi non saranno consentite a meno che il criterio di Configuration Manager non venga riapplicato.
Altre informazioni sugli hash
Controllo app usa l'algoritmo hash dell'immagine Authenticode/PE durante il calcolo dell'hash di un file. A differenza dell'hash di file flat più comunemente noto, il calcolo dell'hash Authenticode omette il checksum del file, la tabella dei certificati e la tabella del certificato degli attributi. Pertanto, l'hash Authenticode di un file non cambia quando le firme e i timestamp del file vengono modificati o quando una firma digitale viene rimossa dal file. Con l'aiuto dell'hash Authenticode, Controllo app offre maggiore sicurezza e un minor sovraccarico di gestione, in modo che i clienti non debbano rivedere le regole hash dei criteri quando viene aggiornata la firma digitale nel file.
L'hash dell'immagine Authenticode/PE può essere calcolato per i file con firma digitale e senza firma.
Perché l'analisi crea quattro regole hash per ogni file XML?
Il cmdlet di PowerShell produce un hash Sha1 Authenticode, un hash Sha256, un hash di pagina Sha1 e un hash di pagina Sha256. Durante la convalida, Controllo app seleziona gli hash calcolati in base alla modalità di firma del file e allo scenario in cui viene usato il file. Ad esempio, se il file è firmato con hash di pagina, Controllo app convalida ogni pagina del file ed evita di caricare l'intero file in memoria per calcolare l'hash di authenticode sha256 completo.
Nei cmdlet, invece di provare a stimare quale hash verrà usato, si precalcolano e si usano i quattro hash (sha1/sha2 authenticode e sha1/sha2 della prima pagina). Questo metodo è anche resiliente alle modifiche apportate alla modalità di firma del file poiché i criteri di Controllo app hanno già più di un hash disponibile per il file.
Perché l'analisi crea otto regole hash per determinati file?
Vengono create regole separate per UMCI e KMCI. Se i cmdlet non riescono a determinare che un file viene eseguito solo in modalità utente o nel kernel, vengono create regole per entrambi gli scenari di firma con molta cautela. Se si sa che un determinato file viene caricato solo in modalità utente o kernel, è possibile rimuovere in modo sicuro le regole aggiuntive.
Quando il controllo app usa il valore hash del file flat?
Esistono alcuni rari casi in cui il formato di un file non è conforme alla specifica Authenticode e quindi Il controllo app torna a usare l'hash del file flat. Questo comportamento può verificarsi per molti motivi, ad esempio se vengono apportate modifiche alla versione in memoria del file in fase di esecuzione. In questi casi, si noterà che l'hash visualizzato nell'evento di informazioni sulla firma 3089 correlato corrisponde all'hash del file flat dell'evento di blocco 3076/3077. Per creare regole per i file con un formato non valido, è possibile aggiungere regole hash ai criteri per l'hash dei file flat usando la Creazione guidata controllo app o modificando direttamente il codice XML dei criteri.