Controllo app per le aziende e .NET
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 livello di integrità supera ancora i criteri di controllo delle app più recenti, l'app viene eseguita senza alcun impatto funzionale. Poiché il codice IL è ora in fase di compilazione in fase di esecuzione, si potrebbe notare un leggero impatto sulle 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 effetti sulle prestazioni causati quando l'EA del controllo app non è valido o mancante:
- 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).
Controllo app e protezione avanzata di .NET
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 i controlli di 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 l'opzione Dynamic Code Security è abilitata, i criteri di controllo delle app vengono applicati alle librerie caricate da .NET da origini esterne. Ad esempio, qualsiasi origine remota, ad esempio Internet o una condivisione di rete.
Importante
La protezione avanzata della sicurezza del codice dinamico .Net è attivata e applicata se qualsiasi criterio di controllo delle app con UMCI abilitato ha impostato l'opzione 19 Enabled:Dynamic Code Security. Non è disponibile alcuna modalità di controllo per questa funzionalità. È consigliabile testare le app con questa opzione impostata prima di attivarla su un numero elevato di dispositivi.
Inoltre, rileva la manomissione nel codice generato su disco da .NET e blocca il caricamento del codice manomesso.
La sicurezza dinamica del codice non è abilitata per impostazione predefinita perché i criteri esistenti potrebbero non tenere conto delle librerie caricate esternamente. Inoltre, alcune funzionalità di caricamento di .NET, incluso il caricamento di assembly non firmati compilati con System.Reflection.Emit, non sono attualmente supportate con La sicurezza dinamica del codice è abilitata. Microsoft consiglia di testare la sicurezza dinamica del codice in modalità di controllo prima di applicarla per scoprire se eventuali nuove librerie devono essere incluse nei criteri.
Inoltre, i clienti possono precompilare per la distribuzione solo per impedire l'interruzione di un eseguibile consentito perché tenta di caricare codice generato dinamicamente non firmato. Per informazioni su come risolvere il problema, vedere la sezione "Precompilazione solo per la distribuzione" nel documento Panoramica della precompilazione ASP.NET .
Per abilitare Dynamic Code Security, aggiungere l'opzione seguente alla <Rules> sezione dei criteri di controllo delle app:
<Rule>
<Option>Enabled:Dynamic Code Security</Option>
</Rule>