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 é Lucas Barbosa da Silva (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: Lucas Barbosa da Silva — 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.

Infrastructure and network

Linux server in Brazil (Campinas, SP); managed database in the São Paulo region. Host firewall with default-deny inbound policy, exposing only required services; SSH protected against repeated attempts. Production, staging and development run in isolated environments and networks, each with its own database. Per-IP rate limiting at the edge. Public access through the database provider's API is revoked and row-level security is enabled on every table.

Access control and least privilege

Strict tenant isolation enforced server-side on every request. Per-user permissions defined by the account owner and enforced on the server. Passwords: minimum 12 characters, complexity rules, common and previously used passwords blocked, stored only as hashes. Login attempts limited per IP and per account; HttpOnly/Secure session cookies and CSRF protection. Admin area restricted to staff, with password re-confirmation every 30 minutes. Production access restricted to the technical partners; every code change goes through a pull request, and production releases require approval by another person. Secrets are kept out of source code.

Data classification and encryption

Classes: Confidential (marketplace/ERP credentials and tokens, application and encryption keys), Restricted (sellers' store data and buyer data: orders, amounts, delivery city/state, questions, claims), Internal (configuration, technical and audit logs), Public (marketing pages and policies). In transit: TLS everywhere, HTTPS enforced. At rest: seller access tokens are encrypted by the application (Fernet: AES with HMAC-SHA256) before storage; the database provider encrypts storage at rest; backups are encrypted with AES-256 on the server before leaving it, with the key stored separately.

Secure development and vulnerability management

Static security analysis (Semgrep) runs before each commit and on every pull request; findings are fixed or justified in writing before merge. No change reaches production without staging and peer approval. Dependencies are version-pinned and updated with each release. Critical vulnerabilities are remediated within 7 days and high-severity ones within 30 days of identification.

Incident response

Incident lead: Lucas Barbosa da Silva (decisions and all communication). Technical team: Seller Gest partners (investigation, containment, fix). Steps: identify and record; contain immediately (revoke affected tokens and keys, rotate secrets, isolate components); assess affected data, customers and stores; notify affected sellers and involved marketplaces (such as TikTok Shop) within 72 hours of confirmation, and the Brazilian Data Protection Authority (ANPD) and data subjects when required by the LGPD; fix the root cause and document lessons learned. Reporting channel: sellergest@gmail.com.

Backups, retention and deletion

A full production backup is taken before every release (no backup, no release), encrypted with AES-256 before leaving the server, stored off-site and verified by downloading it back and comparing byte by byte. Backups are kept for up to 90 days and then deleted automatically. Disconnecting an integration immediately deletes the store's tokens and the data imported from it. At contract termination, customer data is deleted within 30 days; backups containing it expire within the 90-day cycle. Data subject and marketplace requests (access, correction, provision or deletion) are answered within 15 days.

Audit logging and sub-processors

Sensitive actions (connecting or disconnecting integrations, changing application credentials, changing permissions) are recorded in an audit log with user, company and timestamp. Sub-processors: server hosting (Hostinger, Brazil), managed database (Supabase, São Paulo region), AI (OpenAI, United States — receives only what each request needs), encrypted backup storage (Microsoft OneDrive) and payments (Asaas, Brazil).