> ## 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. # Visão Geral de Segurança > A arquitetura de segurança em primeiro lugar da Switchbord para operações empresariais de WhatsApp — ISO 27001, GDPR/LGPD, NIS2, HIPAA-ready e alinhada ao SOC 2. ## Arquitetura com Segurança em Primeiro Lugar A Switchbord é uma plataforma multi-tenant de operações de WhatsApp que processa PII de clientes organizacionais em escala. Segurança não é um item secundário — está embutida na arquitetura em cada camada: desde a forma como o contexto de workspace é resolvido em cada chamada de API, até como os segredos são armazenados, até como a PII é tratada antes de chegar a qualquer modelo de IA. Foi realizada uma auditoria de segurança adversarial abrangendo as dimensões ISO 27001, GDPR, NIS2, HIPAA e SOC 2. As descobertas motivaram um programa estruturado de remediação (BORD-149 a BORD-176) que está em andamento ativo. Esta documentação reflete o estado dos controles de segurança na versão atual. Itens marcados como **Planejado** são acompanhados no Linear e serão implementados nos próximos sprints. ## Metas de Conformidade Controles do sistema de gestão de segurança da informação. Controles do Anexo A mapeados em controle de acesso, criptografia, segurança operacional e relacionamento com fornecedores. Conformidade total com o regulamento de proteção de dados da UE. Direitos do titular dos dados (Art.15, 17, 20), base legal, DPA com subprocessadores, privacidade desde a concepção (Art.25). No Brasil, a LGPD estabelece princípios equivalentes. Diretiva de Segurança de Redes e Informação da UE. Medidas de gestão de risco (Art.21), obrigações de notificação de incidentes (Art.23). Salvaguardas técnicas alinhadas ao HIPAA §164.312. Controles de acesso, controles de auditoria, controles de integridade e segurança de transmissão. Não é uma entidade coberta (covered entity) por padrão — consulte seu responsável por conformidade. Mapeamento dos Trust Service Criteria em CC1–CC9. Controles de acesso lógico, gestão de mudanças, monitoramento e disponibilidade documentados e parcialmente implementados. ## Pilares da Arquitetura ### Isolamento por Workspace Todo tenant opera em um workspace totalmente isolado. O contexto de workspace é resolvido no servidor a partir do registro `workspace_members` do usuário autenticado — nunca a partir de variáveis de ambiente ou headers fornecidos pelo cliente. Um usuário no workspace A não pode acessar, modificar ou enviar mensagens em nome do workspace B. Veja [Multi-Tenancy e Isolamento de Workspace](/pt-BR/security/multi-tenancy). ### Supabase Vault para Segredos Os segredos do tenant — tokens de acesso da Meta, segredos de assinatura de webhook, chaves de API de LLM — são armazenados no Supabase Vault, escopados por workspace. Nenhum segredo reside em tabelas do schema público. Os fallbacks de variáveis de ambiente ficam restritos exclusivamente a ambientes não produtivos. Veja [Gestão de Segredos e Criptografia](/pt-BR/security/secrets-and-encryption). ### Controle de Acesso Baseado em Papéis (RBAC) Quatro papéis são aplicados em toda rota de API: **owner**, **admin**, **developer** e **operator**. As verificações de papel são realizadas após a resolução do contexto de workspace, antes da execução de qualquer lógica de negócio. Veja [Autenticação e Controle de Acesso](/pt-BR/security/authentication). ### Direitos de Dados do GDPR Os contatos têm direito de acesso aos seus dados (Art.15/20) e direito ao esquecimento (Art.17). Ambos são implementados como endpoints de API que exportam ou anonimizam a PII no próprio local, com registros de auditoria em cada operação. Veja [Proteção de Dados e GDPR](/pt-BR/security/data-protection). ### Pseudonimização de PII para IA Antes que qualquer dado de contato chegue a um modelo de IA, o redator de PII substitui números de telefone, e-mails e (opcionalmente) nomes por tokens reversíveis. Os tokens são restaurados na resposta do LLM antes de salvar. Desabilitar a pseudonimização só é permitido quando um provider de IA auto-hospedado (self-hosted) está configurado. Veja [Proteção de Dados e GDPR](/pt-BR/security/data-protection). ## Status de Implementação | Área de Controle | Status | Detalhes | | -------------------------------------------- | -------------- | ---------------------------------------------------------------------------------------------------------------------- | | Isolamento multi-tenant | ✅ Implementado | Resolução baseada em workspace\_members, aplicada em todas as rotas | | Guarda de autenticação em todos os endpoints | ✅ Implementado | ai-assistant, chaves de API, configurações — todos protegidos | | Comparação de segredos com timing seguro | ✅ Implementado | `crypto.timingSafeEqual` | | Gestão de sessão | ✅ Implementado | Janela de 8h, inatividade de 1h, revogação na remoção | | Cabeçalhos de segurança | ✅ Implementado | CSP, HSTS, X-Frame-Options, Permissions-Policy | | CORS | ✅ Implementado | Baseado em allowlist, apenas origens conhecidas | | Segredos no Vault | ✅ Implementado | Vault por workspace, sem fallback de ambiente em produção | | Exportação de dados GDPR (Art.15/20) | ✅ Implementado | `GET /api/contacts/[id]/gdpr` | | Direito ao esquecimento GDPR (Art.17) | ✅ Implementado | `DELETE /api/contacts/[id]/gdpr` | | Política de retenção de dados GDPR | ✅ Implementado | `data_retention_days` por workspace | | Pseudonimização de PII para IA | ✅ Implementado | `pii-redactor.ts`, alternável por workspace | | Proteção contra redirecionamento aberto | ✅ Implementado | `isSafeRedirect()` no callback de autenticação | | Validação de entrada | ✅ Implementado | Zod em todas as rotas principais | | Revogação de sessão | ✅ Implementado | `signOut` na remoção de membro | | RBAC | ✅ Implementado | 4 papéis aplicados em todas as rotas | | Escopo de chaves de API | ✅ Implementado | Filtro workspace\_id em todas as operações de chave (BORD-154) | | Registro de auditoria (operações de escrita) | ✅ Implementado | Tabela `audit_logs` escopada por workspace, mudanças de membros, apagamentos GDPR, atualizações de segredos (BORD-158) | | Livro de consentimento (consent ledger) | ✅ Implementado | Rastreamento de consentimento por contato com histórico de opt-in/opt-out (BORD-193) | | Isolamento de webhook | 📋 Planejado | BORD-157: tabela de roteamento phone\_number\_id | | Claims de workspace no JWT | 📋 Planejado | BORD-155 | | Autenticação no edge middleware | 📋 Planejado | BORD-156 | | Registro de auditoria de leitura | 📋 Planejado | BORD-168 | | Logs de auditoria à prova de adulteração | 📋 Planejado | BORD-168 | | Limitação de taxa por workspace | 📋 Planejado | BORD-162 | | Varredura de dependências (SBOM) | 📋 Planejado | BORD-170 | | Criptografia de PII em nível de coluna | 📋 Planejado | BORD-171 | | Detecção de incidentes | 📋 Planejado | BORD-166 | | Fluxo de notificação de violação de dados | 📋 Planejado | BORD-166 | | Aplicação obrigatória de MFA | 📋 Planejado | TOTP do Supabase disponível | ## Documentação Detalhada Modelo de isolamento de workspace, resolução de contexto e isolamento de despacho de mensagens. Gestão de sessão, RBAC, chaves de API, política de senhas e MFA. Tratamento de PII, direitos do titular dos dados, pseudonimização e subprocessadores. Supabase Vault, cabeçalhos de segurança, TLS e criptografia em repouso. Trilha de auditoria, observabilidade e notificação de violação planejada. Mapeamento completo de controles em ISO 27001, GDPR, NIS2, HIPAA e SOC 2.