Руководство по созданию политик запрета элемента управления приложениями
С помощью управления приложениями для бизнеса можно создавать политики для явного запрета определенных драйверов и приложений. Чтобы создать действующие политики запрета в элементе управления приложениями для бизнеса, следует понимать порядок применения приоритета правил Элемент управления приложениями при оценке файлов по активным политикам.
Автономная политика запрета
При создании политики, состоящей исключительно из правил запрета, необходимо включить правила "Разрешить все" в разделах ядра и пользовательского режима политики в дополнение к явным правилам запрета. Правила "Разрешить все" гарантируют, что все, что явно не запрещено политикой, разрешено к выполнению. Если не добавить правила "Разрешить все" в политику только запрета, вы рискуете заблокировать все. Этот результат происходит потому, что некоторый код явно запрещен, а весь другой код неявно запрещен, так как нет правил для его авторизации. Рекомендуется использовать шаблон политики AllowAll при создании автономных политик запрета.
<FileRules>
<Allow ID="ID_ALLOW_A_1" FriendlyName="Allow Kernel Drivers" FileName="*" />
<Allow ID="ID_ALLOW_A_2" FriendlyName="Allow User mode components" FileName="*" />
</FileRules>
<SigningScenarios>
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS" FriendlyName="Kernel Mode Signing Scenario">
<ProductSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_ALLOW_A_1" />
</FileRulesRef>
</ProductSigners>
</SigningScenario>
<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="User Mode Signing Scenario">
<ProductSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_ALLOW_A_2" />
</FileRulesRef>
</ProductSigners>
</SigningScenario>
</SigningScenarios>
Добавление предыдущих правил "Разрешить все" не влияет на другие развернутые вами политики управления приложениями, которые применяют явный список разрешений. Для иллюстрации рассмотрим следующий пример:
Policy1 — это список разрешений для приложений, подписанных Windows и Майкрософт.
Policy2 — это новая политика запрета, которая блокирует MaliciousApp.exe, а также двоичные wmic.exe компонента Windows. Он также включает правила "Разрешить все".
- MaliciousApp.exe блокируется, так как в политике Policy2 есть явное правило блокировки. Он также неявно блокируется политикой Policy1, так как отсутствуют разрешающие правила, охватывающие файл в этой политике.
- Файл с подписью Windows wmic.exe заблокирован, так как в политике Policy2 есть явное правило блокировки.
- Все остальные приложения, подписанные Windows и Майкрософт, разрешены, так как в политиках Policy1 и Policy2 есть явное правило разрешения, которое охватывает файл.
- Все остальные приложения неявно запрещены. Например, ExampleApp.exe, не допускается, так как он является доверенным только политикой Policy2 (из-за правил Allow All), а не Policy1.
Рекомендации по политике смешанного разрешения и запрета
Если набор правил запрета должен быть добавлен в существующую политику, которая включает явные правила разрешения, не включайте предыдущие правила "Разрешить все". Вместо этого правила запрета следует объединить с существующей политикой управления приложениями с помощью мастера управления приложениями или с помощью следующей команды PowerShell:
$DenyPolicy = <path_to_deny_policy>
$ExistingPolicy = <path_to_existing_policy>
Merge-CIPolicy -PolicyPaths $ DenyPolicy, $ExistingPolicy -OutputFilePath $ExistingPolicy
Рекомендации
Сначала протестируйте в режиме аудита . Как и во всех новых политиках, мы рекомендуем развернуть новую политику запрета в режиме аудита и отслеживать события блокировки аудита 3076 , чтобы обеспечить блокировку только приложений, которые вы намеревались заблокировать. Дополнительные сведения о мониторинге событий блоков с помощью журналов Просмотр событий и расширенной охоты: управление политиками управления приложениями для бизнеса и устранение неполадок
Рекомендуемые типы запрещенных правил . Правила подписывания и атрибутов файлов рекомендуются с точки зрения безопасности, управляемости и производительности. Хэш-правила следует использовать только при необходимости. Так как хэш файла меняется с любым изменением файла, трудно испевать за политикой блоков на основе хэша, когда злоумышленник может тривиально обновить файл. Хотя элемент управления приложениями оптимизировал синтаксический анализ хэш-правил, некоторые устройства могут повлиять на производительность при оценке среды выполнения, если политики имеют десятки тысяч или более хэш-правил.
Руководство по созданию политики запрета
Запретить правила и политики можно создать с помощью командлетов PowerShell или мастера управления приложениями. Мы рекомендуем создавать правила подписывания (PCACertificate, Publisher и FilePublisher) везде, где это возможно. В случае неподписанных двоичных файлов необходимо создавать правила для атрибутов файла, таких как исходное имя файла или хэш.
Правило запрета на основе издателя программного обеспечения
$DenyRules += New-CIPolicyRule -Level FilePublisher -DriverFilePath <binary_to_block> -Fallback SignedVersion,Publisher,Hash -Deny
Правило запрета на основе атрибутов программного обеспечения
$DenyRules += New-CIPolicyRule -Level FileName -DriverFilePath <binary_to_block> -Fallback Hash -Deny
Правило запрета на основе хэша
$DenyRules += New-CIPolicyRule -Level Hash -DriverFilePath <binary_to_block> -Deny
Объединение правил запрета с политикой шаблонов AllowAll
После создания правил запрета их можно объединить с политикой шаблона AllowAll:
$DenyPolicy = <path_to_deny_policy_destination>
$AllowAllPolicy = $Env:windir + "\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml"
Merge-CIPolicy -PolicyPaths $AllowAllPolicy -OutputFilePath $DenyPolicy -Rules $DenyRules
Set-CiPolicyIdInfo -FilePath $DenyPolicy -PolicyName "My Deny Policy" -ResetPolicyID
Развертывание политики запрета
Теперь должна быть подготовлена политика запрета для развертывания. Сведения о развертывании политики в управляемых конечных точках см. в руководстве по развертыванию управления приложениями .