Zero-Trust-Dateifreigabe: niemandem vertrauen, alles verschlüsseln
Wenden Sie Zero-Trust-Sicherheitsprinzipien auf Dateifreigabe an. Warum jedes Netzwerk als feindlich zu behandeln zu besserer Verschlüsselung führt.
Zero-Trust-Dateifreigabe setzt voraus, dass das Netzwerk feindlich ist, der Server kompromittiert ist und das Gerät des Empfängers infiziert sein kann — und verschlüsselt entsprechend. Dateien werden im Browser des Senders mit AES-256-GCM verschlüsselt, bevor ein Byte die Leitung berührt; Schlüssel leiten sich aus einem Passwort plus einem im URL-Fragment gespeicherten Salt ab; der Server handhabt nur opaken Chiffretext. Das ist das Betriebsmodell, das in NIST SP 800-207 kodifiziert und auf Dateiübertragungen angewendet wurde: explizit verifizieren, geringstmögliche Privilegien gewähren und auf jeder Ebene von einem Einbruch ausgehen.
Die drei Annahmen, die das Design treiben
Zero Trust beginnt mit drei Prämissen. Erstens: Der Transport ist kompromittiert — Unternehmens-Proxys führen TLS-Inspektion durch, Café-WLAN betreibt ARP-Spoofing, und nachrichtendienstliche Backbone-Abgriffe existieren (von Snowden 2013 dokumentiert, laut Bloombergs Berichterstattung von 2024 weiterhin operativ). Zweitens: Der Server ist kompromittiert — Cloud-Anbieter werden gebrochen (AWS 2019, Microsoft 2023), Admins werden unehrlich, und Vorladungen kommen still an. Drittens: Das Gerät des Empfängers kann infiziert sein — ein Mitarbeiter-Laptop läuft mit einem veralteten Chrome, Malware sammelt entschlüsselte Dateien. Jede Designentscheidung folgt aus diesen drei Annahmen.
Clientseitige Verschlüsselung als erstes Prinzip
Wenn der Server Klartext sehen kann, ist es kein Zero Trust. Alles beginnt mit dem Browser des Senders, der die Web Crypto API ausführt: einen 256-Bit-Schlüssel generieren, ihn aus dem Benutzerpasswort mit PBKDF2 bei 600.000 Iterationen ableiten, die Datei mit AES-256-GCM verschlüsseln und erst dann den Chiffretext zum Server streamen. Firefox Send bewies, dass das im Consumer-Maßstab funktionierte, bevor Mozilla den Dienst 2020 abschaltete. Moderne Nachfolger — HexaTransfer, Wormhole, Skiff — greifen das Muster auf. Der Server hält Bytes, die er nicht lesen kann.
Schlüsselmaterial verlässt die Endpunkte nie
Der Entschlüsselungsschlüssel muss den Empfänger erreichen, ohne den Server zu berühren. Zwei Mechanismen funktionieren. Erstens der URL-Fragment-Trick: Der Schlüssel lebt nach # in der Download-URL, die Browser nie in HTTP-Anfragen senden. Zweitens passwortabgeleitete Schlüssel: Der Sender teilt dem Empfänger ein Passwort über einen separaten Kanal mit (Signal, Telefonanruf, 1Passwords Psst!), und der Browser des Empfängers leitet den Schlüssel neu ab. Beide halten Schlüsselmaterial aus Server-Logs, CDN-Caches und Datenbank-Backups heraus — was relevant ist, wenn der unvermeidliche Einbruch geschieht.
Den Code verifizieren, der im Browser läuft
Zero Trust auf dem Client ist schwieriger als auf dem Server, weil der Server das JavaScript liefert, das die Verschlüsselung durchführt. Ein bösartiger Server könnte einem gezielten Nutzer ein backdoortes Bundle schicken. Abhilfemaßnahmen: SHA-384-Hashes jeder Release veröffentlichen, sie mit Sigstore oder einem Unternehmens-PGP-Schlüssel signieren, und erfahrene Nutzer zur Verifizierung mit Browser-Erweiterungen wie Code Verify ermutigen (Meta liefert das für WhatsApp Web). CSP-Header mit script-src 'self' und Subresource Integrity blockieren Injektionen von kompromittierten CDNs. Das ist nicht perfekt, aber es verengt die Angriffsfläche.
Authentifizierung ohne gespeicherte gemeinsame Geheimnisse
Passwörter, die per E-Mail gesendet und in Server-Datenbanken gespeichert werden, sind das Gegenteil von Zero Trust. Ersetzen Sie sie durch WebAuthn-Passkeys, die an das Gerät des Empfängers gebunden sind — der private Schlüssel verlässt nie den Secure Enclave, und der Server speichert nur den öffentlichen Schlüssel. Für einmalige Transfers verwenden Sie OPAQUE (RFC 9380) für Passwortauthentifizierung, die das Passwort nie überträgt oder serverseitig speichert. Magic-Links, die an vorab verifizierte E-Mail-Adressen gesendet werden, bieten einen mittleren Weg: Die Token-Entropie (128 Bit) ersetzt die Notwendigkeit eines gespeicherten Geheimnisses.
Transfers nach Sensibilität segmentieren
Nicht jede Datei verdient dieselben Kontrollen. Ein Zero-Trust-Dateifreigabedienst sollte Sendern erlauben, Uploads zu klassifizieren: öffentlich (kein Passwort, 7-Tage-Ablauf), intern (Passwort, 48-Stunden-Ablauf), vertraulich (Passwort + 2FA, 4-Stunden-Ablauf, Einzeldownload), eingeschränkt (Passkey + IP-Bindung + 15-Minuten-Ablauf). Automatisieren Sie die Klassifizierung nach Dateityp, wo möglich: .pdf-Steuererklärungen → vertraulich; .docx-Verträge → intern; .psd-Marketing-Comps → öffentlich. NIST SP 800-171 nennt das Controlled-Unclassified-Information-Handling, und es passt sauber zu Transfer-Workflows.
Das Gerät des Empfängers als nicht vertrauenswürdig behandeln
Sobald jemand ein 5-MB-Rechtsdokument entschlüsselt, liegt es im Downloads-Ordner. Ist sein Laptop kompromittiert, leakt die Datei. Zero-Trust-Denken erstreckt sich dorthin: Ermutigen Sie Empfänger, in ephemeren Speicher zu entschlüsseln (Tails OS, eine Chrome-OS-Gastsession), auf gemeinsam genutzten Rechnern nicht zu entschlüsseln und nach der Nutzung aggressiv zu löschen. Für hochriskante Transfers verwenden Sie geschützte Viewer, die in einen sandboxed Browser-Tab entschlüsseln und den Download verhindern — der Empfänger sieht das .pdf, bekommt aber nie die Bytes auf der Disk. Das ist offensichtlich ein UX-Kompromiss; reservieren Sie es für den höchsten Tier.
Protokollierung ohne Überwachungssystem
Ein Zero-Trust-Audit-Trail protokolliert, was für Incident-Response und Compliance nötig ist — nicht mehr. Hashen Sie IP-Adressen täglich, speichern Sie nur User-Agent-Familien (keine vollständigen Strings), protokollieren Sie niemals Passwörter oder Schlüssel und bewahren Sie nur so lange auf, wie jede Vorschrift verlangt — 90 Tage für DSGVO-Artikel-30-Zwecke, 6 Jahre für HIPAA 164.316. Das Log selbst lebt auf Anhänge-Only-Speicher (S3-Object-Lock, Compliance-Modus), damit ein kompromittierter Admin seine Spuren nicht verwischen kann. Das tägliche Veröffentlichen von Merkle-Roots auf einem öffentlichen Bulletin-Board fügt externe Verifikation hinzu.
Wo Zero Trust auf rechtliche Realität trifft
Zero Trust befreit Sie nicht von Strafverfolgungsanfragen. Es ändert, was Sie übergeben können — Chiffretext, den Sie nicht entschlüsseln können, IP-Hashes, die Sie nicht umkehren können, Logs darüber, wer auf welchen Slug zugegriffen hat. Das reicht meist aus, um einem gültigen Durchsuchungsbefehl zu entsprechen, während Nutzerdaten vor Massenüberwachung geschützt bleiben. Veröffentlichen Sie einen Transparenzbericht (nach dem alten Modell von Twitter) mit Anfragevolumen und Antwortquoten. Dokumentieren Sie Ihre Datensparsamkeit in der Datenschutzerklärung, damit Nutzer die Trade-offs verstehen: Sie können verifizieren, dass eine Datei übertragen wurde, aber Sie können sie nicht lesen oder den Empfänger mit Sicherheit identifizieren.
Auf hexatransfer.com testen — kostenlos, ohne Konto, bis 10 GB.
Große Dateien sicher mit Ende-zu-Ende-Verschlüsselung senden
Übertragen Sie Dateien bis zu 10 GB kostenlos mit Ende-zu-Ende-Verschlüsselung. Kein Konto erforderlich. Ihre Dateien werden in Ihrem Browser verschlüsselt, bevor sie hochgeladen werden — niemand sonst kann sie lesen.
Datei senden