Proteger uma sessão de comunicação remota restrita do PowerShell

Há cenários em que você deseja hospedar uma sessão do PowerShell que, por motivos de segurança, foi limitada a um subconjunto de comandos do PowerShell.

Por definição, uma sessão restrita é aquela em que não é permitido usar Import-Module. Pode haver outras limitações, mas esse é o requisito principal. Se o usuário puder importar um módulo, ele poderá executar o que quiser.

Exemplos de sessões restritas incluem:

• Just-Enough-Administration (JEA)
• Implementações de comunicação remota restrita personalizadas, como os módulos do Exchange e do Teams

Para a maioria dos administradores do sistema, o JEA fornece a melhor experiência para criar sessões restritas e deve ser sua primeira opção. Para obter mais informações sobre JEA, consulte a visão geral do JEA.

Recomendações para implementações de sessão personalizadas

Se o cenário exigir uma implementação personalizada, você deverá seguir essas recomendações.

Limitar o uso e os recursos de provedores do PowerShell

Examine como os provedores permitidos são usados para garantir que você não crie vulnerabilidades em sua implementação de sessão restrita.

Aviso

Não permita o provedor FileSystem . Se os usuários puderem gravar em qualquer parte do sistema de arquivos, será possível ignorar completamente a segurança.

Não permita o provedor de certificados. Com o provedor habilitado, um usuário pode obter acesso a chaves privadas armazenadas.

Não permitir comandos que possam criar novos runspaces

Aviso

O recurso de compatibilidade do Windows no PowerShell 7 cria um novo runspace para hospedar o Windows PowerShell. Não permita comandos que seriam executados por meio do recurso de compatibilidade do Windows. Os *-Job cmdlets podem criar novos runspaces sem as restrições.

Não permita o Trace-Command cmdlet.

Aviso

O uso de Trace-Command traz todos os comandos rastreados para a sessão.

Não crie suas próprias implementações de proxy para os comandos restritos

O PowerShell tem um conjunto de comandos de proxy para cenários de comando restrito. Esses comandos de proxy garantem que os parâmetros de entrada não possam comprometer a segurança da sessão. Os seguintes comandos têm proxies restritos:

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

Se você criar sua própria implementação desses comandos, poderá inadvertidamente permitir que os usuários executem código proibido pelos comandos de proxy JEA.

Você pode executar o seguinte comando para obter uma lista de comandos restritos:

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

Você pode examinar os comandos de proxy restritos usando o seguinte comando:

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

Configurar a sessão para usar o modo NoLanguage

O modo PowerShell NoLanguage desabilita completamente a linguagem de script do PowerShell. Você não pode executar scripts ou usar variáveis. Você só pode executar comandos e cmdlets nativos.

Para obter mais informações sobre modos de linguagem, consulte about_Language_Modes.

Não permita que o depurador seja usado na sessão

Por padrão, o depurador do PowerShell executa o código no FullLanguage modo. Defina a propriedade UseFullLanguageModeInDebugger no SessionState como false.

Para obter mais informações, consulte UseFullLanguageModeInDebugger.