Você está pronto para desistir do acesso root?

Question

Há uma pergunta anterior:

Devemos desativar o usuário root?

A maioria das pessoas contra essa possibilidade estava dizendo que você vai precisar e você estará em apuros se não tiver.

Eu não acho que seja um motivo real, há muitas maneiras de evitar o ponto único de falha de qualquer componente, então a criticidade de ter acesso a um servidor em particular se torna irrelevante.

Portanto, se sua infra-estrutura de TI era completamente redundante e o não acesso a um servidor específico não é crítico e pode ser endereçado por clustering, virtualização, clonagem, sistema de backup rápido, etc.

Você desistirá da conta root? Minha experiência mostra que principalmente sysadmin tem um relacionamento pessoal com a conta root e tem grande problema para não manter a senha do seu próprio servidor.

    

Answer 1

Quando os recursos são mais genericamente suportados em tudo, absolutamente.

Até lá, manterei sudo em torno das poucas coisas que ainda exigem escalonamento de privilégios explícito. Por último, eu olhei para ele, porém, a noção de capacidades ainda não era relativamente suportada em muitos sistemas fora da caixa. Isso seria importante ter. Dessa forma, não importa qual seja o seu sistema, você pode dizer "Este usuário pode acessá-lo", sem precisar escalar para outra conta de usuário. Naturalmente, os privilégios concedidos precisariam ser baseados nos papéis dos usuários nos sistemas, mas, eventualmente, ninguém deveria deter todo o poder da conta (pelo menos não se há várias funções que outras pessoas são empregadas para lidar). .

Se você for um DBA, não precisará de nenhuma forma de acesso de superusuário, desde que seja o proprietário do processo do sistema de banco de dados e da (s) área (s) de armazenamento do sistema de arquivos. Isso pode significar que você tem que pedir ao administrador do disco para fsck diversão em suas partições ou restaurá-los de vez em quando, ou qualquer outra coisa, mas o DBA não deve ter a capacidade de derrubar uma máquina com seus próprios direitos de acesso, a menos que eles "Possui" o servidor.

Dito isto, se você for a única pessoa a gerir 100% dos processos no servidor, então sudo é absolutamente suficiente. É somente quando você tem outras pessoas que usam o servidor e / ou gerenciam coisas nele (ou dependem dele) e há vários administradores que a separação de privilégio entra em conta, de qualquer maneira.

    

Answer 2

Basta desativar o login root via ssh e su para root. Sempre funcionou bem em qualquer organização da qual eu tenha participado. Basta usar o console para fazer login como root para manutenção, todos os outros usuários apenas usam o sudo.

    

Answer 3

Will you give up the root account ? My experience show than mainly sysadmin have a personal relationship with the root account and have big problem to not hold the password of their own server.

Se eu for responsável por um servidor, precisarei de algum nível de acesso privilegiado. Não importa se o nome dessa conta é root , ou se eu tiver que fazer login como eu e usar alguma ferramenta para elevar meus privilégios.

Se o sistema for um padrão * nix (ou fechar também o padrão), então provavelmente precisarei do acesso root para alguma tarefa administrativa em algum ponto ou outro, simplesmente porque é assim que tem sido por décadas, e há muita inércia nesse modo de fazer as coisas. Mas isso não significa que eu faria login como conta quando não preciso disso, ou deixaria essa conta aberta e desprotegida.

Se eu não for responsável pelo host, provavelmente não devo receber a conta root. Na verdade, eu frequentemente tento evitar que alguém me diga qual é a senha do root.

So if your IT infrastructure was completely redundant and the non-access to one particular server is non-critical and can be addressed by clustering, virtualisation, cloning, fast backup system, etc..

Honestamente, não vejo como isso se relaciona com a necessidade de uma conta privilegiada para executar tarefas privilegiadas em um computador.

    

Answer 4

Ainda mantemos contas de root e fazemos login em todos os nossos servidores. A razão é que todas as outras contas de usuário vêm de um servidor de diretório central. Se um servidor foi colocado off-line ou de alguma forma perdeu sua conexão com o diretório, é necessário que haja uma maneira de efetuar login nele para trabalhar nele. Não vejo como isso poderia ser feito além de ter uma conta root.

    

Answer 5

Práticas recomendadas comuns em organizações nas quais trabalhei em relação à conta "raiz".

• Desative totalmente o acesso remoto ou apenas permita o SSH via autenticação de chave.
• Desativar / bloquear a senha do root (a la Ubuntu).
• Requer uso estrito de sudo e garante que ele seja registrado corretamente.
• Bloqueie /bin/su para ser executável apenas por um determinado grupo (geralmente, wheel ou sysadmin ).
• Verifique se os shells de raiz estão bem registrados (imponha script , use sudosh , truques de histórico do shell, etc.).
• Apenas os usuários que exigem root access recebem direitos a sudo ALL e os direitos são concedidos por meio do sudo de acordo com o uso.

O UID 0 ainda é necessário, principalmente para tarefas como a abertura de portas abaixo de 1024, mesmo se privs forem descartados após a execução de um aplicativo.

Segurança e conveniência são mutuamente exclusivas em TI. Usar a conta root diretamente é geralmente uma questão de conveniência, não de necessidade, talvez porque os administradores odeiam digitar sudo o tempo todo?

    

Answer 6

No Unix e no GNU / Linux, ainda há momentos em que você precisa ser root, mas não frequentemente. Você pode reduzir significativamente a necessidade de ser root se você configurar o sudo, o SELinux e / ou os recursos corretamente.

    

Answer 7

Uma grande quantidade de informações sobre falhas está oculta em arquivos de log somente de raiz, mas com a configuração de permissões corretas para permitir esses mesmos arquivos de log e um ambiente de teste no qual posso ser root, se quiser. Eu vou.

    

Answer 8

Se o sudo me permite fazer o que eu preciso fazer - e às vezes eu preciso de um shell de root - então sim, eu desistiria da conta de root. Eu provavelmente estaria mais feliz assim, na verdade.

    

Answer 9

Minha resposta é simplesmente "NÃO". É claro que a conta root é usada sempre que eu precisar de direitos administrativos, caso contrário, uma conta de usuário normal deve ser usada.

Como desenvolvedor do MS Windows, eu sempre usei uma conta de domínio com direitos administrativos locais. Caso contrário, há muitos problemas, especialmente quando você precisa lidar com COM / COM +, etc. Eu tentei desenvolver usando um usuário normal nos primeiros dias do Windows 2000 e desisti finalmente em um mês de tempo ... "RunAs "não pode salvar todo o problema para mim naquele momento ...

    

Answer 10

A maioria dos ambientes em que trabalhei nos últimos anos tem a senha root em um cofre com senha para ser usado em emergências, e para todo acesso privilegiado para passar por sudo ou ksu. Isso não apenas permite um controle de acesso mais refinado, como também tem o efeito colateral de manter uma trilha de auditoria - você pode dizer qual conta não privilegiada escalou para executar o comando.

    

Answer 11

É bom ter a conta root ativada para casos em que você viola a configuração do sudo ou em que o método de autenticação para usuários normais falha (por exemplo, em um ambiente LDAP). Se você tem um usuário local, e sempre usa visudo (o que irá verificar a configuração do sudo e pegar a maioria dos erros), então você deve estar OK. Esteja preparado para ter que usar um CD de boot para entrar no sistema, no entanto, as coisas vão dar errado. Ter acesso a uma conta root, mesmo que a senha seja mantida em algum lugar seguro e não acessível em uso normal, oferece mais uma rede de segurança caso algo dê errado.