Archive : conditions de Certification pour les applications de bureau Windows v 3.1

Version du document : 3,1

Date du document : Le 18 juin 2013

ce document contient les spécifications 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 de logiciel Windows.

Bienvenue !

la plateforme Windows prend en charge un vaste écosystème de produits et de partenaires. l’affichage du logo de Windows sur votre produit représente une relation et un engagement partagé pour la qualité entre Microsoft et votre entreprise. les clients font confiance à la Windows de votre produit, car ils garantissent qu’ils respectent les normes de compatibilité et qu’ils s’exécutent correctement sur la plateforme Windows. la réussite de la réussite de la Certification d’application 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 magasin de Windows.

le programme de Certification des applications Windows est constitué de spécifications techniques et de programme pour garantir que les applications tierces qui enportent la Windows de la personnalisation sont à la fois faciles à installer et fiables sur les pc exécutant Windows. Les clients ont une valeur de stabilité, de compatibilité, de fiabilité, de performances et de qualité dans les systèmes qu’ils achètent. Microsoft met l’accent sur ses investissements pour répondre à ces exigences en matière d’applications logicielles conçues pour s’exécuter sur la plateforme Windows pour les pc. ces efforts incluent des tests de compatibilité pour assurer la cohérence de l’expérience, améliorer les performances et renforcer la sécurité sur les pc exécutant Windows logiciel. Les tests de compatibilité de Microsoft ont été conçus en collaboration avec les partenaires de l’industrie 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é avec ces exigences et remplace le WSLK utilisé pour la validation dans le programme de Logo 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 pour la Certification Windows 8.1 des applications 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 local Windows 8.1
  • il peut s’agir d’un composant client d’une application Windows Server certifiée
  • Le code et la fonctionnalité doivent être terminés
  • il ne doit pas communiquer avec les applications Windows store via des mécanismes locaux, y compris via des fichiers et des clés de registre.
  • elle ne doit pas compromettre ni compromettre la sécurité ou la fonctionnalité 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 antivirus et/ou anti-logiciels espions (c.-à-d., des produits anti-programme malveillant), elle doit respecter les instructions de la plate-forme anti-programme malveillant. Le contrat de licence de l’API logiciel anti-programme malveillant de WINDOWS 8 doit avoir été signé et en vigueur avant l’envoi. Le partenaire doit être membre de, ou avoir des chercheurs qui sont membres de et en bonne position dans une des organisations répertoriées dans le contrat. la fonctionnalité doit être certifiée sur Windows 8 par 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 cessent de répondre entraînent une frustration importante pour l’utilisateur. Les applications sont censées être résilientes et stables, ce qui permet de s’assurer que les logiciels sont plus prévisibles, gérables, performants et dignes de confiance.

1,1 votre application ne doit pas dépendre de Windows modes de compatibilité, du message AppHelp et ou 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 DPI en utilisant le manifeste de l’assembly de l’application plutôt que d’appeler 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 des \ dll HKLM Software \ Microsoft \ Windows NT \ CurrentVersion \ Windows AppInit _ .

2. les applications doivent respecter les meilleures pratiques en matière de sécurité de Windows

l’utilisation des meilleures pratiques de sécurité de Windows permet d’éviter la création d’expositions à des surfaces d’attaque Windows. Les surfaces d’attaque sont les points d’entrée qu’un attaquant malveillants pourrait utiliser pour exploiter le système d’exploitation en tirant parti des vulnérabilités dans le logiciel cible. L’élévation de privilèges constitue l’une des pires failles de sécurité.

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 qui sont vulnérables à la falsification 2,6 votre application doit empêcher les services avec redémarrages rapides de redémarrer plus de deux fois toutes les 24 heures
Remarque : l’accès doit être accordé uniquement aux entités qui l’exigent.

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 de manière à ne pas mettre le système Windows en péril.

3. les applications prennent en charge les fonctionnalités de sécurité Windows

le système d’exploitation Windows possède 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. Des 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 permettre 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 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 du format d’espace d’adresse (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 système

Lorsque les utilisateurs lancent l’arrêt, ils ont généralement un souhait fort de voir la tentative d’arrêt. ils peuvent être impressés de sortir du bureau et de simplement vouloir éteindre leur ordinateur. Les applications doivent respecter ce souhait en ne bloquant pas l’arrêt. Dans la plupart des cas, un arrêt peut ne pas être 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 renvoient la valeur FALSe à WM _ QUERYENDSESSION reçoivent WM _ ENDSESSION et Closed, tandis que celles qui expirent en réponse à WM _ QUERYENDSESSION seront arrêtées.

4.2 A GUI app must return TRUE immediately in preparation for a restart
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 les notifications d’arrêt.
4.3 Your app must return 0 within 30 seconds and shut down
WM \_ ENDSESSION avec LPARAM = ENDSESSION \_ CLOSEAPP (0x1). Au minimum, l’application doit se préparer en enregistrant les données utilisateur et indiquer les informations nécessaires après un redémarrage.
4.4 Console apps that receive the CTRL\_C\_EVENT notification should shut down immediately 4.5 Drivers must not veto a system shutdown event

Remarque : les applications qui doivent bloquer l’arrêt en raison d’une opération qui ne peut pas être interrompue doivent expliquer la raison à l’utilisateur. Utilisez ShutdownBlockReasonCreate pour inscrire une chaîne expliquant la raison de 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 avec succès (déployer et supprimer) des applications sur leurs systèmes.

5,1 votre application doit implémenter correctement une installation propre et réversible
Si l’installation échoue, l’application doit être en mesure de la restaurer et de restaurer l’ordinateur à son état précédent.

5.2 Your app must never force the user to restart the computer immediately
Le redémarrage de l’ordinateur ne doit jamais être la seule option à la fin de l’installation, de la désinstallation ou de la mise à jour. Les utilisateurs doivent avoir la possibilité de redémarrer ultérieurement.
5.3 Your app must never be dependent on 8.3 short file names (SFN) 5.4 Your app must never block silent install/uninstall 5.5 Your app installer must create the correct registry entries to allow successful detection and uninstalls
Windows outils d’inventaire et les outils de télémétrie requièrent 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 un programme d’installation MSI, le module d’installation doit créer les entrées de Registre suivantes au cours de l’installation :
  • DisplayName
  • Emplacement de l’installation
  • Publisher
  • UninstallString
  • VersionMajor ou MajorVersion
  • VersionMinor ou MinorVersion
5.6 The app must remove all of its entries from Add/ Remove Programs upon uninstall

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 diagnostic et de journal 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 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 uniquement prises en compte pour les fichiers redistribuables tiers non signés, à l’exception des pilotes. Une preuve de communication demandant une version signée du ou des redistribuables est nécessaire pour que cette renonciation soit accordée.

7. les applications ne bloquent pas l’installation ou le lancement d’applications en fonction de la vérification de la version du système d’exploitation

Il est important que les clients ne soient pas bloqués de façon artificielle contre l’installation ou l’exécution de 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 vérifier l’égalité de la version
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). De cette façon, votre code de détection continuera à fonctionner sur les futures versions de Windows. Les modules d’installation et de désinstallation de pilotes ne doivent jamais vérifier la version du système d’exploitation.

7.2 Exceptions and Waivers will be considered for apps meeting the criteria below:
  • les applications qui sont remises sous la forme d’un package qui s’exécutent également sous Windows XP, Windows Vista et Windows 7, et qui doivent vérifier la version du système d’exploitation pour déterminer les composants à installer sur un système d’exploitation donné.
  • Applications qui vérifient uniquement la version minimale du système d’exploitation (uniquement lors de l’installation, 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.
  • Les applications de sécurité (antivirus, pare-feu, etc.), les utilitaires système (par exemple, Defrag, les sauvegardes et les outils de diagnostic) qui vérifient la version du système d’exploitation en utilisant uniquement les appels d’API approuvés.

8. les applications ne chargent pas les services ou les pilotes en mode sans échec

Coffre mode 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 scanneurs 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 renonciation doit inclure l’écriture du pilote ou du service applicable 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 les pilotes et services de ce type à l’aide des clés de Registre suivantes :
    - HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal - HKLM/System/CurrentControlSet/Control/SafeBoot/Network

Remarque : Vous devez tester ces pilotes et services pour vous assurer qu’ils fonctionnent en mode sans échec sans erreurs.

9. les applications doivent suivre les instructions relatives au 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 de 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 qui contrôle 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 contexte utilisateur standard d’accès minimal nécessaire à l’utilisateur pour effectuer ses tâches nécessaires. Les instructions de contrôle de compte d’utilisateur (UAC) suivantes fournissent aux applications les autorisations nécessaires lorsqu’elles sont nécessaires à l’application, sans laisser le système constamment exposé aux risques de sécurité. La plupart des applications ne requièrent pas de privilèges d’administrateur au moment de l’exécution et doivent s’exécuter parfaitement 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
Le marquage du manifeste de l’application s’applique uniquement aux fichiers exe, pas aux dll. Cela est dû au fait que le contrôle de compte d’utilisateur n’examine pas les dll pendant la création du processus. il est également intéressant de noter que les règles de contrôle de compte d’utilisateur ne s’appliquent pas à services Microsoft. Le manifeste peut être incorporé ou externe.
Pour créer un manifeste, créez un fichier portant le nom <nom de l’application _ # C1.exe. manifest et stockez-le dans le même répertoire que l’exécutable. Notez que tout manifeste externe est ignoré si l’application a un manifeste interne. Par exemple :
<requestedExecutionLevel Level = "" asInvoker | highestAvailable | requireAdministrator "" UIAccess = "" true | false ""/>

9.2 Your app s main process must be run as a standard user (asInvoker).
Toutes les fonctionnalités d’administration doivent être déplacées dans un processus distinct qui s’exécute avec des privilèges d’administrateur. Les applications accessibles à l’utilisateur, telles que celles qui sont accessibles par le biais du groupe de programmes dans le menu Démarrer, et qui requièrent une élévation doivent être signées avec Authenticode.
9.3 Exceptions and Waivers
Une dérogation 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é en tant que point d’entrée de l’utilisateur dans l’application. Les dérogations seront prises en compte pour les scénarios suivants :
  • Outils d’administration ou système dont le niveau d’exécution est défini sur highestAvailable et/ou requireAdministrator
  • Seule l’application d’accessibilité ou d’UI Automation Framework affecte la valeur true à l’indicateur uiAccess pour ignorer l’isolation des privilèges de l’interface utilisateur (UIPI). Pour démarrer correctement l’utilisation de l’application, cet indicateur doit être signé avec Authenticode et doit résider dans un emplacement protégé dans le système de fichiers, à savoir les fichiers programme.

10. les applications doivent être installées par défaut 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 de l’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 d’un autre utilisateur. 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 par défaut dans le dossier Program Files
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.

10.2 Your app must avoid starting automatically on startup
Par exemple, votre application ne doit pas définir les éléments suivants :
  • 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 AllPrograms > démarrage
10.3 Your app data, which must be shared among users on the computer, should be stored within ProgramData 10.4 Your app s data that is exclusive to a specific user and that is not to be shared with other users of the computer, must be stored in Users\\<username>\\AppData 10.5 Your app must never write directly to the "Windows" directory and or subdirectories
Utilisez les méthodes appropriées pour installer des fichiers, tels que des polices ou des pilotes.
10.6 Your app must write user data at first run and not during the installation in per-machine installations
Lorsque l’application est installée, il n’existe pas d’emplacement utilisateur correct dans lequel stocker les 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 sur un niveau par utilisateur, ce qui empêche plusieurs utilisateurs de remplacer les valeurs par défaut des autres.
10.7 Exceptions and Waivers
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

Windows utilisateurs doivent être en mesure d’exécuter des sessions simultanées sans conflit ou perturbation.

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 une confidentialité et des préférences de l’utilisateur doivent être isolées dans la session 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.

11.5 Apps that are installed for multiple users must store data in the correct folder(s) and registry locations
Reportez-vous aux exigences de contrôle de compte d’utilisateur.
11.6 User apps must be able to run in multiple user sessions (Fast User Switching) for both local and remote access 11.7 Your app must check other terminal service (TS) sessions for existing instances of the app
Remarque : si une application ne prend pas en charge plusieurs sessions utilisateur ou accès à distance, elle doit clairement l’indiquer lorsqu’elle est lancée à partir de ce type de session.

12. les applications doivent prendre en charge les versions x64 de Windows

Étant donné que le matériel 64 bits devient plus courant, les utilisateurs attendent des développeurs d’applications qu’ils 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 correctement 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 assurer 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 ne s’appuient sur aucun composant 16 bits
12,3 l’installation de votre application doit détecter et installer les pilotes et les composants appropriés pour l’architecture 64 bits
12,4 tous les plug-ins de Shell doivent s’exécuter sur les versions 64 bits de Windows
12,5 l’exécution de l’application sous l’émulateur WoW64 ne doit pas tenter de corrompre 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.

Conclusion

À mesure que ces exigences évoluent, nous allons noter les modifications dans l’historique des révisions ci-dessous. Les exigences stables sont essentielles pour effectuer votre travail. nous allons donc veiller à ce que les modifications que nous faisons soient durables et continuent à protéger et à améliorer vos applications.

Merci encore d’avoir participé à 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 version préliminaire.
26 janvier, 2012 1.1 Mise à jour de la section # 2. 1.1
31 mai 2012 1.2 Ajout de résultats de test de synthèse 1.2
29 juin, 2012 3,0 Windows 8 document final 3.0
18 juin, 2013 3.1 document Windows 8.1 3.1

En savoir plus sur la certification des applications de bureau

Condition requise Description Détails supplémentaires
Compatibilité et résilience Les incidents & les blocages sont une interruption majeure des utilisateurs et une certaine frustration. Les applications sont censées être résilientes et stables, ce qui permet de s’assurer que les logiciels sont plus prévisibles, gérables, performants et dignes de confiance.
Le point d’entrée de l’application accessible par l’utilisateur doit être manifeste pour la compatibilité, ainsi que pour la déclaration du bon GUID.
Les points d’entrée de l’application orientée utilisateur doivent se manifester pour une reconnaissance haute résolution et les API appropriées sont appelées pour prendre en charge la haute résolution.
systèmes d’exploitation Windows Vista, Windows 7 et Windows 8
Application Verifier
DLL AppInit
Manifeste de l’application (exécutable)
Écriture d’applications Win32 haute résolution
respectez les meilleures pratiques en matière de Sécurité Windows l’utilisation des meilleures pratiques de sécurité de Windows permet d’éviter la création d’expositions à des surfaces d’attaque Windows. Les surfaces d’attaque sont les points d’entrée qu’un attaquant malveillants pourrait utiliser pour exploiter le système d’exploitation en tirant parti des vulnérabilités dans le logiciel cible. L’élévation de privilèges constitue l’une des pires failles de sécurité. Analyseur de surface d’attaque
Listes de contrôle d’accès
fonctionnalités de Sécurité Windows de Support 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. Des applications mal compilées peuvent entraîner des dépassements de mémoire tampon qui, à leur tour, peuvent provoquer un déni de service ou rendre du code malveillant s’exécuter. Référence de l’outil BinScope
Adhérer aux messages du gestionnaire de redémarrage du système Lorsque les utilisateurs initient un arrêt, dans la grande majorité des cas, ils ont un souhait fort de voir la tentative d’arrêt. ils peuvent être impressés de fermer le bureau et de « simplement veux » que leurs ordinateurs s’éteignent. Les applications doivent respecter ce souhait en ne bloquant pas l’arrêt. Dans la plupart des cas, un arrêt peut ne pas être critique, les applications doivent être préparées pour la possibilité d’un arrêt critique. modifications de l’arrêt de l’Application dans Windows Vista
Développement du gestionnaire de redémarrage
Installation de nettoyage réversible Une installation propre et réversible permet aux utilisateurs de gérer avec succès (déployer et supprimer) des applications sur leurs systèmes. procédure : installer les composants 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 du code malveillant a modifié un fichier binaire système. Génère également un événement de diagnostic et de journal 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 pas bloquer l’installation ou le lancement d’applications en fonction de la vérification de la version du système d’exploitation Il est important que les clients ne soient pas bloqués de façon artificielle contre l’installation ou l’exécution de 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 devraient pas avoir de raison de vérifier la version du système d’exploitation. Contrôle de version du système d’exploitation
ne pas charger les Services et pilotes en Mode Coffre Coffre mode 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é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 configurés 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 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 Coffre
Suivre les instructions relatives au contrôle de compte d’utilisateur (UAC) certaines Windows application s’exécutent dans le contexte de sécurité d’un compte d’administrateur, et de nombreuses nécessitent des droits d’utilisateur et des privilèges de 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 stealthily qui prend la machine ou une action de personnes disposant de privilèges limités, par exemple, un employé qui installe un logiciel interdit sur un ordinateur professionnel). La règle la plus importante pour contrôler l’accès aux ressources consiste à fournir le contexte utilisateur standard d’accès minimal nécessaire à l’utilisateur pour effectuer ses tâches nécessaires. Les instructions de contrôle de compte d’utilisateur suivantes fournissent aux applications 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 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 de l’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 d’un autre utilisateur. Résumé de la configuration requise pour l’installation/la désinstallation
Prendre en charge les sessions multi-utilisateurs Windows utilisateurs doivent être en mesure d’exécuter des sessions simultanées sans conflit ou perturbation. Instructions de programmation Services Bureau à distance
Prendre en charge les versions x64 de Windows Étant donné que le matériel 64 bits devient plus répandu, les utilisateurs attendent des développeurs d’applications qu’ils 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 correctement sous les versions 64 bits de Windows. compatibilité des applications : Windows Vista 64 bits

Voir aussi