Clientseitige vs. serverseitige Verschlüsselung für Uploads

Warum die Wahl der Verschlüsselung für hochgeladene Dokumente wichtig ist

Wenn deine App Leuten erlaubt, Dateien hochzuladen, speicherst du oft nicht nur „Dokumente“. Häufig speicherst du eine zweite Identität der Person: unterschriebene Verträge, Pass‑ oder Führerscheinfotos, medizinische Formulare und Laborergebnisse. Die Dateien sind klein — das Risiko ist es nicht.

Ein geleakter Vertrag kann rechtliche und finanzielle Folgen haben: Preise werden öffentlich, Unterschriften werden kopiert und Streitigkeiten eskalieren schnell. Ein gestohlener Ausweisscan kann zu Identitätsdiebstahl und Kontoübernahmen führen. Medizinische Dokumente können private Gesundheitsdaten offenlegen, die Patienten nicht über ihren kleinen Kreis hinaus geteilt sehen wollten. Ein Fehler kann Vertrauen jahrelang schädigen.

Teams sagen oft „verschlüsselter Speicher“, meinen damit aber Verschiedenes. Manchmal meinen sie, die Übertragungsverbindung sei verschlüsselt (HTTPS). Manchmal meinen sie, die Datei sei auf der Festplatte verschlüsselt (Verschlüsselung im Ruhezustand). Manchmal meinen sie, die Datei sei vor dem Verlassen des Geräts verschlüsselt, sodass der Server nie Klartext sieht (clientseitige Verschlüsselung). Das ist nicht dasselbe. Sie schützen gegen unterschiedliche Ausfallfälle.

Sicherheitsentscheidungen prägen auch die tägliche Nutzbarkeit und den Support. Mehr Privatsphäre kann mehr Reibung bedeuten: zusätzliche Schritte zum Anzeigen einer Datei, erschwertes Teilen, eingeschränkte Suche und Vorschauen sowie schmerzhafte Wiederherstellung, wenn jemand ein Gerät oder einen Schlüssel verliert. Einfacherer Zugang ermöglicht Indexierung, Antivirus‑Scans, Vorschauen und Passwortzurücksetzungen — erhöht aber, was dein Server (und jeder, der ihn kompromittiert) sehen kann.

Stell dir eine kleine Praxis vor, die Versicherungs‑IDs und medizinische PDFs hochlädt. Das Personal muss die richtige Datei schnell finden, aber die Praxis möchte den Schaden reduzieren, falls ein Admin‑Konto gehackt wird. Das „richtige“ Modell hängt davon ab, welcher Ausfall am meisten schadet und welche Unannehmlichkeiten Nutzer in Kauf nehmen.

Kurze Definitionen: clientseitig vs. serverseitig

Die praktische Frage ist einfach: Wann wird die Datei verschlüsselt und wer kann sie später entschlüsseln?

Serverseitige Verschlüsselung bedeutet, dass die Datei dein Backend in lesbarer Form erreicht und dein Server sie vor dem Speichern verschlüsselt. Das ist Verschlüsselung im Ruhezustand: Wenn jemand eine Festplatte stiehlt oder rohen Zugriff auf einen Storage‑Bucket bekommt, sieht er verschlüsselte Daten. Dein Server kann die Datei bei Bedarf trotzdem entschlüsseln.

Clientseitige Verschlüsselung bedeutet, dass die Datei auf dem Gerät des Nutzers (Browser oder Mobilgerät) verschlüsselt wird, bevor sie hochgeladen wird. Dein Server speichert nur Chiffretexte. Im normalen Betrieb kann der Server das Dokument nicht lesen, es sei denn, er hat Zugriff auf den Entschlüsselungsschlüssel.

Die Schlüsselhoheit ist die eigentliche Trennlinie:

• Bei serverseitiger Verschlüsselung werden Schlüssel vom Backend verwaltet (oft über einen Key‑Management‑Service) und das Backend entschlüsselt Dateien für autorisierte Nutzer.
• Bei clientseitiger Verschlüsselung werden Schlüssel vom Nutzer, seinem Gerät oder einem clientseitig gehaltenen Geheimnis kontrolliert, und das Backend setzt hauptsächlich Speicher‑ und Zugriffsregeln durch.

In beiden Modellen brauchst du weiterhin Authentifizierung und Berechtigungen. Verschlüsselung ersetzt keine Zugriffskontrolle.

Manche sagen „Ende‑zu‑End‑Verschlüsselung“ für: die Datei wird auf dem Sendegerät verschlüsselt, bleibt auf dem Server verschlüsselt und wird nur auf dem Gerät eines genehmigten Empfängers entschlüsselt. Das kann die Vertraulichkeit verbessern, macht aber Server‑Vorschauen, Volltextsuche, Virenscans und einfache Wiederherstellung deutlich schwieriger, sofern du nicht bereit bist, das Bedrohungsmodell zu ändern.

Bedrohungsmodelle: Wogegen willst du dich schützen?

Verschlüsselung hilft nur, wenn du klar benennst, welche Risiken du reduzieren willst. „Niemand außer dem vorgesehenen Nutzer darf die Datei lesen“ führt zu anderen Entscheidungen als „Schaden reduzieren, falls der Speicher geleakt wird“.

Gängige Bedrohungen für Apps, die Verträge, Ausweise oder medizinische Dokumente speichern, sind unter anderem:

• Gestohlene oder wiederverwendete Passwörter (Kontoübernahme)
• Insiderzugriff, der weiter reicht als nötig (Support, Admins, Auftragnehmer)
• Ein kompromittiertes Cloud‑Konto oder falsch konfigurierter Storage‑Bucket
• Ein Bug oder Leak, der Datenbanken oder Backups offenlegt
• Malware auf einem Nutzergerät

Es hilft auch, zu trennen, wo eine Exposition passieren kann:

• Während der Übertragung: die Datei bewegt sich vom Gerät zum Server
• Im Ruhezustand: Objektspeicher, Datenbankeinträge, Backups, Logs
• Beim Anzeigen/Verarbeiten: Vorschauen, OCR, Suche, Konvertierungen

Hier der Kernunterschied. Bei serverseitiger Verschlüsselung kann dein System entschlüsseln, also Vorschauen erstellen, scannen und indexieren. Bei clientseitiger Verschlüsselung speichert der Server Chiffretexte und kann den Inhalt ohne Schlüssel nicht lesen. Das reduziert normalerweise die mögliche Schadensausbreitung bei Server‑Kompromittierungen und Insiderzugriff.

Verschlüsselung verhindert nicht alles. Wenn ein Gerät infiziert ist, kann Malware die Datei vor der Verschlüsselung oder nach der Entschlüsselung abgreifen. Wenn jemand ein Dokument ansehen kann, kann er es trotzdem abfilmen, erneut teilen oder ausdrucken.

Wogegen jedes Modell schützt (und wogegen nicht)

Ein nützlicher Vergleich ist: Wer kann die Datei zu irgendeinem Zeitpunkt im Klartext sehen? Diese Antwort bestimmt das Ausmaß eines Leaks, das Insider‑Risiko und die Sicherheit von Backups.

Bei serverseitiger Verschlüsselung kann ein Server‑Breach immer noch viel offenlegen. Das Backend hat meist Zugriff auf Entschlüsselungs‑Keys (oder kann sie anfordern), weil es Vorschauen erstellen, Antivirus‑Checks ausführen, Suche unterstützen oder das Teilen handhaben muss. Im schlimmsten Fall kann ein Angreifer, der sowohl die gespeicherten Daten als auch die Schlüssel erlangt, alles entschlüsseln.

Bei clientseitiger Verschlüsselung stiehlt ein Angreifer, der deine Infrastruktur kompromittiert, in der Regel nur verschlüsselte Blobs. Ohne vom Nutzer gehaltene Schlüssel sind diese Blobs weitaus weniger nützlich.

Der Unterschied wird bei Insiderzugriff besonders sichtbar. Bei serverseitiger Verschlüsselung kann ein privilegierter Mitarbeiter, Cloud‑Admin oder ein kompromittiertes Support‑Konto oft Dokumente einsehen, indem es die App imitiert oder Speicher abfragt. Bei clientseitiger Verschlüsselung kann deine Infrastruktur Dateien zwar speichern und bewegen, sie aber nicht lesen, sofern keine Schlüssel bereitgestellt werden.

Clientseitige Verschlüsselung behebt keinen gehackten Rechner. Für hochriskante Uploads wie IDs und medizinische PDFs sind Gerätesicherheit und Kontoschutz genauso wichtig wie die Speicher‑Verschlüsselung.

Achte auch auf Leaks außerhalb des „Dateispeichers“. Viele Vorfälle passieren über:

• Backups und Snapshots, die entschlüsselte Dateien oder Schlüssel erfassen
• Logs, die Dateinamen, Metadaten oder extrahierten Text speichern
• Thumbnails, Vorschauen und Suchindizes
• Exporte an E‑Mail, Chat oder Ticketing‑Tools
• Temporäre Dateien, die beim Upload oder bei Konvertierungen entstehen

UX‑Abwägungen, die Nutzer sofort merken

Der größte Unterschied ist nicht die Kryptografie. Es ist, was Nutzer leicht tun können und was schwer wird.

Serverseitige Verschlüsselung ist oft unsichtbar. Nutzer melden sich an, laden hoch und sehen sofort eine Vorschau. Der Support kann Zugriffe zurücksetzen. Admins können Berechtigungen neu zuweisen, wenn jemand krank ist.

Clientseitige Verschlüsselung verändert Onboarding und den Alltag. Nutzer brauchen vielleicht eine stärkere Passphrase, einen lokal gespeicherten Schlüssel oder einen zusätzlichen Entsperrschritt. Gerätewechsel, Browser‑Neuinstallation oder App‑Neuinstallation können den Zugriff zerstören, wenn du kein Schlüssel‑Backup und keine Wiederherstellung vorgesehen hast.

Bei der Kontowiederherstellung werden Teams oft überrascht. Wenn nur der Nutzer den Entschlüsselungsschlüssel besitzt, kann „Passwort vergessen“ in „Zugriff verloren“ umschlagen. Du kannst einen Wiederherstellungsschlüssel oder einen Escrow‑Flow hinzufügen, musst dann aber ehrlich erklären, was das bedeutet.

Teilen wird ebenfalls komplizierter. Bei serverseitiger Verschlüsselung sind Shares meist nur Berechtigungen. Bei clientseitiger Verschlüsselung geht es oft auch um Schlüsselweitergabe, Widerruf und die Frage, was mit alten Kopien passiert.

Such‑ und Komfortfunktionen können irgendwo Entschlüsselung erzwingen. Volltextsuche, Vorschauen und OCR sind am einfachsten, wenn der Server die Datei lesen kann. Willst du Datenschutz im Ende‑zu‑Ende‑Sinn, brauchst du clientseitige OCR, lokale Indizes oder eingeschränkte Suche (z. B. nur Dateinamen und Tags).

Beispiel: Eine Praxis lädt Labor‑PDFs hoch und möchte per OCR Patientennamen in gescannten Dokumenten finden. Serverseitige Verschlüsselung unterstützt schnelle OCR und Suche. Clientseitige Verschlüsselung verlagert diese Arbeit auf die Geräte der Nutzer, was langsamer und schwieriger in Web und Mobil umzusetzen ist.

Dokumenten-spezifische Anforderungen: Verträge, Ausweise und medizinische Unterlagen

Die beste Wahl hängt weniger vom Dateityp als vom Workflow ab: Wer muss es lesen, wie schnell, wie oft und wie lange.

Verträge

Verträge beinhalten oft Review, Änderungen, Genehmigungen und Prüfpfade. Teams wollen zuverlässige Suche, Teilen und Aufbewahrungsregeln.

Wenn deine App kollaborative Reviews im Produkt unterstützt, ist serverseitige Verschlüsselung oft der praktische Standard, weil das System Vorschauen rendern, Suche ausführen und rollenbasierte Zugriffe durchsetzen kann, ohne Nutzer mit Schlüsselmanagement zu belasten.

Clientseitige Verschlüsselung passt, wenn die App eher ein Tresor ist, z. B. zum Speichern finaler unterschriebener PDFs für eine kleine Geschäftsführung. Der Kompromiss ist geringere Bequemlichkeit, es sei denn, du fügst clientseitige Werkzeuge hinzu.

Ausweise (Pässe, Führerscheine)

Ausweise sind sehr risikobehaftet, aber oft nur kurzfristig nötig. Viele Teams benötigen sie nur zur Verifikation und löschen sie anschließend. Der Workflow erfordert schnelles Anzeigen und strenge Handhabungsregeln, nicht Kollaboration.

Eine gängige Vorgehensweise ist serverseitige Verschlüsselung kombiniert mit strikten Zugriffskontrollen, starken Prüfprotokollen und kurzer Aufbewahrung. Clientseitige Verschlüsselung passt, wenn Support‑Mitarbeiter niemals Ausweise sehen sollen — dann brauchst du jedoch einen anderen Weg zur Verifikation.

Medizinische Dokumente

Medizinische Unterlagen tragen stärkere Erwartung an Privatsphäre. Nutzer gehen oft davon aus, dass nur eine minimale Personengruppe darauf zugreift.

Clientseitige Verschlüsselung kann die Exposition bei Server‑Lecks oder missbräuchlichem Admin‑Zugriff reduzieren. Sie kann aber auch echte UX‑ und Betriebsprobleme verursachen: Passwortzurücksetzungen, Gerätewechsel und Notfallzugriff werden komplizierter.

Bevor du dich entscheidest, ordne jeden Dokumententyp nach Workflow:

• Wer muss es lesen (und von wo)?
• Wie schnell muss es laden?
• Wie lange wird es aufbewahrt?
• Welche Produktfunktionen sind wichtig (Vorschau, Suche, automatische Löschung)?

Wie man wählt: ein Schritt‑für‑Schritt‑Prozess

Beginne damit, aufzuschreiben, was du speicherst und wer damit zu tun hat. Ein Ordner namens „uploads“ ist keine Richtlinie.

Schritt 1: Zugriffe statt nur „Nutzer“ abbilden

List die Rollen auf und beantworte zwei Fragen: Wer muss die Datei öffnen können und wer darf sie niemals öffnen (einschließlich Admins)? Berücksichtige auch die Aufbewahrung.

Schritt 2: Triff Annahmen zum Bedrohungsmodell

Sei ehrlich bezüglich dessen, wogegen du dich schützen willst.

• Wenn Insider‑Risiko oben auf der Liste steht, wird clientseitige Verschlüsselung attraktiver.
• Wenn Geräteverlust und Passwortzurücksetzungen häufig sind, zahlst du den Preis in Wiederherstellungs‑Komplexität.

Prüfe dann die Erfahrung:

1. Wiederherstellung und Support: Was passiert, wenn jemand sein Passwort vergisst oder sein Telefon verliert? Muss Zugriff wiederhergestellt werden, passt reine clientseitige Verschlüsselung meist nicht.

2. Unverzichtbare Funktionen: Brauchst du Vorschauen, Suche, OCR, E‑Signaturen oder API‑gestützte Verarbeitung? Viele dieser Funktionen sind einfacher, wenn irgendwo serverseitig entschlüsselt wird.

3. Audit und Compliance: Brauchst du klare Protokolle darüber, wer wann was angesehen hat? Beide Modelle können Logs liefern, aber clientseitige Designs brauchen zusätzliche Planung, um nicht in die Lage „wir können nicht helfen“ zu geraten.

Die meisten Teams landen bei einem Hybrid: serverseitige Verschlüsselung für die Mehrheit der Dokumente und clientseitige Verschlüsselung für eine kleine Klasse von „niemals für Personal sichtbar“ Uploads.

Häufige Fehler und Fallen

Die größte Falle ist, Verschlüsselung als die ganze Lösung zu betrachten. Privatsphäre und Compliance hängen auch davon ab, wer Zugriff hat, wie Zugriff genehmigt wird, was protokolliert wird, wie lange Dateien aufbewahrt werden und wie Löschanfragen gehandhabt werden.

An zweiter Stelle steht, clientseitige Verschlüsselung ohne Wiederherstellungsplan einzuführen. Wenn ein Nutzer ein Gerät verliert, eine Passphrase vergisst oder das Unternehmen verlässt — kannst du den Zugriff wiederherstellen, ohne dein Sicherheitsversprechen zu brechen? „Wir können nicht helfen“ mag für einen persönlichen Tresor akzeptabel sein, versagt aber meist bei Business‑Apps.

Diese Fehler führen zu echten Leaks und Workarounds:

• Admins eine versteckte „Alles ansehen“-Möglichkeit geben oder Support erlauben, sich als Nutzer einzuloggen, ohne strenge Logs und Zweitfreigaben.
• Im Browser oder in der App entschlüsseln und Kopien hinterlassen (Cache‑Vorschauen, temporäre Downloads, synchronisierte Ordner).
• „Sichere“ Dokumente später über unsichere Kanäle senden (PDFs per E‑Mail, Screenshots in Chat, Anhänge in Tickets).
• Den sicheren Workflow so umständlich machen, dass Nutzer auf persönliche Laufwerke ausweichen oder Fotos vom Bildschirm machen.
• Annehmen, dass „verschlüsselt im Ruhezustand“ automatisch Anforderungen an Einwilligung, Zugriffshistorie, Aufbewahrung und Meldung von Vorfällen erfüllt.

Beispiel: Eine Praxis verschlüsselt Intake‑Formulare, dann exportiert das Personal einen Abrechnungsbericht, der einen lokalen unverschlüsselten Ordner erzeugt. Dieser Ordner wird in ein geteiltes Laufwerk gesichert. Das Leck passiert im Workflow, nicht in der Kryptografie.

Kurze Checkliste vor der Entscheidung

Formuliere einen einfachen Satz: Wer sollte diese Dateien lesen können und wer auf keinen Fall, selbst wenn jemand Zugriff auf deine Server bekommt?

Prüfe dann:

• Wer kann wann entschlüsseln? Liste genaue Rollen und Bedingungen. Wenn deine Richtlinie „nur der Uploadende“ sagt, füge nicht heimlich einen Backdoor‑Key hinzu.
• Kannst du Zugriff schnell entziehen? Offboarding ist der echte Test. Entscheide, ob Zugriff an ein Konto, ein Gerät oder eine Gruppe gebunden ist.
• Was passiert nach Geräteverlust oder Passwortzurücksetzung? Wenn du Wiederherstellung brauchst, schütze sie mit starken Genehmigungen.
• Brauchst du Vorschauen, Virenscans oder OCR? Wenn ja, plane, wo Entschlüsselung stattfindet und wer sie auslösen darf.
• Sind deine Audit‑Logs spezifisch genug? Definiere, was als „angesehen“ vs. „heruntergeladen“ zählt, und erfasse Nutzer, Zeit, Gerät und Grund.

Beispiel‑Szenario: Ein kleines Team speichert IDs und medizinische PDFs

Eine kleine Praxis hat eine App, in der Personal Patientenüberweisungen (PDFs) und Fotos von Versicherungs‑IDs hochlädt. Ziel ist, Dokumente schnell an die richtigen Personen zu bringen und gleichzeitig den Schaden bei Geräteverlust, kompromittierten Konten oder Cloud‑Fehlern zu minimieren.

Ein praktikabler Ansatz ist serverseitige Verschlüsselung mit strikten Rollen. Dateien werden im Ruhezustand verschlüsselt und Zugriffe über Berechtigungen gesteuert: Empfang kann hochladen, Abrechnung kann IDs sehen und Ärzt*innen sehen Überweisungen. Das ist im Alltag meist einfacher, weil Personal Dokumente auf Desktop oder Mobilgerät ohne Extra‑Schritte öffnen kann und Vorgesetzte im Krankheitsfall Zugriff neu zuweisen können.

Eine andere Möglichkeit ist clientseitige Verschlüsselung für die sensibelsten Elemente. Die Datei wird auf dem Gerät vor dem Upload verschlüsselt, sodass der Server nur Chiffretexte speichert. Das verringert die Folgen von Server‑Lecks oder Insiderzugriffen, verändert aber den Betrieb:

• Passwortzurücksetzungen lassen sich bei serverseitiger Verschlüsselung meist einfach wiederherstellen; bei clientseitiger Verschlüsselung kann eine Zurücksetzung Nutzer aussperren, wenn keine Schlüssel gesichert sind.
• Mitarbeiterwechsel ist bei serverseitiger Verschlüsselung einfacher; bei clientseitiger Verschlüsselung brauchst du einen Plan, um Schlüssel zu übertragen oder zu hinterlegen, damit Dokumente zugänglich bleiben.

Nutzer spüren Reibung beim Teilen, mobilen Zugriff und bei der Wiederherstellung nach Geräteverlust. Diese Details sind genauso wichtig wie das Verschlüsselungsmodell selbst.

Nächste Schritte: Entscheiden, Richtlinie dokumentieren und umsetzen

Formuliere zuerst deine Bedrohungsannahmen in klarer Sprache. Wähle den einfachsten Ansatz, der dein Risiko erfüllt, und verschärfe ihn nur dort, wo Dokumente es wirklich rechtfertigen.

Halte die Entscheidung in einer kurzen internen Regel fest, der Leute folgen können:

• Welche Dateitypen erlaubt sind und wo sie gespeichert werden dürfen
• Wer sie wie freigeben und teilen darf und wie Zugriff genehmigt wird
• Aufbewahrungs‑ und Löschregeln
• Wie Wiederherstellung nach Passwortzurücksetzung und Geräteverlust funktioniert
• Wie Exporte (Downloads, E‑Mails, Nachrichten) gehandhabt oder blockiert werden

Baue dann die Umsetzung um diese Regeln: Rollenprüfungen, protokollierte Aktionen (Ansehen, Herunterladen, Teilen), sichere Vorschauen und sorgfältiges Schlüsselmanagement.

Wenn du auf einer No‑Code‑Plattform wie AppMaster (appmaster.io) aufbaust, hilft es, Rollen und Genehmigungsflüsse früh zu modellieren und dann Anforderungen anzupassen, ohne die ganze App neu schreiben zu müssen. Das Wichtige ist, den sicheren Weg für echte Nutzer zum einfachen Weg zu machen.