Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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 Zertifizierungsprogramm für Windows 8-Desktop-Apps 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 Ihr Produkt, da sichergestellt wird, dass sie Kompatibilitätsstandards erfüllt und auf der Windows-Plattform gut funktioniert. Die erfolgreiche Übergabe der Windows-App-Zertifizierung ermöglicht es Ihrer App, im Windows Compatibility Center zu präsentieren, und es ist auch ein erforderlicher Schritt zum Auflisten einer Desktop-App-Referenz im Windows Store.
Das Zertifizierungsprogramm für Windows-Apps besteht aus Programm- und technischen Anforderungen, um sicherzustellen, dass Apps von Drittanbietern, die die Windows-Marke tragen, sowohl einfach zu installieren als auch zuverlässig auf PCs unter 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 investitionen, um diese Anforderungen für Software-Apps zu erfüllen, die auf der Windows-Plattform für PCs ausgeführt werden sollen. Zu diesen Bemühungen gehören Kompatibilitätstests für die Konsistenz der Erfahrung, 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 auf branchenspezifische Entwicklungen und Verbrauchernachfrage zu reagieren.
Das Zertifizierungskit für Windows-Apps wird verwendet, um die Einhaltung dieser Anforderungen zu überprüfen und den WSLK zu ersetzen, der 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 enthalten sind. Sie ist auch in Microsoft Visual Studio 2012 Express für Windows 8 integriert.
App-Berechtigung
Damit eine App für die Windows 8-Desktop-App-Zertifizierung berechtigt ist, 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 handeln
- Er muss auf einem lokalen Windows 8.1-Computer ausgeführt werden.
- Es kann sich um eine Clientkomponente einer zertifizierten Windows Server-App handeln.
- Es muss Code und Feature abgeschlossen sein.
1. Apps sind kompatibel und robust
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 robust und stabil sind und solche Fehler beseitigen, um sicherzustellen, dass Software vorhersehbarer, wartungsfähiger, leistungsfähiger und vertrauenswürdiger ist.
- 1.1 Ihre App darf keine Abhängigkeit von Windows-Kompatibilitätsmodi, AppHelp-Meldung und anderen Kompatibilitätsfixes übernehmen.
1.2 Ihre App darf keine Abhängigkeit von der VB6-Laufzeit übernehmen.
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 die bewährten Methoden für die Windows-Sicherheit einhalten.
Die Verwendung bewährter Methoden für die Windows-Sicherheit trägt dazu bei, die Gefährdung von Windows-Angriffsflächen zu vermeiden. Angriffsflächen sind die Einstiegspunkte, mit denen ein böswilliger Angreifer das Betriebssystem ausnutzen könnte, indem sicherheitsrisiken in der Zielsoftware genutzt werden. Eine der schlimmsten 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 sichern 2.3 Ihre App muss starke und geeignete . ACLs zum Sichern von Registrierungsschlüsseln 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 verringern, 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.
Das Zertifizierungsprogramm für Windows-Apps überprüft, ob Windows Attack Surfaces 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 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 bösartigen Code ausführen können.
- 3.1 Ihre App darf AllowPartiallyTrustedCallersAttribute (APTCA) nicht verwenden, um sicheren Zugriff auf assemblys mit starkem Namen zu gewährleisten.
3.2 Ihre App muss mithilfe des Flags "/SafeSEH" kompiliert werden, um die Behandlung sicherer Ausnahmen 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 /DYNAMICBASE-Flags für die Zufälligisierung des Adressraumlayouts (ASLR) kompiliert werden.
3.5 Ihre App darf die freigegebenen PE-Abschnitte nicht lesen/schreiben
4. Apps müssen nachrichten des Systemneustart-Managers einhalten
Wenn Benutzer das Herunterfahren initiieren, haben sie in der Regel einen starken Wunsch, das Herunterfahren erfolgreich zu sehen; sie sind möglicherweise in Eile, um 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. In den meisten Fällen ist ein Herunterfahren möglicherweise nicht kritisch, apps müssen jedoch auf die Möglichkeit eines kritischen Herunterfahrens vorbereitet werden.
- 4.1 Ihre App muss kritische Herunterfahren entsprechend behandeln.
- In einem kritischen Herunterfahren werden Apps, die FALSE an WM_QUERYENDSESSION zurückgeben, WM_ENDSESSION und geschlossen, während diese Zeitüberschreitung als Reaktion auf WM_QUERYENDSESSION 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 sich mindestens darauf vorbereiten, indem alle Benutzerdaten gespeichert und die Informationen angegeben werden, die nach einem Neustart benötigt werden.
5. Apps müssen eine saubere, 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 saubere, umkehrbare Installation ordnungsgemäß implementieren.
- DisplayName
- InstallLocation
- Verlag
- UninstallString
- VersionMajor oder MajorVersion
- VersionMinor oder MinorVersion
- Wenn die Installation fehlschlägt, sollte die App in der Lage sein, es zurückzusetzen und den Computer in den vorherigen Zustand wiederherzustellen.
- Das Neustarten des Computers sollte niemals die einzige Option am Ende einer Installation oder eines Updates sein. Benutzer sollten die Möglichkeit haben, später neu zu starten.
- Windows-Inventartools 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 sicherstellen, 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 von Kernelmodus-Codesignaturen ist ein Windows-Feature, das als Codeintegrität (CI) bezeichnet wird, wodurch die Sicherheit des Betriebssystems verbessert wird, indem die Integrität einer Datei bei jedem Laden des Bilds der Datei in den Arbeitsspeicher überprüft wird. CI erkennt, ob bösartiger Code eine System-Binä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 werden.
6.2 Alle von der App installierten Kernelmodustreiber müssen über eine Microsoft-Signatur verfügen, die über das Windows-Hardwarezertifizierungsprogramm abgerufen wird. Alle Dateisystemfiltertreiber müssen von Microsoft signiert werden.
6.3 Ausnahmen und Verzichtserklärungen
- Verzichtserklärungen gelten nur für nicht signierte Weiterverteiler von Drittanbietern, mit Ausnahme von Treibern. Ein Nachweis der Kommunikation, die eine signierte Version der verteilbaren(n) Version anfordert, ist erforderlich, damit diese Verzichtserklärung erteilt wird.
7. Apps blockieren die Installation oder den App-Start nicht basierend auf einer Überprüfung der Betriebssystemversion
Es ist wichtig, dass Kunden nicht künstlich daran gehindert werden, ihre App zu installieren oder auszuführen, wenn keine technischen Einschränkungen bestehen. Wenn Apps für Windows Vista oder höhere Versionen von Windows geschrieben wurden, sollten sie nicht die Betriebssystemversion überprüfen müssen.
- 7.1 Ihre App darf keine Versionsüberprüfungen auf Gleichheit durchführen.
- Apps, die als ein Paket bereitgestellt werden, das auch unter Windows XP, Windows Vista und Windows 7 ausgeführt wird, 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 überprüfen (nur während der Installation, nicht zur Laufzeit), indem sie nur die genehmigten API-Aufrufe verwenden und die mindestversionsanforderung im App-Manifest ordnungsgemäß auflisten.
- Sicherheits-Apps (Antivirus, Firewall usw.), Systemhilfsprogramme (z. B. Defragmentierung, Sicherungen und Diagnosetools), 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 für zukünftige 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 behandeln. Treiber und Dienste dürfen nicht im abgesicherten Modus geladen werden, es sei denn, sie sind für grundlegende Systemvorgänge wie Speichergerätetreiber oder für Diagnose- und Wiederherstellungszwecke wie Virenscanner erforderlich. 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 eine Verzichtserklärung. Die Verzichtserklärungsanforderung 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 betreffenden Treiber und Dienste mithilfe dieser Registrierungsschlüssel registrieren:
Hinweis: Sie müssen diese Treiber und Dienste testen, um sicherzustellen, dass sie ohne Fehler 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 können Benutzer ihre Systeme kontrollieren und vor unerwünschten Änderungen schützen. 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 mit eingeschränkten Berechtigungen. Die wichtigste Regel für die Steuerung des Zugriffs auf Ressourcen ist die Bereitstellung des geringsten Zugriffsstandardbenutzerkontexts, der für den Benutzer erforderlich ist, um seine erforderlichen Aufgaben auszuführen. Die Richtlinien für die Benutzerkontensteuerung (User Account Control, UAC) bieten der App die erforderlichen Berechtigungen, 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 nur als Standardbenutzer ausgeführt werden.
- 9.1 Ihre App muss über ein Manifest verfügen, das Ausführungsebenen definiert und dem Betriebssystem angibt, welche Berechtigungen die App benötigt, um sie auszuführen.
- Administrative oder Systemtools, für die die Ausführungsebene auf "highestAvailable" festgelegt ist, und/oder "requireAdministrator"
- Nur Barrierefreiheits- oder Benutzeroberflächenautomatisierungs-Framework-App 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 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.
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 externe Manifeste ignoriert werden, wenn die App über ein internes Manifest verfügt. Zum 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. Benutzergerichtete Apps, z. B. die über die Programmgruppe im Startmenü zugänglich sind und die Erhöhung erforderlich ist, müssen Authenticode signiert sein.
- Eine Verzichtserklärung ist für Apps erforderlich, die ihren Hauptprozess mit erhöhten Berechtigungen ausführen (requireAdministrator oder highestAvailable). Der Hauptprozess wird als Einstiegspunkt des Benutzers in die 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 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 der anderen zu beschädigen oder zu überschreiben. Windows bietet bestimmte Speicherorte im Dateisystem zum Speichern von Programmen und Softwarekomponenten, freigegebenen App-Daten und App-Daten, die für einen Benutzer spezifisch sind.
- 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ü "AllPrograms" > START
- Für systemeigene 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 niemals an diesem Speicherort gespeichert werden.
- Ihre App sollte z. B. keine der folgenden Optionen festlegen.
- Verwenden Sie die richtigen Methoden zum Installieren von Dateien, z. B. Schriftarten oder Treibern.
- Wenn die App installiert ist, gibt es keinen richtigen Benutzerspeicherort, an dem Daten gespeichert werden sollen. Versuche einer App, standardzuordnungsverhalten auf Computerebene zu ändern, nachdem die Installation nicht erfolgreich war. Stattdessen müssen Standardwerte auf benutzerspezifischer Ebene beansprucht werden, wodurch verhindert wird, dass mehrere Benutzer die Standardwerte gegenseitig überschreiben.
- Eine Verzichtserklärung ist für Apps erforderlich, die in den globalen Assemblycache (GAC) schreiben. .NET-Apps sollten Assemblyabhängigkeiten privat lassen 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 ausgeführt wird.
11.2 Ihre App-Einstellungen und Datendateien dürfen nicht für alle Benutzer 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 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 gemeinsam genutzte Ressourcen verwenden, muss die App sicherstellen, dass kein Konflikt vorliegt.
- Weitere Informationen finden Sie unter den UAC-Anforderungen.
12. Apps müssen x64-Versionen von Windows unterstützen
Da 64-Bit-Hardware 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 64-Bit oder mindestens 32-Bit-Windows-basierte Apps nahtlos auf 64-Bit-Systemen ausführen, 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 von einer 16-Bit-Komponente abhängig sein.
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 subvertieren 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 durch Aufrufen von IsWow64Process tun.
Schlussfolgerung
Da sich diese Anforderungen weiterentwickeln, werden wir die Änderungen im überarbeitungsverlauf unten notieren. Stabile Anforderungen sind entscheidend, um Ihre beste Arbeit zu leisten, sodass wir sicherstellen möchten, dass die von uns vorgenommenen Änderungen nachhaltig sind und Ihre Apps weiterhin schützen und verbessern.
Vielen Dank, dass Sie sich erneut mit unserem Engagement für die Bereitstellung großartiger Kundenerlebnisse verbunden haben.
Überarbeitungsverlauf
| Datum | Version | Revisionsbeschreibung | Link zu Dokument |
|---|---|---|---|
| 20. Dezember 2011 | 1.0 | Anfänglicher Dokumententwurf für die Vorschau. | |
| 26. Januar 2012 | 1.1 | Aktualisieren sie auf Abschnitt Nr. 2. | 1.1 |
| 31. Mai 2012 | 1.2 | Zusammenfassungstestergebnisse hinzugefügt | 1.2 |
| 29. Juni 2012 | 3.0 | Endgültiges Windows 8-Dokument | 3.0 |
Weitere Informationen zur Desktop-App-Zertifizierung
| Anforderung | Beschreibung | Weitere Details |
|---|---|---|
| Kompatibilität und Resilienz | Abstürze & Hängen sind eine große Unterbrechung der Benutzer und führen zu Frustration. Apps werden erwartet, dass sie robust und stabil sind, wodurch solche Fehler beseitigt werden, um sicherzustellen, dass Software vorhersehbarer, wartungsfähiger, leistungsfähiger und vertrauenswürdiger ist. |
Windows Vista, Windows 7 und Windows 8 Betriebssystemen Application Verifier- AppInit DLLs |
| Einhaltung bewährter Methoden für die Windows-Sicherheit | Die Verwendung bewährter Methoden für die Windows-Sicherheit trägt dazu bei, die Gefährdung von Windows-Angriffsflächen zu vermeiden. Angriffsflächen sind die Einstiegspunkte, mit denen ein böswilliger Angreifer das Betriebssystem ausnutzen könnte, indem sicherheitsrisiken in der Zielsoftware genutzt werden. Eine der schlimmsten Sicherheitsrisiken ist die Rechteerweiterung. |
Attack Surface Analyzer Zugriffssteuerungslisten |
| Unterstützen von Windows-Sicherheitsfeatures | 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. Nicht ordnungsgemäß kompilierte Anwendungen könnten Pufferüberläufe verursachen, die wiederum zu Denial of Service führen oder bösartigen Code ausführen können. |
BinScope-Toolreferenz |
| Einhalten von Systemneustart-Manager-Nachrichten | Wenn Benutzer das Herunterfahren initiieren, haben sie in den meisten Fällen einen starken Wunsch, das Herunterfahren erfolgreich zu sehen; sie sind möglicherweise eilig, um das Büro zu verlassen und "nur wollen" ihre Computer zu deaktivieren. Apps müssen diesen Wunsch respektieren, indem sie das Herunterfahren nicht blockieren. In den meisten Fällen ist ein Herunterfahren möglicherweise nicht kritisch, apps müssen jedoch auf die Möglichkeit eines kritischen Herunterfahrens vorbereitet werden. |
Änderungen beim Herunterfahren von Anwendungen in Windows Vista Neustart-Manager-Entwicklung |
| Umsetzbare Installation bereinigen | Mit einer sauberen, umkehrbaren Installation können Benutzer Apps auf ihren Systemen erfolgreich verwalten (bereitstellen und entfernen). |
How to: Install Prerequisites with a ClickOnce Application Anwendungsinstallation auf 64-Bit-Systemen |
| Digitales Signieren von Dateien und Treibern | Mit einer digitalen Authenticode-Signatur können Benutzer sicherstellen, 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 von Kernelmodus-Codesignaturen ist ein Windows-Feature, das als Codeintegrität (CI) bezeichnet wird, wodurch die Sicherheit des Betriebssystems verbessert wird, indem die Integrität einer Datei bei jedem Laden des Bilds der Datei in den Arbeitsspeicher überprüft wird. CI erkennt, ob bösartiger Code eine System-Binä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 keine technischen Einschränkungen bestehen. Wenn Apps für Windows Vista oder spätere Versionen geschrieben wurden, sollten sie grundsätzlich 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, für grundlegende Vorgänge des Systems (z. B. Speichergerätetreiber) oder für Diagnose- und Wiederherstellungszwecke (z. B. Virenscanner) 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 für Diagnose- und Wiederherstellungszwecke. |
Bestimmen, ob das Betriebssystem im abgesicherten Modus ausgeführt wird |
| Richtlinien für die Benutzerkontensteuerung (User Account Control, UAC) befolgen | Einige Windows-Apps 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 vor unerwünschten Änderungen kontrollieren (Eine unerwünschte Änderung kann böswillig sein, z. B. ein Rootkit, das den Computer gestohlen hat, oder eine Aktion von Personen, die eingeschränkte Berechtigungen haben, z. B. eine Mitarbeiterin, die 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 den Benutzer erforderlich ist, um seine erforderlichen Aufgaben auszuführen. Nach den UAC-Richtlinien erhalten Die App bei Bedarf die erforderlichen Berechtigungen, ohne das System ständig sicherheitsrisiken ausgesetzt zu lassen. |
Benutzerkontensteuerung UAC: Richtlinien für Anwendungsupdates |
| Installieren in den richtigen Ordnern standardmäßig | Benutzer sollten über eine konsistente und sichere Erfahrung mit dem Standardinstallationsspeicherort von Dateien verfügen und gleichzeitig die Option beibehalten, eine App an dem von ihnen ausgewä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 der anderen zu beschädigen oder zu überschreiben. |
Zusammenfassung der Installations-/Deinstallationsanforderungen |
| Unterstützen von Mehrbenutzersitzungen | Windows-Benutzer sollten in der Lage sein, gleichzeitige Sitzungen ohne Konflikte oder Unterbrechungen auszuführen. |
Programmierrichtlinien für Remotedesktopdienste |
| Unterstützen von x64-Versionen von Windows | Da die 64-Bit-Hardware 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. |
Anwendungskompatibilität: Windows Vista 64-Bit- |