Isolamento entre clientes não é uma caixa que se marca uma vez. É uma propriedade que precisa continuar verdadeira em toda rota nova, em todo relatório novo, em todo arquivo que alguém sobe. A maneira de saber se ela vale hoje é tentar atravessar de propósito, no seu próprio ambiente, antes que alguém atravesse por acidente.
E antes do checklist, um aviso que vale o artigo inteiro: isso se testa em sistema que é seu, ou em sistema para o qual você tem autorização escrita do dono. Sondar sistema de terceiro sem isso é crime no Brasil, art. 154-A do Código Penal, incluído pela Lei nº 12.737/2012, e não existe versão leve dessa história.
Nem a maior nuvem do mundo tratou isso como resolvido
Em 30 de julho de 2026, a Microsoft concluiu a correção de uma falha de isolamento entre inquilinos no Azure Cosmos DB, batizada CosmosEscape pela empresa de segurança Wiz, que a reportou em novembro de 2025. A cadeia de falhas permitia escapar do sandbox de consultas da API Gremlin e chegar a um segredo de assinatura de escopo global, com o qual era possível obter as chaves primárias de contas de banco de outros clientes, com leitura e escrita. A Microsoft bloqueou o ponto de entrada vulnerável em 48 horas depois do reporte, completou a correção definitiva em todas as regiões em julho de 2026, eliminou a chave de escopo global e afirmou não ter encontrado evidência de impacto em cliente nem atividade além do teste dos pesquisadores. A cobertura está no The Hacker News e a pesquisa original, no blog da Wiz.
Não conto isso para dizer que a nuvem é insegura. Conto porque o time que mantém o Cosmos DB tem mais gente de segurança do que a sua empresa inteira, e ainda assim o isolamento precisou ser reconquistado. A versão que aparece num SaaS pequeno é infinitamente mais banal, e é justamente por isso que ela passa: ninguém procura o óbvio depois que a tela funcionou.
A versão banal tem CVE e tem dono da responsabilidade
O CVE-2025-48757, publicado no NVD em 29 de maio de 2025 e atualizado em junho de 2026, descreve política de segurança em nível de linha insuficiente numa plataforma de geração de apps, permitindo que atacantes não autenticados leiam ou modifiquem dados em tabelas arbitrárias dos sites gerados. A pontuação CVSS 3.1 informada é 9.3, crítica. O registro traz também que o fornecedor disputa a vulnerabilidade, sob o argumento de que a proteção dos dados da aplicação é responsabilidade do cliente. O registro está no NVD.
A disputa é a parte importante para você. Independentemente de quem tem razão sobre a classificação, a posição da plataforma é explícita: a regra de acesso ao dado é do dono do app. Quem gerou o sistema numa plataforma e publicou continua sendo quem responde pelo dado, e é quem vai receber a pergunta do jurídico do cliente.
A regra que a documentação de segurança repete há anos
A OWASP mantém o item API1:2023, Broken Object Level Authorization, no topo da sua lista de riscos de API desde a primeira edição, e a orientação é sempre a mesma: a verificação de autorização por objeto tem que ocorrer no servidor, para cada requisição que recebe um identificador, e usar identificador aleatório e imprevisível não substitui a verificação. A documentação está publicada.
A folha de referência de segurança multi-inquilino da própria OWASP é ainda mais direta sobre onde as pessoas erram: derive o inquilino do token autenticado e verificado, nunca de parâmetro que veio do cliente; verifique em duas camadas, no banco e na aplicação; use chave composta de identificador do inquilino com identificador do recurso nas consultas; e propague o inquilino também para cache e sessão, porque chave de cache sem prefixo de inquilino vaza sem passar por nenhuma consulta. A folha de referência está publicada.
Essa última linha explica um caso que a gente vê com frequência: a consulta está correta, a regra no banco está ativa, e o vazamento acontece no cache, que devolveu para o segundo cliente a resposta montada para o primeiro. Nenhuma revisão do modelo de dados pega isso.
O teste, em sete passos, no seu próprio ambiente
Precisa de duas empresas de teste em homologação, com dado semeado e nomes obviamente diferentes, e de duas sessões abertas ao mesmo tempo. A partir daí, a única habilidade necessária é anotar o resultado sem torcer para ele:
- Leitura direta. Pegue o identificador de um registro da empresa A e peça esse registro pela sessão da empresa B. O esperado é negar. Devolver vazio às vezes já é sinal de que a filtragem está na interface, não no dado.
- Escrita. Tente alterar e apagar o registro da empresa A pela sessão da B. Regra de leitura configurada e regra de escrita esquecida é o par mais comum que existe.
- Listagem e paginação. Peça a listagem com página alta, com limite grande e com ordenação diferente. Filtro que só existe na consulta padrão cai quando o parâmetro muda.
- Relatório e exportação. Rode todo relatório agregado e toda exportação de arquivo pela sessão da B e confira os totais. Consulta agregada escrita à mão é onde o filtro de inquilino mais falta.
- Arquivo e storage. Copie a URL de um anexo da empresa A e abra deslogado, em janela anônima. Arquivo costuma morar num serviço diferente do banco, com regra própria que ninguém revisou.
- Cache, busca e tempo real. Repita a leitura duas vezes seguidas alternando as sessões e compare. Depois, se existir assinatura de eventos em tempo real ou índice de busca, tente assinar o canal da outra empresa.
- Caminho administrativo e integração. Teste o painel interno, o webhook e a chave de API: chave de serviço que ignora as regras de acesso não deveria existir fora do servidor, e qualquer rota administrativa precisa verificar o inquilino do mesmo jeito que a rota do usuário.
Escreva o resultado dos sete numa página, com data. Essa página é o que responde a pergunta da cláusula contratual sobre isolamento, e é a única forma de saber se o isolamento continua valendo depois da próxima entrega.
Achar uma vez é faxina, manter é engenharia
A parte que ninguém conta é que passar nos sete hoje não garante nada sobre o mês que vem. Rota nova nasce sem a verificação, tabela nova nasce sem a regra, relatório novo nasce com consulta escrita à mão. Por isso o teste vira teste automatizado: cada tabela nova entra numa lista que o CI confere, e cada rota ganha um caso que tenta atravessar e espera negação.
No nosso próprio SaaS de compliance, isso é o que existe hoje: segurança em nível de linha ativa em 167 tabelas do banco, conferida tabela a tabela depois de uma migração completa de nuvem, e cada deploy passando por uma suíte de mais de 1.500 testes automatizados. O número não é para impressionar, é para mostrar a forma da coisa: 167 tabelas não se confere na revisão de código, se confere com uma lista que quebra o build.
Também vale dizer o que o teste não cobre. Ele responde se o sistema separa clientes. Não responde se as pessoas com acesso legítimo estão vendo mais do que precisam, que é outra pergunta, resolvida com permissão por papel e trilha de auditoria de acesso. As duas costumam aparecer na mesma cláusula, e são trabalhos diferentes.
Leitura recomendada
- The Hacker News sobre o CosmosEscape no Azure Cosmos DB: thehackernews.com
- Wiz, pesquisa original do CosmosEscape: wiz.io
- NVD, CVE-2025-48757, política de segurança em nível de linha insuficiente em apps gerados: nvd.nist.gov
- OWASP API Security Top 10, API1:2023 Broken Object Level Authorization: owasp.org
- OWASP Multi Tenant Security Cheat Sheet: cheatsheetseries.owasp.org
Depois do teste
Se algum dos sete passos devolveu dado que não devia, a pergunta seguinte deixa de ser técnica e passa a ser de prazo: pela Resolução CD/ANPD nº 15/2024 o relógio de comunicação de incidente conta do conhecimento, não da correção. Tem um autodiagnóstico de proteção de dados aqui no site, em fabership.com.br/diagnostico-lgpd, que percorre esse e os outros pontos que aparecem em cláusula contratual. Você responde sobre o seu próprio sistema e vê o resultado na hora. A gente não toca em sistema nenhum sem contrato assinado e autorização por escrito, inclusive para demonstrar valor.