Índice
- O que «armazenamento na cloud cifrado» significa realmente
- Conhecimento zero vs no servidor: quem detém as chaves
- Os modelos de ameaça que cada desenho defende
- Jurisdição e metadados: a parte que o marketing salta
- Os verdadeiros compromissos do conhecimento zero
- Onde se encaixam os fornecedores E2E: Internxt e Proton Drive
- Um quadro de decisão para programadores
O que «armazenamento na cloud cifrado» significa realmente
«Cifrado» é uma das palavras mais sobrecarregadas do mercado de armazenamento. Quase todos os fornecedores podem afirmar honestamente que o seu serviço é cifrado, porque alguma camada o é — e a camada que importa raramente é a da página de marketing.
Todo o produto de armazenamento na cloud tem três camadas de cifragem distintas, que protegem contra coisas completamente diferentes:
- Cifragem em trânsito — o TLS protege os bytes que viajam entre o teu dispositivo e o servidor. Isto trava um bisbilhoteiro de rede. Todo o fornecedor sério o faz; é um requisito mínimo, não uma funcionalidade.
- Cifragem em repouso — os dados nos discos do fornecedor estão cifrados, normalmente com AES-256. Isto protege contra o roubo físico de um disco do centro de dados. Mas o fornecedor detém a chave, por isso não faz nada contra o fornecedor, uma intimação ou uma intrusão que alcance o cofre de chaves.
- Cifragem ponta a ponta / conhecimento zero — os dados são cifrados no teu dispositivo com uma chave que só tu controlas, antes mesmo de chegarem ao servidor. O fornecedor guarda texto cifrado que não consegue ler.
Quando um programador atento à privacidade pede «armazenamento na cloud cifrado», pensa quase sempre na terceira camada. Quando um fornecedor de massas anuncia «os teus dados estão cifrados», refere-se quase sempre às duas primeiras. Essa lacuna é todo o tema deste artigo.
Conhecimento zero vs no servidor: quem detém as chaves
A única pergunta que separa os dois mundos é: quem consegue decifrar os teus ficheiros sem a tua cooperação?
Cifragem no servidor (convencional). O fornecedor gera e guarda as chaves de cifragem. Os teus ficheiros estão cifrados em repouso, mas o mesmo sistema que guarda o texto cifrado guarda também o meio de o decifrar. É o modelo por trás da experiência predefinida do Dropbox, Google Drive, OneDrive e da maioria dos armazenamentos na cloud de consumo. A vantagem é a comodidade: o servidor pode indexar os teus ficheiros para pesquisa, mostrar pré-visualizações, executar análises antivírus, alimentar a edição colaborativa e repor a tua palavra-passe sem perda de dados. O custo é que o fornecedor — e qualquer um que possa alcançar legal ou ilegalmente o seu cofre de chaves — consegue ler tudo.
Cifragem de conhecimento zero (ponta a ponta). A chave é derivada da tua palavra-passe no teu dispositivo através de uma função de derivação de chave como Argon2 ou PBKDF2. O texto simples é cifrado localmente; só texto cifrado é carregado. O fornecedor guarda uma cópia cifrada do teu material de chaves, envolvida por uma chave que por sua vez vem da tua palavra-passe, por isso o conjunto guardado é inútil sem ti. O fornecedor, portanto, não consegue ler os teus ficheiros, não consegue produzir texto simples em resposta a uma intimação, e não consegue repor a tua palavra-passe sem que percas o acesso. O termo «conhecimento zero» descreve exatamente isto: o serviço tem zero conhecimento do teu texto simples.
A criptografia aqui não é exótica — é o mesmo padrão de cifragem por envelope usado dentro dos gestores de palavras-passe como os tratados no nosso guia de gestores de palavras-passe em CLI para programadores. O que difere entre fornecedores é a disciplina de implementação: qual KDF, qual cifra, se os nomes de ficheiros e a estrutura de pastas também são cifrados, e se o cliente é de código aberto para que a promessa seja verificável em vez de acreditada.
Os modelos de ameaça que cada desenho defende
Escolher um modelo de cifragem é, na verdade, escolher um modelo de ameaça. Faz corresponder o teu adversário ao desenho, não o contrário.
| Ameaça | Em repouso (no servidor) | Conhecimento zero (E2E) |
|---|---|---|
| Bisbilhoteiro de rede | Defendido (TLS) | Defendido (TLS) |
| Disco roubado do centro de dados | Defendido | Defendido |
| O fornecedor lê os teus ficheiros | Não defendido | Defendido |
| Funcionário mal-intencionado | Não defendido | Defendido |
| Intimação para o conteúdo | Não defendido | Defendido (sem texto simples para dar) |
| Intrusão que alcança o cofre de chaves | Não defendido | Defendido (chaves nunca utilizáveis no servidor) |
| Esqueces a tua palavra-passe | O fornecedor pode recuperar | Irrecuperável por desenho |
| Malware no teu próprio dispositivo | Não defendido | Não defendido (o texto simples existe localmente) |
Duas linhas merecem ênfase. O conhecimento zero não te protege de malware na tua própria máquina — assim que decifras localmente, o texto simples está nas tuas mãos e na tua RAM, por isso a higiene do endpoint continua a importar. E o conhecimento zero transfere para ti o risco de recuperação de palavra-passe: a incapacidade do fornecedor de ler os teus dados é a mesma propriedade que torna irrecuperável uma palavra-passe esquecida. É uma funcionalidade, mas uma funcionalidade com um gume afiado.
Jurisdição e metadados: a parte que o marketing salta
A cifragem protege o conteúdo. Por si só não protege os metadados — e os metadados muitas vezes bastam.
Mesmo um serviço de conhecimento zero perfeitamente implementado tem de funcionar. Conhece o email da tua conta (registaste-te com ele), os teus endereços IP no início de sessão, o teu volume de armazenamento, os tamanhos dos ficheiros, as marcas temporais de carregamento e — consoante a implementação — os nomes de ficheiros e pastas. Alguns desenhos E2E cifram também os nomes dos ficheiros; muitos não. Os metadados geralmente não estão cobertos pela garantia de conhecimento zero, e são precisamente o que é intimado primeiro.
Aqui regressa a jurisdição. O regime jurídico de um fornecedor determina que metadados podem ser exigidos e sob que processo. O CLOUD Act dos EUA (2018) permite às autoridades norte-americanas obrigar as empresas americanas a produzir dados guardados em qualquer parte do mundo. O RGPD da UE e a revista Lei Federal de Proteção de Dados da Suíça (LPD, em vigor desde setembro de 2023) impõem condições mais rigorosas à divulgação. É a mesma lógica jurisdicional que tratámos para o email em email auto-hospedado vs ProtonMail vs Fastmail e mais amplamente em soberania de dados: onde um serviço está constituído é uma variável técnica primária, não uma nota de rodapé.
A conclusão prática: combina uma cifragem de conteúdo sólida com um fornecedor numa jurisdição respeitadora da privacidade, e parte do princípio de que os teus metadados estão visíveis para um processo legal suficientemente motivado, aconteça o que acontecer.
Os verdadeiros compromissos do conhecimento zero
O armazenamento de conhecimento zero não é isento de atrito. Ser honesto sobre os custos é a única forma de escolher bem.
A pesquisa e as pré-visualizações degradam-se. Como o servidor só guarda texto cifrado, não consegue construir um índice de texto completo dos teus documentos nem renderizar pré-visualizações e miniaturas no servidor como o Google Drive faz. Os fornecedores E2E pesquisam no cliente (depois de o teu dispositivo decifrar um índice) ou limitam a pesquisa aos nomes dos ficheiros. Para uma pasta de milhares de documentos, a diferença é notável.
A colaboração é mais difícil. A edição colaborativa em tempo real, a que tornou o Google Docs omnipresente, precisa fundamentalmente de um servidor capaz de ler e fundir o estado do documento. Os desenhos de conhecimento zero conseguem colaborar, mas de forma mais limitada e com implementações mais jovens.
Partilhar com não utilizadores exige troca de chaves. Enviar um ficheiro cifrado a alguém fora do serviço implica transmitir uma chave de decifragem por um canal separado, ou usar uma função do fornecedor que gera um link protegido por palavra-passe. Funciona, mas é um passo que os serviços convencionais escondem.
A recuperação de palavra-passe é da tua conta. Vale a pena repetir porque é a forma mais comum de perder dados nestes serviços. Guarda a chave de recuperação que o fornecedor te dá no registo, armazena-a num lugar durável e offline, e usa uma palavra-passe forte e única. Todo o modelo de segurança assenta nessa palavra-passe.
Nenhum destes pontos é uma razão para evitar o armazenamento de conhecimento zero — são razões para o usar deliberadamente, para os dados que o justificam, em vez de como substituto universal de todos os fluxos de trabalho.
Onde se encaixam os fornecedores E2E: Internxt e Proton Drive
Dois fornecedores surgem repetidamente nas comparações focadas na privacidade porque entregam clientes de código aberto e cifragem ponta a ponta por predefinição, e não como extra pago ou modo só para empresas.
Internxt é um fornecedor sediado na UE (Espanha) que oferece armazenamento na cloud de conhecimento zero, cifrado ponta a ponta, com clientes de código aberto e um plano gratuito. O seu posicionamento é uma suíte completa de privacidade (drive, mais ferramentas de privacidade adjacentes), e a base europeia coloca-o sob o RGPD. Como o cliente é de código aberto, a promessa de conhecimento zero é verificável em vez de afirmada.
Proton Drive é o componente de armazenamento do ecossistema Proton — sediado na Suíça, cifrado ponta a ponta, de código aberto, com um plano gratuito. Se já usas o Proton Mail ou o Proton VPN, o Drive encaixa na mesma conta e na mesma jurisdição suíça, tornando-o uma forma natural de manter ficheiros cifrados ao lado de um email cifrado. O mesmo modelo de acesso zero que protege uma caixa Proton protege os ficheiros do Drive.
Nenhum é uma resposta universal. São a ferramenta certa quando precisas especificamente de que o fornecedor seja incapaz de ler os teus dados, e aceitas em troca os compromissos de pesquisa/colaboração.
Um quadro de decisão para programadores
Para de perguntar «qual é o armazenamento na cloud mais seguro» e começa a perguntar «o que são estes dados, e quem não os pode ler?»
Usa armazenamento convencional (Drive/Dropbox/OneDrive) quando: precisas de pesquisa de texto completo rápida nos documentos, colaboração em tempo real, pré-visualizações ricas, e os dados não são suficientemente sensíveis para justificar o atrito. A comodidade é um requisito legítimo.
Usa armazenamento de conhecimento zero (Internxt, Proton Drive) quando: o conteúdo deve permanecer ilegível para o fornecedor — documentos pessoais, arquivos de credenciais, dados de clientes sob NDA, cópias de segurança de projetos sensíveis, qualquer coisa que não quisesses ver produzida sob intimação. Aceita que a pesquisa é local e que partilhar precisa de uma chave.
Para código-fonte: continua a usar Git numa forge pelo fluxo de trabalho; usa o armazenamento cifrado para cópias de segurança de repositórios, ficheiros binários grandes e artefactos de build que não queres que um terceiro indexe. Não ponhas segredos ativos em ficheiros em bruto em nenhum armazenamento — usa um gestor de segredos dedicado ou um cofre cifrado.
Escolhas o que escolheres, verifica a promessa. Prefere clientes de código aberto para que a cifragem seja auditável, prefere uma jurisdição respeitadora da privacidade para que os metadados sejam mais difíceis de exigir, e guarda a tua chave de recuperação no momento em que te registas num serviço de conhecimento zero. A criptografia mais forte do mundo é desfeita por uma palavra-passe esquecida sem via de recuperação.
Para o contexto mais amplo de manter os teus dados fora dos serviços sob jurisdição dos EUA, vê o nosso pilar sobre soberania de dados e o guia prático de migração em alternativas ao Google.
