SSTSegura

Segurança da plataforma

Versão 1.0 · Vigente desde 04/05/2026

Reportar uma vulnerabilidade

Envie para seguranca@sstsegura.com.br. Resposta inicial em até 48 horas úteis. Resolução: P0 (RCE/PII leak) em 7 dias, P1 em 30 dias, demais em 90 dias. Para vulnerabilidades de alto impacto, oferecemos reconhecimento público no Hall of Fame após o fix.

Não faça pentest ativo em produção sem autorização prévia. Não acesse dados de outros clientes. Não realize DoS, brute-force ou spam.

Tenant isolation

RLS em 100% das tabelas

Audit append-only

Triggers + cadeia Merkle

MFA inviolável

Reset não bypassa

TLS 1.3 + AES-256

Trânsito + repouso

1. Modelo de ameaças

Operamos sob pressuposto Zero Trust dentro do tenant: nem o admin do cliente, nem nosso super-admin interno, podem violar as garantias estruturais abaixo. Cada controle é implementado em código e validado por triggers PostgreSQL ou políticas RLS — não depende de comportamento bem-intencionado de pessoas.

Garantias estruturais

GarantiaComo é implementada
Tenant isolation (zero leakage entre clientes)Row-Level Security em 100% das tabelas via auth_company_id() — Postgres impede no nível do banco
Audit log append-onlyTriggers BEFORE UPDATE/DELETE bloqueiam mutação de qualquer linha — incluindo super-admin
Tamper-evidence do audit logCadeia SHA-256 (Merkle-lite): cada linha referencia o hash da anterior. Adulteração detectada em O(N) via verify_audit_chain()
MFA não pode ser bypassado por reset de senhauseMfaEnforcement + MfaGuard em PrivateRoute, validado E2E
Idempotência de pagamentosstripe_webhook_events.event_id como PK — eventos duplicados rejeitados pelo banco
ASOs com peso de provaSHA-256 imutável + QR code de validação pública em /v/aso/<hash>

Ameaças endereçadas

  • Vazamento de dados entre clientes (RLS PostgreSQL, validado por testes)
  • Adulteração silenciosa de logs (cadeia Merkle SHA-256)
  • Bypass de MFA via fluxo de reset de senha (corrigido e testado)
  • Reprocessamento duplicado de webhooks Stripe (idempotência por event_id)
  • Documento médico forjado (hash + QR code, validável publicamente)
  • Sequestro de sessão (TLS 1.3, JWT expiration curto, HttpOnly cookies)
  • SQL injection (queries parametrizadas, nunca concatenação de input)
  • Cross-Site Scripting (auto-escape do React + sanitização em rich text)
  • Force-push em main com bypass (branch protection no GitHub)

Ameaças NÃO endereçadas (declaração honesta)

Acreditamos que transparência sobre limitações é parte de uma postura de segurança madura. Estes vetores existem e nossa mitigação é parcial:

  • Coação física do admin do cliente: o audit log captura a ação, mas a cadeia Merkle apenas prova que houve adulteração subsequente — não previne.
  • Insider threat na infraestrutura Supabase: dependemos das políticas SOC 2 da Supabase. PITR habilitado para recovery.
  • Ataque de cadeia de suprimentos npm: rodamos npm audit em CI; pin de versões em lockfile; ausência de dependências exóticas.
  • Quantum break do SHA-256: out of scope até maturidade do pós-quantum (NIST PQC) na stack web.

2. Controles em produção

Snapshot do que está implementado e em uso (não roadmap):

  • TLS 1.3 em todas as rotas (Vercel + Supabase). HSTS habilitado.
  • AES-256 em repouso (gerenciado pela Supabase).
  • Senhas com bcrypt (Supabase Auth).
  • MFA TOTP obrigatório para admins, com backup codes hasheados via pgcrypto.
  • Edge functions com verify_jwt:true por padrão. Webhooks públicos validam HMAC SHA-256.
  • Audit log em 9 tabelas Tier 1 (PII + dados de saúde + config crítica). Retenção 24 meses.
  • PITR de 7 dias + daily backups + snapshot manual mensal off-site (RPO 1h, RTO 4h).
  • Histórico de uptime público em /status (probes a cada 5 min, retenção 90 dias).
  • CSP em rollout. CSRF mitigado por uso de tokens em header.

3. Conformidade

NormaStatusCobertura
LGPDImplementadoDPO nomeado, RIPD em /ripd, DPA em /dpa, política em /privacidade. 10 direitos do titular operacionais.
NR-7 (Portaria MTb 3.214/78)ImplementadoASO com hierarquia médica completa (médico examinador + responsável técnico).
eSocialImplementadoEmissão de S-2220 (monitoração de saúde) suportada.
ISO 27001RoadmapA.9 (Access Control) e A.10 (Cryptography) atendidos. A.12.4 (Logging) via cadeia Merkle. Certificação formal não obtida.
SOC 2Roadmap longo prazoDependemos de SOC 2 da Supabase para infrastructure layer.

4. Pentest e validação contínua

  • Pentest interno DIY (OWASP ZAP modo passivo + checklist Top 10): planejado para maio/2026.
  • Pentest externo formal: planejado após primeiro contrato enterprise.
  • Bug bounty: avaliação em 2026 H2 dependendo de volume de reports.
  • npm audit em CI a cada deploy.

5. Histórico de incidentes

Nenhum incidente público até 2026-05-04. Eventos internos sem impacto a clientes registrados em SECURITY.md (visível no repositório privado).

Hall of Fame

Em construção. Pesquisadores que reportarem vulnerabilidades de alto impacto serão reconhecidos aqui (com permissão), após fix aplicado.