Criptografia no cliente vs no servidor para uploads

Por que as escolhas de criptografia importam para documentos enviados

Se seu app permite que pessoas enviem arquivos, você não está apenas armazenando “documentos”. Frequentemente está guardando uma segunda identidade do usuário: contratos assinados, fotos de passaporte ou carteira de motorista, formulários médicos e resultados de laboratório. Os arquivos são pequenos. O risco associado a eles não é.

Um contrato vazado pode provocar consequências legais e financeiras: preços se tornam públicos, assinaturas são copiadas e disputas ficam feias rapidamente. Um scan de documento de identidade roubado pode levar a roubo de identidade e tomada de contas. Documentos médicos podem expor detalhes de saúde privados que as pessoas nunca pensaram em compartilhar além de um círculo pequeno. Um erro pode destruir confiança por anos.

Equipes frequentemente dizem “armazenamento criptografado” querendo dizer coisas diferentes. Às vezes querem dizer que a conexão de upload é criptografada (HTTPS). Às vezes querem dizer que o arquivo está criptografado no disco (criptografia em repouso). Às vezes querem dizer que o arquivo é criptografado antes de sair do dispositivo do usuário, de modo que o servidor nunca veja o texto claro (criptografia no cliente). Essas coisas não são intercambiáveis. Elas protegem contra falhas diferentes.

As escolhas de segurança também moldam a usabilidade e o suporte diário. Mais privacidade pode significar mais atrito: passos extras para ver um arquivo, compartilhamento mais difícil, busca e pré‑visualizações limitadas, e uma recuperação dolorosa quando alguém perde um dispositivo ou chave. Acesso mais fácil permite indexação, varredura antivírus, pré‑visualizações e resets de senha, mas também aumenta o que seu servidor (e quem o comprometer) pode ver.

Imagine uma pequena clínica enviando IDs de seguro e PDFs médicos. A equipe precisa encontrar o arquivo certo rapidamente, mas a clínica também quer reduzir o dano caso uma conta administrativa seja invadida. O modelo “certo” depende do que mais dói em caso de falha e do quanto de inconveniência os usuários tolerarão.

Definições rápidas: criptografia no cliente vs no servidor

A pergunta prática é simples: quando o arquivo é criptografado, e quem pode descriptografá‑lo depois?

Criptografia no servidor significa que o arquivo chega ao seu backend em forma legível, e seu servidor o criptografa antes de salvar. Isso é criptografia em repouso: se alguém roubar um disco ou obtiver acesso bruto a um bucket de armazenamento, verá dados embaralhados. Seu servidor ainda pode descriptografar o arquivo quando necessário.

Criptografia no cliente significa que o arquivo é criptografado no dispositivo do usuário (navegador ou móvel) antes do upload. Seu servidor armazena apenas o texto cifrado. Em operação normal, o servidor não consegue ler o documento a menos que também tenha acesso à chave de descriptografia.

A posse da chave é a verdadeira linha divisória:

• Com criptografia no servidor, as chaves são gerenciadas pelo seu backend (frequentemente via um serviço de gerenciamento de chaves), e o backend descriptografa arquivos para usuários autorizados.
• Com criptografia no cliente, as chaves são controladas pelo usuário, seu dispositivo ou um segredo mantido pelo cliente, e o backend atua principalmente para armazenar e aplicar regras de acesso.

Em ambos os modelos, você ainda precisa de autenticação e permissões. Criptografia não substitui controle de acesso.

Pessoas também usam “criptografia ponta a ponta” para significar: o arquivo é criptografado no dispositivo do remetente, permanece criptografado no servidor e é descriptografado apenas no dispositivo do destinatário aprovado. Isso pode melhorar a confidencialidade, mas torna pré‑visualização no servidor, busca em texto, varredura antivírus e recuperação fácil muito mais difíceis, a menos que você aceite mudar o modelo de ameaça.

Modelos de ameaça: contra o que você realmente está tentando se proteger

A criptografia só ajuda quando você está claro sobre os riscos que quer reduzir. “Ninguém exceto o usuário pretendido pode ler o arquivo” leva a escolhas diferentes de “reduzir o dano se o armazenamento for vazado.”

Ameaças comuns para apps que armazenam contratos, IDs ou documentos médicos incluem:

• Senhas roubadas ou reutilizadas (tomada de conta)
• Acesso interno mais amplo do que deveria ser (suporte, admin, contratados)
• Conta de nuvem comprometida ou bucket de armazenamento mal configurado
• Um bug ou vazamento expondo bancos de dados ou backups
• Malware no dispositivo do usuário

Também ajuda separar onde a exposição pode acontecer:

• Em trânsito: o arquivo se movendo do dispositivo para o servidor
• Em repouso: armazenamento de objetos, linhas de banco de dados, backups, logs
• Durante visualização/processamento: pré‑visualizações, OCR, busca, conversões

Aqui está a diferença central. Com criptografia no servidor, seu sistema pode descriptografar, então pode gerar pré‑visualizações, escanear e indexar. Com criptografia no cliente, o servidor armazena o texto cifrado e não pode ler o conteúdo sem as chaves detidas pelo usuário. Isso normalmente reduz o raio de dano em compromissos de servidor e risco interno.

A criptografia não impede tudo. Se um dispositivo está infectado, o malware pode pegar o arquivo antes da criptografia ou depois da descriptografia. Se alguém consegue ver um documento, ainda pode tirar captura de tela, redistribuir ou imprimir.

O que cada modelo protege (e o que não protege)

Uma forma útil de comparar é perguntar: quem pode ver o arquivo em texto claro em qualquer ponto? Essa resposta molda o impacto de um vazamento, o risco interno e a segurança de backups.

Com criptografia no servidor, uma invasão do servidor ainda pode expor muito. O backend geralmente tem acesso às chaves de descriptografia (ou pode solicitá‑las) porque precisa gerar pré‑visualizações, rodar checks antivírus, suportar busca ou tratar compartilhamentos. No pior cenário, um atacante que consiga tanto os dados armazenados quanto acesso às chaves pode descriptografar tudo.

Com criptografia no cliente, um atacante que invada sua infraestrutura normalmente rouba blobs criptografados. Sem chaves detidas pelo usuário, esses blobs são bem menos úteis.

O acesso interno é onde a diferença fica mais visível. Com criptografia no servidor, um funcionário privilegiado, administrador de nuvem ou conta de suporte comprometida pode frequentemente acessar documentos ao se passar pelo app ou consultando o armazenamento. Com criptografia no cliente, sua infraestrutura pode armazenar e mover arquivos, mas não pode lê‑los a menos que as chaves sejam fornecidas.

A criptografia no cliente não resolve um dispositivo hackeado. Para uploads de alto risco como IDs e PDFs médicos, a segurança do dispositivo e a proteção da conta importam tanto quanto a criptografia do armazenamento.

Também fique atento a vazamentos fora do “repositório de arquivos”. Muitos incidentes acontecem por:

• Backups e snapshots que capturam arquivos descriptografados ou chaves
• Logs que registram nomes de arquivo, metadados ou texto extraído
• Miniaturas, pré‑visualizações e índices de busca
• Exportações para e‑mail, chat ou ferramentas de tickets
• Arquivos temporários criados durante upload ou conversão

Compromissos de UX que os usuários notam imediatamente

A maior diferença não é a matemática. É o que os usuários conseguem fazer facilmente e o que fica difícil.

A criptografia no servidor costuma ser invisível. Usuários fazem login, enviam e veem pré‑visualizações imediatamente. O suporte pode resetar acessos. Supervisores normalmente podem reatribuir permissões quando alguém está ausente.

Criptografia no cliente muda o onboarding e o trabalho diário. Usuários podem precisar de uma frase‑secreta mais forte, de uma chave local armazenada no dispositivo ou de um passo extra para desbloquear. Trocar de dispositivo, limpar o navegador ou reinstalar um app pode quebrar o acesso a menos que você tenha planejado backup e recuperação de chaves.

A recuperação de conta é onde equipes se surpreendem. Se somente o usuário detém a chave de descriptografia, “Esqueci a senha” pode virar “acesso perdido”. Você pode adicionar uma chave de recuperação ou fluxo de custódia, mas precisa ser transparente sobre o que isso implica e explicar claramente aos usuários.

Compartilhar também fica mais complicado. Com criptografia no servidor, compartilhar é maioritariamente sobre permissões. Com criptografia no cliente, compartilhar muitas vezes envolve também compartilhar chaves, além de perguntas sobre revogação e cópias antigas.

Busca e funcionalidades de conveniência podem forçar a descriptografia em algum lugar. Busca em texto completo, pré‑visualizações e OCR são mais fáceis quando o servidor consegue ler o arquivo. Se você quer privacidade no estilo ponta a ponta, talvez precise de OCR no cliente, indexação local ou busca limitada (por exemplo, apenas nomes de arquivo e tags).

Exemplo: uma clínica envia PDFs de laboratório e quer OCR para encontrar nomes de pacientes dentro dos scans. A criptografia no servidor suporta OCR e busca rápidas. A criptografia no cliente empurra esse trabalho para os dispositivos dos usuários, o que pode ser mais lento e difícil de suportar em web e mobile.

Necessidades específicas por documento: contratos, IDs e registros médicos

A melhor escolha depende menos do tipo de arquivo e mais do fluxo de trabalho: quem precisa ler, com que rapidez, com que frequência e por quanto tempo.

Contratos

Contratos frequentemente envolvem revisão, alterações (redlines), aprovações e trilhas de auditoria. Equipes também querem busca confiável, compartilhamento e regras de retenção.

Se seu app suporta revisão colaborativa dentro do produto, a criptografia no servidor costuma ser o padrão prático porque o sistema pode renderizar pré‑visualizações, rodar buscas e aplicar acesso baseado em papéis sem obrigar usuários a gerenciar chaves.

Criptografia no cliente pode servir se o app for mais um cofre, como armazenar PDFs assinados finais para um pequeno grupo executivo. O trade‑off é conveniência reduzida a não ser que você adicione ferramentas do lado do cliente.

IDs (passaportes, carteiras de motorista)

IDs são de alto risco, mas muitas vezes de curta duração. Muitas equipes só precisam deles tempo suficiente para verificar uma pessoa, depois os deletam. O fluxo é visualização rápida e regras rígidas de manuseio, não colaboração.

Uma abordagem comum é criptografia no servidor combinada com controle de acesso estrito, logs fortes e retenção curta. Criptografia no cliente pode servir se o pessoal de suporte nunca devesse ver IDs, mas aí você precisa de outra forma de completar a verificação.

Documentos médicos

Registros médicos têm expectativas de privacidade mais fortes. Usuários frequentemente assumem que apenas o conjunto mínimo de pessoas pode ver.

A criptografia no cliente pode reduzir a exposição se o servidor for violado ou se o acesso administrativo for mal utilizado. Mas também pode criar problemas reais de UX e operação: resets de senha, trocas de dispositivo e acesso de emergência ficam complicados.

Antes de escolher, mapeie cada tipo de documento para o fluxo de trabalho:

• Quem deve lê‑lo (e de onde)
• Quão rápido ele precisa carregar
• Por quanto tempo você o mantém
• Quais funcionalidades do produto importam (pré‑visualização, busca, exclusão automática)

Como escolher: um processo passo a passo

Comece anotando o que você armazena e quem tem acesso. Uma pasta chamada “uploads” não é uma política.

Passo 1: mapeie o acesso, não apenas “usuários”

Liste papéis e responda duas perguntas: quem precisa abrir o arquivo e quem nunca deve abrir (incluindo administradores)? Inclua retenção enquanto faz isso.

Passo 2: escolha suas suposições de ameaça

Seja direto sobre contra o que você está se defendendo.

• Se o risco interno é uma preocupação principal, criptografia no cliente fica mais atraente.
• Se perda de dispositivo e resets de senha são comuns, você pagará esse custo em complexidade de recuperação.

Depois teste a experiência:

1. Recuperação e suporte: O que acontece quando alguém esquece a senha ou perde o telefone? Se você precisa recuperar acesso, criptografia puramente no cliente pode não servir.

2. Funcionalidades essenciais: Você precisa de pré‑visualizações, busca, OCR, assinatura eletrônica ou processamento por API? Muitas dessas são mais simples com descriptografia do servidor em algum ponto do fluxo.

3. Auditoria e conformidade: Você precisa de logs claros de quem acessou o quê e quando? Ambos os modelos podem registrar acessos, mas designs com criptografia no cliente precisam de cuidado extra para evitar um resultado de “não podemos ajudar você”.

A maioria das equipes acaba com um híbrido: criptografia no servidor para a maior parte dos documentos, e criptografia no cliente para um pequeno conjunto de uploads “nunca visíveis à equipe”.

Erros comuns e armadilhas a evitar

A maior armadilha é tratar a criptografia como toda a história. Privacidade e conformidade também dependem de quem pode acessar dados, como o acesso é aprovado, o que é registrado, quanto tempo os arquivos são mantidos e como pedidos de exclusão são tratados.

Um segundo erro comum é construir criptografia no cliente sem plano de recuperação. Se um usuário perde um dispositivo, esquece uma frase‑secreta ou sai da empresa, você consegue restaurar acesso sem quebrar sua promessa de segurança? “Não podemos ajudar” pode ser aceitável para um cofre pessoal, mas geralmente falha em apps empresariais.

Esses erros geram vazamentos e contornos reais:

• Dar a administradores um caminho oculto de “ver tudo”, ou permitir que suporte se passe por usuários, sem logs rígidos e aprovações em segunda pessoa.
• Descriptografar no navegador ou app e deixar cópias para trás (pré‑visualizações em cache, downloads temporários, pastas sincronizadas).
• Enviar documentos “seguros” por canais inseguros depois (enviar PDFs por e‑mail, colar capturas em chat, anexar arquivos a tickets).
• Tornar o fluxo seguro tão difícil que usuários migram para drives pessoais ou tiram fotos da tela.
• Assumir que “criptografado em repouso” satisfaz automaticamente requisitos de consentimento, histórico de acesso, retenção e notificação de violação.

Exemplo: uma clínica criptografa formulários de entrada, depois a equipe exporta um relatório de faturamento que cria uma pasta local não criptografada. Essa pasta é rodada para backup em um drive compartilhado. O vazamento acontece no fluxo de trabalho, não na criptografia.

Checklist rápido antes de se comprometer

Escreva uma frase simples: quem deve poder ler esses arquivos, e quem nunca deve poder, mesmo que alguém consiga acesso aos seus servidores.

Depois verifique:

• Quem pode descriptografar, e quando? Liste papéis e condições exatas. Se sua política diz “apenas o remetente”, não adicione uma backdoor por chaves compartilhadas silenciosas.
• Você consegue revogar acesso rapidamente? O offboarding é o verdadeiro teste. Decida se o acesso está ligado a uma conta, um dispositivo ou um grupo.
• O que acontece após perda de dispositivo ou resets de senha? Se precisar de recuperação, proteja-a com aprovações fortes.
• Você precisa de pré‑visualizações, varredura antivírus ou OCR? Se sim, planeje onde a descriptografia acontece e quem pode acioná‑la.
• Seus logs de auditoria são específicos o bastante? Defina o que conta como “visualizado” vs “baixado”, e capture usuário, horário, dispositivo e razão.

Cenário de exemplo: uma pequena equipe armazenando IDs e PDFs médicos

Uma pequena clínica tem um app onde a equipe envia encaminhamentos de pacientes (PDFs) e fotos de IDs de seguro. O objetivo é encaminhar documentos às pessoas certas rapidamente, reduzindo danos por perda de dispositivos, contas comprometidas ou erros na nuvem.

Uma abordagem viável é criptografia no servidor com papéis rígidos. Arquivos são criptografados em repouso, e o acesso é controlado por permissões: recepção pode enviar, faturamento pode ver IDs, e clínicos podem ver encaminhamentos. Isso tende a ser mais fácil no dia a dia porque a equipe pode abrir documentos em desktop ou mobile sem passos extras, e supervisores podem reatribuir acesso durante ausências.

Outra abordagem usa criptografia no cliente para os itens mais sensíveis. O arquivo é criptografado no dispositivo antes do upload, então o servidor armazena apenas o texto cifrado. Isso pode reduzir o impacto de invasões e acesso interno, mas muda operações:

• Resets de senha restauram acesso normalmente com criptografia no servidor; com criptografia no cliente, resets podem bloquear usuários a menos que as chaves sejam salvas com segurança.
• Rotatividade de pessoal é mais simples com criptografia no servidor; com criptografia no cliente, você precisa de um plano para transferir ou custodiar chaves para que documentos permaneçam acessíveis.

Usuários sentirão atrito em compartilhamento, acesso móvel e recuperação após perda de telefone. Esses detalhes importam tanto quanto o modelo de criptografia em si.

Próximos passos: decida, documente a política e implemente

Comece escrevendo suas suposições de ameaça em linguagem simples. Escolha a abordagem mais simples que satisfaça seu risco, depois restrinja apenas onde os documentos realmente justificarem.

Coloque a decisão em um conjunto curto de regras internas que as pessoas possam seguir:

• Quais tipos de arquivo são permitidos e onde podem ser armazenados
• Quem pode acessar e compartilhar, e como o acesso é aprovado
• Regras de retenção e exclusão
• Como a recuperação funciona após resets de senha e perda de dispositivo
• Como exportações (downloads, e‑mail, mensagens) são tratadas e quando são bloqueadas

Depois desenhe a implementação em torno dessas regras: checagens de papel, ações auditadas (visualizar, baixar, compartilhar), pré‑visualizações seguras e tratamento cuidadoso de chaves.

Se você está construindo sobre uma plataforma no‑code como AppMaster (appmaster.io), ajuda modelar papéis e fluxos de aprovação cedo, e depois ajustar conforme os requisitos mudam sem reescrever o app. O importante é tornar o caminho seguro o caminho fácil para usuários reais.