Política de Segurança

Esta Política de Segurança descreve princípios e controles que a SigmaCode aplica para proteger dados pessoais, pagamentos, sessões do portal e o conteúdo digital, em linha com o art. 46 da LGPD e o dever de segurança do Marco Civil da Internet.

1. Objetivos

• Garantir confidencialidade, integridade e disponibilidade dos dados e sistemas.
• Reduzir riscos de acesso indevido, fraude de pagamento, abuso de afiliados e vazamento de conteúdo.
• Assegurar continuidade razoável da entrega no portal autenticado.
• Permitir resposta adequada a incidentes de segurança.

2. Princípios

• Privacidade desde a concepção e por padrão: coleta mínima compatível com login, compra, ownership e programas publicados.
• Menor privilégio: chaves de API, service role e painel admin restritos ao necessário.
• Separação de responsabilidades: cartão só no Mercado Pago; conteúdo pago só com sessão + ownership; segredos fora do client-side.
• Rastreabilidade: aceites legais versionados, pedidos e claims idempotentes.
• Defesa em profundidade: validação no servidor, assinaturas, RLS/policies no banco e controles de aplicação.

3. Controles técnicos

3.1 Transporte e aplicação web

• HTTPS/TLS em produção na plataforma de hospedagem.
• Framework moderno (Next.js) com cabeçalhos e práticas voltadas a reduzir XSS, clickjacking e superfícies comuns.
• Rotas sensíveis do portal exigem sessão autenticada; parâmetros de redirecionamento (next=) são sanitizados (anti open-redirect).

3.2 Autenticação e sessão

• Login por provedor de autenticação (magic link / OTP) com fluxo PKCE; o code-verifier permanece no mesmo navegador da solicitação.
• Cookies de sessão tratados como sensíveis; troca de conta e callback evitam misturar sessões de usuários distintos.
• Conteúdo do pack no portal exige usuário autenticado e verificação de ownership no servidor (não basta “conhecer o productId”).

3.3 Pagamentos

• Checkout Pro / Mercado Pago: a SigmaCode não armazena dados de cartão.
• Preferências criadas no servidor; preço sempre do catálogo backend.
• Webhooks com validação de assinatura (HMAC), processamento idempotente (claim) e reconciliação de valor com o pedido.
• Reembolso na garantia de 7 dias: pedido no portal, análise no admin e estorno via API do Mercado Pago; acesso ao pack é revogado quando o pedido passa a refunded.
• Fallback de confirmação pós-retorno do checkout consulta a API do Mercado Pago para reduzir pedidos “pagos mas não liberados” sem abrir liberação sem comprovação.

3.4 Dados, storage e conteúdo

• Pedidos, perfis e ledgers em banco com chave de serviço apenas no servidor; políticas de acesso (RLS) onde aplicável.
• PDFs em storage controlado; entrega preferencial via portal autenticado — download público aberto está desativado no desenho atual.
• Segredos (tokens MP, service role, webhook secret) em variáveis de ambiente / painel de deploy, não no código público.

3.5 Indicações e parcerias

• Atribuição first-touch de indicação protegida no banco (campos de referral imutáveis após a primeira gravação válida; clientes não podem alterar referred_by via API anon/authenticated).
• Self-referral bloqueado; conversões idempotentes por pedido; créditos e payouts auditáveis em ledger.
• Endpoints de resgate/indicação com autenticação, checagem de origem (same-origin em mutações) e rate limiting leve.

3.6 Painel administrativo

• Acesso separado do portal do aluno, com autenticação própria de operador, cookie httpOnly e proteções de mutação (ex.: same-origin).
• Ações econômicas (aprovar parceiro, marcar payout, config do programa) restritas a operadores autenticados.

3.7 Registro de aceite (LGPD / CDC)

• Checkout, claim gratuito e resgate por créditos exigem aceite da versão vigente do pacote legal (2026-09-03).
• Versão e timestamp do aceite podem ser gravados no pedido para auditoria.

4. Controles organizacionais

• Need-to-know para chaves e painéis (MP, hospedagem, banco, e-mail).
• Proibido compartilhar senhas/tokens em canais inseguros.
• Revisão de acessos quando houver mudança de equipe ou provedor.
• Alterações sensíveis de schema e políticas preferencialmente via migrations versionadas.

5. Incidentes de segurança

Em incidente com risco ou dano relevante aos titulares:

• contenção e investigação;
• avaliação de risco aos titulares;
• comunicação à ANPD e aos titulares quando exigido pela LGPD e normas da ANPD;
• registro de lições aprendidas e reforço de controles.

Canal para reportar vulnerabilidade ou incidente suspeito: contato@sigmacode.dev (assunto: “Segurança”). Não utilize esse canal para explorar falhas em produção sem autorização.

6. Responsabilidades do usuário

• Proteger o e-mail da conta e não encaminhar magic links a terceiros.
• Abrir o link de login no mesmo navegador em que solicitou o acesso (requisito do fluxo PKCE).
• Não compartilhar PDF/acesso em desacordo com os Termos de Serviço.
• Usar dispositivos e redes razoavelmente seguros ao pagar e ao entrar no portal.
• Comunicar acessos indevidos à conta ou ao material.

7. Divulgação responsável

Pesquisadores que identifiquem vulnerabilidades de boa-fé podem reportar pelo canal “Segurança”. Pedimos que não publiquem detalhes exploráveis antes de correção razoável e que não acessem dados de outros titulares.

8. Limitação

Nenhum controle elimina todos os riscos. Esta Política não é garantia absoluta contra ataques sofisticados, mas documenta o compromisso contínuo com a segurança e com a LGPD.

9. Atualizações

Esta Política integra o pacote legal versão 2026-09-03 (3 de setembro de 2026) e pode ser revisada periodicamente. Ver também a Política de Privacidade.