Gerenciando vários servidores, mais de 90 atualmente com 3 devops via Ansible. Tudo está funcionando muito bem, mas há um grande problema de segurança no momento. Cada devop usa sua própria chave ssh local para obter acesso direto aos servidores. Cada devop usa um laptop, e cada laptop pode ser potencialmente comprometido, abrindo assim toda a rede de servidores de produção a um ataque.
Estou procurando uma solução para gerenciar centralmente o acesso e, assim, bloquear o acesso a qualquer chave. Não muito diferente de como as chaves são adicionadas ao bitbucket ou ao github.
Pensando bem, eu presumiria que a solução seria um túnel de uma máquina, o gateway, para o servidor de produção desejado ... ao passar pelo gateway, a solicitação pegaria uma nova chave e usaria para obter acesso ao produto servidor. O resultado seria que poderíamos eliminar o acesso de qualquer devop de forma rápida e eficiente em segundos, apenas negando o acesso ao gateway.
Essa é uma boa lógica? Alguém já viu uma solução para frustrar esse problema?
Responder1
Isso é muito complicado (verificar se uma chave tem acesso a um servidor de produção específico). Use o servidor 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 sua vez) e, em seguida, adicione apenas as chaves permitidas a cada respectivo servidor. Depois disso, certifique-se de poder acessar a porta SSH de cada servidor somente por meio do host de salto.
Esta é a abordagem padrão.
Responder2
Os engenheiros não devem executar o ansible diretamente de seus laptops, a menos que este seja um ambiente de desenvolvimento/teste.
Em vez disso, tenha um servidor central que extraia 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.
Responder3
A Netflix implementou sua configuração e lançou alguns softwares gratuitos para ajudar nessa situação.
Veja este vídeohttps://www.oreilly.com/learning/how-netflix-gives-all-its-engineers-ssh-accessou esta apresentação emhttps://speakerdeck.com/rlewis/how-netflix-gives-all-its-engineers-ssh-access-to-instances-running-in-productioncom o ponto central:
Analisaremos nossa arquitetura bastião SSH, que em sua essência usa 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 para uma instância. Essas credenciais de curta duração reduzem o risco de perda associada. Abordaremos como essa abordagem nos permite auditar e alertar automaticamente após o fato, em vez de atrasar os engenheiros antes de conceder acesso.
O software deles está disponível aqui:https://github.com/Netflix/bless
Algumas conclusões interessantes, mesmo que você não implemente a solução completa:
- eles usam certificados SSH em vez de apenas chaves; você pode colocar muito mais metadados no certificado, permitindo assim muitas restrições por requisitos e também permitindo auditorias mais simples
- usando validade de certificados de prazo muito curto (como 5 minutos) (as sessões SSH permanecem abertas mesmo depois que o certificado expira)
- usar 2FA também 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 através dos mecanismos de segurança oferecidos pela nuvem onde é executado, cuida da geração de certificados de forma dinâmica para que cada desenvolvedor possa acessar qualquer host
Responder4
OneIdentity (ex-Balabit) SPSé exatamente o que você precisa neste cenário. Com este dispositivo você pode gerenciar as identidades dos usuários em basicamente qualquer máquina, rastrear o comportamento do usuário, monitorar e alertar e indexar tudo o que os usuários fazem para análises posteriores.