Archivo: Requisitos de certificación para aplicaciones de escritorio de Windows v3.1
Versión del documento: 3.1
Fecha del documento: 18 de junio de 2013
Este documento contiene los requisitos técnicos y las calificaciones de idoneidad que debe cumplir una aplicación de escritorio para participar en el programa de certificación de aplicaciones de escritorio Windows 8.1. 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 programas y requisitos técnicos para ayudar a garantizar que las aplicaciones de terceros que llevan la marca de Windows son 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 en 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, el rendimiento mejorado y la 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 para Windows 8.1.
Idoneidad de la aplicación
Para que una aplicación sea apta para Windows 8.1 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 el código y la característica completadas
- No debe comunicarse con las aplicaciones de la Tienda Windows a través de mecanismos locales, incluidos los archivos y las claves del Registro.
- No debe poner en peligro ni poner en peligro la seguridad o la funcionalidad del sistema Windows.
- Debe tener un nombre único y no debe ser marca registrada por otros usuarios
Si la aplicación de escritorio se envía a la categoría de productos anti-virus o anti-spyware (es decir, antimalware), debe cumplir con las DIRECTRICES DE LA PLATAFORMA ANTIMALWARE. El CONTRATO DE LICENCIA DE LA API ANTIMALWARE DE WINDOWS 8 debe haberse firmado y en vigor antes del envío. El socio debe ser miembro o tener investigadores que sean miembros de y de buena posición en una de las organizaciones enumeradas en el acuerdo. La funcionalidad debe estar certificada en Windows 8 por una de las organizaciones enumeradas en el contrato. La aplicación debe haber sido probada al menos una vez en los últimos 12 meses y certificada para la detección y limpieza.
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 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 debe tener un manifiesto de compatibilidad y usar los GUID adecuados para las versiones compatibles de Windows
1.3 La aplicación debe ser compatible con PPP mediante el manifiesto de ensamblado de la aplicación en lugar de llamar a SetProcessDPIAware
1.4 La aplicación no debe depender del entorno de ejecución de VB6.
1.5 La aplicación no debe cargar archivos DLL arbitrarios para interceptar las 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 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. La aplicación debe usar ACL seguras y adecuadas para proteger los directorios 2.3. La 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.
El Programa de certificación de aplicaciones de Windows comprobará que las superficies expuestas a ataques de Windows no se exponen comprobando que las ACL y los servicios se implementan de forma que no ponga 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 correctamente los apagados críticos.
- 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.
- 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.
- WM\_ENDSESSION con LPARAM = ENDSESSION\_CLOSEAPP(0x1).
Como mínimo, la aplicación debe prepararse guardando los datos del usuario y guardando la información necesaria después de un reinicio.
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
- DisplayName
- InstallLocation
- Publicador
- UninstallString
- VersionMajor o MajorVersion
- VersionMinor o MinorVersion
- 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.
- Reiniciar el equipo nunca debe ser la única opción al final de una instalación, desinstalación o actualización. Los usuarios deben tener la oportunidad de reiniciarse más adelante.
- 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:
6. Las aplicaciones deben firmar digitalmente archivos y controladores
Una firma digital Authenticode permite a los usuarios asegurarse de que el software es original. También permite detectar si se ha alterado un archivo, como si ha sido infectado por un virus. La aplicación de 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 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 renuncias se considerarán solo 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 hay 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 son iguales
- 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.
- 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.
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:
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.
- 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.
- 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 Microsoft. 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""/>
- 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.
- 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:
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
- 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
- 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.
- Por ejemplo, la aplicación no debe establecer ninguna de las siguientes opciones;
- Use los métodos correctos para instalar archivos, como fuentes o controladores.
- 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.
- 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.
- Consulte los requisitos de UAC.
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 |
| 31 de mayo de 2012 | 1,2 | Se han agregado resultados de pruebas de resumen | 1.2 |
| 29 de junio de 2012 | 3.0 | Windows 8 documento final | 3.0 |
| 18 de junio de 2013 | 3.1 | Windows 8.1 documento | 3.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 provocan 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. El punto de entrada de la aplicación orientada al usuario debe manifestarse por motivos de compatibilidad, así como declarar el GUID correcto. Los puntos de entrada de la aplicación orientadas al usuario deben manifestarse para el reconocimiento de valores altos de PPP y que se llama a las API adecuadas para admitir valores altos de PPP. |
Sistemas operativos Windows Vista, Windows 7 y Windows 8 Comprobador de aplicación Archivos DLL de AppInit Manifiesto de aplicación (ejecutable) Escritura de aplicaciones Win32 de alto ppp |
| Cumplir los procedimientos recomendados de Seguridad de Windows | El uso de procedimientos recomendados de seguridad de Windows ayudará a evitar la exposición a 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 |
| Características de Seguridad de Windows de soporte técnico | 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 el código malintencionado se ejecute. |
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 gran deseo de ver que el apagado se realiza correctamente; pueden estar en prisa para salir de la oficina y "sólo quiere" 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 Reiniciar el desarrollo del administrador |
| Instalación reversible limpia | 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 original. También permite detectar si un archivo se ha alterado, por ejemplo, si ha sido infectado por un virus. La aplicación de 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 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 hay limitaciones técnicas. En general, si las aplicaciones se escribieron para Windows Vista o versiones posteriores, no deberían 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 las 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 muchas requieren derechos excesivos de usuario 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 asumir la máquina o una acción de personas que tienen privilegios limitados, por ejemplo, un empleado que instala 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. Siguiendo las directrices de UAC se 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, al tiempo que mantienen 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 y desinstalación |
| Compatibilidad con sesiones multiusuario | 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 64 bits o que las versiones de 32 bits de la aplicación se ejecutan bien con versiones de 64 bits de Windows. |
Compatibilidad de aplicaciones: Windows Vista de 64 bits |