Segurança & LGPD

Dados sensíveis exigem controles sérios — é assim que tratamos os seus

Criptografia, controle de acesso por titularidade e princípios de LGPD embutidos na arquitetura, não anexados depois.

Dados sensíveis de saúde: voz, expressão facial e conteúdo de sessão terapêutica são tratados como dados sensíveis nos termos da LGPD (Lei 13.709/2018). Esta página descreve os controles técnicos e organizacionais aplicados.

Proteção de dados

Como os dados de sessão são protegidos

Criptografia

Dados em trânsito protegidos por TLS; dados em repouso armazenados de forma criptografada no banco analítico.

Controle de acesso

Cada relatório de sessão é vinculado à titularidade do profissional responsável — acesso restrito por conta, não por sessão compartilhada livremente.

Anonimização analítica

Métricas agregadas para pesquisa interna usam hash de sessão e paciente, sem dados diretamente identificáveis na camada de analytics.

Como funciona, sem simplificar demais

O caminho real de uma sessão

Preferimos descrever a operação completa a resumi-la de forma que pareça mais simples do que é.

Transmissão e processamento

Sessões remotas usam WebRTC; quando a conexão direta entre os dispositivos não é possível, um servidor TURN atua como retransmissor. Parte relevante das métricas é calculada no navegador do profissional; segmentos de áudio podem ser enviados ao backend do FROID e a um provedor de transcrição especializado para processamento de voz, imagem e texto.

Hospedagem e backups

Transcrições, relatórios e registros autorizados são armazenados na infraestrutura do FROID, que pode incluir hospedagem na Estônia e fornecedores de pagamento, IA, e-mail e agenda — o que pode envolver transferência internacional, protegida pelos mecanismos contratuais e técnicos aplicáveis. Backups são criptografados e verificados periodicamente.

Isolamento multitenant

Dados de cada organização (clínica ou profissional) são segregados por Row-Level Security (RLS) no banco de dados — uma organização não acessa, por construção, registros de outra.

Auditoria de acesso

Acesso, alteração, exportação e negação de acesso a relatórios e dados de pacientes são registrados em trilha de auditoria, vinculados à conta que realizou a ação.

Conformidade

LGPD e boas práticas do setor

Tratamos os princípios da LGPD — finalidade, necessidade, transparência e segurança — como requisitos de arquitetura, não como checklist posterior. Isso segue o mesmo racional aplicado por padrões internacionais de SaaS de saúde (HIPAA, GDPR): a conformidade precisa estar embutida em criptografia, trilhas de auditoria e controle de acesso baseado em papel, não apenas em contrato.

Para clínicas e profissionais que contratam o FROID, disponibilizamos os termos de tratamento de dados como parte do processo de cadastro profissional.

Compromissos atuais

  • Consentimento explícito do paciente antes de cada sessão gravada
  • Direito de exclusão de dados mediante solicitação
  • Notificação em caso de incidente de segurança

Modelo de responsabilidade compartilhada

Como em qualquer SaaS de saúde, a segurança se divide: o FROID é responsável pela infraestrutura da plataforma (criptografia, backups, controle de acesso à aplicação); a clínica/profissional contratante é responsável pela gestão de acesso de sua equipe e pelo consentimento obtido do paciente.

Stack técnico relevante

Backend FastAPI com persistência em DuckDB para analytics agregado; controle de titularidade de relatório via _can_access_report() e _report_owner_email(); hashing de sessão anônima via _anonymous_session_hash() antes de qualquer agregação estatística.

Endurecimento de plataforma e infraestrutura

  • Criptografia: TLS na borda; em repouso, criptografia autenticada Fernet (AES-128-CBC + HMAC-SHA256) com rotação de chaves via MultiFernet; senhas com PBKDF2-HMAC-SHA256 (120.000 iterações + salt).
  • Cabeçalhos de segurança: HSTS com preload, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options: DENY, Referrer-Policy e Permissions-Policy (libera apenas câmera/microfone).
  • Superfície de rede reduzida: serviços internos não publicados na interface pública; todo acesso passa pelo Caddy sob TLS; firewall permitindo apenas 80/443 e SSH restrito.
  • Contêineres sem privilégios: processo não-root, no-new-privileges, Linux capabilities removidas (cap_drop: ALL) e limite de processos.
  • Defesa de aplicação: validação do SQL gerado por IA (allowlist SELECT/WITH, conexão read_only, tabelas restritas); limitação de taxa em autenticação e ingestão; limites de corpo e timeouts na borda.
  • Integridade em tempo real: o processamento de sinais (F0/MFCC/envelope) roda em thread pool para não bloquear o laço de análise sob sessões concorrentes.
  • Operação: dependências fixadas para builds reproduzíveis; healthchecks por serviço; backups criptografados off-site com teste de restauração.