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

Относится к:

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

Примечание

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

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

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

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

Чтобы изменить параметры правил политики существующей политики WDAC 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, так как он позволяет протестировать новые политики WDAC перед их выполнением. В режиме аудита приложение не блокируется, вместо этого политика регистрировала событие всякий раз, когда приложение за пределами политики было запущено. Чтобы разрешить эти приложения, можно захватить сведения о политике из журнала событий, а затем объединить эти сведения в существующую политику. При удалении режима Enabled:Audit политика выполняется в принудительном режиме.

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

Правило Описание Допустимый дополнительный параметр
0 Enabled:UMCI (0 включено:UMCI) Политики WDAC предполагают ограниченное использование двоичных файлов в режиме ядра и пользовательском режиме. По умолчанию ограничено использование только двоичных файлов в режиме ядра. Если это правило активно, выполняется проверка исполняемых файлов и скриптов в пользовательском режиме. Нет
1 Enabled:Boot Menu Protection (1 включено: защита меню загрузки) Этот параметр в настоящее время не поддерживается. Нет
2 Required:WHQL (2 Требуется:WHQL) По умолчанию разрешено выполнять устаревшие драйверы, которые не Windows лаборатории качества оборудования (WHQL). Если это правило активно, каждый выполняемый драйвер должен иметь подпись WHQL; поддержка устаревших драйверов прекращается. Драйверы ядра, Windows 10 должны быть сертифицированы в WHQL. Нет
3 Enabled:Audit Mode (Default) (3 Включено: режим аудита (по умолчанию)) Предписывает WDAC входить в журнал сведений о приложениях, сеяных и скриптах, которые были бы заблокированы, если бы политика была применена. С помощью этого параметра можно определить потенциальное влияние политики WDAC и использовать события аудита для уточнения политики перед исполнением. Чтобы применить политику WDAC, удалите этот параметр. Нет
4 Disabled:Flight Signing (4 отключено: подпись тестовых пакетов) Если включено, политики WDAC не будут доверять бинам, подписанным на рейс. Этот параметр будет использоваться организациями, которые хотят запускать только выпущенные binaries, а не 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 и интерактивные PowerShell больше не ограничиваются режимом ограниченного языка.
ПРИМЕЧАНИЕ. Этот параметр необходим для запуска HTA-файлов и поддерживается на сборках 1709, 1803 и 1809 с LCU 10C 2019 и выше, а также на устройствах с обновление Windows 10 за май 2019 г. (1903) и выше. Использование его в версиях Windows без надлежащего обновления может иметь непредвиденные результаты.
Нет
12 Required:Enforce Store Applications (12 требуется: применение политик к приложениям Store) Если этот параметр правил включен, политики WDAC будут также применяться к универсальным приложениями для Windows. Нет
13 Enabled:Managed Installer (13 включено: управляемый установщик) Используйте этот параметр, чтобы автоматически разрешить приложения, установленные управляемым установщиком. Дополнительные сведения см. в ссылке Авторизации приложений, развернутых с управляемым установщиком WDAC. Да
14 Enabled:Intelligent Security Graph Authorization (14 включено: авторизация на основе интеллектуальной системы отслеживания) Этот параметр используется, чтобы автоматически давать разрешение "заведомо надежным" приложениям согласно определению интеллектуальной системы отслеживания Майкрософт (ISG). Да
15 Enabled:Invalidate EAs on Reboot (15 включено: аннулирование расширенных атрибутов при перезагрузке) При использовании параметра интеллектуальной системы отслеживания (14) функция 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 Включено:Отозванный истек как неподписаный Используйте этот параметр для обработки разнопланов, подписанных с истекшими и/или отозванными сертификатами, как "Unsigned binaries" для процесса и компонентов в режиме пользователя, в сценариях подписывания предприятия. Нет

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

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

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

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

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

Примечание

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

Список известных SID-адресов администратора 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-11979844-4069167804-127792394; S-1-15-2-95739096-486727260-2033287795-385358803-16855597119-444378811-274666665523.

При создании правил filepath с помощью New-CIPolicy создается уникальное, полностью квалифицированное правило пути для каждого файла, обнаруженного в отсканированном пути (s). Чтобы создать правила, разрешащие все файлы по указанному пути папки, используйте 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, рекомендуется поддерживать отдельные политики ALLOW и DENY в Windows 10 версии 1903 и более поздней версии.

Примечание

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

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

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

В cmdlet PowerShell будут выпускаться hash Authenticode Sha1, Sha256 Hash, Sha1 Page Hash, Sha256 Page Hash. Во время проверки CI будет выбирать, какие хеши рассчитать, в зависимости от того, как файл подписан. Например, если файл с подписью page-hash, весь файл не будет получать страницу, чтобы сделать полный аутентификацию sha256, и мы бы просто совпадали с использованием хаша первой страницы.

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

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

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

Защитник Windows правила управления файлами application Control

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

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

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

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