Segurança e conformidade

Autenticação

• Os tokens de acesso são JWTs de curta duração (15 minutos), verificados no gateway da API; os tokens de renovação duram 30 dias sem uso e no máximo 90 dias, são rotacionados a cada uso e ficam armazenados em um cookie HttpOnly, Secure e SameSite. Reutilizar um token de renovação já rotacionado revoga toda a cadeia.
• As chaves de assinatura são rotacionadas a cada 90 dias, com sobreposição; as chaves públicas são publicadas em /.well-known/jwks.json.
• As permissões não ficam embutidas nos tokens: elas são lidas a cada requisição, então uma mudança de função tem efeito imediato, e qualquer sessão pode ser revogada de forma centralizada.
• A autenticação de dois fatores (TOTP) pode ser opcional, obrigatória para Proprietários e Administradores ou obrigatória para todos. O login único com Google Workspace e Apple está disponível em todos os planos. SAML 2.0, passkeys e provisionamento SCIM estão planejados e ainda não estão disponíveis.
• As chaves de API são exibidas uma única vez, armazenadas como hash SHA-256, com escopos de um catálogo fechado, limitadas pelas permissões do dono e revogáveis instantaneamente. Veja Autenticação.
• O login tem limite de requisições por IP e por e-mail; dez tentativas malsucedidas bloqueiam a conta por 30 minutos; as tentativas malsucedidas de um mesmo endereço IP são contadas e registradas, mas, por padrão, não bloqueiam esse endereço. Cada login, falha, renovação, mudança de permissão e ação administrativa vai para o log de auditoria.

Isolamento de contas

Cada linha em cada serviço traz a conta à qual pertence, e cada consulta é filtrada por ela automaticamente; desativar o filtro exige uma chamada explícita e permitida em lista, usada apenas por operações da equipe entre contas e coberta por testes. As funções por site adicionam um filtro de site por cima. Uma requisição a um recurso de outra conta responde 404, nunca 403, para que os IDs não possam ser enumerados. Todo endpoint de gravação usa uma lista estrita de campos permitidos. Um teste de acesso entre contas é obrigatório para todo endpoint novo.

O cabeçalho X-Account-Id de cada requisição é comparado com o token, para que um bug no cliente ou um token reutilizado nunca consiga ler silenciosamente os dados de outra conta.

Criptografia

TLS 1.2 ou mais recente em todos os endpoints públicos, TLS mútuo entre serviços, TLS para todos os armazenamentos de dados, volumes criptografados em repouso e criptografia envelope por conta para campos sensíveis. Os certificados públicos são emitidos e renovados automaticamente; os certificados internos são de curta duração.

Segredos

Todos os segredos, incluindo as chaves dos seus provedores BYOK e os segredos de webhook, ficam em um gerenciador de segredos dedicado, criptografados, com escopo por serviço e auditados. Nada fica no controle de versão (garantido por varredura antes de cada commit) nem em imagens de contêiner (verificado no CI). Os desenvolvedores não têm acesso a segredos de produção por padrão; o acesso de emergência exige duas aprovações, é de curta duração e é registrado em um canal que não pode ser silenciado.

Webhooks

As entregas de saída são assinadas com HMAC-SHA256 sobre o timestamp e o corpo bruto, trazem um nonce e um ID de evento, são rejeitadas fora de uma janela de cinco minutos e são repetidas com backoff até uma fila de dead letters. Os segredos são rotacionados com uma janela de sobreposição e podem ser revogados instantaneamente. Os webhooks de entrada dos provedores são verificados com o esquema de cada provedor antes de qualquer processamento. Detalhes: Webhooks.

Limites de requisições

Quatro camadas: proteção contra DDoS e bots na rede de borda, limites por IP no proxy reverso, token buckets por conta e por identidade no gateway da API e limites de domínio dentro dos serviços. Os limites estão na visão geral da API.

Auditoria

Cada alteração é gravada em um log de auditoria somente de acréscimo e encadeado por hash, com duas classes de retenção: eventos gerais e eventos de conformidade (solicitações de titulares de dados, violações, suboperadores e registros de KYC). A classe é atribuída quando a entrada é gravada; ninguém pode editar ou excluir o log, e a limpeza automática por classe ainda não está em operação. Proprietários e Administradores podem filtrá-lo e exportá-lo. Senhas, tokens e chaves nunca são registrados em log; a camada de log oculta as chaves conhecidamente sensíveis.

Proteção de dados

• As solicitações de titulares de dados do GDPR, UK GDPR, CCPA e LGPD (acesso, exportação, exclusão) são recebidas e acompanhadas no console de conformidade, com prazos. A exclusão é feita pela equipe da RolChat, e a solicitação só é encerrada quando ela confirma; a exclusão automática em todos os módulos ainda não está disponível.
• Residência dos dados: os dados são armazenados na UE. A região não é escolhida pelo país no registo; a definição de região nas definições da conta é apenas guardada e ainda não move dados.
• Retenção conforme o plano: 1, 2 ou 3 anos. Excluir uma conversa ou um contato o oculta até o fim desse prazo; excluir uma conta é uma solicitação com 30 dias para cancelar, após os quais a equipe apaga os dados; uma conta inadimplente é mantida por 90 dias e depois apagada. A limpeza automática que aplica esses prazos está sendo implantada.
• Um Acordo de Processamento de Dados, a lista de suboperadores, a política de privacidade e a política de cookies são publicados em rolchat.com; o DPA é aceito no cadastro.
• Notificação de violações em até 72 horas, conforme exige o Artigo 33 do GDPR.

Gestão de vulnerabilidades

As dependências são monitoradas continuamente; os arquivos de lock são versionados; as imagens base são fixadas por digest; as actions do CI são fixadas por commit. Um teste de invasão feito por terceiros está programado anualmente a partir do beta, cobrindo a API, o widget e as páginas públicas, além de um cenário interno de violação presumida. Um programa privado de bug bounty virá com a disponibilidade geral. Relate problemas de segurança para security@rolchat.com.

Disponibilidade

A plataforma roda em vários nós, com failover automático para serviços sem estado e replicação gerenciada para bancos de dados. As metas de disponibilidade por plano estão definidas no seu contrato.

Resposta a incidentes

Runbooks para cada serviço, uma escala de plantão, um sistema de alertas externo que funciona mesmo quando a nossa própria infraestrutura não funciona e obrigações de notificação aos clientes incorporadas ao processo.