Transferir Ficheiros de Projeto com Segurança: Partilha Encriptada para Equipas

A transferência segura de ficheiros de projeto significa que os ficheiros são ilegíveis para qualquer pessoa exceto o remetente e o destinatário — incluindo o próprio serviço de transferência. O mecanismo que garante isto é a encriptação ponta a ponta com AES-256-GCM, com chave derivada de uma palavra-passe que ambas as partes acordam separadamente do link. O upload encripta no browser; o download desencripta no browser. O servidor armazena apenas texto cifrado. O Slack, os anexos de email e o armazenamento na nuvem convencional não cumprem este requisito. Para ficheiros de projeto que contêm especificações de produto, código não publicado ou dados de clientes sob NDA, um link de transferência com conhecimento zero é o canal mínimo aceitável.

O que torna uma transferência "segura" em termos concretos

"Seguro" é uma palavra que as empresas abusam. Aqui está a lista de verificação com especificações:

Encriptação em trânsito: TLS 1.3 (RFC 8446) com cifras modernas (TLS_AES_256_GCM_SHA384). Padrão em todos os browsers e servidores principais desde 2018.
Encriptação em repouso: AES-256 na camada de armazenamento, chaves rodadas. Todos os fornecedores sérios fazem isto.
Encriptação ponta a ponta (E2EE): a chave em texto legível nunca existe no servidor. Esta é a parte difícil — a maioria dos serviços "seguros" ignora-a.
Encriptação autenticada: o AES-256-GCM (NIST SP 800-38D) produz um texto cifrado e uma tag de 128 bits. A adulteração é detetável no momento da desencriptação.
Derivação de chave robusta: PBKDF2-HMAC-SHA256 com 600 000+ iterações (orientação OWASP 2023) ou Argon2id.
Sem fuga de metadados: os nomes de ficheiros e tamanhos não são expostos ao servidor para além do necessário.
Expiração e revogação: os links são eliminados automaticamente; o remetente pode revogar antes da expiração.

A maioria das ferramentas empresariais cumpre os primeiros dois. Muito poucas cumprem todos os sete.

Por que o Slack, o email e o OneDrive não chegam

O plano gratuito do Slack comprime os anexos, limita a 1 GB por ficheiro nos planos pagos, e armazena tudo na AWS com o Slack a guardar as chaves de desencriptação. Um administrador do Slack — ou qualquer pessoa com acesso à exportação do seu espaço de trabalho — consegue ler todos os ficheiros alguma vez carregados. É adequado para um documento de marketing público; não é adequado para uma sala de dados de fusões e aquisições.

O email (SMTP + TLS) é encriptado salto-a-salto, o que significa que cada servidor de correio ao longo do caminho desencripta e re-encripta. O S/MIME e o PGP são ponta a ponta mas requerem gestão de certificados/chaves que 99% das equipas nunca configuram.

O OneDrive, o Google Drive e o Dropbox encriptam em repouso. O fornecedor guarda as chaves. Uma ordem judicial válida, um administrador desonesto ou uma violação do serviço de gestão de chaves expõe todos os ficheiros.

Encriptação ponta a ponta, passo a passo

O que acontece quando faz o upload de um arquivo de projeto para um serviço E2EE bem construído:

Introduz uma palavra-passe no browser. O serviço deriva uma chave de 256 bits com PBKDF2-HMAC-SHA256, usando um salt aleatório de 128 bits e 600 000 iterações. A palavra-passe nunca sai do browser.
O ficheiro é dividido em chunks de 5 MB. Cada chunk recebe um IV (nonce) fresco de 96 bits.
Cada chunk é encriptado com AES-256-GCM. Resultado: texto cifrado + tag de autenticação de 128 bits por chunk.
Os chunks de texto cifrado são enviados ao servidor via TLS 1.3. O servidor vê bytes encriptados, o IV e a tag. Nunca a chave, nunca a palavra-passe.
O serviço devolve um URL. Partilha o URL por um canal (email, Slack) e a palavra-passe por outro (SMS, chamada telefónica, cofre partilhado num gestor de palavras-passe).
O destinatário abre o URL, introduz a palavra-passe, o browser re-deriva a mesma chave (o salt é enviado com o texto cifrado), desencripta cada chunk e reconstituí o ficheiro.

Se o servidor for comprometido amanhã, o atacante obtém texto cifrado e salts — inútil sem a palavra-passe. É conhecimento zero por construção.

Proteger o canal da palavra-passe

A encriptação mais robusta falha se a palavra-passe viaja no mesmo email que o link. Canais separados:

Link por email, palavra-passe por SMS
Link por mensagem direta no Slack, palavra-passe por Signal
Link na ferramenta de gestão de projeto, palavra-passe num cofre partilhado do 1Password
Para situações de alto risco: link online, palavra-passe por chamada telefónica

Para equipas, utilize um gestor de palavras-passe (1Password, Bitwarden, Keeper) com cofres partilhados com âmbito definido para o projeto. A palavra-passe fica lá; as pessoas acedem ao juntarem-se ao cofre; ninguém a cola num email.

Tipos de ficheiros de projeto e o que contêm

| Ficheiro | Conteúdo típico | Por que a encriptação importa | | --- | --- | --- | | .fig backup Figma | UI não publicada, marcas registadas | Risco de fuga para a concorrência | | .rvt modelo Revit | Plantas de edifícios, morada do cliente | Implicações para a segurança física | | .psd master Photoshop | Criativo de campanha pré-lançamento | Risco para a reputação da marca | | .docx rascunho de contrato | Preços, condições, partes | Responsabilidade por violação de NDA | | .zip código-fonte | Algoritmos proprietários | Roubo de propriedade intelectual | | .dicom imagiologia médica | Informação de saúde do paciente | Violação HIPAA / RGPD | | .csv exportação de clientes | Dados pessoais | RGPD Art. 32 acionado |

Um serviço de transferência que consegue ler o ficheiro é uma parte do risco. A E2EE remove o serviço do modelo de ameaça.

Retenção e ciclo de vida do projeto

Alinhe a expiração da transferência com os marcos do projeto. Para um entregável de um sprint de duas semanas, uma expiração de 14 dias é perfeita — o ficheiro desaparece quando o sprint termina. Para um relatório trimestral de cliente, 30 dias. Para uma sala de dados de M&A de longa duração, utilize um VDR (Virtual Data Room) dedicado como Intralinks ou Firmex, não um link de transferência de uso geral.

Após a expiração, verifique se algo foi reenviado. Se o mesmo ficheiro de projeto passou por cinco transferências separadas, é melhor colocá-lo num espaço de trabalho encriptado partilhado (Tresorit, Proton Drive, ou um Nextcloud auto-hospedado com encriptação do lado do servidor).

Registos de auditoria para equipas reguladas

As equipas ao abrigo da ISO 27001, SOC 2 Tipo II ou RGPD precisam de registar quem enviou o quê, quando, e quando foi descarregado. Um bom serviço de transferência expõe:

Identidade do remetente (ou timestamp de upload + IP se anónimo)
Timestamp(s) de download do destinatário
Timestamp de expiração e eliminação
Webhook no download, enviado por email ou publicado no Slack

O HexaTransfer regista estes eventos sem armazenar o conteúdo do ficheiro em texto legível. O registo de auditoria confirma a entrega sem quebrar a propriedade de conhecimento zero.

Comparação de transferência segura para equipas

| Serviço | Encriptação E2E | Palavra-passe no link | Expiração | Webhook de download | Tamanho máx. (grátis) | | --- | --- | --- | --- | --- | --- | | Upload para Slack | Não | Não | Retenção do espaço de trabalho | Não | 1 GB | | Link Google Drive | Não | Opcional | Manual | Não | Quota de 15 GB | | Tresorit Send | Sim (assistida pelo servidor) | Sim | Até 7 dias | Sim | 5 GB grátis | | WeTransfer Pro | Não | Sim | Até 365 dias | Sim | 20 GB | | HexaTransfer | Sim (AES-256-GCM no browser) | Sim | Configurável | Sim | 10 GB |

Uma última coisa: não re-encripte o que já está encriptado

Se o ficheiro de origem é um .asc encriptado com GPG ou um .7z com AES-256 já incorporado, adicionar encriptação ao nível do browser é redundante e não acrescenta segurança. Escolha uma camada, faça-a bem, comunique a chave fora de banda, e siga em frente.

A transferência segura é uma questão de modelo de ameaça, não de texto de marketing. A E2EE coloca o controlo onde pertence — com as duas pessoas que devem conseguir ler o ficheiro.

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