Inhaltsverzeichnis
- Was «verschlüsselter Cloudspeicher» wirklich bedeutet
- Zero-Knowledge vs. serverseitig: wer die Schlüssel hält
- Die Bedrohungsmodelle, die jedes Design abwehrt
- Gerichtsbarkeit und Metadaten: der Teil, den das Marketing überspringt
- Die echten Kompromisse von Zero-Knowledge
- Wo E2E-Anbieter passen: Internxt und Proton Drive
- Ein Entscheidungsrahmen für Entwickler
Was «verschlüsselter Cloudspeicher» wirklich bedeutet
«Verschlüsselt» ist eines der überladensten Wörter im Speichermarkt. Fast jeder Anbieter kann wahrheitsgemäß behaupten, sein Dienst sei verschlüsselt, weil irgendeine Ebene es ist — und die Ebene, die zählt, ist selten die auf der Marketingseite.
Jedes Cloudspeicher-Produkt hat drei verschiedene Verschlüsselungsebenen, die gegen völlig unterschiedliche Dinge schützen:
- Verschlüsselung bei der Übertragung — TLS schützt Bytes, die zwischen deinem Gerät und dem Server wandern. Das stoppt einen Netzwerk-Lauscher. Jeder seriöse Anbieter tut das; es ist Grundvoraussetzung, kein Feature.
- Verschlüsselung im Ruhezustand — die Daten auf den Festplatten des Anbieters sind verschlüsselt, meist mit AES-256. Das schützt gegen den physischen Diebstahl einer Platte aus dem Rechenzentrum. Aber der Anbieter hält den Schlüssel, also bringt es nichts gegen den Anbieter, eine Vorladung oder einen Einbruch, der den Schlüsselspeicher erreicht.
- Ende-zu-Ende-/Zero-Knowledge-Verschlüsselung — die Daten werden auf deinem Gerät mit einem Schlüssel verschlüsselt, den nur du kontrollierst, bevor sie den Server überhaupt erreichen. Der Anbieter speichert Chiffretext, den er nicht lesen kann.
Wenn ein datenschutzbewusster Entwickler nach «verschlüsseltem Cloudspeicher» fragt, meint er fast immer die dritte Ebene. Wenn ein Mainstream-Anbieter «deine Daten sind verschlüsselt» bewirbt, meint er fast immer die ersten beiden. Diese Lücke ist das gesamte Thema dieses Artikels.
Zero-Knowledge vs. serverseitig: wer die Schlüssel hält
Die einzige Frage, die die zwei Welten trennt, lautet: Wer kann deine Dateien ohne deine Mitwirkung entschlüsseln?
Serverseitige (herkömmliche) Verschlüsselung. Der Anbieter erzeugt und speichert die Verschlüsselungsschlüssel. Deine Dateien sind im Ruhezustand verschlüsselt, aber dasselbe System, das den Chiffretext speichert, speichert auch das Mittel zur Entschlüsselung. Das ist das Modell hinter der Standarderfahrung von Dropbox, Google Drive, OneDrive und den meisten Verbraucher-Cloudspeichern. Der Vorteil ist Bequemlichkeit: Der Server kann deine Dateien für die Suche indexieren, Vorschauen rendern, Virenscans ausführen, kollaboratives Bearbeiten ermöglichen und dein Passwort ohne Datenverlust zurücksetzen. Der Preis ist, dass der Anbieter — und jeder, der legal oder illegal seinen Schlüsselspeicher erreicht — alles lesen kann.
Zero-Knowledge-Verschlüsselung (Ende-zu-Ende). Der Schlüssel wird aus deinem Passwort auf deinem Gerät mittels einer Schlüsselableitungsfunktion wie Argon2 oder PBKDF2 abgeleitet. Der Klartext wird lokal verschlüsselt; nur Chiffretext wird hochgeladen. Der Anbieter speichert eine verschlüsselte Kopie deines Schlüsselmaterials, eingehüllt von einem Schlüssel, der selbst aus deinem Passwort stammt, sodass der gespeicherte Bund ohne dich nutzlos ist. Der Anbieter kann deine Dateien daher nicht lesen, kann keinen Klartext auf eine Vorladung hin liefern und kann dein Passwort nicht zurücksetzen, ohne dass du den Zugriff verlierst. Der Begriff «Zero-Knowledge» beschreibt genau das: Der Dienst hat null Wissen über deinen Klartext.
Die Kryptografie hier ist nicht exotisch — es ist dasselbe Umschlag-Verschlüsselungsmuster, das in Passwortmanagern wie den in unserem CLI-Passwortmanager-Leitfaden für Entwickler behandelten verwendet wird. Was sich zwischen Anbietern unterscheidet, ist die Implementierungsdisziplin: welche KDF, welche Chiffre, ob auch Dateinamen und Ordnerstruktur verschlüsselt werden und ob der Client Open Source ist, sodass das Versprechen überprüfbar statt geglaubt ist.
Die Bedrohungsmodelle, die jedes Design abwehrt
Ein Verschlüsselungsmodell zu wählen heißt eigentlich, ein Bedrohungsmodell zu wählen. Ordne deinen Gegner dem Design zu, nicht umgekehrt.
| Bedrohung | Im Ruhezustand (serverseitig) | Zero-Knowledge (E2E) |
|---|---|---|
| Netzwerk-Lauscher | Abgewehrt (TLS) | Abgewehrt (TLS) |
| Gestohlene Rechenzentrums-Platte | Abgewehrt | Abgewehrt |
| Anbieter liest deine Dateien | Nicht abgewehrt | Abgewehrt |
| Böswilliger Mitarbeiter | Nicht abgewehrt | Abgewehrt |
| Vorladung für Inhalte | Nicht abgewehrt | Abgewehrt (kein Klartext zum Herausgeben) |
| Einbruch erreicht Schlüsselspeicher | Nicht abgewehrt | Abgewehrt (Schlüssel nie nutzbar auf dem Server) |
| Du vergisst dein Passwort | Anbieter kann wiederherstellen | Konstruktionsbedingt nicht wiederherstellbar |
| Malware auf deinem eigenen Gerät | Nicht abgewehrt | Nicht abgewehrt (Klartext existiert lokal) |
Zwei Zeilen verdienen Betonung. Zero-Knowledge schützt dich nicht vor Malware auf deiner eigenen Maschine — sobald du lokal entschlüsselst, ist der Klartext in deinen Händen und in deinem RAM, also zählt Endpunkt-Hygiene weiterhin. Und Zero-Knowledge verlagert das Passwort-Wiederherstellungsrisiko auf dich: Die Unfähigkeit des Anbieters, deine Daten zu lesen, ist dieselbe Eigenschaft, die ein vergessenes Passwort unwiederbringlich macht. Das ist ein Feature, aber ein Feature mit scharfer Kante.
Gerichtsbarkeit und Metadaten: der Teil, den das Marketing überspringt
Verschlüsselung schützt Inhalte. Sie schützt für sich allein keine Metadaten — und Metadaten reichen oft.
Selbst ein perfekt implementierter Zero-Knowledge-Dienst muss funktionieren. Er kennt deine Konto-E-Mail (du hast dich damit angemeldet), deine IP-Adressen beim Login, dein Speichervolumen, Dateigrößen, Upload-Zeitstempel und — je nach Implementierung — Datei- und Ordnernamen. Manche E2E-Designs verschlüsseln auch Dateinamen; viele nicht. Metadaten sind in der Regel nicht von der Zero-Knowledge-Garantie abgedeckt, und genau sie werden zuerst vorgeladen.
Hier tritt die Gerichtsbarkeit wieder ein. Das Rechtsregime eines Anbieters bestimmt, welche Metadaten verlangt werden können und in welchem Verfahren. Der US CLOUD Act (2018) erlaubt US-Behörden, amerikanische Unternehmen zur Herausgabe von überall auf der Welt gespeicherten Daten zu zwingen. Die DSGVO der EU und das revidierte Schweizer Bundesgesetz über den Datenschutz (DSG, in Kraft seit September 2023) stellen strengere Bedingungen an die Offenlegung. Es ist dieselbe Gerichtsbarkeitslogik, die wir für E-Mail in selbstgehostete E-Mail vs. ProtonMail vs. Fastmail und breiter in Datensouveränität behandelt haben: Wo ein Dienst eingetragen ist, ist eine primäre technische Variable, keine Fußnote.
Die praktische Erkenntnis: Kombiniere starke Inhaltsverschlüsselung mit einem Anbieter in einer datenschutzfreundlichen Gerichtsbarkeit und nimm an, dass deine Metadaten für ein hinreichend motiviertes Rechtsverfahren ungeachtet dessen sichtbar sind.
Die echten Kompromisse von Zero-Knowledge
Zero-Knowledge-Speicher ist nicht reibungsfrei. Ehrlich über die Kosten zu sein, ist die einzige Möglichkeit, gut zu wählen.
Suche und Vorschauen verschlechtern sich. Da der Server nur Chiffretext speichert, kann er keinen Volltextindex deiner Dokumente aufbauen oder serverseitige Vorschauen und Miniaturansichten wie Google Drive rendern. E2E-Anbieter suchen entweder clientseitig (nachdem dein Gerät einen Index entschlüsselt hat) oder beschränken die Suche auf Dateinamen. Für einen Ordner mit Tausenden Dokumenten ist das ein spürbarer Unterschied.
Zusammenarbeit ist schwieriger. Echtzeit-Kollaborationsbearbeitung, die Art, die Google Docs allgegenwärtig machte, braucht grundsätzlich einen Server, der den Dokumentzustand lesen und zusammenführen kann. Zero-Knowledge-Designs können Zusammenarbeit, aber eingeschränkter und mit jüngeren Implementierungen.
Teilen mit Nicht-Nutzern erfordert Schlüsselaustausch. Eine verschlüsselte Datei an jemanden außerhalb des Dienstes zu senden bedeutet, einen Entschlüsselungsschlüssel über einen separaten Kanal zu teilen oder eine Anbieterfunktion zu nutzen, die einen passwortgeschützten Link erzeugt. Es funktioniert, aber es ist ein Schritt, den herkömmliche Dienste verbergen.
Passwortwiederherstellung liegt bei dir. Das sei wiederholt, weil es die häufigste Art ist, bei diesen Diensten Daten zu verlieren. Speichere den Wiederherstellungsschlüssel, den dir der Anbieter bei der Anmeldung gibt, lege ihn an einem dauerhaften und offline Ort ab und nutze ein starkes, einzigartiges Passwort. Das gesamte Sicherheitsmodell ruht auf diesem Passwort.
Keiner dieser Punkte ist ein Grund, Zero-Knowledge-Speicher zu meiden — es sind Gründe, ihn bewusst zu nutzen, für die Daten, die es rechtfertigen, statt als Drop-in-Ersatz für jeden Workflow.
Wo E2E-Anbieter passen: Internxt und Proton Drive
Zwei Anbieter tauchen in datenschutzorientierten Vergleichen immer wieder auf, weil sie Open-Source-Clients und Ende-zu-Ende-Verschlüsselung standardmäßig liefern, nicht als kostenpflichtiges Add-on oder nur im Enterprise-Modus.
Internxt ist ein in der EU (Spanien) ansässiger Anbieter, der Zero-Knowledge-, Ende-zu-Ende-verschlüsselten Cloudspeicher mit Open-Source-Clients und einem Gratis-Tarif anbietet. Seine Positionierung ist eine vollständige Datenschutz-Suite (Drive plus angrenzende Datenschutz-Tools), und die europäische Basis stellt ihn unter die DSGVO. Da der Client Open Source ist, ist das Zero-Knowledge-Versprechen überprüfbar statt behauptet.
Proton Drive ist die Speicherkomponente des Proton-Ökosystems — in der Schweiz ansässig, Ende-zu-Ende-verschlüsselt, Open Source, mit einem Gratis-Tarif. Wenn du bereits Proton Mail oder Proton VPN nutzt, fügt sich Drive in dasselbe Konto und dieselbe Schweizer Gerichtsbarkeit ein, was es zu einer natürlichen Möglichkeit macht, verschlüsselte Dateien neben verschlüsselter E-Mail zu halten. Dasselbe Zero-Access-Modell, das ein Proton-Postfach schützt, schützt Drive-Dateien.
Keiner ist eine universelle Antwort. Sie sind das richtige Werkzeug, wenn du konkret brauchst, dass der Anbieter deine Daten nicht lesen kann, und im Gegenzug die Such-/Kollaborationskompromisse akzeptierst.
Ein Entscheidungsrahmen für Entwickler
Hör auf zu fragen «welcher ist der sicherste Cloudspeicher» und fang an zu fragen «was sind diese Daten, und wer darf sie nicht lesen?»
Nutze herkömmlichen Speicher (Drive/Dropbox/OneDrive), wenn: du schnelle Volltextsuche über Dokumente, Echtzeit-Zusammenarbeit, reichhaltige Vorschauen brauchst und die Daten nicht sensibel genug sind, um die Reibung zu rechtfertigen. Bequemlichkeit ist eine legitime Anforderung.
Nutze Zero-Knowledge-Speicher (Internxt, Proton Drive), wenn: der Inhalt für den Anbieter unlesbar bleiben muss — persönliche Dokumente, Anmeldedaten-Archive, Kundendaten unter NDA, Backups sensibler Projekte, alles, was du nicht unter einer Vorladung herausgegeben sehen möchtest. Akzeptiere, dass die Suche lokal ist und das Teilen einen Schlüssel braucht.
Für Quellcode: nutze weiterhin Git auf einer Forge für den Workflow; nutze verschlüsselten Speicher für Backups von Repositories, große Binärdateien und Build-Artefakte, die kein Dritter indexieren soll. Lege keine aktiven Geheimnisse als rohe Dateien auf irgendeinem Speicher ab — nutze einen dedizierten Secrets-Manager oder einen verschlüsselten Tresor.
Was auch immer du wählst, überprüfe das Versprechen. Bevorzuge Open-Source-Clients, damit die Verschlüsselung auditierbar ist, bevorzuge eine datenschutzfreundliche Gerichtsbarkeit, damit Metadaten schwerer zu erzwingen sind, und speichere deinen Wiederherstellungsschlüssel in dem Moment, in dem du dich bei einem Zero-Knowledge-Dienst anmeldest. Die stärkste Kryptografie der Welt wird durch ein vergessenes Passwort ohne Wiederherstellungsweg zunichtegemacht.
Für den breiteren Kontext, deine Daten aus Diensten unter US-Gerichtsbarkeit herauszuhalten, siehe unsere Säule zu Datensouveränität und den praktischen Migrationsleitfaden in Alternativen zu Google.
