By · Last updated 2026-03-03

Voltar ao BlogGDPR & Conformidade

Zero-Knowledge vs. Zero-Trust: Por Que Sua Ferramenta...

O LastPass criptografou os dados de seus usuários também — e $438 milhões foram roubados de qualquer maneira.

March 3, 20269 min de leitura
zero-knowledgeencryptionGDPRdata protectionSaaS securityLastPass

A Ilusão da Encriptação

Atualizado para 2026

Em dezembro de 2022, a LastPass informou os utilizadores sobre uma violação. A mensagem foi tranquilizadora: as passwords estavam "encriptadas." O conteúdo dos cofres estava "seguro."

Até 2025, mais de 438 milhões de dólares tinham sido roubados de utilizadores da LastPass. O roubo veio diretamente dos seus cofres supostamente seguros.

Como? A LastPass detinha as chaves.

A sua equipa de segurança deve saber isto antes de escolher uma ferramenta na nuvem. Aplica-se a qualquer ferramenta que trate ficheiros sensíveis — incluindo plataformas de anonimização de PII.

Encriptação do Lado do Servidor vs. Arquitetura de Zero Conhecimento

A maioria das ferramentas na nuvem diz que "encripta os seus ficheiros." Mas usam encriptação do lado do servidor (SSE). Isto é o que isso significa:

PropriedadeEncriptação do Lado do ServidorArquitetura de Zero Conhecimento
Onde ocorre a encriptaçãoNo servidor do fornecedorNo seu dispositivo (browser/desktop)
Quem detém as chavesO fornecedorApenas você
O fornecedor pode ler o seu conteúdoSimNão
Uma violação expõe ficheirosSimNão (apenas texto cifrado)
O fornecedor pode ser forçado a divulgarSimNão (não tem os dados)
Acesso das autoridadesVia fornecedorImpossível sem a sua chave

A LastPass detinha as chaves. Esse foi o erro fatal. Os atacantes entraram e obtiveram tanto o texto cifrado como as ferramentas para o decifrar. Usaram engenharia social, força bruta em passwords fracas e metadados de contas antigas.

Por Que Isto Importa para o Artigo 25 do RGPD

O artigo 25 do RGPD (Proteção de dados desde a conceção) é claro. Os responsáveis pelo tratamento devem usar "medidas técnicas e organizativas adequadas." Estas devem ser integradas desde o início.

O Comité Europeu para a Proteção de Dados (CEPD/EDPB) esclareceu que isto inclui a minimização criptográfica de dados. O próprio sistema deve bloquear o acesso a registos. Os controlos de acesso por si só não chegam.

Um fornecedor que detém as suas chaves não pode cumprir o artigo 25 na sua forma estrita. Eis porquê:

  1. Uma violação do sistema pode expor os seus registos.
  2. Uma intimação ao fornecedor pode entregar o seu conteúdo.
  3. Um funcionário malicioso pode ver os seus ficheiros.
  4. Um ataque à cadeia de fornecimento pode expor tudo.

O Comissário Federal Alemão para a Proteção de Dados (BfDI) emitiu orientações sobre isto. Também a Autoridade Austríaca de Proteção de Dados (Datenschutzbehörde). Ambas dizem que o zero conhecimento é a melhor escolha técnica para processamento de alto risco.

A Realidade das Violações SaaS

O relatório AppOmni / Cloud Security Alliance 2024 encontrou um aumento de 300% em violações SaaS de 2022 a 2024. Os dados principais:

  • Tempo até à violação: 9 minutos (antes medido em horas)
  • Participação de terceiros em violações: duplicou ano após ano (Verizon DBIR 2025)
  • Violação da Conduent: 25,9 milhões de registos expostos (números de segurança social, ficheiros de saúde)
  • Violação do fornecedor do NHS: 9 milhões de doentes expostos

As promessas de política já não chegam. A arquitetura sólida é o padrão mínimo. Isto aplica-se a todo o processamento de alto risco.

Como É uma Verdadeira Arquitetura de Zero Conhecimento

Um sistema real de zero conhecimento tem estas características claras:

1. Derivação de chave do lado do cliente A sua chave vem da sua password. Um KDF com uso intensivo de memória (Argon2id, bcrypt ou scrypt) é executado no seu dispositivo. A chave nunca o abandona.

2. Encriptação do lado do cliente O seu conteúdo é encriptado antes de sair do seu browser ou aplicação. O servidor recebe apenas texto cifrado. Sem a chave, esse texto é inútil.

3. Sem armazenamento de chave do lado do servidor O fornecedor não guarda nenhuma chave, nenhum fragmento de chave e nenhuma cópia de segurança de chave. Usa a sua própria frase de recuperação para recuperar o acesso.

4. Verificabilidade criptográfica O sistema deve ser bem documentado. Deve estar aberto a auditoria. As vagas afirmações de "encriptação de ponta a ponta" sem detalhes técnicos são um sinal de alerta.

Como anonym.legal Implementa o Zero Conhecimento

O início de sessão de zero conhecimento do anonym.legal usa:

  • Derivação de chave Argon2id: 64 MB de memória, 3 iterações — a escolha da OWASP para aplicações de alta segurança
  • Encriptação AES-256-GCM: Executada inteiramente no seu browser ou aplicação de desktop antes de qualquer conteúdo ser enviado
  • Frase de recuperação BIP39 de 24 palavras: A única forma de restaurar o acesso — não armazenada pelo anonym.legal
  • Zero acesso a chaves do lado do servidor: Os servidores do anonym.legal recebem apenas texto cifrado AES-256-GCM que não podem decifrar

Uma violação completa do servidor do anonym.legal produziria apenas blobs encriptados. Sem a chave de cada utilizador — que existe apenas no seu dispositivo — esses blobs são inúteis.

Consulte a nossa visão geral de segurança e conformidade e documentação de conformidade para todos os detalhes.

A Lista de Verificação do Fornecedor

Quando escolhe uma ferramenta na nuvem para registos sensíveis, faça estas perguntas:

Perguntas de arquitetura:

  • Onde ocorre a encriptação — no seu dispositivo ou no servidor do fornecedor?
  • Quem cria as chaves?
  • Onde são armazenadas as chaves?
  • O fornecedor pode entregar cópias em texto simples do seu conteúdo em resposta a uma intimação?
  • O que acontece aos seus ficheiros se o fornecedor for adquirido?

Perguntas de resiliência a violações:

  • Se o sistema do fornecedor for completamente comprometido, quais registos ficam expostos?
  • Se um funcionário do fornecedor agir de forma maliciosa, que conteúdo pode ver?
  • Se um ataque à cadeia de fornecimento atingir o fornecedor, o que fica exposto?

Perguntas regulatórias:

  • O fornecedor pode mostrar documentação para o artigo 25 do RGPD?
  • Um auditor externo examinou o sistema?
  • Existe uma certificação ISO 27001 ou SOC 2 que cobre a encriptação?

Qualquer fornecedor que não possa responder "zero — o conteúdo é encriptado antes de sair do seu dispositivo" às perguntas de violação está a usar encriptação do lado do servidor. Consulte as nossas perguntas frequentes e glossário para mais definições.

O Caso de Uso: Due Diligence de uma Seguradora de Saúde Alemã

Um responsável de conformidade numa grande seguradora de saúde alemã (Krankenkasse) precisava de uma ferramenta de anonimização na nuvem. A tarefa: processar registos de reclamações de segurados. O DPO tinha quatro requisitos:

  • O fornecedor não pode aceder a registos de segurados
  • Sem processamento fora da Alemanha
  • Medidas técnicas do artigo 32 do RGPD documentadas
  • O risco de violação reportável à APD está minimizado

Um grande SaaS de anonimização americano falhou no primeiro ponto. A equipa de suporte podia redefinir os cofres dos utilizadores — prova de acesso a chaves do lado do servidor. Uma segunda ferramenta guardava texto processado durante 30 dias para "trilha de auditoria" — novamente, acesso do lado do servidor.

O anonym.legal cumpriu todos os quatro critérios. O DPO pôde escrever: "Mesmo uma violação completa do fornecedor não produz registos utilizáveis de segurados — as chaves existem apenas nas nossas estações de trabalho." A documentação do artigo 32 do RGPD foi concluída em quatro horas.

Veja os nossos estudos de caso para mais exemplos reais.

O Precedente de Aplicação do ICO

Em dezembro de 2025, o Gabinete do Comissário de Informação do Reino Unido multou a entidade LastPass UK em £1,2 milhões. A razão: "falha em implementar medidas técnicas e organizativas de segurança adequadas."

A multa não foi pela violação em si. Foi pelas decisões de arquitetura que a tornaram tão prejudicial. Configurações KDF inadequadas, metadados expostos e armazenamento de chaves do lado do servidor desempenharam um papel.

Os reguladores agora perguntam: o sistema limitou o impacto da violação? A arquitetura de zero conhecimento responde isso claramente. É a melhor prova dessa intenção.

Quando a Arquitetura de Zero Conhecimento Não É a Solução Certa

A encriptação de zero conhecimento tem compromissos. Estes importam para alguns casos de uso:

Complexidade de recuperação: Se os utilizadores perderem as suas chaves, os seus ficheiros desaparecem para sempre. Não há porta traseira. Alta rotatividade de pessoal ou maus hábitos de gestão de chaves tornam isto um risco real.

Fricção de colaboração: O conteúdo encriptado só pode ser partilhado se a outra parte tiver as ferramentas de desencriptação corretas. Isto é mais lento do que uma simples partilha de link em aplicações de nuvem padrão.

Casos limite regulatórios: Algumas regiões exigem o acesso das autoridades a registos por ordem judicial. Os sistemas de zero conhecimento bloqueiam isto por design. Isso pode causar problemas legais em serviços financeiros ou telecomunicações, onde se aplicam obrigações de intercetação legal.

Sobrecarga computacional: A derivação de chave Argon2id e a encriptação AES-256-GCM adicionam ambas latência. Isto importa mais para o processamento em tempo real de alto volume.

Para equipas que processam milhões de documentos por dia, uma abordagem híbrida pode funcionar melhor. Encripte apenas os campos mais sensíveis. Mantenha os metadados acessíveis. Consulte os planos de preços para níveis de volume.

Conclusão

"Encriptamos os seus ficheiros" não é uma promessa de segurança. É uma frase de marketing que precisa de escrutínio.

As perguntas reais são simples. Quem detém as chaves? Onde ocorre a encriptação? O que fica exposto se os sistemas do fornecedor forem comprometidos?

Para equipas que processam registos sensíveis sob RGPD, HIPAA ou regras semelhantes, estas escolhas de arquitetura moldam tanto o seu risco legal como a sua exposição real a violações.

A LastPass encriptou o conteúdo dos seus utilizadores. A arquitetura de zero conhecimento teria tornado a violação de 2022 um não-evento. Os 438 milhões de dólares roubados dos utilizadores foram o custo de um atalho arquitetónico.


O anonym.legal usa arquitetura de zero conhecimento para anonimização de PII. A derivação de chave Argon2id é executada no seu browser ou aplicação de desktop. A encriptação AES-256-GCM ocorre antes de qualquer conteúdo sair do seu dispositivo. Os servidores do anonym.legal armazenam apenas texto cifrado que não conseguem decifrar. Saiba mais na nossa página sobre nós ou explore o sistema de tokens.

Fontes

Pronto para proteger seus dados?

Comece a anonimizar PII com mais de 285 tipos de entidades em 48 idiomas.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.