Archiv: Zertifizierungsanforderungen für Windows Desktop Apps v3.1
Dokumentversion: 3.1
Dokumentdatum: 18. Juni 2013
Dieses Dokument enthält die technischen Anforderungen und Voraussetzungen, die eine Desktop-App erfüllen muss, um am Zertifizierungsprogramm für Windows 8.1 Desktop-App teilzunehmen. Für Windows 7 wurde dieses Programm als Windows-Softwarelogo-Programm bezeichnet.
Willkommen!
Die Windows-Plattform unterstützt ein breites Ökosystem von Produkten und Partnern. Das Anzeigen des Windows-Logos auf Ihrem Produkt stellt eine Beziehung und eine gemeinsame Verpflichtung zur Qualität zwischen Microsoft und Ihrem Unternehmen dar. Kunden vertrauen der Windows-Marke auf Ihrem Produkt, weil sie sicherstellt, dass es Kompatibilitätsstandards erfüllt und auf der Windows-Plattform gut funktioniert. Das erfolgreiche Bestehen der Windows-App-Zertifizierung ermöglicht es, Ihre App im Windows Compatibility Center zu präsentieren, und es ist auch ein notwendiger Schritt, um eine Desktop-App-Referenz im Windows Store aufzulisten.
Das Zertifizierungsprogramm für Windows-Apps besteht aus programmbezogenen und technischen Anforderungen, um sicherzustellen, dass Apps von Drittanbietern, die die Windows-Marke tragen, sowohl einfach zu installieren als auch zuverlässig auf PCs mit Windows sind. Kunden schätzen Stabilität, Kompatibilität, Zuverlässigkeit, Leistung und Qualität in den von ihnen erworbenen Systemen. Microsoft konzentriert sich auf seine Investitionen, um diese Anforderungen für Software-Apps zu erfüllen, die für die Ausführung auf der Windows-Plattform für PCs entwickelt wurden. Diese Bemühungen umfassen Kompatibilitätstests für Konsistenz, verbesserte Leistung und erhöhte Sicherheit auf PCs, auf denen Windows-Software ausgeführt wird. Microsoft-Kompatibilitätstests wurden in Zusammenarbeit mit Branchenpartnern entwickelt und werden kontinuierlich verbessert, um den Branchenentwicklungen und der Nachfrage der Verbraucher gerecht zu werden.
Das Zertifizierungskit für Windows-Apps wird verwendet, um die Konformität mit diesen Anforderungen zu überprüfen, und ersetzt die WSLK, die für die Validierung im Windows 7-Softwarelogoprogramm verwendet wird. Das Zertifizierungskit für Windows-Apps ist eine der Komponenten, die im Windows Software Development Kit (SDK) für Windows 8.1 enthalten sind.
App-Berechtigung
Damit sich eine App für Windows 8.1 Desktop-App-Zertifizierung qualifizieren kann, muss sie die folgenden Kriterien und alle technischen Anforderungen erfüllen, die in diesem Dokument aufgeführt sind.
- Es muss sich um eine eigenständige App
- Sie muss auf einem lokalen Windows 8.1 Computer ausgeführt werden.
- Dies kann eine Clientkomponente einer zertifizierten Windows Server-App sein.
- Es muss code- und featurevollständig sein.
- Die Kommunikation mit Windows Store-Apps darf nicht über lokale Mechanismen erfolgen, einschließlich Dateien und Registrierungsschlüsseln.
- Sie darf die Sicherheit oder Funktionalität des Windows-Systems nicht gefährden oder gefährden.
- Es muss einen eindeutigen Namen haben und darf nicht von anderen Marken geschützt werden.
Wenn die Desktop-App an die Kategorie Antiviren- und/oder Anti-Spyware-Produkte (d. h. Antischadsoftware) übermittelt wird, muss sie den RICHTLINIEN FÜR DIE ANTIMALWARE-PLATTFORM entsprechen. Der LIZENZVERTRAG für die WINDOWS 8-ANTIMALWARE-API muss vor der Übermittlung signiert und wirksam sein. Der Partner muss Mitglied oder Forscher sein, die Mitglieder einer der organisationen sind, die in der Vereinbarung aufgeführt sind und sich in gutem Rang befinden. Die Funktionalität muss auf Windows 8 von einer der in der Vereinbarung aufgeführten Organisationen zertifiziert werden. Die App muss in den letzten 12 Monaten mindestens einmal getestet und für die Erkennung und Reinigung zertifiziert sein.
1. Apps sind kompatibel und resilient
Die Zeiten, in denen eine App abstürzt oder nicht mehr reagiert, führen zu einer erheblichen Frustration der Benutzer. Es wird erwartet, dass Apps resilient und stabil sind, und die Beseitigung solcher Fehler trägt dazu bei, dass Software besser vorhersagbar, verwaltbar, leistungsfähig und vertrauenswürdiger ist.
- 1.1 Ihre App darf keine Abhängigkeit von Windows-Kompatibilitätsmodi, AppHelp-Nachrichten und anderen Kompatibilitätskorrekturen aufweisen.
1.2 Ihre App muss über ein Kompatibilitätsmanifest verfügen und die entsprechenden GUIDs für die unterstützten Versionen von Windows verwenden.
1.3 Ihre App muss DPI-fähig sein, indem sie das Assemblymanifest der Anwendung verwendet, anstatt SetProcessDPIAware aufzurufen.
1.4 Ihre App darf keine Abhängigkeit von der VB6-Runtime annehmen.
1.5 Ihre App darf keine beliebigen DLLs laden, um Win32-API-Aufrufe mithilfe von HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dlls abzufangen.
2. Apps müssen den bewährten Windows-Sicherheitsmethoden entsprechen
Die Verwendung bewährter Windows-Sicherheitsmethoden trägt dazu bei, die Gefährdung von Windows-Angriffsflächen zu vermeiden. Angriffsflächen sind die Einstiegspunkte, die ein böswilliger Angreifer nutzen kann, um das Betriebssystem auszunutzen, indem er Sicherheitsrisiken in der Zielsoftware ausnutzt. Eines der größten Sicherheitsrisiken ist die Rechteerweiterung.
- 2.1 Ihre App muss starke und geeignete ACLs verwenden, um ausführbare Dateien zu schützen 2.2 Ihre App muss starke und geeignete ACLs verwenden, um Verzeichnisse zu schützen 2.3 Ihre App muss starke und geeignete ACLs verwenden, um Registrierungsschlüssel zu schützen 2.4 Ihre App muss starke und geeignete ACLs verwenden, um Verzeichnisse zu sichern, die Objekte enthalten 2.5 Ihre App muss den Zugriff von Nichtadministratoren auf Dienste reduzieren, die anfällig für Manipulationen sind 2.6 Ihre App muss Dienste mit schnellem Zugriff verhindern. neustartt mehr als zweimal alle 24 Stunden
Das Zertifizierungsprogramm für Windows-Apps überprüft, ob Windows-Angriffsflächen nicht verfügbar gemacht werden, indem überprüft wird, ob ACLs und Dienste auf eine Weise implementiert sind, die das Windows-System nicht gefährdet.
3. Apps unterstützen Windows-Sicherheitsfeatures
Das Windows-Betriebssystem verfügt über viele Features, die Systemsicherheit und Datenschutz unterstützen. Apps müssen diese Features unterstützen, um die Integrität des Betriebssystems aufrechtzuerhalten. Nicht ordnungsgemäß kompilierte Apps können Pufferüberläufe verursachen, die wiederum zu Denial-of-Service führen oder schädlichen Code ausführen lassen können.
- 3.1 Ihre App darf AllowPartiallyTrustedCallersAttribute (APTCA) nicht verwenden, um den sicheren Zugriff auf Assemblys mit starkem Namen sicherzustellen.
3.2 Ihre App muss mit dem /SafeSEH-Flag kompiliert werden, um eine sichere Ausnahmebehandlung sicherzustellen.
3.3 Ihre App muss mit dem Flag /NXCOMPAT kompiliert werden, um die Datenausführung zu verhindern.
3.4 Ihre App muss mithilfe des Flags /DYNAMICBASE für die Zufällige Layout randomisierung des Adressraums (ASLR) kompiliert werden.
3.5 Ihre App darf die freigegebenen PE-Abschnitte nicht lesen/schreiben.
4. Apps müssen den Meldungen des Systemneustart-Managers entsprechen.
Wenn Benutzer das Herunterfahren initiieren, haben sie in der Regel den starken Wunsch, dass das Herunterfahren erfolgreich ist. Sie können es eilig haben, das Büro zu verlassen, und möchten nur, dass ihre Computer ausgeschaltet werden. Apps müssen diesen Wunsch respektieren, indem sie das Herunterfahren nicht blockieren. Während in den meisten Fällen ein Herunterfahren nicht kritisch ist, müssen Apps auf die Möglichkeit eines kritischen Herunterfahrens vorbereitet sein.
- 4.1 Ihre App muss kritische Herunterfahren ordnungsgemäß verarbeiten
- Beim kritischen Herunterfahren werden Apps, die FALSE an WM_QUERYENDSESSION zurückgeben, WM_ENDSESSION gesendet und geschlossen, während apps, die als Reaktion auf WM_QUERYENDSESSION ein Timeout ausführen, beendet werden.
- WM\_QUERYENDSESSION mit LPARAM = ENDSESSION\_CLOSEAPP(0x1).
Konsolen-Apps können SetConsoleCtrlHandler aufrufen, um die Funktion anzugeben, die Benachrichtigungen zum Herunterfahren verarbeitet. Dienst-Apps können RegisterServiceCtrlHandlerEx aufrufen, um die Funktion anzugeben, die Benachrichtigungen zum Herunterfahren empfängt.
- WM\_ENDSESSION mit LPARAM = ENDSESSION\_CLOSEAPP(0x1).
Die App sollte mindestens vorbereiten, indem sie alle Benutzerdaten speichert und die informationen angeben, die nach einem Neustart benötigt werden.
Hinweis: Apps, die das Herunterfahren aufgrund eines Vorgangs blockieren müssen, der nicht unterbrochen werden kann, sollten dem Benutzer den Grund erklären. Verwenden Sie ShutdownBlockReasonCreate, um eine Zeichenfolge zu registrieren, die dem Benutzer den Grund erläutert. Wenn der Vorgang abgeschlossen ist, sollte die App ShutdownBlockReasonDestroy aufrufen, um anzugeben, dass das System heruntergefahren werden kann.
5. Apps müssen eine sauber, umkehrbare Installation unterstützen.
Eine sauber, umkehrbare Installation ermöglicht es Benutzern, Apps auf ihren Systemen erfolgreich zu verwalten (bereitstellen und entfernen).
- 5.1 Ihre App muss eine sauber, umkehrbare Installation ordnungsgemäß implementieren.
- DisplayName
- InstallLocation
- Publisher
- UninstallString
- VersionMajor oder MajorVersion
- VersionMinor oder MinorVersion
- Wenn die Installation fehlschlägt, sollte die App in der Lage sein, ein Rollback durchzuführen und den vorherigen Zustand des Computers wiederherzustellen.
- Ein Neustart des Computers sollte nie die einzige Option am Ende einer Installation, Deinstallation oder Aktualisierung sein. Benutzer sollten die Möglichkeit haben, später neu zu starten.
- Windows-Inventurtools und Telemetrietools erfordern vollständige Informationen zu installierten Apps. Wenn Sie ein MSI-basiertes Installationsprogramm verwenden, erstellt MSI automatisch die folgenden Registrierungseinträge. Wenn Sie kein MSI-Installationsprogramm verwenden, muss das Installationsmodul während der Installation die folgenden Registrierungseinträge erstellen:
6. Apps müssen Dateien und Treiber digital signieren
Mit einer digitalen Authenticode-Signatur können Benutzer sicher sein, dass die Software original ist. Es ermöglicht auch zu erkennen, ob eine Datei manipuliert wurde, z. B. ob sie von einem Virus infiziert wurde. Die Erzwingung der Codesignatur im Kernelmodus ist ein Windows-Feature, das als Codeintegrität (CI) bezeichnet wird und die Sicherheit des Betriebssystems verbessert, indem die Integrität einer Datei bei jedem Laden des Images der Datei in den Arbeitsspeicher überprüft wird. CI erkennt, ob böswilliger Code eine Systembinärdatei geändert hat. Generiert außerdem ein Diagnose- und Systemüberwachungsprotokollereignis, wenn die Signatur eines Kernelmoduls nicht ordnungsgemäß überprüft werden kann.
- 6.1 Alle ausführbaren Dateien (.exe, .dll, .ocx, .sys, .cpl, .drv, .scr) müssen mit einem Authenticode-Zertifikat signiert sein.
6.2 Alle von der App installierten Kernelmodustreiber müssen über eine Microsoft-Signatur verfügen, die über das Windows-Hardwarezertifizierungsprogramm abgerufen wurde. Alle Dateisystemfiltertreiber müssen von Microsoft signiert werden.
6.3 Ausnahmen und Verzichtserklärungen
- Verzichtserklärungen werden nur für nicht signierte Verteiler von Drittanbietern berücksichtigt, ausgenommen Treiber. Ein Kommunikationsnachweis, der eine signierte Version der Verteiler anfordert, ist erforderlich, damit dieser Verzicht gewährt wird.
7. Apps blockieren die Installation oder den App-Start nicht basierend auf einer Betriebssystemversionsprüfung.
Es ist wichtig, dass Kunden nicht künstlich daran gehindert werden, ihre App zu installieren oder auszuführen, wenn es keine technischen Einschränkungen gibt. Wenn Apps für Windows Vista oder höhere Versionen von Windows geschrieben wurden, sollten sie die Betriebssystemversion im Allgemeinen nicht überprüfen müssen.
- 7.1 Ihre App darf keine Versionsüberprüfungen auf Gleichheit durchführen
- Apps, die als ein Paket bereitgestellt werden, die auch unter Windows XP, Windows Vista und Windows 7 ausgeführt werden und die Betriebssystemversion überprüfen müssen, um zu ermitteln, welche Komponenten unter einem bestimmten Betriebssystem installiert werden sollen.
- Apps, die nur die Mindestversion des Betriebssystems überprüfen (nur während der Installation, nicht zur Laufzeit), indem sie nur die genehmigten API-Aufrufe verwenden, und die die Mindestversionsanforderung ordnungsgemäß im App-Manifest auflisten.
- Sicherheits-Apps (Antivirus, Firewall usw.), Systemprogramme (z. B. Defragmentierung, Sicherungen und Diagnose Tools), die die Betriebssystemversion überprüfen, indem nur die genehmigten API-Aufrufe verwendet werden.
- Wenn Sie ein bestimmtes Feature benötigen, überprüfen Sie, ob das Feature selbst verfügbar ist. Wenn Sie Windows XP benötigen, suchen Sie nach Windows XP oder höher (>= 5.1). Auf diese Weise funktioniert Ihr Erkennungscode weiterhin in zukünftigen Versionen von Windows. Treiberinstallationsprogramme und Deinstallationsmodule sollten niemals die Betriebssystemversion überprüfen.
8. Apps laden keine Dienste oder Treiber im abgesicherten Modus
Im abgesicherten Modus können Benutzer Windows diagnostizieren und Problembehandlungen durchführen. Treiber und Dienste dürfen nicht auf das Laden im abgesicherten Modus festgelegt werden, es sei denn, sie werden für grundlegende Systemvorgänge wie Speichergerätetreiber oder für Diagnose- und Wiederherstellungszwecke, z. B. Virenscanner, benötigt. Wenn Windows sich im abgesicherten Modus befindet, wird standardmäßig nur die Treiber und Dienste gestartet, die mit Windows vorinstalliert wurden.
- 8.1 Ausnahmen und Verzichtserklärungen
- Treiber und Dienste, die im abgesicherten Modus gestartet werden müssen, erfordern einen Verzicht. Die Verzichtsanforderung muss jeden anwendbaren Treiber oder Dienst enthalten, der in die SafeBoot-Registrierungsschlüssel schreibt, und die technischen Gründe beschreiben, warum die App oder der Dienst im abgesicherten Modus ausgeführt werden muss. Das App-Installationsprogramm muss alle diese Treiber und Dienste mit den folgenden Registrierungsschlüsseln registrieren:
Hinweis: Sie müssen diese Treiber und Dienste testen, um sicherzustellen, dass sie fehlerfrei im abgesicherten Modus funktionieren.
9. Apps müssen die Richtlinien für die Benutzerkontensteuerung befolgen
Einige Windows-Apps werden im Sicherheitskontext eines Administratorkontos ausgeführt, und Apps fordern häufig übermäßige Benutzerrechte und Windows-Rechte an. Durch die Steuerung des Zugriffs auf Ressourcen haben Benutzer die Kontrolle über ihre Systeme und schützen sie vor unerwünschten Änderungen. Eine unerwünschte Änderung kann böswillig sein, z. B. ein Rootkit, das die Kontrolle über den Computer übernimmt, oder das Ergebnis einer Aktion von Personen sein, die über eingeschränkte Berechtigungen verfügen. Die wichtigste Regel zum Steuern des Zugriffs auf Ressourcen besteht darin, den geringsten Zugriff auf den Standardbenutzerkontext bereitzustellen, der für einen Benutzer erforderlich ist, um seine erforderlichen Aufgaben auszuführen. Die Einhaltung der Richtlinien für die Benutzerkontensteuerung (User Account Control, UAC) stellt der App die erforderlichen Berechtigungen bereit, wenn sie von der App benötigt werden, ohne dass das System ständig Sicherheitsrisiken ausgesetzt ist. Die meisten Apps erfordern keine Administratorrechte zur Laufzeit und sollten als Standardbenutzer problemlos ausgeführt werden.
- 9.1 Ihre App muss über ein Manifest verfügen, das Ausführungsebenen definiert und dem Betriebssystem mitteilt, welche Berechtigungen die App zum Ausführen benötigt.
- Verwaltungs- oder Systemtools, deren Ausführungsebene auf "höchste Verfügbar" und/oder "requireAdministrator" festgelegt ist
- Nur die Framework-App für Barrierefreiheit oder Benutzeroberflächenautomatisierung legt das uiAccess-Flag auf true fest, um die Benutzeroberflächenberechtigungsisolation (UIPI) zu umgehen. Um die App-Auslastung ordnungsgemäß zu starten, muss dieses Flag Authenticode signiert sein und muss sich an einem geschützten Speicherort im Dateisystem befinden, nämlich Programme.
- Die App-Manifestmarkierung gilt nur für EXEs, nicht für DLLs. Dies liegt daran, dass UAC dlLs während der Prozesserstellung nicht überprüft. Es ist auch erwähnenswert, dass UAC-Regeln nicht für Microsoft-Dienste gelten. Das Manifest kann eingebettet oder extern sein.
Um ein Manifest zu erstellen, erstellen Sie eine Datei mit dem Namen <app_name>.exe.manifest, und speichern Sie sie im selben Verzeichnis wie die EXE. Beachten Sie, dass jedes externe Manifest ignoriert wird, wenn die App über ein internes Manifest verfügt. Beispiel:
<requestedExecutionLevel level="asInvoker | höchsteVerfügbar | requireAdministrator"" uiAccess=""true|false"/>
- Alle administrativen Features müssen in einen separaten Prozess verschoben werden, der mit Administratorrechten ausgeführt wird. Benutzerbezogene Apps, z. B. apps, auf die über die Programmgruppe im Startmenü zugegriffen werden kann und die die Erhöhung erfordern, müssen Authenticode signiert sein.
- Eine Verzichtserklärung ist für Apps erforderlich, die ihren Standard-Prozess mit erhöhten Rechten ausführen (requireAdministrator oder highestAvailable). Der Standard Prozess wird als Einstiegspunkt des Benutzers zur App identifiziert. Verzichtserklärungen werden für die folgenden Szenarien berücksichtigt:
10. Apps müssen standardmäßig in den richtigen Ordnern installiert werden.
Benutzer sollten über eine konsistente und sichere Erfahrung mit dem Standardinstallationsspeicherort von Dateien verfügen, während die Option beibehalten wird, eine App am Speicherort ihrer Wahl zu installieren. Es ist auch erforderlich, App-Daten am richtigen Speicherort zu speichern, damit mehrere Personen denselben Computer verwenden können, ohne die Daten und Einstellungen des anderen zu beschädigen oder zu überschreiben. Windows stellt bestimmte Speicherorte im Dateisystem bereit, um Programme und Softwarekomponenten, freigegebene App-Daten und benutzerspezifische App-Daten zu speichern.
- 10.1 Ihre App muss standardmäßig im Ordner Programme installiert sein.
- Registrierungsausführungsschlüssel HKLM und oder HKCU unter Software\Microsoft\Windows\CurrentVersion
- Registrierungsausführungsschlüssel HKLM und oder HKCU unter Software\Wow6432Node\Microsoft\windows\CurrentVersion
- Startmenü AllProgrammstart >
- Für native 32-Bit- und 64-Bit-Apps in %ProgramFiles% und %ProgramFiles(x86)% für 32-Bit-Apps, die unter x64 ausgeführt werden. Benutzerdaten oder App-Daten dürfen aufgrund der für diesen Ordner konfigurierten Sicherheitsberechtigungen nie an diesem Speicherort gespeichert werden.
- Beispielsweise sollte Ihre App keine der folgenden Optionen festlegen:
- Verwenden Sie die richtigen Methoden zum Installieren von Dateien, z. B. Schriftarten oder Treiber.
- Wenn die App installiert ist, gibt es keinen richtigen Benutzerspeicherort, an dem Daten gespeichert werden sollen. Versuche einer App, das Standardzuordnungsverhalten auf Computerebene nach der Installation zu ändern, sind nicht erfolgreich. Stattdessen müssen Standardwerte auf Benutzerebene beansprucht werden, was verhindert, dass mehrere Benutzer die Standardwerte des anderen überschreiben.
- Für Apps, die in den globalen Assemblycache (GAC) schreiben, ist eine Verzichtserklärung erforderlich.NET-Apps sollten Assemblyabhängigkeiten privat halten und im App-Verzeichnis speichern, es sei denn, die Freigabe einer Assembly ist explizit erforderlich.
11. Apps müssen Sitzungen mit mehreren Benutzern unterstützen
Windows-Benutzer sollten in der Lage sein, gleichzeitige Sitzungen ohne Konflikte oder Unterbrechungen auszuführen.
- 11.1 Ihre App muss sicherstellen, dass die normale Funktionalität der App bei der Ausführung in mehreren Sitzungen entweder lokal oder remote nicht beeinträchtigt wird.
11.2 Einstellungen und Datendateien Ihrer App dürfen nicht benutzerübergreifend beibehalten werden.
11.3 Datenschutz und Einstellungen eines Benutzers müssen für die Sitzung des Benutzers isoliert werden.
11.4 Ihre App-Instanzen müssen voneinander isoliert sein
- Dies bedeutet, dass Benutzerdaten aus einer instance für einen anderen instance der App nicht sichtbar sind. Sound in einer inaktiven Benutzersitzung sollte in einer aktiven Benutzersitzung nicht gehört werden. In Fällen, in denen mehrere App-Instanzen freigegebene Ressourcen verwenden, muss die App sicherstellen, dass es keinen Konflikt gibt.
- Weitere Informationen finden Sie unter UAC-Anforderungen.
12. Apps müssen x64-Versionen von Windows unterstützen.
Da 64-Bit-Hardware immer häufiger wird, erwarten Benutzer, dass App-Entwickler die Vorteile der 64-Bit-Architektur nutzen, indem sie ihre Apps zu 64-Bit migrieren, oder dass 32-Bit-Versionen der App unter 64-Bit-Versionen von Windows gut ausgeführt werden.
- 12.1 Ihre App muss nativ 64-Bit- oder mindestens 32-Bit-Windows-basierte Apps auf 64-Bit-Systemen unterstützen, um die Kompatibilität mit 64-Bit-Versionen von Windows zu gewährleisten.
12.2 Ihre App und ihre Installationsprogramme dürfen keinen 16-Bit-Code enthalten oder sich auf eine 16-Bit-Komponente verlassen.
12.3 Ihr App-Setup muss die richtigen Treiber und Komponenten für die 64-Bit-Architektur erkennen und installieren.
12.4 Alle Shell-Plug-Ins müssen unter 64-Bit-Versionen von Windows ausgeführt werden
12.5 App, die unter dem WoW64-Emulator ausgeführt wird, sollte nicht versuchen, Wow64-Virtualisierungsmechanismen zu unterlaufen oder zu umgehen.
- Wenn es bestimmte Szenarien gibt, in denen Apps erkennen müssen, ob sie unter dem WoW64-Emulator ausgeführt werden, sollten sie dies tun, indem sie IsWow64Process aufrufen.
Zusammenfassung
Wenn sich diese Anforderungen weiterentwickeln, werden wir die Änderungen im Folgenden im Revisionsverlauf notieren. Stabile Anforderungen sind von entscheidender Bedeutung für Ihre beste Arbeit. Daher werden wir sicherstellen, dass die Von uns vorgenommenen Änderungen nachhaltig sind und Ihre Apps weiterhin schützen und verbessern.
Nochmals vielen Dank, dass Sie sich an unserem Engagement für eine hervorragende Kundenerfahrung beteiligt haben.
Revisionsverlauf
| Date | Version | Revisionsbeschreibung | Link zum Dokument |
|---|---|---|---|
| 20. Dezember 2011 | 1.0 | Anfänglicher Dokumententwurf für die Vorschauversion. | |
| 26. Januar 2012 | 1.1 | Aktualisieren Sie auf Abschnitt 2. | 1.1 |
| 31. Mai 2012 | 1.2 | Zusammenfassungstestergebnisse hinzugefügt | 1.2 |
| 29. Juni 2012 | 3.0 | Windows 8 Abschlussdokument | 3.0 |
| 18. Juni 2013 | 3.1 | Windows 8.1 Dokument | 3.1 |
Weitere Informationen zur Zertifizierung von Desktop-Apps
| Anforderung | BESCHREIBUNG | Weitere Informationen |
|---|---|---|
| Kompatibilität und Resilienz | & Abstürze, die hängen bleiben, sind eine große Störung für die Benutzer und verursachen Frustration. Es wird erwartet, dass Apps resilient und stabil sind. Dadurch wird sichergestellt, dass Software besser vorhersagbar, verwaltbar, leistungsfähig und vertrauenswürdiger ist. Der Einstiegspunkt für die benutzerseitige App muss aus Gründen der Kompatibilität manifestiert werden und die richtige GUID deklariert werden. Benutzerseitige App-Einstiegspunkte müssen manifestiert werden, um HIGH-DPI-Erkennung zu ermöglichen und dass die richtigen APIs aufgerufen werden, um HIGH-DPI zu unterstützen. |
Windows Vista, Windows 7 und Windows 8 Betriebssysteme Application Verifier AppInit-DLLs App-Manifest (ausführbare Datei) Schreiben von Win32-Anwendungen mit hohem DPI-Wert |
| Befolgen Windows-Sicherheit bewährten Methoden | Die Verwendung bewährter Windows-Sicherheitsmethoden trägt dazu bei, die Gefährdung von Windows-Angriffsflächen zu vermeiden. Angriffsflächen sind die Einstiegspunkte, die ein böswilliger Angreifer nutzen kann, um das Betriebssystem auszunutzen, indem er Sicherheitsrisiken in der Zielsoftware ausnutzt. Eines der größten Sicherheitsrisiken ist die Rechteerweiterung. | Attack Surface Analyzer Zugriffssteuerungslisten |
| Unterstützung Windows-Sicherheit Features | Das Windows-Betriebssystem hat viele Maßnahmen zur Unterstützung der Systemsicherheit und des Datenschutzes implementiert. Anwendungen müssen diese Measures unterstützen, um die Integrität des Betriebssystems aufrechtzuerhalten. Nicht ordnungsgemäß kompilierte Anwendungen können Pufferüberläufe verursachen, die wiederum zu Denial-of-Service führen oder schädlichen Code ausführen können. | Referenz zum BinScope-Tool |
| Befolgen von Systemneustart-Manager-Meldungen | Wenn Benutzer das Herunterfahren initiieren, haben sie in den meisten Fällen den starken Wunsch, dass das Herunterfahren erfolgreich ist; Sie können es eilig haben, das Büro zu verlassen und "nur wollen", dass ihre Computer ausgeschaltet werden. Apps müssen diesen Wunsch respektieren, indem sie das Herunterfahren nicht blockieren. Während in den meisten Fällen ein Herunterfahren nicht kritisch ist, müssen Apps auf die Möglichkeit eines kritischen Herunterfahrens vorbereitet sein. | Änderungen beim Herunterfahren von Anwendungen in Windows Vista Neustarten der Manager-Entwicklung |
| Saubere umkehrbare Installation | Eine sauber, umkehrbare Installation ermöglicht es Benutzern, Apps auf ihren Systemen erfolgreich zu verwalten (bereitstellen und entfernen). | Gewusst wie: Installieren von erforderlichen Komponenten mit einer ClickOnce-Anwendung Anwendungsinstallation auf 64-Bit-Systemen |
| Digitales Signieren von Dateien und Treibern | Mit einer digitalen Authenticode-Signatur können Benutzer sicher sein, dass die Software original ist. Es ermöglicht auch zu erkennen, ob eine Datei manipuliert wurde, z. B. wenn sie von einem Virus infiziert wurde. Die Erzwingung der Codesignatur im Kernelmodus ist ein Windows-Feature, das als Codeintegrität (CI) bezeichnet wird und die Sicherheit des Betriebssystems verbessert, indem die Integrität einer Datei bei jedem Laden des Images der Datei in den Arbeitsspeicher überprüft wird. CI erkennt, ob böswilliger Code eine Systembinärdatei geändert hat. Generiert außerdem ein Diagnose- und Systemüberwachungsprotokollereignis, wenn die Signatur eines Kernelmoduls nicht ordnungsgemäß überprüft werden kann. | Digitale Signaturen für Kernelmodule unter Windows |
| Installation oder App-Start nicht basierend auf der Überprüfung der Betriebssystemversion blockieren | Es ist wichtig, dass Kunden nicht künstlich daran gehindert werden, ihre App zu installieren oder auszuführen, wenn es keine technischen Einschränkungen gibt. Wenn Apps für Windows Vista oder höhere Versionen geschrieben wurden, sollten sie im Allgemeinen keinen Grund haben, die Betriebssystemversion zu überprüfen. | Betriebssystemversionsverwaltung |
| Dienste und Treiber nicht im abgesicherten Modus laden | Im abgesicherten Modus können Benutzer Windows diagnostizieren und behandeln. Es sei denn, dies ist für grundlegende Vorgänge des Systems (z. B. Speichergerätetreiber) oder für Diagnose- und Wiederherstellungszwecke (z. B. Virenscanner) erforderlich, dürfen Treiber und Dienste nicht auf das Laden im abgesicherten Modus festgelegt werden. Standardmäßig startet der abgesicherte Modus die meisten Treiber und Dienste nicht, die nicht mit Windows vorinstalliert waren. Sie sollten deaktiviert bleiben, es sei denn, das System erfordert sie für grundlegende Vorgänge oder für Diagnose- und Wiederherstellungszwecke. | Bestimmen, ob das Betriebssystem im abgesicherten Modus ausgeführt wird |
| Befolgen der Richtlinien für die Benutzerkontensteuerung (UAC) | Einige Windows-Apps werden im Sicherheitskontext eines Administratorkontos ausgeführt, und viele erfordern übermäßige Benutzerrechte und Windows-Berechtigungen. Die Steuerung des Zugriffs auf Ressourcen ermöglicht es Benutzern, die Kontrolle über ihre Systeme gegen unerwünschte Änderungen zu haben (eine unerwünschte Änderung kann bösartig sein, z. B. ein Rootkit, das den Computer heimlich übernimmt, oder eine Aktion von Personen, die eingeschränkte Berechtigungen haben, z. B. ein Mitarbeiter, der verbotene Software auf einem Arbeitscomputer installiert). Die wichtigste Regel für die Steuerung des Zugriffs auf Ressourcen ist die Bereitstellung des geringsten Zugriffsstandardbenutzerkontexts, der für einen Benutzer erforderlich ist, um seine erforderlichen Aufgaben auszuführen. Die Einhaltung der UAC-Richtlinien stellt der App bei Bedarf die erforderlichen Berechtigungen bereit, ohne das System ständig Sicherheitsrisiken ausgesetzt zu lassen. | Benutzerkontensteuerung UAC: Richtlinien für Anwendungsupdates |
| Standardmäßige Installation in den richtigen Ordnern | Benutzer sollten über eine konsistente und sichere Erfahrung mit dem Standardinstallationsspeicherort von Dateien verfügen, während die Option beibehalten wird, eine App an dem von ihnen gewählten Speicherort zu installieren. Es ist auch notwendig, App-Daten am richtigen Ort zu speichern, damit mehrere Personen denselben Computer verwenden können, ohne die Daten und Einstellungen der anderen zu beschädigen oder zu überschreiben. | Zusammenfassung der Installations-/Deinstallationsanforderungen |
| Unterstützung von Sitzungen mit mehreren Benutzern | Windows-Benutzer sollten in der Lage sein, gleichzeitige Sitzungen ohne Konflikte oder Unterbrechungen auszuführen. | Programmierrichtlinien für Remotedesktopdienste |
| Unterstützung von x64-Versionen von Windows | Da 64-Bit-Hardware immer weiter verbreitet wird, erwarten Benutzer, dass App-Entwickler die Vorteile der 64-Bit-Architektur nutzen, indem sie ihre Apps zu 64-Bit migrieren, oder dass 32-Bit-Versionen der App gut unter 64-Bit-Versionen von Windows ausgeführt werden. | Anwendungskompatibilität: Windows Vista 64-Bit |
Siehe auch
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für