Usuários do Servidor Web - Melhor Prática

Question

Eu queria saber qual é considerada a melhor prática quando vários desenvolvedores / administradores exigem acesso ao mesmo servidor da Web.

Deve haver um usuário não-root com um nome de usuário e senha seguros unquigitando o servidor da web que todos fazem login ou como deve haver um nome de usuário para cada pessoa.

Eu estou inclinado a um nome de usuário para cada pessoa para ajudar no registro, etc, mas o mesmo usuário mantém as mesmas credenciais em vários servidores, ou pelo menos sua senha deve mudar dependendo do servidor em que estão?

Algum usuário não-root do sistema deve ser adicionado ao arquivo sudoers ou é uma prática recomendada deixar todos fora dele e permitir que o root execute determinadas tarefas?

Qualquer ajuda seria muito apreciada.

    

Answer 1

• Prática recomendada: tenha rastreabilidade para todas as ações privilegiadas. Isso significa que não há logins como root em circunstâncias normais; as pessoas fazem login com seus próprios IDs e privilégios. Ações que eles tomam são rastreáveis. Se uma determinada conta for comprometida, ela pode ser corrigida sem afetar outras contas ou o sistema como um todo.

• Prática recomendada: menor privilégio. Pessoas e aplicativos obtêm as permissões necessárias para executar suas atividades autorizadas, mas não mais.

Seguir esses dois princípios é a resposta à sua pergunta. Exatamente como você os segue é com você. Depende do que a política do seu site recomenda, a complexidade do seu servidor configurado, planos de continuidade, etc. Note que seguir estes princípios dificulta o comprometimento do seu sistema por ataques hostis, mas o mais importante é limitar as conseqüências de um bem-intencionado erro.

Para coisas como manutenção de servidor web, a maioria dos recursos pode ser habilitada sem exigir acesso root por posse e permissões de usuário / grupo adequadas (note que a pergunta original tinha tags linux / unix). Por exemplo, os arquivos de configuração do servidor podem ser de propriedade de "wserver", group "wsgroup" e 664. Isso permitirá que qualquer usuário leia a configuração e qualquer pessoa em "wsgroup" para editar os arquivos (não necessariamente o que você deseja) . O conteúdo da Web pode estar em um grupo diferente, desde que o processo do servidor da Web tenha lido ou, talvez, permissão de execução, o conteúdo possa ser exibido. Isso permitirá que grupos diferentes (talvez sobrepostos) mantenham o servidor da Web e o conteúdo.

Você também pode configurar sudo para determinados usuários para executar comandos específicos como usuários específicos. Para práticas recomendadas, você deve limitar o acesso root aos poucos itens que realmente exigem privilégios de root (por exemplo, iniciar um processo que escuta em uma porta privilegiada). Configure o restante conforme necessário, concedendo os privilégios necessários, o que ajuda a limitar as consequências dos erros. Por exemplo, se você quiser permitir que um grupo edite os arquivos de configuração do servidor web, permita que eles executem {vim, emacs, gedit} como o proprietário dos arquivos de configuração.

    

Answer 2

Somos uma pequena empresa da webdev com vários servidores.

Todo administrador tem sua própria conta em todos os servidores e geralmente efetua login por meio do certificado. No entanto, eles também podem fazer o login por meio da senha, pois podem precisar fazer login de um local remoto, onde podem não ter seu certificado.

Fazer login diretamente como root só é permitido por meio do certificado. Nós não desativamos completamente o login da raiz remota, já que é muito útil para transferir arquivos entre servidores via rsync e scp, no entanto apenas os administradores mais confiáveis têm seus certificados adicionados ao arquivo authorized_keys do root.

Os administradores obtêm privilégios de superusuário via sudo, tornando-os membros do grupo wheel.

Isso não protege contra administradores mal-intencionados, mas fornece alguns registros e a capacidade de desativar contas individuais quando um administrador sai. Também não é escalável, mas é bom para um pequeno número de servidores.

Scripts que precisam de privilégios de superusuário, como o Capistrano, que usamos para implantar nossos sites do controle de versão para os servidores da web, obtêm suas próprias contas de usuário e podem usar o sudo para realizar ações de superusuário. Mas, eles estão limitados apenas aos comandos que eles precisam, através do Cmnd_Alias do sudo.

Estou pensando em configurar o Likewise Open para que possamos vincular a autenticação ao nosso domínio do Active Directory. Isso tornaria mais fácil centralizar a autenticação, gerenciar senhas e fornecer permissões granulares.