Como protegemos os dados do seu pet

01 Três princípios que orientam as decisões

Segurança boa não é uma lista de tecnologias; é um punhado de decisões repetidas com disciplina. As nossas são estas:

• A regra mora no servidor, não na tela. Esconder um botão não protege nada: quem chama a nossa interface de programação diretamente passa por cima da tela. Toda decisão que importa — quem vê o quê, quem é assinante, quanto já foi usado — é tomada no servidor.
• Falhar fechado. Quando o sistema não consegue confirmar uma permissão, ele nega. Liberar no escuro é o erro mais caro que um serviço com dados de saúde pode cometer.
• Não guardar o que não é preciso. O dado mais seguro é o que não existe. A foto do documento é o exemplo central: ela cumpre sua função e é descartada.

02 Proteção da sua conta

• Senhas são armazenadas apenas como hash criptográfico — não temos como ler a sua senha, nem para ajudar no suporte.
• O cadastro é confirmado por código enviado ao seu e-mail, o que impede criar conta com endereço alheio.
• A redefinição de senha usa link ou código com validade curta e de uso único.
• A sessão do aplicativo usa tokens de acesso de curta duração com renovação automática: um token capturado tem janela de utilidade pequena.
• Ao sair da conta, a sessão é encerrada também nos serviços conectados, como o de assinatura.

03 Isolamento por conta, aplicado no banco de dados

Cada tabela do Boopet tem segurança em nível de linha (Row Level Security) ativada. Na prática: a consulta que o aplicativo faz já chega ao banco amarrada à identidade do usuário logado, e o banco só devolve linhas que pertencem a ele.

Um exemplo concreto do princípio "a regra mora no servidor": o usuário tem permissão de leitura da própria linha de assinatura e nenhuma permissão de escrita sobre ela. Sem isso, "eu sou assinante" seria uma alteração de uma linha de distância. Quem escreve essa informação é exclusivamente o serviço que recebe a confirmação da loja.

04 Criptografia

• Em trânsito: toda comunicação entre o aplicativo, o site e nossos servidores usa HTTPS/TLS. Não existe caminho em texto aberto.
• Em repouso: o banco de dados e o armazenamento de arquivos são criptografados no provedor de infraestrutura.
• No aparelho: guardamos localmente apenas preferências e o token de sessão, no armazenamento protegido do sistema operacional. Nenhum dado sensível fica em arquivo aberto.

05 Fotos dos pets e arquivos

As fotos ficam em um bucket privado, não público. A diferença importa: um bucket público significa endereço adivinhável por quem conhecer o formato do caminho.

• Cada arquivo é gravado em uma pasta identificada pelo dono, e a política de acesso confere essa correspondência a cada leitura, envio, substituição ou exclusão.
• O acesso à imagem se dá por link temporário assinado, gerado sob demanda e com expiração. Nunca guardamos URLs permanentes.
• Trocar a foto do pet apaga a anterior — arquivos órfãos não ficam acumulando no armazenamento.
• Há limite de tamanho e de tipo de arquivo aceito, verificado no servidor.

06 Fotos de documentos: o que acontece e o que não fica

Este é o ponto que mais gera dúvida, então vale o detalhe:

A extração é enviada ao aplicativo com estado de pendente de revisão. Nada vira alarme de medicamento sem passar pelo seu aval — uma decisão de segurança tanto quanto de produto.

07 Segredos nunca ficam dentro do aplicativo

Um aplicativo instalado no celular pode ser desmontado por qualquer pessoa. Tudo que é embutido nele deve ser considerado público. Por isso:

• As chaves dos provedores de inteligência artificial vivem apenas no servidor, como segredos de ambiente, e jamais são embutidas no aplicativo.
• A leitura por foto é executada por uma função no servidor. O aplicativo apenas pede — não sabe qual provedor responde nem com que credencial.
• As únicas chaves presentes no aplicativo são públicas por definição (identificador do projeto, chave anônima do banco protegida por segurança em nível de linha, chave pública da loja de assinaturas).
• Configurações operacionais como provedor, modelo e limites são alteradas no servidor, sem republicar o aplicativo.

08 O plano é verificado no servidor

A tela decide o que desenhar; o servidor decide o que executar. A função de leitura por foto confere a assinatura por conta própria e recusa a chamada de quem não tem plano ativo, mesmo que a requisição venha com uma credencial legítima de usuário.

Sem essa verificação no servidor, tanto o custo quanto a cota seriam, na prática, opcionais para quem soubesse chamar a interface diretamente.

09 Cotas e proteção contra abuso

• Toda leitura é contabilizada antes da chamada ao modelo, inclusive as que falham — assim ninguém contorna o limite forçando erros.
• A cota é mensal, ancorada no ciclo da assinatura, e separada por tipo de documento.
• Há limite de tamanho de imagem aceito, verificado no servidor.
• Os registros de consumo não podem ser alterados nem apagados pelo usuário.

10 Moderação de imagens

Antes de extrair qualquer informação, a imagem é avaliada quanto a conteúdo impróprio. A ordem é proposital: a primeira coisa que o sistema faz é decidir se deve prosseguir.

Quando uma imagem é recusada, registramos apenas a categoria e o número de ocorrências da conta. Não guardamos a imagem nem qualquer descrição do que ela continha — uma descrição seria, ela própria, um registro do conteúdo que decidimos não guardar.

11 Recebimento das confirmações de assinatura

As confirmações de compra chegam por um endereço dedicado no servidor, que é o único caminho capaz de escrever o status de assinatura de uma conta. Ele é protegido por várias camadas:

• Autenticação obrigatória: sem o segredo configurado, o endereço recusa tudo. Falhar fechado é melhor do que aceitar qualquer requisição que afirme "esta pessoa é assinante".
• Assinatura criptográfica (HMAC) da entrega, incluindo o horário de envio, o que impede reaproveitar uma requisição antiga.
• Janela de tempo: entregas antigas demais são recusadas.
• Idempotência: cada evento tem identificador único e é registrado antes de ser processado. Reentregas não duplicam efeito, e uma falha no meio do caminho é refeita com segurança.

12 O que registramos — e o que não

13 Backup e continuidade

A base de dados é hospedada em infraestrutura gerenciada, com backups automáticos periódicos mantidos pelo provedor e redundância de armazenamento. Alterações de esquema do banco são versionadas e aplicadas de forma controlada, o que permite auditar exatamente o que mudou, quando e por quê.

Backups servem para recuperação de desastre. Eles não são usados para consulta a dados de contas excluídas, e expiram dentro do ciclo normal de retenção do provedor.

14 Resposta a incidentes

Nenhum sistema é inviolável, e prometer o contrário seria desonesto. Se ocorrer incidente de segurança que possa acarretar risco ou dano relevante aos titulares:

1. contemos o incidente e preservamos evidências;
2. avaliamos quais dados e quais contas foram afetados;
3. comunicamos os titulares atingidos e a Autoridade Nacional de Proteção de Dados (ANPD) em prazo razoável, conforme o artigo 48 da LGPD;
4. informamos as medidas de correção adotadas e o que você pode fazer para se proteger;
5. revisamos o que permitiu o incidente e corrigimos a causa, não apenas o sintoma.

15 Encontrou uma vulnerabilidade?

Ficamos gratos por relatos responsáveis. Escreva para contact@boopet.app com o assunto "Segurança", descrevendo o problema e os passos para reproduzi-lo.

16 O que cabe a você

Parte da segurança está do seu lado, e vale dizer sem rodeios:

• use uma senha exclusiva para o Boopet, que não seja reaproveitada de outros serviços;
• mantenha bloqueio de tela ativo no aparelho — quem destrava o celular, destrava o app;
• não compartilhe a conta, mesmo com quem também cuida do animal;
• mantenha o aplicativo e o sistema do aparelho atualizados;
• ao trocar ou vender o aparelho, saia da conta antes;
• guarde os documentos originais dos seus animais — o aplicativo organiza, mas não substitui o arquivo de papel.