Jak opravit chybu Execution Policy Restricted ve Windows PowerShell

Nejbezpečnější způsob, jak opravit chybu „Execution Policy Restricted“ ve Windows PowerShell, není zkopírovat nejširší příkaz, který najdete. Nejprve zjistěte, která politika výkonu je skutečně účinná, a poté zvolte nejúžejší změnu, která odpovídá tomu, co se snažíte spustit.

Aktuální dokumentace společnosti Microsoft také zdůrazňuje důležitost kontextu verze. Dokumentace pro Windows PowerShell 5.1 uvádí Restricted jako výchozí politiku výkonu pro klientské počítače Windows. Současná dokumentace pro PowerShell 7.6 definuje Default jako RemoteSigned na systému Windows. Pokud jsou však všechny rozsahy nastaveny na Undefined, Microsoft stále dokumentuje účinnou záložní hodnotu na klientských systémech Windows jako Restricted. Praktické ponaučení je jednoduché: nevyvozujte si svou politiku z verze Windows ani z tutoriálu. Spusťte příkazy pro politiku na stroji, kde se chyba vyskytuje.

Tato příručka porovnává hlavní opravy podle rozsahu, trvalosti, dopadu na administrátorská práva a modelu důvěry. Cílem je spustit legitimní skript bez zbytečného oslabování systému.

Co chyba Restricted ve skutečnosti znamená

Při politice Restricted PowerShell povoluje jednotlivé příkazy, ale neumožňuje spouštění skriptových souborů. To zahrnuje skripty PowerShellu a související konfigurační nebo skriptové soubory modulů. Microsoft popisuje politiku výkonu jako bezpečnostní funkci, která řídí podmínky, za kterých se načítají skripty a konfigurační soubory. Nejedná se o bezpečnostní hranici; Microsoft výslovně uvádí, že uživatel může stále zadávat příkazy interaktivně. Přečtěte si aktuální dokumentaci about_Execution_Policies pro PowerShell 7.6 a dokumentaci politiky výkonu pro Windows PowerShell 5.1.

Běžná chyba uvádí, že soubor .ps1 nelze načíst, protože spouštění skriptů je zakázáno; před změnou politiky si přesně zapište hlášení.

Tento rozdíl je důležitý. Politika výkonu může pomoci zabránit náhodnému spuštění skriptu, ale nastavení RemoteSigned nebo Bypass ze skriptu nedělá důvěryhodný. Nejprve zkontrolujte skript a jeho zdroj.

Krok 1: Identifikujte účinnou politiku a všechny rozsahy

Spusťte tyto dva příkazy:

Get-ExecutionPolicy

Get-ExecutionPolicy -List

První vrátí účinnou politiku pro aktuální relaci. Druhý vypíše politiky aplikované na MachinePolicy, UserPolicy, Process, CurrentUser a LocalMachine. Microsoft doporučuje Get-ExecutionPolicy -List specificky pro zobrazení politik, které mohou ovlivnit relaci. Viz Get-ExecutionPolicy.

Zkontrolujte všechny rozsahy místo toho, abyste předpokládali, že hodnota LocalMachine je ta, která řídí relaci.

Pokud je definován MachinePolicy nebo UserPolicy, zastavte se, než se pokusíte vynutit lokální obcházení. Tyto hodnoty pocházejí ze Skupinové politiky a mohou přepsat nastavení politiky výkonu provedená pomocí PowerShellu. Na spravovaném pracovním počítači je obvykle správným dalším krokem dodržet proces organizace nebo kontaktovat IT oddělení.

Vyberte opravu podle potřeby, ne podle nejkratšího příkazu

Krok 2: Použijte administrátorská práva pouze pro změnu na úrovni celého počítače

Nemusíte otevírat PowerShell se zvýšenými oprávněními pouze pro změnu rozsahu CurrentUser nebo Process. Microsoft uvádí, že zvýšení oprávnění je vyžadováno při změně politiky pro lokální počítač, což znamená LocalMachine. To je užitečný kompromis: pokud pouze váš uživatelský účet potřebuje lokální skriptování, změna politiky pro všechny uživatele přidává rozsah bez přidání přínosu.

Spustit jako správce je vhodné pro záměrnou změnu LocalMachine, ale je zbytečné pro rozsah Process nebo CurrentUser.

Doporučení podle potřeby: použijte CurrentUser pro vývojářský účet, který pravidelně spouští lokálně vytvořené skripty. Vyhraďte LocalMachine pro administrátora, který záměrně chce, aby stejné nastavení ovlivnilo všechny uživatele.

Krok 3: Pro pravidelné lokální skriptování zvažte CurrentUser RemoteSigned

Pro mnoho osobních vývojových strojů je praktickou trvalou volbou:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

RemoteSigned umožňuje spouštět lokální skripty bez nutnosti podpisu, zatímco skripty označené jako stažené z internetu vyžadují důvěryhodný digitální podpis, pokud soubor výslovně neodblockujete. To zachovává užitečné rozlišení mezi kódem, který jste vytvořili lokálně, a kódem získaným z jiného zdroje.

Tento obrázek ukazuje příkaz RemoteSigned pro celý počítač, protože rozsah je vynechán; LocalMachine je výchozí rozsah. Preferujte explicitní rozsah, aby byl dopad záměrný.

Běžnou chybou je spuštění Set-ExecutionPolicy RemoteSigned bez -Scope. Microsoft dokumentuje LocalMachine jako výchozí rozsah při nastavování politiky výkonu. Proto je lepší být explicitní:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Změna je účinná okamžitě; PowerShell nemusí být restartován pro změny CurrentUser nebo LocalMachine.

Krok 4: Pro dočasnou relaci preferujte politiku v rozsahu Process

Pokud ladíte nebo spouštíte důvěryhodný lokální skript jednou, vyhněte se trvalé změně uživatele nebo počítače. Užší možností je:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

Rozsah Process platí pouze pro aktuální relaci PowerShellu. Microsoft uvádí, že je uložen v proměnné prostředí $Env:PSExecutionPolicyPreference a je smazán při uzavření procesu.

Pokud větší aplikace, instalátor nebo řízené prostředí automatizace již má svůj vlastní bezpečnostní model, PowerShell také poskytuje Bypass:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Bypass v rozsahu Process zmizí, když se proces PowerShellu uzavře, ale také odstraní varování a blokování politiky výkonu pro tuto relaci.

Kompromis: Rozsah Process minimalizuje trvalost, ale Bypass je v rámci této relace širší než RemoteSigned. Microsoft popisuje Bypass jako nic neblokující a nezobrazující žádná varování nebo výzvy a uvádí, že je určen pro scénáře, kde jiná aplikace poskytuje bezpečnostní model. Pro běžnou interaktivní ladící relaci použijte nejprve Process RemoteSigned, pokud nemáte specifický důvod pro Bypass.

Pro samostatný jednorázový proces Windows PowerShell můžete také spustit:

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

Pro PowerShell 7 je spustitelný soubor pwsh.exe. Nastavení politiky výkonu z příkazového řádku stále nepřepíše politiku výkonu vynucenou Skupinovou politikou.

Krok 5: Pokud RemoteSigned blokuje stažený skript, odblokujte pouze tento soubor

RemoteSigned zachází se soubory označenými jako pocházející z internetu odlišně. Microsoft dokumentuje cmdlet Unblock-File jako odstraňující toto označení internetové zóny, což umožňuje spuštění zkontrolovaného nepodepsaného skriptu pod RemoteSigned.

Nejprve zkontrolujte skript. Pokud důvěřujete zdroji a zkontrolovali jste obsah, spusťte:

Unblock-File -Path .\script.ps1

Můžete také použít zaškrtávací políčko Unblock v dialogu Vlastnosti souboru. Microsoft uvádí, že Unblock-File provádí stejnou základní operaci. Viz Unblock-File.

Odblokování jednoho zkontrolovaného staženého skriptu je užší než oslabení politiky pro každý skript na stroji.

Můžete zkontrolovat, zda má soubor alternativní datový tok Zone.Identifier pomocí:

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

Microsoft poznamenává, že metody stahování neoznačují všechny soubory stejným způsobem, takže absence tohoto toku není důkazem, že je skript bezpečný.

Krok 6: Použijte AllSigned, pokud má organizace proces podepisování

AllSigned vyžaduje, aby všechny skripty a konfigurační soubory byly podepsány důvěryhodným vydavatelem, včetně skriptů vytvořených lokálně. To poskytuje organizaci konzistentní workflow důvěry ve vydavatele, ale také vytváří provozní režii: skripty potřebují podpisy Authenticode a uživatelé musí důvěřovat příslušným vydavatelům.

Dokumentace Microsoftu about_Signing vysvětluje, jak PowerShell kontroluje podpisy skriptů a jak fungují výzvy pro důvěryhodné vydavatele.

Doporučení podle potřeby: AllSigned dává smysl, když vaše organizace již má certifikáty pro podepisování kódu, kontrolu publikování a proces pro aktualizaci podepsaných skriptů. Pro samostatného vývojáře píšícego lokální utility skripty obvykle RemoteSigned zahrnuje méně tření, zatímco stále zachovává kontrolu původu z internetu.

Krok 7: Nebojujte se Skupinovou politikou na spravovaném PC

PowerShell vystavuje dva rozsahy politik, které pocházejí ze Skupinové politiky: MachinePolicy a UserPolicy. Dokumentace Skupinové politiky Microsoftu uvádí, že nastavení Turn on Script Execution může vynutit chování Restricted, RemoteSigned nebo AllSigned pro spravované uživatele a počítače. Nastavení je pod:

Administrative Templates\Windows Components\Windows PowerShell

Viz about_Group_Policy_Settings.

Pokud Get-ExecutionPolicy -List ukazuje definovaný MachinePolicy nebo UserPolicy, lokální příkaz Set-ExecutionPolicy vám nemusí dát očekávané účinné chování. Praktickým řešením je požádat administrátora o příslušnou politiku, použít podepsaný skript, pokud je vyžadován, nebo použít schválenou metodu nasazení.

Krok 8: Obnovte nastavení, které jste skutečně změnili, a poté ověřte

Před změnou trvalého rozsahu si zaznamenejte jeho stávající hodnotu:

Get-ExecutionPolicy -Scope CurrentUser

Get-ExecutionPolicy -Scope LocalMachine

Pokud budete později potřebovat odstranit hodnotu politiky, kterou jste nastavili, Microsoft dokumentuje nastavení tohoto rozsahu na Undefined:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Undefined

Nebezte slepě Set-ExecutionPolicy Restricted jen proto, že to ukazuje snímek obrazovky. Bez rozsahu příkaz cílí na LocalMachine ve výchozím nastavení a „Restricted“ nemusela být předchozí hodnota tohoto rozsahu.

Snímek obrazovky ilustruje změnu na Restricted, ale skutečné vrácení zpět by mělo obnovit rozsah a hodnotu, kterou jste si zaznamenali, místo hádání předchozí konfigurace.

Nakonec ověřte účinnou politiku i skript:

Get-ExecutionPolicy

Get-ExecutionPolicy -List

.\script.ps1

Úspěšné spuštění skriptu potvrzuje, že bezprostřední příznak je vyřešen; znovu zkontrolujte seznam politik, abyste se ujistili, že jste nezměnili širší rozsah neúmyslně.

Kterou opravu byste měli zvolit?

Běžné chyby, které vytvoří větší problém než původní chyba

• Nastavení Unrestricted nebo Bypass trvale jen proto, aby se spustil jeden skript. To rozšiřuje to, co může být spuštěno, když užší změna v rozsahu Process, CurrentUser nebo specifická pro soubor může problém vyřešit.
• Spouštění každého příkazu jako Administrátor. Změny CurrentUser a Process nevyžadují změnu politiky LocalMachine.
• Ignorování Skupinové politiky. Pokud je zařízení spravováno, politika může být záměrná a lokální změna jiného rozsahu nenahrazuje organizační kontrolu.
• Odblokování skriptu bez jeho přečtení. Unblock-File odstraní blokování původu z internetu; nevaliduje kód.
• Předpoklad, že podepsaný skript je automaticky neškodný. Microsoft poznamenává, že podepsaný kód může být stále škodlivý; podpisy stanovují informace o vydavateli a integritě, nikoli záruku bezpečného chování.
• Zapomenutí, který rozsah jste změnili. Příkaz bez -Scope může ovlivnit LocalMachine, zatímco změna Process zmizí při ukončení.

Závěr

Pro většinu osobního skriptování ve Windows je CurrentUser RemoteSigned rozumnou trvalou volbou, když pravidelně spouštíte lokálně vytvořené skripty, zatímco Unblock-File je užší volbou pro jeden zkontrolovaný skript stažený z internetu. Pro dočasnou ladící relaci Process RemoteSigned minimalizuje trvalost. Bypass má legitimní roli v řízené automatizaci, ale jeho kompromisem je, že blokování a varování politiky výkonu jsou pro tento proces odstraněny. Na spravovaných počítačích by měla být Skupinová politika považována za autoritu, nikoli za překážku, kterou je třeba obejít.

Nejlepší opravou tedy není jedna politika pro všechny. Je to nejmenší rozsah a nejméně permisivní chování, které stále podporuje důvěryhodný skript, který potřebujete spustit.