Общие сведения о правилах политики управления приложениями Защитник Windows (WDAC) и правилах файлов

Применимо к:

  • Windows 10
  • Windows 11
  • Windows Server 2016 и более поздние версии

Примечание.

Некоторые возможности управления приложениями в Защитнике Windows доступны только в определенных версиях для Windows. Узнайте больше о доступности функции управления приложениями в Защитнике Windows.

Защитник Windows управление приложениями (WDAC) может управлять тем, что выполняется в Windows 10 и Windows 11, задавая политики, указывающие, является ли драйвер или приложение доверенным. Политика включает правила политики , управляющие такими параметрами, как режим аудита, а также правила файлов (или уровни правил файлов), определяющие способ идентификации и доверия приложений.

Защитник Windows управление приложениями используется для ограничения устройств для запуска только утвержденных приложений, в то время как операционная система защищается от атак на память ядра с помощью защищенной гипервизором целостности кода (HVCI).

Правила политик управления приложениями в Защитнике Windows

Чтобы изменить параметры правил политики существующего Защитник Windows XML политики управления приложениями, используйте Set-RuleOption. В следующих примерах показано, как использовать этот командлет для добавления и удаления параметра правила в существующей политике WDAC:

  • Чтобы убедиться, что UMCI включен для политики WDAC, созданной с -UserPEs параметром (режим пользователя), добавьте параметр правила 0 в существующую политику, выполнив следующую команду:

    Set-RuleOption -FilePath <Path to policy XML> -Option 0

    Политика, созданная без параметра, -UserPEs не имеет правил для кода пользовательского режима. Если включить UMCI (вариант 0) для такой политики, WDAC заблокит все приложения и даже критически важный код сеанса Windows. В режиме аудита WDAC просто регистрирует событие, но при принудительном применении весь код пользовательского режима будет заблокирован. Чтобы создать политику, включающую исполняемые файлы (приложения) в пользовательском режиме, выполните команду New-CIPolicy с параметром -UserPEs .

  • Чтобы отключить UMCI в существующей политике WDAC, удалите правило 0 с помощью следующей команды:

    Set-RuleOption -FilePath <Path to policy XML> -Option 0 -Delete

В политике WDAC можно задать несколько правил. В таблице 1 описаны все варианты правил и указаны ли в них дополнительные политики. Однако вариант 5 не реализован, так как он зарезервирован для будущей работы, а вариант 7 не поддерживается.

Примечание.

Сначала рекомендуется использовать режим Enabled:Audit, так как он позволяет протестировать новые политики управления приложениями Защитник Windows перед их применением. В режиме аудита приложение не блокируется. Вместо этого политика регистрирует событие при каждом запуске приложения за пределами политики. Чтобы разрешить эти приложения, можно записать сведения о политике из журнала событий, а затем объединить эти сведения в существующую политику. При удалении параметра Enabled:Audit Mode политика выполняется в принудительном режиме.

Таблица 1: Политика управления приложениями в Защитнике Windows: параметры правил политик

Правило Описание Допустимый дополнительный вариант
0 Enabled:UMCI (0 включено:UMCI) Политики WDAC предполагают ограниченное использование двоичных файлов в режиме ядра и пользовательском режиме. По умолчанию ограничено использование только двоичных файлов в режиме ядра. Если это правило активно, выполняется проверка исполняемых файлов и скриптов в пользовательском режиме. Нет
1 Enabled:Boot Menu Protection (1 включено: защита меню загрузки) В настоящее время этот параметр не поддерживается. Нет
2 Required:WHQL (2 Требуется:WHQL) По умолчанию разрешено выполнять устаревшие драйверы, не подписанные Windows Hardware Quality Labs (WHQL). Если это правило активно, каждый выполняемый драйвер должен иметь подпись WHQL; поддержка устаревших драйверов прекращается. Драйверы ядра, созданные для Windows 10, должны иметь сертификат WHQL. Нет
3 Enabled:Audit Mode (Default) (3 Включено: режим аудита (по умолчанию)) Указывает WDAC регистрировать сведения о приложениях, двоичных файлах и сценариях, которые были бы заблокированы, если политика была применена. Этот параметр можно использовать для определения потенциального влияния политики WDAC и использования событий аудита для уточнения политики перед применением. Чтобы применить политику WDAC, удалите этот параметр. Нет
4 Disabled:Flight Signing (4 отключено: подпись тестовых пакетов) Если этот параметр включен, политики WDAC не будут доверять двоичным файлам, подписанным flightroot. Этот параметр будет использоваться организациями, которые хотят запускать только выпущенные двоичные файлы, а не предварительные сборки Windows. Нет
5 Enabled: Inherit Default Policy (5 включено: наследовать политику по умолчанию) Этот параметр зарезервирован для использования в будущем и в настоящее время не действует. Да
6 Enabled:Unsigned System Integrity Policy (Default) (6 включено: неподписанная политика целостности системы (по умолчанию)) Позволяет политике оставаться неподписанной. При удалении этого параметра политика должна быть подписана. Сертификаты, которые являются доверенными для будущих обновлений политики, должны быть определены в разделе UpdatePolicySigners. Да
7 Allowed:Debug Policy Augmented (7 разрешено: расширенная политика отладки) В настоящее время этот параметр не поддерживается. Да
8 Required:EV Signers (8 требуется: подписанты EV) В настоящее время этот параметр не поддерживается. Нет
9 Enabled:Advanced Boot Options Menu (9 включено: меню расширенных параметров загрузки) Предзагрузочное меню F8 отключено по умолчанию для всех политик WDAC. В случае активации этого правила меню F8 будет отображаться физически присутствующим пользователям. Нет
10 Enabled:Boot Audit on Failure (10 включено: аудит при загрузке в случае сбоя) Используется в том случае, если политика WDAC находится в режиме применения политик. В случае сбоя драйвера во время запуска политика WDAC будет переведена в режим аудита, чтобы можно было загрузить Windows. Администраторы могут проверить причину сбоя в журнале событий CodeIntegrity. Нет
11 Disabled:Script Enforcement (11 отключено: применение сценариев) Этот параметр отключает параметры принудительного применения скриптов, охватывающие PowerShell, узел сценариев на основе Windows (wscript.exe), консольный узел сценариев Windows (cscript.exe), HTA-файлы, выполняемые в узле приложения Microsoft HTML (mshta.exe) и MSXML. Дополнительные сведения о принудительном применении скриптов см. в статье Применение скриптов с помощью WDAC.
ПРИМЕЧАНИЕ. Этот параметр не поддерживается в Windows Server 2016 и не должен использоваться в этой операционной системе.
Нет
12 Required:Enforce Store Applications (12 требуется: применение политик к приложениям Store) Если этот параметр правил включен, политики WDAC будут также применяться к универсальным приложениями для Windows. Нет
13 Enabled:Managed Installer (13 включено: управляемый установщик) Используйте этот параметр для автоматического разрешения приложений, установленных управляемым установщиком. Дополнительные сведения см. в статье Авторизация приложений, развернутых с помощью управляемого установщика WDAC. Да
14 Enabled:Intelligent Security Graph Authorization (14 включено: авторизация на основе интеллектуальной системы отслеживания) Используйте этот параметр, чтобы автоматически разрешить приложениям с репутацией "известного качества", как определено в Microsoft Intelligent Security Graph (ISG). Да
15 Enabled:Invalidate EAs on Reboot (15 включено: аннулирование расширенных атрибутов при перезагрузке) При использовании параметра интеллектуальной системы отслеживания (14) функция WDAC устанавливает расширенный атрибут файла, который указывает на то, что файл авторизован для запуска. Этот параметр приведет к тому, что WDAC будет периодически повторно проверять репутацию файлов, которые были авторизованы ISG. Нет
16 Enabled:Update Policy No Reboot (16 включено: обновление политики без перезагрузки) Этот параметр используется, чтобы разрешить применение будущих обновлений политики WDAC без необходимости перезагрузки системы.
ПРИМЕЧАНИЕ. Этот параметр поддерживается только в Windows 10 версии 1709 и выше.
Нет
17 Включено: разрешить дополнительные политики Используйте этот параметр в базовой политике, чтобы разрешить дополнительным политикам его расширение.
ПРИМЕЧАНИЕ. Этот параметр поддерживается только в Windows 10 версии 1903 и выше.
Нет
18 Disabled:Runtime FilePath Rule Protection Этот параметр отключает проверку среды выполнения по умолчанию, которая разрешает правила FilePath только для путей, которые записываются только администратором.
ПРИМЕЧАНИЕ. Этот параметр поддерживается только в Windows 10 версии 1903 и выше.
Да
19 Включено: безопасность динамического кода Обеспечивает принудительное применение политик для приложений .NET и динамически загруженных библиотек.
ПРИМЕЧАНИЕ. Этот параметр поддерживается только в Windows 10 версии 1803 и выше.
Нет
20 Включено: отозвано с истекшим сроком действия как без знака Используйте этот параметр для обработки двоичных файлов, подписанных с истекшим сроком действия и (или) отозванных сертификатов, как "Неподписанные двоичные файлы" для процесса или компонентов пользовательского режима в сценариях подписывания предприятия. Нет

Уровни правил файлов в политиках управления приложениями в Защитнике Windows

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

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

Таблица 2. Политика управления приложениями в Защитнике Windows: уровни правил файлов

Уровень правила Описание
Хэш Указывает отдельные хэш-значения образа Authenticode/PE для каждого обнаруженного двоичного файла. Этот уровень является наиболее конкретным и требует дополнительных усилий для поддержания значений хэша текущих версий продукта. При каждом обновлении двоичного файла изменяется хэш-значение, в связи с чем требуется обновление политики.
FileName (Имя файла) Указывает исходное имя файла для каждого двоичного файла. При обновлении хэш-значения для приложения изменяются, а имена файлов, как правило, нет. Этот уровень обеспечивает менее конкретную безопасность, чем хэш-уровень, но обычно не требует обновления политики при изменении любого двоичного файла.
FilePath Начиная с Windows 10 версии 1903, этот уровень позволяет выполнять двоичные файлы из определенных расположений пути к файлам. Правила FilePath применяются только к двоичным файлам в пользовательском режиме и не могут использоваться для разрешения драйверов режима ядра. Дополнительные сведения о правилах уровня FilePath см. ниже.
SignedVersion (Подписанная версия) Этот уровень объединяет правило издателя с номером версии. Он позволяет выполнять все действия от указанного издателя с версией с указанным номером версии или выше.
Издатель Этот уровень объединяет уровень PcaCertificate (как правило, один сертификат под корнем) и общее имя (CN) конечного сертификата. Этот уровень правила можно использовать для доверия сертификату, выданному определенным ЦС и выданному определенной компании, которой вы доверяете (например, Intel, для драйверов устройств).
FilePublisher (Издатель файла) Этот уровень объединяет атрибут FileName подписанного файла, а также "Publisher" (сертификат PCA с cn of leaf) и минимальный номер версии. Это правило обеспечивает доверие определенным файлам от заданного издателя, если номер версии равен заданному или превышает его.
LeafCertificate (Некорневой сертификат) Добавляет доверенных авторов подписей на индивидуальном уровне сертификата подписи. Преимущество использования этого уровня в сравнении с уровнем отдельных хэш-значений заключается в том, что новые версии продукта будут иметь другие хэш-значения, но, как правило, тот же сертификат подписи. При использовании этого уровня обновление политики для запуска новой версии приложения не требуется. Однако срок действия конечных сертификатов гораздо короче, чем на других уровнях сертификатов, поэтому при каждом изменении этих сертификатов необходимо обновлять политику управления приложениями Защитник Windows.
PcaCertificate (Сертификат PCA) Добавляет наивысший доступный сертификат в предоставленную цепочку сертификатов для подписавших. Этот уровень обычно находится на одном сертификате ниже корневого сертификата, так как проверка не проверяет ничего, кроме сертификатов, включенных в указанную подпись (она не переходит в интернет или не проверяет локальные корневые хранилища).
RootCertificate (Корневой сертификат) Этот уровень может привести к чрезмерно разрешительной политике и не рекомендуется для большинства вариантов использования.
WHQL Доверяет двоичным файлам, если они были проверены и подписаны WHQL. Этот уровень в основном предназначен для двоичных файлов ядра.
WHQLPublisher (Издатель WHQL) Этот уровень объединяет уровень WHQL и CN в конечном сертификате и в основном предназначен для двоичных файлов ядра.
WHQLFilePublisher (Издатель файла WHQL) Указывает, что двоичные файлы проверены и подписаны WHQL, у них есть определенный издатель (WHQLPublisher) и что версия двоичного файла не ниже указанной. Этот уровень в основном предназначен для двоичных файлов ядра.

Примечание.

При создании Защитник Windows политик управления приложениями с помощью New-CIPolicy можно указать уровень правила основного файла, включив параметр -Level. Для обнаруженных двоичных файлов, которые не могут быть включены в список доверия на основании критерий правила основного файла, используется параметр -Fallback (резервный). Например, если уровень правила основного файла — PCACertificate, но вы также хотите доверять неподписанным приложениям, при использовании уровня правила хэша в качестве резервного элемента добавляются хэш-значения двоичных файлов, у которых не было сертификата подписи.

Примечание.

  • WDAC поддерживает только правила подписывания для ключей подписи сертификатов RSA с максимальным числом 4096 бит.
  • Код использует CN для полей CertSubject и CertIssuer в политике. Вы можете использовать certutil папки "Входящие", чтобы просмотреть базовый формат, чтобы убедиться, что UTF-8 не используется для CN. Например, можно использовать печатаемую строку, IA5 или BMP.

Примечание.

Если применимо, минимальный и максимальный номера версий в правиле файла ссылаются на MinimumFileVersion и MaximumFileVersion соответственно в XML-коде политики.

  • Параметр MinimumFileVersion и MaximumFileVersion указан: для правил разрешения разрешен файл с версией , большей или равной MinimumFileVersion и меньшей или равной MaximumFileVersion. Для правил запрета запрещается файл с версией , большей или равной MinimumFileVersion и меньшей или равной MaximumFileVersion.
  • Параметр MinimumFileVersion, указанный без параметра MaximumFileVersion. Для правил разрешить выполнение файла с версией , больше или равной указанной версии. Для правил запрета файл с версией , меньшей или равной указанной версии, блокируется.
  • MaximumFileVersion, указанный без параметра MinimumFileVersion. Для правил разрешить выполнение файла с версией , меньшей или равной указанной версии. Для правил запрета файл с версией , больше или равной указанной версии, блокируется.

Пример использования уровней правил файлов

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

Чтобы создать политику управления приложениями Защитник Windows, они создают эталонный сервер на стандартном оборудовании и устанавливают все программное обеспечение, которое, как известно, выполняется на их серверах. Затем они выполняют New-CIPolicy с -Level Publisher (чтобы разрешить запуск программного обеспечения их поставщиков ПО, "Издателей") и -Fallback Hash (чтобы разрешить запуск внутренних неподписанных приложений). Они развертывают политику в режиме аудита, чтобы определить потенциальное влияние применения политики. С помощью данных аудита они обновляют свои политики WDAC, чтобы включить любое другое программное обеспечение, которое они хотят запустить. Затем они включают политику WDAC в принудительном режиме для своих серверов.

В рамках обычных операций они в конечном итоге устанавливают обновления программного обеспечения или, возможно, добавляют программное обеспечение от одних и того же поставщика программного обеспечения. Так как "Издатель" остается прежним в этих обновлениях и программном обеспечении, ей не нужно обновлять политику WDAC. Если внутреннее приложение без знака обновляется, необходимо также обновить политику WDAC, чтобы разрешить новую версию.

Порядок приоритета правила файлов

Защитник Windows управление приложениями имеет встроенную логику конфликтов правил файлов, которая преобразуется в порядок очередности. Сначала он обработает все явные правила запрета, которые он находит. Затем он обработает все явные правила разрешения. Если правило запрета или разрешения не существует, WDAC проверит наличие управляемого установщика EA. Наконец, если ни один из этих наборов не существует, WDAC вернется к ISG.

Примечание.

Чтобы другие могли лучше понять развернутые политики WDAC, рекомендуется использовать отдельные политики ALLOW и DENY в Windows 10 версии 1903 и более поздних.

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

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

По умолчанию Защитник Windows Application Control выполняет проверку на возможность записи пользователей во время выполнения, которая гарантирует, что текущие разрешения на указанный путь к файлу и его родительским каталогам (рекурсивно) не разрешают доступ на запись стандартным пользователям.

Существует определенный список идентификаторов безопасности, которые WDAC распознает как администраторов. Если путь к файлу разрешает разрешение на запись для любого идентификатора безопасности, отсутствуют в этом списке, путь к файлу считается пригодным для записи пользователем, даже если идентификатор безопасности связан с пользовательским администратором. Для обработки этих особых случаев можно переопределить проверку среды выполнения WDAC, доступную для записи администратором, с помощью описанного выше параметра Disabled:Runtime FilePath Rule Protection .

Список известных идентификаторов безопасности для администраторов WDAC:

S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-16855971919-444378811-2746676523.

Когда правила пути к файлам создаются с помощью New-CIPolicy, для каждого файла, обнаруженного в отсканированных путях, создается уникальное полное правило пути. Чтобы создать правила, которые разрешают все файлы по указанному пути к папке, используйте Командовую команду New-CIPolicyRule для определения правил, содержащих подстановочные знаки, с помощью параметра -FilePathRules .

Подстановочные знаки можно использовать в начале или конце правила пути; Для каждого правила пути допускается только один подстановочный знак. Подстановочные знаки, помещенные в конец пути, рекурсивно разрешают все файлы в этом пути и его подкаталогах (напримерC:\*, ).C:\foo\* Подстановочные знаки, помещенные в начале пути, разрешают точное указанное имя файла по любому пути (например, *\bar.exe разрешает C:\bar.exe и C:\foo\bar.exe). Подстановочные знаки в середине пути не поддерживаются (например, C:\*\foo.exe). Без подстановочного знака правило разрешает только определенный файл (например, C:\foo\bar.exe).

Вы также можете использовать следующие макросы, если точный объем может отличаться: %OSDRIVE%, %WINDIR%, . %SYSTEM32%

Примечание.

При создании политик WDAC с помощью Microsoft Configuration Manager (MEMCM) можно указать MEMCM создать правила для указанных файлов и папок. Эти правила не являются правилами пути к файлам WDAC. Вместо этого MEMCM выполняет однократное сканирование указанных файлов и папок и создает правила для всех двоичных файлов, найденных в этих расположениях во время этой проверки. Изменения файлов в указанных файлах и папках после этого сканирования не будут разрешены, если политика MEMCM не будет применяться повторно.

Примечание.

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

Дополнительные сведения о хэшах

WDAC использует алгоритм хэша образа Authenticode/PE при вычислении хэша файла. В отличие от более популярного, но менее безопасного хэша неструктурированных файлов, вычисление хэша Authenticode пропускает контрольную сумму файла, таблицу сертификатов и таблицу сертификатов атрибутов. Таким образом, хэш Authenticode файла не изменяется при повторной подписи или метке времени или удалении цифровой подписи из файла. С помощью хэша Authenticode WDAC обеспечивает дополнительную безопасность и снижает затраты на управление, поэтому клиентам не нужно пересматривать правила хэша политики при обновлении цифровой подписи в файле.

Хэш изображения Authenticode/PE можно вычислить для файлов с цифровой подписью и без знака.

Почему при сканировании создаются четыре правила хэша для КАЖДОГО XML-файла?

Командлет PowerShell создаст Хэш Sha1 Authenticode, Хэш Sha256, Хэш страниц Sha1, Хэш страниц Sha256. Во время проверки CI выбирает, какие хэши вычислять, в зависимости от того, как файл подписан. Например, если файл подписан хэшом страницы, весь файл не будет выгружаться на страницу для выполнения полного проверки подлинности sha256, и мы просто сопоставим с помощью первого хэша страницы.

В командлетах вместо того, чтобы спрогнозировать, какой хэш будет использовать CI, мы предварительно вычисляем и используем четыре хэша (sha1/sha2 authenticode и sha1/sha2 первой страницы). Этот метод также является устойчивым, если состояние подписи файла изменяется и необходимо для правил запрета, чтобы гарантировать, что изменение или удаление подписи не приведет к хэшу, отличному от того, что было в политике, используемой CI.

Почему при сканировании создаются восемь хэш-правил для определенных XML-файлов?

Для UMCI и KMCI создаются отдельные правила. В некоторых случаях файлы, которые находятся в режиме исключительно пользователя или только в режиме ядра, по-прежнему могут создавать оба набора, так как CI не всегда может точно определить, что является режимом только пользователя и режима ядра, и ошибки на стороне осторожности.

Защитник Windows правила имен файлов для управления приложениями

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

Используйте таблицу 3, чтобы выбрать соответствующий уровень имени файла для вариантов использования. Например, бизнес-приложение или рабочее приложение и его двоичные файлы могут использовать одно и то же название продукта. Этот параметр позволяет легко создавать целевые политики на основе правила имени файла имени продукта.

Табл. 3. Защитник Windows политика управления приложениями — уровни имени файла

Уровень правила Описание
Описание файла Указывает описание файла, предоставленное разработчиком двоичного файла.
Внутреннее имя Задает внутреннее имя двоичного файла.
Исходное имя файла Указывает исходное имя файла или имя, с помощью которого был впервые создан файл двоичного файла.
Имя семейства пакетов Указывает имя семейства пакетов двоичного файла. Имя семейства пакетов состоит из двух частей: имя файла и идентификатор издателя.
Название продукта Указывает имя продукта, с которым поставляется двоичный файл.