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

Esta política se aplica à plataforma TreeSeller — aplicação web, banco de dados, processo de sincronização e integrações com marketplaces — operada por AGF GARAGE, CNPJ 61.444.544/0001-37, Curitiba/PR.

A responsabilidade pela segurança da informação é da direção da empresa, que aprova esta política e destina os recursos para mantê-la. Contato: contato@treeseller.com.br.

Os princípios que orientam as decisões técnicas são menor privilégio (cada componente acessa apenas o necessário), defesa em profundidade (nenhum controle isolado é o único obstáculo) e falha fechada (na dúvida, o sistema nega em vez de permitir).

Tratamos quatro categorias, com controles proporcionais à sensibilidade:

• Credenciais — senhas e tokens de integração. Nunca armazenados de forma reversível ou legível.
• Dados cadastrais — identificação do cliente e dos usuários (nome, e-mail, telefone, CPF/CNPJ).
• Dados operacionais — pedidos, anúncios, custos e preços importados das lojas do cliente.
• Registros — auditoria, logs de importação e telemetria de webhooks.

A plataforma não armazena dados pessoais de compradores: dos pedidos guarda apenas identificador, status, valores e datas. Documentos que contêm dados do comprador (etiqueta de envio, nota fiscal) são obtidos sob demanda no marketplace e entregues ao vendedor sem persistência.

• Isolamento entre clientes: todo registro de negócio carrega o identificador do cliente e toda consulta é filtrada por ele. É regra obrigatória de desenvolvimento, verificada em revisão de código.
• Perfis: proprietário e administrador têm acesso completo à própria conta; o perfil membro é restrito a uma lista de módulos definida pelo cliente.
• Dupla verificação: a checagem otimista de permissão ocorre na camada de borda (bloqueia navegação sem consultar o banco) e a checagem autoritativa ocorre junto ao dado. Nenhuma tela é considerada fronteira de segurança por si só.
• Acesso administrativo: o painel da plataforma exige a marcação explícita de administrador, checada em cada página e em cada ação — não apenas no layout.
• Acesso de suporte à conta do cliente: quando necessário, é feito por função dedicada que registra em auditoria quem acessou, qual conta e quando, e exibe aviso permanente na tela durante o uso.

• Senhas armazenadas com bcrypt, fator de custo 12. Não há como recuperar a senha original a partir do que guardamos.
• Sessão em token assinado (JWT HS256) transportado em cookie httpOnly, secure e sameSite=lax — inacessível a scripts e não enviado em requisições de terceiros. Validade de 24 horas, ou 30 dias quando o usuário opta por permanecer conectado.
• Revogação: cada sessão carrega a versão de sessão do usuário. Incrementá-la — o que acontece na troca e na redefinição de senha — invalida imediatamente todas as sessões abertas.
• Primeiro acesso: conta criada pela nossa equipe com senha provisória exige troca antes de qualquer tela. O bloqueio é aplicado na borda, não apenas na interface.
• Redefinição de senha por link assinado, com finalidade própria, validade de 30 minutos e uso único — o token deixa de valer assim que a senha muda. Um token de redefinição jamais autentica uma sessão.
• Mensagens neutras: login e recuperação respondem igual exista ou não a conta, para não permitir enumeração de usuários.

Limites de tentativa são contados no banco de dados, em janela deslizante — não em memória do processo, que seria contornável por reinício ou por réplica:

• login: 10 tentativas por IP a cada 5 minutos e 10 por conta a cada 15 minutos;
• criação de conta: 5 por IP por hora;
• recuperação de senha: 5 por IP a cada 15 minutos e 3 por conta por hora.

O limite por conta existe além do limite por IP porque um ataque distribuído — ou com cabeçalho de origem forjado — contornaria a contagem por IP. Na identificação da origem, consideramos apenas a entrada confiável do proxy reverso, e não o valor declarado pelo cliente.

• Em trânsito: todo acesso ocorre por HTTPS com certificado válido e renovação automática. O cabeçalho Strict-Transport-Security é enviado com validade de dois anos, abrangendo subdomínios.
• Em repouso: os tokens de autorização das lojas conectadas são cifrados com AES-256-GCM antes de ir ao banco. Um vazamento de dump ou de backup não entrega acesso vivo às contas de marketplace do cliente.
• Segredos de aplicação (chave de sessão, chave de criptografia, chave de comunicação interna) vivem em variáveis de ambiente do serviço, nunca no repositório.
• Comparação de segredos em tempo constante nas rotas internas, para não expor um oráculo de tempo.

• Content Security Policy com nonce gerado por requisição e strict-dynamic: script injetado sem o nonce da resposta não executa. Complementada por object-src none, base-uri self, form-action self e frame-ancestors none.
• Cabeçalhos de segurança aplicados a todas as rotas: proteção contra enquadramento em iframe (anti-clickjacking), bloqueio de inferência de tipo de conteúdo, política de referenciador restritiva e desativação de câmera, microfone e geolocalização.
• Validação de entrada com esquema declarado antes de qualquer escrita no banco.
• Consultas parametrizadas. Onde há SQL direto — usado por desempenho em relatórios agregados — os trechos variáveis são gerados a partir de constantes internas e de valores validados, nunca de entrada concatenada do usuário.
• Valores monetários em tipo decimal, evitando erro de arredondamento com impacto financeiro.
• Autorização em cada ação de servidor, e não apenas na tela que a invoca.

• Aplicação, processo de sincronização e banco de dados rodam como serviços isolados em containers, em servidores localizados no Brasil. O banco não é exposto à internet pública.
• A comunicação entre o agendador e a aplicação usa rota interna protegida por chave compartilhada, com verificação em tempo constante.
• As telas nunca chamam APIs de marketplace diretamente: leem apenas a base local. O acesso externo acontece somente nos fluxos de sincronização, o que reduz a superfície exposta e o risco de vazamento de credencial por caminho inesperado.
• Migrações de banco são aplicadas de forma versionada na subida do serviço; a aplicação não inicia se uma migração falhar.

• Trilha de auditoria por cliente: autenticação, criação de conta, alterações relevantes, conexão e desconexão de loja, e acesso de suporte à conta — com autor, recurso, detalhe e data.
• Registro de importação por execução, permitindo reconstituir o que foi lido de cada marketplace.
• Aceite de termos registrado com data, endereço IP e versão do documento aceito.
• Não registramos senhas, tokens ou conteúdo sensível em log.

• Código versionado, com histórico completo de autoria e motivo de cada alteração.
• Verificação automatizada a cada envio: checagem de tipos, bateria de testes automatizados (incluindo testes de integração contra banco real) e compilação. Falha em qualquer etapa impede a integração.
• Regras de arquitetura e de segurança documentadas no repositório e aplicadas na revisão — entre elas a obrigatoriedade de filtro por cliente, a criptografia de tokens e a preservação do mecanismo de revogação de sessão.
• Dependências fixadas por versão, com registro de integridade.

Trabalhamos com o menor número possível de terceiros, e apenas com os necessários à operação: provedor de infraestrutura, provedor de e-mail transacional e os marketplaces que o próprio cliente autoriza.

O acesso aos marketplaces ocorre exclusivamente por autorização delegada (OAuth) concedida pelo cliente, revogável por ele a qualquer momento tanto na plataforma quanto no painel do próprio marketplace. Não solicitamos nem armazenamos a senha do cliente em nenhum marketplace.

A base de dados é o ativo crítico da operação: as telas dependem dela, e não das APIs externas. A rotina de cópia de segurança é responsabilidade da camada de infraestrutura contratada, e a evolução desse controle está descrita no item 15.

O reprocessamento de dados de marketplace é possível a partir das integrações ativas, o que reduz o impacto de perda parcial de dados operacionais.

Comunicação responsável. Se você identificou uma vulnerabilidade, escreva para contato@treeseller.com.br com a descrição e os passos para reproduzir. Comprometemo-nos a acusar recebimento em até 3 dias úteis e a não tomar medidas legais contra quem reportar de boa-fé, sem acessar dados de terceiros nem degradar o serviço.

Diante de um incidente, o procedimento é: conter o efeito, avaliar quais dados e clientes foram atingidos, corrigir a causa, registrar o ocorrido e comunicar os afetados. Havendo risco relevante a dados pessoais, a comunicação alcança também a Autoridade Nacional de Proteção de Dados, nos termos da LGPD.

Credenciais suspeitas de exposição são rotacionadas, e a revogação de sessões pode ser aplicada por usuário ou por conta inteira.

O acesso administrativo à plataforma é restrito à equipe responsável pela operação, identificado individualmente e registrado em auditoria. Não há acesso compartilhado ou anônimo ao painel administrativo.

O acesso à conta de um cliente para fins de suporte é registrado e sinalizado na interface enquanto durar.

Esta política descreve o que está implementado. Os controles abaixo estão no plano de evolução, priorizados e declarados abertamente — preferimos ser exatos sobre onde estamos a prometer o que ainda não temos:

• autenticação em duas etapas para os perfis administrativos;
• rotina formal de cópia de segurança com teste periódico de restauração;
• isolamento de dados também na camada do banco, somando-se ao isolamento em aplicação;
• verificação de endereço de e-mail na criação de conta;
• varredura automatizada e contínua de vulnerabilidades em dependências;
• rotação periódica programada de segredos de aplicação;
• revisão externa de segurança da aplicação.

Esta política entra em vigor na data de sua publicação e é revista sempre que houver mudança relevante nos controles descritos, e no mínimo uma vez por ano. Cada revisão recebe um identificador de versão.

Dúvidas, pedidos de evidência ou questionários de segurança: contato@treeseller.com.br.