Execution policy w PowerShellu - jak bezpiecznie uruchamiać skrypty

Gdy skrypt PowerShella działa na jednym komputerze, a na drugim kończy się komunikatem o zablokowanym uruchamianiu, przyczyną często jest execution policy. To ustawienie decyduje, czy PowerShell może ładować pliki konfiguracyjne i uruchamiać skrypty, ale nie jest prostym przełącznikiem „bezpieczeństwo włączone lub wyłączone”. Pokażę, jak sprawdzić aktywną politykę, rozumieć jej zakresy, bezpiecznie ją zmieniać i rozwiązywać typowe problemy na Windowsie.

Za co odpowiada execution policy w PowerShellu

Polityka wykonywania to mechanizm ochronny PowerShella, który określa warunki uruchamiania skryptów i ładowania plików konfiguracyjnych. Może wymagać podpisu cyfrowego, blokować pliki pobrane z internetu albo pozwalać na uruchomienie kodu bez dodatkowych ostrzeżeń.

Najczęściej problem pojawia się przy plikach .ps1 pobranych z przeglądarki, poczty lub komunikatora. Windows może oznaczyć taki plik jako pochodzący z internetu, a PowerShell potraktuje go ostrożniej niż skrypt utworzony lokalnie.

Trzeba jednak dobrze rozumieć granice tego mechanizmu. Execution policy nie jest pełnoprawnym systemem kontroli bezpieczeństwa. Doświadczony użytkownik może uruchomić PowerShell z inną polityką, a sama polityka nie analizuje, czy kod jest złośliwy. Dlatego traktuję ją jako warstwę ograniczającą przypadkowe uruchomienie skryptu, a nie jako zamiennik Microsoft Defendera, AppLockera czy zasad kontroli dostępu.

Jak sprawdzić aktywną politykę i jej zakres

Najpierw sprawdzam, jaka polityka faktycznie obowiązuje. Samo polecenie bez parametrów zwraca tylko efektywne ustawienie dla bieżącej sesji:

Get-ExecutionPolicy

Znacznie bardziej przydatne jest polecenie pokazujące wszystkie zakresy:

Get-ExecutionPolicy -List

Wynik może wyglądać podobnie do poniższego:

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process       Undefined
  CurrentUser       RemoteSigned
 LocalMachine       Restricted

W tym przykładzie aktywne jest ustawienie RemoteSigned z zakresu CurrentUser, ponieważ ma wyższy priorytet niż LocalMachine. Kolejność ma znaczenie, dlatego zmiana polityki komendą Set-ExecutionPolicy nie zawsze daje efekt, którego oczekujemy.

W praktyce zaczynam od Process albo CurrentUser. Zmiana LocalMachine wymaga uruchomienia PowerShella jako administrator i wpływa na innych użytkowników, więc powinna mieć wyraźne uzasadnienie.

Co oznaczają poszczególne tryby

Każdy tryb odpowiada innemu poziomowi kontroli. Na komputerze deweloperskim nie zawsze potrzebujesz najbardziej restrykcyjnego ustawienia, ale przejście od razu na Bypass zwykle jest zbyt daleko idącą reakcją na pojedynczy błąd.

Dlaczego RemoteSigned jest praktycznym kompromisem

Tryb RemoteSigned pozwala tworzyć i uruchamiać własne skrypty bez podpisywania każdego pliku. Jednocześnie plik oznaczony przez Windows jako pobrany z internetu musi mieć podpis cyfrowy albo zostać świadomie odblokowany.

Jeżeli znasz źródło pliku i sprawdziłeś jego treść, często lepszym rozwiązaniem jest odblokowanie konkretnego skryptu:

Unblock-File -Path .\skrypt.ps1

To podejście zmienia atrybut jednego pliku, a nie osłabia ustawień całego komputera. Sam stosuję je wtedy, gdy problem dotyczy pojedynczego skryptu dostarczonego przez zaufany zespół.

Jak zmienić politykę bez niepotrzebnego ryzyka

Do zmiany ustawienia służy Set-ExecutionPolicy. Dla bieżącego użytkownika można użyć:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Ta komenda nie wymaga zwykle uprawnień administratora i nie zmienia konfiguracji innych kont. Jeżeli chcesz zastosować zmianę wyłącznie podczas jednego zadania, wybierz zakres Process:

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process

Po zamknięciu sesji ustawienie przestaje działać. To dobry wariant dla testu, instalatora lub jednorazowego procesu, ale Bypass powinien być wyjątkiem, a nie stałą konfiguracją komputera.

Nie zaczynałbym od tej komendy:

Set-ExecutionPolicy Unrestricted -Scope LocalMachine -Force

Zmienia ona ustawienie dla wszystkich użytkowników i może ukryć prawdziwą przyczynę problemu. Parametr -Force dodatkowo pomija pytanie potwierdzające, więc łatwo zastosować zmianę bez świadomej decyzji.

Uruchomienie pojedynczego skryptu z inną polityką

Można też uruchomić nową sesję z polityką obowiązującą tylko dla tego procesu:

powershell.exe -ExecutionPolicy Bypass -File .\skrypt.ps1

W PowerShell 7 analogicznie używa się programu pwsh.exe. Takie rozwiązanie bywa przydatne w kontrolowanym instalatorze, narzędziu developerskim lub zadaniu CI/CD, ale powinno iść w parze z weryfikacją źródła skryptu i ograniczeniem uprawnień procesu.

Dlaczego skrypt nadal się nie uruchamia

Komunikat o zablokowanym pliku nie zawsze oznacza, że trzeba zmienić politykę. Najpierw sprawdzam cztery rzeczy, bo każda prowadzi do innego rozwiązania.

Polityka jest nadpisana przez Group Policy

Jeżeli w wyniku Get-ExecutionPolicy -List widzisz wartość przy MachinePolicy albo UserPolicy, ustawienie mogło zostać narzucone centralnie. Lokalna komenda może wtedy zmienić zapis preferencji, ale nie zmieni efektywnej polityki.

W firmowym środowisku nie próbowałbym tego obchodzić. Właściwą drogą jest kontakt z administratorem albo uzgodnienie podpisywania skryptów.

Plik ma oznaczenie pochodzenia z internetu

Przy polityce RemoteSigned lokalny skrypt może działać, a pobrany z sieci już nie. Możesz sprawdzić właściwości pliku w Eksploratorze Windows i użyć opcji odblokowania albo wykonać:

Unblock-File -Path .\skrypt.ps1

Nie odblokowuj automatycznie wszystkich plików w katalogu bez sprawdzenia ich pochodzenia. Odblokowanie jest świadomą decyzją dotyczącą konkretnego pliku, a nie magiczną naprawą każdego błędu PowerShella.

Skrypt nie znajduje się w bieżącej lokalizacji

PowerShell nie uruchamia pliku z bieżącego katalogu po wpisaniu samej nazwy tak, jak robią to niektóre powłoki. Użyj ścieżki względnej:

.\skrypt.ps1

Jeżeli ścieżka zawiera spacje, przekaż ją jako wartość w cudzysłowie. Ten drobiazg często wygląda jak problem z execution policy, choć w rzeczywistości chodzi o sposób wskazania pliku.

Przeczytaj również: Aktualizacja WSL bez błędów. Polecenia i bezpieczny backup

Problem dotyczy profilu PowerShella

Polityka może również wpływać na ładowanie profilu, czyli skryptu wykonywanego przy uruchomieniu sesji. Gdy profil powoduje błędy, sprawdź jego lokalizację poleceniem:

$PROFILE

Do testowego uruchomienia bez profilu możesz użyć:

powershell.exe -NoProfile

Jeżeli sesja działa poprawnie bez profilu, nie zmieniaj od razu globalnej polityki. Zbadaj zawartość pliku profilu i popraw konkretną instrukcję.

Execution policy w aplikacjach desktopowych i automatyzacji

W aplikacjach .NET, instalatorach i narzędziach administracyjnych PowerShell może być uruchamiany jako proces potomny albo osadzany w aplikacji. W takim scenariuszu ustawienie z bieżącej konsoli nie musi odpowiadać konfiguracji procesu uruchamianego przez aplikację.

Dlatego przy diagnozowaniu aplikacji desktopowej sprawdzam nie tylko własny terminal, lecz także konto użytkownika, ścieżkę do używanego PowerShella i argumenty przekazane przy starcie. Windows PowerShell 5.1 oraz PowerShell 7 mogą mieć różne profile i pliki konfiguracyjne, mimo że oba uruchamiają skrypty z rozszerzeniem .ps1.

W zadaniach automatyzacji rozsądniej jest przekazać politykę tylko dla konkretnego procesu, kontrolować skrypty w repozytorium i logować ich wersję. Stałe ustawienie Bypass na stacji roboczej może usunąć komunikat, ale utrudnia później ustalenie, dlaczego skrypt został uruchomiony.

Na komputerze deweloperskim zwykle wystarcza RemoteSigned w zakresie CurrentUser. W środowisku firmowym ważniejsze od samego trybu są podpisy kodu, Group Policy, ograniczenie uprawnień i kontrola tego, kto może modyfikować pliki wykonywane automatycznie.

Najrozsądniejsza konfiguracja na co dzień

Jeżeli potrzebujesz po prostu uruchamiać własne skrypty na Windowsie, zacznij od sprawdzenia ustawień poleceniem Get-ExecutionPolicy -List. Gdy nie obowiązuje polityka firmowa, wybierz RemoteSigned dla CurrentUser, a przy pojedynczym problemie odblokuj tylko zaufany plik.

Zmianę na Bypass zostaw dla krótkich, kontrolowanych procesów. Najwięcej problemów znika wtedy, gdy rozdzielisz trzy kwestie: politykę wykonywania, oznaczenie pliku pobranego z internetu oraz faktyczne uprawnienia konta. Dzięki temu naprawiasz przyczynę, a nie tylko wyciszasz komunikat.