Zertifizierungsanforderungen für Windows-Desktop-Apps
Dokumentversion: 10
Dokumentdatum: 29. Juli 2015
Dieses Dokument enthält die technischen Anforderungen und Voraussetzungen, die eine Desktop-App erfüllen muss, um am Zertifizierungsprogramm für Windows 10 Desktop-App teilzunehmen.
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, Dass Ihre App im Windows Compatibility Center präsentiert wird, und Sie können das Zertifizierungslogo auf Ihrer Website anzeigen.
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 alle früheren Versionen des Kits, die für die Überprüfung unter Windows 7, Windows 8 oder Windows 8.1 verwendet wurden. Das Zertifizierungskit für Windows-Apps ist eine der Komponenten, die im Windows Software Development Kit (SDK) für Windows 10 enthalten sind.
App-Berechtigung
Damit eine App für Windows 10 Desktop-App-Zertifizierung qualifiziert ist, muss sie die folgenden Kriterien und alle in diesem Dokument aufgeführten technischen Anforderungen erfüllen.
- Es muss sich um eine eigenständige App
- Es muss auf einem lokalen Windows 10 PC ausgeführt werden.
- Dies kann eine Clientkomponente einer zertifizierten Windows Server-App sein.
- Es muss code- und featurevollständig sein.
- Es darf nicht mit Windows Store-Apps über lokale Mechanismen kommunizieren, einschließlich Dateien und Registrierungsschlüsseln, außer in den unterstützten Unternehmensszenarien.
- 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.
- Alle externen Komponenten müssen separat zertifiziert werden oder mit dem Zertifizierungskit für Windows-Apps konform sein.
- Es muss über eine Deaktivierungsoption für alle gebündelten Apps verfügen.
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. Die LIZENZ- UND AUFLISTUNGSVEREINBARUNG FÜR DIE WINDOWS 10 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 für Windows 10 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.
Beachten Sie, dass die Tests 2.1 2.6 nur für Desktop-Apps gelten, die unter Windows 7, Windows 8 oder Windows 8.1 getestet wurden.
- 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 schützen, 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 verhindern, dass Dienste mit schnellen Neustarts mehr als zweimal alle 24 Stunden neu gestartet werden.
Hinweis: Der Zugriff sollte nur für die Entitäten gewährt werden, die ihn benötigen.
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.
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, mit Ausnahme von Treibern. 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 7, Windows 8 und Windows 8.1 ausgeführt werden, und müssen die Betriebssystemversion überprüfen, um zu ermitteln, welche Komponenten auf einem bestimmten Betriebssystem installiert werden sollen.
- Apps, die nur die Mindestversion des Betriebssystems (nur während der Installation, nicht zur Laufzeit) überprüfen, indem sie nur die genehmigten API-Aufrufe verwenden, und die die Mindestversionsanforderung im App-Manifest ordnungsgemäß auflisten.
- Sicherheits-Apps (Antivirus, Firewall usw.), Systemhilfsprogramme (z. B. Defragmentierung, Sicherungen und Diagnose Tools), die die Betriebssystemversion nur mithilfe der genehmigten API-Aufrufe überprüfen.
- Wenn Sie ein bestimmtes Feature benötigen, überprüfen Sie, ob das Feature selbst verfügbar ist. Wenn Sie Windows 7 benötigen, suchen Sie nach Windows 7 oder höher (>= 6.2). Auf diese Weise funktioniert Ihr Erkennungscode auch in zukünftigen Versionen von Windows. Treiberinstallations- 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 behandeln. 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 wie Virenscanner benötigt. Wenn Windows sich im abgesicherten Modus befindet, werden standardmäßig nur die Treiber und Dienste gestartet, die mit Windows vorinstalliert sind.
- 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 geschrieben wird, und die technischen Gründe beschreiben, warum die App oder der Dienst im abgesicherten Modus ausgeführt werden muss. Das App-Installationsprogramm muss alle 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 den Richtlinien für die Benutzerkontensteuerung folgen
Einige Windows-Apps werden im Sicherheitskontext eines Administratorkontos ausgeführt, und Apps fordern häufig übermäßige Benutzerrechte und Windows-Berechtigungen 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 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 Richtlinien für die Benutzerkontensteuerung (User Account Control, UAC) stellen einer App die erforderlichen Berechtigungen bereit, wenn sie von der App benötigt werden, ohne das System ständig Sicherheitsrisiken ausgesetzt zu lassen. Die meisten Apps erfordern zur Laufzeit keine Administratorrechte 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 "highestAvailable" 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 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 während der Prozesserstellung keine DLLs überprüft. Beachten Sie auch, dass UAC-Regeln nicht für Microsoft-Dienste gelten. Das Manifest kann entweder 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 | highestAvailable | requireAdministrator"" uiAccess=""true|false""/>
- Alle administrativen Features müssen in einen separaten Prozess verschoben werden, der mit Administratorrechten ausgeführt wird. Benutzerseitige Apps, z. B. apps, auf die über die Programmgruppe im Startmenü zugegriffen werden kann, und die Rechteerweiterung erfordern, müssen Authenticode signiert sein.
- Eine Ausnahme ist für Apps erforderlich, die ihren Standard-Prozess mit erhöhten Berechtigungen 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 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. Windows stellt bestimmte Speicherorte im Dateisystem zum Speichern von Programmen und Softwarekomponenten, freigegebenen App-Daten und Benutzerspezifischen App-Daten bereit.
- 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ü AlleProgramme > STARTUP
- 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 niemals 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 benutzerspezifischer Ebene beansprucht werden, wodurch verhindert wird, dass mehrere Benutzer die Standardwerte des anderen überschreiben.
- Für Apps, die in den globalen Assemblycache (GAC) schreiben, müssen .NET-Apps 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 bei der Ausführung in mehreren Sitzungen entweder lokal oder remote die normale Funktionalität der App 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 auf die Sitzung des Benutzers isoliert werden.
11.4 Ihre App-Instanzen müssen voneinander isoliert sein.
- Dies bedeutet, dass Benutzerdaten aus einem instance für eine andere instance der App nicht sichtbar sind. Der 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 kein Konflikt vorliegt.
- Weitere Informationen finden Sie in den 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 gut unter 64-Bit-Versionen von Windows 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 aufrechtzuerhalten.
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 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 dazu IsWow64Process aufrufen.
Zusammenfassung
Wenn sich diese Anforderungen weiterentwickeln, werden wir die Änderungen im Revisionsverlauf unten beachten. Stabile Anforderungen sind von entscheidender Bedeutung, um Ihre beste Arbeit zu leisten, daher werden wir sicherstellen, dass die von uns vorgenommenen Änderungen nachhaltig sind und Ihre Apps weiterhin schützen und verbessern.
Vielen Dank, dass Sie sich an unserem Engagement für die Bereitstellung großartiger Kundenerlebnisse 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 |
| 20. Februar 2014 | 3.2 | Internes Update | |
| 18. März 2014 | 3.3 | Windows 8.1 Update 1 | 3.3 |
| 29. Juli 2015 | 10 | Windows 10 Update | 10 |
Weitere Informationen zur Zertifizierung von Desktop-Apps
| Anforderung | BESCHREIBUNG |
| Kompatibilität und Resilienz | Abstürze & Hängen stellen eine große Störung für die Benutzer dar 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. Weitere Informationen finden Sie unter: |
| 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. Weitere Informationen finden Sie unter: |
| 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. Weitere Informationen finden Sie in der 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. |
| Saubere umkehrbare Installation | Eine sauber, umkehrbare Installation ermöglicht es Benutzern, Apps auf ihren Systemen erfolgreich zu verwalten (bereitstellen und entfernen). Weitere Informationen finden Sie unter Vorgehensweise: Installieren der erforderlichen Komponenten mit einer ClickOnce-Anwendung. |
| 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. |
| 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. Weitere Informationen finden Sie unter 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. Weitere Informationen finden Sie unter: |
| 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. Weitere Informationen finden Sie unter: |
| 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. Weitere Informationen finden Sie unter 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. Weitere Informationen finden Sie unter Programmierrichtlinien für Remotedesktopdienste. |
| Unterstützung von x64-Versionen von Windows | Da 64-Bit-Hardware immer häufiger auftritt, 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. |
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