Как да поправите грешката „Execution Policy Restricted“ в Windows PowerShell

Най-безопасният начин да поправите грешката „Execution Policy Restricted“ в Windows PowerShell не е да копирате най-широкообхватната команда, която можете да намерите. Първо идентифицирайте коя политика за изпълнение е действително активна, след което изберете най-тясната промяна, която отговаря на това, което се опитвате да изпълните.

Текущата документация на Microsoft също така подчертава важността на контекста на версията. Документацията за Windows PowerShell 5.1 посочва Restricted като политиката за изпълнение по подразбиране за клиентските компютри с Windows. Текущата документация за PowerShell 7.6 дефинира Default като RemoteSigned във Windows. Ако обаче всички обхвати са Undefined, Microsoft все още документира ефективния резервен вариант за клиентите с Windows като Restricted. Практическият урок е прост: не заключвайте политиката си въз основа на версията на Windows или от урок. Изпълнете командите за политика на машината, която има грешката.

Това ръководство сравнява основните поправки по обхват, постоянство, административно въздействие и модел на доверие. Целта е да накарате легитимен скрипт да работи, без да отслабвате повече системата, отколкото е необходимо.

Какво всъщност означава грешката Restricted

При политиката Restricted PowerShell позволява отделни команди, но не позволява изпълнението на скриптови файлове. Това включва PowerShell скриптове и свързани конфигурационни или скриптови файлове на модули. Microsoft описва политиката за изпълнение като функция за безопасност, която контролира условията, при които скриптовете и конфигурационните файлове се зареждат. Тя не е граница на сигурността; Microsoft изрично отбелязва, че потребителят все още може да въвежда команди интерактивно. Прочетете текущата документация about_Execution_Policies за PowerShell 7.6 и документацията за политиката за изпълнение на Windows PowerShell 5.1.

Честата грешка гласи, че файлът .ps1 не може да бъде зареден, защото изпълнението на скриптове е деактивирано; запишете точното съобщение, преди да промените политиката.

Това разграничение е важно. Политиката за изпълнение може да помогне за предотвратяване на случайно изпълнение на скриптове, но задаването на RemoteSigned или Bypass не прави скрипта надежден. Първо прегледайте скрипта и неговия източник.

Стъпка 1: Идентифицирайте ефективната политика и всеки обхват

Изпълнете тези две команди:

Get-ExecutionPolicy

Get-ExecutionPolicy -List

Първата връща ефективната политика за текущата сесия. Втората изброява политиките, приложени на ниво MachinePolicy, UserPolicy, Process, CurrentUser и LocalMachine. Microsoft препоръчва Get-ExecutionPolicy -List конкретно за виждане на политиките, които могат да повлияят на сесията. Вижте Get-ExecutionPolicy.

Проверете всички обхвати, вместо да приемате, че стойността на LocalMachine е тази, която контролира сесията.

Ако MachinePolicy или UserPolicy са дефинирани, спрете, преди да се опитате да наложите локално заобикаляне. Тези стойности идват от Group Policy и могат да отменят настройките за политика за изпълнение, направени с PowerShell. На управляван работен компютър правилната следваща стъпка обикновено е да следвате процеса на организацията или да се свържете с IT отдела.

Изберете поправката според нуждите, а не по най-късата команда

Стъпка 2: Използвайте администраторски права само за промяна в мащаба на машината

Вие не трябва да отваряте PowerShell с повишени привилегии, само за да промените обхвата CurrentUser или Process. Microsoft посочва, че повишаването на привилегиите е необходимо при промяна на политиката за локалния компютър, т.е. LocalMachine. Това е полезен компромис: ако само вашият потребителски акаунт се нуждае от локално скриптиране, промяната на политиката за всеки потребител добавя обхват, без да добавя полза.

„Run as administrator“ е подходящо за умишлена промяна на LocalMachine, но е ненужно за обхватите Process или CurrentUser.

Препоръка според нуждите: използвайте CurrentUser за акаунт на разработчик, който редовно изпълнява локално написани скриптове. Запазете LocalMachine за администратор, който умишлено иска същата настройка да засегне всички потребители.

Стъпка 3: За редовно локално скриптиране помислете за CurrentUser RemoteSigned

За много лични машини за разработка практичният постоянен избор е:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

RemoteSigned позволява локалните скриптове да се изпълняват без изискване за подпис, докато скриптовете, маркирани като изтеглени от интернет, изискват надежден цифров подпис, освен ако изрично не разблокирате файла. Това запазва полезно разграничение между кода, който сте създали локално, и кода, получен от друг източник.

Тази илюстрация показва команда RemoteSigned за цялата машина, защото обхватът е пропуснат; LocalMachine е обхватът по подразбиране. Предпочитайте явен обхват, за да е въздействието умишлено.

Честа грешка е изпълнението на Set-ExecutionPolicy RemoteSigned без -Scope. Microsoft документира LocalMachine като обхват по подразбиране при задаване на политика за изпълнение. Ето защо е по-добре да сте явни:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Промяната влиза в сила незабавно; PowerShell не се нуждае от рестартиране за промени в CurrentUser или LocalMachine.

Стъпка 4: За временна сесия предпочитайте политика с обхват Process

Ако отстранявате неизправности или изпълнявате надежден локален скрипт веднъж, избягвайте постоянна промяна на потребителя или машината. По-тясна опция е:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

Обхватът Process се прилага само за текущата сесия на PowerShell. Microsoft посочва, че той се съхранява в променливата на средата $Env:PSExecutionPolicyPreference и се изтрива, когато процесът се затвори.

Ако по-голямо приложение, инсталатор или контролирана автоматизационна среда вече имат свой собствен модел за сигурност, PowerShell също така предоставя Bypass:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Bypass с обхват Process изчезва, когато процесът на PowerShell се затвори, но той също така премахва предупрежденията и блокирането на политиката за изпълнение за тази сесия.

Компромис: Обхватът Process минимизира постоянството, но Bypass е по-широк от RemoteSigned в рамките на тази сесия. Microsoft описва Bypass като нещо, което не блокира нищо и не показва предупреждения или подканвания, и посочва, че е предназначен за сценарии, в които друго приложение осигурява модела за сигурност. За нормална интерактивна сесия за отстраняване на неизправности използвайте първо Process RemoteSigned, освен ако нямате конкретна причина за Bypass.

За отделен еднократен процес на Windows PowerShell можете също да стартирате:

powershell.exe -ExecutionPolicy RemoteSigned -File .\script.ps1

За PowerShell 7 изпълнимият файл е pwsh.exe. Настройката на политиката за изпълнение от командния ред все още не отменя политика за изпълнение, наложена от Group Policy.

Стъпка 5: Ако RemoteSigned блокира изтеглен скрипт, разблокирайте само този файл

RemoteSigned третира по различен начин файловете, маркирани като произхождащи от интернет. Microsoft документира командлета Unblock-File като премахващо тази маркировка за интернет зона, позволявайки на прегледан неподписан скрипт да се изпълнява при RemoteSigned.

Първо инспектирайте скрипта. Ако се доверявате на източника и сте прегледали съдържанието, изпълнете:

Unblock-File -Path .\script.ps1

Можете също да използвате отметката Unblock в диалоговия прозорец Properties на файла. Microsoft посочва, че Unblock-File извършва същата основна операция. Вижте Unblock-File.

Разблокирането на един прегледан изтеглен скрипт е по-тясно от отслабването на политиката за всеки скрипт на машината.

Можете да проверите дали файлът има алтернативен поток от данни Zone.Identifier с:

Get-Item .\script.ps1 -Stream Zone.Identifier -ErrorAction SilentlyContinue

Microsoft отбелязва, че методите за изтегляне не маркират всички файлове по един и същи начин, така че липсата на този поток не е доказателство, че скриптът е безопасен.

Стъпка 6: Използвайте AllSigned, когато организацията има процес за подписване

AllSigned изисква всички скриптове и конфигурационни файлове да бъдат подписани от надежден издател, включително скриптове, създадени локално. Това дава на организацията последователен процес на доверие към издателя, но също така създава оперативни разходи: скриптовете се нуждаят от Authenticode подписи и потребителите трябва да се доверяват на съответните издатели.

Документацията about_Signing на Microsoft обяснява как PowerShell проверява подписите на скриптове и как работят подканванията за надеждни издатели.

Препоръка според нуждите: AllSigned има смисъл, когато вашата организация вече има сертификати за подписване на код, контроли на публикуването и процес за актуализиране на подписани скриптове. За самостоятелен разработчик, пишещ локални помощни скриптове, RemoteSigned обикновено включва по-малко триене, като същевременно запазва проверката за произход от интернет.

Стъпка 7: Не се борете с Group Policy на управляван PC

PowerShell излага два обхвата на политиката, които идват от Group Policy: MachinePolicy и UserPolicy. Документацията на Microsoft за Group Policy посочва, че настройката Turn on Script Execution може да наложи поведение Restricted, RemoteSigned или AllSigned за управлявани потребители и компютри. Настройката е под:

Administrative Templates\Windows Components\Windows PowerShell

Вижте about_Group_Policy_Settings.

Ако Get-ExecutionPolicy -List показва дефинирана MachinePolicy или UserPolicy, локалната команда Set-ExecutionPolicy може да не ви даде очакваното ефективно поведение. Практическото решение е да поискате подходящата политика от администратора, да използвате подписан скрипт, ако се изисква, или да използвате одобрен метод за внедряване.

Стъпка 8: Възстановете настройката, която всъщност сте променили, след което проверете

Преди да промените постоянен обхват, запишете съществуващата му стойност:

Get-ExecutionPolicy -Scope CurrentUser

Get-ExecutionPolicy -Scope LocalMachine

Ако по-късно трябва да премахнете стойност на политика, която сте задали, Microsoft документира задаването на този обхват на Undefined:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Undefined

Не изпълнявайте сляпо Set-ExecutionPolicy Restricted само защото екранна снимка го показва. Без обхват командата насочва към LocalMachine по подразбиране, а „Restricted“ може да не е била предишната стойност на този обхват.

Екранната снимка илюстрира промяна на Restricted, но истинско връщане назад трябва да възстанови обхвата и стойността, които сте записали, вместо да гадаете предишната конфигурация.

Накрая проверете както ефективната политика, така и скрипта:

Get-ExecutionPolicy

Get-ExecutionPolicy -List

.\script.ps1

Успешното изпълнение на скрипта потвърждава, че непосредственият симптом е разрешен; проверете отново списъка с политики, за да потвърдите, че не сте оставили по-широк обхват променен непреднамерено.

Коя поправка трябва да изберете?

Чести грешки, които създават по-голям проблем от оригиналната грешка

• Задаване на Unrestricted или Bypass постоянно, само за да работи един скрипт. Това разширява това, което може да се изпълни, когато по-тясна промяна на Process, CurrentUser или специфична за файла може да реши проблема.
• Изпълнение на всяка команда като Administrator. Промените на CurrentUser и Process не се нуждаят от промяна на политиката на LocalMachine.
• Игнориране на Group Policy. Ако устройството е управлявано, политиката може да е умишлена и локалната промяна на друг обхват не замества организационния контрол.
• Разблокиране на скрипт без да го прочетете. Unblock-File премахва блокирането за произход от интернет; то не валидира кода.
• Приемане, че подписаният скрипт е автоматично безвреден. Microsoft отбелязва, че подписаният код все още може да бъде злонамерен; подписите установяват информация за издателя и целостта, а не гаранция за безопасно поведение.
• Забравяне кой обхват сте променили. Команда без -Scope може да засегне LocalMachine, докато промяна на Process изчезва при изход.

Долната линия

За повечето лични скриптове във Windows, CurrentUser RemoteSigned е разумен постоянен избор, когато редовно изпълнявате локално създадени скриптове, докато Unblock-File е по-тясният избор за един прегледан скрипт, изтеглен от интернет. За временна сесия за отстраняване на неизправности, Process RemoteSigned минимизира постоянството. Bypass има легитимна роля в контролираната автоматизация, но компромисът е, че блокирането и предупрежденията на политиката за изпълнение се премахват за този процес. На управлявани компютри Group Policy трябва да се третира като авторитет, а не като пречка, която да се заобикаля.

Най-добрата поправка следователно не е една политика за всички. Това е най-малкият обхват и най-малко разрешаващото поведение, което все още поддържа надеждния скрипт, който трябва да изпълните.