Control de aplicaciones para empresas y .NET
Advertencia
Cuando se aplica App Control, .NET no carga determinados objetos del modelo de objetos componentes (COM) si su GUID de registro no coincide con el calculado por el sistema en tiempo de ejecución. Cuando esto sucede, el usuario ve un cuadro de diálogo general de error de carga COM, pero no se registra ningún evento u otra información en el sistema. Para obtener más información, vea App Control Administración Tips & Known Issues: .NET doesn't load COM objects with mismatched GUIDs (Sugerencias de control de aplicaciones Administración sugerencias & problemas conocidos: .NET no carga objetos COM con GUID no coincidentes).
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 problema funcional. Dado que el IL se está compilando ahora en tiempo de ejecución, es posible que observe una ligera reducción 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 reducción de rendimiento causada 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. - Migre aplicaciones a .NET Core (.NET 6 o posterior) y habilite AOT nativo.
Control de aplicaciones y protección de seguridad de código dinámico 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 el 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 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 o remotos, como Internet o un recurso compartido de red. También detecta alteraciones en el código generado en el disco por .NET y bloquea la carga de código que está alterado. Además, algunas características de carga de .NET no compatibles con la seguridad dinámica de código, incluida la carga de ensamblados sin firmar creados con System.Reflection.Emit, siempre se bloquean.
Normalmente, cuando se bloquea el código dinámico, su proceso primario se detiene o se bloquea. Para evitarlo mediante ASP.NET, puede precompilar el código dinámico solo para la implementación. Consulte "Precompiling for Deployment Only" (Precompiling for Deployment Only) en ASP.NET Precompilation Overview (Introducción a la precompilación).
Importante
La seguridad de código dinámico de .NET solo funciona en modo de auditoría en Windows 11 24H2 y versiones posteriores, y Windows Server 2025 y versiones posteriores. No hay ningún modo de auditoría para la seguridad dinámica de código en Windows 10 o en versiones anteriores de Windows 11 y Windows Server. Si alguna directiva de Control de aplicaciones establece la opción 19 Enabled:Dynamic Code Security en esas versiones anteriores, la protección de la seguridad dinámica del código se activa y se aplica incluso si la directiva está en modo de auditoría. Pruebe siempre las aplicaciones exhaustivamente y use prácticas de implementación seguras al implementar directivas de control de aplicaciones en producción.
Dynamic Code Security mitiga las posibles técnicas de ataque a menudo denominadas ataques de "segundo orden". Esto significa que el atacante tiene acceso al sistema y es capaz de ejecutar código. Los ataques de segundo orden pueden ser intentos de obtener persistencia o ocultar aún más las actividades de los atacantes. Aunque la seguridad dinámica de código es importante y se recomienda, Microsoft también recomienda probar la directiva en modo de auditoría en sistemas que ejecutan Windows 11 24H2 y versiones posteriores, o Windows Server 2025 y versiones posteriores antes de aplicarla.
El código bloqueado por Dynamic Code Security se registra mediante el identificador de evento 3114 en el registro de eventos CodeIntegrity - Operational . Excepto para el código cargado con una de las características de .NET no admitidas, como System.Reflection.Emit, puede crear reglas para permitir código dinámico bloqueado mediante información de los eventos. Consulte Uso del Asistente para control de aplicaciones para crear reglas a partir de los registros de eventos de App Control.
Nota
.NET intenta que dos métodos diferentes ejecuten código generado dinámicamente. Si la directiva de Control de aplicaciones bloquea el primer método, .NET intenta el segundo. Cada uno de los dos intentos genera un evento 3114 distinto. Cuando se produce un evento 3114 de forma aislada, es seguro omitirlo como un "falso positivo" porque solo cubre el primer intento de .NET de ejecutar el código. Solo cuando se ven dos eventos 3114 en milisegundos para el mismo código, indica un problema real que se debe revisar.
Para habilitar la seguridad dinámica de código, agregue la opción 19 - Enabled:Dynamic Code Security a la directiva de App Control mediante el Asistente para control de aplicaciones, el cmdlet set-ruleoption de PowerShell o agregando lo siguiente a la <Rules> sección del XML de directiva de App Control:
<Rule>
<Option>Enabled:Dynamic Code Security</Option>
</Rule>