Contrôle d’application pour les entreprises et .NET
Les applications .NET (telles qu’elles sont écrites dans un langage de haut niveau comme C#) sont compilées en langage intermédiaire (IL). IL est un format de code compact qui peut être pris en charge sur n’importe quel système d’exploitation ou architecture. La plupart des applications .NET utilisent des API prises en charge dans plusieurs environnements, ce qui nécessite uniquement l’exécution du runtime .NET. Il doit être compilé en code natif pour s’exécuter sur un processeur, par exemple Arm64 ou x64. Quand .NET compile IL en image native (NI) sur un appareil avec une stratégie de mode utilisateur App Control, il vérifie d’abord si le fichier IL d’origine transmet les stratégies App Control actuelles. Si c’est le cas, .NET définit un attribut étendu NTFS (EA) sur le fichier NI généré afin que Le contrôle d’application sache également qu’il doit lui faire confiance. Lorsque l’application .NET s’exécute, Le contrôle d’application voit l’ea sur le fichier NI et l’autorise.
L’ea défini sur le fichier NI s’applique uniquement aux stratégies App Control actuellement actives. Si l’une des stratégies App Control actives est mise à jour ou si une nouvelle stratégie est appliquée, l’ea sur le fichier NI est invalidé. La prochaine fois que l’application s’exécute, Le contrôle d’application bloque le fichier NI. .NET gère le bloc correctement et revient au code IL d’origine. Si l’il passe toujours les dernières stratégies de contrôle d’application, l’application s’exécute sans aucun impact fonctionnel. Étant donné que l’il est maintenant compilé au moment de l’exécution, vous pouvez remarquer un léger impact sur les performances de l’application. Lorsque .NET doit revenir à IL, .NET planifie également l’exécution d’un processus à la fenêtre de maintenance suivante pour régénérer tous les fichiers NI, rétablissant ainsi l’ea de contrôle d’application pour tout le code qui passe les dernières stratégies App Control.
Dans certains cas, si un fichier NI est bloqué, vous pouvez voir un événement de bloc « faux positif » dans le journal des événements CodeIntegrity - Operational, comme décrit dans Contrôle d’application Administration Conseils & Problèmes connus.
Pour atténuer tout impact sur les performances provoqué lorsque l’EA App Control n’est pas valide ou manquant :
- Évitez de mettre à jour les stratégies de contrôle d’application souvent.
- Exécutez
ngen update(sur toutes les architectures de machine) pour forcer .NET à régénérer tous les fichiers NI immédiatement après avoir appliqué des modifications à vos stratégies De contrôle d’application. - Migrer des applications vers .NET Core (.NET 6 ou version ultérieure).
Contrôle d’application et renforcement .NET
Les chercheurs en sécurité ont constaté que certaines fonctionnalités .NET qui permettent aux applications de charger des bibliothèques à partir de sources externes ou de générer du nouveau code au moment de l’exécution peuvent être utilisées pour contourner les contrôles App Control. Pour résoudre cette vulnérabilité potentielle, App Control inclut une option appelée Dynamic Code Security qui fonctionne avec .NET pour vérifier le code chargé au moment de l’exécution.
Lorsque l’option Sécurité du code dynamique est activée, la stratégie De contrôle d’application est appliquée aux bibliothèques que .NET charge à partir de sources externes. Par exemple, toutes les sources distantes, telles qu’Internet ou un partage réseau.
Important
Le renforcement de la sécurité du code dynamique .Net est activé et appliqué si une stratégie de contrôle d’application avec UMCI activée a défini l’option 19 Enabled :Dynamic Code Security. Il n’existe aucun mode d’audit pour cette fonctionnalité. Vous devez tester vos applications avec cette option définie avant de l’activer sur un grand nombre d’appareils.
En outre, il détecte la falsification du code généré sur le disque par .NET et bloque le chargement du code qui a été falsifié.
La sécurité du code dynamique n’est pas activée par défaut, car les stratégies existantes peuvent ne pas prendre en compte les bibliothèques chargées en externe. En outre, certaines fonctionnalités de chargement .NET, notamment le chargement d’assemblys non signés créés avec System.Reflection.Emit, ne sont pas prises en charge actuellement avec Dynamic Code Security activé. Microsoft recommande de tester la sécurité du code dynamique en mode audit avant de l’appliquer pour déterminer si de nouvelles bibliothèques doivent être incluses dans la stratégie.
En outre, les clients peuvent précompiler pour le déploiement uniquement pour empêcher l’arrêt d’un exécutable autorisé, car il tente de charger du code généré dynamiquement non signé. Consultez la section « Précompilation pour le déploiement uniquement » dans le document vue d’ensemble de la précompilation ASP.NET pour savoir comment résoudre ce problème.
Pour activer la sécurité du code dynamique, ajoutez l’option suivante à la <Rules> section de votre stratégie De contrôle d’application :
<Rule>
<Option>Enabled:Dynamic Code Security</Option>
</Rule>