-
Die Erfindung betrifft ein System zur Speicherung von Daten, umfassend eine Schnittstelle, ein Berechtigungsmodul, mindestens eine Zieldatenbank und mindestens ein Datenzugriffsmodul. Des Weiteren betrifft die Erfindung ein Verfahren zur Speicherung von entsprechenden Daten mittels eines entsprechenden Systems.
-
Im medizinischen Sektor ist das Speichern von Daten hochgradig problematisch. Die Daten sind häufig personenbezogen und sehr sensibel. Gleichzeitig besteht der Bedarf, dass entsprechende Daten für diverse Personenkreise und Anwendungen zur Verfügung stehen. Sowohl das Stellen einer zutreffenden Diagnose sowie die erfolgreiche Behandlung von Krankheiten erfordern belastbare Daten. Auch für die Weiterentwicklung von medizinischen Algorithmen ist es notwendig, dass Daten, insbesondere langfristig, zur Verfügung stehen.
-
Im Gesundheitswesen sind daher übergreifende Systeme in der Entwicklung, die entsprechende Daten, insbesondere auch personenbezogene Daten, zur Verfügung stellen.
-
Die Verwaltung derartiger personenbezogener Daten ist aufwändig, da unterschiedliche Regeln und Gesetze zum Umgang mit diesen Daten existieren. Diese Regeln und Gesetze betreffen die Form der Speicherung, deren Aufbewahrungsfrist sowie deren Verwendung für unterschiedliche Anwendungszwecke.
-
Weiterhin ist die Anbindung von unterschiedlichen Anwendungen an derartige Systeme zur Speicherung von Daten aufwändig. In vielen der bestehenden Anwendungen und Systeme wird versucht, notwendige Algorithmen zur Einhaltung des Datenschutzes lokal - d. h. in der jeweiligen Anwendung - zu implementieren, wobei dieser Ansatz sehr aufwändig ist. Neuere Systeme setzen auf eine zentrale Datenverwaltung, wobei das Anbinden von bestehenden Anwendungen technisch aufwändig ist. Häufig ist es notwendig, dass die bestehenden Anwendungen vollständig neu implementiert werden müssen.
-
In der
US 10 572 684 B2 ist ein System beschrieben, bei dem personenbezogene Daten in einer verteilten Datenbank, vorzugsweise in einer Blockchain gespeichert werden. Die
EP 1 226 524 A2 beschreibt ein System, bei dem Daten zwischen Entitäten freigegeben werden können. Mit diesem System ist es auch möglich, Daten für das Gesundheitssystem freizugeben, wobei die Datensicherheit durch Verschlüsselung und entsprechende Zertifikate gewährleistet ist.
-
Die
EP 2 656 274 B1 beschreibt ein System zum Austausch bzw. Zurverfügungstellung von Dokumenten. Das System implementiert eine Zugangsbeschränkung, die es ermöglicht, persönliche Daten zu schützen.
-
Das Dokument „PostgreSQL Anonymizer, Dynamic Masking", Dalibo SARL SCOP, 2022, URL: https://postgresqlanonymizer.readthedocs.io/en/stable/dynamic_masking/P1 betrifft die Erweiterung „postgresql_anonymizer“ des Opensource-Datenbankmanagementsystems PostgreSQL. Konkret beschreibt das Dokument einen dynamischen Maskierungsansatz, der es erlaubt, einen Benutzer bzw. eine Rolle für maskierten Zugriff auf eine Datenbank zu kennzeichnen. Dabei können Maskierungsregeln für bestimmte Tabellen festgelegt werden. Eine Anfrage eines Benutzers, der nur eine eingeschränkte Berechtigung bezüglich der angefragten Tabelle der Datenbank besitzt, wird mit einem maskierten bzw. anonymisierten Datensatz statt des tatsächlichen Datensatzes beantwortet. Dies wird durch das Erstellen von Ansichten (Views) realisiert.
-
Das Dokument „PostgreSQL Anonymizer, Static Masking", Dalibo SARL SCOP, 2022. URL: https://postgresqlanonymizer.readthedocs.io/en/stable/static_masking betrifft ebenfalls die Erweiterung „postgresql_anonymizer“. Dieses Dokument beschreibt einen statischen Maskierungsansatz für PostgreSQL, bei dem die Originaldaten mit maskierten bzw. anonymisierten Daten unwiederbringlich überschrieben werden.
-
Der Wikipedia-Artikel „Java Database Connectivity", URL https://en.wikipedia.org/w/index.php?title=Java_Database_Connectivity&oldid=11 38424183 beschreibt eine API für die Programmiersprache Java, die einen definierten Zugriff eines Clients auf eine relationale Datenbank erlaubt.
-
Die Wikipedia-Artikel „Database“, URL:
- https://en.wikipedia.org/w/index.php?title=Database&oldid=1148834229 und „Database encryption“ URL:
- https://en.wikipedia.org/w/index.php?title=Database_encryption&oldid=11327770 51 beschreiben allgemeine Grundlagen zu verschiedenen Typen von Datenbanksystemen und zur Verschlüsselung von Datenbanken.
-
Ausgehend von diesem Stand der Technik, insbesondere von dem oben genannten Dokument „PostgreSQL Anonymizer, Dynamic Masking“, ist es Aufgabe der vorliegenden Erfindung, ein effizientes und sicheres System zur Speicherung von Daten zu schaffen. Insbesondere soll es das System ermöglichen, bestehende Anwendungen einfach und effizient einzubinden.
-
Die Aufgabe wird durch ein System gemäß Anspruch 1, durch ein Verfahren gemäß Anspruch 10 sowie einen computerlesbaren Speicher nach Anspruch 11 gelöst.
-
Insbesondere wird die Aufgabe durch ein System zur Speicherung von Daten, insbesondere von personenbezogenen Daten, gelöst, das umfasst:
- - eine Schnittstelle, insbesondere eine REST API;
- - ein Berechtigungsmodul;
- - mindestens eine Zieldatenbank zur Speicherung der Daten;
- - ein Konfigurationsverwaltungsmodul; und
- - ein Datenzugriffsmodul, das dazu ausgebildet ist,
- a) Anfragen eines Client-Computers mittels der Schnittstelle zu empfangen;
- b) in Reaktion auf die empfangene Anfrage Daten von der mindestens einen Zieldatenbank abzufragen;
- c) festzustellen, ob eine Berechtigung zum Abfragen seitens des Client-Computers und/oder des Benutzers besteht; und
- d) zur Beantwortung der Anfrage einen Antwortdatensatz zu generieren und an den Client-Computer zu übermitteln, wobei zumindest einige Daten des Antwortdatensatzes anonymisiert sind, wenn festgestellt wird, dass eine eingeschränkte Berechtigung besteht.
-
Dabei ist das Berechtigungsmodul dazu ausgebildet,
- - der Anfrage eine Rolle und/oder einen Benutzer zuzuordnen;
- - festzustellen, ob die Zieldatenbank eine relationale Datenbank ist;
- - wenn die Zieldatenbank eine relationale Datenbank ist, unter Verwendung der Rolle bzw. von Angaben zu dem Benutzer eine Ansicht aus einer Vielzahl von Ansichten auszuwählen, die verwendet wird, um die Anfrage zu beantworten;
- - festzustellen, ob die Zieldatenbank eine Hashdatenbank ist; und
- - wenn die Zieldatenbank eine Hashdatenbank ist, unter Verwendung der Rolle bzw. von Angaben zu dem Benutzer eine Kopie-Hashdatenbank aus einer Vielzahl von Kopie-Hashdatenbanken auszuwählen, die verwendet wird, um die Anfrage zu beantworten.
-
Dabei ist das Konfigurationsverwaltungsmodul dazu ausgebildet,
- - für unterschiedliche Benutzer und/oder Rollen in Abhängigkeit von vorgegebenen und/oder zugeordneten Berechtigungen, für eine relationale Zieldatenbank die Ansichten für mindestens eine Zieltabelle zu generieren und abzuspeichern, wobei die Ansicht in Abhängigkeit von den Berechtigungen so konfiguriert ist, dass Werte aus der Zieltabelle mit anonymisierten Werten ersetzt sind; und
- - für unterschiedliche Benutzer und/oder Rollen in Abhängigkeit von vorgegebenen und/oder zugeordneten Berechtigungen für eine (verteilte) Ziel-Hashdatenbank, die als Zieldatenbank verwendet wird, rollenspezifische Kopien in Form einer Kopie-Hashdatenbank zu generieren und abzuspeichern, wobei die Kopie-Hashdatenbank in Abhängigkeit von den Berechtigungen so geändert ist, dass (selektiv) Werte aus der Ziel-Hashdatenbank mit anonymisierten Werten ersetzt sind.
-
Ein Gedanke der vorliegenden Erfindung besteht darin, die Daten in (zentralen) Zieldatenbanken zu speichern. Den Zieldatenbanken ist ein (Zentral-) Datenzugriffsmodul vorgeschaltet, das den Zugriff auf die Daten verwaltet. Welche Anwendung auf welche Daten zugreifen kann, wird durch das Berechtigungsmodul geregelt. Mit der Erfindung ist es somit nicht mehr möglich, dass Anwendungen direkt auf die Daten zugreifen. Stattdessen muss ein Zugriff über das Datenzugriffsmodul erfolgen, welches Anfragen, beispielsweise von Client-Computern, über eine vorzugsweise vordefinierte Schnittstelle empfängt. Die angefragten Daten können dann zumindest teilweise von den Zieldatenbanken abgefragt werden. Wie bereits erläutert, wird überprüft, ob und in welchem Umfang eine Berechtigung für den Zugriff auf die abgefragten bzw. angefragten Daten besteht. Eine entsprechende Zugriffsregelung kann benutzer- und/oder rollen- und/oder gerätebasiert sein, wobei, wie in gängigen Betriebssystemen üblich, einzelnen Anwendungen Benutzerkonten zugeordnet werden können. Erfindungsgemäß sind auch andere bekannte Berechtigungskonzepte denkbar.
-
Das Datenzugriffsmodul ist erfindungsgemäß dazu ausgebildet, zur Beantwortung der Anfrage einen Antwort-Datensatz zu generieren und an den Client-Computer zu übermitteln, wobei einzelne der Daten des Antwort-Datensatzes anonymisiert sind. Eine entsprechende Anonymisierung kann online - d. h. zum Zeitpunkt der Abfrage - oder offline - zu einem Zeitpunkt vor der Anfrage, beispielsweise beim Erfassen der Daten oder innerhalb einer nächtlichen Routine - erfolgen.
-
In einer Ausführungsform der Erfindung handelt es sich bei der Schnittstelle, die zum Abfragen und/oder Bereitstellen der Daten genutzt wird, um eine Schnittstelle, die REST (engl.: „Representational State Transfer“) -basiert ist. Eine entsprechende REST-API kann als Webservice implementiert sein und ermöglicht das effiziente Abwickeln von Anfragen.
-
In einer Ausführung umfasst das System einen, insbesondere auf mindestens einem Client-Computer installierten, Datenbanktreiber, der dazu eingerichtet ist, mit der Schnittstelle zu kommunizieren. Ein entsprechender Datenbanktreiber kann ein JDBC-Treiber sein. Auf vielen der bestehenden Betriebssysteme existieren sehr ausgeklügelte Datenbankzugriffsmodule. Viele dieser Datenbankzugriffsmodule sind ODBC-basiert. Somit greifen Anwendungen auf Client-Computern nicht direkt auf die Datenquelle zu, sondern nutzen installierte ODBC-Treiber, um einen entsprechenden Zugriff zu implementieren. Im Vergleich zu den herkömmlichen ODBC-Treibern sind REST-APIs relativ neu. Die Erfindung sieht es vor, ODBC-Treiber, insbesondere JDBC-Treiber bereitzustellen, die es Anwendungen ermöglichen, über diese Treiber mit der Schnittstelle des erfindungsgemäßen Systems zu kommunizieren. Somit ist deren Zugriff auf das System klar strukturiert und bestehende Anwendungen können mittels der ODBC-Treiber bzw. JDBC-Treiber mit dem System kommunizieren. Der Aufwand für eine Migration ist somit denkbar gering, insbesondere, wenn man bedenkt, dass sich das erfindungsgemäße System trotz der zusätzlichen Funktionalitäten des Berechtigungs- und des Datenzugriffsmoduls wie eine herkömmliche Zieldatenbank verhalten kann.
-
In einer Ausführungsform umfasst das Datenbankzugriffsmodul eine Parsereinheit, die dazu ausgebildet ist, eine Zeichenkette mit einem SQL-Ausdruck zu empfangen und aus dem SQL-Ausdruck Feldnamen zu extrahieren. In dem Datenbankzugriffsmodul können weiterhin Konfigurationen auf die SQL-Abfrage angewandt werden.
-
Es ist möglich, den Datenbanktreiber derart zu implementieren, dass dieser weitestgehend automatisch eine SQL-Anfrage in eine Anfrage, die an die Schnittstelle übermittelt wird, übersetzt. In einer Ausführungsform erfolgt beispielsweise die Übersetzung der SQL-Anfrage in eine Anfrage, die konform ist mit einem REST-Standard. In einer Ausführungsform wird hierfür eine Parsereinheit eingesetzt, die beispielsweise Tabellennamen und/oder Spaltennamen aus dem SQL-Ausdruck oder der ODBC-Anfrage extrahiert. Diese Daten können dazu verwendet werden, um über die Schnittstelle spezifische Datenanfragen zu erstellen. Beispielsweise kann per HTTP eine GET-Anfrage abgesetzt werden, bei der die Tabellennamen und/oder Spaltennamen die abzufragende Ressource adressieren.
-
In einer (anderen) Ausführungsform wird die SQL-Anfrage als Zeichenkette in eine REST-Anfrage bzw. einen REST-Aufruf gekapselt, die an die Schnittstelle gesandt wird.
-
In einer Ausführungsform umfasst das System eine Datenbank, die eine Vielzahl von Rollen und/oder Benutzern speichert, wobei den Rollen/Benutzern jeweils Berechtigungen zugeordnet sind. Es ist möglich, das Berechtigungskonzept der einzelnen Zieldatenbanken zu verwenden, um dem System, insbesondere dem Berechtigungsmodul eine Zugriffsverwaltung zu ermöglichen. In einer bevorzugten Ausführungsform wird eine (gesonderte) Datenbank verwendet, um Zieldatenbanken übergreifend Rollen und/oder Benutzer zu verwalten und diesen jeweils Berechtigungen zuzuordnen.
-
Das Berechtigungsmodul kann dazu ausgebildet sein, zumindest eine Auswahl von Anfragen, die mittels der Schnittstelle empfangen werden, jeweils mindestens einer Rolle bzw. einem Benutzer aus der Datenbank zuzuordnen und basierend auf der zugeordneten Berechtigung festzustellen, welche Daten in Antwort auf die jeweilige Anfrage mittels der Schnittstellen übermittelt werden.
-
In einer Ausführungsform kann das Berechtigungsmodul entscheiden, dass einem Benutzer oder einer Rolle der Zugriff auf bestimmte Daten gänzlich verweigert wird. In einer (anderen) Ausführungsform haben die Berechtigungen darauf Einfluss, welche Zieldatenbank und/oder welche Unterkomponenten (beispielsweise Tabellen und/oder Views bzw. Ansichten) einer bestimmten Zieldatenbank abgefragt werden. Erfindungsgemäß ist es auch möglich, dass basierend auf der Berechtigung mindestens eine Anonymisierungsfunktion ausgewählt wird, um bestimmte Daten aus einer Zieldatenbank (online) zu anonymisieren.
-
Das Konfigurationsverwaltungsmodul ist dazu ausgebildet, für unterschiedliche Benutzer und/oder Rollen in Abhängigkeit von vorgegebenen und/oder zugeordneten Berechtigungen, Zieldatenbanken und/oder Ansichten (z. B. sogenannte SQL-Views) zu generieren und abzuspeichern.
-
In einer Ausführungsform gibt es für einen originären Datensatz jeweils mehrere Zieldatenbanken und/oder Ansichten, wobei sich die einzelnen Zieldatenbanken und/oder Ansichten darin unterscheiden, dass sie unterschiedlich stark anonymisiert sind. Beispielsweise kann eine erste Ansicht die vom Konfigurationsverwaltungsmodul originär erfassten Daten ausgeben, eine zweite Ansicht zeigt nur einen Teil der originär erfassten Daten, wobei beispielsweise Datensätze entfernt wurden und/oder Einträge anonymisiert sind.
-
Diese Ausführungsform erfolgt also eine Offline-Anonymisierung, wobei die Daten ggf. dupliziert oder aufgrund von unterschiedlichen Ansichten unterschiedlich ausgegeben werden. Dieser Ansatz hat den Vorteil, dass Anfragen sehr performant beantwortet werden können. Weiterhin ist es möglich, die Zustände und somit die unterschiedlichen Anonymisierungsgrade der einzelnen Tabellen/Ansichten/Felder zu erfassen und somit zu dokumentieren.
-
Wie bereits erläutert, kann das System dazu ausgebildet sein, für Anfragen auf der Schnittstelle eine Zieldatenbank aus einer Vielzahl von Zieldatenbanken auszuwählen, die die Daten zur Beantwortung der Anfrage enthält.
-
Das Berechtigungsmodul ist dazu ausgebildet,
- a) der Anfrage eine Rolle und/oder einen Benutzer zuzuordnen;
- b) festzustellen, ob die Zieldatenbank eine relationale Datenbank ist; und
- c) wenn die Zieldatenbank eine relationale Datenbank ist, unter Verwendung der Rolle bzw. unter Verwendung von Angaben zu dem Benutzer eine Ansicht bzw. eine View aus einer Vielzahl von Ansichten auszuwählen;
- d) die ausgewählte View/Ansicht zu verwenden, um die Anfrage zu beantworten.
-
Die Verwendung von Ansichten/Views hat den Vorteil, dass zumindest in Bezug auf SQL-Datenbanken die Daten nicht beliebig dupliziert werden, während gleichzeitig ein effektives Zugriffskonzept implementiert werden kann.
-
Das Konfigurationsverwaltungsmodul ist dazu ausgebildet, für unterschiedliche Benutzer und/oder Rollen in Abhängigkeit von vorgegebenen und/oder zugeordneten Berechtigungen für eine (verteilte) Ziel-Hashdatenbank, die als Zieldatenbank verwendet wird, Kopien zu generieren und abzuspeichern. Die so erstellten Kopie-Hashdatenbanken können vergleichbar mit den bereits erläuterten Ansichten bzw. SQL-Tabellen unterschiedliche Anonymisierungsgrade aufweisen.
-
In einer Ausführungsform besteht eine Korrelation zwischen unterschiedlichen Berechtigungen und unterschiedlichen Ziel-Hashdatenbanken. In einer Ausführungsform gibt es Korrelationen zwischen unterschiedlichen Rollen und den Kopie-Hashdatenbanken. Es handelt sich also um rollenspezifische Kopien.
-
Als Hashdatenbank im Sinne der vorliegenden Erfindung wird eine Nicht-SQLbasierte Datenbank bezeichnet. Es kann sich hierbei um eine Datenbank handeln, die Schlüssel-Werte-Paare speichert. Bei der Hashdatenbank kann es sich um eine verteilte Datenbank, beispielsweise wie die DynamoDB® von Amazon, handeln. Entsprechende Hashdatenbanken sind hinsichtlich der Beantwortung von Anfragen hoch performant. Durch das Erzeugen der Kopien wird diese Performance nicht beeinträchtigt. Durch ein geschicktes Verteilen der einzelnen Kopien auf unterschiedliche Server kann die Performance des Systems weiter erhöht werden.
-
Das System ist dazu ausgebildet, für Anfragen auf der Schnittstelle eine Zieldatenbank aus einer Vielzahl von Zieldatenbanken auszuwählen, die die Daten zur Beantwortung der Anfrage enthält. In diesem Zusammenhang kann das Berechtigungsmodul weiterhin dazu ausgebildet sein,
- a) der Anfrage eine Rolle und/oder einen Benutzer zuzuordnen;
- b) festzustellen, ob die Zieldatenbank eine Hashdatenbank ist; und
- c) wenn die Zieldatenbank eine Hashdatenbank bzw. eine Hashtabelle ist, unter Verwendung der Rolle bzw. von Angaben zu dem Benutzer eine Kopie-Hashdatenbank aus einer Vielzahl von Kopie-Hashdatenbanken auszuwählen, die verwendet wird, um die Anfrage zu beantworten.
-
In einer (bevorzugten) Ausführungsform existieren SQL-Datenbanken und Nicht-SQL-Datenbanken, insbesondere Hash-Datenbanken, parallel nebeneinander. Die Anonymisierung der SQL-Datenbanken erfolgt in diesem Zusammenhang gemäß unterschiedlichen Ansätzen. Beispielsweise können die SQL-Datenbanken durch das Bereitstellen von unterschiedlichen Ansichten und die Nicht-SQL-Datenbanken durch das Duplizieren einzelner Daten (vgl. Kopie-Hashdatenbanken) anonymisiert werden. Das System kennt zumindest diese beiden Anonymisierungsansätze und ermittelt bei der Beantwortung einer Anfrage die Entität (Ansicht oder Kopie), die bei gegebener Berechtigung zu verwenden ist. Somit können trotz der notwendigen Anonymisierung unterschiedliche Datenbank-Implementierungen verwendet werden. Die unterschiedlichen Datenbank-Implementierungen können insbesondere darauf abgestimmt sein, wie die Daten am effizientesten gespeichert und abgefragt werden können. Unabhängig von der konkreten Implementierung der jeweiligen Datenbank kann somit ein notwendiger Datenschutz umgesetzt werden. Die konkrete Technologie, die zur Implementierung der jeweiligen Datenbanken verwendet wird, ist für den Zugriff von außen (über die Schnittstellen) nicht transparent, sodass ein einheitlicher Zugriff erfolgen kann.
-
In einer Ausführungsform umfasst das System ein Datensammel-Kontextmodul, das dazu ausgebildet ist, zu mindestens einer Auswahl von Datensätzen auf der mindestens einen Zieldatenbank Datensammel-Kontext zu speichern. Bei dem Datensammel-Kontext kann es sich beispielsweise um einen Zeitpunkt der Erfassung der Daten, eine Zielsetzung der Datenerfassung, einen Datenaufbewahrungszeitraum, eine Rechtsgrundlage für die Datenerfassung, Angaben zu zugehörigen Aufbewahrungsrichtlinien etc. handeln. Durch die Erfassung des Datensammel-Kontextes ist es möglich, basierend auf diesen Daten unterschiedliche Formen der Anonymisierung einzuleiten. Auch können teil- oder vollautomatisierte Aufbewahrungsrichtlinien von einzelnen Daten umgesetzt werden. Hierzu kann das System, insbesondere das Konfigurationsverwaltungsmodul, dazu ausgebildet sein, basierend auf dem Datensammel-Kontext Daten auszuwählen und die ausgewählten Daten in einer anonymisierten Form zu speichern.
-
In einer Ausführungsform sind zumindest einige der Daten mindestens einer Zieldatenbank verschlüsselt, wobei das System dazu ausgebildet ist, einen Sicherheitstoken zu empfangen und anhand des Sicherheitstokens zu bestimmen, ob der die Anfrage abgebende Client-Computer berechtigt ist, mit dem System zu kommunizieren und/oder die abgefragten Daten zu erhalten. Hierfür kann eine Schlüssel-Datenbank vorgesehen sein, wobei das System dazu ausgebildet ist, unter Verwendung der Schlüssel-Datenbank einen Schlüssel auszuwählen, der verwendet wird, um verschlüsselte Daten insbesondere von der mindestens einen Zieldatenbank zu entschlüsseln.
-
Das erfindungsgemäße System kann somit auch eine Schlüsselverwaltungsfunktion wahrnehmen, wobei sich ein abfragender Client-Computer/Benutzer gegenüber dem System authentifiziert und das System in Abhängigkeit des eigenen Berechtigungskonzepts Schlüssel für den Zugriff auf einzelne verschlüsselnde Daten in den Zieldatenbanken auswählt. Mittels des bereits beschriebenen Treibers und des erfindungsgemäßen Systems ist es somit auch möglich, für ältere Anwendungen, die auf den Client-Computern laufen, ein Berechtigungssystem zu implementieren, das einheitlich über alle Zugriffsanfragen umgesetzt wird.
-
Die eingangs genannte Aufgabe wird des Weiteren durch ein Verfahren zur Beantwortung mindestens einer Anfrage mittels eines Antwortdatensatzes gelöst, wobei das Verfahren die folgenden Schritte umfasst:
- a) Empfangen mindestens einer Anfrage über eine Schnittstelle, insbesondere eine REST-API;
- b) Zuordnen einer Rolle und/oder eines Benutzers zu der Anfrage;
- c) Abfragen von Daten von mindestens einer Zieldatenbank in Reaktion auf die empfangene Anfrage;
- d) Feststellen, ob die Zieldatenbank eine relationale Datenbank ist, wobei für eine relationale Zieldatenbank für unterschiedliche Benutzer und/oder Rollen in Abhängigkeit von vorgegebenen und/oder zugeordneten Berechtigungen Ansichten für mindestens eine Zieltabelle generiert und abgespeichert sind, wobei die Ansicht in Abhängigkeit von den Berechtigungen so konfiguriert ist, dass Werte aus der Zieltabelle mit anonymisierten Werten ersetzt sind;
- e) Feststellen, ob die Zieldatenbank eine Hashdatenbank ist, wobei für eine Ziel-Hashdatenbank für unterschiedliche Benutzer und/oder Rollen in Abhängigkeit von vorgegebenen und/oder zugeordneten Berechtigungen rollenspezifische Kopien in Form einer Kopie-Hashdatenbank generiert und abgespeichert sind, wobei die Kopie-Hashdatenbank in Abhängigkeit von den Berechtigungen so geändert ist, dass (selektiv) Werte aus der Ziel- Hashdatenbank mit anonymisierten Werten ersetzt sind;
- f) Feststellen, ob eine Berechtigung zum Abfragen seitens des Client-Computers und/oder des Benutzers besteht; und
- g) Übermitteln mindestens eines Antwortdatensatzes zur Beantwortung der Anfrage, wobei zumindest einige Daten des Antwortdatensatzes anonymisiert sind, wenn festgestellt wird, dass eine eingeschränkte Berechtigung besteht.
-
Dabei wird, wenn die Zieldatenbank eine relationale Datenbank ist, unter Verwendung der Rolle bzw. von Angaben zu dem Benutzer eine Ansicht aus einer Vielzahl von Ansichten ausgewählt wird, die verwendet wird, um die Anfrage zu beantworten.
-
Ferner wird, wenn die Zieldatenbank eine Hashdatenbank ist, unter Verwendung der Rolle bzw. von Angaben zu dem Benutzer eine Kopie-Hashdatenbank aus einer Vielzahl von Kopie-Hashdatenbanken ausgewählt wird, die verwendet wird, um die Anfrage zu beantworten.
-
Für das Verfahren ergeben sich Vorteile, wie diese bereits in Verbindung mit dem System erläutert wurden. Das Verfahren kann auf dem bereits erläuterten System ausgeführt werden. Es ergeben sich durch die Beschreibung des Systems implizite Verfahrensschritte für das erfindungsgemäße Verfahren, die dieses in unterschiedlichen Ausführungsformen näher bestimmen.
-
Die eingangs genannte Aufgabe wird weiterhin durch einen computerlesbaren Speicher mit Instruktionen zur Implementierung des bereits genannten Verfahrens gelöst, insbesondere wenn die Instruktionen auf mindestens einer Recheneinheit ausgeführt werden. Auch hier ergeben sich ähnliche Vorteile, wie diese bereits in Verbindung mit den erfindungsgemäßen Systemen beschrieben wurden.
-
Weitere vorteilhafte Ausführungsformen ergeben sich anhand der Unteransprüche.
-
Nachfolgend wird die Erfindung mittels mehrerer Ausführungsbeispiele beschrieben, die anhand von Abbildungen näher erläutert werden. Hierbei zeigen:
- 1 eine schematische Darstellung des erfindungsgemäßen Systems, das kommunikativ über das Internet mit einem Client-Computer in Verbindung steht;
- 2 eine schematische Detaildarstellung des erfindungsgemäßen Systems gemäß 1; und
- 3 eine schematische Darstellung von unterschiedlich anonymisierten Daten.
-
In der nachfolgenden Beschreibung werden für gleiche und gleichwirkende Teile dieselben Bezugsziffern verwendet.
-
1 zeigt einen Client-Computer 10, der über das Internet 1 kommunikativ mit einem Ausführungsbeispiel des erfindungsgemäßen Systems 100 verbunden ist.
-
In dem gezeigten Abstrahierungsgrad umfasst das System 100 eine relationale Datenbank 30 sowie eine Hash-Datenbank, beispielsweise eine DynamoDB®-Datenbank von Amazon.
-
Auf dem Client-Computer 10 können unterschiedliche Anwendungen installiert sein, die üblicherweise über eine ODBC-Schnittstelle mit einer Datenbank kommunizieren. In dem gezeigten Ausführungsbeispiel ist ein Datenbanktreiber 12 vorgesehen, der es den Anwendungen ermöglicht, über einen JDBC-Treiber mit einer REST-API 105 (vgl. 2) des Systems 100 zu kommunizieren.
-
2 zeigt das System 100, wobei schematisch einige Softwarekomponenten hervorgehoben sind. Diese Softwarekomponenten umfassen:
| Komponentenname | Komponentenbeschreibung |
| Datenimport-Modul („Data Import Module“) | Komponente, die für die Unterstützung zuständig ist: |
| - Authentifizierung von externen Datenlieferanten (z. B. Krankenhaussysteme) |
| - Verschlüsselung von Daten, die von externen Datenanbietern bereitgestellt werden |
| - Empfang und Speicherung von Daten, die von externen Datenanbietern bereitgestellt werden |
| Datenexport-Modul („Data Export Module“) | Komponente, die für die Unterstützung zuständig ist: |
| - Authentifizierung der externen Systeme, denen Daten zur Verfügung gestellt werden |
| - die Verschlüsselung von Daten, die externen Systemen zur Verfügung gestellt werden, |
| - Bereitstellung von persistierten Daten für externe Systeme |
| Datenfluss-Module („Data Flow Module“) | Komponente, die verantwortlich ist für: |
| - die Ausführung von Datenflüssen zwischen verschiedenen Datenspeichern |
| - Unterstützung der Konfigurierbarkeit solcher Datenflüsse, soweit zutreffend |
| - Unterstützung der operativen Überwachung und Verwaltung solcher Datenflüsse |
| Datenflüsse zwischen den folgenden Datenspeichern werden von dieser Komponente verwaltet: |
| - Datenspeicher, die vom Datenimportmodul verwendet werden |
| - Datenspeicher, die vom Datenexportmodul verwendet werden |
| werden - SQL-Datenbank |
| | - Hash-Datenbank |
| Datenzugriffs-Modul („Data Access Module“) | Komponente, die den Datenzugriff implementiert und eine Anonymisierung unterstützt. Diese Komponente greift auf Daten zu, indem sie in einer Ausführungsform immer dieselben Schritte nacheinander durchführt und dabei die folgenden Punkte berücksichtigt: |
| - Datenerfassungskontext des Datenzugriffs |
| - Datenautorisierung, sicherheits- und datenschutztechnische Konfigurationen des Datenzugriffs |
| - auf den Datenzugriff anzuwendende sicherheitstechnische Logik |
| - auf den Datenzugriff anzuwendende Logik der Datenschutztechnik |
| - für den Datenzugriff anzuwendende Prüfpfade |
| - physische Datenzugriffsoperationen für SQL- und Hash-Datenbanken |
| Diese Komponente delegiert einen Großteil ihrer Funktionalität über ihre definierten Endpunkte an die entsprechenden Module. |
| SQL-Datenbank-Proxy („FRAPPiD based Application SQL Data Store Proxy“) | Komponente, die Aufrufe an SQL-Datenbank abfängt, um den Datenzugriff über die Logik des „Datenzugriffsmoduls“ zu leiten. Diese Komponente kann clientseitige Abhängigkeiten (z. B. Bibliotheken, Pakete, Module) für die unterstützten Laufzeiten (z. B. JVM, .NET, Python) und Betriebssysteme (z. B. Windows ".dll", Linux ".so", ".a") erfordern. |
| Nicht-SQL-Datenbank-Proxy („FRAPPiD based Application NoSQL Data Store Proxy“) | Komponente, die Aufrufe an Nicht-SQL-Datenbanken abfängt, um den Datenzugriff über die Logik des „Data Access Module“ zu leiten. Diese Komponente kann clientseitige Abhängigkeiten (z. B. Bibliotheken, Pakete, Module) für die unterstützten Laufzeiten (z. B. JVM, .NET, Python) und Betriebssysteme (z. B. Windows ".dll", Linux ".so", ".a") erfordern. |
| SQL-Datenbank („FRAPPiD based Application SQL Data Store“) | Komponente, die Daten von Anwendungen in einem der unterstützten SQL-Datenspeicher speichert. Der Zugriff auf diese Komponente erfolgt fast ausschließlich über das „Data Access Module“. |
| Hash-Datenbank ("FRAPPiD based | Komponente, die Daten von Anwendungen in einem der unterstützten Nicht-SQL-Datenspeicher, z.B. einer |
| Application NoSQL Data Store") | Hashdatenbank, speichert. Der Zugriff auf diese Komponente erfolgt in einer Ausführungsform (fast) ausschließlich über das Datenzugriffs-Modul. |
| Datensammel-Kontextmodul („Data Collection Context Module“) | Komponente, die verantwortlich ist für die Bereitstellung von: |
| - Datensammel-Kontext |
| - Management UI zur Verwaltung der Datenerfassungskontextdaten |
| - Persistenz der Datenerfassungskontextinformationen |
| Die Rechtsgrundlage für die Datenerhebung kann unter anderem Folgendes umfassen: |
| - Datenattribute im Zusammenhang mit der Einwilligung der betroffenen Person |
| - Datenattribute im Zusammenhang mit der Datenverarbeitungsvereinbarung mit dem für die Datenverarbeitung Verantwortlichen |
| - Datenattribute im Zusammenhang mit einer rechtlichen Verpflichtung, die die Datenerhebung vorschreibt |
| - Datenattribute im Zusammenhang mit dem lebenswichtigen Interesse der betroffenen Person |
| - Datenattribute im Zusammenhang mit dem öffentlichen Interesse |
| Konfiguarationsverwaltungsmodul („Configuration Management Module“) | Komponente, die für die Bereitstellung verantwortlich ist: |
| - Anwendungskonfiguration über definierte Endpunkte |
| - UI zur Pflege von Anwendungskonfigurationsdaten |
| - API zur Pflege von Anwendungskonfigurationsdaten |
| - Persistenz von Anwendungskonfigurationsdaten |
| Authentifizierungsmodule („Authentication Module“) | Komponente, die verantwortlich ist für: |
| - Ausführung zusätzlicher Authentifizierung mit Authentifizierungsfaktoren (z. B. Client-Zertifikate, Einmalpasswörter, Push-Benachrichtigungen, Bestätigungs-E-Mails, Benachrichtigungs-E-Mails, Sicherheitsfragen) |
| - Verwalten, Ausstellen, Bereitstellen, Überprüfen dieser zusätzlichen Authentifizierungsfaktoren |
| Sicherheitstechnik-Module („Security Engineering Module“) | Komponente, die für die Bereitstellung verantwortlich ist: |
| - Wrapper für unterstützte Verschlüsselungsmethoden über definierte Endpunkte |
| - Wrapper für unterstützte Hashing-Methoden über definierte Endpunkte |
| - Funktionalität zur Verwaltung, Bereitstellung und Anwendung von Verschlüsselungsschlüsseln |
| - eine Reihe von APIs, um ausgewählte Funktionen für Anwendungen verfügbar zu machen |
| Audit Trail System | Komponente, die eine nicht widerlegbare Protokollierung des Datenzugriffs einschließlich des Endpunkt- und SQL-Zugriffs auf verschiedene Komponenten entlang des Datenzugriffspfads unterstützt. |
-
Ein Aspekt der Erfindung besteht darin, dass der Client-Computer 10 über die REST-API 105 mit dem Data Access Modul bzw. Datenzugriffsmodul 110 kommuniziert. Das Datenzugriffsmodul stellt eine zentrale Komponente des Systems 100 dar und organisiert im Wesentlichen die Beantwortung von Anfragen, die von dem Client-Computer 10 ausgegeben werden. In dem beschriebenen Ausführungsbeispiel befinden sich zwischen der REST-API 105 und dem Datenzugriffsmodul 110 Datenbankanbindungsmodule bzw. Datenbank-Proxys. Diese können eingesetzt werden, um zieldatenbankspezifisch (vgl. die relationale Datenbank 30 bzw. SQL Datenbank oder die Hash-Datenbank 40) Abfragen an das Datenzugriffsmodul 110 weiterzugeben. Im gezeigten Ausführungsbeispiel handelt es sich bei dem linken Modul um ein SQLspezifisches Datenbankanbindungsmodul 140 und bei der rechten Komponente um ein Datenbankanbindungsmodul für Nicht-SQL-Zieldatenbanken.
-
In der 2 ist es exemplarisch veranschaulicht, dass die Datenanfragen originär nicht von dem Client-Computer 10, sondern von darauf laufenden Anwendungen stammen.
-
In einem Ausführungsbeispiel handelt es sich bei der Anwendung um eine Anwendung, die typischerweise über eine ODBC-Schnittstelle mit einer geeigneten Zieldatenbank kommunizieren würde. Erfindungsgemäß weist, wie bereits erläutert, der Client-Computer 10 einen Datenbanktreiber 12 auf, der eine abgegebene SQL-Anfrage in eine REST-Anfrage übersetzt. Hierzu wird der adressierte Tabellenname aus der Anfrage geparst und spezifische Feldangaben aufgelöst. Unspezifische Feldangaben, wie beispielsweise ein Wildcard-Symbol („*“) können ebenso in einzelne Feldnamen übersetzt werden, soweit die Zieldatenbank bekannt ist. Auch die SQL-typischen Bedingungen, die für eine bestimmte Anfrage gesetzt werden (Schlüsselwort: „WHERE“) lassen sich übersetzen. Im Wesentlichen generiert der Datenbanktreiber 12 aus der SQL-Abfrage eine REST-Anfrage und sendet diese REST-Anfrage über die Schnittstelle 105 an das System 100. Dort wird die Abfrage unter anderem durch das Datenzugriffsmodul 110 verarbeitet.
-
Das Datenzugriffsmodul 110 wählt beispielsweise anhand des von dem Datenbankanbindungsmodul 140 bereitgestellten Daten eine Zieldatenbank, im Beispiel die relationale Datenbank 30 aus.
-
In einem Ausführungsbeispiel stellt das Datenzugriffsmodul 110 auch fest, inwieweit originäre Daten oder teilweise anonymisierte Daten in Reaktion auf die Anfrage zur Verfügung gestellt werden können. Beispielsweise kann der anfragenden Anwendung auf dem Client-Computer 10 aufgrund von Identifikationsinformationen eine bestimmte Rolle innerhalb des Systems 100 zugeordnet werden. Diese Rolle kann mit einer bestimmten Ansicht der relationalen Datenbank 30 verknüpft sein.
-
3 zeigt zwei unterschiedliche Ansichten, nämlich eine vollständige Datenbankansicht 31 und eine zumindest teilweise anonymisierte Datenbankansicht 32. Exemplarisch kann es sich bei den gezeigten Tabellen bzw. Ansichten um Patientendaten handeln. Während in der vollständigen Datenbankansicht 31 Name, genaues Geburtsdatum und Blutgruppe angegeben sind, verfügt die anonyme Datenbankansicht 32 neben den Namen lediglich über eine Jahresangabe des Geburtsdatums und über keine Angabe der Blutgruppe. Die Blutgruppe wurde zur Generierung der anonymen Datenbankansicht 32 einfach auf einen Nullwert („NULL“) gesetzt.
-
Nach der Auswahl einer dieser Ansichten können die entsprechenden Daten über die REST-API 105 vom Datenzugriffsmodul 110 an die Anwendung auf dem Client-Computer 10 zurückgeliefert werden. Insofern ist es einfach möglich, Daten klar strukturiert in anonymisierter Form zur Verfügung zu stellen.
-
Der in 3 gezeigte Ansatz mittels Ansichten hat den Vorteil, dass in der relationalen Datenbank 30 Datensätze nur einmal existieren müssen und die notwendigen Anonymisierungsfunktionen online beim Abfragen der Datensätze durchgeführt werden.
-
Ein sich deutlich unterscheidender Ansatz kann für die nicht-SQL-basierten Datenbanken verwendet werden. Am Beispiel der Hash-Datenbank 40 ist es möglich, Kopien einer originären Hash-Datenbank zu erstellen und dort bestimmte Werte dauerhaft zu überschreiben. Insofern wird das Datenzugriffsmodul 110 in Abhängigkeit von der zugeordneten Rolle bei einer Anfrage die auf die Hash-Datenbank 40 gerichtet ist, die Hash-Datenbank auswählen, die der Benutzerrolle der abfragenden Anwendung zugeordnet ist. Dieser Ansatz hat den Vorteil, dass eine hohe Performanz erzielt wird.
-
In dem beschriebenen Ausführungsbeispiel werden beide Ansätze parallel in Abhängigkeit der technischen Implementierung der jeweiligen Zieldatenbank verfolgt. Erfindungsgemäß ist es jedoch auch denkbar, in einem System 100 nur einen dieser Ansätze zu implementieren.
-
In einem Ausführungsbeispiel umfasst das System 100 ein Datensammel-Kontextmodul 150. Dieses Datensammel-Kontextmodul kann dazu ausgebildet sein, Daten zu sammeln und in den Zieldatenbanken, beispielsweise in der relationalen Datenbank 30 oder in der Hash-Datenbank 40, abzulegen. Als Teil dieses Sammelvorgangs können zusätzliche Informationen, die den Kontext der Datenerfassung angeben, abgespeichert werden. Hierfür kann eine gesonderte Datenbank vorgesehen sein. Die Kontextdaten bzw. Datensammel-Kontext der können umfassen:
- - eindeutiger Bezeichner eines Datenerfassungskontexts
- - Umfang der Datenerhebung
- - Zweck der Datenerhebung
- - Dauer der Datenerhebung
- - Rechtsgrundlage der Datenerhebung
- - geltende Vorschriften zur Einhaltung des Datenschutzes
-
Diese Kontextdaten können benutzt werden, um initial notwendige Anonymisierungsschritte für die gespeicherten Daten zu bestimmen. Zusätzlich kann in Abhängigkeit von zeitlichen Abläufen der Inhalt der Zieldatenbanken verändert werden. Beispielsweise ist es denkbar, dass bestimmte Daten nur für einen bestimmten Zeitraum aufgehoben werden können. Insofern erlaubt es das erfindungsgemäße System 100 Daten basierend auf dem Kontext zu einem bestimmten Zeitpunkt zu löschen. Zusätzlich oder alternativ kann es vorgesehen sein, dass bestimmte Daten nach einem vorgegebenen Zeitpunkt der Allgemeinheit oder bestimmten Anwendungen zur Verfügung gestellt werden können. Insofern ist es nicht zwangsläufig notwendig, dass der Grad der Anonymisierung im Laufe der Zeit zunehmen muss. Theoretisch sind auch Szenarien denkbar, bei denen zu einem späteren Zeitpunkt geringere Anonymisierungsinformationen bestehen.
-
Die beschriebenen Mechanismen sind auch nicht auf reine zeitliche Informationen eingeschränkt. So kann der Kontext beispielsweise angeben, zu welchem Zweck bestimmte Daten gesammelt wurden und somit darauf Einfluss darauf nehmen, welche Zugriffsrollen berechtigt sind, bestimmte Daten abzufragen.
-
Bezugszeichen
-
- 1
- Internet
- 10
- Client-Computer
- 12
- Datenbanktreiber
- 30
- Relationale Datenbank
- 31
- Vollständige Datenbankansicht
- 32
- Anonyme Datenbankansicht
- 40
- Hash-Datenbank
- 100
- System
- 105
- REST-API
- 110
- Datenzugriffsmodul
- 120
- Konfigurationsverwaltungsmodul
- 130
- Authentifizierungsmodul
- 140
- Datenbankanbindungsmodul
- 150
- Datensammel-Kontextmodul