Información técnica de Directivas de restricción de software
Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 y Windows Server 2012.
En este tema se describen las directivas de restricción de software, cuándo y cómo usar la característica, qué cambios se han implementado en versiones anteriores y, además, se proporcionan vínculos a recursos adicionales para ayudarle a crear e implementar directivas de restricción de software a partir de Windows Server 2008 y Windows Vista.
Introducción
Las directivas de restricción de software proporcionan a los administradores un mecanismo controlado por directivas de grupo para identificar el software y controlar su capacidad de ejecutarse en el equipo local. Estas directivas se pueden usar para proteger equipos que ejecutan sistemas operativos Microsoft Windows (a partir de Windows Server 2003 y Windows XP Professional) contra conflictos conocidos y para proteger los equipos contra amenazas de seguridad como virus malintencionados y programas de caballo de Troya. También puede usar las directivas de restricción de software para crear una configuración altamente restringida para los equipos, en los que solamente pueden ejecutarse aquellas aplicaciones específicamente identificadas. Las directivas de restricción de software están integradas en Microsoft Active Directory y la directiva de grupo. También puede crear directivas de restricción de software en equipos independientes.
Las directivas de restricción de software son directivas de confianza, las cuáles son normativas establecidas por un administrador para restringir los scripts y otros códigos que no son de confianza plena. La extensión Directivas de restricción de software para el Editor de directivas de grupo local proporciona una única interfaz de usuario a través de la cual la configuración para restringir el uso de aplicaciones se puede administrar en el equipo local o en todo un dominio.
Procedimientos
Escenarios de uso de directivas de restricción de software
Los usuarios empresariales colaboran por correo electrónico, mensajería instantánea y aplicaciones punto a punto. A medida que aumentan estas colaboraciones, especialmente con el uso de Internet en la informática empresarial, también lo hacen las amenazas de código malintencionado, como gusanos, virus y amenazas malintencionadas de usuarios o atacantes.
Los usuarios pueden recibir código hostil de muchas formas, desde archivos ejecutables nativos de Windows (archivos .exe), hasta macros en documentos (como archivos .doc) y scripts (como archivos .vbs). Los atacantes o usuarios malintencionados suelen usar métodos de ingeniería social para que los usuarios ejecuten código que contenga virus y gusanos. (La ingeniería social es un término para engañar a las personas con la intención de que revelen su contraseña o algún tipo de información de seguridad). Si se activa este código, puede generar ataques por denegación de servicio en la red, enviar datos confidenciales o privados a Internet, poner en riesgo la seguridad del equipo o dañar el contenido de la unidad de disco duro.
Las organizaciones de TI y los usuarios deben ser capaces de determinar qué software es seguro ejecutar y cuál no. Con tanta cantidad y tantas formas de código hostil, esto se convierte en una tarea difícil.
Para ayudar a proteger sus equipos de red frente a código hostil y software desconocido o no compatible, las organizaciones pueden implementar directivas de restricción de software como parte de su estrategia de seguridad general.
Los administradores pueden usar las directivas de restricción de software para realizar las siguientes tareas:
Definir el código de confianza
Diseñar una directiva de grupo flexible para regular scripts, archivos ejecutables y controles ActiveX
El sistema operativo y las aplicaciones (como las aplicaciones de scripting) que cumplen con las directivas de restricción de software aplican las directivas de restricción de software.
Concretamente, los administradores pueden usar las directivas de restricción de software con los siguientes propósitos:
Especificar qué software (archivos ejecutables) pueden ejecutarse en los equipos cliente
Evitar que los usuarios ejecuten programas específicos en equipos compartidos.
Especificar qué personas pueden agregar editores de confianza en los equipos cliente
Especificar el alcance de las directivas de restricción de software (especificar si las directivas afectarán a todos los usuarios o a un subconjunto de usuarios en los equipos cliente)
Evitar que los archivos ejecutables se ejecuten en el equipo local, la unidad organizativa (OU), el sitio o el dominio. Esto resultaría apropiado cuando no está usando directivas de restricción de software para tratar problemas potenciales con usuarios malintencionados.
Diferencias y cambios de la funcionalidad
No hay ningún cambio en la funcionalidad en SRP para Windows Server 2012 y Windows 8.
Versiones compatibles
Las directivas de restricción de software solo se pueden configurar y aplicar en equipos que ejecutan al menos Windows Server 2003, incluido Windows Server 2012, y al menos Windows XP, incluido Windows 8.
Nota
Algunas ediciones del sistema operativo cliente Windows a partir de Windows Vista no tienen directivas de restricciones de software. Es posible que los equipos no administrados en un dominio por la directiva de grupo no reciban directivas distribuidas.
Comparación de las funciones de control de aplicaciones en Directivas de restricción de software y AppLocker
En la tabla siguiente se comparan las características y funciones de la característica Directivas de restricción de software (SRP) y AppLocker.
| Función de control de aplicaciones | SRP | AppLocker |
|---|---|---|
| Ámbito | Las directivas de SRP se pueden aplicar a todos los sistemas operativos Windows a partir de Windows XP y Windows Server 2003. | Las directivas de AppLocker solo se aplican a Windows Server 2008 R2, Windows Server 2012 , Windows 7 y Windows 8. |
| Creación de directivas | Las directivas de SRP se mantienen a través de la directiva de grupo y solo el administrador del GPO puede actualizar la directiva de SRP. El administrador del equipo local puede modificar las directivas de SRP definidas en el GPO local. | Las directivas de AppLocker se mantienen a través de la directiva de grupo y solo el administrador del GPO puede actualizar la directiva. El administrador del equipo local puede modificar las directivas de AppLocker definidas en el GPO local. AppLocker permite la personalización de mensajes de error con el fin de dirigir a los usuarios a una página web para obtener ayuda. |
| Mantenimiento de directivas | Las directivas de SRP deben actualizarse mediante el complemento de directiva de seguridad local (si se crean las directivas localmente) o la consola de administración de directiva de grupo (GPMC). | Las directivas de AppLocker pueden actualizarse mediante el complemento de directiva de seguridad local (si se crean las directivas localmente), los GPMC o los cmdlets de Windows PowerShell AppLocker. |
| Aplicación de la directiva | Las directivas de SRP se distribuyen a través de la directiva de grupo. | Las directivas de AppLocker se distribuyen a través de la directiva de grupo. |
| Modo de cumplimiento | SRP funciona en el "modo de lista de denegación", donde los administradores pueden crear reglas para los archivos que no desean permitir en la empresa, mientras que el resto del archivo se puede ejecutar de manera predeterminada. SRP también se puede configurar en el "modo de lista de permitidos", de modo que todos los archivos se bloquean de forma predeterminada y los administradores necesitan crear reglas de permiso para los archivos que quieren permitir. |
AppLocker funciona de forma predeterminada en el "modo de lista de permitidos", donde solo esos archivos tienen permiso para ejecutarse cuando haya una regla de permiso que coincida. |
| Tipos de archivo que se pueden controlar | SRP puede controlar los siguientes tipos de archivo: - Ejecutables SRP no puede controlar cada tipo de archivo por separado. Todas las reglas de SRP están en una colección de regla única. |
AppLocker puede controlar los siguientes tipos de archivo: - Ejecutables AppLocker mantiene una colección de reglas independientes para cada uno de los cinco tipos de archivo. |
| Tipos de archivo designados | SRP admite una lista extensible de tipos de archivo que se consideran ejecutables. Los administradores pueden agregar extensiones a los archivos que deben considerarse ejecutables. | AppLocker no admite esto. AppLocker admite actualmente las siguientes extensiones de archivo: - Ejecutables (.exe, .com) |
| Tipos de regla | SRP admite cuatro tipos de reglas: - Hash |
AppLocker admite tres tipos de reglas: - Hash |
| Editar el valor de hash | SRP permite a los administradores proporcionar valores hash personalizados. | AppLocker calcula el valor de hash por su cuenta. De manera interna, usa el hash SHA1 Authenticode para archivos ejecutables portables (exe y dll) y los Windows Installer, y un hash de archivo plano SHA1 para el resto. |
| Compatibilidad con diferentes niveles de seguridad | Con SRP, los administradores pueden especificar los permisos con los que se puede ejecutar una aplicación. Por lo tanto, un administrador puede configurar una regla de manera que siempre se ejecute el bloc de notas con permisos restringidos y nunca con privilegios administrativos. SRP en Windows Vista y varios niveles de seguridad anteriores compatibles. En Windows 7, esa lista se restringió a tan solo dos niveles: No permitido y Sin restricciones (Usuario básico se traduce en No permitido). |
AppLocker no admite niveles de seguridad. |
| Administrar aplicaciones empaquetadas e instaladores de aplicaciones empaquetadas | No se puede | .appx es un tipo de archivo válido que puede administrar AppLocker. |
| Selección del destino de una regla para un usuario o un grupo de usuarios | Las reglas de SRP se aplican a todos los usuarios en un equipo determinado. | Las reglas de AppLocker pueden destinarse a un usuario específico o un grupo de usuarios. |
| Compatibilidad con las excepciones de regla | SRP no admite excepciones de reglas. | Las reglas de AppLocker pueden tener las excepciones que permiten a los administradores crear reglas como "Permitir todo desde Windows excepto regedit.exe". |
| Compatibilidad con el modo auditoría | SRP no admite el modo auditoría. La única manera de probar las directivas de SRP es configurar un entorno de prueba y ejecutar algunos experimentos. | AppLocker admite el modo de auditoría, que permite a los administradores probar el efecto de la directiva en el entorno de producción real sin afectar a la experiencia del usuario. Una vez que estés satisfecho con los resultados, puedes iniciar la aplicación de la directiva. |
| Compatibilidad para exportar e importar directivas | SRP no admite la importación o la exportación de directivas. | AppLocker admite la importación y la exportación de directivas. Esto te permite crear la directiva de AppLocker en un equipo de muestra, probarla, exportar esa directiva y volver a importarla al GPO deseado. |
| Aplicación de reglas | De forma interna, el cumplimiento de las reglas de SRP se realiza en el modo de usuario, que es menos seguro. | De forma interna, se aplican las reglas de AppLocker para archivos exe y dll en modo kernel, que es más seguro que aplicarlas en el modo de usuario. |
Requisitos del sistema
Las directivas de restricción de software solo se pueden configurar y aplicar en equipos que ejecutan al menos Windows Server 2003 y al menos Windows XP. Se requiere una directiva de grupo para distribuir los objetos de directiva de grupo que contienen directivas de restricción de software.
Arquitectura y componentes de las directivas de restricción de software
Las directivas de restricción de software proporcionan un mecanismo para que el sistema operativo y las aplicaciones cumplan las directivas de restricción de software para restringir la ejecución en tiempo de ejecución de los programas de software.
En un nivel superior, las directivas de restricción de software constan de los siguientes componentes:
API de directivas de restricción de software Las interfaces de programación de aplicaciones (API) se usan para crear y configurar las reglas que constituyen la directiva de restricción de software. También hay API de directivas de restricción de software para consultar, procesar y aplicar directivas de restricción de software.
Una herramienta de administración de directivas de restricción de software. Esto consta de la extensión Directivas de restricción de software del complemento Editor de objetos de directiva de grupo local, que los administradores usan para crear y editar las directivas de restricción de software.
Un conjunto de API y aplicaciones de sistema operativo que llaman a las API de directivas de restricción de software para proporcionar la aplicación de las directivas de restricción de software en tiempo de ejecución.
Active Directory y directiva de grupo. Las directivas de restricción de software dependen de la infraestructura de directivas de grupo para propagar las directivas de restricción de software de Active Directory a los clientes adecuados y para determinar el ámbito y filtrar la aplicación de estas directivas a los equipos de destino adecuados.
API de confianza de Authenticode y WinVerify que se usan para procesar archivos ejecutables firmados.
Visor de eventos. Las funciones usadas por las directivas de restricción de software registran eventos en los registros del Visor de eventos.
Conjunto resultante de directivas (RSoP), que puede ayudar en el diagnóstico de la directiva efectiva que se aplicará a un cliente.
Para obtener más información sobre la arquitectura de SRP, cómo SRP administra reglas, procesos e interacciones, vea Funcionamiento de las directivas de restricción de software en la biblioteca técnica de Windows Server 2003.
Procedimientos recomendados
No modifique la directiva de dominio predeterminada.
- Si no edita la directiva de dominio predeterminada, siempre tiene la opción de volver a aplicar la directiva de dominio predeterminada si algo va mal con la directiva de dominio personalizada.
Cree un objeto de directiva de grupo independiente para las directivas de restricción de software.
- Si crea un objeto de directiva de grupo independiente (GPO) para las directivas de restricción de software, puede deshabilitar las directivas de restricción de software en una emergencia sin deshabilitar el resto de la directiva de dominio.
Si experimenta problemas con la configuración de directiva aplicada, reinicie Windows en modo seguro.
- Las directivas de restricción de software no se aplican cuando Windows se inicia en modo seguro. Si bloquea accidentalmente una estación de trabajo con directivas de restricción de software, reinicie el equipo en modo seguro, inicie sesión como administrador local, modifique la directiva, ejecute gpupdate, reinicie el equipo y, a continuación, inicie sesión de la forma habitual.
Tenga cuidado al definir una configuración predeterminada de No permitido.
Cuando se define una configuración predeterminada de No permitido, no se admite todo el software excepto el que se ha permitido explícitamente. Cualquier archivo que quiera abrir tiene que tener una regla de directivas de restricción de software que le permita abrirlo.
Para impedir el bloqueo de los administradores fuera del sistema, cuando el nivel de seguridad predeterminado se establece en No permitido, se crean automáticamente cuatro reglas de ruta de acceso del Registro. Puede eliminar o modificar estas reglas de ruta de acceso del Registro; sin embargo, esto no se recomienda.
Para obtener la mejor seguridad, use listas de control de acceso junto con las directivas de restricción de software.
- Los usuarios pueden intentar eludir las directivas de restricción de software cambiando el nombre o moviendo archivos no permitidos o sobrescribiendo archivos sin restricciones. Como resultado, se recomienda usar listas de control de acceso (ACL) para denegar a los usuarios el acceso necesario para realizar estas tareas.
Pruebe exhaustivamente la nueva configuración de directiva en entornos de prueba antes de aplicar la configuración de directiva al dominio.
La nueva configuración de directiva puede actuar de forma diferente a la esperada originalmente. Las pruebas reducen la posibilidad de detectar un problema al implementar la configuración de directiva en toda la red.
Puede configurar un dominio de prueba, independiente del dominio de la organización, en el que probar la nueva configuración de directiva. También puede probar la configuración de directiva mediante la creación de un GPO de prueba y la vinculación a una unidad organizativa de prueba. Cuando haya probado exhaustivamente la configuración de directiva con usuarios de prueba, puede vincular el GPO de prueba al dominio.
No defina programas ni archivos como No permitidos sin pruebas para ver cuál puede ser el efecto. Las restricciones en determinados archivos pueden afectar gravemente al funcionamiento de su equipo o red.
La información que se escribe incorrectamente o que escribe errores puede provocar una configuración de directiva que no funciona según lo previsto. Probar la nueva configuración de directiva antes de aplicarla puede impedir un comportamiento inesperado.
Filtre la configuración de la directiva de usuario en función de la pertenencia a grupos de seguridad.
Puede especificar usuarios o grupos para los que no desea que se aplique la configuración de una directiva; para ello, desactive las casillas Aplicar directiva de grupo y Leer, que se encuentran en la pestaña Seguridad del cuadro de diálogo de propiedades del GPO.
Cuando se deniega el permiso de lectura, el equipo no descarga la configuración de la directiva. Como resultado, se consume menos ancho de banda descargando la configuración de directiva innecesaria, lo que permite que la red funcione más rápidamente. Para denegar el permiso de lectura, active la casilla Denegar para el permiso Lectura, que se encuentra en la pestaña Seguridad del cuadro de diálogo de propiedades del GPO.
No vincule a un GPO en otro dominio o sitio.
- La vinculación a un GPO en otro dominio o sitio puede provocar un rendimiento bajo.
Recursos adicionales
| Tipo de contenido | Referencias |
|---|---|
| Planeamiento | Referencia técnica sobre las directivas de restricción de software |
| Operaciones | Administración de las directivas de restricción de software |
| Solución de problemas | Solución de problemas de las directivas de restricción de software (2003) |
| Seguridad | Amenazas y contramedidas para las directivas de restricción de software (2008) Amenazas y contramedidas para las directivas de restricción de software (2008 R2) |
| Herramientas y configuración | Herramientas y configuraciones de las directivas de restricción de software (2003) |
| Recursos de la comunidad | Bloqueo de la aplicación con directivas de restricción de software |