Hai mai scaricato uno script di PowerShell, eseguito e riscontrato il famigerato messaggio di errore qui sotto? In tal caso, hai bisogno del cmdlet Set-ExecutionPolicy e di questo tutorial!
In questo post, imparerai le politiche di esecuzione di PowerShell e come gestirle con il cmdlet Set-ExecutionPolicy. Alla fine di questo post, saprai non solo come eseguire gli script ma anche come utilizzare le politiche di esecuzione!
Questo tutorial è stato scritto con Windows PowerShell in mente e tutte le dimostrazioni sono state eseguite con Windows PowerShell. Le politiche di esecuzione non sono uniche per Windows PowerShell e operano in modo molto simile in PowerShell 6+. Tuttavia, se stai lavorando con PowerShell 6+, potresti trovare piccole differenze nel comportamento.
What è una politica di esecuzione?
Se ti sei mai imbattuto nell’errore descritto sopra, hai incontrato una politica di esecuzione. Le politiche di esecuzione di PowerShell sono un meccanismo di sicurezza per proteggere il tuo sistema dall’esecuzione di script dannosi. Le politiche di esecuzione non impediscono l’esecuzione del codice PowerShell nella console come shell ma l’esecuzione degli script.
Microsoft dice che una politica di esecuzione non è tecnicamente una misura di “sicurezza” ma più un cancello che puoi aprire e chiudere. Dopotutto, puoi aggirare facilmente una politica di esecuzione definita, come imparerai in seguito.
Le politiche di esecuzione si basano sulla fede. Se si ha fiducia in uno script, è probabile che non sia dannoso. Le politiche di esecuzione di solito non impediscono l’esecuzione degli script di tutti. Il loro scopo principale (soprattutto quando configurato in modo più rigoroso) è assicurarsi che si abbia fiducia che lo script in esecuzione sia firmato criptograficamente con un certificato.
Scopi delle politiche di esecuzione
Come hai appreso, le politiche di esecuzione limitano l’esecuzione degli script, ma PowerShell può eseguire script in molti contesti diversi. PowerShell esegue gli script nel contesto dell’utente loggato o nel contesto globale della macchina, tramite attività pianificate che vengono eseguite come SYSTEM o all’interno del contesto di una singola console PowerShell aperta.
Per accomodare tutti questi contesti, PowerShell ha cinque contesti o ambiti diversi in cui puoi definire una politica di esecuzione.
- MachinePolicy – Questo ambito è limitato a un singolo computer. Influisce su tutti gli utenti che accedono a quel computer, ed è impostato da un oggetto di criteri di gruppo di Active Directory. Quando è definito, ha la precedenza su tutti gli altri ambiti.
- LocalMachine. Questo è lo scope predefinito che influisce su tutti gli utenti del computer e viene memorizzato nella sottochiave del registro HKEY_LOCAL_MACHINE. Quando si imposta una policy di esecuzione utilizzando
Set-ExecutionPolicy, questo scope è il predefinito.
La policy di esecuzione per LocalMachine è memorizzata nella chiave del registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell.
- UserPolicy – Lo scope UserPolicy influisce solo su un singolo utente su un computer, e viene impostato da un oggetto di policy di gruppo Active Directory. Non è possibile modificare questa policy con
Set-ExecutionPolicy. - CurrentUser. Lo scope della policy CurrentUser imposta la policy di esecuzione solo per l’utente corrente e viene memorizzato nell’alveo del registro HKEY_CURRENT_USER. Non è possibile modificare questa policy con
Set-ExecutionPolicy.
La policy di esecuzione per CurrentUser è memorizzata nella chiave del registro HKEY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell.
- Process – Questo scope definisce la policy di esecuzione per una singola sessione PowerShell per un singolo utente. Lo scope di esecuzione del processo è la policy di esecuzione più granulare che è possibile definire. A differenza delle altre policy di esecuzione, questa policy viene salvata in una variabile di ambiente chiamata
PSExecutionPolicyPreferenceanziché nel registro.
Tipi di Policy di Esecuzione
Le politiche di esecuzione hanno vari “livelli di sicurezza”. Questi livelli stabiliscono quanto rigido sia il criterio di esecuzione. Ad esempio, è possibile avere una politica di esecuzione che fondamentalmente non fa nulla; è disabilitata, ma d’altra parte, una politica di esecuzione può disabilitare completamente l’esecuzione degli script.
Copriamo ora ciascuno dei modi in cui è possibile configurare il livello di sicurezza di una politica di esecuzione, dal meno al più restrittivo.
Non restrittivo
La politica meno restrittiva è quella che non ha alcun effetto; è Non restrittivo. Le politiche di esecuzione Non restrittive sono fondamentalmente disabilitate. Gli utenti possono eseguire tutti gli script indipendentemente dalla fiducia quando una politica di esecuzione è Non restrittiva.
Bypass
Come il tipo Non restrittivo, una politica di esecuzione impostata su Bypass non blocca nulla.
Anche se Bypass e Non restrittivo hanno un effetto simile, il tipo di politica di esecuzione Bypass non è tecnicamente un tipo. Salta completamente una politica di esecuzione definita.
Non definito
Anche se non comunemente usato, è possibile rimuovere essenzialmente una politica di esecuzione impostandola su Non definito. Quando si imposta una politica di esecuzione su Non definito, PowerShell rimuove completamente tutte le politiche di esecuzione assegnate dallo scope assegnato.
Sui computer non-Windows, la politica di esecuzione è sempre impostata su Non restrittivo e non può essere modificata.
Quando tutti gli ambiti sono impostati su Non definito, PowerShell tratta fondamentalmente tutti gli ambiti come Restretto.
RemoteSigned
Come hai letto in precedenza, le politiche di esecuzione riguardano la fiducia guadagnata attraverso una firma digitale sugli script. PowerShell tiene anche conto da dove proviene quello script. È stato creato sul tuo computer locale o da qualche persona a caso su Internet?
Gli script costruiti in un luogo diverso dal tuo computer locale non dovrebbero essere implicitamente fidati. Questo è il motivo per cui PowerShell fornisce la politica di esecuzione RemoteSigned. La politica di esecuzione RemoteSigned impone che tutti gli script scritti in un luogo diverso dal tuo computer locale siano firmati crittograficamente.
Puoi sovrascrivere questa politica di esecuzione in qualche misura per i file scaricati da Internet usando il
cmdletUnblock-File. Ottieni ulteriori informazioni su questo comportamento un po’ più avanti nella sezione Come funziona la politica RemoteSigned.
Per Windows Server, RemoteSigned viene assegnato come politica predefinita.
AllSigned
Se desideri garantire che tutti gli script di PowerShell siano firmati crittograficamente, imposta la politica di esecuzione su AllSigned. Come RemoteSigned, questa politica di esecuzione porta il requisito di firma un passo avanti e impone che tutti gli script siano firmati prima dell’esecuzione.
Anche se hai impostato la politica di esecuzione AllSigned, puoi comunque aggirare la politica di esecuzione eludendola, come imparerai più avanti.
Restricted
La politica di esecuzione più restrittiva è Restricted. Quando una politica di esecuzione è impostata su Restricted, nessuno script può essere eseguito, indipendentemente dal fatto che siano considerati attendibili o meno. Questa politica disabilita essenzialmente completamente l’esecuzione degli script.
Inoltre, a differenza dei tipi meno restrittivi, il tipo Restricted garantisce che i file di formattazione di PowerShell e i file di configurazione (PS1XML), i file degli script dei moduli (PSM1) e i profili di PowerShell non possano essere eseguiti.
Tutti i client Windows, per impostazione predefinita, sono impostati su una politica di esecuzione Restricted.
Tecnicamente, Microsoft definisce una settima politica di esecuzione chiamata Default, ma il tipo è essenzialmente un altro nome per RemoteSigned (Windows Server) e Restricted (Windows Clients).
Come funziona la politica RemoteSigned
Un particolare scenario da notare è come funziona la politica di esecuzione RemoteSigned. Questa politica di esecuzione (come hai appreso) impedisce l’esecuzione di script creati da qualche parte diversa dal tuo computer locale.
Ma come fa PowerShell a sapere che lo script è stato creato altrove? Attraverso i flussi di dati.
Comprensione e interrogazione dei flussi di dati NTFS
Ogni volta che si crea un file su un sistema di file NTFS, NTFS applica un attributo di flusso di dati alternativo (ADS) al file. Un ADS ha due attributi di file: $Data e zone.Identifier. PowerShell utilizza l’attributo zone.Identifier per identificare se uno script di PowerShell è stato creato altrove.
A differenza di altri attributi come Compressa o Sola lettura, gli attributi ADS sono nascosti in Esplora file. Tuttavia, utilizzando PowerShell, è possibile ispezionare questi flussi di dati.
Esegui il cmdlet Get-Item utilizzando il percorso dello script e il parametro Stream come mostrato di seguito. In questo esempio, Hello World.ps1 è stato scritto sul computer locale. Nota che l’unico attributo assegnato alla proprietà Stream è $DATA. Non ci sono attributi ADS.
Ora, esegui lo stesso comando su uno script scaricato da Internet. Nota che ora Get-Item restituisce un altro oggetto completamente diverso con un Stream di Zone.Identifier.
Una volta che sai che un file ha un ADS, puoi utilizzare il comando Get-Content per scoprire la zona. La zona definisce da dove proviene il file.
Get-Content restituirà un valore ZoneId che rappresenta la zona da cui proviene il file.
I possibili valori della zona sono:
Precedenza delle policy di esecuzione
Come già detto, esistono contemporaneamente molte diverse policy di esecuzione. Tutte queste policy di esecuzione, quando combinate, indicano le impostazioni della sessione corrente. Quando hai più policy di esecuzione in vigore, devono avere una precedenza.
La precedenza delle policy è l’ordine in cui PowerShell applica diverse policy impostate su diverse aree di ambito. Alcune policy di esecuzione hanno una priorità maggiore rispetto ad altre.
Quando esegui il comando Get-ExecutionPolicy -List, troverai tutte le policy di esecuzione attualmente in vigore ordinate dalla priorità più bassa alla più alta. Ad esempio, poiché MachinePolicy ha una priorità più bassa, le policy LocalMachine e CurrentUser le sovrascriveranno.
Lavorare con le Policy di Esecuzione
Dopo aver compreso il contesto delle policy di esecuzione, vediamo come lavorare con esse! Per gestire le policy di esecuzione di PowerShell, hai a disposizione due comandi: Get-ExecutionPolicy per scoprire le policy attualmente definite e Set-ExecutionPolicy per impostare nuove policy.
Ottenere le Policy Attualmente Assegnate
Prima di poter iniziare a modificare le policy di esecuzione, devi capire con cosa stai lavorando. Per fare ciò, hai il comando Get-ExecutionPolicy. Questo comando elenca tutte le policy attualmente assegnate su un computer.
Quando esegui direttamente il comando Get-ExecutionPolicy su una console di PowerShell senza parametri, verrà mostrata la policy di esecuzione impostata per la tua sessione PowerShell corrente.
Per visualizzare la policy di esecuzione impostata per un determinato ambito, specifica il parametro Scope utilizzando il nome dello scope per cui desideri vedere i risultati.
Per visualizzare tutti gli ambiti e le relative policy di esecuzione, utilizza il parametro List come mostrato di seguito.
Cambiare le Policy di Esecuzione
Una volta che sai quali sono le politiche di esecuzione attualmente assegnate, puoi cambiarle anche tu. Per cambiare la politica su un singolo computer, hai a disposizione il comando Set-ExecutionPolicy. Ma, se ti trovi in un’organizzazione, vorrai cambiare le politiche in blocco. In tal caso, hai sempre a disposizione Group Policy se ti trovi in un dominio Active Directory.
Utilizzo di Set-ExecutionPolicy
Prima vediamo come cambiare le politiche con il comando Set-ExecutionPolicy. Per farlo, apri PowerShell come amministratore.
Ora esegui il comando Set-ExecutionPolicy con un singolo parametro (ExecutionPolicy) fornendo il nome della politica di esecuzione.
PowerShell quindi chiederà se desideri cambiare la politica di esecuzione. Se sì, digita Y o A e premi Invio.
Alcuni comandi di PowerShell devono eseguire molteplici altre attività per funzionare. Se nell’esempio sopra inserisci Y, PowerShell potrebbe chiederti di continuare per ogni passaggio. Se premi A, continuerà per tutti i passaggi successivi.
Esecuzione di Set-ExecutionPolicy Senza Prompt
Di default, quando esegui Set-ExecutionPolicy, ti chiederà se desideri o meno modificare la policy di esecuzione. Puoi evitare questa richiesta aggiungendo il parametro Force al tuo comando. Utilizzare il parametro Force sopprimerà tutte le conferme.
Impostare la Policy di Esecuzione di PowerShell tramite il Registro
Dato che la maggior parte delle policy di esecuzione è memorizzata nel registro (escludendo Process), è possibile cambiare le policy direttamente tramite il registro.
Per cambiare le policy di esecuzione tramite il registro:
- Apri l’Editor del Registro di Windows (regedit) o il tuo strumento di modifica del registro preferito.
2. Naviga fino alla chiave del registro della portata della policy di esecuzione che desideri modificare.
LocalMachine – HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
CurrentUser – HKEY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
3. Fai clic destro sulla chiave del registro e crea una nuova stringa chiamata ExecutionPolicy.
4. Fai doppio clic sulla stringa ExecutionPolicy appena creata e inserisci il nome desiderato della policy di esecuzione (Restricted, RemoteSigned, AllSigned, Unrestricted, o Undefined).
5. Crea un altro valore stringa nella stessa chiave chiamato Path. Il valore stringa Path rappresenta il percorso per il motore PowerShell. Assicurati che il valore Path sia C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe, che punta al motore Windows PowerShell.
La policy di esecuzione CurrentUser sovrascrive una policy LocalMachine. Se hai impostato una policy CurrentUser nel registro e provi a cambiare la policy di esecuzione tramite Set-ExecutionPolicy, che, per impostazione predefinita, imposta la policy allo scope LocalMachine, PowerShell restituirà un errore mostrato di seguito.
Impostare la Policy di Esecuzione di PowerShell tramite Group Policy
Se ti trovi in un’organizzazione con Active Directory, non vorrai girare per tutte le tue macchine Windows e eseguire il cmdlet Set-ExecutionPolicy. Invece, puoi gestire le policy in blocco con la Group Policy.
Per gestire le policy di esecuzione tramite GPO:
Crea l’Object Group Policy
- Apri l’applicazione Group Policy Management su un controller di dominio o sulla tua workstation associata al dominio.
2. Espandi Domini —> <il tuo Active Directory forest> —> Group Policy Objects.
3. Fai clic destro su Group Policy Objects e clicca su Nuovo.
4. Assegna un nome al tuo GPO. In questo tutorial, il GPO è chiamato PowerShell Execution Policy.
5. Fai clic con il pulsante destro del mouse sul GPO appena creato e clicca su Edit.
6. Naviga su Computer Configuration\Policies\Administrative Templates\Windows Components\Windows PowerShell.
7. Apri l’impostazione nella finestra destra, apri l’impostazione Turn on Script Execution.
8. Nella casella Turn on Script Execution, seleziona l’opzione Enabled. Ora puoi selezionare una delle opzioni mostrate di seguito:
9. Cambia ora l’Execution Policy con la policy desiderata.
- Allow only signed scripts – Consente l’esecuzione di tutti gli script quando un editore attendibile li firma.
- Allow local scripts and remote signed scripts – Consente l’esecuzione di script locali, ma gli script scaricati da Internet devono essere firmati da un editore attendibile.
- Allow all scripts – Consente l’esecuzione di tutti gli script.
Assegna l’oggetto Group Policy
Una volta creato il GPO, è ora di assegnarlo ai tuoi computer di destinazione. Per farlo, devi assegnare il GPO a un’Unità Organizzativa di Active Directory (OU).
Se, invece di creare un nuovo GPO, hai modificato un GPO esistente, è probabile che quel GPO sia già stato assegnato a una OU.
- In Gestione delle policy di gruppo, naviga nella tua OU di scelta andando su Domini —> <il tuo bosco di Active Directory> —> <La tua OU>.
2. Fai clic con il tasto destro sull’OU e seleziona Collega una GPO esistente…
3. Seleziona la GPO appena creata (Policy di esecuzione di PowerShell) e fai clic su OK.
Dovresti ora vedere la GPO assegnata all’OU come mostrato di seguito.
A questo punto, puoi attendere l’intervallo di aggiornamento definito della Policy di gruppo o eseguire il comando gpupdate su un computer di destinazione per forzare un aggiornamento.
Bloccare le modifiche alla Policy locale
Una volta che una GPO è in vigore e cambia la policy di esecuzione, gli utenti locali non possono più modificare la policy tramite la console PowerShell locale. Se provano, riceveranno un errore, come mostrato di seguito.
Eludere completamente la Policy di esecuzione
Come già accennato, una policy di esecuzione non è necessariamente un misura di sicurezza. Perché? Perché puoi eluderla completamente se lo desideri in diversi modi.
Usando il parametro -ExecutionPolicy Bypass
A differenza delle altre politiche di esecuzione, la politica Bypass è di solito impostata non nella console PowerShell, ma passata al motore powershell.exe eseguito come amministratore.
Ad esempio, per eseguire uno script chiamato Hello World.ps1 ignorando completamente qualsiasi politica di esecuzione, invoca powershell.exe, utilizza il parametro Bypass e fornisce il percorso del file come mostrato di seguito.
Lettura degli script ed esecuzione del codice grezzo
Puoi anche aggirare qualsiasi politica di esecuzione leggendo prima i contenuti di uno script e passando quei contenuti direttamente al motore PowerShell. In questo modo, esegue ogni comando individualmente e non come uno script completo in una volta sola.
Come puoi vedere di seguito, la politica di esecuzione è impostata su Restricted, ma leggendo lo script e passandolo a powershell.exe, funziona comunque.
Questo approccio è simile all’apertura di uno script in un editor PowerShell come PowerShell ISE o Visual Studio Code, selezionando una riga e premendo F8.
Conclusioni
A questo punto dovresti sapere tutto ciò che c’è da sapere sulle politiche di esecuzione di PowerShell. Anche se non sono tecnicamente una misura di sicurezza, dovresti comunque gestirle nella tua organizzazione secondo le politiche organizzative.