Verschlüsselung at Rest vs in Transit: beide sind wichtig

Verschlüsselung in Transit schützt Daten, die sich zwischen zwei Punkten bewegen – etwa zwischen Ihrem Browser und einem Server – mittels TLS 1.3 mit AES-256-GCM oder ChaCha20-Poly1305. Verschlüsselung at Rest schützt Daten, die auf einem Datenträger liegen, typischerweise mit AES-256-XTS für Vollverschlüsselung oder AES-256-GCM pro Datei. Keine der beiden allein reicht aus. TLS schützt vor Netzwerk-Abhören, entschlüsselt aber am Server; At-Rest-Verschlüsselung schützt gespeicherte Daten, ist aber nutzlos, wenn die Schlüssel neben dem Chiffretext liegen. Echte Sicherheit entsteht durch das Schichten beider Methoden – idealerweise ergänzt durch clientseitige (Ende-zu-Ende-)Verschlüsselung, sodass der Server niemals Klartext sieht.

Zwei unterschiedliche Bedrohungen, zwei unterschiedliche Maßnahmen

Die Bedrohungen sehen je nach Aufenthaltsort Ihrer Daten anders aus:

In Transit (Netzwerkweg): Ein Angreifer im Café, der ein Paket-Sniffer-Tool ausführt, ein kompromittierter ISP-Router, ein Geheimdienst, der Unterseekabel anzapft. Die Snowden-Dokumente von 2013 enthüllten das NSA-MUSCULAR-Programm, das interne Google-Glasfaserverbindungen anzapfte. Schutz: TLS 1.3, vorzugsweise mit Certificate Pinning für Apps.

At Rest (Speicher): Ein gestohlener Laptop, ein durchgesickertes Backup-Band, ein falsch konfigurierter S3-Bucket, ein betrügerischer Rechenzentrumsmitarbeiter mit Datenträgerzugang. Der Equifax-Einbruch 2017 legte 147 Millionen Datensätze teilweise deshalb offen, weil Daten unverschlüsselt lagen. Schutz: LUKS, BitLocker, FileVault für Datenträger; AES-256-GCM oder AES-256-XTS für Datei- oder Blockebene.

Der Fehler ist, eine Methode als Ersatz für die andere zu behandeln. TLS schützt keinen Datenbank-Dump. Datenträgerverschlüsselung stoppt keinen Man-in-the-Middle-Angriff.

Wie TLS 1.3 Daten in Transit schützt

TLS 1.3, standardisiert in RFC 8446 (2018), ist der moderne Standard. Es verwendet:

Forward Secrecy standardmäßig über ephemeren ECDHE-Schlüsselaustausch. Selbst wenn der langfristige Schlüssel eines Servers durchsickert, bleiben vergangene Sitzungen geschützt.
Nur AEAD-Verschlüsselung – AES-128-GCM, AES-256-GCM oder ChaCha20-Poly1305. Alte CBC-Modi und RC4 sind entfernt.
Einzelner Round-Trip-Handshake (1-RTT) oder kein Round-Trip (0-RTT) für die Wiederaufnahme.
Verschlüsselter Handshake, sodass passive Beobachter die Zertifikatskette nicht sehen können.

Jeder seriöse Dateitransferdienst – WeTransfer, SwissTransfer, Tresorit, Proton Drive, HexaTransfer – betreibt TLS 1.3 mit HSTS-Headern, die HTTPS für mindestens 12 Monate erzwingen. Sie können das mit SSL Labs' testssl-Tool prüfen; alles unter A- hat Konfigurationsprobleme.

Wie At-Rest-Verschlüsselung serverseitig funktioniert

Sobald Dateien ankommen und TLS endet, übernimmt At-Rest-Verschlüsselung. Es gibt mehrere Ebenen:

Blockebene (Vollverschlüsselung): AES-256-XTS auf LUKS (Linux), BitLocker (Windows), FileVault (macOS) oder Cloud-Provider-Äquivalente wie AWS EBS-Verschlüsselung. Schützt gegen gestohlene Datenträger.
Dateisystemebene: eCryptfs, Fscrypt auf ext4/F2FS. Dateien jedes Nutzers mit separaten Schlüsseln verschlüsselt.
Objektspeicher-Ebene: AWS S3 SSE-KMS, Azure Blob mit Storage Service Encryption, Google Cloud Storage mit kundenverwalteten Schlüsseln. Jedes Objekt mit AES-256-GCM verschlüsselt.
Anwendungsebene: Der Dienst verschlüsselt jede Datei in seinem eigenen Code, bevor er sie in den Speicher schreibt, mit Schlüsseln in einem KMS oder HSM.

Die Anwendungsebene ist am stärksten, weil die Verschlüsselung erfolgt, bevor ein Speichersystem die Daten sieht. AWS KMS kostet 1 $/Schlüssel/Monat plus 0,03 $ pro 10.000 Anfragen – günstig genug, dass ernsthafte Dienste es pro Datei verwenden.

Die „Schlüssel neben Chiffretext"-Falle

At-Rest-Verschlüsselung scheitert häufig daran. Werden die Schlüssel auf demselben Server gespeichert wie der Chiffretext, erhält ein Angreifer bei einem Servereinbruch beides. Der Anbieter kann technisch das Häkchen bei „verschlüsselt at Rest" setzen, während er null realen Schutz gegen Servereinbrüche bietet.

Gute Architekturen trennen die Zuständigkeiten:

Chiffretext in S3 oder ähnlichem Objektspeicher.
Verschlüsselungsschlüssel in AWS KMS, Google Cloud KMS, Azure Key Vault oder einem dedizierten HSM.
Zugang zu Schlüsseln durch kurzlebige IAM-Anmeldedaten und Audit-Logs gesichert.

Exzellente Architekturen gehen weiter: Die Schlüssel existieren überhaupt nie auf dem Server. Clientseitige Verschlüsselung (E2EE) bedeutet, dass der Browser des Nutzers den Schlüssel erzeugt, die Datei verschlüsselt und den Schlüssel behält. Der Server speichert Chiffretext und hat nichts zu verlieren.

Wo Verschlüsselungslücken entstehen

Selbst mit beiden Maßnahmen ist Daten kurzzeitig an mehreren Stellen im Klartext:

Im Serverspeicher während der Upload-Verarbeitung, Virenscans oder Thumbnail-Generierung. Ein Speicher-Dump in diesem Fenster enthüllt Klartext.
In Zugriffs-Logs, wenn Dateinamen oder Inhaltsauszüge für das Debugging protokolliert werden.
In Backup-Bändern, wenn Backups nicht dieselbe Verschlüsselung erben.
Während Komprimierung oder Transkodierung, wo der Dienst Dateiinhalte verarbeitet.
Im Browser-Cache nach dem Download, wenn der Nutzer ihn nicht leert.

Deshalb ist Zero-Knowledge (clientseitige) Verschlüsselung wichtig. Werden Dateien im Browser vor dem Upload verschlüsselt, werden serverseitige Lücken irrelevant – der Server sieht nur Chiffretext.

Was die großen Dienste tatsächlich tun

Eine grobe Klassifikation basierend auf öffentlicher Dokumentation:

Google Drive, Dropbox, OneDrive: TLS 1.3 in Transit, AES-256 at Rest mit anbieterseitig gespeicherten Schlüsseln. Nicht Zero-Knowledge – der Anbieter kann Ihre Dateien lesen.
WeTransfer (kostenlose Stufe): TLS 1.3, AES-256 at Rest auf AWS S3. Anbieter hält die Schlüssel.
Box Enterprise: TLS 1.3, AES-256-GCM at Rest, optional kundenverwaltete Schlüssel (Box KeySafe).
Tresorit, Proton Drive, SwissTransfer E2EE-Stufe, HexaTransfer: TLS 1.3 in Transit, AES-256-GCM at Rest, aber die Schlüssel pro Datei sind clientseitig generiert und erreichen den Server nie. Faktisch Zero-Knowledge.

Für sensible Daten bietet nur die letzte Kategorie aussagekräftigen Schutz gegen Insider-Bedrohungen und legitime rechtliche Anfragen.

DSGVO und die Anforderung „Defense in Depth"

Regulierungsbehörden verlangen beide Maßnahmen ausdrücklich:

DSGVO Artikel 32 schreibt „Pseudonymisierung und Verschlüsselung personenbezogener Daten" vor, ohne Einschränkung auf den Zustand der Daten.
HIPAA Security Rule 45 CFR § 164.312 verlangt Verschlüsselung für ePHI sowohl in Transit als auch at Rest.
PCI DSS 4.0 Anforderungen 3 und 4 trennen „gespeicherte Karteninhaberdaten schützen" (at Rest) von „Karteninhaberdaten bei der Übertragung mit starker Kryptografie schützen" (in Transit).
FIPS 140-3-Validierung gilt für kryptografische Module in beiden Kontexten.

Nur eine der beiden bereitzustellen ist ein Compliance-Versagen, bevor es zum Sicherheitsversagen wird.

Wie Sie überprüfen, ob beide aktiv sind

Fünf schnelle Prüfungen für jeden Dateitransferdienst:

Führen Sie testssl.sh https://anbieter.com aus, um TLS 1.3 mit ausschließlich starken Verschlüsselungssuites zu bestätigen.
Prüfen Sie HSTS-Header mit max-age von mindestens 31.536.000 (ein Jahr).
Lesen Sie das Security-Whitepaper auf ausdrückliche Erwähnung von AES-256-GCM oder AES-256-XTS at Rest.
Bestätigen Sie, dass Schlüssel in einem KMS oder HSM gehalten werden, nicht in der Anwendungsdatenbank.
Suchen Sie nach SOC 2 Type II oder ISO 27001-Zertifizierung – beide verlangen dokumentierte At-Rest- und In-Transit-Kontrollen.

Bonus: Prüfen Sie, ob clientseitige Verschlüsselung als Option verfügbar ist. Wenn ja, aktivieren Sie sie für alles Sensible.

Korrekte Schichtung

Das Muster, das tatsächlich funktioniert:

Browser verschlüsselt Datei mit einem zufälligen AES-256-GCM-Schlüssel (clientseitig).
Chiffretext reist über TLS 1.3 zum Server (in Transit).
Server speichert Chiffretext auf AES-256-verschlüsseltem Speicher (at Rest).
Entschlüsselungsschlüssel lebt nur im Freigabe-URL-Fragment, wird nie an den Server gesendet.

Drei unabhängige Schichten. Bricht eine, halten die anderen. Das ist das Design von HexaTransfer, Tresorit Send, Proton Drive-Freigabelinks und SwissTransfers E2EE-Modus.

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