Vender cloud significa colocar clientes diferentes na mesma infraestrutura física. É isso que torna o negócio viável — sem compartilhamento, não há economia de escala nem margem. E é isso que cria a obrigação mais séria do provedor: garantir que um cliente não alcance o dado, o tráfego ou o desempenho do outro. Isolamento não é um recurso que se liga; é o resultado de decisões em cinco camadas distintas, e falhar em qualquer uma delas compromete o conjunto.

As cinco camadas

A camada mais frequentemente subestimada é a de identidade. Muito provedor cuida bem de rede e storage e deixa o painel de controle com uma falha de escopo — o cliente troca um identificador na chamada de API e recebe dado de outro. É um dos vazamentos mais comuns e mais graves, porque não exige nenhuma habilidade técnica para ser descoberto por acidente.

Computação: cliente recebe VM

Já tratamos disso em detalhe ao comparar container e máquina virtual, e a conclusão vale ser repetida aqui como regra de arquitetura de provedor: carga de cliente roda em VM.

Container compartilha o kernel do host. Enquanto todos os containers são administrados por você, o risco é gerenciável. No momento em que existe root de cliente lá dentro, uma vulnerabilidade de escalonamento no kernel deixa de ser um problema daquele cliente e passa a ser um problema de todos os que compartilham o nó.

A economia de densidade do container é real, e não paga o risco. Use container para os seus próprios serviços internos.

Rede: o erro mais comum é a rede plana

O desenho padrão de quem começa é uma bridge única com todas as VMs de todos os clientes. Elas se veem, e isso significa varredura de portas, falsificação de ARP para interceptar tráfego e movimentação lateral a partir de uma VM comprometida.

O que precisa existir:

1. Segmento próprio por cliente — VLAN, ou VNet sobre VXLAN quando o volume de clientes exige. Cada cliente numa rede em que só ele está.
2. Filtragem no nível da VM, aplicada pela plataforma e não configurável pelo cliente, impedindo que ele forje endereço de origem ou de MAC.
3. Proteção do plano de gestão. A rede de gestão do cluster e a de storage jamais devem ser alcançáveis a partir de VM de cliente. Esse é o caminho de escalada mais direto que existe.
4. Controle de tráfego entre clientes, negado por padrão. Se dois clientes precisam se comunicar, isso é uma exceção explícita.
5. Provisionamento automático do segmento no momento da venda. Se criar rede de cliente é tarefa manual, alguém vai reaproveitar uma existente sob pressão de prazo.

Armazenamento: isolamento e dado residual

Compartilhar um pool de storage entre clientes é aceitável e normal, desde que três coisas estejam resolvidas.

A primeira é o volume dedicado por cliente, com controle de acesso que impede um host ou uma VM de acessar o volume de outro.

A segunda é a cifragem, preferencialmente com chave distinta por cliente. Ela protege contra dois cenários concretos: disco que sai do datacenter para manutenção ou descarte, e dado residual acessível caso o isolamento lógico falhe.

A terceira é o limite de IOPS, e essa é a que mais gera chamado. Sem limite por VM, um cliente rodando uma indexação pesada consome a capacidade de I/O do pool e degrada todos os vizinhos. O sintoma chega como "está lento" de vários clientes ao mesmo tempo, sem nenhum deles ter causado o problema.

Recursos: cota é isolamento também

Isolamento não é só sobre acesso — é sobre desempenho. Um cliente não deve conseguir prejudicar o outro consumindo recurso sem limite:

• CPU com limite e peso definidos, para que o overcommit seja distribuído com justiça em vez de por quem chega primeiro.
• Memória sem overcommit agressivo. É o recurso que menos tolera, e a degradação é imediata e visível.
• IOPS e banda de storage limitados por VM.
• Banda de rede limitada, incluindo o tráfego de saída.
• Cota de criação de recursos, para uma conta comprometida não provisionar cem VMs.

E uma reserva de capacidade que costuma ser esquecida: mantenha folga para absorver a queda de um nó. Cluster preenchido até o limite não consegue realocar as VMs do nó que caiu — o que transforma uma falha de hardware prevista em indisponibilidade para vários clientes.

Identidade e o plano de controle

Todo recurso precisa ter dono, e toda operação precisa verificar se quem pede é o dono. Parece óbvio, e é justamente onde as falhas aparecem:

• Verificação de propriedade em cada chamada, não apenas na listagem. Se o painel filtra corretamente mas a API aceita um identificador arbitrário, o isolamento não existe.
• Identificadores não sequenciais. Numeração previsível transforma tentativa em enumeração fácil.
• Escopo de token de API limitado ao cliente e, idealmente, ao conjunto de operações necessárias.
• Separação entre acesso de cliente e acesso administrativo, com autenticação de dois fatores obrigatória para o administrativo.
• Registro de auditoria por cliente, que serve tanto para investigar incidente quanto para responder à pergunta "quem apagou minha VM?".

Backup e o fim do relacionamento

Duas situações que exigem atenção específica.

No backup, a cópia de cada cliente precisa ser isolada, com cifragem por cliente, e o processo de restauração precisa validar a quem pertence o backup solicitado. Restauração cruzada é uma forma silenciosa e completa de vazamento de dado.

No encerramento, quando o cliente sai, o dado precisa ser efetivamente destruído — o volume, os snapshots e os backups, respeitando a retenção contratual. Isso tem duas dimensões: é obrigação legal sob a LGPD e é risco de segurança, porque volume liberado sem limpeza pode ser realocado a outro cliente. Cifragem com chave por cliente resolve elegantemente: destruir a chave inutiliza o dado.

Documente e comunique esse procedimento. É uma pergunta frequente de cliente corporativo em processo de compra, e ter a resposta pronta é vantagem comercial.

Teste a fronteira, não presuma

Isolamento configurado não é isolamento verificado. Um roteiro de teste que vale executar em ambiente controlado, com duas VMs de clientes fictícios diferentes:

1. Tente alcançar a outra VM pela rede — por endereço, por varredura, por difusão.
2. Tente alcançar a interface de gestão do host e a rede de storage.
3. Na API, troque o identificador do recurso pelo de outro cliente e observe a resposta.
4. Gere carga intensa de disco em uma e meça o impacto na outra.
5. Solicite a restauração de um backup usando um identificador que não é seu.
6. Encerre um cliente e verifique se o dado realmente desapareceu.

Cada um desses testes tem resultado esperado claro, e qualquer desvio é achado. Repita depois de mudança relevante na plataforma — isolamento tende a regredir em silêncio quando alguém ajusta uma regra durante um incidente.

Erros comuns

• Entregar container em vez de VM para carga de cliente.
• Rede plana, com todas as VMs se vendo.
• Rede de gestão ou de storage alcançável a partir de VM de cliente.
• Nenhum limite de IOPS, com vizinho ruidoso degradando todos.
• Overcommit de memória entre clientes.
• API que aceita identificador de recurso sem verificar propriedade.
• Identificadores sequenciais e previsíveis.
• Backup sem isolamento nem cifragem por cliente.
• Nenhum procedimento de destruição de dado no encerramento.
• Cluster sem folga para absorver a queda de um nó.
• Criação manual de rede por cliente, reaproveitada sob pressão.
• Nunca testar a fronteira de isolamento.

Onde a Solvefy/Cloud entra

Isolamento multi-tenant é um dos pilares do que entregamos na plataforma E-CLOUD: rede própria por cliente provisionada automaticamente no momento da venda, cotas de CPU, memória, IOPS e banda aplicadas pela plataforma, escopo verificado no painel e na API, backup isolado com cifragem por cliente e procedimento documentado de destruição de dado no encerramento. Também executamos o teste de fronteira com você — é o que transforma isolamento configurado em isolamento comprovado, e é a evidência que o seu cliente corporativo vai pedir.

Quer verificar se os seus clientes estão realmente isolados? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.