Conditions de certification des applications de bureau Windows
Version du document : 10
Date du document : 29 juillet 2015
Ce document contient les exigences techniques et les qualifications d’éligibilité qu’une application de bureau doit remplir pour participer au programme de certification des applications de bureau Windows 10.
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é envers la qualité entre Microsoft et votre entreprise. Les clients font confiance à la marque Windows sur votre produit, car elle garantit qu’elle répond aux normes de compatibilité et qu’elle 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 et vous pouvez afficher le logo de certification sur votre site.
Le programme de certification des applications Windows est constitué d’exigences techniques et de programme 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é dans les 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 les versions précédentes du kit utilisées pour la validation sur Windows 7, Windows 8 ou Windows 8.1. Le Kit de certification des applications Windows est l’un des composants inclus dans le Kit de développement logiciel (SDK) Windows pour Windows 10.
Éligibilité de l’application
Pour qu’une application soit éligible à Windows 10 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 PC Windows 10 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é complets
- Il ne doit pas communiquer avec les applications du Windows Store via des mécanismes locaux, notamment via des fichiers et des clés de Registre, sauf dans les scénarios d’entreprise pris en charge
- 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 personnes
- Tous les composants externes doivent être certifiés séparément ou être conformes au Kit de certification des applications Windows
- Il doit disposer d’une option de refus pour toutes les applications groupées
Si l’application de bureau est soumise à la catégorie de produits anti-virus et/ou anti-logiciel espion (c’est-à-dire, anti-programme malveillant), elle doit respecter les DIRECTIVES DE LA PLATEFORME ANTIMALWARE. Le CONTRAT DE LICENCE ET DE RÉFÉRENCEMENT DE L’API ANTIMALWARE WINDOWS 10 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 10 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 moments 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 disposer d’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 à l’aide du 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 meilleures 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 vulnérabilités de sécurité est l’élévation des privilèges.
Notez que les tests 2.1 2.6 s’appliquent uniquement aux applications de bureau testées sur Windows 7, Windows 8 ou Windows 8.1.
- 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 des redémarrages rapides de redémarrer plus de deux fois toutes les 24 heures
Remarque : L’accès ne doit être accordé qu’aux entités qui en ont besoin.
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 le système Windows en danger.
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 compilées de manière incorrecte 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 aux noms forts
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 respecter les 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 simplement 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
- Lors d’un arrêt critique, les applications qui retournent la valeur 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.
5. Les applications doivent prendre en charge une installation réversible propre
Une installation propre 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 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 la machine.
- 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 forme de package qui s’exécutent également sur Windows 7, Windows 8 et Windows 8.1, 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 7, case activée pour Windows 7 ou version ultérieure (>= 6.2). 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 à une 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. Par 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 |
| 20 février 2014 | 3.2 | Mise à jour interne | |
| 18 mars 2014 | 3.3 | Mise à jour Windows 8.1 1 | 3.3 |
| 29 juillet 2015 | 10 | mise à jour Windows 10 | 10 |
En savoir plus sur la certification des applications de bureau
| Condition requise | Description |
| 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. Pour plus d’informations, consultez les pages suivantes : |
| 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. Pour plus d’informations, consultez les pages suivantes : |
| 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. Pour plus d’informations, consultez la référence de 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. |
| 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. Pour plus d’informations, consultez How to: Install Prerequisites with a ClickOnce Application. |
| 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. |
| 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. Pour plus d’informations, consultez 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. Pour plus d’informations, consultez les pages suivantes : |
| 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é. Pour plus d’informations, consultez les pages suivantes : |
| 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. Pour plus d’informations, consultez Résumé des exigences d’installation/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. Pour plus d’informations, consultez 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. |