Política de Segurança da Informação
Atualizado em: 29 de setembro de 2026
O programa de segurança do Central Seller: infraestrutura, controle de acesso, classificação e criptografia de dados, gestão de vulnerabilidades e resposta a incidentes. Vale para todos que operam o sistema e para todo ambiente onde dados das lojas são tratados.
1. Princípios e responsáveis
Os dados da loja pertencem ao vendedor. Coletamos só o que o serviço precisa, damos a cada pessoa o acesso mínimo necessário e preferimos controles que o próprio sistema garante a procedimentos manuais. Os sócios da Central Seller Gestão e Integração Ltda. são os responsáveis por esta política, revisam-na pelo menos uma vez por ano e sempre que o sistema muda, e respondem dúvidas de segurança em centralseller.adm@gmail.com.
2. Infraestrutura e rede
- O sistema roda inteiro em provedores de nuvem gerenciados: banco de dados no Supabase (AWS, São Paulo), painel web e gateway de API na Vercel (São Paulo) e automações no n8n Cloud. Não mantemos servidores próprios, e nenhuma rede de escritório guarda dados de lojas.
- O banco não é acessível diretamente: todo acesso passa por APIs autenticadas, e a segurança por linha (RLS) decide quais linhas cada requisição pode ler ou alterar.
- Todo o tráfego usa HTTPS/TLS 1.2 ou superior. Os provedores fornecem isolamento de rede, proteção contra DDoS e registros de acesso.
- Desenvolvimento, dados de teste e produção são separados: os testes usam uma empresa de demonstração fictícia, nunca dados reais de lojas.
3. Controle de acesso (privilégio mínimo)
- Uma única tabela de vínculos define quais empresas e lojas cada pessoa enxerga, com os papéis dono, admin e operador. Só dono e admin conectam ou desconectam lojas, aprovam respostas ou mudam regras automáticas.
- Essa regra é aplicada dentro do banco, em todas as tabelas e views, e não só nas telas. Um teste de isolamento com mais de 80 verificações entra como usuário de uma empresa e confirma que ele não lê nem age nas lojas de outra; ele roda depois de toda mudança nas regras de acesso.
- A IA que o usuário conecta recebe uma chave própria e revogável, vê só as lojas daquele usuário e usa só as ferramentas do plano dele. As chaves são guardadas como hash SHA-256.
- Credenciais de serviço só são usadas no servidor e nunca chegam ao navegador.
- As contas administrativas da equipe (repositório de código, hospedagem, banco e automações) usam senha única e verificação em duas etapas. O acesso é retirado assim que a pessoa deixa de precisar.
4. Classificação e criptografia dos dados
| Classe | Exemplos | Regra |
|---|---|---|
| Pública | Esta página, material de divulgação | Sem restrição. |
| Interna | Código-fonte, documentação | Repositório privado; nunca contém segredos nem dados reais. |
| Confidencial | Vendas, anúncios, custos, reputação de uma loja | Só quem tem acesso àquela loja; cifrada no armazenamento. |
| Sensível | Dados pessoais de compradores, tokens de marketplace e ERP, chaves de API | Tokens e chaves só no cofre cifrado ou como hash; dados de compradores só nos registros da própria loja, nunca em logs ou exportações sob nosso controle. |
- Criptografia no tráfego com TLS e no armazenamento com AES-256 (Supabase/AWS).
- Os tokens OAuth dos marketplaces e os tokens de ERP ficam no Supabase Vault; telas e automações não conseguem lê-los diretamente.
- Segredos nunca entram no repositório de código; ficam nas variáveis de ambiente e nos cofres de credenciais dos provedores.
- As automações que lidam com o token do ERP não guardam histórico de execução.
5. Ações nos marketplaces
As integrações são de leitura por padrão. As únicas ações que escrevem num marketplace (responder compradores, participar de promoções) exigem aprovação de um dono ou admin, ou uma regra automática que ele ligou de forma explícita, e cada aprovação usa um código de uso único que vence em minutos. Antes de enviar, o sistema lê o marketplace de novo e só segue se a ação continuar permitida.
6. Computadores e operação do dia a dia
- Os computadores da empresa têm antivírus ativo e atualizações automáticas, bloqueio de tela e senha.
- Senhas fortes e únicas, verificação em duas etapas onde houver, e nenhum dado de loja guardado em disco local ou em e-mail.
7. Gestão de vulnerabilidades e ameaças
- Os verificadores automáticos de segurança e desempenho do banco são revisados depois de toda mudança de estrutura; os apontamentos são corrigidos ou documentados.
- As dependências são atualizadas com regularidade e toda mudança é revisada antes de ir para produção.
- Usuários anônimos não executam funções; toda função com privilégio confere o acesso de quem chama à loja.
- Verificações de saúde acompanham a integração em tempo real e alertam quando os avisos param de chegar.
8. Resposta a incidentes
- Comunicar: quem suspeitar de um incidente escreve para centralseller.adm@gmail.com. Vendedores podem usar o mesmo endereço.
- Conter: revogar chaves e tokens envolvidos, desconectar lojas afetadas e parar as automações envolvidas.
- Avaliar: identificar dados, lojas e pessoas afetados, com os registros dos provedores.
- Notificar: os vendedores afetados e os marketplaces envolvidos (inclusive TikTok Shop e Shopee) em até 72 horas da confirmação, e a ANPD e os titulares quando a LGPD exigir.
- Corrigir e aprender: eliminar a causa, registrar o ocorrido e atualizar esta política.
Os sócios são os responsáveis pela resposta a incidentes; um deles coordena cada caso e é o ponto único de contato até o encerramento.
9. Fornecedores
Só usamos fornecedores que publicam seus próprios programas de segurança (Supabase, Vercel, n8n, AWS, com relatórios SOC 2). A lista de fornecedores e onde tratam os dados está na Política de Privacidade.