Como o Spun criptografa seus dados, da criptografia do WhatsApp às chamadas em grupo
Detalhes honestos, cenário por cenário, sobre a criptografia do WhatsApp, as chamadas e os dados armazenados: o que tem criptografia de ponta a ponta, o que só é criptografado em trânsito e o que precisa ser legível pelo Spun para o produto funcionar.
Visão geral
Criptografia por cenário
Abaixo está cada tipo de dado que o Spun acessa e exatamente como ele é protegido. Marcamos E2EE como Sim somente quando nenhum sistema do Spun consegue ler o conteúdo.
| Cenário | E2EE | Observações |
|---|---|---|
Chamada de voz 1:1 (Spun → Spun) DTLS-SRTP (WebRTC) | Sim | WebRTC puramente ponto a ponto. As chaves são negociadas entre os dois extremos: o Spun nunca as tem. |
Chamada de vídeo 1:1 (Spun → Spun) DTLS-SRTP (WebRTC) | Sim | Igual à chamada de voz. Os relays TURN só veem pacotes criptografados quando a conexão P2P direta falha. |
Chamada em grupo (3 ou mais participantes) TLS 1.2+ até o SFU, DTLS-SRTP para a mídia | Não | O SFU do LiveKit Cloud descriptografa a mídia para encaminhá-la aos outros participantes. Arquitetura SFU padrão. |
Sala de tradução (modo P2P, ≤2 participantes) DTLS-SRTP (WebRTC) | Sim | Passa para o SFU se um terceiro participante entrar: veja a linha acima. |
Sala de tradução (modo SFU, 3 ou mais participantes) TLS 1.2+ até o SFU | Não | O SFU do LiveKit tem acesso à mídia para traduzi-la e mixá-la de novo. |
Mensagens do WhatsApp (dentro do WhatsApp) Signal Protocol (Meta) | Parcial | O próprio WhatsApp tem E2EE entre os participantes. Mas, quando o seu provedor de gateway recebe as suas mensagens recebidas em seu nome, o gateway e o Spun veem o texto sem criptografia: é assim que a caixa de entrada funciona. |
Mensagens do WhatsApp (no Spun) TLS 1.2+ | Não | Necessário para exibir a caixa de entrada, a busca, os recursos de IA e as automações. |
Spun Chat e mensagens da equipe TLS 1.2+ | Não | Texto sem criptografia em repouso para que as mensagens possam ser pesquisadas e processadas pelos recursos de IA que você ativar. |
Anexos de mídia (imagens, vídeo, documentos) TLS 1.2+ (Cloudflare R2 + S3 SigV4) | Não | O R2 gerencia as chaves. O Spun assina URLs de curta duração para controlar o acesso por organização. |
Dados de cartão de pagamento TLS 1.2+ direto para a Stripe | Parcial | O Stripe Elements coleta os dados do cartão diretamente no navegador: eles nunca chegam aos servidores do Spun. Recebemos apenas um ID de cliente opaco. |
Prompts e respostas de IA TLS 1.2+ até o provedor de IA | Não | Enviados por TLS para OpenAI / AssemblyAI / etc. A ocultação de dados pessoais (PII), quando ativada, remove os campos sensíveis antes da transmissão. |
Backups do banco de dados TLS 1.2+ | Não | Criptografia padrão de backups gerenciados. |
E2EE = criptografia de ponta a ponta. “Sim” significa que nem o Spun consegue ler os dados. “Parcial” significa E2EE dentro de um terceiro (Stripe, WhatsApp), mas visível para o Spun na parte que nós processamos.
Em trânsito
Tudo o que circula entre o seu navegador, os nossos servidores e os nossos suboperadores é criptografado com TLS.
TLS 1.2+ em todas as conexões de rede
Todo o tráfego navegador ↔ Spun, Spun ↔ gateway do WhatsApp, Spun ↔ OpenAI / AssemblyAI / Deepgram / Sarvam / Azure e Spun ↔ Stripe é criptografado com TLS. As versões mais antigas do protocolo ficam desativadas no balanceador de carga.
Borda protegida pela Cloudflare
A Cloudflare encerra o TLS na borda e criptografa de novo até a origem. Os certificados de origem fixam as requisições nos nossos servidores da Hetzner. A proteção WAF e DDoS fica sempre ativa.
URLs assinadas de curta duração
Os downloads de mídia usam URLs pré-assinadas S3 SigV4 restritas a um único objeto, com validade fixa. Mesmo uma URL vazada para de funcionar quando expira.
Em repouso
Os dados armazenados são isolados por organização pela segurança em nível de linha do PostgreSQL, e a mídia só pode ser acessada por URLs assinadas e restritas a um objeto.
PostgreSQL com segurança em nível de linha
Toda tabela com dados de clientes tem políticas de segurança em nível de linha (RLS) do PostgreSQL que garantem o isolamento por organização. Até uma consulta que, por engano, não tenha o filtro de organização é negada no nível do banco de dados.
Alemanha primeiro, com uma célula nos EUA
A célula principal (plano de controle, servidores de aplicação, PostgreSQL e Redis) roda na Hetzner em Nuremberg (Alemanha, UE). Uma segunda célula roda em Manassas, Virgínia. Cada organização fica hospedada em exatamente uma célula, e toda organização nova é criada na célula da UE.
Cloudflare R2 para mídia
Imagens, vídeos, áudios e documentos são armazenados no Cloudflare R2. O acesso nunca acontece por um endereço de bucket público, apenas por uma URL assinada restrita a um único objeto.
Chamadas de voz e vídeo
O que é E2EE de verdade, o que não é e por quê. Não anunciamos as chamadas em grupo como criptografadas de ponta a ponta, porque elas não são.
Voz e vídeo 1:1: E2EE de verdade
Quando dois usuários do Spun ligam um para o outro, o áudio e o vídeo são criptografados com DTLS-SRTP de ponta a ponta entre os dois navegadores. O servidor do Spun só retransmite a sinalização SDP. Mesmo que o Cloudflare TURN precise retransmitir (NATs simétricos, firewalls), ele vê apenas pacotes criptografados.
Chamadas em grupo (3 ou mais): criptografadas em trânsito, sem E2EE
As chamadas de áudio e vídeo em grupo e as salas de tradução com vários participantes usam o LiveKit Cloud como SFU (unidade de encaminhamento seletivo). A mídia é criptografada com DTLS-SRTP entre cada cliente e o SFU, mas o SFU a descriptografa ao recebê-la para encaminhá-la aos outros participantes. Essa é a arquitetura SFU padrão e não tem criptografia de ponta a ponta.
Salas de tradução: P2P primeiro sempre que possível
As salas de tradução tentam primeiro o P2P (E2EE) quando há só dois participantes, e passam para o SFU quando um terceiro entra ou quando os dispositivos têm recursos limitados demais para o P2P. O modo de conexão aparece na interface da chamada.
Por que não afirmamos ter E2EE completo nas chamadas em grupo
O LiveKit oferece um modo opcional de criptografia de ponta a ponta (com a API Encoded Insertable Streams) que protege a mídia até do SFU. Ele não está ativado hoje nas chamadas em grupo do Spun: adicioná-lo exige um mecanismo de troca de chaves entre os participantes e compatibilidade verificada de navegador e codec para cada cliente suportado.
Se E2EE completo em grupo for um requisito para você, fale com a gente em [email protected]: isso está no roadmap e vamos compartilhar o andamento.
Pagamentos e identidade
Os dados mais sensíveis são tratados por processadores especializados, então o Spun nunca os vê nem os armazena.
Os dados do cartão vão direto para a Stripe
O Stripe Elements coleta números de cartão, CVCs e datas de validade dentro de um iframe que os envia diretamente para a Stripe, sem passar em nenhum momento pelos servidores do Spun. Recebemos apenas um ID opaco de cliente ou de forma de pagamento. A Stripe tem certificação PCI-DSS Level 1.
Senhas com hash Argon2
As contas com e-mail e senha usam Argon2id com salts por usuário. Não guardamos nem registramos senhas em texto sem criptografia. O Google Sign-In delega a autenticação inteiramente ao Google: nenhuma senha chega a existir no Spun para essas contas.
Chaves de API e webhooks assinados
Todos os payloads de webhooks de terceiros (WhatsApp, Stripe, webhooks de extensões) são assinados com HMAC-SHA256 e verificados no servidor. Os tokens de API das extensões são JWTs de curta duração (RS256), com um endpoint JWKS publicado.
Mensagens do WhatsApp: os limites do E2EE
O E2EE do WhatsApp protege as mensagens enquanto elas estão dentro da infraestrutura do WhatsApp. No momento em que o seu provedor de gateway recebe uma mensagem em seu nome, o gateway vê o texto sem criptografia. Isso vale para todo provedor da WhatsApp Business API: é assim que as caixas de entrada empresariais funcionam.
Mais perguntas?
Para detalhes técnicos específicos (conjuntos de cifras, autoridades certificadoras, política de rotação de chaves etc.) ou para pedir a resposta a um questionário de segurança, escreva para [email protected].