Isolamento por site
O isolamento é a diferença entre um incidente e uma interrupção. Cada site que hospedamos roda dentro de uma gaiola LVE do CloudLinux em nível de kernel com seus próprios limites de CPU, RAM, E/S e processos, sua própria visão de sistema de arquivos CageFS, sua própria versão do PHP e seu próprio limitador de banco de dados. Um site que é atacado, comprometido ou que simplesmente está executando uma consulta pesada é contido onde está — e a base de isolamento está incluída em todos os planos, sem ser vendida a você como um upgrade. Disponibilidade: a limitação de banco de dados por site e as estatísticas de recursos por site estão em desenvolvimento ativo e ainda não estão disponíveis. Tudo o mais descrito aqui está ativo hoje.
A frota de workers executa o CloudLinux OS, que estende o suporte a múltiplos tenants diretamente até o kernel. Cada site recebe um Lightweight Virtual Environment — um LVE — que constitui um limite rígido em vez de uma convenção educada. Nada que um site faça dentro de sua cage pode ultrapassar o orçamento de outra pessoa.
O LVE limita o CPU, RAM, IO, IOPS, processos e processos de entrada de cada site de forma independente. Quando um site ultrapassa o seu limite, ele é contido dentro da sua própria "cage" — a falha é registrada para esse site e os sites vizinhos continuam funcionando sem serem afetados.
Um plugin preso em um loop, um trabalho cron mal escrito ou um crawler sobrecarregando um endpoint atingem primeiro os limites de processos e de processos de entrada do próprio site. Um único site simplesmente não pode consumir a máquina.
Como os processos de entrada são limitados por cage, um ataque direcionado a um site não pode abrir trabalho ilimitado no host. A limitação de conexões e requisições do LiteSpeed e o firewall de rede do Imunify360 atuam na frente disso, de modo que o ataque continua sendo um problema apenas do alvo.
Cada falha de LVE é registrada por site e integrada ao motor de políticas da plataforma, que pode ajustar os limites de forma automática, para mais ou para menos. Você descobre o motivo e o momento em que um site sofreu limitação — de forma gradual, reversível e registrada.
O isolamento de recursos impede que um site seja barulhento. O isolamento do sistema de arquivos impede que ele seja intrusivo. O CageFS oferece a cada inquilino uma visão privada e restrita da máquina.
Sob o CageFS, um locatário vê seus próprios arquivos e um conjunto mínimo e higienizado de binários do sistema — e não consegue ver outros locatários, os sites de outros locatários ou arquivos confidenciais do sistema. A falha típica de hospedagem compartilhada, em que uma conta comprometida se torna um ponto de leitura sobre todas as outras contas na máquina, é eliminada no nível do kernel.
Isso importa mais no dia em que algo dá errado. Se um site for comprometido — por meio de um plugin desatualizado, uma credencial roubada, um tema vulnerável — o CageFS é o que mantém o raio de impacto restrito a essa única cage. Nossa especificação de segurança é rigorosa quanto aos termos: o CageFS contém violações. Contenção é a promessa honesta, e é ela que decide se um incidente é a limpeza de um único site ou de toda a frota.
Os backups reforçam a mesma barreira. Os backups por site são imutáveis, armazenados fora do local e isolados da frota em execução, com restaurações testadas, para que até mesmo um comprometimento na pior das hipóteses em um site tenha um caminho de recuperação limpo e independente, que não dependa do estado da máquina em que ele estava sendo executado.
O isolamento da camada web é apenas metade da história. Em uma frota do WordPress, o que mais frequentemente faz um servidor parecer lento são as consultas de um site, e não o tráfego dele. Isso é tratado explicitamente.
O CloudLinux MySQL Governor limita o uso de banco de dados por site, para que as consultas pesadas de um site não desacelerem o servidor para todos os outros. É o controle anti-lentidão, e ele é executado quer o site barulhento perceba que está sendo contido ou não.
A frota executa MariaDB (ou Percona), escolhido para cargas de trabalho do WordPress em vez de herdado por padrão, com o Governor atuando no topo como a camada de justiça por locatário.
Um cache de objeto Redis por site absorve leituras repetidas antes que cheguem ao banco de dados, o que reduz a pressão que o Governor precisa arbitrar em primeiro lugar. O cache e o isolamento funcionam como um único sistema.
O CloudLinux alt-PHP oferece a cada site seu próprio seletor de versão do PHP, suas próprias extensões (imagick, gd, redis e o restante) e suas próprias configurações endurecidas — com workers LSAPI limitados pelos LVE limits desse site, de modo que a concorrência do PHP faz parte da jaula em vez de ser uma fuga dela.
O isolamento decide até onde um problema se propaga. A imposição decide o que acontece a seguir. Substituímos a suspensão brusca de liga/desliga por uma máquina de estados, impulsionada por fluxos de trabalho duráveis e aplicada no worker por meio de LiteSpeed, LVE e Imunify.
O isolamento não é um recurso de plano que aparece três níveis acima. Ele é uma propriedade da infraestrutura, portanto é idêntico quer você esteja executando uma loja WooCommerce ou dois mil sites de rede.
Redes em massa e PBNs rodam sobre a mesma infraestrutura LVE e CageFS, combinadas com rotação de contas de CDN conscientes de footprint e entrega de HTML estático. O isolamento é o que torna a alta densidade segura: os sites compartilham uma frota sem compartilhar o destino.
Sites WordPress, WooCommerce, PHP, estáticos e Node ganham o mesmo isolamento, além de total autonomia — sua própria versão e extensões do PHP, cache de objetos Redis, ambiente de homologação e publicação para produção.
Para cargas de trabalho que precisam de um limite mais forte do que o padrão otimizado para densidade, o isolamento completo de um container por site é oferecido como uma variante do driver de provisionamento: mesmo motor, mesmo painel de controle, posicionamento diferente, com maior consumo de recursos.
O isolamento LVE e CageFS, o WAF proativo e a varredura de malware estão incluídos para todos os clientes, porque um site infectado ou fora de controle ameaça seus vizinhos e a nossa reputação de IP. A limpeza de malware em um clique e os níveis de proteção avançados são complementos pagos — a base não é.
A tentação comercial na hospedagem é vender segurança em níveis: colocar os clientes baratos em um servidor compartilhado com limites flexíveis, e cobrar daqueles que se importam por um limite isolado. Nós não fazemos isso, porque o cliente que não pagou pelo isolamento é exatamente aquele cuja página comprometida se torna o incidente de todos os outros.
Hospedamos mais de 650.000 sites em todo o mundo, em uma frota onde a densidade é toda a proposta econômica. Isso só funciona se o isolamento subjacente for incondicional. Gaiolas em nível de kernel, uma visão de sistema de arquivos privado, limitação de banco de dados por site e PHP por site são o preço de operar nessa escala sem destino compartilhado — por isso, eles estão ativados para todos, em todos os planos, desde o primeiro site que você implanta.
O resultado é uma plataforma que se comporta de maneira previsível durante os dias ruins de outras pessoas. Por trás dela, há uma garantia de 99,99% de tempo de atividade (uptime), backups externos imutáveis por site com restaurações testadas e um registro de auditoria completo de cada ação de imposição realizada em seus sites.
O isolamento foi projetado especificamente para impedir isso. O LVE limita CPU, RAM, IO, IOPS e processos por site, o MySQL Governor restringe o uso de banco de dados por site e os trabalhadores LSAPI são limitados pela própria "jaula" do site — portanto, o pico de tráfego de um vizinho ou uma carga pesada de consultas é contido pelo limite dele, e não pelo seu. Cada falha é registrada por site, e o mecanismo de políticas pode apertar os limites de um site barulhento automaticamente.
A resposta honesta é contenção em vez de garantia. O CageFS oferece a cada inquilino uma visão de sistema de arquivos isolada — um inquilino comprometido não pode ver outros inquilinos, seus sites ou arquivos confidenciais do sistema —, e um caso confirmado de malware ou phishing move esse site para a quarentena: offline, arquivos bloqueados, sem execução, isolado para perícia. É isso que limita o raio de explosão. Paralelamente, executamos varredura de malware e um WAF proativo em cada site, além de backups externos imutáveis por site com restaurações testadas, para que a recuperação nunca dependa do estado da máquina envolvida.
Está incluído em todos os planos. O isolamento LVE e CageFS, o WAF proativo e a verificação de malware são padrão para todos os clientes, porque um site infectado ou fora de controle ameaça seus vizinhos e nossa reputação de IP — não podemos razoavelmente deixar isso como opcional. O que é vendido como um complemento é a limpeza e remediação de malware com um clique, além de níveis de proteção avançados, como regras de WAF aprimoradas, verificação prioritária, gerenciamento de bots e níveis mais altos de DDoS.
Ele é limitado (throttled) dentro da sua própria gaiola, em vez de ser desativado. Limitado significa limites de LVE mais rígidos e controle de taxa (rate limiting), com o site ainda no ar e funcionando, e ele se recupera automaticamente assim que a causa é resolvida. Você é notificado sobre o motivo, a transição é registrada com suas evidências e é possível recorrer. Se a carga for um crescimento genuíno em vez de uma falha, a solução é um plano maior, e não uma limitação permanente.
Não — um site suspenso exibe uma página de espera com marca e motivo específico (faturamento, manutenção ou abuso) para parecer intencional, e não quebrado. A suspensão é revertida mediante pagamento, correção ou recurso. A quarentena é mais rigorosa e funciona de outra forma: ela é revertida apenas após a limpeza e a revisão, nunca de forma automática.
No Zinn® Managed WordPress, sim — o CloudLinux alt-PHP oferece a cada site seu próprio seletor de versão do PHP, suas próprias extensões como imagick, gd e redis, e suas próprias configurações fortificadas, todas limitadas pelos limites LVE daquele site. O Footprint-Free Hosting executa deliberadamente uma configuração por site mais padronizada e restrita, porque a variedade de configurações é, por si só, uma pegada (footprint).
Sim. O CloudLinux LVE e o CageFS são o padrão optimizado para densidade em ambas as linhas de produtos. Para cargas de trabalho que necessitam de um limite mais rígido, a isolação completa de contentor por site é oferecida como uma variante de driver de provisionamento — o mesmo motor e plano de controlo com posicionamento diferente, trocando sobrecarga por uma separação mais forte.
Sim. O Footprint-Free Hosting começa com um teste de 14 dias sem cartão, cobrindo até cinco sites — sem dados de pagamento, sem compromisso. Implante alguns sites, envie um pouco de tráfego para eles e veja como as cages se comportam antes de decidir.
Comece uma avaliação gratuita de 14 dias sem cartão no Footprint-Free Hosting — até cinco sites, sem dados de pagamento, sem compromisso. O isolamento em nível de kernel, o WAF proativo e a varredura de malware estão incluídos desde o primeiro deploy.
Comece grátis