Uma única chave em várias máquinas certamente reduz a quantidade de chaves que um administrador de sistemas precisa manipular. Eu tenho cinco máquinas nas quais posso trabalhar (geralmente cerca de três muito ativas, mas uma pode estar em reparo, outra em uso muito ocasional). Se uma empresa tinha oito pessoas como eu, faz 40 chaves para administrar em vez de 8.
No entanto, a questão que a Arcege apontou de maneira bastante inteligente, embora indireta, é que, se uma única máquina for comprometida ou mesmo desaparecer por um curto período de tempo, isso significaria que eu não teria mais acesso a partir de nenhuma máquina (como minha chave para todas as minhas máquinas teriam que ser derrubadas). Certamente, a conveniência de poder remover uma única chave de um laptop comprometido ou roubado e poder continuar trabalhando em outra máquina vale o trabalho de lidar com várias chaves.
Em um exemplo ainda mais extremo, imagine que eu sou o administrador do sistema e tenho um laptop roubado ou hackeado. Minha chave precisa ser removida, mas eu preciso acessar todos os sistemas para fazer isso. Embora seja tecnicamente possível substituir e remover em uma única sessão, ao tentar mover-se rapidamente e cobrir todas as bases, isso complica consideravelmente o cenário de emergência.
Por outro lado, se eu tiver chaves únicas para cada estação de trabalho, se puder acessar uma estação de trabalho alternativa, posso excluir rápida e eficientemente a chave comprometida, sem correr o risco de me bloquear.
À medida que me aprofundo na abordagem das chaves SSH à segurança, fica claro que, para segurança real, todos devemos usar os dois:
- o que temos (chaves SSH)
- o que sabemos (senha para o servidor)
O requisito de senha abrange o acesso ao servidor e uma senha para a chave. O fator de aborrecimento aumenta, mas no momento temos os três em vigor (chaves SSH, senha de acesso à chave SSH, senha do servidor) nesse ponto, não há mais um único ponto de falha . Uma senha de servidor compartilhada também protege sua equipe contra uma senha de chave SSH muito fraca (normalmente não temos controle sobre o nível de senha que nossos colegas geram - e um administrador de senhas em uma situação corporativa em que tenho acesso às ferramentas de auditoria de senha que posso diga a você mesmo quem deve saber melhor às vezes cria senhas chocantemente fracas).
Um invasor precisa ser determinado e um ataque bem-sucedido pode levar meses ou até anos. Alterando a senha do servidor ocasionalmente (a cada seis meses ou mais, a senha do servidor é compartilhada com um sistema de nível empresarial como o LastPass - lembre-se de que também existem chaves SSH), neste momento seus servidores desfrutam de segurança razoável (como ninguém poderia combinar um SSH quente chave com uma senha antiga para invadir).
É preciso pensar no acesso interno ilegal (Edward Snowden vem à mente, o Ashley Madison vem em segundo) como um risco primário. Somente usando chaves e senhas seria possível realmente desacelerar um usuário interno.
Diferente do método chinês antigo: enterre-os vivos quando seu trabalho terminar.
Após o enterro, sugeriu-se que seria uma violação grave se os artesãos que construíram os dispositivos mecânicos e conheciam seus tesouros divulgassem esses segredos. Portanto, depois que as cerimônias fúnebres terminaram e os tesouros foram escondidos, a passagem interna foi bloqueada e o portão externo abaixou, prendendo imediatamente todos os trabalhadores e artesãos que estavam dentro. Ninguém poderia escapar.