Centro de Segurança

Documentação de compliance (CPG / enterprise)

Pacote público para due diligence de compradores enterprise. Cada documento abaixo reflete controles implementados em produção (atualizado 2026-05-25).

Controles ativos em produção

Cada controle abaixo está em código, com teste automatizado de regressão e evidência rastreável em audit/FINDINGS.md. A página é atualizada a cada rodada de auditoria interna.

Sub-operadores principais

Lista resumida — a página completa, com DPA, jurisdição e finalidade, está em /subprocessors.

Divulgação responsável (Responsible Disclosure)

Política completa em .github/SECURITY.md. Resumo dos SLAs:

• 24 horas para confirmar o recebimento do relatório.
• 72 horas para triagem e classificação de severidade.
• 7 dias para fix de severidade Crítica / Alta (ou mitigação documentada).
• 30 dias para fix de severidade Média / Baixa.
• Safe harbor para pesquisas em conformidade com a política.

O que ainda não temos (transparência)

Honestidade pesa mais do que selo. Itens em andamento que não fazem parte do nosso posture atual:

• Certificação SOC 2 Type II — fora do escopo pré-launch; planejada após primeiro contrato enterprise.
• Pentest externo de terceiro — em planejamento para o próximo trimestre.
• Bug bounty program — avaliado conforme o pipeline cresce.
• WAF Enterprise dedicado — atualmente usamos a proteção edge da Vercel + nosso CSP.

Autenticação

• Autenticação por e-mail e provedores OAuth confiáveis (via Supabase Auth).
• Senhas armazenadas em hash pelo provedor de autenticação; nunca em texto puro.
• Suporte a autenticação multifator (MFA via TOTP) — exigido para administradores internos.
• Recuperação de senha por link de uso único, expirável.

Controle de acesso

• Row Level Security (RLS) em todas as tabelas com dados de usuários e workspaces.
• Service role só é usado em rotas server-side autenticadas e auditadas.
• Papéis de workspace (admin, editor, viewer) são checados antes de qualquer ação sensível.
• Princípio do menor privilégio aplicado a contas de operação.

Isolamento entre workspaces

• Cada workspace tem chaves e identificadores próprios; políticas de RLS impedem leitura cruzada.
• Compartilhamentos são explícitos e revogáveis pelo admin do workspace.

Criptografia

• Tráfego em HTTPS/TLS por padrão. Cabeçalhos de segurança (HSTS, CSP) ativos no proxy.
• Criptografia em repouso fornecida por Vercel e provedores de armazenamento.
• Tokens de sessão e tokens CSRF gerados com entropia criptográfica.

Logs e observabilidade

• Logs de aplicação e erros monitorados via provedores de observabilidade (Sentry, etc.).
• Logs de auditoria privacy-sensíveis são gravados em tabela dedicada e somente leitura.
• IP e User-Agent só são armazenados em forma de hash com pepper.

Backups e continuidade

• Backups gerenciados pelo provedor de banco de dados, com retenção e restore testado periodicamente.
• Capacidade de restauração para incidentes operacionais sem perder consistência de billing.

Resposta a incidentes

• Plano de resposta a incidentes com playbooks de contenção, comunicação e pós-mortem.
• Registros internos no security_incidents; comunicações externas seguem o art. 48 da LGPD.
• Notificação à ANPD e aos titulares quando o incidente exigir, dentro de prazo razoável.

Defesas contra abuso

• Rate limiting distribuído (Upstash Redis) obrigatório em produção. Em desenvolvimento há fallback em memória; a aplicação se recusa a iniciar em produção sem Redis.
• Proteção CSRF “double-submit cookie” com comparação timing-safe, emitida no proxy a cada requisição.
• Validação de origem (Sec-Fetch-Site) nas requisições mutativas.
• Webhooks Stripe e Telegram verificam assinatura HMAC e janela de tempo.
• Idempotência de webhook Stripe garantida por INSERT com ON CONFLICT em webhook_processed_events antes do processamento.
• Cap diário de crédito por workspace na RPC consume_workspace_credits_atomic — limita o gasto máximo em provedores de IA por dia mesmo se o saldo permitir.
• Reembolso atômico (refund_workspace_credits_atomic) só executa quando há débito correspondente — bloqueia inflação de crédito por referência inexistente.

Hardening de aplicação

• Content Security Policy com nonce por requisição; img-src, connect-src, font-src e media-src com hosts enumerados (sem https: coringa).
• HSTS com preload, X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, Permissions-Policy restritiva.
• Uploads validados por magic bytes (não só extensão); arquivos SVGZ/gzip e MIME suspeitos rejeitados.
• Moderação de conteúdo (AUP): prompts de rotas faturadas de IA passam por filtros server-side antes do provedor; violações retornam content_policy_violation — ver Política de Uso Aceitável.
• DLP brasileiro: CPF, CNPJ, RG, cartão (validação Luhn), CEP e telefone são redacted antes de qualquer chamada a provedor de IA.
• Prompts de IA com allowlist de modos (sem aceitar systemPrompt bruto do cliente); contexto de usuário envelopado em bloco UNTRUSTED_DATA.
• Token de convite com floor de tempo constante (250ms) por resposta, eliminando timing side-channel em enumeração.
• MFA obrigatório para mutações de billing quando WORKSPACE_OWNER_MFA_REQUIRED=true — cobre checkout, billing portal, convites, seats, top-ups, políticas de domínio e licenças.
• Sanitização de logs (Sentry + pino) com paridade de patterns para Stripe, OpenAI, Anthropic, FAL, Replicate, AWS, JWT, Bearer, URLs com credenciais.

Imutabilidade dos logs de auditoria

• As tabelas privacy_audit_logs, security_events e workspace_usage_events são append-only no banco: políticas RLS RESTRICTIVE bloqueiam UPDATE/DELETE para os papéis JWT.
• Trigger adicional em privacy_audit_logs bloqueia mutação até por service_role, exceto quando a transação seta explicitamente uma flag para jobs de retenção autorizados.
• Retenção: 1 ano para audit logs, 90 dias para security events, 5 anos para eventos de uso ligados a billing (CTN art. 174).

Acesso administrativo

• Console administrativo restrito a operadores cadastrados em platform_admins ou gerart_team_members.
• Exigência de MFA para acessar áreas administrativas.
• Toda ação administrativa relevante é registrada em log de auditoria.

Retenção

Os prazos de retenção são declarativos na tabela data_retention_rules e executados por jobs agendados. Detalhes na Política de Privacidade.

Reportar uma vulnerabilidade

Encontrou uma vulnerabilidade? Escreva para info@gerart.ai com o máximo de detalhes (passos para reproduzir, impacto estimado, contas envolvidas). Não publique a vulnerabilidade até que possamos remediá-la.