Compartilhar via

Considerações sobre segurança do JEA

O JEA ajuda você a melhorar sua postura 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 novo ponto de entrada para os usuários gerenciarem o sistema. Os usuários que precisam de acesso elevado, mas não ilimitado, ao computador para realizar tarefas administrativas podem ter acesso ao endpoint JEA. Como o JEA permite que esses usuários executem comandos administrativos sem ter acesso total ao administrador, você pode remover esses usuários de grupos de segurança altamente privilegiados.

Run-As conta

Cada endpoint JEA tem uma conta run-as designada na 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 escolhida tem uma influência significativa na segurança do ponto de extremidade.

As contas virtuais são a maneira recomendada de configurar a conta de execução como. As contas virtuais são contas locais temporárias e únicas, criadas para o usuário conectado usar pelo período de sua sessão JEA. Assim que a sessão for encerrada, a conta virtual será destruída e não poderá mais ser usada. O usuário que se conecta não sabe as credenciais da conta virtual. A conta virtual não pode ser usada para acessar o sistema por outros meios, como Área de Trabalho Remota ou um ponto de extremidade não restrito do PowerShell.

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

Os controladores de domínio são um caso especial, pois não há um grupo de Administradores local. Em vez disso, as contas virtuais pertencem aos Administradores de Domínio e podem gerenciar os serviços de diretório no controlador de domínio. A identidade de domínio ainda é restrita para uso no controlador de domínio em que a sessão JEA foi instanciada. Qualquer acesso à rede parece vir 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 feita 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 de conta virtual a esse grupo. A associação de grupo para contas virtuais é limitada a grupos de segurança locais em servidores membros e de estação de trabalho. Em controladores de domínio, as contas virtuais devem 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 pertence mais aos grupos padrão (administradores locais ou de domínio).

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

Tipo de computador Configuração do grupo de contas virtuais Contexto do usuário local Contexto do usuário de rede
Controlador de domínio Padrão Usuário do domínio, membro do <DOMAIN>\Domain Admins Conta de Computador
Controlador de domínio Grupos de domínio A e B Usuário do domínio, membro de <DOMAIN>\A, <DOMAIN>\B Conta de Computador
Servidor membro ou estação de trabalho Padrão Usuário local, membro do BUILTIN\Administrators Conta de Computador
Servidor membro ou estação de trabalho Grupos locais C e D Usuário local, membro de <COMPUTER>\C e <COMPUTER>\D Conta de Computador

Ao examinar a auditoria de segurança e os logs de eventos do aplicativo, você verá que cada sessão de usuário JEA tem uma conta virtual exclusiva. Essa conta única ajuda você a acompanhar as ações dos usuários em um ponto de extremidade JEA, retornando ao usuário original que executou o comando. Os nomes de conta virtual 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 a quaisquer eventos do gerenciador de controle de serviço será WinRM Virtual Users\WinRM_VA_1_contoso_alice.

As gMSAs (contas de serviço gerenciadas por grupo) são úteis quando um servidor membro precisa ter acesso aos recursos de rede na sessão JEA. Por exemplo, quando um endpoint JEA é usado para controlar o acesso a um serviço de API REST hospedado em uma máquina diferente. É fácil gravar funções para invocar as APIs REST, mas você precisa de uma identidade de rede para se autenticar com a API. O uso de uma conta de serviço gerenciada por grupo possibilita o segundo salto, mantendo o controle sobre quais computadores podem usar a conta. As associações aos grupos de segurança (sejam locais ou de domínio) da gMSA definem as permissões efetivas da conta gMSA.

Quando o ponto de extremidade JEA é configurado para usar uma gMSA, as ações de todos os usuários JEA parecem originar-se do mesmo gMSA. A única maneira de rastrear ações de volta para 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 de executar como. O PowerShell usa a credencial do usuário de conexão para executar comandos no servidor remoto. Para usar credenciais de passagem, você deve conceder ao usuário acesso direto de conexão a grupos de gerenciamento privilegiados. Essa configuração NÃO é recomendada para 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 executar como padrão permitem que você especifique qualquer conta de usuário sob a qual toda a sessão do PowerShell é executada. As configurações de sessão usando contas fixas executar como (com o parâmetro -RunAsCredential) não são compatíveis com JEA. As definições de função não funcionam mais conforme o esperado. Cada usuário autorizado a acessar o endpoint recebe o mesmo papel.

Você não deve usar um RunAsCredential em um ponto de extremidade JEA porque é difícil rastrear ações de volta a usuários específicos e não tem suporte para mapear usuários a funções.

ACL do ponto de extremidade do WinRM

Assim como acontece com os endpoints de remoting regulares do PowerShell, cada endpoint JEA tem uma lista de controle de acesso (ACL) separada que controla quem pode autenticar-se no endpoint JEA. Se configurado incorretamente, os usuários confiáveis podem não conseguir acessar o ponto de extremidade JEA e os usuários não confiáveis poderão ter acesso. A ACL do WinRM não afeta o mapeamento de usuários para 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 que todos os usuários mapeados tenham acesso. Por exemplo, uma sessão JEA configurada usando os comandos a seguir concede acesso total 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 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 um prompt interativo ou Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> atualize as permissões. Os usuários precisam de, no mínimo, direitos de invocação para acessar o ponto de extremidade JEA.

É possível criar um ponto de extremidade JEA que não mapeie uma função definida para cada usuário que tenha 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 endpoint JEA executando Get-PSSessionCapability. Para obter mais informações, consulte Auditoria e Relatórios no JEA.

Funções de privilégios mínimos

Ao projetar funções JEA, é importante lembrar que as contas de serviço gerenciadas por grupo e virtuais em execução nos bastidores podem ter acesso irrestrito ao computador local. Os recursos de função JEA ajudam a limitar os comandos e aplicativos que podem ser executados nesse contexto privilegiado. Funções projetadas incorretamente podem permitir comandos perigosos que podem permitir que um usuário saia dos 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 permite que os usuários executem qualquer cmdlet do PowerShell com o substantivo Process do módulo Microsoft.PowerShell.Management. Talvez os usuários precisem acessar cmdlets como Get-Process ver quais aplicativos estão em execução no sistema e Stop-Process eliminar aplicativos que não estão respondendo. No entanto, essa entrada também permite 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 fornece ao usuário privilégios de administrador local, executa malware e muito mais.

Uma versão mais segura dessa mesma capacidade de função seria semelhante a:

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

Evite usar curingas em recursos de função. Certifique-se de auditar regularmente as permissões de usuário efetivas para ver quais comandos são acessíveis a um usuário. Para obter mais informações, consulte a seção Verificar direitos efetivos do artigo Auditing and Reporting on JEA .

Recomendações de práticas recomendadas

Veja a seguir as práticas recomendadas para garantir a segurança dos seus pontos de extremidade JEA:

Limitar o uso e os recursos de provedores do PowerShell

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

Aviso

Não permita o provedor FileSystem . Se os usuários puderem gravar em qualquer parte do sistema de arquivos, será possível ignorar completamente a segurança.

Não permita o provedor de certificados. Com o provedor habilitado, um usuário pode obter acesso a chaves privadas armazenadas.

Não permita comandos que possam criar novos runspaces.

Aviso

Os *-Job cmdlets podem criar novos runspaces sem as restrições.

Não permita o Trace-Command cmdlet.

Aviso

O uso de Trace-Command traz todos os comandos rastreados para a sessão.

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 protege contra administradores

Um dos princípios fundamentais do JEA é que ele permite que não administradores executem algumas tarefas administrativas. O JEA não protege contra 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 fazer login com RDP, usar consoles MMC remotos ou conectar-se a pontos de extremidade não restritos do PowerShell. Além disso, o administrador local em um sistema pode modificar as configurações JEA para adicionar mais usuários ou alterar uma capacidade de função para estender 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 verificar se existem outras maneiras de obter acesso privilegiado ao sistema.

Além de usar o JEA para manutenção diária regular, é comum implementar um sistema de gerenciamento de acesso privilegiado just-in-time. Esses sistemas permitem que os usuários designados se tornem temporariamente administradores locais somente depois de concluirem um fluxo de trabalho que documenta o uso dessas permissões.