Archive : Exigences de certification pour les applications de bureau Windows v1.2
Version du document : 1.2
Date du document : 31 mai 2012
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. 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.
Éligibilité de l’application
Pour qu’une application soit éligible à Windows 8 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
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 ne doit pas dépendre du runtime VB6
1.3 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.
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 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 qui sont livrées en tant que 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, pas 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éfragmentation, 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 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 services préinstallés avec Windows.
- 8.1 Exceptions et renonciations
- Les pilotes et les services qui doivent être démarrés en mode sans échec nécessitent une renonciation. La demande de renonciation doit inclure chaque pilote ou service applicable écrit 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 d’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 est de fournir le moins de contexte utilisateur standard d’accès nécessaire pour qu’un utilisateur effectue ses tâches nécessaires. Les instructions suivantes relatives au contrôle de compte d’utilisateur (UAC) fournissent à l’application les autorisations nécessaires quand elles sont nécessaires, sans laisser le système constamment exposé à des 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 parfaitement exécutées 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 dont le niveau d’exécution est défini sur le plus élevéDisponible 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, pas aux DLL. Cela est dû au fait que l’UAC n’inspecte pas les DLL pendant la création du processus. Il est également important de noter que les règles UAC ne s’appliquent pas aux services Windows. Le manifeste peut être incorporé ou externe.
Pour créer un manifeste, créez un fichier portant le nom <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 administratives doivent être déplacées dans un processus distinct qui s’exécute avec des privilèges d’administration. Les applications destinées 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 exemption 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 vers l’application. Les dérogations seront prises en compte pour les scénarios suivants :
10. Par défaut, les applications doivent être installées dans les dossiers appropriés
Les utilisateurs doivent disposer d’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 de l’autre. 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 du Registre HKLM et, ou HKCU sous Software\Microsoft\Windows\CurrentVersion
- Clés d’exécution du Registre HKLM et ou HKCU sous Software\Wow6432Node\Microsoft\windows\CurrentVersion
- Menu Démarrer Tous les programmes > DÉMARRAGE
- 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 définir aucun des é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 pas d’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 de l’autre.
- Une exemption est requise pour les applications qui écrivent dans les applications .NET 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 que lorsqu’elle s’exécute 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 persister entre les utilisateurs
11.3 La confidentialité et les préférences d’un utilisateur doivent être isolées dans 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 de UAC.
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 où les applications doivent détecter si elles s’exécutent sous l’émulateur WoW64, elles doivent le faire en appelant IsWow64Process.
Résumé des tests effectués sur les applications de bureau
| Nom du test | Résultats possibles des tests |
|---|---|
| Respecter les messages du gestionnaire de redémarrage du système | Réussite/échec |
| Nettoyer l’installation réversible | Pass/Fail/Warning |
| Test de résilience de compatibilité & | Pass/Fail/Warning |
| Test de fichier signé numériquement | Pass/Fail/Warning |
| Installer sur le test de dossiers appropriés | Avertissement |
| Test de session multiutilisateur | Avertissement |
| Test de vérification de version du système d’exploitation | Réussite/échec |
| Test en mode sans échec | Réussite/échec |
| Prise en charge du test Windows x64 | Réussite/échec |
| Tester les modifications apportées aux fonctionnalités de sécurité Windows (Analyseur surface d’attaque) | Pass/Fail/Warning |
| Tester les modifications apportées aux fonctionnalités de sécurité Windows (BinScope Binary Analyzer) | Avertissement |
| Test du contrôle de compte d’utilisateur (UAC) | Pass/Fail/Warning |
Conclusion
À mesure que ces exigences évoluent, nous noterons les modifications apportées à l’historique des révisions ci-dessous. La stabilité des exigences est essentielle à l’exécution de votre travail. Nous nous efforcerons donc de garantir que les modifications que nous apporterons sont durables et continuent de protéger et d’améliorer vos applications.
Merci encore d’avoir rejoint notre engagement à offrir d’excellentes expériences client.
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 #2. | 1.1 |
| 31 mai 2012 | 1,2 | Ajout des résultats de test récapitulatives Document final |
1,2 |
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 perturbation 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. |
Systèmes d’exploitation Windows Vista, Windows 7 et Windows 8 Application Verifier DLL AppInit |
| Respecter les meilleures pratiques 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. |
Analyseur de surface d’attaque Listes de contrôle d’accès |
| Fonctionnalités de 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 compilées de manière incorrecte peuvent entraîner des dépassements de mémoire tampon qui, à leur tour, pourraient provoquer un déni de service ou exécuter du code malveillant. |
Informations de référence sur l’outil BinScope |
| Adhérer aux 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 Développement du Gestionnaire de redémarrage |
| Nettoyer l’installation réversible | Une installation propre 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 d’application sur des systèmes 64 bits |
| Signer numériquement des fichiers et des 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. |
Signatures numériques pour les modules du noyau sur Windows |
| Ne bloquez pas l’installation ou le lancement d’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 lorsqu’il n’existe aucune limitation technique. En général, si des applications ont été écrites pour Windows Vista ou des versions ultérieures, elles ne doivent pas avoir de raison de case activée la version du système d’exploitation. |
Contrôle de version du système d’exploitation |
| Ne chargez pas 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 configurés pour se charger 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 |
| Suivez 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 non souhaitée peut être malveillante, comme un rootkit prenant furtivement le contrôle de la machine, ou une action de personnes disposant de privilèges limités, par exemple, un employé qui installe des logiciels interdits sur un ordinateur de travail). La règle la plus importante pour contrôler l’accès aux ressources est de fournir le moins de contexte utilisateur standard d’accès nécessaire pour qu’un utilisateur effectue ses tâches nécessaires. Le suivi des instructions UAC fournit à l’application les autorisations nécessaires si nécessaire, sans laisser le système constamment exposé à des risques de sécurité. |
Contrôle de compte d'utilisateur UAC : Instructions de mise à jour des applications |
| Installer dans les dossiers appropriés par défaut | Les utilisateurs doivent disposer d’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 de l’autre. |
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 |