Ограничение выполнения PowerShell: как работает, чем различаются режимы, и как их настроить правильно 🔐⚙️

PowerShell — мощный инструмент, который в руках злоумышленника способен причинить серьёзный ущерб. Именно поэтому Microsoft реализовала многоуровневую систему контроля выполнения скриптов. Если вы администратор, разработчик DevOps или просто разработчик, который хочет запустить скрипт на машине и ничего не получается — это нормально. Windows специально блокирует выполнение скриптов по соображениям безопасности.

В этой статье я разберу, как работают политики выполнения PowerShell, покажу все уровни контроля (от простой политики выполнения до WDAC и AppLocker), объясню тонкости их взаимодействия и дам вам инструменты для грамотной настройки. Информация актуальна для Windows 10, Windows 11 (включая критический баг версии 24H2) и Windows Server 2016+.

Внимание: если вы занимаетесь тестированием на проникновение или исследованием безопасности, соблюдайте российское законодательство. Все описанные здесь техники предназначены для использования только на системах, на которые у вас есть права и разрешение.

Как работает PowerShell Execution Policy под капотом 🔍

Политика выполнения — не система безопасности в классическом смысле. Это средство предотвращения случайного запуска вредоносных скриптов. Пользователь легко может её обойти, просто копируя код прямо в консоль. Однако это НЕ означает, что её настраивать не нужно — она обеспечивает первый уровень защиты и помогает контролировать запуск скриптов на корпоративных машинах.

Политика выполнения хранится в реестре и имеет несколько уровней приоритета (области действия). При загрузке PowerShell проверяет политики в строгом порядке:

1. MachinePolicy — устанавливается администратором через групповую политику (GPO) для всех пользователей компьютера. Имеет наивысший приоритет.
2. UserPolicy — устанавливается через групповую политику для конкретного пользователя. Имеет приоритет выше, чем LocalMachine.
3. Process — действует только в текущей сессии PowerShell, хранится в памяти (в переменной окружения $Env:PSExecutionPolicyPreference) и теряется при закрытии консоли.
4. LocalMachine — по умолчанию применяется ко всем пользователям. Хранится в реестре: HKLM:\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell\ExecutionPolicy.
5. CurrentUser — действует только для текущего пользователя. Хранится в реестре: HKCU:\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell\ExecutionPolicy.

Ключевое правило: чем выше политика в этом списке, тем выше её приоритет. Если установлена MachinePolicy, остальные игнорируются.

Отличие между Windows PowerShell (5.1) и PowerShell 7.x: они хранят политики ОТДЕЛЬНО. Windows PowerShell использует реестр Windows, а PowerShell 7.x использует файл powershell.config.json. Поэтому вы можете иметь разные политики выполнения в PowerShell 5.1 и PowerShell 7 (на ноябрь 2025 года актуальна версия 7.5 с поддержкой до май 2026).

Типы политики выполнения 📋

Каждая политика определяет, какие скрипты могут выполняться. Вот они по порядку от наиболее к наименее безопасной:

Restricted — жёсткий режим. Не загружаются файлы конфигурации, не запускаются скрипты. Запускаются только отдельные команды (интерактивные). Это режим по умолчанию для Windows 10/11 в PowerShell 5.1.

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

RemoteSigned — локальные скрипты запускаются без ограничений. Скрипты, скачанные из интернета (отмечены меткой Zone.Identifier=3), должны быть подписаны. ✅ Это рекомендуемая политика для баланса между безопасностью и удобством. Используется по умолчанию в Windows Server и PowerShell 7.x.

Unrestricted — все скрипты запускаются, но при запуске скрипта из интернета выводится предупреждение. Небезопасно для общих систем.

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

Undefined — политика не установлена. PowerShell использует эффективную политику из другой области действия. Если все области действия — Undefined, то эффективная политика = Restricted.

Диагностика и просмотр текущих политик 🔎

Первый шаг при любой проблеме — понять, какая политика действует:

# Просмотреть все уровни политик

Get-ExecutionPolicy -List

# Пример вывода:

# Scope ExecutionPolicy

# ----- ---------------

# MachinePolicy Undefined

# UserPolicy Undefined

# Process Undefined

# CurrentUser RemoteSigned

# LocalMachine Restricted

Вывод читается так: эффективная политика — первая с определённым значением в порядке приоритета. Если видите, что MachinePolicy = Undefined, UserPolicy = Undefined, Process = Undefined, то действует CurrentUser. Если все Undefined, действует Restricted.

Команда без параметров показывает только эффективную политику:

Get-ExecutionPolicy # Выведет одно значение

Пошаговая инструкция: устанавливаем политику правильно ✅

Вариант 1: временно для одной сессии (ноль риска)

Используйте параметр -ExecutionPolicy Bypass при запуске PowerShell:

powershell.exe -ExecutionPolicy Bypass -File .\myscript.ps1

Или из CMD/батника:

@echo off

powershell -ExecutionPolicy Bypass -NoProfile -File "C:\scripts\myscript.ps1"

Преимущества: ничего не меняется на машине, политика действует только для этого вызова.

Недостатки: нельзя использовать для интерактивной работы, нельзя запустить прямо из проводника файлов.

Вариант 2: для текущего пользователя (рекомендуется для локальных машин)

Откройте PowerShell БЕЗ прав администратора (!) и выполните:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force

Проверьте результат:

Get-ExecutionPolicy -List

Преимущества: не требует прав администратора, изменения касаются только вас.

Недостатки: другие пользователи машины не смогут запускать скрипты без собственной настройки.

Вариант 3: для всей машины (требует администратора)

Запустите PowerShell от администратора (правый клик → «Запустить от администратора») и выполните:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine -Force

Преимущества: политика действует для всех пользователей.

Недостатки: требует прав администратора, влияет на всю машину.

Вариант 4: откат политики на дефолт

# Сбросить для текущего пользователя

Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope CurrentUser -Force

# Или для всей машины

Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope LocalMachine -Force

После этого эффективная политика станет = Restricted.

🔖Дорогие гости и подписчики канала. Если наши материалы приносят вам пользу, вы всегда можете поддержать команду символическим переводом. Любая помощь мотивирует писать для Вас больше полезного и качественного контента безо всяких подписок.🙏🤝🙏🤝🙏

💰ПОДДЕРЖАТЬ КАНАЛ МОЖНО ТУТ ( ОТ 50 РУБЛЕЙ )💰

Или сделать любой перевод по QR-коду через СБП. Быстро, безопасно и без комиссии.(Александр Г.)

С уважением, Команда "Т.Е.Х.Н.О Windows & Linux".

Групповая политика (GPO): когда локальные изменения не работают ⚠️

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

Get-ExecutionPolicy -List

# MachinePolicy: AllSigned (или любое значение, не Undefined)

Если MachinePolicy определена, любой вызов Set-ExecutionPolicy локально вам скажет:

Set-ExecutionPolicy : PowerShell updated your local preference successfully, but

the setting is overridden by the Group Policy applied to your system.

Что делать: нужно менять групповую политику, а не локальную политику. Обратитесь к администратору домена.

Если вы сами администратор домена и хотите настроить групповую политику для машин в домене:

1. Откройте Group Policy Management Console (GPMC.msc или gpedit.msc для локальной машины).
2. Найдите путь: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell.
3. Найдите политику Turn on Script Execution.
4. Установите её в режим Enabled и выберите вариант:
5. Allow Only Signed Scripts = AllSigned
6. Allow Local Scripts and Remote Signed Scripts = RemoteSigned
7. Allow All Scripts = Unrestricted

После применения групповой политики может потребоваться перезагрузка или выполнить gpupdate /force на клиентской машине.

Работа с подписанными скриптами 🔐

Если установлена политика AllSigned или RemoteSigned (для скриптов из интернета), нужна цифровая подпись.

Создание самоподписанного сертификата (для тестирования)

# Создайте самоподписанный сертификат

$cert = New-SelfSignedCertificate -CertStoreLocation Cert:\CurrentUser\My `

-Subject "CN=MyScriptCert" -KeyUsage DigitalSignature `

-Type CodeSigningCert -FriendlyName "My Code Signing Cert"

Подписание скрипта

$cert = @(Get-ChildItem cert:\CurrentUser\My -CodeSigningCert)[0]

Set-AuthenticodeSignature -FilePath "C:\scripts\myscript.ps1" -Certificate $cert

Проверьте подпись:

Get-AuthenticodeSignature -FilePath "C:\scripts\myscript.ps1"

Обход через разблокировку файла (для скачанных скриптов) 🔓

Когда вы скачиваете скрипт из интернета (особенно через браузер), Windows помечает его меткой Zone.Identifier=3. При политике RemoteSigned такой скрипт будет заблокирован.

Способ 1: используйте Unblock-File (PowerShell 3.0+):

Unblock-File -Path "C:\Downloads\script.ps1"

Способ 2: через контекстное меню (графически):

Щелкните правой кнопкой по файлу .ps1 → Свойства → на вкладке General нажмите Разблокировать (если кнопка есть).

Способ 3: проверьте наличие метки:

Get-Item -Path "C:\Downloads\script.ps1" -Stream *

# Если увидите Zone.Identifier, значит файл помечен как скачанный

Удалите метку вручную:

Remove-Item -Path "C:\Downloads\script.ps1:Zone.Identifier" -ErrorAction SilentlyContinue

Ограниченный языковой режим: углубленное ограничение 🔒

Политика выполнения — первый уровень. Но есть второй: ограниченный языковой режим. Он включается вместе с WDAC (контроль приложений Windows Defender) или AppLocker и максимально ограничивает возможности PowerShell даже для администраторов.

В режиме ограниченного языка недоступны:

• .NET типы (блокируются опасные, вроде System.Diagnostics)
• Объекты COM
• Командлет Add-Type
• Многие переменные окружения

Проверить, в каком режиме вы:

$ExecutionContext.SessionState.LanguageMode

# FullLanguage - нормально, ограничений нет

# ConstrainedLanguage - режим ограничений активен

Критический баг Windows 11 версии 24H2 (уже исправлен)

В обновлении Windows 11 версии 24H2 обнаружилась серьёзная уязвимость: правила скриптов AppLocker перестали принудительно применять ограниченный языковой режим. PowerShell запускался в режиме FullLanguage вопреки политикам. Если вы используете AppLocker для ограничения скриптов — это была критическая проблема.

Статус: исправлено в обновлении системы безопасности May 2025 (KB5058411, сборка 26100.4061) и выше. Microsoft изменила логику внутри политики блокировки Windows (WLDP), которая теперь корректно возвращает требование к ограниченному языковому режиму.

Проверка: если вы на Windows 11 версии 24H2 и видите ограниченный языковой режим, убедитесь, что установлены обновления как минимум от May 2025. На ноябрь 2025 актуально обновление KB5068861 (сборка 26100.7171 для 24H2 и 26200.7171 для 25H2).

Контроль приложений Windows Defender и AppLocker: контроль на уровне приложений 🎯

Это уже не политика выполнения, а полноценная система контроля приложений.

AppLocker (больше не развивается, но всё ещё работает):

• Создание правил для разрешения/блокировки приложений
• Можно заблокировать PowerShell.exe полностью
• Можно заблокировать запуск скриптов по пути, хешу, издателю
• Статус: Microsoft больше не развивает, может получать только исправления безопасности

WDAC (контроль приложений Windows Defender, рекомендуемый подход):

• Более мощная, работает на уровне ядра
• Требует Secure Boot и UEFI
• Доступна на Windows 10/11 Pro/Enterprise и Server 2016+
• Работает в режимах: Audit (логирует нарушения, не блокирует) и Enforced (блокирует)
• Microsoft рекомендует сначала включить режим Audit для тестирования

WDAC требует PowerShell для управления. Пример создания простой политики из шаблона:

$template = "C:\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Audit.xml"

ConvertFrom-CIPolicy -XmlFilePath $template -BinaryFilePath "C:\Windows\System32\CodeIntegrity\SIPolicy.p7b"

# Требуется перезагрузка

Канал «Каморка Программиста» — это простые разборы программирования, языков, фреймворков и веб-дизайна. Всё для новичков и практиков.

Присоединяйся прямо сейчас.

Типичные ошибки и их решение 🛠️

Ошибка: "cannot be loaded because running scripts is disabled on this system"

Решение: установите RemoteSigned для CurrentUser или LocalMachine (см. пошаговую инструкцию выше).

Ошибка: "File xxx.ps1 cannot be loaded. The file xxx.ps1 is not digitally signed."

Решение 1: если вы владелец скрипта, подпишите его (см. раздел о подписях).

Решение 2: используйте Unblock-File (см. выше).

Решение 3: временно используйте -ExecutionPolicy Bypass.

Ошибка: Set-ExecutionPolicy выполнился, но политика не изменилась

Причина: вероятно, установлена MachinePolicy через групповую политику. Проверьте Get-ExecutionPolicy -List и ищите определённое значение в MachinePolicy.

Решение: измените групповую политику (требует прав администратора домена) или используйте временный режим bypass.

Ошибка: PowerShell 5.1 имеет одну политику, PowerShell 7 — другую

Это нормально. Они независимы. Установите политику отдельно для каждой версии.

Ошибка: $Env:PSExecutionPolicyPreference пуста, но политика работает

Это норма. Если область действия Process не установлена явно, PowerShell использует другие области действия.

Практические примеры из реальной жизни 💼

Пример 1: запуск скрипта автоматизации из батника на корпоративной машине

@echo off

REM Батник для запуска PowerShell скрипта при входе в систему

REM Используем -ExecutionPolicy Bypass, чтобы не зависеть от групповой политики

REM -NoProfile ускоряет запуск, исключая загрузку профиля пользователя

REM -WindowStyle Hidden запускает окно скрытым

%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe ^

-ExecutionPolicy Bypass ^

-NoProfile ^

-WindowStyle Hidden ^

-File "%~dp0deploy.ps1"

echo Deploy script executed at %date% %time% >> "%TEMP%\deploy.log"

Пример 2: настройка сетевого администратора на личной машине

# Администратор устанавливает RemoteSigned для себя

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force

# Проверяет результат

Get-ExecutionPolicy -List

# Теперь он может запускать локальные скрипты, но скачанные требуют подписи

.\my-local-script.ps1 # ✅ Работает

Invoke-WebRequest -Uri "https://example.com/script.ps1" | Invoke-Expression # ❌ Потребует подписи

Пример 3: DevOps настраивает агента непрерывной интеграции/развёртывания

# На машине агента CI/CD (если это Windows)

# Устанавливается RemoteSigned на уровне машины, так как множество пользователей

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine -Force

# Затем все скрипты развёртывания могут запускаться без дополнительных проверок

Пример 4: заблокировать PowerShell через AppLocker (для пользователей)

Путь в групповой политике: Computer Configuration → Windows Settings → Security Settings → Application Control Policies → AppLocker

Создайте правило:

• Executable Rules → новое правило
• Путь: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
• Action: Deny
• User: Everyone (или конкретная группа)

Результат: обычные пользователи не смогут запускать PowerShell, но администраторы смогут (у них другие правила).

Диагностика и логирование 📊

Чтобы узнать, почему скрипт не запустился:

Просмотр логов AppLocker (если используется)

Get-WinEvent -LogName "Microsoft-Windows-AppLocker/EXE and DLL" -MaxEvents 100 | `

Where-Object {$_.Message -match "PowerShell"} | `

Format-List TimeCreated, Message

Просмотр логов контроля целостности кода (если используется WDAC)

Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" -MaxEvents 100 | `

Format-List TimeCreated, Message

Включить логирование PowerShell (для отладки)

В редакторе групповой политики (gpedit.msc):

• Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell
• Turn on Module Logging — Enabled, введите Microsoft.PowerShell.*
• Turn on PowerShell Script Block Logging — Enabled

Логи появятся в программе просмотра событий → Windows Logs → Application, источник PowerShell.

Проверка реестра вручную

# Для LocalMachine

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell"

# Для CurrentUser

Get-ItemProperty "HKCU:\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell"

# Для групповой политики (если есть)

Get-ItemProperty "HKLM:\Software\Policies\Microsoft\Windows\PowerShell"

Производительность и оптимизация ⚡

Миф: политика выполнения влияет на производительность скриптов.

Реальность: нет. Проверка политики происходит один раз при запуске, не на каждой команде.

Где может быть реальное замедление:

• Подписанные скрипты: проверка подписи добавляет примерно 100–200 миллисекунд при запуске большого скрипта (зависит от размера).
• Правила AppLocker: если правил много (1000+), проверка может добавить несколько миллисекунд.
• Политика WDAC: обработка происходит в ядре, незначительное влияние (примерно 1–5 миллисекунд).

Оптимизация: используйте -NoProfile при запуске PowerShell из батников или планировщика задач. Это исключает загрузку профиля пользователя и ускоряет запуск на 100–300 миллисекунд.

powershell.exe -NoProfile -File .\script.ps1

Безопасность: что надо знать 🛡️

✅ Правильные подходы:

• Используйте RemoteSigned как минимум для баланса между безопасностью и удобством.
• Подписывайте критичные скрипты в production окружении.
• Применяйте WDAC в режиме Audit сначала, затем переводите в режим Enforced.
• Логируйте запуск скриптов через логирование модулей PowerShell.
• Ограничивайте PowerShell для обычных пользователей через AppLocker/WDAC.

❌ Опасные подходы:

• Не устанавливайте Bypass постоянно (Set-ExecutionPolicy Bypass). Используйте только для одного вызова (-ExecutionPolicy Bypass).
• Не полагайтесь только на политику выполнения как на решение в области безопасности.
• Не используйте переменную окружения __PSLockdownPolicy — она легко обходится.
• Не назначайте права администратора пользователям, чтобы они могли менять политику выполнения.

Важное замечание об обходах: существуют способы обхода политики выполнения (понижение версии на PowerShell 2.0, если он установлен; использование -Command вместо -File; запуск скрипта через Invoke-Expression и т. д.). Однако они требуют физического доступа или компрометации учётной записи. Правильная комбинация WDAC + AppLocker + цифровая подпись кода значительно повышает барьер.

Чек-лист применения перед внедрением ✔️

Перед тем как менять политику выполнения в production:

• Проверил текущую политику: Get-ExecutionPolicy -List
• Проверил наличие групповой политики: команда выше должна показать Undefined в MachinePolicy (если нет групповой политики)
• Проверил версию PowerShell: $PSVersionTable.PSVersion
• Проверил версию Windows: [System.Environment]::OSVersion
• Протестировал новую политику на тестовой машине с похожей конфигурацией
• Уведомил пользователей об изменениях
• Подготовил план отката (знаю, как вернуть старую политику)
• Включил логирование (логирование PowerShell в программе просмотра событий)
• Проверил, что критичные скрипты работают с новой политикой
• Задокументировал причину изменения и дату внедрения

Часто задаваемые вопросы: вопросы и ответы ❓

В: Что такое режим Restricted по умолчанию?

О: На клиентских машинах Windows 10/11 по умолчанию установлен режим Restricted для LocalMachine. На Windows Server по умолчанию установлен режим RemoteSigned. PowerShell 7.x по умолчанию имеет режим RemoteSigned. Это сделано для того, чтобы серверные администраторы и те, кто намеренно установил PowerShell 7, могли работать со скриптами без дополнительной настройки.

В: Могу ли я удалить политику выполнения полностью?

О: Да, установив Undefined для всех областей действия. Тогда эффективная политика = Restricted. Фактически это означает полный запрет на скрипты.

В: Почему PowerShell 5.1 показывает одну политику, а PowerShell 7 — другую?

О: Они хранят настройки отдельно. PowerShell 5.1 (Windows PowerShell) использует реестр Windows. PowerShell 7.x (Core) использует файл powershell.config.json. Это разные приложения с независимыми настройками. Нужно настраивать каждое отдельно. На ноябрь 2025 года поддерживаемые версии — 7.4 (долгосрочная поддержка до ноября 2026) и 7.5 (стандартная поддержка до май 2026).

В: Как узнать, установлена ли групповая политика?

О: Выполните Get-ExecutionPolicy -List и посмотрите на MachinePolicy. Если там что-то кроме Undefined, установлена групповая политика.

В: Можно ли обойти политику выполнения?

О: Теоретически да, если у вас есть доступ к машине. Но с правильным контролем приложений Windows Defender + AppLocker это становится очень сложным. Для рядовых пользователей — невозможно. Политика выполнения работает против случайного запуска вредоноса, не против целевых атак.

В: Какая разница между режимами Unrestricted и Bypass?

О: Режим Unrestricted показывает предупреждение при запуске скрипта из интернета. Режим Bypass не показывает никаких предупреждений. Режим Bypass безопаснее использовать для одного вызова, а не устанавливать постоянно.

В: Если я поставлю режим AllSigned, будут ли мне доступны встроенные команды PowerShell?

О: Да, встроенные команды и командлеты работают в любом режиме. Ограничение касается только скриптов (файлов .ps1).

В: Как скрипту получить свою текущую политику выполнения?

О: Используйте Get-ExecutionPolicy, но имейте в виду, что это может отличаться от того, при каком режиме скрипт был запущен. Если скрипт запущен при режиме Bypass, то Get-ExecutionPolicy внутри скрипта может показать другое значение.

В: Windows 11 версия 24H2 — нужно ли мне что-то делать?

О: Если вы используете AppLocker для ограничения скриптов PowerShell — убедитесь, что установлены обновления минимум от May 2025 (KB5058411 или выше). Это исправляет критический баг с ограниченным языковым режимом. На ноябрь 2025 актуально обновление KB5068861.

В: Можно ли подписать скрипт для использования на других машинах?

О: Да, но нужно экспортировать ваш сертификат кодовой подписи (как .cer или .pfx), импортировать его на другой машине в хранилище доверенных корневых центров сертификации или доверенных издателей, и скрипт будет работать там без предупреждений.

Вывод: собираем всё воедино 🎯

Политика выполнения — первый и самый простой уровень контроля над PowerShell. Это не панацея, но при правильной настройке отлично предотвращает случайный запуск вредоноса.

Ключевые моменты, которые надо запомнить:

1. Начните с диагностики: Get-ExecutionPolicy -List — ваш первый шаг.
2. Выберите правильную область действия: CurrentUser для личной машины, LocalMachine для сервера (если нет групповой политики).
3. RemoteSigned — золотой стандарт: локальные скрипты запускаются, из интернета — требуется подпись.
4. Никогда не устанавливайте режим Bypass постоянно: используйте только для одного вызова.
5. В enterprise — используйте контроль приложений Windows Defender: это будущее контроля приложений на Windows.
6. Windows 11 версия 24H2 имеет критический баг: если вы используете AppLocker, обновитесь как минимум до May 2025.
7. Логирование — ваш друг: включите логирование модулей PowerShell для отладки проблем.

Если вы разработчик или администратор, потратьте 15 минут на настройку политики выполнения на своей машине. Это предотвратит массу проблем в будущем и защитит вас от случайного запуска вредоносного кода.

И помните: политика выполнения работает против шума и случайности, но не против целевых атак. Для полной защиты комбинируйте её с контролем приложений Windows Defender, AppLocker, цифровыми подписями кода и мониторингом.

#PowerShell #ПолитикаВыполнения #Windows11 #Безопасность #DevOps #Администрирование #Скриптинг #WDAC #AppLocker #БезопасностьWindows #ТехничеснаяАвтоматизация #КиберБезопасность #EnterpriseIT #ИнструментыАдмина #БезопасностьКода #СкриптыPowerShell #WindowsServer #Соответствие #КонтрольДоступа #УтвёрждениеСистемы #ЛучшиеПрактики #Системный_администратор #БезопасностьIT #ОграниченныйЯзык #ГрупповаяПолитика #НастройкиРеестра #БезопасностьНа_первомМесте #ПрофессиональныеСоветы #НадёжнаяАвтоматизация