Habilitar a comunicação remota de vários saltos no Windows PowerShell
Outro desafio na comunicação remota está relacionado à delegação de credenciais em várias conexões remotas. Por padrão, as credenciais podem ser delegadas em apenas uma conexão ou um salto. Essa delegação de restrições impede que o computador remoto continue a delegar as credenciais, pois isso pode apresentar um risco de segurança adicional.
Em geral, este é o cenário que queremos abordar:
- Você está conectado ao ServerA.
- No ServerA, você inicia uma sessão remota do PowerShell para se conectar ao ServerB.
- Um comando executado no ServerB por meio de sua sessão de Conexão Remota do PowerShell tenta acessar um recurso no ServerC.
- O acesso ao recurso no ServerC foi negado, pois as credenciais usadas para criar a sessão de Comunicação Remota do PowerShell não foram passadas do ServerB para o ServerC.
A necessidade de executar a delegação de saltos múltiplos (ou de vários saltos) geralmente pode ocorrer em ambientes de produção. Por exemplo, em algumas organizações, os administradores não têm permissão para se conectar diretamente dos computadores cliente a um servidor no datacenter. Em vez disso, eles devem se conectar a um gateway intermediário ou servidor de salto e então se conectar ao servidor que pretendem gerenciar. Na configuração padrão, a comunicação remota não permite essa abordagem. Depois que você estiver conectado a um computador remoto, a credencial não poderá ir além do computador remoto. Tentar acessar qualquer recurso que não esteja localizado nesse computador normalmente resulta em uma falha, pois o acesso não é acompanhado por uma credencial. A solução é habilitar o CredSSP (Provedor de Suporte à Segurança de Credenciais).
Como habilitar o CredSSP
O CredSSP armazena credenciais em cache no servidor remoto (ServerB, do exemplo anterior). Por isso, você deve estar ciente de que o uso do CredSSP deixa você aberto a possíveis ataques de roubo de credenciais. Se o computador remoto estiver comprometido, o invasor terá acesso às credenciais do usuário. O CredSSP é desabilitado por padrão nos computadores cliente e servidor. Você só deve habilitar o CredSSP nos ambientes mais confiáveis. Por exemplo, um administrador de domínio que se conecta a um controlador de domínio poderia ter o CredSSP habilitado, pois o controlador de domínio é altamente confiável.
Você deve habilitar o protocolo CredSSP no computador inicial, chamado de cliente, e no computador receptor, chamado de servidor. Isso permite que o computador receptor delegue a credencial a um salto adicional.
Para configurar o cliente, execute o seguinte comando, substituindo o nome do servidor pelo nome do servidor que poderá delegar novamente a credencial:
Enable-WsManCredSSP –Role Client –Delegate servername
O nome do servidor pode conter caracteres curinga. No entanto, usar o curinga asterisco (*) por si só é muito permissivo porque você estaria possibilitando que qualquer computador delegasse novamente a credencial, até mesmo um usuário não autorizado. Em vez disso, considere um padrão de curinga limitado, como *.ADATUM.com, que restringiria a nova delegação a computadores nesse domínio.
Para configurar o servidor, execute Enable-WsManCredSSP –Role Server. Nenhuma lista de computadores delegados é necessária no servidor. Você também pode definir essas configurações por meio da Política de Grupo, que oferece uma configuração mais centralizada e consistente em uma empresa.
Observação
Houve inúmeras violações de segurança documentadas ao usar o CredSSP e, portanto, não essa é mais uma opção preferencial. Em vez disso, você deve usar a delegação restrita.
Delegação restrita de Kerberos baseada em recursos
A partir do Windows Server 2012, você pode renunciar ao uso do CredSSP e, em vez disso, usar a delegação restrita. A delegação restrita implementa a delegação de tíquetes de serviço usando descritores de segurança, em vez de uma lista de permissões de nomes de servidor. Isso permite que o recurso determine quais entidades de segurança podem solicitar tíquetes em nome de outro usuário. A delegação restrita baseada em recursos funciona de forma correta, independentemente do nível funcional do domínio.
A delegação restrita exige:
- Acesso a um controlador de domínio no mesmo domínio que o computador host em que os comandos de comunicação remota do Windows PowerShell estão sendo executados.
- Acesso a um controlador de domínio no domínio que hospeda o servidor remoto que você está tentando acessar pelo servidor remoto intermediário.
O código de configuração das permissões requer um computador que execute o Windows Server com as Ferramentas de Administração de Servidor Remoto do PowerShell do Active Directory. Você pode adicionar as Ferramentas de Administração de Servidor Remoto como recurso do Windows, executando os dois comandos a seguir:
Add-WindowsFeature RSAT-AD-PowerShell
Import-Module ActiveDirectory
Para conceder a delegação restrita de Kerberos baseada em recursos do LON-SVR1, passando pelo LON-SVR2 até o LON-SVR3, execute o comando a seguir:
Set-ADComputer -Identity LON-SVR2 -PrincipalsAllowedToDelegateToAccount LON-SVR3
Um problema pode fazer com que esse comando falhe. O KDC (Centro de Distribuição de Chaves) tem um cache SPN negativo de 15 minutos. Se o LON-SVR2 já tiver tentado se comunicar com o LON-SVR3, haverá uma entrada de cache negativo. Você precisará limpar o cache no LON-SVR2, usando uma das técnicas a seguir:
- Execute o comando
klist purge -li 0x3e7. Este é o método preferencial e mais rápido. - Aguarde 15 minutos para que o cache seja limpo automaticamente.
- Reinicie o LON-SVR2.
Para testar a delegação restrita, execute o exemplo de código a seguir:
$cred = Get-Credential Adatum\TestUser
Invoke-Command -ComputerName LON-SVR1.Name -Credential $cred -ScriptBlock {Test-Path \\$($using:ServerC.Name)\C$ `
Get-Process lsass -ComputerName $($using:LON-SVR2.Name)
Get-EventLog -LogName System -Newest 3 -ComputerName $using:LON-SVR3.Name
}
Administração Just Enough
O JEA (Just Enough Administration) é uma tecnologia de segurança que permite a administração delegada para itens gerenciados pelo PowerShell. Com o JEA, você pode:
- Reduza o número de administradores nos computadores usando contas virtuais ou contas de serviço gerenciado por grupo, para executar ações com privilégios em nome dos usuários regulares.
- Limitar o que os usuários podem fazer especificando quais cmdlets, funções e comandos externos eles podem executar.
- Entenda melhor o que os usuários estão fazendo, examinando as transcrições e os logs que descrevem exatamente quais comandos um usuário executou durante a sessão.
Contas altamente privilegiadas, usadas para administrar os servidores, representam um sério risco de segurança. Caso um invasor comprometa uma dessas contas, poderia iniciar ataques laterais por toda a sua organização. Cada conta comprometida dá a um invasor acesso a ainda mais contas e recursos e o coloca um passo mais perto de roubar segredos da empresa, iniciar um ataque de DOS (negação de serviço) e muito mais.
No entanto, nem sempre é fácil remover privilégios administrativos. Considere um cenário comum em que a função DNS foi instalada no mesmo computador que o controlador de domínio do Active Directory. Os administradores do DNS exigem privilégios de administrador local para corrigir problemas com o servidor DNS. Mas para fazer isso, você deve torná-los membros do grupo de segurança de Administradores com privilégios elevados. Essa abordagem oferece efetivamente aos Administradores de DNS a capacidade de obter controle sobre todo o domínio e acesso a todos os recursos desse computador.
O JEA resolve desse problema usando o princípio de privilégios mínimos. Com o JEA, você pode configurar um ponto de extremidade de gerenciamento para administradores do DNS que fornece a eles acesso somente os comandos do PowerShell de que precisam para realizar seus trabalhos. Isso significa que você pode fornecer o acesso apropriado para reparar um cache DNS inviabilizado ou reiniciar o servidor DNS, sem acidentalmente conceder a eles direitos ao Active Directory, para navegar no sistema de arquivos ou para executar scripts potencialmente perigosos. Melhor ainda, quando a sessão do JEA é configurada para usar contas virtuais temporárias com privilégios, os administradores de DNS podem se conectar ao servidor usando credenciais não administrativas e ainda podem executar os comandos que, geralmente, exigem privilégios de administrador. O JEA permite que você remova usuários das funções administrador local/de domínio com privilégios elevados e controle cuidadosamente o que eles podem fazer em cada computador.
O JEA é um recurso incluído no PowerShell 5.0 e mais recente. Para obter a funcionalidade completa, você deve instalar a versão mais recente do PowerShell disponível para o sistema. A Comunicação Remota do PowerShell fornece a base na qual o JEA é criado. É necessário garantir que a comunicação remota do PowerShell esteja habilitada e devidamente protegida antes de usar o JEA.
Ao criar um ponto de extremidade JEA, é necessário definir uma ou mais capacidades de função que descrevam o que alguém pode fazer em uma sessão JEA. Uma capacidade de função é um arquivo de dados do PowerShell com a extensão .psrc, que lista todos os cmdlets, as funções, os provedores e os programas externos que devem ser disponibilizados para os usuários que estão se conectando.
Você pode criar um novo arquivo de capacidade de função do PowerShell com o cmdlet New-PSRoleCapabilityFile. O arquivo de capacidade de função resultante deve ser editado, para permitir os comandos necessários para a função. A documentação de ajuda do PowerShell contém vários exemplos de como você pode configurar o arquivo.