Prática recomendada para gerenciar o acesso em uma conta compartilhada?

Question

Nossa empresa tem um servidor web para dev e cada um de nossos desenvolvedores tem uma conta de usuário. O servidor também tem uma conta para o usuário ' app '. O usuário 'app' não pertence a uma única pessoa --- é uma conta compartilhada que qualquer desenvolvedor pode usar para implantar código pronto para o controle de qualidade. O código pronto para teste é enviado para / home / app / public_html /

Estamos tentando descobrir um sistema eficaz para gerenciar o acesso a essa conta compartilhada. Atualmente, todos compartilhamos a senha do usuário do "aplicativo", o que é ruim por vários motivos.

Gostaríamos de ter um sistema em que os desenvolvedores ainda possam usar SFTP ou FTP para fazer upload de arquivos diretamente na conta de usuário 'app'. Pensamos em modificar o grupo em / home / app e sub-pastas para que os membros do grupo 'wheel' também tivessem permissão para adicionar, modificar e excluir arquivos. No entanto, você executa a questão dos arquivos enviados pelos usuários para / home / app não pertencerem a 'app', mas sim de propriedade do usuário que fez o upload deles.

Existe alguma prática recomendada para gerenciar o acesso a uma conta compartilhada?

    

Answer 1

A prática recomendada para gerenciar contas compartilhadas é bloquear a conta compartilhada.

Em vez de gerenciar o acesso a uma conta compartilhada - o que é ruim por vários motivos, você deve adicionar todos os desenvolvedores a um grupo (por exemplo, app_development ), testadores a outro grupo (por exemplo, app_testing ) etc. Depois que você tiver usuários (cada um deles usado apenas por uma única pessoa ) colocados em grupos de acordo com as tarefas e / ou tarefas que estão fazendo atualmente, conceda aos grupos permissões apropriadas para os arquivos. / p>

Para este exemplo, um desenvolvedor de software empregado para desenvolver aplicativos da web pertenceria a software_development e web_development (um desenvolvedor trabalhando em aplicativos locais pode pertencer a application_development em vez de web_development ). Um membro testador / QA da equipe pertenceria aos grupos software_testing e web_testing .

Os usuários do grupo wheel sempre têm permissão para ler e escrever via root (a menos que você esteja limitando diretamente o acesso deles ao SELinux).

sudo -i
groupadd software_development
groupadd web_development
groupadd software_testing
groupadd web_testing
mkdir -p /home/software_development/web_development/staging'

Listas de controle de acesso POSIX

Crie uma estrutura de diretórios para colaboração, dando permissão mínima para grupos

chown -R root:software_development /home/software_development
chmod 550 /home/software_development
setfacl -m g:software_development:r-x /home/software_development
setfacl -m g:software_testing:r-x /home/software_development

chown -R root:web_development /home/software_development/web_development
chmod -R 2570 /home/software_development/web_development
setfacl -R -m g:web_development:rwx /home/software_development/web_development
setfacl -R -m d:g:web_development:rwx /home/software_development/web_development
setfacl -m g:web_testing:r-x /home/software_development/web_development
setfacl -m d:g:web_testing:0 /home/software_development/web_development
setfacl -m d:g:web_testing:r-x /home/software_development/web_development/staging
setfacl -R -m d:u:root:r-x /home/software_development

1. root e qualquer pessoa nos grupos software_development ou software_testing pode entrar em /home/software_testing e ver seu conteúdo.
2. Todos os web_developers podem ver e modificar o conteúdo de /home/software_development/web_development e todos os subdiretórios (os que existem atualmente e todos os que podem ser criados no futuro).
3. Todos os web_testers podem ver o conteúdo direto de /home/software_development/web_development , mas nenhum subdiretório, exceto staging .
4. Observe que web_testing e software_testing não têm acesso de gravação, pois não precisam disso para realizar seus trabalhos.

É importante que os desenvolvedores entendam que seus projetos devem ser colocados dentro de um subdiretório de web_development (geralmente um nome de projeto: ex. web_development/project_1 , negando acesso para que os testadores vejam Quando estiver pronto para testar / controle de qualidade, eles o copiariam para o subdiretório de teste.