Suggerimenti Amministrazione controllo app & problemi noti

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.

Questo articolo illustra suggerimenti e consigli per gli amministratori e i problemi noti relativi al controllo delle app per le aziende. Testare questa configurazione nel lab prima di abilitarla nell'ambiente di produzione.

suggerimenti e suggerimenti Amministrazione

Percorsi dei file dei criteri di Controllo app

Nei percorsi seguenti sono disponibili più criteri di controllo delle app, a seconda che il criterio sia firmato o meno e del metodo di distribuzione dei criteri usato.

• <Volume> del sistema operativo\Windows\System32\CodeIntegrity\CiPolicies\Active\{PolicyId GUID}.cip
• <Partizione> di sistema EFI\Microsoft\Boot\CiPolicies\Active\{PolicyId GUID}.cip

Il valore {PolicyId GUID} è univoco per criterio e definito nel codice XML del criterio con l'elemento <PolicyId> .

Per un singolo formato di criteri, oltre ai due percorsi precedenti, cercare anche un file denominato SiPolicy.p7b nei percorsi seguenti:

• <Partizione> di sistema EFI\Microsoft\Boot\SiPolicy.p7b
• <Volume> del sistema operativo\Windows\System32\CodeIntegrity\SiPolicy.p7b

Nota

In uno qualsiasi dei percorsi dei file di criteri potrebbe essere presente un criterio di controllo app con il singolo formato di criteri GUID {A244370E-44C9-4C06-B551-F6016E563076} .

Ordine di precedenza delle regole di file

Quando il motore di Controllo app valuta i file rispetto al set attivo di criteri nel dispositivo, le regole vengono applicate nell'ordine seguente. Dopo che un file rileva una corrispondenza, Controllo app interrompe l'ulteriore elaborazione.

1. Qualsiasi file corrispondente a una regola di negazione esplicita viene bloccato, anche se si creano altre regole per tentare di consentirla. Le regole di negazione possono usare qualsiasi livello di regola. Usare il livello di regola più specifico pratico durante la creazione di regole di negazione per evitare di bloccare più di quanto si intende.

2. Qualsiasi file corrispondente a una regola consenti esplicita viene eseguito.

3. Qualsiasi file con un programma di installazione gestito o un attributo isg (Intelligent Security Graph) esteso (EA) viene eseguito se il criterio abilita l'opzione corrispondente (programma di installazione gestito o ISG).

4. Qualsiasi file non consentito in base alle condizioni precedenti viene controllato per la reputazione usando l'ISG quando tale opzione è abilitata nei criteri. Il file viene eseguito se l'ISG decide che è sicuro e un nuovo isg EA viene scritto nel file.

5. Qualsiasi file non consentito da una regola esplicita o basato su ISG o programma di installazione gestito viene bloccato in modo implicito.

Problemi noti

I criteri di controllo delle app in modalità di controllo potrebbero influire sulle prestazioni in un dispositivo

Quando un file viene valutato in base al set corrente di criteri di Controllo app, il motore di Controllo app imposta gli attributi estesi del kernel nel file quando passa i criteri attivi. In seguito, se viene eseguito lo stesso file, Controllo app controlla le EA e riutilizza il risultato memorizzato nella cache finché i criteri in vigore rimangono invariati. Questo meccanismo di memorizzazione nella cache garantisce la scalabilità di Controllo app anche quando sono attivi molti criteri contenenti un numero elevato di regole. Tuttavia, questa ottimizzazione delle prestazioni non viene usata per i criteri in modalità di controllo. In alcuni casi è possibile osservare una differenza di prestazioni tra i sistemi con criteri applicati solo rispetto ai sistemi con criteri di controllo.

L'opzione Intelligent Security Graph (ISG) può influire sulle prestazioni quando viene verificata la ricerca di molti file nel cloud

L'opzione ISG è una funzionalità incredibilmente importante di Controllo app che semplifica la complessità della gestione delle regole per singoli file e app. Tuttavia, poiché si basa su modelli di intelligenza artificiale (IA) basati sul cloud, è consigliabile evitare di affidarsi all'ISG per prendere decisioni sulle app e i file importanti che è necessario eseguire. La dipendenza dall'ISG non è consigliata per i carichi di lavoro critici, il codice del sistema operativo Windows, in particolare il codice eseguito durante l'avvio o le situazioni in cui le prestazioni sono più critiche. Quando possibile, è necessario assicurarsi che esistano regole esplicite nei criteri o usare i programmi di installazione gestiti anziché l'ISG come modo per ridurre il sovraccarico di gestione dei criteri.

Quando si considera la tolleranza per gli effetti sulle prestazioni dell'ISG, considerare anche gli effetti sulle prestazioni aggiunti del problema precedente che influiscono sulle prestazioni dei criteri della modalità di controllo. Provare a evitare l'esecuzione di criteri in modalità di controllo che si basano principalmente sull'autorizzazione ISG per un numero elevato di file.

L'errore di arresto dell'avvio (schermata blu) si verifica se sono attivi più di 32 criteri

Fino a quando non si applica l'aggiornamento della sicurezza di Windows rilasciato il 9 aprile 2024 o dopo tale data, il dispositivo è limitato a 32 criteri attivi. Se viene superato il numero massimo di criteri, gli schermi blu del dispositivo fanno riferimento ci.dll con un valore di controllo dei bug pari a 0x0000003b. Considerare questo limite massimo di conteggio dei criteri durante la pianificazione dei criteri di Controllo app. Anche tutti i criteri di Posta in arrivo di Windows attivi nel dispositivo vengono conteggiati per questo limite. Per rimuovere il limite massimo di criteri, installare l'aggiornamento della sicurezza di Windows rilasciato il 9 aprile 2024 o dopo il 9 aprile 2024 e quindi riavviare il dispositivo. In caso contrario, ridurre il numero di criteri nel dispositivo per rimanere al di sotto di 32 criteri.

Nota

Il limite dei criteri non è stato rimosso in Windows 11 21H2 e rimane limitato a 32 criteri.

I criteri della modalità di controllo possono modificare il comportamento per alcune app o causare arresti anomali delle app

Anche se la modalità di controllo controllo app è progettata per evitare qualsiasi effetto sulle app, alcune funzionalità sono sempre attive o sempre applicate con qualsiasi criterio di controllo delle app che attiva l'integrità del codice in modalità utente (UMCI) con l'opzione 0 Abilitato:UMCI. Ecco un elenco di modifiche note del sistema in modalità di controllo:

• Alcuni host di script potrebbero bloccare il codice o eseguire codice con meno privilegi anche in modalità di controllo. Per informazioni sui comportamenti dei singoli host di script, vedere Applicazione di script con controllo app.
• L'opzione 19 Enabled:Dynamic Code Security viene sempre applicata se qualsiasi criterio UMCI include tale opzione in alcune versioni di Windows e Windows Server. Vedere Controllo app e .NET.

Le immagini native .NET potrebbero generare eventi di blocco falsi positivi

In alcuni casi, i log di integrità del codice in cui vengono scritti gli errori e gli avvisi di Controllo app per le aziende includono gli eventi di errore per le immagini native generate per gli assembly .NET. In genere, i blocchi di immagini nativi sono funzionalmente benigni perché un'immagine nativa bloccata rientra nell'assembly corrispondente e .NET rigenera l'immagine nativa nella finestra di manutenzione pianificata successiva. Per evitarlo, compilare l'applicazione .NET in codice nativo prima della funzionalità.

.NET non carica oggetti COM (Component Object Model) con GUID non corrispondenti

Gli oggetti COM semplificano la comunicazione e la collaborazione tra diversi componenti software. Per essere utilizzati da un altro componente, gli oggetti COM devono essere registrati con il sistema operativo. La registrazione include un GUID calcolato in base al codice dell'oggetto. Il caricamento e l'attivazione dell'oggetto COM vengono eseguiti usando un'altra parte della registrazione denominata nome del tipo. A volte esiste una mancata corrispondenza tra il GUID registrato e il GUID effettivo del codice dell'oggetto COM attivato. Le mancate corrispondenze potrebbero derivare da bug nel codice di registrazione dell'oggetto COM dell'app o se il codice dell'oggetto COM viene modificato in modo da influire sul GUID. In genere, Windows e .NET perdonano questa condizione ed eseguono il codice dell'oggetto COM indipendentemente. Tuttavia, consentire il caricamento di oggetti COM in presenza di mancata corrispondenza guid lascia il sistema vulnerabile agli utenti malintenzionati che possono sfruttare la confusione del GUID per eseguire codice imprevisto.

Per aumentare l'efficacia protettiva di Controllo app in un sistema vulnerabile a questa tecnica di attacco, .NET applica una convalida aggiuntiva per verificare che il GUID dell'oggetto COM registrato corrisponda a quello calcolato dal sistema. Se viene rilevata una mancata corrispondenza, .NET non carica l'oggetto COM e viene generato un errore di caricamento COM generale. Le app che usano oggetti COM con questa condizione possono comportarsi in modo imprevisto e devono essere aggiornate per risolvere i problemi relativi al codice di registrazione dell'oggetto COM dell'app.

Poiché questo comportamento si verifica solo quando i criteri di Controllo app vengono applicati al codice in modalità utente, non è possibile rilevarlo in modalità di controllo. Non sono presenti registrazione o altri eventi quando un oggetto COM non viene caricato a causa del controllo di convalida aggiuntivo. La riparazione o la reinstallazione dell'app può risolvere temporaneamente il problema, ma è necessario un aggiornamento dell'app per risolvere il problema di registrazione COM ed evitare istanze future del problema.

Non sono disponibili opzioni di controllo dei criteri per gestire . Controllo di verifica GUID di NET, ovvero il controllo viene sempre eseguito. Se vengono visualizzati errori degli oggetti COM dopo la distribuzione di un criterio di controllo app, contattare lo sviluppatore software o il fornitore di software indipendente (ISV) che produce l'app per richiedere una correzione per il problema.

Le firme che usano la crittografia a curva ellittica (ECC) non sono supportate

Le regole basate sul firmatario di Controllo app funzionano solo con la crittografia RSA. Gli algoritmi ECC, ad esempio ECDSA, non sono supportati. Se Controllo app blocca un file in base alle firme ECC, gli eventi di informazioni sulla firma 3089 corrispondenti mostrano VerificationError = 23. È possibile autorizzare i file tramite regole hash o attributi di file o usando altre regole del firmatario se il file è firmato anche con firme tramite RSA.

I programmi di installazione dell'identità del servizio gestito vengono considerati come scrivibili dall'utente in Windows 10 quando sono consentiti dalla regola FilePath

I file del programma di installazione msi vengono sempre rilevati come scrivibili dall'utente in Windows 10 e Windows Server 2022 e versioni precedenti. Se è necessario consentire i file MSI usando regole FilePath, è necessario impostare l'opzione 18 Disabled:Runtime FilePath Rule Protection nei criteri di Controllo app.

I programmi di installazione msi avviati direttamente da Internet sono bloccati

L'installazione di file .msi direttamente da Internet in un computer protetto da Controllo app non riesce. Ad esempio, questo comando ha esito negativo:

msiexec -i https://download.microsoft.com/download/2/E/3/2E3A1E42-8F50-4396-9E7E-76209EA4F429/Windows10_Version_1511_ADMX.msi

Come soluzione alternativa, scaricare il file MSI ed eseguirlo in locale:

msiexec -i c:\temp\Windows10_Version_1511_ADMX.msi

Avvio lento e prestazioni con criteri personalizzati

Controllo app valuta tutti i processi in esecuzione, inclusi i processi di Windows nella posta in arrivo. È possibile causare tempi di avvio più lenti, prestazioni ridotte ed eventualmente problemi di avvio se i criteri non si basano sui modelli di Controllo app o non considerano attendibili i firmatari di Windows. Per questi motivi, è consigliabile usare i modelli di base di Controllo app quando possibile per creare i criteri.

I criteri di assegnazione di tag AppId valutano i file DLL non inclusi nell'ambito per l'assegnazione di tag

Quando si usano i criteri di assegnazione di tag AppId, il risultato sono i metadati, i "tag", aggiunti al token di processo di qualsiasi file eseguibile che passa i criteri. È quindi possibile usare i tag per modificare il comportamento di un'app o di un componente che riconosce il tag AppId e cerca un tag corrispondente in un processo. Ad esempio, è possibile impostare una regola di Windows Firewall che usa un tag personalizzato per identificare i processi che devono essere autorizzati a connettersi tramite il firewall. I tag AppId si applicano solo ai file eseguibili (ES) e non si applicano mai ad altri tipi di codice, ad esempio le librerie a collegamento dinamico (DLL). Tuttavia, quando viene eseguita una DLL, Controllo app valuta il file in base ai criteri, a meno che non esista una regola per consentire tutti i file di quel tipo. Per eseguire la valutazione dei criteri di corto circuito per le DLL e ridurre ulteriormente l'impatto di Controllo app sulle prestazioni, aggiungere la regola seguente ai criteri di assegnazione di tag AppId: