Acesso a jump box difícil de reforçar?

Como você garante de forma mais segura tanto o host jump / jump box quanto as credenciais do administrador?

Estas são as ideias que tenho:

Restringir o acesso de rede de entrada às jump boxes somente ao acesso via RDP a partir dos seus servidores RDS, portas e endereços IP necessários para comunicação e gerenciamento do AD.

Configurar o AppLocker para restringir o software executado nas jump boxes.

Exigir autenticação por cartão inteligente para fazer login nas jump boxes.

Adicionar licenças às jump boxes para que mais de 2 administradores possam fazer login ao mesmo tempo.

Exigir uma conexão VPN.

Um acesso em camadas para todos os sistemas é muito mais importante, a jump box é apenas um ponto de acesso adicional na cadeia - tenha um conceito e sistema adequados conforme este Securing privileged access Enterprise access model - Privileged access | Microsoft Learn

Quanto a um sistema simples como uma jump box, a proteção padrão para esse SO deve ser padrão - o que também significa, não coloque nada nessa jump box (como um gerenciador de senhas) que possa comprometer tudo o mais

Junte a Jumpbox ao seu próprio domínio em uma rede não conectada à Internet e ao resto da sua LAN com um firewall de hardware no meio. Então você faz uma confiança unidirecional para que seu Domínio confie no domínio da jump, mas não ao contrário, assim você não consegue invadir pela LAN normal. Então seus administradores fazem login usando credenciais separadas no domínio da jump com MFA. Depois, você faz a conexão de volta a partir do domínio para administrar o domínio regular. É assim que faço. Você pode me perguntar se quiser. Pesquise sobre a antiga Samba Red Forest. É parte disso. Ainda funciona, também.

EDIT: A Microsoft está tentando promover isso agora. Incorporei partes disso ao meu projeto. Estou trabalhando para fazer o Azure AD ser administrado apenas por lá via Acesso Condicional / Restrições de IP. Preciso abrir uma brecha para o Azure Management DNS/IP Endpoints though.

CISA, SANS e cerca de um milhão de outras organizações têm boas práticas pré-construídas para isso. Basta procurar no Google.

Bloquear o firewall para que fiquem acessíveis apenas de determinados IPs é a maior redução de risco.

basicamente apenas reforçamos a autenticação multifator, restringimos o acesso de entrada à nossa sub-rede administrativa e limitamos o acesso à internet a partir dela.

e permitimos login somente para o usuário que possui a jump box

  1. Use chaves
  2. restrinja aos IPs de equipamentos físicos controlados por pessoas específicas, não ao console genérico de “admin”.
  3. remova todos os pacotes não utilizados
  4. remova o acesso direto à internet e só permita atualizações conhecidas com processo de gerenciamento de mudanças
  5. contas de usuário específicas, uma para cada pessoa
  6. root restrito, sem login direto de root, e sem acesso su
  7. ufw, feche tudo que você não conhece.

e se quiser ser mais cauteloso – monitore e envie por e-mail todos os logs de sessão para serem mantidos na gestão de mudanças.
ou melhor ainda, uma notificação no login e uma tela forçada no login que permita monitoramento ao vivo.

Você também pode considerar não permitir nem mesmo o acesso a X, use só como uma caixa de salto.

Implementar uma firewall de autenticação kerberos para o tier de contas/sistemas. Ainda em desenvolvimento (para minha organização), mas é fácil de gerenciar e depois apenas desabilitar o NTLM. (via Protected Users)

https://www.reddit.com/r/activedirectory/comments/12h3fua/how_to_implement_auth_policy_and_silos/

(e tudo de reforço de segurança, claro)

Restringir logins apenas para administradores nas jump boxes e servidores, e garantir que esses contas de administrador estejam desabilitadas em qualquer outra coisa.

Garanta que você tenha um sistema de breakglass. Recomendo uma caixa física na sala de servidores.

Não recomendo fazer duplo pulo por outra RDS, é melhor usar uma RDP direto, com cartões inteligentes + MFA.

Use estações de trabalho privilegiadas ao invés disso. Jump box é aceitável, mas aumenta a superfície de ataque e oferece um caminho de escalonamento de privilégios significativo. Em vez disso, comece de uma sessão privilegiada em hardware conhecido e confiável.

A única coisa que eu acrescentaria é Acesso Condicional se estiver exposto para o público e JIT também, mas isso depende de eles estarem no Azure, assim como meu HSM e PKI.

Uma identidade permite fornecer acesso seguro a fornecedores sem dar VPN no seu ambiente.

Remova credenciais em cache, adicione contas usando jump ou paws ao grupo de usuários protegidos (não aos administradores de domínio). Limite quem pode fazer login neles com “negado login” etc configure o firewall do Windows para quais faixas de IP podem se conectar às caixas etc

https://www.gartner.com/reviews/market/privileged-access-management

algo como PAM Secret Server

Não entendo o que uma VPN acrescentaria se as jump boxes só forem acessíveis através do seu RDS interno.

PAWs não vão acontecer. Portanto, a próxima opção, além de não fazer nada, é implementar jump boxes.

Estamos implementando os Padrões CIS e o CIS parou de recomendar PAWs porque foram considerados pouco práticos após o trabalho remoto ter se tornado comum.

Paw é interessante, mas os técnicos são preguiçosos e usar a conta privilegiada no computador físico faz com que eles a usem para tudo, em vez de usar a VM para tarefas rotineiras.

dois computadores físicos são chatos.

Estou sem ideias de como fazer eles usarem corretamente

A Microsoft não recomenda mais a floresta vermelha ou o ESae há bastante tempo

Seguindo o CIS CSC, eles pararam de recomendar PAWs e agora dizem que as jump boxes são boas o suficiente.