Eine Handreichung zur Frage der Datensicherheit verschiedener Praxis-IT-Lösungen


Mit Blick auf meine verschlüsselte Online Praxisverwaltung kumppani weise ich immer wieder darauf hin, wie wichtig eine echte Ende-zu-Ende-Verschlüsselung (E2EE > End-2-End-Encryption) ist, um ein Höchstmaß an Datensicherheit für meine Daten, aber natürlich ganz besonders die Patientendaten zu erreichen, wenn auf der anderen Seite die Vorteile einer Online Anwendung genutzt werden sollen. Da wird es Zeit, einmal etwas grundsätzlicher und weiter auszuholen, um zu begründen, wie ich zu dieser Einschätzung gekommen bin.

Völlig unabhängig von allen rechtlichen Fragen sind wir Menschen in Heilberufen auch aus Verantwortung unserer Existenzgrundlage und unseren Patienten gegenüber aufgefordert, für unsere Praxis-Daten ein angemessenes Maß an technischer Sicherheit zu gewährleisten.

Wer sich also in der Berufsausübung nicht auf Papier, Stift und Schreibmaschine beschränken will, muss sich in jedem Fall mit dem Thema Datenschutz und der Datensicherheit auch aus technischer Sicht beschäftigen.

Vorneweg: 100%ige Sicherheit gibt es nie und nirgends. Aber es gibt für jede Art von elektronisch gespeicherten Daten technische Sicherheitsstrategien. Allerdings auch unterschiedliche Meinungen darüber, was denn nun ein wirklich ausreichender Schutz ist. Je nach Blickwinkel und Eigeninteresse fallen die Antworten da sehr verschieden aus.

Das hat natürlich auch damit zu tun, dass jede Entscheidung mit Blick auf die technische Sicherheit eines IT-Systems eine Abwägung zwischen Bedienungsfreundlichkeit und Sicherheit beinhaltet. Auf diese Abwägung komme ich ganz am Schluss zurück, wenn ich meine eigenen Entscheidungen zur Thematik vorstelle und begründe, warum ich dem bunten Strauß an Praxissoftware eine weitere Blüte hinzugefügt habe. Das Thema IT-Sicherheit ist komplex und für Laien teilweise schwer zu verstehen. Trotzdem werde ich versuchen, in diesem Artikel einige für Heilberufler wichtige Aspekte nachvollziehbar und praxisnah zu erläutern. Es braucht etwas Grundlagenwissen, um sich eine eigene Meinung dazu zu bilden. Das folgt im übernächsten Abschnitt. Wer in diesen Dingen schon genug Wissen hat, kann ihn gerne überspringen. Als Praxisbetreiber haben wir es mit zwei Typen von Gefährdung unserer Daten zu tun:

• den Datenverlust durch einen technischen Defekt oder Datenträgerzerstörung • einem „Diebstahl" von Daten durch einen realen oder elektronischen Einbruch

Beides sind sehr reale Gefährdungen, wie die folgenden Beispiele zeigen.

Ein Großbrand und zwei „Hacks"

Am 10. März 2021 zerstörte ein Großbrand 2 von 4 Blöcken eines Rechenzentrums des Providers OVH in Straßburg, und mit ihnen zahllose Datenträger, auf denen die Daten von Millionen Kunden (oder die Daten von Kunden dieser Kunden) gespeichert waren. Die Daten etlicher dieser Kunden sind für immer vollständig verloren, darunter wohl auch die einer großen Anwaltskanzlei (1). 2020 wurden in Finnland tausende von psychotherapeutischen Unterlagen (2) und 2018 in Norwegen sogar Millionen von Gesundheitsdaten von Servern gestohlen, auf denen diese Daten zentral gespeichert waren (3). Drittes Beispiel aus Irland: durch “RansomWare” wurden wichtige Daten des staatlichen Gesundheitssystems durch eine kriminell motivierte Verschlüsselung unbrauchbar gemacht (4). Das Tückische an einem elektronischen Daten-„Diebstahl" ist der Umstand, dass es technisch gesehen nur ein Kopieren der Daten ist, keine wirkliche Entwendung. Ist das unauffällig genug gemacht, wird der „Diebstahl" erst bemerkt, wenn die Täter es öffentlich machen.

Ein paar technische Grundlagen zu Computerprogrammen

Gerade Psychotherapeuthen, die schon länger mit Computern unterwegs sind, kennen die altehrwürdigste Form von Programmen (Anwendungen) von ihrer unerfreulichen Seite: Das Programm wird auf dem „Einzelplatzrechner", dem PC oder Mac, installiert (früher von einem Datenträger, heute heruntergeladen von einem Server irgendwo im Internet). Ich muss regelmäßig ein Update machen (oder dem Hersteller erlauben, aus dem Internet auf mein Gerät zuzugreifen und aus der Ferne das Update anzustoßen). Aber genau so stressig sind die anderen Fragen: Habe ich ein (noch) ausreichend aktuelles und funktionierendes Backup? Wo ist es denn nun gerade, wenn ich es dringend brauche? Wo liegt der Fehler nun wirklich? Und dann doch oft nicht zuletzt: Ist mein PC-Helfer gerade greifbar? Dieses Prinzip ist nach wie vor aktuell, egal ob für ein Desktop-Gerät, ein Tablet oder Smartphone: Ich installiere Programme oder "Apps" und bin verantwortlich für Updates und Backups von Programmen und Daten. Eine in Praxen mit mehreren Mitarbeitern sinnvollvere Lösung sieht etwas anders aus. Das Praxisprogramm läuft auch auf nur einem Rechner, dem Praxis-Zentralrechner (genannt „Server"), der über das lokale Netzwerk (per Kabelverbindung oder über kabellose Funkverbindung) mit allen Arbeitsplatz-Rechnern (genannt „Clients") verbunden ist, die aber keinen Programmcode des Praxisprogramms enthalten. Diese Arbeitsplatz-Rechner sind dann bildlich gesprochen nur noch Anzeigegeräte.

Der Aufwand zur Programm- und Datenpflege ist im Grunde nicht höher als bei einem echten Einzelplatz-Rechner, obwohl beliebig viele Arbeitsplätze mit den Praxisprogramm verbunden sind, aber natürlich kommt die Pflege des Netzwerks und das Verwalten von Zugangsberechtigungen hinzu.

Seit ca. 10 Jahren etabliert sich sehr erfolgreich eine Alternative, die auf den ersten Blick viele Vorteile zu haben scheint: die browserbasierte Online- oder Web-Anwendung, kurz „WebApp". Ich muss dann auf meinem Gerät nichts installieren (außer dem Browser natürlich), sondern nur mit dem Internet verbunden sein. Ich erstelle ein Konto beim Anbieter, logge mich anschließend ein und nutze die auf dem Anbieter-Server laufende Anwendung, rufe sie wie eine Webseite auf, wann und wo immer ich will. Die Verarbeitung aller Daten findet auf dem Server statt. Das Ganze nennt sich auch „Software-as-a-Service" (SaaS).

Vereinfacht kann man sich das so vorstellen, dass der Zentralrechner, der Server, auf dem alle Prozesse ablaufen, nicht mehr in der Praxis steht, sondern irgendwo auf der Welt. Da heißt es dann auch schon mal wenig konkret, das Programm laufe in der “Cloud”. Das klappt, weil das Internet, das „Netz", inzwischen so viel Kapazität („Bandbreite") besitzt, dass immer mehr Daten gleichzeitig zwischen Abermilliarden von Rechnern, Tablets und Smartphones (aber inzwischen ja auch Kühlschränken, Toastern, Thermostatventilen und und und) hin- und hergeschoben werden können. Die Vorteile liegen auf der Hand: die App ist immer und von überall (mit Netzverbindung) erreichbar, läuft automatisch immer mit der aktuellen Version, und auf die Daten passen die Profis vom Anbieter auf. Sie sorgen für Wartung und regelmäßige Backups von System und Daten. Wenn denn alles korrekt läuft… Es gibt jedoch auch noch eine andere Form von WebApp, die weniger verbreitet ist, aber mir als Nutzer weitere Vorteile bietet. Bei dieser Variante arbeitet das Programm nicht auf dem (entfernten) Server. Vielmehr wird mir nach dem Einloggen die aktuelle Version des Programmes in meinen Firefox, Chrome oder Safari geladen und arbeitet dann in diesem Browser. Man könnte sagen, dass diese Form von WebApp in gewisser Weise die Eigenschaften von installierten Programmen und Online Programmen miteinander kreuzt: das Anwendungsprogramm und meine Anwendungsdaten liegen auf einem entfernten Server und warten, bis ich mich einlogge. Bin ich "authentifiziert", lädt mein Browser die Anwendung ebenfalls wie eine Webseite (aber eben mit allem Code für die Datenverarbeitung) zusammen mit meinen Daten herunter und legt los. Oder er synchronisiert als erstes die Daten in der Datenbank des Browsers von meinem letzten Arbeiten vorher mit den Daten in der Datenbank auf dem Server. Dann kann ich mit den aktualisierten Daten (weiter) arbeiten. Diese Technik wird “clientseitige Programmausführung” bezeichnet, im Gegensatz zur “serverseitigen Programmausführung” bei der zuvor beschriebenen WebApp-Technik, bei der das Programm auf einem Anwendungsserver in der Cloud läuft. Jetzt kann ich erklären, was eine lückenlose E2EE eigentlich ist. Die Daten werden im Browser verarbeitet bzw. verändert, die neu erzeugten oder veränderten Daten werden im Browser verschlüsselt und zur zentralen Datenbank beim Diensteanbieter (also z.B. uns) übertragen und dort verschlüsselt gespeichert. Beim nächsten Aufruf der WebApp durch die Nutzerin vom gleichen oder einem anderen Gerät werden die Daten dann wieder in der aktuellen Version weiterhin verschlüsselt in den Browser geladen, erst dort wieder entschlüsselt und weiter bearbeitet. Der Schlüssel zum Ver- und Entschlüsseln ist ausschließlich im Besitz der Nutzerin. Wir als Diensteanbieter haben ihn nicht und brauchen ihn auch nicht. Nirgendwo außerhalb des Browsers liegen die Daten in unverschlüsselter, lesbarer Form vor. Glücklicherweise bieten inzwischen alle relevanten Browser von Edge, über Firefox und Chrome bis zum Safari diese Fähigkeit zur Erzeugung eines Schlüssels. Das stellt sicher, dass es laufend aktualisiert und gegen auftauchende Schwachstellen von den Browseranbietern abgesichert wird. Und naturgemäß sind Angriffe gegen hunderte oder Tausende von Nutzergeräten viel schwieriger als Angriffe auf einen zentralen Server. Wir Entwickler kleinerer Projekte können so auf dieses Werkzeug unsere Anwendung aufbauen. Es empfiehlt sich immer, diesen Schlüssel auch exportieren und sicher verwahren zu können. Das ist der Preis für diese Art erhöhter Datensicherheit: ich muss auf den Schlüssel aufpassen. Noch ein Vorteil dieser Lösung: die erzeugten Schlüssel sind passwortunabhängig und verwenden einen wirklich sicheren Erzeugungsalgorithmus. „123456“ und „dadada“ haben ausgedient. Vergessen Nutzer ihr Passwort für den WebApp Account, kann dieses gewechelt werden, ohne das die Daten damit verloren sind. Es gibt sogar einen Weg, den Schüssel auf andere Geräte von mir zu übertragen, ohne das manuell machen zu müssen. Kriminelle “Datendiebstähle” an einer zentralen Stelle, wie oben beschrieben, sind dann prinzipiell unmöglich. Allerdings brauche ich weiterhin eine immer funktionsfähige Internetverbindung, weil die Daten im Gerät nicht gespeichert werden. E2EE ist die eindeutig sicherste Art von Verschlüsselung von Daten im Netz (6). Ohne bewusst eingebaute “Hintertüren” sind sie bei Verwendunge eines sicheren Schlüssels für viele Jahre nicht lesbar. An diesem Punkt setzt nun eine weitere Technik an, die offline-fähige “Local bzw. offline first Web App” – offline im Gegensatz zu online. Völlig unabhängig von der Frage, ob ich eine E2EE einsetze oder nicht nicht, kann ich entscheiden, die Nutzerinnendaten auch in einer Datenbank im Browser zu speichern, sodass sie auch bei einer fehlenden oder ausgefallenen Netzverbindung zur Verfügung stehen. Habe ich mal gerade keine Netzverbindung, kann ich mit der im Gerät gespeicherten letzten Fassung der WebApp und den Daten auf meinen Gerät weiterarbeiten, bis die Netzverbindung wieder vorhanden ist. Die Datenbestände werden dann im Hintergrund automatisch synchronisiert. Ich kann also wie bei einem auf meinem Gerät installierten Programm offline arbeiten, habe aber wie bei "normalen" WebApps den Vorteil, mich um Updates und Backups nicht ständig kümmern zu müssen. Probleme können entstehen, wenn ich mehrere Geräte parallel verwende, die alle über längere Zeit keine Netzverbindung hatten, wodurch der Datenbestand widersprüchlich werden kann und dann manuell nachgepflegt werden muss. Übrigens besteht für die im Browser gespeicherten Daten auch die Möglichkeit, sie verschlüsselt zu speichern, sodass auch die Nutzerin sie nicht direkt sehen kann, sondern sie nur mit einem vom Browser erzeugten Schlüssel ver- und entschlüsselt werden. Das hat allerdings mit der lückenlosen E2EE nichts zu tun. Einfache Online-Webapps können auf diese Variante nicht umgestellt werden, ohne sie komplett neu zu programmieren. Warum ist das so? Weil Daten in verschlüsselter Form nicht bearbeitet werden können. Da aber die Daten ja im Anwendungsserver des Diensteanbieters verarbeitet werden, müssen sie an einer Stelle der Verarbeitungskette außerhalb des Nutzerinnen-Browsers mit einem beim Diensteanbieter vorliegenden Schlüssel entschlüsselt werden. Bei einer serverseitigen Anwendung werden die Daten auf dem Wege vom Browser zum Webserver des Diensteanbieters (sozusagen der “Tür” zum Anwendungsserver) transportverschlüsselt (TLS-Verschlüsselung, ausgeschrieben “Transport Security Layer”). Man kann sich das so vorstellen, dass die Daten in eine verschlüsselte Transportschicht eingewickelt werden. Das ist inzwischen Standard im Internet und gilt auch für die allermeisten ganz normalen Webseiten. Sind es aber Programmdaten, müssen sie zur Verarbeitung entschlüsselt werden. Bevor sie dann in der zentralen Datenbank gespeichert werden, werden sie erneut mit einem anderen Schlüssel, der immer beim Diensteanbieter verwendbar vorhanden sein muss, verschlüsselt. Die Fachwelt spricht dann von verschlüsselten “Data-in-Motion” (auf dem Weg zwischen Browser und Webserver) und verschlüsselten “Data-at-Rest” (in der zentralen Datenbank). Aber zumindest im Arbeitsspeicher des Anwendungsservers sind sie prinzipbedingt lesbar, also nicht lückenlos E2E-verschlüsselt aus Sicht der Nutzerin.

Zu den Risiken und Nebenwirkungen fragen Sie Ihren Arzt oder Apotheker

Rechner in der Praxis oder als Mobilgerät

Habe ich des Praxisprogramm auf meinen eigenen Rechner oder auf dem Praxis-Zentralrechner (Server) installiert, muss ich folgende Gefährdungen meiner Daten im Auge haben: • Bedienungsfehler • Probleme mit der Zugangssperre des Gerätes • technischer Defekt während der Verwendung • Zerstörung des Gerätes oder Daten durch Unfall oder Unglück (Sturz, Stromausfall, Feuer,...) • Datenverlust durch Softwarefehler • Fehlschlag des Updates • das Update ist von Kriminellen beim Hersteller unbemerkt mit Schadsoftware („Malware") kompromittiert worden • elektronischer Einbruch in mein Gerät („Diebstahl" von Daten und Passwörtern, Verschlüsselung meiner Daten mit Erpressungsversuch) • Probleme bei der Verwendung oder mit dem Update des Betriebssystems (Windows-Nutzern durchaus vertraut)

Da kommt einiges zusammen, was mir prinzipiell Probleme machen kann. Nicht alles ist gleich wahrscheinlich, aber im Ernstfall genügt ja schon ein Ereignis, um mich in ernsthafte Schwierigkeiten zu bringen. Als Nutzer*in solcher Programme habe ich die volle Verantwortung für alles, behalte aber auch die volle Kontrolle über meine Daten und mit abnehmender Tendenz den Vorteil, nur einmal bezahlen zu müssen. Um diese Kontrolle auch sicher aufrecht zu erhalten, brauche ich Backups, Backups, Backups... (und natürlich auf mein Gerät aufpassen). Ich will sagen, ich brauche eine professionelle Backup-Strategie, nicht einfach nur, ab und an meine Daten auf einen USB-Stick kopieren. Zu erklären, was das praktisch bedeutet, würde tatsächlich den Rahmen dieses Artikels sprengen. Als Tipp sei beispielhaft auf eine der vielen Anleitungen im Netz verwiesen, die ich für verständlich halte (5). Ein Teil der Lösung kann übrigens sein, dass ich meine Daten (durchaus auch verschlüsselt) im virtuellen Laufwerk eines "Cloud"-Speicher-Anbieters (Google Drive, HiDrive, Dropbox,...) speichere, wodurch diese Daten dann automatisch im Hintergrund auf dem beim Anbieter gebuchten Speicherplatz gesichert werden. Das reicht zwar eigentlich nicht, aber ein Teil der Verantwortung ist dadurch an Profis ausgelagert. Die Wahrscheinlichkeit eines vollständigen Datenverlustes ist deutlich verringert. Und sehr schön daran ist, dass ich dafür sorgen kann, dass die Daten mein Gerät nur verschlüsselt verlassen und auch erst im Gerät wieder entschlüsselt werden.

Klassische Online WebApp

Verwende ich eine „Cloud"-basierte Online WebApp, verlagern sich bzw. verringern sich vordergründig die Gefährdungen. Denn was auch immer ich mit meinen Gerät anstelle, meine Daten sind beim Anbieter der WebApp gespeichert, und ich kann nach der Beseitigung eines Schadens bei mir oder direkt von einem anderen Gerät schnell wieder darauf zugreifen. Ich lege die Pflege und die Verbesserung des Programms sowie die Aufbewahrung und die Sicherung meiner Daten in die Verantwortung von Menschen, die das als Dienstleistung anbieten und denen ich dafür regelmäßig etwas bezahle. Damit ist die gesamte Praxis-IT entkoppelt von meinem einen alleinigen Gerät, von dessen „Gesundheit" alles abhängt. Allerdings hängt nun alles davon ab, dass diese Anbieter ihren Job wirklich umsichtig und professionell machen (technisch und juristisch). All die Gefährdungen, die ich oben für die eigene IT aufgelistet habe, bestehen natürlich auch für alle Anwendungen in der berühmt-berüchtigten Cloud. Ich sehe es nur nicht mehr. Denn es heißt zwar „Cloud" (Wolke), aber in diesem Fall ist nur der Begriff wolkig (8). Real arbeiten die Programme auf prinzipiell baugleichen Rechnern mit CPU und Arbeitsspeicher, und liegen die Daten ganz normal auf einem Datenträger (HD oder SSD) wie bei mir zuhause, alles natürlich in einer Dimension, die vollkommen unvergleichlich ist. Nur befindet sich das alles, wie schon gesagt, irgendwo in der Welt, ohne dass wir einzelnen Nutzer überhaupt wissen oder sicher sein können, wo genau. Wir müssen uns auf die Sorgfalt und die Angaben der Anbieter verlassen. Die Bespiele ganz oben beweisen, dass das leider doch nicht immer zuverlässig funktioniert. Streng genommen habe ich es nämlich mit mindestens 2 Anbietern zu tun: dem, der mir die WebApp als SaaS vermietet (s.o.), und im Hintergrund dem Infrastrukturanbieter, bei dem wiederum mein Anbieter Kunde ist (Marktführer sind hier Amazon Web Services). Ein größerer Fehler im Gesamtsystem kann zu Unerreichbarkeit meiner Anwendung führen und meine Arbeit lahmlegen. Selbst überprüfen, ob alles korrekt läuft, ist praktisch unmöglich. Sicherheit sollen uns Prüfsiegel und Zertifikate geben. Das ist auch schon wieder ein Thema für einen ganzen Artikel. Der Infrastruktur-Anbieter OVH hatte es versäumt, die Daten der Kunden unaufgefordert auf verschiedene Standorte zu spiegeln. Das mussten die Kunden gegen Aufpreis zusätzlich bestellen. Und dann brannten unerwartet die Container, in denen das Rechenzentrum eingebaut war... Die beschriebenen Daten-„Diebstähle" von außen beruhten auf Sicherheitslücken in den Systemen oder Fehlern von Mitarbeitern. Leider sind solche Sicherheitslücken und auch Fehlverhalten (z.B. der Klick in eine “verseuchte” Mail) letztlich unvermeidlich, selbst bei größter Sorgfalt. Das ist die unabänderliche Realität. Ein Anbieter kann nicht mehr tun als ein System nach Stand der Technik zu designen und zu pflegen und alle bekannten Sicherheitslücken durch Updates jeweils schnellstmöglich zu schließen. Dummerweise ist an dem Spruch, es sei nicht die Frage, ob, sondern nur, wann ein System ein ernstes Sicherheitsproblem haben wird, etwas Wahres dran. Ein weiterer Gesichtspunkt ist die Tatsache, dass bei dieser Architektur ein einziger Fehler eines Menschen genügt, dass davon Tausende oder Millionen von Nutzerinnen betroffen sind. Genauso fatal ist eine gerade sehr verbreitete Angriffstechnik, die darin besteht, Mitarbeiter dazu zu bringen, dass sie, ohne es zu merken, eine “Ransomware” in das System einschleusen, die dann alles verschlüsselt, was sie zu fassen bekommt (siehe das irische Besipiel von oben). Noch einfacher und fataler sind Angriffe von „innen" , d.h. von Mitarbeitern des Anbieters, die von Berufs wegen Zugang zu den Systemen haben (auch schon passiert). Das bringt mich auf einen weiteren Punkt. Von innen wie von außen besteht prinzipiell die Möglichkeit, die WebApp selbst mit Schadsoftware zu kontaminieren, die dann bei der Benutzung des Programms an alle gerade aktiven Nutzer über den Browser verteilt wird. Ist sie so programmiert, dass sie über eine noch unbekannte Lücke aus dem Browser „ausbricht", ist der potentielle Schaden sehr groß. Und schließlich gibt es noch eine Art des Angriffs, die nennt sich „Man-in-the-Middle"- Angriff. Das bedeutet, dass es jemandem gelingt, sich irgendwo auf der Internetwegstrecke zwischen dem Server und dem Client in meiner Praxis einzuklinken, um den Datenstrom zu manipulieren. Sei es, dass Daten “ausgeleitet” werden, Malware untergeschoben wird oder bei Offline WebApps der Programmcode verändert wird. Das ist nicht trivial, aber dennoch nicht völlig unmöglich. Deutlich erschwert wird das allerdings, seit allgemein die oben beschriebene Transportverschlüsselung verwendet wird. Zu erkennen ist es an dem Schloss-Symbol in der Adresszeile des Browsers. Diese lassen inzwischen eine unverschlüsselte Verbindung nur noch auf ausdrücklichen Wunsch der Nutzerinnen zu. Eine einzelne Nutzerin kann auch durch Angriffe auf ihren Router oder das WLAN gefährdet werden. Deshalb braucht eigentlich jeder, auch die Nutzer*innen von WebApps, zusätzlich zu den Backups der Diensteanbieter auch noch eigene Backups. M.E. sollte jede Online Software deshalb die Möglichkeit bieten, selbst manuell Sicherheitskopien der Daten herzustellen. Das muss ich dann realistischerweise aber nicht jeden Abend machen. Natürlich haben E2E-verschlüsselte WebApps die gleichen technischen Risiken. Nur der Dirbstahl der Daten ist ausgeschlossen.

Local oder Offline WebApps

Offline-WebApps sind wie oben beschrieben anders aufgebaut. Alle Datenverarbeitung geschieht im Gerät der Nutzerin. Auf meinen Geräten liegt auch immer eine Kopie der Daten in der Browserdatenbank. Die Aufgabe der Server beim Anbieter reduziert sich auf des Ausliefern des Programmcodes und das Synchronisieren der Daten zwischen den Browsern meiner Geräte. Der Anbieter hat auch einen reduzierten Aufwand mit dem Programm selbst. Er muss ausschließlich darauf achten, dass der an die Browser auszuliefernde Programmcode sauber ist, die eigentliche Programmaktivität findet dezentral auf den Geräten der Nutzerinnen statt. Die Infrastruktur ist deutlich weniger komplex und es fließen weniger Daten. Benutze ich mehrere Geräte, ist der Schlüssel auf allen diesen Geräten vorhanden und allein schon dadurch vor Verlust geschützt. Außerdem muss ein Praxisprogramm aber auch die Möglichkeit bieten, die Praxisdaten selbst unverschlüsselt auf einem externen Medium zu speichern. Im Falle eines GAU's kam ich dann zumindest den Stand meiner Daten aus dieser manuellen Sicherung mit einem neuen Schlüssel zurückübertragen. Diese Maßnahmen bilden dann alle zusammen in meinen Augen eine deutliche Erhöhung der Sicherheit bei Web Apps, auch wenn dadurch die anderen Gefahren für diese Sicherheit nicht vollständig gebannt sind. Die sorgfältige Pflege der Infrastruktur beim Anbieter bleibt auch bei offline-fähigen Web Apps sehr wichtig. Nur sind meine Daten nicht verloren, wenn es beim Anbieter doch mal crasht. Bei mir selbst sind sie dann nicht automatisch auch kaputt. Ich komme auf die Abwägung zwischen „Bequemlichkeit" und Sicherheit zurück. Eine Web App ist eindeutig komfortabler als die Gesamtverantwortung für alle Aspekte einer Praxis-IT. Gerade als selbstständiger Einzelunternehmer und Praxisbetreiber habe ich weder das Wissen, noch die Ressourcen die verwendete Hard- und Software immer mit der notwendigen Professionalität zu pflegen. Leider entstehen andere Risiken, die nicht ganz so offensichtlich sind. Eine E2E-verschlüsselte Offline first Web App bietet mir die Bequemlichkeit einer Online Anwendung, sichert mich aber ab gegenüber zwei wichtigen Risiken dieser Technik. Dafür bekomme ich die Verantwortung für einen Masterkey, den ich nicht ganz verlieren darf. Diskutieren kann man die Frage, ob die Daten aus Sicherheitsgründen (oder unter rechtlichen Gesichtspunkten) im Browser nur verschlüsselt gespeichert werden sollten. Eine Online Praxis-IT ohne die Möglichkeit einer E2E Verschlüsselung, also jeglicher Vermeidung von lesbaren Patientendaten im Netz, kommt für mich persönlich nicht wirklich in Frage. Ist damit zusätzlich eine Offline-Fähigkeit verbunden, ist ein beruhigendes zusätzliches Merkmal. In meiner Ansicht zu einer lückenlosen Verschlüsselungskette (E2EE) stehe ich in Übereinstimmung mit den allermeisten Experten für IT-Sicherheit (7, 8) bis hin zu den Richtlinien des Bundesministeriums für Wirtschaft (9). Als ich mit der Entwicklung meiner Praxis-Web App kumppani begann (ist übrigens finnisch und bedeutet "Begleiter"), gab es das so nicht. Insofern spiegelt kumppani durch seine Architektur als E2E-verschlüsselte Web App mit den genannten zusätzlichen Merkmalen unsere Antwort auf die Frage nach dem richtigen Verhältnis von Anwenderfreundlichkeit und Datensicherheit. Wie funktioniert “kumppani”? Nach dem Anlegen eines Kontos bei uns und dessen Verifikation durch die Bestätigungsmail können sich Nutzerinnen einloggen und bekommen die App dann komplett in ihren Browser geladen. Die App ruft dann die Verschlüsselungsfunktion des Browsers auf und erstellt den Schlüssel. Alle Daten sind von nun an nur noch für eine authentifizierte Nutzerin im Browser lesbar. Kumppani ist nach diesen Schritten sofort auch offline-fähig. Es empfiehlt sich, als erstes den Schlüssel zu exportieren. Zu allem gibt es übrigens ausführliche Hilfen als Texte und Videos. Die Ansicht startet mit dem Kalender. Es handelt sich um einen vollwertigen verschlüsselten Kalender, nicht nur um einen Praxisterminplan. Die sichere Verschlüsselung gilt natürlich damit auch für alle anderen Daten, die ich in der App anlege: Kontakte, Patienten, Protokolle, Rechnungen und vieles mehr. Eine Eigenschaft, die mir sehr wichtig war, ist die Art, wie Rechnungen angelegt werden. Habe ich meine Termine im Praxiskalender (und die Patientenadressen) sauber geführt, sind die Rechnungen nach Terminende praktisch fertig vorbereitet. Ein Klick und sie können gespeichert und/oder ausgedruckt werden. Zumindest das verschlüsselte Ablegen von Patienten- und Rechnungsdaten in der Browserdatenbank ist GoBD-konform, das haben wir uns von Experten der entsprechenden Zertifizierungsunternehmen bestätigen lassen. Zur Vermeidung von Schlüsselverlusten und als eine weitere Sicherungsebene für Daten bietet kumppani für beides eine Exportmöglichkeit auf einen Datenträger eigener Wahl. Das Daten-Export-Dateiformat ist xml, d.h. kompatibel mit anderen Anwendungen, die das verbreitete xml-Format verarbeiten können. Außerdem arbeiten wir aktuell an einer Lösung, den Programmcode, den wir an die Browser unserer Nutzer ausliefern, gegen Manipulationen durch unbefugte Dritte durch Signaturen und deren fortlaufende Überprüfung noch mehr abzusichern. Wer durch meine Beschreibung neugierig geworden ist, sollte mit Hilfe des unten abgedruckten Links einen eigenen Blick auf kumppani werfen. Software kann nur durch Ausprobieren wirklich beurteilt werden (10). Ganz zum Schluss noch ein Wort zur rechtlichen Situation. Die Verwendung von serverbasierten Online Anwendungen ist zulässig, solange die DSGVo eingehalten wird. Insoweit muss sich niemand mit einer deratigen Praxis-IT-Lösung Sorgen machen. Der Gesetzgeber konnte sich nicht dazu durchringen, für besonders sensible personenbezogene Daten eine lückenlose Ende-zu-Ende-Verschlüsselung vorzuschreiben. Die Autoren des Fachartikels (7) hatten das 2019 noch erwartet. Es ist anders gekommen. Die Folgen für alle Anbieter mit dieser technischen Basis wären allerdings auch sehr heftig. Völlige Neuprogrammierung wäre erforderlich. Dies war nun ein zugegebenermaßen langer Durchgang durch das Thema Datensicherheit. Wer bis hierher durchgehalten, aber noch Fragen hat, kann sich gerne an mich wenden.

Quellen:

(1) Christian Schubert „Millionen Webseiten vom Brand beim Cloud-Betreiber betroffen" https://www.faz.net/aktuell/wirtschaft/digitec/brand-bei-cloud-betreiber-millionen-von-webseiten-betroffen-17238989.html

(2) aerzteblatt.de/News 27.10.2020 „Vertrauliche Psychotherapiedaten in Finnland gehackt“ https://www.aerzteblatt.de/nachrichten/117742/Vertrauliche-Psychotherapiedaten-in-Finnland-gehackt (3) Dennis Schirrmacher „Offenbar Patienten-Daten von fast 3 Millionen Norwegern gehackt“ https://www.heise.de/newsticker/meldung/Offenbar-Patienten-Daten-von-fast-3-Millionen-Norwegern-gehackt-3945709.html

(4) Volker Brieglieb „Ransomware legt IT des irischen Gesundheitswesens lahm“ https://www.heise.de/news/Ransomware-legt-IT-des-irischen-Gesundheitswesens-lahm-6046309.html

(5) Mitch Symalla “Deine Backup-Strategie – Datensicherung für kleine Unternehmen” https://www.datenwache.de/datensicherung-kleine-unternehmen/

(6) White Paper zum Sicherheitskonzept des Filehosters Mega https://mega.nz/SecurityWhitepaper.pdf

(7) Klaus Schmeh, Udo Wichert „Mit der Keule" iX 2/2019, S.84-87

(8) Alexander Wilms “Cloud ist, wenn einer meine Daten klaut ...” https://www.doctors.today/praxis-qualitaetsmanagement/a/cloud-ist-wenn-einer-meine-daten-klaut-1790331 (9) „Kompass IT-Verschlüsselung“ Orientierungs- und Entscheidungshilfen für kleine und mittlere Unternehmen Studie im Auftrag des Bundesministeriums für Wirtschaft und Energie (BMWi) https://www.bmwi.de/Redaktion/DE/Publikationen/Studien/kompass-it-verschluesselung.pdf?__blob=publicationFile

(10) Umfassende Infos zu kumppani: https://kumppani.app Anlegen eines kostenlosen Kontos: https://abo.kumppani.app

Dr. rer.nat. Thomas Naujokat Dipl.-Psych. Dipl-Biol. Heilpraktiker für Psychotherapie in eigener Praxis Projektleiter für die Entwicklung von kumppani thomas@naujokat.de kontakt@tuuva.systems

Der Artikel ist ein Vorabdruck meines Beitrages in der Zeitschrift des vfp "Freie Psychotherapie" (zuletzt aktualisiert: 17.06.2021)