Trasferire file di progetto in sicurezza: condivisione cifrata

Trasferire file di progetto in sicurezza significa che i file sono illeggibili a chiunque tranne il mittente e il destinatario — incluso il servizio di trasferimento stesso. Il meccanismo che fornisce questa garanzia è la crittografia end-to-end con AES-256-GCM, con chiave derivata da una password che entrambe le parti concordano separatamente dal link. L'upload cifra nel browser; il download decifra nel browser. Il server memorizza solo testo cifrato. Slack, allegati email e archiviazione cloud ordinaria non raggiungono questo standard. Per file di progetto che contengono specifiche di prodotto, codice non rilasciato o dati cliente sotto NDA, un link di trasferimento a conoscenza zero è il canale minimo accettabile.

Cosa rende un trasferimento "sicuro" in senso concreto

"Sicuro" è una parola che le aziende abusano. Ecco la checklist con specifiche:

Crittografia in transito: TLS 1.3 (RFC 8446) con cipher suite moderne (TLS_AES_256_GCM_SHA384). Standard su ogni browser e server principale dal 2018.
Crittografia a riposo: AES-256 sul livello di archiviazione, chiavi ruotate. Ogni provider serio fa questo.
Crittografia end-to-end (E2EE): la chiave in chiaro non esiste mai sul server. Questa è la parte difficile — la maggior parte dei servizi "sicuri" la salta.
Crittografia autenticata: AES-256-GCM (NIST SP 800-38D) produce un testo cifrato e un tag a 128 bit. La manomissione è rilevabile in fase di decifratura.
Derivazione di chiave robusta: PBKDF2-HMAC-SHA256 con 600.000+ iterazioni (linea guida OWASP 2023) o Argon2id.
Nessuna fuga di metadati: nomi file e dimensioni non sono esposti al server oltre il necessario.
Scadenza e revoca: i link si auto-eliminano; il mittente può revocare prima della scadenza.

La maggior parte degli strumenti enterprise spunta i primi due. Pochissimi spuntano tutti e sette.

Perché Slack, email e OneDrive non bastano

Il piano gratuito di Slack comprime gli allegati, limita a 1 GB per file sui piani a pagamento e archivia tutto su AWS con Slack che detiene le chiavi di decifratura. Un admin Slack — o chiunque abbia accesso all'export del tuo workspace — può leggere ogni file mai caricato. Va bene per un documento di marketing pubblico; non va bene per una data room M&A.

L'email (SMTP + TLS) è cifrata hop-by-hop, il che significa che ogni server di posta lungo il percorso decifra e ricifra. S/MIME e PGP sono end-to-end ma richiedono una gestione certificati/chiavi che il 99% dei team non configura mai.

OneDrive, Google Drive e Dropbox cifrano a riposo. Il provider detiene le chiavi. Un valido ordine del tribunale, un admin disonesto o un servizio di gestione chiavi violato espongono ogni file.

Crittografia end-to-end, passo dopo passo

Ecco cosa accade quando carichi un archivio di progetto su un servizio di trasferimento E2EE costruito correttamente:

Digiti una password nel browser. Il servizio deriva una chiave a 256 bit con PBKDF2-HMAC-SHA256, usando un salt casuale a 128 bit e 600.000 iterazioni. La password non lascia mai il browser.
Il file è suddiviso in blocchi da 5 MB. Ogni blocco riceve un nuovo IV (nonce) a 96 bit.
Ogni blocco è cifrato con AES-256-GCM. Output: testo cifrato + tag di autenticazione a 128 bit per blocco.
I blocchi cifrati vengono caricati sul server su TLS 1.3. Il server vede byte cifrati, l'IV e il tag. Mai la chiave, mai la password.
Il servizio restituisce un URL. Condividi l'URL su un canale (email, Slack) e la password su un altro (SMS, telefonata, vault condivisa di un password manager).
Il destinatario apre l'URL, digita la password, il browser ri-deriva la stessa chiave (il salt è inviato col testo cifrato), decifra ogni blocco e riassembla il file.

Se il server viene compromesso domani, l'attaccante ottiene testo cifrato e salt — inutili senza la password. Quella è conoscenza zero per costruzione.

Proteggere il canale della password

La crittografia più forte fallisce se la password viaggia nella stessa email del link. Canali separati:

Link via email, password via SMS
Link in DM Slack, password via Signal
Link nello strumento di project management, password in una 1Password Shared Vault
Per posta in gioco alta: link online, password via telefonata

Per i team, usa un password manager (1Password, Bitwarden, Keeper) con vault condivisi limitati al progetto. La password vive lì; le persone la vedono entrando nel vault; nessuno la incolla in un'email.

Tipi di file di progetto e cosa contengono

| File | Contenuti tipici | Perché la crittografia conta | | --- | --- | --- | | Backup .fig Figma | UI non rilasciata, marchi | Rischio di fuga competitiva | | Modello .rvt Revit | Planimetrie, indirizzo cliente | Implicazioni di sicurezza fisica | | Master .psd Photoshop | Creatività di campagna pre-lancio | Rischio reputazionale di brand | | Bozza contratto .docx | Prezzi, termini, parti | Responsabilità per violazione NDA | | Codice sorgente .zip | Algoritmi proprietari | Furto di IP | | Imaging medico .dicom | Informazioni sanitarie del paziente | Violazione HIPAA / GDPR | | Export clienti .csv | PII | GDPR Art. 32 attivato |

Un servizio di trasferimento che può leggere il file è una parte del rischio. L'E2EE rimuove il servizio dal modello di minaccia.

Conservazione e ciclo di vita del progetto

Allinea la scadenza del trasferimento alle milestone del progetto. Per un deliverable di sprint di due settimane, una scadenza di 14 giorni è perfetta — il file scompare quando lo sprint finisce. Per un report cliente trimestrale, 30 giorni. Per una data room M&A di lunga durata, usa una VDR (Virtual Data Room) costruita allo scopo come Intralinks o Firmex, non un link di trasferimento generico.

Dopo la scadenza, controlla se qualcosa è stato rinviato. Se lo stesso file di progetto ruota tra cinque trasferimenti separati, sta meglio in uno workspace condiviso cifrato (Tresorit, Proton Drive o un Nextcloud self-hosted con crittografia lato server).

Audit trail per team regolamentati

I team sotto ISO 27001, SOC 2 Type II o GDPR devono registrare chi ha inviato cosa, quando e quando è stato scaricato. Un buon servizio di trasferimento espone:

Identità del mittente (o timestamp di upload + IP se anonimo)
Timestamp di download del destinatario
Timestamp di scadenza e cancellazione
Webhook al download, via email o pubblicato su Slack

HexaTransfer registra questi eventi senza memorizzare il contenuto in chiaro del file. L'audit trail conferma la consegna senza rompere la proprietà di conoscenza zero.

Confronto di trasferimenti sicuri team-friendly

| Servizio | Crittografia E2E | Password sul link | Scadenza | Webhook download | Dimensione max (gratis) | | --- | --- | --- | --- | --- | --- | | Upload file Slack | No | No | Conservazione workspace | No | 1 GB | | Link Google Drive | No | Opzionale | Manuale | No | Quota 15 GB | | Tresorit Send | Sì (assistita dal server) | Sì | Fino a 7 giorni | Sì | 5 GB gratis | | WeTransfer Pro | No | Sì | Fino a 365 giorni | Sì | 20 GB | | HexaTransfer | Sì (AES-256-GCM nel browser) | Sì | Configurabile | Sì | 10 GB |

Un'ultima cosa: non ricifrare ciò che è già cifrato

Se il file sorgente è un .asc cifrato con GPG o un .7z con AES-256 già incluso, aggiungere la crittografia a livello browser è ridondante e non aggiunge sicurezza. Scegli un livello, fallo bene, comunica la chiave fuori banda, vai avanti.

Il trasferimento sicuro riguarda il modello di minaccia, non il copy di marketing. L'E2EE mette il controllo dove deve stare — con le due persone che dovrebbero poter leggere il file.

Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.