Как настроить выполнение подписанных скриптов в PowerShell: политики, подписи и проверка настроек

Чтобы настроить выполнение подписанных скриптов PowerShell, нужно определить подходящую политику выполнения, выбрать область её применения и убедиться, что скрипты имеют доверенную цифровую подпись. Главный принцип: разрешать запуск не всех сценариев подряд, а только тех, происхождение и целостность которых можно проверить.

Чаще всего для управляемой среды используют политики RemoteSigned или AllSigned. Первая требует подпись для загруженных из внешних источников скриптов, а вторая требует подпись для всех сценариев, включая созданные локально. Выбор зависит от того, насколько строгий контроль нужен и кто управляет скриптами.

Что такое политика выполнения PowerShell

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

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

В PowerShell используются несколько основных вариантов политики:

• Restricted — блокирует выполнение скриптов. Подходит для систем, где запуск сценариев не нужен.
• RemoteSigned — разрешает локальные скрипты без подписи, но требует подписи для скриптов, полученных из внешних источников.
• AllSigned — требует доверенную цифровую подпись для всех скриптов и файлов конфигурации.
• Unrestricted — позволяет выполнять скрипты с минимальными ограничениями и требует осторожности.
• Bypass — отключает проверки политики выполнения и обычно применяется только в специальных сценариях автоматизации.

Когда имеет смысл использовать AllSigned и RemoteSigned

Выбор политики зависит от того, как организована работа со скриптами. Чем больше пользователей имеют возможность создавать или запускать сценарии, тем важнее контроль происхождения файлов.

Политика	Когда подходит	Особенности
RemoteSigned	Персональные компьютеры и рабочие среды с локальной разработкой скриптов	Удобный баланс между безопасностью и удобством. Внешние скрипты должны быть подписаны.
AllSigned	Организации с централизованным управлением сценариями	Все скрипты должны проходить процедуру подписания доверенным издателем.
Bypass	Специализированные процессы, где безопасность контролируется другими механизмами	Не подходит как обычная настройка для рабочих компьютеров.

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

Как проверить текущую политику выполнения

Перед изменением настроек нужно определить, какая политика действует сейчас и какая область её задаёт.

1. Откройте PowerShell.
2. Проверьте активную политику командой:

Get-ExecutionPolicy

Эта команда показывает эффективную политику для текущего сеанса.

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

Get-ExecutionPolicy -List

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

Настройка политики выполнения подписанных скриптов

Для изменения политики используется командлет Set-ExecutionPolicy. Настройку можно применять ко всему компьютеру или только к текущему пользователю.

Например, чтобы включить режим RemoteSigned для текущего пользователя:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Если требуется обязательная подпись всех скриптов:

Set-ExecutionPolicy -ExecutionPolicy AllSigned -Scope CurrentUser

Область CurrentUser изменяет настройки только для одного пользователя. Область LocalMachine применяется ко всем пользователям компьютера и обычно требует повышенных прав.

Перед изменением политики стоит учитывать:

• какие пользователи будут запускать скрипты;
• откуда будут поступать сценарии;
• кто отвечает за выпуск и проверку подписей;
• нужно ли централизованное управление через групповую политику.

Как работает цифровая подпись PowerShell-скрипта

Подпись скрипта создаётся с помощью сертификата подписи кода. Она позволяет PowerShell проверить, что файл не был изменён после подписания и что он принадлежит указанному издателю.

Для запуска подписанного скрипта необходимо, чтобы сертификат был признан доверенным системой. Если сертификат неизвестен компьютеру, PowerShell может потребовать дополнительного подтверждения или отказаться выполнять сценарий в зависимости от настроек.

При проверке подписи важно учитывать несколько факторов:

• срок действия сертификата;
• доверие к центру сертификации или самозаверенному сертификату;
• соответствие сертификата назначению для подписи кода;
• отсутствие изменений файла после подписания.

Как проверить, подписан ли скрипт

Перед запуском неизвестного сценария полезно проверить его подпись. Для этого используется команда:

Get-AuthenticodeSignature путь_к_скрипту.ps1

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

Настройка через групповую политику

В организациях с большим количеством компьютеров настройки часто задаются централизованно через групповую политику Windows. Такой подход позволяет единообразно применять требования к запуску сценариев.

Через групповую политику можно выбрать режимы, соответствующие основным политикам PowerShell:

• разрешить только подписанные скрипты — аналог AllSigned;
• разрешить локальные скрипты и удалённые подписанные — аналог RemoteSigned;
• разрешить выполнение всех скриптов — аналог Unrestricted.

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

Почему подписанный скрипт всё равно может не запускаться

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

Наиболее распространённые причины:

• Сертификат не является доверенным. Компьютер не может подтвердить издателя скрипта.
• Скрипт был изменён после подписания. Даже небольшое изменение текста нарушает проверку подписи.
• Политика задаётся другой областью. Например, групповая политика имеет приоритет над локальной настройкой.
• Скрипт был получен из внешнего источника. При RemoteSigned к таким файлам применяются дополнительные проверки.
• Используется другая версия PowerShell. Настройки Windows PowerShell и PowerShell могут отличаться.

Типичные ошибки при настройке выполнения подписанных скриптов

Изменение политики без проверки текущих настроек

Иногда пользователь сразу устанавливает новую политику, но проблема остаётся. Причина может быть в том, что фактическое ограничение установлено на другом уровне.

Правильный подход — сначала выполнить проверку через Get-ExecutionPolicy -List, а затем менять именно тот уровень, который действительно используется.

Использование Bypass вместо настройки доверия

Отключение проверок может быстро решить проблему запуска, но одновременно убирает механизм контроля. Если причина ошибки связана с сертификатом или доверием к издателю, лучше исправить именно её.

Подписание скриптов неизвестным сертификатом

Сам факт наличия подписи недостаточен. Если сертификат создан без понятной процедуры доверия, другие компьютеры всё равно могут блокировать выполнение.

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

Для большинства задач достаточно следующего алгоритма:

1. Определите, какие скрипты должны запускаться: только внутренние, полученные извне или все используемые в организации.
2. Проверьте текущие политики выполнения и их области действия.
3. Выберите подходящий режим: RemoteSigned для более гибкой работы или AllSigned для строгого контроля.
4. Настройте политику через PowerShell или централизованное управление.
5. Проверьте подписи используемых скриптов.
6. Протестируйте запуск на обычном сценарии, прежде чем распространять настройку на большое количество систем.

Что выбрать в зависимости от ситуации

Если скрипты создаются одним пользователем на своём компьютере и не распространяются извне, строгая политика может создавать лишние препятствия. В такой ситуации чаще подходит RemoteSigned.

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

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

Что проверить перед окончательной настройкой

• Есть ли понятный источник каждого запускаемого скрипта.
• Назначены ли ответственные за создание и подписание сценариев.
• Доверяют ли компьютеры используемым сертификатам.
• Не переопределяет ли настройки групповая политика.
• Соответствует ли выбранная политика реальному уровню риска.

Как действовать дальше

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

Практический следующий шаг — проверить текущую конфигурацию через Get-ExecutionPolicy -List, определить источник ограничений и только затем выбрать подходящую политику. Если требуется строгий контроль, настройка должна включать не только Execution Policy, но и управление сертификатами доверия.