Prática recomendada para acesso root com vários Admin

Question

Estou tentando montar uma política de segurança para uma coleção de servidores Linux. Há oito pessoas na minha organização que precisam de acesso ao nível da raiz sobre o SSH.

Em uma empresa antiga, minha solução era permitir somente chaves RSA e fornecer a todos uma chave própria para todos.

Para conceder privilégios de root, eu configurei o UID para 0. Isso negou a necessidade de configurar sudo ou su que as pessoas parecem sudo su - / sudo / bin / bash de qualquer maneira. Também me deixa fazer o seguinte.

Eu atualizei o Bash para registrar o valor de retorno de getlogin () e o comando para o syslog. Eu então tive um log de tudo executado nos servidores e nomes de usuários ligados aos usuários. Se eu usasse o su ou o sudo, eu teria apenas o usuário root.

Estou em um estado novo agora em uma nova empresa e me pergunto se alguém tem uma política que eles usam e gostam.

    

Answer 1

Usamos o sudo configurado para permitir comandos do grupo. Para evitar o sudo -i ou sudo bash, eu configurei um apelido incluindo todos os shells conhecidos que eu desaprovo usando! na definição do que o grupo pode fazer. Dessa forma, todos os comandos executados com o sudo são registrados no syslog. O único shell que instalei e permiti é o rootsh , que registra tudo que foi feito a partir dele.

Cmnd_Alias SHELLS= /bin/sh, /bin/ksh, /bin/bash, /bin/zsh, /bin/csh, /bin/tcsh, /bin/login, /bin/su
%admin ALL = (ALL) ALL, !SHELLS

Obviamente, nada pode impedir um administrador de

cp /bin/bash /tmp/shell
sudo /tmp/shell

para contornar essa segurança, mas você ainda tem direitos de root, você precisa confiar neles de qualquer maneira ...

    

Answer 2

Não tenho recomendações para fornecer quando se trata de registro ou privilégios, pois não entendo por que você gostaria de fazer isso. Você confia nos seus administradores e lhes dá acesso, ou não, e obtém novos administradores.

    

Answer 3

Com o acesso root, muitas vezes gosto de adotar a abordagem de pauska. Frequentemente, defino sudo all para administradores, o que permite que eles utilizem sudo su e executem comandos por meio dela. .bash_history ainda está no escopo, o que permite a revisão no caso de uma dúvida ocorrer no futuro.

A solução do skinp é mais uma política administrativa do que qualquer outra, como outros apontaram, não é uma solução segura. Exigir que todos os comandos root sejam executados via sudo é uma política comum atualmente.

Dependendo dos seus requisitos, geralmente usarei algo como rootsh para o registro central. No passado, o shell tinha problemas de funcionalidade, o que impede que seja sempre ideal. Eu gosto da sua solução para remendar o bash.

Dar UID 0 para contas de usuários é absolutamente confuso. O sistema corre o risco de erros simples e é mais provável que pise sobre as convenções do sistema. Eu desencorajaria isso em todos os casos.

Se você tiver uma justificativa de negócios que exija que uma equipe que não seja de TI ou não administrativa tenha acesso total à raiz, dar a eles acesso a rootsh ou fazer logoff do sudo é um requisito absoluto.

Por fim, qualquer pessoa que tenha acesso a privilégios de root provavelmente terá um vetor de ataque fácil. Uma trilha de auditoria é realmente uma prática recomendada, mas a implementação de restrições em excesso faz pouco pela segurança, ao mesmo tempo em que dificulta o trabalho dos administradores.