Почему Windows показывает сообщение «Windows защитил ваш компьютер»

SmartScreen, подпись кода, сертификаты EV/OV, распространение через MSIX/Store — с практической точки зрения

Когда вы создаёте и распространяете Windows-приложение, одна из первых стен, в которую вы упираетесь, — это предупреждение.

Windows защитил ваш компьютер
Microsoft Defender SmartScreen не позволил запустить нераспознанное приложение.

Когда появляется это предупреждение, пользователи начинают беспокоиться. Разработчики тоже задаются вопросами: «Это же не вирус, почему его блокируют?», «Я подписал код, почему предупреждение всё равно появляется?».

В этой статье мы разбираем предупреждения SmartScreen при распространении Windows-приложений с точки зрения подписи кода, сертификатов EV/OV, MSIX, Microsoft Store, ClickOnce и внутреннего распространения.

1. Эта статья в двух словах

При распространении Windows-приложения подпись кода необходима.
Однако подпись кода — это не волшебная палочка, гарантированно устраняющая предупреждения SmartScreen.

Важно рассматривать три аспекта раздельно.

Примерный ориентир для решения выглядит так.

2. SmartScreen — это не только «проверка на вирусы»

Когда появляется предупреждение SmartScreen, пользователи чувствуют: «это опасное приложение?»

Но SmartScreen не проверяет только «вирус это или нет». Согласно объяснению Microsoft, для загруженных файлов система прежде всего смотрит на следующую информацию о репутации.

Здесь важно то, что у только что созданного файла ещё нет репутации.

Даже если для вас самих это правильное приложение, с точки зрения Windows это «файл, увиденный впервые». Даже при наличии подписи предупреждение SmartScreen может появляться, пока репутация хеша файла или издателя недостаточна.

Иными словами, предупреждение SmartScreen проще понять так:

Это не означает, что файл признан вредоносным.
Но это означает, что Windows пока не считает его достаточно надёжным.

Если не понимать эту разницу, возникают заблуждения вроде «я подписал, но ничего не изменилось» или «я купил сертификат EV, но ничего не поменялось».

3. Что на самом деле гарантирует подпись кода

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

1. Что файл подписан именно тем издателем, который отображается
2. Что после подписи файл не был изменён

И наоборот, следующее подпись напрямую не гарантирует:

• Что приложение абсолютно безопасно
• Что в приложении нет ошибок
• Что предупреждение SmartScreen никогда не появится
• Что корпоративная политика обязательно его разрешит

Тем не менее подпись кода — это практически обязательное требование.

Без подписи пользователи не могут узнать, кто издатель. В корпоративной среде неподписанные файлы могут блокироваться App Control, EDR, Defender, прокси и почтовыми шлюзами. При создании автообновления подпись также важна для проверки подлинности файлов обновления.

Иными словами, подпись кода нужна не только «чтобы убрать предупреждение» — это основа распространения, обновлений, аудита и корпоративного внедрения.

4. «С сертификатом EV предупреждение исчезает с первого раза» — устаревшее представление

Раньше было широко распространено мнение, что использование сертификата EV для подписи кода даёт преимущество в SmartScreen.

Однако сегодня решение купить сертификат EV исключительно ради обхода SmartScreen как минимум рискованно. Согласно текущим материалам Microsoft, поведение, при котором сертификат EV автоматически обходил предупреждение SmartScreen при первой загрузке, больше не действует. Файлы, подписанные EV, как и файлы с сертификатом OV, нужно рассматривать с расчётом на постепенное накопление репутации.

Это не значит, что сертификат EV совсем бессмысленен.

• Более строгая проверка личности ценится при корпоративных закупках
• EV требуется проверкой безопасности со стороны партнёра
• Сертификат EV уже есть, и его продолжают использовать

Если есть такие причины, использовать его можно.

Однако покупать сертификат EV только ради этой цели не рекомендуется:

Купить сертификат EV, чтобы предупреждение SmartScreen исчезло с первого дня

Если цель именно такая, сначала стоит пересмотреть канал распространения, способ подписи, разъяснения для первых пользователей, частоту обновлений и возможность распространения через Store.

5. Варианты подписи

Разберём варианты подписи и распространения, которые часто встречаются при распространении Windows-приложений.

Microsoft Store / MSIX

Если вы распространяете приложение среди обычных пользователей, в первую очередь стоит рассмотреть Microsoft Store.

Особенно выгодно сочетание MSIX и распространения через Store с точки зрения управления сертификатами и предупреждений SmartScreen. Пакеты MSIX, отправленные в Store, переподписываются на стороне Microsoft, что также снижает нагрузку на разработчика по индивидуальной покупке и продлению сертификатов.

Впрочем, не каждое Windows-приложение хорошо подходит для MSIX.

• Активное использование служб Windows
• Требуются драйверы
• Есть shell extension
• Есть устаревшая регистрация COM или активы ActiveX
• Требуются сложные изменения ОС при установке

В таких случаях MSI или традиционный установщик может быть более естественным выбором, чем MSIX.

Azure Artifact Signing

Azure Artifact Signing — это облачная служба подписи кода от Microsoft. Ранее она называлась Trusted Signing.

Её привлекательность в том, что не требуется физический USB-токен и она легко встраивается в CI/CD. Это сильный вариант подписи для распространения вне Store, но существуют условия по регионам и аккаунтам.

По состоянию на 2026 год в документации Microsoft для организаций доступны США, Канада, ЕС и Великобритания, а для индивидуальных разработчиков — США и Канада. Если вы используете её как юридическое лицо или частное лицо в Японии, обязательно проверьте условия доступности. Если использовать её нельзя, реалистичным вариантом становится традиционный сертификат OV для подписи кода.

Кроме того, подпись через Azure Artifact Signing не даёт доверие SmartScreen мгновенно. Как и с сертификатом OV, репутация накапливается по мере распространения.

Сертификат OV для подписи кода

Для разработчиков и компаний в Японии, распространяющих Windows-приложения вне Store, сертификат OV для подписи кода и сегодня остаётся реалистичным выбором.

При использовании сертификата OV пользователю отображается имя издателя. Это явно лучше, чем отсутствие подписи. Однако для новых приложений и новых файлов предупреждение SmartScreen всё же может появляться.

При использовании сертификата OV стоит учитывать следующее:

• Использовать имя издателя постоянно
• Каждый раз подписывать от имени одного и того же издателя
• Не изменять файл после подписи
• Проставлять метку времени
• Проверять не только EXE, но и DLL, MSI, updater
• Подготовить план перехода на момент продления сертификата

Самоподписанный сертификат

Самоподписанный сертификат удобен для разработки и проверки.

Однако для публичного распространения он в основном непригоден. С точки зрения Windows пользователя такой сертификат не является доверенным.

Самоподписанный сертификат можно использовать в следующих средах:

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

Даже при использовании самоподписанного сертификата нужно управлять тем, «когда его удалить», «кто добавил его в доверенные» и «не попадёт ли он случайно в продуктивную среду».

6. Что на практике нужно подписывать

«Я подписал EXE — и на этом всё» — не так это работает.

При распространении Windows-приложения нужно проверить весь набор объектов подписи.

При использовании SignTool в текущем Windows SDK важны параметры /fd и /td. Как правило, указывается SHA256.

signtool sign /fd SHA256 /tr <timestamp-server-url> /td SHA256 /a .\MyApp.exe
signtool verify /pa /v .\MyApp.exe

Ключевой момент — подписывать конечный артефакт.

Если после подписи переписать EXE, заменить файл внутри ZIP или изменить встроенный файл после создания установщика, подпись может сломаться или результат проверки может не совпасть с ожидаемым.

В конвейере сборки этот порядок нужно закрепить:

Сборка
  ↓
Сбор зависимых файлов
  ↓
Создание установщика / пакета
  ↓
Подпись
  ↓
Проверка подписи
  ↓
Запись хешей
  ↓
Распространение

7. Подход в зависимости от способа распространения

Установщик MSI / EXE

При распространении через установщик MSI или EXE обязательно подписывайте файл, который пользователь запускает первым.

Кроме того, пересмотрите как объекты подписи и EXE/DLL, которые размещаются после установки. Даже если подписан только установщик, неподписанный updater или helper, развёрнутый позже, может блокироваться в корпоративной среде.

Круг вопросов примерно фиксирован:

• подписывать сам установщик;
• подписывать также вложенные EXE/DLL;
• выделять в отдельный процесс операции, требующие повышения через UAC;
• проверять updater и service helper как отдельную категорию аудита;
• поддерживать стабильный URL страницы загрузки;
• сообщать имя издателя первым пользователям.

MSIX

MSIX — это способ с сильной целостностью на уровне пакета.

Если возможно распространение через Store, обращение с предупреждениями SmartScreen и управлением сертификатами становится значительно проще. С другой стороны, при внутреннем sideload или распространении вне Store нужно тщательно спроектировать подпись пакета MSIX и доверие к сертификату.

Отметим важные моменты:

• для разработки и проверки годится самоподписанный сертификат;
• для промышленного распространения используйте публично доверенный способ подписи;
• обеспечьте совпадение Publisher в appxmanifest и Subject сертификата;
• закладывайте возможность появления предупреждения SmartScreen при распространении вне Store;
• заранее проверьте, нет ли интеграции с ОС, плохо совместимой с MSIX.

ClickOnce

ClickOnce удобен для распространения .NET-приложений (WinForms/WPF и т. п.) среди обычных пользователей.

Однако сам факт использования ClickOnce не устраняет проблему SmartScreen. Имеют значение путь, по которому пользователь загружает и запускает приложение, подпись манифеста, источник распространения и изменения файлов при обновлении.

При использовании ClickOnce стоит проверить следующее:

• подпись манифеста приложения и манифеста развёртывания;
• управление URL распространения или общей папкой;
• обработку смены сертификата при обновлении;
• не блокируется ли приложение внутренним прокси или Defender;
• разъяснения для пользователя при первой установке.

Сильная сторона ClickOnce — «легко распространять», но если не продумать доверие к издателю и канал распространения до конца, на практике приложение будет блокироваться.

Распространение через xcopy / ZIP

Распространение вида «просто положить папку» или «распаковать ZIP» — простое.

Оно может быть эффективным в закрытом контуре или для внутренних инструментов. Однако для веб-распространения среди обычных пользователей это способ, наиболее подверженный влиянию SmartScreen, Defender и Mark of the Web.

Если вы выбираете распространение через xcopy, стоит соблюдать следующее:

• подписывать EXE/DLL;
• не полагаться только на ZIP — проверять содержимое файлов;
• зафиксировать источник распространения;
• явно указывать версию, хеш, историю изменений;
• если позже добавляется автообновление, включить в него проверку подписи.

Вместо «это просто, потому что мы не создаём установщик» стоит думать так: «мы сами берём на себя ответственность, которую обычно несёт установщик».

Собственный updater

Собственный updater удобен, но сам по себе является границей безопасности.

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

Как минимум проверьте следующее:

• подписывать метаданные обновления;
• включать в метаданные version, hash, size, channel, expiry;
• проверять hash и подпись после загрузки;
• при неудачной проверке останавливаться по принципу fail-closed;
• подготовить процедуру отката;
• определить, как обновляется сам updater;
• отделять продуктивный ключ подписи от среды разработки.

Эту тему проще понять вместе со статьёй «Проектирование безопасности автообновления».

8. Для внутреннего распространения одного SmartScreen недостаточно

Во внутренних приложениях часто встречается заблуждение:

Раз используем только внутри компании, подпись не нужна

Это опасно.

Во внутренней среде задействован не только SmartScreen, но и целый ряд механизмов.

Особенно в средах с App Control for Business важно не только то, «подписан ли файл», но и «разрешён ли этот издатель», «пришёл ли файл через managed installer», «разрешены ли хеш или путь».

Руководство Microsoft по развёртыванию также описывает подход, при котором изменения политики App Control сначала развёртываются в режиме аудита, проверяется соответствие событий блокировки ожиданиям, и только затем переходят в режим принудительного применения.

Для внутреннего распространения реалистично проектировать в таком порядке:

1. Разделить целевые устройства
   - разработчики
   - тестировщики
   - отдельные подразделения
   - вся компания

2. Определить канал распространения
   - Intune
   - GPO + общая папка
   - внутренний портал
   - VDI / RemoteApp
   - ручное распространение в закрытом контуре

3. Определить правила доверия
   - правила по издателю
   - распространение сертификатов
   - managed installer
   - разрешение по хешу
   - разрешение по пути

4. Проверить в режиме аудита
   - что блокируется
   - какие DLL или helper упущены
   - не рассматриваются ли обновления как другие файлы

5. Развернуть поэтапно
   - распространить в малом масштабе
   - смотреть логи
   - корректировать правила разрешений
   - расширять

Суть внутреннего распространения — не обход SmartScreen, а создание канала распространения, объяснимого для Windows.

9. Частые заблуждения и правильный взгляд

10. Как объяснить ситуацию пользователям при первом релизе

У нового приложения предупреждения SmartScreen могут появляться в первые недели и у первых пользователей.

В этот момент просто сказать пользователям «запускайте, даже если появится предупреждение» — плохая практика. В безопасное объяснение стоит включить информацию, которую можно проверить.

Пункты, которые стоит включить в разъяснение:

• официальный URL загрузки;
• отображаемое имя издателя;
• имя файла;
• номер версии;
• дату выпуска;
• при необходимости — хеш SHA-256;
• способ проверить, что файл подписан;
• указание не запускать файлы, полученные из неизвестных источников.

Например, для внутренних пользователей безопасно такое разъяснение:

Это приложение распространяется только со следующей страницы внутреннего портала.
Убедитесь, что отображаемое имя издателя — «ООО ХХХ».
Не запускайте EXE, пересланные по почте вложением или в чате.
Если появилось предупреждение SmartScreen, покажите экран сотрудникам ИТ-отдела.

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

11. Схема принятия решения

При выборе способа распространения проще всего размышлять в таком порядке.

flowchart TD
    A[Распространить Windows-приложение] --> B{Для обычных пользователей?}
    B -->|Да| C{Можно ли выпустить в Microsoft Store?}
    C -->|Да| D[Отдать приоритет Store / MSIX]
    C -->|Нет| E[Подписать сертификатом OV или через Artifact Signing]
    B -->|Нет, для внутреннего использования| F{Есть управление устройствами?}
    F -->|Есть Intune/GPO| G[Подпись + распространение сертификатов + аудит App Control]
    F -->|Управления нет| H[Фиксированный источник распространения + подпись + разъяснение пользователям]
    E --> I[Закладывать начальные предупреждения SmartScreen]
    G --> J[Поэтапное развёртывание начиная с режима аудита]
    H --> J

Первый выбор на практике можно систематизировать так.

12. Минимальный чек-лист

Пункты для проверки перед публикацией и распространением Windows-приложения.

Подпись

• EXE подписан
• DLL подписаны
• MSI или EXE установщика подписан
• updater подписан
• проставлена метка времени
• файл не изменялся после подписи
• проверено через signtool verify

Распространение

• определён официальный URL распространения
• на странице загрузки указано имя издателя
• указаны номер версии и дата выпуска
• заложена вероятность появления начальных предупреждений SmartScreen
• рассмотрена возможность выпуска в Microsoft Store
• при распространении вне Store рассмотрены сертификат OV или Artifact Signing

Обновления

• файлы обновления также подписаны
• при собственном updater метаданные подписаны
• проверяются hash, size, version
• при ошибке происходит остановка по принципу fail-closed
• есть процедура отката

Внутреннее распространение

• проверено наличие Intune / GPO / App Control
• определён способ распространения сертификатов
• проверены события блокировки в режиме аудита
• развёртывание идёт поэтапно по подразделениям
• проверено, что обновления не блокируются повторно

13. Итог

Windows-приложение — это не «создал и готово»: распространяемые файлы должны находиться в «форме, вызывающей доверие» у Windows, у пользователей и у корпоративной политики.

Стоит запомнить следующее:

• SmartScreen учитывает репутацию файлов и издателей;
• подпись кода необходима, но не гарантирует полное отсутствие предупреждений;
• не выбирайте сертификат EV ради мгновенного обхода SmartScreen;
• для массового распространения в первую очередь рассматривайте Microsoft Store / MSIX;
• при распространении вне Store используйте сертификат OV или Artifact Signing и закладывайте начальные предупреждения;
• при внутреннем распространении смотрите не только на SmartScreen, но и на Intune, GPO, App Control;
• проектируйте updater не как функцию распространения, а как границу безопасности продукта.

Одной фразой:

Распространение Windows-приложения — это не вопрос «куда положить», а проектирование того, «как заставить Windows довериться».

Также рекомендуем прочитать

• Руководство по выбору способа распространения Windows-приложения
• Введение в ClickOnce: распространение, обновления, критерии выбора
• Проектирование безопасности автообновления
• Минимальный чек-лист безопасности при разработке Windows-приложений
• Где нужны и не нужны права администратора Windows
• Пределы и практика распространения Windows-приложения одним файлом

Справочные ссылки

• Microsoft Learn: SmartScreen reputation for Windows app developers
• Microsoft Learn: Code signing options for Windows app developers
• Microsoft Learn: Sign your MSIX package - end-to-end guide
• Microsoft Learn: SignTool.exe
• Microsoft Learn: Deploying App Control for Business policies
• Microsoft Learn: Manage approved apps for Windows devices with App Control for Business policy and Managed Installers in Microsoft Intune

Похожие статьи

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

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Почему появляется предупреждение «Windows защитил ваш компьютер»?

Потому что Microsoft Defender SmartScreen ещё не считает этот файл достаточно надёжным. SmartScreen — это не простая проверка на вирусы, а оценка репутации издателя, репутации хеша файла, наличия подписи и канала распространения. С точки зрения Windows только что созданный файл — это «файл, увиденный впервые», поэтому даже подписанный файл может вызывать предупреждение, пока не накопится репутация. Это не означает, что файл признан вредоносным, но означает, что Windows пока не считает его достаточно надёжным.

Исчезнет ли предупреждение SmartScreen, если подписать код?

Не обязательно. Подпись кода гарантирует только две вещи: что файл подписан именно тем издателем, который отображается, и что после подписи файл не был изменён — она не гарантирует полное отсутствие предупреждений. Даже при наличии подписи предупреждение может появляться, пока репутация файла или издателя недостаточна. Тем не менее подпись кода — это практически обязательная основа для распространения, обновлений, аудита и корпоративного внедрения. Без подписи в корпоративной среде файл может блокироваться средствами App Control, EDR или Defender.

Если купить сертификат EV, исчезнет ли предупреждение SmartScreen с первого запуска?

Это устаревшее представление. Согласно текущим материалам Microsoft, поведение, при котором сертификат EV автоматически обходил предупреждение SmartScreen при первой загрузке, больше не действует, и файлы, подписанные EV, как и файлы с сертификатом OV, должны накапливать репутацию постепенно. Смысл использовать EV есть, если он требуется корпоративными закупочными процедурами или проверкой безопасности со стороны партнёра, но покупать сертификат EV исключительно ради обхода SmartScreen не рекомендуется. Для этой цели стоит сначала пересмотреть канал распространения, способ подписи и возможность распространения через Store.

Как распространять приложение, чтобы сократить число предупреждений SmartScreen?

Для широкого распространения среди обычных пользователей в первую очередь стоит рассмотреть Microsoft Store / MSIX. Пакет MSIX, отправленный в Store, повторно подписывается на стороне Microsoft, поэтому это, как правило, самый стабильный канал с точки зрения SmartScreen. Если распространение через Store невозможно, используйте сертификат OV или Azure Artifact Signing, закладывайте вероятность появления предупреждений на начальном этапе и сообщайте пользователям официальный URL загрузки, имя издателя, версию и хеш. Для внутреннего распространения помимо подписи нужно проектировать канал распространения с учётом Intune / GPO / App Control.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.