Archive : Exigences de certification pour les applications de bureau Windows v3.1
Version du document : 3.1
Date du document : 18 juin 2013
Ce document contient les exigences techniques et les qualifications d’éligibilité qu’une application de bureau doit respecter pour participer au programme de certification des applications de bureau Windows 8.1. Pour Windows 7, ce programme était connu sous le nom de Programme de logo logiciel Windows.
Bienvenue !
La plateforme Windows prend en charge un large écosystème de produits et de partenaires. L’affichage du logo Windows sur votre produit représente une relation et un engagement partagé en matière de qualité entre Microsoft et votre entreprise. Les clients font confiance à la marque Windows sur votre produit, car elle garantit qu’il répond aux normes de compatibilité et fonctionne correctement sur la plateforme Windows. La réussite de la certification d’application Windows permet à votre application d’être présentée dans le Centre de compatibilité Windows. Il s’agit également d’une étape nécessaire pour répertorier une référence d’application de bureau dans le Windows Store.
Le programme de certification des applications Windows est constitué d’exigences techniques et de programmes pour garantir que les applications tierces portant la marque Windows sont à la fois faciles à installer et fiables sur les PC exécutant Windows. Les clients apprécient la stabilité, la compatibilité, la fiabilité, les performances et la qualité des systèmes qu’ils achètent. Microsoft concentre ses investissements pour répondre à ces exigences pour les applications logicielles conçues pour s’exécuter sur la plateforme Windows pour PC. Ces efforts incluent des tests de compatibilité pour la cohérence de l’expérience, l’amélioration des performances et une sécurité renforcée sur les PC exécutant des logiciels Windows. Les tests de compatibilité Microsoft ont été conçus en collaboration avec des partenaires du secteur et sont constamment améliorés en réponse aux développements du secteur et à la demande des consommateurs.
Le Kit de certification des applications Windows est utilisé pour valider la conformité à ces exigences et remplace le WSLK utilisé pour la validation dans le programme Logo logiciel Windows 7. Le Kit de certification des applications Windows est l’un des composants inclus dans le Kit de développement logiciel (SDK) Windows pour Windows 8.1.
Éligibilité de l’application
Pour qu’une application soit éligible à Windows 8.1 certification d’application de bureau, elle doit répondre aux critères suivants et à toutes les exigences techniques répertoriées dans ce document.
- Il doit s’agir d’une application autonome
- Il doit s’exécuter sur un ordinateur Windows 8.1 local
- Il peut s’agir d’un composant client d’une application Windows Server certifiée
- Il doit s’agir d’un code et d’une fonctionnalité complète
- Il ne doit pas communiquer avec les applications du Windows Store via des mécanismes locaux, y compris via des fichiers et des clés de Registre
- Il ne doit pas compromettre ou compromettre la sécurité ou les fonctionnalités du système Windows
- Elle doit avoir un nom unique et ne doit pas être déposée par d’autres
Si l’application de bureau est soumise à la catégorie de produits anti-virus et/ou anti-logiciels espions (c’est-à-dire, anti-programme malveillant), elle doit respecter les INSTRUCTIONS DE LA PLATEFORME ANTIMALWARE. Le contrat de licence d’API WINDOWS 8 ANTIMALWARE doit avoir été signé et en vigueur avant la soumission. Le partenaire doit être membre ou avoir des chercheurs qui sont membres et en règle dans l’une des organisations mentionnées dans l’entente. La fonctionnalité doit être certifiée sur Windows 8 par l’une des organisations répertoriées dans le contrat. L’application doit avoir été testée au moins une fois au cours des 12 derniers mois et certifiée pour la détection et le nettoyage.
1. Les applications sont compatibles et résilientes
Les fois où une application se bloque ou cesse de répondre provoquent beaucoup de frustration de l’utilisateur. Les applications sont censées être résilientes et stables et l’élimination de ces défaillances permet de garantir que les logiciels sont plus prévisibles, maintenables, performants et fiables.
- 1.1 Votre application ne doit pas dépendre des modes de compatibilité Windows, du message AppHelp et de tout autre correctif de compatibilité
1.2 Votre application doit avoir un manifeste de compatibilité et utiliser les GUID appropriés pour les versions prises en charge de Windows
1.3 Votre application doit prendre en charge les ppp en utilisant le manifeste d’assembly de l’application plutôt qu’en appelant SetProcessDPIAware
1.4 Votre application ne doit pas dépendre du runtime VB6
1.5 Votre application ne doit pas charger de DLL arbitraires pour intercepter les appels d’API Win32 à l’aide de HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dlls.
2. Les applications doivent respecter les bonnes pratiques de sécurité Windows
L’utilisation des meilleures pratiques de sécurité Windows permet d’éviter de créer une exposition aux surfaces d’attaque Windows. Les surfaces d’attaque sont les points d’entrée qu’un attaquant malveillant peut utiliser pour exploiter le système d’exploitation en tirant parti des vulnérabilités du logiciel cible. L’une des pires failles de sécurité est l’élévation des privilèges.
- 2.1 Votre application doit utiliser des listes de contrôle d’accès fortes et appropriées pour sécuriser les fichiers exécutables 2.2 Votre application doit utiliser des listes de contrôle d’accès fortes et appropriées pour sécuriser les répertoires 2.3 Votre application doit utiliser des listes de contrôle d’accès fortes et appropriées pour sécuriser les clés de Registre 2.4 Votre application doit utiliser des listes de contrôle d’accès fortes et appropriées pour sécuriser les répertoires qui contiennent des objets 2.5 Votre application doit réduire l’accès non administrateur aux services vulnérables à la falsification 2.6 Votre application doit empêcher les services avec un accès rapide redémarre à partir d’un redémarrage plus de deux fois toutes les 24 heures
Le programme de certification des applications Windows vérifie que les surfaces d’attaque Windows ne sont pas exposées en vérifiant que les listes de contrôle d’accès et les services sont implémentés d’une manière qui ne met pas en danger le système Windows.
3. Les applications prennent en charge les fonctionnalités de sécurité Windows
Le système d’exploitation Windows dispose de nombreuses fonctionnalités qui prennent en charge la sécurité et la confidentialité du système. Les applications doivent prendre en charge ces fonctionnalités pour maintenir l’intégrité du système d’exploitation. Les applications mal compilées peuvent entraîner des dépassements de mémoire tampon qui peuvent, à leur tour, provoquer un déni de service ou autoriser l’exécution de code malveillant.
- 3.1 Votre application ne doit pas utiliser AllowPartiallyTrustedCallersAttribute (APTCA) pour garantir un accès sécurisé aux assemblys avec nom fort
3.2 Votre application doit être compilée à l’aide de l’indicateur /SafeSEH pour garantir une gestion sécurisée des exceptions
3.3 Votre application doit être compilée à l’aide de l’indicateur /NXCOMPAT pour empêcher l’exécution des données
3.4 Votre application doit être compilée à l’aide de l’indicateur /DYNAMICBASE pour la randomisation de la disposition de l’espace d’adressage (ASLR)
3.5 Votre application ne doit pas lire/écrire les sections PE partagées
4. Les applications doivent adhérer aux messages du gestionnaire de redémarrage du système
Lorsque les utilisateurs lancent l’arrêt, ils ont généralement un fort désir de voir l’arrêt réussir ; ils sont peut-être pressés de quitter le bureau et veulent juste que leurs ordinateurs s’éteignent. Les applications doivent respecter ce désir en ne bloquant pas l’arrêt. Bien que dans la plupart des cas, un arrêt ne soit pas critique, les applications doivent être préparées à la possibilité d’un arrêt critique.
- 4.1 Votre application doit gérer les arrêts critiques de manière appropriée
- Dans un arrêt critique, les applications qui retournent false à WM_QUERYENDSESSION sont envoyées WM_ENDSESSION et fermées, tandis que celles qui expirent en réponse à WM_QUERYENDSESSION sont arrêtées.
- WM\_QUERYENDSESSION avec LPARAM = ENDSESSION\_CLOSEAPP(0x1).
Les applications console peuvent appeler SetConsoleCtrlHandler pour spécifier la fonction qui gérera les notifications d’arrêt. Les applications de service peuvent appeler RegisterServiceCtrlHandlerEx pour spécifier la fonction qui recevra des notifications d’arrêt.
- WM\_ENDSESSION avec LPARAM = ENDSESSION\_CLOSEAPP(0x1).
Au minimum, l’application doit se préparer en enregistrant les données utilisateur et en indiquant les informations nécessaires après un redémarrage.
Remarque : Les applications qui doivent bloquer l’arrêt en raison d’une opération qui ne peut pas être interrompue doivent en expliquer la raison à l’utilisateur. Utilisez ShutdownBlockReasonCreate pour inscrire une chaîne qui explique la raison à l’utilisateur. Une fois l’opération terminée, l’application doit appeler ShutdownBlockReasonDestroy pour indiquer que le système peut être arrêté.
5. Les applications doivent prendre en charge une installation propre et réversible
Une installation propre et réversible permet aux utilisateurs de gérer (déployer et supprimer) les applications sur leurs systèmes.
- 5.1 Votre application doit implémenter correctement une installation propre et réversible
- DisplayName
- Emplacement de l’installation
- Serveur de publication
- UninstallString
- VersionMajor ou MajorVersion
- VersionMinor ou MinorVersion
- Si l’installation échoue, l’application doit pouvoir la restaurer et restaurer l’état précédent de l’ordinateur.
- Le redémarrage de l’ordinateur ne doit jamais être la seule option à la fin d’une installation, d’une désinstallation ou d’une mise à jour. Les utilisateurs doivent avoir la possibilité de redémarrer ultérieurement.
- Les outils d’inventaire Windows et les outils de télémétrie nécessitent des informations complètes sur les applications installées. Si vous utilisez un programme d’installation msi, MSI crée automatiquement les entrées de Registre ci-dessous. Si vous n’utilisez pas de programme d’installation MSI, le module d’installation doit créer les entrées de Registre suivantes pendant l’installation :
6. Les applications doivent signer numériquement les fichiers et les pilotes
Une signature numérique Authenticode permet aux utilisateurs de s’assurer que le logiciel est authentique. Il permet également de détecter si un fichier a été falsifié, par exemple s’il a été infecté par un virus. L’application de la signature de code en mode noyau est une fonctionnalité Windows appelée intégrité du code (CI), qui améliore la sécurité du système d’exploitation en vérifiant l’intégrité d’un fichier chaque fois que l’image du fichier est chargée en mémoire. CI détecte si du code malveillant a modifié un fichier binaire système. Génère également un événement de journal de diagnostic et d’audit système lorsque la signature d’un module de noyau ne parvient pas à vérifier correctement.
- 6.1 Tous les fichiers exécutables (.exe, .dll, .ocx, .sys, .cpl, .drv, .scr) doivent être signés avec un certificat Authenticode
6.2 Tous les pilotes en mode noyau installés par l’application doivent avoir une signature Microsoft obtenue via le programme de certification du matériel Windows. Tous les pilotes de filtre de système de fichiers doivent être signés par Microsoft.
6.3 Exceptions et dérogations
- Les dérogations seront prises en compte uniquement pour les redistribuables tiers non signés, à l’exception des pilotes. Une preuve de communication demandant une version signée du ou des redistribuables est requise pour que cette dérogation soit accordée.
7. Les applications ne bloquent pas l’installation ou le lancement de l’application en fonction d’une version de système d’exploitation case activée
Il est important que les clients ne soient pas empêchés artificiellement d’installer ou d’exécuter leur application en l’absence de limitations techniques. En général, si les applications ont été écrites pour Windows Vista ou des versions ultérieures de Windows, elles ne doivent pas avoir à case activée la version du système d’exploitation.
- 7.1 Votre application ne doit pas effectuer de vérifications de version pour l’égalité
- Les applications fournies sous la forme d’un package qui s’exécutent également sur Windows XP, Windows Vista et Windows 7, et qui doivent case activée la version du système d’exploitation pour déterminer les composants à installer sur un système d’exploitation donné.
- Applications qui case activée uniquement la version minimale du système d’exploitation (pendant l’installation uniquement, et non au moment de l’exécution) en utilisant uniquement les appels d’API approuvés, et qui répertorient correctement la version minimale requise dans le manifeste de l’application.
- Applications de sécurité (antivirus, pare-feu, etc.), utilitaires système (par exemple, défragmenter, sauvegardes et outils diagnostics) qui case activée la version du système d’exploitation en utilisant uniquement les appels d’API approuvés.
- Si vous avez besoin d’une fonctionnalité spécifique, case activée si la fonctionnalité elle-même est disponible. Si vous avez besoin de Windows XP, case activée pour Windows XP ou version ultérieure (>= 5.1). De cette façon, votre code de détection continuera à fonctionner sur les versions futures de Windows. Les programmes d’installation de pilotes et les modules de désinstallation ne doivent jamais case activée la version du système d’exploitation.
8. Les applications ne chargent pas les services ou les pilotes en mode sans échec
Le mode sans échec permet aux utilisateurs de diagnostiquer et de dépanner Windows. Les pilotes et les services ne doivent pas être configurés pour être chargés en mode sans échec, sauf s’ils sont nécessaires pour les opérations système de base de telles que les pilotes de périphériques de stockage ou à des fins de diagnostic et de récupération, telles que les analyseurs antivirus, . Par défaut, lorsque Windows est en mode sans échec, il démarre uniquement les pilotes et les services qui ont été préinstallés avec Windows.
- 8.1 Exceptions et dérogations
- Les pilotes et les services qui doivent être démarrés en mode sans échec nécessitent une dérogation. La demande de dérogation doit inclure chaque pilote ou service applicable écrivant dans les clés de Registre SafeBoot, et décrire les raisons techniques pour lesquelles l’application ou le service doit s’exécuter en mode sans échec. Le programme d’installation de l’application doit inscrire tous ces pilotes et services à l’aide de ces clés de Registre :
Note: Vous devez tester ces pilotes et services pour vous assurer qu’ils fonctionnent en mode sans échec sans erreur.
9. Les applications doivent suivre les instructions de contrôle de compte d’utilisateur
Certaines applications Windows s’exécutent dans le contexte de sécurité d’un compte administrateur, et les applications demandent souvent des droits d’utilisateur et des privilèges Windows excessifs. Le contrôle de l’accès aux ressources permet aux utilisateurs de contrôler leurs systèmes et de les protéger contre les modifications indésirables. Une modification indésirable peut être malveillante, telle qu’un rootkit prenant le contrôle de l’ordinateur, ou être le résultat d’une action effectuée par des personnes disposant de privilèges limités. La règle la plus importante pour contrôler l’accès aux ressources consiste à fournir le moins de contexte utilisateur standard d’accès nécessaire à un utilisateur pour effectuer ses tâches nécessaires. Le respect des instructions de contrôle de compte d’utilisateur (UAC) fournit à l’application les autorisations nécessaires lorsqu’elle en a besoin, sans laisser le système constamment exposé aux risques de sécurité. La plupart des applications ne nécessitent pas de privilèges d’administrateur au moment de l’exécution et doivent être exécutées correctement en tant qu’utilisateur standard.
- 9.1 Votre application doit avoir un manifeste qui définit les niveaux d’exécution et indique au système d’exploitation les privilèges dont l’application a besoin pour s’exécuter
- Outils d’administration ou système avec le niveau d’exécution défini sur highestAvailable et/ou requireAdministrator
- Seule l’application d’infrastructure d’accessibilité ou d’automatisation de l’interface utilisateur définit l’indicateur uiAccess sur true pour contourner l’isolation des privilèges d’interface utilisateur (UIPI). Pour démarrer correctement l’utilisation de l’application, cet indicateur doit être signé Authenticode et doit résider dans un emplacement protégé dans le système de fichiers, à savoir Program Files.
- Le marquage du manifeste d’application s’applique uniquement aux EXE, et non aux DLL. Cela est dû au fait que la UAC n’inspecte pas les DLL lors de la création du processus. Il est également important de noter que les règles de contrôle d’utilisateur ne s’appliquent pas aux services Microsoft. Le manifeste peut être incorporé ou externe.
Pour créer un manifeste, créez un fichier nommé <app_name>.exe.manifest et stockez-le dans le même répertoire que l’EXE. Notez que tout manifeste externe est ignoré si l’application a un manifeste interne. Exemple :
<requestedExecutionLevel level=""asInvoker | highestAvailable | requireAdministrator" » uiAccess=""true|false"/>
- Toutes les fonctionnalités d’administration doivent être déplacées dans un processus distinct qui s’exécute avec des privilèges d’administration. Les applications accessibles aux utilisateurs, telles que celles accessibles via le groupe de programmes dans le menu Démarrer, et nécessitant une élévation doivent être signées Authenticode.
- Une dérogation est requise pour les applications qui exécutent leur processus main avec des privilèges élevés (requireAdministrator ou highestAvailable). Le processus main est identifié comme point d’entrée de l’utilisateur pour l’application. Les dérogations seront prises en compte pour les scénarios suivants :
10. Les applications doivent être installées dans les dossiers appropriés par défaut
Les utilisateurs doivent avoir une expérience cohérente et sécurisée avec l’emplacement d’installation par défaut des fichiers, tout en conservant la possibilité d’installer une application à l’emplacement de leur choix. Il est également nécessaire de stocker les données d’application à l’emplacement approprié pour permettre à plusieurs personnes d’utiliser le même ordinateur sans endommager ou remplacer les données et les paramètres des autres. Windows fournit des emplacements spécifiques dans le système de fichiers pour stocker des programmes et des composants logiciels, des données d’application partagées et des données d’application spécifiques à un utilisateur
- 10.1 Votre application doit être installée dans le dossier Program Files par défaut
- Clés d’exécution de Registre HKLM et, ou HKCU sous Software\Microsoft\Windows\CurrentVersion
- Clés d’exécution de Registre HKLM, et ou HKCU sous Software\Wow6432Node\Microsoft\windows\CurrentVersion
- Menu Démarrer Tousprograms > STARTUP
- Pour les applications natives 32 bits et 64 bits dans %ProgramFiles%, et %ProgramFiles(x86)% pour les applications 32 bits s’exécutant sur x64. Les données utilisateur ou les données d’application ne doivent jamais être stockées à cet emplacement en raison des autorisations de sécurité configurées pour ce dossier.
- Par exemple, votre application ne doit pas définir les éléments suivants :
- Utilisez les méthodes appropriées pour installer des fichiers, telles que des polices ou des pilotes.
- Lorsque l’application est installée, il n’existe aucun emplacement utilisateur correct dans lequel stocker les données. Les tentatives d’une application pour modifier les comportements d’association par défaut au niveau de l’ordinateur après l’installation échouent. Au lieu de cela, les valeurs par défaut doivent être revendiquées au niveau de chaque utilisateur, ce qui empêche plusieurs utilisateurs de remplacer les valeurs par défaut des autres utilisateurs.
- Une dérogation est requise pour les applications qui écrivent dans les applications .NET du Global Assembly Cache (GAC) doivent conserver les dépendances d’assembly privées et les stocker dans le répertoire de l’application, sauf si le partage d’un assembly est explicitement requis.
11. Les applications doivent prendre en charge les sessions multi-utilisateurs
Les utilisateurs Windows doivent être en mesure d’exécuter des sessions simultanées sans conflit ni interruption.
- 11.1 Votre application doit s’assurer qu’en cas d’exécution dans plusieurs sessions, localement ou à distance, les fonctionnalités normales de l’application ne sont pas affectées
11.2 Les paramètres et les fichiers de données de votre application ne doivent pas être conservés entre les utilisateurs
11.3 La confidentialité et les préférences d’un utilisateur doivent être isolées de la session de l’utilisateur
11.4 Les instances de votre application doivent être isolées les unes des autres
- Cela signifie que les données utilisateur d’un instance ne sont pas visibles par un autre instance de l’application. Le son dans une session utilisateur inactive ne doit pas être entendu dans une session utilisateur active. Dans les cas où plusieurs instances d’application utilisent des ressources partagées, l’application doit s’assurer qu’il n’y a pas de conflit.
- Reportez-vous aux exigences du contrôle d’utilisateur.
12. Les applications doivent prendre en charge les versions x64 de Windows
À mesure que le matériel 64 bits devient plus courant, les utilisateurs s’attendent à ce que les développeurs d’applications tirent parti des avantages de l’architecture 64 bits en migrant leurs applications vers 64 bits, ou que les versions 32 bits de l’application s’exécutent bien sous les versions 64 bits de Windows.
- 12.1 Votre application doit prendre en charge en mode natif 64 bits ou, au minimum, les applications windows 32 bits doivent s’exécuter en toute transparence sur les systèmes 64 bits pour maintenir la compatibilité avec les versions 64 bits de Windows
12.2 Votre application et ses programmes d’installation ne doivent pas contenir de code 16 bits ou s’appuyer sur un composant 16 bits
12.3 La configuration de votre application doit détecter et installer les pilotes et composants appropriés pour l’architecture 64 bits
12.4 Tous les plug-ins d’interpréteur de commandes doivent s’exécuter sur les versions 64 bits de Windows
12.5 L’application exécutée sous l’émulateur WoW64 ne doit pas tenter de contourner ou de contourner les mécanismes de virtualisation Wow64
- S’il existe des scénarios spécifiques dans lesquels les applications doivent détecter si elles s’exécutent sous l’émulateur WoW64, elles doivent le faire en appelant IsWow64Process.
Conclusion
À mesure que ces exigences évoluent, nous notons les modifications dans l’historique des révisions ci-dessous. La stabilité des exigences est essentielle à l’exécution de votre travail. Nous nous efforçons donc de garantir que les modifications que nous effectuons sont durables et continuent de protéger et d’améliorer vos applications.
Merci encore d’avoir rejoint notre engagement à offrir des expériences client exceptionnelles.
Historique des révisions
| Date | Version | Description de la révision | Lien vers le document |
|---|---|---|---|
| 20 décembre 2011 | 1.0 | Brouillon initial du document pour la préversion. | |
| 26 janvier 2012 | 1.1 | Mettez à jour vers la section n° 2. | 1.1 |
| 31 mai 2012 | 1,2 | Ajout des résultats de test récapitulatives | 1.2 |
| 29 juin 2012 | 3.0 | Windows 8 document final | 3.0 |
| 18 juin 2013 | 3.1 | Windows 8.1 document | 3.1 |
En savoir plus sur la certification des applications de bureau
| Condition requise | Description | Détails supplémentaires |
|---|---|---|
| Compatibilité et résilience | Les blocages & sont une interruption majeure pour les utilisateurs et provoquent de la frustration. Les applications sont censées être résilientes et stables, l’élimination de ces défaillances permet de garantir que les logiciels sont plus prévisibles, maintenables, performants et fiables. Le point d’entrée de l’application devant l’utilisateur doit être manifesté à des fins de compatibilité, ainsi que la déclaration du GUID approprié. Les points d’entrée d’application accessibles aux utilisateurs doivent être manifestés pour la reconnaissance high-DPI et que les API appropriées sont appelées pour prendre en charge HIGH-DPI. |
Systèmes d’exploitation Windows Vista, Windows 7 et Windows 8 Application Verifier DLL AppInit Manifeste d’application (exécutable) Écriture d’applications Win32 haute résolution |
| Adhérer à Sécurité Windows bonnes pratiques | L’utilisation des meilleures pratiques de sécurité Windows permet d’éviter de créer une exposition aux surfaces d’attaque Windows. Les surfaces d’attaque sont les points d’entrée qu’un attaquant malveillant peut utiliser pour exploiter le système d’exploitation en tirant parti des vulnérabilités du logiciel cible. L’une des pires failles de sécurité est l’élévation des privilèges. |
Analyseur de surface d’attaque Listes de contrôle d’accès |
| Fonctionnalités Sécurité Windows de prise en charge | Le système d’exploitation Windows a implémenté de nombreuses mesures pour prendre en charge la sécurité et la confidentialité du système. Les applications doivent prendre en charge ces mesures pour maintenir l’intégrité du système d’exploitation. Les applications mal compilées peuvent entraîner des dépassements de mémoire tampon qui, à leur tour, peuvent entraîner un déni de service ou exécuter du code malveillant. |
Informations de référence sur l’outil BinScope |
| Respecter les messages du Gestionnaire de redémarrage du système | Lorsque les utilisateurs lancent l’arrêt, dans la grande majorité des cas, ils ont un fort désir de voir l’arrêt réussir; ils sont peut-être pressés de quitter le bureau et « veulent juste » que leurs ordinateurs s’éteignent. Les applications doivent respecter ce désir en ne bloquant pas l’arrêt. Bien que dans la plupart des cas, un arrêt ne soit pas critique, les applications doivent être préparées à la possibilité d’un arrêt critique. |
Modifications de l’arrêt d’application dans Windows Vista Redémarrer le développement du Gestionnaire |
| Installation réversible propre | Une installation propre et réversible permet aux utilisateurs de gérer (déployer et supprimer) les applications sur leurs systèmes. |
Guide pratique pour installer des composants prérequis avec une application ClickOnce Installation de l’application sur des systèmes 64 bits |
| Fichiers et pilotes de signature numérique | Une signature numérique Authenticode permet aux utilisateurs de s’assurer que le logiciel est authentique. Il permet également de détecter si un fichier a été falsifié, par exemple s’il a été infecté par un virus. L’application de la signature de code en mode noyau est une fonctionnalité Windows appelée intégrité du code (CI), qui améliore la sécurité du système d’exploitation en vérifiant l’intégrité d’un fichier chaque fois que l’image du fichier est chargée en mémoire. CI détecte si du code malveillant a modifié un fichier binaire système. Génère également un événement de journal de diagnostic et d’audit système lorsque la signature d’un module de noyau ne parvient pas à vérifier correctement. |
Signatures numériques pour les modules de noyau sur Windows |
| Ne bloquez pas l’installation ou le lancement de l’application en fonction de la version du système d’exploitation case activée | Il est important que les clients ne soient pas empêchés artificiellement d’installer ou d’exécuter leur application en l’absence de limitations techniques. En général, si les applications ont été écrites pour Windows Vista ou des versions ultérieures, elles ne doivent avoir aucune raison de case activée la version du système d’exploitation. |
Contrôle de version du système d’exploitation |
| Ne pas charger les services et les pilotes en mode sans échec | Le mode sans échec permet aux utilisateurs de diagnostiquer et de dépanner Windows. Sauf si cela est nécessaire pour les opérations de base du système (par exemple, les pilotes de périphérique de stockage) ou à des fins de diagnostic et de récupération (par exemple, les analyseurs antivirus), les pilotes et les services ne doivent pas être définis pour être chargés en mode sans échec. Par défaut, le mode sans échec ne démarre pas la plupart des pilotes et services qui n’ont pas été préinstallés avec Windows. Ils doivent rester désactivés, sauf si le système en a besoin pour les opérations de base ou à des fins de diagnostic et de récupération. |
Déterminer si le système d’exploitation s’exécute en mode sans échec |
| Suivre les instructions relatives au contrôle de compte d’utilisateur (UAC) | Certaines applications Windows s’exécutent dans le contexte de sécurité d’un compte administrateur, et beaucoup nécessitent des droits d’utilisateur et des privilèges Windows excessifs. Le contrôle de l’accès aux ressources permet aux utilisateurs de contrôler leurs systèmes contre les modifications indésirables (une modification indésirable peut être malveillante, telle qu’un rootkit prenant furtivement le contrôle de l’ordinateur, ou une action de personnes disposant de privilèges limités, par exemple, un employé installant des logiciels interdits sur un ordinateur de travail). La règle la plus importante pour contrôler l’accès aux ressources consiste à fournir le moins de contexte utilisateur standard d’accès nécessaire à un utilisateur pour effectuer ses tâches nécessaires. Le respect des instructions de contrôle d’utilisateur fournit à l’application les autorisations nécessaires si nécessaire, sans laisser le système constamment exposé aux risques de sécurité. |
Contrôle de compte d'utilisateur UAC : Instructions de mise à jour d’application |
| Installer dans les dossiers corrects par défaut | Les utilisateurs doivent avoir une expérience cohérente et sécurisée avec l’emplacement d’installation par défaut des fichiers, tout en conservant la possibilité d’installer une application à l’emplacement de leur choix. Il est également nécessaire de stocker les données d’application à l’emplacement approprié pour permettre à plusieurs personnes d’utiliser le même ordinateur sans endommager ou remplacer les données et les paramètres des autres. |
Résumé de la configuration requise pour l’installation/la désinstallation |
| Prendre en charge les sessions multi-utilisateurs | Les utilisateurs Windows doivent être en mesure d’exécuter des sessions simultanées sans conflit ni interruption. |
Instructions de programmation des services Bureau à distance |
| Prise en charge des versions x64 de Windows | À mesure que le matériel 64 bits devient plus répandu, les utilisateurs s’attendent à ce que les développeurs d’applications tirent parti des avantages de l’architecture 64 bits en migrant leurs applications vers 64 bits, ou que les versions 32 bits de l’application s’exécutent bien sous les versions 64 bits de Windows. |
Compatibilité des applications : Windows Vista 64 bits |