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

Esta política descreve os controles de segurança aplicados pelo ZUVIA, plataforma de criação de conteúdo com inteligência artificial para afiliados da TikTok Shop, operada por 62.457.442 RICARDO ARAUJO DOS SANTOS, CNPJ 62.457.442/0001-19.

Ela vale para o serviço em zuviaugc.com e para todas as integrações que ele mantém com plataformas de terceiros.

1. Responsável

Ricardo Araújo dos Santos responde pela segurança da informação e pela proteção de dados pessoais. Comunicações sobre vulnerabilidades, incidentes ou dúvidas de conformidade devem ser enviadas para zuvia.ugc@gmail.com.

2. Credenciais e segredos

• Nenhuma credencial, chave de API ou segredo é gravado no código-fonte ou no repositório. Todos residem em variáveis de ambiente da plataforma de hospedagem.
• Arquivos de ambiente (.env e derivados) estão excluídos do controle de versão.
• Tokens de acesso de terceiros são cifrados antes de serem gravados, com AES-256-GCM e vetor de inicialização único por gravação. O modo GCM autentica o conteúdo: um valor adulterado é recusado, não decifrado parcialmente.
• Segredos nunca são registrados em log. As mensagens de erro identificam a operação e o código de falha, não os valores envolvidos.

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

O acesso a dados pessoais é concedido pelo princípio do privilégio mínimo: cada pessoa e cada componente do sistema recebe o menor conjunto de permissões que permite executar sua função, e nada além disso.

• O acesso de usuários é feito por autenticação federada (OAuth com o Google) ou por link de acesso enviado por e-mail. O ZUVIA não armazena senhas.
• Funções administrativas são restritas a uma lista fechada de endereços, verificada no servidor a cada requisição.
• O acesso a recursos é decidido no servidor, em ponto único, e não pela interface. A ausência de um botão na tela nunca é o mecanismo de proteção.
• Cada cliente acessa somente os próprios dados. A verificação de posse acontece na consulta ao banco, não na apresentação.
• As permissões de cada plano são definidas em uma matriz explícita, avaliada no servidor antes de qualquer operação que gere custo, grave ou exponha dado.
• Integrações com terceiros solicitam apenas os escopos efetivamente usados pelo produto. Escopos não utilizados são desativados na configuração da aplicação.
• Credenciais de infraestrutura (hospedagem, banco de dados, CDN, provedores de pagamento e de IA) são de uso exclusivo da aplicação e não são compartilhadas entre ambientes: desenvolvimento e produção usam credenciais distintas.
• O acesso administrativo às plataformas de infraestrutura é protegido por autenticação multifator.
• Encerrado o vínculo de qualquer colaborador, os acessos são revogados no mesmo dia.

4. Integrações com terceiros

Autorização

As integrações usam OAuth 2.0. O ZUVIA recebe um token de acesso concedido explicitamente pelo titular da conta, com escopo limitado ao necessário, e nunca solicita nem armazena a senha da plataforma de origem.

Assinatura de requisições

Todas as chamadas às APIs integradas são assinadas em HMAC-SHA256 com o segredo da aplicação, conforme exigido por cada provedor.

Recebimento de notificações (webhooks)

Endpoints que recebem notificações automáticas verificam a assinatura criptográfica de cada requisição antes de qualquer processamento. Requisições sem assinatura válida são recusadas. A comparação usa algoritmo de tempo constante, para não revelar informação pelo tempo de resposta.

Retorno de autorização

O parâmetro de estado do fluxo OAuth é assinado e tem prazo de validade, impedindo que uma autorização seja vinculada à conta de outro usuário.

5. Classificação de dados

Os dados tratados pelo ZUVIA são classificados em quatro níveis, e o nível determina o tratamento exigido. A classificação existe para que a proteção seja proporcional ao risco — cifrar tudo com o mesmo rigor tende a produzir, na prática, rigor nenhum.

Nível 1 — Público

Material de divulgação, documentação e estas políticas. Sem restrição de acesso.

Nível 2 — Interno

Métricas agregadas de uso, registros de erro sem identificação pessoal, catálogo de produtos públicos. Acesso restrito à operação; sem exigência de cifragem em campo.

Nível 3 — Confidencial

Dados cadastrais do cliente (nome, e-mail, foto de perfil), conteúdos gerados, histórico de créditos, registros de pagamento e dados comerciais de vendas de afiliado. Tratamento exigido: transmissão cifrada, criptografia em repouso no provedor, acesso restrito ao próprio titular e ao responsável pela operação, e eliminação conforme os prazos da Política de Privacidade.

Nível 4 — Crítico

Segredos de aplicação (chaves de API, segredos de assinatura, credenciais de banco) e tokens de acesso de contas de terceiros pertencentes aos clientes. Tratamento exigido: nunca em código-fonte, nunca em log, nunca exibidos em tela; armazenamento exclusivo em variáveis de ambiente da plataforma ou cifrados em campo com AES-256-GCM, além da criptografia de disco do provedor.

6. Dados em trânsito e em repouso

• Todo o tráfego usa HTTPS/TLS. Não há endpoint em texto claro.
• O banco de dados é PostgreSQL gerenciado, com criptografia em repouso fornecida pelo provedor de infraestrutura, e acesso restrito por credencial e rede.
• Tokens de terceiros recebem camada adicional de cifragem no campo, independente da criptografia de disco.
• Arquivos de mídia são servidos por CDN com endereço derivado do conteúdo, sem enumeração previsível.

7. Dados que NÃO coletamos

Esta seção é tão importante quanto a anterior. O ZUVIA não coleta nem armazena:

• Números de cartão, CVV ou dados bancários — o pagamento ocorre inteiramente no ambiente do provedor de pagamentos;
• Senhas de qualquer plataforma, própria ou de terceiros;
• Documentos de identidade;
• Dados pessoais de compradores finais dos afiliados — as integrações de afiliado retornam produto, loja, valor e comissão, não a identidade de quem comprou.

8. Desenvolvimento

• Verificação estática de tipos e compilação completa são executadas antes de cada publicação. Código que não compila não vai ao ar.
• Toda operação que gera custo ou altera dado passa por verificação de identidade e de permissão no servidor, na primeira linha.
• Operações sensíveis a duplicidade — cobranças, créditos, notificações — usam restrição de unicidade no banco, e não verificação prévia em memória.
• Dependências são obtidas de repositórios públicos com versão fixada.

9. Gestão de vulnerabilidades

Vulnerabilidade em dependência não avisa: é publicada num boletim que ninguém lê, e o sistema segue executando a versão afetada até alguém tropeçar. O procedimento abaixo existe para tornar isso visível em vez de silencioso.

• Monitoramento contínuo de dependências. Verificação automática semanal do gerenciador de pacotes e das ações de automação, com abertura automática de pedidos de atualização. Correções de segurança são tratadas em fila própria, sem esperar as atualizações de rotina.
• Auditoria a cada integração. A esteira de publicação executa auditoria de vulnerabilidades conhecidas em toda alteração enviada ao repositório, e o resultado é registrado no histórico da execução.
• Distinção entre produção e desenvolvimento. Vulnerabilidades em dependências que não são distribuídas ao ambiente de produção são registradas e corrigidas na janela regular; as que afetam código em execução têm prioridade imediata.
• Verificação estática obrigatória. Análise de tipos, verificação de padrões de código e compilação completa são executadas antes de cada publicação. Alteração que não passa não vai ao ar.
• Versões fixadas. As dependências têm versão travada em arquivo de bloqueio, o que impede que uma alteração de terceiro entre em produção sem revisão.
• Canal de recebimento. Relatos externos de vulnerabilidade chegam por zuvia.ugc@gmail.com e entram no procedimento de resposta a incidentes descrito na seção seguinte.

Prazos de correção

• Crítica em produção: contenção imediata e correção em até 72 horas.
• Alta em produção: correção em até 7 dias.
• Média, ou alta restrita ao ambiente de desenvolvimento: até 30 dias.
• Baixa: na janela regular de manutenção.

10. Resposta a incidentes

Papéis e responsabilidades

A operação é conduzida por estrutura enxuta, e por isso os papéis estão concentrados e nomeados — atribuição difusa é o que faz um incidente ficar sem dono.

• Responsável pela resposta a incidentes e encarregado de dados (DPO): Ricardo Araújo dos Santos. Decide a classificação do incidente, coordena a contenção, autoriza comunicações e responde pelas notificações legais.
• Ponto único de contato: zuvia.ugc@gmail.com, monitorado em dias úteis. É o canal para clientes, pesquisadores de segurança, plataformas parceiras e autoridades.
• Provedores de infraestrutura respondem pelos incidentes da camada que operam (hospedagem, banco de dados, CDN, pagamentos) e são acionados pelos canais oficiais de suporte de cada um.

Classificação

• Crítico — exposição de segredos de aplicação ou de tokens de contas de clientes; acesso não autorizado ao banco de dados.
• Alto — exposição de dados pessoais de clientes; indisponibilidade prolongada do serviço.
• Médio — vulnerabilidade explorável reportada, sem evidência de exploração.
• Baixo — falha sem impacto sobre dados ou disponibilidade.

Procedimento

• 1. Registro e triagem. Todo relato é registrado com data, origem e descrição, e classificado em até 1 dia útil.
• 2. Contenção. Para incidentes críticos, a ação imediata é revogar e rotacionar as credenciais afetadas e invalidar as autorizações de terceiros envolvidas — antes de qualquer investigação de causa.
• 3. Erradicação e recuperação. Correção da causa, publicação da correção e verificação de que o acesso indevido cessou.
• 4. Notificação. Conforme a seção seguinte.
• 5. Registro pós-incidente. Documentação do que ocorreu, do que falhou e da medida adotada para impedir recorrência.

Comunicação e prazos

• Recebimento de relato: reconhecido em até 3 dias úteis.
• Titulares afetados e ANPD: comunicados em prazo razoável, conforme o art. 48 da Lei nº 13.709/2018 (LGPD), com descrição dos dados envolvidos, dos riscos e das medidas adotadas.
• Plataformas parceiras: quando o incidente envolver integração de terceiro, o provedor é notificado pelos canais oficiais e as autorizações afetadas são revogadas.
• Divulgação responsável: pesquisadores devem relatar por e-mail sem publicação prévia. Coordenamos a divulgação após a correção.

11. O que ainda não fazemos

Declarado por transparência. O ZUVIA é operado por estrutura enxuta, e estes controles ainda não existem:

• Certificação formal (ISO 27001, SOC 2) — não obtida;
• Teste de intrusão por terceiro independente — não realizado;
• Centro de operações de segurança com monitoramento contínuo — não há;
• Programa formal de recompensa por vulnerabilidade — não há, mas relatos são bem-vindos pelo e-mail acima.

Esta lista é revista conforme a operação cresce. Preferimos declará-la a sugerir maturidade que não temos.

12. Vigência

Esta política vigora a partir da data de última atualização indicada no topo e substitui versões anteriores. Alterações materiais serão publicadas nesta mesma página.