scoreodonto.com/documentação/STATUS-SEGURANCA-E-PRODUCAO.md

Status — Segurança & Produção (ScoreOdonto)

Resumo do que foi feito e do que falta. Atualizado em 22/jun/2026. Produção no ar: v1.0.19 (715b2dc) — fila A concluída (push → CI → tag → deploy). Commits publicados (git push feito). A rotação do JWT_SECRET segue aplicada e verificada em produção.

---

✅ O QUE JÁ FOI FEITO

1. Segredos

• JWT_SECRET rotacionado em DEV e PRODUÇÃO (recriado o backend na VPS1 na mesma tag, sem rebuild; /api/health e /api/version validados). → vetor de tomada de conta FECHADO (o segredo vazado não forja mais tokens). Ação operacional na VPS1 — sem commit (o segredo não é versionado).
• backend/.env fora do tracking do git + backend/.dockerignore (o Dockerfile fazia COPY . . sem .dockerignore → segredos iam para dentro da imagem) + .env.example. Commits fcf2fb1.
• Senhas hardcoded removidas do docker-compose.yml: banco via SCOREO_DB_PASS (com :? fail-fast); DRAGONFLY_URL (com senha) movido para env_file. Commit 3aa6a44. Validado em DEV (pgdev/cache ok).

2. Frontend

• /update (migração de banco) restrito a superadmin (era acessível a qualquer um, até deslogado).
• Deep-links corrigidos (/comissoes, /glosas faltavam no ROUTE_MAP → caíam em dashboard).
• Commit 1559387. (Build compila; validação visual de RBAC precisa de navegador.)

3. RBAC intra-clínica no backend (99 rotas) — NÚCLEO FECHADO

Antes: qualquer membro autenticado (até paciente) podia chamar ações privilegiadas direto na API (a UI escondia, o backend não barrava). Agora há autorização por cargo, espelhando o isViewAllowed do frontend, via 3 helpers: requireCapability, requireCapabilityRow, requireCapabilityFromOrders.

Grupo	Commit
Financeiro (comissões/repasses/financeiro/glosas)	f4e7fe3
Gestão de equipe/clínica (membros/setores/funções/reset-senha/cor)	9ad65c3
Cadastros administrativos (dentistas/especialidades/procedimentos/planos + reorder)	116200c + 0667456
Operação clínica (pacientes/agenda/leads)	5b58a8a
Orçamentos/Contratos	16c13ad
Sub-pass clínico (presença/pendências/horários/detalhes de paciente)	0fc69bb

• Marketplace (salas/sala-reservas/propostas): auditado — já protegido por POSSE nos handlers (owner_usuario_id, profissional destinatário, dono/solicitante). Sem gap; sem mudança. Commit 0667456.
• Validado em DEV com tokens forjados: dono passa, dentista/paciente 403, isolamento cross-tenant intacto.

4. Documentação & Skills

• documentação/MAPA-FUNCIONAL-COMPLETO.md (inventário rotas/telas/botões/fluxos/módulos).
• documentação/AUDITORIA-ESTRATEGICA-MODELAGEM.md (Pessoa→Vínculo→Workspace, débitos, riscos).
• ScoreOdonto_Skills_Enterprise/: 62/62 skills preenchidas com conteúdo real. Commits 5b99292, e83af04, f22e30e.

5. Pré-requisito de produção

• SCOREO_DB_PASS provisionado na VPS1 (/home/deploy/stack/scoreodonto.com/.env, 0600), valores extraídos do container em execução, .gitignore da VPS1 ajustado, conexão validada (SELECT 1 = ok).

6. Fila A concluída — PRODUÇÃO EM v1.0.19 (22/jun/2026)

• git push do lote (RBAC 99 rotas + segredos fora do compose/imagem + correções de frontend).
• CI desbloqueada: o build falhou na 1ª vez (SCOREO_DB_PASS com :? quebrava a interpolação do compose no docker compose build do runner) → corrigido com placeholder runtime-only no build.yml (commit 715b2dc). Build verde → imagens :715b2dc (back+front, atômicas) publicadas no registry.
• Tag v1.0.19 → 715b2dc: job promote re-tagueou :715b2dc → :v1.0.19 sem rebuild (digests idênticos conferidos) e rodou deploy-prod.sh v1.0.19 na VPS1.
• Backup do banco antes do deploy: ~/backups/scoreodonto_20260622_0005.dump na VPS1 (PG18).
• Verificado em produção: /api/version = v1.0.19 (715b2dc, PROD); /api/health = ok (DB ok, cache ok). DEV (8020) realinhado ao mesmo commit via ./dev-build.sh (mostra v1.0.19).
• Rollback trivial: ./deploy-prod.sh v1.0.18 (+ dump do banco, se necessário).

---

⏳ O QUE FALTA

A) Levar o trabalho a produção (fila) — ✅ CONCLUÍDA

1. Imagem limpa v1.0.19 → FEITO (ver "Fila A concluída" acima). Produção em v1.0.19/715b2dc.
2. Compose novo na VPS1 (opcional, passo 2b): deploy-prod.sh não faz git pull → o docker-compose.yml da VPS1 segue o antigo. Para tirar a senha hardcoded do compose local, copiar o novo docker-compose.yml (scp) + recreate. O root .env já provisionado cobre isso. Ainda pendente.

B) Rotação dos demais segredos (ainda vivos no histórico/artefatos antigos)

3. Senha do banco (scoreodonto_user) — contida ao scoreodonto; exige refactor já feito no compose + ALTER USER + atualizar .env/backend/.env + recreate. Risco de outage → com cuidado/janela.
4. Senha do Dragonfly (cache) — ⚠️ compartilhada entre apps (rx, newwhats, subdominio, mercado); trocar derruba os outros → exige janela coordenada.
5. OPENAI_API_KEY / GEMINI_API_KEY — só você rotaciona (painéis OpenAI/Google); depois colo os novos valores no .env e recrio.
6. Histórico do git — backend/.env (e um backend/.env.bak) estão no histórico. Após rotacionar tudo, o scrub de histórico (force-push, destrutivo) vira cosmético — não recomendado às pressas.

C) Residual de qualidade (não-bloqueante; do MAPA / AUDITORIA)

• RECEITA de procedimento é opcional (gerarLancamento/valor>0) → decidir se vira padrão (risco de caixa).
• Estado de plugins divergente cliente/servidor (localStorage vs usuario_plugins).
• Órfã OrthoReports.tsx; SyncView desativada; server.js.bak/scripts legados → limpeza.
• Marketplace: gateway de pagamento (salas têm valor, sem captura) e assinaturas SaaS (manual).

D) Débitos de modelagem (estratégico; exige aprovação + janela)

• dentistas como projeção da pessoa (hoje duplica a pessoa por clínica).
• pacientes com identidade de pessoa (hoje preso à clínica, não-portável) — antes, decisão LGPD/jurídica.
• Unificar workspace (clinicas + salas); entidade "rede/grupo" acima da clínica.

Recomendação estratégica única: assumir a Pessoa como âncora e parar de manter o legado clínica-cêntrico em paralelo. Detalhe em AUDITORIA-ESTRATEGICA-MODELAGEM.md.

---

Commits da sessão — PUBLICADOS (git push feito; produção em v1.0.19)

Todos empurrados para origin/main. Promovidos a produção via tag v1.0.19 (commit 715b2dc). A rotação do JWT_SECRET não está nesta lista (foi ação operacional na VPS, sem commit).

715b2dc ci(build): desbloqueia build — SCOREO_DB_PASS placeholder na interpolação
8a27f3b docs+infra: corrige status (JWT/contagem) + versão em DEV (dev-build.sh)
6adf353 docs: status geral de segurança & produção (este documento)
f22e30e docs(skills): completa as 62 skills
e83af04 docs(skills): biblioteca operacional
5b99292 docs: auditoria funcional + estratégica
0667456 security(rbac): reorder + auditoria do marketplace
0fc69bb security(rbac): sub-pass clínico
16c13ad security(rbac): orçamentos e contratos
5b58a8a security(rbac): operação clínica
116200c security(rbac): cadastros administrativos
9ad65c3 security(rbac): gestão de equipe/clínica
f4e7fe3 security(rbac): rotas financeiras
1559387 security/fix(front): /update + deep-links
3aa6a44 security(infra): senhas fora do compose
fcf2fb1 security(infra): .env fora do git + .dockerignore

Como retomar

• Fila A: ✅ concluída — produção em v1.0.19 (715b2dc). Próximo release: git push → CI builda :<sha> → git tag vX.Y.Z → job promote deploya na VPS1.
• Antes de abrir a usuários reais: concluir B (rotações) — sobretudo as API keys (você) e a senha do banco.
• Pendência pontual: passo A.2 (compose novo na VPS1 via scp + recreate) para tirar a senha hardcoded do compose local.
• Código rodando em DEV (dev.scoreodonto.com) e PROD no mesmo commit 715b2dc; rollback de prod: ./deploy-prod.sh v1.0.18 (+ dump ~/backups/scoreodonto_20260622_0005.dump se necessário).