Como isolar usuários de hospedagem com segurança no Linux
Publicado em 12 de novembro de 2026
Um servidor compartilhado pode funcionar perfeitamente durante meses, até que um site comprometido leia um arquivo que nunca deveria acessar. É por isso que as equipes precisam isolar os usuários de hospedagem com segurança: não como um luxo reservado a grandes empresas de hospedagem, mas como uma regra básica para todo servidor que hospede mais de um site, cliente ou projeto.
O isolamento de usuários limita os danos quando um aplicativo tem um plugin vulnerável, uma senha fraca ou um arquivo enviado que acaba sendo malicioso. Ele também impede que uma conta muito ocupada deixe os sites de todos os outros lentos. O objetivo é simples: cada cliente deve ter controle suficiente para gerenciar seus próprios sites, enquanto o servidor mantém limites claros em relação a todo o resto.
O que realmente significa o isolamento de usuários de hospedagem
O isolamento não é uma única configuração. É um conjunto de camadas que funcionam em conjunto. No mínimo, uma conta de hospedagem precisa de seu próprio usuário Linux, diretório pessoal, permissões de arquivos, credenciais de banco de dados, processo PHP e regras de acesso. Uma falha em um site não deve conceder automaticamente acesso a todos os sites do servidor.
Imagine um servidor compartilhado como um prédio de apartamentos. Um usuário Linux separado é a porta do apartamento. As permissões corretas dos arquivos são a fechadura. Pools PHP-FPM separados, usuários de banco de dados e limites de recursos são as paredes, os serviços e os disjuntores. Uma camada ajuda, mas depender de apenas uma é o que transforma pequenos incidentes em longas noites.
O nível adequado de isolamento depende do que você hospeda. Alguns sites internos administrados por um único administrador de confiança têm necessidades diferentes das de um servidor de agência com 80 contas de clientes. Para clientes sem relação entre si, uma separação mais forte vale a configuração adicional e um pequeno aumento no uso de memória.
Comece com um usuário Linux por conta de hospedagem
Nunca execute todos os sites sob a mesma conta do sistema. Se todos os arquivos da Web pertencerem a um usuário genérico da Web, como `www-data`, qualquer script vulnerável capaz de gravar arquivos também poderá modificar o site de outro cliente.
Crie um usuário Linux dedicado para cada conta de hospedagem e torne esse usuário proprietário de sua própria raiz de documentos, logs, arquivos temporários e arquivos do aplicativo. Evite diretórios compartilhados com permissão de gravação sempre que possível. Um diretório que pode ser gravado por todas as contas acaba se tornando um lugar onde os problemas ficam à espera.
Defina permissões restritivas por padrão. Os diretórios de sites geralmente precisam de `755`, enquanto arquivos comuns podem usar `644`. Arquivos de configuração que contêm segredos devem ter permissões mais restritivas, geralmente `600` ou `640`, dependendo da conta de serviço que precisa lê-los. Não recorra a `777` porque uma pasta de envio de arquivos não está funcionando. Isso corrige o sintoma removendo a fechadura da porta.
A propriedade dos arquivos é tão importante quanto as permissões numéricas. Um site WordPress, por exemplo, pode precisar de acesso de gravação a `wp-content/uploads`, mas o serviço Web não deve ter permissão para reescrever o aplicativo inteiro. Conceda acesso de gravação somente aos diretórios que realmente precisam dele.
Mantenha os limites entre contas fora dos caminhos compartilhados
É tentador armazenar backups, sessões, caches ou arquivos de implantação em um local comum. Isso pode ser conveniente, até que as permissões mudem ou uma tarefa de limpeza remova os arquivos errados. Mantenha os dados de aplicativos de cada usuário no diretório pessoal dessa conta ou em outro local pertencente especificamente a ela.
Se um serviço compartilhado for inevitável, deixe o acesso explícito. Use um grupo dedicado com as permissões mais restritas necessárias, documente o motivo de sua existência e revise-o após alterações. O acesso compartilhado “temporário” costuma se tornar permanente.
Execute o PHP separadamente para cada conta
Para sites PHP, o modelo de execução é uma das escolhas mais importantes que você fará. Executar PHP por meio de um processo compartilhado significa que um site vulnerável pode herdar acesso muito além de seus próprios arquivos. Usar um pool PHP-FPM separado para cada usuário de hospedagem cria um limite mais claro: o processo de trabalho do PHP é executado como o usuário Linux da conta, com suas próprias configurações de processo e limites.
Um pool PHP-FPM por usuário também facilita a solução de problemas. Se o aplicativo de um cliente começar a consumir processos de trabalho ou memória, você poderá identificar o pool responsável, em vez de tratar o servidor como um grande mistério. Defina limites no nível do pool, como o máximo de processos filhos e os tempos limite das solicitações, de acordo com o plano da conta e as necessidades reais do aplicativo.
Há uma compensação. Mais pools PHP-FPM consomem mais memória do que um único pool compartilhado, especialmente em um servidor virtual pequeno. Para um servidor com poucos sites de baixo tráfego, escolha limites razoáveis em vez de criar pools superdimensionados. Mas não sacrifique a separação entre contas apenas para economizar uma quantidade modesta de RAM. Aumente a capacidade antes de transformar todos os clientes em uma única zona de segurança.
Para aplicativos que não usam PHP, siga o mesmo princípio. Execute Node.js, Python, Ruby ou serviços personalizados com usuários dedicados. Use serviços do sistema e arquivos de ambiente separados, em vez de uma única conta de aplicativo compartilhada com acesso a todos os projetos.
Separe bancos de dados, credenciais e segredos
O servidor de banco de dados costuma ser onde o isolamento falha silenciosamente. Usar o mesmo login de administrador do banco de dados em todos os aplicativos é conveniente durante a configuração e arriscado para sempre depois disso. Cada site deve ter seu próprio banco de dados e usuário de banco de dados, com permissões limitadas a esse banco.
Não conceda aos usuários dos aplicativos privilégios globais, permissão para criar novos usuários ou acesso a todos os esquemas, a menos que haja um motivo operacional específico. Uma credencial comprometida do CMS deve expor os dados de um aplicativo, não os registros dos clientes do servidor inteiro.
Trate os segredos com o mesmo cuidado. Armazene senhas de banco de dados, chaves de API e credenciais de e-mail em arquivos de configuração pertencentes à conta. Mantenha-os fora de diretórios públicos da Web, pastas de controle de versão e locais de backup compartilhados. Quando um funcionário, contratado ou cliente não precisar mais de acesso, remova-o em vez de presumir que as credenciais antigas continuarão inofensivas.
Controle o acesso ao shell, SSH e tarefas agendadas
Nem todo usuário de hospedagem precisa de SSH. Para um cliente que administra apenas um site básico, o gerenciamento de arquivos pelo painel ou por SFTP pode ser suficiente. Para desenvolvedores e agências, o SSH pode ser realmente útil para implantações, Composer, WP-CLI e verificações de logs. A solução prática não é bloqueá-lo em todos os casos, mas concedê-lo de forma deliberada.
Use chaves SSH em vez de senhas sempre que possível. Desative o login direto como root, evite contas de administrador compartilhadas e crie contas individuais para a equipe, para que as ações possam ser rastreadas. Se um usuário precisar apenas transferir arquivos, considere restringir a conta a SFTP. Se precisar de um shell, certifique-se de que não possa ler os diretórios pessoais de outros usuários nem usar caminhos arriscados de escalonamento de privilégios.
As tarefas do cron merecem a mesma atenção. Execute cada tarefa agendada como o usuário proprietário, não como root nem sob uma conta Web compartilhada. Uma tarefa do cron com falhas pode encher um disco, enviar milhares de e-mails ou executar repetidamente um script que consome muitos recursos. Defina limites claros e revise as tarefas que não são alteradas há muito tempo.
Defina limites de recursos para cada conta
A segurança e a estabilidade se encontram no controle de recursos. Uma conta pode afetar todas as outras sem invadir seus arquivos, simplesmente esgotando a CPU, a memória, os processos, o espaço em disco ou a quantidade de inodes. Os limites de recursos mantêm um pico de tráfego, uma consulta incorreta ou um loop acidental restrito à conta que o causou.
Use os controles compatíveis com seu ambiente Linux, como limites de processos, configurações de pools PHP-FPM, cotas de disco e cgroups no nível do sistema. Monitore o uso real antes de definir valores. Um limite baixo demais pode prejudicar o tráfego legítimo de comércio eletrônico, importações em segundo plano ou backups. Um limite alto demais não é bem um limite.
No mínimo, acompanhe a carga da CPU, a pressão sobre a memória, o uso do disco, o uso de inodes, a quantidade de processos, as falhas de login e o volume de e-mails enviados por conta, sempre que possível. O monitoramento em tempo real transforma “o servidor parece lento” em uma resposta útil: qual usuário, qual processo e quando o problema começou.
Adicione medidas de contenção, mas não as confunda com uma solução
Ambientes chroot, contêineres e virtualização podem criar limites mais fortes entre usuários. Os contêineres são especialmente úteis quando os clientes precisam de ambientes de execução personalizados, dependências ou controle no nível do serviço que, de outra forma, entrariam em conflito em um único sistema operacional. As máquinas virtuais oferecem uma separação ainda mais forte, com um custo operacional maior.
Essas ferramentas ajudam, mas não substituem permissões, aplicação de patches ou credenciais seguras. Um contêiner executado como root com uma montagem gravável do host não é um limite seguro entre clientes. Da mesma forma, um ambiente chroot pode reduzir o acesso visível ao sistema de arquivos, mas talvez não contenha todos os problemas no nível do aplicativo. Escolha a camada adequada ao risco e configure-a com cuidado.
Uma lista prática de verificação do isolamento
Antes de adicionar uma nova conta de hospedagem, verifique estes itens essenciais:
- A conta tem seu próprio usuário Linux, diretório pessoal, arquivos do site, logs e caminhos temporários.
- O PHP ou outro ambiente de execução de aplicativos é executado com esse usuário, e não com uma identidade de serviço compartilhada.
- A conta tem credenciais de banco de dados separadas, com acesso somente ao próprio banco de dados.
- A propriedade e as permissões dos arquivos impedem leituras e gravações entre contas.
- O SSH, o SFTP, as tarefas do cron, os backups e os limites de recursos são concedidos e configurados especificamente para essa conta.
Um painel de controle deve tornar esses limites visíveis, em vez de escondê-los atrás de jargão de servidor. O FASTPANEL ajuda os administradores a gerenciar contas, domínios, bancos de dados e atividades do servidor em um único espaço de trabalho claro, facilitando a manutenção de um bom isolamento à medida que o servidor cresce.
Continue verificando após a configuração
O isolamento não é uma tarefa que você conclui uma vez e depois esquece. Novos plugins, scripts de migração, alterações manuais de permissões e correções apressadas de suporte podem enfraquecê-lo com o tempo. Revise a propriedade das contas após migrações de sites, procure arquivos com permissão de gravação para todos, remova usuários inativos, aplique atualizações de segurança e teste os backups sem conceder aos processos de backup acesso desnecessário a todas as contas.
A melhor configuração é aquela que sua equipe consegue entender e manter sob pressão. Defina um limite claro para cada usuário, mantenha as exceções raras e documentadas e deixe o servidor fazer discretamente o trabalho de impedir que um dia ruim em um site se torne um problema para todos.