Archive : Exigences de certification pour les applications de bureau Windows v3.0
version de document : 3.0
date du document : le 29 juin 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 approuvent la marque Windows sur votre produit, car ils garantissent qu’ils répondent aux normes de compatibilité et s’exécutent correctement sur la plateforme Windows. La réussite de la certification des applications Windows permet à votre application d’être présentée dans le Centre de compatibilité Windows et il est également nécessaire de répertorier une référence d’application de bureau dans le Windows Store.
Le programme de certification des applications Windows est constitué des exigences techniques et du programme pour vous assurer que les applications tierces portant la marque Windows sont 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 assurer la cohérence de l’expérience, améliorer les performances et améliorer la sécurité sur les PC exécutant des logiciels Windows. Les tests de compatibilité Microsoft ont été conçus en collaboration avec les partenaires du secteur et sont continuellement 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 Windows 7 Software Logo. Le Kit de certification des applications Windows est l’un des composants inclus dans le Kit de développement logiciel Windows (SDK) pour Windows 8. Il est également intégré à Microsoft Visual Studio 2012 Express pour Windows 8.
Éligibilité de l’application
Pour qu’une application se qualifie pour la certification des applications de bureau Windows 8, elle doit respecter les 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 du code et de la fonctionnalité terminées
1. Les applications sont compatibles et résilientes
Les moments où une application plante ou cesse de répondre provoquent beaucoup de frustration de l’utilisateur. Les applications sont censées être résilientes et stables et éliminer ces défaillances permettent de s’assurer que les logiciels sont plus prévisibles, gérables, performants et fiables.
- 1.1 Votre application ne doit pas dépendre des modes de compatibilité Windows, du message AppHelp et des autres correctifs de compatibilité
1.2 Votre application ne doit pas être dépendante du runtime VB6
1.3 Votre application ne doit pas charger des 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 l’exposition aux surfaces d’attaque Windows. Les surfaces d’attaque sont les points d’entrée qu’un attaquant malveillant pourrait utiliser pour exploiter le système d’exploitation en tirant parti des vulnérabilités dans le logiciel cible. L’une des pires vulnérabilités de sécurité est l’élévation de 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 fichiers exécutables forts et appropriés Les listes de contrôle d’accès 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
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ées de manière à ne pas mettre 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 a 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 incorrectement 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 nommés fort
3.2 Votre application doit être compilée à l’aide de l’indicateur /SafeSEH pour garantir la 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 peuvent être pressés de quitter le bureau et veulent simplement que leurs ordinateurs soient désactivés. 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 pour 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 seront envoyées WM_ENDSESSION et fermées, tandis que celles qui expirent en réponse à WM_QUERYENDSESSION seront arrêtées.
- WM\_QUERYENDSESSION avec LPARAM = ENDSESSION\_CLOSEAPP(0x1).
Les applications console peuvent appeler SetConsoleCtrlHandler pour spécifier la fonction qui gère 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 toutes 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
- InstallLocation
- Éditeur
- UninstallString
- VersionMajor ou MajorVersion
- VersionMinor ou MinorVersion
- Si l’installation échoue, l’application doit pouvoir la restaurer et restaurer l’ordinateur à son état précédent.
- 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 basé sur 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 lors de l’installation :
6. Les applications doivent 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 le 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 par le biais du programme de certification matérielle Windows. Tous les pilotes de filtre du système de fichiers doivent être signés par Microsoft.
6.3 Exceptions et exceptions
- Les exemptions ne seront prises en compte que pour les redistribuables tiers non signés, à l’exclusion des pilotes. Une preuve de communication demandant une version signée du ou des redistribuables est requise pour que cette exemption soit accordée.
7. Les applications ne bloquent pas l’installation ou le lancement de l’application en fonction d’une vérification de version du système d’exploitation
Il est important que les clients ne soient pas artificiellement bloqués d’installer ou d’exécuter leur application lorsqu’il n’existe aucune limitation technique. En général, si les applications ont été écrites pour Windows Vista ou les versions ultérieures de Windows, elles ne doivent pas avoir à vérifier 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 en tant que package qui s’exécutent également sur Windows XP, Windows Vista et Windows 7, doivent vérifier la version du système d’exploitation pour déterminer les composants à installer sur un système d’exploitation donné.
- Les applications qui vérifient uniquement la version minimale du système d’exploitation (pendant l’installation uniquement, pas au moment de l’exécution) à l’aide uniquement des appels d’API approuvés et qui répertorient correctement la configuration requise de version minimale dans le manifeste de l’application.
- Applications de sécurité (antivirus, pare-feu, etc.), utilitaires système (par exemple, défragmentation, sauvegardes et outils de diagnostic) qui vérifient la version du système d’exploitation à l’aide uniquement des appels d’API approuvés.
- Si vous avez besoin d’une fonctionnalité spécifique, vérifiez si la fonctionnalité elle-même est disponible. Si vous avez besoin de Windows XP, recherchez Windows XP ou version ultérieure (>= 5.1). Ainsi, votre code de détection continuera de fonctionner sur les futures versions de Windows. Les programmes d’installation de pilotes et les modules de désinstallation ne doivent jamais vérifier la version du système d’exploitation.
8. Les applications ne chargent pas de services ou de 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 charger 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érique de stockage ou à des fins de diagnostic et de récupération, telles que les scanneurs antivirus. Par défaut, lorsque Windows est en mode sans échec, il démarre uniquement les pilotes et les services préinstallés avec Windows.
- 8.1 Exceptions et exceptions
- Les pilotes et les services qui doivent être démarrés en mode sans échec nécessitent une exemption. La demande de dispense 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 :
Remarque : Vous devez tester ces pilotes et services pour vous assurer qu’ils fonctionnent en mode 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 excessifs et des privilèges Windows. 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 qui ont des privilèges limités. La règle la plus importante pour contrôler l’accès aux ressources consiste à fournir la quantité minimale de contexte utilisateur standard d’accès nécessaire pour qu’un utilisateur effectue ses tâches nécessaires. Les instructions de contrôle de compte d’utilisateur (UAC) suivantes fournissent à l’application les autorisations nécessaires quand elles sont nécessaires par l’application, 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 s’exécuter 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 requis par l’application pour s’exécuter
- Outils d’administration ou système dont le niveau d’exécution est 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 de l’application s’applique uniquement aux EXEs, et non aux DLL. Cela est dû au fait que L’UAC n’inspecte pas les DLL pendant la création du processus. Il vaut également la peine de noter que les règles UAC ne s’appliquent pas aux services Microsoft. 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. Par 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 accessibles par l’utilisateur, 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 principal avec des privilèges élevés (requireAdministrator ou highestAvailable). Le processus principal 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. Les applications doivent être installées sur 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 l’option d’installation d’une application à l’emplacement de leur choix. Il est également nécessaire de stocker des 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 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
- Les clés d’exécution du Registre HKLM et, ou HKCU, sous Software\Microsoft\Windows\CurrentVersion
- Les clés d’exécution du Registre HKLM et ou HKCU sous Software\Wow6432Node\Microsoft\windows\CurrentVersion
- Menu Démarrer AllPrograms > 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 dans cet emplacement en raison des autorisations de sécurité configurées pour ce dossier.
- Par exemple, votre application ne doit pas définir l’un des éléments suivants ;
- Utilisez les méthodes appropriées pour installer des fichiers, tels que des polices ou des pilotes.
- Lorsque l’application est installée, il n’existe aucun emplacement d’utilisateur correct dans lequel stocker des données. Les tentatives effectuées par 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.
- Une exemption 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 pouvoir 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, la fonctionnalité normale de l’application n’est pas affectée de manière négative
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’une instance ne sont pas visibles par une 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 l’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 des versions 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 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 n’importe quel 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 shell doivent s’exécuter sur des versions 64 bits de Windows
12.5 L’application s’exécutant sous l’émulateur WoW64 ne doit pas tenter de contourner les mécanismes de virtualisation Wow64
- S’il existe des scénarios spécifiques où les applications doivent détecter s’ils s’exécutent sous l’émulateur WoW64, ils doivent le faire en appelant IsWow64Process.
Conclusion
À mesure que ces exigences évoluent, nous notons les modifications apportées à l’historique des révisions ci-dessous. Les exigences stables sont essentielles pour effectuer votre meilleur travail. Nous nous efforçons donc de garantir que les modifications que nous faisons sont durables et continuent de protéger et d’améliorer vos applications.
Merci encore de vous joindre à notre engagement à offrir de grandes expériences client.
Historique des révisions
| Date | Version | Description de révision | Lien vers le document |
|---|---|---|---|
| 20c 2011 | 1.0 | Brouillon initial du document pour la préversion. | |
| 26 janvier 2012 | 1.1 | Effectuez une mise à jour vers la section n° 2. | 1.1 |
| 31 mai 2012 | 1.2 | Ajout des résultats de test de synthèse | 1.2 |
| 29 juin 2012 | 3.0 | Document final Windows 8 | 3.0 |
En savoir plus sur la certification des applications de bureau
| Exigence | Description | Plus d’informations |
|---|---|---|
| Compatibilité et résilience | Les blocages & sont une perturbation majeure des utilisateurs et provoquent des frustrations. Les applications sont censées être résilientes et stables, ce qui permet d’éliminer ces défaillances afin de s’assurer que les logiciels sont plus prévisibles, gérables, performants et fiables. |
systèmes d’exploitation Windows Vista, Windows 7 et Windows 8 du vérificateur d’application DLL AppInit |
| Respecter les meilleures pratiques de sécurité Windows | L’utilisation des meilleures pratiques de sécurité Windows permet d’éviter l’exposition aux surfaces d’attaque Windows. Les surfaces d’attaque sont les points d’entrée qu’un attaquant malveillant pourrait utiliser pour exploiter le système d’exploitation en tirant parti des vulnérabilités dans le logiciel cible. L’une des pires vulnérabilités de sécurité est l’élévation de privilèges. |
Attack Surface Analyzer listes de contrôle d’accès |
| Prise en charge des fonctionnalités de sécurité Windows | 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 incorrectement peuvent entraîner des dépassements de mémoire tampon qui, à leur tour, pourraient entraîner un déni de service ou exécuter du code malveillant. |
référence de 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 peuvent être pressés de quitter le bureau et de « vouloir » que leurs ordinateurs soient désactivés. 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 pour la possibilité d’un arrêt critique. |
modifications d’arrêt d’application dans windows Vista redémarrer le de développement du Gestionnaire de redémarrage |
| 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. |
Comment : installer les prérequis avec une application ClickOnce installation d’applications 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 le 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 vérification de la version du système d’exploitation | Il est important que les clients ne soient pas artificiellement bloqués d’installer ou d’exécuter leur application lorsqu’il n’existe aucune limitation technique. En général, si les applications ont été écrites pour Windows Vista ou versions ultérieures, elles ne doivent pas avoir de raison de vérifier la version du système d’exploitation. |
de contrôle de version du système d’exploitation |
| Ne chargez pas les services et pilotes en mode sans échec | Le mode sans échec permet aux utilisateurs de diagnostiquer et de dépanner Windows. Sauf si nécessaire pour les opérations de base du système (par exemple, les pilotes de périphériques de stockage) ou à des fins de diagnostic et de récupération (par exemple, les scanneurs 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 ne sont pas préinstallés avec Windows. Ils doivent rester désactivés, sauf si le système les requiert pour des 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 de contrôle de compte d’utilisateur (UAC) | Certaines applications Windows s’exécutent dans le contexte de sécurité d’un compte d’administrateur, et beaucoup nécessitent des droits d’utilisateur excessifs et des privilèges Windows. 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 le contrôle de l’ordinateur ou d’une action de personnes disposant de privilèges limités, par exemple, d’un employé qui installe des logiciels interdits sur un ordinateur professionnel). La règle la plus importante pour contrôler l’accès aux ressources consiste à fournir la quantité minimale de contexte utilisateur standard d’accès nécessaire pour qu’un utilisateur effectue ses tâches nécessaires. Les instructions UAC suivantes fournissent aux applications les autorisations nécessaires si nécessaire, sans laisser le système constamment exposé aux risques de sécurité. |
de 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 l’option d’installation d’une application à l’emplacement choisi. Il est également nécessaire de stocker des 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 paramètres des autres. | résumé des exigences d’installation/désinstallation |
| Prise en charge des sessions multi-utilisateurs | Les utilisateurs Windows doivent pouvoir 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 des versions 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 |