Archivo: Requisitos de certificación para aplicaciones de escritorio de Windows v1.1

Versión del documento: 1.1

Fecha del documento: 26 de enero de 2012

Este documento contiene los requisitos técnicos y las calificaciones de idoneidad que una aplicación de escritorio debe cumplir para participar en el programa de certificación de aplicaciones de escritorio Windows 8. Para Windows 7, este programa se conocía como programa de logotipos de software de Windows.

¡Bienvenido!

La plataforma Windows admite un amplio ecosistema de productos y asociados. Mostrar el logotipo de Windows en el producto representa una relación y un compromiso compartido con la calidad entre Microsoft y su empresa. Los clientes confían en la marca de Windows en el producto porque garantiza que cumple los estándares de compatibilidad y funciona bien en la plataforma Windows. Pasar correctamente la certificación de aplicaciones de Windows permite que la aplicación se muestre en el Centro de compatibilidad de Windows y también es un paso necesario para enumerar una referencia de aplicación de escritorio en la Tienda Windows.

El Programa de certificación de aplicaciones de Windows se compone de requisitos técnicos y de programa para ayudar a garantizar que las aplicaciones de terceros que llevan la marca de Windows sean fáciles de instalar y confiables en equipos que ejecutan Windows. Los clientes valoran la estabilidad, la compatibilidad, la confiabilidad, el rendimiento y la calidad en los sistemas que compran. Microsoft centra sus inversiones para cumplir estos requisitos para las aplicaciones de software diseñadas para ejecutarse en la plataforma Windows para equipos. Estos esfuerzos incluyen pruebas de compatibilidad para la coherencia de la experiencia, un rendimiento mejorado y una seguridad mejorada en equipos que ejecutan software de Windows. Las pruebas de compatibilidad de Microsoft se han diseñado en colaboración con asociados del sector y se han mejorado continuamente en respuesta a los desarrollos del sector y a la demanda de los consumidores.

El Kit para la certificación de aplicaciones de Windows se usa para validar el cumplimiento de estos requisitos y reemplaza el WSLK usado para la validación en el programa logotipo de software de Windows 7. El Kit para la certificación de aplicaciones de Windows es uno de los componentes incluidos en el Kit de desarrollo de software (SDK) de Windows.

Idoneidad de la aplicación

Para que una aplicación califique para Windows 8 Certificación de aplicaciones de escritorio, debe cumplir los siguientes criterios y todos los requisitos técnicos enumerados en este documento.

  • Debe ser una aplicación independiente.
  • Debe ejecutarse en un equipo de Windows 8.1 local.
  • Puede ser un componente cliente de una aplicación de Windows Server certificada.
  • Debe ser código y característica completada

1. Las aplicaciones son compatibles y resistentes

Las veces en que una aplicación se bloquea o deja de responder provocan mucha frustración del usuario. Se espera que las aplicaciones sean resistentes y estables y que eliminen estos errores ayudan a garantizar que el software sea más predecible, fácil de mantener, de alto rendimiento y de confianza.

1.1 La aplicación no debe depender de los modos de compatibilidad de Windows, el mensaje AppHelp ni ninguna otra corrección de compatibilidad.
1.2 La aplicación no debe depender del entorno de ejecución de VB6.
1.3 La aplicación no debe cargar archivos DLL arbitrarios para interceptar llamadas API de Win32 mediante HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dlls.

2. Las aplicaciones deben cumplir los procedimientos recomendados de seguridad de Windows

El uso de procedimientos recomendados de seguridad de Windows ayudará a evitar la exposición a las superficies expuestas a ataques de Windows. Las superficies de ataque son los puntos de entrada que un atacante malintencionado podría usar para aprovechar el sistema operativo aprovechando las vulnerabilidades del software de destino. Una de las peores vulnerabilidades de seguridad es la elevación de privilegios.

2.1 La aplicación debe usar ACL seguras y adecuadas para proteger los archivos ejecutables 2.2 Su aplicación debe usar ACL seguras y adecuadas para proteger los directorios 2.3 Su aplicación debe usar ACL seguras y adecuadas para proteger las claves del Registro 2.4. La aplicación debe usar ACL seguras y adecuadas para proteger los directorios que contienen objetos 2.5 La aplicación debe reducir el acceso no administrador a los servicios que son vulnerables a la manipulación 2.6 La aplicación debe evitar los servicios con rapidez. se reinicia al reiniciar más de dos veces cada 24 horas
**Nota: Solo se debe conceder acceso a las entidades que lo requieran.**

El Programa de certificación de aplicaciones de Windows comprobará que las superficies expuestas a ataques de Windows no están expuestas comprobando que las ACL y los servicios se implementan de una manera que no pone en riesgo el sistema windows.

3. Las aplicaciones admiten características de seguridad de Windows

El sistema operativo Windows tiene muchas características que admiten la seguridad y la privacidad del sistema. Las aplicaciones deben admitir estas características para mantener la integridad del sistema operativo. Las aplicaciones compiladas incorrectamente podrían provocar saturaciones de búfer que, a su vez, pueden provocar la denegación de servicio o permitir la ejecución de código malintencionado.

3.1 La aplicación no debe usar AllowPartiallyTrustedCallersAttribute (APTCA) para garantizar el acceso seguro a ensamblados con nombre seguro
3.2 La aplicación debe compilarse con la marca /SafeSEH para garantizar el control de excepciones seguras.
3.3 La aplicación debe compilarse con la marca /NXCOMPAT para evitar la ejecución de datos
3.4 La aplicación debe compilarse con la marca /DYNAMICBASE para la selección aleatoria del diseño del espacio de direcciones (ASLR)
3.5 La aplicación no debe leer y escribir las secciones de PE compartidas

4. Las aplicaciones deben cumplir los mensajes del administrador de reinicio del sistema

Cuando los usuarios inician el apagado, normalmente tienen un gran deseo de ver que el apagado se realiza correctamente; pueden estar en prisa para salir de la oficina y solo quiere que sus ordenadores se apaguen. Las aplicaciones deben respetar este deseo al no bloquear el apagado. Aunque en la mayoría de los casos, es posible que un apagado no sea crítico, las aplicaciones deben estar preparadas para la posibilidad de un apagado crítico.

4.1 La aplicación debe controlar los apagados críticos adecuadamente.
En un apagado crítico, las aplicaciones que devuelven FALSE a WM_QUERYENDSESSION se enviarán WM_ENDSESSION y se cerrarán, mientras que las que agotan el tiempo de espera en respuesta a WM_QUERYENDSESSION finalizarán.

4.2 Una aplicación de GUI debe devolver TRUE inmediatamente como preparación para un reinicio
WM\_QUERYENDSESSION con LPARAM = ENDSESSION\_CLOSEAPP(0x1). Las aplicaciones de consola pueden llamar a SetConsoleCtrlHandler para especificar la función que controlará las notificaciones de apagado. Las aplicaciones de servicio pueden llamar a RegisterServiceCtrlHandlerEx para especificar la función que recibirá notificaciones de apagado.
4.3 La aplicación debe devolver 0 en un plazo de 30 segundos y apagarla
WM\_ENDSESSION con LPARAM = ENDSESSION\_CLOSEAPP(0x1). Como mínimo, la aplicación debe prepararse guardando los datos de usuario y estableciendo la información necesaria después de un reinicio.
4.4 Las aplicaciones de consola que reciben la notificación CTRL\_C\_EVENT deben apagarse inmediatamente 4.5 Los controladores no deben vetar un evento de apagado del sistema
**Nota: Las aplicaciones que deben bloquear el apagado debido a una operación que no se puede interrumpir deben explicar el motivo al usuario.** Use ShutdownBlockReasonCreate para registrar una cadena que explique el motivo para el usuario. Una vez completada la operación, la aplicación debe llamar a ShutdownBlockReasonDestroy para indicar que el sistema se puede apagar.

5. Las aplicaciones deben admitir una instalación limpia y reversible

Una instalación limpia, reversible, permite a los usuarios administrar correctamente (implementar y quitar) aplicaciones en sus sistemas.

5.1 La aplicación debe implementar correctamente una instalación limpia y reversible
Si se produce un error en la instalación, la aplicación debería poder revertirla y restaurar la máquina a su estado anterior.

5.2 La aplicación nunca debe forzar al usuario a reiniciar el equipo inmediatamente
Reiniciar el equipo nunca debe ser la única opción al final de una instalación o actualización. Los usuarios deben tener la oportunidad de reiniciarse más adelante.
5.3 La aplicación nunca debe depender de los nombres de archivo cortos 8.3 (SFN) 5.4 La aplicación nunca debe bloquear la instalación silenciosa o desinstalación 5.5 El instalador de la aplicación debe crear las entradas del Registro correctas para permitir la detección y desinstalación correctas.
Las herramientas de inventario de Windows y las herramientas de telemetría requieren información completa sobre las aplicaciones instaladas. Si usa un instalador basado en MSI, MSI crea automáticamente las entradas del Registro siguientes. Si no usa un instalador MSI, el módulo de instalación debe crear las siguientes entradas del Registro durante la instalación:
  • DisplayName
  • InstallLocation
  • Publicador
  • UninstallString
  • VersionMajor o MajorVersion
  • VersionMinor o MinorVersion

6. Las aplicaciones deben firmar digitalmente archivos y controladores

Una firma digital Authenticode permite a los usuarios asegurarse de que el software es auténtico. También permite detectar si un archivo ha sido alterado, como si ha sido infectado por un virus. El cumplimiento de la firma de código en modo kernel es una característica de Windows conocida como integridad de código (CI), que mejora la seguridad del sistema operativo comprobando la integridad de un archivo cada vez que la imagen del archivo se carga en la memoria. CI detecta si el código malintencionado ha modificado un archivo binario del sistema. También genera un evento de registro de diagnóstico y auditoría del sistema cuando la firma de un módulo de kernel no se puede comprobar correctamente.

6.1 Todos los archivos ejecutables (.exe, .dll, .ocx, .sys, .cpl, .drv, .scr) deben estar firmados con un certificado Authenticode
6.2 Todos los controladores de modo kernel instalados por la aplicación deben tener una firma de Microsoft obtenida a través del programa de certificación de hardware de Windows. Microsoft debe firmar todos los controladores de filtro del sistema de archivos.
6.3 Excepciones y exenciones
Las exenciones solo se considerarán para los redistribuibles de terceros sin firmar, excepto los controladores. Se requiere una prueba de comunicación que solicite una versión firmada de los redistribuibles para que se conceda esta exención.

7. Las aplicaciones no bloquean la instalación ni el inicio de la aplicación en función de una comprobación de la versión del sistema operativo

Es importante que los clientes no estén bloqueados artificialmente para instalar o ejecutar su aplicación cuando no haya limitaciones técnicas. En general, si las aplicaciones se escribieron para Windows Vista o versiones posteriores de Windows, no deben tener que comprobar la versión del sistema operativo.

7.1 La aplicación no debe realizar comprobaciones de versión para comprobar si hay igualdad
Si necesita una característica específica, compruebe si la propia característica está disponible. Si necesita Windows XP, busque Windows XP o posterior (>= 5.1). De este modo, el código de detección seguirá funcionando en versiones futuras de Windows. Los instaladores de controladores y los módulos de desinstalación nunca deben comprobar la versión del sistema operativo.

7.2 Las excepciones y exenciones se considerarán para las aplicaciones que cumplan los criterios siguientes:
  • Las aplicaciones que se entregan como un paquete que también se ejecutan en Windows XP, Windows Vista y Windows 7, y deben comprobar la versión del sistema operativo para determinar qué componentes instalar en un sistema operativo determinado.
  • Las aplicaciones que comprueban solo la versión mínima del sistema operativo (solo durante la instalación, no en tiempo de ejecución) mediante solo las llamadas API aprobadas y que enumeran correctamente el requisito de versión mínima en el manifiesto de la aplicación.
  • Aplicaciones de seguridad (antivirus, firewall, etc.), utilidades del sistema (por ejemplo, desfragmentar, copias de seguridad y herramientas de diagnóstico) que comprueban la versión del sistema operativo mediante solo las llamadas API aprobadas.

8. Las aplicaciones no cargan servicios ni controladores en modo seguro

El modo seguro permite a los usuarios diagnosticar y solucionar problemas de Windows. Los controladores y servicios no deben establecerse para cargarse en modo seguro a menos que sean necesarios para las operaciones básicas del sistema de , como controladores de dispositivos de almacenamiento o con fines de diagnóstico y recuperación, como escáneres antivirus, . De forma predeterminada, cuando Windows está en modo seguro, inicia solo los controladores y servicios que se han preinstalado con Windows.

  • 8.1 Excepciones y exenciones
    Los conductores y servicios que deben iniciarse en modo seguro requieren una exención. La solicitud de exención debe incluir cada controlador o servicio aplicable que escriba en las claves del Registro SafeBoot y describir los motivos técnicos por los que la aplicación o el servicio deben ejecutarse en modo seguro. El instalador de la aplicación debe registrar todos estos controladores y servicios mediante estas claves del Registro:
    - HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal - HKLM/System/CurrentControlSet/Control/SafeBoot/Network

Nota: Debe probar estos controladores y servicios para asegurarse de que funcionan en modo seguro sin errores.

9. Las aplicaciones deben seguir las directrices de control de cuentas de usuario

Algunas aplicaciones de Windows se ejecutan en el contexto de seguridad de una cuenta de administrador y las aplicaciones suelen solicitar derechos de usuario excesivos y privilegios de Windows. Controlar el acceso a los recursos permite a los usuarios controlar sus sistemas y protegerlos frente a cambios no deseados. Un cambio no deseado puede ser malintencionado, como un rootkit que toma el control del equipo, o ser el resultado de una acción realizada por personas que tienen privilegios limitados. La regla más importante para controlar el acceso a los recursos es proporcionar la menor cantidad de acceso al contexto de usuario estándar necesario para que un usuario realice sus tareas necesarias. Siguiendo las directrices de control de cuentas de usuario (UAC) proporciona a la aplicación los permisos necesarios cuando la aplicación los necesita, sin dejar el sistema expuesto constantemente a riesgos de seguridad. La mayoría de las aplicaciones no requieren privilegios de administrador en tiempo de ejecución y deben funcionar correctamente como usuario estándar.

9.1 La aplicación debe tener un manifiesto que defina los niveles de ejecución e indique al sistema operativo qué privilegios requiere la aplicación para poder ejecutarse.
El marcado del manifiesto de la aplicación solo se aplica a exes, no a archivos DLL. Esto se debe a que UAC no inspecciona los archivos DLL durante la creación del proceso. También merece la pena tener en cuenta que las reglas de UAC no se aplican a los servicios de Windows. El manifiesto puede ser incrustado o externo.
Para crear un manifiesto, cree un archivo con el nombre <app_name>.exe.manifest y almacénelo en el mismo directorio que exe. Tenga en cuenta que cualquier manifiesto externo se omite si la aplicación tiene un manifiesto interno. Por ejemplo:
<requestedExecutionLevel level=""asInvoker | highestAvailable | requireAdministrator"" uiAccess=""true|false""/>

9.2 El proceso principal de la aplicación debe ejecutarse como usuario estándar (asInvoker).
Las características administrativas deben moverse a un proceso independiente que se ejecute con privilegios administrativos. Las aplicaciones orientadas al usuario, como las accesibles a través del grupo de programas del menú Inicio, y que requieren elevación deben estar firmadas por Authenticode.
9.3 Excepciones y exenciones
Se requiere una exención para las aplicaciones que ejecutan su proceso principal con privilegios elevados (requireAdministrator o highestAvailable). El proceso principal se identifica como el punto de entrada del usuario a la aplicación. Las exenciones se considerarán en los siguientes escenarios:
  • Herramientas administrativas o del sistema con el nivel de ejecución establecido en highestAvailable y/o requireAdministrator
  • Solo la aplicación de marco de automatización de la interfaz de usuario o accesibilidad establece la marca uiAccess en true para omitir el aislamiento de privilegios de la interfaz de usuario (UIPI). Para iniciar correctamente el uso de la aplicación, esta marca debe estar firmada con Authenticode y debe residir en una ubicación protegida en el sistema de archivos, es decir, Archivos de programa.

10. Las aplicaciones deben instalarse en las carpetas correctas de forma predeterminada

Los usuarios deben tener una experiencia coherente y segura con la ubicación de instalación predeterminada de los archivos, a la vez que mantienen la opción de instalar una aplicación en la ubicación que prefieran. También es necesario almacenar los datos de la aplicación en la ubicación correcta para permitir que varias personas usen el mismo equipo sin dañar ni sobrescribir los datos y la configuración de los demás. Windows proporciona ubicaciones específicas en el sistema de archivos para almacenar programas y componentes de software, datos de aplicación compartidos y datos de aplicación específicos de un usuario.

10.1 La aplicación debe estar instalada en la carpeta Archivos de programa de forma predeterminada
Para aplicaciones nativas de 32 y 64 bits en %ProgramFiles%, y %ProgramFiles(x86)% para aplicaciones de 32 bits que se ejecutan en x64. Los datos de usuario o los datos de la aplicación nunca se deben almacenar en esta ubicación debido a los permisos de seguridad configurados para esta carpeta.

10.2 La aplicación debe evitar iniciarse automáticamente al iniciarse
Por ejemplo, la aplicación no debe establecer ninguna de las siguientes opciones;
  • El Registro ejecuta claves HKLM y, o HKCU en Software\Microsoft\Windows\CurrentVersion
  • El Registro ejecuta claves HKLM y HKCU en Software\Wow6432Node\Microsoft\windows\CurrentVersion
  • Menú Inicio AllPrograms > STARTUP
10.3 Los datos de la aplicación, que deben compartirse entre los usuarios del equipo, deben almacenarse en ProgramData 10.4 Los datos de la aplicación que son exclusivos de un usuario específico y que no se van a compartir con otros usuarios del equipo deben almacenarse en Users\\<username>\\AppData 10.5 La aplicación nunca debe escribir directamente en el directorio "Windows" o subdirectorios.
Use los métodos correctos para instalar archivos, como fuentes o controladores.
10.6 La aplicación debe escribir datos de usuario en la primera ejecución y no durante la instalación en instalaciones por máquina
Cuando se instala la aplicación, no hay ninguna ubicación de usuario correcta en la que almacenar los datos. Los intentos de una aplicación para modificar los comportamientos de asociación predeterminados en un nivel de máquina después de la instalación no se realizarán correctamente. En su lugar, los valores predeterminados deben reclamarse en un nivel por usuario, lo que impide que varios usuarios sobrescriban los valores predeterminados de los demás.
10.7 Excepciones y exenciones
Se requiere una exención para las aplicaciones que escriben en la caché global de ensamblados (GAC) .NET deben mantener las dependencias de ensamblado privadas y almacenarlas en el directorio de la aplicación a menos que se requiera explícitamente compartir un ensamblado.

11. Las aplicaciones deben admitir sesiones de varios usuarios

Los usuarios de Windows deben poder ejecutar sesiones simultáneas sin conflictos o interrupciones.

11.1 La aplicación debe asegurarse de que, al ejecutarse en varias sesiones de forma local o remota, la funcionalidad normal de la aplicación no se ve afectada negativamente.
11.2 Los archivos de datos y la configuración de la aplicación no deben conservarse entre los usuarios
11.3 Las preferencias y privacidad de un usuario deben estar aisladas en la sesión del usuario.
11.4 Las instancias de la aplicación deben estar aisladas entre sí
Esto significa que los datos de usuario de una instancia no son visibles para otra instancia de la aplicación. El sonido de una sesión de usuario inactiva no debe escucharse en una sesión de usuario activa. En los casos en los que varias instancias de aplicación usan recursos compartidos, la aplicación debe asegurarse de que no haya un conflicto.

11.5 Las aplicaciones instaladas para varios usuarios deben almacenar datos en las carpetas y ubicaciones del Registro correctas.
Consulte los requisitos de UAC.
11.6 Las aplicaciones de usuario deben poder ejecutarse en varias sesiones de usuario (cambio rápido de usuario) para el acceso local y remoto 11.7 La aplicación debe comprobar otras sesiones de Terminal Service (TS) para las instancias existentes de la aplicación.
**Nota:** Si una aplicación no admite varias sesiones de usuario o acceso remoto, debe indicarlo claramente cuando se inicia desde este tipo de sesión.

12. Las aplicaciones deben admitir versiones x64 de Windows

A medida que el hardware de 64 bits es más común, los usuarios esperan que los desarrolladores de aplicaciones aprovechen las ventajas de la arquitectura de 64 bits mediante la migración de sus aplicaciones a 64 bits o que las versiones de 32 bits de la aplicación se ejecutan bien con versiones de 64 bits de Windows.

12.1 La aplicación debe admitir de forma nativa 64 bits o, como mínimo, las aplicaciones basadas en Windows de 32 bits deben ejecutarse sin problemas en sistemas de 64 bits para mantener la compatibilidad con versiones de 64 bits de Windows.
12.2 La aplicación y sus instaladores no deben contener ningún código de 16 bits ni confiar en ningún componente de 16 bits.
12.3 La configuración de la aplicación debe detectar e instalar los controladores y componentes adecuados para la arquitectura de 64 bits
12.4 Cualquier complemento de shell debe ejecutarse en versiones de 64 bits de Windows
12.5 La aplicación que se ejecuta en el emulador woW64 no debe intentar subvertir ni omitir los mecanismos de virtualización Wow64.
Si hay escenarios específicos en los que las aplicaciones necesitan detectar si se ejecutan en el emulador woW64, deben hacerlo llamando a IsWow64Process.

Conclusión

A medida que evolucionan estos requisitos, observaremos los cambios en el historial de revisiones siguiente. Los requisitos estables son fundamentales para realizar su mejor trabajo, por lo que nos dirigiremos a garantizar que los cambios que realicemos sean sostenibles y continúen protegiendo y mejorando sus aplicaciones.

Gracias de nuevo por unirse a nuestro compromiso con la entrega de excelentes experiencias de los clientes.

Historial de revisiones

Date Versión Descripción de la revisión Vínculo a documento
20 de dic, 2011 1.0 Borrador inicial del documento para la versión preliminar.
26 de enero de 2012 1.1 Actualice a la sección 2. 1.1

Más información sobre la certificación de aplicaciones de escritorio

Requisito Descripción Más detalles
Compatibilidad y resistencia & Los bloqueos se bloquean son una interrupción importante para los usuarios y causan frustración. Se espera que las aplicaciones sean resistentes y estables, lo que elimina estos errores ayuda a garantizar que el software sea más predecible, fácil de mantener, de alto rendimiento y de confianza. Sistemas operativos Windows Vista, Windows 7 y Windows 8
Comprobador de aplicación
DLL de AppInit
Cumplir los procedimientos recomendados de Seguridad de Windows El uso de procedimientos recomendados de seguridad de Windows ayudará a evitar la exposición a las superficies expuestas a ataques de Windows. Las superficies de ataque son los puntos de entrada que un atacante malintencionado podría usar para aprovechar el sistema operativo aprovechando las vulnerabilidades del software de destino. Una de las peores vulnerabilidades de seguridad es la elevación de privilegios. Analizador de superficie expuesta a ataques
Listas de control de acceso
Compatibilidad con características de Seguridad de Windows El sistema operativo Windows ha implementado muchas medidas para admitir la seguridad y la privacidad del sistema. Las aplicaciones deben admitir estas medidas para mantener la integridad del sistema operativo. Las aplicaciones compiladas incorrectamente podrían provocar saturaciones de búfer que, a su vez, podrían provocar la denegación de servicio o hacer que se ejecute código malintencionado. Referencia de la herramienta BinScope
Cumplir los mensajes del Administrador de reinicio del sistema Cuando los usuarios inician el apagado, en la gran mayoría de los casos, tienen un fuerte deseo de ver que el apagado se realiza correctamente; pueden estar con prisa para salir de la oficina y "sólo desear" sus ordenadores para apagar. Las aplicaciones deben respetar este deseo al no bloquear el apagado. Aunque en la mayoría de los casos, es posible que un apagado no sea crítico, las aplicaciones deben estar preparadas para la posibilidad de un apagado crítico. Cambios de apagado de aplicaciones en Windows Vista
Reinicio del desarrollo del administrador
Limpieza de la instalación reversible Una instalación limpia, reversible, permite a los usuarios administrar correctamente (implementar y quitar) aplicaciones en sus sistemas. Cómo: Instalación de requisitos previos con una aplicación ClickOnce
Instalación de aplicaciones en sistemas de 64 bits
Firmar digitalmente archivos y controladores Una firma digital Authenticode permite a los usuarios asegurarse de que el software es auténtico. También permite detectar si un archivo se ha alterado, por ejemplo, si ha sido infectado por un virus. El cumplimiento de la firma de código en modo kernel es una característica de Windows conocida como integridad de código (CI), que mejora la seguridad del sistema operativo comprobando la integridad de un archivo cada vez que la imagen del archivo se carga en la memoria. CI detecta si el código malintencionado ha modificado un archivo binario del sistema. También genera un evento de registro de diagnóstico y auditoría del sistema cuando la firma de un módulo de kernel no se puede comprobar correctamente. Firmas digitales para módulos kernel en Windows
No bloquear la instalación ni el inicio de la aplicación en función de la comprobación de la versión del sistema operativo Es importante que los clientes no estén bloqueados artificialmente para instalar o ejecutar su aplicación cuando no haya limitaciones técnicas. En general, si las aplicaciones se escribieron para Windows Vista o versiones posteriores, no deben tener ninguna razón para comprobar la versión del sistema operativo. Control de versiones del sistema operativo
No cargar servicios y controladores en modo seguro El modo seguro permite a los usuarios diagnosticar y solucionar problemas de Windows. A menos que sea necesario para las operaciones básicas del sistema (por ejemplo, controladores de dispositivos de almacenamiento) o con fines de diagnóstico y recuperación (por ejemplo, escáneres antivirus), los controladores y servicios no deben establecerse para cargarse en modo seguro. De forma predeterminada, el modo seguro no inicia la mayoría de los controladores y servicios que no vienen preinstalados con Windows. Deben permanecer deshabilitados a menos que el sistema los requiera para operaciones básicas o con fines de diagnóstico y recuperación. Determinar si el sistema operativo se está ejecutando en modo seguro
Seguir las directrices de control de cuentas de usuario (UAC) Algunas aplicaciones de Windows se ejecutan en el contexto de seguridad de una cuenta de administrador y muchos requieren derechos de usuario excesivos y privilegios de Windows. Controlar el acceso a los recursos permite a los usuarios controlar sus sistemas frente a cambios no deseados (un cambio no deseado puede ser malintencionado, como un rootkit sigilosamente tomando el control de la máquina o una acción de personas que tienen privilegios limitados, por ejemplo, una instalación de software prohibido en un equipo de trabajo). La regla más importante para controlar el acceso a los recursos es proporcionar la menor cantidad de acceso al contexto de usuario estándar necesario para que un usuario realice sus tareas necesarias. Las siguientes directrices de UAC proporcionan a la aplicación los permisos necesarios cuando sea necesario, sin dejar el sistema expuesto constantemente a riesgos de seguridad. Control de cuentas de usuario
UAC: Directrices de actualización de aplicaciones
Instalar en las carpetas correctas de forma predeterminada Los usuarios deben tener una experiencia coherente y segura con la ubicación de instalación predeterminada de los archivos, manteniendo la opción de instalar una aplicación en la ubicación que elijan. También es necesario almacenar los datos de la aplicación en la ubicación correcta para permitir que varias personas usen el mismo equipo sin dañar ni sobrescribir los datos y la configuración de los demás. Resumen de los requisitos de instalación o desinstalación
Compatibilidad con sesiones de varios usuarios Los usuarios de Windows deben poder ejecutar sesiones simultáneas sin conflictos o interrupciones. Directrices de programación de Servicios de Escritorio remoto
Compatibilidad con versiones x64 de Windows A medida que el hardware de 64 bits es más frecuente, los usuarios esperan que los desarrolladores de aplicaciones aprovechen las ventajas de la arquitectura de 64 bits mediante la migración de sus aplicaciones a versiones de 64 bits o que las versiones de 32 bits de la aplicación se ejecuten bien en versiones de 64 bits de Windows. Compatibilidad de aplicaciones: Windows Vista 64 bits

Consulte también