Как включить запуск скриптов в Windows 10

Кратко: Этот материал объясняет, как безопасно разрешить запуск скриптов в Windows 10 — через Параметры, PowerShell, Group Policy и реестр. Приведены команды, чек-листы для ролей, сценарии тестирования, рекомендации по безопасности и схема принятия решения.

enable running scripts on windows 10

Запуск скриптов в Windows 10 даёт мощные возможности автоматизации, настройки и устранения неисправностей. Однако неправильная настройка может повысить риск выполнения вредоносного кода. В этой статье вы найдёте пошаговые инструкции, рекомендации по безопасности, критерии приёмки и планы отката.

Что даёт включение запуска скриптов

Включение выполнения скриптов полезно по ряду причин:

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

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

Краткая терминология

Политика выполнения (Execution Policy) — встроенный механизм PowerShell, ограничивающий запуск скриптов по уровням доверия.
RemoteSigned, AllSigned, Unrestricted, Bypass — стандартные режимы политики выполнения (см. раздел «Политики выполнения»).

Проверки перед началом

У вас есть права администратора на компьютере.
Установлен PowerShell (в большинстве Windows 10 он предустановлен). При необходимости обновите через официальный сайт Microsoft.
Понимаете источник и цель запускаемых скриптов.

1. Через приложение «Параметры» (Settings)

Нажмите Windows + I, чтобы открыть Параметры.
Перейдите в Обновление и безопасность.
В левой колонке выберите Для разработчиков.
Включите Переключатель Режим разработчика.
Разверните раздел PowerShell и установите отметку Изменять политику выполнения, чтобы разрешить локальные PowerShell-скрипты без подписи. Требовать подпись для удалённых скриптов.
Нажмите Применить и закройте окно.

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

2. Через Windows PowerShell

Откройте PowerShell с нужным уровнем прав и выполните одну из команд в зависимости от задачи.

Нажмите Windows, введите powershell и откройте приложение.

Чтобы разрешить запуск скриптов для текущего пользователя:

Set-ExecutionPolicy Bypass -Scope CurrentUser -Force

Чтобы разрешить для всей машины (локально):

Set-ExecutionPolicy Unrestricted -Scope LocalMachine -Force

Если нужно временно разрешить выполнение только для текущего процесса (без изменения системной политики):

Set-ExecutionPolicy Bypass -Scope Process -Force

Важно: Scope=Process безопаснее для разовых запусков, Scope=CurrentUser не требует прав администратора и влияет только на профиль текущего пользователя.

3. Через Редактор локальной групповой политики (Group Policy Editor)

Нажмите Windows + R, чтобы открыть окно Выполнить.
Введите gpedit.msc и нажмите ОК.
Перейдите в: User Configuration\Administrative Templates\Windows Components\Windows PowerShell
В правой панели дважды кликните Включить выполнение сценариев (Turn on Script Execution).
Выберите Включено, в параметрах выберите Разрешить все скрипты (Allow all scripts).
Нажмите Применить, затем ОК.

Group Policy подходит для управления политиками на уровне предприятия и позволяет централизованно применять настройки к группе машин.

4. Через реестр Windows (Registry Editor)

Нажмите Windows + R и откройте Выполнить.
Введите regedit и нажмите ОК.
Перейдите по пути:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell

Найдите параметр ExecutionPolicy и дважды щёлкните по нему.
Измените значение на AllSigned или RemoteSigned в зависимости от нужной политики.
Нажмите ОК, закройте редактор реестра.

Предупреждение: изменения реестра влияют на всю систему. Делайте резервную копию ключей перед изменением.

Политики выполнения: что означают и когда выбирать

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

Рекомендуемая практика: для рабочих станций — RemoteSigned; для серверов и критичных рабочих мест — AllSigned; для временных задач — Process=Bypass.

Схема принятия решения (Mermaid)

flowchart TD
  A[Нужно запустить скрипт?] --> B{Источник скрипта}
  B -->|Доверенный локальный| C[RemoteSigned или CurrentUser]
  B -->|Подписанный| D[AllSigned]
  B -->|Временный одноразовый| E[Process=BYPASS]
  B -->|Неизвестный/ненадёжный| F[Не запускать]
  C --> G[Тест и аудит]
  D --> G
  E --> G
  G --> H[Мониторинг и откат]

Практическая процедура безопасности (SOP) для администраторов

Оцените необходимость: подтвердите, почему нужен запуск скриптов.
Тестовая среда: разверните изменения в тестовой машине с Snapshot/точкой восстановления.
Выберите минимально возможную политику (Process или CurrentUser, если достаточно).
Подпишите внутренние скрипты с помощью корпоративного сертификата, используйте AllSigned на серверах.
Внедрите через Group Policy для множества компьютеров.
Включите аудит: логирование выполнения PowerShell (Module Logging, Script Block Logging).
План отката: заранее сохраните исходные значения ExecutionPolicy и создайте точку восстановления реестра.

Чек-листы по ролям

Администратор:

Проверить права доступа и резервные копии реестра.
Настроить Group Policy для домена.
Настроить аудит и централизованные логи.

Разработчик / инженер поддержки:

Тестировать скрипты в изолированной среде.
Использовать подписи и контроль версий.
Документировать зависимости.

Офицер по безопасности:

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

Критерии приёмки

Скрипт запускается в тестовой среде с выбранной политикой.
Аудит и логирование включены и отправляют события в SIEM/централизованный лог.
Резервная точка восстановления создана.
План отката проверен и документирован.

Типовые проблемы и способы их решения

Ошибка “execution of scripts is disabled on this system”: выполнить Set-ExecutionPolicy с нужным Scope.
Отказ в правах доступа: запустите PowerShell от имени администратора или используйте Scope=CurrentUser.
Проблемы с подписью: проверьте цепочку сертификатов и дату истечения.
Политика домена переопределяет локальные настройки: проверьте GPO на уровне домена.

Тест-кейсы и проверка

Тест-кейс 1: Запуск простого скрипта у пользователя с Scope=CurrentUser — ожидаемый результат: скрипт выполняется.
Тест-кейс 2: Запуск неподписанного удалённого скрипта при RemoteSigned — ожидание: скрипт блокируется или требует подтверждения.
Тест-кейс 3: Временный запуск с Process=BYPASS — ожидание: после закрытия процесса политика не меняется.
Тест-кейс 4: Внедрение через GPO — ожидание: клиенты домена получают настройку после обновления политики.

Модель зрелости управления скриптами (2 уровня)

Уровень 1 (Базовый): RemoteSigned на рабочих станциях, ручное управление.
Уровень 2 (Контролируемый): Подпись скриптов, AllSigned для серверов, централизованный аудит и GPO.

Матрица рисков и смягчающие меры

Выполнение неподписанных скриптов — риск: высокий. Меры: AllSigned, проверка источников, SIEM.
Изменения реестра — риск: средний. Меры: резервирование, тестирование, контроль доступа.
Промежуточные обходы (Bypass) — риск: высокий. Меры: использовать только временно и под наблюдением.

Совместимость и миграция

PowerShell 5.1 и новее поддерживает те же политики выполнения. Если на устройстве установлен PowerShell Core (7+), политика выполнения управляется аналогично, но стоит проверить Scope и настройки модулей.

Примеры команд для быстрого восстановления

Сохранить текущую политику в переменную для отката:

$old = Get-ExecutionPolicy -List

Вернуть политику для LocalMachine:

Set-ExecutionPolicy $old["LocalMachine"].ExecutionPolicy -Scope LocalMachine -Force

Дополнительные советы и лучшие практики

Подписывайте корпоративные скрипты цифровой подписью и храните сертификат в защищённом хранилище.
Включите Script Block Logging и Module Logging для расследований инцидентов.
Ограничьте привилегии: используйте Least Privilege для запуска скриптов.

Контрольный список перед развёртыванием в продакшн

Тестовая среда настроена и проверена.
Бэкап реестра/снимок системы создан.
Аудит включён и интегрирован с SIEM.
Политика выбрана и документирована.
План отката и ответственные лица назначены.

Часто встречающиеся вопросы

Q: Могу ли я разрешить скрипты только для одного запуска?
A: Да — используйте Scope=Process (Process=BYPASS) для одноразового запуска.

Q: Что безопаснее — AllSigned или RemoteSigned?
A: AllSigned строже и безопаснее, так как требует подпись для всех скриптов.

Q: Политика домена переопределяет локальные настройки, как это обойти?
A: Нельзя обойти GPO без прав администратора домена; нужно изменить политику на контроллере домена или создать исключение.

Заключение

Включение запуска скриптов в Windows 10 может значительно повысить эффективность, но требует продуманного подхода к безопасности. Выберите минимально необходимую политику, подписывайте скрипты, тестируйте в изолированной среде и включайте аудит. Соблюдение чек-листов и процедур снизит риск и обеспечит восстановимость в случае проблем.

Если возникли вопросы или у вас есть опыт внедрения — поделитесь в комментариях ниже.

Прочитать больше:

Windows 10 Emoji Search Breaks After Latest Update, and There’s No Fix Yet
Windows 10 Build 19045.6156 hits Release Preview with Secure Boot upgrade