Einzelnen Beitrag anzeigen

UntoterGeist

Registriert seit: 18. Sep 2019
25 Beiträge
 
#1

SelectWhereQuery auf verschlüsselten Spalten durch Methodik beschleunigen

  Alt 13. Sep 2021, 23:41
Datenbank: postgres • Version: 13 • Zugriff über: ado
Gegeben ist: Eine Tabelle mit Personendaten, wobei die Spalten mit AES 128 verschlüsselt sind, die zur Identifikation verwendet werden könnten. Verknüpfte Daten aus anderen Tabellen spielen erstmal keine wesentliche Rolle. DBMS ist postgres und den Schlüssel kennt nur der Anwender und ist nur lokal oder im LAN verfügbar. Das Problem ist aber eigentlich allgemeiner Natur. Falls es überhaupt eine Lösungsweg gibt. Gefunden hab ich keinen richtigen.

Der Query ist reichlich simple: Abfrage einer Person dessen Name "beliebige Zeichenfolge" enthalten könnte. Also Where .. ILike .. Eine Optimierung Aufgrund der Einfachheit praktisch nicht möglich.

Ergebnis: Eine unerträglich lange Wartezeit auf das Ergebnis. Aber man kann es technisch machen.

Ursache: Jede einzelne Zeile muss entschlüsselt werden bevor sie verglichen werden kann.

Soweit sogut. Das war ja zu erwarten.

Nur die Anforderungen aus der Cybersecurity an Datensicherheit und Verfügbarkeit wiedersprechen sich da. Auf der einen Seite sollen Personenbezogene Daten geschützt sein (gut), und sie dürfen nur von berechtigten Personen gelesen werden (der technische Service, DBA oder sonstwer gehört nicht dazu), auf der anderen Seite soll es auch nicht ewig dauern bis man eine bestimmte Person findet, wenn man sie suchen sollte (nachvollziehbar). Wenn man jetzt 15.000 Personen in der Datenbank hat, was nicht wirklich viel ist, dann dauert ein Full Table Scan nach Liesschen Müller gefühlt ewig, was sonst ca. 100 ms dauern würde. Falls nicht vorher schon ein Query Timeout kommt.

Aufwand für die Umsetzung der Anforderungen ist kein Argument, sagen die die das Fordern. Dass die Security Anforderungen im medizinischen Bereich strenger gehandhabt werden sollen, ist eigentlich nicht so neu und es wird sich zeigen, was die Praxis davon überhaupt realistisch umsetzen kann. Für Legacy Software im medizinischen Bereich ist aber das Ende schon geplant. Ob es durchführbar ist oder es immer wieder Fristverlängerungen für diese gibt, ist eine andere Sache.

Jetzt müsste man mal innovativ sein.

Bei meiner Recherche hab ich eine Arbeit gefunden die sich genau damit beschäftigt hat. Also mit Personendatenbanken in medizinischen Anwendungen in denen die sensitiven Daten verschlüsselt werden müssen. Also Namen, Adressen, Befunde usw. Allerdings haben die primär in ihren Testqueries immer mit IDS gesucht. Was natürlich deutlich schneller ist. Das finden und entschlüsseln eines Datensatzes geht dann fast so schnell wie jeder andere Query. Leider ist es nicht wirklich nur ein worstcase Scenario nach einer beliebigen Person über Namensbestandteile suchen zu wollen. Es ist einfach nicht sichergestellt, dass die Software eine nehmen wir mal an in der DB nicht verschlüsselte PatientenID + PatientenDaten aus der Praxis EDV erhält (über wahrscheinlich ungesicherte Kanäle). Die Software muss trotzdem das Arbeiten ermöglichen. Kein Befund = Schaden für Patient.

Eine Lösungsstrategie die ich gefunden habe war ein Index von Hashwerten zu erstellen. Also Teilstrings zu hashen und für einen Vergleich in einer Tabelle pflegen. Allerdings kann man sich den Aufwand sparen. Ein Buchstabe (den man auch direkt in der Tabelle vorhalten kann) als Index reduziert die zwar Suchergebnisse vielleicht auf 1/15 je nach Buchstabe und Häufigkeit. Das wäre ja schon ganz gut. Aber man könnte auch gleich ein Entschlüsselungswörterbuch neben die Hashwerte legen in der alle Lösungen drin stehen, wenn man sowieso das ganze Alphabet und eventuell Kombinationen gehasht speichern muss damit es funktioniert. Kann man sich das Hashen eigentlich auch sparen und die Anfangsbuchstaben als Klartext ablegen. Da stellt sich dann aber schon die Frage: Weicht man damit dann schon die Verschlüsselung soweit auf das es nicht mehr akzeptabel ist?

Leider waren das schon alle Sachen die ich zu praktischen Lösungsansätzen gefunden habe, wie man das umsetzen könnte. Ansonsten findet man nur die Forderungen was man alles machen muss, wenn man aktuell eine Neuzulassung möchte. Und das ist sehr viel. Wenn es danach geht, würde jede Hausarztpraxis nach innen und außen Fortnox gleichen, was faktisch nicht der Fall ist. Cloud Dienste müssen das ja auch irgendwie umsetzen. Außer sie tun es einfach nicht weil sie eh im Rechenzentrum stehen und sagen ist gesichert.

Den Server an sich zu verschlüsseln schützt die Daten auch nicht vor unberechtigtem Personal. Der DBA muss nun wirklich nicht wissen wer alles Depressionen und Psychosen hat um seine Arbeit machen zu können. Bzw. wären die Daten auch nur dann sicher wenn er auch ausgeschaltet wird.

Es stellt sich mir auch die Frage wozu ich einfach keine Antwort gefunden habe: Was dauert länger viele kleine Texte einzeln entschlüsseln oder die Summe aller Texte einmalig entschlüsseln. Habe das Gefühl wenn ich es ausprobiere komme ich zumindest ansatzweise schneller zur Antwort als wenn ich nach einer Grafik oder so suche.

Leider bringt auch Limit oder Fetch nicht die Lösung. Im schlimmsten Fall sucht er dann doch bis zur letzten Zeile um Zacharias Zander in der gut sortierten Tabelle zu finden. Komischerweise haben die in ihrer Arbeit (ob das Diplom oder sonstwas war weiß ich nicht mehr) geschrieben das sie ihre Queries auf 5 Ergebnisse limitiert haben. <.<

Aber wenn ein Query jetzt 40 Sekunden dauert, ist das eigentlich keine zumutbare Lösung für die Praxis. Kann man eigentlich nur mit vorhergehender Warnung ausführen. Muss der Doc dann halt die PatientenID aufschreiben und mit in den Behandlungsraum nehmen, wenn er sich die nicht merken kann. Im wesentlichen darf man wohl zumindest diese Nummer nicht verschlüsseln. Sonst hat man nicht mal im automatisierten Fall der Patietenzuweisung eine Chance.

Ich glaub ich hab immer nur ganz komplizierte oder als unlösbar deklarierte Probleme.
  Mit Zitat antworten Zitat