Control de aplicaciones para empresas y .NET
Las aplicaciones .NET (como se escriben en un lenguaje de alto nivel como C#) se compilan en un lenguaje intermedio (IL). IL es un formato de código compacto que se puede admitir en cualquier sistema operativo o arquitectura. La mayoría de las aplicaciones .NET usan API que se admiten en varios entornos, lo que requiere que solo se ejecute el entorno de ejecución de .NET. IL debe compilarse en código nativo para poder ejecutarse en una CPU, por ejemplo Arm64 o x64. Cuando .NET compila IL en una imagen nativa (NI) en un dispositivo con una directiva de modo de usuario de Control de aplicaciones, primero comprueba si el archivo IL original pasa las directivas de Control de aplicaciones actuales. Si es así, .NET establece un atributo extendido NTFS (EA) en el archivo NI generado para que App Control también sepa confiar en él. Cuando se ejecuta la aplicación .NET, App Control ve el EA en el archivo NI y lo permite.
El conjunto de EA en el archivo NI solo se aplica a las directivas de Control de aplicaciones actualmente activas. Si se actualiza una de las directivas activas de App Control o se aplica una nueva, se invalida el ea en el archivo ni. La próxima vez que se ejecute la aplicación, App Control bloqueará el archivo NI. .NET controla el bloque correctamente y vuelve al código de IL original. Si el IL sigue pasando las directivas de App Control más recientes, la aplicación se ejecuta sin ningún impacto funcional. Dado que el IL se está compilando ahora en tiempo de ejecución, es posible que observe un ligero impacto en el rendimiento de la aplicación. Cuando .NET debe volver a IL, .NET también programará un proceso para que se ejecute en la siguiente ventana de mantenimiento para volver a generar todos los archivos NI, de modo que se restablezca el ea de Control de aplicaciones para todo el código que pasa las directivas de Control de aplicaciones más recientes.
En algunos casos, si se bloquea un archivo NI, es posible que vea un evento de bloque "falso positivo" en el registro de eventos operativos codeintegrity, tal como se describe en App Control Administración Sugerencias & problemas conocidos.
Para mitigar cualquier impacto en el rendimiento causado cuando app control EA no es válido o falta:
- Evite actualizar las directivas de App Control a menudo.
- Ejecute
ngen update(en todas las arquitecturas de máquina) para forzar a .NET a volver a generar todos los archivos NI inmediatamente después de aplicar los cambios a las directivas de App Control. - Migrar aplicaciones a .NET Core (.NET 6 o posterior).
Control de aplicaciones y protección de .NET
Los investigadores de seguridad descubrieron que algunas funcionalidades de .NET que permiten a las aplicaciones cargar bibliotecas desde orígenes externos o generar código nuevo en tiempo de ejecución se pueden usar para eludir los controles de Control de aplicaciones. Para solucionar esta posible vulnerabilidad, App Control incluye una opción denominada Seguridad dinámica de código que funciona con .NET para comprobar el código cargado en tiempo de ejecución.
Cuando la opción Seguridad dinámica de código está habilitada, la directiva de Control de aplicaciones se aplica a las bibliotecas que .NET carga desde orígenes externos. Por ejemplo, cualquier origen remoto, como Internet o un recurso compartido de red.
Importante
La protección de la seguridad del código dinámico de .Net está activada y aplicada si alguna directiva de Control de aplicaciones con UMCI habilitado ha establecido la opción 19 Enabled:Dynamic Code Security. No hay ningún modo de auditoría para esta característica. Debe probar las aplicaciones con esta opción establecida antes de activarlas en un gran número de dispositivos.
Además, detecta la alteración del código generado en el disco por .NET y bloquea la carga de código con el que se ha manipulado.
La seguridad dinámica de código no está habilitada de forma predeterminada porque las directivas existentes podrían no tener en cuenta las bibliotecas cargadas externamente. Además, algunas características de carga de .NET, incluida la carga de ensamblados sin firmar creados con System.Reflection.Emit, no se admiten actualmente con la seguridad dinámica de código habilitada. Microsoft recomienda probar la seguridad de código dinámico en modo de auditoría antes de aplicarla para detectar si se deben incluir nuevas bibliotecas en la directiva.
Además, los clientes pueden precompilar para la implementación solo para evitar que se termine un ejecutable permitido porque intenta cargar código generado dinámicamente sin signo. Consulte la sección "Precompiling for Deployment Only" (Precompiling for Deployment Only) del documento ASP.NET Precompilation Overview (Introducción a la precompilación) para ver cómo corregirlo.
Para habilitar la seguridad dinámica de código, agregue la siguiente opción a la sección de la <Rules> directiva de App Control:
<Rule>
<Option>Enabled:Dynamic Code Security</Option>
</Rule>