13.14. Administração Compartilhada com Sudo
Anterior | Capítulo 13. Segurança | Próxima

## 13.14. Administração Compartilhada com Sudo

Contribuído por Tom Rhodes.

Os administradores do sistema geralmente precisam conceder permissões avançadas aos usuários para que eles possam executar tarefas privilegiadas. A ideia de que os membros da equipe tenham acesso a um sistema FreeBSD para executar suas tarefas específicas abre desafios únicos para cada administrador. Esses membros da equipe precisam apenas de um subconjunto de acesso além dos níveis normais de usuário final; no entanto, eles quase sempre dizem ao gerenciadores que eles são incapazes de executar suas tarefas sem acesso de superusuário. Felizmente, não há motivo para fornecer tal acesso aos usuários finais porque existem ferramentas para gerenciar esse exato requisito.

Até este ponto, o capítulo de segurança cobriu o acesso a usuários autorizados e a tentativa de impedir o acesso não autorizado. Outro problema surge quando os usuários autorizados têm acesso aos recursos do sistema. Em muitos casos, alguns usuários podem precisar acessar os scripts de inicialização do aplicativo ou uma equipe de administradores precisa manter o sistema. Tradicionalmente, os usuários e grupos padrão, as permissões de arquivo e até mesmo o comando su() gerenciariam esse acesso. E como os aplicativos exigiam mais acesso, à medida que mais usuários precisavam usar recursos do sistema, era necessária uma solução melhor. A aplicação mais usada atualmente é o Sudo.

O Sudo permite que os administradores configurem um acesso mais rígido aos comandos do sistema e forneçam alguns recursos avançados de log. Como uma ferramenta, ele está disponível na coleção de ports como security/sudo ou usando o utilitário pkg(8). Para usar a ferramenta pkg(8):

    # pkg install sudo

Após a conclusão da instalação, o `visudo` instalado abrirá o arquivo de configuração com um editor de texto. O uso do `visudo` é altamente recomendado, pois vem com um verificador de sintaxe incorporado para verificar se não há erros antes que o arquivo seja salvo.

O arquivo de configuração é composto de várias seções pequenas que permitem uma configuração extensiva. No exemplo a seguir, o mantenedor do aplicativo da web, user1, precisa iniciar, parar e reiniciar o aplicativo da web conhecido como `webservice`. Para conceder a este usuário permissão para executar estas tarefas, adicione esta linha ao final do arquivo `/usr/local/etc/sudoers`:

    user1   ALL=(ALL)       /usr/sbin/service webservice *

O usuário pode agora iniciar o `webservice` usando este comando:

    % sudo /usr/sbin/service webservice start

Embora essa configuração permita que um único usuário acesse o serviço webservice; No entanto, na maioria das organizações, existe uma equipe inteira da Web encarregada de gerenciar o serviço. Uma única linha também pode dar acesso a um grupo inteiro. Essas etapas criarão um grupo da Web, adicionarão um usuário a esse grupo e permitirão que todos os membros do grupo gerenciem o serviço:

    # pw groupadd -g 6001 -n webteam

Usando o mesmo comando pw(8), o usuário é adicionado ao grupo webteam:

    # pw groupmod -m user1 -n webteam

Finalmente, esta linha no arquivo `/usr/local/etc/sudoers` permite que qualquer membro do grupo webteam gerencie o `webservice`:

    %webteam   ALL=(ALL)       /usr/sbin/service webservice *

Ao contrário do su(1), o Sudo requer apenas a senha do usuário final. Isso adiciona uma vantagem em que os usuários não precisarão de senhas compartilhadas, uma descoberta na maioria das auditorias de segurança e o que por si só já ruins em todos os aspectos.

Os usuários autorizados a executar aplicativos com o Sudo só inserem suas próprias senhas. Isso é mais seguro e oferece melhor controle do que o su(1), onde a senha de `root` é inserida e o usuário adquire todas as permissões de `root`.

### Dica:

A maioria das organizações está se movendo ou migrou para um modelo de autenticação de dois fatores. Nestes casos, o usuário pode não ter uma senha para entrar. O Sudo resolve estes casos com a variável `NOPASSWD`. Adicioná-lo à configuração acima permitirá que todos os membros do grupo `webteam` gerenciem o serviço sem o requisito de senha:

    %webteam   ALL=(ALL)       NOPASSWD: /usr/sbin/service webservice *

### 13.14.1. Logando a Saída

Uma vantagem para implementar o Sudo é a capacidade de ativar o log de sessão. Usando os mecanismos de log integrados e o comando sudoreplay incluído, todos os comandos iniciados por meio de Sudo são registrados para verificação posterior. Para ativar esse recurso, adicione uma entrada de diretório de log padrão, este exemplo usa uma variável de usuário. Existem várias outras convenções de nome de arquivo de log, consulte a página de manual do sudoreplay para obter informações adicionais.

    Defaults iolog_dir=/var/log/sudo-io/%{user}

### Dica:

Este diretório será criado automaticamente após o logging ser configurado. É melhor deixar o sistema criar o diretório com permissões padrão apenas para estar seguro. Além disso, essa entrada também registra os administradores que usam o comando sudoreplay. Para alterar esse comportamento, leia e descomente as opções de log dentro do arquivo `sudoers`.

Uma vez que esta diretiva tenha sido adicionada ao arquivo `sudoers`, qualquer configuração de usuário pode ser atualizada com a solicitação para acessar o log. No exemplo mostrado, a entrada `webteam` atualizada teria as seguintes alterações adicionais:

    %webteam ALL=(ALL) NOPASSWD: LOG_INPUT: LOG_OUTPUT: /usr/sbin/service webservice *

Deste ponto em diante, todos os membros do grupo `webteam` que alteram o status do aplicativo `webservice` serão registrados. A lista de sessões anteriores e atuais pode ser exibida com:

    # sudoreplay -l

Na saída, para reproduzir uma sessão específica, procure a entrada `TSID=` e passe-a para o sudoreplay sem outras opções para reproduzir a sessão na velocidade normal. Por exemplo:

    # sudoreplay user1/00/00/02

### Atenção:

Enquanto as sessões são registradas, qualquer administrador pode remover as sessões e deixar apenas uma questão de por que elas fizeram isso. Vale a pena adicionar uma verificação diária por meio de um sistema de detecção de intrusão (IDS) ou software semelhante para que outros administradores sejam alertados sobre alterações manuais.

O `sudoreplay` é extremamente extensível. Consulte a documentação para mais informações.

Anterior | Acima | Próxima
13.13. Limites de Recursos | Principal | Capítulo 14. Jails

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.