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

Примечание.

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

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

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

Чтобы изменить параметры правил политики существующего XML-файла политики WDAC, используйте мастер политики WDAC или командлет PowerShell Set-RuleOption .

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

Примечание.

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

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

Таблица 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 отключено: подпись тестовых пакетов) Если этот параметр включен, двоичные файлы из сборок программы предварительной оценки Windows не являются доверенными. Этот параметр полезен для организаций, которые хотят запускать только выпущенные двоичные файлы, а не предварительные сборки Windows. Нет
5 Enabled: Inherit Default Policy (5 включено: наследовать политику по умолчанию) Этот параметр зарезервирован для использования в будущем и в настоящее время не действует. Да
6 Enabled:Unsigned System Integrity Policy (Default) (6 включено: неподписанная политика целостности системы (по умолчанию)) Позволяет политике оставаться неподписанной. При удалении этого параметра политика должна быть подписана, а все дополнительные политики также должны быть подписаны. Сертификаты, которые являются доверенными для будущих обновлений политики, должны быть определены в разделе UpdatePolicySigners. Сертификаты, которые являются доверенными для дополнительных политик, должны быть определены в разделе SupplementalPolicySigners. Нет
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 или Windows 10 1607 LTSB и не должен использоваться в этих операционных системах.		 Нет
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 или Windows Server 2019 и более поздних версий.		 Нет
17 Включено: разрешить дополнительные политики Используйте этот параметр в базовой политике, чтобы разрешить дополнительным политикам его расширение.
ПРИМЕЧАНИЕ. Этот параметр поддерживается только в Windows 10 версии 1903 или Windows Server 2022 и более поздних версий.		 Нет
18 Disabled:Runtime FilePath Rule Protection Этот параметр отключает проверка среды выполнения по умолчанию, который разрешает правила FilePath только для путей, доступных только администратору.
ПРИМЕЧАНИЕ. Этот параметр поддерживается только в Windows 10 версии 1903 или Windows Server 2022 и более поздних версий.		 Да
19 Включено: безопасность динамического кода Обеспечивает принудительное применение политик для приложений .NET и динамически загруженных библиотек.
ПРИМЕЧАНИЕ. Этот параметр поддерживается только в Windows 10 версии 1803 и более поздних версий или Windows Server 2019 и более поздних версий.
ПРИМЕЧАНИЕ. Этот параметр всегда применяется, если его включает любая политика WDAC UMCI. Режим аудита для усиления защиты динамического кода .NET не существует.		 Нет
20 Включено: отозвано истекло как без знака Используйте этот параметр для обработки двоичных файлов, подписанных с отозванными сертификатами, или сертификатов с истекшим сроком действия с EKU для подписи в подписи как "Неподписанные двоичные файлы" для процесса или компонентов пользовательского режима в сценариях подписывания предприятия. Нет
Включено: динамическое доверие к коду в режиме разработчика Используйте этот параметр, чтобы доверять приложениям UWP, которые отлаживаются в Visual Studio или развернуты на портале устройств, когда в системе включен режим разработчика. Нет

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

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

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

Примечание.

Правила на основе подписывания WDAC работают только с шифрованием RSA. Алгоритмы ECC, такие как ECDSA, не поддерживаются. Если вы попытаетесь разрешить файлы с помощью подписи на основе подписей ECC, вы увидите VerificationError = 23 в соответствующих событиях сведений о сигнатуре 3089. Вместо этого файлы могут быть разрешены правилами хэша или атрибутов файлов или с помощью других правил подписи, если файл также подписан с помощью подписей с помощью RSA.

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

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

Примечание.

При создании политик WDAC с помощью 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. Для правил разрешить выполнение файла с версией , меньшей или равной указанной версии. Для правил запрета файл с версией , больше или равной указанной версии, блокируется.

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

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

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

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

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

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

Примечание.

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

Использование -SpecificFileNameLevel с правилами уровня FileName, FilePublisher или WHQLFilePublisher

По умолчанию уровни правил FileName, FilePublisher и WHQLFilePublisher используют атрибут OriginalFileName из заголовка ресурса файла. Для правил можно использовать альтернативный атрибут заголовка ресурса, задав -SpecificFileNameLevel. Например, разработчик программного обеспечения может использовать одно и то же ProductName для всех двоичных файлов, которые являются частью приложения. С помощью -SpecificFileNameLevel можно создать одно правило, которое будет охватывать все эти двоичные файлы в политике, а не отдельные правила для каждого файла.

В таблице 3 описаны доступные параметры атрибутов заголовка ресурса, которые можно задать с помощью -SpecificFileNameLevel.

Табл. 3. Параметры -SpecificFileNameLevel

Значение SpecificFileNameLevel Описание
FileDescription Указывает описание файла, предоставленное разработчиком двоичного файла.
InternalName Задает внутреннее имя двоичного файла.
OriginalFileName Указывает исходное имя файла или имя, с помощью которого был впервые создан файл двоичного файла.
PackageFamilyName Указывает имя семейства пакетов двоичного файла. Имя семейства пакетов состоит из двух частей: имя файла и идентификатор издателя.
Productname Указывает имя продукта, с которым поставляется двоичный файл.
Filepath Указывает путь к двоичному файлу.

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

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

Пути к файлам, доступные для записи пользователем

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

Существует определенный список идентификаторов безопасности, которые 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 .

Использование подстановочных знаков в правилах пути к файлам WDAC

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

Подстановочный знак Значение Поддерживаемые операционные системы
* Соответствует нулю или нескольким символам. Windows 11, Windows 10 и Windows Server 2022
? Соответствует одному символу. только Windows 11

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

Примечание.

На Windows 11 можно использовать один или несколько подстановочных знаков в любом месте правила пути к файлу.

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

Примеры правил пути к файлам с подстановочными знаками

Примеры: Описание Поддерживаемые операционные системы
C:\windows\*
D:\EnterpriseApps\MyApp\*
%OSDRIVE%\Windows\*		 Подстановочные знаки, помещенные в конец пути, рекурсивно разрешают все файлы в непосредственном пути и его подкаталогах. Windows 11, Windows 10 и Windows Server 2022
*\bar.exe Подстановочные знаки, помещенные в начале пути, допускают точное указанное имя файла в любом расположении. Windows 11, Windows 10 и Windows Server 2022
C:\*\CCMCACHE\*\7z???? -x64.exe
%OSDRIVE%\*\CCMCACHE\*\7z???? -x64.exe		 Подстановочные знаки, используемые в середине пути, разрешают все файлы, соответствующие шаблону. Тщательно рассмотрите все возможные совпадения, особенно если политика отключает проверка с возможностью записи администратора с параметром Disabled:Runtime FilePath Rule Protection . В этом примере оба этих гипотетических пути будут совпадать:
C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe
C:\USERS\WDACUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe		 только Windows 11

Без подстановочного знака правило пути к файлу разрешает только определенный файл (например, C:\foo\bar.exe).

Примечание.

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

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

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

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

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

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

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

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

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

Когда WDAC использует значение хэша неструктурированного файла?

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