Sudoer de log e relatório de email

5

Eu tenho um usuário em um sistema Ubuntu que precisa de acesso ao sudo, mas eu não confio nele tanto quanto eu gostaria de poder. Existe uma maneira de registrar toda a sua atividade sudo e enviá-la por e-mail para mim no final do dia?

    
por zib_redlektab 17.02.2011 / 20:41

3 respostas

5

Esta não é uma boa ideia. Existem vários pontos fracos neste plano.

  1. Se você não confia nele, não lhe dê acesso. E-mail sua maldade no final do dia não vai ajudar nada se ele já fez isso à noite. E se ele realmente quisesse comprometer o sistema, ele certamente encontraria uma maneira de manipular esses e-mails desagradáveis. É um cálculo bastante fácil, se um usuário que você não confia tem privilégios administrativos no sistema, você não pode confiar na observação do sistema.

  2. Se ele realmente precisa de acesso, podemos trabalhar em torno de privilégios de superusuário? E se ele realmente precisa de sudo, pode ser restrito a apenas alguns comandos.

por 17.02.2011 / 20:57
2

A maneira mais simples de fazer isso é configurar logwatch na sua máquina. Por padrão, o logwatch gera um e-mail todas as noites, incluindo vários detalhes do sistema e importantes mensagens de log. Por padrão, inclui todos os comandos sudo registrados também.

Em seguida, basta definir o endereço de e-mail do logwatch em /etc/logwatch.conf para o seu endereço e você receberá esses e-mails todas as noites.

Eu recomendo strongmente que você converse com o usuário em questão e compartilhe suas preocupações com ele honestamente. Muito melhor para ele saber que ele pode perguntar se ele está confuso sobre qualquer coisa do que para você encontrar erros nos registros. Confie, mas verifique.

    
por 17.02.2011 / 20:56
2

Este é o exemplo clássico do conceito Princípio do Menor Privilégio. Ou seja, o usuário deve ter o menor acesso necessário para executar suas funções de trabalho. A solução real para o seu problema é implementar um procedimento operacional padrão que limite os direitos totais de administrador a um servidor apenas àquelas pessoas que realmente administram o servidor. Embora isso seja fácil de sugerir, será preciso uma boa quantidade de trabalho de sua parte para ser implementado e, normalmente, exigirá uma mudança no processo de negócios para os DBAs, administradores de aplicativos, etc.

O que você precisa fazer é sentar-se com o usuário e determinar exatamente o que o usuário faz usando esse sistema e mapear quais direitos de acesso seriam necessários. A coisa realmente complicada aqui é determinar o que eles precisam fazer em oposição a como eles fazem isso. Alguns dos tipos de perguntas que você deve começar são coisas como eles precisam editar arquivos do sistema, reiniciar serviços, ver arquivos de log, etc.

Depois de ter essas informações catalogadas, você pode começar a descobrir se há algo que você deveria fazer em vez disso. Por exemplo, se um arquivo em / etc / sysconfig precisar ser alterado, o usuário deve preparar a alteração e, em seguida, fornecê-la a um administrador de sistema para implantar? Ou se eles precisam ser capazes de gerenciar serviços, quais comandos são realmente necessários para fazer isso, e isso tem que ser feito como root ou como uma conta de serviço?

No final do exercício, você deve ter uma lista de comandos que eles precisam para executar (e para quem), os arquivos que precisam acessar e os procedimentos que você e o usuário podem seguir para fazer alterações anormais.

    
por 17.02.2011 / 22:02