DE112014001363T5

DE112014001363T5 - Verfahren, Vorrichtung und computer-lesbares Medium zum Datentokenisieren

Info

Publication number: DE112014001363T5
Application number: DE112014001363.3T
Authority: DE
Inventors: Eric Boukobza
Original assignee: Informatica LLC
Current assignee: Informatica LLC
Priority date: 2013-03-15
Filing date: 2014-03-14
Publication date: 2015-11-26
Also published as: US9336256B2; US20140280260A1; WO2014143786A1; CA2906658C; CA2906658A1; JP6169777B2; GB201517898D0; JP2016519808A; GB2528203B; GB2528203A

Abstract

Eine Vorrichtung, ein computerlesbares Medium und ein computerimplementiertes Verfahren zur Datentokenisierung sind offenbart. Das Verfahren umfasst Empfangen, an einem Datenbanknetzwerkrouter, einer Datenbankzugriffsanfrage, die an eine tokenisierte Datenbank gerichtet ist, wobei die tokenisierte Datenbank einen oder mehrere tokenisierte Datenwerte umfasst, Anwenden von einer oder von mehreren Regeln auf die Anfrage, Umschreiben der Anfrage, auf Basis zumindest einer der einen oder der mehreren Regeln, so dass Datenwerte, die in die tokenisierte Datenbank hinzugefügt werden, tokenisierte Datenwerte sein werden, und Datenwerte, die von der tokenisierten Datenbank empfangen werden, nicht-tokenisierte Datenwerte sein werden, und Übertragen der umgeschriebenen Anfrage an die Datenbank.

Description

VERWANDTE ANMELDEDATEN
Die vorliegende Anmeldung beansprucht die Priorität der U. S. Patentanmeldung Nr. 13/840,446, die am 15. März 2013 eingereicht wurde, deren Inhalt in seiner Gesamtheit hiermit durch Bezug hierin aufgenommen wird.
HINTERGRUND
Große Mengen von Daten werden in Datenbanken, wie beispielsweise in Unternehmensdatenbanken gespeichert. Ein Großteil dieser Daten umfasst vertrauliche oder anderweitig sensible Informationen. Dadurch verwenden Unternehmen häufig Tokenisierung, um die Werte der möglicherweise sensiblen Daten in ihren Datenbanken zu verstecken. Dieser Tokenisierungsprozess kann aus Ersetzen der Datenwerte in einer Datenbank durch Tokenwerte bestehen. Die Token-zu-Daten-Wert-Beziehung kann in einem Tresor (vault) gespeichert werden, der verschlüsselt sein kann, um unbefugten Zugriff zu verhindern und um sicherzustellen, dass nur zugelassene Benutzer auf die realen Werte der Token in der Datenbank zugreifen können. Anstatt der Speicherung der Echtdatenwerte in dem Token-Tresor, kann alternativ der Token-Tresor verwendet werden, um einen echten Datenwert mittels einem Entschlüsselungsprozess zu extrahieren, der in einem Token eingebettet ist.
Wenn ein autorisierter Benutzer auf die Daten in der Datenbank von einer Anwendung zugreifen möchte, trägt die Anwendung die Verantwortung zum Identifizieren des berechtigten Benutzers und zum Ersetzen der Tokens durch die realen Werte. Wenn außerdem ein autorisierter Benutzer neue Daten in die Datenbank hinzufügen möchte, trägt die Anwendung die Verantwortung der Tokenisieren der neuen Daten, vor dem Hinzufügen zu der Datenbank. Dies stellt zusätzliche Belastungen für die Anwendung dar und erfordert, dass die Anwendung in Verbindung mit dem Token-Tresor, sowie mit der Datenbank steht. Wenn zum Beispiel der Benutzer einen Datenwert zu der Datenbank hinzufügt, muss die Anwendung zuerst den Datenwert tokenisieren, dann die Token-zu-Datenwerte-Beziehung zu dem Tresor hinzufügen, und dann die tokenisierten Daten an die Datenbank übertragen.
Als Ergebnis dessen, dass die Anwendung für die meisten Aufgaben bezüglich Tokenisierung zuständig ist, muss die Anwendung stark angepasst werden, um die besondere Tokenisierung-Application-Programming-Interface (API) zu integrieren, die von jedem Datenbankanbieter verwendet wird, und kann nicht mit den APIs von anderen Datenbankanbietern oder Tokenisierungs-Anbietern genutzt werden.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1A ist ein Systemdiagramm, das die Anordnung der Systemkomponenten und die Interaktionen zwischen den Komponenten in früheren Tokenisierungsschemata zeigt.
1B ist eine beispielhafte Vorrichtung zur Datentokenisierung, gemäß einer offenbarten Ausführungsform.
2 ist eine beispielhafte Vorrichtung zur Datentokenisierung mit mehreren Datenbanken, Anwendungen und Tokenisierungs-Schemata, gemäß einer offenbarten Ausführungsform.
3 ist ein Flussdiagramm, das ein beispielhaftes Verfahren für den Umgang mit Datenbankzugriffsanfragen durch den Datenbanknetzwerkrouter (DNA) zeigt, gemäß einer offenbarten Ausführungsform.
4 ist ein Diagramm, das viele der Regeln und Regelsätzen zeigt, die auf die Anfrage von dem DNA angewendet werden können, gemäß einer offenbarten Ausführungsform.
5 ist ein Diagramm eines Muster-Token-Tresors und Muster-tokenisierten-Datenbank, die eine Muster-Tabelle umfasst, gemäß einer offenbarten Ausführungsform.
6 ist ein Diagramm, das den Muster-Token-Tresor und die Muster-Tabelle vor und nach einer Aktualisierungs-Anfrage zeigt.
7 ist ein Diagramm, das den Muster-Token-Tresor und die Muster-Tabelle vor und nach einer Aktualisierungs-Anfrage zeigt.
8 ist ein Flussdiagramm, das ein beispielhaftes Verfahren für den Umgang mit unvollständigen Anfragen durch den DNA zeigt, gemäß einer offenbarten Ausführungsform.
9 ist ein Flussdiagramm, das ein beispielhaftes Verfahren zum Verhindern von unberechtigtem Zugriff auf die Datenbank durch den DNR zeigt, gemäß einer offenbarten Ausführungsform.
10 zeigt eine beispielhafte Rechenumgebung, die verwendet werden kann für die Durchführung der Verfahren der Datentokenisierung, gemäß einer offenbarten Ausführungsform.
AUSFÜHRLICHE BESCHREIBUNG
Während Verfahren, Vorrichtungen und computerlesbaren Medien hierin anhand von Beispielen und Ausführungsformen beschrieben werden, wird der Fachmann auf dem Gebiet erkennen, dass die Verfahren, Vorrichtungen und computerlesbaren Medien zur Datentokenisierung nicht auf die beschriebenen Ausführungsformen und Zeichnungen beschränkt sind. Es sollte verstanden werden, dass die Zeichnungen und die Beschreibung nicht auf die besondere offenbarte Form beschränkend sind. Vielmehr ist es die Absicht, alle Modifikationen, Äquivalente und Alternativen, die in den Geiste und den Umfang der beigefügten Ansprüche fallen, abzudecken. Alle hier verwendeten Überschriften sind nur zu organisatorischen Zwecken gedacht und sind nicht dazu gedacht, den Umfang der Beschreibung oder der Ansprüche zu beschränken. Wie hier verwendet, wird das Wort ”kann” in einem möglichen Sinne verwendet (d. h. es bedeutet, dass es das Potenzial zu etwas hat), anstatt in einem obligatorischen Sinne (d. h. es bedeutet, es muss). Ebenso bedeuten die Wörter ”umfassen”, ”enthalten” und ”enthält” einschließen, aber nicht darauf beschränkt.
1A ist ein Systemdiagramm, das die Anordnung der Systemkomponenten in früheren Tokenisierungsschemata und die Interaktionen zwischen den Komponenten zeigt. Datenbank 102 ist eine tokenisierte Datenbank, die Daten in einem tokenisierten Format speichert. Die Token-zu-Daten-Beziehungen können in dem Token-Tresor 101 gespeichert werden. Anwendung 100 steht in bidirektionaler Kommunikation mit Token-Tresor 101 und Datenbank 102, die tokenisierte Daten speichert. Wenn so zum Beispiel ein Benutzer die tokenisierte Datenbank 102 abfragen möchte, muss die Anwendung 100 zunächst alle Filterwerte in der Abfrage tokenisieren, die Anfrage an die Datenbank 102 senden, um die Token-Werte zu erhalten, die die Abfrage erfüllen, und dann die reale Werte holen, die den Token-Werten aus dem Token-Tresor 101 entsprechen. Falls der Benutzer auf ähnlicher Weise die Datenbank aktualisieren will, muss die Anwendung 100 die neuen Datenwerte tokenisieren und sie an den Token-Tresor 101 senden, zusätzlich zur Übersendung tokenisierte Datenbank 102.
Die Anmelder haben ein System zum Bewegen der Tokenisierungs-Verantwortung von der Anwendung zu einem Zwischenknoten, was die erforderlichen Ressourcen reduziert und die Implementierung vereinfacht. Diese Änderung würde es Datenbankanbietern ermöglichen, jede Anwendung mit ihrer tokenisierten Datenbank zu nutzen, ohne dass die Anwendung auf die Bedürfnisse des jeweiligen Tokenisierung-API angepasst werden muss. Darüber hinaus könnte der Zwischenknoten verwendet werden, um mehreren Datenbankanbietern mit unterschiedlichen Tokenisierungs-Technologien zu dienen.
1B ist eine beispielhafte Vorrichtung zur Datentokenisierung, gemäß einer offenbarten Ausführungsform. Der Datenbanknetzwerkrouter (”DNR”) 104 dient als der oben genannten Zwischenknoten zwischen der Anwendung 103 und der tokenisierten Datenbank 105. Die Datenbank 105 kommuniziert direkt mit Token-Tresor 106 durch die Verwendung eines DNR-Software-Agenten 107, der auf der Datenbank läuft, der Befehle analysiert und ausführt, die als Teil der Datenbankzugriffsanfragen von dem DNA 104 empfangene werden. Durch die Verwendung des DNA 104 und des DNA-Software-Agenten 107, kann die Anwendung 103 von der Datenbank 105 entkoppelt werden, und die Belastung der Integration von Tokenisierungs-APIs und dem Durchführen von Tokenisierungs- oder Ent-Tokenisierungs-Funktionen können auf den DNA 104 und den DNR-Software-Agenten 107 verschoben werden. Darüber hinaus können durch Entfernen der Tokenisierungs- und Ent-Tokenisierungs-Funktionen von der Anwendung, mehrere Tokenisierungs-Anbieter oder Unternehmen den DNA und einen DNA-Software-Agenten als Schnittstelle zwischen ihren eigenen Datenbanken und Anwendungen nutzen.
Ein Beispiel, wie der DNA mit mehreren Datenbanken verwendet wird, ist in 2 gezeigt. Anwendungen 200A, 200B und 200C können auf verschiedenen Client-Rechnern (nicht dargestellt) laufen, und können drei verschiedenen tokenisierten Datenbanken 202A, 202B und 202C zugeordnet werden. Ein DNA-Software-Agent, der auf jeder der Datenbanken, 204A, 204B und 204C, läuft, kommuniziert mit jedem der entsprechenden Token-Tresore, 203A, 203B und 203C. Selbstverständlich wird nicht für jede Datenbank ein separater Token-Tresor benötigt. Beispielsweise können die Datenbanken 202B und 202C das gleiche Tokenisierungs-Schema verwenden und können einen einzelnen Token-Tresor teilen.
Der DNA 201 kann eine Anfrage von Anwendung 200A empfangen oder abfangen und, basierend auf der Anwendung, dem Client-Rechner, den Benutzeranmeldeinformationen (user credentials), dem Anfrageziel, dem Anfrage-Inhalt, oder einigen anderen Parametern, feststellen, dass die Anfrage mit Datenbank 202A verbunden ist. Die Anfrage kann dann in Übereinstimmung mit den Regeln verarbeitet werden, die der Datenbank 202A zugeordnet sind, wie weiter unten beschrieben wird, und an die Datenbank 202A weitergeleitet werden. An der Datenbank 202A kann der DNR-Agent 204A bestimmen, dass einige Datenwerte tokenisiert werden müssen, oder ein tokenisierter Wert ent-tokenisiert werden muss, woraufhin er mit dem Token-Tresor 203A kommunizieren kann, um vor dem Rückgeben von irgendwelchen Ergebnissen an den DNR 201 und möglicherweise an die Anwendung 200A die angemessene Operation durchzuführen.
Mit Bezug auf 3 wird ein Verfahren zur Handhabung von Datenbankzugriffsanfragen durch den DNR, eines offenbarten Ausführungsbeispiels beschrieben. In Schritt 301 empfängt der DNR eine Datenbankzugriffsanfrage von einer Anwendung. Die Anfrage kann zu einer Zieldatenbank gerichtet sein und zu dem DNR umgeleitet werden, oder die Anfrage kann durch den DNR abgefangen werden. Alternativ kann die Anfrage an den DNR gesendet werden, aber eine Zieldatenbank angeben. Viele Variationen sind zum Empfangen der Datenbankzugriffsanfrage an dem DNR möglich.
Die Datenbankzugriffsanfrage kann jede Art von Anfrage umfassen, einschließlich einer Datenabfrage-Anfrage, einer Datenaktualisierungs-Anfrage, einer Daten-Einfügen-Anfrage einer Daten-Löschen-Anfrage, oder einer anderen ähnlichen Datenbankzugriffsanfrage. Zusätzlich kann die Sprache der Anfrage jede Art von Datenbank-Abfrage-Sprache umfassen, einschließlich der Structured-Query-Language (SQL), Contextual-Query-Language (CQL), XQuery, YQL, Datalog, OQL, RDQL, und viele andere.
In Schritt 302 kann der DNR eine oder mehrere Regeln auf die Anfrage anwenden. Diese Regeln werden im Folgenden näher erläutert, aber können Regeln für den richtigen Umgang mit verschiedenen Arten von Datenbankzugriffsanfragen, Anfrage-Routing, Tokenisierungsregeln und dergleichen umfassen. Nach Anwendung der Regeln kann die Anfrage in Schritt 303 neu geschrieben werden, basierend auf wenigstens eine der einen oder der mehreren Regeln. Zum Beispiel kann die Anfrage umgeschrieben werden, um einen oder mehrere Befehle in die Datenbankzugriffsanfrage hinzuzufügen, die durch den DNR-Agenten analysiert ausgeführt werden, der auf der Datenbank läuft. Zusätzlich können ein oder mehrere Parameter an den DNR-Agenten geleitet werden, mit den Befehlen, die dem DNR-Agenten anweisen, wie die Daten, die mit den Befehlen geleitet werden zu behandeln sind. Beispielsweise können Parameter bestimmte Tokenisierungs-Schemata angeben, die zu benutzen sind, Zulassung eines bestimmten Benutzers oder eines Rechners angeben, angeben ob der Befehl ignoriert werden soll, oder ob falsche Werte zurückgegeben werden sollten.
Nachdem die Anfrage unter Verwendung einer oder mehrerer Regeln umgeschrieben wird, kann die umgeschriebene Anfrage an die Zieldatenbank in Schritt 304 übertragen werden. Die eigentliche Übertragung der umgeschriebenen Anfrage kann auch basierend auf einer oder mehreren Regeln beruhen. Zum Beispiel kann die Zieldatenbank eine verteilte Datenbank sein, die über eine Vielzahl von Speichern verteilt ist. Der DNR kann eine Regel auf die Datenbankzugriffsanfrage, oder deren Inhalte anwenden, um zu Bestimmung, an welchen der Speicher die Anfrage weitergeleitet werden soll. Und falls der DNR Anfragen für mehrere verschiedene Datenbanken mit unterschiedlichen Tokenisierungs-Schemata routet, kann der DNR Regeln anwenden, um die richtige Datenbank zu bestimmen, um die umgeschriebene Anfrage zu senden. Alternativ, wenn der DNR eine Anforderung abfängt, die bereits eine Zieldatenbank spezifiziert, kann der DNR die umgeschriebene Anfrage zu dieser Zieldatenbank einfach übertragen.
4 zeigt einige mögliche Regeln und Regelsätze 400, die auf die Anfrage angewendet werden können. Der DNR kann eine Reihe von Regeln auf Grundlage der Art der Anfrage, die empfangen wird anwenden, wie beispielsweise Datenabfrage-Anfrage-Regeln 401, Datenaktualisierungs-Anfrage-Regeln 402, und Daten-Einfügen-Anfrage-Regeln 403. Darüber hinaus, obwohl diese nicht gezeigt sind, kann der DNR auch Regelsätze in Bezug auf Daten-Löschen-Anfragen anwenden. In der Praxis würden diese ähnlich den Daten-Aktualisieren-Anfragen sein. Filter-Begriffe-Regeln 404 können angewendet werden, wenn die Zugriffs-Anfrage eine oder mehrere Filter-Begriffe umfasst. Zum Beispiel kann eine SQL-Abfrage angeben ”Wähle Variable A, wo Variable B = X”. Die Wo-Klausel und zugehörige Informationen sind die Filter-Begriffe, und ein Satz von Regeln kann verwendet werden, um festzustellen, wie die Filter-Begriffe zu behandeln sind.
Beispielsweise können Filter-Begriffe nicht-tokenisierte Daten umfassen, die Tokenisierung benötigt, nachdem sie zu dem DNR-Agenten geliefert werden, der auf der Datenbank läuft. Jedoch kann die Tokenisierungs-API angeben, dass ein neuer Token nicht für Datenwerte erstellt werden sollte, die als Filter-Datenwerte übergeben werden, sondern vielmehr, dass der Token-Wert (falls vorhanden) in einem Token-Tresor betrachtet werden sollte. Wie weiter unten erläutert, können die Filter-Begriffe-Regeln verwendet werden, um einen Parameter in einen Tokenisierungs-Befehl einzufügen, der den DNR-Agenten wissen lässt, dass er einen übergebenen Wert tokenisieren sollte, aber dass er keinen neuen Token in dem Prozess erstellen sollte.
Tokenisierungs-API-Regeln 405 beziehen sich auf die verschiedenen Regeln, die für das Abrufen von Daten von, oder für das Senden von Daten an tokenisierte Datenbanken verwendet werden, die eine Vielzahl von Tokenisierungs-Schemata aufweisen. Beispielsweise kann eine erste Anfrage an eine erste Datenbank gerichtet sein, die einen ersten Tokenisierungs-Algorithmus verwendet, um alle darin gespeicherten Datenwerte zu tokenisieren, und eine zweite Anfrage kann an eine zweite Datenbank gerichtet sein, die einen zweiten Tokenisierungs-Algorithmus verwendet, um nur sensible Daten zu tokenisieren, die darin gespeichert sind. Falls so zum Beispiel der DNA eine Datenabfrage-Anfrage empfängt, die an die zweite Datenbank gerichtet ist, kann er die zugehörige Tokenisierungs-API-Regeln für diese Datenbank konsultieren, und festzustellen, ob die angeforderten Daten in einem Token-Format gespeichert sind. Wenn ja, dann kann der DNA einen Ent-Tokinisieren-Befehl in die Anfrage einfügen, und wenn nicht, dann ist der Ent-Tokinisieren-Befehl nicht erforderlich.
Tokenisierung API Regeln 405 können festlegen, welche Arten von Daten oder Datenfelder in tokenisiert werden sollten. Zum Beispiel kann eine Tokenisierungs-API angeben, dass alle Daten tokenisiert werden sollten, während eine andere Tokenisierungs-API angeben kann, dass nur Datenfelder tokenisiert werden sollten, die persönliche oder vertrauliche Informationen enthalten.
Unvollständige-Anfrage-Regeln 406 werden auch weiter unten detaillierter diskutiert, und können angewendet werden, wenn der DNA eine Anfrage empfängt, in der bestimmte Felder oder andere notwendige Informationen fehlen.
Berechtigungs-Regeln 407 und Sicherheits-Regeln 408 können verwendet werden, um festzustellen, ob der Benutzer, der Rechner, oder die Sitzung des Benutzers über ausreichende Berechtigungsnachweise (credentials) zum Durchführen der Anfrage verfügt, sowie um festzulegen, welche Aktionen in verschiedenen Situationen durchzuführen sind, wenn der Benutzer nicht über ausreichende Berechtigungsnachweise verfügt. Zum Beispiel können in einer Verbraucher-Transaktions-Datenbank Sicherheits-Regeln besagen, dass nur jeder Verbraucher in der Lage sein sollte, seine eigenen Kreditkarteninformationen in ent-tokenisierter Form zu betrachten. Wenn ein Systemadministrator eine Liste der Transaktionen mit allen damit zusammenhängenden Feldern anfordert, können Sicherheits-Regeln verwendet werden, um die Felder zurückzugeben, die nicht in ent-tokenisierter Form geschützt sind und die zugehörigen Kreditkartennummern im Token-Format zurückgeben. Alternativ können die Sicherheits-Regeln verwendet werden, um die Datenbank anzuweisen, gefälschte oder fiktive Nummern für jede Kreditkartennummer zurückzugeben. Fiktive Werte können mit einem Algorithmus erzeugt werden oder können aus einem Pool von fiktiven Werten ausgewählt werden. Berechtigungs-Regeln können verwendet werden, um unterschiedliche Zugriffsebenen für verschiedene Benutzertypen zu implementieren. Beispielsweise kann es sein, dass nur ein Administrator die erforderlichen Berechtigungen hat, um Einträge in der Datenbank zu aktualisieren, einzufügen oder zu löschen, während alle anderen Benutzer nur die Erlaubnis haben, Abfragen durchzuführen.
Schließlich können, wie bereits erläutert, Routing-Regeln 409 verwendet werden, um zu bestimmen, wohin Anfragen weitergeleitet werden sollen. Routing-Regeln 409 können so einfach wie eine Regel sein, die die Zieldatenbank-Adresse einer abgefangen Angfrage aufnimmt und die umgeschriebene Anfrage an diese Adresse weiterleitet.
Obwohl alle Regeln im Rahmen des DNA diskutiert werden, versteht es sich, dass einige oder alle der Funktionen der Regeln durch den DNR-Software-Agenten auf der Datenbank ausgeführt implementiert werden können. Falls zum Beispiel ein Benutzer nicht berechtigt ist, eine Anfrage zu machen, kann die Beurteilung von dem DNA gemacht werden, der einen ”nicht-autorisierten” Token oder Nachricht in die umgeschriebene Anfrage einfügen kann, die an die Datenbank gesendet wird. Bei der Datenbank kann der DNA-Software-Agent den ”nicht-autorisierten” Tokens lesen und feststellen, dass keine Maßnahme in Reaktion auf die Anfrage unternommen werden sollte. Zusätzlich, wie von einem Fachmann auf dem Gebiet verstanden werden wird, sind nicht alle diese Regeln erforderlich für die Durchführung des Verfahrens der Datentokenisierung, die hierin offenbart ist.
5 veranschaulicht eine beispielhafte tokenisierte Datenbank 501. Tabelle XYZ 502 in Muster-Datenbank 501 enthält eine tokenisierte Auflistung von Namen und Sozialversicherungsnummern. Tokenwerte T1, T2, T3 und T4 sind nur zur Veranschaulichung bereitgestellt und die tatsächliche Token-Werte können eine beliebige Folge von Zahlen oder alphanumerischen Zeichen sein, die der Datenbankbesitzer/Administrator oder Tokenisierungs-Anbieter bevorzugt.
Muster-Datenbank 501 enthält auch einen DNA-Software-Agenten 505, der die Befehle implementiert, die aus über den DNA 504 empfangenen umgeschrieben Anfragen geparst werden. Der DNA-Agent 505, der auf der Muster-Datenbank 501 läuft, steht mit Muster-Token-Tresor 503 in Verbindung, der die Datenwerte umfasst, die den Token-Werten in der Muster-tokenisierten-Datenbank 501 enthalten sind.
Der DNA 504 empfängt Datenbankzugriffsanfragen von einer oder mehreren Anwendungen 506 und leitet, nach Verarbeitung/Umschreibung der Anfragen, die entsprechenden umgeschriebenen Anfragen zu Muster-tokenisierter-Datenbank 501 weiter. Natürlich kann DNR 504 in Kommunikation mit mehreren tokenisierten Datenbanken (nicht gezeigt) und mehreren Anwendungen zur gleichen Zeit stehen, und begrenzten Komponenten werden nur zur Veranschaulichung und Klarheit angezeigt.
Der DNR 504 ermöglicht es einem Benutzer (nicht dargestellt), der Anwendung 506 verwendet, Datenbankzugriffsanfrage einzugeben und zu senden, die an die Mustertokenisierter-Datenbank 501 gerichtet sind, ohne dass die Anwendung für die Tokenisierung oder Ent-Tokenisierungs verantwortlich ist. Der Benutzer kann Datenbank-Anfragen so eingeben, wie sie normalerweise eingegeben werden, und die Anwendung 506 kann sie an den DNR 504 weiterleiten, der alle Tokenisierungs- und Ent-Tokenisierungs-bezogene Verarbeitungen handhabt.
Der Betrieb von verschiedenen Arten von Anfragen und konkreten Beispielen für jede Anfrage wird nun unter Bezugnahme auf Tabelle XYZ 502 in Muster-tokenisierter-Datenbank 501 und Muster-Token-Tresor 503 beschrieben. Obwohl die Sprache in den Beispielen SQL entspricht, ist sie nur zur Veranschaulichung vorgesehen, und jede Abfragesprache kann verwendet werden.
Falls der DNR 504 eine Datenabfrage-Anfrage empfängt, die an Muster-tokenisierter-Datenbank 501 gerichtet ist, lädt er zuerst die entsprechende Regel, die für Datenabfrage-Anfragen festgelegt ist. Nach dem Laden des entsprechenden Regelsatzes, wertet er die Datenabfrage-Anfrage aus und schreibt sie so um, dass nachdem sie zu der Mustertokenisierten-Datenbank 501 gesendet wird, die Werte in ent-tokenisierter Form zurückgegeben werden, die empfangen werden sollen.
Zum Beispiel ist, sagen wir, die Datenabfrage-Anfrage wie folgt:
”WÄHLE Name VON Tabelle XYZ”
Falls diese Abfrage auf Tabelle XYZ 502 in der Muster-tokenisierten-Datenbank ohne Änderungen ausgeführt werden würde, wäre der Ergebnissatz, der zurückgegeben werden würde:
Name: T1, T2
Selbstverständlich ist dies nicht die Information, die der Benutzer vermutlich mit solchen Abfragen abgerufen haben will. Wenn der DNR 504 diese Abfrage empfängt, wird der entsprechende Regelsatz verwendet, um die Abfrage umzuschreiben in:
”WÄHLE entToken(Name) VON Tabelle XYZ”
Die entToken-Funktion weist dem DNA-Agenten 505 an, der auf der Mustertokenisierten-Datenbank 501 läuft, die abgerufenen Werte vor der Übertragung des Ergebnissatzes an den DNA 504 zu ent-tokenisieren. Unter Benutzung des Beispiels der umgeschrieben Abfrage, wird die Muster-Datenbank 501 die umgeschriebene Abfrage ausführen, um die Tokenwerte in der Namenspalte abzurufen, und der DNA-Agent 505 wird diese Tokenwerte an den Muster-Token-Tresor 503 übertragen, um die tatsächlichen Werte abzurufen, die dann zurück in den DNA 504 weitergegeben werden.
Obwohl die gezeigte entToken-Funktion nur einen Parameter nimmt, ist dies nur aus Gründen der Klarheit so. Die entToken-Funktion kann viele Parameter nehmen. Beispielsweise kann die entToken-Funktion einen Parameter nehmen, einschließlich der DNR-Ursprungs-Signatur zur Überprüfung, so dass auf den DNR-Agenten nicht direkt zugegriffen werden kann. Die Funktion kann einen Parameter nehmen, der zu einem bestimmten Tokenisierungs-Schema gehört, das verwendet wird, oder einen Parameter mit Informationen verwendet, die sich auf eine bestimmte Benutzersitzung beziehen, wie beispielsweise einen Benutzersitzungs-Kennzeichnungsstempel. Die Funktion kann auch Sicherheitsdaten umfassen, die sich darauf Beziehen, welche Art von Werten zurückgeführt werden sollten, wie in größerem Detail in Bezug auf fiktive Werte diskutiert wird.
So ist der Ergebnissatz, der an den Benutzer von Anwendung 506 zurück übertragen wird, wenn die Abfrage durch DNA 504 läuft und umgeschrieben wird, bevor sie zu Mustertokenisierter-Datenbank 501 geschickt wird, wie folgt:
Name: Miller, Sanchez
Die entToken-Funktion kann wahlweise auf Basis von Sicherheits- und Berechtigungs-Erwägungen angewendet werden, und kann eine oder mehrere zusätzliche Variablen zur Muster-Datenbank 501 übergeben. Diese Variationen werden mit Bezug auf die Sicherheits- und fiktiven Werte-Funktionen weiter unten erläutert werden.
Falls der DNA 504 eine Datenaktualisierungs-Anfrage empfängt, die an Mustertokenisierter-Datenbank 501 gerichtet ist, lädt er zuerst die entsprechende Regel, die für Datenaktualisierungs-Anfrage festgelegt ist. Nach dem Laden des entsprechenden Regelsatzes, wertet er die Datenabfrage-Anfrage aus und schreibt sie so um, dass nachdem sie zu der Muster-tokenisierten-Datenbank 501 gesendet wird, die Werte in Token-Form sind, die zu der tokenisierten Datenbank hinzugefügt werden sollen und die passenden Token-zu-Daten-Beziehungen werden in dem Muster-Token-Tresor gespeichert.
Falls also die Datenaktualisierungs-Anfrage, die an die Muster-tokenisierte-Datenbank 501 gesendet wird, durch den DNA 504 abgefangen wird:
AKTUALISIERE Tabelle XYZ, SETZE SSN = 421-66-4567
Dann kann die umgeschriebene Anfrage sein:
AKTUALISIERE Tabelle XYZ, SETZE SSN = Tokenisiere(421-66-4567)
Die Tokenisiere-Funktion kann dem DNR-Agenten 505, der auf der Mustertokenisierter-Datenbank läuft, angeben, dass er einen Token-Wert für die Aktualisierungsdaten erstellen soll. Obwohl die gezeigte Tokenisiere-Funktion nur einen Parameter nimmt, ist dies nur aus Gründen der Klarheit so. Die Tokenisiere-Funktion kann viele Parameter nehmen. Beispielsweise kann die Tokenisiere-Funktion einen Parameter nehmen, einschließlich der DNR-Ursprungs-Signatur zur Überprüfung, so dass auf den DNR-Agenten nicht direkt zugegriffen werden kann. Die Funktion kann einen Parameter nehmen, der zu einem bestimmten Tokenisierungs-Schema gehört, das verwendet wird, oder einen Parameter mit Informationen verwendet, die sich auf eine bestimmte Benutzersitzung beziehen, wie beispielsweise einen Benutzersitzungs-Kennzeichnungsstempel. Die Funktion kann auch Sicherheitsdaten umfassen, die sich darauf Beziehen, welche Art von Werten zurückgeführt werden sollten, wie in größerem Detail in Bezug auf fiktive Werte diskutiert wird.
Wenn der DNR-Agent 505 die Tokenisiere-Funktion empfängt, kann er einen neuen Token für den Datenwert erzeugen, der in die Funktion übergeben wird, wenn so einer nicht bereits vorhanden ist. Zusätzlich kann der DNR-Agent 505 dann die relevanten Teile der Tabelle XYZ 502 mit dem tokenisierten Datenwert aktualisieren, entsprechend den Aktualisierungs-Anfrage-Spezifikationen, und die Token-zu-Daten-Wert-Beziehung an den Muster-Token-Tresor 503 zum Speichern senden. Natürlich werden in der Praxis viele Aktualisierungs-Befehle eine ”Wo”-Klausel enthalten, um anzugeben, welche Teile zu aktualisieren sind. Dies wird in größerem Detail in Bezug auf Filterwerte erläutert. Die Tokenisiere-Funktion kann optional auch einen Parameter enthalten, der dem DNR-Agenten anzeigt, ob der Tokenwert, der aus dem Datenwert erzeugt wird, zu dem Token-Tresor hinzugefügt werden sollte.
Unter Bezugnahme auf 6, wird der Muster-Token-Tresor zu zwei Zeitpunkten gezeigt, zu dem Zeitpunkt T-0 603, vor dem Empfang der Aktualisierungs-Anfrage, und zum Zeitpunkt T-1 604 nach dem Empfang der Aktualisierungs-Anfrage. Zusätzlich wird Tabelle XYZ auch zu den beiden Zeitpunkten T-0 601 und T-1 602 gezeigt.
Am Beispiel der spezifischen Aktualisierungs-Anfrage, wie oben erörtert, werden die Änderungen, sowohl an der Tabelle XYZ, als auch an dem Token-Tresor diskutiert. Da die Aktualisierungs-Anfrage einen Datenwert enthielt, der nicht bereits einen entsprechendem Token aufweist, die neue SSN-Nummer ”421-66-4567”, muss ein neuer Tokenwert für den Wert generiert werden. Der DNA-Agent erzeugt den neuen Token ”T5” mittels der entsprechenden Tokenisierungs-Regel. Die Tokenisierungs-Regel kann auf den DNR-Agenten während der Installation vorgeladen werden, oder zu einem bestimmten späteren Zeitpunkt aus dem Token-Tresor, der Datenbank oder anderen geeigneten Quellen empfangen werden.
Nach dem Erzeugen des Tokens T5 entsprechend der neuen Nummer 421-66-4567, werden der neue Token und der zugehörige Datenwert in dem Muster-Token-Tresor 604 gespeichert. Zusätzlich werden alle der SSNs für jeden der Einträge in Tabelle XYZ 602 mit dem neuen Token T5 aktualisiert. Wie oben erläutert, ist dies, weil die Aktualisierungs-Anfrage keine ”Wo”-Begrenzung umfasste.
Ähnlich der entToken-Funktion, kann die Tokenisiere-Funktion wahlweise auf Basis von Sicherheits- und Berechtigungs-Erwägungen angewendet werden, oder kann eine oder mehrere zusätzliche Variablen zur Muster-Datenbank übergeben. Diese Variationen werden mit Bezug auf die Sicherheits- und fiktiven Werte-Funktionen weiter unten erläutert werden.
Daten-Einfügen-Anfragen werden in ähnlicher Weise gehandhabt wie Daten-Aktualisieren-Anfragen, indem die Tokenisiere-Funktion für die neuen Daten verwendet wird. Falls so zum Beispiel ein Benutzer einen Eintrag zu Tabelle XYZ hinzufügen wollte, den Eintrag, der den Sozialversicherungs-Namen einer Person mit dem Namen ”Jackson” umfasst, könnte die Einfügen-Anfrage geschrieben werden als:
EINFÜGEN IN TABELLE XYZ, WERTE(Jackson, 162-97-2441)
Nachdem diese Anfrage von dem DNA abgefangen wird und neu geschrieben wird, um den Tokenisieren-Befehl zu umfassen, kann er zu der Muster-tokenisierten-Datenbank gesendet werden:
EINFÜGEN IN TABELLE XYZ, WERTE (Tokenisiere(Jackson), Tokenisiere(162-97-2441))
Dies wird den DNR-Agenten dazu alarmieren, der auf der Muster-tokenisierten-Datenbank ausgeführt wird, neue Tokenwerte für jeden der neuen Datenwerte zu erzeugen und die Datenbank und den Token-Tresor entsprechend zu aktualisieren.
Unter Bezugnahme auf 7 ist das Ergebnis des Einfügen-Befehls, der oben aufgeführt ist gezeigt. Tabelle XYZ zum Zeitpunkt T-0 701 stellt die Tabelle vor der Daten-Einfügen-Anfrage dar, die an die Datenbank gesendet wird, und Tabelle XYZ zum Zeitpunkt T-1 702 stellt die Tabelle dar, nachdem die Daten-Einfügen-Anfrage gesendet wurde. In ähnlicher Weise zeigt Token-Tresor zum Zeitpunkt T-0 703 den Token-Tresor vor der Daten-Einfügen-Anfrage, die an die Datenbank gesendet wird, und Token-Tresor zum Zeitpunkt T-1 704 stellt den Token-Tresor dar, nachdem die Daten-Einfügen-Anfrage gesendet wurde. Tabelle XYZ zum Zeitpunkt T-1 702 und Muster-Token-Tresor zum Zeitpunkt T-1 704 zeigen die Aufnahme von zwei neuen Token, T5 und T6. Diese beiden neuen Token entsprechen den neuen Datenwerten Jackson und 162-97-2441.
Viele Anfragen können Filter-Begriffe umfassen. Das bedeutet, Begriffe, die den Umfang und die Größe des Datensatzes reduzieren oder filtern, auf den die Anfrage angewandt wird. Unter Verwendung des früheren Beispiels der Tabelle XYZ 502 in 5, kann ein Benutzer den Nachnamen von jemandem haben und interessiert sein am Abrufen dessen Sozialversicherungsnummer (SSN), aber nicht der SSN jeder Person in der Tabelle. Falls die Person, nach deren SSN gesucht wird, den Namen ”Miller” hat, würde man in der Regel die folgende Abfrage an die Datenbank senden, um die SSN von Miller abzurufen:
WÄHLE SSN VON Tabelle XYZ WO Name=Miller
Wenn natürlich die Abfrage an die tokenisierte Tabelle XYZ in der tokenisierten Datenbank so gesendet werden würde, würde der Name Miller nicht gefunden werden und es würden keine Ergebnisse zurückgeben werden, da diese Abfrage für eine nicht-tokenisierte Datenbank vorgesehen ist. Um mit der tokenisierten Datenbank kompatibel zu sein, würde die Abfrage von dem DNA als umgeschrieben werden als:
Wähle entToken(SSN) VON Tabelle XYZ WO Name=Tokenisiere(Miller)
Die erste Veränderung der Anfrage ist das Einfügen der entToken-Funktion, wie es oben mit Bezug auf die Datenabfrage-Anfrage diskutiert wird. Die zweite Änderung der Anfrage ist das Einfügung der Tokenisiere-Funktion für den Filter-Datenwert ”Miller”. Dies alarmiert den DNR-Agenten, der auf der Datenbank läuft, den Tokenwert entsprechend ”Miller” nachzuschlagen, und dann diesen Tokenwert als Filter zu verwenden, bei der Auswahl von Sozialversicherungsnummern.
In diesem Fall ist der Tokenwert entsprechend ”Miller” T1, wodurch die Abfrage in der Auswahl der tokenisierten SSN resultiert, entsprechend T1, was T3 ist. Der DNR-Agent wird dann die entToken-Funktion auf T3 anwenden, um die SSN ”045-22-1246” zu erzeugen, die an den Benutzer zurückgegeben wird.
Gegebenenfalls kann die Tokenisiere-Funktion einen Parameter übergeben, der angibt, ob sie mit einem Datenwert-Einfügen, Datenwert-Aktualisieren, oder Datenwert-Filtern verbunden ist. Dies kann nützlich für den DNR-Agenten bei der Bestimmung sein, ob die Erzeugung eines neuen Tokens für den Datenwert erforderlich ist. Wenn zum Beispiel die Tokenisiere-Funktion mit einem Datenwert-Einfügen, oder Datenwert-Aktualisieren verwendet wird, kann der DNA-Agent den Token-Tresor überprüfen, um zu sehen, ob ein Tokenwert für den Datenwert vorhanden ist, und einen neuen Tokenwert erzeugen, wenn er nicht existiert. Wenn die Tokenisiere-Funktion mit einem Datenwert-Filtern verwendet wird, kann der DNR-Agent bestimmen, dass kein neuer Token erzeugt werden muss, da die Filter-Datenwerte verwendet werden, um einen ausgewählten Satz von Datenwerten zu filtern, und in die Datentabellen hinzugefügt werden. In dieser Situation kann der DNA-Agent nur den entsprechenden Tokenwert entsprechend der Datenwert-Filtern in dem Token-Tresor nachschlagen, und falls ein Tokenwert noch nicht vorhanden ist, kann der DNA-Agent korrekt bestimmen, dass keine Einträge dem Datenwert-Filter entsprechen, da ein Token hätte für den Datenwert erzeugt worden sein müsste, falls er in die Tabelle zuvor aufgenommen wurde. Alternativ kann die Tokenisiere-Funktion verwendet werden, um Token-Werte für alle übergebenen Datenwerte zu erzeugen, die nicht bereits einen zugeordneten Tokenwert haben.
Zusätzlich zu der Verwendung mit Datenabrufbefehlen, können Filter mit Aktualisierungen der in der Datenbank gespeicherten Datenwerte verwendet werden. Zum Beispiel unter Bezugnahme auf Tabelle XYZ 502 in 5, kann ein Benutzer wünschen, die SSN mit dem Namen ”Sanchez” zu aktualisieren. Um dies zu tun, könnte man die Anfrage übertragen:
AKTUALISIERE Tabelle XYZ, SETZE SSN = 123-45-6789 WO Name=Sanchez
Falls die Datenbank nicht in tokenisiert war, würde dies die SSN, die mit dem Namen ”Sanchez” assoziiert ist in ”123-45-6789” ändern. Da jedoch die Datenbank tokenisiert ist, muss die Anfrage umgeschrieben werden von dem DNA:
AKTUALISIERE Tabelle XYZ, SETZE SSN = Tokenisiere(123-45-6789) WO Name = Tokenisiere (Sanchez)
Die umgeschriebene Anfrage weist den DNR-Agenten an, einen neuen Token für den neuen Datenwert zu machen, der in die Datenbank aufgenommen wird, und den Tokenwert hinzuzufügen, wo der der Name gleich dem Tokenwert T2 ist. Wie zuvor, wird der Tokenwert entsprechend dem Namen Sanchez vom DNA bestimmt, dadurch, dass der DNA dieselben Tokenisierungs-Regeln anwendet, wie sie von dem DNR-Agenten verwendet werden.
Der DNA kann zusätzliche Arten von Datenbankzugriffsanfragen handhaben und umschreiben, die hier nicht speziell aufgezählt sind. Zum Beispiel kann der Benutzer eine Löschanfrage für einen spezifischen Daten-Eintrag übertragen. Natürlich ist beim Löschen eines Eintrags keine Tokenisierung oder Ent-Tokenisierung erforderlich, aber der DNR kann wahlweise die Daten durch Umschreiben der Anfrage übergeben, um eine removeToken-Funktion hinzuzufügen, die dem DNR-Agenten mitteilt, nicht nur den Eintrag zu entfernen, sondern auch die Token-zu-Daten-Beziehung aus dem Token-Tresor. Weitere Arten von Anfragen und Parameter, die von dem DNR auf eine tokenisierte Datenbank angepasst werden können, können beispielsweise ”Wähle-Eindeutig” (”select distinct”) und ”Sortiere-Nach” Modifikatoren umfassen.
Der DNR kann eine oder mehrere Regeln für den Umgang mit unvollständigen Anfragen haben. Bezugnehmend auf 8, kann der DNR eine Datenbankzugriffsanfrage in Schritt 801 empfangen und beurteilen, ob die Anfrage eine unvollständige Anfrage ist in Schritt 802. Unvollständige Anfragen können als Anfragen klassifiziert werden, bei denen durch eine oder mehrere Regeln bestimmt wurde, dass notwendigen Informationen fehlen. Unter Verwendung des früheren Beispiels der Tabelle XYZ 502 in 5, kann die Anfrage sein:
WÄHLE * VON Tabelle XYZ
In diesem Beispiel wird der Asterisk, oder Stern-Operator verwendet, um anzuzeigen, dass der Benutzer alle möglichen Felder in Tabelle XYZ auswählen möchte. Doch um die entToken-Funktion richtig zu nutzen, kann die Liste der tatsächlichen Spaltennamen erforderlich sein. Daher kann der DNR in Schritt 802 bestimmen, dass die Anfrage unvollständig ist, und zu Schritt 803 gehen, wo er eine Anfrage für die fehlenden Daten sendet. Die Anfrage kann an die Datenbank, den DNR-Agenten in der Datenbank, oder an einen anderen Speicher gesendet werden, der die Spaltennamen nachvollzieht. Zusätzlich können die fehlenden Informationen auch in einem gewissen Speicher auf dem DNR selbst gespeichert werden.
Im obigen Beispiel wird der DNR eine Liste aller Spalten anfragen, die in der Tabelle XYZ angezeigt werden, in Schritt 803. Dies würde dazu führen, dass der Spalten-Bezeichner für Name und SSN von dem DNR erhalten wird. In Schritt 804 überprüft der DNR, dass es keine zusätzlichen fehlende Daten gibt, und wenn ja, geht es weiter zu Schritt 805. Wenn es noch fehlende Informationen gibt, kann der DNR eine weitere Anfrage an die gleiche oder eine andere Quelle für die fehlenden Informationen senden.
In Schritt 805 schreitet der DNR zum umschreiben der Datenbankzugriffsanfrage fort, nicht nur gemäß der Anfrage-basierten Regeln, sondern auch um die fehlenden Informationen zu integrieren. So kann in dem obigen Beispiel die Anfrage zuerst so umgeschrieben werden:
WÄHLE Name, SSN AUS Tabelle XYZ
Danach kann die Anfrage des Weiteren umgeschrieben werden als:
WÄHLE entToken(Name), entToken(SSN) VON Tabelle XYZ
Dadurch wird sichergestellt, dass die Datenwerte in der Tabelle XYZ, und nicht die Tokenwerte, an den Benutzer zurückgegeben werden. Nachdem die Abfrage umgeschrieben ist, wird sie an die Datenbank in Schritt 806 gesendet.
Unter Bezugnahme auf 9, wird ein DNR Sicherheitsprozess zum Verhindern von nicht autorisiertem Zugriff auf eine Datenbank beschrieben. Das Verfahren kann als eine oder mehrere Sicherheitsregeln durchgeführt werden, die auf den DNR angewandt werden, wie zuvor erörtert. Nachdem die Anfrage im Schritt 901 erhalten wurde, ermittelt der DNR, ob der Benutzer berechtigt ist, die Anfrage in Schritt 902 zu machen. Dazu kann Bestimmen umfassen, ob der Benutzer berechtigt ist, irgendwelche Anfragen zu machen, wie Überprüfen eines unberechtigten Systembenutzers, sowie die Überprüfung, ob der Benutzer berechtigt ist, eine bestimmte Art von Anfrage zu machen, wie eine Aktualisierungs-Anfrage. So kann zum Beispiel ein Benutzer, der nu Lesezugriff hat, ermächtigt werden, eine ausgewählte Anfrage zu machen, aber keine Aktualisierungs-Anfrage. In anderen Situationen kann bestimmen werden, dass der Benutzer fehlende Berechtigung zum Zugriff auf die Datenbank in irgendeiner Weise hat.
Falls der Benutzer nicht über die Berechtigung für die Anfrage verfügt, kann in Schritt 904 eine Sicherheitsaktion von dem DNR durchgeführt werden. Die Sicherheitsaktion kann aus einer Vielzahl von möglichen Sicherheitsaktionen ausgewählt werden. Zum Beispiel kann der DNR die Anfrage umschreiben, um eine Flagge zu umfassen, die der Datenbank mitteilt, die Anfrage zu ignorieren, falls es eine Aktualisierung, oder Einfügung ist, oder fiktive Werte zurückzugeben, wenn es eine Auswahl-Anfrage ist. Zum Beispiel kann die Tokenisiere-Funktion konfiguriert werden, um mehrere Variablen zu übergeben, eine davon ist eine fiktive-Werte-Flagge, wie beispielsweise Tokenisiere(Wert, fictiver_Wert?). Wenn also der Benutzer ist nicht berechtigt ist, Aktualisierungen vorzunehmen und eine Aktualisierungs-Anfrage eingegeben hat, wie zum Beispiel:
AKTUALISIERE Tabelle XYZ, SETZE SSN = 123-45-6789
Dann kann die umgeschrieben Anfrage, die die Sicherheitsregeln beachtet, sein:
AKTUALISIERE Tabelle XYZ, SETZE SSN = Tokenisiere(123-45-6789, wahr)
Dies wird den DNR-Agenten darüber informieren, dass die Werte in der Tokenisiere-Funktion fiktiv sind und dass die Aktualisierung ignoriert werden sollte. Und falls die Anfrage eine Auswahl-Anfrage ist, kann die entToken-Funktion eine fiktive-Werte-Flagge übergeben. Falls also ein Benutzer nicht autorisiert ist und eine Auswahl-Anfrage eingegeben hat, wie beispielsweise:
WÄHLE Name VON Tabelle XYZ
Dann wäre die umgeschriebene Anfrage, die Sicherheitsregeln berücksichtigt:
WÄHLE entToken(Name, wahr) VON Tabelle XYZ
Dies würde den DNR benachrichtigen, dass fiktive Werte in Reaktion auf die Auswahl-Anfrage zurückgegeben werden sollten, anstatt die wirklichen ent-tokenisierten Werte. Dies kann auf viele Arten erreicht werden. Zum Beispiel kann ein Zufallszahlengenerator den Tokenwert als Startwert verwenden, um einen fiktiven Wert für die Rückgabe an den Benutzer zu erzeugen. Die fiktive Wert-Flagge in der entToken-, oder Tokenisiere-Funktion kann standardmäßig auf falsch gesetzt sein, kann aber auf wahr geändert werden, wenn ein nicht autorisierter Benutzer erkannt wird.
Zusätzlich dazu, dass eine fiktive-Werte-Flagge in der Tokenisiere- und entToken-Funktion ist, kann eine Fiktive-Werte-Funktion genutzt werden, um die Datenwerte zu übergeben. Zum Beispiel, anstatt eine entToken-Funktion zu verwenden, um den Datenwert zu übergeben, kann eine returnFictiveValue-Funktion verwendet werden, um den DNR Agenten dazu anzuweisen, einen fiktiven Wert als Reaktion auf die Datenanfrage zurückzugeben.
Darüber hinaus sind fiktiv Werte nicht der einzige Weg für den Umgang mit nicht autorisierten Benutzern oder Wünschen. Die entToken-Funktion kann eine Flagge umfassen, die dem DNR-Agenten dazu anweist, einen leeren oder NULL-Wert zurückzugeben, wenn ein Benutzer ohne Genehmigung ist, oder einen Tokenwert anstelle eines ent-tokenisierten Wertes zurückzugeben. Zusätzlich kann der DNR die Sicherheitsregeln verwenden, um eine Aktualisierungs-, Einfügungs-, oder Auswahl-Anfrage zu blockieren, wenn der Benutzer ohne Genehmigung ist. Viele Variationen sind möglich.
Falls der Benutzer die Berechtigung hat, die Anfrage zu stellen, bestimmt bei Schritt 903 der DNR, ob es irgendwelche geschützten Datenfelder in der Anfrage gibt. Zum Beispiel kann eine Tabelle in einer Datenbank mehrere Datenfelder enthalten, und eine oder mehrere von ihnen können auf nur eine Teilmenge der Anwender begrenzt werden, die Zugriff auf die Datenbank oder die Tabelle haben. Also kann im vorhergehenden Beispiel der Tabelle XYZ, das Feld ”Name” ein regelmäßiges Datenfeld sein, das für alle Benutzer zugänglich ist, während das Datenfeld ”SSN” auf eine Teilmenge der Benutzer eingeschränkt werden kann, wie beispielsweise auf Administratoren. Verschiedenen Berechtigungsstufen können mit verschiedenen Typen von Datenfeldern verwendet werden, und die Anzahl der Berechtigungsstufen ist nicht auf zwei beschränkt, sondern kann viele verschiedenen Stufen von Genehmigungen und zugehörige Datenfelder in einer Datenbank umfassen.
falls es keine geschützten Datenfelder gibt, dann wird in Schritt 905 die Anfrage verarbeitet, wie es normalerweise für einen autorisierten Benutzer geschieht. Wenn es geschützte Datenfelder gibt, dann untersucht der DNA in Schritt 906 Benutzer-Berechtigungsstufen für jedes geschützte Datenfeld und bestimmt, ob der Benutzer berechtigt ist, auf dieses Datenfeld in der Weise zuzugreifen, wie in der Anfrage angegeben. Dies kann durch den Vergleich der Berechtigungen/Autorisierungen des Benutzers mit den Berechtigungen/Autorisierungen geschehen, die für die Anfrage auf das geschützte Datenfeld erforderlich sind. Zum Beispiel kann ein geschütztes Datenfeld die Anforderung aufweisen, dass, um eine der Daten zu sehen, der Benutzer ”Stufe-5-Genehmigung” haben muss. Falls ein anffragender Benutzer niedriger als Stufe-5-Genehmigung ist, dann wird bestimmt, das die Genehmigung für die Anfrage auf dem geschützten Datenfeld fehlt. In ähnlicher Weise kann das gleiche geschützte Datenfeld eine Anforderung aufweisen, dass, um eine der Daten zu ändern, der Benutzer ”Stufe-7-Genehmigung” haben muss. Sogar ein Stufe-5-Benutzer, der Sicht-Zugriff hatte, wäre dann nicht in der Lage, die Daten in dem geschützten Datenfeld erfolgreich zu verändern. Mittels dem früheren Beispiel der Tabelle XYZ, kann eine Anfrage, die ausdrückt: ”WÄHLE SSN VON Tabelle XYZ” gestattet werden, während eine Anfrage ”AKTUALISIERE Tabelle XYZ, SETZE SSN = 123,45,6789” durch den selben Benutzer nicht autorisiert sein kann. Natürlich muss Autorisierung nicht in Stufen organisiert werden. So kann beispielsweise Autorisierung nach einer Benutzerrolle, einem Zustand oder irgendeiner anderen Grundlage für die Unterscheidung zwischen einem autorisierten Zugriff und einen nicht autorisierten Zugriff organisiert werden.
Falls der Benutzer keine Berechtigung hat, auf ein bestimmtes geschütztes Datenfeld zuzugreifen, dann kann der DNA eine Sicherheitsaktion für dieses geschützte Datenfeld in Schritt 908 ausführen. Diese Sicherheitsaktion kann ähnlich den Sicherheitsaktionen aus Schritt 904 sein, einschließlich der Fiktive-Werte-Flagge, aber kann insbesondere auf die geschützten Datenfelder, auf die der Benutzer keine Zugriffsberechtigung hat, anwenden. In dem Beispiel der Tabelle XYZ, falls ein Benutzer eine Berechtigung hat zum Zugriff auf das Namen-Feld, aber nicht das SSN-Feld, und die Anfrage überträgt:
WÄHLE Name, SSN VON Tabelle XYZ
Dann kann die Anfrage umgeschrieben werden, um die Fiktive-Werte-Flagge zu beinhalten:
WÄHLE entToken(Name, falsch), entToken(SSN, wahr) VON Tabelle XYZ
Diese umgeschriebene Anfrage teilt dem DNA mit, dass die entToken-Funktion für das Namenfeld keine fiktiven Werte zurückgeben sollte, sondern die tatsächlichen ent-tokenisierten Namenswerte, und für das SSN-Feld fiktive Werte zurückgeben sollte. Zusätzlich, wie bereits erwähnt, kann auch die Sicherheitsaktion für das nicht autorisierte Datenfeld NULL-Werte für das Feld zurückgeben, Tokenwerte statt entTokenisierte Werte zurückgeben, oder den Teil der Anfrage blockieren.
In Schritt 907 bestimmt der DNA, ob es zusätzliche geschützten Datenfelder gibt, und wenn ja, kehrt für zusätzliche Bestimmungen und Verarbeitungen zu Schritt 906 zurück. Falls es keine weiteren geschützten Datenwerte mehr gibt, dann fährt die Verarbeitung des Rests der Anfrage wie normal in Schritt 909 weiter.
Wie in dem oben beschriebenen Sicherheitsprozess verwendet, kann sich Autorisierung auf viele verschiedene Arten von Sicherheits-Berechtigungsnachweise und Autorisierungs-Schemata beziehen. Zum Beispiel kann die Autorisierung auf bestimmten Maschinenkennungen beruhen und nicht auf bestimmten Benutzern, Autorisierungen können auf Netzwerk-Informationen des Rechners basieren, von dem die Anfrage empfangen wird, Autorisierungs-Schemata wie beispielsweise verschiedene Stufen der Berechtigungen oder Privilegien können verwendet werden, sowie als Sicherheitstoken, Zertifikate oder andere Formen der Authentifizierung oder Autorisierung. Dazu kommt, dass obwohl die Fiktive-Werte-Flagge als Standard auf falsch festgelegt diskutiert wird, die Flagge auf wahr als Standard festgelegt werden kann (z. B. der Standardwert kann einen nicht autorisierten Benutzer oder Anfrage annehmen), und kann zu falsch geändert werden, wenn die Anfrage-Autorisierung bestätigt wird. Es sind viele Variationen möglich und die Sicherheitsregeln sind nicht auf die spezifischen hier offenbarten Beispiele für die Authentifizierung und Autorisierung beschränkt.
Zusätzlich zum Empfangen und Weiterleiten von Datenwerten in die Datenbank, kann der DNR auch Sicherheitstoken oder Berechtigungsnachweise an die Datenbank empfangen und übergeben. Der DNA kann einen Sicherheitstoken mit der Anfrage aus der Anwendung erhalten. Der Sicherheitstoken kann ein Berechtigungsnachweis sein, wie einem Kennwort, oder ein Zertifikat, oder andere Daten, die dem DNA ermöglichen, den Benutzer zu überprüfen und zu überprüfen, ob der Benutzer berechtigt ist.
Der DNR kann den Sicherheitstoken oder Berechtigungsnachweis authentifizieren oder anderweitig überprüfen, bevor er die Anfrage umschreibt und an die Datenbank sendet. Falls der Sicherheitstoken gültig ist, kann der DNR Flaggen benutzen, die ähnlich den Fiktive-Werte-Flaggen sind, wie oben diskutiert, um den DNR-Agenten darauf hinzuweisen, dass die Anfrage berechtigt und sicher ist. Zum Beispiel kann die Tokenisiere (oder entToken) Funktion zwei Parameter übergeben, von denen einer der Datenwert ist, und der andere die Gültigkeit des Sicherheitstokens angibt, wie Tokenisiere(Datenwert, valid_security_credential?).
Diese Sicherheitstoken-Flagge kann auch zusätzlich zu der Fiktive-Werte-Flagge in manchen Situationen übergeben werden. Zum Beispiel, wenn der mit einem Benutzer assoziierte Sicherheits-Token gültig ist, aber der Benutzer nicht ausreichende Rechte hat, um auf ein bestimmtes Datenfeld zugegriffen, dann können zwei Flaggen zusätzlich zu dem Datenwert in einer Tokenisiere- oder entToken-Funktion übergeben werden.
Die Sicherheits-Flagge kann von der Datenbank oder dem DNR-Agenten, der auf der Datenbank ausgeführt wird, verwendet werden, um festzustellen, wie die Anfrage zu bearbeiten ist. Zum Beispiel, falls eine entToken-Funktion empfangen wird, mit der Sicherheits-Flagge auf falsch gesetzt, dann kann der Ent-Tokenisierungs-Schritt weggelassen werden, was zu Tokenwerten führt, die an den Benutzer zurückgegeben werden. Und falls eine Tokenisiere-Funktion empfangen wird, mit der Sicherheits-Flagge auf falsch gesetzt, dann kann der DNR-Agent die Funktion ignorieren, anstelle den mit übergebenen Datenwert zu tokenisieren. So kann eine entToken-Funktion, wie entToken(Name, fictiver_Wert?, gültiger_Sicherheitsnachweis?), fiktive Werte für Namen zurückgeben, wenn die Berechtigungsnachweise gültig sind, aber der Benutzer nicht über ausreichende Berechtigungen verfügt, um Namen abzurufen, und keine Werte zurückgeben, wenn die Berechtigungsnachweise ungültig sind.
Zusätzlich können der Sicherheitstoken/die Berechtigungsnachweise, die an dem DNR empfangen werden, zu dem DNR-Agenten als Argument in einer der Funktionen übergeben werden. In diesem Szenario kann eine Bewertung der Gültigkeit der Sicherheitstoken/Berechtigungsnachweise direkt an dem DNR-Agenten und nicht an dem DNR durchgeführt werden.
ine oder mehrere der oben beschriebenen Techniken können in einem oder mehreren Computersystemen implementiert werden oder beinhaltet sein. 10 stellt ein allgemeines Beispiel einer Rechnerumgebung 1000 dar. Die Rechnerumgebung 1000 beabsichtigt nicht, irgendeine Einschränkung auf den Umfang der Nutzung oder Funktionalität einer beschriebenen Ausführung zu suggerieren.
Mit Bezug auf 10 umfasst die Rechnerumgebung 100 mindestens eine Verarbeitungseinheit 1010 und einen Speicher 1020. Die Verarbeitungseinheit 1010 führt computerausführbaren Anweisungen aus und kann ein realer oder ein virtueller Prozessor sein. In einem Multiprozessorsystem führen mehrere Verarbeitungseinheiten computerausführbare Befehle durch, um die Verarbeitungsleistung zu erhöhen. Der Speicher 1020 kann flüchtiger Speicher (z. B. Register, Cachespeicher, RAM), nichtflüchtiger Speicher (z. B. ROM, EEPROM, Flash-Speicher, etc.), oder eine Kombination aus beiden sein. Der Speicher 1020 kann Software 1080 speichern, die die beschriebenen Techniken implementiert.
Eine Rechenumgebung kann zusätzliche Funktionen haben. Beispielsweise umfasst die Rechnerumgebung 1000 Speicher 1040, eine oder mehrere Eingabevorrichtungen 1050, eine oder mehrere Ausgabevorrichtungen 1060, und eine oder mehrere Kommunikationsverbindungen 1090. Ein Verbindungsmechanismus 1070, wie beispielsweise ein Bus-Controller oder Netzwerk verbindet die Komponenten der Berechnungsumgebung 1000. Typischerweise stellen die Betriebssystemsoftware oder Firmware (nicht gezeigt) eine Betriebsumgebung für andere Software bereit, die in der Rechnerumgebung 1000 laufen, und koordiniert die Aktivitäten der Komponenten der Rechnerumgebung 1000.
Der Speicher 1040 kann entfernbar oder nicht-entfernbar sein und umfasst Magnetplatten, Magnetbänder oder Kassetten, CD-ROMs, CD-RWs, DVDs oder jedes andere Medium, das verwendet werden kann, um Informationen zu speichern und auf die zugegriffen werden kann, innerhalb der Rechenumgebung 1000. Der Speicher 1040 kann Anweisungen für die Software 1080 speichern.
Die Eingabevorrichtung(en) 1050 kann ein Berührungseingabegerät, wie beispielsweise eine Tastatur, eine Maus, einen Stift, einen Trackball, Touchscreen oder Game-Controller, eine Spracheingabeeinrichtung, einer Abtastvorrichtung, eine Digitalkamera, Fernsteuerung, oder ein anderes Gerät sein, das Eingaben an die Rechnerumgebung 1000 liefert. Die Ausgabevorrichtung(en) 1060 kann eine Anzeige, Fernseher, Monitor, Drucker, Lautsprecher oder eine andere Vorrichtung sein, die Ausgabe aus der Rechnerumgebung 1000 liefert.
Die Kommunikationsverbindung(en) 1090 ermöglichen die Kommunikation über ein Kommunikationsmedium an eine andere Recheneinheit. Das Kommunikationsmedium transportiert Informationen, wie durch computerausführbare Befehle, Audio- oder Videoinformation oder andere Daten in einem modulierten Datensignal. Ein moduliertes Datensignal ist ein Signal, das eine oder mehrere seiner Eigenschaften so eingestellt oder verändert hat, dass Informationen in dem Signal kodiert sind. Beispielhaft und nicht als Beschränkung gedacht, umfassen Kommunikationsmedien drahtgebundene oder drahtlose Techniken mit einem elektrischen, optischen, HF-, Infrarot-, akustische oder anderem Träger implementiert.
Implementierungen können im allgemeinen Kontext von computerlesbaren Medien beschrieben werden. Computerlesbare Medien sind beliebige verfügbare Medien, auf die innerhalb einer Rechnerumgebung zugegriffen werden kann. Beispielhaft und nicht als Einschränkung gedacht, umfassen in der Rechnerumgebung 1000 computerlesbaren Medien Speicher 1020, Speicher 1040, Kommunikationsmedien und Kombinationen aus beliebigen der oben genannten.
Natürlich stellt 10 Rechenumgebung 1000, Anzeigevorrichtung 1060, und Eingabevorrichtung 1050 als separate Vorrichtungen dar, zur Erleichterung der Identifikation. Rechnerumgebung 1000, Anzeigevorrichtung 1060, und Eingabevorrichtung 1050 können separate Vorrichtungen sein (z. B. ein Personalcomputer, der durch Kabel mit einem Monitor und einer Maus verbunden ist), können in einer einzigen Vorrichtung integriert sein (beispielsweise ein Mobilgerät mit einer berührungsempfindlichen Anzeige, wie ein Smartphone oder ein Tablet), oder eine beliebige Kombination von Vorrichtungen sein (beispielsweise eine Rechenvorrichtung, die mit einer Touch-Screen-Anzeigevorrichtung gekoppelt ist, eine Vielzahl von Rechenvorrichtungen, die zu einer einzigen Anzeigevorrichtung und Eingabevorrichtung verbunden sind, etc.). Computerumgebung 1000 kann eine Set-Top-Box, ein PC oder ein oder mehrere Server sein, zum Beispiel eine Farm vernetzter Server, eine Server-Clusterumgebung oder ein Cloud-Netzwerk von Recheneinrichtungen.
Nach der Beschreibung und Darstellung der Prinzipien unserer Erfindung unter Bezugnahme auf die beschriebene Ausführungsform, wird man erkennen, dass die beschriebene Ausführungsform in Anordnung und Detail ohne Abweichung von solchen Prinzipien modifiziert werden kann. Es versteht sich, dass die hier beschriebenen Programme, Prozesse oder Verfahren nicht auf eine bestimmte Art von Computerumgebung beschränkt sind, wenn nicht anders angegeben. Verschiedene Arten von Allzweck- oder Spezial-Computer-Umgebungen können in Übereinstimmung mit Operationen mit den hierin beschriebenen Lehren verwendet werden. Elemente der in Software dargestellt beschriebenen Ausführungsform kann in Hardware und umgekehrt umgesetzt werden.
In Anbetracht der vielen möglichen Ausführungsformen, auf die die Prinzipien unserer Erfindung angewendet werden können, beanspruchen wir als unsere Erfindung alle derartigen Ausführungsformen, die innerhalb des Umfangs und des Geistes der folgenden Ansprüche und deren Äquivalente kommen.

Claims

Datenbanknetzwerkrouter-Vorrichtung zur Datentokenisierung, wobei die Vorrichtung umfasst: einen oder mehrere Prozessoren; und einen oder mehrere Speicher, die betriebsfähig mit wenigsens einem des einen oder der mehreren Prozessoren verbunden ist/sind und Instruktionen darauf gespeichert hat/haben, die, wenn sie durch mindestens einen des einen oder der mehreren Prozessoren ausgeführt werden, mindestens einen des einen oder der mehreren Prozessoren veranlasst zum: Empfangen einer Datenbankzugriffsanfrage, die an eine tokenisierte Datenbank gerichtet ist, wobei die tokenisierte Datenbank einen oder mehrere tokenisierte Datenwerte umfasst; Anwenden von einer oder mehreren Regeln auf die Anfrage; Umschreiben der Anfrage, auf Basis zumindest einer der einen oder der mehreren Regeln, so dass Datenwerte, die in die tokenisierte Datenbank hinzugefügt werden, tokenisierte Datenwerte sein werden, und Datenwerte, die von der tokenisierten Datenbank empfangen werden, nicht-tokenisierte Datenwerte sein werden; und Übertragen der umgeschriebenen Anfrage an die tokenisierte Datenbank.
Datenbanknetzwerkrouter-Vorrichtung nach Anspruch 1, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Auswählen einer Abfrage-Regel, wenn die Datenbankzugriffsanfrage eine Datenabfrage-Anfrage ist; und Umschreiben der Anfrage, um einen ent-token-Befehl in die Anfrage einzufügen, wobei der ent-token-Befehl an einen Software-Agent signalisiert, der in einer tokenisierten Datenbank angesiedelt ist, die tokenisierten Datenwerte zu ent-tokenisieren, die aus ein Ergebnis der Anfrage vor Übertragung der Datenwerte zurück an den Datenbanknetzwerkrouter empfangen werden.
Datenbanknetzwerkrouter-Vorrichtung nach Anspruch 1, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Auswählen einer Aktualisierungs-Regel, wenn die Datenbankzugriffsanfrage eine Datenaktualisierungs-Anfrage ist, wobei die Datenaktualisierungs-Anfrage des Weiteren einen oder mehrere neue Datenwerte umfasst; und Umschreiben der Anfrage, um einen Tokenisieren-Befehl in die Anfrage einzufügen, wobei der Tokenisieren-Befehl an einen Software-Agent signalisiert, der in einer tokenisierten Datenbank angesiedelt ist, den einen oder die mehreren neuen Datenwerte zu tokenisieren, bevor sie in die tokenisierte Datenbank hinzugefügt werden
Datenbanknetzwerkrouter-Vorrichtung nach Anspruch 1, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Auswählen einer Einfügen-Regel, wenn die Datenbankzugriffsanfrage eine Daten-Einfügen-Anfrage ist, wobei die Daten-Einfügen-Anfrage des Weiteren einen oder mehrere neue Datenwerte umfasst; und Umschreiben der Anfrage, um einen Tokenisieren-Befehl in die Anfrage einzufügen, wobei der Tokenisieren-Befehl an einen Software-Agent signalisiert, der in einer tokenisierten Datenbank angesiedelt ist, den einen oder die mehreren neuen Datenwerte zu tokenisieren, bevor sie in die tokenisierte Datenbank eingefügt werden.
Datenbanknetzwerkrouter-Vorrichtung nach Anspruch 1, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Auswählen einer Begriff-Filter-Regel, wenn die Anfrage einen oder mehrere Filter-Datenwerte umfasst, wobei der eine oder die mehreren Filter-Datenwerte die Anfrage auf eine Teilmenge von Einträge beschränkt, die sich auf den einen oder die mehreren Filter-Datenwerte bezieht; und Umschreiben der Anfrage, um einen Tokenisieren-Befehl in die Anfrage einzufügen, wobei der Tokenisieren-Befehl an einen Software-Agent signalisiert, der in einer tokenisierten Datenbank angesiedelt ist, den einen oder die mehreren Filter-Datenwerte zu tokenisieren, bevor die Anfrage auf die tokenisierte Datenbank ausgeführt wird.
Datenbanknetzwerkrouter-Vorrichtung nach Anspruch 1, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Auswählen einer Unvollständige-Anfrage-Regel, wenn die Anfrage als unvollständig bestimmt wird; Übertragen einer Anfrage für fehlende Daten an die tokenisierte Datenbank, wobei die fehlenden Daten der unvollständige Teil der Datenbankzugriffsanfrage ist; Empfangen der fehlenden Daten aus der tokenisierten Datenbank; und Umschreiben der Datenbankzugriffsanfrage, um fehlende Daten einzuschließen.
Datenbanknetzwerkrouter-Vorrichtung nach Anspruch 1, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Vergleichen der Berechtigungsstufe, die mit der Anfrage verbunden ist, mit der Berechtigungsstufe, die erforderlich ist, um auf ein oder auf mehrere Datenfelder in der tokenisierten Datenbank zuzugreifen; Identifizieren von einem oder von mehreren nicht autorisierten Datenfelder in der Anfrage, auf Basis des Vergleichs; für jedes nicht autorisierte Datenfeld in der Anfrage, Umschreiben der Anfrage, um einen Fiktive-Daten-Befehl in die Anfrage einzufügen, wobei der Fiktive-Daten-Befehl an einen Software-Agenten signalisiert, der in einer tokenisierten Datenbank angesiedelt ist, fiktive Datenwerte in Reaktion auf die Anfrage zurück zu geben, falls die Anfrage eine Datenabfrage-Anfrage für Daten in dem nicht autorisierten Datenfeld ist, oder die Datenwerte, die an den Software-Agenten als fiktive Werte gegeben werden außer Acht lassen, falls die Anfrage eine Aktualisierungs- oder Einfügen-Anfrage ist, die Daten in dem nicht autorisierten Datenfeld umfasst.
Datenbanknetzwerkrouter-Vorrichtung nach Anspruch 1, wobei die Datenbankzugriffsanfrage einen Sicherheitsnachweis umfasst und der Sicherheitsnachweis an die tokenisierte Datenbank als Teil der umgeschriebenen Anfrage übertragen wird.
Computerimplementiertes Verfahren zur Datentokenisierung durch eine oder mehrere Computervorrichtungen, wobei das Verfahren umfasst: Empfangen, durch die eine oder mehreren Computervorrichtungen, einer Datenbankzugriffsanfrage, die an eine tokenisierte Datenbank gerichtet ist, wobei die tokenisierte Datenbank einen oder mehrere tokenisierte Datenwerte umfasst; Anwenden, durch eine oder mehrere Computervorrichtungen, von einer oder mehreren Regeln auf die Anfrage; Umschreiben, durch die eine oder die mehreren Computervorrichtungen, der Anfrage, auf Basis zumindest einer der einen oder der mehreren Regeln, so dass Datenwerte, die in die tokenisierte Datenbank hinzugefügt werden, tokenisierte Datenwerte sein werden, und Datenwerte, die von der tokenisierten Datenbank empfangen werden, nicht-tokenisierte Datenwerte sein werden; und Übertragen, durch die eine oder die mehreren Computervorrichtungen, der umgeschriebenen Anfrage an die tokenisierte Datenbank.
Computerimplementiertes Verfahren nach Anspruch 9, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Auswählen, durch die eine oder die mehreren Computervorrichtungen, einer Abfrage-Regel, wenn die Datenbankzugriffsanfrage eine Datenabfrage-Anfrage ist; und Umschreiben, durch die eine oder die mehreren Computervorrichtungen, der Anfrage, um einen ent-token-Befehl in die Anfrage einzufügen, wobei der ent-token-Befehl an einen Software-Agent signalisiert, der in einer tokenisierten Datenbank angesiedelt ist, die tokenisierten Datenwerte zu ent-tokenisieren, die aus ein Ergebnis der Anfrage vor Übertragung der Datenwerte zurück an den Datenbanknetzwerkrouter empfangen werden.
Computerimplementiertes Verfahren nach Anspruch 9, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Auswählen, durch die eine oder die mehreren Computervorrichtungen, einer Aktualisierungs-Regel, wenn die Datenbankzugriffsanfrage eine Datenaktualisierungs-Anfrage ist, wobei die Datenaktualisierungs-Anfrage des Weiteren einen oder mehrere neue Datenwerte umfasst; und Umschreiben, durch die eine oder die mehreren Computervorrichtungen, der Anfrage, um einen Tokenisieren-Befehl in die Anfrage einzufügen, wobei der Tokenisieren-Befehl an einen Software-Agent signalisiert, der in einer tokenisierten Datenbank angesiedelt ist, den einen oder die mehreren neuen Datenwerte zu tokenisieren, bevor sie in die tokenisierte Datenbank hinzugefügt werden.
Computerimplementiertes Verfahren nach Anspruch 9, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Auswählen, durch die eine oder die mehreren Computervorrichtungen, einer Einfügen-Regel, wenn die Datenbankzugriffsanfrage eine Daten-Einfügen-Anfrage ist, wobei die Daten-Einfügen-Anfrage des Weiteren einen oder mehrere neue Datenwerte umfasst; und Umschreiben, durch die eine oder die mehreren Computervorrichtungen, der Anfrage, um einen Tokenisieren-Befehl in die Anfrage einzufügen, wobei der Tokenisieren-Befehl an einen Software-Agent signalisiert, der in einer tokenisierten Datenbank angesiedelt ist, den einen oder die mehreren neuen Datenwerte zu tokenisieren, bevor sie in die tokenisierte Datenbank eingefügt werden.
Computerimplementiertes Verfahren nach Anspruch 9, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Auswählen, durch wenigstens eine der einen oder der mehreren Computervorrichtungen, einer Begriff-Filter-Regel, wenn die Anfrage einen oder mehrere Filter-Datenwerte umfasst, wobei der eine oder die mehreren Filter-Datenwerte die Anfrage auf eine Teilmenge von Einträge beschränkt, die sich auf den einen oder die mehreren Filter-Datenwerte bezieht; und Umschreiben, durch wenigstens eine der einen oder der mehreren Computervorrichtungen, der Anfrage, um einen Tokenisieren-Befehl in die Anfrage einzufügen, wobei der Tokenisieren-Befehl an einen Software-Agent signalisiert, der in einer tokenisierten Datenbank angesiedelt ist, den einen oder die mehreren Filter-Datenwerte zu tokenisieren, bevor die Anfrage auf die tokenisierte Datenbank ausgeführt wird.
Computerimplementiertes Verfahren nach Anspruch 9, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Auswählen, durch die eine oder die mehreren Computervorrichtungen, einer Unvollständige-Anfrage-Regel, wenn die Anfrage als unvollständig bestimmt wird; Übertragen, durch die eine oder die mehreren Computervorrichtungen, einer Anfrage für fehlende Daten an die tokenisierte Datenbank, wobei die fehlenden Daten der unvollständige Teil der Datenbankzugriffsanfrage ist; Empfangen, durch die eine oder die mehreren Computervorrichtungen, der fehlenden Daten aus der tokenisierten Datenbank; und Umschreiben, durch die eine oder die mehreren Computervorrichtungen, der Datenbankzugriffsanfrage, um fehlende Daten einzuschließen.
Computerimplementiertes Verfahren nach Anspruch 9, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Vergleichen, durch die eine oder die mehreren Computervorrichtungen, der Berechtigungsstufe, die mit der Anfrage verbunden ist, mit der Berechtigungsstufe, die erforderlich ist, um auf ein oder auf mehrere Datenfelder in der tokenisierten Datenbank zuzugreifen; Identifizieren, durch die eine oder die mehreren Computervorrichtungen, von einem oder von mehreren nicht autorisierten Datenfelder in der Anfrage, auf Basis des Vergleichs; für jedes nicht autorisierte Datenfeld in der Anfrage, Umschreiben, durch die eine oder die mehreren Computervorrichtungen, der Anfrage, um einen Fiktive-Daten-Befehl in die Anfrage einzufügen, wobei der Fiktive-Daten-Befehl an einen Software-Agenten signalisiert, der in einer tokenisierten Datenbank angesiedelt ist, fiktive Datenwerte in Reaktion auf die Anfrage zurück zu geben, falls die Anfrage eine Datenabfrage-Anfrage für Daten in dem nicht autorisierten Datenfeld ist, oder die Datenwerte, die an den Software-Agenten als fiktive Werte gegeben werden außer Acht lassen, falls die Anfrage eine Aktualisierungs- oder Einfügen-Anfrage ist, die Daten in dem nicht autorisierten Datenfeld umfasst.
Computerimplementiertes Verfahren nach Anspruch 9, wobei die Datenbankzugriffsanfrage einen Sicherheitsnachweis umfasst und der Sicherheitsnachweis an die tokenisierte Datenbank als Teil der umgeschriebenen Anfrage übertragen wird.
Wenigstens ein dauerhaftes Computerlesbares Medium, das computerlesbare Instruktionen speichert, die, wenn sie durch eine oder mehrere Computervorrichtungen ausgeführt werden, wenigstens eine der einen oder der mehreren Computervorrichtungen veranlassen zum: Empfangen einer Datenbankzugriffsanfrage, die an eine tokenisierte Datenbank gerichtet ist, wobei die tokenisierte Datenbank einen oder mehrere tokenisierte Datenwerte umfasst; Anwenden von einer oder mehreren Regeln auf die Anfrage; Umschreiben der Anfrage, auf Basis zumindest einer der einen oder der mehreren Regeln, so dass Datenwerte, die in die tokenisierte Datenbank hinzugefügt werden, tokenisierte Datenwerte sein werden, und Datenwerte, die von der tokenisierten Datenbank empfangen werden, nicht-tokenisierte Datenwerte sein werden; und Übertragen der umgeschriebenen Anfrage an die tokenisierte Datenbank.
Wenigstens ein dauerhaftes Computerlesbares Medium nach Anspruch 17, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Auswählen einer Abfrage-Regel, wenn die Datenbankzugriffsanfrage eine Datenabfrage-Anfrage ist; und Umschreiben der Anfrage, um einen ent-token-Befehl in die Anfrage einzufügen, wobei der ent-token-Befehl an einen Software-Agent signalisiert, der in einer tokenisierten Datenbank angesiedelt ist, die tokenisierten Datenwerte zu ent-tokenisieren, die aus ein Ergebnis der Anfrage vor Übertragung der Datenwerte zurück an den Datenbanknetzwerkrouter empfangen werden.
Wenigstens ein dauerhaftes Computerlesbares Medium nach Anspruch 17, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Auswählen einer Aktualisierungs-Regel, wenn die Datenbankzugriffsanfrage eine Datenaktualisierungs-Anfrage ist, wobei die Datenaktualisierungs-Anfrage des Weiteren einen oder mehrere neue Datenwerte umfasst; und Umschreiben der Anfrage, um einen Tokenisieren-Befehl in die Anfrage einzufügen, wobei der Tokenisieren-Befehl an einen Software-Agent signalisiert, der in einer tokenisierten Datenbank angesiedelt ist, den einen oder die mehreren neuen Datenwerte zu tokenisieren, bevor sie in die tokenisierte Datenbank hinzugefügt werden
Wenigstens ein dauerhaftes Computerlesbares Medium nach Anspruch 17, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Auswählen einer Einfügen-Regel, wenn die Datenbankzugriffsanfrage eine Daten-Einfügen-Anfrage ist, wobei die Daten-Einfügen-Anfrage des Weiteren einen oder mehrere neue Datenwerte umfasst; und Umschreiben der Anfrage, um einen Tokenisieren-Befehl in die Anfrage einzufügen, wobei der Tokenisieren-Befehl an einen Software-Agent signalisiert, der in einer tokenisierten Datenbank angesiedelt ist, den einen oder die mehreren neuen Datenwerte zu tokenisieren, bevor sie in die tokenisierte Datenbank eingefügt werden.
Wenigstens ein dauerhaftes Computerlesbares Medium nach Anspruch 17, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Auswählen einer Begriff-Filter-Regel, wenn die Anfrage einen oder mehrere Filter-Datenwerte umfasst, wobei der eine oder die mehreren Filter-Datenwerte die Anfrage auf eine Teilmenge von Einträge beschränkt, die sich auf den einen oder die mehreren Filter-Datenwerte bezieht; und Umschreiben der Anfrage, um einen Tokenisieren-Befehl in die Anfrage einzufügen, wobei der Tokenisieren-Befehl an einen Software-Agent signalisiert, der in einer tokenisierten Datenbank angesiedelt ist, den einen oder die mehreren Filter-Datenwerte zu tokenisieren, bevor die Anfrage auf die tokenisierte Datenbank ausgeführt wird.
Wenigstens ein dauerhaftes Computerlesbares Medium nach Anspruch 17, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Auswählen einer Unvollständige-Anfrage-Regel, wenn die Anfrage als unvollständig bestimmt wird; Übertragen einer Anfrage für fehlende Daten an die tokenisierte Datenbank, wobei die fehlenden Daten der unvollständige Teil der Datenbankzugriffsanfrage ist; Empfangen der fehlenden Daten aus der tokenisierten Datenbank; und Umschreiben der Datenbankzugriffsanfrage, um fehlende Daten einzuschließen.
Wenigstens ein dauerhaftes Computerlesbares Medium nach Anspruch 17, wobei Anwenden einer oder mehrerer Regeln und Umschreiben der Anfrage umfasst: Vergleichen der Berechtigungsstufe, die mit der Anfrage verbunden ist, mit der Berechtigungsstufe, die erforderlich ist, um auf ein oder auf mehrere Datenfelder in der tokenisierten Datenbank zuzugreifen; Identifizieren von einem oder von mehreren nicht autorisierten Datenfelder in der Anfrage, auf Basis des Vergleichs; für jedes nicht autorisierte Datenfeld in der Anfrage, Umschreiben der Anfrage, um einen Fiktive-Daten-Befehl in die Anfrage einzufügen, wobei der Fiktive-Daten-Befehl an einen Software-Agenten signalisiert, der in einer tokenisierten Datenbank angesiedelt ist, fiktive Datenwerte in Reaktion auf die Anfrage zurück zu geben, falls die Anfrage eine Datenabfrage-Anfrage für Daten in dem nicht autorisierten Datenfeld ist, oder die Datenwerte, die an den Software-Agenten als fiktive Werte gegeben werden außer Acht lassen, falls die Anfrage eine Aktualisierungs- oder Einfügen-Anfrage ist, die Daten in dem nicht autorisierten Datenfeld umfasst.
Wenigstens ein dauerhaftes Computerlesbares Medium nach Anspruch 17, wobei die Datenbankzugriffsanfrage einen Sicherheitsnachweis umfasst und der Sicherheitsnachweis an die tokenisierte Datenbank als Teil der umgeschriebenen Anfrage übertragen wird.