gateway de acesso SSH para muitos servidores

Question

Gerenciando vários servidores, em excesso de 90 atualmente com 3 devops via Ansible. Tudo está funcionando muito bem, no entanto, há um problema de segurança gigante agora. Cada devop está usando sua própria chave ssh local para obter acesso diretamente aos servidores. Cada devop usa um laptop, e cada laptop potencialmente pode ser comprometido, abrindo assim 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 específica. Não é diferente de como as chaves são adicionadas ao bitbucket ou github.

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

Esta é uma boa lógica? Alguém já viu uma solução lá fora para frustrar este problema?

    

Answer 1

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

Esta é a abordagem padrão.

    

Answer 2

Os engenheiros não devem estar correndo diretamente a partir de seu laptop, a menos que 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 o acesso.

    

Answer 3

O Netflix implementou sua configuração e lançou alguns softwares gratuitos para ajudar nessa situação.

Veja este vídeo link ou esta apresentação em < href="https://speakerdeck.com/rlewis/how-netflix-gives-all-its-engineers-ssh-access-to-instances-running-in-production"> link com o ponto principal :

We’ll review our SSH bastion architecture, which at its core uses SSO to authenticate engineers, and then issues per user credentials with short lived certificates for SSH authentication of the bastion to an instance. These short lived credentials reduce the risk associated them being lost. We’ll cover how this approach allows us to audit and automatically alert after the fact, instead of slowing down engineers before granting access.

O software deles está disponível aqui: link

Algumas dicas interessantes ainda 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, permitindo muitas restrições por requisitos e também permitindo auditorias mais simples
• usando validade de certificados de curtíssimo prazo (como 5 minutos) (as sessões do SSH permanecem abertas mesmo após o certificado expirar)
• usando o 2FA para dificultar a criação de scripts e forçar os desenvolvedores a encontrar outras soluções
• um submódulo específico, fora de sua infraestrutura e devidamente protegido por meio dos mecanismos de segurança oferecidos pela nuvem em que é executado, manipula a geração de certificados dinamicamente para que cada desenvolvedor possa acessar qualquer host

Answer 4

Minha sugestão não permite acesso ssh de máquinas de usuários, Em vez disso,

1. Playbooks do host no Git.
2. Transforme o "servidor de acesso" em um servidor Jenkins.
3. Conceder apenas acesso necessário ao Jenkins para usuários devops.
4. Executa execuções ansiosas no jenkins para criar trabalhos via HTTP.
5. Como medida de segurança adicional, desative o jenkins cli, se necessário.

O modelo de execução de amostra,

1. Plugin do Jenkins Ansible: link

OR

2. Tipo de trabalho do shell clássico -exeecute. Adicione suas etapas de criação manualmente, incluindo o checkout do git.

Se você estiver limitado com recursos do servidor, o mesmo servidor jenkins também poderá hospedar o git (scm-manager). (Ameaça de segurança adicional, se uma das máquinas do desenvolvedor estiver infectada, provavelmente pode atenuar cortando o servidor Jenkins da Internet e resfriar as dependências ansible localmente)