PENTESTY · ANÁLISE EDITORIAL · · 4 min de leitura
Trezor e ShipMonk: a confirmação de exclusão precisa alcançar as cópias
O fornecedor confirmou que apagou os dados. Veja quais evidências ajudam a verificar o descarte em sistemas, exportações e procedimentos de recuperação.
Por Pentesty
O comunicado tem uma data e uma atribuição
Na atualização de 4 de setembro de 2026, a Trezor informou exposição de dados de aproximadamente mais 67 mil clientes dos EUA na ShipMonk, referentes a pedidos entre novembro de 2019 e agosto de 2021. Segundo a fabricante, o fornecedor havia confirmado por escrito a exclusão dessas informações. A Trezor afirmou que seus sistemas e dispositivos não foram comprometidos. Este é o relato da contratante sobre o incidente logístico, não uma reconstrução técnica independente.
O recibo deve identificar aquilo que foi apagado
O contrato pode prever um prazo, mas a equipe de operação precisa saber onde ele começa e quais registros entram no procedimento. Entrega, devolução e encerramento da relação comercial podem acionar rotinas distintas. Defina a regra por conjunto de dados, com responsável e tratamento das exceções necessárias ao serviço.
A política da Trezor descreve exclusão de dados de pedidos após 90 dias, com exceções declaradas. Esse prazo pertence à política da empresa e não deve ser apresentado como obrigação universal. Na avaliação de outro fornecedor, peça a justificativa do prazo aplicável e a descrição de como ele é executado.
Desenhe o caminho das cópias antes de pedir evidência
Uma operação de entrega pode enviar dados para atendimento, etiquetas, relatórios e ferramentas de análise. Para cada caminho realmente utilizado, registre quem recebe a informação, por quanto tempo precisa dela e como participa do descarte. Não presuma que apagar a linha no sistema principal elimina uma exportação feita anteriormente.
Peça um inventário proporcional ao contrato, sem solicitar dados de outros clientes do prestador. Relacione sistemas operacionais, cópias de trabalho e procedimentos de recuperação aos responsáveis. Essa delimitação complementa a análise de acessos de terceiros no caso dinamarquês: acesso permitido e necessidade de retenção são decisões diferentes.
Ensaie o ciclo com um pedido fictício
Combine um ambiente autorizado com o fornecedor e crie um identificador sintético reconhecível. Faça o registro percorrer apenas os componentes incluídos no ensaio. Se algum sistema real não puder participar, registre a limitação e peça documentação correspondente; não preencha a lacuna com uma conclusão de exclusão completa.
Acione o procedimento previsto e verifique os pontos onde o registro deveria deixar de aparecer. Compare a resposta de uma consulta comum com a de uma exportação autorizada. Registre também o comportamento de uma solicitação legítima após o descarte, para identificar dependências que ainda precisam de tratamento.
- Antes: conjunto fictício, destinos previstos, prazo aplicável e responsável pela execução.
- Durante: identificação do procedimento, horário, sistemas abrangidos e exceções registradas.
- Depois: consultas autorizadas, resultado observado e decisão sobre cópias que tenham tratamento diferente.
A restauração também precisa respeitar o descarte
Pergunte como o fornecedor trata registros que podem reaparecer ao restaurar uma cópia anterior. Uma resposta útil identifica o período de retenção da cópia, quem pode acessá-la e o procedimento para reaplicar exclusões quando necessário. Não substitua essa explicação por uma exigência genérica de apagar imediatamente todo backup.
Ensaie a restauração com conteúdo sintético quando isso estiver no escopo e for operacionalmente viável. Verifique o resultado antes de reabrir a aplicação ao uso comum. Se o exercício não alcançar essa etapa, descreva a dependência no aceite e atribua a próxima verificação a um responsável.
Uma divergência deve mudar o estado da decisão
Se a amostra reaparecer onde deveria estar excluída, preserve a evidência minimizada e interrompa a conclusão de descarte daquele conjunto. Peça apuração do alcance, com critérios para eventual comunicação e contenção definidos pelas áreas responsáveis. O objetivo é resolver a divergência sem transformar uma amostra em contagem de todo o incidente.
O recebimento de relatórios também exige critérios de origem e autorização, como discutimos em investigações corporativas e procedência dos dados. Ao encerrar o trabalho, informe quais cópias foram verificadas, quais dependem de declaração e quais permanecem pendentes.
Perguntas frequentes
O caso demonstra invasão das carteiras Trezor?
O comunicado atribui a exposição à logística e afirma que sistemas e dispositivos Trezor não foram comprometidos. Não equipare dados de pedidos a acesso ao hardware.
Uma confirmação escrita deixa de ter valor?
Ela documenta uma declaração importante. Peça identificação do conjunto, do procedimento e das limitações para relacioná-la às evidências disponíveis.
Todos os fornecedores devem apagar dados após 90 dias?
O prazo citado é uma escolha declarada pela Trezor. Cada organização precisa definir sua regra aplicável com as áreas responsáveis e documentar exceções.
Como testar sem usar dados pessoais reais?
Use pedidos fictícios e identificadores sintéticos em componentes expressamente autorizados. Registre o alcance do exercício e evite consultar informações de outros clientes.
Fontes e referências
- Trezor: comunicado e atualização de 4 de setembro sobre ShipMonk
- Trezor: política declarada de privacidade de pedidos
Análise original da Pentesty, publicada em 16 de outubro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.