Zero-trust bestandsdeling: vertrouw niemand, versleutel alles

Zero-trust bestandsdeling gaat ervan uit dat het netwerk vijandig is, de server gecompromitteerd is, en het apparaat van de ontvanger mogelijk geïnfecteerd is — en versleutelt dienovereenkomstig. Bestanden worden versleuteld in de browser van de afzender met AES-256-GCM voordat een byte de draad raakt, sleutels zijn afgeleid van een wachtwoord plus een zout opgeslagen in het URL-fragment, en de server verwerkt alleen ondoorzichtige ciphertext. Dit is het bedrijfsmodel dat is gecodificeerd in NIST SP 800-207, toegepast op bestandsoverdracht: verificeer expliciet, verleen minimale rechten en ga bij elke laag uit van inbreuk.

De drie aannames die het ontwerp sturen

Zero trust begint met drie uitgangspunten. Ten eerste is het transport gecompromitteerd — bedrijfsproxy's doen TLS-inspectie, openbaar wifi in cafés voert ARP-spoofing uit, en statelijke afluisterpunten op backbone-niveau bestaan (gedocumenteerd door Snowden in 2013, nog steeds operationeel volgens Bloomberg-rapportage uit 2024). Ten tweede is de server gecompromitteerd — cloudproviders worden gehackt (AWS in 2019, Microsoft in 2023), beheerders worden omgekocht, en dagvaardingen komen stilletjes. Ten derde kan het apparaat van de ontvanger geïnfecteerd zijn — de laptop van een medewerker draait een verouderde Chrome, malware oogst ontsleutelde bestanden. Elke ontwerpbeslissing vloeit voort uit deze drie aannames.

Clientsijdige versleuteling als eerste principe

Als de server plaintext kan zien, is het geen zero trust. Alles begint met de browser van de afzender die de Web Crypto API uitvoert: genereer een 256-bit sleutel, leid die af van het wachtwoord van de gebruiker via PBKDF2 bij 600.000 iteraties, versleutel het bestand met AES-256-GCM, en stream pas daarna de ciphertext naar de server. Firefox Send bewees dat dit op consumentenschaal werkte voordat Mozilla het in 2020 stopzette. Moderne opvolgers — HexaTransfer, Wormhole, Skiff — pakken het patroon op. De server bewaart bytes die hij niet kan lezen.

Sleutelmateriaal verlaat de eindpunten nooit

De decryptiesleutel moet de ontvanger bereiken zonder de server aan te raken. Twee mechanismen werken. Ten eerste de URL-fragmenttruc: de sleutel staat na # in de download-URL, die browsers nooit in HTTP-verzoeken meesturen. Ten tweede wachtwoordafgeleide sleutels: de afzender vertelt de ontvanger een wachtwoord via een afzonderlijk kanaal (Signal, telefoon, 1Password Psst!), en de browser van de ontvanger leidt de sleutel opnieuw af. Beide houden sleutelmateriaal buiten serverlogboeken, CDN-caches en databaseback-ups — wat telt wanneer de onvermijdelijke inbreuk plaatsvindt.

De code verifiëren die in de browser wordt uitgevoerd

Zero trust aan de clientkant is moeilijker dan aan de serverkant, want de server levert de JavaScript die de versleuteling uitvoert. Een kwaadaardige server kan een gebackdoorde bundel naar één gerichte gebruiker sturen. Mitigaties: publiceer SHA-384-hashes van elke release, onderteken ze met Sigstore of een bedrijfs-PGP-sleutel, en moedig gevorderde gebruikers aan te verifiëren met browserextensies zoals Code Verify (Meta levert dit voor WhatsApp Web). CSP-headers met script-src 'self' en Subresource Integrity blokkeren injectie vanuit gecompromitteerde CDN's. Niets hiervan is perfect, maar het verkleint het aanvalsoppervlak.

Authenticatie zonder gedeelde geheimen opgeslagen in rust

Wachtwoorden verstuurd via e-mail en opgeslagen in serverdatabases zijn het tegengestelde van zero trust. Vervang ze door WebAuthn-passkeys gebonden aan het apparaat van de ontvanger — de privésleutel verlaat de Secure Enclave nooit, en de server slaat alleen de publieke sleutel op. Voor eenmalige overdrachten: gebruik OPAQUE (RFC 9380) voor wachtwoordauthenticatie die het wachtwoord nooit server-side verzendt of opslaat. Magiclinks verzonden naar vooraf geverifieerde e-mailadressen bieden een middenweg: de entropie van de token (128 bits) vervangt de behoefte aan een opgeslagen geheim.

Overdrachten segmenteren op gevoeligheid

Niet elk bestand verdient dezelfde controles. Een zero-trust bestandsdelingsservice laat afzenders uploads classificeren: openbaar (geen wachtwoord, 7 dagen verval), intern (wachtwoord, 48 uur verval), vertrouwelijk (wachtwoord + 2FA, 4 uur verval, één download), beperkt (passkey + IP-binding + 15 minuten verval). Automatiseer classificatie op bestandstype waar mogelijk: .pdf belastingaangifte → vertrouwelijk; .docx contracten → intern; .psd marketingbestanden → openbaar. NIST SP 800-171 noemt dit beheer van gecontroleerde niet-geclassificeerde informatie, en het past naadloos op overdrachtsworkflows.

Het apparaat van de ontvanger behandelen als niet-vertrouwd

Zodra Bob de juridische notitie van Alice van 5 MB ontsleutelt, staat die in zijn map Downloads. Als zijn laptop gecompromitteerd is, lekt het bestand. Zero-trust denken reikt verder: moedig ontvangers aan te ontsleutelen naar vluchtige opslag (Tails OS, een Chrome OS-gastsessie), vermijd ontsleutelen op gedeelde machines, en wis agressief na gebruik. Voor overdrachten met hoge inzet: gebruik beveiligde viewers die ontsleutelen in een gesandboxed browsertabblad en downloaden voorkomen — de ontvanger ziet de .pdf maar krijgt de bytes nooit op schijf. Dat is een duidelijke UX-uitruil; reserveer het voor het hoogste niveau.

Loggen zonder een surveillancesysteem te worden

Een zero-trust audit trail logt wat het moet voor incidentrespons en compliance, niet meer. Hash IP-adressen dagelijks, sla alleen User-Agent-families op (niet volledige strings), log nooit wachtwoorden of sleutels, en bewaar voor de minimale periode die elke regelgeving vereist — 90 dagen voor AVG Artikel 30, 6 jaar voor HIPAA 164.316. Het logboek zelf woont op append-only opslag (S3 Object Lock, compliance-modus) zodat een gecompromitteerde beheerder zijn sporen niet kan uitwissen. Dagelijks Merkle-roots publiceren op een openbaar prikbord voegt externe verificatie toe.

Waar zero trust de juridische werkelijkheid ontmoet

Zero trust ontheft je niet van verzoeken van wetshandhaving. Het verandert wat je kunt overhandigen — ciphertext die je niet kunt ontsleutelen, IP-hashes die je niet kunt omkeren, logboeken van wie welke slug heeft benaderd. Dat is gewoonlijk genoeg om een geldig bevel te voldoen terwijl gebruikersdata privé blijft voor massasurveillance. Publiceer een transparantierapport (het oude model van Twitter) dat aanvraagvolumes en responspercentages toont. Documenteer je dataminimalisatie in het privacybeleid zodat gebruikers de afwegingen begrijpen: je kunt verifiëren dat een bestand is overgedragen, maar je kunt het niet lezen of de ontvanger met zekerheid identificeren.

Probeer het op hexatransfer.com — gratis, zonder account, tot 10 GB.