Saltar para o conteúdo 
CageFS por site Separa rigorosamente os sites individuais dentro de uma conta de alojamento partilhado, limitando assim o risco de propagação lateral após um ataque. Vou explicar a nova arquitetura de segurança, apresentar cenários práticos de utilização e explicar como podes gerir vários projetos de forma segura numa única conta.
Pontos centrais
- Isolamento do site: A separação adicional no âmbito de uma conta reduz os riscos colaterais.
- CloudLinux: Alargamento do conceito CageFS ao nível do domínio.
- WordPress: Executar várias instâncias em paralelo de forma segura.
- Recursos: Os limites para CPU/RAM/E/S complementam a separação da visualização de ficheiros.
- Prática: Ativação por domínio e uma estratégia clara em termos de direitos e percursos.
O que o „Per-Site CageFS“ faz, concretamente
A extensão isola cada um Domínios dentro de um CageFS de utilizador já existente, para que cada site veja apenas os seus próprios ficheiros e processos. Desta forma, evito que um projeto comprometido aceda a ficheiros de configuração, ficheiros carregados ou chaves de outros sites na mesma conta. De acordo com CloudLinux O blogue (anúncio da versão beta) explica que o CageFS por site reforça o isolamento entre sites dentro da mesma conta de utilizador, reduzindo assim o risco de contaminação cruzada. Para mim, a vantagem é evidente: consigo segmentar de forma clara as contas da agência, as configurações multisite e os ambientes de teste, sem alterar a estrutura de alojamento. Esta explicação fornece uma visão geral rápida do princípio do CageFS: Sistema de ficheiros CageFS, no qual se baseia o isolamento por local.
Por que razão o isolamento de contas, por si só, não é suficiente
Uma conta reúne frequentemente várias Projectos – cerca de duas lojas, três blogs e um ambiente de teste. Se um exploit atacar um plugin vulnerável, um atacante pode, sem segmentação adicional, aceder a diretórios adjacentes e colocar aí mais cargas maliciosas. É precisamente aqui que o Per-Site CageFS restringe o acesso ao sistema de ficheiros e aos processos de tal forma que cada site funciona como se estivesse numa Prisão funciona. Especialmente no caso de instâncias separadas do WordPress com um utilizador PHP comum, isso criaria, de outra forma, uma possibilidade de escaladas, que eu elimino com o isolamento de domínios. Isso reduz os danos consequentes, simplifica a análise forense e permite planear as recuperações mais rapidamente.
Eis como funciona, do ponto de vista técnico, o isolamento do site
O CloudLinux encapsula, através do CageFS, um ambiente virtual por utilizador sistema de ficheiros; a camada «Per-Site» alarga isto aos limites do domínio. Cada domínio ativado recebe uma área de visibilidade separada dentro do CageFS do utilizador, incluindo percursos restritivos, diretórios temporários próprios e execução de scripts isolada. Desta forma, ficheiros wp-config.php, pastas de upload ou ficheiros de chaves de terceiros desaparecem da perspetiva do site atacado. As tarefas cron, o PHP e, se for o caso, os comandos SSH acedem às mesmas bibliotecas do sistema, mas apenas visualizam as áreas atribuídas Subconjuntos do sistema de ficheiros. De acordo com a documentação, é possível ativar ou desativar a separação por domínio, o que me proporciona um controlo muito preciso para as instâncias em produção, de teste e de pré-produção.
Comparação: isolamento de contas, CageFS por site e contentores
Para fazer a escolha de forma estruturada, comparo três opções comuns Modelos em função do nível de isolamento, do esforço envolvido e da compatibilidade. O isolamento de contas resolve a separação entre clientes, mas deixa em aberto as fronteiras internas entre sites. O CageFS por site colmata essa lacuna, tanto do ponto de vista do sistema de ficheiros como dos processos. Os contentores criam limites rígidos, mas exigem frequentemente mais manutenção e ajustes. Esta análise fornece uma classificação fundamentada do isolamento de processos Comparação entre Chroot, CageFS e Jails.
| Abordagem | Separação entre contas | Separação entre sites na conta | Compatibilidade (PHP/CGI/SSH/Cron) | Despesas de funcionamento |
|---|---|---|---|---|
| Isolamento de contas (clássico) | Elevado | Baixa | Muito bom | Baixa |
| CageFS por site | Elevado | Médio a elevado | Muito bom | Baixo a médio |
| Contentores por local | Muito elevado | Muito elevado | Bom a muito bom | Médio a elevado |
Em ambientes de alojamento partilhado, o CageFS por site oferece uma combinação eficaz de controlo preciso Separação e com poucas alterações, uma vez que os scripts, em regra geral, continuam a funcionar sem alterações. Desta forma, protejo o ponto fraco mais comum: vários sites independentes sob uma única conta de utilizador.
Na prática: gerir várias instâncias do WordPress de forma segura
Separo cada instância do WordPress com a função ativada Isolamento de domínios e defino conjuntos próprios de PHP-FPM para cada site, para que os registos, o opcache e os limites possam ser atribuídos de forma clara. Além disso, defino SALTs/KEYS próprios para cada site no ficheiro wp-config.php e impedo qualquer acesso cruzado através de direitos de ficheiro e equivalentes ao open_basedir. Guardo os ficheiros carregados estritamente dentro da respetiva raiz de documentos e proíbo diretórios globais de carregamento partilhados. Durante as implementações, mantenho os caminhos temporários dentro do próprio site e elimino imediatamente os artefactos de compilação, para que não fiquem pontos de vulnerabilidade desnecessários. Para as caches do Composer ou do NPM, utilizo caches locais do site Diretórios, para que não surjam efeitos colaterais.
Desempenho e gestão de recursos em sinergia
O CageFS por site trata da visualização dos ficheiros; o Desempenho Asseguro-me de que existem limites para a CPU, a RAM, as E/S e os processos, tanto ao nível da conta como do pool. Desta forma, evito que um site gere demasiada carga devido a plugins defeituosos e abrande toda a conta. Em muitas configurações, isto está integrado em quotas LVE ou semelhantes, que ajusto com precisão por pool ou conta. Associo isto à limitação de pedidos no servidor web ou no WAF, para que os picos de tráfego sejam geridos de forma ordenada. Esta combinação de isolamento e quotas aumenta a segurança dos serviços e a previsibilidade Distribuição da carga.
Cadeia de proteção: O que o CageFS por site não substitui
O isolamento impede visões transversais, mas considero as atualizações, Endurecimento continua a aplicar de forma rigorosa as diretrizes relativas ao PHP e às palavras-passe seguras. A autenticação multifator (MFA) para inícios de sessão de administrador, os direitos mínimos sobre ficheiros e os filtros de upload continuam a ser obrigatórios. Um WAF, limites de taxa e registo contínuo cobrem vias adicionais que a simples separação de acesso a ficheiros não controla. Além disso, verifico regularmente as tarefas Cron e os tokens de integração, que os atacantes muitas vezes se esquecem de remover. Para saber mais sobre a interação entre a separação de clientes e o reforço de segurança, consulte este guia sobre Segurança do alojamento partilhado, que sublinha essa linha de pensamento.
Implementação e obstáculos típicos
Ativo o isolamento de domínios de forma específica para cada website e, em seguida, testo os acessos via SSH, Cron e PHP em condições reais. Os caminhos absolutos nos scripts de implementação ou nos plugins podem causar problemas, por isso opto por caminhos relativos ou variáveis. Evito ligações simbólicas entre projetos, porque enfraquecem o princípio de segregação; prefiro adicionar as bibliotecas necessárias ao repositório de cada site. Para as cópias de segurança, defino arquivos separados e guardo os registos por domínio, para que a recuperação e a análise forense se mantenham organizadas. No que diz respeito aos direitos de acesso, os valores 640 para ficheiros e 750 para pastas têm-se revelado eficazes, além de Proprietário adequado ao respetivo pool de PHP.
Análise custo-benefício para agências e freelancers
Calculo o ganho em termos de segurança em relação ao tempo de gestão e aos potenciais custos de inatividade que um incidente transversal provocaria, tendo em conta Euro-Base. Muitas vezes, apenas algumas horas de resposta a incidentes custam significativamente mais do que um pequeno custo adicional mensal para um melhor isolamento. Para contas de agências com vários projetos de clientes, a segmentação reduz sensivelmente o risco de responsabilidade civil e de reputação. Além disso, os processos de cópia de segurança e restauração decorrem de forma mais organizada, uma vez que posso restaurar sites individuais com precisão. No geral, o CageFS «por site» contribui para uma maior fiabilidade Gestão operacional com processos previsíveis.
Lista de verificação: Quando o CageFS por site se torna obrigatório
Ativo o isolamento de domínios assim que houver vários Instalações funcionam numa única conta e têm ciclos de atualização diferentes. Outro aspeto importante: equipas de projeto separadas ou acessos de administrador externos, que aumentam o risco de intervenções não intencionais. Os elevados volumes de upload, os conversores de ficheiros ou o processamento de imagens justificam ainda mais a separação, uma vez que é aqui que muitas vezes surgem pontos de vulnerabilidade. Requisitos de conformidade diferentes (por exemplo, clientes, mercados, proteção de dados) também apontam para segmentos mais específicos. Quem opera os ambientes de preparação, teste e produção em paralelo beneficia de domínios de erros claramente separados e de uma Forense.
Requisitos e compatibilidade na prática
Antes de colocar o Per-Site CageFS em produção, verifico o ambiente de execução: o handler PHP utilizado (por exemplo, PHP-FPM, lsapi), o servidor web ativo, a integração disponível com o painel de controlo e a forma como as tarefas Cron e as sessões SSH são geridas. Em ambientes partilhados típicos, as aplicações continuam a funcionar sem alterações no código. Certifico-me de que existe uma raiz de documentos própria para cada domínio, que os caminhos são únicos (por exemplo, /home/user/sites/projeto-a/public) e que cada site dispõe de um pool dedicado de PHP-FPM. Para as tarefas Cron, utilizo crontabs próprias por domínio ou — quando o painel as agrupa — prefixos e caminhos de registo claros, para que as tarefas permaneçam dentro do seu Prisões trabalho.
Separar claramente bases de dados, caches e sessões
A visualização dos ficheiros é apenas uma parte. Estendo essa separação até à base de dados e aos caches. Por cada site, crio uma base de dados própria e um utilizador de base de dados próprio com direitos mínimos. Para caches de objetos ou de páginas (por exemplo, Redis, Memcached), utilizo instâncias separadas por site ou, pelo menos, prefixos de chave e bases de dados/espaços de nomes dedicados. As sessões PHP são armazenadas em caminhos próprios de cada site; defino o `session.save_path` separadamente para cada pool do FPM. Se utilizar uma fila central ou um backend de pesquisa, separo os índices e os tópicos por site. Este princípio de „separação até ao último quilómetro“ impede que os incidentes se propaguem através de sistemas secundários.
CI/CD e implementações em isolamento
Nas pipelines de compilação, faço do isolamento a regra: existe uma tarefa de implementação específica para cada site, que acede apenas ao diretório do site. Descompacto os artefactos na raiz do domínio, executo em seguida as correções de proprietário/grupo e invalido exclusivamente as caches afetadas. Os comandos WP-CLI são executados no respetivo contexto CageFS, para que não afetem projetos externos. Mantenho as variáveis de ambiente separadas por site; os segredos permanecem nos ficheiros de configuração próprios de cada site ou no armazenamento de segredos do painel. Para garantir um tempo de inatividade zero, utilizo trocas atómicas de ligações simbólicas dentro dos limites do domínio (por exemplo, current/releases), mas tenho o cuidado de garantir que as ligações simbólicas não apontem para projetos vizinhos. As verificações pós-implantação (estado de funcionamento, verificação de erros 404/500, verificação de direitos) são obrigatórias para cada site.
Monitorização, registo e análise forense
Separo os registos de forma sistemática: registos de acesso/erro por domínio, registos próprios de PHP e Cron, incluindo rotações e períodos de retenção. Em caso de incidente, consigo assim reconstruir a cronologia de um único site, sem ter de vasculhar toda a conta. Além disso, recorro a verificações de integridade de ficheiros (somas de verificação de diretórios principais), registos de auditoria distribuídos para ações administrativas e ficheiros «canary» simples, que detetam manipulações numa fase precoce. Para os alertas, muitas vezes bastam valores-limite: aumentos repentinos nos erros 500, tamanhos de upload invulgares, ocupação de inodes em forte crescimento ou arranques excessivos de workers PHP. Associo estes sinais a manuais de intervenção claros: bloquear o site, verificar as cópias de segurança, salvaguardar os artefactos e reiniciar num âmbito isolado.
Casos especiais do WordPress: Multisite, plugins MU e fluxos de upload
No caso do WordPress Multisite, tenho de ponderar: uma instalação Multisite beneficia menos do CageFS por site, uma vez que vários sites partilham deliberadamente uma base de código e uma estrutura. Se precisar de limites mais rigorosos (equipas independentes, caches separadas, análise forense clara), prefiro configurar instâncias individuais e isolá-las. Distribuo plugins MU, drop-ins ou bibliotecas globais «Must-Use» apenas internamente no site e evito pastas partilhadas. Os fluxos de trabalho de multimédia (CDN, otimização de imagens, conversores) decorrem dentro da «jaula» do domínio; excluo os uploads de um site para diretórios de outro. Se uma equipa pretender partilhar pipelines de ativos, replico-os por site ou encapsulo-os num pacote que é integrado no respetivo repositório.
Percurso de migração: do sistema monolítico à conta segmentada
Muitas contas começam com uma pasta `public_html` grande e vão crescendo ao longo do tempo. Eu sigo cinco passos: 1) Fazer um inventário: que sites, domínios, tarefas cron, bases de dados e chaves secretas existem? 2) Definir a estrutura de caminhos: para cada site, uma pasta raiz, temporária, de registos e de cópias de segurança próprias. 3) Definir os pools do PHP-FPM por domínio e estabelecer limites. 4) Mover ficheiros, ajustar direitos de acesso, limpar caminhos absolutos e inclusões. 5) Ativar o CageFS por site, realizar testes sob carga e ativar a monitorização. Entretanto, mantenho uma estratégia de reversão pronta (instantâneos, cópias de segurança separadas). Após a transição, verifico se ferramentas como o WP-CLI, o Composer, os processos de imagens e as tarefas Cron estão a funcionar no âmbito correto e, se necessário, ajusto as variáveis de caminho.
Imagens de erros e resolução de problemas
- Erros 403/404 após a ativação: na maioria das vezes, as regras de reescrita ou as inclusões remetem para caminhos fora da raiz do domínio. Corrijo os caminhos para variantes relativas ou utilizo variáveis.
- O Composer/NPM falha: as caches globais não são visíveis. Defino diretórios de cache locais ao site e ajusto as variáveis HOME/TMP na implementação.
- O WP-CLI não encontra o ficheiro wp-config.php: a execução não está na raiz do domínio. Defino o diretório de trabalho corretamente ou indico o caminho explicitamente.
- Cronjobs inativos: os utilizadores Cron ou os caminhos não estão definidos por domínio. Verifico as variáveis de ambiente, os caminhos dos ficheiros binários e os destinos dos registos dentro do «Site-Jail».
- Falhas nos uploads: session.save_path ou tmp_dir apontam para o diretório errado. Atribuo caminhos temporários locais ao site para cada pool do FPM.
- Falta uma biblioteca partilhada: a ligação simbólica para o projeto vizinho está bloqueada. Replico a biblioteca em cada site ou integro-a como um pacote na implementação.
Governança e modelo de acesso
Mesmo que, do ponto de vista técnico, tudo esteja separado, a questão dos acessos mantém-se. Atribuo acessos SSH/SFTP dedicados a cada site ou restrinjo os acessos ao painel ao domínio em questão. As equipas de programadores e das agências recebem apenas as chaves e as autorizações de que realmente necessitam. Para situações de emergência, disponho de um processo de «break-glass» (direitos temporariamente alargados, registo completo, revogação posterior). Nas auditorias, documento, por site: caminhos, pools, limites, responsáveis, atribuições RBAC e cópias de segurança. Desta forma, a segmentação mantém-se robusta não só do ponto de vista técnico, mas também organizacional.
Brevemente resumido
O CageFS por site complementa a separação de utilizadores existente com uma website-nível, reduzindo assim eficazmente o risco de movimentos laterais. Considero que esta é uma medida prática, uma vez que muitas contas agrupam vários projetos independentes. A combinação entre a separação da visualização de ficheiros e os limites de recursos traz ordem ao desempenho, à segurança e ao funcionamento. Quem hospeda várias instâncias do WordPress ou de lojas online ganha tempo na deteção de erros, nas cópias de segurança e na recuperação após incidentes. Com direitos claros, atualizações, autenticação multifator (MFA) e registo de atividades, cria-se uma estrutura sustentável Corrente de segurança, o que torna o alojamento partilhado significativamente mais robusto.
