Priviy
privacy-basicsINFO

Metadados na nuvem: o que o seu fornecedor zero-knowledge continua a ver (2026)

O zero-knowledge protege o conteúdo dos ficheiros mas deixa escapar toda uma camada de sinais: tamanho, momento, frequência de acesso, estrutura de pastas, IP de origem. Em 2026, estes metadados bastam para reconstruir a sua utilização, o seu perfil e por vezes a sua identidade. Análise completa do que o Proton Drive, o Tresorit, o pCloud Crypto e o Nextcloud E2E NÃO cifram — e como limitar os danos.

Por Eric Gerard · Éditeur · Priviy12 min de leituraPhoto: Thomas Jensen via Unsplash

Que metadados é que a sua nuvem zero-knowledge continua a expor?

O zero-knowledge cifra o conteúdo do ficheiro mas não os sinais de utilização. O Proton Drive, o Tresorit e o pCloud Crypto conservam todos em claro: o tamanho do ficheiro (bytes), as marcas temporais de criação/modificação, o IP de origem (registo de 30 dias), a frequência de acesso e o user-agent. Através de correlação, estes sinais bastam para traçar o perfil da utilização e podem contribuir para a reidentificação — é o princípio da análise de tráfego. E a lógica dos relatórios de transparência dos fornecedores zero-knowledge confirma-o: o que podem entregar mediante pedido legal são metadados (registos de ligação, IP, marcas temporais), nunca o conteúdo cifrado que não conseguem tecnicamente decifrar.

O essencial

O zero-knowledge protege o conteúdo dos seus ficheiros: nem o fornecedor, nem um atacante que viole os seus servidores, nem um Estado que imponha um mandado conseguem ler o que armazena. É a promessa criptográfica do Proton Drive, do Tresorit, do pCloud Crypto e do Nextcloud E2E.

Mas em torno desse conteúdo cifrado orbita toda uma camada de sinais que permanecem em claro do lado do servidor: o tamanho de cada ficheiro, as marcas temporais de criação e modificação, os registos de acesso, o IP de origem, a frequência de ligação e por vezes a estrutura de pastas ou o hash do conteúdo cifrado. Estes sinais são metadados — e a sua fuga, em 2026, basta em muitos casos para reconstruir a sua utilização, o seu perfil e por vezes a sua identidade.

A grande mentira implícita no marketing zero-knowledge é sugerir que um serviço «zero-knowledge» não sabe nada sobre si. A realidade é mais matizada: não sabe o que está dentro dos seus ficheiros, mas sabe com precisão quando carrega, de onde, em que volume e com que frequência. Para a grande maioria dos casos de utilização, é proteção suficiente. Para um perfil de alto risco (jornalista, ativista, denunciante), é precisamente o elo fraco.

Este artigo discrimina o que o Proton Drive, o Tresorit, o pCloud Crypto e o Nextcloud E2E não cifram, o que daí se pode inferir e os sete passos concretos para limitar as fugas sem bloquear o seu fluxo de trabalho.

O que é que um fornecedor de nuvem zero-knowledge vê realmente apesar da cifragem?

Racks de servidores iluminados a azul num centro de dados
Racks de servidores iluminados a azul num centro de dados

Para compreender o que escapa, é preciso distinguir três zonas de dados em qualquer nuvem:

  1. Zona do conteúdo — os bytes em bruto do ficheiro (texto, imagem, vídeo). Cifrados do lado do cliente pelos serviços zero-knowledge.
  2. Zona dos metadados do ficheiro — nome, tamanho, tipo MIME, marcas temporais, identificador interno. Parcialmente cifrada consoante o serviço.
  3. Zona dos metadados técnicos — IP de origem, user-agent, versão do cliente, latência, frequência dos pedidos, duração da sessão. Nunca cifrada (impossível de cifrar do lado do cliente por construção).

Um zero-knowledge sério protege a zona 1 e cifra parte da zona 2 (nomes, estruturas de pastas). A zona 3 permanece sistematicamente em claro porque os servidores precisam dela para funcionar.

Análise do Proton Drive: o que escapa apesar do OpenPGP

O whitepaper do Proton Drive de 2023 (atualizado em 2024) lista explicitamente as informações conservadas não cifradas do lado do servidor:

  • Tamanho do ficheiro em bytes, arredondado ao bloco de cifragem (16 KB por predefinição). Permite distinguir uma foto (3–5 MB), um PDF (<5 MB), um filme (700 MB+), um arquivo ZIP (variável).
  • Marcas temporais de criação, modificação e último acesso, em UTC com resolução ao segundo. Permitem rastrear a atividade diária e correlacioná-la com outros sinais.
  • Identificador interno (UUID) de cada ficheiro e de cada utilizador. Permite ligar os registos de acesso aos ficheiros.
  • IP de origem de cada ligação, conservado durante 30 dias para fins antifraude/antiabuso. Permite localizar aproximadamente o utilizador ou detetar mudanças de país.
  • User-agent e versão do cliente utilizado. Permite traçar o perfil da plataforma e potencialmente visar vulnerabilidades.
  • Frequência de acesso por ficheiro, conservada para fins de desempenho (cache, prefetch).

Também pode ser conservado um hash do conteúdo cifrado, usado para a deduplicação intra-utilizador. Tal hash não permite recuperar o conteúdo, mas deixa o fornecedor saber se dois ficheiros cifrados pertencentes ao mesmo utilizador são idênticos — útil para poupar espaço de armazenamento, problemático se o utilizador carregar o mesmo ficheiro sensível em várias contas.

Análise do Tresorit: modelo semelhante, menos transparência

O Tresorit cifra o conteúdo e os nomes dos ficheiros do lado do cliente (as auditorias de segurança independentes confirmam a implementação). Mas o seu whitepaper público é menos detalhado do que o do Proton: menciona a conservação do tamanho e das marcas temporais «para fins operacionais» sem especificar os períodos de conservação. Os registos de acesso são conservados «durante o tempo necessário» — uma linguagem jurídica vaga.

O Tresorit publica um relatório de transparência, mas com menor granularidade do que o Proton. Por construção, o que um serviço zero-knowledge pode entregar mediante pedido legal limita-se aos metadados (registos, IP, marcas temporais): o conteúdo cifrado permanece inacessível. O detalhe preciso dos metadados entregues não é, em geral, tornado público.

Análise do pCloud Crypto: zero-knowledge parcial

O modelo pCloud Crypto cifra apenas a pasta Crypto — uma pasta separada ativada através do extra pago. O resto da conta (os ficheiros fora da Crypto) é gerido com chaves do lado do servidor. Para a pasta Crypto:

  • O conteúdo e os nomes dos ficheiros são cifrados do lado do cliente (chave derivada da palavra-passe Crypto).
  • O tamanho dos ficheiros Crypto permanece em claro, tal como no resto da conta.
  • As marcas temporais são conservadas em claro.
  • O hash do conteúdo cifrado é usado para a deduplicação.

Para um utilizador do pCloud que coloca os documentos sensíveis na pasta Crypto e tudo o resto (música, fotos de férias) fora dela, a própria proporção Crypto/não-Crypto é um metadado revelador. Se 90% dos ficheiros de uma conta estiverem na pasta Crypto, isso sugere um utilizador atento à privacidade — uma informação que poderia interessar a uma autoridade.

Análise do Nextcloud E2E: melhor granularidade, atrito máximo

O módulo de cifragem End-to-End do Nextcloud, desde a versão 25, cifra o conteúdo, os nomes e a estrutura de pastas do lado do cliente. É a implementação mais completa entre os serviços aqui analisados. Mas:

  • A instância Nextcloud permanece um servidor web tradicional, pelo que o IP de origem, as marcas temporais e os registos de acesso ficam visíveis nos logs do Apache/Nginx — a menos que os desative explicitamente (perdendo a capacidade de depuração).
  • O tamanho dos ficheiros cifrados permanece legível porque o servidor aloca o armazenamento.
  • O módulo E2E só é compatível com os clientes de ambiente de trabalho e iOS/Android — não com o cliente web — o que restringe a utilização.

No papel, uma instância Nextcloud E2E auto-alojada numa jurisdição protetora é a solução mais defensiva. Na prática, o custo operacional (administração, atualizações, cópias de segurança, certificados TLS) e o risco de erro humano fazem dela uma solução reservada a perfis tecnicamente sofisticados.

O que se pode reconstruir a partir dos metadados

Três mecanismos concretos. Não são casos nomeados mas ilustrações do que os metadados por si só podem revelar.

Reconstrução do perfil do utilizador

A partir dos momentos, tamanhos e frequências de carregamento/descarregamento de uma conta na nuvem, pode-se razoavelmente classificar um utilizador em perfis típicos — sem nunca decifrar o conteúdo. É o princípio do fingerprinting comportamental: categorias como «fotógrafo amador», «freelancer criativo», «funcionário de escritório», «estudante universitário» ou «ativista / jornalista com elevada carga documental» apresentam assinaturas de utilização diferentes.

O perfil «ativista / jornalista» é assinalado por carregamentos em rajada de tamanhos homogéneos (1–3 MB por ficheiro, sugerindo documentos PDF digitalizados), em horários irregulares (fora do padrão de escritório das 9h às 18h), a partir de IP variados (sugerindo mobilidade ou VPN), com acessos de leitura muito espaçados mas recorrentes sobre os mesmos UUID de ficheiro. Nenhuma destas inferências exige decifrar o conteúdo.

Identificação por correlação

A identificação por correlação significa cruzar os metadados de um serviço com outros rastos (os logs de outro fornecedor, dados de localização, vários registos). Um fornecedor zero-knowledge não pode entregar conteúdo, mas os seus registos de ligação (IP de origem, marcas temporais) podem, mediante pedido legal, ser cruzados com outras fontes para situar uma pessoa. O caso público do Proton de 2021 ilustra-o: por ordem de um tribunal suíço, o Proton teve de registar e depois divulgar o endereço IP de uma conta — sem nunca decifrar qualquer conteúdo.

Neste tipo de cenário, nenhum conteúdo é decifrado — nem tecnicamente exequível nem necessário: os metadados de ligação por si só bastam para orientar uma investigação. É precisamente disto que um jornalista que cobre temas sensíveis se deve precaver.

Dedução da estrutura de pastas a partir do tamanho e da estrutura

Mesmo quando os nomes dos ficheiros estão cifrados (como no Proton Drive e no Tresorit), a distribuição dos tamanhos dentro de uma pasta é reveladora. Uma pasta que contém 30 ficheiros de 1,5 MB cada sugere digitalizações em PDF de documentos A4 a preto e branco — comportamento típico de arquivo administrativo. Uma pasta que contém um único ficheiro de 4 GB sugere um filme. Uma pasta que contém 200 ficheiros de 50–200 KB sugere e-mails exportados como .eml.

Combinada com as marcas temporais, esta permite reconstruir quando o utilizador arquivou o quê, sem saber nada sobre o conteúdo em si. Para uma investigação, é mais do que suficiente para direcionar pedidos adicionais ou para orientar uma busca física.

Sete passos para limitar as fugas em 2026

Nenhum destes passos é dispendioso ou tecnicamente complexo. A maioria pode ser implementada em menos de uma hora.

Passo 1 — Contentor cifrado local antes do carregamento. Em vez de carregar ficheiro a ficheiro, coloque os documentos sensíveis num contentor Cryptomator (gratuito, multiplataforma) ou num volume VeraCrypt. O contentor surge à nuvem como um único blob de tamanho fixo (que configura). O fornecedor vê «um ficheiro de 5 GB» em vez de «237 PDF de 200 KB a 4 MB». A estrutura interna de pastas torna-se invisível.

Passo 2 — VPN multi-hop ou Tor para o acesso. Mascare o seu IP de origem. Uma VPN padrão (Mullvad, Proton VPN, IVPN) é suficiente na maioria dos casos. Para perfis de alto risco, use o Tor com acesso à nuvem através do serviço onion deles, se disponível (o Proton expõe o seu serviço onion oficial em protonirockerxow.onion).

Passo 3 — Evite carregamentos em horários previsíveis. Se carrega sempre às 18h depois do trabalho, é uma assinatura comportamental explorável. Varie os horários, agrupe os seus carregamentos em janelas irregulares de 1–2 horas.

Passo 4 — Elimine as versões históricas. As nuvens zero-knowledge conservam frequentemente versões anteriores dos ficheiros modificados. Cada versão tem a sua própria marca temporal e tamanho — a árvore temporal torna-se reveladora. Configure o seu serviço para limitar o histórico a 7 dias, ou elimine manualmente.

Passo 5 — Separe arquivo e colaboração. Não coloque arquivos sensíveis e documentos partilhados na mesma conta de nuvem. Use dois fornecedores ou duas contas para garantir que uma única fuga não exponha toda a sua atividade digital.

Passo 6 — Pague em criptomoeda ou com voucher em dinheiro onde possível. O Proton aceita Bitcoin, o pCloud aceita BitPay. Dissociar a sua identidade de pagamento da sua conta de nuvem reduz a rastreabilidade. Para os mais cautelosos, pague com Bitcoin misturado (tumbled) ou Monero.

Passo 7 — Leia os relatórios de transparência anuais. O Proton, o Tresorit e o pCloud publicam estatísticas sobre pedidos governamentais. Verifique todos os anos: quantos pedidos recebidos, quantos parcialmente satisfeitos, que jurisdições os solicitam. Se os números do seu fornecedor dispararem sem comunicação transparente, mude de fornecedor.

O nosso veredicto 2026

Para a maioria dos utilizadores de nuvem atentos à privacidade em 2026, a combinação vencedora continua a ser a que documentámos em E2E vs zero-knowledge cloud storage: Proton Drive ou Tresorit para o conteúdo, acesso através de clientes nativos, chave de recuperação em papel. Os metadados que escapam são compatíveis com um modelo de ameaça de «concorrência comercial» ou «vigilância estatal passiva».

Para perfis de alto risco (jornalista a investigar a vigilância estatal, denunciante, ativista politicamente exposto, dissidente), o zero-knowledge clássico não basta. É preciso empilhar:

  • Contentor Cryptomator antes do carregamento (camada 1)
  • Acesso através do Tor ou de uma VPN multi-hop (camada 2)
  • Fornecedor suíço fora dos 14 Eyes (camada 3)
  • Pagamento crypto desanonimizado (camada 4)
  • Conta isolada das outras contas nominais (camada 5)

Esta pilha custa 1–2 horas de configuração inicial e 5 minutos de atrito por sessão. É o preço da resistência à correlação de metadados em 2026 — um custo trivial face às consequências de uma desanonimização bem-sucedida.

Leitura adicional


Artigo publicado a 5 de junho de 2026. Metodologia: análise dos whitepapers públicos do Proton Drive (2023, atualizado em 2024), do Tresorit (2022), do pCloud Crypto e do Nextcloud E2E v25; análise dos relatórios de transparência públicos; aplicação dos princípios conhecidos da análise de tráfego e da correlação de metadados. Guia editorial explicativo: não avança qualquer estudo estatístico próprio nem alegações de casos judiciais próprios; os exemplos citados (incluindo o caso do Proton de 2021) são públicos e verificáveis.

Choix éditorial
4.5 / 5

Store your files privately → pCloud

Swiss privacy · 10 GB free · optional zero-knowledge Crypto

Société suisse depuis 2013Satisfait ou remboursé 10jFree 10 GB
Voir l'offre