Condividi tramite

Funzionalità di sicurezza di PowerShell

PowerShell offre diverse funzionalità progettate per migliorare la sicurezza dell'ambiente di scripting.

Criterio di esecuzione

Suggerimenti: i criteri di esecuzione di PowerShell sono una funzionalità di sicurezza che controlla le condizioni in cui PowerShell carica i file di configurazione ed esegue gli script Questa funzionalità aiuta a prevenire l'esecuzione di script dannosi. È possibile usare un'impostazione di Criteri di gruppo per impostare i criteri di esecuzione per computer e utenti. I criteri di esecuzione si applicano solo alla piattaforma Windows.

Per altre informazioni, vedere about_Execution_Policies.

Uso della classe SecureString

PowerShell include diversi cmdlet che supportano l'uso della System.Security.SecureString classe . Inoltre, come con qualsiasi classe .NET, è possibile usare SecureString negli script personalizzati. Tuttavia, Microsoft non consiglia di usare SecureString per un nuovo sviluppo. Microsoft consiglia di evitare di usare le password e di basarsi su altri mezzi per l'autenticazione, ad esempio certificati o autenticazione di Windows.

PowerShell continua a supportare la classe SecureString per la compatibilità con le versioni precedenti. L'uso di secureString è ancora più sicuro rispetto all'uso di una stringa di testo normale. PowerShell si basa ancora sul tipo SecureString per evitare di esporre accidentalmente il contenuto alla console o nei log. Usare SecureString con attenzione, perché può essere facilmente convertito in una stringa di testo normale. Per una discussione completa sull'uso di SecureString, vedere la documentazione della classe System.Security.SecureString.

Registrazione del blocco di moduli e script

La registrazione dei moduli consente di abilitare la registrazione per i moduli di PowerShell selezionati. Questa impostazione è efficace in tutte le sessioni del computer. PowerShell registra gli eventi di esecuzione della pipeline per i moduli specificati nel registro eventi di Windows PowerShell.

La registrazione blocchi di script consente la registrazione per l'elaborazione di comandi, blocchi di script, funzioni e script, sia che richiamati in modo interattivo o tramite l'automazione. PowerShell registra queste informazioni nel registro eventi Microsoft-Windows-PowerShell/Operational .

Per altre informazioni, vedere gli articoli seguenti:

Supporto AMSI

Windows Antimalware Scan Interface (AMSI) è un'API che consente alle applicazioni di passare azioni a uno scanner antimalware, ad esempio Windows Defender, per cercare payload dannosi. A partire da PowerShell 5.1, PowerShell in esecuzione in Windows 10 (e versioni successive) passa tutti i blocchi di script ad AMSI.

PowerShell 7.3 estende i dati inviati ad AMSI per l'ispezione. Include ora tutte le chiamate al metodo .NET.

Per altre informazioni su AMSI, vedere How AMSI helps(Come AMSI aiuta).

Modalità del linguaggio vincolato

La modalità ConstrainedLanguage protegge il sistema limitando i cmdlet e i tipi .NET consentiti in una sessione di PowerShell. Per una descrizione completa, vedere about_Language_Modes.

Controllo applicazione

Windows 10 include due tecnologie, Controllo app per le aziende e AppLocker che puoi usare per controllare le applicazioni. PowerShell rileva se vengono applicati criteri di controllo delle applicazioni a livello di sistema. Il criterio applica determinati comportamenti durante l'esecuzione di blocchi di script, file di script o caricamento di file di modulo per impedire l'esecuzione arbitraria del codice nel sistema.

Controllo app per le aziende è progettato come funzionalità di sicurezza in base ai criteri di manutenzione definiti da Microsoft Security Response Center (MSRC). Controllo app è il sistema di controllo delle applicazioni preferito per Windows.

Per altre informazioni su come PowerShell supporta AppLocker e Controllo app, vedere Usare Controllo app per proteggere PowerShell.

Software Distinta base (Bill of Materials - SBOM)

A partire da PowerShell 7.2, tutti i pacchetti di installazione contengono una distinta software (SBOM). Il team di PowerShell produce anche SBOMs per i moduli di cui sono proprietari ma vengono forniti in modo indipendente da PowerShell.

È possibile trovare i file SBOM nei percorsi seguenti:

  • In PowerShell trovare SBOM in $PSHOME/_manifest/spdx_2.2/manifest.spdx.json.
  • Per i moduli, trovare sbom nella cartella del modulo in _manifest/spdx_2.2/manifest.spdx.json.

La creazione e la pubblicazione di SBOM è il primo passo per modernizzare la cybersecurity del Governo federale e migliorare la sicurezza della supply chain del software. Per altre informazioni su questa iniziativa, vedere il post di blog Generazione di SBOMs con SPDX in Microsoft.

Proteggere il trasferimento dati nel remoting di PowerShell

Prima di PowerShell v7.6-preview5, viene utilizzato un Session_Key per crittografare un SecureString prima di inviarlo in una sessione remota di PowerShell. Il PowerShell Remoting Protocol (PSRP) esegue uno scambio di chiavi tra client e server quando è necessario trasferire un SecureString oggetto. Lo scambio prevede i passaggi seguenti:

  1. Il lato client genera una coppia di chiavi pubblica/privata e invia la chiave pubblica al server.
  2. Il server genera una chiave di sessione per la crittografia simmetrica.
  3. Il server usa la chiave pubblica per crittografare la chiave di sessione e inviarla al client.
  4. Sia il client che il server usano la nuova chiave di sessione per crittografare un oggetto SecureString .

Il protocollo PSRP (Remoting Protocol) di PowerShell usa l'algoritmo RSAEncryptionPadding.Pkcs1 durante lo scambio di chiavi. L'algoritmo non è sicuro, quindi lo scambio di chiavi non fornisce alcuna sicurezza aggiuntiva.

Importante

È necessario usare un livello di trasporto sicuro per garantire il trasferimento sicuro dei dati tramite PSRP.

A partire da PowerShell v7.6-preview.5, lo scambio di chiavi è stato deprecato. La versione di PSRP è stata incrementata alla versione 2.4 e include le modifiche seguenti:

  • I messaggi PSRP seguenti sono deprecati quando sia il client che il server sono v2.4 o versione successiva:

    • Chiave pubblica
    • RICHIESTA_DI_CHIAVE_PUBBLICA
    • CHIAVE_DI_SESSIONE_CRIPTATA

  • I passaggi di crittografia e decrittografia per SecureString vengono ignorati quando sia il client che il server sono v2.4 o versione successiva.

Questa modifica è compatibile con le versioni precedenti.

  • Per i server o i client meno recenti (versione 2.3 o inferiore), lo scambio di chiavi viene comunque usato quando necessario.
  • Le sessioni remote tramite named pipe possono essere utilizzate da PSRP quando sia il client che il server si trovano nello stesso computer. Poiché è possibile che un client remoto si connetta a named pipe e i dati non siano più crittografati con una chiave di sessione, la named pipe (usata per Enter-PSHostProcess) rifiuta il client remoto.

Criteri di manutenzione della sicurezza

PowerShell segue i criteri Microsoft Security Servicing Criteria for Windows (Criteri di manutenzione della sicurezza Microsoft per Windows). Solo le funzionalità di sicurezza soddisfano i criteri per la manutenzione.

Funzionalità di sicurezza

  • Blocco di sistema con Controllo app per le aziende
  • Modalità del linguaggio vincolata con Controllo app per le aziende

Funzionalità di difesa avanzata

  • Blocco di sistema con AppLocker
  • Modalità del linguaggio vincolato con AppLocker
  • Criteri di esecuzione
  • Last updated on