1. Objetivo e responsabilidades

Proteger a confidencialidade, a integridade e a disponibilidade dos dados dos vendedores (nossos clientes), dos compradores que aparecem nos pedidos e da própria empresa.

• Responsável pela segurança da informação e encarregado de dados: eduardo@metalivre.com.br.
• Toda pessoa com acesso aos sistemas recebe esta Política, a Política Interna de Proteção de Dados e o Plano de Resposta a Incidentes, e declara ciência antes de receber credenciais.
• Descumprimento desta Política leva à revogação imediata do acesso e às medidas contratuais e legais cabíveis.

2. Arquitetura: um único ponto de acesso aos dados

Nem o site nem o aplicativo falam diretamente com os marketplaces ou com provedores de IA. Toda comunicação passa pelo servidor da MetaClick (backend), que é o único lugar onde ficam os tokens de acesso e as regras de negócio. O navegador do cliente recebe somente o resultado pronto.

A plataforma é hospedada na Railway (nuvem, região dos Estados Unidos), com banco de dados PostgreSQL gerenciado. O DNS e o certificado do domínio passam pela Cloudflare.

3. Controle de acesso

• Menor privilégio: cada pessoa recebe só o acesso que a função exige, e o acesso é revisto quando a função muda e retirado no mesmo dia em que a pessoa deixa a empresa.
• Acesso nominal: credenciais são individuais e intransferíveis; não há contas compartilhadas na equipe.
• Isolamento entre clientes: toda consulta a uma loja passa por uma verificação de propriedade no servidor — uma conta só alcança as lojas que são dela (ou que o dono liberou para o colaborador). O vendedor também restringe, por colaborador, quais lojas e quais telas cada um vê, e o servidor reforça essa restrição em toda requisição.
• Perfis administrativos da MetaClick são poucos, criados por nós, e seu uso fica registrado.
• Sessão do painel: token assinado (JWT) em cookie httpOnly, secure e sameSite, inacessível a scripts da página; expira e exige novo login.
• Senhas de clientes: mínimo de 8 caracteres e guardadas apenas como hash bcrypt, nunca em texto.
• Verificação em duas etapas obrigatória em todas as contas do painel desde 27/10/2026 — clientes, colaboradores e equipe. Depois da senha certa, o acesso só é liberado com um segundo fator: código de aplicativo autenticador (TOTP, padrão RFC 6238) ou código de 6 dígitos enviado por e-mail, válido por 10 minutos e de uso único. Ao configurar, a pessoa recebe códigos de recuperação de uso único para o caso de perder o celular.
• Tentativas erradas do segundo fator travam a verificação da conta por tempo progressivo (5 erros seguidos: 5 minutos, dobrando a cada nova rodada até 24 horas). A pessoa pode marcar um aparelho como confiável por até 30 dias; ligar, desligar ou mudar o segundo fator exige a senha, e as mudanças ficam registradas e são avisadas por e-mail ao titular.
• Acesso ao marketplace: por autorização oficial (OAuth) do próprio vendedor; a MetaClick nunca recebe a senha do marketplace e o vendedor pode revogar a autorização a qualquer momento.

4. Estações de trabalho e contas da equipe

• Bloqueio automático de tela após no máximo 5 minutos sem uso, com desbloqueio por senha, PIN ou biometria.
• Senhas fortes (mínimo de 12 caracteres, únicas por serviço), guardadas em gerenciador de senhas.
• Autenticação em dois fatores (2FA) obrigatória em todas as contas administrativas: nuvem (Railway), repositório de código (GitHub), DNS (Cloudflare), e-mail corporativo, provedor de pagamento e painéis de parceiro dos marketplaces.
• Antivírus e proteção de endpoint ativos e atualizados em todos os computadores usados para trabalho (Microsoft Defender no Windows, com o Controle Inteligente de Aplicativos, que bloqueia executáveis não assinados).
• Sistema operacional e navegador com atualizações automáticas ligadas; disco do computador criptografado quando o sistema oferece (BitLocker/FileVault).
• Segredos de produção (chave de criptografia, chaves de API) ficam somente nas variáveis de ambiente da nuvem; não são guardados em código, planilha, e-mail ou chat.

5. Rede: segmentação e monitoramento

• O servidor da API e o banco de dados conversam pela rede privada da nuvem. O único serviço da aplicação aberto ao público é o site, que repassa ao servidor apenas os caminhos autorizados. O acesso administrativo direto ao banco é restrito à equipe técnica, protegido por credencial forte e usado só para manutenção e conferência.
• Ambientes separados: desenvolvimento roda na máquina local com banco próprio; produção é isolada e só recebe código pelo processo de publicação.
• Todo tráfego externo é HTTPS (TLS). O servidor aplica cabeçalhos de segurança (helmet), CORS restrito ao domínio oficial e limite de requisições por cliente (120 por minuto).
• Notificações recebidas dos marketplaces (webhooks) têm a assinatura conferida antes de qualquer processamento.
• Monitoramento: registros (logs) da plataforma na nuvem, trilha de acesso por usuário e tela, e o Sentinela — vigia automático que confere diariamente se dados e rotinas fazem sentido (rotina parada, cache congelado, números que deixaram de bater) e avisa a administração.

6. Classificação de dados e criptografia

• Em trânsito: HTTPS/TLS em todas as conexões — navegador ↔ plataforma e plataforma ↔ marketplaces.
• Em repouso: tokens de acesso dos marketplaces e segredos do aplicativo autenticador (verificação em duas etapas) cifrados com AES-256-GCM, com chave guardada fora do banco; sem essa chave o servidor de produção recusa iniciar. Códigos de verificação por e-mail e de recuperação são guardados apenas como hash. O banco de dados e os backups ficam em armazenamento gerenciado e criptografado pelo provedor de nuvem.
• Minimização: do TikTok Shop não gravamos nome, CPF, e-mail, telefone nem endereço do comprador — esses campos são lidos, quando necessário, apenas em memória para conferir a nota fiscal, e descartados. Os dados de comprador da Shopee já chegam mascarados pela própria Shopee.

7. Gestão de vulnerabilidades e atualizações

• Dependências (bibliotecas npm) do servidor e do site são verificadas com auditoria de vulnerabilidades (npm audit) ao menos uma vez por mês e antes de cada atualização relevante.
• Prazos de correção a partir da descoberta: crítica em até 7 dias; alta em até 30 dias; média e baixa no ciclo normal de manutenção.
• Preferimos bibliotecas mantidas e de código JavaScript puro; versões sem manutenção são substituídas.
• Todo código passa por verificação de tipos antes de ir para produção; a publicação é feita a partir do repositório, com histórico de quem mudou o quê.
• Problemas de segurança relatados por terceiros podem ser enviados a eduardo@metalivre.com.br e são tratados pelo Plano de Resposta a Incidentes.

8. Auditoria, rastreabilidade e reversão

• Toda ação que a plataforma executa numa loja (preço, promoção, estoque, anúncio) passa por uma fila única, fica registrada com o estado ANTERIOR e pode ser desfeita pelo botão Desfazer.
• Mudanças em travas e configurações sensíveis (lista de anúncios intocáveis, travas de margem, preço mínimo, limites dos robôs, liga/desliga da automação) ficam registradas com quem mudou, quando e o valor antes e depois.
• A navegação de cada usuário (quem abriu qual tela, de qual loja, quando e de qual IP) é guardada por 180 dias e fica visível ao dono da conta.
• Existe um interruptor geral que suspende toda escrita automática da plataforma em caso de emergência.

9. Continuidade e backup

O banco de dados tem backup gerenciado pelo provedor de nuvem. As rotinas automáticas recuperam execuções perdidas após reinícios, e os dados de leitura (caches) podem ser reconstruídos a partir dos marketplaces.

10. Fornecedores

Usamos apenas fornecedores necessários ao serviço (nuvem e banco de dados, DNS, e-mail transacional, pagamento, notificação no aplicativo e provedor de IA), escolhidos por oferecerem criptografia e controles de acesso compatíveis com esta Política. Ao provedor de IA enviamos apenas o necessário para a tarefa (por exemplo, o texto de uma pergunta ou avaliação e os dados do anúncio), nunca documento (CPF), e-mail, telefone ou endereço de comprador.

11. Certificações

A MetaClick não possui, nesta data, certificações formais de segurança (como ISO/IEC 27001 ou SOC 2). Os controles descritos aqui são aplicados e verificáveis no próprio sistema.

12. Revisão

Esta Política é revisada ao menos uma vez por ano, após qualquer incidente relevante e sempre que a arquitetura mudar. Dúvidas: eduardo@metalivre.com.br.

1. Purpose and responsibilities

To protect the confidentiality, integrity and availability of the data of sellers (our customers), of the buyers who appear in orders, and of the company itself.

• Information security officer and Data Protection Officer: eduardo@metalivre.com.br.
• Everyone with access to our systems receives this Policy, the Internal Data Protection Policy and the Incident Response Plan, and acknowledges them before receiving credentials.
• Breach of this Policy results in immediate revocation of access and applicable contractual and legal measures.

2. Architecture: a single point of access to data

Neither the website nor the mobile app talks directly to marketplaces or AI providers. All communication goes through the MetaClick server (backend), the only place where access tokens and business rules are kept. The customer's browser only receives the finished result.

The platform is hosted on Railway (cloud, United States region), with a managed PostgreSQL database. The domain's DNS and certificate are served through Cloudflare.

3. Access control

• Least privilege: each person receives only the access their role requires; access is reviewed when the role changes and removed the same day the person leaves the company.
• Named access: credentials are personal and non-transferable; there are no shared team accounts.
• Tenant isolation: every request to a store goes through a server-side ownership check — an account can only reach the stores it owns (or that the owner granted to a collaborator). Sellers can further restrict, per collaborator, which stores and screens each person sees, and the server enforces this on every request.
• MetaClick administrative profiles are few, created by us, and their use is logged.
• Dashboard session: signed token (JWT) in an httpOnly, secure, sameSite cookie, unreachable by page scripts; it expires and requires a new login.
• Customer passwords: minimum of 8 characters, stored only as bcrypt hashes, never in plain text.
• Two-step verification mandatory on every dashboard account since October 27, 2026 — customers, collaborators and staff. After the correct password, access is granted only with a second factor: an authenticator app code (TOTP, RFC 6238) or a 6-digit code sent by e-mail, valid for 10 minutes and single-use. When setting it up, the user receives single-use recovery codes in case the phone is lost.
• Wrong second-factor attempts lock the account's verification for a progressive period (5 consecutive errors: 5 minutes, doubling on each new round up to 24 hours). A user may mark a device as trusted for up to 30 days; enabling, disabling or changing the second factor requires the password, and changes are logged and notified to the account holder by e-mail.
• Marketplace access: through the seller's own official authorization (OAuth); MetaClick never receives the marketplace password, and the seller can revoke the authorization at any time.

4. Workstations and team accounts

• Automatic screen lock after at most 5 minutes of inactivity, unlocked by password, PIN or biometrics.
• Strong passwords (at least 12 characters, unique per service), kept in a password manager.
• Two-factor authentication (2FA) mandatory on every administrative account: cloud (Railway), source code repository (GitHub), DNS (Cloudflare), corporate e-mail, payment provider and marketplace partner portals.
• Antivirus and endpoint protection active and up to date on every computer used for work (Microsoft Defender on Windows, with Smart App Control blocking unsigned executables).
• Operating system and browser with automatic updates enabled; disk encryption enabled where the system supports it (BitLocker/FileVault).
• Production secrets (encryption key, API keys) live only in the cloud environment variables; they are never stored in code, spreadsheets, e-mail or chat.

5. Network segmentation and monitoring

• The API server and the database talk over the cloud's private network. The only application service open to the public is the website, which forwards to the server only the authorized paths. Direct administrative access to the database is restricted to the technical team, protected by a strong credential and used only for maintenance and verification.
• Separate environments: development runs on a local machine with its own database; production is isolated and only receives code through the release process.
• All external traffic uses HTTPS (TLS). The server applies security headers (helmet), CORS restricted to the official domain and per-client rate limiting (120 requests per minute).
• Notifications received from marketplaces (webhooks) have their signature verified before any processing.
• Monitoring: platform logs in the cloud, an access trail per user and screen, and the Sentinel — an automated watchdog that checks daily whether data and routines make sense (stalled jobs, frozen caches, figures that stopped matching) and alerts the administration.

6. Data classification and encryption

• In transit: HTTPS/TLS on every connection — browser ↔ platform and platform ↔ marketplaces.
• At rest: marketplace access tokens and authenticator app secrets (two-step verification) encrypted with AES-256-GCM, with the key stored outside the database; without that key the production server refuses to start. E-mail verification codes and recovery codes are stored only as hashes. The database and its backups live on managed storage encrypted by the cloud provider.
• Minimization: from TikTok Shop we do not store the buyer's name, CPF (tax ID), e-mail, phone or address — when needed, these fields are read only in memory to check the invoice and then discarded. Shopee buyer data already arrives masked by Shopee.

7. Vulnerability and patch management

• Server and website dependencies (npm libraries) are checked with a vulnerability audit (npm audit) at least monthly and before every relevant upgrade.
• Remediation deadlines from discovery: critical within 7 days; high within 30 days; medium and low in the regular maintenance cycle.
• We prefer maintained, pure-JavaScript libraries; unmaintained versions are replaced.
• All code goes through type checking before production; releases are made from the repository, with a history of who changed what.
• Security issues reported by third parties can be sent to eduardo@metalivre.com.br and are handled under the Incident Response Plan.

8. Audit, traceability and rollback

• Every action the platform performs on a store (price, promotion, stock, listing) goes through a single queue, is logged with the PREVIOUS state, and can be reverted with the Undo button.
• Changes to sensitive locks and settings (do-not-touch listings, margin locks, minimum price, robot limits, automation on/off) are logged with who changed them, when, and the before and after values.
• Each user's navigation (who opened which screen, of which store, when and from which IP) is kept for 180 days and is visible to the account owner.
• A global kill switch can suspend all automated writes on the platform in an emergency.

9. Continuity and backup

The database has managed backups from the cloud provider. Scheduled routines catch up on runs missed after restarts, and read caches can be rebuilt from the marketplaces.

10. Vendors

We use only vendors required for the service (cloud and database, DNS, transactional e-mail, payments, app notifications and AI provider), chosen for offering encryption and access controls consistent with this Policy. The AI provider receives only what the task needs (for example, the text of a question or review and the listing data), never a buyer's tax ID (CPF), e-mail, phone or address.

11. Certifications

As of this date, MetaClick holds no formal security certifications (such as ISO/IEC 27001 or SOC 2). The controls described here are applied and verifiable in the system itself.

12. Review

This Policy is reviewed at least once a year, after any relevant incident and whenever the architecture changes. Questions: eduardo@metalivre.com.br.