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

# Revisão Adversarial

> Descobertas da auditoria de segurança, status de remediação e hardening contínuo para a plataforma Switchbord.

# 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](/pt-BR/security/overview).

## 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](/pt-BR/security/multi-tenancy).

### 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](/pt-BR/security/secrets-and-encryption).

### 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](/pt-BR/security/authentication).

### 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](/pt-BR/security/data-protection).

## Itens Planejados Remanescentes

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

| Item                                                                  | Ticket   |
| --------------------------------------------------------------------- | -------- |
| Roteamento por phone\_number\_id com escopo de webhook                | BORD-157 |
| Claims de workspace em JWT na autenticação do Supabase                | BORD-155 |
| Aplicação de autenticação no edge middleware                          | BORD-156 |
| Rate limiting por workspace                                           | BORD-162 |
| Log de auditoria de acesso de leitura + cadeia à prova de adulteração | BORD-168 |
| Criptografia de PII em nível de coluna                                | BORD-171 |
| Detecção de incidentes e notificação de violação                      | BORD-166 |
| SBOM e varredura de dependências                                      | BORD-170 |

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