Política de Segurança da Informação
O que fazemos hoje para proteger os dados que você e seus participantes nos confiam.
Versão 1.0 · em vigor desde 4 de setembro de 2026
Em linguagem simples
- Este documento descreve controles que existem hoje, não planos.
- Tudo trafega cifrado. Senhas viram resumo criptográfico e nunca são guardadas em texto.
- Vídeos e áudios ficam em armazenamento privado e só abrem por link assinado que expira em uma hora.
- Acesso dentro do produto é por papel, conferido no servidor a cada requisição.
- O que ainda não temos está dito com todas as letras na última seção.
Este resumo ajuda a entender, mas não substitui o texto das cláusulas abaixo.
1. Proteção do dado em trânsito e em repouso
- 1.1Todo o tráfego usa HTTPS. O cabeçalho HSTS instrui o navegador a nunca tentar conexão não cifrada com o domínio.
- 1.2O banco de dados e o armazenamento de arquivos ficam cifrados em repouso pelos respectivos provedores.
- 1.3Tokens de integração de terceiros são cifrados com AES-256-GCM antes de gravados.
- 1.4Gravações de tela e áudios ficam em bucket privado, sem URL pública. O acesso ocorre por link assinado com validade de 1 hora, gerado apenas para quem tem permissão no workspace.
2. Autenticação e controle de acesso
- 2.1Senhas são guardadas apenas como resumo criptográfico com bcrypt.
- 2.2A sessão é mantida por token assinado com segredo do servidor.
- 2.3Cada workspace tem quatro papéis: dono, administrador, editor e leitor. A permissão é lida do banco a cada requisição, e não apenas do token, para que a remoção de acesso tenha efeito imediato.
- 2.4Toda consulta a dados de estudo é isolada por workspace.
- 2.5O painel administrativo interno é restrito a endereços autorizados por configuração, e cada ação fica registrada em trilha de auditoria com autor, ação, alvo e data.
- 2.6Redefinição de senha usa token de uso único com prazo de validade e limite de pedidos por hora.
3. Proteção contra abuso
- 3.1Rotas públicas, usadas por participantes, têm limite de requisições por endereço e por sessão.
- 3.2Cada conta tem tetos diários de uso de inteligência artificial, de síntese e transcrição de voz e de envio de arquivos.
- 3.3Os eventos de coleta são deduplicados por chave única, de modo que reenvio por rede instável não gera resposta duplicada.
- 3.4Links públicos de relatório e de trecho de vídeo usam token aleatório longo e podem ser revogados pelo cliente.
4. Desenvolvimento e mudanças
- 4.1O código é versionado, e cada mudança passa por verificação automática de tipos, testes automatizados e compilação antes da publicação.
- 4.2Migrações de banco são aditivas e revisadas manualmente antes de aplicadas.
- 4.3Erros em produção são monitorados, com remoção de corpo de requisição e de conteúdo de resposta antes do envio ao provedor de monitoramento.
- 4.4Há verificação automática de acessibilidade do fluxo do participante a cada mudança.
5. Continuidade
- 5.1O banco de dados conta com cópias de segurança gerenciadas pelo provedor.
- 5.2Gravações vencidas são apagadas automaticamente por rotina diária, conforme o prazo do plano.
- 5.3Há verificação de saúde da aplicação e alerta por e-mail quando o serviço fica indisponível.
6. O que ainda não temos
Transparência aqui vale mais do que aparência. Na data desta versão, os itens abaixo não estão implementados e não devem ser afirmados a clientes.
- 6.1Segundo fator de autenticação para pesquisadores.
- 6.2Ambiente de homologação separado da produção.
- 6.3Teste periódico de restauração de cópia de segurança, com tempo de recuperação medido.
- 6.4Certificação externa de segurança, como ISO 27001 ou SOC 2.
- 6.5Teste de intrusão por terceiro independente.
Definições pendentes
Pontos deste documento que ainda dependem de decisão comercial ou jurídica antes da versão final.
- Segundo fator de autenticação para contas de pesquisador: ainda não implementado.
- Teste de restauração de cópia de segurança: precisa ser executado e documentado.
- Certificações externas, como ISO 27001 ou SOC 2: não existem e não devem ser prometidas a clientes.