Magic Quadrant™ per la gestione degli accessi privilegiati 2025: Netwrix riconosciuta per il quarto anno consecutivo. Scarica il report.

Piattaforma
Centro risorseBlog
Criteri di esecuzione PowerShell

Criteri di esecuzione PowerShell

Mar 26, 2025

Le policy di esecuzione di PowerShell controllano le condizioni di esecuzione degli script per ridurre esecuzioni accidentali o non sicure. Variano da restrittive (Restricted, AllSigned) a permissive (Unrestricted, Bypass) e possono essere applicate a diversi ambiti come Process, CurrentUser e LocalMachine. Sebbene non costituiscano un confine di sicurezza, promuovono la scrittura di script più sicuri, supportano la firma digitale e possono essere applicate centralmente tramite Group Policy per un controllo organizzativo coerente.

Introduzione alle politiche di esecuzione di PowerShell

In PowerShell, le policy di esecuzione sono una funzionalità di sicurezza progettata per controllare le condizioni sotto le quali gli script PowerShell vengono eseguiti su un sistema. Queste policy non sono esattamente un meccanismo di sicurezza, ma sono intese a servire lo scopo seguente:

  • Prevenire l'esecuzione accidentale di script
  • Aiuta a gestire il rischio dell'esecuzione di script da fonti sconosciute o non affidabili

Le politiche di esecuzione svolgono un ruolo importante nel potenziare la sicurezza degli script. Agiscono come prima linea di difesa limitando i tipi di script che possono essere eseguiti su un sistema. Stabiliscono inoltre fiducia per le fonti degli script, come le politiche AllSigned e RemoteSigned che assicurano che gli script provengano da fonti affidabili. Questo aiuta a ridurre gli errori umani, come in una situazione in cui gli utenti potrebbero inconsapevolmente eseguire script scaricati da allegati email o dal web. In un contesto più ampio, le organizzazioni possono utilizzare le politiche di esecuzione per imporre pratiche di sicurezza coerenti su macchine e utenti.

Tuttavia, è necessario tenere anche presente che:

  • Le policy di esecuzione non rappresentano un confine di sicurezza. Possono essere sovrascritte dagli utenti con privilegi amministrativi o eluse tramite specifici flag di PowerShell.
  • Il loro scopo principale è prevenire l'esecuzione accidentale, non fermare gli attori malintenzionati con intento deliberato.

Le policy di esecuzione di PowerShell dovrebbero essere utilizzate come parte di una strategia di sicurezza più ampia, che include script firmati, repository sicuri e altre misure protettive.

Netwrix Auditor for Windows File Servers

Semplifica il processo di monitoraggio dei nuovi file con Netwrix Auditor for Windows File Server

Scopri di più

Comprensione delle Execution Policies di PowerShell

Iniziamo con il funzionamento delle policy di esecuzione nella pratica. Quando esegui uno script, PowerShell controlla la policy di esecuzione.

  • Se lo script soddisfa i requisiti, come essere firmato da un editore affidabile o provenire da una fonte locale, viene eseguito.
  • Se lo script non soddisfa i requisiti della policy, PowerShell impedisce la sua esecuzione e visualizza un messaggio di errore.

Vantaggi principali

Alcuni vantaggi chiave delle politiche di esecuzione di PowerShell sono:

  • Previene l'Esecuzione Accidentale di Script Dannosi – Le politiche di esecuzione riducono il rischio di eseguire involontariamente script non affidabili o nocivi, in particolare quelli scaricati da internet.
  • Incoraggia Pratiche di Scripting Sicure – Politiche come AllSigned e RemoteSigned incoraggiano gli autori e gli utenti di script a firmare gli script con certificati affidabili, garantendo autenticità e integrità.
  • Differenzia script locali vs. remoti – Politiche come RemoteSigned consentono agli script creati localmente di essere eseguiti senza restrizioni mentre applicano controlli più rigorosi su script remoti o scaricati.
  • Configurazione flessibile – Le politiche di esecuzione possono essere applicate a vari ambiti (Process, CurrentUser, LocalMachine, MachinePolicy e UserPolicy), offrendo agli amministratori il controllo su come e dove le politiche vengono applicate.
  • Override temporanee per flessibilità – Le override temporanee (ad esempio, utilizzando -ExecutionPolicy Bypass) consentono l'esecuzione di script in scenari controllati senza modificare permanentemente le impostazioni di sicurezza del sistema.
  • Promuove la conformità organizzativa – Le politiche di esecuzione possono essere applicate in tutta l'organizzazione tramite Group Policy per garantire pratiche di sicurezza coerenti per l'esecuzione degli script.
  • Aumenta la consapevolezza della sicurezza degli script – Richiedendo un'azione esplicita, come firmare gli script o aggirare le politiche, le politiche di esecuzione incoraggiano gli utenti a riflettere criticamente sulle fonti degli script e sulla loro affidabilità.

Principali limitazioni

Alcune limitazioni chiave delle politiche di esecuzione di PowerShell sono:

  • Le policy di esecuzione non rappresentano un confine di sicurezza poiché non sono progettate per prevenire attacchi deliberati. Un utente esperto con privilegi amministrativi può facilmente aggirarle in questo modo:
  • Utilizzando il flag -ExecutionPolicy Bypass
  • Modificare il registro di sistema
  • Esecuzione di script all'interno di un altro processo o eludendo completamente PowerShell
  • Le policy di esecuzione non analizzano il contenuto degli script. Anche gli script firmati possono contenere codice maligno se la chiave di firma è compromessa.
  • Le policy di esecuzione hanno uno scopo di protezione limitato poiché si applicano solo agli script e ai comandi PowerShell. Non controllano altri tipi di script (ad esempio, VBScript, Python) o file eseguibili, lasciando lacune nella protezione.
  • Politiche rigorose come AllSigned possono causare ritardi se gli utenti non hanno accesso a un'infrastruttura di firma affidabile o lavorano spesso con script non firmati.
  • Le politiche di esecuzione si basano sull'adesione degli utenti. Gli utenti non formati potrebbero eludere le politiche di esecuzione o disattivarle senza comprendere appieno le implicazioni.
  • Ambiti di policy multipli, come MachinePolicy, UserPolicy e Process, possono creare confusione, specialmente in ambienti con configurazioni miste o sovrapposte.
  • Gli script automatizzati o le pipeline CI/CD possono incontrare problemi a causa di politiche restrittive, rendendo necessaria una configurazione aggiuntiva o l'annullamento temporaneo delle politiche.
  • Le policy di esecuzione possono creare un falso senso di sicurezza. Gli amministratori e gli utenti potrebbero erroneamente presumere che siano un meccanismo di sicurezza robusto, mentre sono principalmente una salvaguardia contro l'esecuzione accidentale di script.

La seguente tabella riassume i principali vantaggi e limitazioni delle politiche di esecuzione di PowerShell.

Controllo dell'esecuzione degli script

Previeni l'esecuzione accidentale di script dannosi

Facilmente aggirabile dagli utenti con privilegi amministrativi

Convalida della fonte

Incoraggia la firma degli script e l'utilizzo di fonti affidabili

Non verifica il contenuto degli script per comportamenti dannosi

Uso organizzativo

Supporta l'applicazione coerente tramite Group Policy

Potrebbe ostacolare la produttività in ambienti con script non firmati

Flessibilità

Consente configurazioni con ambito e sovrascritture temporanee

Avere più ambiti può creare confusione nella gestione delle policy

Ambito di sicurezza

Aggiunge un livello di difesa in una strategia di sicurezza

Limitato agli script PowerShell, lasciando altri strumenti non protetti

Tipi di PowerShell Execution Policies

PowerShell offre sei tipi di criteri di esecuzione.

Riservato

Questa è la politica di esecuzione predefinita sui sistemi Windows. Blocca l'esecuzione di tutti gli script, quindi gli amministratori non possono automatizzare i compiti utilizzando script. Con questa politica, possono essere eseguiti interattivamente solo comandi singoli.

Poiché questa politica garantisce le massime restrizioni nell'esecuzione degli script, è ideale per ambienti in cui gli script non sono necessari.

RemoteSigned

Questa è la politica di esecuzione predefinita per i server Windows. La politica richiede che gli script remoti, come quelli scaricati da internet, siano firmati da un editore affidabile. Gli script scritti sul computer locale non necessitano di essere firmati. Nel complesso, questa politica bilancia sicurezza e comodità, sebbene possa causare inconvenienti in alcuni scenari.

Per eseguire uno script non firmato scaricato da Internet, è necessario sbloccarlo, ad esempio utilizzando il cmdlet Unblock-File.

AllSigned

Questa politica si basa su certificati affidabili e infrastruttura dei certificati. In base ad essa, solo gli script e i file di configurazione firmati da un editore fidato possono essere eseguiti. Gli script non firmati o manomessi non possono essere eseguiti. Inoltre, viene richiesta la conferma all'utente prima di eseguire qualsiasi script, anche se firmato.

Questa politica è la migliore per ambienti con un forte accento sull'integrità degli script e sull'autenticazione.

Senza restrizioni

Questa politica consente l'esecuzione di tutti gli script senza restrizioni, sebbene vengano visualizzati degli avvisi per gli script remoti non firmati prima dell'esecuzione. È la politica di esecuzione predefinita per i computer non Windows e non può essere modificata.

Poiché questa politica aumenta il rischio di esecuzione di script dannosi o nocivi, dovrebbe essere limitata agli ambienti di sviluppo o di test dove la flessibilità è prioritaria rispetto alla sicurezza.

Bypass

Questa politica consente agli script di essere eseguiti liberamente, senza avvisi o richieste. Utilizza questa opzione in scenari di automazione, pipeline CI/CD o quando le politiche di esecuzione interferiscono con flussi di lavoro legittimi. Attenzione che l'assenza di protezioni o restrizioni può moltiplicare il rischio di esecuzione accidentale o malevola di script.

Indefinito

Utilizzando questa opzione si rimuove la policy di esecuzione per l'ambito corrente. Se tutti gli ambiti sono indefiniti, la policy effettiva di default è Restricted per i client Windows e RemoteSigned per Windows Server. Viene utilizzata per cancellare le impostazioni della policy di esecuzione per un ambito.

Ambito delle politiche di esecuzione di PowerShell

Le policy di esecuzione di PowerShell possono essere applicate a vari ambiti, che determinano come e dove la policy viene applicata. Gli ambiti consentono agli amministratori di controllare il comportamento di esecuzione degli script a diversi livelli, come per singoli utenti, tutti gli utenti su una macchina o una singola sessione. I vari ambiti sono discussi di seguito.

MachinePolicy

Impostato da una Direttiva di Gruppo per tutti gli utenti del computer. Questa direttiva ha la precedenza su LocalMachine e CurrentUser. Per sovrascrivere questa direttiva, rimuovere l'impostazione della Group Policy. Viene utilizzata per la gestione centralizzata delle politiche di esecuzione degli script per tutti gli utenti su una macchina.

UserPolicy

Impostata da una Criteri di Gruppo per l'utente corrente del computer. Questa politica ha la precedenza su LocalMachine e CurrentUser. Viene utilizzata per la gestione centralizzata degli utenti individuali all'interno di un ambiente di dominio. Come per MachinePolicy, questa politica non può essere sovrascritta localmente.

Processo

Si applica solo alla sessione corrente di PowerShell. La policy viene salvata nella variabile d'ambiente $env:PSExecutionPolicyPreference. Quando la sessione di PowerShell viene chiusa, la variabile e il suo valore vengono eliminati. Pertanto la policy è temporanea e termina alla chiusura della sessione. È utile per testare o sovrascrivere temporaneamente la policy di sistema senza apportare modifiche permanenti.

UtenteCorrente

Si applica solo all'utente attualmente connesso. Questa policy è memorizzata nel file di configurazione CurrentUser. È utilizzata per impostare una policy per singoli utenti senza influenzare altri utenti sullo stesso computer.

LocalMachine

Si applica a tutti gli utenti del computer. Questa politica è memorizzata nel file di configurazione AllUsers. Questo è l'ambito predefinito quando non viene specificato alcun ambito. Usatelo per politiche su scala aziendale su macchine condivise o quando più utenti necessitano della stessa politica.

Le politiche di esecuzione per l'utente corrente e il computer locale sono memorizzate nei file di configurazione di PowerShell. La politica di esecuzione per una sessione specifica è memorizzata solo nella memoria e viene persa quando la sessione viene chiusa.

Precedenza dell'ambito

Quando sono definite più politiche di esecuzione in ambiti diversi, PowerShell utilizza il seguente ordine di precedenza per determinare quale politica sia effettiva (dalla priorità più alta alla più bassa):

  1. Group Policy: MachinePolicy
  2. Group Policy: UserPolicy
  3. Politica di esecuzione: Process
  4. Criteri di Esecuzione: LocalMachine
  5. Criteri di Esecuzione: CurrentUser

Ricorda quanto segue:

  • Le impostazioni dei Criteri di gruppo (MachinePolicy e UserPolicy) hanno la precedenza sulle configurazioni locali.
  • Se non viene specificato alcun ambito durante l'impostazione di una policy di esecuzione, per impostazione predefinita viene utilizzato LocalMachine.
  • Se è in atto una Group Policy, i tentativi di modificare la policy con Set-ExecutionPolicy a livelli inferiori falliranno.

Impostazione delle politiche di esecuzione di PowerShell

Impostare una policy di esecuzione PowerShell determina come gli script vengono eseguiti su un sistema.

Controlla la Current Execution Policy

Utilizza il seguente cmdlet per verificare l'attuale policy di esecuzione:

      Get-ExecutionPolicy
      
Image

Verifica le policy per tutti gli ambiti

Utilizza il seguente cmdlet per controllare le policy per tutti gli ambiti:

      Get-ExecutionPolicy -List
      
Image

Imposta una Policy di Esecuzione

Utilizza il cmdlet Set-ExecutionPolicy per impostare una policy di esecuzione per PowerShell.

Sintassi del comando

      Set-ExecutionPolicy <PolicyName> -Scope <Scope>
      

Esempio 1 – Imposta una policy di esecuzione

Utilizza il seguente cmdlet per impostare la policy su Unrestricted.

      Set-ExecutionPolicy Unrestricted
      
Image

Premi Y per procedere o L per annullare l'azione.

Esempio 2 – Specificare l'ambito della Policy di esecuzione

È possibile impostare la policy a diversi livelli (scope). Utilizzare il seguente cmdlet per impostare la policy su RemoteSigned per il computer locale:

      Set-ExecutionPolicy RemoteSigned -Scope LocalMachine
      

Nota quanto segue:

  • È necessario eseguire PowerShell come amministratore per impostare le politiche di esecuzione per l'ambito LocalMachine.
  • Se una policy è applicata tramite Group Policy (MachinePolicy o UserPolicy), essa avrà la precedenza su altre impostazioni e il tentativo di modificare la policy causerà un errore.

Applica la Policy di Esecuzione da un Computer Remoto a un Computer Locale

Per applicare una policy di esecuzione PowerShell da un computer remoto a un computer locale, puoi utilizzare una combinazione di remoting PowerShell e il cmdlet Set-ExecutionPolicy. Si procede nel seguente modo:

      Invoke-Command -ComputerName TargetComputer -ScriptBlock {

    Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force

} -Credential (Get-Credential)
      

Qui, -ComputerName specifica il computer di destinazione. -ScriptBlock contiene il comando da eseguire (Set-ExecutionPolicy in questo caso). -Credential consente di specificare le credenziali se l'account corrente non dispone di autorizzazioni sul computer di destinazione.

Forza l'impostazione della Policy

Per ignorare le richieste durante i cambiamenti della policy di esecuzione, utilizzare il parametro -Force.

      Set-ExecutionPolicy RemoteSigned -Force
      

Rimuovere una Policy di Esecuzione

Per rimuovere una policy per un ambito specifico, impostare la policy su Undefined.

      Set-ExecutionPolicy Undefined -Scope CurrentUser
      

Se tutti gli ambiti sono impostati su Undefined, la politica predefinita diventa Restricted.

Bypass temporaneo delle policy di esecuzione di PowerShell

È possibile aggirare temporaneamente le politiche di esecuzione quando si esegue uno script in PowerShell senza modificare permanentemente la politica. Tuttavia, aggirare le politiche di esecuzione può esporre il sistema a rischi per la sicurezza. Assicurati che gli script che stai eseguendo provengano da fonti affidabili.

Si noti inoltre che potrebbero essere richiesti privilegi amministrativi per alcuni comandi.

Esempio 1: Eludere la Policy di Esecuzione per un Singolo Script

Questo comando elude la policy di esecuzione per quella specifica invocazione di PowerShell.

      powershell.exe -ExecutionPolicy Bypass -File "C:\Temp\Script.ps1"
      

Esempio 2: Bypass nella sessione corrente

È possibile modificare temporaneamente la policy di esecuzione per la durata della sessione corrente.

      Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
      

Qui, -Scope Process assicura che la modifica sia limitata alla sessione PowerShell corrente. Quando chiudi la sessione, la politica di esecuzione tornerà alla sua impostazione originale.

Esempio 3: Esegui script senza modificare la Policy

Utilizza il parametro -Command per eseguire direttamente lo script inline.

powershell.exe -ExecutionPolicy Bypass -Command “& { . ‘C:\Temp\Script.ps1’ }”

Utilizzare Criteri di gruppo per gestire la Policy di esecuzione

L’impostazione del criterio di gruppo “Attiva l’esecuzione degli script” (Turn on Script Execution) consente di gestire il criterio di esecuzione dei computer all’interno della tua azienda. Questa impostazione di Criterio di grupposostituisce i criteri di esecuzione configurati in PowerShell in tutti gli ambiti

  • Quando Turn on Script Execution è disabilitato, gli script non vengono eseguiti. Questo equivale alla politica di esecuzione Restricted.
  • Puoi abilitare Turn on Script Execution e selezionare una politica di esecuzione.
  • Quando Turn on Script Execution non è configurato, non ha alcun effetto. La policy di esecuzione impostata in PowerShell è efficace.

Gestire script firmati e non firmati

Uno script firmato è uno script PowerShell che include:

  • Il contenuto dello script
  • Una firma digitale da un'autorità di certificazione (CA) fidata o un certificato autofirmato

Ciò garantisce che gli script provengano da una fonte affidabile e che non siano stati modificati dopo la loro firma. Gli script firmati contribuiscono ad aumentare la sicurezza negli ambienti che richiedono il controllo sui script che possono essere eseguiti.

Le seguenti politiche di esecuzione sono relative agli script firmati:

  • AllSigned – Richiede che tutti gli script e i file di configurazione siano firmati da un editore affidabile.
  • RemoteSigned – Richiede che gli script scaricati da internet siano firmati da un editore affidabile. Gli script locali non necessitano di essere firmati.

Firma uno script

Per firmare uno script, hai bisogno di un certificato di firma del codice.

  • Puoi ottenere un certificato da un'autorità di certificazione (CA) o generare un certificato autofirmato utilizzando il cmdlet New-SelfSignedCertificate.
  • Utilizza il cmdlet Set-AuthenticodeSignature per firmare lo script.

Ecco come puoi firmare lo script.

      $cert = Get-Item Cert:\CurrentUser\My\CERT_THUMBPRINT
      
      Set-AuthenticodeSignature -FilePath "C:\Temp\Script.ps1" -Certificate $cert
      

Sostituire CERT_THUMBPRINT con l'impronta digitale effettiva del proprio certificato.

Visualizza lo stato della firma dello script

Per verificare se uno script è firmato e lo stato della firma, utilizzare:

      Get-AuthenticodeSignature -FilePath "C:\Temp\Script.ps1"
      

Gestisci script non fidati o non firmati

Per gestire i permessi per gli script senza eludere completamente le politiche, considera quanto segue:

  • Se uno script è contrassegnato come 'da internet', sbloccalo.
  • Quando si eseguono script firmati da un editore per la prima volta, potrebbe essere necessario approvare il certificato dell'editore. È possibile aggiungerlo come affidabile utilizzando gli strumenti di gestione dei certificati.

Esempio: Sblocca uno Script

A volte, uno script potrebbe essere bloccato perché scaricato da internet. Utilizza il cmdlet Unblock-File per sbloccarlo senza aggirare le politiche di esecuzione.

      Unblock-File -Path "C:\Temp\Script.ps1"
      

Gestisci i permessi degli script

La gestione dei permessi degli script in PowerShell comporta il controllo di quali script possono essere eseguiti e da chi. Questo include la configurazione delle politiche di esecuzione, l'utilizzo dei permessi dei file e l'adozione di pratiche di firma del codice.

Controlla l'esecuzione degli script utilizzando le policy di esecuzione di PowerShell

Le politiche di esecuzione limitano le condizioni in cui gli script possono essere eseguiti. Politiche diverse applicano restrizioni diverse. Ad esempio, nessuno script può essere eseguito sotto la politica Restricted.

Utilizza la firma del codice per gli script

La firma degli script garantisce che solo gli script affidabili possano essere eseguiti in ambienti con politiche rigorose.

Utilizzare i permessi dei file NTFS

Limita l'accesso ai file di script modificando i permessi dei file o delle cartelle. Ecco come puoi concedere o negare i permessi.

  1. Fare clic con il pulsante destro del mouse sul file script o sulla cartella e scegliere Proprietà.
  2. Vai alla scheda Sicurezza e fai clic su Modifica.
  3. Aggiungere o rimuovere utenti o gruppi e assegnare i permessi appropriati (ad esempio, Leggi, Scrivi, Esegui).
  4. Nega i permessi agli utenti non autorizzati per prevenire l'esecuzione o la modifica.

Controlla i permessi utilizzando Group Policy

Le Group Policy possono imporre permessi per gli script e politiche di esecuzione su più sistemi. Per configurare una group policy:

  1. Apri la console di Group Policy Management (GPMC).
  2. Naviga in Configurazione computer > Modelli amministrativi > Componenti di Windows > Windows PowerShell.
  3. Imposta la policy di esecuzione desiderata utilizzando la policy “Turn on Script Execution”.

Proteggi script da fonti Internet

Gli script scaricati da internet sono contrassegnati come non sicuri. Apri lo script in un editor di testo per controllarne la sicurezza prima di eseguirlo.

Migliori pratiche per l'impostazione delle politiche di esecuzione

Impostare correttamente le policy di esecuzione di PowerShell è essenziale per bilanciare sicurezza e funzionalità. Da un punto di vista della sicurezza, è necessario comprendere che le policy di esecuzione non sono un confine di sicurezza robusto, ma uno strumento per prevenire l'esecuzione accidentale di script. Esse dovrebbero essere utilizzate insieme ad altre misure di sicurezza come i controlli di accesso, la firma degli script e la protezione degli endpoint. In ambienti aziendali, applicare policy coerenti tramite Group Policy ed educare gli utenti sulle migliori pratiche per minimizzare i rischi.

Di seguito sono riportate alcune delle migliori pratiche per configurare le politiche di esecuzione che bilanciano la sicurezza con la funzionalità.

Utilizza la Policy meno permissiva

Dovresti applicare la politica di esecuzione Restricted o AllSigned ogni volta che è possibile per imporre controlli più rigorosi. RemoteSigned è una scelta pratica per ambienti che richiedono una certa flessibilità ma hanno ancora la necessità di proteggersi da minacce esterne.

Evitare di usare Bypass in modo permanente

Utilizza la policy di esecuzione Bypass solo in scenari specifici di automazione o risoluzione dei problemi. Ritorna a una policy più rigorosa una volta completato il compito.

Utilizza la firma digitale

Firmate gli script utilizzando un'autorità di certificazione (CA) affidabile per garantire integrità e autenticità. Dovete anche incoraggiare gli sviluppatori di script a firmare i loro script, specialmente per l'uso con la politica AllSigned.

Implementare il monitoraggio e la registrazione

Abilita la registrazione delle attività di PowerShell (ad esempio, registrazione dei blocchi di script, registrazione dei moduli e trascrizione) per rilevare e rispondere alle attività sospette.

Utilizza il seguente cmdlet per abilitare il logging del modulo:

      Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging" -Name EnableModuleLogging -Value 1
      

I log possono essere visualizzati in Event Viewer sotto Applicazioni e Servizi Logs > Microsoft > Windows > PowerShell.

Puoi anche utilizzare strumenti come Microsoft Defender for Endpoint o soluzioni SIEM per monitorare i log.

Testare le politiche in un ambiente non di produzione

Per evitare sorprese, testare le politiche di esecuzione in un ambiente controllato prima di distribuirle in tutta l'organizzazione. Ciò garantirà anche che script legittimi e flussi di lavoro di automazione non vengano interrotti.

Utilizzare le modifiche condizionali delle policy

Per gestire i flussi di lavoro che richiedono flessibilità, modificare temporaneamente le politiche utilizzando il parametro -Scope Process. Il cmdlet è il seguente:

      Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process
      

Considerare l'ambiente quando si applica la Policy

Le policy di esecuzione PowerShell consigliate variano a seconda dell'ambiente.

  • Ambiente di Sviluppo – RemoteSigned rimane la politica consigliata. Offre flessibilità agli sviluppatori per eseguire script locali senza firmarli e garantisce che gli script scaricati da internet siano firmati e affidabili. Dovresti anche abilitare la registrazione dei blocchi di script per monitorare l'esecuzione degli script.
  • Ambiente di Test/Staging – Utilizzare la policy RemoteSigned o AllSigned. RemoteSigned è pratica per testare una combinazione di script locali ed esterni con controlli di integrità di base mentre AllSigned impone un controllo più rigoroso richiedendo che tutti gli script siano firmati.
  • Ambiente di Produzione – Utilizzare la politica AllSigned o Restricted. AllSigned garantisce che vengano eseguiti solo script firmati da un editore affidabile. Tuttavia, Restricted è l'opzione più sicura per ambienti che non si basano su script PowerShell. È inoltre consigliabile applicare le politiche tramite Group Policy per garantire la coerenza tra i sistemi.
  • Ambiente di automazione – Bypass è la politica consigliata (solo per compiti specifici). Permette alle attività di automazione di procedere senza interruzioni, specialmente quando le politiche sono gestite da altri meccanismi, come la whitelist delle applicazioni e le pipeline DevOps. È necessario anche proteggere l'ambiente di automazione con controlli di accesso adeguati e audit regolari.
  • Ambienti altamente sicuri – La policy Restricted dovrebbe essere la vostra scelta poiché impedisce l'esecuzione di qualsiasi script.

Risoluzione degli errori della Policy di esecuzione

Di seguito sono riportati errori comuni relativi alle politiche di esecuzione di PowerShell e le loro soluzioni.

“L'esecuzione degli script è disabilitata su questo sistema”

Potresti ricevere un messaggio di errore come:

Il file C:\Temp\Script.ps1 non può essere caricato perché l'esecuzione degli script è disabilitata su questo sistema.

Causa: La policy di esecuzione è impostata su Restricted o Undefined, il che impedisce l'esecuzione di qualsiasi script.

Soluzione: Verificare la policy attuale e modificarla temporaneamente per la sessione specifica. In alternativa, è possibile modificare la policy per l'utente o la macchina corrente:

Per modificare la policy per la sessione corrente, utilizzare il seguente cmdlet:

      Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
      

Per modificare la policy per l'utente o la macchina corrente, utilizzare il seguente cmdlet:

      Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned
      

“Non può essere caricato perché lo script non è firmato digitalmente”

Potresti ricevere un messaggio di errore del tipo:

Il file C:\Temp\Script.ps1 non può essere caricato. Il file non è firmato digitalmente.

Causa: La policy di esecuzione è impostata su AllSigned o RemoteSigned, il che richiede che gli script siano firmati.

Soluzione: Utilizzare RemoteSigned invece di AllSigned se ti fidi degli script locali. Oppure potresti aggirare temporaneamente la policy.

“L'accesso alla chiave di registro è negato”

Potresti ricevere un messaggio di errore del tipo:

Set-ExecutionPolicy: Accesso alla chiave di registro negato.

Causa: Non si dispone dei permessi sufficienti per modificare la policy di esecuzione nell'ambito LocalMachine.

Soluzione: Esegui PowerShell come amministratore o imposta la policy per l'utente corrente utilizzando il seguente cmdlet:

      Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned
      

Conflitti di Policy di Esecuzione tra Ambiti

Ambiti diversi (MachinePolicy, UserPolicy, Process, CurrentUser, LocalMachine) presentano politiche in conflitto.

Causa: Una politica più rigorosa a un livello superiore (come MachinePolicy) prevale su una politica più permissiva a un livello inferiore (come LocalMachine).?

Soluzione: Verificate le policy per tutti gli ambiti utilizzando il seguente cmdlet:

      Get-ExecutionPolicy -List
      

Una volta ottenute queste informazioni, puoi modificare la policy nell'ambito appropriato o eseguire script in una sessione con una policy più permissiva.

“Impossibile modificare la policy di esecuzione perché è controllata da un Group Policy Object (GPO)”

Questo problema si verifica quando la policy di esecuzione è imposta tramite Group Policy, impedendo modifiche locali.

Soluzione: Consultare l'amministratore di sistema per modificare il Group Policy. Per una soluzione rapida, tuttavia, è possibile bypassare temporaneamente la policy.

“Ambito della policy non riconosciuto”

Potresti ricevere un messaggio di errore del tipo:

Set-ExecutionPolicy: L'ambito specificato non è riconosciuto.

Causa: Un errore di battitura nel nome dell'ambito.

Soluzione: Assicurarsi che l'ambito sia correttamente specificato come uno di questi.

Comportamento inaspettato in diverse versioni di PowerShell

Le versioni precedenti di PowerShell, come la 2.0, gestiscono le politiche di esecuzione in modo diverso o mancano di alcune funzionalità.

Soluzione: Aggiornare all'ultima versione di PowerShell.

Script contrassegnati come bloccati

Potresti ricevere un messaggio di errore del tipo:

Il file non può essere caricato. Il file non è firmato digitalmente o è stato scaricato da internet ed è bloccato.

Causa: Lo script è stato contrassegnato come bloccato perché è stato scaricato da internet.

Soluzione: Sblocca lo script utilizzando il seguente cmdlet:

      Unblock-File -Path C:\Temp\Script.ps1
      

Conclusione: Scegliere la giusta Execution Policy di PowerShell

È necessario prendere in considerazione questi fattori quando si sceglie una politica di esecuzione efficace.

  • Identificate l'ambiente prima di scegliere una politica di esecuzione poiché diversi ambienti richiedono una politica diversa. Ad esempio, per i server di produzione, AllSigned o RemoteSigned è il migliore per imporre un certo livello di verifica degli script.
  • Dovreste anche valutare i vostri requisiti di sicurezza e decidere di conseguenza. Ad esempio, utilizzate AllSigned se avete un solido processo di firma del codice e volete imporre un controllo rigoroso sull'esecuzione degli script. Oppure usate Restricted per i sistemi che non dovrebbero eseguire script.
  • Considerate le vostre esigenze di automazione. Sarebbe più semplice utilizzare la policy Bypass in ambienti dove gli script vengono eseguiti automaticamente da processi affidabili.
  • Infine, valutate la fonte degli script. Se gli script provengono internamente e sono affidabili, RemoteSigned offre un equilibrio tra usabilità e sicurezza. E se gli script sono un mix di interni ed esterni, considerate AllSigned per una sicurezza potenziata.

FAQ

Cos'è la variabile $env:psexecutionpolicypreference?

La variabile d'ambiente $env:PSExecutionPolicyPreference viene utilizzata in PowerShell per sovrascrivere temporaneamente la politica di esecuzione per una singola sessione senza modificare le politiche di esecuzione a livello di sistema o specifiche per l'utente. Quando chiudi la sessione, la modifica viene persa.

Puoi utilizzare $env:psexecutionpolicypreference nei seguenti modi:

  • Assegna un valore a $env:PSExecutionPolicyPreference per modificare temporaneamente la policy di esecuzione, come mostrato di seguito:

$env:PSExecutionPolicyPreference = “Bypass”

Dopo ciò, gli script verranno eseguiti senza restrizioni per la durata della sessione.

  • Controlla il valore attuale di questa variabile, come mostrato di seguito:

$env:PSExecutionPolicyPreference

  • Rimuovi la policy temporanea e ritorna al comportamento predefinito, come mostrato di seguito:

Remove-Item Env:PSExecutionPolicyPreference

Condividi su

Scopri di più

Informazioni sull'autore

Asset Not Found

Jonathan Blackwell

Responsabile dello Sviluppo Software

Dal 2012, Jonathan Blackwell, ingegnere e innovatore, ha fornito una leadership ingegneristica che ha posizionato Netwrix GroupID all'avanguardia nella gestione di gruppi e utenti per ambienti Active Directory e Azure AD. La sua esperienza nello sviluppo, nel marketing e nelle vendite permette a Jonathan di comprendere appieno il mercato dell'Identity Management e il modo di pensare degli acquirenti.