Ende-zu-Ende-Verschlüsselung in der Praxissoftware. Warum Serververschlüsselung nicht reicht

Der Unterschied zwischen Serververschlüsselung und E2E-Verschlüsselung für Therapiedaten. Was Therapeut:innen bei der Softwarewahl wissen müssen.

Von Christian Glatz · Mai 2026

Praktisch jede Praxissoftware schreibt "verschlüsselt" auf ihre Website. Hilfreich ist das selten, weil die Frage nicht ist, ob verschlüsselt wird, sondern wo — und vor allem: Wer hat den Schlüssel? Dieser Artikel erklärt den Unterschied zwischen Serververschlüsselung und Ende-zu-Ende-Verschlüsselung (E2E) und benennt die Grenzen, die in der Praxis oft unter den Tisch fallen.

Serververschlüsselung: Schutz gegen ein bestimmtes Szenario

Serververschlüsselung (encryption at rest) bedeutet: Die Daten liegen verschlüsselt auf der Festplatte des Servers. Das schützt gegen einen physischen Diebstahl der Hardware — wer die Festplatte aus dem Rechenzentrum trägt, kann mit ihr nichts anfangen.

Es schützt nicht gegen Zugriffe auf den laufenden Server. Der Anbieter besitzt den Schlüssel, die Anwendung entschlüsselt die Daten bei jedem Zugriff. Konkret bedeutet das:

• Mitarbeiter:innen mit Serverzugang können die Daten lesen.
• Sicherheitslücken in der Anwendung können Klartextdaten freilegen.
• Behördliche Anfragen sind bedienbar, weil der Anbieter entschlüsseln kann.
• Ein Angriff auf den laufenden Server umgeht die Festplattenverschlüsselung.

Zusätzlich nutzen die meisten Anbieter TLS für den Transport zwischen Browser und Server. Das ist Standard und wichtig, ändert aber nichts daran, dass die Daten auf dem Server während der Verarbeitung im Klartext vorliegen.

Ende-zu-Ende-Verschlüsselung: Der Schlüssel bleibt am Gerät

Bei Ende-zu-Ende-Verschlüsselung (E2E) passiert die Verschlüsselung im Browser, bevor die Daten den Server überhaupt erreichen. Der Server speichert nur Ciphertext und besitzt keinen Schlüssel.

Der Ablauf: Sie tragen eine Sitzungsnotiz ein. Der Browser verschlüsselt sie mit einem Verfahren wie AES-256-GCM. Der Server speichert den verschlüsselten Text. Beim nächsten Login auf einem anderen Gerät wird der Schlüssel aus dem Passwort (oder einem zweiten Faktor) neu abgeleitet und die Daten lokal entschlüsselt.

Wenn der Server bei einem Angriff vollständig kompromittiert wird, bekommen Angreifer:innen Ciphertext und Metadaten in die Hand. Den Inhalt der Notizen können sie ohne Schlüssel nicht lesen — der praktische Schaden ist damit deutlich geringer als bei reiner Serververschlüsselung, aber nicht null: Termine, Namen auf Honorarnoten und ähnliche Metadaten bleiben einsehbar (siehe nächster Abschnitt).

Die Grenzen, die man ehrlich benennen muss

E2E ist kein Allheilmittel. Drei Punkte gehören zu jeder seriösen Darstellung:

1. Metadaten sind systembedingt nicht vollständig E2E-verschlüsselt. Damit Termine im Kalender sortierbar, Honorarnoten an die Buchhaltung übergebbar und Zahlungen über externe Zahlungsdienstleister abwickelbar sind, müssen bestimmte Daten dem Server bekannt sein — typischerweise Terminzeiten, Rechnungsnummern, Beträge, Namen auf Honorarnoten und Zahlungsinformationen. Anbieter unterscheiden sich darin, welche Felder im Klartext liegen; lassen Sie sich das im Detail aufschlüsseln.

2. Browserbasierte E2E setzt Vertrauen in den ausgelieferten Code voraus. Der Verschlüsselungscode kommt bei jedem Aufruf vom Server. Wenn der Server kompromittiert ist, könnte theoretisch manipulierter JavaScript-Code ausgeliefert werden, der den Schlüssel oder Klartext mitsendet. Gegen dieses Restrisiko helfen Maßnahmen wie Subresource Integrity, reproduzierbare Builds und unabhängige Audits — aber nicht jede Lösung implementiert sie konsequent.

3. Passwortverlust = Datenverlust. Der Anbieter kann das Passwort nicht zurücksetzen, weil er den Schlüssel nicht hat. Recovery-Mechanismen (Recovery Key, zweites verifiziertes Gerät, sicher verwahrtes Passwort) sind kein Komfort, sondern Voraussetzung — sonst sind Ihre Daten bei einem vergessenen Passwort dauerhaft weg.

Daneben gibt es funktionale Einschränkungen: Volltextsuche über verschlüsselte Daten ist nicht möglich; Suche muss lokal laufen oder mit kryptografischen Verfahren wie HMAC-Hashes arbeiten. Support kann nicht "mal nachschauen", wenn etwas hakt. Beides ist gewollt, gehört aber zur Realität.

Fünf Fragen an jede:n Anbieter:in

Ob Sie eine Software gerade neu auswählen oder eine bestehende prüfen — diese Fragen klären die wesentlichen Punkte schneller als jede Marketing-Seite:

1. Wo liegt der Schlüssel? Beim Anbieter, beim Server oder ausschließlich auf meinem Gerät?
2. Was ist verschlüsselt, was nicht? Welche Felder (Notizen, Termine, Honorarnoten, Anhänge, Zahlungsdaten) liegen im Klartext, welche als Ciphertext?
3. Was passiert bei Passwortverlust? Gibt es einen Recovery Key, kann der Anbieter zurücksetzen — und wenn ja, was bedeutet das für E2E?
4. Gibt es einen AV-Vertrag nach Art. 28 DSGVO? Wie sind Subunternehmer geregelt?
5. Wo stehen die Server? EU/Österreich, oder Drittland (z. B. USA) mit allen daran hängenden Übermittlungsfragen?

Klare, präzise Antworten sind ein gutes Zeichen. Ausweichende Antworten oder Hinweise auf "militärische Verschlüsselung" ohne konkrete Angaben sind ein schlechtes.

Fazit

Ende-zu-Ende-Verschlüsselung ist für Therapiedaten ein deutlicher Sicherheitsgewinn gegenüber reiner Serververschlüsselung — vorausgesetzt, die Grenzen werden offen kommuniziert. Eine Software, die E2E ehrlich erklärt (inklusive Metadaten, Browser-Codevertrauen und Recovery), ist verlässlicher als eine, die mit Superlativen wirbt und Details vermeidet.