Политика выполнения PowerShell и подпись скриптов — практическое руководство, как перестать «затыкать дыры» параметром Bypass

«На новом ПК скрипт не запускается, выдавая «выполнение сценариев в данной системе отключено…»». «Просто добавили -ExecutionPolicy Bypass и всё заработало, теперь так написано во всех задачах». «Файл .ps1, лежащий в общей папке, выдаёт ошибку подписи только на одном компьютере». Политика выполнения PowerShell — это стена, в которую почти наверняка упрётесь, продвигая автоматизацию внутри компании. И на многих площадках накапливается практика «затыкать дыры Bypass», не разбираясь в самом механизме.

Сложность в том, что легко неправильно понять, «что именно защищает» политика выполнения. Одни считают её функцией безопасности, закручивают гайки слишком туго — и работа встаёт. Другие решают, что «всё равно бесполезно», ставят везде Bypass — и снимают тем самым последний защитный механизм, предотвращающий случайные ошибки. Обеих крайностей можно избежать, если понимать сам механизм.

Эта статья адресована сотрудникам ИТ-отделов малых и средних компаний, а также всем, кто автоматизирует рутинные внутренние задачи с помощью PowerShell. Мы разберём, опираясь на официальную документацию, что на самом деле представляет собой политика выполнения, как работает приоритет областей действия, как она связана с Zone.Identifier (так называемым Mark of the Web), и как организовать распространение скриптов через их подпись.

1. Сначала вывод

• Политика выполнения — это защитный механизм, а не граница безопасности. Официальная документация прямо утверждает: «политика выполнения — это не система безопасности, ограничивающая действия пользователя» и «её легко обойти, введя содержимое скрипта в командную строку». Её цель — задать базовые правила и предотвратить непреднамеренное выполнение (случайные ошибки).¹
• Политика выполнения влияет только на запуск скриптов — интерактивный запуск команд всегда возможен. По умолчанию в Windows PowerShell 5.1 на клиентских ОС установлена политика Restricted (запуск скриптов запрещён), а на Windows Server — RemoteSigned. В PowerShell 7 политикой по умолчанию считается RemoteSigned.²¹
• У политики есть пять областей действия, приоритет которых выглядит так: MachinePolicy > UserPolicy > Process > CurrentUser > LocalMachine. MachinePolicy и UserPolicy предназначены только для групповой политики, их нельзя изменить командой Set-ExecutionPolicy, и указание в командной строке их тоже не перекрывает.¹³
• RemoteSigned требует подписи только для скриптов «из интернета». Происхождение определяется по прикреплённому к файлу альтернативному потоку данных Zone.Identifier (Mark of the Web); проверив содержимое и удалив его командой Unblock-File, скрипт можно запустить, не меняя политику.¹⁴
• AllSigned требует подписи доверенного издателя для всех скриптов, включая созданные локально. Подпись ставится командой Set-AuthenticodeSignature и встраивается в конец файла в виде блока комментариев # SIG #.¹⁵
• Обязательно ставьте временную метку (-TimestampServer) при подписании. С временной меткой скрипт остаётся действительным даже после истечения срока сертификата подписи. Поскольку большинство сертификатов для подписи кода действительны год, пропуск этого шага превращается в ежегодную бомбу замедленного действия.⁶⁵
• Самоподписанный сертификат годится только для тестирования. Скрипт, подписанный самоподписанным сертификатом, не запустится на других компьютерах. Для распространения в организации используйте сертификат для подписи кода, выданный удостоверяющим центром (внутренним ЦС или коммерческим).⁵⁷
• Для организационного контроля управляйте всем централизованно через параметр групповой политики «Включить выполнение сценариев». Этот параметр имеет приоритет над всеми настройками областей действия на стороне PowerShell.¹

2. Что на самом деле представляет собой политика выполнения — «защитный механизм», а не «граница безопасности»

Сначала подтвердим исходную предпосылку. Формулировка официальной документации (about_Execution_Policies) предельно откровенна. Политика выполнения — это «функция безопасности» (safety feature), контролирующая условия, при которых PowerShell загружает файлы конфигурации и выполняет скрипты, и она «не является системой безопасности, ограничивающей действия пользователя». Причина в том, что даже пользователь, которому запрещено запускать скрипт, может выполнить ту же самую обработку, просто вставив содержимое скрипта в командную строку. Прямо указано, что роль политики выполнения — задать базовые правила и предотвратить их непреднамеренное нарушение.¹ Во вводной документации та же мысль повторяется: «это не граница безопасности; она не может остановить пользователя, который намеренно пытается запустить скрипт».²

Если понять эту позицию, направление проектирования эксплуатации становится ясным. Ошибочны оба утверждения — и «раз мы ужесточили политику выполнения, атаки предотвращены», и «раз её всё равно можно обойти, в ней нет смысла». Противодействие атакам — задача другого уровня (контроль приложений, минимизация прав, аудит журналов), а задача политики выполнения — предотвращение случайных ошибок.⁸

Ниже сведены различия между основными политиками.¹

Часто упускают из виду, что Restricted блокирует не только рабочие скрипты, но и загрузку профилей (.ps1), модулей (.psm1) и файлов конфигурации форматирования (.ps1xml).¹ Классическое обращение к нам — когда причиной «профиль не загружается на новом компьютере» оказывается именно политика выполнения.

3. Области действия и приоритет — что на самом деле стоит за «я изменил, но ничего не поменялось»

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

Стандартный способ разобраться с проблемой «я настроил, но ничего не изменилось» — смотреть не на действующее значение, а на весь список.

# Обязательно проверяйте не только действующую политику, но и то, какая область действия применяется
Get-ExecutionPolicy -List

# Пример: даже если LocalMachine настроен на AllSigned, побеждает RemoteSigned из CurrentUser
#         Scope ExecutionPolicy
#         ----- ---------------
# MachinePolicy       Undefined
#    UserPolicy       Undefined
#       Process       Undefined
#   CurrentUser    RemoteSigned
#  LocalMachine       AllSigned

# Чтобы изменить только своё окружение, удобна область CurrentUser — она не требует прав администратора
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Поскольку CurrentUser имеет приоритет выше, чем LocalMachine, действующей политикой в примере выше оказывается RemoteSigned.¹ Команда Set-ExecutionPolicy по умолчанию записывает в область LocalMachine, поэтому требует прав администратора, но в области CurrentUser её может изменить и обычный пользователь.³

А главный инструмент организационного управления — групповая политика. Политика «Включить выполнение сценариев» (Turn on Script Execution) имеет приоритет над всеми областями действия, заданными на стороне PowerShell. Если её отключить, действие эквивалентно Restricted; если включить, можно выбрать один из вариантов — «Разрешить все сценарии» (Unrestricted), «Разрешить локальные сценарии и подписанные удалённые сценарии» (RemoteSigned) или «Разрешить только подписанные сценарии» (AllSigned); находится она в административных шаблонах, в разделе Компоненты Windows\Windows PowerShell. Конфигурация компьютера имеет приоритет над конфигурацией пользователя.¹ В среде, управляемой через GPO, команда Set-ExecutionPolicy сохранит настройку, но она не будет действовать, и появится сообщение, объясняющее конфликт.³

Отсюда следует один важный вывод. Если политика управляется через GPO, -ExecutionPolicy Bypass, прописанный в задаче или ярлыке, не действует. Прямо указано, что указание области Process побеждает конфигурацию LocalMachine/CurrentUser, но не может победить групповую политику.¹ Иными словами, приём «пропиши Bypass — и всё как-нибудь заработает» срабатывает только там, где организация вообще не управляет политикой выполнения.

4. Zone.Identifier (Mark of the Web) и Unblock-File

Понятие «удалённый (из интернета)» в RemoteSigned определяется не местом хранения файла, а меткой. Программы вроде браузеров прикрепляют к скачанным файлам альтернативный поток данных, помечая их как «файл, пришедший из интернета».¹ Этот поток называется Zone.Identifier и содержит значение 3, обозначающее интернет-зону. Это и есть так называемый Mark of the Web.⁴

При попытке запустить неподписанный скрипт с этой меткой в среде с политикой RemoteSigned запуск блокируется с ошибкой «файл не имеет цифровой подписи». Решение состоит из двух шагов.

# 1) Сначала проверьте, какие файлы заблокированы (безопасная операция, только чтение)
Get-Item -Path C:\Tools\*.ps1 -Stream Zone.Identifier -ErrorAction SilentlyContinue

# 2) Снимайте блокировку только с тех файлов, чьё содержимое вы проверили и признали безопасным
#    (Unblock-File удаляет поток Zone.Identifier; сама политика выполнения не меняется)
Unblock-File -Path C:\Tools\Get-InventoryReport.ps1

Unblock-File — это командлет, удаляющий альтернативный поток данных Zone.Identifier; это та же операция, что и кнопка «Разблокировать» (Unblock) в свойствах файла в проводнике. Важно то, что можно пропускать только проверенные файлы, не ослабляя саму политику выполнения.⁴ Официальная документация тоже указывает обязательным шагом «проверить файл и источник его получения перед использованием и убедиться в его безопасности».⁴³

Стоит знать и о ловушке в обратную сторону. Не каждый способ получения файла прикрепляет Mark of the Web. Прямо указано, что файлы, скачанные через curl.exe, Invoke-WebRequest или Invoke-RestMethod, иногда не получают метку интернет-зоны.¹ Иными словами, RemoteSigned — не гарантия того, что «все опасные скачанные файлы будут остановлены» (именно поэтому это защитный механизм, а не граница безопасности). Есть и предупреждение о том, что в системах, настроенных не различать пути UNC и интернет-пути, скрипт на общей папке иногда отклоняется при политике RemoteSigned.¹ Если «.ps1 на общей папке останавливается только на некоторых компьютерах», подозревайте настройки зон и наличие Zone.Identifier.

Кстати, о механизме SmartScreen, вызывающем похожий симптом со стороны скачанных исполняемых файлов (.exe), мы пишем в статье «Почему Windows показывает сообщение «Windows защитил ваш компьютер»».

5. Практика подписи скриптов — Set-AuthenticodeSignature и временные метки

Чтобы перейти к эксплуатации AllSigned или к подписи распространяемых файлов в среде RemoteSigned, нужен сертификат для подписи кода. Способы его получения можно свести к трём вариантам.⁵

Официальная документация даёт ту же классификацию: «сертификат, выданный удостоверяющим центром, доверен и на других компьютерах», а «самостоятельно созданный сертификат бесплатен, но действителен только на вашем компьютере, и его следует использовать исключительно для тестирования».⁵ Если цель — внутреннее распространение, реалистичнее всего выдавать сертификат для подписи кода через внутренний ЦС, например Active Directory Certificate Services.

Сначала проверим весь процесс на тестовом самоподписанном сертификате.

# Создаём тестовый сертификат для подписи кода (самоподписанный ── доверен только на этой машине)
$params = @{
    Subject           = 'CN=KomuraSoft Code Signing (Test)'
    Type              = 'CodeSigningCert'
    CertStoreLocation = 'Cert:\CurrentUser\My'
    HashAlgorithm     = 'sha256'
}
$cert = New-SelfSignedCertificate @params

New-SelfSignedCertificate — это командлет, создающий самоподписанный сертификат для целей тестирования; указав -Type CodeSigningCert, вы добавляете расширение для подписи кода. Срок действия по умолчанию — один год.⁷ Если самоподписанный сертификат используется для тестирования среды AllSigned, его нужно зарегистрировать в хранилище доверенных корневых центров сертификации на этой машине.⁵

Само подписание в боевом режиме — это одна строка.

# Получаем сертификат для подписи кода из хранилища сертификатов и подписываем
# -CodeSigningCert лишь сужает выбор до «сертификатов, пригодных для подписи кода»,
# поэтому дополнительно ограничиваем выбор действующими сертификатами с закрытым ключом,
# а при наличии нескольких подходящих — уточняем по Subject или Thumbprint
$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert |
    Where-Object { $_.HasPrivateKey -and $_.NotAfter -gt (Get-Date) -and
                   $_.Subject -eq 'CN=KomuraSoft Code Signing (Test)' } |
    Sort-Object NotAfter -Descending |
    Select-Object -First 1   # Если из-за продления есть несколько сертификатов с одинаковым Subject, берём тот, что действует дольше всех

# Временная метка обязательна. Благодаря ей подпись остаётся действительной даже после истечения срока сертификата
# Замените URL на службу временных меток, которую рекомендует издатель вашего сертификата (внутренний ЦС или поставщик)
Set-AuthenticodeSignature -FilePath .\Invoke-NightlyBatch.ps1 -Certificate $cert `
    -HashAlgorithm SHA256 -TimestampServer 'http://timestamp.example.com'

# Проверить статус подписи можно командой Get-AuthenticodeSignature (Valid/NotSigned/HashMismatch и т. д.)
Get-AuthenticodeSignature -FilePath .\Invoke-NightlyBatch.ps1

Есть три важные особенности, которые стоит зафиксировать.⁶⁵

• Подпись встраивается в конец файла в виде блока комментариев # SIG #. Если уже есть подпись, она заменяется. Иными словами, изменение скрипта хотя бы на один символ после подписания делает подпись недействительной. Именно это и работает как обнаружение изменений.
• Указание -TimestampServer означает, что скрипт не перестанет работать даже после истечения срока действия сертификата. Подпись остаётся действительной «пока действителен сертификат подписи» либо «пока сервер меток времени способен подтвердить, что подпись была поставлена, когда сертификат ещё был действителен»; поскольку большинство сертификатов для подписи кода действительны год, временная метка становится жизненно важной для долгосрочной эксплуатации.⁶⁵ URL используемой службы меток времени следует брать из инструкций издателя вашего сертификата (ЦС).
• В Windows PowerShell 5.1 и в версиях PowerShell до 7.2 скрипт для подписания нужно было сохранять в кодировке ASCII или UTF8NoBOM. Начиная с PowerShell 7.2 поддерживаются подписанные скрипты в любой кодировке.⁵ На площадках, где ещё используется 5.1, стоит быть особенно внимательным: проверка подписи скриптов с комментариями на японском языке из-за кодировки часто ломается. Подробнее об общих различиях между 5.1 и 7 см. в статье «Различия между Windows PowerShell 5.1 и PowerShell 7 и переход между ними».

В среде AllSigned, даже если скрипт подписан, но издатель ещё не классифицирован как доверенный или отклонённый, при запуске появляется запрос «Выполнить программное обеспечение от этого недоверенного издателя?». Если выбрать «Всегда выполнять», в дальнейшем для этого издателя подтверждение запрашиваться не будет.¹⁵ При работе с внутренним ЦС можно дополнительно распространить сертификат издателя в хранилище «Доверенные издатели» на каждой машине и полностью убрать этот запрос из эксплуатации.

6. Стандартная практика (таблица решений) — от «затыкания дыр Bypass» до процесса подписи

Управление распространением и запуском внутренних скриптов принято продумывать по следующей таблице решений.

Дополним последнюю строку. Проблема эксплуатации, «затыкающей дыры ExecutionPolicy Bypass», заключается не в самом факте открытия бреши в безопасности (ведь политика выполнения изначально не была границей). Проблема в следующих трёх вещах.

• Отказ от защитного механизма — вы навсегда снимаете последнюю сетку, предотвращающую случайный запуск не того скрипта или незаметный запуск изменённого скрипта.
• Расхождение с управлением — в тот момент, когда политика выполнения начинает управляться через GPO, указание Bypass перестаёт действовать, и все задачи, которые оно «затыкало», разом начинают падать.¹ Это технический долг, при котором «причина, по которой всё работало», оказывается неуправляемой лазейкой.
• Помеха расследованию причин — когда Bypass разбросан по разным местам, поведение системы перестаёт быть предсказуемым по действующей политике окружения, и расследование различий между машинами («почему падает именно на этой машине») сильно усложняется.

Сам по себе Bypass — это настройка, предусмотренная для конфигураций, где приложение, встраивающее PowerShell, управляется собственной моделью безопасности.¹ Смиритесь с тем, что это не то, что стоит постоянно использовать как опцию запуска для написанных людьми рабочих скриптов. Построение безопасного регулярного выполнения в планировщике заданий подробно разобрано в статье «Почему задачи планировщика заданий не запускаются или завершаются с кодом 0x1 ── разбор причин и проектирование безопасной эксплуатации».

7. Итог

• Политика выполнения — это защитный механизм, а не граница безопасности. Противодействие атакам ведите на другом уровне, а на политику выполнения возлагайте задачу «предотвращения случайных ошибок».
• У политики пять областей действия с приоритетом MachinePolicy > UserPolicy > Process > CurrentUser > LocalMachine. Диагностику начинайте с команды Get-ExecutionPolicy -List.
• RemoteSigned опирается на Zone.Identifier (Mark of the Web). Проверенные файлы пропускайте командой Unblock-File, не ослабляя саму политику.
• Подписывайте командой Set-AuthenticodeSignature, обязательно указывая -TimestampServer. Для внутреннего распространения используйте сертификат внутреннего ЦС; самоподписанный — только для тестов.
• Организационный контроль централизуйте через параметр групповой политики «Включить выполнение сценариев». Он имеет приоритет над всеми областями действия и над указанием -ExecutionPolicy.
• Постоянное использование -ExecutionPolicy Bypass — это отказ от защитного механизма, и под управлением GPO оно не действует. Правильный путь — сделать «затыкание дыр» ненужным, наладив политику окружения и процесс подписи.

Похожие статьи

• Основы команд PowerShell ── что выучить в первую очередь и как использовать их безопасно
• Почему Windows показывает сообщение «Windows защитил ваш компьютер»
• Почему задачи планировщика заданий не запускаются или завершаются с кодом 0x1 ── разбор причин и проектирование безопасной эксплуатации
• Обработка ошибок и проектирование повторных попыток (retry) для скриптов PowerShell
• Различия между Windows PowerShell 5.1 и PowerShell 7 и переход между ними
• Переход от bat-файлов к PowerShell: как принять решение

Смежные области консультирования

KomuraSoft LLC (合同会社小村ソフト) занимается проектированием политики выполнения и процесса подписи внутренних скриптов PowerShell, рассмотрением развёртывания через групповую политику и расследованием различий окружения — например, случаев «скрипт не работает только на определённых машинах». Мы также можем помочь перевести существующие активы в виде bat-файлов и скриптов на безопасную эксплуатацию.

• Техническая консультация и ревью проекта
• Исследование ошибок и анализ первопричин
• Доработка и сопровождение существующего ПО для Windows
• Связаться с нами

Справочные ссылки

Похожие статьи

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

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

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

Является ли политика выполнения PowerShell функцией безопасности?

Официальная документация прямо говорит: «политика выполнения — это не система безопасности, ограничивающая действия пользователя». Причина в том, что её легко обойти, просто вставив содержимое скрипта в командную строку. Цель политики выполнения — задать базовые правила и служить защитным механизмом, который предотвращает случайное «непреднамеренное выполнение скрипта», а не строить архитектуру вокруг неё как вокруг границы безопасности, останавливающей злоумышленника. Противодействие атакам — задача другого уровня (контроль приложений, минимизация прав и так далее).

В чём разница между RemoteSigned и AllSigned?

RemoteSigned требует подписи доверенного издателя только для скриптов, полученных из интернета (несущих Mark of the Web); скрипты, созданные локально, могут выполняться без подписи. AllSigned требует подписи для всех скриптов и файлов конфигурации, включая созданные локально, и запрашивает подтверждение перед запуском скрипта от ещё не классифицированного издателя. AllSigned — реалистичный выбор, если в компании можно наладить процесс подписи (распространение сертификатов для подписи кода и процедуру подписания); если такой инфраструктуры нет, реалистичнее выбрать RemoteSigned.

Почему скачанный скрипт не запускается с ошибкой «не имеет цифровой подписи»?

Потому что к файлам, скачанным через браузер и подобные программы, прикрепляется альтернативный поток данных Zone.Identifier, и они помечаются как «файл, пришедший из интернета». При политике выполнения RemoteSigned неподписанный скрипт с этой меткой блокируется от запуска. Если вы проверили содержимое и убедились в его безопасности, можно снять Zone.Identifier командлетом Unblock-File или флажком «Разблокировать» в свойствах файла в проводнике — и запустить скрипт, не меняя политику выполнения.

Как реалистично организовать эксплуатацию скриптов PowerShell, распространяемых внутри компании?

В целом есть два варианта. Первый — RemoteSigned плюс размещение на файловом сервере: можно начать, не выстраивая систему подписи, но в зависимости от канала распространения может прикрепиться Mark of the Web и заблокировать выполнение, а изменение скрипта обнаружить тоже не получится. Второй — AllSigned плюс процесс подписи: скрипты подписываются командой Set-AuthenticodeSignature с помощью сертификата для подписи кода (реалистичнее всего — выданного внутренним удостоверяющим центром), а политика централизованно управляется через групповую политику. В обмен на контроль над политикой выполнения и возможность обнаруживать изменения приходится нести операционные затраты на распространение и обновление сертификатов.

Можно ли и дальше постоянно указывать -ExecutionPolicy Bypass в планировщике заданий?

Это будет работать, но не рекомендуется. Во-первых, в среде, где политика выполнения управляется через групповую политику, указание ExecutionPolicy в командной строке не может победить групповую политику, поэтому оно попросту не действует. Во-вторых, постоянное использование Bypass — это самостоятельный демонтаж защитного механизма, предотвращающего случайный запуск, и со временем это приводит к расхождению между политикой организации и реальным положением дел на местах. Если нужна постоянная эксплуатация, правильный путь — задать политику окружения через групповую политику или через Set-ExecutionPolicy от имени администратора, а доверие к скриптам обеспечивать подписью.

Зачем при подписи скрипта нужна временная метка (-TimestampServer)?

Действительность подписи в принципе привязана к сроку действия сертификата подписи, но при наличии временной метки сервер меток времени подтверждает, что «подпись была поставлена, пока сертификат ещё был действителен», поэтому скрипт можно продолжать использовать и после истечения срока действия сертификата. Большинство сертификатов для подписи кода действительны около года, поэтому эксплуатация без временной метки каждый год несёт риск того, что «в один прекрасный день все подписанные скрипты компании разом перестанут работать». Обязательно указывайте -TimestampServer при подписании.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.