Ir para o conteúdo
HexaTransfer
Voltar ao blog
RGPD e conformidade

Privacy by Design em Ferramentas de Transferência

Como aplicar os princípios de privacy by design em ferramentas de transferência de ficheiros, garantindo proteção de dados em todas as fases do processo de partilha.

Privacy by Design numa ferramenta de transferência de ficheiros significa que a configuração predefinida já protege os dados pessoais sem que o utilizador toque numa única definição. O Artigo 25.º do RGPD codifica dois tipos: a proteção de dados por conceção (Artigo 25.º(1)) exige que se integrem medidas técnicas adequadas no produto desde a fase de planeamento, e a proteção de dados por defeito (Artigo 25.º(2)) exige que a configuração predefinida trate apenas o que é necessário, partilhe apenas com quem precisa, e retenha apenas pelo tempo necessário. Para uma ferramenta de transferência, isso traduz-se em encriptação do lado do cliente ativa por defeito, expiração abaixo dos 30 dias, recolha mínima de metadados e revogação com um clique.

Os sete princípios de Cavoukian aplicados às transferências

O quadro de Ann Cavoukian dos anos 90 — proativo e não reativo, privacidade como configuração predefinida, integrada na conceção, funcionalidade total, segurança de ponta a ponta, visibilidade e transparência, respeito pela privacidade do utilizador — mapeia diretamente para a arquitetura de transferência de ficheiros. Proativo: detetar cifras fracas no código antes da implementação via análise estática automatizada. Predefinição: AES-256-GCM ativado sem possibilidade de desativação. Integrado: a encriptação ocorre no pipeline de carregamento, não como etapa separada. Funcionalidade total: os ficheiros encriptados ainda suportam pré-visualizações via desencriptação do lado do cliente. Ponta a ponta: a plataforma nunca toca o texto simples. Visibilidade: publicar as especificações de encriptação. Respeito: dar aos utilizadores controlo sobre a retenção e expiração.

Artigo 25.º(1): obrigações na fase de conceção

O Artigo 25.º(1) exige medidas "tanto no momento da definição dos meios de tratamento como no momento do próprio tratamento". Isso significa obrigações de privacidade na conceção da arquitetura, não em retrospetiva. Escolha um protocolo de transporte (HTTPS com TLS 1.3), um conjunto de cifras (AES-256-GCM ou XChaCha20-Poly1305), uma função de derivação de chaves (PBKDF2-SHA-256 a 600.000 iterações ou Argon2id), e uma região de armazenamento (UE) antes de escrever a primeira linha de código. Documente as escolhas num registo de decisões de arquitetura para que os futuros engenheiros compreendam as restrições.

Artigo 25.º(2): obrigações de configuração predefinida

O Artigo 25.º(2) especifica quatro predefinições: limitar a quantidade de dados pessoais recolhidos, limitar o tratamento, limitar o período de retenção, e limitar a acessibilidade. Para uma ferramenta de transferência, isso traduz-se em: pedir apenas os e-mails do remetente e do destinatário (não nome completo, telefone, morada); tratar o ficheiro uma vez e eliminá-lo; reter 7 dias e não indefinidamente; restringir o acesso aos destinatários específicos, não uma URL pública indexada por motores de busca. Compare com as ligações partilháveis públicas do WeTransfer Free — convenientes, mas não conformes com o Artigo 25.º(2) sem garantias adicionais.

Minimização de dados no fluxo de carregamento

O formulário de carregamento do remetente é onde a minimização começa. Má conceção: pedir nome do remetente, empresa, telefone, nome do destinatário, empresa do destinatário, mensagem. Cada campo é um ponto de dados pessoais armazenado e analisado. Boa conceção: apenas e-mail, campo de mensagem opcional, sem pixels de rastreamento. O SwissTransfer e a HexaTransfer implementam formulários mínimos; o WeTransfer e o Dropbox Transfer recolhem mais. Remova os metadados EXIF das imagens do lado do servidor se a remoção do lado do cliente não estiver disponível. Não registe os nomes dos ficheiros se estes contiverem dados pessoais — crie um hash para o registo de auditoria e armazene o mapeamento do lado do servidor apenas.

Encriptação ativa por defeito sem desculpas de desempenho

O AES-256-GCM em browsers modernos via Web Crypto API corre a cerca de 200 a 500 MB/s num portátil de 2020. Um ficheiro de 100 MB encripta em bem menos de um segundo. O XChaCha20-Poly1305 da Libsodium corre de forma similar. O argumento do desempenho para tornar a encriptação opcional é obsoleto. Utilize chaves por ficheiro derivadas de um segredo detido pelo utilizador — uma palavra-passe ou uma chave aleatória incorporada no fragmento da URL (após o #, para que os servidores nunca a vejam). Consulte a arquitetura do Firefox Send de 2017-2019 para um padrão comprovado: o fragmento da URL transportava a chave, o servidor via apenas texto cifrado.

Pseudonimização onde possível

O Artigo 4.º(5) define a pseudonimização. Ao abrigo do Considerando 28, é encorajada em todo o regulamento. Para transferências de ficheiros, a pseudonimização significa substituir identificadores diretos nos metadados do sistema: remetente@empresa.com torna-se um hash SHA-256 no registo de auditoria, com a tabela de mapeamento armazenada separadamente sob controlos de acesso mais rigorosos. Os destinatários de forma similar. Se um atacante comprometer apenas o registo de auditoria, vê hashes, não um grafo de contactos. A tabela de mapeamento — mais pequena e num cofre separado — é protegida com chaves e políticas de acesso diferentes.

Transparência através de arquitetura publicada

O Artigo 25.º não exige código aberto, mas a transparência é um princípio de privacy by design. Publique: as especificações de encriptação (cifra, KDF, iterações, comprimento da etiqueta de autenticação), o diagrama de fluxo de dados, a lista de sub-subcontratantes com jurisdições, o calendário de retenção, o prazo de notificação de violações, e o esquema do registo de auditoria. O Proton, o Tresorit e a HexaTransfer publicam todos whitepapers técnicos. As afirmações criptográficas que não podem ser verificadas — "encriptação de grau militar" vaga — são sinais de alerta. Se o fornecedor não nomear a cifra, presuma segurança fraca.

Controlo do utilizador como predefinição, não como funcionalidade premium

O Privacy by Design falha quando os controlos estão bloqueados por detrás de níveis pagos. As ligações protegidas por palavra-passe não devem ter custo adicional. Os limites de descarregamento não devem ser premium. A revogação de ligações não deve exigir contactar o suporte. A postura mínima de privacidade — expiração, palavra-passe, revogação, notificações de descarregamento — deve ser gratuita, com os níveis pagos a acrescentar escala (armazenamento, gestão de equipa) ou conveniência (ligações personalizadas, retenção mais longa). Esta é tanto uma postura ao abrigo do RGPD como uma postura comercial: os utilizadores confiam em produtos que lhes dão controlo sem uma barreira de pagamento.

Registar respeitando o princípio

Os registos de auditoria são eles próprios dados pessoais. Registar em excesso cria uma nova superfície de violação. Registar insuficientemente impede o cumprimento do Artigo 33.º ou a demonstração de conformidade ao abrigo do Artigo 5.º(2). O equilíbrio: registar tipo de evento, data e hora, hash do ID do ficheiro, hash do ID do ator, resultado. Não registar IPs completos — truncar para /24 (IPv4) ou /64 (IPv6). Não registar agentes utilizador na íntegra — extrair família de browser e versão principal. Reter pelo período mínimo necessário para segurança e conformidade (tipicamente seis meses), e depois eliminar. Encriptar o pipeline de registos de ponta a ponta; o próprio acesso aos registos torna-se um evento.

Testar a postura antes do lançamento

Execute uma auditoria de fluxo de dados com um engenheiro recente que não esteve envolvido na construção. Pergunte: para cada sistema, que dados pessoais transitam? Onde são armazenados? Por quanto tempo? Quem pode aceder? Como é registado o acesso? Como são eliminados? Compare as respostas com os compromissos do Artigo 25.º documentados na AIPD. Teste de penetração contra a arquitetura declarada — o servidor vê realmente apenas texto cifrado? A chave do fragmento da URL está realmente fora dos registos? Serviços com afirmações frágeis de privacy-by-design falham estes testes rapidamente. Serviços com afirmações sólidas — expiração de 7 dias da HexaTransfer com AES-256-GCM do lado do cliente — resistem porque a arquitetura faz o que a documentação afirma.

Integre a privacidade na conceção; não a adicione a posteriori. 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