daten browserseitig verschlüsseln
0 
Felix Riesterer
1
daten browserseitig verschlüsseln
MudGuardHallo, ich stehe vor folgendem Problem:
eine medizinische Client-Server-Anwendung soll erstellt werden. Die Patienten/Befund-Daten dürfen den Anwender-PC nur verschlüsselt verlassen, d.h. sie müssen clientseitig verschlüsselt werden, dann via Transportlayerverschlüsselung auf einen Server geladen werden und in der dortige DB gespeichert werden. Die Daten dürfen ausserhalb des Client-Rechners auf keinen Fall irgendwo unverschlüsselt vorliegen. (Gescannte Dokumente oder andere personalisierte Dokumente werden zu einem Cloud-Anbieter hochgeladen, der sich auf medizinische Daten spezialisiert hat).
Das wirft für mich natürlich eine Menge Fragen auf:
-
ist das mit Webtechnologie so überhaupt machbar? Wie funktioniert zum Beispiel eine Patientensuche nach Namen? Meine serverseitige Anwendung kennt ja nur die verschlüsselten Daten. Große Teile der Logik müssen wohl daher lokal implementiert werden (Alle Patienten initial runterladen, entschlüsseln, dann lokale Suche und so weiter).
-
die Datenbankstruktur muss völlig anders aussehen, als in gewöhnlichen Fällen. Zum Beispiel ist der Patienten-Name üblicherweise ein VARCHAR 40, muss aber in der DB ein BLOB sein. Ist das bei medizinischen Daten tatsächlich so üblich?
-
wie würde der Prozess aussehen? Alle get- bzw. post-Daten müssen vor dem Absenden verschlüsselt werden. Das Password darf sich folglich nur auf dem Client-Rechner befinden. Local Storage? Oder eine selbstgestrickte Java/C#/C++-Anwendung, über der der ganze Transport läuft und dort ver- und entschlüsselt wird?
-
der Transport der Daten soll überdies über einen vpn-tunnel laufen. Ok, das ist jetzt nicht so das große Problem, denke ich.
Ich bin Student und das Projekt wäre eine große Chance für mich. Allerdings sehe ich eine Menge Fragezeichen. Ich bin jetzt an dem Punkt, wo ich sage, ich programmiere das als lokale Anwendung klassisch in C++ oder Java, allerdings ist das nicht gewünscht.
Vielleicht kennt sich jemand auf dem Gebiet medizinische Daten aus, kann mir einen Hinweis geben, wie man das vielleicht umsetzen könnte. Ich habe schon ziemlich viel recherchiert, aber auf eine mögliche Implementierung bin ich bisher noch nicht gestoßen.
Danke schonmal und beste Grüße Wolfgang
-
Lieber Fritz the Whop,
ich habe keine Ahnung. Aber Ideen hätte ich.
Wenn die Daten nur auf dem Client in entschlüsselter Form vorliegen dürfen, dann muss der Client das komplette Handling selbst leisten. Die serverseitige Speicherung in der Datenbank ist dann nur noch das, eine Speicherung. Wird der Client gestartet, muss er wohl oder übel die Daten von der DB komplett beziehen, um sie dann lokal zu entschlüsseln und für die üblichen Mechanismen wie Suche, Bearbeiten und Neuanlegen zur Verfügung zu haben. Am Ende wird alles wieder in Gänze in der DB gespeichert.
- ist das mit Webtechnologie so überhaupt machbar?
Ja. Wenn der Client so geschrieben ist, dass man sich mit Benutzernamen und Passwort anmelden muss, dann kann man aus dieser Kombination eine Passphrase erzeugen, die als Schlüssel für die Daten in der DB benutzt wird. Es gibt in JavaScript geschriebene Crypto-Bibliotheken (wie z.B. CryptoJS), mit denen das Ent- und Verschlüsseln durchgeführt werden kann.
Wie funktioniert zum Beispiel eine Patientensuche nach Namen? Meine serverseitige Anwendung kennt ja nur die verschlüsselten Daten. Große Teile der Logik müssen wohl daher lokal implementiert werden (Alle Patienten initial runterladen, entschlüsseln, dann lokale Suche und so weiter).
Das sehe ich auch so. Alles nur noch lokal implementierbar.
- die Datenbankstruktur muss völlig anders aussehen, als in gewöhnlichen Fällen. Zum Beispiel ist der Patienten-Name üblicherweise ein VARCHAR 40, muss aber in der DB ein BLOB sein. Ist das bei medizinischen Daten tatsächlich so üblich?
Wie gesagt, ich habe keine Ahnung. Ob Du die Daten überhaupt in Tabellen organisieren solltest, oder ob Du nicht lieber einen JSON-String mit der DB-Struktur des Clients in einem einzigen riesigen BLOB speicherst, kann ich nicht beurteilen.
- wie würde der Prozess aussehen? Alle get- bzw. post-Daten müssen vor dem Absenden verschlüsselt werden. Das Password darf sich folglich nur auf dem Client-Rechner befinden. Local Storage? Oder eine selbstgestrickte Java/C#/C++-Anwendung, über der der ganze Transport läuft und dort ver- und entschlüsselt wird?
So wie ich das im Moment sehe, gibt es nur einen GET-Request beim Laden direkt nach der Anmeldung und diversen POST-Requests wann immer Daten gespeichert werden, weil Änderungen gemacht wurden.
Wenn das Verschlüsseln der gesamten Daten etwas dauert, darf es ja nicht die Bedienbarkeit vorübergehend blockieren, muss also irgendwie asynchron geschehen - vielleicht in einer Art
setTimeout()-gesteuerten Weise?- der Transport der Daten soll überdies über einen vpn-tunnel laufen. Ok, das ist jetzt nicht so das große Problem, denke ich.
OK... Intranet?
Ich bin jetzt an dem Punkt, wo ich sage, ich programmiere das als lokale Anwendung klassisch in C++ oder Java, allerdings ist das nicht gewünscht.
Warum nicht? Und was spricht gegen eine Anwendung im Browser, die rein auf JavaScript basiert? Das ganze steht dann in einer einzigen HTML-Datei, die im Browser läuft. Klingt doch gut!
Liebe Grüße,
Felix Riesterer.
-
Tach!
ich habe keine Ahnung. Aber Ideen hätte ich.
Als unbeschriebenes Blatt würde ich diese Aufgabe auch als Chance sehen. Als halb beschriebenes würde ich eher abraten, solch ein Projekt im Alleingang durchzuführen, ohne auf direkte erfahrene Unterstützung bauen zu können. Das Internet ist kein Ersatz dafür. Zu sehr verschätzt man sich an der eigenen Leistungsfähigkeit. Und dann ist da auch noch der sehr sensible Bereich des Datenschutzes, der vermutlich auch noch branchenspezifische Vorschriften kennt.
Wie funktioniert zum Beispiel eine Patientensuche nach Namen? Meine serverseitige Anwendung kennt ja nur die verschlüsselten Daten. Große Teile der Logik müssen wohl daher lokal implementiert werden (Alle Patienten initial runterladen, entschlüsseln, dann lokale Suche und so weiter).
Das sehe ich auch so. Alles nur noch lokal implementierbar.
Ja, ich wüsste nicht, wie man in verschlüsselten Daten suchen könen sollte, ohne sie jeweils zu entschlüsseln, um sie mit dem Suchbegriff vergleichen zu können. Besonders wenn es sich um Teilwerte oder Schreibweisen handelt, wo andere Buchstabe oder anders geschriebene Wörter gleich eine komplett neue kodierte Zeichen-/Bytefolge ergeben.
Wenn das Verschlüsseln der gesamten Daten etwas dauert, darf es ja nicht die Bedienbarkeit vorübergehend blockieren, muss also irgendwie asynchron geschehen - vielleicht in einer Art
setTimeout()-gesteuerten Weise?Man würde sich vermutlich nicht hinsetzen, und solch eine SPA mit Vanilla-Javascript umsetzen, sondern sich ein Framework nehmen, das bereits eine grundlegene Anwendungsarchitektur mitbringt. Unter anderem den Umgang mit abzufragenden Daten. Mit setTimeout was zu basteln ist da eher ... naja. Es gibt heutzutage Promises (bereits nativ in Javascript enthalten) und Observables (in Form von RxJS zum Beispiel). Und die Web Workers API ist für Hintergrundaufgaben geschaffen worden.
Und was spricht gegen eine Anwendung im Browser, die rein auf JavaScript basiert?
Hauptsächlich sehe ich da Performance als den großen Knackpunkt an, wenn die Verschlüsslungsroutinen in Javascript geschrieben sind.
Das ganze steht dann in einer einzigen HTML-Datei, die im Browser läuft. Klingt doch gut!
Das (webpack-)Kompilat vielleicht. Eine ganze Anwendung dieser Größenordnung in nur einer Datei schreiben zu wollen, halte ich für nicht sinnvoll handhabbar. Da sucht man sich zu Tode, besonders wenn die Erfahrung fehlt, wie man menschenlesbaren Code schreibt.
dedlfix.
-
Hallo,
noch eine letze Frage in die Runde: Felix brachte Intranet auf. Die Idee finde ich grundsätzlich nicht verkehrt und hatte ich auch schon in Betracht gezogen. Leider darf auf dem Praxis-Server nichts weiter außer der praxisinternen Software installiert werden. Ich hatte mir dann überlegt, einen Mini-Server zu kaufen, der dann halt vor Ort gewartet werden muss. Von der Performance würde es wohl auch ein Beagle-Bone/Rasperry mit Speicherkarte tun.
Allerdings, großer Nachteil: bei Software-Updates oder Serverproblemen muss ich immer vor Ort sein (die Software soll an mehreren Orten unabhängig voneinandern laufen).
Was haltet ihr von der Idee eines eigenständigen Mini-Servers, der im Intranet der 4 Praxen läuft?
grüße wolfgang
-
Tach!
Leider darf auf dem Praxis-Server nichts weiter außer der praxisinternen Software installiert werden.
Das Betriebssystem inklusive Hilfsprogramme und Sicherheitslücken läuft auch auf dem Server. Hat da auch jemand spezifiziert, welche Art von Tools erlaubt sind?
Allerdings, großer Nachteil: bei Software-Updates oder Serverproblemen muss ich immer vor Ort sein (die Software soll an mehreren Orten unabhängig voneinandern laufen).
Netzwerkanbindung braucht der auch. Ob man darüber per SSH (oder RDP für Windows-Systeme) zugreifen kann oder ob man eine Konsole (Bildschirm- und Tastatur-Emulation) anschließt und über einen anderen Rechner im Netz auf diese Konsole zugreift, nimmt sich grundsätzlich nicht viel. Wenn wirklich nur ein Vor-Ort-Zugang gestattet werden sollte, erhält man meiner Meinung nach nur erhöhte Wartungskosten ohne einen signifikanten Sicherheitsgewinn.
dedlfix.
-
-
-
Hallo Felix,
danke Dir für deine Einschätzung. Ich denke aber, eine lokale Anwendung, die in JavaScript läuft, wird irgendwann zu langsam, wenn die Anzahl der Informationen steigt. Bei 20 Patienten geht es vermutlich noch, bei 2000 sieht das schon anderes aus.
Auch, wie Dedlfix das schon schrieb, da was selber zu stricken ist wohl nicht der richtige Weg. Ich dachte mir das zuerst auch, aber es gibt doch soviele Unsicherheitsfaktoren und Unbekannte, das ist mir zu heiß. Als Testprojekt würde sowas vielleicht mal Spaß machen.
Nach längerem Telefongespräch wird das Ding jetzt einfach in JAVA gebaut und läuft lokal. Sehr schade, weil ich Webtechnologie eigentlich liebe und in Zukuft auch in diesem Bereich arbeiten will.
Danke Dir und liebe Grüße Wolfgang
-
Hi,
Ja. Wenn der Client so geschrieben ist, dass man sich mit Benutzernamen und Passwort anmelden muss, dann kann man aus dieser Kombination eine Passphrase erzeugen, die als Schlüssel für die Daten in der DB benutzt wird.
Wenn der User sein Paßwort ändert, kann man nix mehr entschlüsseln. Oder man muß beim Paßwort-Ändern alles mit dem alten PW entschlüsseln und mit dem neuen PW verschlüsseln.
Und bei mehreren Usern mit unterschiedlichen Logins auf demselben Client wird's auch schwierig, wenn die Daten gemeinsam genutzt werden sollen …
cu,
Andreas a/k/a MudGuard
-
Hallo Fritz,
nimm es mir nicht übel, ich will dich nicht vor den Kopf stoßen. Aber ich würde mir an deiner Stelle ernsthaft überlegen, dieses Projekt anzugehen. Du kannst dabei so unendlich viel falsch machen… siehe auch den Talk All Your Gesundheitsakten Are Belong To Us vom 35C3.
LG,
CK-
Hallo Christian,
ich gebe Dir vollkommen recht. Seit zwei Wochen zerbreche ich mir meinen Kopf über das Thema und auch ewiges Recherchieren hat mich nicht weitergebracht. So ein Projekt ist vermutlich eher was für ein Software-Haus mit entsprechend erfahrenen Leuten aus genau diesem Bereich.
Das Ding wird jetzt als Java-Programm entwickelt und läuft nur noch lokal.
grüße Wolfgang
-