Security Architecture Review — Plataforma SaaS¶
Objetivo¶
Validar a postura de segurança atual da plataforma, identificar lacunas e priorizar melhorias para um SaaS que processa dados pessoais e dados sensíveis de saúde.
Data de referência: 2026-03-08
Escopo¶
- Backend:
billings-ease-backend - Web:
billings-ease-web - Infra/edge observável publicamente:
api.billings-ease.com.brewww.billings-ease.com.br
Método¶
- Evidência de implementação por código.
- Verificação runtime para headers HTTP/TLS/CORS via
security_check.shecurl. - Classificação por controle:
implementado,parcial,ausente.
Matriz de validação¶
| Controle | Status | Evidência | Risco residual | Prioridade |
|---|---|---|---|---|
| JWT bearer, access/refresh separados, rotação e reuse detection | Implementado | internal/modules/auth/service.go, internal/modules/auth/shared/jwt.go, internal/models/refresh_session.go |
Baixo | Manter |
| Hash de refresh token em banco | Implementado | internal/modules/auth/service.go (hashToken), internal/models/refresh_session.go (TokenHash) |
Baixo | Manter |
| Proteção enumeração (forgot/resend) | Implementado | internal/modules/auth/service.go (ForgotPassword, ResendVerificationEmail) |
Baixo | Manter |
| OAuth/OIDC com state+PKCE+TTL+consumo único | Implementado | internal/modules/auth/services/oauth/provider.go, state_store.go |
Baixo | Manter |
| Autorização por role/módulo + aprovação de perfil | Implementado | internal/middleware/role/role.go, internal/middleware/moduleaccess/moduleaccess.go, internal/middleware/profile/profile.go |
Médio (cobertura depende da aplicação em todas rotas) | Manter + revisão periódica |
| Proteção BOLA/IDOR por escopo relacional | Implementado | internal/security/access_policy/policy.go |
Médio (exige disciplina em novos endpoints) | Manter + testes de regressão |
public_id UUID em v2 |
Implementado | internal/middleware/publicid/publicid.go |
Médio (modo transitório aceita ID legado em rotas mapeadas) | P1 |
| LGPD (export, exclusão, assinatura HMAC, pseudonimização, trilha) | Implementado | internal/modules/lgpd/service.go, internal/modules/lgpd/routes.go, migração 033_create_lgpd_core_tables.sql |
Baixo | Manter |
| Headers HTTP de segurança (HSTS, etc.) | Parcial | Runtime: security_check.sh e curl; edge server: cloudflare; app não define headers de segurança próprios |
Médio | P0 |
| CSP ativa | Ausente | Sem política CSP no app (billings-ease-web/index.html) e sem middleware/headers no backend |
Alto (XSS impacta sessão/dados) | P0 |
| Audit trail estruturado transversal (auth/admin/dados) | Parcial | Existem trilhas específicas: AdminAuditLog, LGPDEvent, PlaybackTokenAuditLog |
Médio | P1 |
| Revogação antecipada de access token | Parcial | Refresh/sessão revogável; access token é stateless | Médio (janela até expiração) | P1 |
Rotação de chaves JWT de autenticação (kid, múltiplas chaves) |
Ausente | Auth usa HS256 com segredo único (auth/shared/jwt.go) |
Alto (compromisso de segredo) | P0 |
| Segurança de upload (MIME real, extensão, tamanho, sanitização) | Implementado | internal/modules/professional/profile/upload.go, internal/modules/client/profile/service.go, internal/infra/storage/r2.go, internal/infra/security/filename.go |
Médio (sem AV/CDR) | P2 |
| Monitoramento de sinais de segurança | Parcial | Métricas e alertas gerais em internal/observability/prometheus.go e docs/prometheus.alerts.yml; sem regras focadas em abuso de auth |
Médio | P1 |
Itens validados em runtime (produção)¶
Strict-Transport-Security: presente.X-Content-Type-Options: nosniff: presente.- Redirect HTTP -> HTTPS: ativo.
- CORS para origem não confiável: sem
Access-Control-Allow-Originexplícito. X-Frame-Options,Referrer-Policy,Permissions-Policy,Content-Security-Policy: não observados na checagem realizada.
Conclusão executiva¶
A arquitetura atual é forte em autenticação/sessão, autorização contextual e fluxo LGPD.
As lacunas prioritárias estão na camada de hardening de browser/edge e no ciclo de gestão de chaves/token de autenticação:
- Ativar CSP e completar headers de segurança no edge.
- Implementar rotação de chave JWT com
kid. - Consolidar trilha de auditoria de eventos sensíveis em modelo transversal.
Referências técnicas¶
billings-ease-backend/internal/modules/auth/*billings-ease-backend/internal/middleware/*billings-ease-backend/internal/modules/lgpd/*billings-ease-backend/internal/observability/prometheus.gobillings-ease-web/src/services/api.tsbillings-ease-web/src/components/ProtectedRoute.tsxbillings-ease-web/index.htmlsecurity_check.sh