Archiv: Zertifizierungsanforderungen für Windows Desktop-Apps v3.0

Dokumentversion: 3.0

Dokumentdatum: 29. Juni 2012

Dieses Dokument enthält die technischen Anforderungen und Qualifikationsqualifikationen, die eine Desktop-App erfüllen muss, um am Windows 8 Desktop-App-Zertifizierungsprogramm teilnehmen zu können. 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 in Ihrem Produkt stellt eine Beziehung und eine gemeinsame Verpflichtung zur Qualität zwischen Microsoft und Ihrem Unternehmen dar. Kunden vertrauen dem Windows Marke auf Ihrem Produkt, da es sicherstellt, dass es kompatibilitätsstandards erfüllt und auf der Windows-Plattform gut funktioniert. Wenn Sie Windows App-Zertifizierung erfolgreich bestanden haben, kann Ihre App im Windows Compatibility Center vorgestellt werden, und es ist auch ein notwendiger Schritt zum Auflisten eines Desktop-App-Verweises im Windows Store.

Das Windows App-Zertifizierungsprogramm setzt sich aus Programm- und technischen Anforderungen zusammen, um sicherzustellen, dass Drittanbieter-Apps, die die marke Windows tragen, auf PCs, auf denen Windows ausgeführt wird, einfach zu installieren und zuverlässig sind. Kunden legen Wert auf Stabilität, Kompatibilität, Zuverlässigkeit, Leistung und Qualität in den systemen, die sie erwerben. Microsoft konzentriert sich auf seine Investitionen, um diese Anforderungen für Software-Apps zu erfüllen, die auf der Windows-Plattform für PCs ausgeführt werden sollen. Diese Bemühungen umfassen Kompatibilitätstests auf Konsistenz der Benutzererfahrung, 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 als Reaktion auf Branchenentwicklungen und Verbrauchernachfrage kontinuierlich verbessert.

Das Windows App Certification Kit wird verwendet, um die Konformität mit diesen Anforderungen zu überprüfen, und ersetzt den WSLK, der für die Validierung im Softwarelogoprogramm Windows 7 verwendet wird. Das Windows App Certification Kit ist eine der Komponenten, die im Windows Software Development Kit (SDK) für Windows 8 enthalten sind. Es ist auch in Microsoft Visual Studio 2012 Express für Windows 8 integriert.

App-Berechtigung

Damit sich eine App für Windows 8 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
  • Er 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 feature complete sein.

1. Apps sind kompatibel und resilient

Die Zeiten, in denen eine App abstürzt oder nicht mehr reagiert, führen zu einer großen Benutzerverärkung. Es wird erwartet, dass Apps robust und stabil sind, und die Beseitigung solcher Fehler trägt dazu bei, sicherzustellen, dass Software besser vorhersagbar, wartbar, leistungsfähig und vertrauenswürdiger ist.

1.1 Ihre App darf keine Abhängigkeit von Windows Kompatibilitätsmodi, AppHelp-Nachricht und oder anderen Kompatibilitätskorrekturen aufweisen.
1.2 Ihre App darf keine Abhängigkeit von der VB6-Runtime annehmen.
1.3 Ihre App darf keine beliebigen DLLs laden, um Win32-API-Aufrufe mit hklm \ software Microsoft Windows NT \ \ \ CurrentVersion Windows \ AppInit-DLLs _ abzufangen.

2. Apps müssen Windows bewährten Sicherheitsmethoden entsprechen.

Die Verwendung Windows bewährten Sicherheitsmethoden trägt dazu bei, die Gefährdung durch Windows Angriffsflächen zu vermeiden. Angriffsflächen sind die Einstiegspunkte, die ein böswilliger Angreifer verwenden kann, um das Betriebssystem auszunutzen, indem er Sicherheitsrisiken in der Zielsoftware nutzt. Eines der schlechtesten 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 schützen, die Objekte enthalten. 2.5 Ihre App muss den Nichtadministratorzugriff 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: Zugriff sollte nur den Entitäten gewährt werden, die ihn benötigen.**

Das Windows App-Zertifizierungsprogramm überprüft, ob Windows Angriffsflächen nicht verfügbar gemacht werden, indem überprüft wird, ob ACLs und Dienste auf eine Weise implementiert werden, die das Windows System nicht gefährdet.

3. Apps unterstützen Windows Sicherheitsfeatures

Das Windows Betriebssystem verfügt über viele Features, die die Systemsicherheit und den Datenschutz unterstützen. Apps müssen diese Features unterstützen, um die Integrität des Betriebssystems aufrechtzuerhalten. Falsch kompilierte Apps können Pufferüberläufe verursachen, die wiederum Denial-of-Service-Angriffe verursachen oder die Ausführung von schädlichem Code zulassen.

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 die Behandlung sicherer Ausnahmen sicherzustellen.
3.3 Ihre App muss mit dem /NXCOMPAT-Flag kompiliert werden, um die Datenausführung zu verhindern.
3.4 Ihre App muss mit dem /DYNAMICBASE-Flag für die Zufälligisierung des Adressraumlayouts (Address Space Layout Randomization, 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, möchten sie in der Regel, dass das Herunterfahren erfolgreich ist. sie sind möglicherweise in der Lage, das Büro zu verlassen, und möchten nur, dass ihre Computer ausgeschaltet werden. Apps müssen diesen Wunsch berücksichtigen, indem sie das Herunterfahren nicht blockieren. Obwohl das Herunterfahren in den meisten Fällen möglicherweise nicht kritisch ist, müssen Apps auf die Möglichkeit eines kritischen Herunterfahrens vorbereitet werden.

4.1 Ihre App muss kritisches Herunterfahren entsprechend behandeln.
Bei einem kritischen Herunterfahren werden Apps, die FALSE an WM _ QUERYENDSESSION zurückgeben, WM ENDSESSION gesendet _ und geschlossen, während apps, bei denen ein Time out als Reaktion auf WM _ QUERYENDSESSION erfolgt, beendet werden.

4.2 A GUI app must return TRUE immediately in preparation for a restart
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.
4.3 Your app must return 0 within 30 seconds and shut down
WM \_ ENDSESSION with LPARAM = ENDSESSION \_ CLOSEAPP(0x1). Die App sollte sich mindestens vorbereiten, indem sie alle Benutzerdaten speichert und die Informationen angibt, die nach einem Neustart benötigt werden.
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
**Note: Apps that must block shutdown because of an operation that cannot be interrupted should explain the reason to the user.** Use ShutdownBlockReasonCreate to register a string that explains the reason to the user. When the operation has completed, the app should call ShutdownBlockReasonDestroy to indicate that the system can be shut down.

5. Apps müssen eine bereinigte, umkehrbare Installation unterstützen.

Mit einer sauberen, umkehrbaren Installation können Benutzer Apps auf ihren Systemen erfolgreich verwalten (bereitstellen und entfernen).

5.1 Ihre App muss eine bereinigte, umkehrbare Installation ordnungsgemäß implementieren.
Wenn bei der Installation ein Fehler auftritt, sollte die App in der Lage sein, ein Rollback für den Computer zu durchführen und den vorherigen Zustand wiederherzustellen.

5.2 Your app must never force the user to restart the computer immediately
Das Neustarten des Computers sollte nie die einzige Option am Ende einer Installation oder eines Updates sein. Benutzer sollten die Möglichkeit haben, später neu zu starten.
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 Inventurtools und Telemetrietools erfordern vollständige Informationen zu installierten Apps. Wenn Sie ein MSI-basiertes Installationsprogramm verwenden, erstellt MSI automatisch die unten angegebenen Registrierungseinträge. Wenn Sie kein MSI-Installationsprogramm verwenden, muss das Installationsmodul während der Installation die folgenden Registrierungseinträge erstellen:
  • DisplayName
  • InstallLocation
  • Publisher
  • UninstallString
  • VersionMajor oder MajorVersion
  • VersionMinor oder MinorVersion

6. Apps müssen Dateien und Treiber digital signieren

Mit einer digitalen Authenticode-Signatur können Benutzer sicherstellen, dass die Software echt ist. Außerdem kann erkannt werden, ob eine Datei manipuliert wurde, z. B. ob sie von einem Virus infiziert wurde. Die Erzwingung von Codesignaturen im Kernelmodus ist ein Windows Feature, das als Codeintegrität (Code Integrity, CI) bezeichnet wird und die Sicherheit des Betriebssystems verbessert, indem die Integrität einer Datei jedes Mal überprüft wird, wenn das Image der Datei in den Arbeitsspeicher geladen wird. CI erkennt, ob schädlicher Code eine Systembinärdatei geändert hat. Generiert auch 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 werden.
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 Ausnahmen
Ausnahmen werden nur für verteilbare Drittanbieter ohne Vorzeichen berücksichtigt, ausgenommen Treiber. Ein Kommunikationsnachweis, der eine signierte Version der verteilbaren (verteilbaren) Verteilbaren Anforderer anfordert, ist erforderlich, damit dieser Verzicht gewährt wird.

7. Apps blockieren die Installation oder den App-Start nicht basierend auf einer Versionsprüfung des Betriebssystems.

Es ist wichtig, dass Kunden nicht 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 im Allgemeinen nicht die Betriebssystemversion überprüfen müssen.

7.1 Ihre App darf keine Versionsüberprüfungen auf Gleichheit durchführen.
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 an zukünftigen Versionen von Windows. Treiberinstallationsprogramme und Deinstallationsmodule sollten nie die Betriebssystemversion überprüfen.

7.2 Exceptions and Waivers will be considered for apps meeting the criteria below:
  • Apps, die als ein Paket bereitgestellt werden, das auch unter Windows XP, Windows Vista und Windows 7 ausgeführt wird, und die die Betriebssystemversion überprüfen müssen, um zu bestimmen, welche Komponenten auf 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 Mindestversionsanforderungen im App-Manifest ordnungsgemäß auflisten.
  • Sicherheits-Apps (Antivirus, Firewall usw.), Systemhilfsprogramme (z. B. Defragmentierung, Sicherungen und Diagnosetools), die die Betriebssystemversion nur mithilfe der genehmigten API-Aufrufe überprüfen.

8. Apps laden keine Dienste oder Treiber im abgesicherten Modus

Tresor Modus ermöglicht Benutzern die Diagnose und Problembehandlung Windows. Treiber und Dienste dürfen nur dann im abgesicherten Modus geladen werden, wenn sie für grundlegende Systemvorgänge wie Speichergerätetreiber oder für Diagnose- und Wiederherstellungszwecke wie Virenscanner erforderlich sind. Wenn sich Windows im abgesicherten Modus befindet, werden standardmäßig nur die Treiber und Dienste gestartet, die mit Windows vorinstalliert wurden.

  • 8.1 Ausnahmen und Ausnahmen
    Treiber und Dienste, die im abgesicherten Modus gestartet werden müssen, erfordern ein Aussetzen. Die Aufhebungsanforderung 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 mithilfe der folgenden Registrierungsschlüssel registrieren:
    - HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal - HKLM/System/CurrentControlSet/Control/SafeBoot/Network

Hinweis: Sie müssen diese Treiber und Dienste testen, um sicherzustellen, dass sie im abgesicherten Modus ohne Fehler funktionieren.

9. Apps müssen die Richtlinien für die Benutzerkontensteuerung einhalten.

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 können Benutzer ihre Systeme steuern und vor unerwünschten Änderungen schützen. Eine unerwünschte Änderung kann schädlich sein, z. B. ein Rootkit, das die Kontrolle über den Computer übernimmt, oder das Ergebnis einer Aktion von Personen mit eingeschränkten Berechtigungen sein. Die wichtigste Regel für die Steuerung des Zugriffs auf Ressourcen besteht darin, den minimalen Standardbenutzerkontext für den Zugriff bereitzustellen, der erforderlich ist, damit ein Benutzer seine erforderlichen Aufgaben ausführen kann. Die Einhaltung der Richtlinien für die Benutzerkontensteuerung (User Account Control, UAC) bietet der App die erforderlichen Berechtigungen, wenn sie von der App benötigt werden, ohne dass das System ständig Sicherheitsrisiken ausgesetzt ist. Für die meisten Apps sind zur Laufzeit keine Administratorrechte erforderlich, und die Ausführung als Standardbenutzer sollte in Ordnung sein.

9.1 Ihre App muss über ein Manifest verfügen, das Ausführungsebenen definiert und dem Betriebssystem mit aufzählt, welche Berechtigungen die App für die Ausführung benötigt.
Die Kennzeichnung des App-Manifests gilt nur für EXEs, nicht für DLLs. Dies liegt daran, dass die UAC dlls während der Prozesserstellung nicht überprüft. Beachten Sie auch, dass UAC-Regeln nicht für Microsoft-Dienste gelten. Das Manifest kann entweder eingebettet oder extern sein.
Erstellen Sie zum Erstellen eines Manifests eine Datei mit dem Namen <_ App-Namen>.exe.manifest, und speichern Sie sie im selben Verzeichnis wie die EXE-Datei. Beachten Sie, dass externe Manifeste ignoriert werden, wenn die App über ein internes Manifest verfügt. Beispiel:
<requestedExecutionLevel level=""asInvoker | highestAvailable | requireAdministrator"" uiAccess=""true | false"""/>

9.2 Your app s main process must be run as a standard user (asInvoker).
Alle administrativen Features müssen in einen separaten Prozess verschoben werden, der mit Administratorrechten ausgeführt wird. Benutzerorientierte Apps, z. B. apps, auf die über die Programmgruppe im Startmenü zugegriffen werden kann und die erhöhte Rechte erfordern, müssen authenticode signiert sein.
9.3 Exceptions and Waivers
Eine Aufhebung ist für Apps erforderlich, die ihren Hauptprozess mit erhöhten Rechten ausführen (requireAdministrator oder highestAvailable). Der Hauptprozess wird als Einstiegspunkt des Benutzers für die App identifiziert. Ausnahmen werden für die folgenden Szenarien berücksichtigt:
  • Verwaltungs- oder Systemtools mit der Ausführungsebene "highestAvailable" und/oder "requireAdministrator"
  • Nur die Framework-App für Barrierefreiheit oder Benutzeroberflächenautomatisierung legt das uiAccess-Flag auf TRUE fest, um die Isolation von Benutzeroberflächenberechtigungen (User Interface Privilege Isolation, UIPI) zu umgehen. Um die App-Auslastung ordnungsgemäß zu starten, muss dieses Flag authenticodesigniert sein und sich an einem geschützten Speicherort im Dateisystem befinden, nämlich in Programme.

10. Apps müssen standardmäßig in den richtigen Ordnern installiert werden.

Benutzer sollten über eine konsistente und sichere Benutzeroberfläche mit dem Standardinstallationsspeicherort von Dateien verfügen und gleichzeitig die Option beibehalten, 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 gegenseitig zu beschädigen oder zu überschreiben. Windows stellt bestimmte Speicherorte im Dateisystem zum Speichern von Programmen und Softwarekomponenten, freigegebenen App-Daten und App-Daten bereit, die für einen Benutzer spezifisch sind.

10.1 Ihre App muss standardmäßig im Ordner Programme installiert sein.
Für native 32-Bit- und 64-Bit-Apps in %ProgramFiles%, und %ProgramFiles(x86)% für 32-Bit-Apps, die auf x64 ausgeführt werden. Benutzerdaten oder App-Daten dürfen aufgrund der für diesen Ordner konfigurierten Sicherheitsberechtigungen nie an diesem Speicherort gespeichert werden.

10.2 Your app must avoid starting automatically on startup
Beispielsweise sollte Ihre App keine der folgenden Angaben festlegen:
  • Registrierung führt die Schlüssel HKLM und oder HKCU unter Software \ Microsoft \ Windows \ CurrentVersion aus.
  • Registrierung führt die Schlüssel HKLM und oder HKCU unter Software \ Wow6432Node \ Microsoft \ windows \ CurrentVersion aus.
  • Startmenü AllPrograms > STARTUP
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
Verwenden Sie die richtigen Methoden zum Installieren von Dateien, z. B. Schriftarten oder Treiber.
10.6 Your app must write user data at first run and not during the installation in per-machine installations
Wenn die App installiert ist, gibt es keinen richtigen Benutzerspeicherort, an dem Daten gespeichert werden sollen. Versuche einer App, das Standardzuordnungsverhalten nach der Installation auf Computerebene zu ändern, sind nicht erfolgreich. Stattdessen müssen Standardwerte auf Benutzerebene beansprucht werden, wodurch verhindert wird, dass mehrere Benutzer die Standardwerte gegenseitig überschreiben.
10.7 Exceptions and Waivers
Für Apps, die in den globalen Assemblycache (GAC) schreiben, ist eine Ausnahme 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 nicht beeinträchtigt wird, wenn sie lokal oder remote in mehreren Sitzungen ausgeführt wird.
11.2 Die Einstellungen und Datendateien Ihrer App dürfen nicht benutzerübergreifend beibehalten werden.
11.3 Der Datenschutz und die Einstellungen eines Benutzers müssen in der Sitzung des Benutzers isoliert werden.
11.4 Ihre App-Instanzen müssen voneinander isoliert werden.
Dies bedeutet, dass Benutzerdaten aus einer Instanz für eine andere Instanz 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 kein Konflikt vorliegt.

11.5 Apps that are installed for multiple users must store data in the correct folder(s) and registry locations
Weitere Informationen finden Sie in den UAC-Anforderungen.
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
**Note:** If an app does not support multiple user sessions or remote access, it must clearly state this when launched from this kind of session.

12. Apps müssen x64-Versionen von Windows unterstützen.

Da 64-Bit-Hardware immer häufiger verwendet 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 64-Bit nativ unterstützen, oder mindestens 32-Bit-Windows-basierte Apps müssen nahtlos auf 64-Bit-Systemen ausgeführt werden, um die Kompatibilität mit 64-Bit-Versionen von Windows
12.2 Ihre App und ihre Installationsprogramme dürfen keinen 16-Bit-Code enthalten und dürfen keine 16-Bit-Komponente verwenden.
12.3 Das Setup Ihrer App muss die richtigen Treiber und Komponenten für die 64-Bit-Architektur erkennen und installieren.
12.4 Alle Shell-Plug-Ins müssen auf 64-Bit-Versionen von Windows
12.5 App, die unter dem WoW64-Emulator ausgeführt wird, sollte nicht versuchen, Wow64-Virtualisierungsmechanismen zu unter- 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 notieren. Stabile Anforderungen sind wichtig, um Ihre beste Arbeit zu leisten. Daher werden wir sicherstellen, dass die von uns vorgenommenen Änderungen dauerhaft sind und Ihre Apps weiterhin schützen und verbessern.

Nochmals vielen Dank, dass Sie sich unserer Verpflichtung zur Bereitstellung hervorragender Kundenerlebnisse verpflichtet haben.

Revisionsverlauf

Date Version Revisionsbeschreibung Link zum Dokument
20. Dezember 2011 1.0 Erster Entwurf des Dokuments für die Vorschau.
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 endgültiges Dokument 3.0

Weitere Informationen zur Zertifizierung von Desktop-Apps

Anforderung BESCHREIBUNG Weitere Informationen
Kompatibilität und Resilienz Abstürze & Hängen stellen eine erhebliche Unterbrechung für Benutzer dar und verursachen Frust. Es wird erwartet, dass Apps resilient und stabil sind. Durch die Beseitigung solcher Fehler wird sichergestellt, dass Software besser vorhersagbar, veraufrechterhalten, leistungsfähig und vertrauenswürdiger ist. Windows Vista, Windows 7 und Windows 8 Betriebssysteme
Application Verifier
AppInit-DLLs
Befolgen Windows-Sicherheit bewährten Methoden Die Verwendung Windows bewährten Sicherheitsmethoden trägt dazu bei, die Gefährdung durch Windows Angriffsflächen zu vermeiden. Angriffsflächen sind die Einstiegspunkte, die ein böswilliger Angreifer verwenden kann, um das Betriebssystem auszunutzen, indem er Sicherheitsrisiken in der Zielsoftware nutzt. Eines der schlechtesten 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 Maßnahmen unterstützen, um die Integrität des Betriebssystems aufrechtzuerhalten. Falsch kompilierte Anwendungen können Pufferüberläufe verursachen, die wiederum zu Denial-of-Service-Angriffen führen oder die Ausführung von schädlichem Code bewirken können. BinScope-Toolreferenz
Befolgen von Meldungen des Systemneustart-Managers Wenn Benutzer das Herunterfahren initiieren, haben sie in den meisten Fällen den starken Wunsch, dass das Herunterfahren erfolgreich ist. sie sind möglicherweise in der Lage, das Büro zu verlassen, und "nur" möchten, dass ihre Computer ausgeschaltet werden. Apps müssen diesen Wunsch berücksichtigen, indem sie das Herunterfahren nicht blockieren. Obwohl das Herunterfahren in den meisten Fällen möglicherweise nicht kritisch ist, müssen Apps auf die Möglichkeit eines kritischen Herunterfahrens vorbereitet werden. Änderungen beim Herunterfahren von Anwendungen in Windows Vista
Restart Manager-Entwicklung
Bereinigen der umkehrbaren Installation Mit einer sauberen, umkehrbaren Installation können Benutzer Apps auf ihren Systemen erfolgreich 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 sicherstellen, dass die Software echt ist. Außerdem kann erkannt werden, ob eine Datei manipuliert wurde, z. B. wenn sie von einem Virus infiziert wurde. Die Erzwingung von Codesignaturen im Kernelmodus ist ein Windows Feature, das als Codeintegrität (Code Integrity, CI) bezeichnet wird und die Sicherheit des Betriebssystems verbessert, indem die Integrität einer Datei jedes Mal überprüft wird, wenn das Image der Datei in den Arbeitsspeicher geladen wird. CI erkennt, ob schädlicher Code eine Systembinärdatei geändert hat. Generiert auch ein Diagnose- und Systemüberwachungsprotokollereignis, wenn die Signatur eines Kernelmoduls nicht ordnungsgemäß überprüft werden kann. Digitale Signaturen für Kernelmodule auf Windows
Installation oder App-Start nicht basierend auf der Versionsprüfung des Betriebssystems blockieren Es ist wichtig, dass Kunden nicht 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. Betriebssystemversionsierung
Nicht laden von Diensten und Treibern im Tresor Modus Tresor Modus ermöglicht Benutzern die Diagnose und Problembehandlung Windows. Sofern dies nicht für grundlegende Vorgänge des Systems (z. B. Speichergerätetreiber) oder für Diagnose- und Wiederherstellungszwecke (z. B. Virenscanner) erforderlich ist, dürfen Treiber und Dienste nicht auf das Laden im abgesicherten Modus festgelegt werden. Standardmäßig startet der abgesicherte Modus nicht die meisten Treiber und Dienste, die nicht mit Windows vorinstalliert wurden. Sie sollten deaktiviert bleiben, es sei denn, das System erfordert sie für grundlegende Vorgänge oder zu Diagnose- und Wiederherstellungszwecken. Bestimmen, ob das Betriebssystem im Tresor Modus ausgeführt wird
Befolgen der Richtlinien für die Benutzerkontensteuerung (User Account Control, UAC) Einige Windows App werden im Sicherheitskontext eines Administratorkontos ausgeführt, und viele erfordern übermäßige Benutzerrechte und Windows Berechtigungen. Durch die Steuerung des Zugriffs auf Ressourcen können Benutzer ihre Systeme gegen unerwünschte Änderungen steuern (eine unerwünschte Änderung kann schädlich sein, z. B. ein Rootkit, das den Computer unbeaufsichtigt übernimmt, oder eine Aktion von Personen, die eingeschränkte Berechtigungen haben, z. B. ein Mitarbeiter, der unzulässige Software auf einem Arbeitscomputer installiert). Die wichtigste Regel für die Steuerung des Zugriffs auf Ressourcen besteht darin, den minimalen Standardbenutzerkontext für den Zugriff bereitzustellen, der erforderlich ist, damit ein Benutzer seine erforderlichen Aufgaben ausführen kann. Die Einhaltung von UAC-Richtlinien bietet der App bei Bedarf die erforderlichen Berechtigungen, ohne dass das System ständig Sicherheitsrisiken ausgesetzt bleibt. Benutzerkontensteuerung
UAC: Richtlinien für Anwendungsupdates
Standardmäßig in den richtigen Ordnern installieren Benutzer sollten über eine konsistente und sichere Benutzeroberfläche mit dem Standardinstallationsspeicherort von Dateien verfügen und gleichzeitig die Option beibehalten, eine App an dem von ihnen gewählten Speicherort 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 gegenseitig zu beschädigen oder zu überschreiben. Zusammenfassung der Installations-/Deinstallationsanforderungen
Unterstützen von Sitzungen mit mehreren Benutzern Windows Benutzer sollten in der Lage sein, gleichzeitige Sitzungen ohne Konflikte oder Unterbrechungen auszuführen. Remotedesktopdienste Programmierrichtlinien
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 gut unter 64-Bit-Versionen von Windows ausgeführt werden. Anwendungskompatibilität: Windows Vista 64-Bit

Weitere Informationen