Considerações de segurança do JEA

A JEA ajuda você a melhorar sua postura de segurança, reduzindo o número de administradores permanentes em suas máquinas. 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, à máquina para realizar tarefas administrativas podem ter 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 Run-As

Cada ponto de extremidade JEA tem uma conta run-as designada sob a qual as ações do usuário conectado são executadas. Essa conta é configurável no arquivo de configuração da sessão, e a conta escolhida tem uma influência significativa na segurança do seu endpoint.

As contas virtuais são a maneira recomendada de configurar a conta run-as . As contas virtuais são contas locais únicas e temporárias que são criadas para o usuário conectado usar durante a duração de sua sessão JEA. Assim que a sessão é encerrada, a conta virtual é destruída e não pode 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 a Área de Trabalho Remota ou um ponto de extremidade do PowerShell sem restrições.

Por padrão, as contas virtuais são membros do grupo Administradores local na máquina. Esta associação dá-lhes plenos direitos para gerir qualquer coisa no sistema, mas não direitos para gerir recursos na rede. Quando o usuário se conecta a outras máquinas a partir da sessão JEA, o contexto do usuário é o da conta do computador local, não a conta virtual.

Os controladores de domínio são um caso especial, uma vez que não existe um grupo local de Administradores . Em vez disso, as contas virtuais pertencem aos administradores do 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 onde 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 de estação de trabalho e membros. Nos controladores de domínio, as contas virtuais devem ser membros de grupos de segurança de domínio. Depois que a conta virtual for 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 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 da rede
Controlador de domínio	Predefinido	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 do <DOMAIN>\A, <DOMAIN>\B	Conta de computador
Servidor membro ou estação de trabalho	Predefinido	Usuário local, membro da 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

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

As contas de serviço gerenciadas por grupo (gMSAs) são úteis quando um servidor membro precisa ter acesso aos recursos da 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 uma máquina diferente. É fácil escrever 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 torna o segundo salto possível, mantendo o controle sobre quais computadores podem usar a conta. As associações de grupo de segurança (local ou domínio) do gMSA definiram as permissões efetivas para a conta gMSA.

Quando um ponto de extremidade JEA é configurado para usar um gMSA, as ações de todos os usuários do JEA parecem vir do mesmo gMSA. A única maneira de rastrear 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 run-as . 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 conectado acesso direto a grupos de gerenciamento privilegiados. Esta 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 de execução padrão 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 run-as fixas (com o -RunAsCredential parâmetro) não reconhecem JEA. As definições de função não funcionam mais como esperado. A cada usuário autorizado a acessar o ponto de extremidade é atribuída a mesma função.

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

ACL de ponto de extremidade do WinRM

Assim como acontece com os pontos de extremidade de comunicação remota regulares do PowerShell, cada ponto de extremidade JEA tem uma lista de controle de acesso (ACL) separada que controla quem pode se autenticar com o ponto de extremidade 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 podem 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ários recursos 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 usando os seguintes comandos 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 para um prompt interativo ou Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> para atualizar as permissões. Os usuários precisam pelo menos invocar direitos 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 tem acesso. Esses usuários podem iniciar uma sessão JEA, mas só têm acesso aos cmdlets padrão. Você pode auditar permissões de usuário em um ponto de extremidade JEA executando Get-PSSessionCapability. Para obter mais informações, consulte Auditoria e relatórios sobre JEA.

Funções de menor privilégio

Ao projetar funções JEA, é importante lembrar que as contas de serviço virtuais e gerenciadas em grupo executadas nos bastidores podem ter acesso irrestrito à máquina 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'
}

Esse recurso de função permite que os usuários executem qualquer cmdlet do PowerShell com o substantivo Process do módulo Microsoft.PowerShell.Management . Os usuários podem precisar acessar cmdlets como Get-Process ver quais aplicativos estão sendo executados no sistema e Stop-Process matar aplicativos que não estão respondendo. No entanto, esta 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 dá ao usuário privilégios de administrador local, executa malware e muito mais.

Uma versão mais segura desse mesmo recurso 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 eficazes 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 JEA .

Recomendações de boas práticas

A seguir estão recomendações de práticas recomendadas para garantir a segurança de seus pontos de extremidade JEA:

Limitar o uso e os recursos dos provedores do PowerShell

Analise 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, é possível ignorar completamente a segurança.

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

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

Aviso

Os *-Job cmdlets podem criar novos espaços de execução sem as restrições.

Não permita o Trace-Command cmdlet.

Aviso

Usar 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 proxy para cenários de comando restrito. Esses comandos de proxy garantem que os parâmetros de entrada não comprometam 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 proxy JEA.

O JEA não protege contra administradores

Um dos princípios fundamentais do JEA é que ele permite que não-administradores façam 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 entrar com RDP, usar consoles MMC remotos ou conectar-se a pontos de extremidade do PowerShell sem restrições. Além disso, o administrador local em um sistema pode modificar as configurações do JEA para adicionar mais usuários ou alterar um recurso de função para estender o escopo do que um usuário pode fazer em sua sessão JEA. É importante avaliar as permissões estendidas dos usuários do JEA para ver se há 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 administradores locais somente depois de concluírem um fluxo de trabalho que documente o uso dessas permissões.