Projektdateien sicher übertragen: verschlüsseltes Teamwork

Sicherer Projektdatei-Transfer bedeutet, dass die Dateien für niemanden außer Absender und Empfänger lesbar sind — einschließlich des Transferdienstes selbst. Der Mechanismus, der das gewährleistet, ist Ende-zu-Ende-Verschlüsselung mit AES-256-GCM, mit einem Schlüssel aus einem Passwort, das beide Parteien separat vom Link vereinbaren. Upload verschlüsselt im Browser; Download entschlüsselt im Browser. Der Server speichert nur Geheimtext. Slack, E-Mail-Anhänge und gewöhnlicher Cloud-Speicher erfüllen diesen Anspruch nicht. Für Projektdateien mit Produktspezifikationen, unveröffentlichtem Code oder Kundendaten unter NDA ist ein Zero-Knowledge-Transfer-Link der mindestens akzeptable Kanal.

Was einen Transfer konkret „sicher" macht

„Sicher" ist ein Begriff, den Unternehmen missbrauchen. Hier die Checkliste mit konkreten Anforderungen:

• Verschlüsselung in Transit: TLS 1.3 (RFC 8446) mit modernen Cipher Suites (TLS_AES_256_GCM_SHA384). Standard in jedem gängigen Browser und Server seit 2018.
• Verschlüsselung im Ruhezustand: AES-256 auf der Speicherebene, Schlüssel rotiert. Jeder seriöse Anbieter tut das.
• Ende-zu-Ende-Verschlüsselung (E2EE): Der Klartext-Schlüssel existiert nie auf dem Server. Das ist der schwierige Teil — die meisten „sicheren" Dienste überspringen ihn.
• Authentifizierte Verschlüsselung: AES-256-GCM (NIST SP 800-38D) erzeugt Geheimtext und ein 128-Bit-Tag. Manipulationen werden bei der Entschlüsselung erkannt.
• Starke Schlüsselableitung: PBKDF2-HMAC-SHA256 mit 600.000+ Iterationen (OWASP-2023-Empfehlung) oder Argon2id.
• Keine Metadaten-Lecks: Dateinamen und Größen werden dem Server nicht über das Notwendige hinaus offenbart.
• Ablauf und Widerruf: Links werden automatisch gelöscht; der Absender kann vor Ablauf widerrufen.

Die meisten Unternehmens-Tools erfüllen die ersten zwei Punkte. Sehr wenige alle sieben.

Warum Slack, E-Mail und OneDrive nicht ausreichen

Der kostenlose Slack-Tarif komprimiert Anhänge, begrenzt auf 1 GB pro Datei im bezahlten Plan und speichert alles auf AWS, wobei Slack die Entschlüsselungsschlüssel hält. Ein Slack-Administrator — oder jede Person mit Zugang zum Workspace-Export — kann jede jemals hochgeladene Datei lesen. Das ist in Ordnung für ein öffentliches Marketing-Dokument; nicht in Ordnung für einen M&A-Datenraum.

E-Mail (SMTP + TLS) ist hop-by-hop verschlüsselt, das heißt, jeder Mail-Server auf dem Weg entschlüsselt und verschlüsselt erneut. S/MIME und PGP sind Ende-zu-Ende, erfordern aber Zertifikat-/Schlüsselverwaltung, die 99 % aller Teams nie einrichten.

OneDrive, Google Drive und Dropbox verschlüsseln im Ruhezustand. Der Anbieter hält die Schlüssel. Eine gültige Gerichtsverfügung, ein unehrlicher Administrator oder ein kompromittierter Schlüsselverwaltungsdienst legt jede Datei offen.

Ende-zu-Ende-Verschlüsselung — Schritt für Schritt

Was passiert, wenn Sie ein Projektarchiv auf einen korrekt implementierten E2EE-Transferdienst hochladen:

1. Sie geben ein Passwort im Browser ein. Der Dienst leitet einen 256-Bit-Schlüssel mit PBKDF2-HMAC-SHA256 ab, mit einem zufälligen 128-Bit-Salt und 600.000 Iterationen. Das Passwort verlässt den Browser nie.
2. Die Datei wird in 5-MB-Blöcke aufgeteilt. Jeder Block erhält eine neue 96-Bit-IV (Nonce).
3. Jeder Block wird mit AES-256-GCM verschlüsselt. Ausgabe: Geheimtext + 128-Bit-Authentifizierungs-Tag pro Block.
4. Geheimtext-Blöcke werden über TLS 1.3 auf den Server hochgeladen. Der Server sieht verschlüsselte Bytes, die IV und das Tag. Niemals den Schlüssel, niemals das Passwort.
5. Der Dienst gibt eine URL zurück. Sie teilen die URL über einen Kanal (E-Mail, Slack) und das Passwort über einen anderen (SMS, Telefonat, Passwort-Manager-Tresor).
6. Der Empfänger öffnet die URL, gibt das Passwort ein, der Browser leitet denselben Schlüssel ab (Salt wird mit dem Geheimtext gesendet), entschlüsselt jeden Block und reassembliert die Datei.

Wenn der Server morgen kompromittiert wird, erhält der Angreifer Geheimtext und Salts — ohne das Passwort wertlos. Das ist Zero-Knowledge by construction.

Den Passwort-Kanal schützen

Die stärkste Verschlüsselung versagt, wenn das Passwort in derselben E-Mail reist wie der Link. Getrennte Kanäle:

• Link per E-Mail, Passwort per SMS
• Link per Slack-DM, Passwort per Signal
• Link im Projektmanagement-Tool, Passwort in einem 1Password Shared Vault
• Für Hocheinsatz-Fälle: Link online, Passwort per Telefonat

Für Teams einen Passwort-Manager (1Password, Bitwarden, Keeper) mit geteilten Tresoren verwenden, die auf das Projekt beschränkt sind. Das Passwort lebt dort; Personen sehen es durch Beitritt zum Tresor; niemand fügt es in E-Mails ein.

Projektdateitypen und ihr Inhalt

| Datei | Typischer Inhalt | Warum Verschlüsselung wichtig ist | | --- | --- | --- | | .fig Figma-Backup | Unveröffentlichte UI, Markenzeichen | Wettbewerbliches Leak-Risiko | | .rvt Revit-Modell | Baupläne, Kundenadresse | Physische Sicherheitsimplikationen | | .psd Photoshop-Master | Kampagnen-Kreation vor dem Launch | Marken-Reputationsrisiko | | .docx Vertragsentwurf | Preise, Bedingungen, Parteien | NDA-Verletzungshaftung | | .zip Quellcode | Proprietäre Algorithmen | IP-Diebstahl | | .dicom medizinische Bildgebung | Gesundheitsdaten von Patienten | HIPAA / DSGVO-Verstoß | | .csv Kundenexport | Personenbezogene Daten | DSGVO Art. 32 ausgelöst |

Ein Transferdienst, der die Datei lesen kann, ist Teilnehmer am Risiko. E2EE entfernt den Dienst aus dem Bedrohungsmodell.

Aufbewahrung und Projekt-Lebenszyklus

Transfer-Ablauf an Projektmeilensteine anpassen. Für ein Zwei-Wochen-Sprint-Lieferobjekt ist ein 14-tägiger Ablauf ideal — die Datei verschwindet, wenn der Sprint endet. Für einen vierteljährlichen Kundenbericht 30 Tage. Für einen langläufigen M&A-Datenraum einen spezialisierten VDR (Virtual Data Room) wie Intralinks oder Firmex verwenden, keinen allgemeinen Transfer-Link.

Nach dem Ablauf prüfen, ob etwas erneut gesendet wurde. Wenn dieselbe Projektdatei durch fünf separate Transfers rotiert, ist sie besser in einem gemeinsam genutzten verschlüsselten Workspace (Tresorit, Proton Drive oder ein selbst gehostetes Nextcloud mit serverseitiger Verschlüsselung).

Prüfprotokolle für regulierte Teams

Teams unter ISO 27001, SOC 2 Typ II oder DSGVO müssen protokollieren, wer was wann gesendet hat und wann es heruntergeladen wurde. Ein guter Transferdienst bietet:

• Absender-Identität (oder Upload-Zeitstempel + IP bei Anonymität)
• Zeitstempel(n) des Empfänger-Downloads
• Ablauf- und Lösch-Zeitstempel
• Webhook bei Download, per E-Mail oder in Slack gepostet

HexaTransfer protokolliert diese Ereignisse, ohne den Klartext-Dateiinhalt zu speichern. Das Prüfprotokoll bestätigt die Lieferung ohne die Zero-Knowledge-Eigenschaft zu brechen.

Vergleich team-freundlicher sicherer Transferdienste

| Dienst | E2E-Verschlüsselung | Passwort am Link | Ablauf | Download-Webhook | Max. Größe (kostenlos) | | --- | --- | --- | --- | --- | --- | | Slack-Datei-Upload | Nein | Nein | Workspace-Aufbewahrung | Nein | 1 GB | | Google Drive Link | Nein | Optional | Manuell | Nein | 15-GB-Quota | | Tresorit Send | Ja (serverunterstützt) | Ja | Bis 7 Tage | Ja | 5 GB kostenlos | | WeTransfer Pro | Nein | Ja | Bis 365 Tage | Ja | 20 GB | | HexaTransfer | Ja (AES-256-GCM im Browser) | Ja | Konfigurierbar | Ja | 10 GB |

Zum Schluss: Doppelte Verschlüsselung vermeiden

Wenn die Quelldatei bereits GPG-verschlüsselt (.asc) oder eine .7z mit eingebautem AES-256 ist, ist das Hinzufügen einer Browser-Verschlüsselungsschicht redundant und erhöht die Sicherheit nicht. Eine Schicht wählen, korrekt umsetzen, den Schlüssel Out-of-Band kommunizieren, weitermachen.

Sicherer Transfer dreht sich um das Bedrohungsmodell, nicht um Marketing-Texte. E2EE legt die Kontrolle dorthin, wo sie hingehört — bei den zwei Personen, die die Datei lesen dürfen.

Auf hexatransfer.com testen — kostenlos, ohne Konto, bis 10 GB.