Qual é o melhor método para definir uma lista de comandos e acesso que seria necessário para administrar um determinado aplicativo?

Question

Minha equipe precisa instalar e administrar um aplicativo muito grande no Red Hat 5.7, e precisa ser capaz de fazer isso como root. Durante o projeto, a equipe de suporte do Unix (que é responsável pelo suporte do sistema operacional) nos concede (à equipe de suporte do aplicativo) sudo todo o acesso para que possamos fazê-lo. No entanto, nossa política interna determina que, uma vez que o servidor tenha sido operacionalizado (oficialmente suportado pela nossa equipe Unix e seja ativado), ninguém, a não ser eles, deverá ter acesso root.

Para poder apoiar definitivamente o aplicativo em questão, minha equipe precisaria fornecer uma lista completa de comandos e requisitos de acesso à equipe do Unix para que eles pudessem nos conceder acesso sudo a todos esses comandos individualmente. O fornecedor do aplicativo não suporta esse tipo de administração restritiva e não possui uma receita definida para fazer isso adequadamente sem problemas. Será praticamente uma tentativa e erro.

Dito isso, qual seria o melhor método para listar todos os comandos necessários que precisaríamos executar e listar todos os acessos a arquivos / diretórios que precisaremos?

O aplicativo está sendo instalado como root, todos os arquivos sob seu diretório de instalação são atualmente de propriedade de root ou pelo usuário do serviço (usuário criado para o serviço do aplicativo).

Eu comecei listando todos os arquivos com perms u + x, e obtive uma contagem impressionante de 2801 arquivos após uma instalação básica, não modificada. Isso exclui os scripts init em /etc/init.d e outros comandos do sistema (como chown, chmod, ps, kill etc ...) que talvez tenhamos que executar também.

Para mim, parece quase impossível (ou pelo menos extremamente difícil) fazer isso sem encontrar problemas mais tarde. Eu entendo que essa não é uma pergunta fácil e que pode haver muitas maneiras de fazer isso, mas gostaria, no entanto, de ouvir a opinião da comunidade sobre isso.

    

Answer 1

Primeiro, gosto da sua abordagem inicial de encontrar todos os arquivos executáveis. Parece que o fornecedor tem um mau hábito de marcar tudo o que é executável, no entanto. Eu realmente espero que não haja 2.801 binários no produto! Você provavelmente poderia passar todos esses arquivos através de file e ver quais são realmente binários, scripts, etc. Isso deve restringir o escopo.

Em segundo lugar, inclua definitivamente o que for necessário para parar e iniciar o aplicativo. Parece que o fornecedor instala um script de inicialização, então provavelmente é tudo que você precisa. Também acesse less de todos os arquivos de log, se eles estiverem armazenados em um local do sistema, como / var / log e não legíveis por usuários sem privilégios.

Finalmente, veja se eles podem configurar as regras de sudo de modo a permitir que sua equipe execute comandos específicos como o usuário do serviço. Por exemplo, você pode querer executar vim como este usuário para modificar os arquivos de configuração. Se eles quiserem ser mais restritivos, dê uma olhada nas convenções de nomenclatura dos arquivos de configuração. Talvez uma regra que permita vim *.conf (ou um glob ou globs mais complexo).

Outro pensamento que vem à mente é ter um claro caminho de escalonamento no caso de um problema futuro. Você tem alguém para quem você pode paginar se você precisar de algo feito em uma pitada? Eles estarão monitorando a saúde do sistema? Eles podem ter sua equipe notificada em caso de falha do aplicativo?

    

Answer 2

Aqui estão alguns pontos que podem ser considerados úteis para você (espero):

1. Uma interface da Web impedirá a necessidade de ter acesso ssh e, portanto, privilégios de sudo.
2. Uma vez que o aplicativo está sendo executado corretamente, deve ser responsabilidade da equipe do administrador do sistema certificar-se de que ele esteja ativo e em execução, não dos desenvolvedores.
3. Você pode solicitar as permissões para modificar os arquivos de configuração do aplicativo e alguns arquivos de dados, se houver. Não há necessidade de modificar todos os arquivos / pastas do aplicativo.
4. Se este for um servidor de teste, mais flexibilidade deve ser concedida aos desenvolvedores para poder depurar facilmente o aplicativo.