{"id":200588,"date":"2024-02-15T14:22:05","date_gmt":"2024-02-15T14:22:05","guid":{"rendered":"https:\/\/www.ninjaone.com\/?p=200588"},"modified":"2025-05-21T08:00:25","modified_gmt":"2025-05-21T08:00:25","slug":"comprendere-i-criteri-di-esecuzione-di-powershell","status":"publish","type":"post","link":"https:\/\/www.ninjaone.com\/it\/blog\/comprendere-i-criteri-di-esecuzione-di-powershell\/","title":{"rendered":"Comprendere i criteri di esecuzione di PowerShell"},"content":{"rendered":"

Sviluppato da Microsoft<\/a>, PowerShell \u00e8 diventato uno standard moderno per l’amministrazione, lo scripting e l’automazione in ambiente Windows. Combinando un’interfaccia a riga di comando con un linguaggio di scripting, PowerShell ha trasformato le modalit\u00e0 di gestione in Windows.<\/span><\/p>\n

Basato sul framework .NET<\/a>, PowerShell si integra perfettamente con le tecnologie Microsoft utilizzando brevi comandi, o cmdlet, per interagire con i componenti del sistema, manipolare i dati e automatizzare le funzioni amministrative. Questo approccio basato su script consente agli utenti di semplificare le attivit\u00e0, migliorare l’efficienza e automatizzare le attivit\u00e0 pi\u00f9 comuni. PowerShell supporta anche la gestione degli eventi, la pianificazione delle attivit\u00e0 e la gestione remota, offrendo una soluzione completa per gli amministratori IT, i professionisti della sicurezza informatica e gli esperti di scripting.<\/span><\/p>\n

Questa guida si concentra sui criteri di esecuzione di PowerShell<\/strong>, spiegandone l’importanza, il funzionamento, la gestione, l’impatto che hanno sulla sicurezza del sistema e le best practice a essi correlate. L’obiettivo \u00e8 quello di far comprendere come questi criteri di esecuzione permettano di eseguire efficacemente gli script e ottimizzino la sicurezza del sistema in ambienti Windows.<\/span><\/p>\n

Cosa sono i criteri di esecuzione di PowerShell?<\/h2>\n

I criteri di esecuzione di PowerShell fungono da meccanismo di salvaguardia negli ambienti Windows, determinando il livello di fiducia assegnato agli script prima della loro esecuzione. Questi criteri mirano a trovare un equilibrio tra la possibilit\u00e0 di eseguire script per scopi legittimi e la riduzione dei potenziali rischi di sicurezza associati. Aderendo a un criterio di esecuzione, gli amministratori possono progettare un ambiente di scripting coerente e sicuro, riducendo le possibilit\u00e0 che script dannosi compromettano i loro sistemi.\u00a0<\/span><\/p>\n

I tipi di criteri di esecuzione disponibili sono i seguenti:<\/span><\/p>\n

    \n
  • AllSigned:<\/b> Con questo criterio, tutti gli script, compresi quelli creati localmente, devono essere firmati digitalmente da una fonte affidabile per poter essere eseguiti. Questo approccio garantisce che solo gli script autorizzati possano essere eseguiti, ma comporta il rischio di eseguire script dannosi che sono stati comunque firmati.<\/span><\/li>\n
  • Bypass:<\/b> Questo criterio consente l’esecuzione di qualsiasi script senza limitazioni. Questo criterio deve essere usato con estrema cautela, se non altro perch\u00e9 pu\u00f2 potenzialmente esporre i sistemi a rischi di sicurezza, dato che consente l’esecuzione di script non firmati e non verificati.<\/span><\/li>\n
  • Default: <\/b>Con questo tipo di criterio, viene impostata l’esecuzione predefinita. Per impostazione predefinita, il criterio di esecuzione \u00e8 \u201crestricted\u201d per i client Windows e \u201cRemoteSigned\u201d per i server Windows. Di seguito vengono illustrati entrambi i tipi di criteri di esecuzione.<\/span><\/li>\n
  • RemoteSigned:<\/b> Questo criterio richiede che gli script scaricati da Internet siano firmati digitalmente per l’esecuzione e siano consentiti. Gli script creati localmente possono essere eseguiti senza firma digitale. Questo criterio secondo molti garantisce un equilibrio concreto tra usabilit\u00e0 e sicurezza.<\/span><\/li>\n
  • Restricted:<\/b> Questo criterio \u00e8 il pi\u00f9 sicuro tra quelli disponibili. Blocca l’esecuzione di tutti gli script, creati o scaricati localmente, e di tutti i file di script. Tuttavia, non impedisce di eseguire i singoli comandi nell’ambiente PowerShell.<\/span><\/li>\n
  • Undefined:<\/b> Questo criterio viene utilizzato quando non \u00e8 stato impostato esplicitamente alcun criterio di esecuzione. Consente agli utenti di eseguire script e offre flessibilit\u00e0, ma \u00e8 consigliabile selezionare un criterio specifico per garantire il controllo e migliorare la sicurezza. Se il criterio \u00e8 impostato come Undefined in tutti i campi di applicazione, verranno impostate automaticamente le restrizioni predefinite.<\/span><\/li>\n
  • Unrestricted: <\/b>Questo criterio permette l’esecuzione illimitata di script, consentendo di eseguire script sia locali che provenienti da Internet senza alcuna restrizione. Sebbene sia comodo per lo sviluppo e i test, non dovrebbe essere utilizzato in ambienti di produzione a causa dei notevoli rischi per la sicurezza che comporta.<\/span><\/li>\n<\/ul>\n

    La comprensione di questi criteri di esecuzione consente agli amministratori e ai professionisti della sicurezza di adottare l’approccio pi\u00f9 adatto ai requisiti di sicurezza dei loro sistemi.\u00a0<\/span><\/p>\n

    Nelle sezioni successive verranno analizzate la gestione, le best practice e le conseguenze dell\u2019utilizzo dei criteri di esecuzione di PowerShell.<\/span><\/p>\n

    Gestione dei criteri di esecuzione di PowerShell<\/h2>\n

    L’impostazione e la modifica dei criteri di esecuzione di PowerShell \u00e8 fondamentale per creare un ambiente di scripting sicuro. Gli amministratori possono utilizzare il cmdlet Set-ExecutionPolicy per configurare questi criteri. Comprendendo i potenziali rischi e i benefici delle diverse configurazioni dei criteri, gli amministratori possono prendere decisioni consapevoli e in linea con i loro obiettivi di sicurezza.\u00a0<\/span><\/p>\n

    La prima considerazione riguarda il campo di applicazione del criterio di esecuzione, che pu\u00f2 essere uno dei seguenti:<\/span><\/p>\n

      \n
    • MachinePolicy:<\/b> Questo campo di applicazione \u00e8 impostato dai criteri di gruppo (group policy) e vede il criterio di esecuzione applicato a tutti gli utenti e i processi di un computer, garantendo l’uniformit\u00e0 in tutto il sistema. I criteri dell’utente locale possono essere sovrascritti da questo criterio.<\/span><\/li>\n
    • UserPolicy:<\/b> Questo campo di applicazione \u00e8 impostato da criteri di gruppo e applica il criterio di esecuzione per gli utenti di una macchina specifica. \u00c8 particolarmente utile per mantenere un ambiente di scripting coerente per tutti gli utenti.<\/span><\/li>\n
    • Processo<\/b>: In questo campo di applicazione, i criteri di esecuzione sono definiti solo per la sessione PowerShell corrente. Consente un controllo pi\u00f9 granulare sull’esecuzione degli script in base a esigenze specifiche.<\/span><\/li>\n
    • CurrentUser:<\/b> Questo campo di applicazione utilizza il criterio di esecuzione per la sessione corrente dell’utente. Non richiede alcuna elevazione dei privilegi.<\/span><\/li>\n
    • LocalMachine:<\/b> Questo \u00e8 il campo di applicazione predefinito e l’assegnazione di un criterio qui ha un impatto su tutti gli utenti di un determinato computer. Se esiste un criterio utente, avr\u00e0 la precedenza rispetto a questo campo di applicazione.<\/span><\/li>\n<\/ul>\n

      Le modifiche ai criteri di esecuzione hanno un impatto diretto sulla sicurezza del sistema e sull’esecuzione degli script. Un criterio pi\u00f9 restrittivo, come “Restricted” o “AllSigned”, aumenta la sicurezza riducendo il rischio di esecuzione di script non autorizzati o dannosi. Tuttavia, ci\u00f2 potrebbe rendere necessari ulteriori passaggi, come la firma degli script, che possono comportare un sovraccarico di lavoro amministrativo.<\/span><\/p>\n

      Un criterio pi\u00f9 permissivo, come “Unrestricted” o “Bypass”, semplifica l’esecuzione degli script rimuovendo le barriere, ma potrebbe esporre il sistema a rischi di sicurezza. L’adozione di questi ultimi criteri deve avvenire con cautela e deve essere impiegata solo in ambienti controllati per periodi di tempo limitati o durante le fasi di sviluppo e di test. Gli amministratori devono tenere in considerazione i requisiti di sicurezza dell’organizzazione e le esigenze specifiche degli utenti quando scelgono e modificano i criteri di esecuzione. Il giusto equilibrio tra sicurezza e funzionalit\u00e0 garantisce la sicurezza dell’ambiente di scripting PowerShell.<\/span><\/p>\n

      Nelle sezioni seguenti verranno analizzate le best practice associate ai criteri di esecuzione di PowerShell, i problemi comuni che si incontrano durante la loro gestione, e il loro allineamento con le linee guida dell’organizzazione in materia di sicurezza. Questi approfondimenti permetteranno agli amministratori e ai professionisti della sicurezza di prendere decisioni consapevoli per ottenere un ambiente di scripting sicuro ed efficiente.<\/span><\/p>\n

      Best practice per i criteri di esecuzione di PowerShell<\/h2>\n

      Quando si sceglie un criterio di esecuzione di PowerShell per ambienti diversi, \u00e8 bene tenere in considerazione la natura degli script che verranno eseguiti, il livello di sicurezza richiesto e il ruolo degli utenti. Per esempio:<\/span><\/p>\n

        \n
      • Ambiente di produzione:<\/b> In un ambiente di produzione, \u00e8 prudente adottare un criterio pi\u00f9 restrittivo come “AllSigned” o “RemoteSigned”. Questo garantisce che gli script siano firmati e autenticati prima dell’esecuzione e riduce il rischio legato all\u2019uso di codice non autorizzato o dannoso.<\/span><\/li>\n
      • Ambiente di sviluppo:<\/b> In un ambiente di sviluppo, \u00e8 possibile utilizzare un criterio pi\u00f9 flessibile come “Bypass” o “Unrestricted” per facilitare i test e la risoluzione dei problemi. Tuttavia, questi criteri non devono essere trasferiti agli ambienti di produzione.<\/span><\/li>\n<\/ul>\n

        Come gestire e modificare i criteri in modo sicuro<\/h3>\n

        Per gli amministratori IT, i professionisti della sicurezza informatica e le persone coinvolte nell’amministrazione di Windows e nello scripting PowerShell, \u00e8 fondamentale capire come gestire in modo sicuro questi criteri.\u00a0<\/span><\/p>\n

        Le best practice per la gestione e la modifica dei criteri di esecuzione di PowerShell includono:<\/span><\/p>\n

          \n
        • Documentare i criteri di esecuzione:<\/b> Assicurati che gli amministratori e gli utenti comprendano le conseguenze dell\u2019applicazione dei diversi criteri di esecuzione. Crea una documentazione chiara che illustri quali criteri sono appropriati per scenari specifici.<\/span><\/li>\n
        • Rendi obbligatoria la firma degli script:<\/b> Per i criteri pi\u00f9 restrittivi, come “AllSigned” e “RemoteSigned”, rendi obbligatoria la pratica di firmare gli script con firme digitali. Questo aggiunge un ulteriore livello di sicurezza, garantendo l’autenticit\u00e0 degli script.<\/span><\/li>\n
        • Selezionare il campo di applicazione meno permissivo:<\/b> Determina il campo di applicazione appropriato per l’impostazione dei criteri di esecuzione. Tieni presente l’impatto sugli utenti e sui processi all’interno dei diversi campi di applicazione, nonch\u00e9 l’impatto sulla sicurezza del sistema e l’allineamento con i criteri di sicurezza. La scelta del criterio che offre il minor privilegio possibile pur fornendo la funzione richiesta \u00e8, in questo caso, la best practice.<\/span><\/li>\n
        • Revisionare i criteri<\/b>: Ricontrolla e verifica regolarmente i criteri di esecuzione in tutto l’ambiente. Assicurati che i criteri rimangano in linea con i requisiti di sicurezza e le linee guida organizzative.<\/span><\/li>\n<\/ul>\n

          Problemi frequenti e soluzioni<\/h2>\n

          L’impostazione dei criteri di esecuzione di PowerShell pu\u00f2 spesso portare a problemi di impatto sugli script e sulle operazioni di sistema. Alcuni problemi comuni includono:<\/span><\/p>\n

            \n
          • Accesso negato: <\/b>Gli utenti potrebbero riscontrare errori di “Accesso negato” quando cercano di modificare i criteri di esecuzione, a causa della mancanza di privilegi amministrativi.<\/span><\/li>\n
          • Script bloccati:<\/b> Criteri pi\u00f9 restrittivi come “AllSigned” possono impedire l’esecuzione di script non firmati o firmati in modo improprio, causando frustrazione agli utenti.<\/span><\/li>\n
          • Script non attendibili:<\/b> Gli script provenienti da Internet potrebbero essere bloccati da criteri come “RemoteSigned”, anche se sono sicuri e legittimi.<\/span><\/li>\n<\/ul>\n

            Per risolvere questi problemi e garantire l’esecuzione corretta dello script, segui questi passaggi di troubleshooting:<\/span><\/p>\n

              \n
            • Elevare i privilegi:<\/b> Assicurati di avere privilegi amministrativi quando modifichi i criteri di esecuzione. Esegui PowerShell con diritti amministrativi cliccando con il pulsante destro del mouse e selezionando “Esegui come amministratore”<\/span><\/li>\n
            • Firma dello script:<\/b> Quando si utilizzano criteri come “AllSigned”, assicurati che gli script siano firmati correttamente utilizzando firme digitali valide. In questo modo si evitano falsi errori di “Accesso negato”.<\/span><\/li>\n
            • Fonti affidabili:<\/b> Per i criteri “AllSigned” e “RemoteSigned”, autorizza i publisher degli script importando i loro certificati nell’archivio certificati.<\/span><\/li>\n
            • Sbloccare i file:<\/b> Se un file di script \u00e8 stato scaricato da Internet ed \u00e8 bloccato, sbloccalo utilizzando il cmdlet ‘Unblock-File’.<\/span><\/li>\n
            • Verificare la presenza di problemi relativi al campo di applicazione:<\/b> Tieni presente il campo di applicazione del criterio di esecuzione. In caso di problemi, assicurati che il criterio sia impostato sul livello appropriato per il campo di applicazione.<\/span><\/li>\n
            • Controllare le restrizioni dei criteri di gruppo (group policy):<\/b> Negli ambienti di dominio, i criteri di gruppo possono applicare criteri di esecuzione specifici. Verifica le impostazioni dei criteri di gruppo applicate al sistema e la loro posizione.<\/span><\/li>\n
            • Utilizzare PowerShell remoting<\/b>: In caso di criteri “Restricted” o “AllSigned” che bloccano l’esecuzione locale, utilizza PowerShell remoting per eseguire gli script sui sistemi remoti.<\/span><\/li>\n
            • Controllare il software di sicurezza:<\/b> Alcuni software di sicurezza possono interferire con l’esecuzione degli script. Disattivali temporaneamente o modifica le loro impostazioni per individuare e risolvere il problema.<\/span><\/li>\n
            • Verificare la presenza di conflitti:<\/b> Tieni sempre in considerazione i potenziali conflitti tra le impostazioni locali e quelle dei criteri di gruppo. Assicurati che ci sia coerenza nell’applicazione dei criteri di esecuzione.<\/span><\/li>\n<\/ul>\n

              Come sempre, fare dei tentativi per escludere alcune cause dovrebbe aiutarti a capire la causa di un problema. Se uno script che non veniva eseguito inizia invece a funzionare con diritti elevati, dovrai approfondire la questione dei permessi. Se funziona con un bypass dei criteri, controlla le restrizioni della macchina, e cos\u00ec via. Affrontando questi problemi comuni e seguendo le fasi di troubleshooting descritte sopra, gli amministratori e i professionisti possono gestire efficacemente i criteri di esecuzione di PowerShell, evitando blocchi nell’esecuzione degli script e mantenendo un ambiente di scripting sicuro.<\/span><\/p>\n

              Allineamento alle linee guida di sicurezza dell’organizzazione<\/h2>\n

              L’allineamento dei criteri di esecuzione di Windows PowerShell alle linee guida di sicurezza dell’organizzazione \u00e8 fondamentale per mantenere un ambiente di scripting sicuro e controllato. Spesso le organizzazioni hanno requisiti e criteri di sicurezza specifici che impongono regole sul modo in cui gli script dovranno essere eseguiti. Allineando i criteri di esecuzione a queste linee guida, le organizzazioni possono garantire la coerenza, ridurre i rischi e migliorare la sicurezza generale.<\/span><\/p>\n

              L’importanza degli audit periodici e della revisione dei criteri<\/h3>\n

              Audit e revisioni regolari dei criteri assicurano che i criteri di esecuzione rimangano efficaci e aggiornati. Con l’evolversi delle esigenze organizzative e delle minacce alla sicurezza, i criteri di esecuzione potrebbero dover essere modificati.\u00a0<\/span><\/p>\n

              La conduzione di revisioni periodiche consente alle organizzazioni di:<\/span><\/p>\n

                \n
              • Adattarsi a un panorama di minacce in continua evoluzione:<\/b> Il panorama della sicurezza informatica \u00e8 dinamico. Le revisioni periodiche dei criteri aiutano le organizzazioni a tenere sotto controllo le nuove minacce e ad adeguare i criteri di conseguenza.<\/span><\/li>\n
              • Valutare l’efficacia dei criteri:<\/b> Le organizzazioni possono valutare se gli attuali criteri di esecuzione stanno efficacemente riducendo i rischi o se sono necessarie modifiche.<\/span><\/li>\n
              • Garantire la conformit\u00e0:<\/b> I requisiti di conformit\u00e0 possono cambiare nel tempo. Le revisioni periodiche aiutano a garantire che i criteri di esecuzione siano in linea con gli standard di conformit\u00e0 attuali.<\/span><\/li>\n
              • Identificare i conflitti relativi ai criteri:<\/b> In ambienti complessi, possono verificarsi conflitti relativi ai criteri o effetti collaterali non voluti. Gli audit periodici aiutano a identificare e risolvere questi problemi.<\/span><\/li>\n
              • Mantenere la coerenza:<\/b> Nel corso del tempo, potrebbero essere introdotti nuovi script e utenti. Gli audit aiutano a garantire che i criteri di esecuzione siano applicati in modo coerente in tutta l’organizzazione.<\/span><\/li>\n
              • Ridurre i rischi relativi agli script non autorizzati:<\/b> Le revisioni regolari possono aiutare a identificare e gestire gli script non autorizzati o dannosi che possono essere presenti nella linea di produzione senza essere stati rilevati in precedenza.<\/span><\/li>\n<\/ul>\n

                Con una strategia di criteri di esecuzione ben definita e applicata in modo coerente, le organizzazioni possono sfruttare la potenza dello scripting di PowerShell mantenendo una solida sicurezza.<\/span><\/p>\n

                Criteri di esecuzione di PowerShell: Un pilastro fondamentale della sicurezza del sistema<\/h2>\n

                L’uso ponderato dei criteri di esecuzione di PowerShell \u00e8 un pilastro fondamentale della sicurezza del sistema e dell\u2019amministrazione efficace di Windows. Questi criteri fungono da gatekeeper per l’esecuzione degli script e agiscono come protezioni, per assicurare che solo gli script autorizzati e affidabili vengano eseguiti all’interno di un ambiente. Stabilendo dei limiti all’esecuzione degli script, le organizzazioni possono limitare il potenziale di compromissione dei loro sistemi da parte di codice prodotto da criminali informatici o generato in modo accidentale. La gamma di criteri di esecuzione disponibili, ciascuno progettato per una specifica situazione d’uso nell\u2019ambito della sicurezza, \u00e8 una dimostrazione del livello di controllo granulare che gli amministratori hanno sulle modalit\u00e0 di esecuzione degli script.<\/span><\/p>\n

                I criteri di esecuzione di PowerShell vanno oltre le regole e le impostazioni di configurazione; rappresentano un impegno verso l\u2019ottenimento di operazioni IT coerenti e sicure. Rispettando le best practice dei criteri di esecuzione di PowerShell di cui abbiamo parlato, sarai sulla buona strada per ottenere un ambiente Windows sicuro, efficiente e resiliente.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

                Sviluppato da Microsoft, PowerShell \u00e8 diventato uno standard moderno per l’amministrazione, lo scripting e l’automazione in ambiente Windows. Combinando un’interfaccia a riga di comando con un linguaggio di scripting, PowerShell ha trasformato le modalit\u00e0 di gestione in Windows. Basato sul framework .NET, PowerShell si integra perfettamente con le tecnologie Microsoft utilizzando brevi comandi, o cmdlet, […]<\/p>\n","protected":false},"author":72,"featured_media":141342,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_relevanssi_hide_post":"","_relevanssi_hide_content":"","_relevanssi_pin_for_all":"","_relevanssi_pin_keywords":"","_relevanssi_unpin_keywords":"","_relevanssi_related_keywords":"","_relevanssi_related_include_ids":"","_relevanssi_related_exclude_ids":"","_relevanssi_related_no_append":"","_relevanssi_related_not_related":"","_relevanssi_related_posts":"","_relevanssi_noindex_reason":"","_lmt_disableupdate":"no","_lmt_disable":"","footnotes":""},"categories":[4367,4354,3066],"tags":[],"class_list":["post-200588","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicurezza","category-operazioni-it","category-rmm-it"],"acf":[],"modified_by":"AnaMaria Diaconescu","_links":{"self":[{"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/posts\/200588","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/users\/72"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/comments?post=200588"}],"version-history":[{"count":0,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/posts\/200588\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/media\/141342"}],"wp:attachment":[{"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/media?parent=200588"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/categories?post=200588"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/tags?post=200588"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}