Não sou administrador de servidor, mas nosso atual administrador de servidor saiu. Portanto, coube temporariamente a mim cuidar das coisas. Nossos sistemas estão atualmente protegidos por chaves públicas/privadas. Mas ao fazer algumas investigações descobri que o único acesso é através desta chave. Não acredito que existam contas secundárias que possam ser acessadas. A raiz foi bloqueada. Isso me preocupa porque se por algum motivo a chave falhar/expirar, seremos bloqueados. Como eu disse, não sou administrador de servidor, mas imaginei que precisaríamos pelo menos de outra conta acessível que não fosse root, possivelmente com permissões sudo.
Agora vem o problema, temos cerca de 30 servidores Ubuntu principalmente web, e gerenciar todas essas senhas parece uma tarefa árdua. Não desejo entrar e criar contas ainda. Preciso de conselhos sobre a melhor maneira de configurar o acesso a mais de 30 (e crescentes) servidores.
Qual é a melhor forma de proteger o ambiente, tendo em mente o crescimento? Preciso apenas configurar manualmente todas essas contas, com senhas individuais? Ou deveríamos pensar em usar um serviço de diretório? Se sim, o que você recomendaria para o Ubuntu?
Você não precisa se preocupar e não precisa mudar. Seu antigo administrador fez um ótimo trabalho, desabilitar root e senhas é um bom começo para melhorar a segurança geral. Usar apenas a autenticação de chave é seguro. Normalmente as chaves não ficam desatualizadas, elas são apenas armazenadas no sistema de arquivos e, enquanto permanecerem lá, funcionarão. Você também não precisa se preocupar em ficar bloqueado. Se você tiver controle total sobre os servidores web, você sempre poderá obter acesso root apenas modificando o arquivo
/etc/shadow
(ativando o root novamente). O único problema aqui seria que você precisa montar o sistema de arquivos com outra instância do sistema operacional. Existem várias maneiras de fazer isso. Uma das maneiras mais fáceis é usar a camada do sistema operacional initramfs ou usar uma imagem de instalação inicializável e usar um shell.Se você realmente deseja ter uma senha de root, recomendo usar uma senha bem longa e configurá-la em todas as máquinas, imprimi-la e guardá-la em um cofre. Você pode definir uma senha root apenas com
sudo passwd
. Isso geralmente também ativa a conta do usuário root. Esta senha só deve ser conhecida por um número mínimo de pessoas, não deve ser armazenada em nenhum sistema informático com acesso à internet e só deve ser utilizada em caso de emergência.Eu usaria o ansible para gerenciar centralmente as chaves ssh nesses servidores, pode ser um exagero, não tenho certeza.
https://medium.com/@chandrapal/managing-linux-users-ssh-keys-using-ansible-39ee2fc24c16
E talvez combine isso com uma solução como o Keeper Security, onde você pode compartilhar as chaves ssh apenas com as pessoas que precisam delas.
Uma série de coisas:
Parece que há uma conta de administrador compartilhada e uma chave ssh compartilhada para fazer logon remoto nessa conta.
Em geral, você deseja que os administradores (e todos os usuários, na verdade) façam login com suas próprias contas e suas próprias chaves. E então eles podem aumentar seus privilégios com
sudo
suas próprias senhas pessoais.Quando uma pessoa sai da sua organização, você pode bloquear/excluir sua conta pessoal e pronto.
Com contas compartilhadas o processo se torna cada vez mais complicado, pois você deve alterar a senha de todas as contas compartilhadas em todos os lugares e quanto mais houver, maior será a probabilidade de você perder alguma ou alguma quebra.
Quase universalmente, todas as diretrizes de segurança exigem que o acesso root remoto seja desativado. O login root através do console normalmente é permitido, mas requer que a senha root seja conhecida.
Como já sugerido, gere uma lista de senhas de root fortes, de preferência uma para cada sistema, imprima essa lista e cole-a no cofre do escritório para eventos de quebra de vidro. (Quando você precisar acessar o console remoto.)
Faça hashes criptografados SHA512 dessas senhas e use essas senhas criptografadas para definir as senhas root em seus sistemas (por meio da automação de gerenciamento de configuração) para evitar o manuseio de senhas de texto não criptografado.
A propósito, os pares de chaves ssh convencionais não expiram.
Com 30 servidores e esperando mais, você deve considerar uma forma de gerenciamento de configuração centralizado e automatizado.
Isso tornará tudo muito mais fácil:
para fornecer acesso para cada membro da equipe/funcionário/administrador de sistema com uma conta pessoal e seu par de chaves ssh
para fornecer
sudo
privilégios (baseados em grupo) para cada membro da equipe/funcionário/administrador de sistemafazer atualizações
reimplantar a configuração correta para testes, escalabilidade horizontal, recuperação de desastres, etc.
Com o gerenciamento de configuração automatizado adequado, você pode evitar um diretório de usuários centralizado e provisionar contas de usuários locais para todos os seus administradores e funcionários.
Isso pode ser menos complicado no curto prazo.
Mas se você quiser impor a rotação regular de senhas e precisar garantir que todos usem senhas fortes, um diretório central de usuários rapidamente se tornará a melhor solução.
Se você já possui um diretório central de usuários, o Microsoft Active Directory, por exemplo, é quase sempre melhor integrá-lo a ele do que configurar um diretório de usuários separado para o gerenciamento de seus servidores Linux.