​

Revisão Adversarial

Esta página documenta a auditoria de segurança adversarial realizada em toda a plataforma Switchbord e o programa de remediação que se seguiu. O acompanhamento detalhado está no Linear (BORD-149 até BORD-176). Para uma tabela de status de implementação em tempo real, veja Visão Geral de Segurança.

​

Auditoria de Multi-Tenancy (BORD-149 – BORD-176)

Uma revisão adversarial estruturada foi realizada contra as dimensões ISO 27001, GDPR, NIS2, HIPAA e SOC 2. A auditoria focou em cinco áreas de risco:

​

1. Isolamento de workspace e resolução de contexto

Descoberta: Várias rotas de API derivavam o contexto de workspace a partir de variáveis de ambiente (readSingleWorkspace()) em vez da sessão autenticada. Esse padrão é incompatível com multi-tenancy — uma suposição de tenant único permitiria que uma requisição manipulada agisse como qualquer workspace. Remediação: readSingleWorkspace() foi descontinuada e removida de todos os caminhos de código de produção. Todas as rotas agora chamam resolveCallerWorkspaceFromSupabase(userId), que resolve o contexto de workspace a partir de workspace_members no lado do servidor. Todas as 13 rotas de configurações foram auditadas e reestruturadas com requireSettingsAccess() como a primeira operação. Veja Multi-Tenancy e Isolamento de Workspace.

​

2. Brecha de autenticação do assistente de IA

Descoberta: O endpoint /api/ai-assistant estava acessível sem autenticação. Qualquer chamador não autenticado poderia enviar prompts processados com credenciais de LLM do workspace. Remediação: Guarda de autenticação adicionada. O endpoint agora exige uma sessão válida e resolve o contexto de workspace antes do processamento. O contexto de IA é restrito apenas a contatos e conversas dentro do workspace do chamador.

​

3. Armazenamento de segredos

Descoberta: Tokens de acesso da Meta e segredos de assinatura de webhook eram lidos a partir de variáveis de ambiente em alguns caminhos, criando uma suposição de tenant único e impedindo a rotação de segredos por workspace. Remediação: Todos os segredos de provedor (tokens da Meta, segredos de assinatura de webhook, chaves de API de LLM) são armazenados no Supabase Vault, com escopo por workspace, acessados via workspace_secret_bindings. Fallbacks de variável de ambiente são bloqueados em produção. Veja Gestão de Segredos e Criptografia.

​

4. Ciclo de vida de sessão e acesso

Descoberta: A remoção de um membro não revogava as sessões ativas. Um membro removido podia continuar operando até que seu token expirasse. Remediação: A remoção de membro agora chama signOut para revogar imediatamente a sessão ativa. A política de sessão impõe um timeout absoluto de 8 horas e um timeout de inatividade de 1 hora. Veja Autenticação e Controle de Acesso.

​

5. Lacunas de conformidade com o GDPR

Descoberta: Não existiam endpoints de direitos do titular dos dados. PII de contatos só podia ser exportado ou apagado via acesso direto ao banco de dados. Remediação: Endpoints de GDPR implementados:

• GET /api/contacts/[id]/gdpr — exportação estruturada (Art.15/20)
• DELETE /api/contacts/[id]/gdpr — anonimização in-place (Art.17)

Ambas as operações gravam em audit_logs. A política de retenção de dados (data_retention_days) é configurável por workspace. Veja Proteção de Dados e GDPR.

​

Itens Planejados Remanescentes

Os seguintes itens da auditoria permanecem em andamento e são rastreados no Linear:

​

Postura de Revisão Contínua

Todo PR de funcionalidade importante deve incluir:

• seção de verificações adversariais na descrição do PR
• identificação de quaisquer novos caminhos de acesso a dados e se eles têm escopo de workspace
• identificação de quaisquer novos segredos ou credenciais e se estão armazenados no Vault
• nota de rollback

Os problemas de hardening são rastreados em planning/linear/BACKLOG.yaml e sincronizados com issues do Linear. Não mantenha descobertas abertas apenas neste documento.