Funcionalidades de segurança do PowerShell

O PowerShell tem vários recursos projetados para melhorar a segurança do seu ambiente de script.

Política de execução

A política de execução do PowerShell é um recurso de segurança que controla as condições sob as quais o PowerShell carrega arquivos de configuração e executa scripts. Esse recurso ajuda a impedir a execução de scripts mal-intencionados. Você pode usar uma configuração de Diretiva de Grupo para definir diretivas de execução para computadores e usuários. As políticas de execução aplicam-se apenas à plataforma Windows.

Para obter mais informações, consulte about_Execution_Policies.

Uso da classe SecureString

O PowerShell tem vários cmdlets que dão suporte ao uso da System.Security.SecureString classe. E, como com qualquer classe .NET, você pode usar SecureString em seus próprios scripts. No entanto, a Microsoft não recomenda o uso do SecureString para novos desenvolvimentos. A Microsoft recomenda que você evite usar senhas e confie em outros meios para autenticar, como certificados ou autenticação do Windows.

O PowerShell continua a oferecer suporte à classe SecureString para compatibilidade com versões anteriores. Usar um SecureString ainda é mais seguro do que usar uma cadeia de caracteres de texto simples. O PowerShell ainda depende do tipo SecureString para evitar a exposição acidental do conteúdo ao console ou em logs. Use o SecureString com cuidado, porque ele pode ser facilmente convertido em uma cadeia de texto simples. Para obter uma discussão completa sobre como usar SecureString, consulte a documentação da classe System.Security.SecureString.

Registo de módulos e de blocos de scripts

O registo de módulos permite ativar o registo para os módulos do PowerShell selecionados. Essa configuração é efetiva em todas as sessões no computador. O PowerShell registra eventos de execução de pipeline para os módulos especificados no log de eventos do Windows PowerShell.

O registo em log de blocos de script permite registar o processamento de comandos, blocos de script, funções e scripts, quer sejam invocados interativamente, quer através de automatização. O PowerShell regista estas informações no registo de eventos Microsoft-Windows-PowerShell/Operational.

Para obter mais informações, consulte os seguintes artigos:

• sobre_Configurações_de_Política_de_Grupo
• sobre_Logging_Windows
• sobre_registo_Non-Windows

Suporte AMSI

A Interface de Verificação Antimalware do Windows (AMSI) é uma API que permite que os aplicativos passem ações para um scanner antimalware, como o Windows Defender, para verificar cargas maliciosas. A partir do PowerShell 5.1, o PowerShell em execução no Windows 10 (e superior) passa todos os blocos de script para o AMSI.

O PowerShell 7.3 estende os dados que envia à AMSI para inspeção. Ele agora inclui todas as invocações do método .NET.

Para obter mais informações sobre o AMSI, consulte Como o AMSI ajuda.

Modo de linguagem restrita

O modo ConstrainedLanguage protege seu sistema limitando os cmdlets e os tipos .NET permitidos em uma sessão do PowerShell. Para obter uma descrição completa, consulte about_Language_Modes.

Controlo de Aplicação

O Windows 10 inclui duas tecnologias, o App Control for Business e o AppLocker que você pode usar para controlar aplicativos. O PowerShell deteta se uma política de controle de aplicativo em todo o sistema está sendo imposta. A política aplica determinados comportamentos ao executar blocos de script, arquivos de script ou carregar arquivos de módulo para evitar a execução arbitrária de código no sistema.

O Controle de Aplicativo para Empresas foi projetado como um recurso de segurança de acordo com os critérios de manutenção definidos pelo Centro de Resposta de Segurança da Microsoft (MSRC). O App Control é o sistema de controle de aplicativos preferido para Windows.

Para obter mais informações sobre como o PowerShell oferece suporte ao AppLocker e ao Controle de Aplicativo, consulte Usar o Controle de Aplicativo para proteger o PowerShell.

Modo de Bloqueio do Sistema

No PowerShell, o modo System Lockdown é uma abstração da política de controlo de aplicações a nível do sistema imposta pelo Windows através do App Control for Business ou do AppLocker. Quando uma política de controlo de aplicação está ativa, o PowerShell entra em modo de Bloqueio do Sistema. No modo System Lockdown, a política de controlo da aplicação determina o modo de linguagem para cada espaço de execução.

Lista de materiais de software (SBOM)

A partir do PowerShell 7.2, todos os pacotes de instalação contêm uma Lista de Materiais de Software (SBOM). A equipa do PowerShell também produz SBOMs para módulos pelos quais é responsável, mas que são distribuídos de forma independente do PowerShell.

Você pode encontrar arquivos SBOM nos seguintes locais:

• No PowerShell, localize a SBOM em $PSHOME/_manifest/spdx_2.2/manifest.spdx.json.
• Para módulos, localize o SBOM na pasta do módulo em _manifest/spdx_2.2/manifest.spdx.json.

A criação e publicação do SBOM é o primeiro passo para modernizar a segurança cibernética do Governo Federal e melhorar a segurança da cadeia de suprimentos de software. Para obter mais informações sobre essa iniciativa, consulte a postagem do blog Gerando SBOMs com SPDX na Microsoft.

Transferência segura de dados na gestão remota do PowerShell

Antes do PowerShell v7.6-preview5, um Session_Key é usado para criptografar um SecureString antes de enviá-lo para uma sessão remota do PowerShell. O protocolo PSRP (PowerShell Remoting Protocol) executa uma troca de chaves entre cliente e servidor quando um SecureString objeto precisa ser transferido. O intercâmbio envolve as seguintes etapas:

1. O lado do cliente gera um par de chaves pública/privada e envia a chave pública para o servidor.
2. O servidor gera uma chave de sessão para encriptação simétrica.
3. O servidor usa a chave pública para criptografar a chave de sessão e envia-a para o cliente.
4. O cliente e o servidor usam a nova chave de sessão para criptografar um objeto SecureString .

O protocolo PSRP (PowerShell Remoting Protocol) usa o RSAEncryptionPadding.Pkcs1 algoritmo durante a troca de chaves. O algoritmo NÃO é seguro, por isso a troca de chaves não fornece qualquer segurança extra.

A partir do PowerShell v7.6-preview.5, a troca de chaves foi preterida. A versão do PSRP foi incrementada para v2.4 e inclui as seguintes alterações:

• As seguintes mensagens PSRP são preteridas quando o cliente e o servidor são v2.4 ou superiores:

  • PUBLIC_KEY
  • PUBLIC_KEY_REQUEST
  • ENCRYPTED_SESSION_KEY

• As etapas de encriptação e desencriptação para SecureString são ignoradas quando o cliente e o servidor estiverem ambos na versão v2.4 ou superior.

Esta alteração é compatível com versões anteriores.

• Para clientes ou servidores antigos (v2.3 ou inferior), a troca de chaves ainda é usada quando necessário.
• O PSRP pode usar sessões remotas através de um pipe com nome quando o cliente e o servidor estão na mesma máquina. Como é possível que um cliente remoto se conecte ao pipe nomeado e os dados não são mais criptografados com uma chave de sessão, o pipe nomeado (usado para Enter-PSHostProcess) rejeita o cliente remoto.

Critérios de manutenção de segurança

O PowerShell segue os Critérios de Serviço de Segurança da Microsoft para Windows. Apenas os elementos de segurança cumprem os critérios de manutenção.

Funcionalidades de segurança

• Bloqueio do Sistema com Controlo de Aplicações para Empresas
• Modo de linguagem restrita com o Controlo de Aplicações para Empresas

Funcionalidades de defesa em profundidade

• Bloqueio do sistema com AppLocker
• Modo de idioma restrito com o AppLocker
• Política de Execução