Remotesigned powershell что это
Настройка политики запуска скриптов (Execution Policy) PowerShell
По-умолчанию настройки Windows запрещают запуск скриптов PowerShell. Это необходимо для предотвращения запуска вредоносного кода на PowerShell. Настройки политик запуска PowerShell скриптов определяются в Execution Policy. В этой статье мы рассмотрим доступные политики запуска PS скриптов, как изменить Execution Policy и настроить политики использования PowerShell скриптов на компьютерах в домене.
Выполнение PowerShell скриптов запрещено для данной системы
При попытке выполнить PowerShell скрипт (файл с расширением PS1) на чистой Windows 10, появляется ошибка:
Текущее значение политики выполнения скриптов PowerShell на компьютере можно получить командой:
Доступны следующие значения PowerShell Execution Policy:
Как разрешить запуск скриптов PowerShell с помощью Execution Policy?
Чтобы изменить текущее значение политики запуска PowerShell скриптов, используется командлет Set-ExecutionPolicy.
Например, разрешим запуск локальных скриптов:
Подтвердите изменение политики запуска PS1 скриптов, нажав Y или A.
Чтобы запрос не появлялся, можно использовать параметр Force.
Set-ExecutionPolicy RemoteSigned –Force
Если вы установили значение политики PowerShell Execution Policy в Unrestricted, то при запуске удаленных скриптов из сетевых каталогов по UNC пути, скачанных из интернета файлов, все равно будет появляться предупреждение:
Также следует различать различные области действия политик выполнения скриптов PowerShell (scopes):
Область применения политики можно указать с помощью параметр Scope командлета Set-ExecutionPolicy. Например:
Проверим текущие настройки ExecutionPolicy для всех областей:
Значение политики выполнения, которые вы задаете с помощью командлета Set-ExecutionPolicy для областей CurrentUser и LocalMachine, хранятся в реестре. Например, выполните командлет:
Откройте ветку реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell и проверьте значение REG_SZ параметра ExecutionPolicy. Оно изменилось на Restricted (допустимые значения параметра Restricted, AllSigned, RemoteSigned, Bypass, Unrestricted и Undefined).
Аналогичные настройки для области CurrentUser находятся в разделе реестра пользователя HKEY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell.
Отметим, что чаще всего в корпоративной среде используется ExecutionPolicy со значением AllSigned на уровне LocalMachine. Это обеспечивает максимальный баланс между безопасностью и удобством. Для личного пользования на компьютере можно использовать RemoteSigned. Ну а Bypass политику лучше использовать только для запуска отдельных задач (например для запуска скриптов через GPO или заданий планировщика).
Настройка PowerShell Execution Policy с помощью групповых политик
Вы можете настроить политику выполнения PowerShel скриптов на серверах или компьютерах домена с помощью групповых политик.
После настройки политики выполнения через GPO вы не сможете изменить настройки политики выполнения скриптов вручную. При попытке изменить настройки Execution Policy на компьютере, на который применяется такая GPO, появится ошибка:
Способы обхода политики PowerShell Execution
Есть несколько трюков, которые могут помочь вам, когда нужно запустить на компьютере PowerShell скрипт, не изменяя настройки политики выполнения. Например, я хочу запустить простой PS1 скрипт, который поверяет, что запущен с правами администратора.
Можно с помощью Get-Content получить содержимое скрипта и перенаправить его в стандартныq поток ввода консоли PS.
Set-Execution Policy
Sets the PowerShell execution policies for Windows computers.
Syntax
Description
The Set-ExecutionPolicy cmdlet changes PowerShell execution policies for Windows computers. For more information, see about_Execution_Policies.
Beginning in PowerShell 6.0 for non-Windows computers, the default execution policy is Unrestricted and can’t be changed. The Set-ExecutionPolicy cmdlet is available, but PowerShell displays a console message that it’s not supported.
An execution policy is part of the PowerShell security strategy. Execution policies determine whether you can load configuration files, such as your PowerShell profile, or run scripts. And, whether scripts must be digitally signed before they are run.
The Set-ExecutionPolicy cmdlet’s default scope is LocalMachine, which affects everyone who uses the computer. To change the execution policy for LocalMachine, start PowerShell with Run as Administrator.
Examples
Example 1: Set an execution policy
This example shows how to set the execution policy for the local computer.
The Set-ExecutionPolicy cmdlet uses the ExecutionPolicy parameter to specify the RemoteSigned policy. The Scope parameter specifies the default scope value, LocalMachine. To view the execution policy settings, use the Get-ExecutionPolicy cmdlet with the List parameter.
Example 2: Set an execution policy that conflicts with a Group Policy
This command attempts to set the LocalMachine scope’s execution policy to Restricted. LocalMachine is more restrictive, but isn’t the effective policy because it conflicts with a Group Policy. The Restricted policy is written to the registry hive HKEY_LOCAL_MACHINE.
The Set-ExecutionPolicy cmdlet uses the ExecutionPolicy parameter to specify the Restricted policy. The Scope parameter specifies the default scope value, LocalMachine. The Get-ChildItem cmdlet uses the Path parameter with the HKLM provider to specify registry location.
Example 3: Apply the execution policy from a remote computer to a local computer
This command gets the execution policy object from a remote computer and sets the policy on the local computer. Get-ExecutionPolicy sends a Microsoft.PowerShell.ExecutionPolicy object down the pipeline. Set-ExecutionPolicy accepts pipeline input and doesn’t require the ExecutionPolicy parameter.
Example 4: Set the scope for an execution policy
This example shows how to set an execution policy for a specified scope, CurrentUser. The CurrentUser scope only affects the user who sets this scope.
Set-ExecutionPolicy uses the ExecutionPolicy parameter to specify the AllSigned policy. The Scope parameter specifies the CurrentUser. To view the execution policy settings, use the Get-ExecutionPolicy cmdlet with the List parameter.
The effective execution policy for the user becomes AllSigned.
Example 5: Remove the execution policy for the current user
This example shows how use the Undefined execution policy to remove an execution policy for a specified scope.
Set-ExecutionPolicy uses the ExecutionPolicy parameter to specify the Undefined policy. The Scope parameter specifies the CurrentUser. To view the execution policy settings, use the Get-ExecutionPolicy cmdlet with the List parameter.
Example 6: Set the execution policy for the current PowerShell session
The Set-ExecutionPolicy uses the ExecutionPolicy parameter to specify the AllSigned policy. The Scope parameter specifies the value Process. To view the execution policy settings, use the Get-ExecutionPolicy cmdlet with the List parameter.
Example 7: Unblock a script to run it without changing the execution policy
This example shows how the RemoteSigned execution policy prevents you from running unsigned scripts.
A best practice is to read the script’s code and verify it’s safe before using the Unblock-File cmdlet. The Unblock-File cmdlet unblocks scripts so they can run, but doesn’t change the execution policy.
The Set-ExecutionPolicy uses the ExecutionPolicy parameter to specify the RemoteSigned policy. The policy is set for the default scope, LocalMachine.
The Get-ExecutionPolicy cmdlet shows that RemoteSigned is the effective execution policy for the current PowerShell session.
The Start-ActivityTracker.ps1 script is executed from the current directory. The script is blocked by RemoteSigned because the script isn’t digitally signed.
For this example, the script’s code was reviewed and verified as safe to run. The Unblock-File cmdlet uses the Path parameter to unblock the script.
To verify that Unblock-File didn’t change the execution policy, Get-ExecutionPolicy displays the effective execution policy, RemoteSigned.
The script, Start-ActivityTracker.ps1 is executed from the current directory. The script begins to run because it was unblocked by the Unblock-File cmdlet.
Parameters
Prompts you for confirmation before running the cmdlet.
| Type: | SwitchParameter |
| Aliases: | cf |
| Position: | Named |
| Default value: | False |
| Accept pipeline input: | False |
| Accept wildcard characters: | False |
Specifies the execution policy. If there are no Group Policies and each scope’s execution policy is set to Undefined, then Restricted becomes the effective policy for all users.
The acceptable execution policy values are as follows:
Suppresses all the confirmation prompts. Use caution with this parameter to avoid unexpected results.
| Type: | SwitchParameter |
| Position: | Named |
| Default value: | False |
| Accept pipeline input: | False |
| Accept wildcard characters: | False |
Specifies the scope that is affected by an execution policy. The default scope is LocalMachine.
The effective execution policy is determined by the order of precedence as follows:
Execution policies for the CurrentUser scope are written to the registry hive HKEY_LOCAL_USER.
Execution policies for the LocalMachine scope are written to the registry hive HKEY_LOCAL_MACHINE.
| Type: | ExecutionPolicyScope |
| Accepted values: | CurrentUser, LocalMachine, MachinePolicy, Process, UserPolicy |
| Position: | 1 |
| Default value: | LocalMachine |
| Accept pipeline input: | True |
| Accept wildcard characters: | False |
Shows what would happen if the cmdlet runs. The cmdlet is not run.
| Type: | SwitchParameter |
| Aliases: | wi |
| Position: | Named |
| Default value: | False |
| Accept pipeline input: | False |
| Accept wildcard characters: | False |
Inputs
Microsoft.PowerShell.ExecutionPolicy, System.String
Outputs
None
Set-ExecutionPolicy doesn’t return any output.
Notes
Set-ExecutionPolicy doesn’t change the MachinePolicy and UserPolicy scopes because they are set by Group Policies.
Set-ExecutionPolicy doesn’t override a Group Policy, even if the user preference is more restrictive than the policy.
If the Group Policy Turn on Script Execution is enabled for the computer or user, the user preference is saved, but it is not effective. PowerShell displays a message that explains the conflict.
Get-Execution Policy
Gets the execution policies for the current session.
Syntax
Description
The effective execution policy is determined by execution policies that are set by Set-ExecutionPolicy and Group Policy settings.
Examples
Example 1: Get all execution policies
This command displays the execution policies for each scope in the order of precedence.
The Get-ExecutionPolicy cmdlet uses the List parameter to display each scope’s execution policy.
Example 2: Set an execution policy
This example shows how to set an execution policy for the local computer.
The Set-ExecutionPolicy cmdlet uses the ExecutionPolicy parameter to specify the RemoteSigned policy. The Scope parameter specifies the default scope value, LocalMachine. To view the execution policy settings, use the Get-ExecutionPolicy cmdlet with the List parameter.
Example 3: Get the effective execution policy
This example shows how to display the effective execution policy for a PowerShell session.
The Get-ExecutionPolicy cmdlet uses the List parameter to display each scope’s execution policy. The Get-ExecutionPolicy cmdlet is run without a parameter to display the effective execution policy, AllSigned.
Example 4: Unblock a script to run it without changing the execution policy
This example shows how the RemoteSigned execution policy prevents you from running unsigned scripts.
A best practice is to read the script’s code and verify it’s safe before using the Unblock-File cmdlet. The Unblock-File cmdlet unblocks scripts so they can run, but doesn’t change the execution policy.
The Set-ExecutionPolicy uses the ExecutionPolicy parameter to specify the RemoteSigned policy. The policy is set for the default scope, LocalMachine.
The Get-ExecutionPolicy cmdlet shows that RemoteSigned is the effective execution policy for the current PowerShell session.
The Start-ActivityTracker.ps1 script is executed from the current directory. The script is blocked by RemoteSigned because the script isn’t digitally signed.
For this example, the script’s code was reviewed and verified as safe to run. The Unblock-File cmdlet uses the Path parameter to unblock the script.
To verify that Unblock-File didn’t change the execution policy, Get-ExecutionPolicy displays the effective execution policy, RemoteSigned.
The script, Start-ActivityTracker.ps1 is executed from the current directory. The script begins to run because it was unblocked by the Unblock-File cmdlet.
Parameters
Gets all execution policy values for the session listed in precedence order. By default, Get-ExecutionPolicy gets only the effective execution policy.
| Type: | SwitchParameter |
| Position: | Named |
| Default value: | None |
| Accept pipeline input: | False |
| Accept wildcard characters: | False |
Specifies the scope that is affected by an execution policy.
The effective execution policy is determined by the order of precedence as follows:
Inputs
None
Get-ExecutionPolicy doesn’t accept input from the pipeline.
Outputs
The cmdlet always returns Unrestricted on Linux and macOS platforms.
Notes
An execution policy is part of the PowerShell security strategy. Execution policies determine whether you can load configuration files, such as your PowerShell profile, or run scripts. And, whether scripts must be digitally signed before they are run.
about_Signing
Краткое описание
Описывает, как подписывать сценарии, чтобы они соответствовали политикам выполнения PowerShell.
Подробное описание
Политика ограниченного выполнения не позволяет запускать скрипты. Политики выполнения AllSigned и RemoteSigned запрещают PowerShell выполнять сценарии, не имеющие цифровой подписи.
В этом разделе объясняется, как выполнить выбранные сценарии, которые не подписаны, даже если политика выполнения RemoteSigned и как подписывать сценарии для собственного использования.
Дополнительные сведения о политиках выполнения PowerShell см. в разделе about_Execution_Policies.
Разрешение выполнения подписанных сценариев
При первом запуске PowerShell на компьютере, скорее всего, действует политика ограниченного выполнения (по умолчанию).
Политика с ограниченным доступом не позволяет запускать скрипты.
Чтобы найти действующую политику выполнения на компьютере, введите:
Чтобы запустить неподписанные скрипты, написанные на локальном компьютере и подписанные скрипты от других пользователей, запустите PowerShell с параметром Запуск от имени администратора, а затем используйте следующую команду, чтобы изменить политику выполнения на компьютере на RemoteSigned:
Дополнительные сведения см. в разделе справки по Set-ExecutionPolicy командлету.
Выполнение неподписанных скриптов с помощью политики выполнения RemoteSigned
Если политика выполнения PowerShell — RemoteSigned, PowerShell не будет запускать неподписанные сценарии, которые будут скачаны из Интернета, в том числе неподписанные сценарии, получаемые через электронную почту и программы обмена мгновенными сообщениями.
При попытке запустить скачанный скрипт PowerShell выводит следующее сообщение об ошибке:
Перед выполнением скрипта проверьте код, чтобы убедиться, что он является доверенным. Сценарии имеют тот же результат, что и любая исполняемая программа.
Чтобы выполнить неподписанный скрипт, используйте командлет Unblock-File или выполните следующую процедуру.
Если сценарий, скачанный из Интернета, имеет цифровую подпись, но вы еще не выбрали доверие к издателю, PowerShell выводит следующее сообщение:
Если вы доверяете издателю, выберите «запустить один раз» или «всегда запускать». Если вы не доверяете издателю, выберите параметр «никогда не запускать» или «не запускать». Если выбрать параметр «никогда не запускать» или «всегда запускать», PowerShell не будет выводить запрос для этого издателя снова.
Методы подписания скриптов
Вы можете подписывать скрипты, которые вы пишете, и скрипты, получаемые из других источников. Перед тем как подписать любой сценарий, проверьте каждую команду, чтобы убедиться в том, что он является надежным для выполнения.
Рекомендации по подписывания кода см. в статье рекомендации по подписываниякода.
Дополнительные сведения о том, как подписать файл скрипта, см. в разделе Set-AuthenticodeSignature.
New-SelfSignedCertificate Командлет, представленный в модуле PKI в PowerShell 3,0, создает самозаверяющий сертификат, подходящий для тестирования. Дополнительные сведения см. в разделе справки по командлету New-SelfSignedCertificate.
Чтобы добавить цифровую подпись в скрипт, необходимо подписать его с помощью сертификата подписи кода. Для подписи файла скрипта подходят два типа сертификатов:
Сертификаты, созданные центром сертификации. для платной платы общедоступный центр сертификации проверяет ваше удостоверение и предоставляет сертификат подписи кода. при приобретении сертификата от известного центра сертификации можно предоставить общий доступ к сценарию пользователям на других компьютерах, на которых выполняется Windows, так как эти компьютеры доверяют центру сертификации.
Создаваемые сертификаты: можно создать самозаверяющий сертификат, для которого компьютер является центром сертификации, который создает сертификат. Этот сертификат предоставляется бесплатно и позволяет писать, подписывать и выполнять сценарии на компьютере. Однако сценарий, подписанный самозаверяющим сертификатом, не будет выполняться на других компьютерах.
Как правило, самозаверяющий сертификат используется только для подписывания сценариев, написанных для собственного использования, и для подписывания сценариев, получаемых из других источников, которые были проверены как надежные. Он не подходит для сценариев, которые будут совместно использоваться даже в рамках предприятия.
При создании самозаверяющего сертификата обязательно включите усиленную защиту закрытого ключа в сертификате. Это не позволит вредоносным программам подписывать сценарии от вашего имени. Инструкции включены в конце этого раздела.
Создание самозаверяющего сертификата.
Чтобы создать самозаверяющий сертификат, используйте командлет New-SelfSignedCertificate в модуле PKI. этот модуль появился в PowerShell 3,0 и входит в Windows 8 и Windows Server 2012. Дополнительные сведения см. в разделе справки по New-SelfSignedCertificate командлету.
Использование Makecert.exe
Дополнительные сведения о синтаксисе и описаниях параметров MakeCert.exe средства см. в разделе средство создания сертификатов (MakeCert.exe).
Чтобы использовать MakeCert.exe средство для создания сертификата, выполните следующие команды в окне командной строки пакета SDK.
Первая команда создает локальный центр сертификации для компьютера. Вторая команда создает личный сертификат из центра сертификации. Вы можете скопировать или ввести команды в том виде, в каком они отображаются. Подстановки не требуются, хотя имя сертификата можно изменить.
MakeCert.exe Средство предложит ввести пароль закрытого ключа. Пароль гарантирует, что никто не сможет использовать сертификат или получить к нему доступ без вашего согласия. Создайте и введите пароль, который вы можете запомнить. Этот пароль будет использоваться позже для получения сертификата.
Чтобы убедиться, что сертификат создан правильно, выполните следующую команду, чтобы получить сертификат в хранилище сертификатов на компьютере. Файл сертификата не будет найден в каталоге файловой системы.
В командной строке PowerShell введите следующее:
Эта команда использует поставщик сертификата PowerShell для просмотра сведений о сертификате.
Подписать сценарий
Следующий пример скрипта Add-Signature.ps1 подписывает скрипт. Однако при использовании политики выполнения AllSigned необходимо подписать Add-Signature.ps1 сценарий перед запуском.
Скрипт должен быть сохранен с использованием кодировки ASCII или UTF8NoBOM. Вы можете подписать файл сценария, который использует другую кодировку. Но сценарий не запускается, или модуль, содержащий скрипт, не удается импортировать.
Чтобы подписать Add-Signature.ps1 файл скрипта, введите в командной строке PowerShell следующие команды:
После подписания скрипта его можно запустить на локальном компьютере. Однако сценарий не будет выполняться на компьютерах, на которых политика выполнения PowerShell требует наличия цифровой подписи от доверенного центра сертификации. При попытке PowerShell отобразится следующее сообщение об ошибке:
Если PowerShell отображает это сообщение при выполнении скрипта, который не был написан, обработайте файл так, как если бы вы ни использовали любой неподписанный сценарий. Проверьте код, чтобы определить, можно ли доверять сценарию.
Включение усиленной защиты закрытого ключа для сертификата
При наличии частного сертификата на компьютере вредоносные программы могут подписывать сценарии от вашего имени, что позволяет PowerShell выполнять их.
Чтобы экспортировать сертификат, выполните следующие действия.
Чтобы повторно импортировать сертификат, выполните следующие действия.
Запрет истечения срока действия подписи
Цифровая подпись в скрипте действительна до истечения срока действия сертификата подписи или до тех пор, пока сервер отметок времени не сможет проверить, подписан ли сценарий, пока сертификат для подписи был действителен.
Так как большинство сертификатов подписи действительны только в течение одного года, использование сервера отметок времени гарантирует, что пользователи смогут использовать ваш сценарий в течение многих лет.