Condivisione file zero-trust: non fidarti di nessuno, critta tutto

La condivisione file zero-trust assume che la rete sia ostile, il server sia compromesso e il dispositivo del destinatario possa essere infetto — e poi cifra di conseguenza. I file vengono cifrati nel browser del mittente con AES-256-GCM prima che un singolo byte raggiunga il wire; le chiavi derivano da una password e un salt conservato nel frammento URL; il server gestisce solo ciphertext opaco. Questo è il modello operativo codificato in NIST SP 800-207 applicato al trasferimento file: verifica esplicitamente, concedi il privilegio minimo, assumi la violazione a ogni livello.

Le tre ipotesi che guidano il design

Zero trust parte da tre premesse. Prima: il trasporto è compromesso — i proxy aziendali fanno ispezione TLS, il Wi-Fi del bar esegue ARP spoofing, e i tap backbone di stato-nazione esistono (documentati da Snowden nel 2013, ancora operativi secondo i report del 2024). Seconda: il server è compromesso — i cloud provider vengono violati (AWS nel 2019, Microsoft nel 2023), gli amministratori diventano delinquenti, e le richieste legali arrivano in silenzio. Terza: il dispositivo del destinatario potrebbe essere infetto — un laptop aziendale gira su un Chrome non aggiornato, il malware raccoglie file decifrati. Ogni decisione di design deriva da queste tre premesse.

La crittografia lato client come primo principio

Se il server può vedere il testo in chiaro, non è zero trust. Tutto inizia con il browser del mittente che esegue la Web Crypto API: genera una chiave da 256 bit, la deriva dalla password dell'utente con PBKDF2 a 600.000 iterazioni, cifra il file con AES-256-GCM, e solo allora trasmette il ciphertext al server. Firefox Send ha dimostrato che questo funzionava su scala consumer prima che Mozilla lo chiudesse nel 2020. I successori moderni — HexaTransfer, Wormhole, Skiff — riprendono il pattern. Il server conserva byte che non sa leggere.

Il materiale crittografico non lascia mai gli endpoint

La chiave di decifratura deve raggiungere il destinatario senza toccare il server. Due meccanismi funzionano. Primo, il trucco del frammento URL: la chiave vive dopo # nell'URL di download, che i browser non inviano mai nelle richieste HTTP. Secondo, le chiavi derivate da password: il mittente comunica la password al destinatario attraverso un canale separato (Signal, telefonata, 1Password Psst!), e il browser del destinatario ri-deriva la chiave. Entrambi mantengono il materiale crittografico fuori dai log del server, dalle cache CDN e dai backup del database — il che conta quando la violazione inevitabile accade.

Verificare il codice che gira nel browser

Lo zero trust lato client è più difficile che lato server perché il server invia il JavaScript che esegue la cifratura. Un server malevolo potrebbe spingere un bundle backdoored a un singolo utente preso di mira. Mitigazioni: pubblica hash SHA-384 di ogni release, firmali con Sigstore o una chiave PGP aziendale, e incoraggia gli utenti avanzati a verificare con estensioni browser come Code Verify (Meta la usa per WhatsApp Web). Gli header CSP con script-src 'self' e Subresource Integrity bloccano l'iniezione da CDN compromesse. Niente di questo è perfetto, ma riduce la superficie di attacco.

Autenticazione senza segreti condivisi conservati

Le password inviate via email e conservate nei database del server sono l'antitesi dello zero trust. Sostituiscile con passkey WebAuthn legate al dispositivo del destinatario — la chiave privata non lascia mai il Secure Enclave, e il server conserva solo la chiave pubblica. Per i trasferimenti una tantum, usa OPAQUE (RFC 9380) per l'autenticazione con password che non trasmette né conserva la password lato server. I magic link inviati a indirizzi email pre-verificati offrono una via di mezzo: l'entropia del token (128 bit) sostituisce la necessità di un segreto conservato.

Segmentare i trasferimenti per sensibilità

Non ogni file merita gli stessi controlli. Un servizio di condivisione file zero-trust dovrebbe permettere ai mittenti di classificare gli upload: pubblico (nessuna password, scadenza 7 giorni), interno (password, scadenza 48 ore), riservato (password + 2FA, scadenza 4 ore, download singolo), ristretto (passkey + binding IP + scadenza 15 minuti). Automatizza la classificazione per tipo di file dove possibile: .pdf dichiarazione dei redditi → riservato; .docx contratti → interno; .psd comp marketing → pubblico. NIST SP 800-171 chiama questo gestione delle informazioni non classificate controllate (CUI), e si mappa pulitamente sui flussi di trasferimento.

Trattare il dispositivo del destinatario come non attendibile

Una volta che Bob decifra il brief legale da 5 MB di Alice, sta nella sua cartella Download. Se il suo laptop è compromesso, il file trapela. Il pensiero zero-trust si estende qui: incoraggia i destinatari a decifrare in storage effimero (Tails OS, una sessione ospite Chrome OS), ad evitare la decifratura su macchine condivise, e a cancellare aggressivamente dopo l'uso. Per i trasferimenti ad alto rischio, usa visualizzatori protetti che decifrano in una tab del browser sandboxata e impediscono il download — il destinatario vede il .pdf ma non ottiene mai i byte su disco. Ovviamente questo è un costo in termini di UX; riservalo al livello top.

Logging senza diventare un sistema di sorveglianza

Una traccia di audit zero-trust registra ciò che deve per la risposta agli incidenti e la conformità, nient'altro. Hasha gli IP giornalmente, conserva solo le famiglie di User-Agent (non le stringhe complete), non registrare mai password o chiavi, e conserva per il periodo minimo richiesto da ciascuna normativa — 90 giorni per i fini dell'Articolo 30 del GDPR, 6 anni per HIPAA 164.316. Il log stesso vive su storage append-only (S3 Object Lock, modalità Compliance) così un amministratore compromesso non può coprire le proprie tracce. Pubblicare le radici Merkle giornalmente su un bollettino pubblico aggiunge verifica esterna.

Dove lo zero trust incontra la realtà legale

Lo zero trust non ti esenta dalle richieste delle forze dell'ordine. Cambia ciò che puoi consegnare — ciphertext che non puoi decifrare, hash IP che non puoi invertire, log di chi ha avuto accesso a quale slug. Di solito è sufficiente per soddisfare un mandato valido mantenendo privati i dati degli utenti dalla sorveglianza di massa. Pubblica un transparency report (il vecchio modello di Twitter) mostrando volumi di richieste e tassi di risposta. Documenta la tua minimizzazione dei dati nella privacy policy così gli utenti capiscono i compromessi: puoi verificare che un file è stato trasferito, ma non puoi leggerlo o identificare il destinatario con certezza.

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