Развертывание Защитник Windows политик управления приложениями с помощью групповой политики Deploy Windows Defender Application Control policies by using Group Policy

Относится к: Applies to:

• Windows 10 Windows 10
• Windows Server 2016 Windows Server 2016

Групповая политика позволяет легко развертывать политики WDAC и управлять ими. WDAC policies can easily be deployed and managed with Group Policy. Защитник Windows позволяет упростить развертывание Защитник Windows аппаратных функций безопасности и политик Защитник Windows управления приложениями. Windows Defender allows you to simplify deployment Windows Defender hardware-based security features and Windows Defender Application Control policies. Ниже описана процедура развертывания политики WDAC с именем DeviceGuardPolicy.bin в тестовом подразделении под названием DG Enabled PCs с помощью объекта групповой политики Contoso GPO Test. The following procedure walks you through how to deploy a WDAC policy called DeviceGuardPolicy.bin to a test OU called DG Enabled PCs by using a GPO called Contoso GPO Test.

В этом пошаговом руководстве предполагается, что вы уж создали политику WDAC и у вас есть клиентский компьютер с ОС Windows10, на котором будет выполняться пробное развертывание групповой политики. This walkthrough requires that you have previously created a WDAC policy and have a computer running Windows 10 on which to test a Group Policy deployment. Дополнительные сведения о том, как создать политику WDAC, см. в разделе Создание политики управления приложениями в Защитнике Windows на основе эталонного компьютера ранее в этой статье. For more information about how to create a WDAC policy, see Create a Windows Defender Application Control policy from a reference computer, earlier in this topic.

Подписанные политики WDAC могут вызвать ошибки загрузки при развертывании. Signed WDAC policies can cause boot failures when deployed. Рекомендуем тщательно проверить подписанные политики WDAC на каждой аппаратной платформе, прежде чем развертывать их на предприятии. We recommend that signed WDAC policies be thoroughly tested on each hardware platform before enterprise deployment.

Процедура развертывания политики WDAC и управления ей с помощью групповой политики. To deploy and manage a WDAC policy with Group Policy:

На клиентский компьютер, на котором установлен RSAT, откройте GPMC, за запущенный GPMC.MSC On a client computer on which RSAT is installed, open the GPMC by running GPMC.MSC

Создайте новый GPO: щелкните правой кнопкой мыши OU, а затем выберите «Создать GPO в этом домене» и привяжете его сюда. Create a new GPO: right-click an OU and then click Create a GPO in this domain, and Link it here.

Можно использовать любое имя OU. You can use any OU name. Кроме того, фильтрация групп безопасности — это вариант, когда вы рассматриваете различные способы объединения политик WDAC (или с сохранением их в отдельности), как это было рассмотрено в Защитник Windows управления политиками управления приложениями. Also, security group filtering is an option when you consider different ways of combining WDAC policies (or keeping them separate), as discussed in Plan for Windows Defender Application Control policy management.

Введите имя нового объекта групповой политики. Name the new GPO. Вы можете выбрать любое имя. You can choose any name.

Откройте редактор «Управление групповыми политиками»: щелкните правой кнопкой мыши новый объект групповой политики и выберите пункт Изменить. Open the Group Policy Management Editor: right-click the new GPO, and then click Edit.

В выбранном объекте групповой политики перейдите к разделу «Конфигурация компьютера\Административные шаблоны\Система\Device Guard». In the selected GPO, navigate to Computer Configuration\Administrative Templates\System\Device Guard. Щелкните правой кнопкой мыши Развертывание функции управления приложениями в Защитнике Windows и нажмите Изменить. Right-click Deploy Windows Defender Application Control and then click Edit.

В диалоговом окне Развертывание функции управления приложениями в Защитнике Windows выберите параметр Включено и укажите путь для развертывания политики. In the Deploy Windows Defender Application Control dialog box, select the Enabled option, and then specify the code integrity policy deployment path.

При настройке этого параметра политики необходимо указать либо локальный путь к местоположению на клиентском компьютере, где будет размещаться политика, либо UNC-путь, по которому клиентские компьютеры будут запрашивать последнюю версию политики. In this policy setting, you specify either the local path in which the policy will exist on the client computer or a Universal Naming Convention (UNC) path that the client computers will look to retrieve the latest version of the policy. Например, в случае DeviceGuardPolicy.bin на тестовом компьютере примером пути к файлу будет C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin. For example, with DeviceGuardPolicy.bin on the test computer, the example file path would be C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin.

Этот файл политики не требуется копировать на каждый компьютер. This policy file does not need to be copied to every computer. Вместо этого вы можете скопировать политики WDAC в общую папку, которая доступна всем компьютерам. You can instead copy the WDAC policies to a file share to which all computer accounts have access. Любая выбранная на данном этапе политика преобразовывается в SIPolicy.p7b при развертывании на отдельных клиентских компьютерах. Any policy selected here is converted to SIPolicy.p7b when it is deployed to the individual client computers.

Возможно, вы заметили, что параметр GPO ссылается на файл .p7b, а в данном примере используется файл политики .bin. You may have noticed that the GPO setting references a .p7b file and this example uses a .bin file for the policy. Все развертываемые политики, независимо от типа (BIN, P7B или P7), преобразуются в SIPolicy.p7b при передаче на клиентский компьютер с Windows10. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped on the client computer running Windows 10. Сделайте свои политики WDAC совместимыми и позвольте системе самостоятельно преобразовывать имена политик. В этом случае политики будет легко различать при просмотре в общей папке или любом другом централизованном хранилище. Make your WDAC policies friendly and allow the system to convert the policy names for you to ensure that the policies are easily distinguishable when viewed in a share or any other central repository.

Закройте редактор «Управление групповыми политиками» и перезагрузите тестовый компьютер под управлением Windows10. Close the Group Policy Management Editor, and then restart the Windows 10 test computer. При перезагрузке клиентского компьютера происходит обновление политики WDAC. Restarting the computer updates the WDAC policy. Сведения об аудите политик WDAC см. в Защитник Windows политики управления приложениями. For information about how to audit WDAC policies, see Audit Windows Defender Application Control policies.

Общие сведения о правилах политики и файлах правил WDAC Understand WDAC policy rules and file rules

Область применения: Applies to:

• Windows 10 Windows 10
• Windows Server 2016 и выше Windows Server 2016 and above

Защитник Windows управления приложениями (WDAC) обеспечивает контроль над компьютером под управлением Windows 10 с помощью политик, которые определяют, доверять ли драйверу или приложению и можно ли запускать. Windows Defender Application Control (WDAC) provides control over a computer running Windows 10 by using policies that specify whether a driver or application is trusted and can be run. Политика включает ** правила политики, которые контролируют такие параметры, как режим аудита или включена ли целостность кода пользовательского режима (UMCI) в политике WDAC, а также правила файлов (или уровни правил файлов), которые указывают уровень, на котором будут определены и доверенными приложения. A policy includes policy rules that control options such as audit mode or whether user mode code integrity (UMCI) is enabled in a WDAC policy, and file rules (or file rule levels) that specify the level at which applications will be identified and trusted.

Правила политик управления приложениями в Защитнике Windows Windows Defender Application Control policy rules

Чтобы изменить параметры правил политики существующей политики WDAC XML, используйте Set-RuleOption. To modify the policy rule options of an existing WDAC policy XML, use Set-RuleOption. В следующих примерах покажите, как использовать этот кодлет для добавления и удаления параметра правила в существующей политике WDAC: The following examples show how to use this cmdlet to add and remove a rule option on an existing WDAC policy:

Чтобы убедиться, что UMCI включена для политики WDAC, созданной с помощью параметра -UserPEs (режим пользователя), добавьте правило 0 к существующей политике с помощью следующей команды: To ensure that UMCI is enabled for a WDAC policy that was created with the -UserPEs (user mode) option, add rule option 0 to an existing policy by running the following command:

Обратите внимание, что политика, которая была создана без параметра -UserPEs , не содержит исполняемых файлов пользовательского режима, то есть приложений. Note that a policy that was created without the -UserPEs option is empty of user mode executables, that is, applications. Если включить для такой политики UMCI (параметр 0), а затем попробовать запустить приложение, функция управления приложениями в Защитнике Windows определит, что этого приложения нет в списке (который не содержит приложений) и ответит. If you enable UMCI (Option 0) for such a policy and then attempt to run an application, Windows Defender Application Control will see that the application is not on its list (which is empty of applications), and respond. В режиме аудита этот ответ записывает в журнал событие, а в принудительном режиме он блокирует приложение. In audit mode, the response is logging an event, and in enforced mode, the response is blocking the application. Чтобы создать политику, которая включает исполняемые файлы режима пользователя (приложения), при запуске New-CIPolicy включите параметр -UserPEs . To create a policy that includes user mode executables (applications), when you run New-CIPolicy , include the -UserPEs option.

Чтобы отключить UMCI в существующей политике WDAC, удалите правило 0 с помощью следующей команды: To disable UMCI on an existing WDAC policy, delete rule option 0 by running the following command:

-Option 0 -Delete

В политике WDAC можно задать несколько правил. You can set several rule options within a WDAC policy. В таблице 1 описывается каждый параметр правила. Table 1 describes each rule option.

Рекомендуется сначала использовать режим Enabled:Audit, так как он позволяет протестировать новые политики WDAC перед их выполнением. We recommend that you use Enabled:Audit Mode initially because it allows you to test new WDAC policies before you enforce them. В режиме аудита приложение не блокируется, вместо этого политика регистрировала событие всякий раз, когда приложение за пределами политики было запущено. With audit mode, no application is blocked—instead the policy logs an event whenever an application outside the policy is started. Чтобы разрешить эти приложения, можно захватить сведения о политике из журнала событий, а затем объединить эти сведения в существующую политику. To allow these applications, you can capture the policy information from the event log, and then merge that information into the existing policy. При удалении режима Enabled:Audit политика выполняется в принудительном режиме. When the Enabled:Audit Mode is deleted, the policy runs in enforced mode.

Таблица 1: Table 1. Политика управления приложениями в Защитнике Windows: параметры правил политик Windows Defender Application Control policy — policy rule options

Правило Rule option	Описание Description
0 Enabled:UMCI (0 включено:UMCI) 0 Enabled:UMCI	Политики WDAC предполагают ограниченное использование двоичных файлов в режиме ядра и пользовательском режиме. WDAC policies restrict both kernel-mode and user-mode binaries. По умолчанию ограничено использование только двоичных файлов в режиме ядра. By default, only kernel-mode binaries are restricted. Если это правило активно, выполняется проверка исполняемых файлов и скриптов в пользовательском режиме. Enabling this rule option validates user mode executables and scripts.
1 Enabled:Boot Menu Protection (1 включено: защита меню загрузки) 1 Enabled:Boot Menu Protection	Этот параметр в данный момент не поддерживается. This option is not currently supported.
2 Required:WHQL (2 Требуется:WHQL) 2 Required:WHQL	По умолчанию устаревшие драйверы, не подписанные лабораториями WHQL, можно запускать. By default, legacy drivers that are not Windows Hardware Quality Labs (WHQL) signed are allowed to execute. Если это правило активно, каждый выполняемый драйвер должен иметь подпись WHQL; поддержка устаревших драйверов прекращается. Enabling this rule requires that every executed driver is WHQL signed and removes legacy driver support. В перспективе каждый новый драйвер, совместимый с Windows10, должен будет пройти сертификацию WHQL. Going forward, every new Windows 10–compatible driver must be WHQL certified.
3 Enabled:Audit Mode (Default) (3 Включено: режим аудита (по умолчанию)) 3 Enabled:Audit Mode (Default)	Разрешается выполнение двоичных файлов вне политики WDAC, но при этом каждое появление такого файла регистрируется в журнале событий CodeIntegrity, с помощью которого можно обновить существующую политику перед применением. Enables the execution of binaries outside of the WDAC policy but logs each occurrence in the CodeIntegrity event log, which can be used to update the existing policy before enforcement. Чтобы начать применять политику WDAC, удалите это правило. To begin enforcing a WDAC policy, delete this option.
4 Disabled:Flight Signing (4 отключено: подпись тестовых пакетов) 4 Disabled:Flight Signing	Если правило активно, политики WDAC не будут доверять двоичным файлам с подписью flightroot. If enabled, WDAC policies will not trust flightroot-signed binaries. Это можно использовать в сценарии, в котором организации необходимо только запускать выпущенные двоичные файлы, а не тестовые сборки. This would be used in the scenario in which organizations only want to run released binaries, not flighted builds.
5 Enabled: Inherit Default Policy (5 включено: наследовать политику по умолчанию) 5 Enabled:Inherit Default Policy	Этот параметр зарезервирован для использования в будущем и в настоящее время не имеет эффекта. This option is reserved for future use and currently has no effect.
6 Enabled:Unsigned System Integrity Policy (Default) (6 включено: неподписанная политика целостности системы (по умолчанию)) 6 Enabled:Unsigned System Integrity Policy (Default)	Позволяет политике оставаться неподписанной. Allows the policy to remain unsigned. Если удалить это правило, политику нужно будет подписывать и добавлять к ней UpdatePolicySigners, чтобы можно было в будущем ее изменять. When this option is removed, the policy must be signed and have UpdatePolicySigners added to the policy to enable future policy modifications.
7 Allowed:Debug Policy Augmented (7 разрешено: расширенная политика отладки) 7 Allowed:Debug Policy Augmented	Этот параметр в данный момент не поддерживается. This option is not currently supported.
8 Required:EV Signers (8 требуется: подписанты EV) 8 Required:EV Signers	Помимо подписи WHQL данное правило предусматривает, чтобы драйверы предоставлялись партнером, имеющим сертификат расширенной проверки (EV). In addition to being WHQL signed, this rule requires that drivers must have been submitted by a partner that has an Extended Verification (EV) certificate. Все будущие драйверы Windows10 и последующих версий будут соответствовать этому требованию. All future Windows 10 and later drivers will meet this requirement.
9 Enabled:Advanced Boot Options Menu (9 включено: меню расширенных параметров загрузки) 9 Enabled:Advanced Boot Options Menu	Предзагрузочное меню F8 отключено по умолчанию для всех политик WDAC. The F8 preboot menu is disabled by default for all WDAC policies. В случае активации этого правила меню F8 будет отображаться физически присутствующим пользователям. Setting this rule option allows the F8 menu to appear to physically present users.
10 Enabled:Boot Audit on Failure (10 включено: аудит при загрузке в случае сбоя) 10 Enabled:Boot Audit on Failure	Используется в том случае, если политика WDAC находится в режиме применения политик. Used when the WDAC policy is in enforcement mode. В случае сбоя драйвера во время запуска политика WDAC будет переведена в режим аудита, чтобы можно было загрузить Windows. When a driver fails during startup, the WDAC policy will be placed in audit mode so that Windows will load. Администраторы могут проверить причину сбоя в журнале событий CodeIntegrity. Administrators can validate the reason for the failure in the CodeIntegrity event log.
11 Disabled:Script Enforcement (11 отключено: применение сценариев) 11 Disabled:Script Enforcement	Этот параметр отключает параметры правоприменения сценариев. This option disables script enforcement options. Неподписаные скрипты PowerShell и интерактивные PowerShell больше не ограничиваются режимом ограниченного языка. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to Constrained Language Mode. ПРИМЕЧАНИЕ. Этот параметр поддерживается на сборках 1709, 1803 и 1809 с LCU 10C 2019 и выше, а также на устройствах с обновлением Windows 10 May 2019 (1903) и более высокими. NOTE: This option is supported on 1709, 1803, and 1809 builds with the 2019 10C LCU or higher, as well as on devices with the Windows 10 May 2019 Update (1903) and higher. Использование его в версиях Windows 10 до 1903 года без 10C или более позднего LCU не поддерживается и может иметь непредвиденные результаты. Using it on pre-1903 versions of Windows 10 without the 10C or later LCU is not supported and may have unintended results.
12 Required:Enforce Store Applications (12 требуется: применение политик к приложениям Store) 12 Required:Enforce Store Applications	Если этот параметр правил включен, политики WDAC будут также применяться к универсальным приложениями для Windows. If this rule option is enabled, WDAC policies will also apply to Universal Windows applications.
13 Enabled:Managed Installer (13 включено: управляемый установщик) 13 Enabled:Managed Installer	Используйте этот параметр, чтобы автоматически разрешить приложения, установленные решением распространения программного обеспечения, например Microsoft Endpoint Configuration Manager, которое было определено как управляемый установщик. Use this option to automatically allow applications installed by a software distribution solution, such as Microsoft Endpoint Configuration Manager, that has been defined as a managed installer.
14 Enabled:Intelligent Security Graph Authorization (14 включено: авторизация на основе интеллектуальной системы отслеживания) 14 Enabled:Intelligent Security Graph Authorization	Этот параметр используется, чтобы автоматически давать разрешение «заведомо надежным» приложениям согласно определению интеллектуальной системы отслеживания Майкрософт (ISG). Use this option to automatically allow applications with «known good» reputation as defined by Microsoft’s Intelligent Security Graph (ISG).
15 Enabled:Invalidate EAs on Reboot (15 включено: аннулирование расширенных атрибутов при перезагрузке) 15 Enabled:Invalidate EAs on Reboot	При использовании параметра интеллектуальной системы отслеживания (14) функция WDAC устанавливает расширенный атрибут файла, который указывает на то, что файл авторизован для запуска. When the Intelligent Security Graph option (14) is used, WDAC sets an extended file attribute that indicates that the file was authorized to run. При использовании этого параметра функция WDAC будет периодически перепроверять репутацию файлов, авторизованных системой ISG. This option will cause WDAC to periodically re-validate the reputation for files that were authorized by the ISG.
16 Enabled:Update Policy No Reboot (16 включено: обновление политики без перезагрузки) 16 Enabled:Update Policy No Reboot	Этот параметр используется, чтобы разрешить применение будущих обновлений политики WDAC без необходимости перезагрузки системы. Use this option to allow future WDAC policy updates to apply without requiring a system reboot. ПРИМЕЧАНИЕ. Этот параметр поддерживается только в Windows 10, версии 1709 и выше. NOTE: This option is only supported on Windows 10, version 1709, and above.
17 Включено:Разрешить дополнительные политики 17 Enabled:Allow Supplemental Policies	Используйте этот параметр в базовой политике, чтобы разрешить дополнительные политики для его расширения. Use this option on a base policy to allow supplemental policies to expand it. ПРИМЕЧАНИЕ. Этот параметр поддерживается только в Windows 10, версии 1903 и выше. NOTE: This option is only supported on Windows 10, version 1903, and above.
18 Disabled:Runtime FilePath Rule Protection 18 Disabled:Runtime FilePath Rule Protection	Отключение защиты правил FilePath по умолчанию (приложения и исполняемые материалы, разрешенные на основе правил пути к файлам, должны быть исходя из пути файла, который может быть только для администратора) для любого файла FileRule, который позволяет файл на основе FilePath. Disable default FilePath rule protection (apps and executables allowed based on file path rules must come from a file path that’s only writable by an administrator) for any FileRule that allows a file based on FilePath. ПРИМЕЧАНИЕ. Этот параметр поддерживается только в Windows 10, версии 1903 и выше. NOTE: This option is only supported on Windows 10, version 1903, and above.
19 Включено:Динамическая безопасность кода 19 Enabled:Dynamic Code Security	Включает применение политики для приложений .NET и динамически загруженных библиотек. Enables policy enforcement for .NET applications and dynamically-loaded libraries. ПРИМЕЧАНИЕ. Этот параметр поддерживается только в Windows 10, версии 1803 и выше. NOTE: This option is only supported on Windows 10, version 1803, and above.

Уровни правил файлов в политиках управления приложениями в Защитнике Windows Windows Defender Application Control file rule levels

Уровни правил файлов позволяют администраторам определять уровень доверия для своих приложений. File rule levels allow administrators to specify the level at which they want to trust their applications. Этот уровень доверия может быть точным (например, хэш-значение каждого двоичного файла), или общим (сертификат ЦС). This level of trust could be as fine-tuned as the hash of each binary or as general as a CA certificate. Уровни правил файлов указываются как при создании политики WDAC на основе сканирования, так и при создании политики на основе событий аудита. You specify file rule levels both when you create a new WDAC policy from a scan and when you create a policy from audit events. Кроме того, можно группировать уровни правил, обнаруженные в различных политиках, путем объединения этих политик. In addition, to combine rule levels found in multiple policies, you can merge the policies. При объединении политик WDAC их правила файлов совмещаются, чтобы любое приложение, разрешенное какой-либо из исходных политик, было разрешено объединенной политикой. When merged, WDAC policies combine their file rules, so that any application that would be allowed by either of the original policies will be allowed by the combined policy.

У каждого уровня правил файлов есть свои преимущества и недостатки. Each file rule level has its benefit and disadvantage. Используйте таблицу 2, чтобы выбрать соответствующий уровень защиты для доступных административных ресурсов и Защитник Windows развертывания application Control. Use Table 2 to select the appropriate protection level for your available administrative resources and Windows Defender Application Control deployment scenario.

Таблица2. Table 2. Политика управления приложениями в Защитнике Windows: уровни правил файлов Windows Defender Application Control policy — file rule levels

Уровень правила Rule level	Описание Description
Хэш Hash	Устанавливает отдельные хэш-значения для каждого обнаруженного двоичного файла. Specifies individual hash values for each discovered binary. Хотя этот уровень является специальным, он может вызвать дополнительные административные затраты на поддержку хэш-значений текущих версий продукта. Although this level is specific, it can cause additional administrative overhead to maintain the current product versions’ hash values. При каждом обновлении двоичного файла изменяется хэш-значение, в связи с чем требуется обновление политики. Each time a binary is updated, the hash value changes, therefore requiring a policy update.
FileName (Имя файла) FileName	Определяет имена отдельных двоичных файлов. Specifies individual binary file names. При обновлении хэш-значения для приложения изменяются, а имена файлов, как правило, нет. Although the hash values for an application are modified when updated, the file names are typically not. В этом случае защита будет менее точной, чем в случае хэш-уровня, но при изменении какого-либо двоичного файла, скорее всего, не потребуется обновление политики. This offers less specific security than the hash level but does not typically require a policy update when any binary is modified.
FilePath FilePath	Начиная с Windows 10 версии 1903, в этом документе указаны правила, позволяющие использовать файлы, содержащиеся в определенных расположениях пути файлов. Beginning with Windows 10 version 1903, this specifies rules that allow execution of binaries contained under specific file path locations. Дополнительные сведения о правилах уровня FilePath можно найти ниже. Additional information about FilePath level rules can be found below.
SignedVersion (Подписанная версия) SignedVersion	Правило издателя в сочетании с номером версии. This combines the publisher rule with a version number. Это правило позволяет выполнять запуск всех файлов заданной или более поздней версии от конкретного издателя. This option allows anything from the specified publisher, with a version at or above the specified version number, to run.
Publisher (Издатель) Publisher	Это сочетание уровня PcaCertificate (как правило, на один уровень ниже корневого сертификата) и общего имени (CN) некорневого сертификата. This is a combination of the PcaCertificate level (typically one certificate below the root) and the common name (CN) of the leaf certificate. Этот уровень правила позволяет организациям доверять сертификатам от крупных ЦС (например, Symantec), но только в том случае, если некорневой сертификат предоставлен определенной компанией (например, Intel для драйверов устройств). This rule level allows organizations to trust a certificate from a major CA (such as Symantec), but only if the leaf certificate is from a specific company (such as Intel, for device drivers).
FilePublisher (Издатель файла) FilePublisher	Это сочетание атрибута FileName подписанного файла, атрибута Publisher (сертификат PCA с общим именем некорневого сертификата) и минимального номера версии. This is a combination of the “FileName” attribute of the signed file, plus “Publisher” (PCA certificate with CN of leaf), plus a minimum version number. Это правило обеспечивает доверие определенным файлам от заданного издателя, если номер версии равен заданному или превышает его. This option trusts specific files from the specified publisher, with a version at or above the specified version number.
LeafCertificate (Некорневой сертификат) LeafCertificate	Добавляет доверенных авторов подписей на индивидуальном уровне сертификата подписи. Adds trusted signers at the individual signing certificate level. Преимущество использования этого уровня в сравнении с уровнем отдельных хэш-значений заключается в том, что новые версии продукта будут иметь другие хэш-значения, но, как правило, тот же сертификат подписи. The benefit of using this level versus the individual hash level is that new versions of the product will have different hash values but typically the same signing certificate. При использовании этого уровня для запуска новой версии приложения обновление политики не понадобится. Using this level, no policy update would be needed to run the new version of the application. Однако срок действия некорневых сертификатов гораздо короче, чем у сертификатов ЦС, поэтому по истечении срока действия для обновления политики WDAC потребуются дополнительные административные издержки. However, leaf certificates have much shorter validity periods than CA certificates, so additional administrative overhead is associated with updating the WDAC policy when these certificates expire.
PcaCertificate (Сертификат PCA) PcaCertificate	Добавляет наивысший доступный сертификат в предоставленную цепочку сертификатов для подписавших. Adds the highest available certificate in the provided certificate chain to signers. Обычно это единственный сертификат под корневым сертификатом, так как при сканировании не проверяются никакие объекты, кроме сертификатов, включенных в предоставленную подпись (это делается без подключения к Интернету и проверки локальных корневых хранилищ). This is typically one certificate below the root certificate, because the scan does not validate anything beyond the certificates included in the provided signature (it does not go online or check local root stores).
RootCertificate (Корневой сертификат) RootCertificate	В настоящее время не поддерживается. Currently unsupported.
WHQL WHQL	Обеспечивает доверие двоичным файлам, если они прошли проверку и подписаны WHQL. Trusts binaries if they have been validated and signed by WHQL. Это касается, в первую очередь, двоичных файлов ядра. This is primarily for kernel binaries.
WHQLPublisher (Издатель WHQL) WHQLPublisher	Это сочетание WHQL и CN в некорневом сертификате; касается, в первую очередь, двоичных файлов ядра. This is a combination of the WHQL and the CN on the leaf certificate and is primarily for kernel binaries.
WHQLFilePublisher (Издатель файла WHQL) WHQLFilePublisher	Указывает, что двоичные файлы проверены и подписаны WHQL, у них есть определенный издатель (WHQLPublisher) и что версия двоичного файла не ниже указанной. Specifies that the binaries are validated and signed by WHQL, with a specific publisher (WHQLPublisher), and that the binary is the specified version or newer. Это касается, в первую очередь, двоичных файлов ядра. This is primarily for kernel binaries.

При создании политик WDAC с помощью New-CIPolicyможно указать основной уровень правил файлов, включив параметр -Level. When you create WDAC policies with New-CIPolicy, you can specify a primary file rule level by including the -Level parameter. Для обнаруженных двоичных файлов, которые не могут быть включены в список доверия на основании критерий правила основного файла, используется параметр -Fallback (резервный). For discovered binaries that cannot be trusted based on the primary file rule criteria, use the -Fallback parameter. Например, если уровень правила основного файла — PCACertificate, а вам также необходимо доверять неподписанным приложениям, используйте уровень правила хэша в качестве резервного, чтобы добавлялись хэш-значения двоичных файлов, у которых нет сертификата подписи. For example, if the primary file rule level is PCACertificate but you would like to trust the unsigned applications as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate.

WDAC поддерживает только правила подписывания ключей подписывания сертификата RSA с максимальным количеством 4096 битов. WDAC only supports signer rules for RSA certificate signing keys with a maximum of 4096 bits.

Пример использования уровней правил файлов Example of file rule levels in use

Например, рассмотрим ИТ-специалистов в отделе, использующем много серверов. For example, consider some IT professionals in a department that runs many servers. Они решили, что хотят использовать на серверах только программное обеспечение, подписанное поставщиками их программного обеспечения и драйверов, то есть компаниями, выпускающими их оборудование, операционную систему, антивирусное и другое важное ПО. They decide they want their servers to run only software signed by the providers of their software and drivers, that is, the companies that provide their hardware, operating system, antivirus, and other important software. Они знают, что на их серверах также выполняется написанное в компании приложение, которое не имеет подписи, но редко обновляется. They know that their servers also run an internally written application that is unsigned but is rarely updated. Они хотят разрешить выполнение этого приложения. They want to allow this application to run.

Для создания политики WDAC они собирают эталонный сервер на своем стандартном оборудовании и устанавливают все программное обеспечение, которое, как им известно, работает на их серверах. To create the WDAC policy, they build a reference server on their standard hardware, and install all of the software that their servers are known to run. Затем они выполняют New-CIPolicy с -Level Publisher (чтобы разрешить запуск программного обеспечения их поставщиков ПО, «Издателей») и -Fallback Hash (чтобы разрешить запуск внутренних неподписанных приложений). Then they run New-CIPolicy with -Level Publisher (to allow software from their software providers, the «Publishers») and -Fallback Hash (to allow the internal, unsigned application). Они включают политику в режиме аудита и собирают сведения обо всем необходимом программном обеспечении, которое не было установлено на эталонный сервер. They enable the policy in auditing mode and gather information about any necessary software that was not included on the reference server. Они объединяют политики WDAC с исходной политикой, чтобы разрешить выполнение этого дополнительного программного обеспечения. They merge WDAC policies into the original policy to allow that additional software to run. Затем они включают политику WDAC в принудительном режиме для своих серверов. Then they enable the WDAC policy in enforced mode for their servers.

В ходе нормальной работы они в конечном итоге установят обновления программного обеспечения или, возможно, добавят программное обеспечение тех же поставщиков программного обеспечения. As part of normal operations, they will eventually install software updates, or perhaps add software from the same software providers. Поскольку «Издатель» не изменится в этих обновлениях и ПО, им не потребуется обновлять свою политику WDAC. Because the «Publisher» remains the same on those updates and software, they will not need to update their WDAC policy. Если они достигнут такого этапа, на котором потребуется обновить написанное в компании неподписанное приложение, им также потребуется обновить политику WDAC, чтобы хэш в политике соответствовал хэшу обновленного внутреннего приложения. If they come to a time when the internally-written, unsigned application must be updated, they must also update the WDAC policy so that the hash in the policy matches the hash of the updated internal application.

Они также могут создать каталог, в котором будут записываться сведения о неподписанном внутреннем приложении, а затем подписать и распространить этот каталог. They could also choose to create a catalog that captures information about the unsigned internal application, then sign and distribute the catalog. Затем внутреннее приложение сможет обрабатываться политиками WDAC таким же образом, как и любое другое подписанное приложение. Then the internal application could be handled by WDAC policies in the same way as any other signed application. Обновление внутреннего приложения потребует только восстановления каталога, его подписывания и распространения (перезапуск не потребуется). An update to the internal application would only require that the catalog be regenerated, signed, and distributed (no restarts would be required).

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

Правила Filepath не предоставляют тех же гарантий безопасности, что и явные правила подписываемых, так как они основаны на разрешениях на мутируемый доступ. Filepath rules do not provide the same security guarantees that explicit signer rules do, as they are based on mutable access permissions. Правила Filepath лучше всего подходят для сред, в которых большинство пользователей работают в стандартном, а не в качестве администратора. ИТ-специалисты должны заботиться при разработке правил пути, чтобы разрешить путь, который, как они знают, может оставаться только для записи администратора и запретить выполнение из подкожи, где стандартные пользователи могут изменять ACLs в папке. Filepath rules are best suited for environments where most users are running as standard rather than admin. IT Pros should take care while crafting path rules to allow paths that they know are likely to remain to be admin-writeable only and deny execution from sub-directories where standard users can modify ACLs on the folder.

По умолчанию WDAC выполняет проверку на записи пользователей во время выполнения, которая гарантирует, что текущие разрешения в указанном файлополучре и его родительских каталогах (рекурсивно) не позволяют стандартным пользователям записывать доступ. By default, WDAC performs a user-writeability check at runtime which ensures that the current permissions on the specified filepath and its parent directories (recursively) do not allow standard users write access.

Существует определенный список siDs, которые WDAC распознает как администраторы. There is a defined list of SIDs which WDAC recognizes as admins. Если filepath позволяет записывать разрешения для любого SID, не в этом списке, filepath считается пользовательским, даже если дополнительный SID связан с пользовательским пользователем администратора. If a filepath allows write permissions for any SID not in this list, the filepath is considered to be user-writeable even if the additional SID is associated to a custom admin user. Чтобы справиться с этими особыми случаями, можно переопределять проверку администрирования WDAC на время работы с помощью вышеупомясного параметра защиты от отключений:Runtime FilePath. To handle these special cases, you can override WDAC’s runtime admin-writeable check with the Disabled:Runtime FilePath Rule Protection option described above.

Список известных SID-адресов администратора WDAC: WDAC’s list of well-known admin SIDs are:
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. 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-1685597119-444378811-2746676523.

При создании правил filepath с помощью New-CIPolicyсоздается уникальное, полностью квалифицированное правило пути для каждого файла, обнаруженного в отсканированном пути (s). When generating filepath rules using New-CIPolicy, a unique, fully-qualified path rule is generated for every file discovered in the scanned path(s). Чтобы создать правила, разрешащие все файлы по указанному пути папки, используйте New-CIPolicyRule для определения правил, содержащих подтеки с помощью переключателя -FilePathRules. To create rules that instead allow all files under a specified folder path, use New-CIPolicyRule to define rules containing wildcards using the -FilePathRules switch.

Поддиальды можно использовать в начале или конце правила пути; для каждого правила пути разрешено только одно под диктовка. Wildcards can be used at the beginning or end of a path rule; only one wildcard is allowed per path rule. Подгруппы, размещенные в конце пути, разрешают все файлы на этом пути и его подтеки повторно (например. Wildcards placed at the end of a path authorize all files in that path and its subdirectories recursively (ex. C:\\* будет включать C:\foo\\* ). would include C:\foo\\* ). Подтеки, размещенные в начале пути, позволяют точное указанное имя файла в любом пути (например. Wildcards placed at the beginning of a path will allow the exact specified filename under any path (ex. *\bar.exe позволит C:\bar.exe и C:\foo\bar.exe ). would allow C:\bar.exe and C:\foo\bar.exe ). Поддиальды в середине пути не поддерживаются (например. Wildcards in the middle of a path are not supported (ex. C:\\*\foo.exe ). ). Без под диктовки правило разрешает только определенный файл (например. Without a wildcard, the rule will allow only a specific file (ex. C:\foo\bar.exe ). ).
Использование макрос также поддерживается и полезно в сценариях, в которых системный диск отличается от C:\ диска. The use of macros is also supported and useful in scenarios where the system drive is different from the C:\ drive. Поддерживаемые макрос: %OSDRIVE% %WINDIR% , %SYSTEM32% . Supported macros: %OSDRIVE% , %WINDIR% , %SYSTEM32% .

Из-за существующей ошибки нельзя сочетать правила ALLOW на основе path с любыми правилами DENY в одной политике. Due to an existing bug, you can not combine Path-based ALLOW rules with any DENY rules in a single policy. Вместо этого либо разделяйте правила DENY в отдельную базовую политику, либо перемещайте правила ALLOW на основе пути в дополнительную политику, как описано в развертывании нескольких политик WDAC. Instead, either separate DENY rules into a separate Base policy or move the Path-based ALLOW rules into a supplemental policy as described in Deploy multiple WDAC policies.

Защитник Windows правила управления файлами Windows Defender Application Control filename rules

Уровни правил имени файлов предоставляют администраторам для указания атрибутов файлов, от которых можно было бы основать правило имени файла. File name rule levels provide administrators to specify the file attributes off which to base a file name rule. Правила имен файлов предоставляют те же гарантии безопасности, что и явные правила подписываемых, так как они основаны на атрибутах не мутируемых файлов. File name rules provide the same security guarantees that explicit signer rules do, as they are based on non-mutable file attributes. Спецификация уровня имени файла возникает при создании новых правил политики. Specification of the file name level occurs when creating new policy rules. Кроме того, чтобы объединить уровни имен файлов, найденных в нескольких политиках, можно объединить несколько политик. In addition, to combine file name levels found in multiple policies, you can merge multiple policies.

Используйте таблицу 3, чтобы выбрать соответствующий уровень имени файла для доступных административных ресурсов и Защитник Windows развертывания application Control. Use Table 3 to select the appropriate file name level for your available administrative resources and Windows Defender Application Control deployment scenario. Например, LOB или производственное приложение и его binaries (например. For instance, an LOB or production application and its binaries (eg. DLLs) могут иметь одно и то же имя продукта. DLLs) may all share the same product name. Это позволяет пользователям легко создавать целевые политики на основе уровня правила имя продукта. This allows users to easily create targeted policies based on the Product Name filename rule level.

Табл.3. Table 3. Защитник Windows политики управления приложениями — уровни имен файлов Windows Defender Application Control policy — filename levels