Protezione di una sessione remota di PowerShell con restrizioni

Esistono scenari in cui si vuole ospitare una sessione di PowerShell che, per motivi di sicurezza, è stata limitata a un subset di comandi di PowerShell.

Per definizione, una sessione con restrizioni è una sessione in cui Import-Module non è consentito l'uso. Potrebbero esserci altre limitazioni, ma questo è il requisito principale. Se l'utente può importare un modulo, può eseguire qualsiasi elemento desiderato.

Esempi di sessioni con restrizioni includono:

• Just-Enough-Administration (JEA)
• Implementazioni di comunicazione remota con restrizioni personalizzate, ad esempio i moduli di Exchange e Teams

Per la maggior parte degli amministratori di sistema, JEA offre la migliore esperienza per la creazione di sessioni con restrizioni e deve essere la prima scelta. Per altre informazioni su JEA, vedere la panoramica di JEA.

Raccomandazioni per le implementazioni di sessione personalizzate

Se lo scenario richiede un'implementazione personalizzata, è necessario seguire queste raccomandazioni.

Limitare l'uso e le funzionalità dei provider di PowerShell

Esaminare il modo in cui vengono usati i provider consentiti per assicurarsi di non creare vulnerabilità nell'implementazione della sessione con restrizioni.

Avvertimento

Non consentire il provider FileSystem . Se gli utenti possono scrivere in qualsiasi parte del file system, è possibile ignorare completamente la sicurezza.

Non autorizzare il provider di certificato. Con il provider abilitato, un utente potrebbe ottenere l'accesso alle chiavi private archiviate.

Non consentire comandi in grado di creare nuovi spazi di esecuzione

Avvertimento

I *-Job cmdlet possono creare nuovi spazi di esecuzione senza restrizioni.

Non consentire questo Trace-Command cmdlet.

Avvertimento

L'uso di Trace-Command porta tutti i comandi tracciati nella sessione.

Non creare implementazioni proxy personalizzate per i comandi con restrizioni

PowerShell include un set di comandi proxy per scenari di comandi con restrizioni. Questi comandi proxy assicurano che i parametri di input non possano compromettere la sicurezza della sessione. I comandi seguenti hanno proxy con restrizioni:

• Exit-PSSession
• Get-Command
• Get-FormatData
• Get-Help
• Measure-Object
• Out-Default
• Select-Object

Se si crea una propria implementazione di questi comandi, è possibile consentire inavvertitamente agli utenti di eseguire codice vietato dai comandi proxy JEA.

È possibile eseguire il comando seguente per ottenere un elenco di comandi con restrizioni:

$commands = [System.Management.Automation.CommandMetadata]::GetRestrictedCommands(
    [System.Management.Automation.SessionCapabilities]::RemoteServer
)

È possibile esaminare i comandi proxy con restrizioni usando il comando seguente:

$commands = [System.Management.Automation.CommandMetadata]::GetRestrictedCommands(
    [System.Management.Automation.SessionCapabilities]::RemoteServer
)
$getHelpProxyBlock = [System.Management.Automation.ProxyCommand]::Create($commands['Get-Help'])

Configurare la sessione per l'uso della modalità NoLanguage

La modalità PowerShell NoLanguage disabilita completamente il linguaggio di scripting di PowerShell. Non è possibile eseguire script o usare variabili. È possibile eseguire solo comandi e cmdlet nativi.

Per altre informazioni sulle modalità del linguaggio, vedere about_Language_Modes.

Non consentire l'uso del debugger nella sessione

Per impostazione predefinita, il debugger di PowerShell esegue il codice in FullLanguage modalità . Impostare la proprietà UseFullLanguageModeInDebugger in SessionState su false.

Per altre informazioni, vedere UseFullLanguageModeInDebugger.