Как настроить Windows для удобной работы с PowerShell-скриптами

Краткое содержание

• Как и зачем Windows и PowerShell блокируют выполнение скриптов.
• Изменение ассоциации файлов .PS1.
• Настройка PowerShell ExecutionPolicy.
• Запуск скриптов от имени администратора.
• Финальные штрихи: -NoExit, ISE вместо Notepad и т.д.
• Тестирование и проверка.
• Методики, чек-листы и сценарии для ролей.

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

Как и зачем Windows и PowerShell блокируют выполнение скриптов.

PowerShell — это и оболочка, и язык сценариев, который заменяет классический CMD и батники на современных Windows-системах. Скрипт PowerShell имеет доступ к телу операционной системы примерно в тех же пределах, что и команды, запускаемые вручную: чтение/запись файлов, изменение реестра, управление сервисами и т.д. Это даёт огромное удобство автоматизации, но одновременно создаёт значительную угрозу, если скрипт запускается случайно или злонамеренно.

Пример простой, но разрушительной команды (не запускать):

Get-ChildItem "$env:SystemDrive\" -Recurse -ErrorAction SilentlyContinue | Remove-Item -Force -Recurse -ErrorAction SilentlyContinue

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

Почему Windows и PowerShell защищают пользователя по умолчанию:

• Предотвращение случайного двойного клика и мгновенного исполнения произвольного кода.
• Ограничение запуска неподписанных скриптов и скриптов, содержащих пометку «с Интернета» (Zone.Identifier).
• Разделение областей исполнения и областей применения политик (Scopes) для управления локальными и групповыми политиками.

Короткая дефиниция: ExecutionPolicy — механизм PowerShell, ограничивающий выполнение скриптов по цифровой подписи и происхождению.

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

Изменение ассоциации .PS1 файлов.

По умолчанию Windows не ассоциирует расширение .ps1 с исполнением в PowerShell (двойной клик обычно открывает Notepad). Это поведение защищает от случайного запуска, но неудобно для разработчиков скриптов.

Существует несколько подходов:

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

Ключ реестра, контролирующий поведение .ps1 файлов:

HKEY_CLASSES_ROOT\Microsoft.PowerShellScript.1\Shell

В под-ключах Shell обычно присутствуют действия:

• 0 — Run with PowerShell (в контекстном меню уже есть строка «Run with PowerShell»).
• Edit — открыть в PowerShell ISE.
• Open — открыть в Notepad (значение по умолчанию для двойного клика).

Изменение значения по умолчанию на уровне Shell перенастроит действие при двойном щелчке.

Если вы предпочитаете работать через PowerShell, можно создать PSDrive для HKEY_CLASSES_ROOT и менять значения через команды. Пример создания PSDrive (требуется запуск от администратора):

New-PSDrive HKCR Registry HKEY_CLASSES_ROOT

После этого вы можете менять действие двойного клика:

• Установить запуск скрипта при двойном щелчке:

Set-ItemProperty HKCR:\Microsoft.PowerShellScript.1\Shell '(Default)' 0

• Открывать в PowerShell ISE:

Set-ItemProperty HKCR:\Microsoft.PowerShellScript.1\Shell '(Default)' 'Edit'

• Восстановить стандартное поведение (открывать в Notepad):

Set-ItemProperty HKCR:\Microsoft.PowerShellScript.1\Shell '(Default)' 'Open'

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

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

Настройка PowerShell ExecutionPolicy.

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

Доступные политики (от самого строгого к свободному):

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

Области (scopes), в которых задаётся политика (в порядке приоритета):

• MachinePolicy — групповые политики на уровне компьютера (обычно в домене).
• UserPolicy — групповые политики на уровне пользователя.
• Process — политика для текущего процесса PowerShell (влияет только на эту сессию).
• CurrentUser — политика, заданная в реестре текущего пользователя.
• LocalMachine — политика, заданная в реестре для всех пользователей машины.

Команда для просмотра текущих настроек всех областей:

Get-ExecutionPolicy -List

Рекомендованная комбинация для баланса удобства и безопасности, если вы один пользователь на машине:

• LocalMachine: Restricted (защитит других пользователей системы от случайного запуска скриптов).
• CurrentUser: Unrestricted (позволит вам запускать собственные скрипты без лишних барьеров).
• Process (для запуска из Explorer): RemoteSigned (позволяет двойной клик для локальных скриптов, но блокирует скрипты, помеченные как загруженные из Интернета).

Установка LocalMachine и CurrentUser (в повышенной сессии PowerShell):

Set-ExecutionPolicy Restricted
Set-ExecutionPolicy Unrestricted -Scope CurrentUser

Примечание: если вы запускаете Set-ExecutionPolicy без -Scope, по умолчанию изменится LocalMachine и для этого требуется Elevation.

Чтобы элементарно понять, какая команда настроит политику для процессов, запускаемых из Explorer, нужно изменить значение в реестре, которое мы уже рассматривали для команды запуска (.\Shell\Command). Текущая строка может выглядеть по-разному в зависимости от версии Windows / PowerShell.

Примеры реестровых строк, встречающихся на практике:

(Наблюдалось на Windows 7 SP1 x64, PowerShell 2.0)

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-file" "%1"

(Наблюдалось на Windows 8.1 x64, PowerShell 4.0)

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-Command" "if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass }; & '%1'"

Второй вариант — опасный обход политики, потому что он в Process-области применяет Bypass при запуске из Explorer, фактически игнорируя любые локальные и пользовательские ограничения.

Чтобы установить безопасное поведение (Process-level RemoteSigned) для скриптов, запускаемых из Explorer, измените значение на:

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-ExecutionPolicy" "RemoteSigned" "-file" "%1"

Запрос текущего значения (после создания PSDrive HKCR):

Get-ItemProperty HKCR:\Microsoft.PowerShellScript.1\Shell\Command | Select-Object '(Default)'

Изменение через PowerShell (в повышенной сессии):

Set-ItemProperty HKCR:\Microsoft.PowerShellScript.1\Shell\Command '(Default)' '"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-ExecutionPolicy" "RemoteSigned" "-file" "%1"'

Важно: всегда проверяйте, что именно вы прописываете в реестр. Неправильная строка может сделать невозможным запуск скриптов или вызвать неожиданные эффектЫ.

Запуск PowerShell-скриптов как Администратор.

Политика принципиальна: не следует запускать всё от Admin по умолчанию. Но иногда требуются действия с повышенными правами (установка программ, изменение системных настроек). Хорошая практика — оставить стандартный запуск без elevation и добавить отдельный пункт в контекстное меню для запуска от имени администратора.

Добавление пункта в реестр (руками через Regedit):

Перейдите в:

HKEY_CLASSES_ROOT\Microsoft.PowerShellScript.1\Shell

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

• Run with PowerShell (Admin)
  • Command
    • (Default) =

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-Command" ""& {Start-Process PowerShell.exe -ArgumentList '-ExecutionPolicy RemoteSigned -File \"%1\"' -Verb RunAs}"

Эта строка запускает новую сессию PowerShell с поставленной задачей стартовать от имени администратора (Start-Process … -Verb RunAs). Первый экземпляр выступает «стартером», второй — уже с повышением привилегий.

Создание тех же ключей из PowerShell потребует трёх вызовов (New-Item для двух ключей и Set-ItemProperty для значения):

New-Item 'HKCR:\Microsoft.PowerShellScript.1\Shell\Run with PowerShell (Admin)'
New-Item 'HKCR:\Microsoft.PowerShellScript.1\Shell\Run with PowerShell (Admin)\Command'
Set-ItemProperty 'HKCR:\Microsoft.PowerShellScript.1\Shell\Run with PowerShell (Admin)\Command' '(Default)' '"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-Command" ""& {Start-Process PowerShell.exe -ArgumentList ''-ExecutionPolicy RemoteSigned -File \"%1\"'' -Verb RunAs}"'

Обратите внимание на кавычки: комбинация одинарных и двойных кавычек необходима, чтобы корректно записать значение в реестр через PowerShell.

Результат: новый пункт контекстного меню «Run with PowerShell (Admin)». При выборе будет показан UAC Prompt, а затем скрипт выполнится с повышенными правами.

Важно: пункт «Run with PowerShell (Admin)» создаёт два процесса PowerShell: первый выступает как «запускатор», второй — как повышенная сессия. Это нормально.

Финальные штрихи: удобство вывода и ISE вместо Notepad.

Несколько мелких настроек делают работу с .ps1 файлами приятнее:

• Заменить открытие в Notepad на PowerShell ISE (powersehll_ise.exe), чтобы при двойном щелчке редактировать скрипты в интегрированной среде разработки.
• Добавить параметр -NoExit к командам запуска, чтобы окно консоли не закрывалось автоматически по завершении скрипта — это полезно для просмотра вывода и отладки.

Значение для Open/Command, открывающее в ISE:

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell_ise.exe" "%1"

Команды PowerShell для установки Open->ISE (Elevated & HKCR):

Set-ItemProperty HKCR:\Microsoft.PowerShellScript.1\Shell\Open\Command '(Default)' '"C:\Windows\System32\WindowsPowerShell\v1.0\powershell_ise.exe" "%1"'

Чтобы окно не закрывалось (вариант для обычного запуска и для запуска от администратора):

Без elevation (Non-Admin):

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-NoExit" "-ExecutionPolicy" "RemoteSigned" "-file" "%1"

С elevation (Admin):

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-Command" ""& {Start-Process PowerShell.exe -ArgumentList '-NoExit -ExecutionPolicy RemoteSigned -File \"%1\"' -Verb RunAs}"

Через PowerShell (Non-Admin):

Set-ItemProperty HKCR:\Microsoft.PowerShellScript.1\Shell\Command '(Default)' '"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-NoExit" "-ExecutionPolicy" "RemoteSigned" "-file" "%1"'

Через PowerShell (Admin):

Set-ItemProperty 'HKCR:\Microsoft.PowerShellScript.1\Shell\Run with PowerShell (Admin)\Command' '(Default)' '"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-Command" ""& {Start-Process PowerShell.exe -ArgumentList ''-NoExit -ExecutionPolicy RemoteSigned -File \"%1\"'' -Verb RunAs}"'

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

Тестирование: запуск и проверка политик выполнения и прав

Пример тестового скрипта MyScript.ps1, находящегося в D:\Script Lab — этот скрипт проверяет, запущен ли он с правами администратора, и выводит список ExecutionPolicy для областей:

if(([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
{Write-Output 'Running as Administrator!'}
else {Write-Output 'Running Limited!'}
Get-ExecutionPolicy -List

Запуск через обычный пункт «Run with PowerShell» покажет исполнение без elevation и применённые политики.

Запуск через «Run with PowerShell (Admin)» после подтверждения UAC покажет, что скрипт выполняется с повышенными правами и, возможно, с другими значениями ExecutionPolicy в Process/CurrentUser/LocalMachine.

Чтобы продемонстрировать поведение RemoteSigned для файлов с пометкой «загружено из Интернета», можно добавить поток Zone.Identifier к файлу сценария:

Add-Content -Path 'D:\Script Lab\MyScript.ps1' -Value "[ZoneTransfer]`nZoneId=3" -Stream 'Zone.Identifier'

После этого PowerShell будет считать файл «скачанным из Интернета» и применит соответствующую политику.

Команда для удаления Zone.Identifier:

Clear-Content -Path 'D:\Script Lab\MyScript.ps1' -Stream 'Zone.Identifier'

Когда описанные подходы не подходят: примерные сценарии и ограничения

• Многопользовательная корпоративная машина. Если за машиной следят другие пользователи или отдел ИТ, не меняйте LocalMachine или HKCR без согласования с группой администрирования.
• Среды с централизованным управлением через Group Policy. Политики MachinePolicy или UserPolicy могут перезаписать локальные значения.
• Требования соответствия и аудита. В ряде отраслей (финансы, здравоохранение) любые послабления в политике запуска могут быть запрещены документами по безопасности.

Альтернативные подходы, если локальное изменение реестра неприемлемо:

• Использовать ярлыки, которые запускают PowerShell.exe с -ExecutionPolicy параметром (т.е. не менять HKCR, а создавать ярлык с нужными аргументами).
• Применять сценарии развёртывания через Configuration Management (SCCM, Intune) с централизованной политикой для доверенных пользователей.
• Использовать цифровую подпись скриптов (AllSigned) и собственный PKI для подписи подпадающих под доверие скриптов.

Методика: порядок действий для безопасной настройки (минимум ошибок)

1. Сделайте резервную копию реестра или экспортируйте ключи HKCR\Microsoft.PowerShellScript.1.
2. Создайте PSDrive HKCR, запустив PowerShell от имени администратора.
3. Настройте LocalMachine ExecutionPolicy в Restricted, если машина используется не только вами.
4. Настройте CurrentUser ExecutionPolicy в Unrestricted, если вы доверенный пользователь.
5. Обновите HKCR:\Microsoft.PowerShellScript.1\Shell\Command, чтобы задать -ExecutionPolicy RemoteSigned и -NoExit для удобства.
6. Добавьте под-ключ Run with PowerShell (Admin) с Command, использующим Start-Process -Verb RunAs.
7. Проверьте, что при двойном клике и через контекстное меню поведение соответствует ожиданиям.
8. Тестируйте на изолированной машине или виртуальной среде перед массовым развёртыванием.

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

• При двойном щелчке локальный скрипт запускается (или открывается в ISE, если выбрано).
• Скрипт, помеченный Zone.Identifier как «из Интернета», требует подписи или выдает ошибку при RemoteSigned.
• Контекстное меню содержит пункт Run with PowerShell (Admin), который запрашивает UAC и выполняет скрипт с правами администратора.

Чек-листы для ролей

Для администратора системы:

• Резервная копия реестра перед изменениями.
• Централизованная политика (GPO) синхронизирована с изменениями локально.
• Документированное одобрение от отдела безопасности.
• Скрипты для массового развёртывания протестированы в тестовой среде.

Для разработчика/автора скриптов:

• Подписывайте скрипты, если возможно.
• Добавляйте в конце скрипта Read-Host “Press Enter to exit” или используйте -NoExit при отладке.
• Проверяйте работу скрипта как в обычном, так и в повышенном режиме.

Для рядового пользователя:

• Не меняйте LocalMachine политики без согласования с администратором.
• При получении скрипта из Интернета обращайте внимание на Zone.Identifier и цифровые подписи.

Риск-матрица и меры смягчения

Риск: случайный запуск вредоносного скрипта посредством двойного клика.

• Вероятность: умеренная, если разрешён двойной запуск (RemoteSigned/Unrestricted).
• Влияние: высокое — утрата данных, компрометация учётных записей.
• Смягчение: оставить LocalMachine=Restricted, CurrentUser=Unrestricted; требовать цифровой подписи для внешних источников; включить антивирус/EDR.

Риск: пользователи обходят политику через Process-level Bypass.

• Вероятность: низкая, но возможна при неправильно настроенном реестре.
• Влияние: высокое.
• Смягчение: контролировать значение HKCR:\Microsoft.PowerShellScript.1\Shell\Command утвержденными средствами управления конфигурацией.

Быстрая шпаргалка: команды и шаблоны

Создать PSDrive для HKCR (Elevated):

New-PSDrive HKCR Registry HKEY_CLASSES_ROOT

Установить двойной щелчок на запуск скрипта:

Set-ItemProperty HKCR:\Microsoft.PowerShellScript.1\Shell '(Default)' 0

Установить Process-level RemoteSigned для запуска через Explorer:

Set-ItemProperty HKCR:\Microsoft.PowerShellScript.1\Shell\Command '(Default)' '"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-ExecutionPolicy" "RemoteSigned" "-file" "%1"'

Добавить пункт Run with PowerShell (Admin):

New-Item 'HKCR:\Microsoft.PowerShellScript.1\Shell\Run with PowerShell (Admin)'
New-Item 'HKCR:\Microsoft.PowerShellScript.1\Shell\Run with PowerShell (Admin)\Command'
Set-ItemProperty 'HKCR:\Microsoft.PowerShellScript.1\Shell\Run with PowerShell (Admin)\Command' '(Default)' '"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-Command" ""& {Start-Process PowerShell.exe -ArgumentList ''-ExecutionPolicy RemoteSigned -File \"%1\"'' -Verb RunAs}"'

Добавить -NoExit для удобства отладки:

Set-ItemProperty HKCR:\Microsoft.PowerShellScript.1\Shell\Command '(Default)' '"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-NoExit" "-ExecutionPolicy" "RemoteSigned" "-file" "%1"'

Decision flowchart: запуск скрипта (Mermaid)

flowchart TD
  A[Пользователь двойной клик на .ps1] --> B{Двойной клик запускает PowerShell или открывает в ISE/Notepad?}
  B -->|Открыть в ISE/Notepad| C[Редактирование\/Просмотр]
  B -->|Запустить в PowerShell| D{Запуск через обычный пункт или через Run as Admin?}
  D -->|Обычный| E{ExecutionPolicy в Process}
  D -->|Run as Admin| F{Запрос UAC}
  E -->|RemoteSigned| G{Файл помечен Zone.Identifier?}
  G -->|Да| H[Блокировать или запрос подписи]
  G -->|Нет| I[Выполнить скрипт]
  F -->|Подтверждён| J[Запустить как Admin с параметрами -NoExit и RemoteSigned]
  F -->|Отклонён| K[Отмена]

Короткая галерея пограничных случаев

• Старые системы с PowerShell 2.0 могут иметь другие значения в реестре по умолчанию.
• Если в строке запуска используется -Command с Set-ExecutionPolicy -Scope Process Bypass, пользователь получает полное обходное поведение только при запуске из Explorer.
• Некоторые антивирусы могут вмешиваться и блокировать изменение ключей HKCR; проверяйте логи антивируса при неожиданном поведении.

1‑строчный глоссарий

• ExecutionPolicy: механизм PowerShell для контроля запуска скриптов по подписи/источнику.
• HKCR: HKEY_CLASSES_ROOT — корневая ветвь реестра, отвечающая за ассоциации файлов.
• Zone.Identifier: альтернативный поток файла NTFS, помечающий файл как скачанный из сети.
• UAC: User Account Control — механизм повышения прав и запроса согласия пользователя.

Заключение и рекомендации

1. Всегда делайте резервную копию перед изменениями реестра.
2. Для личного компьютера: LocalMachine можно оставить Restricted, а CurrentUser настроить на Unrestricted или использовать ярлыки с нужными флагами.
3. Для корпоративных машин — согласовывайте изменения с отделом ИТ/безопасности.
4. Подписывайте скрипты и используйте RemoteSigned для сочетания удобства и защиты.

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

Полезные ссылки и источники для дальнейшего чтения

• Running PowerShell scripts from a batch file - Daniel Schroeder’s Programming Blog
• Checking for Administrator permissions in PowerShell - Hey, Scripting Guy! Blog

Экспертная цитата

“Баланс между безопасностью и удобством — это не всегда компромисс; это выбор стратегии, учитывающей роль пользователя и среду.” — эксперт по системной безопасности.

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