Última atualização: outubro de 2026. Versão 1.4. Documento público para clientes e revisões de parceiros (ex.: TikTok Shop Partner). Versão em inglês: /security.
Este Plano de Segurança descreve as medidas técnicas e organizacionais da Syntra (Maranata Software) para proteger dados de contas, pedidos, financeiro, integrações com marketplaces e ERPs (incluindo TikTok Shop, Mercado Livre, Shopee, SHEIN, Amazon, Bling, Tiny e Omie) e credenciais OAuth. Abrange a aplicação web e APIs em getsyntra.com.br, a infraestrutura de produção, webhooks e o acesso da equipe à produção. Complementa a Política de Privacidade em /privacidade.
Público: páginas institucionais e documentos públicos. Interno: métricas operacionais agregadas. Confidencial: pedidos, valores, taxas, custos, margem e identificadores de loja por conta. Restrito: tokens OAuth, segredos de integração, credenciais de banco e segredos de MFA. Cada camada tem tratamento próprio: confidencial fica isolada por organização, e restrito nunca é exibido em interface, log ou exportação.
Em trânsito: HTTPS com TLS 1.2 e TLS 1.3 somente; TLS 1.0 e 1.1 são recusados no handshake, e as suites configuradas são AEAD (ECDHE-AES-GCM e CHACHA20-POLY1305). Todo tráfego HTTP é redirecionado (301) para HTTPS. Em repouso: tokens OAuth, payloads de integração e segredos de MFA são cifrados com AES-256-GCM; senhas nunca são armazenadas em claro — derivação scrypt com salt por usuário e comparação em tempo constante. Chaves e segredos de produção ficam em arquivo de leitura restrita ao root e não entram no repositório de código. Limite declarado: o volume do sistema operacional não usa criptografia de disco gerenciada pelo cliente; a compensação é isolamento na nuvem, acesso humano apenas por chave SSH e criptografia na camada de aplicação para os dados classificados como restritos.
Autenticação com política de senha (mínimo de 12 caracteres e expiração definida por conta), MFA em TOTP com re-autenticação (step-up) antes de ações sensíveis, sessões validadas no servidor com expiração por inatividade, cookies HttpOnly + Secure + SameSite=Lax, e revogação no servidor em logout, logout-all e reset de senha. Papéis por organização (proprietário, administrador, membro); ações destrutivas de privacidade exigem o papel de proprietário. Toda consulta a dados de marketplace é chaveada pela organização da sessão — o identificador do cliente nunca vem de parâmetro do navegador. Acesso humano à produção é limitado a quem opera o serviço, por SSH com chave (autenticação por senha desabilitada no sshd). No banco de dados, a aplicação conecta com uma conta de serviço dedicada sem privilégios administrativos e os dumps de backup usam uma conta somente-leitura; as credenciais de banco ficam em arquivo de leitura restrita ao root.
A entrada pública única é o Nginx nas portas 80 e 443; a lista de segurança do provedor de nuvem permite apenas 22, 80 e 443 de fora, e as portas internas da aplicação e do banco não são alcançáveis pela internet (verificação externa: 3001, 3004, 3006, 3008, 5432, 6380, 8001 e 8443 sem resposta). O PostgreSQL escuta apenas em 127.0.0.1. Proteções ativas no host: Fail2ban (jail sshd), ClamAV com atualização diária de assinaturas, Suricata em modo de observação, e cabeçalhos de resposta x-frame-options DENY, x-content-type-options nosniff, referrer-policy strict-origin-when-cross-origin e permissions-policy sem câmera/microfone/geolocalização. Rotas sensíveis têm rate limit e checagem de origem nas mutações.
Esta é a linha de base exigida de quem opera o serviço, medida por comando e não por declaração: estação de trabalho corporativa autenticada por domínio, com antivírus de endpoint em tempo real ativo (proteção em tempo real, acesso, comportamento, rede e antimanipulação), firewall do sistema ativo nos três perfis, política de senha e bloqueio após tentativas inválidas em vigor, e logon exigido no console (sem autologon). Regra absoluta: nenhuma credencial de produção e nenhum dado pessoal de cliente em notebook ou estação de trabalho — as credenciais existem apenas em arquivo somente-root no servidor, e os dados restritos só existem cifrados no banco. Mesa limpa para material que contenha dados de clientes. Limite declarado: nessa estação não configuramos bloqueio automático de tela por inatividade, criptografia de disco inteiro nem gerenciador de senhas dedicado — é uma máquina gerenciada pela organização, e essas três decisões pertencem ao TI corporativo; a compensação é que ela não guarda dado pessoal nem segredo de produção. Autenticação em dois fatores é obrigatória no produto (TOTP com re-autenticação antes de ações sensíveis, seção 4) e declarada habilitada nas contas de operador que destravam a produção — a afirmação sobre essas contas vem do responsável, porque a API do hospedador de código não expõe essa verificação por comando. No servidor, a linha de base é verificável: autenticação SSH só por chave, usuário de serviço sem privilégios de root, arquivo de ambiente do serviço somente para root, e atualização automática de pacotes de segurança.
Correção automática de vulnerabilidades no sistema (unattended-upgrades habilitado para os repositórios de segurança da distribuição e extensões mantidas), atualização diária de assinaturas de antivírus, varredura de dependências do projeto em integração contínua com bloqueio para falhas de alta severidade, e portais de qualidade antes de qualquer deploy (checagem de tipos, lint e suíte completa de testes). Janela mensal de manutenção aplica atualizações completas e reinício do host quando o kernel exige; pendências de patch são tratadas como débito com data, não como exceção permanente.
Logs estruturados em JSON com nível de severidade, trilha de auditoria em banco para eventos de segurança e de privacidade, rotação de logs do proxy (14 períodos, comprimidos) e retenção do journal do sistema, monitoramento de saúde por /api/health, /api/health/live, /api/health/ready e página /status. Falhas de sincronização de marketplace são classificadas, registradas e exibidas na interface do vendedor, que recebe alerta por e-mail e WhatsApp conforme a configuração de cada conta.
Plano escrito com quatro classes de severidade e sete etapas (detecção, triagem, contenção, erradicação, recuperação, comunicação e pós-incidente), líder de incidente nomeado por documento de responsabilidades, preservação de evidência por no mínimo 12 meses com horários em UTC, e notificação ao parceiro de marketplace em até 24 horas após a confirmação, sem aguardar o fim da investigação. Canais: [email protected] para privacidade e titulares, canal de suporte/Partner Center do parceiro afetado para dados de marketplace e, quando aplicável, o canal de segurança do parceiro. Ao menos um exercício de mesa por semestre, com resultado registrado.
Exportação autenticada dos dados da conta (POST /api/privacy/export, com segredos suprimidos) e solicitação de exclusão/anonimização pelo proprietário da organização (POST /api/privacy/delete-request, que anonimiza o cadastro, revoga todas as sessões e registra o evento em auditoria). Contato do Encarregado (DPO): [email protected] — prazo alvo de resposta: 15 dias.
Dados de conta: enquanto a conta estiver ativa e, quando aplicável, até 5 anos por obrigação fiscal. Logs operacionais: tipicamente 12 meses. Dados de marketplace: enquanto a integração/conta permanece ativa e dentro dos limites do plano; removidos ou anonimizados no fluxo de exclusão. Tokens OAuth: enquanto a integração estiver conectada; rotacionados ou revogados ao desconectar ou em incidente. O cancelamento não apaga a conta: os dados permanecem até o proprietário pedir a exclusão, e então são removidos ou anonimizados, com a retenção que a lei fiscal exigir.
Dump lógico diário do banco (02:00 UTC, reter 30 dias), executado por uma conta de banco somente-leitura, e backup da aplicação a cada deploy (reter 14 dias), com restauração prevista no plano de resposta a incidentes. Os arquivos de dump e os arquivos de credencial são legíveis somente pelo root. O script de deploy preserva a versão anterior e execita checagens de saúde depois de publicar. Em andamento, declarado: copia dos dumps para um segundo local fora do host de produção.
Oracle Cloud Infrastructure (hospedagem da aplicação e do banco, região de São Paulo, Brasil), processador de pagamentos Stripe (somente assinaturas da Syntra — nenhum dado de pedido do marketplace passa por ele, e a Syntra não armazena números de cartão), e provedores de entrega de notificação (e-mail e WhatsApp). O tratamento com terceiros é limitado ao necessário à prestação do serviço.
A Syntra processa dados de APIs e webhooks apenas para prestar o serviço contratado pelo vendedor (importação de pedidos, margem, reconciliação, reprecificação e alertas). Não vendemos dados pessoais e não usamos dados do TikTok Shop ou de qualquer marketplace para publicidade ou profiling não relacionado ao serviço.
Este plano é revisado ao menos semestralmente e após incidentes relevantes. Versão atual: 1.4 — outubro de 2026.