Gateway de acesso SSH para muitos servidores

Gerenciando vários servidores, atualmente acima de 90, com 3 devops via Ansible. Tudo está funcionando muito bem, no entanto, há um problema de segurança gigante no momento. Cada devop está usando sua própria chave ssh local para obter acesso diretamente aos servidores. Cada devop usa um laptop e cada laptop pode ser comprometido, abrindo toda a rede de servidores prod até um ataque.

Estou procurando uma solução para gerenciar centralmente o acesso e, assim, bloquear o acesso a qualquer chave. Não é diferente de como as chaves são adicionadas ao bitbucket ou ao github.

No topo da minha cabeça, eu assumiria que a solução seria um túnel de uma máquina, o gateway, para o servidor de prod desejado ... ao passar o gateway, o pedido pegaria uma nova chave e usaria para obter acesso ao prod servidor. O resultado seria que podemos matar de forma rápida e eficiente o acesso a qualquer devop em segundos, apenas negando o acesso ao gateway.

Essa é uma boa lógica? Alguém já viu uma solução por aí para impedir esse problema?

Isso é muito complicado (verificar se uma chave tem acesso a um servidor de prod específico). Use o servidor de gateway como host de salto que aceita todas as chaves válidas (mas pode remover facilmente o acesso a uma chave específica que remove o acesso a todos os servidores por vez) e adicione apenas as chaves permitidas a cada servidor respectivo. Depois disso, verifique se você pode alcançar a porta SSH de todos os servidores apenas através do host de salto.

Essa é a abordagem padrão.

Os engenheiros não devem estar executando diretamente do laptop, a menos que este seja um ambiente de desenvolvimento / teste.

Em vez disso, tenha um servidor central que retire os runbooks do git. Isso permite controles adicionais (quatro olhos, revisão de código).

Combine isso com um bastião ou host de salto para restringir ainda mais o acesso.

A Netflix implementou sua configuração e lançou algum software gratuito para ajudar nessa situação.

Veja este vídeo https://www.oreilly.com/learning/how-netflix-gives-all-its-engineers-ssh-access ou esta apresentação em https://speakerdeck.com/rlewis/how-netflix-gives- all-its-engineer-ssh-access-to-instance-running-in-production com o ponto principal:

Analisaremos nossa arquitetura de bastião SSH, que em seu núcleo usa o SSO para autenticar engenheiros e, em seguida, emitirá credenciais por usuário com certificados de curta duração para autenticação SSH do bastião em uma instância. Essas credenciais de vida curta reduzem o risco associado à perda. Abordaremos como essa abordagem nos permite auditar e alertar automaticamente após o fato, em vez de desacelerar os engenheiros antes de conceder acesso.

O software deles está disponível aqui: https://github.com/Netflix/bless

Algumas dicas interessantes, mesmo que você não implemente toda a solução:

• eles usam certificados SSH em vez de apenas chaves; você pode colocar muito mais metadados no certificado, possibilitando muitas restrições por requisitos e também permitindo auditorias mais simples
• usando validade de certificados de muito curto prazo (como 5 minutos) (as sessões SSH permanecem abertas mesmo após a expiração do certificado)
• usar o 2FA para também dificultar o script e forçar os desenvolvedores a encontrar outras soluções
• um submódulo específico, fora de sua infraestrutura e adequadamente protegido pelos mecanismos de segurança oferecidos pela nuvem em que é executado, gerencia a geração de certificados dinamicamente para que cada desenvolvedor possa acessar qualquer host

O SPS do OneIdentity (ex-Balabit) é exatamente o que você precisa neste cenário. Com esse dispositivo, você pode gerenciar as identidades do usuário em praticamente qualquer máquina, rastrear o comportamento do usuário, monitorar e alertar e indexar o que os usuários estão fazendo para análises posteriores.

Minha sugestão é proibir o acesso SSH das máquinas dos usuários.

Em vez disso, você deveria

1. Hospede playbooks no Git.
2. Transforme o "servidor de acesso" em um servidor Jenkins.
3. Grant só precisava do acesso de Jenkins a usuários de devops.
4. Execute execuções Ansible no Jenkins sobre trabalhos de construção via HTTP.
5. Como medida de segurança adicional, desative o Jenkins CLI, se necessário.

O modelo de execução de amostra,

1. Jenkins Ansible plugin: https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin

OU

2. Shell clássico - tipo de trabalho executado. Adicione suas etapas de compilação manualmente, incluindo git checkout.

Se você estiver limitado aos recursos do servidor, o mesmo servidor Jenkins também poderá hospedar o Git (scm-manager), embora exista um risco adicional à segurança se uma das máquinas do desenvolvedor estiver infectada. Você pode atenuar isso desconectando o servidor Jenkins da Internet e resolver dependências Ansible localmente.