Informazioni sulle regole dei criteri e sulle regole dei file di Controllo app per le aziende

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.

Tabella 1. Criteri di Controllo app per le aziende - Opzioni delle regole dei criteri

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.

Tabella 2. Criteri di Controllo app per le aziende - Livelli di regole file

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.

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

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:

È 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.

Regole di filepath di esempio con caratteri jolly

Senza un carattere jolly, la regola filepath consente solo un file specifico (ad esempio C:\foo\bar.exe).

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.