Partilha de Ficheiros Zero-Trust: Não Confie em Ninguém, Encripte Tudo
Aplique princípios de segurança zero-trust à partilha de ficheiros. Porque assumir que cada rede é hostil leva a uma melhor encriptação e transferências mais seguras.
A partilha de ficheiros zero-trust parte de três premissas: a rede é hostil, o servidor pode estar comprometido e o dispositivo do destinatário pode estar infetado — e encripta em conformidade. Os ficheiros são encriptados no browser do remetente com AES-256-GCM antes de qualquer byte sair para a rede, as chaves derivam de uma palavra-passe mais um salt guardado no fragmento do URL, e o servidor lida apenas com texto cifrado opaco. Este é o modelo operacional codificado na NIST SP 800-207 aplicado à transferência de ficheiros: verificar explicitamente, conceder o mínimo de privilégios e assumir sempre que existe uma violação em cada camada.
As três premissas que moldam o design
Zero trust começa com três suposições. Primeiro, o transporte está comprometido — proxies empresariais fazem inspeção TLS, o Wi-Fi de cafés corre ataques ARP spoofing, e existem interceções de backbones de operadoras documentadas (documentadas por Snowden em 2013, ainda em funcionamento segundo relatórios de 2024). Segundo, o servidor pode estar comprometido — fornecedores de cloud sofrem violações (AWS em 2019, Microsoft em 2023), administradores tornam-se desonestos, e intimações chegam discretamente. Terceiro, o dispositivo do destinatário pode estar infetado — um portátil corporativo corre um Chrome desatualizado, e malware recolhe ficheiros já desencriptados. Todas as decisões de design nascem destas três premissas.
Encriptação no lado do cliente como primeiro princípio
Se o servidor consegue ver o texto em claro, não é zero trust. Tudo começa com o browser do remetente a executar a Web Crypto API: gerar uma chave de 256 bits, derivá-la da palavra-passe do utilizador com PBKDF2 em 600 000 iterações, encriptar o ficheiro com AES-256-GCM, e só depois enviar o texto cifrado para o servidor. O Firefox Send provou que isto funcionava à escala de consumidor antes de a Mozilla o encerrar em 2020. Sucessores modernos — HexaTransfer, Wormhole, Skiff — adotam o mesmo padrão. O servidor guarda bytes que não consegue ler.
Material de chave que nunca abandona os pontos terminais
A chave de desencriptação tem de chegar ao destinatário sem passar pelo servidor. Dois mecanismos funcionam. Primeiro, o truque do fragmento de URL: a chave vive depois de # no URL de transferência, que os browsers nunca enviam nos pedidos HTTP. Segundo, chaves derivadas de palavra-passe: o remetente comunica ao destinatário uma palavra-passe por um canal separado (Signal, chamada telefónica, 1Password Psst!), e o browser do destinatário re-deriva a chave. Ambos mantêm o material de chave fora dos registos do servidor, das caches de CDN e das cópias de segurança de base de dados — o que conta quando a violação inevitável acontecer.
Verificar o código que corre no browser
Zero trust no cliente é mais difícil do que no servidor porque o servidor serve o JavaScript que faz a encriptação. Um servidor malicioso poderia enviar um bundle com backdoor para um utilizador específico e visado. Medidas de mitigação: publicar hashes SHA-384 de cada versão, assiná-las com Sigstore ou uma chave PGP corporativa, e encorajar utilizadores avançados a verificar com extensões de browser como o Code Verify (a Meta distribui isto para o WhatsApp Web). Cabeçalhos CSP com script-src 'self' e Subresource Integrity bloqueiam injeções de CDNs comprometidos. Nada disto é perfeito, mas reduz a superfície de ataque.
Autenticação sem segredos partilhados guardados em repouso
Palavras-passe enviadas por email e guardadas em bases de dados do servidor são o oposto de zero trust. Substitua-as por passkeys WebAuthn ligadas ao dispositivo do destinatário — a chave privada nunca abandona o Secure Enclave, e o servidor guarda apenas a chave pública. Para transferências pontuais, use OPAQUE (RFC 9380) para autenticação por palavra-passe que nunca transmite nem guarda a palavra-passe do lado do servidor. Ligações mágicas enviadas para endereços de email previamente verificados oferecem um caminho intermédio: a entropia do token (128 bits) substitui a necessidade de um segredo guardado.
Segmentar transferências por sensibilidade
Nem todos os ficheiros merecem os mesmos controlos. Um serviço de partilha de ficheiros zero-trust deve permitir que os remetentes classifiquem os envios: público (sem palavra-passe, expiração em 7 dias), interno (palavra-passe, expiração em 48 horas), confidencial (palavra-passe + 2FA, expiração em 4 horas, transferência única), restrito (passkey + ligação a IP + expiração em 15 minutos). Automatize a classificação por tipo de ficheiro sempre que possível: declarações de IRS em .pdf → confidencial; contratos em .docx → interno; composições de marketing em .psd → público. A NIST SP 800-171 trata isto como informação não classificada controlada, e enquadra-se bem nos fluxos de trabalho de transferência.
Tratar o dispositivo do destinatário como não confiável
Assim que o destinatário desencripta um relatório jurídico de 5 MB, o ficheiro fica na pasta Transferências dele. Se o portátil estiver comprometido, o ficheiro vaza. O pensamento zero-trust estende-se aqui: incentive os destinatários a desencriptar para armazenamento efémero (Tails OS, uma sessão de convidado no Chrome OS), evitar desencriptar em máquinas partilhadas, e eliminar de forma assertiva após uso. Para transferências de alto risco, use visualizadores protegidos que desencriptam para um separador de browser isolado e impedem a transferência do ficheiro — o destinatário vê o .pdf mas nunca obtém os bytes no disco. Obviamente isto penaliza a experiência de utilizador; reserve para o nível mais sensível.
Registos sem se tornar num sistema de vigilância
Uma trilha de auditoria zero-trust regista o que é necessário para resposta a incidentes e conformidade, nada mais. Faça hash dos endereços IP diariamente, guarde apenas famílias de User-Agent (não strings completas), nunca registe palavras-passe ou chaves, e retenha pelo período mínimo exigido por cada regulação — 90 dias para efeitos do Artigo 30.º do RGPD, 6 anos para HIPAA 164.316. O próprio registo vive em armazenamento só de acréscimo (S3 Object Lock, modo de conformidade) para que um administrador comprometido não possa encobrir os seus rastos. Publicar raízes Merkle diariamente num boletim público adiciona verificação externa.
Onde o zero trust encontra a realidade jurídica
Zero trust não o isenta de pedidos das autoridades. Muda o que pode entregar — texto cifrado que não consegue desencriptar, hashes de IP que não consegue inverter, registos de quem acedeu a que slug. Isso normalmente é suficiente para satisfazer um mandado válido enquanto mantém os dados dos utilizadores privados de vigilância em massa. Publique um relatório de transparência mostrando volumes de pedidos e taxas de resposta. Documente a minimização de dados na política de privacidade para que os utilizadores compreendam as trocas: pode verificar que uma transferência aconteceu, mas não consegue ler o conteúdo nem identificar o destinatário com certeza.
Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.
Envie arquivos grandes com segurança e criptografia de ponta a ponta
Transfira arquivos de até 10 GB gratuitamente com criptografia de ponta a ponta. Sem necessidade de conta. Seus arquivos são criptografados no navegador antes do envio — ninguém mais pode lê-los.
Enviar um arquivo