Política de Segurança da Informação

1. Objetivo e escopo

Este documento descreve o programa de segurança da informação do Seller Gest: os controles técnicos e administrativos que protegem os dados de clientes, de suas lojas nos marketplaces e de seus compradores. Vale para o site, o painel, as integrações, a infraestrutura e todas as pessoas com acesso à produção.

O responsável pelo programa é o Seller Gest (CNPJ 43.919.473/0001-08). A equipe técnica é formada pelos sócios do Seller Gest. Esta política é revisada ao menos uma vez por ano e sempre que um controle mudar; a data no topo indica a versão vigente.

2. Infraestrutura e rede

• O sistema roda em servidor Linux no Brasil (Campinas, SP) e o banco de dados é um serviço gerenciado na região de São Paulo.
• O servidor usa firewall com bloqueio padrão de entrada: só ficam expostos os serviços necessários. O acesso administrativo (SSH) tem proteção automática contra tentativas repetidas.
• Produção, homologação e desenvolvimento rodam em ambientes e redes isolados, cada um com o seu próprio banco de dados.
• A entrada da aplicação tem limite de requisições por endereço IP, que contém abuso e automação indevida.
• No banco de dados, o acesso público pela API do provedor foi revogado e a segurança por linha (RLS) está ligada em todas as tabelas; a aplicação é a única porta de acesso.

3. Controle de acesso e privilégio mínimo

• Isolamento entre empresas: cada cliente só enxerga os dados da própria empresa; a checagem é feita no servidor, em toda requisição.
• Permissões por usuário: o dono da conta define quais áreas cada colaborador acessa; o que não foi liberado é recusado no servidor, e não apenas escondido no menu.
• Senhas: mínimo de 12 caracteres, regras de complexidade, bloqueio de senhas comuns e de senhas já usadas; guardadas apenas em forma de hash.
• Proteção de login: tentativas limitadas por endereço IP e por conta; sessões com cookies HttpOnly e Secure e proteção contra requisições forjadas (CSRF).
• Área administrativa: restrita à equipe, com nova confirmação de senha a cada 30 minutos e limite próprio de tentativas.
• Produção: acesso restrito aos sócios responsáveis técnicos. Toda mudança de código passa por pull request, e a publicação na produção exige aprovação de outra pessoa.
• Segredos (chaves de aplicativos e de criptografia) ficam fora do código-fonte: em variáveis de ambiente do servidor ou cifrados no banco, nunca exibidos por inteiro na tela.

4. Classificação de dados e criptografia

Classificação

• Confidencial: credenciais e autorizações de marketplaces e ERPs, chaves de aplicativos e de criptografia.
• Restrito: dados das lojas dos clientes e de seus compradores — pedidos, valores, cidade e UF de entrega, perguntas e respostas, reclamações.
• Interno: configurações, registros técnicos e de auditoria.
• Público: páginas de apresentação, planos e políticas.

Criptografia

• Em trânsito: todo o tráfego usa HTTPS (TLS), com redirecionamento obrigatório; as chamadas às APIs dos marketplaces também usam TLS.
• Em repouso: as autorizações das lojas (tokens de acesso) são cifradas pela aplicação com criptografia simétrica autenticada (Fernet: AES com HMAC-SHA256) antes de irem ao banco; o provedor do banco cifra o armazenamento em disco.
• Cópias de segurança: cifradas com AES-256 no próprio servidor, antes de saírem dele. A chave fica separada das cópias.

5. Desenvolvimento seguro e gestão de vulnerabilidades

• Análise estática de segurança (Semgrep) roda antes de cada gravação de código e, de novo, em todo pull request; o que ela aponta é corrigido ou justificado por escrito antes de o código entrar.
• Revisão: nenhuma mudança chega à produção sem passar pelo ambiente de homologação e sem aprovação de outra pessoa.
• Dependências com versões fixadas, atualizadas junto com as versões do sistema.
• Correção por gravidade: vulnerabilidades críticas são tratadas em até 7 dias e as de alta gravidade em até 30 dias, contados da identificação.
• Relatos de vulnerabilidade podem ser enviados para sellergest@gmail.com.

6. Resposta a incidentes

Papéis

• Responsável pelo incidente: o sócio administrador do Seller Gest — decide as medidas e conduz toda a comunicação com clientes, marketplaces e autoridades.
• Equipe técnica: os sócios do Seller Gest — investigam, contêm e corrigem.

Etapas

1. Identificação e registro: todo evento suspeito é registrado com data, hora e evidências.
2. Contenção imediata: revogar autorizações e chaves afetadas, trocar segredos e isolar o componente comprometido.
3. Avaliação: quais dados, quais clientes e quais lojas foram afetados, e qual o risco para os titulares.
4. Comunicação: clientes afetados e marketplaces envolvidos (como a TikTok Shop) são avisados em até 72 horas da confirmação do incidente; a Autoridade Nacional de Proteção de Dados (ANPD) e os titulares, quando houver risco ou dano relevante, no prazo previsto na regulamentação da LGPD.
5. Correção e revisão: causa corrigida, controles reforçados e registro final do que aconteceu e do que mudou.

Canal para comunicar incidentes ou suspeitas: sellergest@gmail.com.

7. Cópias de segurança

• Uma cópia completa da produção é feita antes de cada atualização do sistema; se ela falhar, a atualização não acontece.
• A cópia é cifrada (AES-256) antes de sair do servidor e guardada fora dele, em serviço de armazenamento em nuvem.
• A integridade é conferida baixando a cópia de volta e comparando byte a byte.
• As cópias são mantidas por até 90 dias e depois apagadas automaticamente.

8. Retenção e exclusão de dados

• Desconectar uma integração apaga, na hora, as autorizações da loja e os dados trazidos dela (pedidos, perguntas e demais registros).
• Encerramento do contrato: os dados do cliente são apagados em até 30 dias; as cópias de segurança que ainda os contenham expiram no ciclo de até 90 dias.
• Pedidos de titulares ou de marketplaces para acessar, corrigir, fornecer ou excluir dados são atendidos em até 15 dias pelo canal sellergest@gmail.com.

9. Registros e auditoria

Ações sensíveis — conectar e desconectar integrações, trocar credenciais de aplicativos, mudar permissões — ficam em registro de auditoria, com usuário, empresa e horário. Cada requisição recebe um identificador para rastrear falhas sem expor dados pessoais nos registros.

10. Fornecedores

Usamos apenas os fornecedores necessários à operação e sob obrigações de confidencialidade e segurança: hospedagem do servidor (Hostinger, Brasil), banco de dados gerenciado (Supabase, região de São Paulo), inteligência artificial (OpenAI, Estados Unidos — recebe apenas o necessário para cada pedido), armazenamento das cópias de segurança cifradas (Microsoft OneDrive) e pagamentos (Asaas, Brasil). A lista e os detalhes de privacidade estão na Política de Privacidade.