Considerações sobre segurança de JEA

O JEA ajuda a melhorar a sua situação de segurança, reduzindo o número de administradores permanentes em seus computadores. O JEA usa uma configuração de sessão do PowerShell para criar um ponto de entrada para os usuários gerenciarem o sistema. Os usuários que precisam de acesso com privilégios elevados, mas não acesso ilimitado, ao computador para realizar tarefas administrativas podem receber acesso ao ponto de extremidade JEA. Como o JEA permite que esses usuários executem comandos administrativos sem ter acesso total de administrador, você pode remover esses usuários de grupos de segurança altamente privilegiados.

Conta Executar como

Cada ponto de extremidade do JEA tem uma conta executada como designada sob a qual as ações do usuário conectado são executadas. Essa conta é configurável no arquivo de configuração de sessão e a conta que você escolher tem uma influência significativa sobre a segurança de seu ponto de extremidade.

As contas virtuais são a maneira recomendada de configurar a conta Executar como. As contas virtuais são avulsas, temporárias e locais que são criadas para o usuário que está se conectando para ser usada durante a duração de sua sessão JEA. Assim que a sessão é terminada, a conta virtual é destruída e não pode mais ser usada. O usuário que está se conectando não sabe as credenciais da conta virtual. A conta virtual não pode ser usada para acessar o sistema por outros meios, como a Área de Trabalho Remota ou um ponto de extremidade irrestrito do PowerShell.

Por padrão, as contas virtuais são membros do grupo local Administradores no computador. Essa associação lhes dá direitos totais para gerenciar qualquer coisa no sistema, mas nenhum direito para gerenciar recursos na rede. Quando o usuário se conecta a outros computadores a partir da sessão do JEA, o contexto do usuário é o da conta do computador local, não o da conta virtual.

Os controladores de domínio são um caso especial, uma vez que não há um grupo local de administradores. Em vez disso, as contas virtuais pertencem a Administradores de Domínio e podem gerenciar os serviços de diretório no controlador de domínio. A identidade do domínio ainda é restrita para uso no controlador de domínio em que foi criada uma instância da sessão JEA. Qualquer acesso à rede parece ser proveniente do objeto de computador do controlador de domínio.

Em ambos os casos, você pode atribuir a conta virtual a grupos de segurança específicos, especialmente quando a tarefa pode ser realizada sem privilégios de administrador local ou de domínio. Se você já tiver um grupo de segurança definido para seus administradores, conceda a associação da conta virtual a esse grupo. A associação de grupos para contas virtuais é limitada a grupos de segurança locais em estações de trabalho e servidores membros. Em controladores de domínio, as contas virtuais precisam ser membros de grupos de segurança de domínio. Depois que a conta virtual tiver sido adicionada a um ou mais grupos de segurança, ela não pertencerá mais aos grupos padrão (administradores locais ou de domínio).

A seguinte tabela resume as possíveis opções de configuração e as permissões resultantes para as contas virtuais:

Ao examinar a auditoria de segurança e os logs de eventos do aplicativo, você verá que cada sessão de usuário do JEA tem uma conta virtual exclusiva. Essa conta exclusiva ajuda você a acompanhar as ações de usuário em um ponto de extremidade JEA até o usuário original que executou o comando. Os nomes das contas virtuais seguem o formato WinRM Virtual Users\WinRM_VA_<ACCOUNTNUMBER>_<DOMAIN>_<sAMAccountName>. Por exemplo, se o usuário Alice no domínio Contoso reiniciar um serviço em um ponto de extremidade JEA, o nome de usuário associado aos eventos do Gerenciador de Controle de Serviço será WinRM Virtual Users\WinRM_VA_1_contoso_alice.

As GMSAs (contas de serviço gerenciado de grupo) são úteis quando um servidor membro precisa ter acesso aos recursos de rede na sessão JEA. Por exemplo, quando um ponto de extremidade JEA é usado para controlar o acesso a um serviço de API REST hospedado em outro computador. É fácil escrever funções para invocar as APIs REST, mas você precisa de uma identidade de rede para autenticação na API. O uso de uma conta de serviço gerenciado de grupo possibilita o segundo salto, sem perder o controle sobre quais computadores podem usar a conta. Os membros do grupo de segurança (local ou de domínio) da gMSA definiram as permissões efetivas para a conta gMSA.

Quando um ponto de extremidade JEA é configurado para usar uma GMSA, as ações de todos os usuários JEA parecem vir da mesma GMSA. A única maneira de rastrear as ações até um usuário específico é identificar o conjunto de comandos executados em uma transcrição de sessão do PowerShell.

As credenciais de passagem são usadas quando você não especifica uma conta executar como. O PowerShell usa a credencial do usuário que está se conectando para executar comandos no servidor remoto. Para usar credenciais de passagem, é necessário conceder ao usuário conectado acesso direto a grupos de gerenciamento privilegiados. Essa configuração NÃO é recomendada para o JEA. Se o usuário conectado já tiver privilégios de administrador, ele poderá ignorar o JEA e gerenciar o sistema usando outros métodos de acesso.

As contas padrão Executar como permitem especificar qualquer conta de usuário na qual toda a sessão do PowerShell é executada. As configurações de sessão que usam contas fixas Executar como (com o parâmetro -RunAsCredential) não reconhecem o JEA. As definições de função deixarão de funcionar conforme o esperado. A mesma função é atribuída a todos os usuários autorizados a acessar o ponto de extremidade.

Você não deve usar uma RunAsCredential em um ponto de extremidade JEA, devido ao fato de ser difícil rastrear as ações até usuários específicos e não haver suporte para ela no mapeamento de usuários às funções.

ACL do Ponto de Extremidade do WinRM

Assim como acontece com pontos de extremidade regulares de comunicação remota do PowerShell, cada ponto de extremidade JEA tem uma ACL (lista de controle de acesso) separada que controla quem pode se autenticar no ponto de extremidade JEA. Se configurado incorretamente, os usuários confiáveis podem não conseguir acessar o ponto de extremidade do JEA e os usuários não confiáveis podem ter acesso. A ACL do WinRM não afeta o mapeamento de usuários às funções JEA. O mapeamento é controlado pelo campo RoleDefinitions no arquivo de configuração de sessão usado para registrar o ponto de extremidade.

Por padrão, quando um ponto de extremidade JEA tem várias capacidades de função, a ACL do WinRM é configurada para permitir o acesso a todos os usuários mapeados. Por exemplo, uma sessão JEA configurada que usa os comandos a seguir permite acesso completo a CONTOSO\JEA_Lev1 e CONTOSO\JEA_Lev2.

$roles = @{ 'CONTOSO\JEA_Lev1' = 'Lev1Role'; 'CONTOSO\JEA_Lev2' = 'Lev2Role' }
New-PSSessionConfigurationFile -Path '.\jea.pssc' -SessionType RestrictedRemoteServer -RoleDefinitions $roles -RunAsVirtualAccount
Register-PSSessionConfiguration -Path '.\jea.pssc' -Name 'MyJEAEndpoint'

Você pode auditar as permissões de usuário com o cmdlet Get-PSSessionConfiguration.

Get-PSSessionConfiguration -Name 'MyJEAEndpoint' | Select-Object Permission

Permission
----------
CONTOSO\JEA_Lev1 AccessAllowed
CONTOSO\JEA_Lev2 AccessAllowed

Para alterar quais usuários têm acesso, execute Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -ShowSecurityDescriptorUI para um prompt interativo ou Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> para atualizar as permissões. Os usuários precisam, pelo menos, de direitos de Invocar para acessar o ponto de extremidade JEA.

É possível criar um ponto de extremidade JEA que não mapeia uma função definida para cada usuário que tem acesso. Esses usuários podem iniciar uma sessão JEA, mas só têm acesso aos cmdlets padrão. Você pode auditar as permissões de usuário em um ponto de extremidade JEA executando o Get-PSSessionCapability. Para obter mais informações, confira Auditoria e relatórios no JEA.

Funções de privilégio mínimo

Durante a criação de funções JEA, é importante lembrar que as contas virtuais e as contas de serviço gerenciado de grupo executadas em segundo plano têm acesso irrestrito ao computador local. As capacidades de função JEA ajudam a limitar os comandos e os aplicativos que podem ser executados nesse contexto privilegiado. As funções projetadas de modo inadequado podem permitir comandos perigosos que, por sua vez, podem permitir que um usuário ultrapasse os limites do JEA ou obtenha acesso a informações confidenciais.

Por exemplo, considere a seguinte entrada de capacidade de função:

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\*-Process'
}

Essa capacidade de função permite que os usuários executem cmdlets do PowerShell com o substantivo Process do módulo Microsoft.PowerShell.Management. Os usuários podem precisar acessar cmdlets como Get-Process para ver quais aplicativos estão sendo executados no sistema e Stop-Process para encerrar os aplicativos que não esteja respondendo. No entanto, essa entrada também permite o Start-Process, que pode ser usado para iniciar um programa arbitrário com permissões de administrador completas. O programa não precisa ser instalado localmente no sistema. Um usuário conectado pode iniciar um programa a partir de um compartilhamento de arquivos que lhe conceda privilégios de administrador local, execute malware e muito mais.

Uma versão muito mais segura desse mesma capacidade de função seria:

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\Get-Process',
                     'Microsoft.PowerShell.Management\Stop-Process'
}

Evite usar curingas em capacidades de função. Certifique-se de auditar regularmente as permissões efetivas do usuário para ver quais comandos estão acessíveis a um usuário. Para obter mais informações, consulte a seção Verificar direitos efetivos do artigo Auditoria e relatórios sobre o JEA.

Recomendações de melhores práticas

Veja a seguir as recomendações de práticas recomendadas para garantir a segurança de seus ponto de extremidades do JEA:

Limite o uso e os recursos de provedores do PowerShell

Revise como os provedores permitidos são usados para garantir que você não crie vulnerabilidades em sua sessão configurada.

Não permita comandos que possam criar novos espaços de execução.

Não permita o cmdlet Trace-Command.

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.

O JEA não oferece proteção contra administradores

Um dos princípios fundamentais do JEA é que ele permite que não administradores realizem algumas tarefas administrativas. O JEA não oferece proteção contra os usuários que já têm privilégios de administrador. Os usuários que pertencem a Administradores de domínio, Administradores locais ou outros grupos altamente privilegiados podem contornar as proteções do JEA de outras maneiras. Por exemplo, eles podem entrar com o RDP, usar consoles remotos do MMC ou se conectar aos pontos de extremidade irrestritos do PowerShell. Além disso, o administrador local de um sistema pode modificar as configurações do JEA para adicionar mais usuários ou alterar um recurso de função para ampliar o escopo do que um usuário pode fazer em sua sessão do JEA. É importante avaliar as permissões estendidas dos usuários JEA para ver se existem outras maneiras de obter acesso privilegiado ao sistema.

Além de usar o JEA para manutenção diária regular, é comum ter um sistema de gerenciamento de acesso privilegiado just-in-time. Esses sistemas permitem que os usuários designados se tornem temporariamente um administrador local somente depois de concluírem um fluxo de trabalho que documente o uso dessas permissões.