> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apollospace.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Modelo multi-tenant

> Como o Apollo Space isola dados entre organizações no nível do banco — para times de segurança que precisam evidência.

## 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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Conexão de aplicação não consegue burlar">
    O role de banco usado pela aplicação **não tem permissão pra
    desligar a política**. Mesmo se a aplicação tentasse "executar
    sem filtro", o banco mantém a regra.
  </Step>
</Steps>

## 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 |

Pra um incidente acontecer, **ambas as camadas precisariam falhar
simultaneamente** — improvável.

## Como seu time de segurança audita

Auditores externos da sua empresa podem verificar o modelo de duas
formas:

<CardGroup cols={2}>
  <Card title="Inspeção da configuração do banco" icon="database">
    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.
  </Card>

  <Card title="Probe automatizado" icon="vial">
    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.
  </Card>
</CardGroup>

## 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, precisa identificar a org
* **Acesso bypass-RLS** existe pra debug crítico mas é restrito,
  audited e atrelado a um ticket aberto

Pra incidentes que exigem leitura de dados de cliente (debug de bug
específico, resposta a chamado), o cliente é **notificado em
postmortem** com o que foi acessado e por quê.

## 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_id` como dimensão de
  agregação. Conteúdo de cliente não.

## Próximos passos

<CardGroup cols={2}>
  <Card title="Segurança (geral)" icon="lock" href="/trust/security">
    Auth, criptografia, audit, resposta a incidente.
  </Card>

  <Card title="Organizações" icon="building" href="/concepts/organizations">
    O modelo de papéis dentro de uma org.
  </Card>
</CardGroup>