Ir para o conteúdo

Segurança & LGPD — Cliwefy

Postura de segurança e privacidade da plataforma. Cliwefy trata dados pessoais sensíveis de saúde (LGPD art. 11), então segurança não é opcional — é requisito do produto. Documento vivo: atualizar a cada mudança estrutural de segurança.

1. Classificação de dados

  • Sensíveis (saúde): prontuário, odontograma, anamnese, imagens clínicas (radiografia/foto), receitas.
  • Pessoais: cadastro do paciente (nome, CPF, nascimento, contato), cobranças.
  • Operacionais/internos: agenda, caixa, metas, configurações.

2. Isolamento multi-tenant (a regra dura)

  • Todo dado é escopado por clinic_id (unidade) e organization_id (rede).
  • O clinic_id/org_id vem sempre do servidor (guards), nunca do cliente.
  • Franqueado/staff só enxergam as unidades deles; relatórios de rede são agregações read-only.
  • Ver ADR-0001 e ADR-0002.

3. Autenticação e sessão

  • Equipe (clínica/rede): Supabase Auth (e-mail/senha) + guards server-side (requireClinicUser, requireOrgAdmin). Super-admin impersona via cookies (imp_clinic/imp_org).
  • Paciente (portal): acesso por magic link (token de uso único enviado por WhatsApp) → sessão portal_session (cookie httpOnly, 30 dias). Sem senha.
  • 2FA disponível para contas internas (flag TWOFA).

4. Controle de acesso (RBAC)

  • Permissões por módulo × papel em lib/permissions.ts (completo/leitura/nenhum).
  • Gate crítico: financeiro_dono — o P&L/DRE do dono NÃO é visível para o operador de caixa.
  • Rotas de API sempre atrás de guard; o módulo é checado no servidor.

5. Imagens e documentos clínicos

  • Armazenados no CDN (Bunny.net), fora do banco.
  • Servidos apenas por URL assinada de curta duração (Token Authentication ligado na pull zone) — acesso público sem token é bloqueado (403).
  • Compressão (webp) + thumbnail; strip de EXIF recomendado.
  • Soft-delete para conciliar retenção legal (prontuário/CRO ~10 anos) × direito de apagamento (LGPD).
  • Ver ADR-0004.

6. Gestão de segredos

  • Chaves de integração (Asaas, Bunny, Memed, SMTP, etc.) ficam em system_config (banco) ou variáveis de ambiente — nunca no frontend, nunca em repositório público.
  • Exceção: chaves públicas de sandbox/homologação (ex.: Memed homologação) podem ir ao repo, pois a própria doc do fornecedor as publica. Chaves de produção nunca.
  • getConfig com cache de 60s; getSignedUrl/token server-side apenas.

7. Assinatura e validade jurídica

  • Termos do paciente (anamnese, cancelamento de orto): assinatura eletrônica com registro de IP + user-agent + hash do documento (base legal Marco Civil). IP sempre do header do proxy, nunca do corpo.
  • Receita/atestado: via Memed (assinatura por certificado em nuvem ICP-Brasil). Ver ADR-0010.

8. Trilha de auditoria

  • Anexos e eventos registram uploaded_by/autor + timestamps; o portal grava IP/UA.
  • Ocorrências, cancelamentos e reaberturas têm histórico e aprovadores.
  • Changelog de releases em /dev/atualizacoes.

9. Infraestrutura

  • App Next.js (standalone) em Docker no VPS, atrás de nginx (TLS/Let's Encrypt com deploy-hook).
  • Banco Supabase (Postgres) gerenciado; pooling pelo Supavisor.
  • CDN Bunny.net para mídia.
  • Deploy: git push → VPS git reset --hard origin/main + rebuild do container.

10. Hardening — pendências conhecidas

  • [ ] Rotacionar segredos hardcoded no utilitário de migração (db.py: PAT + senha do VPS).
  • [ ] Mover o cron_secret de reminders para system_config (hoje hardcoded no arquivo).
  • [ ] Revisar client_max_body_size do nginx (≥ 25MB) para uploads.
  • [ ] Política formal de backup/restore e DR documentada.
  • [ ] Varredura de dependências (SCA) e SAST no CI.