- Полный гайд для системных администраторов и специалистов по информационной безопасности
- Актуализировано: 08.05.2026 ✅
Подпишитесь на канал — впереди ещё больше практических гайдов по безопасности Windows и PowerShell
📋 Что вы узнаете из этой статьи
✨ Краткое сравнение трёх технологий ограничения скриптов
✨ Пошаговые инструкции с готовыми командами для копирования
✨ Секретные лайфхаки, о которых молчат 90% админов
✨ Чек-лист для быстрой проверки вашей среды
✨ Прогноз на 2027 — что изменится в управлении скриптами
Прочтение займёт ~7 минут. Сохраните в закладки — пригодится при аудите.
🔍 Краткое сравнение технологий
ExecutionPolicy ⚡
🔹 Уровень защиты: Низкий (не является механизмом безопасности)
🔹 Тип политики: Разрешительная/запретительная
🔹 Поддержка: Все версии Windows
🔹 Гранулярность: Только для скриптов .ps1
🔹 Статус в 2026: Поддерживается, но не для серьёзной защиты
Software Restriction Policies (SRP) 🛡️
🔹 Уровень защиты: Средний
🔹 Тип политики: Запретительная (deny-list)
🔹 Поддержка: ≥ Windows XP/Server 2003
🔹 Гранулярность: .exe, .dll, .msi, скрипты
🔹 Статус в 2026: Устаревает, не развивается — только для обратной совместимости
AppLocker 🔐
🔹 Уровень защиты: Высокий
🔹 Тип политики: Разрешительная (allow-list)
🔹 Поддержка: ≥ Windows 7/Server 2008 R2
🔹 Гранулярность: .exe, .dll, .msi, .ps1, .appx + контроль по пользователям
🔹 Статус в 07.05.2026: ✅ Поддерживается, только исправления безопасности
App Control for Business (WDAC) 🚀
🔹 Уровень защиты: Максимальный (ядро-уровневое принуждение)
🔹 Тип политики: Разрешительная (allow-list)
🔹 Поддержка: ≥ Windows 10/Server 2016
🔹 Гранулярность: Все исполняемые файлы + драйверы + репутационная проверка
🔹 Статус в 2026: 🔥 Рекомендуется Microsoft для новых внедрений
Важно: Для гомогенной среды с современными ОС выбирайте App Control for Business. AppLocker используйте только как дополнение для сценариев с разными правами пользователей на одном устройстве.
⚙️ PowerShell ExecutionPolicy: что это и чего НЕ делает
ExecutionPolicy — это функция уровня «защита от случайного запуска», а не настоящая система контроля доступа.
Просмотр текущих политик:
Get-ExecutionPolicy -List
Пример вывода:
Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined ← GPO (наивысший приоритет)
UserPolicy Undefined ← GPO для пользователя
Process Undefined ← Только текущая сессия
CurrentUser RemoteSigned ← Текущий пользователь
LocalMachine AllSigned ← Все пользователи на ПК
Типы политик:
🔹 Restricted — Запрещает ВСЕ скрипты, только интерактивные команды
🔹 AllSigned — Требует подписи доверенным издателем для ВСЕХ скриптов
🔹 RemoteSigned — ✅ По умолчанию. Подпись только для скриптов из интернета
🔹 Unrestricted — Разрешает всё, предупреждает о внешних скриптах
🔹 Bypass — Полное отключение проверок (только для встроенных приложений)
🔹 Undefined — Нет политики, наследование из вышестоящей области
Настройка через GPO:
Путь в редакторе:
Конфигурация компьютера → Политики → Административные шаблоны → Компоненты Windows → Windows PowerShell → "Включить выполнение скриптов"
⚠️ Критические ограничения:
🔸 Не является механизмом безопасности — пользователи могут обойти, вставив код в консоль
🔸 Приоритет: MachinePolicy (GPO) > UserPolicy > Process > LocalMachine > CurrentUser
🔸 Не работает на non-Windows (Linux/macOS по умолчанию Unrestricted)
🔸 Известны случаи игнорирования MachinePolicy в PowerShell 7.4+ при определённых конфигурациях
🛡️ Software Restriction Policies (SRP): когда ещё можно использовать
SRP — устаревшая технология. Поддерживается для обратной совместимости, но не рекомендуется для новых внедрений.
Типы правил:
🔹 Путь — Блокировка по пути к файлу (C:\Scripts\*). Легко обойти переименованием
🔹 Хеш — Блокировка по криптографическому хешу. Требует обновления при изменении файла
🔹 Сертификат — По издателю кода (Authenticode). Только для подписанных файлов
🔹 Зона интернета — По метке "скачано из интернета". Зависит от Alternate Data Streams
Базовый сценарий настройки:
🔸 Установить уровень по умолчанию: Запрещено
🔸 Добавить исключения: %SystemRoot%\*.exe, %ProgramFiles%\*.exe, доверенные пути
🔸 Включить принудительное применение для всех пользователей
⚠️ Предупреждение: При уровне "Запрещено" создаются 4 автоматических правила реестра для предотвращения блокировки администраторов. Не удаляйте их без понимания последствий.
🔐 AppLocker: преимущества и пошаговая настройка
Почему AppLocker лучше SRP:
✅ Гранулярный контроль по пользователям/группам
✅ Режим аудита — тестирование без блокировки
✅ Исключения в правилах — "разрешить всё, кроме regedit.exe"
✅ Отдельные коллекции правил для .exe, .dll, .ps1, .msi, .appx
✅ PowerShell-управление через командлеты AppLocker
✅ Экспорт/импорт политик для тестирования на стенде
Поддерживаемые типы правил:
🔹 Executable (.exe, .com) — Блокировка неутверждённых приложений
🔹 Script (.ps1, .psm1, .bat, .cmd, .vbs, .js) — Контроль выполнения скриптов
🔹 Windows Installer (.msi, .msp, .mst) — Запрет несанкционированной установки
🔹 Packaged app (.appx, .appxbundle) — Контроль приложений из Microsoft Store
🔹 DLL (.dll, .ocx) — ⚠️ Использовать с осторожностью (влияние на производительность)
Шаг 1: Подготовка правил на рабочей станции
# Создать правила на основе установленных программ
$rules = New-AppLockerPolicy -RuleType Path, Publisher, Hash `
-User Everyone -Path "C:\Program Files\ApprovedApps\*" `
-Action Allow
# Добавить правило для доверенных скриптов организации
$scriptRule = New-AppLockerPolicy -RuleType Path `
-User "Domain\PowerUsers" `
-Path "\\domain\sysvol\scripts\approved\*.ps1" `
-Action Allow
# Объединить и экспортировать
$finalPolicy = $rules + $scriptRule
$finalPolicy | Export-Clixml -Path "C:\temp\AppLockerPolicy.xml"
Шаг 2: Развёртывание через GPO
🔸 Открыть Group Policy Management Console
🔸 Создать/редактировать GPO
🔸 Перейти: Конфигурация компьютера → Политики → Параметры безопасности → Политики управления приложениями → AppLocker
🔸 Импортировать правила из .xml или создать вручную
🔸 Включить службу Application Identity (обязательно!):
# Через настройки системных служб в GPO:
# Application Identity → Режим запуска: Автоматически
Шаг 3: Тестирование в режиме аудита
# Проверить события аудита:
Get-WinEvent -FilterHashtable @{
LogName='Microsoft-Windows-AppLocker/MSI and Script'
ID=8002,8003,8004,8006,8007
} | Select-Object TimeCreated, Message
Шаг 4: Включение принудительного режима
🔸 Изменить режим коллекции на "Принудительно"
🔸 Выполнить gpupdate /force на целевых ПК
🔸 Мониторить события с ID=8004 (блокировка) и 8006 (разрешение)
⚠️ Для PowerShell: При срабатывании правил скрипты выполняются в режиме ConstrainedLanguage — это дополнительная защита от выполнения вредоносного кода.
🚀 App Control for Business (WDAC): рекомендуемая замена
Почему переходить на WDAC в 2026:
✅ Безопасность уровня ядра — правила .exe/.dll применяются в kernel-mode
✅ Интеграция с Intelligent Security Graph — репутационная проверка приложений
✅ Managed Installer — контроль установщиков на уровне процесса
✅ Детальный аудит — логи с описанием причин блокировки
✅ Поддержка сценариев с общим доступом — через комбинацию с AppLocker
Минимальные требования:
🔹 Windows 10 1607+ / Windows 11 / Server 2016+
🔹 UEFI Secure Boot (рекомендуется)
🔹 TPM 2.0 (для расширенных сценариев)
Базовая настройка через PowerShell:
# Создать базовую политику (разрешить подписанное Microsoft)
$policy = New-CIPolicy -Level PcaCertificate -FilePath "C:\WDAC\AllowMicrosoft.xml" `
-Rules @(New-CIPolicyRule -Publisher "CN=Microsoft*" -FriendlyName "Microsoft Signed")
# Добавить правило для доверенных скриптов организации
$orgRule = New-CIPolicyRule -FilePathRule "C:\OrgScripts\*.ps1" `
-FriendlyName "Org Approved Scripts" -Action Allow
$policy = Merge-CIPolicy -OutputFilePath "C:\WDAC\PolicyWithOrg.xml" `
-PolicyPaths $policy, $orgRule
# Преобразовать в бинарный формат для развёртывания
ConvertFrom-CIPolicy -XmlFilePath "C:\WDAC\PolicyWithOrg.xml" `
-BinaryFilePath "C:\WDAC\Sipolicy.p7b"
Интеграция с PowerShell:
🔹 Доверенные скрипты → выполняются в FullLanguage режиме
🔹 Недоверенные скрипты → автоматически в ConstrainedLanguage режиме
🔹 Аудит-режим (PowerShell 7.4+) → логирование без блокировки для тестирования
# Проверка текущего режима:
$ExecutionContext.SessionState.LanguageMode
# Возможные значения: FullLanguage, ConstrainedLanguage, NoLanguage, RestrictedLanguage
⚠️ Критические изменения в Windows 11 24H2/25H2/26H1
🚨 Исправленная проблема: Сбой принуждения AppLocker для PowerShell
*Проблема (апрель-май 2025):*
В Windows 11 24H2 режим ConstrainedLanguage не применялся корректно при использовании правил скриптов AppLocker.
Статус на 08.05.2026:
✅ Исправлено в обновлении 2025-05 B (KB5058411) для 24H2 и последующих версиях.
✅ Все актуальные сборки 24H2 (≥26100.4061), 25H2, 26H1 содержат исправление.
Проверка исправления:
# Проверка версии сборки
[System.Environment]::OSVersion.Version.Build
# Для 24H2 должно быть ≥ 26100.4061
# После обновления: сброс кэша AppLocker
Stop-Service appidsvc -Force
Start-Service appidsvc
gpupdate /force
Другие важные изменения 2026:
🔹 *26H1* — Новая версия только для новых устройств (не для обновления)
🔹 *25H2/24H2* — Улучшена интеграция AMSI с PowerShell 7.6 (лучшее обнаружение вредоносных скриптов)
🔹 Все версии — Ужесточение проверки драйверов с апреля 2026 (проверьте совместимость подписанных модулей)
✅ ПОДПИСКА, ❤️ ЛАЙК, 🔄 РЕПОСТ друзьям, 💰 ДОНАТ на сбер по QR 👇
💰ПОДДЕРЖКА АВТОРА КАНАЛА КОПЕЙКОЙ - ДЕЛО ДОБРОВОЛЬНОЕ💰
🛠️ Пошаговая настройка через GPO: универсальный сценарий
Сценарий: Разрешить только утверждённые скрипты для отдела IT
Шаг 1: Подготовка инфраструктуры
# Подписать все скрипты сертификатом организации
$cert = Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert | Select-Object -First 1
Set-AuthenticodeSignature -FilePath "C:\script.ps1" -Certificate $cert
🔸 Создать структуру: \\domain\SYSVOL\domain\Policies\Scripts\Approved\
🔸 Настроить права: Чтение — "Domain\IT-Staff", Запись — "Domain\GPO-Admins"
Шаг 2: Создание GPO
Имя: PS-Restriction-IT-Department
Конфигурация компьютера:
🔹 Системные службы → Application Identity → Режим запуска: Автоматически
🔹 AppLocker → Коллекция "Script":
- Режим: Принудительно (после аудита)
- Правила:
1. [Allow] Путь: \\domain\SYSVOL\*\Approved\*.ps1, Пользователи: Domain\IT-Staff
2. [Allow] Путь: %WINDIR%\System32\WindowsPowerShell\*, Пользователи: Все
3. [Deny] Путь: * (по умолчанию)
Конфигурация пользователя (дополнительно):
🔹 "Включить выполнение скриптов" → Включено → "Разрешить только подписанные"
Шаг 3: Тестирование
# Применить политики
gpupdate /force
# Проверить применённые политики
Get-AppLockerPolicy -Effective | Select-Object -ExpandProperty RuleCollections
# Проверить язык выполнения для недоверенных скриптов
$ExecutionContext.SessionState.LanguageMode # Должен быть ConstrainedLanguage
Шаг 4: Мониторинг блокировок
# Сбор событий блокировки за сутки
$filter = @{
LogName = 'Microsoft-Windows-AppLocker/Script'
ID = 8004
StartTime = (Get-Date).AddDays(-1)
}
Get-WinEvent -FilterHashtable $filter |
Select-Object TimeCreated,
@{N='User';E={$_.Properties[1].Value}},
@{N='Script';E={$_.Properties[2].Value}} |
Export-Csv "C:\Logs\AppLocker-Blocks-$(Get-Date -f yyyyMMdd).csv" -NoTypeInformation
📊 Таблица принятия решений (текстовая версия)
Есть ли устаревшие ОС (Win7/8/2008R2)?
🔹 Да → Используйте SRP + ExecutionPolicy
⚠️ Но планируйте миграцию на современные ОС — поддержка заканчивается
🔹 *Нет (только Win10+/2016+)* → Переходите к следующему вопросу
Нужен контроль по пользователям (разные права на одном ПК)?
🔹 Да → Используйте AppLocker + ExecutionPolicy
✅ Добавьте режим аудита минимум на 2 недели перед включением принуждения
🔹 Нет (одинаковые права для всех) → Используйте App Control for Business
🔥 Это рекомендуемый выбор для новых внедрений в 2026
Для всех сценариев:
✅ Всегда включайте модульное логирование PowerShell
✅ Всегда тестируйте в изолированной среде перед продакшном
✅ Всегда имейте план отката
✅ Чек-лист перед внедрением в продакшн
Обязательные настройки:
🔹 Включите модульное логирование PowerShell через GPO
🔹 Включите логирование блоков скриптов (для обнаружения obfuscation)
🔹 Настройте пересылку событий в SIEM (источники: Microsoft-Windows-PowerShell/Operational, AppLocker/*)
Дополнительные меры:
🔹 Используйте Constrained Language Mode через WDAC/AppLocker
🔹 Подписывайте все внутренние скрипты и используйте AllSigned или RemoteSigned
🔹 Регулярно обновляйте хеш-правила при изменении легитимных скриптов
🔹 Тестируйте в режиме аудита минимум 2 недели перед включением принуждения
🔹 Документируйте исключения и проводите ревью каждые 90 дней
Быстрая диагностика за 60 секунд:
& {
$r = @();
$r += "EP: $((Get-ExecutionPolicy -List | ? Scope -eq MachinePolicy).ExecutionPolicy)";
$r += "AL: $((Get-Service appidsvc -EA 0).Status)";
$r += "LM: $($ExecutionContext.SessionState.LanguageMode)";
$r += "WDAC: $(if(Test-Path "$env:windir\System32\CodeIntegrity\Sipolicy.p7b"){'ACTIVE'}else{'INACTIVE'})";
$r
}
Если EP ≠ Restricted/AllSigned ИЛИ AL ≠ Running ИЛИ LM = FullLanguage для обычных пользователей — ваша среда требует доработки.
🎁 Бонус: секретные лайфхаки для профи
«Тихий» аудит без влияния на пользователей:
# Задача для сбора «ложных срабатываний» ежедневно в 23:00
$auditTask = @{
Name = "AppLocker-Audit-Collector"
ScriptBlock = {
Get-WinEvent -FilterHashtable @{
LogName = 'Microsoft-Windows-AppLocker/*'
ID = 8002,8003,8004,8006,8007
StartTime = (Get-Date).AddHours(-24)
} -ErrorAction SilentlyContinue |
Export-Csv "C:\Logs\AppLocker-Audit-$(Get-Date -f yyyyMMdd).csv" -Append
}
Trigger = New-JobTrigger -Daily -At "23:00"
Principal = New-ScheduledJobPrincipal -UserId "SYSTEM" -RunLevel Highest
}
Register-ScheduledJob @auditTask
Обход проблемы с кэшированием правил на 24H2:
# «Мягкий сброс» без перезагрузки после обновления политик
Stop-Service appidsvc -Force
Start-Sleep -Seconds 3
$cachePath = "$env:ProgramData\Microsoft\Windows\AppRepository\PackageCache"
if (Test-Path $cachePath) {
Get-ChildItem $cachePath -Filter "*.bin" | Remove-Item -Force -ErrorAction SilentlyContinue
}
Start-Service appidsvc
gpupdate /force /sync
Комбинация 3 уровней защиты для максимального эффекта:
# Проверка всех уровней одним скриптом
$securityReport = [PSCustomObject]@{
ExecutionPolicy = (Get-ExecutionPolicy -List | Where-Object {$_.Scope -eq 'MachinePolicy'}).ExecutionPolicy
AppLockerStatus = (Get-Service appidsvc).Status
LanguageMode = $ExecutionContext.SessionState.LanguageMode
AMSIEnabled = -not [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').GetValue($null)
}
$securityReport | Format-List
Понравился гайд? ❤️
Подпишитесь на канал, чтобы не пропустить новые инструкции по безопасности Windows и PowerShell! 🔔
Если статья была полезна — поставьте лайк ❤️, подпишитесь на канал и поделитесь с коллегами в профчатах
#тег #PowerShell #GPO #AppLocker #SRP #WDAC #Windows11 #WindowsServer #InfoSec #Кибербезопасность #СистемноеАдминистрирование #GPOнастройка #ExecutionPolicy #ConstrainedLanguage #AppControl #Microsoft #ITпрофи #БезопасностьСкриптов #Аудит #ПолитикиБезопасности #PowerShell7 #Windows11_24H2 #Windows11_25H2 #GroupPolicy #SysAdmin #DevSecOps #Hardening #ЗащитаОтВредоносов #Логирование #SIEM #ЧекЛист #Гайд2026