Требования к сертификации для классических приложений Windows

Версия документа: 10

Дата документа: 29 июля 2015 г.

В этом документе содержатся технические требования и квалификации, которым должно соответствовать настольное приложение для участия в программе сертификации настольных приложений Windows 10.

Welcome!

Платформа Windows поддерживает широкую экосистему продуктов и партнеров. Отображение логотипа Windows в продукте представляет связь и общую приверженность качеству между корпорацией Майкрософт и вашей компанией. Клиенты доверяют бренду Windows на продукт, так как он соответствует стандартам совместимости и хорошо работает на платформе Windows. Успешное прохождение сертификации приложений Windows позволяет продемонстрировать приложение в Центре совместимости Windows, и вы можете отобразить логотип сертификации на сайте.

Программа сертификации приложений Windows состоит из программ и технических требований, чтобы гарантировать, что сторонние приложения, использующие бренд Windows, легко установить и надежно на компьютерах под управлением Windows. Клиенты ценят стабильность, совместимость, надежность, производительность и качество в системах, которые они покупают. Корпорация Майкрософт фокусирует свои инвестиции на соответствие этим требованиям для приложений программного обеспечения, предназначенных для работы на платформе Windows для компьютеров. Эти усилия включают тесты совместимости для согласованности взаимодействия, повышения производительности и повышенной безопасности на компьютерах под управлением программного обеспечения Windows. Тесты совместимости Майкрософт разработаны в сотрудничестве с отраслевыми партнерами и постоянно улучшаются в ответ на отраслевые разработки и потребительский спрос.

Комплект сертификации приложений Для Windows используется для проверки соответствия этим требованиям и заменяет все предыдущие версии комплекта, используемого для проверки в Windows 7, Windows 8 или Windows 8.1. Комплект сертификации приложений Windows является одним из компонентов, включённых в Windows Software Development Kit (SDK) для Windows 10.

Право на доступ к приложению

Чтобы приложение соответствовало сертификации классических приложений Windows 10, оно должно соответствовать следующим критериям и всем техническим требованиям, перечисленным в этом документе.

• Это должно быть автономное приложение
• Он должен работать на локальном компьютере с Windows 10
• Это может быть клиентский компонент сертифицированного приложения Windows Server
• Это должен быть завершенный код и все функции.
• Он не должен взаимодействовать с приложениями Магазина Windows через локальные механизмы, включая файлы и разделы реестра, за исключением поддерживаемых корпоративных сценариев.
• Он не должен ставить под угрозу или компрометировать безопасность или функциональные возможности системы Windows
• Оно должно иметь уникальное имя и не быть зарегистрированным товарным знаком других лиц.
• Все внешние компоненты должны быть сертифицированы отдельно или соответствовать комплекту сертификации приложений Windows
• У него должен быть вариант отказа для любых пакетных приложений

Если классическое приложение отправляется в категорию продуктов антивирусной программы и (или) антишпионского ПО (т. е. антивредоносные программы), оно должно соответствовать руководящим принципам антивредоносной платформы. ЛИЦЕНЗИЯ НА API ЗАЩИТЫ ОТ ВРЕДОНОСНЫХ ПРОГРАММ WINDOWS 10 И СОГЛАШЕНИЕ О СПИСКАХ должно быть подписано и действовать перед отправкой. Партнер должен быть членом или иметь исследователей, которые являются членами и в хорошем положении в одной организации, перечисленных в соглашении. Функции должны быть сертифицированы в Windows 10 одним из организаций, перечисленных в соглашении. Приложение должно быть проверено по крайней мере один раз за последние 12 месяцев и сертифицировано для обнаружения и очистки.

1. Приложения совместимы и устойчивы

Когда приложение завершается или перестает отвечать, это вызывает значительное разочарование у пользователей. Ожидается, что приложения будут устойчивыми и стабильными. Устранение подобных сбоев помогает сделать программное обеспечение более предсказуемым, поддерживаемым, производительным и надежным.

1.1 Приложение не должно зависеть от режимов совместимости Windows, сообщения AppHelp и других исправлений совместимости.
1.2 Приложение должно иметь манифест совместимости и использовать соответствующие идентификаторы GUID для поддерживаемых версий Windows.
1.3 Ваше приложение должно поддерживать DPI с помощью манифеста сборки, а не через вызов SetProcessDPIAware
1.4 Ваше приложение не должно зависеть от среды выполнения VB6.
1.5 Приложение не должно загружать произвольные библиотеки DLL для перехвата вызовов API Win32 с помощью HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dlls.

2. Приложения должны соответствовать рекомендациям по безопасности Windows

Использование лучших практик безопасности Windows поможет избежать уязвимости для атак на поверхности Windows. Поверхности атаки — это точки входа, которые злоумышленник может использовать для эксплуатации операционной системы, используя уязвимости в целевом программном обеспечении. Одним из худших уязвимостей безопасности является повышение привилегий.

Обратите внимание, что тесты 2.1 2.6 применимы только для классических приложений, протестированных в Windows 7, Windows 8 или Windows 8.1.

2.1 Приложение должно использовать надежные и соответствующие списки управления доступом для защиты исполняемых файлов.
2.2 Приложение должно использовать надежные и соответствующие списки управления доступом для защиты каталогов.
2.3 Приложение должно использовать надежные и соответствующие списки управления доступом для защиты разделов реестра.
2.4 Приложение должно использовать надежные и соответствующие списки управления доступом для защиты каталогов, содержащих объекты.
2.5 Ваше приложение должно сократить доступ неадминистратора к службам, уязвимым для изменения
2.6 Ваше приложение должно предотвратить быстрый перезапуск служб чаще двух раз в сутки.

Примечание. Доступ должен предоставляться только сущностям, которым требуется.

Программа сертификации приложений Windows проверяет, что поверхности атак Windows не оказываются уязвимыми, подтверждая, что списки управления доступом и службы настроены так, чтобы система Windows не подвергалась риску.

3. Приложения поддерживают функции безопасности Windows

Операционная система Windows имеет множество функций, поддерживающих безопасность системы и конфиденциальность. Приложения должны поддерживать эти функции для обеспечения целостности операционной системы. Неправильно скомпилированные приложения могут привести к переполнению буферов, которые могут, в свою очередь, вызвать отказ в обслуживании или разрешить выполнение вредоносного кода.

3.1 Ваше приложение не должно использовать AllowPartiallyTrustedCallersAttribute (APTCA) для обеспечения безопасного доступа к сборкам с сильным именем
3.2 Приложение должно быть скомпилировано с помощью флага /SafeSEH, чтобы обеспечить безопасную обработку исключений.
3.3 Приложение должно быть скомпилировано с помощью флага /NXCOMPAT, чтобы предотвратить выполнение данных
3.4 Приложение должно быть скомпилировано с использованием флага /DYNAMICBASE для рандомизации размещения адресного пространства (ASLR)
3.5 Ваше приложение не должно читать и записывать общие разделы PE

4. Приложения должны соответствовать сообщениям диспетчера перезапуска системы

Когда пользователи инициируют завершение работы, они обычно имеют сильное желание успешно завершить работу; они могут быть в спешке покинуть офис и просто хотят, чтобы их компьютеры выключились. Приложения должны уважать это желание, не блокируя завершение работы. Хотя в большинстве случаев завершение работы может не быть критическим, приложения должны быть подготовлены к возможному завершении работы.

4.1 Ваше приложение должно корректно обрабатывать критические завершения работы.

При критическом завершении работы приложения, которые возвращают FALSE на WM_QUERYENDSESSION, будут получать WM_ENDSESSION и закрыты, а те, что не отвечают в течение заданного времени, будут принудительно завершены.

4.2 Приложение графического интерфейса пользователя должно немедленно вернуть TRUE при подготовке к перезапуску

WM\_QUERYENDSESSION с LPARAM = ENDSESSION\_CLOSEAPP(0x1). Консольные приложения могут вызывать SetConsoleCtrlHandler, чтобы указать функцию, которая будет обрабатывать уведомления о завершении работы. Приложения-службы могут вызывать RegisterServiceCtrlHandlerEx, чтобы указать функцию, которая будет получать уведомления о завершении работы.

4.3 Ваше приложение должно вернуть 0 в течение 30 секунд и завершить работу.

WM\_ENDSESSION с LPARAM = ENDSESSION\_CLOSEAPP(0x1). Как минимум, приложение должно подготовиться, сохраняя все пользовательские данные и указав необходимые сведения после перезапуска.

4.4 Консольные приложения, получающие уведомление CTRL\_C\_EVENT, должны немедленно завершить работу 4.5 Драйверы не должны вето на событие завершения работы системы

5. Приложения должны поддерживать чистую, обратимую установку

Чистая, обратимая установка позволяет пользователям успешно управлять (развертывать и удалять) приложения в своих системах.

5.1 Ваше приложение должно правильно реализовать чистую, обратимую установку

Если установка завершается ошибкой, приложение должно иметь возможность выполнить откат и восстановить компьютер до предыдущего состояния.

5.2 Ваше приложение никогда не должно принудительно перезагрузить компьютер немедленно.

Перезапуск компьютера никогда не должен быть единственным вариантом в конце установки, удаления или обновления. Пользователи должны иметь возможность перезапустить позже.

5.3 Ваше приложение никогда не должно зависеть от имен коротких файлов 8.3 (SFN) 5.4. Ваше приложение никогда не должно блокировать автоматическую установку и удаление 5.5. Установщик приложения должен создать правильные записи реестра, чтобы разрешить успешное обнаружение и удаление.

Для средств инвентаризации Windows и средств телеметрии требуются полные сведения об установленных приложениях. Если вы используете установщик на основе MSI, MSI автоматически создает записи реестра ниже. Если вы не используете установщик MSI, модуль установки должен создать следующие записи реестра во время установки:

• Отображаемое имя
• InstallLocation
• Publisher
• УдалениеString
• VersionMajor или MajorVersion
• VersionMinor или MinorVersion

5.6 Приложение должно удалить все свои записи в разделе "Установка и удаление программ" при удалении.

6. Приложения должны подписывать файлы и драйверы с помощью цифровой подписи

Цифровая подпись Authenticode позволяет пользователям убедиться, что программное обеспечение является подлинным. Он также позволяет определить, был ли файл изменен, например, если он был заражен вирусом. Принудительное применение подписывания кода в режиме ядра — это функция Windows, известная как целостность кода (CI), которая повышает безопасность операционной системы путем проверки целостности файла при каждом загрузке образа файла в память. CI определяет, изменил ли вредоносный код системный двоичный файл. Также создает событие журнала диагностики и аудита системы, когда подпись модуля ядра не может быть корректно проверена.

6.1 Все исполняемые файлы (.exe, .dll, .ocx, .sys, .cpl, .drv, .scr) должны быть подписаны с помощью сертификата Authenticode.
6.2 Все драйверы режима ядра, установленные приложением, должны иметь подпись Майкрософт, полученную с помощью программы сертификации оборудования Windows. Все драйверы фильтров файловой системы должны быть подписаны корпорацией Майкрософт.
6.3 Исключения и отказы

Освобождения будут рассматриваться только для неподписанного стороннего программного обеспечения, за исключением драйверов. Для предоставления этого отказа требуется предъявить подтверждение факта связи, в которой запрашивается подписанная версия распространяемых компонентов.

7. Приложения не блокируют установку или запуск приложений на основе проверки версии операционной системы

Важно, чтобы клиенты не были искусственно заблокированы при установке или запуске приложения, если нет технических ограничений. Как правило, если приложения были написаны для Windows Vista или более поздних версий Windows, они не должны проверять версию операционной системы.

7.1 Ваше приложение не должно выполнять проверки версий на равенство

Если вам нужна определенная функция, проверьте, доступна ли сама функция. Если вам нужна Windows 7, проверьте наличие Windows 7 или более поздней версии (>= 6.2). Таким образом, код обнаружения будет продолжать работать в будущих версиях Windows. Установщики драйверов и модули удаления никогда не должны проверять версию операционной системы.

Исключения 7.2 и отказы будут рассматриваться для приложений, которые соответствуют приведенным ниже критериям:

• Приложения, которые доставляются как один пакет, который также работает в Windows 7, Windows 8 и Windows 8.1, и необходимо проверить версию операционной системы, чтобы определить, какие компоненты необходимо установить в данной операционной системе.
• Приложения, которые проверяют только минимальную версию операционной системы (только во время установки, а не во время выполнения) с помощью только утвержденных вызовов API и правильно перечисляют минимальные требования к версии в манифесте приложения.
• Приложения безопасности (антивирусная программа, брандмауэр и т. д.), системные служебные программы (например, дефрагменты, резервные копии и средства диагностики), которые проверяют версию операционной системы, используя только утвержденные вызовы API.

8. Приложения не загружают службы или драйверы в безопасном режиме

Безопасный режим позволяет пользователям диагностировать и устранять неполадки с Windows. Драйверы и службы не должны загружаться в безопасном режиме, если они не требуются для основных системных операций, таких как драйверы устройств хранения или для диагностики и восстановления, таких как сканеры антивирусов. По умолчанию, когда Windows находится в безопасном режиме, он запускает только драйверы и службы, которые были предварительно установлены в Windows.

• 8.1 Исключения и отказы

  Драйверы и службы, которые должны быть запущены в безопасном режиме, требуют исключения. Запрос на отказ должен содержать все применимые драйверы или службы, которые записываются в разделы реестра SafeBoot, и в нем должны быть четко описаны технические причины, по которым приложение или служба должны функционировать в безопасном режиме. Установщик приложений должен зарегистрировать все такие драйверы и службы с использованием следующих ключей реестра.

  — HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal — HKLM/System/CurrentControlSet/Control/SafeBoot/Network

Заметка: Эти драйверы и службы необходимо протестировать, чтобы обеспечить их работу в безопасном режиме без ошибок.

9. Приложения должны следовать рекомендациям по управлению учетными записями пользователей

Некоторые приложения Windows выполняются в контексте безопасности учетной записи администратора, а приложения часто запрашивают чрезмерные права пользователя и привилегии Windows. Управление доступом к ресурсам позволяет пользователям контролировать свои системы и защищать их от нежелательных изменений. Нежелательные изменения могут быть вредоносными, такими как руткит, берущий под контроль компьютер, или быть результатом действия, сделанного людьми с ограниченными привилегиями. Наиболее важным правилом для управления доступом к ресурсам является предоставление минимального количества стандартного контекста пользователя, необходимого для выполнения пользователем необходимых задач. Следование рекомендациям по управлению учетными записями пользователей (UAC) позволяет приложению получать необходимые разрешения тогда, когда они нужны, без постоянного оставления системы подверженной рискам безопасности. Большинство приложений не требуют прав администратора во время выполнения и могут без проблем работать от имени стандартного пользователя.

9.1 Приложение должно иметь манифест, который определяет уровни выполнения и сообщает операционной системе, какие привилегии требуется приложению для запуска.

Манифест приложения применяется только к EXEs, а не к библиотекам DLL. Это связано с тем, что UAC не проверяет библиотеки DLL во время создания процесса. Также стоит отметить, что правила UAC не применяются к службам Майкрософт. Манифест может быть внедренным или внешним.
Чтобы создать манифест, создайте файл с именем <app_name>.exe.manifest и сохраните его в том же каталоге, что и EXE. Обратите внимание, что любой внешний манифест игнорируется, если у приложения есть внутренний манифест. Рассмотрим пример.
<requestedExecutionLevel level="asInvoker | highestAvailable | requireAdministrator"" uiAccess=""true|false"/>

9.2 Основной процесс вашего приложения должен выполняться как стандартный пользователь (asInvoker).

Все административные функции должны быть перемещены в отдельный процесс, который выполняется с правами администратора. Пользовательские приложения, такие как доступные через группу программ в меню "Пуск" и требующие повышения прав, должны быть подписаны Authenticode.

9.3 Исключения и отказы

Требуется отказ для приложений, которые выполняют свой основной процесс с повышенными привилегиями (требуетАдминистратора или максимальноВозможный уровень). Основной процесс определяется как точка входа пользователя в приложение. Отказы будут рассматриваться в следующих сценариях:

• Административные или системные средства с установленным уровнем выполнения до наивысшего доступного и/или требуют прав администратора
• Только приложения, использующие специальные возможности или фреймворки автоматизации пользовательского интерфейса, устанавливают значение флага uiAccess на true, благодаря чему обходится изоляция привилегий пользовательского интерфейса (UIPI). Чтобы правильно запустить использование приложения, этот флаг должен быть подписан Authenticode и должен находиться в защищенном расположении в файловой системе, а именно Program Files.

10. Приложения должны устанавливаться в правильные папки по умолчанию

Пользователи должны иметь согласованный и безопасный интерфейс с расположением установки файлов по умолчанию, сохраняя возможность установки приложения в выбранном расположении. Кроме того, необходимо хранить данные приложения в правильном расположении, чтобы несколько пользователей могли использовать один и тот же компьютер без повреждения или перезаписи данных и параметров друг друга. Windows предоставляет определенные расположения в файловой системе для хранения программ и компонентов программного обеспечения, общих данных приложения и данных приложения, относящихся к пользователю

10.1 Приложение должно быть установлено в папке Program Files по умолчанию.

Для собственных 32-разрядных и 64-разрядных приложений в %ProgramFiles%и %ProgramFiles(x86)% для 32-разрядных приложений, работающих на X64. Данные пользователя или данные приложения никогда не должны храниться в этом расположении из-за разрешений безопасности, настроенных для этой папки.

10.2 Ваше приложение должно избежать автоматического запуска при запуске.

Например, приложение не должно задавать ни одно из следующих элементов.

• Разделы запуска реестра HKLM и HKCU в разделе Software\Microsoft\Windows\CurrentVersion
• Разделы ключей запуска реестра HKLM и/или HKCU в Software\Wow6432Node\Microsoft\windows\CurrentVersion
• Меню Пуск Все программы > STARTUP

10.3 Данные вашего приложения, которые должны быть общими для пользователей на компьютере, должны храниться в ProgramData. 10.4 Данные вашего приложения, которые являются эксклюзивными для конкретного пользователя и не должны быть общими для других пользователей компьютера, должны храниться в Users\\<username>\\AppData. 10.5 Ваше приложение никогда не должно записываться непосредственно в каталог Windows и его подкаталоги.

Используйте правильные методы для установки файлов, таких как шрифты или драйверы.

10.6 Ваше приложение должно записывать пользовательские данные при первом запуске, а не во время установки на уровне всех пользователей компьютера.

При установке приложения нет подходящего места для хранения данных. Попытки приложения изменить поведение сопоставлений по умолчанию на уровне компьютера после установки будут неудачными. Вместо этого значения по умолчанию должны назначаться на уровне каждого пользователя, что предотвращает взаимное перезаписывание значений по умолчанию несколькими пользователями.

10.7 Исключения и отказы

Для приложений, которые записывают в глобальный кэш сборок (GAC), требуется отказ от отказа. Приложения .NET должны держать зависимости сборок закрытыми и хранить их в каталоге приложений, если только явно не требуется разделение сборки.

11. Приложения должны поддерживать сеансы с несколькими пользователями

Пользователи Windows должны выполнять одновременные сеансы без конфликтов или нарушений.

11.1 Ваше приложение должно гарантировать, что при работе в нескольких сеансах, как локально, так и удаленно, его нормальная функциональность не ухудшается.
11.2 Параметры и файлы данных приложения не должны сохраняться между пользователями
11.3 Конфиденциальность и предпочтения пользователя должны быть изолированы для сеанса пользователя
11.4 Экземпляры приложения должны быть изолированы друг от друга.

Это означает, что данные пользователя из одного экземпляра не видны другому экземпляру приложения. Звук в неактивном сеансе пользователя не должен быть услышан в активном сеансе пользователя. В случаях, когда несколько экземпляров приложений используют общие ресурсы, приложение должно убедиться, что конфликт не существует.

11.5 Приложения, установленные для нескольких пользователей, должны хранить данные в правильных папках и расположениях реестра.

Ознакомьтесь с требованиями UAC.

11.6 Пользовательские приложения должны работать в нескольких сеансах пользователей (быстрое переключение пользователей) для локального и удаленного доступа 11.7. Приложение должно проверять другие сеансы службы терминалов для существующих экземпляров приложения.

12. Приложения должны поддерживать версии Windows x64

Поскольку 64-разрядное оборудование становится более распространенным, пользователи ожидают, что разработчики приложений будут использовать преимущества 64-разрядной архитектуры, переходят на 64-разрядную, или что 32-разрядные версии приложения хорошо работают под управлением 64-разрядных версий Windows.

12.1 Ваше приложение должно изначально поддерживать 64-разрядные приложения или, как минимум, 32-разрядные приложения windows должны работать без проблем на 64-разрядных системах, чтобы обеспечить совместимость с 64-разрядными версиями Windows.
12.2 Ваше приложение и его установщики не должны содержать 16-разрядный код или полагаться на любой 16-разрядный компонент.
12.3 Настройка приложения должна обнаруживать и устанавливать соответствующие драйверы и компоненты для 64-разрядной архитектуры.
12.4 Любые подключаемые модули оболочки должны работать в 64-разрядных версиях Windows
12.5 Приложение, работающее под эмулятором WoW64, не должно пытаться подставить или обойти механизмы виртуализации Wow64

Если существуют определенные сценарии, в которых приложения должны определить, работают ли они в эмуляторе WoW64, они должны сделать это путем вызова IsWow64Process.

Conclusion

По мере развития этих требований мы отразим изменения в приведенном ниже журнале изменений. Стабильные требования критически важны для эффективной работы, поэтому мы будем стремиться обеспечить устойчивость изменений, которые мы делаем, и продолжать защищать и улучшать ваши приложения.

Благодарим вас еще раз за присоединение к нашей приверженности обеспечению большого опыта работы с клиентами.

Журнал редакций

Дополнительные сведения о сертификации настольных приложений

См. также

• Программа сертификации оборудования Windows
• Использование комплекта сертификации приложений Для Windows