Partilhar via

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.

Registro de blocos de módulo e script

O Registro em Log de Módulos permite habilitar o registro em log para 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 Log de Blocos de Scripts permite o registro em log para o processamento de comandos, blocos de script, funções e scripts - sejam eles invocados interativamente ou por meio de automação. O PowerShell registra essas informações no log de eventos Microsoft-Windows-PowerShell /Operation .

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 Microsoft Security Response Center (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.

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 equipe do PowerShell também produz SBOMs para módulos que eles possuem, mas são fornecidos independentemente 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 comunicaçã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 criptografia e descriptografia são SecureString ignoradas quando o cliente e o servidor são v2.4 ou superiores.

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 de pipe nomeado 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 controle de aplicativo para empresas
  • Modo de idioma restrito com o Controle de Aplicativo para Empresas

Características de defesa em profundidade

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