Общие сведения о правилах политики управления приложениями для бизнеса и правилах файлов
Примечание.
Некоторые возможности управления приложениями для бизнеса доступны только в определенных версиях Windows. Дополнительные сведения о доступности функций управления приложениями.
Элемент управления приложениями для бизнеса может управлять тем, что выполняется на устройствах Windows, задавая политики, указывающие, является ли драйвер или приложение доверенным. Политика включает правила политики , управляющие такими параметрами, как режим аудита, и правила файлов (или уровни правил файлов), определяющие способ идентификации приложений, которым доверяет ваша организация.
Правила политики управления приложениями для бизнеса
Чтобы изменить параметры правил политики существующего XML-файла политики элемента управления приложениями, используйте мастер политики управления приложениями или командлет PowerShell Set-RuleOption .
В политике управления приложениями можно задать несколько параметров правила. В таблице 1 описаны все параметры правила и возможность их установки дополнительными политиками. Некоторые параметры правил зарезервированы для будущей работы или не поддерживаются.
Примечание.
Мы рекомендуем изначально использовать режим Enabled:Audit, так как он позволяет протестировать новые политики управления приложениями перед их применением. В режиме аудита приложения выполняются в обычном режиме, но элемент управления приложениями регистрирует события при каждом запуске файла, который не разрешен политикой. Чтобы разрешить эти файлы, можно записать сведения о политике из журнала событий, а затем объединить эти сведения в существующую политику. При удалении параметра Enabled:Audit Mode политика выполняется в принудительном режиме.
Некоторые приложения могут работать по-разному, даже если политика находится в режиме аудита. Если параметр может изменить поведение в режиме аудита, это указано в таблице 1. Всегда следует тщательно тестировать приложения при развертывании значительных обновлений политик управления приложениями.
Таблица 1: Политика управления приложениями для бизнеса — параметры правила политики
| Правило | Описание | Допустимый дополнительный вариант |
|---|---|---|
| 0 Enabled:UMCI (0 включено:UMCI) | Политики управления приложениями ограничивают двоичные файлы в режиме ядра и в пользовательском режиме. По умолчанию ограничено использование только двоичных файлов в режиме ядра. Если это правило активно, выполняется проверка исполняемых файлов и скриптов в пользовательском режиме. | Нет |
| 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 Включено: режим аудита (по умолчанию)) | Указывает элементу управления приложениями регистрировать сведения о приложениях, двоичных файлах и сценариях, которые были бы заблокированы, если бы политика была применена. Этот параметр можно использовать для определения потенциального влияния политики управления приложениями и использования событий аудита для уточнения политики перед применением. Чтобы применить политику управления приложениями, удалите этот параметр. | Нет |
| 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 по умолчанию отключено для всех политик управления приложениями. В случае активации этого правила меню F8 будет отображаться физически присутствующим пользователям. | Нет |
| 10 Enabled:Boot Audit on Failure (10 включено: аудит при загрузке в случае сбоя) | Используется, когда политика управления приложениями находится в режиме принудительного применения. При сбое драйвера, критического для загрузки во время запуска, политика управления приложениями помещается в режим аудита, чтобы windows загружала. Администраторы могут проверить причину сбоя в журнале событий CodeIntegrity. | Нет |
| 11 Disabled:Script Enforcement (11 отключено: применение сценариев) | Этот параметр отключает параметры принудительного применения скриптов, охватывающие PowerShell, узел сценариев на основе Windows (wscript.exe), консольный узел сценариев Windows (cscript.exe), HTA-файлы, выполняемые в узле приложений Microsoft HTML (mshta.exe) и MSXML. Некоторые узлы скриптов могут работать по-разному, даже если политика находится в режиме аудита. Дополнительные сведения о принудительном применении скриптов см. в статье Применение скриптов с помощью элемента управления приложениями. ПРИМЕЧАНИЕ. Этот параметр не поддерживается в Windows Server 2016 или Windows 10 1607 LTSB и не должен использоваться в этих операционных системах. |
Нет |
| 12 Required:Enforce Store Applications (12 требуется: применение политик к приложениям Store) | Если этот параметр правила включен, политики управления приложениями также применяются к универсальным приложениям Windows. | Нет |
| 13 Enabled:Managed Installer (13 включено: управляемый установщик) | Используйте этот параметр для автоматического разрешения приложений, установленных управляемым установщиком. Дополнительные сведения см. в статье Авторизация приложений, развернутых с помощью управляемого установщика управления приложениями. | Да |
| 14 Enabled:Intelligent Security Graph Authorization (14 включено: авторизация на основе интеллектуальной системы отслеживания) | Используйте этот параметр, чтобы автоматически разрешить приложениям с репутацией "известного качества", как определено в Microsoft Intelligent Security Graph (ISG). | Да |
| 15 Enabled:Invalidate EAs on Reboot (15 включено: аннулирование расширенных атрибутов при перезагрузке) | При использовании параметра Intelligent Security Graph (14) элемент управления приложениями задает расширенный атрибут файла, указывающий, что файл был авторизован на выполнение. Этот параметр позволяет элементу управления приложениями периодически повторно проверять репутацию файлов, ранее авторизованных ISG. | Нет |
| 16 Enabled:Update Policy No Reboot (16 включено: обновление политики без перезагрузки) | Используйте этот параметр, чтобы разрешить применение будущих обновлений политики управления приложениями без необходимости перезагрузки системы. ПРИМЕЧАНИЕ. Этот параметр поддерживается только в 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 и более поздних версий. ПРИМЕЧАНИЕ. Этот параметр всегда применяется, если любая политика UMCI управления приложениями включает его. Режим аудита для усиления защиты динамического кода .NET не существует. |
Нет |
| 20 Включено: отозвано истекло как без знака | Используйте этот параметр для обработки двоичных файлов, подписанных с отозванными сертификатами, или сертификатов с истекшим сроком действия с EKU для подписи в подписи как "Неподписанные двоичные файлы" для процесса или компонентов пользовательского режима в сценариях подписывания предприятия. | Нет |
| Включено: динамическое доверие к коду в режиме разработчика | Используйте этот параметр, чтобы доверять приложениям UWP, которые отлаживаются в Visual Studio или развернуты на портале устройств, когда в системе включен режим разработчика. | Нет |
Уровни правил файлов управления приложениями для бизнеса
Уровни правил файлов позволяют администраторам определять уровень доверия для своих приложений. Этот уровень доверия может быть таким же детализированным, как хэш каждого двоичного файла, или общим, как сертификат ЦС. Уровни правил файлов указываются при использовании мастера управления приложениями или командлетов PowerShell управления приложениями для создания и изменения политик.
Каждый уровень правила файла имеет свои преимущества и недостатки. Используйте таблицу 2, чтобы выбрать соответствующий уровень защиты для доступных административных ресурсов и сценария развертывания управления приложениями.
Примечание.
Правила на основе элемента управления приложениями работают только с шифрованием RSA с максимальной длиной ключа 4096 бит. Алгоритмы ECC, такие как ECDSA, не поддерживаются. Если вы попытаетесь разрешить файлы с помощью подписи на основе подписей ECC, вы увидите VerificationError = 23 в соответствующих событиях сведений о сигнатуре 3089. Вместо этого файлы могут быть разрешены правилами хэша или атрибутов файлов или с помощью других правил подписи, если файл также подписан с помощью подписей с помощью RSA.
Таблица 2. Политика управления приложениями для бизнеса — уровни правил файлов
| Уровень правила | Описание |
|---|---|
| Хэш | Указывает отдельные хэш-значения образа 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 (Некорневой сертификат) | Добавляет доверенных авторов подписей на индивидуальном уровне сертификата подписи. Преимущество использования этого уровня по сравнению с отдельным хэш-уровнем заключается в том, что новые версии продукта имеют разные значения хэша, но обычно один и тот же сертификат подписи. При использовании этого уровня обновление политики для запуска новой версии приложения не требуется. Однако конечные сертификаты обычно имеют более короткие сроки действия, чем другие уровни сертификатов, поэтому политику управления приложениями необходимо обновлять при каждом изменении этих сертификатов. |
| PcaCertificate (Сертификат PCA) | Добавляет наивысший доступный сертификат в предоставленную цепочку сертификатов для подписавших. Этот уровень обычно находится на одном сертификате ниже корневого каталога, так как проверка не разрешает полную цепочку сертификатов через локальные корневые хранилища или с помощью проверка в Интернете. |
| RootCertificate (Корневой сертификат) | Не поддерживается. |
| WHQL | Доверяет только двоичным файлам, которые были отправлены в корпорацию Майкрософт и подписаны Лабораторией квалификации оборудования Windows (WHQL). Этот уровень в основном предназначен для двоичных файлов ядра. |
| WHQLPublisher (Издатель WHQL) | Этот уровень объединяет уровень WHQL и CN в конечном сертификате и в основном предназначен для двоичных файлов ядра. |
| WHQLFilePublisher (Издатель файла WHQL) | Этот уровень объединяет атрибут FileName подписанного файла, а также WHQLPublisher и минимальный номер версии. Этот уровень в основном предназначен для двоичных файлов ядра. По умолчанию этот уровень использует атрибут OriginalFileName заголовка ресурса файла. Используйте -SpecificFileNameLevel , чтобы выбрать альтернативный атрибут, например ProductName. |
Примечание.
При создании политик управления приложениями с помощью New-CIPolicy можно указать уровень правила основного файла, включив параметр -Level . Для обнаруженных двоичных файлов, которые не могут быть включены в список доверия на основании критерий правила основного файла, используется параметр -Fallback (резервный). Например, если уровень правила основного файла — PCACertificate, но вы также хотите доверять неподписанным приложениям, при использовании уровня правила хэша в качестве резервного элемента добавляются хэш-значения двоичных файлов, у которых не было сертификата подписи.
Примечание.
Если применимо, минимальный и максимальный номера версий в правиле файла ссылаются на MinimumFileVersion и MaximumFileVersion соответственно в XML-коде политики.
- Параметр MinimumFileVersion и MaximumFileVersion указан: для правил разрешения разрешен файл с версией , большей или равной MinimumFileVersion и меньшей или равной MaximumFileVersion. Для правил запрета запрещается файл с версией , большей или равной MinimumFileVersion и меньшей или равной MaximumFileVersion.
- Параметр MinimumFileVersion, указанный без параметра MaximumFileVersion. Для правил разрешить выполнение файла с версией, превышающей указанную версию или равной ей. Для правил запрета файл с версией , меньшей или равной указанной версии, блокируется.
- MaximumFileVersion, указанный без параметра MinimumFileVersion. Для правил разрешить выполнение файла с версией , меньшей или равной указанной версии. Для правил запрета файл с версией , больше или равной указанной версии, блокируется.
Пример использования уровней правил файлов
Например, рассмотрим ИТ-специалиста в отделе, где работает много серверов. Они хотят запускать только программное обеспечение, подписанное компаниями, которые предоставляют свое оборудование, операционную систему, антивирусную программу и другое важное программное обеспечение. Они знают, что на их серверах также выполняется написанное в компании приложение, которое не имеет подписи, но редко обновляется. Они хотят разрешить выполнение этого приложения.
Чтобы создать политику управления приложениями, они создают эталонный сервер на стандартном оборудовании и устанавливают все программное обеспечение, которое, как известно, запущено на их серверах. Затем они выполняют New-CIPolicy с -Level Publisher (чтобы разрешить запуск программного обеспечения их поставщиков ПО, "Издателей") и -Fallback Hash (чтобы разрешить запуск внутренних неподписанных приложений). Они развертывают политику в режиме аудита, чтобы определить потенциальное влияние применения политики. С помощью данных аудита они обновляют свои политики управления приложениями, чтобы включить любое другое программное обеспечение, которое они хотят запустить. Затем они активируют политику управления приложениями в принудительном режиме для своих серверов.
В рамках обычных операций они в конечном итоге устанавливают обновления программного обеспечения или, возможно, добавляют программное обеспечение от одних и того же поставщика программного обеспечения. Так как "Издатель" остается прежним в этих обновлениях и программном обеспечении, им не нужно обновлять политику управления приложениями. Если внутреннее приложение без знака обновляется, необходимо также обновить политику управления приложениями, чтобы разрешить новую версию.
Порядок очередности правил файлов
Элемент управления приложениями имеет встроенную логику конфликтов правил файлов, которая преобразуется в порядок приоритета. Сначала он обрабатывает все явные правила запрета, которые она находит. Затем он обрабатывает все явные правила разрешения. Если правило запрета или разрешения не существует, элемент управления приложениями проверяет наличие утверждения управляемого установщика , если это разрешено политикой. Наконец, управление приложениями возвращается к ISG , если это разрешено политикой.
Примечание.
Чтобы упростить рассуждение по политикам управления приложениями, рекомендуется использовать отдельные политики ALLOW и DENY в версиях Windows, которые поддерживают несколько политик управления приложениями.
Использование -SpecificFileNameLevel с правилами уровня FileName, FilePublisher или WHQLFilePublisher
По умолчанию уровни правил FileName, FilePublisher и WHQLFilePublisher используют атрибут OriginalFileName из заголовка ресурса файла. Для правил можно использовать альтернативный атрибут заголовка ресурса, задав -SpecificFileNameLevel. Например, разработчик программного обеспечения может использовать одно и то же ProductName для всех двоичных файлов, которые являются частью приложения. С помощью -SpecificFileNameLevel можно создать одно правило, которое будет охватывать все эти двоичные файлы в политике, а не отдельные правила для каждого файла.
В таблице 3 описаны доступные параметры атрибутов заголовка ресурса, которые можно задать с помощью -SpecificFileNameLevel.
Табл. 3. Параметры -SpecificFileNameLevel
| Значение SpecificFileNameLevel | Описание |
|---|---|
| FileDescription | Указывает описание файла, предоставленное разработчиком двоичного файла. |
| InternalName | Задает внутреннее имя двоичного файла. |
| OriginalFileName | Указывает исходное имя файла или имя, с помощью которого был впервые создан файл двоичного файла. |
| PackageFamilyName | Указывает имя семейства пакетов двоичного файла. Имя семейства пакетов состоит из двух частей: имя файла и идентификатор издателя. |
| ProductName | Указывает имя продукта, с которым поставляется двоичный файл. |
| Путь к файлу | Указывает путь к двоичному файлу. |
Дополнительные сведения о правилах пути к файлам
Правила пути к файлам не предоставляют те же гарантии безопасности, что и правила явного подписывателя, так как они основаны на разрешениях на изменяемый доступ. Правила пути к файлам лучше всего подходят для сред, в которых большинство пользователей работают как стандартные, а не как администраторы. Правила пути лучше всего подходят для разрешения путей, которые должны оставаться только для записи администратором. Вы можете избежать правил пути для каталогов, в которых стандартные пользователи могут изменять списки управления доступом в папке.
Пути к файлам, доступные для записи пользователем
По умолчанию элемент управления приложениями выполняет проверка возможности записи пользователей во время выполнения, который гарантирует, что текущие разрешения на указанный путь к файлу разрешают доступ на запись только пользователям администрирования.
Существует определенный список идентификаторов безопасности, которые элемент управления приложениями распознает в качестве администраторов. Если путь к файлу разрешает разрешение на запись для любого идентификатора безопасности, отсутствуют в этом списке, путь к файлу считается пригодным для записи пользователем, даже если идентификатор безопасности связан с пользовательским администратором. Для обработки этих особых случаев можно переопределить проверка среды выполнения App Control с помощью описанного выше параметра Disabled:Runtime FilePath Rule Protection.
Список известных идентификаторов безопасности администратора в элементе управления приложениями:
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 .
Использование подстановочных знаков в правилах пути к файлам управления приложениями
В правилах пути к файлам элемента управления приложениями можно использовать следующие подстановочные знаки:
| Подстановочный знак | Значение | Поддерживаемые операционные системы |
|---|---|---|
* |
Соответствует нулю или нескольким символам. | 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\AppControlUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe |
только Windows 11 |
Без подстановочного знака правило пути к файлу разрешает только определенный файл (например, C:\foo\bar.exe).
Примечание.
При создании политик управления приложениями с помощью Configuration Manager можно создать правила для указанных файлов и папок. Эти правила не являются правилами пути к файлу управления приложениями. Вместо этого Configuration Manager выполняет однократное сканирование указанных файлов и папок и создает правила для всех двоичных файлов, найденных в этих расположениях во время этой проверки. Изменения файлов в указанных файлах и папках после этой проверки не будут разрешены, если политика Configuration Manager не будет повторно применяться.
Дополнительные сведения о хэшах
Элемент управления приложениями использует алгоритм хэша образа Authenticode/PE при вычислении хэша файла. В отличие от более известного хэша неструктурированного файла, вычисление хэша Authenticode исключает контрольную сумму файла, таблицу сертификатов и таблицу сертификатов атрибутов. Таким образом, хэш Authenticode файла не изменяется при изменении подписей файла и меток времени или при удалении цифровой подписи из файла. С помощью хэша Authenticode элемент управления приложениями обеспечивает дополнительную безопасность и сокращает затраты на управление, поэтому клиентам не нужно пересматривать правила хэша политики при обновлении цифровой подписи в файле.
Хэш изображения Authenticode/PE можно вычислить для файлов с цифровой подписью и без знака.
Почему при сканировании создаются четыре правила хэша для КАЖДОГО XML-файла?
Командлет PowerShell создает Хэш Sha1 Authenticode, Хэш Sha256, Хэш страниц Sha1, Хэш страниц Sha256. Во время проверки элемент управления приложениями выбирает, какие хэши вычисляются в зависимости от того, как подписан файл и в каком сценарии используется файл. Например, если файл подписан хэшом страницы, элемент управления приложениями проверяет каждую страницу файла и не загружает весь файл в память, чтобы вычислить полный хэш проверки подлинности sha256.
В командлетах вместо того, чтобы спрогнозировать, какой хэш будет использоваться, мы предварительно вычисляем и используем четыре хэша (sha1/sha2 authenticode и sha1/sha2 первой страницы). Этот метод также устойчив к изменениям в способе подписи файла, так как политика управления приложениями уже имеет несколько хэшей, доступных для файла.
Почему сканирование создает восемь хэш-правил для определенных файлов?
Для UMCI и KMCI создаются отдельные правила. Если командлеты не могут определить, что файл выполняется только в пользовательском режиме или в ядре, правила создаются для обоих сценариев подписывания из обилия осторожности. Если вы знаете, что определенный файл загружается только в пользовательском режиме или ядре, вы можете безопасно удалить дополнительные правила.
Когда элемент управления приложениями использует значение хэша неструктурированного файла?
В некоторых редких случаях формат файла не соответствует спецификации Authenticode, поэтому элемент управления приложениями возвращается для использования хэша неструктурированного файла. Такое поведение может происходить по многим причинам, например, если во время выполнения внесены изменения в версию файла в памяти. В таких случаях вы увидите, что хэш, отображаемый в связанном событии сведений о сигнатуре 3089, соответствует хэшу неструктурированного файла из события блока 3076/3077. Чтобы создать правила для файлов с недопустимым форматом, можно добавить хэш-правила в политику для хэша неструктурированных файлов с помощью мастера управления приложениями или путем непосредственного редактирования XML-кода политики.