AppLocker, App Control for Business (WDAC) y la distribución de aplicaciones empresariales ── antes de que las bloquee el «control de ejecución»

«La instalé en el PC del cliente y la aplicación no arranca. Al hacer doble clic no pasa nada»: en la distribución de aplicaciones empresariales, la causa puede no ser solo un defecto de la propia aplicación, sino el control de ejecución de aplicaciones del entorno del cliente. A veces el exe arranca y solo se detienen las DLL o los scripts que van con él.

En ese momento, en lugar de cambiar de entrada la firma o la carpeta de instalación, hay que aislar qué mecanismo detuvo qué archivo, y con qué fundamento.

Este artículo organiza el control de ejecución de Windows desde la perspectiva de quien crea y distribuye la aplicación. Tras fijar las diferencias entre AppLocker, App Control for Business (antes WDAC, Windows Defender Application Control), Smart App Control y SmartScreen, pasa a los bloqueos típicos, a cómo leer los registros de eventos y a las medidas previas a la distribución. Al final resume también el procedimiento para sistemas de información que vayan a implementarlo en sus propios equipos.

1. Primero la conclusión

• Empiece por distinguir los cuatro mecanismos y fije el objetivo en el registro. La advertencia de SmartScreen, el control de AppLocker por usuario y por grupo, el control de App Control en toda la máquina y la protección de Smart App Control para PC personales no son lo mismo. Si es un exe o una DLL de AppLocker, el centro de la investigación es el 8004; si es App Control, el 3077 y la información de firma 3089. En scripts y MSI, compruebe también el otro registro.¹²
• El lado que distribuye hace una aplicación cuyas reglas de permiso siguen coincidiendo después de una actualización. El eje es una firma coherente que cubre no solo el exe, sino también las DLL, el instalador y los scripts incluidos. Alinee también la información del editor, los atributos del archivo, la ubicación y el flujo de actualización automática. Incluso en un PC que no está bajo administración empresarial, Smart App Control puede detener una aplicación sin firmar.³⁴
• El lado que lo implementa deja que el negocio dé un ciclo completo en modo de auditoría antes de pasar a la aplicación. Elija App Control cuando pueda, y use AppLocker cuando haga falta un control por usuario u otra razón similar. No se puede dar por sentado que «los PC del cliente son Pro, así que esto no va con nosotros». En Windows 10 2004 en adelante con la KB 5024351 y en Windows 11, aplicar AppLocker no exige una edición concreta, y App Control cubre todas las ediciones cliente.³⁵

Cómo leerlo según el objetivo

Con PowerShell, a veces el script no se bloquea del todo, sino que se ejecuta en modo de lenguaje restringido y solo falla una parte del tratamiento. El capítulo 4 cubre también esta diferencia.²

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (36 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. Distinguir los cuatro mecanismos

Separe los productos de nombre parecido por «objetivo», «cómo actúan» y «quién los administra». Empiece por ver si lo que hay que tratar es una advertencia o una comprobación contra las reglas de permiso de un administrador.

2.1. SmartScreen ── el único mecanismo que detiene con una «advertencia»

SmartScreen es un mecanismo que advierte según la reputación del archivo. Actúa por defecto aunque no haya un administrador que escriba reglas, y de ordinario el usuario puede superar la advertencia y ejecutarlo.

Ahora bien, si está aplicada una directiva de administración que prohíbe superar la advertencia, SmartScreen también se convierte en un bloqueo de hecho. No significa «es una advertencia, así que siempre se puede ejecutar».

Las medidas del lado que distribuye hay que pensarlas aparte de pedir al cliente que escriba reglas de permiso de AppLocker u otros. En SmartScreen el eje es la firma y la acumulación de reputación. El detalle está en «Windows SmartScreen y la firma de código». Los apartados 2.2 a 2.4 que siguen son mecanismos que bloquean la ejecución, no que advierten.

2.2. AppLocker ── el veterano que puede controlar por usuario

Con qué fundamento, y de quién, controla la ejecución

AppLocker se introdujo en Windows 7. El fundamento de las reglas son los atributos del certificado de firma de código (el editor), los atributos de archivo derivados de los metadatos de firma (nombre de archivo original y versión), el hash y la ruta del archivo. La directiva se puede aplicar no solo a todo el equipo, sino también a usuarios y grupos concretos.³

Separar «se pueden crear reglas» de «se pueden aplicar»

Los requisitos de edición se entienden mejor si se separan esas dos cosas. Desde la KB 5024351, en Windows 10 versión 2004 en adelante y en todas las ediciones de Windows 11 no hace falta una edición concreta para aplicar las directivas de AppLocker.⁵

En Windows antiguos, en cambio, sigue habiendo diferencias según el método de distribución. En un entorno que incluye Windows 10 anterior a 2004 o Windows Server 2019, se mantienen las condiciones de siempre: la aplicación de una directiva distribuida por Directiva de grupo solo está en las ediciones Enterprise y Server; la distribución por MDM funciona en todas las ediciones.⁵

En Pro también se pueden crear reglas. La restricción anterior era sobre todo si se aplican o no, y con distribución por MDM ya entonces se podían aplicar en Pro. Los tipos de regla —archivos ejecutables, Windows Installer, scripts, DLL y aplicaciones empaquetadas— tampoco cambian con la edición.⁵

Hay además un requisito distinto de la edición. Si el servicio Application Identity (AppIDSvc) no está en ejecución, las reglas no se evalúan. El capítulo 6 lo comprueba junto con la preparación de la auditoría.

Su lugar como función de seguridad

Microsoft indica con claridad que AppLocker no cumple los criterios de servicio (servicing criteria) del MSRC para una función de seguridad. Aunque se encuentre una técnica de evasión, ese hecho por sí solo no se trata como vulnerabilidad de seguridad. En este punto también se diferencia del App Control que sigue.³

2.3. App Control for Business ── la opción de fondo como función de seguridad

Un mecanismo que se aplica a toda la máquina

App Control for Business es el nombre actual del mecanismo que en Windows 10, como parte de Device Guard, se llamó «integridad de código configurable». Durante mucho tiempo se conoció como WDAC. Las directivas se aplican a toda la máquina y afectan a todos los usuarios de ese dispositivo. Este sí está diseñado como función de seguridad según los criterios de servicio del MSRC.³

El fundamento de las reglas se puede ordenar así.³

Condiciones de uso y métodos de distribución

Las directivas se pueden crear y aplicar en cualquier edición cliente de Windows 10/11, o en Windows Server 2016 en adelante. Para distribuirlas se pueden usar MDM como Intune, Configuration Manager o PowerShell. También se puede usar Directiva de grupo, pero queda limitada al formato de directiva única que funciona en Windows Server 2016/2019.³

Cómo elegir entre esto y AppLocker

Microsoft recomienda usar App Control cuando se pueda implementar con App Control. App Control sigue mejorando, mientras que AppLocker recibe correcciones de seguridad pero no se le añaden funciones nuevas.³

AppLocker encaja cuando se quiere distribuir la misma directiva en un entorno mixto que incluye Windows antiguo, o cuando en un PC compartido se quieren reglas distintas por usuario o grupo. También se puede usar como complemento de App Control para añadir restricciones por usuario.³

2.4. Smart App Control ── el control de ejecución que ya está «por su cuenta» en el PC personal

Smart App Control es una función de protección para usuarios particulares de Windows 11. En tiempo de ejecución comprueba la predicción de seguridad de un servicio en la nube y si hay una firma válida. Bloquea las aplicaciones consideradas maliciosas y las que no tienen una firma válida y cuya confianza no se puede confirmar.⁴

En un PC nuevo empieza en modo de evaluación; Windows decide si encaja con ese usuario y entonces se activa o se desactiva. En usuarios que van a tropezar a menudo con bloqueos, como los desarrolladores, se desactiva de forma automática.⁴

El punto que el lado que distribuye debe fijar es que el control de ejecución actúa también en un PC en el que sistemas de información no ha escrito ninguna directiva. Los clientes de pequeña empresa o autónomos no quedan fuera. Una aplicación sin firmar puede detenerse, y Microsoft también indica a los desarrolladores que firmen con un certificado válido. Cómo elegir el certificado se ordena en el capítulo 5.⁴

3. Patrones típicos en los que su aplicación queda bloqueada

Compruebe no solo «si arranca el programa principal», sino también la instalación, la carga de DLL, los scripts, los complementos y la actualización automática. Los patrones que más suelen dar problemas en el desarrollo a medida y en la distribución empaquetada son estos.

La causa común es que el fundamento de las reglas de permiso no es estable

Lo que la tabla tiene en común es que el lado que permite necesita un fundamento (firma, ruta, hash) que el lado que distribuye no está ofreciendo de forma estable.

Por ejemplo, aunque solo se firme el exe, las DLL sin firmar no pueden usar la misma regla de editor. Si se permiten con reglas de hash individuales, cada vez que una actualización cambie el binario hay que actualizar las reglas. Puede parecer que la causa es el control del cliente cuando, en realidad, el material distribuido o el método de actualización hacen que las reglas se rompan con facilidad.

Cuando los síntomas hayan acotado los candidatos, los registros siguientes permiten fijar el archivo que realmente se detuvo. Pensar la medida viene después.

4. Fijar lo ocurrido con el registro

En el registro de eventos, lea por separado «el hecho de que se detuvo» y «qué hay que corregir». La entrada son las dos familias bajo AppLocker y CodeIntegrity, pero lo importante es que también se registran eventos de App Control bajo un registro cuyo nombre es AppLocker.²

4.1. Eventos de AppLocker

Abrir el registro y elegir el tipo de objetivo

Abra el Visor de eventos buscando «Visor de eventos» en el menú Inicio, o escribiendo eventvwr.msc en Ejecutar.¹

Visor de eventos > Registros de aplicaciones y servicios > Microsoft > Windows > AppLocker > EXE and DLL / MSI and Script / Packaged app-Deployment / Packaged app-Execution

En un entorno en inglés es Applications and Services Logs > Microsoft > Windows > AppLocker.

Para obtenerlos con PowerShell, abra una sesión de administrador y ejecute el comando siguiente. Este ejemplo extrae solo auditorías y bloqueos de exe/DLL de las últimas 24 horas. Scripts y MSI no entran.

# Extraer bloqueos (8004) y auditorías (8003) de AppLocker de las últimas 24 horas
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-AppLocker/EXE and DLL'
    Id        = 8003, 8004
    StartTime = (Get-Date).AddDays(-1)
} | Format-List TimeCreated, Id, Message

¿Coincidió con una regla de denegación, o falta una regla de permiso?

El evento registra la ruta del archivo, el resultado de permiso o bloqueo, el tipo de regla (ruta, hash, editor), el nombre de la regla y el SID del usuario o grupo.¹

En una operación de lista de permitidos, sin embargo, lo más frecuente es la «denegación implícita» de no coincidir con ninguna regla de permiso.

El 8004 dice que hubo un bloqueo y cuál era el objetivo, pero en una denegación implícita el nombre de la regla por sí solo no identifica la causa. Hay que cotejar el evento con la directiva en vigor, no solo mirar el evento.

4.2. Eventos de App Control for Business (WDAC)

exe, DLL y controladores van en un registro distinto de los scripts

El control de exe, DLL y controladores se comprueba en el registro CodeIntegrity siguiente. El de MSI, scripts y COM se registra en el registro AppLocker - MSI and Script de más arriba.²

Visor de eventos > Registros de aplicaciones y servicios > Microsoft > Windows > CodeIntegrity > Operational (en un entorno en inglés, Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational)

# Ver juntos los bloqueos (3077) y auditorías (3076) de App Control y la información de firma correspondiente (3089)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id        = 3076, 3077, 3089
    StartTime = (Get-Date).AddDays(-1)
} | Sort-Object TimeCreated | Format-List TimeCreated, Id, Message

Este comando obtiene los 3076, 3077 y 3089 de CodeIntegrity. Al investigar MSI, scripts o COM, siga la tabla siguiente y compruebe por separado también AppLocker - MSI and Script. Mientras no se sepa qué mecanismo interviene, coteje los registros bajo AppLocker y CodeIntegrity en el mismo intervalo de tiempo.

Con el 3089, comprobar la firma que se evaluó de verdad

Se genera un evento 3089 por cada firma del archivo. En un archivo sin firmar sale un evento con recuento de firmas 0. Se corresponde con 3076, 3077 y otros por el Activity ID de correlación.²

Problemas como «debería estar firmado y se trata como no firmado» o «sigue la firma de un certificado antiguo» se confirman con esta información de firma. Coteje el estado del archivo que comprobó el lado que distribuye con el estado del archivo que evaluó el lado del cliente.

Aunque haya un 8029, PowerShell no tiene por qué detenerse del todo

El 8029 indica el bloqueo de un script, pero el comportamiento real de aplicación se deja al host de scripts. PowerShell no detiene del todo un script que la directiva no permite: lo ejecuta en modo de lenguaje restringido (Constrained Language Mode).²

En este modo, la creación de objetos .NET queda muy limitada. El síntoma es «el script arrancó, pero falló solo una línea a mitad». En la investigación de un script incluido, no juzgue solo por si arrancó. La práctica de la firma está en «Directiva de ejecución de PowerShell y firma de scripts».

Además, la edición Windows Server Core no tiene el registro AppLocker - MSI and Script. Al investigar una aplicación en un servidor, hay que atender también a si el registro existe.²

5. Medidas del lado que distribuye ── hacer una aplicación «fácil de escribir en reglas»

El objetivo es distribuir en un estado en el que el departamento de sistemas de información del cliente pueda escribir reglas de permiso estables. La firma es la medida central, pero no significa que con firmar ya se pueda ejecutar con independencia de la directiva del cliente. Lo que hay que alinear se divide en seis.

Esta preparación también sirve para Smart App Control. Un binario firmado y con reputación acumulada tropieza menos con el bloqueo automático de un PC personal.⁴

5.1. Cuando se obtiene por primera vez un certificado de firma de código

Elegir un certificado RSA de una entidad de certificación de confianza

Si se distribuye a clientes externos, elija un certificado de firma de código basado en RSA emitido por una entidad de certificación pública (CA comercial). Un certificado autofirmado o de una CA interna no se puede validar en un PC del cliente que no confíe en esa CA, y Smart App Control tampoco lo admite.⁶

Compruebe también el algoritmo. La comprobación de firma de Smart App Control no admite firmas ECC (curva elíptica). Firmar con ECC puede hacer que, en un PC personal, se trate casi como si no estuviera firmado.⁶

También en App Control, las reglas basadas en el firmante solo admiten RSA (hasta 4096 bits). Si se intenta permitir una firma ECDSA con una regla de editor, el 3089 correspondiente registra VerificationError = 23. Elegirlo solo porque «ECC es más nuevo y más fuerte» acaba en un problema de compatibilidad con el control de ejecución.⁷

OV y EV, desde el punto de vista de las reglas de editor, sirven los dos

Los certificados de una CA pública incluyen el OV, que valida la existencia de la empresa, y el EV, de revisión más estricta. Las reglas de editor de AppLocker y de App Control se pueden crear con cualquiera de los dos.

App Control tiene una opción de regla Required:EV Signers, pero la documentación oficial dice que en este momento no está admitida. Por tanto, no hay razón para elegir EV por el control de ejecución que aquí se trata. La relación con SmartScreen se ordena aparte en «Windows SmartScreen y la firma de código».⁷

Presupuestar no solo el certificado, sino el almacenamiento de la clave privada y la operación de firma

El coste varía según la CA y el periodo de validez. En el presupuesto, además del certificado, compruebe el token, el HSM o la tarifa del servicio de firma en la nube que ofrezca la CA.

En los certificados emitidos a partir del 1 de junio de 2023, los requisitos del CA/Browser Forum exigen que, tanto en OV como en EV, la clave privada se genere y se guarde en hardware de nivel FIPS 140-2 2 o equivalente (HSM o token USB).⁸

Si se firma de forma automática en CI/CD, a veces un servicio de firma en la nube es más fácil de configurar que un token físico. Antes de comprar el certificado, lo práctico es hablar también de cómo se operará desde la compilación hasta la firma.

Firmar todos los binarios y añadir un sello de tiempo

La firma Authenticode hay que alinearla no solo en el exe, sino también en las DLL de compilación propia, el instalador (MSI o exe de instalación) y los scripts incluidos. Con metadatos de firma, el cliente puede escribir reglas que resisten las actualizaciones, del tipo «permitir este producto de este editor, sea cual sea la versión».³

El sello de tiempo se añade para que la firma siga válida después de que caduque el certificado. Un ejemplo mínimo con signtool del Windows SDK es el siguiente.

:: Firmar (hash SHA-256 y sello de tiempo RFC 3161)
signtool sign /fd sha256 /tr <URL del servidor de sello de tiempo> /td sha256 /a MyApp.exe

:: Comprobar la firma (validar con la directiva Authenticode y mostrar el detalle)
signtool verify /pa /v MyApp.exe

Use la URL del servidor de sello de tiempo que indique la CA de la que lo compró. Si usa una clave de token o HSM, compruebe también en la guía de la CA cómo indicar el CSP/KSP. Las DLL y el instalador se firman con el mismo comando, así que el flujo es firmar y verificar todo al final de la compilación.

5.2. Tratar el cambio de certificado y de atributos de archivo como un cambio de las reglas del cliente

Aunque la firma sea coherente, la versión nueva se detiene si cambia aquello con lo que comparan las reglas. Lo que hay que comprobar no es solo el sujeto o la cadena del certificado. El nombre del producto, el nombre de archivo original y la versión vienen del recurso de versión de cada archivo (información del ensamblado), no del certificado.

El Publisher de App Control es «certificado PCA (normalmente el inmediatamente inferior a la raíz) + CN del certificado hoja», y FilePublisher añade además el atributo FileName del archivo firmado (OriginalFileName por defecto) y una versión mínima.⁷

Para el cliente, estos cambios se ven como «después de actualizar, solo en ese entorno dejó de arrancar». Si cambia la grafía del nombre, la CA o los atributos de producto y archivo, ponga en las notas de la versión la información de firma antigua y nueva (sujeto, CA emisora) en paralelo, y avise con antelación. Así el departamento de sistemas del cliente puede añadir o actualizar las reglas de permiso.

5.3. Estabilizar la ubicación y el flujo de actualización automática

Coloque los ejecutables bajo Program Files u otro lugar similar, y evite un diseño que en tiempo de ejecución extraiga exe/DLL a %TEMP% o %APPDATA% y los arranque desde ahí. Un diseño que se ejecuta en un lugar en el que el usuario puede escribir encaja mal con un entorno de reglas de ruta.

En la actualización automática, firme también el propio programa de actualización, de modo que un binario firmado se sustituya por un binario firmado. El detalle de un diseño seguro está en «Diseño de seguridad de la actualización automática».

En la distribución con Intune o Configuration Manager, si el cliente ha configurado el agente de distribución como instalador administrado, se puede permitir los binarios que entran por esa vía. Distribuir con Intune no los permite de forma automática: hace falta una configuración explícita del administrador. Preparar un MSI con instalación silenciosa pone esa opción en manos del cliente.

5.4. Reunir en la guía de implantación la información para escribir las reglas

La guía de implantación que se entrega al cliente debe indicar el sujeto de la firma, la lista de binarios necesarios para ejecutarse y las rutas de instalación. Eso es el fundamento con el que sistemas de información escribe las reglas de permiso.

Para el caso de un bloqueo, haga posible pedir la comprobación indicando el nombre del registro y el id de evento del capítulo 4. Así se reducen los ida y vuelta de «no arranca» y se puede cotejar enseguida el archivo y la información de firma.

6. Puntos clave para el lado que lo implementa (sistemas de información)

La secuencia básica del lado que lo implementa es elegir la tecnología → comprobar el impacto con una auditoría → alinear las reglas de permiso y aplicarlas → seguir gestionando las excepciones. Lo importante es no empezar a bloquear de golpe en todos los equipos.

6.1. Elegir la tecnología según el uso y alinear los requisitos de la auditoría

El principio es App Control for Business. Use AppLocker a la vez cuando haga falta un control por usuario en un PC compartido, o cuando se mezclen sistemas operativos antiguos.³ En un PC de uso fijo, como un kiosco, acotar primero el uso con una restricción de shell simplifica las reglas. Véase también «El modo kiosco de Windows y el acceso asignado».

La auditoría reúne, sin detener el negocio, «lo que se habría bloqueado de estar aplicada la directiva». En AppLocker, AppIDSvc tiene que estar en ejecución; si el servicio está parado, tampoco salen eventos de auditoría. Configure el inicio automático en los equipos objetivo antes de empezar.

La idea de reunir hasta que el negocio dé un ciclo completo y entonces pasar a la aplicación es la misma que con la firma SMB o las restricciones NTLM. Incluya también los lotes mensuales y anuales, y no dé por terminada la comprobación solo con las operaciones de cada día.

6.2. AppLocker pasa de la auditoría a la aplicación en tres pasos

1. Activar el modo de auditoría. En el Editor de administración de Directiva de grupo (en local, secpol.msc) abra Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad > Directivas de control de aplicaciones > AppLocker. Haga clic con el botón derecho en AppLocker, abra Propiedades, elija «Configurar» en cada colección de reglas (archivos ejecutables, Windows Installer, scripts, aplicaciones empaquetadas) y póngala en «Solo auditoría». Cree las reglas predeterminadas en cada colección y configure también el inicio automático de AppIDSvc.

2. Reunir eventos del registro que corresponda al objetivo. exe/DLL es el 8003 de EXE and DLL; scripts y MSI, el 8006 de MSI and Script. El comando del apartado 4.1 cubre solo EXE and DLL, así que no recoge el 8006. Para ver ambos, obtenga los registros por separado como sigue.¹

    # En modo de auditoría, reunir «lo que se habría bloqueado de estar aplicada la directiva» de los dos registros
    $since = (Get-Date).AddDays(-7)
    $collections = @(
        @{ LogName = 'Microsoft-Windows-AppLocker/EXE and DLL';    Id = 8003 }
        @{ LogName = 'Microsoft-Windows-AppLocker/MSI and Script'; Id = 8006 }
    )
    foreach ($c in $collections) {
        Get-WinEvent -FilterHashtable ($c + @{ StartTime = $since }) -ErrorAction SilentlyContinue |
            Select-Object TimeCreated, LogName, Id, Message
    }
   

   En un registro sin eventos coincidentes Get-WinEvent devuelve un error, así que este ejemplo añade -ErrorAction SilentlyContinue. Si no hay salida, compruebe si el servicio está en ejecución, el registro objetivo y el periodo de obtención. Si también entran las aplicaciones empaquetadas, añada Packaged app-Deployment / Packaged app-Execution de la misma forma, y compruebe hasta los lotes mensuales y anuales.

3. Alinear las reglas de permiso y entonces pasar a la aplicación. Revise los archivos necesarios para el negocio que salieron en 8003 y 8006 e incorpórelos a las reglas de permiso. Después, en la misma pantalla de propiedades, cambie a «Aplicar reglas». Tras el cambio, vigile los bloqueos 8004 (exe/DLL) y 8007 (scripts y MSI).

6.3. En App Control, quitar la opción de auditoría para pasar a la aplicación

Distribuya la directiva con la opción de regla 3 (Enabled:Audit Mode) en el XML. Para configurarla use el Asistente para directivas de App Control o el cmdlet Set-RuleOption.⁷

Compruebe el impacto en el negocio con 3076 y 8028, alinee las reglas de permiso y entonces elimine la opción de auditoría para pasar al modo de aplicación. Microsoft también recomienda comprobar primero una directiva nueva en modo de auditoría.⁷

6.4. Vincular las excepciones sin firmar a la gestión de activos

Las aplicaciones empresariales antiguas que se siguen usando sin firmar se registran como excepción con reglas de hash y se gestionan así. Esa lista es también la lista de activos que habrá que renovar. No se quede en crear la excepción: vincúlela a la gestión de activos y revísela cada año.

7. Resumen

La respuesta al control de ejecución se ordena en tres cosas: distinguir el mecanismo, fijarlo en el registro y hacer un material distribuido cuyas reglas de permiso sean estables.

SmartScreen es, en lo básico, una advertencia, pero bajo una directiva que prohíbe superarla se convierte en un bloqueo. Trátelo aparte de AppLocker, App Control y Smart App Control. La restricción de edición de AppLocker se ha relajado, y App Control se puede usar en todas las ediciones cliente. Smart App Control actúa también en el PC personal, así que «es Pro» o «no hay sistemas de información» no lo deja fuera.⁵³⁴

Cuando no arranca, tome como entrada el 8004 de AppLocker y el 3077 y 3089 de App Control, y coteje también los registros de scripts y MSI. Si solo fallan algunas funciones, compruebe también el modo de lenguaje restringido de PowerShell.¹²

El lado que distribuye alinea una firma coherente de todos los binarios, el sello de tiempo, una información de editor y unos atributos de archivo estables, una ubicación habitual, una actualización automática firmada y la guía de implantación. Lo básico es hacer una aplicación en la que el cliente pueda escribir reglas de permiso con facilidad y mantenerlas también después de una actualización.

El lado que lo implementa deja que el negocio dé un ciclo completo con los 8003 y 8006 de AppLocker y los 3076 y 8028 de App Control, y entonces pasa a la aplicación. Alinear distribución y operación reduce los casos de «solo falla en el entorno del cliente».

Artículos relacionados

• Por qué aparece «Windows protegió su PC» en Windows
• Diseño de seguridad de la actualización automática - Por qué HTTPS no es suficiente
• Cómo elegir el método de distribución de aplicaciones de Windows - MSI/MSIX/ClickOnce/xcopy/actualizador propio
• Directiva de ejecución de PowerShell y firma de scripts — Guía práctica para dejar de “tapar con Bypass”
• Cuando su aplicación Windows de desarrollo propio es tratada como virus — cómo abordar los falsos positivos de Microsoft Defender y su impacto en el rendimiento
• Blindar equipos de uso dedicado con el modo kiosco de Windows ── Cómo elegir entre Assigned Access y Shell Launcher, y diseñar su operación
• La salida realista tras el fin de soporte de Windows 10 — la tabla de decisión entre ESU, LTSC y la renovación de equipos

Áreas de consultoría relacionadas

En KomuraSoft LLC nos ocupamos del desarrollo y la modificación de aplicaciones empresariales que funcionan en un entorno de control de ejecución (AppLocker / App Control for Business), del diseño de distribución y actualización automática con firma de código integrada, y de la investigación de casos en los que la aplicación no arranca en el entorno del cliente.

• Desarrollo de aplicaciones para Windows
• Modificación y mantenimiento de software existente para Windows
• Investigación de errores y análisis de causa raíz
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿No se puede usar AppLocker en la edición Pro?

Esa idea está desactualizada. Desde la KB 5024351, en Windows 10 versión 2004 en adelante y en todas las ediciones de Windows 11 ya no hace falta una edición concreta para aplicar las directivas de AppLocker. La antigua restricción de que «la aplicación mediante distribución por Directiva de grupo solo funciona en las ediciones Enterprise y Server» sigue vigente únicamente en versiones de Windows 10 anteriores a la 2004 y hasta Windows Server 2019 (incluso en ese caso, la distribución mediante MDM funciona en todas las ediciones). En un entorno de pymes centrado en equipos Pro, AppLocker ya es una opción.

¿Hay que comprar un certificado de firma de código EV?

Desde el punto de vista de las reglas de editor (publisher rules) de AppLocker o App Control for Business, tanto un certificado OV (validación de organización) como uno EV permiten crear reglas basadas en la información del firmante. Además, la idea de que «con EV la advertencia de SmartScreen desaparece desde el primer momento» ya es antigua: hoy un archivo firmado con EV hay que pensarlo, igual que uno firmado con OV, sobre la acumulación de reputación (este punto se trata en el artículo aparte «Windows SmartScreen y la firma de código»). Lo importante no es el tipo de certificado, sino firmar con un sujeto (subject) coherente todos los binarios —no solo el exe, sino también las DLL y el instalador—, añadir un sello de tiempo y mantener estable la información del editor incluso al renovar el certificado. Las reglas de editor se escriben confiando en esa información del firmante, así que si el estado de la firma cambia de una versión a otra, las reglas del cliente se rompen.

Parece que la aplicación propia fue bloqueada en el entorno del cliente, pero no encuentro nada en los registros. ¿Dónde hay que mirar?

La causa más frecuente es que hay que revisar dos familias de registro distintas. Los bloqueos de exe/DLL por AppLocker aparecen en el evento 8004 del registro «AppLocker - EXE and DLL» (8003 en modo de auditoría), y los scripts y MSI en el evento 8007 del registro «AppLocker - MSI and Script» (8006 en modo de auditoría). Por otro lado, los bloqueos de App Control for Business (WDAC) aparecen en el evento 3077 del registro «CodeIntegrity - Operational» (3076 en modo de auditoría), y la información de firma correspondiente se registra en el 3089. Además, si un script, un MSI o un objeto COM tropiezan con App Control, aparecen en los eventos 8029, 8036 y 8040 del registro «AppLocker - MSI and Script». Cuando no se sepa cuál de los dos mecanismos está actuando, coteje por hora tanto CodeIntegrity - Operational como los registros bajo AppLocker.

¿Qué se necesita para que Smart App Control no bloquee la aplicación propia?

En la práctica, la firma de código. Al ejecutar una aplicación, Smart App Control comprueba, mediante un servicio de seguridad en la nube, si puede predecir con fiabilidad la seguridad de la aplicación y si esta tiene una firma válida, y bloquea las aplicaciones consideradas maliciosas y las no firmadas cuya confianza no puede confirmarse. Microsoft también indica a los desarrolladores, como orientación, firmar la aplicación con un certificado válido. Hay que prestar atención al algoritmo de firma: la comprobación de firma de Smart App Control no admite firmas de curva elíptica (ECC), así que las aplicaciones firmadas con certificados basados en RSA son las que pueden autorizarse para ejecutarse. Smart App Control no es una función de administración empresarial, sino una protección para usuarios particulares de Windows 11; el modo de evaluación decide de forma automática si se activa o se desactiva, así que, desde el lado de la distribución, lo seguro es asumir que «un ejecutable sin firmar puede no funcionar en un PC personal».

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.