Controllo app per le aziende e .NET

Warning

Quando viene applicato il controllo app, .NET non carica determinati oggetti COM (Component Object Model) se il GUID di registrazione non corrisponde a quello calcolato dal sistema in fase di esecuzione. In questo caso, l'utente visualizza una finestra di dialogo di errore di caricamento COM generale, ma non vengono registrati eventi o altre informazioni nel sistema. Per altre informazioni, vedere Controllo app Amministrazione Suggerimenti & Problemi noti: .NET non carica oggetti COM con GUID non corrispondenti.

Le app .NET (come scritto in un linguaggio di alto livello come C#) vengono compilate in un linguaggio intermedio (IL). IL è un formato di codice compatto che può essere supportato in qualsiasi sistema operativo o architettura. La maggior parte delle app .NET usa API supportate in più ambienti, che richiedono solo il runtime .NET per l'esecuzione. IL deve essere compilato in codice nativo per essere eseguito su una CPU, ad esempio Arm64 o x64. Quando .NET compila IL in un'immagine nativa (NI) in un dispositivo con criteri di modalità utente di Controllo app, controlla prima di tutto se il file IL originale supera i criteri di Controllo app correnti. In tal caso, .NET imposta un attributo esteso NTFS (EA) nel file NI generato in modo che il controllo app sappia considerarlo attendibile. Quando viene eseguita l'app .NET, Controllo app visualizza l'EA nel file NI e lo consente.

Il set EA nel file NI si applica solo ai criteri di controllo app attualmente attivi. Se uno dei criteri di controllo delle app attivi viene aggiornato o viene applicato un nuovo criterio, l'EA nel file NI viene invalidato. La volta successiva in cui viene eseguita l'app, Controllo app bloccherà il file NI. .NET gestisce il blocco in modo normale e restituisce il codice IL originale. Se il servizio di bilanciamento del carico supera ancora i criteri di controllo delle app più recenti, l'app viene eseguita senza problemi funzionali. Poiché il codice IL è ora in fase di compilazione in fase di esecuzione, si potrebbe notare una leggera riduzione delle prestazioni dell'app. Quando .NET deve tornare a IL, .NET pianificherà anche l'esecuzione di un processo nella finestra di manutenzione successiva per rigenerare tutti i file NI, ristabilindo così l'EA controllo app per tutto il codice che supera i criteri di controllo delle app più recenti.

In alcuni casi, se un file NI è bloccato, è possibile che venga visualizzato un evento di blocco "falso positivo" nel registro eventi CodeIntegrity - Operational come descritto in Controllo app Amministrazione Suggerimenti & Problemi noti.

Per attenuare eventuali riduzioni delle prestazioni causate quando l'EA del controllo app non è valido o manca:

• Evitare di aggiornare spesso i criteri di Controllo app.
• Eseguire ngen update (in tutte le architetture del computer) per forzare .NET a rigenerare tutti i file NI immediatamente dopo aver applicato le modifiche ai criteri di Controllo app.
• Eseguire la migrazione delle applicazioni a .NET Core (.NET 6 o versione successiva) e abilitare AOT nativo.

Controllo delle app e protezione avanzata di .NET Dynamic Code Security

I ricercatori di sicurezza hanno scoperto che alcune funzionalità .NET che consentono alle app di caricare librerie da origini esterne o generare nuovo codice in fase di esecuzione possono essere usate per aggirare il controllo delle app. Per risolvere questa potenziale vulnerabilità, Controllo app include un'opzione denominata Dynamic Code Security che funziona con .NET per verificare il codice caricato in fase di esecuzione.

Quando la sicurezza dinamica del codice è abilitata, i criteri di controllo app vengono applicati alle librerie caricate da .NET da origini esterne o remote, ad esempio Internet o una condivisione di rete. Rileva anche manomissioni nel codice generato su disco da .NET e blocca il caricamento del codice manomessa. Inoltre, alcune funzionalità di caricamento .NET non supportate con Dynamic Code Security, incluso il caricamento di assembly non firmati compilati con System.Reflection.Emit, sono sempre bloccate.

In genere, quando il codice dinamico viene bloccato, il processo padre viene arrestato o arrestato in modo anomalo. Per evitare questo errore usando ASP.NET, è possibile precompilare il codice dinamico solo per la distribuzione. Vedere "Precompilazione solo per la distribuzione" nella panoramica della precompilazione ASP.NET.

Importante

.NET Dynamic Code Security funziona in modalità di controllo solo in Windows 11 24H2 e versioni successive e Windows Server 2025 e versioni successive. Non è disponibile alcuna modalità di controllo per la sicurezza dinamica del codice in Windows 10 o nelle versioni precedenti di Windows 11 e Windows Server. Se un criterio di Controllo app imposta l'opzione 19 Enabled:Dynamic Code Security in tali versioni precedenti, la protezione avanzata della sicurezza del codice dinamico viene attivata e applicata anche se i criteri sono in modalità di controllo. Testare sempre accuratamente le app e usare procedure di distribuzione sicure quando si distribuiscono i criteri di controllo delle app nell'ambiente di produzione.

La sicurezza dinamica del codice riduce le potenziali tecniche di attacco spesso definite attacchi di "secondo ordine". Ciò significa che l'utente malintenzionato ha accesso al sistema ed è in grado di eseguire il codice. Gli attacchi di secondo ordine potrebbero essere tentativi di ottenere persistenza o nascondere ulteriormente le attività degli utenti malintenzionati. Sebbene la sicurezza dinamica del codice sia importante e consigliata, Microsoft consiglia anche di testare i criteri in modalità di controllo nei sistemi in esecuzione Windows 11 24H2 e versioni successive o Windows Server 2025 e versioni successive prima di applicarlo.

Il codice bloccato da Dynamic Code Security viene registrato usando l'ID evento 3114 nel registro eventi CodeIntegrity - Operational . Ad eccezione del codice caricato usando una delle funzionalità .NET non supportate, ad esempio System.Reflection.Emit, è possibile creare regole per consentire il codice dinamico bloccato usando le informazioni degli eventi. Vedere Usare la Creazione guidata controllo app per creare regole dai log eventi di Controllo app.

Nota

.NET tenta due metodi diversi per eseguire codice generato in modo dinamico. Se i criteri di Controllo app bloccano il primo metodo, .NET prova il secondo. Ognuno dei due tentativi genera un evento 3114 distinto. Quando si verifica un evento 3114 in isolamento, è possibile ignorare come "falso positivo" perché copre solo il primo tentativo da parte di .NET di eseguire il codice. Solo quando vengono visualizzati due eventi 3114 back-to-back in millisecondi per lo stesso codice, indica un problema effettivo da esaminare.

Per abilitare La sicurezza dinamica del codice, aggiungere l'opzione 19 - Enabled:Dynamic Code Security ai criteri di Controllo app usando la Creazione guidata controllo app, il cmdlet PowerShell set-ruleoption o aggiungendo quanto segue alla <Rules> sezione del codice XML dei criteri di Controllo app:

<Rule>
    <Option>Enabled:Dynamic Code Security</Option>
</Rule>