Criptografia em repouso vs em trânsito: ambas são necessárias

A encriptação em trânsito protege os dados enquanto se deslocam entre dois pontos — o seu navegador e um servidor, por exemplo — usando TLS 1.3 com AES-256-GCM ou ChaCha20-Poly1305. A encriptação em repouso protege os dados guardados em disco, tipicamente com AES-256-XTS para encriptação completa do disco ou AES-256-GCM por ficheiro. Nenhuma delas é suficiente por si só. O TLS protege contra interceção na rede mas desencripta no servidor; a encriptação em repouso protege os dados armazenados mas é inútil se as chaves ficarem junto ao texto cifrado. A segurança real vem de combinar ambas, idealmente com encriptação do lado do cliente (ponta a ponta) para que o servidor nunca veja o texto simples.

Duas ameaças distintas, dois controlos distintos

As ameaças são diferentes consoante onde os dados se encontram:

Em trânsito (caminho de rede): um atacante numa cafetaria a correr um sniffer de pacotes, um router ISP comprometido, um estado-nação a intercetar cabos submarinos. Os documentos Snowden de 2013 revelaram o programa MUSCULAR da NSA a intercetar as ligações internas de fibra do Google. Defesa: TLS 1.3, preferencialmente com certificate pinning nas aplicações.

Em repouso (armazenamento): um portátil roubado, uma fita de cópia de segurança vazada, um bucket S3 mal configurado, um funcionário desonesto de um datacenter com acesso aos discos. A violação de dados da Equifax em 2017 expôs 147 milhões de registos, em parte porque os dados estavam armazenados sem encriptação. Defesa: LUKS, BitLocker, FileVault para discos; AES-256-GCM ou AES-256-XTS por ficheiro ou por bloco.

O erro mais comum é tratar uma como substituta da outra. O TLS não protege uma exportação de base de dados. A encriptação do disco não impede um ataque man-in-the-middle.

Como o TLS 1.3 protege os dados em trânsito

O TLS 1.3, padronizado na RFC 8446 (2018), é o padrão moderno. Utiliza:

Sigilo de encaminhamento por defeito através de troca de chaves ECDHE efémera. Mesmo que a chave de longa duração do servidor vaze, as sessões anteriores ficam protegidas.
Apenas cifras AEAD — AES-128-GCM, AES-256-GCM, ou ChaCha20-Poly1305. Os antigos modos CBC e RC4 foram eliminados.
Handshake de uma única viagem (1-RTT), ou zero viagens (0-RTT) para retoma de sessão.
Handshake encriptado para que observadores passivos não possam ver a cadeia de certificados.

Todos os serviços de transferência de ficheiros respeitáveis — WeTransfer, SwissTransfer, Tresorit, Proton Drive, HexaTransfer — correm TLS 1.3 com cabeçalhos HSTS a impor HTTPS durante pelo menos 12 meses. Pode verificar com a ferramenta testssl do SSL Labs; qualquer pontuação abaixo de A- indica problemas de configuração.

Como funciona a encriptação em repouso no servidor

Assim que os ficheiros chegam e o TLS termina, a encriptação em repouso assume o controlo. Existem várias camadas:

Ao nível do bloco (disco completo): AES-256-XTS em LUKS (Linux), BitLocker (Windows), FileVault (macOS), ou equivalentes em nuvem como a encriptação AWS EBS. Protege contra discos roubados.
Ao nível do sistema de ficheiros: eCryptfs, Fscrypt em ext4/F2FS. Os ficheiros de cada utilizador encriptados com chaves separadas.
Ao nível do armazenamento de objetos: AWS S3 SSE-KMS, Azure Blob com Storage Service Encryption, Google Cloud Storage com chaves geridas pelo cliente. Cada objeto encriptado com AES-256-GCM.
Ao nível da aplicação: o serviço encripta cada ficheiro no seu próprio código antes de escrever no armazenamento, com chaves guardadas num KMS ou HSM.

O nível de aplicação é o mais forte porque a encriptação ocorre antes de qualquer sistema de armazenamento ver os dados. O AWS KMS cobra 1 $/chave/mês mais 0,03 $ por 10 000 pedidos — barato o suficiente para que serviços sérios o usem por ficheiro.

A armadilha das "chaves junto ao texto cifrado"

É aqui que a encriptação em repouso falha com mais frequência. Se as chaves estiverem guardadas no mesmo servidor que o texto cifrado, um atacante que comprometa o servidor obtém ambos. O fornecedor pode tecnicamente assinalar a caixa "encriptado em repouso" para fins de conformidade sem oferecer qualquer proteção real contra comprometimento do servidor.

Boas arquiteturas separam as preocupações:

Texto cifrado no S3 ou armazenamento de objetos equivalente.
Chaves de encriptação no AWS KMS, Google Cloud KMS, Azure Key Vault, ou num HSM dedicado.
Acesso às chaves controlado por credenciais IAM de curta duração e registos de auditoria.

As melhores arquiteturas vão mais longe: as chaves nunca existem no servidor. A encriptação do lado do cliente (E2EE) significa que o navegador do utilizador gera a chave, encripta o ficheiro, e guarda a chave. O servidor armazena texto cifrado e não tem nada a revelar.

Onde surgem lacunas na encriptação

Mesmo com ambos os controlos ativos, os dados ficam brevemente em texto simples em vários momentos:

Na memória do servidor durante o processamento do carregamento, análise antivírus, ou geração de miniaturas. Um despejo de memória nessa janela revela texto simples.
Nos registos de acesso se nomes de ficheiros ou fragmentos de conteúdo forem registados para depuração.
Nas fitas de cópia de segurança se as cópias de segurança não herdarem a mesma encriptação.
Durante a compressão ou transcodificação onde o serviço processa o conteúdo dos ficheiros.
Na cache do navegador após o descarregamento, se o utilizador não a limpar.

Estas lacunas são a razão pela qual a encriptação de conhecimento zero (do lado do cliente) importa. Quando os ficheiros são encriptados no navegador antes do carregamento, as lacunas do lado do servidor tornam-se irrelevantes — o servidor só vê texto cifrado.

O que os grandes serviços fazem na prática

Uma classificação aproximada com base em documentação pública:

Google Drive, Dropbox, OneDrive: TLS 1.3 em trânsito, AES-256 em repouso com chaves do fornecedor. Não são de conhecimento zero — o fornecedor pode ler os seus ficheiros.
WeTransfer (nível gratuito): TLS 1.3, AES-256 em repouso no AWS S3. O fornecedor guarda as chaves.
Box Enterprise: TLS 1.3, AES-256-GCM em repouso, com opção de chaves geridas pelo cliente (Box KeySafe).
Tresorit, Proton Drive, SwissTransfer E2EE, HexaTransfer: TLS 1.3 em trânsito, AES-256-GCM em repouso, mas as chaves por ficheiro são geradas pelo cliente e nunca chegam ao servidor. Efetivamente de conhecimento zero.

Para dados sensíveis, apenas a última categoria oferece proteção significativa contra ameaças internas e pedidos legais válidos.

Conformidade e o mandato de "defesa em profundidade"

Os reguladores exigem explicitamente ambas as camadas:

Artigo 32.º do RGPD impõe "pseudonimização e encriptação de dados pessoais" sem restrição ao estado em que os dados se encontram.
HIPAA Security Rule 45 CFR § 164.312(a)(2)(iv) e (e)(2)(ii) exige encriptação para ePHI tanto em trânsito como em repouso.
PCI DSS 4.0 Requisitos 3 e 4 separa "proteger dados de titulares de cartões armazenados" (em repouso) de "proteger dados de titulares de cartões com criptografia robusta durante a transmissão" (em trânsito).
FIPS 140-3 a validação aplica-se a módulos criptográficos usados em ambos os contextos.

Fornecer apenas uma delas é uma falha de conformidade antes mesmo de ser uma falha de segurança.

Como verificar se ambas estão ativas

Cinco verificações rápidas para qualquer serviço de transferência de ficheiros:

Execute testssl.sh https://fornecedor.com para confirmar TLS 1.3 apenas com cifras robustas.
Verifique os cabeçalhos HSTS com max-age de pelo menos 31 536 000 (um ano).
Leia o whitepaper de segurança para menção explícita de AES-256-GCM ou AES-256-XTS em repouso.
Confirme que as chaves estão num KMS ou HSM, não na base de dados da aplicação.
Procure certificação SOC 2 Type II ou ISO 27001 — ambas exigem controlos documentados em repouso e em trânsito.

Bónus: verifique se a encriptação do lado do cliente está disponível. Se sim, ative-a para qualquer conteúdo sensível.

Como combinar corretamente as duas camadas

O padrão que realmente funciona:

O navegador encripta o ficheiro com uma chave AES-256-GCM aleatória (lado do cliente).
O texto cifrado viaja por TLS 1.3 até ao servidor (em trânsito).
O servidor armazena o texto cifrado em armazenamento encriptado AES-256 (em repouso).
A chave de desencriptação vive apenas no fragmento do URL de partilha, nunca enviada ao servidor.

Três camadas independentes. Comprometa uma, as outras aguentam. Este é o design usado pelo HexaTransfer, assim como pelo Tresorit Send, pelas ligações de partilha do Proton Drive, e pelo modo E2EE do SwissTransfer.

Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.