Compartilhar via

Recursos de segurança do PowerShell

O PowerShell tem vários recursos projetados para aprimorar 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 Política de Grupo para definir políticas de execução para computadores e usuários. As políticas de execução aplicam-se somente à plataforma Windows.

Para obter mais informações, consulte o item sobre Políticas de Execução.

Uso da classe SecureString

O PowerShell tem vários cmdlets que dão suporte ao uso da classe System.Security.SecureString. Como é o caso de qualquer classe .NET, é possível usar SecureString em seus próprios scripts. No entanto, a Microsoft não recomenda usar SecureString para novos desenvolvimentos. A Microsoft recomenda evitar o uso de senhas e confiar em outros meios de autenticação, como certificados ou a autenticação do Windows.

O PowerShell continua a dar suporte à classe SecureString para compatibilidade com versões anteriores. Usar a classe SecureString ainda é mais seguro do que usar uma cadeia de texto sem formatação. O PowerShell ainda depende do tipo SecureString para evitar expor acidentalmente o conteúdo ao console ou nos logs. Use SecureString com cuidado, pois ele pode ser facilmente convertido em uma cadeia de caracteres de texto sem formatação. Para saber detalhes completos sobre como usar a SecureString, consulte a documentação da classe System.Security.SecureString.

Registro em log de blocos de módulo e script

O log do módulo permite habilitar o registro em log para módulos do PowerShell selecionados. Essa configuração é eficaz 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 Registro em Log de Blocos de Script permite o registro em log do processamento de comandos, blocos de script, funções e scripts, seja ele invocado interativamente ou por meio de automação. O PowerShell registra essas informações no log de eventos do Microsoft-Windows-PowerShell/Operational.

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

Suporte à AMSI

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

O PowerShell 7.3 estende os dados enviados ao AMSI para inspeção. Agora ele inclui todas as invocações de método .NET.

Para mais informações sobre a AMSI, confira Como a AMSI ajuda.

Modo de linguagem restrita

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

Controle do aplicativo

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

O Controle de Aplicativos 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 dá suporte ao AppLocker e ao Controle de Aplicativos, consulte Usar o Controle de Aplicativos para proteger o PowerShell.

SBOM (lista de materiais de software)

Do PowerShell 7.2 em diante, todos os pacotes de instalação contêm uma SBOM (lista de materiais de software). A equipe de PowerShell também produz SBOMs para os módulos que ela tem, mas que são fornecidos separadamente do PowerShell.

É possível encontrar o arquivos de SBOM nos seguintes locais:

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

A criação e a publicação da SBOM é a primeira etapa para modernizar a segurança cibernética do Governo Federal e para aprimorar a segurança da cadeia de fornecedores de software. Para obter mais informações sobre essa iniciativa, confira a postagem no blog Geração de SBOMs com SPDX na Microsoft.

Segurança da transferência de dados na remotização do PowerShell

Antes do PowerShell v7.6-preview5, um Session_Key é usado para criptografar um SecureString antes de enviá-lo a uma sessão remota do PowerShell. O Protocolo de Comunicação Remota do PowerShell (PSRP) executa uma troca de chaves entre o cliente e o servidor quando um SecureString objeto precisa ser transferido. A troca 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 criptografia simétrica.
  3. O servidor usa a chave pública para criptografar a chave de sessão e as envia ao cliente.
  4. O cliente e o servidor usam a nova chave de sessão para criptografar um objeto SecureString .

O Protocolo de Comunicação Remota do PowerShell (PSRP) usa o RSAEncryptionPadding.Pkcs1 algoritmo durante a troca de chaves. O algoritmo NÃO é seguro, portanto, a troca de chaves não fornece nenhuma 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
    • SOLICITAÇÃO_DE_CHAVE_PÚBLICA
    • ENCRYPTED_SESSION_KEY

  • As etapas de criptografia e descriptografia são SecureString ignoradas quando o cliente e o servidor estão na versão v2.4 ou versões superiores.

Esta alteração é retrocompatível.

  • 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 nomeadas quando o cliente e o servidor estiverem no mesmo computador. Como é possível que um cliente remoto se conecte ao pipe nomeado e os dados não sejam 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 da manutenção de segurança da Microsoft no Windows. Somente os recursos de segurança atendem aos critérios de manutenção.

Recursos de segurança

  • Bloqueio do sistema com o App Control for Business
  • Modo de idioma restrito com o Controle de Aplicativos para Empresas

Recursos de defesa em profundidade

  • Bloqueio do sistema com AppLocker
  • Modo de linguagem restrita com AppLocker
  • Política de execução
  • Last updated on