Análise LGPD dos dados armazenados: anonimização e pontos de vazamento

[hbgit]

Contexto

O schema do backend já persiste dados pessoais e de saúde em diversas tabelas — users (nome, data de nascimento, cpf_hash), patients (contato de emergência, condições crônicas, hash da última localização), triage_sessions (respostas de triagem em JSONB), visits (notas do ACS em JSONB), alerts (hash de localização, device_id), consent_logs e audit_logs (ver migrations em backend/lib/src/infrastructure/database/migrations/). Já existe um documento de requisitos de conformidade em spec/lgpd_design.md (LGPD-RF01 a RF21) e alguns campos já nascem hasheados (cpf_hash, ip_hash, last_location_hash), mas não existe ainda uma análise que confirme, campo a campo, se isso é suficiente, nem um levantamento de pontos de possível vazamento de dados no código/infra.

Objetivo

@GuilhermeAlmeidadaLuz, pedimos que você analise os dados armazenados pelo SinalACS sob a ótica da LGPD, com três focos:

1. Inventário de dados: mapear cada tabela/coluna do schema atual e classificar (identificável, sensível/saúde, já anonimizado/pseudonimizado, anônimo).
2. Necessidade de anonimização adicional: apontar quais campos hoje em texto claro deveriam ser hasheados, truncados, tokenizados ou removidos, e se o hashing já existente é adequado (ex.: hash de CPF sem salt tem espaço de busca pequeno e é praticamente reversível por força bruta — vale confirmar como cpf_hash é gerado).
3. Pontos de possível vazamento de dados: no código do backend, nos logs, na infraestrutura de deploy e nos apps.

Escopo sugerido

• Campos sensíveis em texto claro — avaliar necessidade de anonimização/pseudonimização em: users.name, users.birth_date, patients.emergency_contact, patients.chronic_conditions (JSONB — dado de saúde sensível, art. 5º II da LGPD), triage_sessions.answers (JSONB, pode conter respostas de sintomas), visits.notes (JSONB, texto livre do ACS — risco de conter dado de saúde não estruturado), alerts.device_id / triage_sessions.device_id.
• Qualidade do hashing já existente — cpf_hash, ip_hash, last_location_hash/location_hash: confirmar algoritmo, uso de salt, e se são efetivamente irreversíveis.
• Vazamento já identificado, como ponto de partida: em backend/bin/server.dart o boot do servidor faz print('Database URL: ${config.databaseUrl}'), o que expõe usuário e senha do PostgreSQL em texto claro nos logs do processo (e, em produção, nos logs da plataforma de hosting/CI). Vale mapear se há outros print/logs equivalentes vazando segredos ou dados pessoais.
• Retenção e exclusão (LGPD-RF07) — hoje não há rotina de expurgo/anonimização de dados antigos em alerts, visits, triage_sessions; avaliar se falta.
• Dados em ambiente não produtivo — confirmar que backend/lib/src/infrastructure/database/seeds/development.sql e os dados usados em testes/CI são sempre fictícios, nunca dados reais.
• Piloto free-tier — backend/DEPLOY.md descreve um caminho de deploy usando Postgres/MQTT gerenciados por terceiros (Neon, HiveMQ Cloud); mapear onde dados pessoais passam a residir fora do controle direto do projeto e se isso é aceitável no estágio atual (protótipo, sem dados reais de pacientes).

Entregável esperado

Um relatório (sugestão: novo documento em spec/, ex. spec/lgpd_data_audit.md) com:

1. Inventário de dados por tabela/coluna e classificação de sensibilidade.
2. Recomendações concretas de anonimização/pseudonimização, por campo.
3. Lista de pontos de vazamento encontrados, com severidade e sugestão de correção.

Como contribuir

Entregue via Pull Request (documento novo em spec/ e, se aplicável, correções pontuais de código — ex. remover segredos de logs), em vez de só comentar aqui. Assim dá pra revisar e discutir cada achado inline no diff.

Referências

• spec/lgpd_design.md — requisitos de conformidade LGPD já mapeados
• backend/lib/src/infrastructure/database/migrations/ — schema completo do banco
• CLAUDE.md — invariantes de negócio/privacidade
• backend/DEPLOY.md — piloto free-tier e onde os dados trafegam