Согласно статье «Windows 10 features we’re no longer developing«, вместо SRP нам предлагают использовать «лучший» на их взгляд вариант — WDAC. AppLocker я не рассматриваю, т.к. он не работает даже на версии Professional:
Instead of using the Software Restriction Policies through Group Policy, you can use AppLocker or Windows Defender Application Control to control which apps users can access and what code can run in the kernel.MSDN
Windows Defender Application Control
Контроль Приложений с помощью Windows Defender является заменой Applocker и SRP (Software Restriction Policies). WDAC доступен на Windows 10, при этом политики могут отрабатываться аж на уровне ядра. Т.о. нам позволено контролировать даже драйверы устройств, чего не было в Applocker и тем более SRP. При этом для проверки файлов используются не только и не столько правила пути, сколько данные из облака. Например репутация файла (вычисляется его хэш и сравнивается с базой).
Вот примеры .XML-файлов с правилами для WDAC:
C:\Windows\schemas\CodeIntegrity\ExamplePolicies
Например самый маленький из файлов (AllowAll.xml):
<?xml version="1.0" encoding="utf-8"?>
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy">
<VersionEx>1.0.1.0</VersionEx>
<PolicyID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyID>
<BasePolicyID>{A244370E-44C9-4C06-B551-F6016E563076}</BasePolicyID>
<PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>
<Rules>
<Rule>
<Option>Enabled:Unsigned System Integrity Policy</Option>
</Rule>
<Rule>
<Option>Enabled:Advanced Boot Options Menu</Option>
</Rule>
<Rule>
<Option>Enabled:UMCI</Option>
</Rule>
<Rule>
<Option>Enabled:Update Policy No Reboot</Option>
</Rule>
</Rules>
<!--EKUS-->
<EKUs />
<!--File Rules-->
<FileRules>
<Allow ID="ID_ALLOW_A_1" FileName="*" />
<Allow ID="ID_ALLOW_A_2" FileName="*" />
</FileRules>
<!--Signers-->
<Signers />
<!--Driver Signing Scenarios-->
<SigningScenarios>
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS_1" FriendlyName="Auto generated policy on 08-17-2015">
<ProductSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_ALLOW_A_1" />
</FileRulesRef>
</ProductSigners>
</SigningScenario>
<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="Auto generated policy on 08-17-2015">
<ProductSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_ALLOW_A_2" />
</FileRulesRef>
</ProductSigners>
</SigningScenario>
</SigningScenarios>
<UpdatePolicySigners />
<CiSigners />
<HvciOptions>0</HvciOptions>
<Settings>
<Setting Provider="PolicyInfo" Key="Information" ValueName="Name">
<Value>
<String>AllowAll</String>
</Value>
</Setting>
<Setting Provider="PolicyInfo" Key="Information" ValueName="Id">
<Value>
<String>041417</String>
</Value>
</Setting>
</Settings>
</SiPolicy>Можно конечно на основе одного из файлов сделать свой файл правил, но это всё нужно будет делать вручную! В этом случае отсутствует наглядность и удобство. Кроме того нет проверки внесённых изменений. Допускаю, что я мало искал, или пока необходимый инструмент не реализован прямо в Windows Defender. В итоге я нашёл стороннюю утилиту для создания правил — WDAC Policy Wizard. При этом на текущий момент их всё равно придётся применять НЕ в через Windows Defender!
WDAC Policy Wizard
0. Качаем и запускаем утилиту Windows Defender App Control Policy Wizard
1. На экране приветствия выбираем «Создание политики» (Policy Createator):
2. Далее выбираем тип новой политики (Select a New Policy Type), нам подходит Base Policy:
3. Зададим название политики, расположение, а также её тип (Signed and Reputable Mode):
4. При первичной настройке политики лучше включить режим Аудита:
5. На экране правил для цифровой подписи можно нажать Next, если вы не ходите добавить свои правила:
6. На этом экране будет указан путь к файлу с созданными политиками:
7. А вот дальше «минус» — данные политики применить через эту утилиту нельзя, но можно одним из способов:
- — Intune
- — GPO
- — PowerShell
- Не приходит СМС для авторизации на сайте Госуслуги - 01.11.2024
- VSCode: Найти и удалить элементы xml - 29.10.2024
- WordPress: Ошибка в плагине WpDiscuz - 08.10.2024