A pergunta que essa página responde
“Se eu sou cliente Apollo Space e outra empresa também é, qual a garantia de que um bug ou má-fé não exponha meus dados pra ela?”Resposta curta: isolamento aplicado no nível do banco (não apenas na camada de aplicação), de forma forçada e auditável.
Por que isolamento no banco, e não só na aplicação
A abordagem ingênua de multi-tenant é filtrar dados por organização em cada consulta da camada de aplicação. Funciona enquanto ninguém esquece o filtro — code review pega 99%, mas 1% basta pra um incidente sério. O Apollo Space aplica a verificação no próprio banco, via uma política embutida em cada tabela com dados de cliente. Se a aplicação esquece o filtro, o banco recusa o acesso — não há consulta “ampla demais” que dê certo.Como funciona na prática
Sessão é aberta com identidade clara
Ao processar uma requisição, o backend identifica qual
organização está ativa (via URL + autenticação) e marca a
sessão do banco com esse identificador.
Cada query é avaliada contra a política
Antes de retornar qualquer linha de uma tabela tenant, o banco
confere: a linha pertence à organização ativa nesta sessão? Sim
→ retorna. Não → omite, como se não existisse.
Writes seguem a mesma regra
INSERT/UPDATE tentando criar registro pra outra org? Rejeitado
pelo banco com erro de permissão. Não há “atalho” na camada de
aplicação.
Defense in depth — duas camadas
Apesar do banco fazer o trabalho principal, o Apollo Space aplica também o filtro na camada de aplicação (cinto-e-suspensórios):| Camada | Função |
|---|---|
| Aplicação | Filtra explicitamente por organização em todas as queries — code review + lint enforce |
| Banco | Aplica a política de isolamento via row-level security forçada — se a aplicação falhar, banco bloqueia |
Como seu time de segurança audita
Auditores externos da sua empresa podem verificar o modelo de duas formas:Inspeção da configuração do banco
Sob NDA, o Apollo Space libera evidências da configuração de
isolamento (políticas, roles, grants) pra inspeção. Não exige
acesso ao banco de produção — basta a configuração.
Probe automatizado
O Apollo Space roda continuamente um teste automatizado que tenta
vazar dados entre orgs sintéticas — duas tenants de teste, uma
tenta ler/escrever da outra. Qualquer sucesso quebra o deploy.
Evidência da execução é compartilhável.
Operação interna do Apollo Space
Operadores da Apollo Space (engenharia, suporte) não veem dados de cliente por inspeção casual. As práticas:- Acesso ao banco de produção é gateado — exige escalação + justificativa + auditoria
- Mesmo com acesso ao banco, a sessão padrão honra a política de isolamento — não basta logar, é preciso identificar a org
- Qualquer acesso privilegiado para debug crítico é restrito, registrado e atrelado a um ticket aberto — nunca rotineiro
Limites conhecidos
Honestamente:- Backup multi-tenant: backups do banco contêm dados de todas as orgs. Restauração seletiva (uma org só) é trabalho operacional manual. Em incidente sério, isto vira projeto.
- Logs de aplicação: linhas de log podem conter IDs de organização ou pequenos fragmentos de dados (em casos de erro). Logs são retidos por 30 dias e acessados só pelo time de operação. Não são compartilhados externamente.
- Telemetria de operação: métricas agregadas (latência por
endpoint, taxa de erro) contêm
org_idcomo dimensão de agregação. Conteúdo de cliente não.
Próximos passos
Segurança (geral)
Auth, criptografia, audit, resposta a incidente.
Organizações
O modelo de papéis dentro de uma org.