Relatórios analíticos · Aula 5 de 6
Proteção de dados, ética e divulgação responsável
9 min de leitura
Os dados de blockchain são públicos, mas isso não significa que seja justo publicar tudo o que um analista consegue deduzir deles. No momento em que um endereço é associado a uma pessoa, as entradas pseudônimas do livro-razão se tornam um registro detalhado e permanente das finanças dessa pessoa, e uma associação equivocada pode expor alguém inocente a assédio, fraude ou perigo físico. Esta aula aborda as práticas profissionais que mantêm a análise on-chain proporcional: minimização de dados, proteção de pessoas físicas, tratamento de informações de fontes abertas, divulgação responsável de vulnerabilidades e descobertas sobre fundos roubados e trabalho com processos legais.
Por que dados públicos ainda precisam de proteção
Três propriedades dos dados on-chain os tornam mais sensíveis do que parecem:
- Possibilidade de associação: uma atribuição revela todo um histórico. Associar um único endereço a um nome expõe todas as transações passadas e futuras do cluster por trás dele.
- Permanência: o livro-razão não pode ser corrigido. Uma atribuição errada publicada hoje continuará associada a essas transações para qualquer pessoa que as pesquisar no futuro.
- Agregação: fatos inofensivos isoladamente (um registro de serviço de nomes, uma publicação em rede social, um padrão de depósito) se combinam para formar um perfil que nenhuma fonte isolada revelou.
Os danos são concretos. Vítimas cujos endereços são publicados se tornam alvos de golpistas de “recuperação” que prometem reaver seu dinheiro mediante pagamento. Pessoas que são publicamente conhecidas por manter grandes saldos já foram alvos de extorsão e coerção física. Pessoas identificadas por engano perdem contas ou sua reputação. E uma publicação pública que identifica o endereço de um suspeito pode alertá-lo antes que os serviços tenham a chance de congelar os fundos.
A maioria dos regimes de proteção de dados em todo o mundo trata informações que podem identificar uma pessoa como dados pessoais, mesmo quando estão disponíveis publicamente, e muitos incluem a minimização de dados entre seus princípios fundamentais. As práticas abaixo constituem uma base profissional, independentemente da legislação local, e a equipe jurídica de uma organização decide como elas se aplicam em uma determinada jurisdição.
Minimização de dados e proporcionalidade
Minimização de dados significa coletar e manter apenas os dados necessários para responder à pergunta. A ideia aparece nas Diretrizes de Privacidade da OCDE (publicadas pela primeira vez em 1980, revisadas em 2013) como o princípio da limitação da coleta, e o Protocolo de Berkeley sobre Investigações Digitais com Fontes Abertas (publicado pelo Centro de Direitos Humanos da UC Berkeley em conjunto com o escritório de direitos humanos da ONU em 2020) a lista como princípio metodológico: coletar e processar apenas o que se justifica por uma finalidade que possa ser explicitada, é necessário para ela e é proporcional a ela.
Proporcionalidade pondera o grau de intrusão de uma medida em relação à gravidade da questão e ao valor do que ela produzirá. Rastrear um exploit de nove dígitos até endereços de depósito em uma exchange é proporcional; traçar o perfil de todas as pequenas contrapartes ao longo do caminho não é.
Na prática:
| Em vez de | Faça isto |
|---|---|
| Enriquecer todas as contrapartes com pesquisas em fontes abertas | Enriqueça apenas os endereços relevantes para decisões dentro do escopo |
| Rastrear indefinidamente | Aplique os limites de saltos e as regras de parada definidos no documento de escopo (consulte Da pergunta à hipótese) |
| Usar endereços reais e nomes em todas as notas de trabalho | Use pseudônimos para os casos (“Endereço A7”, “Pessoa 2”) e mantenha a chave separadamente |
| Usar uma única pasta compartilhada para tudo | Use um anexo de identidade com acesso restrito, legível apenas por quem precisa dele |
| Manter os dados do caso para sempre | Defina um período de retenção conforme a política e, depois, exclua ou arquive os dados |
Como evitar expor pessoas físicas
A regra padrão para qualquer documento que saia da equipe é: não incluir endereços, identificadores ou nomes que apontem para uma pessoa física, a menos que o leitor precise deles para agir (uma exchange congelar uma conta, uma autoridade executar um processo legal) e os receba por um canal restrito.
O que geralmente é aceitável em um relatório público: nomes de serviços, protocolos e empresas; endereços que autoridades, tribunais ou a própria organização vítima tenham publicado; contratos envolvidos em exploits e os endereços que receberam diretamente fundos roubados em um incidente divulgado publicamente. O que não é aceitável: endereços de vítimas, contrapartes sem envolvimento e pessoas físicas identificadas apenas por inferência.
A ocultação é mais difícil do que parece. Truncar um endereço (bc1q…7k3f) não basta se o relatório também informar o valor exato e o minuto da transação: qualquer pessoa pode pesquisar uma saída de 0,95000000 BTC naquele bloco e recuperar o endereço completo. Ao ocultar informações, arredonde também os valores, amplie os horários para abranger o dia ou substitua os detalhes por um rótulo.
Registros de serviços de nomes e links para perfis exigem cuidado especial. Um endereço que resolve para um nome que parece ser de uma pessoa pode pertencer à pessoa nomeada, a alguém que está se passando por ela ou a alguém que vendeu o nome posteriormente. Trate esse tipo de registro como uma pista a verificar, nunca como uma atribuição a publicar (consulte Atribuição e rotulagem).
Tratamento de informações de fontes abertas
A inteligência de fontes abertas (OSINT), como publicações em fóruns, perfis em redes sociais, páginas da web arquivadas e repositórios de código, muitas vezes é o que conecta um cluster on-chain ao mundo real. O Protocolo de Berkeley descreve um processo de investigação adequado a casos on-chain: consultas on-line, avaliação preliminar, coleta, preservação, verificação e análise investigativa.
- Preserve cada item com seu URL, horário de captura em UTC e um hash criptográfico do arquivo salvo, para que seja possível demonstrar posteriormente que ele não foi alterado.
- Verifique de forma independente: uma captura de tela de uma publicação é uma alegação, não um fato. Corrobore-a com uma segunda fonte ou com dados on-chain que não poderiam ter sido falsificados pela publicação.
- Mantenha uma postura passiva. Não envie mensagens a suspeitos, não crie identidades falsas, não tente adivinhar senhas nem acesse contas que não sejam suas. Interações encobertas são assunto para autoridades com poderes legais, e agir por conta própria pode prejudicar o caso e infringir a lei.
- Evite dados obtidos por violações, como bancos de dados de clientes vazados, a menos que sua organização tenha uma base jurídica e uma política claras para usá-los.
- Tenha cuidado com seus próprios rastros. Consultar o endereço de um suspeito em um explorador público revela seu interesse ao operador do explorador. É melhor realizar consultas sensíveis em seu próprio nó ou conjunto de dados (consulte APIs de nós e acesso a dados).
Divulgação responsável de vulnerabilidades
Às vezes, a análise de um exploit revela que a falha ainda não foi corrigida ou que outros contratos copiaram o mesmo código vulnerável. Muitos protocolos são bifurcados, então um padrão de exploit pode ameaçar dezenas de implementações que ainda mantêm fundos.
Divulgação responsável (coordenada) significa informar primeiro, em privado, aqueles que podem corrigir o problema e publicar os detalhes somente depois de lhes dar uma oportunidade razoável de agir. Referências úteis são a ISO/IEC 29147 (divulgação de vulnerabilidades) e a ISO/IEC 30111 (processos de tratamento de vulnerabilidades), além da RFC 9116, que define o arquivo security.txt publicado por muitos projetos para indicar um contato de segurança. Na prática:
- Encontre o contato de segurança do projeto ou o programa de recompensas por bugs; use canais criptografados quando disponíveis.
- Relate o mínimo necessário para reproduzir e corrigir o problema e combine um cronograma.
- Não publique um caminho de exploração funcional, nem um relatório detalhado o bastante para servir como tal, enquanto contratos vulneráveis ainda mantiverem fundos.
- Não transfira os fundos por conta própria para “resgatá-los”, a menos que esteja atuando sob um acordo white hat estabelecido e documentado com o projeto afetado; a situação jurídica varia conforme a jurisdição.
Divulgação de descobertas sobre fundos roubados
Após um roubo, cada minuto conta: às vezes é possível congelar fundos que chegam a um serviço, e stablecoins emitidas de forma centralizada podem ser congeladas por seus emissores no nível do contrato. Mas um alerta incorreto pode congelar a conta de um cliente inocente. Equilibre rapidez e precisão da seguinte forma:
- Notifique diretamente os serviços que receberam fundos, pelos canais publicados de conformidade ou de contato com autoridades, antes de publicar qualquer informação.
- Compartilhe o mínimo de que precisam para agir: endereços, hashes de transações, valores, horários e a probabilidade e o grau de confiança de cada associação (consulte Confiança, incerteza e linguagem).
- Identifique as associações inferidas como inferências. Uma correspondência de valor e horário é motivo para investigar, não para congelar.
- Pondere os alertas públicos. Uma publicação pública ajuda serviços que você não conseguiu contatar a bloquear depósitos, mas também informa ao ladrão quais endereços estão sendo monitorados. Coordene-se com a organização vítima e corrija prontamente as declarações públicas se uma associação se revelar equivocada.
Trabalho com processos legais
A análise on-chain geralmente termina onde começam os registros de custódia, e esses registros são obtidos por meio de processos legais: ordens judiciais, ordens de produção ou solicitações de autoridades competentes, além de assistência jurídica mútua quando os registros estão em outro país (consulte Rastrear valor por meio de exchanges e serviços). O papel do analista é tornar esse processo preciso:
- Redija conclusões nas quais um tribunal ou uma autoridade possa se basear: separe fatos de inferências, descreva os métodos e declare as limitações.
- Mantenha uma cadeia de custódia dos dados e das informações de OSINT: quem coletou o quê, quando, de onde e qual é o hash.
- Solicite aos serviços que preservem os registros com antecedência, pelo canal apropriado, pois os períodos de retenção variam.
- Se atuar como especialista, mantenha a independência, divulgue limitações e conflitos e nunca alegue um grau de certeza superior ao que os dados permitem.
Foco no exame: por que os dados públicos on-chain ainda precisam de proteção (possibilidade de associação, permanência, agregação) e quais são os danos concretos; minimização de dados e proporcionalidade, com o princípio de limitação da coleta da OCDE e o Protocolo de Berkeley como exemplos; pseudônimos de casos, anexos de identidade com acesso restrito e retenção; o que pode ou não aparecer em um relatório público e por que endereços truncados acompanhados de valores e horários exatos podem ser reidentificados; o ciclo de OSINT, a preservação com hashes, a postura passiva e o cuidado com seus próprios rastros; a divulgação coordenada de vulnerabilidades conforme descrita em normas internacionais e os contatos de segurança publicados; a notificação direta, mínima e identificada por grau de confiança de descobertas sobre fundos roubados; processos legais em geral, solicitações de preservação e cadeia de custódia.