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:

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 for Business é o sistema de controle de aplicativos preferido para Windows. Para mais informações sobre como o PowerShell suporta o AppLocker e o App Control for Business, consulte Use App Control to secure PowerShell.

O AppLocker é um sistema de controlo de aplicações legado que ainda é suportado no Windows 11. O AppLocker não é uma funcionalidade de segurança segundo os critérios de manutenção definidos pela MSRC. Para mais informações sobre critérios de manutenção, consulte Microsoft Security Servicing Criteria for Windows.

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.

Importante

Sem o modo System Lockdown, o modo de linguagem não se propaga entre espaços de execução. Cada espaço de execução consulta independentemente a política de controlo da aplicação Windows para determinar o seu modo de linguagem. Definir o modo de linguagem num espaço de execução não afeta outros espaços de execução. Sem uma política ativa de controlo de aplicações, os novos espaços de execução passam por padrão ao FullLanguage modo.

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.

Importante

Você deve usar uma camada de transporte segura para garantir a transferência segura de dados por PSRP.

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

Uma fronteira de segurança fornece uma separação lógica entre o código e os dados de domínios de segurança com diferentes níveis de confiança. As características de segurança baseiam-se nos limites de segurança para proporcionar proteção robusta contra ameaças específicas. Para as funcionalidades de segurança desta categoria, a Microsoft pretende abordar vulnerabilidades reportadas através da manutenção.

Características de segurança do PowerShell

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

Para mais informações, consulte a documentação Microsoft Security Servicing Criteria for Windows.

Em alguns casos, uma funcionalidade de segurança pode fornecer proteção contra uma ameaça sem poder proporcionar uma defesa robusta. Estas características de segurança são normalmente designadas como funcionalidades de defesa em profundidade ou mitigações porque proporcionam segurança adicional, mas podem ter limitações por design que as impedem de mitigar totalmente uma ameaça. Um bypass para uma funcionalidade de segurança de defesa em profundidade, por si só, não representa um risco direto porque um atacante deve também ter encontrado uma vulnerabilidade que afete uma fronteira de segurança, ou deve recorrer a técnicas adicionais, como engenharia social, para alcançar a fase inicial de um compromisso de dispositivo.

Funcionalidades de defesa em profundidade do PowerShell

  • Modo de idioma restrito com o AppLocker ou configurado através da configuração da sessão ou ao definir manualmente $ExecutionContext.SessionState.LanguageMode
  • Bloqueio do sistema com AppLocker
  • Política de Execução
  • Last updated on