Centro de Segurança

Documentação de compliance (CPG / enterprise)

Pacote de due diligence para compradores enterprise, enviado sob solicitação pelo e-mail de segurança. A documentação distingue controles implementados, configurações necessárias e etapas pendentes de verificação; não representa certificação independente.

Controles implementados e escopo de verificação

Os controles abaixo descrevem medidas implementadas na aplicação. Testes automatizados e verificações delimitadas ajudam a avaliá-las; a presença de um controle não comprova todas as jornadas de produção. A consulta de dependências acima registra avisos conhecidos na data indicada, não a ausência de vulnerabilidades no aplicativo.

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. Metas de resposta (objetivos, sem garantia de prazo):

• 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

• Políticas RLS e verificações de propriedade e participação protegem os recursos cobertos de usuários e workspaces.
• Credenciais service role ficam restritas ao servidor, com guardas próprias de cada operação, incluindo sessões, tarefas internas e compartilhamentos públicos autorizados.
• Papéis de workspace (admin, editor, viewer) são verificados nas operações protegidas; os ensaios entre contas cobrem caminhos selecionados.
• Princípio do menor privilégio aplicado a contas de operação.

Isolamento entre workspaces

• O acesso aos recursos combina o identificador do workspace, propriedade, participação e políticas RLS. Foram verificados casos selecionados de acesso próprio e recusa de acesso alheio.
• 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 operacionais disponíveis na Vercel. Há instrumentação Sentry no código; ingestão e entrega de notificações Sentry ainda não foram verificadas.
• Logs de auditoria privacy-sensíveis são gravados em tabela dedicada e somente leitura.
• Novos registros de auditoria e eventos de segurança usam hash do User-Agent com pepper configurado; sem pepper, descartam o valor. Registros antigos podem conter User-Agent técnico com tamanho limitado. Esses controles não garantem anonimização.

Backups e continuidade

• Uma restauração física do banco foi ensaiada em cópia isolada. Esse ensaio não comprova periodicidade de testes, PITR ativo ou objetivos de recuperação medidos.
• A Lixeira e a exportação do Canvas foram verificadas para um projeto sintético; esses recursos não equivalem a backup independente de todos os arquivos.
• O backup recorrente independente dos arquivos não está ativo. Os ensaios realizados não comprovam recuperação integral de objetos, reconciliação de billing ou RPO/RTO.

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 com Upstash Redis. As requisições cobertas são recusadas quando o Redis é exigido e está indisponível; o fallback em memória é usado em desenvolvimento conforme a configuração.
• Proteção CSRF “double-submit cookie” com comparação timing-safe nas mutações protegidas por sessão.
• Validação de origem nas mutações de sessão cobertas; webhooks e tarefas internas seguem suas guardas próprias.
• 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.
• Filtros de minimização detectam formatos de dados pessoais, como CPF, CNPJ e cartão com validação Luhn, nos fluxos cobertos. Isso não comprova remoção de todo dado pessoal em toda chamada externa.
• 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.
• Filtros de logs tratam padrões de credenciais e dados pessoais nas origens cobertas; a presença desses filtros não comprova que todo metadado seja anonimizado ou que o pipeline Sentry esteja operacional.

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.