Skip to main content

Modelo de Isolamento

A Switchbord é uma plataforma multi-tenant onde cada organização tenant opera como um workspace independente. A garantia de isolamento é:
Um usuário no workspace A não pode ler, gravar ou agir sobre dados pertencentes ao workspace B — independentemente de como as chamadas de API são construídas.
Essa garantia é aplicada no lado do servidor, na camada de API, e não apenas por meio de roteamento no cliente ou controles de UI.

Resolução do Contexto de Workspace

resolveCallerWorkspaceFromSupabase(userId)

Toda rota de API autenticada resolve o contexto de workspace consultando a tabela workspace_members usando o ID do usuário autenticado:
Propriedades principais:
  • Lê a partir de workspace_members, não de variáveis de ambiente
  • Retorna o workspace ao qual o usuário realmente pertence — não pode ser sobrescrito por parâmetros de requisição
  • Lança erro imediatamente se o usuário não for membro de nenhum workspace
  • Usada como base para todo acesso a dados escopado por workspace

requireSettingsAccess()

Todas as 13 rotas de API de configurações usam requireSettingsAccess() como sua primeira operação, que chama resolveCallerWorkspaceFromSupabase e impõe um nível mínimo de papel antes que qualquer dado de configuração seja lido ou gravado:
Nunca passe workspaceId como um parâmetro de query ou campo do corpo da requisição usado para autorização. Sempre derive-o no servidor a partir da sessão autenticada.

Padrão Descontinuado: readSingleWorkspace()

A função readSingleWorkspace() lia a configuração de workspace a partir de variáveis de ambiente, o que é incompatível com multi-tenancy. Ela foi descontinuada e removida de todos os caminhos de código em produção. Caminho de migração para qualquer código que ainda a referencie:

Encadeamento nas Rotas de Configurações

Todas as 13 rotas de API de configurações encadeiam o workspaceId derivado de requireSettingsAccess() em todas as consultas subsequentes. Nenhuma rota de configurações lê dados de workspace sem primeiro estabelecer o contexto de workspace do chamador. Exemplo de padrão para uma rota de configurações:

Isolamento no Despacho de Mensagens

A função dispatchMessageViaMetaInSupabase lê as credenciais da Meta a partir do workspace identificado por job.workspace_id — o workspace que é proprietário do job, não uma configuração global:
Isso significa que:
  • O workspace A não pode fazer com que mensagens sejam enviadas através do número Meta do Workspace B
  • O vazamento de credenciais entre tenants na camada de despacho é estruturalmente impossível
  • Cada workspace configura e rotaciona seu próprio token de acesso Meta de forma independente

Modelo de Entrada Somente por Convite

Os usuários só podem entrar em um workspace por meio de um convite explícito de um admin ou owner de workspace já existente. Não há descoberta ou fluxo de entrada por autoatendimento. Isso garante que:
  • A participação no workspace seja sempre intencional
  • Novos membros recebam apenas o papel explicitamente concedido pelo admin que convidou
  • A remoção de um membro revogue imediatamente todo acesso, incluindo sessões ativas
Veja Autenticação e Controle de Acesso para detalhes sobre revogação de sessão.

Escopo de Chaves de API

As chaves de API são escopadas ao workspace que as criou. Todas as operações de chave de API (listar, excluir, revogar) filtram pelo workspace_id resolvido do chamador:

Isolamento do Assistente de IA

O endpoint /api/ai-assistant anteriormente não possuía uma guarda de autenticação. Agora ele exige autenticação e resolve o contexto de workspace antes de processar qualquer requisição. O contexto de IA é escopado apenas a contatos e conversas dentro do workspace do chamador.

Mapeamento de Conformidade

Para o mapeamento completo de controles de conformidade, veja a Matriz de Conformidade.