AppLocker, App Control for Business (WDAC) и распространение бизнес-приложений — пока управление запуском приложений не заблокировало вас

«Установили на компьютер заказчика — приложение не запускается. Двойной щелчок ничего не делает». Когда вы распространяете бизнес-приложение, причиной может быть не только дефект самого приложения, но и управление запуском приложений в среде заказчика. Бывает и так, что exe запускается, а останавливаются только поставляемые вместе с ним DLL или скрипты.

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

Эта статья разбирает управление запуском приложений в Windows с точки зрения той стороны, которая разрабатывает и распространяет приложение. Сначала мы разберём различия между AppLocker, App Control for Business (ранее WDAC, Windows Defender Application Control), Smart App Control и SmartScreen, а затем перейдём к типичным блокировкам, чтению журналов событий и подготовке к распространению. В конце приведена процедура для отдела информационных систем, который внедряет эти механизмы на своих компьютерах.

1. Сначала выводы

• Сначала различите четыре механизма, а затем определите объект по журналу. Предупреждение SmartScreen, управление AppLocker на уровне пользователей и групп, управление App Control на уровне всей машины и защита Smart App Control для личных ПК — это не одно и то же. Для exe или DLL под AppLocker расследование строится вокруг 8004, для App Control — вокруг 3077 и сведений о подписи в 3089. Для скриптов и MSI проверьте и другой журнал.¹²
• На стороне распространения нужно сделать приложение, у которого правила разрешения продолжают совпадать и после обновления. В основе этого — единообразная подпись, охватывающая не только exe, но и DLL, установщик и поставляемые скрипты. Приведите в порядок также сведения об издателе, атрибуты файлов, папку установки и схему автоматического обновления. Даже на ПК, который не находится под корпоративным управлением, Smart App Control может остановить неподписанное приложение.³⁴
• На стороне внедрения нужно дать бизнесу пройти полный цикл в режиме аудита, прежде чем переходить к принудительному режиму. Там, где возможно, выбирайте App Control, а AppLocker используйте там, где требуется, например, управление по пользователям. Нельзя исходить из того, что «у заказчика ПК на Pro, значит, нас это не касается». В Windows 10 2004 и более поздних с KB 5024351 и в Windows 11 для принудительного применения AppLocker не нужна определённая редакция, а App Control поддерживается во всех клиентских редакциях.³⁵

Как читать статью в зависимости от цели

В PowerShell скрипт иногда не блокируется полностью, а работает в режиме ограниченного языка, и отказывает только часть обработки. Эта разница тоже разобрана в главе 4.²

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 36, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Различаем четыре механизма

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

2.1. SmartScreen — единственный механизм, который останавливает предупреждением

SmartScreen предупреждает на основе репутации файла. Он работает по умолчанию, даже если администратор не пишет правил, и обычно пользователь может обойти предупреждение и запустить файл.

Тем не менее если действует политика управления, запрещающая обход предупреждения, SmartScreen становится и фактической блокировкой. Из этого не следует, что «раз это предупреждение, файл всегда можно запустить».

Меры на стороне распространения стоит рассматривать отдельно от того, что заказчик пишет правила разрешения для AppLocker и подобных механизмов. В случае SmartScreen главное — подпись и накопление репутации. Подробно это разобрано в статье «Windows SmartScreen и подпись кода». Разделы 2.2–2.4 ниже — это механизмы, которые не предупреждают, а блокируют запуск.

2.2. AppLocker — ветеран, умеющий управлять по пользователям

На каком основании и чьим запуском он управляет

AppLocker появился в Windows 7. Его правила опираются на атрибуты сертификата подписи кода (издателя), атрибуты файла из метаданных подписи (исходное имя файла и версию), хеш и путь к файлу. Политику можно применять не только ко всему компьютеру, но и к отдельным пользователям и группам.³

Разделите «правила можно создавать» и «правила можно применять»

Требования к редакции понять проще, если разделить эти две вещи. Начиная с KB 5024351 для принудительного применения политики AppLocker не требуется определённая редакция в Windows 10 версии 2004 и более поздних, а также в любой редакции Windows 11.⁵

В более старых версиях Windows, напротив, остаётся разница в зависимости от способа распространения. В средах, включающих Windows 10 старше версии 2004 или Windows Server 2019, сохраняются прежние условия: принудительное применение политики, распространяемой через групповую политику, ограничено редакциями Enterprise и Server, а распространение через MDM работает во всех редакциях.⁵

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

Есть и другое условие, не связанное с редакцией. Если служба Application Identity (AppIDSvc) не запущена, правила не оцениваются. Это вместе с подготовкой к аудиту разобрано в главе 6.

Место AppLocker как средства безопасности

Microsoft прямо указывает, что AppLocker не соответствует критериям обслуживания (servicing criteria) MSRC для средства безопасности. Иными словами, если будет найден способ обхода, сам этот факт не рассматривается как уязвимость. В этом он тоже отличается от App Control, о котором речь ниже.³

2.3. App Control for Business — основной выбор как средство безопасности

Механизм, действующий на всю машину

App Control for Business — современное название механизма, который в Windows 10 входил в состав Device Guard и назывался «настраиваемой целостностью кода». Долгое время его называли WDAC. Его политики применяются ко всей машине и влияют на всех пользователей устройства. Этот механизм спроектирован как средство безопасности в смысле критериев обслуживания MSRC.³

Основания, которые могут использоваться в его правилах, сводятся к следующему.³

Условия использования и способы распространения

Политики можно создавать и применять в любой клиентской редакции Windows 10/11 или в Windows Server 2016 и более поздних. Для распространения можно использовать MDM, например Intune, Configuration Manager или PowerShell. Групповую политику тоже можно использовать, но учтите, что она ограничена форматом одной политики, работающим в Windows Server 2016/2019.³

Как выбирать между ним и AppLocker

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

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

2.4. Smart App Control — управление запуском, которое уже есть на личных ПК

Smart App Control — защитная функция для личных пользователей Windows 11. Во время запуска она проверяет прогноз безопасности от облачного сервиса и наличие действительной подписи. Она блокирует приложения, признанные вредоносными, а также приложения без действительной подписи, доверие к которым подтвердить нельзя.⁴

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

Для стороны распространения важно, что управление запуском действует и на ПК, где отдел информационных систем не писал никакой политики. Малые предприятия и индивидуальные предприниматели среди ваших заказчиков не исключение. Неподписанные приложения могут быть остановлены, и Microsoft сама рекомендует разработчикам подписывать приложения действительным сертификатом. Как выбирать сертификат, разобрано в главе 5.⁴

3. Типичные ситуации, в которых ваше приложение блокируется

Проверяйте не только то, «запускается ли основная программа»: проверьте установку, загрузку DLL, скрипты, подключаемые модули и автоматическое обновление. Ситуации, которые чаще всего создают проблемы при заказной разработке и распространении пакетов, таковы.

Общая причина — основания правил разрешения нестабильны

Общее для всей таблицы — сторона распространения не может стабильно предоставить основания, которые нужны разрешающей стороне: подпись, путь или хеш.

Если подписать только exe, то для неподписанных DLL то же правило издателя использовать нельзя. Если разрешать их отдельными правилами по хешам, правила придётся обновлять всякий раз, когда обновление меняет двоичные файлы. Может казаться, что причина в средствах контроля заказчика, тогда как на самом деле именно состав поставки или способ обновления делают правила хрупкими.

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

4. Устанавливаем по журналам, что произошло

В журнале событий читайте «факт остановки» и «что нужно исправить» как две разные вещи. Точек входа две — журналы под AppLocker и журнал CodeIntegrity, — но важно то, что события App Control записываются и в журнал с именем AppLocker.²

4.1. События AppLocker

Открываем журнал и выбираем тип объекта

Откройте «Просмотр событий», найдя его поиском в меню «Пуск», или введя eventvwr.msc в диалоге «Выполнить».¹

Просмотр событий > Журналы приложений и служб > Microsoft > Windows > AppLocker > EXE and DLL / MSI and Script / Packaged app-Deployment / Packaged app-Execution

В англоязычной версии Windows этот путь выглядит как Applications and Services Logs > Microsoft > Windows > AppLocker.

Чтобы получить эти события через PowerShell, откройте сеанс с правами администратора и выполните следующее. В этом примере извлекаются только аудит и блокировки exe/DLL за последние 24 часа. Скрипты и MSI в него не входят.

# Извлекаем блокировки (8004) и аудит (8003) AppLocker за последние 24 часа
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-AppLocker/EXE and DLL'
    Id        = 8003, 8004
    StartTime = (Get-Date).AddDays(-1)
} | Format-List TimeCreated, Id, Message

Совпало с правилом запрета или не хватает правила разрешения?

Событие фиксирует путь рассматриваемого файла, результат (разрешено или заблокировано), тип правила (путь, хеш или издатель), имя правила и SID пользователя или группы.¹

Однако при работе по списку разрешённых чаще всего встречается неявный запрет, когда файл не совпал ни с одним правилом разрешения.

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

4.2. События App Control for Business (WDAC)

exe, DLL и драйверы находятся в другом журнале, чем скрипты

Для контроля exe-файлов, DLL и драйверов проверяйте журнал CodeIntegrity ниже. Контроль MSI, скриптов и COM записывается в журнал AppLocker - MSI and Script, упомянутый выше.²

Просмотр событий > Журналы приложений и служб > Microsoft > Windows > CodeIntegrity > Operational (в англоязычной версии Windows: Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational)

# Смотрим блокировки (3077) и аудит (3076) App Control вместе с соответствующей информацией о подписи (3089)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id        = 3076, 3077, 3089
    StartTime = (Get-Date).AddDays(-1)
} | Sort-Object TimeCreated | Format-List TimeCreated, Id, Message

Эта команда извлекает события CodeIntegrity 3076, 3077 и 3089. Когда вы разбираете MSI, скрипты или COM, проверьте отдельно и журнал AppLocker - MSI and Script по таблице ниже. Пока неясно, какой механизм задействован, сопоставляйте журналы под AppLocker и CodeIntegrity за один и тот же интервал времени.

По 3089 проверяем, какая подпись была фактически оценена

Событие 3089 создаётся по одной подписи файла. Для неподписанного файла создаётся одно событие с числом подписей, равным нулю. С 3076, 3077 и другими оно сопоставляется по correlation Activity ID.²

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

Даже при 8029 PowerShell не обязательно останавливается полностью

Событие 8029 указывает на блокировку скрипта, но фактическое поведение принудительного применения зависит от узла скриптов. PowerShell не останавливает скрипт, который не разрешён политикой, полностью, а выполняет его в режиме ограниченного языка (Constrained Language Mode).²

В этом режиме создание объектов .NET широко ограничено. В результате возникает симптом «скрипт начал выполняться, но одна строка в середине отказала». При разборе поставляемого скрипта не судите только по тому, запустился ли он. Практическая сторона подписи описана в статье «Политика выполнения PowerShell и подпись скриптов».

Учтите также, что в редакции Windows Server Core журнала AppLocker - MSI and Script нет. При разборе приложения на сервере нужно обращать внимание и на наличие журнала.²

5. Что может сделать сторона распространения — приложение, для которого легко писать правила

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

Эта подготовка помогает и в случае Smart App Control. Подписанный двоичный файл с накопленной репутацией реже попадает под автоматическую блокировку на личном ПК.⁴

5.1. Когда вы впервые получаете сертификат подписи кода

Выбирайте RSA-сертификат доверенного удостоверяющего центра

Если вы распространяете приложение внешним заказчикам, выбирайте RSA-сертификат подписи кода, выпущенный публичным (коммерческим) удостоверяющим центром. Самоподписанный сертификат или сертификат внутреннего удостоверяющего центра не удастся проверить на ПК заказчика, который не доверяет этому центру, и Smart App Control его тоже не поддерживает.⁶

Проверьте и алгоритм. Проверка подписи в Smart App Control не поддерживает подписи на эллиптических кривых (ECC). Если подписать через ECC, на личных ПК файл может рассматриваться как фактически неподписанный.⁶

В App Control тоже правила на основе подписанта поддерживают только RSA (до 4096 бит). Если попытаться разрешить подпись ECDSA правилом издателя, в соответствующем событии 3089 будет записано VerificationError = 23. Выбор ECC только потому, что «ECC новее и надёжнее», создаёт проблему совместимости с управлением запуском.⁷

Для правил издателя подходят и OV, и EV

Сертификаты публичных удостоверяющих центров бывают OV, подтверждающие существование организации, и EV с более строгой проверкой. Правила издателя AppLocker и App Control можно построить на любом из этих сертификатов.

В App Control есть параметр правила Required:EV Signers, но в официальной документации сказано, что в настоящее время он не поддерживается. Поэтому выбирать EV ради рассмотренного здесь управления запуском нет причин. Связь со SmartScreen отдельно разобрана в статье «Windows SmartScreen и подпись кода».⁷

Заложите в бюджет не только цену сертификата, но и хранение закрытого ключа и операции подписи

Стоимость зависит от удостоверяющего центра и срока действия. В смете проверьте, помимо самого сертификата, цену токена или HSM либо облачного сервиса подписи от удостоверяющего центра.

Для сертификатов, выпущенных 1 июня 2023 года или позже, требования CA/Browser Forum означают, что независимо от OV или EV закрытый ключ должен быть сгенерирован и храниться в аппаратном средстве, соответствующем FIPS 140-2 уровня 2 или эквивалентному (HSM или USB-токен).⁸

Если вы подписываете автоматически в CI/CD, облачный сервис подписи часто настроить проще, чем физический токен. Перед покупкой сертификата практически полезно обсудить и то, как будет устроен процесс от сборки до подписи.

Подпишите каждый двоичный файл и добавьте отметку времени

Настройте подписи Authenticode не только на exe, но и на собственных сборках DLL, установщике (MSI или setup exe) и поставляемых скриптах. При наличии метаданных подписи заказчик может создать устойчивые к обновлениям правила вида «разрешить этот продукт этого издателя независимо от версии».³

Отметка времени добавляется, чтобы подпись оставалась действительной после истечения срока действия сертификата. Ниже — минимальный пример с signtool из Windows SDK.

:: Подписываем файл (хеш SHA-256 и отметка времени RFC 3161)
signtool sign /fd sha256 /tr <URL сервера отметок времени> /td sha256 /a MyApp.exe

:: Проверяем подпись (проверка по политике Authenticode с выводом подробностей)
signtool verify /pa /v MyApp.exe

Используйте URL сервера отметок времени, который указан вашим удостоверяющим центром. Если вы используете ключ на токене или в HSM, проверьте в инструкции центра и указание CSP/KSP. DLL и установщики подписываются той же командой, поэтому сделайте подпись и проверку всего последним шагом сборки.

5.2. Изменения сертификата и атрибутов файлов — это изменения правил заказчика

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

В App Control Publisher — это «сертификат PCA (обычно на один уровень ниже корневого) плюс CN листового сертификата», а FilePublisher дополнительно объединяет с этим атрибут FileName подписанного файла (по умолчанию OriginalFileName) и минимальную версию.⁷

Для заказчика такие изменения выглядят как «после обновления перестало запускаться только в этой среде». Когда вы меняете написание названия компании, удостоверяющий центр или атрибуты продукта и файлов, включите в примечания к выпуску сопоставление старых и новых сведений о подписи (subject, выпускающий центр) и предупредите заранее. Тогда отдел информационных систем заказчика сможет добавить или обновить правила разрешения.

5.3. Стабилизируйте папку установки и схему автоматического обновления

Размещайте исполняемые файлы в Program Files и избегайте решений, которые во время работы распаковывают exe или DLL в %TEMP% или %APPDATA% и запускают их оттуда. Решение, выполняющее код из места, доступного пользователю на запись, плохо сочетается со средами, работающими на правилах путей.

При автоматическом обновлении подписывайте сам пакет обновления, чтобы подписанный двоичный файл заменялся подписанным двоичным файлом. Подробности безопасного проектирования — в статье «Проектирование безопасности автоматического обновления».

При распространении через Intune или Configuration Manager, если заказчик настроил агент распространения как managed installer, двоичные файлы, пришедшие этим путём, можно разрешать в рабочем порядке. Распространение через Intune не разрешает их автоматически; обязательным условием является явная настройка администратором. Если предоставить MSI с поддержкой тихой установки, эта возможность окажется в руках заказчика.

5.4. Включите в руководство по внедрению информацию, нужную для создания правил

В руководстве по внедрению, которое вы передаёте заказчику, укажите subject подписи, список необходимых для работы двоичных файлов и пути установки. Это основания, по которым отдел информационных систем строит правила разрешения.

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

6. Ключевые моменты для стороны внедрения (отдела информационных систем)

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

6.1. Выбирайте технологию по назначению и подготовьте условия для аудита

По умолчанию это App Control for Business. Используйте вместе с ним AppLocker, когда требуется управление по пользователям на общем ПК или когда в парке есть старые операционные системы.³ Для ПК с фиксированным назначением, например киосков, сначала сузьте назначение ограничением оболочки — правила станут проще. Смотрите также «Киоск-режим и назначенный доступ».

Аудит собирает «то, что было бы заблокировано при принудительном режиме», не останавливая работу бизнеса. В AppLocker обязательна работающая служба AppIDSvc; если служба остановлена, событий аудита тоже не будет. Настройте её автоматический запуск на целевых машинах до начала.

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

6.2. AppLocker переходит от аудита к принудительному режиму в три шага

1. Включите режим аудита. В редакторе управления групповыми политиками (локально — secpol.msc) откройте Конфигурация компьютера > Политики > Конфигурация Windows > Параметры безопасности > Политики управления приложениями > AppLocker. Щёлкните AppLocker правой кнопкой, откройте Свойства, выберите «Настроено» для каждого набора правил (правила для исполняемых файлов, правила установщика Windows, правила для скриптов, правила для упакованных приложений) и установите «Только аудит». Создайте в каждом наборе правила по умолчанию и настройте автоматический запуск AppIDSvc.

2. Собирайте события из журнала, соответствующего объекту. Для exe и DLL это 8003 в EXE and DLL, для скриптов и MSI — 8006 в MSI and Script. Команда из раздела 4.1 охватывает только EXE and DLL, поэтому 8006 она не соберёт. Чтобы увидеть оба, извлекайте журналы по отдельности, как показано ниже.¹

    # Собираем в режиме аудита «то, что было бы заблокировано при принудительном режиме», из двух журналов
    $since = (Get-Date).AddDays(-7)
    $collections = @(
        @{ LogName = 'Microsoft-Windows-AppLocker/EXE and DLL';    Id = 8003 }
        @{ LogName = 'Microsoft-Windows-AppLocker/MSI and Script'; Id = 8006 }
    )
    foreach ($c in $collections) {
        Get-WinEvent -FilterHashtable ($c + @{ StartTime = $since }) -ErrorAction SilentlyContinue |
            Select-Object TimeCreated, LogName, Id, Message
    }
   

   Поскольку для журнала без подходящих событий Get-WinEvent возвращает ошибку, в этом примере добавлен -ErrorAction SilentlyContinue. Если вывода нет, проверьте состояние службы, нужный журнал и период выборки. Если в область входят и упакованные приложения, добавьте Packaged app-Deployment и Packaged app-Execution в той же форме и проверьте вплоть до месячных и годовых пакетных заданий.

3. Приведите в порядок правила разрешения и переключитесь на принудительный режим. Просмотрите критичные для бизнеса файлы, попавшие в 8003 и 8006, и внесите их в правила разрешения. Затем в том же окне свойств измените режим на «Применять правила». После переключения следите за блокировками в 8004 (exe/DLL) и 8007 (скрипты и MSI).

6.3. В App Control переходят к принудительному режиму, убирая параметр аудита

Распространите политику с параметром правила 3 (Enabled:Audit Mode) в XML политики. Для его установки используйте мастер политик App Control или командлет Set-RuleOption.⁷

Проверьте влияние на бизнес по 3076 и 8028, приведите в порядок правила разрешения, а затем удалите параметр аудита — и режим станет принудительным. Microsoft также рекомендует сначала проверять новую политику в режиме аудита.⁷

6.4. Свяжите исключения для неподписанных приложений с учётом активов

Старые бизнес-приложения, которые остаются неподписанными, регистрируются как исключения правилами по хешам и управляются таким образом. Этот список — ещё и список активов, подлежащих замене. Не останавливайтесь на создании исключения: свяжите его с учётом активов и пересматривайте каждый год.

7. Итоги

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

SmartScreen в основном предупреждает, но при политике, запрещающей обход, он становится блокировкой. Рассматривайте его отдельно от AppLocker, App Control и Smart App Control. Ограничения AppLocker по редакциям ослаблены, а App Control работает во всех клиентских редакциях. Smart App Control действует и на личных ПК, поэтому «у них Pro» или «у них нет отдела информационных систем» не делает его неактуальным.⁵³⁴

Когда что-то не запускается, используйте как точки входа AppLocker 8004 и App Control 3077 и 3089, а также сверяйтесь с журналами скриптов и MSI. Когда отказывает только часть функций, проверьте и режим ограниченного языка PowerShell.¹²

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

Сторона внедрения даёт бизнесу пройти полный цикл по AppLocker 8003 и 8006 и App Control 3076 и 8028, прежде чем переходить к принудительному режиму. Если выстроены и распространение, и эксплуатация, случаев «работает только не в среде заказчика» становится меньше.

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

• Почему в Windows появляется «Windows защитил ваш компьютер»
• Проектирование безопасности автоматического обновления — почему одного HTTPS недостаточно
• Как выбрать способ распространения приложений Windows — MSI/MSIX/ClickOnce/xcopy/собственный updater
• Политика выполнения PowerShell и подпись скриптов — практическое руководство по отказу от «закрывания вопроса через Bypass»
• Разбор ложных срабатываний (False Positive) Microsoft Defender
• Киоск-режим Windows и назначенный доступ
• Реальные варианты после окончания поддержки Windows 10 — таблица решений по ESU, LTSC и замене

Смежные области консультаций

Компания KomuraSoft LLC занимается разработкой и доработкой бизнес-приложений, работающих в средах управления запуском (AppLocker / App Control for Business), проектированием распространения и автоматического обновления со встроенной подписью кода, а также разбором случаев, когда приложение не запускается в среде заказчика.

• Разработка приложений для Windows
• Доработка и сопровождение существующего ПО для Windows
• Разбор дефектов и анализ причин
• Связаться с нами

Справочные материалы

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

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

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

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

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

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

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

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

Разве AppLocker нельзя использовать в редакции Pro?

Это распространённое убеждение устарело. Начиная с KB 5024351 принудительное применение политики AppLocker больше не требует определённой редакции в Windows 10 версии 2004 и более поздних и в любой редакции Windows 11. Прежнее ограничение — «принудительное применение политики, распространяемой через групповую политику, ограничено редакциями Enterprise и Server» — относится только к версиям Windows 10 старше 2004 и к Windows Server 2019 (и даже там распространение через MDM работает во всех редакциях). Теперь AppLocker — реальный вариант и для среды, построенной в основном на машинах Pro малого бизнеса.

Стоит ли покупать сертификат подписи кода EV?

С точки зрения правил издателя AppLocker и App Control for Business правило на основе сведений о подписанте можно написать и с сертификатом OV (проверка существования организации), и с сертификатом EV. Учтите также, что убеждение «с EV предупреждение SmartScreen исчезает с самого первого запуска» устарело: файл, подписанный EV, теперь нужно рассматривать так же, как подписанный OV, — исходя из накопления репутации (этот вопрос разобран в отдельной статье «Windows SmartScreen и подпись кода»). Важнее типа сертификата — подписывать каждый двоичный файл единообразным subject: не только exe, но и DLL, и установщик, — добавлять отметку времени и сохранять сведения об издателе стабильными при обновлении сертификата. Правила издателя пишутся на основе этих сведений о подписанте, поэтому если состояние подписи меняется от выпуска к выпуску, правила на стороне заказчика ломаются.

Кажется, наше приложение заблокировали в среде заказчика, но в журнале ничего не удаётся найти. Где смотреть?

Обычная причина в том, что нужный журнал разделён на два семейства. Блокировка exe или DLL средствами AppLocker отображается как событие 8004 (8003 в режиме аудита) в журнале «AppLocker - EXE and DLL», а скрипты и MSI — как 8007 (8006 в режиме аудита) в журнале «AppLocker - MSI and Script». Блокировка средствами App Control for Business (WDAC), напротив, отображается как событие 3077 (3076 в режиме аудита) в журнале «CodeIntegrity - Operational», а соответствующие сведения о подписи записываются в 3089. Кроме того, когда скрипт, MSI или COM-объект попадает под App Control, он появляется в журнале «AppLocker - MSI and Script» как 8029, 8036 или 8040. Когда вы разбираетесь, не зная, какой механизм работает, выстройте CodeIntegrity - Operational и всё содержимое AppLocker по времени и сравните.

Что нужно, чтобы Smart App Control не блокировал наше приложение?

На практике — подпись кода. При запуске приложения Smart App Control проверяет, может ли облачный сервис безопасности предсказать, что приложение безопасно, и есть ли у приложения действительная подпись, и блокирует приложения, признанные вредоносными, а также неподписанные приложения, доверие к которым подтвердить нельзя. В рекомендациях Microsoft для разработчиков также указано подписывать приложение действительным сертификатом. Однако на алгоритм подписи нужно обратить внимание: проверка подписи в Smart App Control не поддерживает подписи на эллиптических кривых (ECC), и запуск разрешён приложениям, подписанным сертификатом на основе RSA. Smart App Control — не средство корпоративного управления, а защита для личных пользователей Windows 11, и она включается или отключается автоматически начиная с режима оценки, поэтому со стороны распространения безопасно исходить из того, что неподписанный исполняемый файл может не запуститься на личном ПК.

Об авторе

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

Го Комура

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

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