Beschreibung

Technisches Gebiet

Die vorliegenden Darstellungen betreffen IT-Systeme und insbesondere die Zu- griffskontrolle auf von IT-Systemen verwaltete Datenobjekte mittels Zertifikaten. Stand der Technik

Aus dem Stand der Technik sind verschiedene Ansätze zur Zugriffskontrolle auf in IT-Systemen wie z.B. Datenbanken gespeicherte Daten bekannt. Beispielsweise können klassische, SQL basierte Datenbanken verwendet werden, die von entsprechend geschultem Personal verwaltet werden. Ein oder mehrere Datenbankadministratoren sind verantwortlich für die Pflege der Daten und die Einrichtung von Datenbanken und Datenbanknutzern.

So zeigt beispielsweise Figur 3 eine typische Organisationsstruktur eines Unter- nehmens und die organisatorische Einbettung der Datenbanken und der Tätigkeit der Administratoren in die Unternehmenshierarchie. Typischerweise sind in einem Unternehmen ein oder mehrerer Geschäftsführer 302 sowie mehrere Abteilungsleiter 304, 306 tätig. Diesen untergeordnet sind Leiter 308, 310, 312 einzelner technischer Teams, die für die Sicherheit und Verfügbarkeit der IT-Struktur oder für die Entwicklung Unternehmensrelevanter Applikationen verantwortlich sind. Zur IT Sicherheit können mehrere Administratoren 314, 316, 318 gehören, die ebenfalls hierarchisch organisiert sind.

Scheidet nun ein Mitarbeiter„Otto" aus dem Unternehmen aus, oder liegt der Verdacht einer Untreue vor, kann es notwendig sein, dem Mitarbeiter„Otto" sehr kurz- fristig seine Zugangsberechtigungen zu sensiblen Unternehmensdaten zu entziehen. Im Stand der Technik erfolgt dies typischerweise dadurch, dass eine leitende Stelle, z.B. der Geschäftsführer oder Leiter der Personalabteilung, die Aufgabe des Entzugs der Zugriffsberechtigung über mehrere Hierarchiestufen weitergibt („delegieren"). Dies ist oft mit erheblichen zeitlichen Verzögerungen verbunden, da jede krankheits- oder urlaubsbedingte Abwesenheit eines Mitarbeiters innerhalb der Kette zu entsprechenden Verzögerungen führt. Oder der Geschäftsführer oder bzw. Leiter der Personalabteilung greift selbst ein („durchgreifen"), was aber den Nachteil hat, dass Personen, die ohnehin im Regelfall zeitlich überlastet sind, sich auch noch um IT-nahe Verwaltungstätigkeiten kümmern müssen. In einem weiteren Aspekt werden im Stand der Technik oft rollenbasierte Zugriffsberechtigungssysteme verwendet wie in Figur 4 dargestellt. Diese haben jedoch den Nachteil, dass nicht mehr nachvollzogen werden kann, welcher Nutzer für eine bestimmte Datenveränderung verantwortlich war, da mehrere Nutzer unter derselben Rolle handeln können. Insbesondere für die Verwaltung sicherheitskritischer, sensibler Daten ist daher der Einsatz rollenbasierter Systeme zur Verwaltung von Zugriffsrechten problematisch.

In einem weiteren Aspekt haben im Stand der Technik verwendete Zugriffsverwaltungssysteme den Nachteil, dass die technischen Administratoren notwendiger- weise Zugriff auf alle Daten des Unternehmens einschließlich der Daten des Geschäftsführers haben. Dies birgt die Gefahr, dass sensible Daten nach außen dringen.

Technisches Problem und grundlegende Lösungen

Mit den bekannten IT-Systemen und Datenbanken und diesbezüglich entwickelten Verfahren der Zugriffsverwaltung und/oder Organisation von Daten sind zwar Möglichkeiten zur Verwaltung der Zugriffsrechte einzelner Nutzer auf verschiedene In- halte von Datenbanken gegeben. Im Kontext einer typischen Organisationsstruktur mittelständischer oder großer Unternehmen bedeutet dies aber Nachteile in Bezug auf die Geschwindigkeit und Flexibilität, mit der Zugriffsrechte geändert werden können und in Bezug auf die klare Feststellbarkeit von Verantwortlichkeiten. Vor diesem Hintergrund besteht ein Bedarf an verbesserten Verfahren zur Verwaltung von Zugriffsrechten und an entsprechend verbesserten Zugriffs- Verwaltungssysteme insofern, dass die vorangehend erwähnten Nachteile damit zumindest teilweise vermeidbar sind. Der Erfindung liegt demgegenüber die Aufgabe zugrunde, ein verbessertes Verfahren zur Zugriffskontrolle auf Datensätze zu schaffen, sowie ein entsprechendes Zugriffskontrollsystem. Die der Erfindung zugrundeliegenden Aufgaben werden jeweils mit den Merkmalen der unabhängigen Patentansprüche gelöst. Ausführungsformen der Erfindung sind in den abhängigen Ansprüchen angegeben. Die im Folgenden aufgeführten Ausfüh- rungsformen sind frei miteinander kombinierbar, sofern sie sich nicht gegenseitig ausschließen.

In einem Aspekt betrifft die Erfindung ein Verfahren zur Zugriffskontrolle auf Datensätze. Das Verfahren umfasst:

- Verknüpfung eines ersten Eigner-Zertifikats, das einer Nutzdaten-Datenbank zu- geordnet ist, mit einem ersten Nutzer, wobei ein Eigner-Zertifikat ein Zertifikat ist, das einer oder mehreren Nutzdaten-Datenbanken zugeordnet ist und jedem Nutzer, mit dem es verknüpft ist, das Recht gewährt, Datensätze in dieser Nutzdaten-Datenbank anzulegen;

- Bereitstellung einer ersten Schnittstelle, die es dem ersten Nutzer ermöglicht, ein zweites Eigner-Zertifikat für die Nutzdaten-Datenbank zu erstellen und dieses mit einem zweiten Nutzer zu verknüpfen um diesem zu ermöglichen, Datensätze in der Nutzdaten-Datenbank anzulegen;

- Bereitstellung einer zweiten Schnittstelle, die es dem zweiten Nutzer, der einen Datensatz in der Nutzdaten-Datenbank erstellt hat, ermöglicht, mindestens ein Zugriffs-Zertifikat, das eine Art des Datensatzzugriffs auf den von dem zweiten Nutzer erstellten Datensatz spezifiziert, zu erstellen und mit dem Nutzer-Zertifikat eines Nutzers, dem Zugriff auf diesen Datensatz gewährt werden soll, zu verknüpfen,

- Prüfung der Zugriffsberechtigung des ersten Nutzers auf einen von dem zweiten Nutzer angelegten Datensatz, wobei die Nutzdaten-Datenbank den Zugriff nur dann gewährt, wenn dem ersten Nutzer sowohl ein Eigner-Zertifikat für die Nutzdaten-Datenbank als auch ein Zugriffs-Zertifikat für den Zugriff auf den Datensatz zugeordnet ist. Dies kann vorteilhaft sein, da jeder Nutzer, auch auf der untersten„Rechte-Ebene", volle Kontrolle über die von ihm erstellten Daten erlangt: auch wenn ein anderer Nutzer, z.B. der Geschäftsführer oder eine dem Geschäftsführer untergeordnete, vertrauenswürdige Person (z.B. Bereichsleiter, Sicherheitsbeauftragter, etc) dem Nutzer zunächst einmal durch Ausstellung eines Eigner-Zertifikats erlauben müssen, überhaupt Daten in einer Nutzdaten-Datenbank anzulegen, so bedeutet dies nicht, dass dadurch der Geschäftsführer oder die besagte vertrauenswürdige Person damit automatisch auch Zugriff auf die von diesem Nutzer erstellte Daten haben. Damit wird der Datenschutz enorm erhöht, denn bei dem die Daten erzeugenden Nutzer kann es sich sowohl um einfache Mitarbeiter und Angestellte handeln als auch um leitende Angestellte oder Geschäftsführer handeln. Beispielsweise kann das erste Eigner-Zertifikat für eine Nutzdaten-Datenbank an einen Geschäftsführer ausgestellt werden, welcher dann wiederum weitere Eigner-Zertifikate an den Sicherheitsbeauftragten und einfache Angestellte ausstellt. Dies bedeutet aber nicht automatisch, dass dieser Geschäftsführer auf die Daten, die der Sicherheitsbeauftragte oder die Angestellten dann in dieser Nutzdaten-Datenbank erstellt, auch le- sen können. Dies ist vielmehr nur möglich, wenn ein Nutzer, der einen bestimmten Datensatz anlegt, ein oder mehreren Zugriffsrechte bezüglich der von diesem Nutzer erstellten Datensätzen explizit an den Geschäftsführer zuweist. In einem vorteilhaften Aspekt ist also ein hohes Maß an Datenschutz gewährleistet da eine Prüfung zweier unabhängiger Parameter vor Zugriffsgewährung erfolgt (sowohl bezüglich der Eignerschaft als auch bezüglich der Zugriffsberechtigung). Gerade im Hinblick auf die unabhängige Tätigkeit unternehmensinterner Kontrollgremien wie etwa des Aufsichtsrats, der Qualitätskontrolle, des Betriebsrats oder des Betriebsarztes kann es wichtig sein, dass ein Vorgesetzter die von diesen Personen bzw. Stellen generierte Daten nicht automatisch lesen darf. In einem weiteren Aspekt können Ausführungsformen der Erfindung sicherstellen, dass technische Administratoren, die z.B. die Hardware für die Nutzdaten- Datenbanken bereitstellen und administrieren, im Hinblick auf die Zugriffsrechte auf die in diesen Datenbanken gespeicherten Informationen keine besonderen Zugriffsrechte besitzen. Damit kann das Problem, dass heute das technisch-administrative Personal oftmals freien Zugang auf hoch sensible Daten der Geschäftsführung hat, vermieden werden. In einem weiteren vorteilhaften Aspekt ermöglicht die Verwendung der ersten und zweiten Schnittstelle eine unabhängige Kontrolle und Rechtevergabe bezüglich zweier technischer Funktionalitäten, nämlich a) der Funktionalität der Datensatzerzeugung in einer Datenbank und b) der Funktionalität des Zugriffs auf Datensätze innerhalb der Datenbank. Eine in hohem Maße flexible und feingranulare Zuweisung von Rechten wird somit ermöglicht, was angesichts komplexer und sich häufig ändernder Zuständigkeitsverhältnisse gerade in großen Konzernen von hohem Vorteil ist. Der initiale Eigner einer Datenbank kann frei bestimmen, welchen anderen Nutzern er Eignerschafts-Rechte zuerkennen will, ohne hierbei in technischer Hinsicht an bestimmte Unternehmenshierarchien gebunden zu sein. In analoger Weise ist jeder Nutzer, der Daten erstellt hat, frei, beliebigen anderen Nutzern Zugriffsrechte auf diese Daten über die Zuweisung entsprechender Zugriffsrechte zu gewähren, ohne hierbei in technischer Hinsicht an bestimmte Unternehmenshierarchien gebunden zu sein, und ohne dass übergeordnete Personen und/oder das technisch- administrative Personal automatisch Zugriff auf die erstellten Daten haben.

Nach Ausführungsformen umfasst die Prüfung der Zugriffsberechtigung:

- Empfang einer Zugriffsanfrage durch die Nutzdaten-Datenbank von dem ersten Nutzer;

- Aufbau einer Datenbankverbindung für den ersten Nutzer zu der Nutzdaten- Datenbank nur dann, wenn die Nutzdaten-Datenbank feststellt, dass ein valides

Eigner-Zertifikat der Nutzdaten-Datenbank mit dem ersten Nutzer verknüpft ist, wobei der Aufbau der Datenbankverbindung unabhängig davon erfolgt, welche Zugriffs-Zertifikate mit dem ersten Nutzer verknüpft sind;

- Falls die Datenbankverbindung aufgebaut wird, Gewährung des Zugriffs auf den Datensatz des zweiten Nutzers nur dann, wenn die Nutzdaten-Datenbank feststellt, dass ein Zugriffs-Zertifikat mit dem ersten Nutzer verknüpft ist, wobei der Zugriff nur im Rahmen der in dem Zugriffs-Zertifikat spezifizierten Art des Zugriffs gewährt wird.

Dies kann vorteilhaft sein, da einem Nutzer, der kein Eigner-Zertifikat hat, von vor- neherein schon der Verbindungsaufbau zu der Datenbank verwehrt wird. Somit kann auf einfache Weise global sichergestellt werden (z.B. durch Entzug des Eig- ner-Zertifikats), dass ein bestinnnnter Nutzer auf keinerlei Daten einer bestimmten Nutzdaten-Datenbank mehr zugreifen kann, ohne dass hierfür ggf. eine große Zahl an Nutzern, die diesem Nutzer ein Zugriffsrecht für die von ihnen jeweils erstellte Daten eingeräumt haben, diesem einen Nutzer die Zugriffsrechte einzeln entziehen müssten. Durch Zuweisung oder Entziehung (z.B. Invalidierung oder Verweigerung einer erneuten Ausstellung nach dem Ablauf eines aktuellen Eigner-Zertifikats (typische Validitätsdauer z.B. innerhalb einiger Tage, Wochen oder Monate)) kann also ein relativ weitreichender, global gut kontrollierbarer Zugriffsschutz für sämtliche in einer Datenbank gespeicherte Daten bereitgestellt werden. Nach Ausführungsformen umfasst das mindestens eine Zugriffs-Zertifikat ein oder mehrere der folgenden Zugriffs-Zertifikattypen:

- ein Lesezug riffs-Zertifikat, welches einem Nutzer einen lesenden Zugriff auf den Inhalt eines Datensatzes ermöglicht;

- ein Schreibzugriffs-Zertifikat, welches einem Nutzer einen modifizierenden Zugriff auf den Inhalt eines bereits existierenden Datensatzes ermöglicht;

- ein Indexzug riffs-Zertifikat, welches einem Nutzer Kenntnis der Existenz des Datensatzes in der Nutzdaten-Datenbank und einen lesenden Zugriff auf Metadaten des Datensatzes ermöglicht.

Beispielsweise ermöglicht ein Indexzugriffs-Zertifikat es einem Nutzer, eine statisti- sehe Auswertung mehrerer Datensätze zu erhalten, etwa bezüglich der Frage, auf wie viele Datensätze einer Nutzdaten-Datenbank ein bestimmter Nutzer Lesezugriff oder Schreibzugriff besitzt oder wie viele Datensätze in dem Nutzdatenfeld die Wörter„Max Mustermann" beinhalten.

Die Verwendung mehrerer unterschiedlicher Typen von Zugriffs-Zertifikaten für un- terschiedliche Zugriffsarten und die individuelle Zuweisung dieser Zertifikatstypen an einzelne Nutzer um diesen den Zugriff auf die von einem Nutzer erstellte Daten zu ermöglichen, kann vorteilhaft sein, da dadurch eine besonders feingranulare Kontrolle des Zugriffs auf die Daten ermöglicht wird.

Nach Ausführungsformen beinhaltet das erste und/oder zweite Eigner-Zertifikat ei- nen Delegierbarkeitsparameter, welcher entweder den Datenwert„DELEGIERBAR" oder den Datenwert„NICHT DELEGIERBAR" annehmen kann. Eine zur Erstellung der Eigner-Zertifikate verwendete Programmlogik, z.B. ein I D-Management Modul, ist so konfiguriert, dass

- ein Nutzer, dem ein Eigner-Zertifikat für die Nutzdaten-Datenbank zugeordnet ist und welcher ein Eigner-Zertifikat für einen anderen Nutzer für diese Nutzdaten- Datenbank erstellt, den Delegierbarkeitsparameter des erstellten Eigner- Zertifikats unabhängig vom Delegierbarkeitsparameter des ihm zugeordneten Eigner-Zertifikats auf „NICHT DELEGIERBAR" setzen kann, den Delegierbarkeitsparameter des erstellten Eigner-Zertifikats jedoch nur dann auf „DELEGIERBAR" setzen kann, wenn der Delegierbarkeitsparameter seines Eigner-Zertifikats den Wert„DELEGIERBAR" hat; und

- ein Nutzer, welchem eine Eigner-Zertifikat für eine Nutzdaten-Datenbank zugeordnet ist, dessen Delegierbarkeitsparameter den Wert„NICHT DELEGIERBAR" hat, keine weiteren Eigner-Zertifikate für andere Nutzer für diese Nutzdaten- Datenbank erstellen kann.

Nach alternativen Ausführungsformen beinhaltet ein Datenobjekt, das ein Eigner- Zertifikat einem bestimmten Nutzer zuweist oder das das Eigner-Zeritifikat einer Kette aus zwei oder mehr Nutzern, die sich das Eigner-Recht zugewiesen haben, zuweist, den Delegierbarkeitsparameter. Ein solches Objekt, im Folgenden auch als Eignerschaftermächtigungskettenobjekt bezeichnet, kann z.B. in Form einer neuen Kopie erzeugt und in der ID-Datenbank gespeichert werden sobald eine Kette aus Nutzern, die sich das Eigner-Recht für eine Nutzdaten-Datenbank zugewiesen haben, um ein Kettenglied (also z.B. ein weiteres Nutzer-Zertifikat) erweitert wird. Der Delegierbarkeitsparameter kann entweder den Datenwert„DELEGIERBAR" oder den Datenwert„NICHT DELEGIERBAR" annehmen. Eine zur Erstellung der Eigner- Zertifikate verwendete Programmlogik, z.B. ein ID-Management Modul, ist so konfiguriert, dass

- ein Nutzer, dem ein Eigner-Zertifikat für die Nutzdaten-Datenbank zugeordnet ist und welcher ein neues Eignerschaftsermächtigungskettenobjekt in der ID- Datenbank speichert, um einem anderen Nutzer für diese Nutzdaten-Datenbank das Eigner-Zertifikat zuzuweisen, den Delegierbarkeitsparameter des erstellten Eignerschaftsermächtigungskettenobjekts unabhängig vom Delegierbarkeitspa- rameter eines bestehenden Eignerschaftsermächtigungskettenobjekts, dass diesem Nutzer das Eigner-Zertifikat zuweist, auf „NICHT DELEGIERBAR" setzen kann, den Delegierbarkeitsparameter des erstellten Eignerschaftsermächtigungs- kettenobjekts jedoch nur dann auf „DELEGIERBAR" setzen kann, wenn der Delegierbarkeitsparameter des bestehenden Eignerschaftsermächtigungs- kettenobjekts (welches dem das neue Recht ausstellenden Nutzer das Eigner- Zertifikat zuweist) den Wert„DELEGIERBAR" hat; und

- ein Nutzer, welchem eine Eigner-Zertifikat für eine Nutzdaten-Datenbank mittels eines Eignerschaftsermächtigungskettenobjekts zugeordnet ist, dessen Delegierbarkeitsparameter den Wert„NICHT DELEGIERBAR" hat, keine weiteren Eigner- schaftsermächtigungskettenobjekte erstellen kann, welche dieses Eigner- Zertifikat anderen Nutzern für diese Nutzdaten-Datenbank zuweist.

Dies kann vorteilhaft sein, da ein hoher Grad an Dynamik und Flexibilität im Hinblick auf die Vergabe der Zugriffsrechte ermöglicht wird: typischerweise wird einem bestimmten Nutzer, zum Beispiel dem Geschäftsführer, ein Eigner-Zertifikat für eine bestimmte Nutzdaten-Datenbank zugeordnet. Dieses„erste/initiale" Eigner-Zertifikat hat vorzugsweise den Delegierbarkeitsparameterwert„DELEGIERBAR". Dieser Nutzer kann nun über die erste Schnittstelle dieses erste Eigner-Zertifikat in identi- scher oder modifizierter Kopie ein oder mehreren weiteren Nutzern zuordnen, sodass diese weiteren Nutzer im Hinblick auf die Nutzdaten-Datenbank ebenfalls Eigner-Rechte bekommen und Datensätze anlegen können. Dabei kann der Inhaber des ersten Eigner-Zertifikats entscheiden, ob die den weiteren Nutzern zugeordneten Eigner-Zertifikate für diese Nutzdaten-Datenbank ebenfalls delegierbar sein sol- len, diese anderen Nutzer also ebenfalls die Möglichkeit haben sollen, weiteren Nutzern Eigner-Rechte bezüglich dieser Nutzdaten-Datenbank auszustellen. Falls eine modifizierte Kopie des Eigner-Zertifikats für die ein oder mehreren weiteren Nutzer erstellt wird, welches den Delegierbarkeitsparameterwert„NICHT

DELEGIERBAR" besitzt, können die weiteren Nutzer zwar eine Datenbankverbin- dung zu der Nutzdaten-Datenbank erstellen und dort Datensätze erzeugen, jedoch keine weiteren Eigner-Zertifikate für weitere Nutzer bezüglich dieser Nutzdaten- Datenbank ausstellen. Die Kette der ausgestellten Eigner-Zertifikate endet also notwendigerweise mit der Ausstellung von nicht weiter delegierbaren Eigner- Zertifikaten, wobei es natürlich möglich ist, das einen bestimmten Nutzer von einem Datenbank-Eigner ein delegierbares Eigner-Zertifikat ausgestellt wird und von einem anderen Datenbank-Eigner ein nicht-delegierbares Eigner-Zertifikat. In diesem Fall kann der Nutzer weitere Eigner-Zertifikate für Dritte ausstellen, jedoch wird vorzugsweise die chronologische Kette der ein Eigner-Zertifikat ausstellen Nutzer gespeichert, zum Beispiel in Form von Ermächtigungsobjekten und/oder Logeinträgen, sodass der Pfad der Verantwortungskette dokumentiert ist. Vorzugsweise erfolgt die Speicherung dieser chronologischen Kette in einer speziellen Datenbank, im fol- genden„ID- Datenbank" genannt. In analoger Weise kann der Delegierbarkeitspa- rameter innerhalb eines Zuweisungsobjekts, also z.B. eines Eignerschaftsermächti- gungskettenobjekts, gespeichert sein und vorgeben, ob ein Nutzer weitere Zuweisungsobjekte (weitere Eignerschaftsermächtigungskettenobjekte) erstellen darf um ein Eigner-Zertifikat anderen Nutzern zuzuweisen). In einem weiteren vorteilhaften Aspekt wird jedem Datenbank-Eigner damit die Möglichkeit gegeben, frei zu entscheiden, ob er Verantwortung (und Arbeit!) bezüglich der Zugriffsrechtsverwaltung einer Datenbank an eine bestimmte Person so weitreichend delegieren möchte, dass diese ihrerseits wiederum diese Tätigkeit delegieren kann, oder ob nur ein einfaches Eigner-Recht zum Erstellen von eigenen Datensätzen in der Nutzdaten-Datenbank erteilt werden soll.

Nach Ausführungsformen erfolgt die Verknüpfung des zumindest einen Zugriffs- Zertifikat mit dem erzeugten Datensatz so, dass das zumindest eine Zugriffs- Zertifikat desjenigen Nutzers, welcher den Datensatz erstellt hat, als Bestandteil des Datensatzes in einem eigenen Feld der Nutzdaten-Datenbank gespeichert wird. Dies kann vorteilhaft sein, da das Zugriffs-Zertifikat getrennt von den übrigen Nutzdaten indiziert werden kann, sodass über den Index eine schnelle Suche nach Datensätzen, die ein bestimmter Nutzer erstellt hat, möglich ist.

Vorzugsweise handelt es sich bei den in den entsprechenden Feldern des Datensatz gespeicherten Zugriffs-Zertifikaten um reine Zahlenwerte, nicht um komplexe x509 Zertifikate. Metadaten bezüglich der Gültigkeit und andere Aspekte können getrennt von dem eigentlichen Zugriffs-Zertifikat in der ID-Datenbank gespeichert sein. Vorzugsweise enthält jeder von einem bestimmten Nutzer in einer Nutzdaten- Datenbank erstellte Datensatz in seinen entsprechenden Feldern sämtliche Zugriffs- Zertifikate des diesen Datensatz erstellenden Nutzers. Wird beispielsweise ein Datensatz DS von Nutzer U 1 erstellt und der Nutzer-111 hat gemäß dem Inhalt der ID- Datenbank genau 3 Typen von Zertifikaten (ein Lesezugriffs-Zertifikat„U1 .Z-

Zert[R]", ein Schreibzugriffs-Zertifikat„U1 .Z-Zert[W]" und ein Indexzug riffs-Zertifikat „U1 .Z-Zert[S]"), so werden Kopien genau dieser 3 Zugriffs-Zertifikate im Zuge der Speicherung des Datensatzes DS aus der ID-Datenbank erstellt und die in die entsprechenden Felder des Datensatzes DS gespeichert. Wenn nun der Nutzer-111 einem anderen Nutzer U2 Leserechte bezüglich des Datensatzes DS einräumt, bedeutet das, dass in der ID-Datenbank eine Zuordnung dieses Lesezugriffs-Zertifikat „U1 .Z-Zert[R]" des Nutzers U1 und des Nutzer-Zertifikats des Nutzers U2 gespeichert wird. Falls der Nutzer U2 nun zu einem späteren Zeitpunkt auf den Datensatz DS zugreifen will, sendet die Nutzdaten-Datenbank, die den Datensatz DS beinhal- tet, in Antwort auf die Zugriffsanfrage des Nutzers U2 automatisch eine Berechtigungsanfrage an die ID-Datenbank zusammen mit den in dem Datensatz DS gespeicherten Zugriffsrechten des Erstellers U1 . Die ID-Datenbank prüft daraufhin, ob ein dem Nutzer U2 zugeordnetes Nutzer-Zertifikat in der ID-Datenbank mit ein oder mehreren der in dem Datensatz DS gespeicherten Zugriffsrechte des Erstellers U1 verknüpft gespeichert ist. Nur falls dies der Fall ist, und falls der Nutzer U2 außerdem Eigner der Nutzdaten-Datenbank ist, darf er auf den Datensatz zugreifen.

Nach Ausführungsformen umfasst das zumindest eine Zugriffs-Zertifikat, dass vorzugsweise als Bestandteil des erstellten Datensatzes gespeichert ist, mehrere Zugriffs-Zertifikate für jeweils andere Zugriffsarten. Die mehreren Zugriffs-Zertifikate umfassen zum Beispiel ein Schreibzugriffs-Zertifikat Z.Zert_U2[W] des erstellenden Nutzers, und/oder ein Lesezugriffs-Zertifikat Z.Zert_U2[R] des erstellenden Nutzers und/oder ein Indexzugriffs-Zertifikat Z.Zert_U2[S].

Das Zugriffs-Verwaltungssystem erzeugt automatisch für jede der Zugriffsarten eine Indexstruktur aus den Zugriffs-Zertifikaten sämtlicher Datensätze, die diese Zu- griffsart spezifiziert. So kann zum Beispiel ein erster Index für die Schreibzugriffs- Zertifikate, ein zweiter Index für die Lesezug riffs-Zertifikate und ein dritter Index für die Index Zugriffs-Zertifikate sowie ein weiterer Index für die Nutzdaten selbst er- stellt werden. In Antwort auf eine Datenbankfrage eines Nutzers, die auf einen oder mehrere der für die Nutzdaten-Datenbank erstellten Indices der Zugriffs-Zertifikate zugreift, prüft das Zugriffs-Verwaltungssystem, ob dem Nutzer ein Indexzug riffs- Zertifikat (Z.Zert_U2[S]), welches einem Nutzer Kenntnis der Existenz des Daten- satzes in der Nutzdaten-Datenbank und einen lesenden Zugriff auf Metadaten des Datensatzes ermöglicht, zugewiesen ist. Diese Prüfung kann insbesondere durch die Nutzdaten-Datenbank in Interoperation mit der ID-Datenbank und gegebenenfalls weiteren Modulen, zum Beispiel dem ID-Management-Modul, erfolgen. Die Nutzdaten-Datenbank ermöglicht dem anfragenden Nutzer die Verwendung der ein oder mehreren Indices zur Ausführung der Datenbankabfrage nur dann, wenn dem anfragenden Nutzer das Indexzugriffs-Zertifikat zugewiesen ist.

Dies kann vorteilhaft sein, da über den Index eine schnelle Abfrage einer Zugriffsberechtigungsstatistik über die Datensätze einer Datenbank im Hinblick auf mehrere verschiedene Nutzer durchgeführt werden kann. Aus dieser geht dann zum Beispiel hervor, welche der bei dem Zugriffs-Verwaltungssystem registrierten Nutzer im Hinblick auf weiche Datensätze zum Lesen, Schreiben und oder Indexzugriff berechtigt ist. Allerdings wird über eine Anfrage, die durch das Indexzugriffs-Zertifikat ermöglicht wird, nur eine statistische Auskunft über mehrere Datensätze gegeben, ein lesender oder schreibenden Zugriff auf die Nutzdaten der Datensätze ist in den Rech- ten, die einen Indexzugriffs-Zertifikat gewährt, nicht umfasst.

Nach Ausführungsformen wird das Verfahren von einem Zugriffs- Verwaltungssystem, welches eine oder mehrere Nutzdaten-Datenbanken sowie eine ID-Datenbank beinhaltet ausgeführt, wobei die Ausstellung weiterer Zugriffs- Zertifikate und/oder Eigner-Zertifikate für bestimmte Nutzer vorzugsweise in In- teroperation mit menschlichen Nutzern erfolgt. Beispielsweise kann das Zugriffs- Verwaltungssystem eine grafische Benutzeroberfläche (GUI) bereitstellen, welche es den Nutzern einer Organisation ermöglicht, weitere Eigner-Zertifikate für andere, manuell ausgewählte Nutzer für eine bestimmte Nutzdaten-Datenbank zu erstellen, sofern dem ausstellenden Nutzer selbst ein entsprechendes Eigner-Zertifikat in der ID-Datenbank zugewiesen ist. Zusätzlich kann es diese Benutzeroberfläche dem Nutzer, der einen bestimmten Datensatz erstellt hat, ermöglichen, ein oder mehreren anderen manuell über die GUI ausgewählten Nutzern, ein oder mehrere ausge- wählte Zugnffsrechte auf diesen Datensatz einzuräumen. Beispielsweise kann die GUI mehrere Personen, die der Organisation angehören, in Form einer auswählbaren Personenliste grafisch repräsentieren, sodass ein Nutzer der GUI durch Auswahl von ein oder mehreren Personen aus dieser Personenliste die Empfänger der einzuräumenden Eigner-und Zugriffsrechte spezifizieren kann. Weitere auswählbare GUI Elemente, zum Beispiel Radio-Buttons oder Check-Boxes können es dem Nutzer der GUI ermöglichen, durch Auswahl dieses Elementes den Delegierbarkeitspa- rameter des ausgestellten Zugriffs-bzw. Eigner-Zertifikats zu bestimmen (delegierbar oder nicht-delegierbar), sofern die Berechtigung des Nutzers hierfür ausrei- chend ist. Die GUI kann ferner über auswählbare GUI Elemente verfügen, die es einem Nutzer ermöglichen, Zugriffsrechte, die er anderen Nutzern eingeräumt hat, auch wieder zu entziehen. Die GUI ist so konfiguriert, dass sie automatisch im Hintergrund neue Zertifikate und/oder Zuweisungen von Zertifikaten zu nutzen gemäß den Eingaben des Nutzers über die GUI erstellt oder invalidiert und den Inhalt der ID-Datenbank entsprechend aktualisiert.

Nach Ausführungsformen handelt es sich bei den ein oder mehreren Nutzdaten- Datenbanken und der ID-Datenbank jeweils um eine NoSQL-Datenbank. Vorzugsweise handelt es sich bei den NoSQL-Datenbanken jeweils um eine sogenannte „strukturlose" Datenbank, die eine freie Definition der Art und Anzahl der Datenfel- der unterstützt. Vorzugsweise ist die NoSQL-Datenbank so konfiguriert, dass der Inhalt sämtlicher Datenfelder eines jeden neuen Datensatzes automatisch indexiert wird und dass Änderungen des Inhalts der Datenbank in Form neuer Versionen gespeichert werden („versionierte Datenbank"). Vorzugsweise wird die Erzeugung neuer Zugriffs-und/oder Eigner-Zertifikate sowie die chronologische Sequenz der Nutzer, die anderen Nutzern jeweils diese Zertifikate zugewiesen haben, in einer Log (z.B. Log-Datei) der ID-Datenbank gespeichert.

Nach Ausführungsformen handelt es sich bei dem Zugriffs-Verwaltungssystem um ein Datenbanksystem. Es ist jedoch auch möglich, dass andere Systeme die zur Speicherung von Daten ausgelegt sind, verwendet werden, z.B. Microcontroller, in deren Speicher die Zertifikate und Ermächtigungskettenobjekte sowie die hier beschriebene Programmlogik implementiert sein kann. Nach Ausführungsformen handelt es sich bei dem Zugriffs-Verwaltungssystem, das die ein oder mehrere Nutzdaten-Datenbanken und die ID-Datenbank umfasst, um ein NoSQL Datenbanksystem.

Nach Ausführungsformen ist dem ersten Nutzer ein erstes Nutzer-Zertifikat zuge- ordnet. Das erste Nutzer-Zertifikat kann zum Beispiel ein Root-Zertifikat, das von einer Zertifizierungsstelle (certifying authority - CA) herausgegeben wird, sein. Das erste Nutzer-Zertifikat ist in eine von einer Zertifizierungsstelle (140) herausgegebene erste Zertifikatskette prüfbar eingeordnet (ist also beispielsweise bis zum Root- Zertifikat der Zertifizierungsstelle prüfbar). Dies kann vorteilhaft sein, da Zertifizie- rungsstellen als unabhängige Vertrauensgaranten auf breiter Basis bereits akzeptiert sind und bereits von vielen bestehenden technischen Systemen zur Prüfung der Authentizität bestimmter Nutzer und Nutzeraktionen verwendet werden.

Nach Ausführungsformen wird das zweite Eigner-Zertifikat so erstellt, dass dieses in die erste Zertifikatskette eingeordnet ist und durch das erste Nutzer-Zertifikat prüfbar ist. Beispielsweise wird das zweite Eigner-Zertifikat von dem Zugriffs- Verwaltungssystem durch den privaten Schlüssel des ersten Nutzer-Zertifikats signiert. In analoger Weise kann der erste Nutzer auch Kopien von Zugriffs-Zertifikates, die anderen Nutzern Zugriff auf die von dem ersten Nutzer erstellte Datensätze ein- räumen, mit dem privaten Schlüssel seines Nutzer-Zertifikats (hier also des ersten Nutzer-Zertifikats) signieren.

Nach Ausführungsformen ist dem zweiten Nutzer ein zweites Nutzer-Zertifikat zugeordnet, wobei das zweite Nutzer-Zertifikat in eine von einer Zertifizierungsstelle herausgegebene zweite Zertifikatskette prüfbar eingeordnet ist. Nach Ausführungsformen umfasst das Verfahren eine Erstellung eines dritten Eigner-Zertifikats durch den zweiten Nutzer über die erste Schnittstelle und Verknüpfung des dritten Eigner-Zertifikats mit einem dritten Nutzer, um diesem zu ermöglichen, Datensätze in der Nutzdaten-Datenbank anzulegen.

Nach Ausführungsformen beinhaltet das zumindest eine Zugriffs-Zertifikat einen Delegierbarkeitsparameter, welcher entweder den Datenwert„DELEGIERBAR" oder den Datenwert„NICHT DELEGIERBAR" annehmen kann. Eine zur Erstellung jedes der Zugriffs-Zertifikate verwendete Programmlogik ist so konfiguriert ist, dass

Ein Nutzer, dem ein Zugriffs-Zertifikat für einen Datensatz (106-1 16) in der Nutzdaten-Datenbank (102) zugeordnet ist und welcher ein Zugriffs-Zertifikat für einen an- deren Nutzer für diesen Datensatz erstellt, den Delegierbarkeitsparameter des erstellten Zugriffs-Zertifikats unabhängig vom Delegierbarkeitsparameter seines Zugriffs-Zertifikats auf„NICHT DELEGIERBAR" setzen kann, den Delegierbarkeitsparameter des erstellten Zugriffs-Zertifikats jedoch nur dann auf„DELEGIERBAR" setzen kann, wenn der Delegierbarkeitsparameter des diesem Nutzer zugewiesenen Zugriffs-Zertifikats den Wert„DELEGIERBAR" hat; und

Ein Nutzer, welchem ein Zugriffs-Zertifikat für einen Datensatz zugeordnet ist, dessen Delegierbarkeitsparameter den Wert„NICHT DELEGIERBAR" hat, keine weiteren Zugriffs-Zertifikate für andere Nutzer für diesen Datensatz erstellen kann.

Alternativ dazu kann der Delegierbarkeitsparameter auch als Bestandteil eines Da- tenobjekts gespeichert sein, welches ein bestimmtes Zugriffs-Zertifikat einem Nutzer oder einer Kette von Nutzern, die sich dieses Zugriffs-Zertifikat zugewiesen haben, zuweist. Im Folgenden wird ein solches Datenobjekt auch als Zugriffsermächti- gungskettenobjekt bezeichnet. Wie bereits oben für das Eignerschaftsermächti- gungskettenobjekt darstestellt kann der Nutzer in Abhängigkeit vom Wert des Dele- gierbarkeitsparameters des Zugriffsermächtigungskettenobjekts, welches diesem Nutzer ein bestimmtes Nutzer-Zertifikat zuweist, eine Kopie dieses Zugriffsermäch- tigungskettenobjekts erstellen, die ein zusätzliches Nutzer-Zertifikat des Nutzers enthält, welchem das Zugriffsrecht zugewiesen werden soll, oder nicht.

Auch die Zugriffs-Zertifikate oder die Zugriffsermächtigungskettenobjekte können also, wie bereits für die Eigner-Zertifikate beschrieben, als delegierbare oder als nicht-delegierbare Zugriffs-Zertifikate erstellt und anderen Nutzern zugewiesen werden bzw. die Zuweisung selbst, also die Zugriffsermächtigungskettenobjekte, kann delegierbar oder nicht-delegierbar sein. So kann jeder Ersteller eines Datensatzes und jeder Inhaber eines delegierbaren Zugriffs-Zertifikats eines anderen Nutzers, der einen Datensatz erstellt hat, flexibel selbst entscheiden, ob und inwieweit er die Zugriffs-Verantwortung und damit zusammenhängende Pflichten und Tätigkeiten an andere Nutzer überträgt. Dies kann vorteilhaft sein, da ein hoher Grad an Flexibilität und Komplexität der Zugangsgewährung ermöglicht wird.

Nach Ausführungsformen sind in einer ID-Datenbank eine Vielzahl von Nutzer- Zertifikaten, eine Vielzahl von Zugriffs-Zertifikaten und eine Vielzahl von Eigner- Zertifikaten gespeichert. Das Verfahren umfasst die Speicherung von Eigner- schaftsermächtigungskettenobjekten und/oder Zugriffsermächtigungskettenobjekten in der ID-Datenbank.

Jedes Eignerschaftsermächtigungskettenobjekt ist ein Datenobjekt, welches eines der Eigner-Zertifikate und ein oder mehrere der Nutzer-Zertifikate beinhaltet (und dadurch einander zuweist). Die Reihung der Nutzer-Zertifikate in dem Eigner- schaftsermächtigungskettenobjekt gibt die Sequenz der Nutzer, die dieses Eigner- schafts-Zertifikat für jeweils andere Nutzer, deren Nutzer-Zertifikat in dem Eigner- schaftsermächtigungskettenobjekt enthalten ist, erstellt haben, wieder.

Jedes Zugriffsermächtigungskettenobjekt ist ein Datenobjekt, welches eines der Zugriffs-Zertifikate und ein oder mehrere der Nutzer-Zertifikate beinhaltet (und dadurch einander zuweist). Die Reihung der Nutzer-Zertifikate in dem Zugriffser- mächtigungskettenobjekt gibt die Sequenz der Nutzer, die dieses Zugriffs-Zertifikat für jeweils andere Nutzer, deren Nutzer-Zertifikat in dem Zugriffsermächtigungsket- tenobjekt enthalten ist, ausgestellt haben, wieder. Dies kann vorteilhaft sein, da im Falle eines von einem bestimmten Nutzer verursachten Fehlers (zum Beispiel der Löschung eines für mehrere Nutzer wichtigen Datensatzes) anhand der Zugriffsermächtigungskettenobjekte und/oder Eigner- schaftsermächtigungskettenobjekte sofort ersichtlich ist, wer diesem Nutzer die entsprechenden Rechte eingeräumt hat und damit eventuell mitverantwortlich für des- sen Fehler ist. Vorzugsweise werden die besagten Ermächtigungskettenobjekte o- der zumindest deren Inhalt regelmäßig oder zumindest bei jeder Änderung oder Aktualisierung in eine Logdatei des Zugriffsverwaltungs-Systems geschrieben, sodass die Kette der Verantwortlichkeit auch für jeden denkbaren Zeitpunkt in der Vergangenheit dokumentiert ist und rekonstruiert werden kann. Nach Ausführungsformen sind die Nutzdaten-Datenbanken frei von Zugriffsermäch- tigungskettenobjekten und beinhalten für jeden Datensatz nur die Zugriffs- Zertifikate, die dem Nutzer, welcher diesen Datensetz erstellt hat, Zugriff auf diesen Datensatz gewähren. Die Verknüpfung dieser Zugriffs-Rechte des Datensatzerstellers mit ein oder mehreren anderen Nutzern um diesen Zugriff auf den Datensatz zu gewähren ist nicht in der Nutzdaten-Datenbank gespeichert, sondern in der ID-Datenbank. Umgekehrt enthält die ID-Datenbank keine Referenz auf einzelne Datensätze der Nutzdaten- Datenbänke. Dies kann vorteilhaft sein, da die Größe und Komplexität der einzelnen Datensätze der Nutzdaten-Datenbank begrenzt und logisch von der Verwaltung der Zugriffsrechte weitgehend entkoppelt wird. Die Größe der Datensätze wird also auch dadurch begrenzt, dass nicht die komplette Kette der Berechtigungsübertragungen als Bestandteil der Datensätze gespeichert werden. Insbesondere bei einer Vielzahl kleiner Datensätze mit identischer Berechtigungsstruktur kann dies den von der Datenbank benötigten Speicherplatz erheblich reduzieren.

Nach Ausführungsformen umfasst das Verfahren ferner:

- Empfang einer Zugriffsanfrage des ersten Nutzers durch die Nutzdaten- Datenbank, wobei in der Zugriffsanfrage der erste Nutzer Zugriff auf einen Datensatz, den der zweite Nutzer angelegt hat, anfrägt; - Ermitteln der Zugriffs-Zertifikate des zweiten Nutzers, der in der Nutzdaten- Datenbank als Bestandteil des einen Datensatzes gespeichert ist, durch die Nutzdaten-Datenbank;

- Senden des ersten Nutzer-Zertifikats, das dem anfragenden Nutzer zugeordnet ist, und der ermittelten Zugriffs-Zertifikate, von der Nutzdaten-Datenbank an die ID-Datenbank;

- In Antwort auf den Empfang des ersten Nutzer-Zertifikats und der ermittelten Zugriffs-Zertifikate, Generierung eines Berechtigungsnachweises durch die ID- Datenbank, wobei der Berechtigungsnachweis angibt, ob der erste Nutzer einem Eigner-Zertifikat der Nutzdaten-Datenbank durch zumindest eines der Eigner- schaftsermächtigungskettenobjekte zugewiesen ist und ob der erste Nutzer dem einen Datensatz durch zumindest eines der Zugriffsermächtigungskettenobjekte zugewiesen ist;

- Übermittlung des Berechtigungsnachweises von der ID-Datenbank an die Nutzdaten-Datenbank; - Prüfung, durch die Nutzdaten-Datenbank, anhand des Berechtigungsnachweises, ob dem ersten Nutzer ein Eigner-Zertifikat für die Nutzdaten-Datenbank zugewiesen ist und ob und welche Zugriffs-Zertifikate dem ersten Nutzer in Bezug auf den einen Datensatz zugewiesen sind;

- wobei die Nutzdaten-Datenbank dazu konfiguriert ist, dem ersten Nutzer einen Aufbau einer Datenbankverbindung nur dann zu gewähren, wenn diesem ein

Eigner-Zertifikat für die Nutzdaten-Datenbank zugewiesen ist und dem ersten Nutzer Zugriff auf den einen Datensatz nur in dem Umfang zu gewähren, welche dem ersten Nutzer durch die diesem zugewiesenen Zugriffs-Zertifikate einräumen. Nach Ausführungsformen beinhaltet die ID-Datenbank einen privaten Signierschlüssel. Die Nutzdaten-Datenbank beinhaltet einen öffentlichen Signaturprüfschlüssel, welcher zur Prüfung der mit dem Signierschlüssel erstellten Signaturen ausgebildet ist. Das Verfahren umfasst die Signierung des Berechtigungsnachweises (oder mehrerer für einen Nutzer ausgestellten Berechtigungsnachweise) durch die ID- Datenbank mit dem Signierschlüssel, wobei der Berechtigungsnachweis in signierter Form an die Nutzdaten-Datenbank übermittelt wird. Die Nutzdaten-Datenbank prüft mittels des Signaturprüfschlüssels, ob die Signatur des Berechtigungsnachweises valide ist, wobei der Aufbau der Datenbankverbindung und der Datensatzzugriff nur dann gestattet wird, wenn die Signatur valide ist. Dies kann vorteilhaft sein, da es nicht erforderlich ist, einzelne Nutzdaten- Datenbanken mit Programlogik zur Zertifikatskettenprüfung auszustatten. Ganz allgemein kann durch das beschriebene Verfahren bzw. die beschriebene Datenbankstruktur eine weitgehende Trennung der Datenhaltung (in der Nutzdaten- Datenbanken) und der Verwaltung von Zugriffsrechten (in der ID-Datenbank) erzielt werden. Die ID-Datenbank enthält und/oder ist operativ gekoppelt an ein oder mehrere Programmmodule zum Beispiel zur Zertifikatskettenprüfung (zum Beispiel von Nutzer-Zertifikaten bis hin zum Root-Zertifikat der das Nutzer-Zertifikat ausstellenden Zertifizierungsstelle), zur Speicherung von Änderungen der Zuweisungen von Zertifikaten und Nutzern in einer Log-Datei und in Ermächtigungskettenobjekten sowie zur dynamischen Erstellung von signierten Berechtigungsnachweisen unter Berücksichtigung der in den Ermächtigungskettenobjekten dokumentierten Chronologie der Übertragung von Rechten. Die einzelnen Nutzdaten-Datenbanken müssen dahingegen nur über Mittel zur Prüfung, ob für die Nutzdaten-Datenbank selbst bzw. für die darin enthaltenen Datensätze entsprechende Berechtigungen vorliegen verfügen (oder an diese operativ gekoppelt sein), wobei diese Mittel gegebenenfalls Mittel zur Signaturprüfung umfassen.

Nach Ausführungsformen führt die ID-Datenbank im Zuge der Erzeugung des Berechtigungsnachweises, der eines der Eigner-Zertifikate beinhaltet, eine Zertifikatskettenprüfung durch. Dies geschieht, um festzustellen, ob dieses Eigner-Zertifikat prüfbar in die Zertifikatskette des Nutzer-Zertifikats, dem dieses Eigner-Zertifikat in einem der Eignerschaftsermächtigungskettenobjekte zugewiesen ist, eingebunden ist. Die ID-Datenbank signiert den Berechtigungsnachweises nur im Falle der Feststellung einer erfolgreichen Einbindung in die Zertifikatskette des Eigner-Zertifikat. Diese Zertifikatskettenprüfung kann also insbesondere entlang der Zertifikatskette der Zertifizierungsstelle, die das Nutzer-Zertifikat als Root-Zertifikat herausgegeben hat, erfolgen.

Zusätzlich oder alternativ dazu führt die ID-Datenbank im Zuge der Erzeugung eines Berechtigungsnachweises, der ein oder mehrere Zugriffs-Zertifikate eines Nutzers zum Zugriff auf von ihm erstellte Datensätze beinhaltet, eine Zertifikatskettenprüfung durch, um für jedes der Zugriffs-Zertifikate des Nutzers festzustellen, ob dieses Zugriffs-Zertifikat prüfbar in die Zertifikatskette des Nutzer-Zertifikats, dem dieses Zugriffs-Zertifikat in einem der Zugriffsermächtigungskettenobjekten zugewiesen ist, eingebunden ist. Die ID-Datenbank signiert den Berechtigungsnachweis nur im Falle der Feststellung einer erfolgreichen Einbindung.

Nach Ausführungsformen verwendet der zweite Nutzer, der einen bestimmten Da- tensatz erstellt hat, oder ein dritter Nutzer, dem über ein Zugriffsermächtigungsket- tenobjekt ein oder mehrere Zugriffszertifikate des zweiten Datenbank-Nutzers zu- gewiesen sind, die zweite Schnittstelle, um ein weiteres Zugriffsberechtigungskettenobjekt anzulegen. In diesem weiteren Zugriffsberechtigungskettenobjekt werden ein oder mehrere Zugriffs-Zertifikate des Erstellers (also des zweiten Nutzers) dem vierten Nutzer zugewiesen. Die Nutzdaten-Datenbank ist dazu konfiguriert, vor der Gewährung des Zugriffs auf den von dem zweiten Nutzer erzeugten Datensatz durch den vierten Nutzer zu prüfen, ob dem vierte Nutzer ein oder mehrere dieser Zugriffs-Zertifikate zugewiesen sind.

Nach einer Ausführungsform ist jedem der Datensätze in der Nutzdaten-Datenbank ein oder mehrere Zugriffs-Zertifikate des den Datensatz erstellenden Nutzers zugeordnet.

Den Eigner-Zertifikaten in der ID-Datenbank jeweils ein oder mehrere Nutzer- Zertifikate so zugeordnet sind, dass die chronologische Sequenz von Nutzern, die sich Eignerrechte der Nutzdaten-Datenbank eingeräumt haben, jeweils in Form ei- ner ersten Hierarchie repräsentiert ist. Diese Zuordnung kann z.B. mittels Eigner- schaftsermächtigungskettenobjekten erfolgen.

Den Zugriffs-Zertifikaten in der ID-Datenbank sind jeweils ein oder mehrere Nutzer- Zertifikate so zugeordnet, dass die chronologische Sequenz von Nutzern, die sich ein oder mehrere der Zugriffsrechte des den Datensatz erstellenden Nutzers einge- räumt haben, jeweils in Form einer zweiten Hierarchie repräsentieren ist. Diese Zuordnung kann z.B. mittels Zugriffsermächtigungskettenobjekten erfolgen.

Die ersten Hierarchien werden unabhängig von den zweiten Hierarchien dynamisch erzeugt, z.B. dadurch dass Nutzer mit Eigner-Berechtigung im Hinblick auf eine bestimmte Nutzdaten-Datenbank einem anderen Nutzer diese Berechtigung mittels einer GUI des Zugriffs-Verwaltungssystems übertragen und dieser andere Nutzer diesen Schritt wiederholt, um einem weiteren Nutzer Eigner-Rechte einzuräumen, sodass eine erste Hierarchie von erteilten Eigner-Rechten für diese bestimmte Datenbank entsteht. Werden mehrere Nutzdaten-Datenbanken verwaltet, kann für jede der Nutzdaten-Datenbanken eine eigene erste Hierarchie entstehen. Die zweiten Hierarchien können z.B. dadurch gebildet werden, dass ein Nutzer U2 einen Datensatz anlegt, wobei in dem angelegten Datensatz drei Zugriffs-Zertifikate des Nutzers U2 (Lese-, Schreib-, und Index-Zugriff) enthalten sind. Der zweite Nutzer überträgt nun z.B. selektiv das Schreib-Zugriffsrecht an einen Nutzer U3, indem das Schrei bzugriffs-Zertifikat von U2 mit dem Nutzer-Zertifikat von U3 in der ID- Datenbank verknüpft gespeichert wird (Zugriffsermächtigungskettenobjekt). Der dritte Nutzer U3 überträgt nun z.B. selektiv das Schreib-Zugriffsrecht an einen vierten Nutzer U4, indem das Schrei bzugriffs-Zertifikat von U2 mit dem Nutzer-Zertifikat von U4 in der ID-Datenbank verknüpft gespeichert wird. Im Hinblick auf das Schreibzu- griffs-Zertifikat von Nutzer U2 ist eine zweite Hierarchie gemäß U2- U3 -> U4 entstanden. In analoger Weise können weitere zweite Hierarchien für andere Zugriffsrechte (z.B. Lese- und Indexzugriffsrechte des gleichen Nutzers U2 oder anderer Nutzer) entstehen, die auf individuellen Vertrauensverhältnissen zwischen Nutzern beruhen, nicht auf einer starren, vorgegebenen Hierarchie einer Organisation. Vorzugsweise prüft die ID-Datenbank bei der Übertragung von Zugriffsrechten nicht, ob der Empfänger auch über Eigner-Rechte für die entsprechende Datenbank verfügt, sodass auch die Entstehung der zweiten Hierarchien unabhängig von der Entstehung der ersten Hierarchien erfolgt. Dies kann z.B. dann sinnvoll sein, wenn ein Nutzer einem anderen Zugriff auf seine Daten zu einem Zeitpunkt verschaffen möchte, an dem er weiß, dass dem Empfänger der Zugriffsrechte in absehbarer Zukunft auch Eigner-Rechte für die Nutzdaten-Datenbank, die den fraglichen Datensatz enthält, eingeräumt werden.

Nach Ausführungsformen sind in der Nutzdaten-Datenbank die Datensätze in einem Format gespeichert, welches eine Extraktion der in den Datensätzen enthaltenen Information ohne einen Zugriff über eine Datenbankverbindung zu der Nutzdaten- Datenbank ausschließt. Beispielsweise können die Datensätze als binäre Objekte oder in verschlüsselter Form gespeichert sein. Backups der Nutzdaten-Datenbank führt der Administrator-Nutzer (also die digitale Repräsentanz einer technischadministrativ tätigen Person ohne gesonderte Zugriffsrechte auf die Datensätze) oder das Zugriffs-Verwaltungssystem durch Kopieren der Nutzdaten-Datenbank auf ein anderes Speichermedium aus, wobei der Administrator-Nutzer kein Eigner- Zertifikat für diese Nutzdaten-Datenbank besitzt. Dies kann vorteilhaft sein, da der Administrator-Nutzer zwar noch die ihm typischerweise zugeordneten Tätigkeiten wie zum Beispiel das Erstellen von Backups durchführen kann, jedoch nicht mehr auf den Inhalt der in der Datenbank gespeicherten Nutzerdaten zugreifen kann. Dies schützt die Organisation durch miss- bräuchliche Weitergabe sensibler Daten an Dritte durch den Administrator-Nutzer. Der Administrator-Nutzer des Zugriffs-Verwaltungssystems hat nach Ausführungsformen der Erfindung also deutlich weniger Zugriffsrechte als dies in herkömmlichen IT-Systemen der Fall ist.

Nach Ausführungsformen schreibt das Zugriffs-Verwaltungssystem die chronologi- sehe Sequenz der Erzeugung aller Eigner-Zertifikate und Zugriffs-Zertifikate durch eine Kette einander vertrauender Nutzer sowie die chronologische Sequenz der Zuweisung von Zugriffs-Zertifikaten und Eignerschafts-Zertifikaten zu Nutzer- Zertifikaten entlang einer weiteren Kette sich vertrauender Nutzer in ein Datenbanklog. Beispielsweise kann das Zugriffs-Verwaltungssystem einen neuen Log-Eintrag erzeugen, wann immer ein Nutzer einen neuen Datensatz erzeugt, wann immer ein Nutzer einem anderen Nutzer ein Zugriffs-Zertifikat neu zuweist (oder in dieses entzieht) und wann immer ein Nutzer einem anderen Nutzer ein Eigner-Zertifikat neu zuweist (oder ihm dieses entzieht). Vorzugsweise wird jeder Log-Eintrag mit einem Zeitstempel versehen, sodass die aktuellen Eigner-und Zugriffsrechte sämtlicher Nutzer, die sich bei dem Zugriffs-Verwaltungssystem registriert haben, zu einem beliebigen Zeitpunkt in der Vergangenheit bekannt ist.

Dies kann vorteilhaft sein, da anhand der Log-Datei auch für jeden Zeitpunkt der Vergangenheit überprüft werden kann, wer welche Rechte besaß und von wem. Im Falle eines missbräuchlichen Zugriffs auf eine Datenbank und/oder einen Datensatz kann somit nicht nur der jeweilige Nutzer, der den missbräuchlichen Zugriff durchgeführt hat, sondern auch die Kette aller Nutzer, die diesem Nutzer die entsprechenden Rechte eingeräumt haben, rekonstruiert werden.

Nach Ausführungsformen repräsentiert jeder oder zumindest einige der Datensätze in der Nutzdaten-Datenbank jeweils ein Funktionsobjekt. Nur ein Nutzer, dem sowohl ein Eigner-Zertifikat der Nutzdaten-Datenbank als auch ein Zugriffs-Zertifikat für den Zugriff auf das Funktionsobjekt zugewiesen ist, wird von dem Zugriffs- Verwaltungssystem gestattet, die Funktion durchzuführen bzw. die Ausführung der Funktion zu veranlassen. Bei der Funktion kann es sich beispielsweise um das Starten eines Geräts, die Aktivierung oder Bewegung einer Hardwarekomponente, das Öffnen oder Schließen einer Tür für Gebäude, Räume oder Fahrzeuge, das Öffnen oder Schließen sonstiger Zutrittsbarrieren oder Verschlussvorrichtungen von Behältnissen oder um eine bestimmte Software Funktionalität handeln.

Somit kann die oben beschriebene vorteilhafte, flexible und feingranulare Zugriffskontrolle nicht nur für die Kontrolle des Zugriffs auf Datensätze, sondern auch für die Kontrolle des Zugriffs auf eine Vielzahl anderer Funktionen einschließlich Hardwarefunktionalitäten verwendet werden.

In einem weiteren Aspekt betrifft die Erfindung ein System mit einer oder mehreren Nutzdaten-Datenbanken und einer ID-Datenbank. Das System bzw. dessen Komponenten ist bzw. sind zur Durchführung eines Verfahrens zur Zugriffskontrolle auf Datensätze, die in einer der Nutzdaten-Datenbanken gespeichert sind, konfiguriert. Das Verfahren umfasst:

- Verknüpfung eines ersten Eigner-Zertifikats, das der Nutzdaten-Datenbank zugeordnet ist, mit einem ersten Nutzer, wobei ein Eigner-Zertifikat ein Zertifikat ist, das einer oder mehreren Nutzdaten-Datenbanken zugeordnet ist und jedem Nut- zer, mit dem es verknüpft ist, das Recht gewährt, Datensätze in dieser Nutzdaten-Datenbank anzulegen;

- Bereitstellung einer ersten Schnittstelle, die es dem ersten Nutzer ermöglicht, ein zweites Eigner-Zertifikat für die Nutzdaten-Datenbank zu erstellen und dieses mit einem zweiten Nutzer zu verknüpfen um diesem zu ermöglichen, Datensätze in der Nutzdaten-Datenbank (102) anzulegen;

- Bereitstellung einer zweiten Schnittstelle, die es dem zweiten Nutzer, der einen Datensatz in der Nutzdaten-Datenbank erstellt hat, ermöglicht, mindestens ein Zugriffs-Zertifikat, das eine Art des Datensatzzugriffs auf den von dem zweiten Nutzer erstellten Datensatz spezifiziert, zu erstellen und mit dem Nutzer-Zertifikat eines Nutzers, dem Zugriff auf diesen Datensatz gewährt werden soll, zu verknüpfen, - Prüfung der Zugriffsberechtigung des ersten Nutzers auf einen von dem zweiten Nutzer angelegten Datensatz, wobei die Nutzdaten-Datenbank den Zugriff nur dann gewährt, wenn dem ersten Nutzer sowohl ein Eigner-Zertifikat für die Nutzdaten-Datenbank als auch ein Zugriffs-Zertifikat für den Zugriff auf den Datensatz zugeordnet ist.

Beispielsweise kann die Prüfung von der Nutzdaten-Datenbank in Interoperation mit der ID-Datenbank durchgeführt werden. Die erste und zweite Schnittstelle können beispielsweise von einem I D-Management Modul oder einer ID-Management Appli- kation implementiert und instanziiert werden. Das ID-Management Modul bzw. die ID-Management Applikation hat Zugriff auf den Inhalt der ID-Datenbank und vorzugsweise auch auf die Zugriffs-Zertifikate, die in den einzelnen Datensätzen der Nutzdaten-Datenbanken gespeichert sind. Das ID-Management Modul kann zum Beispiel als Plug-in das Zugriffs-Verwaltungssystem implementiert sein. Unter "Nutzdaten" werden hier Daten verstanden, die für einen Nutzer, für einen Arbeitsablauf oder für eine Hardware- oder Softwarefunktionalität außerhalb des sie beinhaltenden Zugriffs-Verwaltungssystems relevant sind und welche nicht der Zu- griffsverwaltung von Zugriffsrechten verschiedener Nutzer eines Zugriffs- Verwaltungssystems dienen. Nutzdaten können insbesondere Text, Zeichen, Bilder und Töne umfassen.

Eine„NoSQL" (englisch für Not only SQL) Datenbank ist eine Datenbank, die einen nicht-relationalen Ansatz verfolgt und keine festgelegten Tabellenschemata benötigt. Zu den NoSQL Datenbanken gehören insbesondere dokumentenorientierte Datenbanken wie Apache Jackrabbit, BaseX, CouchDB, IBM Notes, MongoDB, Graphdatenbanken wie Neo4j, OrientDB, InfoGrid, HyperGraphDB, Core Data, DEX, AllegroGraph, und 4store, verteilte ACID-Datenbanken wie MySQL Cluster, Key-Value-Datenbanken wie Chordless, Google BigTable, GT.M, InterSystems Cache, Membase, Redis, sortierte Key-Value-Speicher, Multivalue-Datenbanken, Objektdatenbanken wie Db4o, ZODB, spaltenorientierte Datenbanken und temporale Datenbanken wie Cortex DB. Unter einem„Zugriffs-Verwaltungssystem" oder„System" wird im Folgenden ein elektronisches System zur Speicherung und Wiedergewinnung von Daten verstanden. Beispielsweise kann es sich bei dem Zugriffs-Verwaltungssystem um ein„Datenbanksystem", auch„Datenbankmanagementsystem" (DBMS) handeln. Es ist aber auch möglich, dass die Daten in einem Mikrocontrollerspeicher gespeichert werden und von einem Applikationsprogramm verwaltet werden, das als Zugriffs- Verwaltungssystem arbeitet, ohne ein klassisches DBMS zu sein. Vorzugsweise werden die Daten in dem Zugriffs-Verwaltungssystem widerspruchsfrei und dauerhaft gespeichert und verschiedenen Anwendungsprogrammen und Nutzern in be- darfsgerechter Form effizient zur Verfügung gestellt. Ein Datenbankmanagementsystem kann typischerweise ein oder mehrere Datenbanken beinhalten und die darin enthaltenen Datensätze verwalten.

Unter einem „Datensatz" wird im Folgenden eine inhaltlich zusammenhängende und gemeinsam von einem Datenbankmanagementsystem verwaltete Menge an Daten verstanden. Ein Datensatz stellt typischerweise die kleinste strukturelle Einheit des Datenbestandes einer bestimmten Datenbank dar.

Unter einer„Datenbank" wird im Folgenden eine (typischerweise große) Menge von Daten verstanden, die in einem Computersystem von einem Zugriffs- Verwaltungssystem nach bestimmten Kriterien verwaltet werden. Unter einer„ID-Datenbank" wird im Folgenden eine Datenbank verstanden, welche nutzerbezogene Informationen wie zum Beispiel Nutzer-Zertifikate sowie diesen Nutzern zugewiesene Rechte in Form von weiteren Zertifikaten enthält und verwaltet. In Abgrenzung zu Nutzdaten-Datenbanken, welche vorwiegend der Speicherung von Nutzdaten dienen, dient die ID-Datenbank vorwiegend der Verwaltung der den Nutzern im Hinblick auf die Nutzdaten zugewiesenen Eigner- und Zugriffsrechte.

Unter einem "Nutzer" wird im Folgenden die digitale Repräsentanz einer menschlichen Person oder einer Softwarelogik verstanden, die bei dem Zugriffs- Verwaltungssystem registriert ist. Bei einem Nutzer kann es sich insbesondere um einen Datenbanknutzer handeln, der eine bestimmte menschliche Person repräsen- tiert. Alternativ dazu kann es sich bei dem Nutzer um einen System-Nutzer handeln, also eine digitale Repräsentation eines menschlichen Nutzers, die von einem Be- triebssystem eines Rechners verwaltet wird, und welcher zum Beispiel ein oder mehrere Datenbanknutzer zugeordnet sein können. Auch ist es möglich, dass verschiedene Softwareapplikationen jeweils durch einen Nutzer repräsentiert und bei dem Zugriffs-Verwaltungssystem registriert sind, um gegebenenfalls auf bestimmte Nutzdaten-Datenbanken und deren Datensätze zuzugreifen.

Unter einem "Zertifikat" wird hier im Folgenden ein digitales Zertifikat verstanden. Ein Zertifikat ist ein digitaler Datensatz, der bestimmte Eigenschaften von Nutzern oder anderen Objekten bestätigt und dessen Authentizität und Integrität durch kryp- tografische Verfahren geprüft werden kann. Das digitale Zertifikat enthält die zu sei- ner Prüfung erforderlichen Daten entweder selbst oder ist mit zertifikatsbezogenen Metadaten verknüpft gespeichert, sodass die zu seiner Prüfung erforderlichen Daten aus den Metadaten bezogen werden können. Die Ausstellung des Zertifikats erfolgt vorzugsweise durch eine offizielle Zertifizierungsstelle, die Certification Au- thority (CA). Beispielsweise kann das Zertifikat als Zahlenwert ausgebildet sein, welchem in der ID-Datenbank Metadaten zugeordnet sind. Die Verwendung von Zahlwerten kann vorteilhaft sein, da diese sich gut indexieren lassen und nicht einer Variation durch leicht modifizierte Metadaten unterworfen sind. Vorzugsweise sind die Zugriffs-Zertifikate einzelner Nutzer als Attributzertifikate, insbesondere als Zahlwerte ausgebildet. Attributzertifikate enthalten keinen öffentlichen Schlüssel, sondern verweisen auf ein Public-Key-Zertifikat und legen dessen Geltungsbereich genauer fest. Alternativ dazu kann ein Zertifikat auch nach dem Standard X.509 ausgebildet sein, also einen öffentlichen Schlüssel beinhalten und die Identität des Inhabers sowie weitere Eigenschaften des öffentlichen kryptographischen Schlüssels des Zertifikats bestätigen. Ein Zertifikat kann sich, muss sich aber nicht not- wendigerweise auf einen kryptographischen Schlüssel beziehen, sondern kann allgemein Daten zur Prüfung einer elektronischen Signatur enthalten oder mit diesen Daten verknüpft gespeichert sein.

Unter "Log" wird hier insbesondere eine Datenmenge, z.B. eine Log-Datei, verstanden, welche automatisch erzeugt wird und in welcher Prozesse, die in einem Zu- griffs-Verwaltungssystem ablaufen, aufgezeichnet werden. Unter einer "Schnittstelle" wird im Folgenden eine Verbindungsstelle für den Datenaustausch zwischen einem Zugriffs-Verwaltungssystem und einem oder mehreren menschlichen Nutzern verstanden, welche eine Programmlogik beinhaltet, die in Abhängigkeit von Nutzer-Interaktionen mit der Schnittstelle Zugriffs- und Eigner- Rechte erzeugt und/oder anderen Nutzern zuweist. Die Schnittstelle kann insbesondere als graphische Benutzeroberfläche („GUI") oder als ein Teilbereich einer GUI ausgebildet sein.

Unter einem„Root-Zertifikat" oder„Wurzel -Zertifikat" wird im Folgenden dasjenige Zertifikat bezeichnet, das den Vertrauensanker einer PKI darstellt. Da das Wurzel- Zertifikat und damit die gesamte Zertifikatshierarchie nur vertrauenswürdig bleibt, solange dessen privater Schlüssel ausschließlich der ausstellenden Partei bekannt ist, kommt dem Schutz der Root-CA höchste Bedeutung zu.

Gemäß manchen Ausführungsformen stellt das Nutzer-Zertifikat desjenigen Nutzers, der in der Hierarchie einer Organisation ganz oben angesiedelt ist, das Root- Zertifikat der PKI dieser Organisation dar. Die Nutzer-Zertifikate aller anderen Mitglieder dieser Organisation sind von dem privaten Schlüssel dieses Root-Zertifikats signiert und damit von diesem gemäß einer Zertifikatskettenhierarchie abhängig. Aufgrund des hohen Schutzbedürfnisses des Root-Zertifikats erfolgt die automatische Verarbeitung von Signatur- oder Verschlüsselungsanforderungen mit Unterzer- tifikaten, die mit dem Root-Zertifikat signiert wurden und eine kürzere Gültigkeit (meist wenige Monate bis Jahre) als das Root-Zertifikat (das in der Regel mehrere Jahre oder Jahrzehnte gilt) aufweisen. Beispielsweise können die Nutzer-Zertifikate anderer Nutzer und/oder die von einzelnen Nutzern ausgestellten oder übertragenen Eigner-Zertifikate, Zugriffs-Zertifikate und/oder Attribut-Zertifikate eine begrenz- te Gültigkeitsdauer von wenigen Tagen oder Monaten haben. Die Gültigkeit der Unterzertifikate wird so gewählt, dass es als unwahrscheinlich angesehen werden kann, dass die zu den Unterzertifikaten gehörenden privaten Schlüssel innerhalb des gewählten Gültigkeitszeitraums mit derzeit verfügbarer Rechenkapazität berechnet werden können. Auf diese Weise entsteht eine Zertifikatskette, bei der je- weils auf das unterzeichnende Zertifikat als ausgebende Stelle verwiesen wird. Diese Kette wird in der Regel als Teil eines Zertifikats mitgeliefert, um eine Prüfung be- züglich Vertrauenswürdigkeit, Gültigkeit und ggf. vorhandenem Zertifikatswiderruf entlang der gesamten Zertifikatskette zu ermöglichen.

Unter einem„Eigner" oder„Eigentümer" wird im Folgenden ein Nutzer verstanden, dem durch Zuweisung eines Eigner-Zertifikats das Recht im Hinblick auf eine be- stimmte Nutzdaten-Datenbank eingeräumt wurde, in dieser Datensätze zu erstellen und eine Datenbankverbindung mit dieser Datenbank aufzubauen. Nach ausfüh- rungsformen leiten sich alle Eigner-Zertifikate, die für die Nutzdaten-Datenbanken eines Zugriffsverwaltungs-System ausgestellt wurden, vom Nutzer-Zertifikat („CEO- Zertifikat") desjenigen Nutzers ab, der die höchste Position innerhalb der Organisa- tion, die das Zugriffsverwaltungs-System betreibt, innehat. Die Ableitung aus diesem Nutzer-Zertifikat bedeutet, dass jede Kopie dieses Eigner-Zertifikats per Zertifikatskettenprüfung auf Validität überprüft werden kann, wobei die für die Zertifikatskettenprüfung verwendete Zertifikatskette das„CEO-Nutzer-Zertifikat" beinhaltet.

Unter einem„zugriffsberechtigten Nutzer" wird im Folgenden ein Nutzer verstan- den, dem durch Zuweisung eines Zugriffs-Zertifikats das Recht eingeräumt wurde, auf einen Datensatz, der dieses Zugriffs-Zertifikat beinhaltet, auf die Weise zuzugreifen, die in diesem Zugriffs-Zertifikat spezifiziert ist, sofern weitere notwendige Kriterien, wie z.B. die Eignerschaft bezüglich der den Datensatz enthaltenden Datenbank, erfüllt sind.

Die Verwendung von Ordinalzahlen wie erstes, zweites, drittes etc. dient hier, allein der Unterscheidung voneinander Elemente und/oder Personen mit ansonsten gleicher Bezeichnung und soll keine bestimmte Reihenfolge implizieren. Ferner kann es sich bei Elemente und/oder Personen, deren Bezeichnung sich allein durch eine Ordinalzahl unterscheidet, soweit sich aus dem konkreten Zusammenhang nicht eindeutig etwas anderes ergibt, um identische oder voneinander verschiedene Elemente bzw. Personen handeln.

Kurzbeschreibung der Figuren

Ein exemplarisches Verfahren zur Zugriffskontrolle auf Datensätze eines Zugriffs- Verwaltungssystems sowie ein entsprechendes exemplarisches Zugriffs- Verwaltungssystem sind in den anhängenden Zeichnungen 1 -2 sowie 5-9 veranschaulicht. Darin zeigen:

Figur 1 ein Blockdiagramm einer Ausführungsform eines erfindungsgemäßen

Zugriffs-Verwaltungssystem mit mehreren Datenbanken,

Figur 2 den Vorgang der Erstellung von Berechtigungsnachweisen für zwei

Nutzer gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens,

Figur 3 im Stand der Technik verwendete Verfahren zur Zugriffskontrolle ent- lang einer vorgegebenen Unternehmenshierarchie,

Figur 4 im Stand der Technik verwendete Verfahren zur Zugriffskontrolle basierend auf der Verwendung von Rollen,

Figur 5 den Ablauf der Einräumung von Zugriffsrechten über eine Sequenz von

Nutzern,

Figur 6 Ein Beispiel für Nutzdaten, die Bestandteil eines Datensatzes sind,

Figur 7 zwei dynamisch und unabhängig voneinander generierte Hierarchien, entlang welcher einerseits Zugriffsrechte und andererseits Eignerrechte über eine Kaskade von Nutzern vergeben wurden,

Figur 8 die Neuausstellung eines Nutzer-Zertifikats für einen neuen Geschäfts- führer einer Organisation, und

Figur 9 ein Flussdiagramm einer weiteren Ausführungsform eines erfindungsgemäßen Verfahrens.

Ausführliche Beschreibung Figur 1 zeigt ein Blockdiagramm einer Ausführungsform eines erfindungsgemäßen Zugriffs-Verwaltungssystem 100 mit mehreren Nutzdaten-Datenbanken 102 DB1 , 104 DB2 und einer ID-Datenbank 136. Das Zugriffs-Verwaltungssystem 100 ist dazu konfiguriert den Zugriff von mehreren Nutzern U1 , U2, U3, auf mehrere Datensätze 1 12, 1 14, 1 16 zu kontrollieren. Beispielsweise ist einem ersten Nutzer- U1 ein Nutzer-Zertifikat 134 zugeordnet. Das Nutzer-Zertifikat 134 wurde von einer Zertifizierungsstelle 140 als ein Root- Zertifikat für den Nutzer-111 ausgestellt. Nutzer U1 wie auch die anderen Nutzer U2, U3 könnten beispielsweise Mitarbeiter eines Unternehmens repräsentieren. In analoger Weise könnten auch den weiteren Mitarbeitern des Unternehmens Nutzer- Zertifikate 132,124 zugeordnet sein, die von der Zertifizierungsstelle als Root- Zertifikate ausgestellt wurden. Die Nutzer-Zertifikate 134,132,124 können durch Zer- tifikatskettenprüfung bis zum entsprechenden Rot-Zertifikat der Zertifizierungsstelle geprüft werden.

Der erste Nutzer U1 könnte beispielsweise technischer Administrator für mehrere Nutzdaten-Datenbanken DB1 , DB2, sein. Entsprechend kann dem ersten Nutzer U 1 ein Eigner-Zertifikat 128 für die erste Nutzdaten-Datenbank DB1 zugeordnet sein. Die Zuordnung, auch „Verknüpfung" genannt, kann beispielsweise in Form eines Ermächtigungskettenobjekts 139 implementiert und in einer ID-Datenbank 136 gespeichert sein.

Das Zugriffs-Verwaltungssystem 100 ist also dazu ausgebildet, ein erstes Eignerzertifikat, zum Beispiel Eigner-Zertifikat 128 bezüglich DB1 oder Eigner-Zertifikat 130 bezüglich DB2 mit dem ersten Nutzer U 1 zu verknüpfen. Dies kann durch Speicherung des Eigner-Zertifikats 128 und des Nutzer-Zertifikat 134 des ersten Nutzers U1 in einem Eignerschaftsermächtigungskettenobjekt 139 erfolgen bzw. durch Speicherung des Eigner-Zertifikat 130 und des Nutzer-Zertifikats 134 des ersten Nutzers U1 in einem Eignerschaftsermächtigungskettenobjekt 141 . Ein Eigner- Zertifikat ist ein Zertifikat, welches einer oder mehreren Nutzdaten-Datenbanken zugeordnet ist und jedem Nutzer, mit dem es verknüpft ist, das Recht gewährt, Datensätze in dieser Nutzdaten-Datenbank anzulegen. Beispielsweise gewährt das Eigner-Zertifikat 128 jedem Nutzer, dem es (zum Beispiel durch ein Eignerschafts- ermächtigungskettenobjekt) zugeordnet ist, das Recht, einen oder mehrere Datens- ätze in der Datenbank-DB1 zu erstellen.

Das Zugriffs-Verwaltungssystem 100 beinhaltet eine erste Schnittstelle 142, die es dem ersten Nutzer U1 , dem das Eigner-Zertifikat 128 für die Datenbank DB1 zugeordnet ist, ermöglicht, ein zweites Eigner-Zertifikat für die Nutzdaten-Datenbank DB1 zu erstellen und dieses zweite Eigner-Zertifikat mit einem zweiten Nutzer U2 zu verknüpfen. Diese Verknüpfung mit dem zweiten Eigner-Zertifikat ermöglicht es dem zweiten Nutzer, nun seinerseits Datensätze in der Nutzdaten-Datenbank DB1 anzu- legen. Auch der zweite Nutzer kann sich, sofern das zweite Eigner-Zertifikat gemäß seines Delegierbarkeitsparameters delegierbar ist, dieser ersten Schnittstelle bedienen um weiteren Nutzern seines Vertrauens identische oder veränderte Kopien des Eigner-Zertifikats für die Datenbank-DB1 auszustellen und in Verbindung mit einem Nutzer-Zertifikat dieser weitere Nutzer in der ID-Datenbank zu speichern, zum Beispiel in Form weiterer Eignerschaft Ermächtigungskettenobjekte 139, 141 .

Das Zugriffs-Verwaltungssystem 100 beinhaltet eine zweite Schnittstelle 144, die es dem zweiten Nutzer U2, der einen Datensatz 106, 108 in der Nutzdaten-Datenbank 102 erstellt hat (nachdem ihm bereits von dem ersten oder einem anderen Nutzer ein Eigner-Zertifikat für die DB1 ausgestellt wurde), ermöglicht, mindestens ein Zugriffs-Zertifikat zu erstellen und mit dem Nutzer-Zertifikat eines Nutzers, dem Zugriff auf diesen Datensatz gewährt werden soll, zu verknüpfen. Bei dem Nutzer, dem Zugriff gewährt werden soll, kann es sich um einen beliebigen anderen Nutzer, der bei dem Zugriffs-Verwaltungssystem registriert ist und der das Vertrauen des zwei- ten Nutzers (Datensatzerstellers) besitzt, handeln. Bei den Zugriffs-Zertifikaten des zweiten Nutzers U2 kann es sich zum Beispiel um ein Schreibzugriffs-Zertifikat Z.Zert_U2[W], ein Lesezug riffs-Zertifikat Z.Zert_U2[R] und/oder ein Indexzugriffs- Zertifikat Z.Zert_U2[S] handeln. Ein Zugriffs-Zertifikat kann also eine Art des Datensatzzugriffs auf den von dem zweiten Nutzer erstellten Datensatz spezifizieren. Falls nun der erste Nutzer U 1 auf einen Datensatz 106, 108, den der zweite Nutzer U2 erstellt hat, zugreifen will, prüft das Zugriffs-Verwaltungssystem die Zugriffsberechtigung des ersten Nutzers auf einen von dem zweiten Nutzer angelegten Datensatz 106, 108. Der gewünschte Zugriff wird dem ersten Nutzer nur dann gewährt, wenn das Zugriffs-Verwaltungssystem feststellt, dass dem ersten Nutzer U1 sowohl ein Eigner-Zertifikat für die Nutzdaten-Datenbank 102 als auch ein Zugriffs-Zertifikat Z.Zert U2 [W] (oder [R] oder [S]) für den Zugriff auf den Datensatz zugeordnet ist.

Die einzelnen Datensätze 106, 108, 1 10, 1 12, 1 14, 1 16 enthalten lediglich Zugriffs- Zertifikate, die der Nutzer, der den betreffenden Datensatz erstellt hat, diesen Datensätzen im Zuge der Erstellung zuweist. Beispielsweise kann das Zugriffs- Verwaltungssystem 100 während des Vorgangs der Erstellung eines neuen Datensatzes im Hintergrund automatisch prüfen, welche Zugriffs-Rechte für den Nutzer, der gerade einen Datensatz erstellt, in der ID-Datenbank hinterlegt sind. Dies kann insbesondere dann vorteilhaft sein, wenn jedem Nutzer ein vordefinierter Satz an Zugriffs-Zertifikaten (zum Beispiel für Lese-, Schreib-, und Indexzugriffsrechte) zugewiesen ist welcher automatisch auch komplett jedem neu erstellten Datensatz zugewiesen werden soll. Diese Situation ist in Figur 1 dargestellt. Alternativ dazu ist es jedoch auch möglich, dass jedem Nutzer mehrere verschiedene Zugriffs- Zertifikate (der gleichen Zugriffsart, zum Beispiel Lesezugriff) in der ID-Datenbank zugewiesen sind und der Nutzer manuell über eine GUI im Zuge der Datensatzerstellung auswählen kann, welche dieser Zugriffs-Zertifikate dem neuen Datensatz zugewiesen werden sollen. Dies kann vorteilhaft sein, da der Nutzer für eine große Vielzahl von Datensätzen, die er anliegt und die zum Beispiel ähnlichen Inhalts sind oder ein ähnliches Vertraulichkeitsniveau besitzen, den gleichen Satz an Zugriffs- Zertifikaten im Zuge der Erstellung zuweisen kann. Für den Fall aber dass der Nutzer zum Beispiel zehn verschiedene Kreditkarten verwaltet und die vertraulichen Kreditkartennummern in zehn verschiedenen Datensätzen speichert, hat der Nutzer auch die Möglichkeit, jedem dieser Datensätze ein anderes Zugriffs-Zertifikat zuzuweisen. Dies hat den Vorteil, dass der Ersteller jedes dieser Kreditkartennummern- Datensätze weiteren Nutzern selektiv nur für einen bestimmten Kreditkartennummern-Datensatz gewähren kann, also ohne den betreffenden weiteren Nutzern au- tomatisch auch Zugriffsrechte für die anderen Kreditkartendatensätze zu geben. Der Einfachheit halber beziehen sich die meisten der hier beschriebenen Ausführungsformen und Beispiele darauf, das einem Nutzer 3 Zugriffs-Zertifikate für Lese-, Schreib-, und Indexzugriffsrechte zugewiesen sind, die im Zuge einer Datensatzerstellung durch den Nutzer automatisch in diesen Datensatz integriert werden. Diese Beispiele sind jedoch so zu verstehen, dass nach alternativen Ausführungsformen und Beispielen der Nutzer, der einen Datensatz erstellt, auch manuell eine bestimmte Untermenge aus vordefinierten und ihm zugewiesenen Zugriffs-Zertifikaten auswählen und in den erstellten Datensatz integrieren kann.

Die in Figur 1 dargestellten Datensätze zeigen, dass beispielsweise die Datensätze 106, 108, und 1 12 von dem Nutzer U2 angelegt wurden. Der Datensatz 1 10 wurde von dem Nutzer U1 angelegt. Der Datensatz 1 16 wurde von dem Nutzer U3 angelegt. Die vordefinierten Zugriffs-Zertifikate der jeweiligen Ersteller wurden in die Da- tensätze integriert. Zumindest die Ersteller haben also vollumfänglichen Zugriff auf ihre Datensätze, sofern sie auch über ein Eigner-Zertifikat für die jeweilige Nutzdaten-Datenbank verfügen. Es ist jedoch durchaus möglich, dass weitere Nutzer Zugriff auf einzelne Datensätze haben. Diese Information ist jedoch nicht in der Nutz- daten-Datenbank enthalten, sondern in Form von Zugriffsermächtigungskettenob- jekten 143 in der ID-Datenbank gespeichert. So ist beispielsweise aus dem Objekt 143 ersichtlich, dass ein Zugriffs-Zertifikat des Nutzers U1 , dass ein Leserecht spezifiziert, von dem Ersteller U1 dem Nutzer U2 zugewiesen wurde, indem das Nutzer- Zertifikat 132 dieses Nutzers U2 innerhalb des Objekts 143 mit dem Lesezugriffs- Zertifikat von U1 verknüpft wurde. Außerdem ist aus dem Objekt 143 ersichtlich, dass der Nutzer U2 dieses Leserecht auf einen weiteren Nutzer U3 übertragen (weitergegeben) hat, indem das Nutzer-Zertifikat 124 des Nutzers U3 innerhalb des Objekts 143 mit dem Lesezug riffs-Zertifikat von U1 verknüpft wurde. Im Zuge jeder Übertragung eines Zugriffsrechts bzw. damit einhergehend im Zuge jeder Zuwei- sung eines weiteren Nutzer-Zertifikats zu einem bestimmten Zugriffs-Zertifikat wird ein neues Zugriffsermächtigungskettenobjekt in der ID-Datenbank vom Zugriffs- Verwaltungssystem erstellt. Dem menschlichen Nutzer wird vorzugsweise eine intuitive GUI angeboten um Nutzern Zugriffs bzw. Eignerrechte zu übertragen und dadurch im Hintergrund die Erzeugung weiterer Zertifikate oder weiterer Verknüp- fungen von Zugriffs-bzw. Eigner-Zertifikaten mit Nutzer-Zertifikaten zu initialisieren. Das Zugriffsermächtigungskettenobjekt 143 impliziert also, dass sowohl Nutzer U2 als auch Nutzer U3 (und selbstverständlich auch Nutzer U1 ) Lesezugriff auf die von Nutzer-U1 erstellten Datensätze, zum Beispiel Datensatz 1 10, haben.

In analoger Weise spezifizieren Eignerschaftsermächtigungskettenobjekten 139, 141 eine Kette aus ein oder mehreren Nutzern, die anderen Nutzern Eigner- Zertifikate zugewiesen und dadurch Eigner-Rechte übertragen haben. So geht beispielsweise aus Objekt 139 hervor, dass der Nutzer-U1 Eigner-Rechte im Hinblick auf die Nutzdaten-Datenbank-DB1 besitzt, da das Nutzer-Zertifikat 134 des Nutzers U1 in dem Objekt 139 dem Eigner-Zertifikat 128 der DB1 zugewiesen ist. Das Ob- jekt 141 spezifiziert, dass der Nutzer U1 die Eigner-Rechte für die Datenbank DB2 an einen weiteren Nutzer U2 übertragen hat. Falls ein Nutzer eine Zugriffsanfrage auf eine bestimmte Nutzdaten-Datenbank 102 absendet, prüft das Zugriffs-Verwaltungssystem 100 oder eine Komponente desselben, zum Beispiel die betreffende Datenbank 102, ob dem Nutzer, von dem die Anfrage stammt, in der ID- Datenbank ein Eigner-Zertifikat zugewiesen ist. Beispiels- weise könnte dieser Schritt eine Analyse sämtlicher Eignerschaftsermächtigungs- kettenobjekte, die sich auf diese Nutzdaten-Datenbank 102 beziehen, umfassen. Nur falls der anfragenden Nutzer diese Eignerrechte hat, wird ihm der Aufbau einer Datenbank Verbindung zu der Nutzdaten-Datenbank 102 gewährt und, falls dies angefragt wird, auch die Erstellung neuer Datensätze in dieser Datenbank. Damit diese Nutzer jedoch auch auf einzelne Datensätze lesend oder schreibend zugreifen kann oder über einen Index unerfahren bringen kann ob ein bestimmter Datensatz überhaupt existiert, müssen ihm (als es einem Nutzer-Zertifikat) in der ID- Datenbank auch die entsprechenden Rechte zugewiesen sein. Das Zugriffs- Verwaltungssystem prüft vor jedem Zugriff eines Nutzers mit Eignerschaftsrechten also zusätzlich, ob der Nutzer über die erforderlichen Zugriffsrechte verfügt.

Nach manchen Ausführungsformen (hier nicht dargestellt) verfügt jeder Datensatz einer bestimmten Nutzdaten-Datenbank über ein oder mehrere zusätzliche Felder für Zugriffs-Zertifikate, die anderen Nutzern oder Funktionen zugewiesen sind (also nicht speziell dem Nutzer, der den Datensatz erstellt hat). Beispielsweise kann es sich bei einer Nutzdaten-Datenbank um eine Finanzdaten-Datenbank oder um eine Personaldaten-Datenbank handeln. Um die Sicherheit zu erhöhen, kann zum Beispiel in jedem Datensatz der Finanzdatenbank ein zusätzliches Feld enthalten sein, in welchem ein Finanzdaten-Zertifikat gespeichert ist. Falls es sich bei der Datenbank um eine Personaldatenbank handelt, kann in jedem Datensatz der Personal- datenbank ein zusätzliches Feld enthalten sein, in welchem ein Personalabteilung- Zertifikat gespeichert ist. Es können eine Vielzahl solcher Felder pro Datensatz enthalten sein, und das Zugriffs-Verwaltungssystem kann für bestimmte Typen von Nutzdaten-Datenbanken automatisch im Zuge der Erzeugung eines neuen Datensatzes die entsprechenden Zugriffs-Zertifikate in den Feldern speichern. Beispiels- weise wird bei Erzeugung eines neuen Finanzdaten-Datensatzes automatisch in das entsprechende Feld ein Finanzdaten-Zertifikat durch das Zugriffs- Verwaltungssystem eingefügt. Ein Nutzer, der auf einen solchen Datensatz zugrei- fen möchte, muss also zusätzlich zu dem Eignerschaftsrecht bezüglich der Datenbank und zusätzlich zu der Zugriffsberechtigung durch den Ersteller oder einer von diesen dazu ermächtigten Nutzer auch noch nachweisen, dass ihm ein Finanzdaten-Zertifikat zugewiesen ist. Dies kann die Sicherheit erhöhen, da so auf relativ generische und globale Art und Weise bestimmten Nutzern der Zugriff auf bestimmte Daten verwehrt werden kann, von welchen davon ausgegangen werden kann, dass sie für die Arbeit des Nutzers nicht notwendig sind. Vorzugsweise ist die Gesamtheit der Zugriffs-Zertifikate eines Datensatzes durch ein oder mehrere logische Operatoren wie zum Beispiel„AND" oder„OR" miteinander verbunden, sodass sich ein komplexer, logisch verbundener Ausdruck ergibt, welcher spezifiziert, welche Zugriffs-Zertifikate einem Nutzer zugewiesen sein müssen damit dieser Zugriff auf einen Datensatz hat. Dabei beinhalten die Zugriffs-Zertifikate eines Datensatzes vorzugsweise eine Mischung aus Zugriffs-Zertifikaten, die dem Ersteller des Datensatzes persönlich zugewiesen sind und die anderen Nutzern persönlich zugewiesen werden müssen um diesen Zugriff zu gewähren, und Zugriffs-Zertifikaten, die von dem Zugriffs-Verwaltungssystem oder einem menschlichen Nutzer automatisch o- der manuell jedem Datensatz einer bestimmten Nutzdaten-Datenbank bei Erstellung zugewiesen werden (zum Beispiel Finanzdaten-Zugriffszertifikat oder Personalda- ten-Zugriffszertifikat). Diese Zugriffs-Zertifikate werden auch als„Attribut-Zertifikate" bezeichnet.

Optional können die einzelnen Ermächtigungsobjekte 139, 141 , 143 mit dem privaten Signaturschlüssel 107 des Zugriffs-Verwaltungssystems signiert werden. Zusätzlich oder alternativ dazu können Berechtigungsnachweise, die in Antwort auf eine Zugriffsanfrage eines Nutzers an eine Nutzdaten-Datenbank von der ID- Datenbank für den Nutzer dynamisch erstellt werden, signiert werden (siehe Beschreibung Fig. 2).

Figur 2 illustriert den Vorgang der Erstellung von Berechtigungsnachweisen für zwei Nutzer U2, U3 gemäß einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens. Wesentliche Komponenten der hier dargestellten Ausführungsform entsprechen den in Figur 1 beschriebenen Komponenten, jedoch können die Eig- nerschafts-und Zugriffsrechtsverhältnisse der in Figur 2 abgebildeten Situation von der in Figur 1 abgebildeten Situation abweichen. In der ID-Datenbank sind einer Vielzahl von Nutzern 202 jeweils ein Nutzer-Zertifikat 204 zugewiesen. Die Nutzer-Zertifikate werden vorzugsweise von einer Zertifizierungsstelle 140 herausgegeben und mit einem privaten Signierschlüssel 212 der Zertifizierungsstelle signiert. Die Zertifizierungsstelle stellt zudem einen öffentlichen Signaturprüfschlüssel 210 zur Verfügung (zum Beispiel über entsprechende öffentl iche Schlüsselverzeichnisse, die über das Internet einsehbar sind). Das bedeutet, dass die ID-Datenbank 136 die Validität eines Nutzer-Zertifikats durch Zertifikatskettenprüfung unter Einbeziehung des öffentlichen Signaturprüfschlüssels 210 der Zertifizierungsstelle prüfen kann. In der ID-Datenbank können Identifikatoren 216 meh- rerer Nutzdaten-Datenbanken gespeichert sein, welchen wiederum jeweils ein oder mehrere eigene-Zertifikate zugewiesen sein können. Vorzugsweise enthält die ID- Datenbank jedoch keine Nutzdaten oder Verweise auf einzelne Datensätze in Nutzdaten-Datenbanken.

Wenn ein Nutzer U2, zum Beispiel über eine grafische Benutzeroberfläche, Zugriff auf Datensätze, die in der Nutzdaten-Datenbank-DB1 gespeichert sind, anfordert, wird von dem Zugriffs-Verwaltungssystem 100 automatisch eine Berechtigungsanfrage für diesen Nutzer U2 generiert und an die ID-Datenbank gesendet. Diese analysiert eine Menge an Ermächtigungskettenobjekten 137 um festzustellen, welche Eigner-Zertifikate und Zugriffs-Zertifikate dem Nutzer-Zertifikat 132 des Nutzers U2 zugewiesen sind und erstellt dynamisch in Antwort an diese Berechtigungsanfrage einen Berechtigungsnachweis 220 für den Nutzer U2. Aus diesem Berechtigungsnachweis geht hervor, dass dem Nutzer U2 ein Eigner-Zertifikat 128 für die Daten- bank-DB1 zugewiesen ist, der Nutzer also zum Aufbau einer Datenbank Verbindung zur DB1 berechtigt ist. Außerdem geht aus dem Berechtigungsnachweis hervor, dass der Nutzer U2 berechtigt ist für den Schreibzugriff auf sämtliche Datensätze, die von dem Nutzer-111 erstellt wurden.

Beispielsweise kann der Berechtigungsnachweis gegliedert sein in einen Konnektivitätsnachweis 206 für den Nutzer U2 im Hinblick auf die Erstellung einer Datenbank Verbindung zur DB1 und in einen Zugriffsberechtigungsnachweis im Hinblick auf eine bestimmte Zugriffsart und im Hinblick auf alle Datensätze, die von einem bestimmten Nutzer erstellt wurden. Der Berechtigungsnachweis 202 und/oder die jeweiligen Teil- Berechtigungsnachweise 206, 225 können eine Signatur 237, 236 enthalten, die mit dem privaten Signierschlüssel 107 der ID-Datenbank dynamisch in Antwort auf die Berechtigungsanfrage erzeugt wurde. Jede der Nutzdaten-Datenbanken beinhaltet einen öffentlichen Signaturprüfschlüssel 105, der mit dem privaten Signierschlüssel 107 ein asymmetrisches kryptographisches Schlüsselpaar bildet. Bevor die Nutzda- ten-Datenbank-DB1 dem Nutzer U2 den Aufbau einer Datenbankverbindung und/oder den Zugriff auf einzelne Datensätze erlaubt, wird neben dem Vorhandensein der entsprechenden Zertifikate auch die Validität der Signaturen 237, 236 ge- prüft und der Verbindungsaufbau bzw. der Datensatzzugriff nur im Falle der Validität der Signatur zugelassen.

In analoger Weise wird in Antwort auf eine Zugriffsanfrage des Nutzers U3 von der ID-Datenbank der Berechtigungsnachweis 222 generiert und signiert, aus welchem hervorgeht, dass Nutzer U3 zum Verbindungsaufbau zur Datenbank-DB1 berechtigt ist. Außerdem geht aus den Berechtigungsnachweisen 226, 242 hervor, dass der Nutzer U3 auf die von Nutzer U2 erstellten Datensätze lesend und schreibend zugreifen darf und auch eine Indexabfrage um zu erfahren, ob ein bestimmter Datensatz, den der Nutzer erstellt hat, überhaupt existiert, durchführen darf. Außerdem darf Nutzer-U3 eine entsprechende Indexabfrage für Datensätze durchführen, die der Nutzer-111 erstellt hat, jedoch nicht schreibend oder lesend zugreifen.

Dass der Nutzer U2 auf die Datensätze des Nutzers U 1 nur lesend und schreibend, aber nicht per Indexzugriff zugreifen darf, geht aus dem Fehlen eines entsprechenden Zugriffs-Zertifikats in einem entsprechenden Zugriffsermächtigungskettenobjekt hervor. Dieses Fehlen ist durch Box 228 angedeutet. Dass der Nutzer U3 auf die Datensätze des Nutzers U1 nicht schreibend oder lesend zugreifen darf, geht aus den Boxen 229, 230 hervor. Wenn einem Nutzer in der ID-Datenbank Zugriffsrechte in Form entsprechender Zugriffs-Zertifikate nicht zugewiesen sind, enthält auch der dynamisch erstellte Berechtigungsnachweis 220, 222 die entsprechenden Rechte nicht. Vorzugsweise enthalten die dynamisch erstellten Berechtigungsnachweise 220, 222 nicht die gesamte Kette der Nutzer-Zertifikate derjenigen Nutzer, die anderen Nut- zern entsprechende Eigner-Zertifikate oder Zugriffs-Zertifikate zugewiesen haben, sondern nur die dem anfragenden Nutzer zugewiesenen Eigner- und Zugriffs- Zertifikate sowie optional noch das Nutzer-Zertifikat des anfragenden Nutzers. Für den Nachweis der Berechtigung ist eine Dokumentation der Übertragungskette der Rechte nicht relevant. Dadurch, dass die Berechtigungsnachweise frei sind von den Nutzer-Zertifikaten der Übertragungskette, kann die Größe der Berechtigungsnachweise reduziert, das Verfahren beschleunigt und der Datenverkehr reduziert werden.

Figur 5 zeigt beispielhaft für 4 Nutzer 402, 420, 422, 438, welche Zugriffs-Zertifikate und Nutzer-Zertifikate diesen Nutzern in der ID-Datenbank jeweils zugewiesen sein können. Beispielsweise ist dem Nutzer 402 ein Nutzer-Zertifikat 412 zugewiesen. Außerdem sind dem Nutzer 3 Zugriffs-Zertifikate für unterschiedliche Arten des Zugriffs auf die von ihm erstellten Datensätze zugewiesen, nämlich das Zugriffs- Zertifikat 404 für den Lesezugriff, das Zugriffs-Zertifikat 406 für den Schreibzugriff sowie das Zugriffs-Zertifikat 408 für den Zugriff auf einen oder mehrere Indices eine Nutzdaten-Datenbank um zu erfahren, ob und wie viele Datensätze dieser Nutzer in der Nutzdaten-Datenbank erstellt hat. In analoger Weise sind auch den anderen Nutzern 420, 422, 438 entsprechende Nutzer-Zertifikate und Zugriffs-Zertifikate zugewiesen. Figur 5 illustriert zudem eine mögliche Sequenz der Übertragung von Zugriffs- Rechten über eine Kette mehrerer Nutzer.

In einem ersten Schritt erstellt der Nutzer 402 in einer Nutzdaten-Datenbank DB1 einen Datensatz 410. Im Zuge der Erstellung werden neben den eigentlichen Nutzdaten, wie zum Beispiel in Figur 6 abgebildet, automatisch im Hintergrund auch die 3 Zugriffs-Zertifikate 404, 406, und 408, die dem erstellenden Nutzer 402 zugewiesen sind, in entsprechenden Feldern des Datensatzes gespeichert.

In einem nächsten Schritt überträgt der Ersteller 402 mithilfe einer GUI einem anderen Nutzer 420 Leserechte auf den Datensatz 410 (sowie auf sämtliche anderen Datensätze, die der Nutzer 402 mit diesem speziellen Lesezug riffs-Zertifikat 404 erstellt hat). Dies bedeutet, dass das Zugriffs-Verwaltungssystem in der ID- Datenbank dem Nutzer dieses spezielle Lesezug riffs-Zertifikat 404 zuweist, zum Beispiel in dem dieses Zertifikat 404 mit dem Nutzer-Zertifikat 414 des Nutzers 420 verknüpft gespeichert wird, zum Beispiel innerhalb des gleichen Zugriffsermächti- gungskettenobjekts.

Der Ersteller des Datensatzes 410 kann auch einem anderen Nutzer Zugriffsrechte einräumen. So räumt der Nutzer 402 beispielsweise im nächsten Schritt einem anderen Nutzer 422 (Nutzer-Zertifikat 418) Lese-und Schreibrechte für sämtliche von dem Nutzer 402 erstellten Datensätze, die die Zertifikate 404 und 406 beinhalten, ein. Die ID-Datenbank bzw. die Ermächtigungskettenobjekte werden um ein neues Zugriffsermächtigungskettenobjekt je Zugriffs-Zertifikat 404, 406, das dem Nutzer- Zertifikat 418 zugewiesen werden soll, ergänzt, welche spezifizieren, dass der Nutzer 402 dem Nutzer 422 die Zugriffs-Zertifikate 404 und 406 zugewiesen hat. In den neu generierten Zugriffsermächtigungskettenobjekten kann jeweils eine Kopie des oder der zugewiesenen Zugriffs-Zertifikate gespeichert sein, die zumindest im Hinblick auf den Wert eines Delegierbarkeitsparameters von dem ursprünglichen Zu- griffs-Zertifikat abweicht. Dadurch kann jeder Nutzer der Kette kontrollieren, ob ein anderer Nutzer, dem er bestimmte Rechte einräumt, diese weitergeben kann oder nicht. In dem in Figur 5 dargestellten Beispiel wurden dem Nutzer 422 die Zugriffsrechte 404 und 406 in delegierbarer Form zugewiesen. Alternativ dazu ist es auch möglich dass nur ein einziges Zugriffsermächtigungskettenobjekt erzeugt wird, wel- ches beide Zugriffs-Zertifikate 404, 406 und das Nutzer-Zertifikat 418 beinhaltet.

Der Nutzer 418 kann diese Rechte also an andere weitergeben, was im nächsten Schritt illustriert ist: der Nutzer 422 weist die ihm zugewiesenen Zugriffs-Rechte 404 und 406 nunmehr auch an den Nutzer 438 zu. Diese Zuweisung bewirkt eine Erstellung eines neuen Zugriffsermächtigungskettenobjekts in der ID-Datenbank für jedes der Zugriffs-Zertifikate 404, 406, in welchen jeweils die in ihnen enthaltene Nutzer- Zertifikatskette durch Anfügen eines weiteren Nutzer-Zertifikats 436 des Nutzers, dem die Rechte zugewiesen wurden, um ein Glied erweitert wird. Nach einer alternativen Implementierung wird für zwei oder mehrere Zugriffs-Zertifikate, die mit der gleichen Kette an Nutzer-Zertifikaten verknüpft sind, insgesamt nur ein neues Zu- grifffsermächtigungskettenobjekt pro Rechteübertragung an einen anderen Nutzer erzeugt. Im Beispiel von Figur 5b würden die Zertifikate 404 und 406 im gleichen Zugrifffsermächtigungskettenobjekt gespeichert sein, welches zudem auch die Nutzer-Zertifikate 418 und 436 beinhaltet.

Die in den Ermächtigungskettenobjekten dokumentierte Kette an Nutzer-Zertifikaten dokumentiert die Übertragung von Eigner-oder Zugriffs-Rechten über eine Sequenz mehrerer Nutzer. Die Sequenz kann aus einer bloßen Aneinanderreihung von Nutzer-Zertifikaten bestehen, wobei beispielsweise die Position der Nutzer-Zertifikate innerhalb der Kettenobjekte die zeitliche Reihe der Übertragungen repräsentiert. Optional kann nach manchen Ausführungsformen die Kette von Nutzer-Zertifikaten innerhalb eines Ermächtigungskettenobjekten dadurch generiert werden, dass die ID-Datenbank die den einzelnen Nutzer-Zertifikaten zugeordneten privaten Schlüssel so verwendet, dass das letzte Nutzer-Zertifikat in der Kette das an dieses neuangefügte neue Nutzer-Zertifikat signiert, sodass auch innerhalb der Kette der Nutzer-Zertifikate der einzelnen Ermächtigungskettenobjekte eine Zertifikatskettenprüfung möglich ist. Figur 6 zeigt ein Beispiel für Nutzdaten 600, die Bestandteil eines Datensatzes 106, 108 sein können. Die Nutzdaten sind im JSon Format spezifiziert. Es können jedoch auch beliebige andere Datenformate verwendet werden.

Figur 7 zwei dynamisch und unabhängig voneinander durch mehrere Nutzer über die erste und zweite Schnittstelle generierte Hierarchien, entlang welcher einerseits Zugriffsrechte und andererseits Eignerrechte über eine Kaskade von Nutzern vergeben wurden.

So repräsentiert die in Figur 7A abgebildete Hierarchie eine Kaskade von Zugriffsrechten auf ein oder mehrere von Nutzer H erstellte Datensätze. Das Zugriffs-Recht umfasst z.B. drei Zugriffsarten Lesen [R], Schreiben [W] und Indexzugriff [S] und kann mittels einem kombinierten oder drei unterschiedlichen Zugriffs-Zertifikaten auf andere Nutzer übertragen werden. Im vorliegenden Fall hat der Nutzer H, der einen Datensatz erstellte und mit den besagten Zugriffsrechtein (in der Nutzdaten- Datenbank) verknüpfte, die Zugriffrechte über drei Zugriffs-Zertifikate an die Nutzer B und P weitergegeben, wobei Nutzer P diese Zugriffsrechte auf die von H erstellten Datensätze wiederum an den Nutzer D weitergab. Somit bezieht Nutzer D seine Zugriffsrechte auf die Daten von H über den Mittelsmann„P". Die in Figur 7B abgebildete Hierarchie bildet eine Kaskade von Eigner-Rechten auf ein oder mehrere Nutzdaten-Datenbanken DB1 , DB2 ab. Der Geschäftsführer CEO hat z.B. Eigner-Zertifikate sowohl für Datenbank DB1 als auch DB2. Er überträgt diese Eigner-Rechte über eine Schnittstelle des Zugriffs-Verwaltungssystems der- art, dass Nutzer H ein Eigner-Zertifikat für die Datenbank DB1 und Nutzer A ein Eigner-Zertifikat für Datenbank DB2 zugewiesen wird. Nutzer H wiederum überträgt Eignerschafts-Rechte für die Datenbank DB1 an die Nutzer B, P und D. Jedem Nutzer, der ein Eigner-Zertifikat für z.B. DB1 zugewiesen bekommt, ist damit ermächtigt, eine Datenbankverbindung zu der entsprechenden Nutzdaten-Datenbank auf- zubauen und in dieser eigene Datensätze anzulegen. Im vorliegenden Fall hat der Nutzer D Eignerschaftsrechte für die Datenbank DB1 über den Nutzer H vom CEO erhalten. Die Weitergabe von Zugriffsrechten über Zugriffs-Zertifikate wie in 7A dargestellt und die Weitergabe von Eigner-Rechten über Eigner-Zertifikate wie in 7B dargestellt erfolgen entlang einer dynamisch zwischen Nutzern definierten Kette des Vertrauens und vorzugsweise unabhängig von einer vorgegebenen Hierarchie. Ein in der Unternehmenshierarchie in der Mitte angesiedelter Nutzer kann also sowohl seinem Vorgesetzten als auch seinen Untergebenen Zugriffsrechte und/oder Eigner-Rechte einräumen.

Figur 8 zeigt eine Sonderfunktionalität des Zugriffs-Verwaltungssystems zum Aus- tausch eines Nutzer-Zertifikats leitender Personen einer Organisation, insbesondere eines Geschäftsführers, gemäß einer weiteren Ausführungsform.

Die Nutzer-Zertifikate, die den Mitgliedern einer Organisation zugewiesen sind, werden vorzugsweise alle von der gleichen Zertifizierungsstelle ausgestellt und gehören der gleichen Public-Key-Infrastrukturen (PKI) an. Dies bedeutet, dass nach Ausfüh- rungsformen die Nutzer-Zertifikate alle Element eines Zertifikatskettenbaums sind, welcher von einem Root-Zertifikat der Zertifizierungsstelle ausgeht. Das Nutzer- Zertifikat des Geschäftsführers (oder einer anderen Person, die in der jeweiligen Organisation eine leitende Funktion einnimmt), im Folgenden auch CEO-Zertifikat genannt, wird nach Ausführungsformen der Erfindung dazu verwendet, um die Nut- zer-Zertifikate anderer Nutzer, die diesem„CEO" Nutzer in der Organisationshierarchie untergeordnet sind, zu signieren, sodass die Gesamtheit der in der Organisation verwendeten Nutzer-Zertifikate oder zumindest eine Teilmenge dieser Nutzer- Zertifikate einen zusammenhängenden, hierarchischen, per Zertifikatskettenprüfung prüfbaren Baum von sich beglaubigenden Zertifikaten darstellt. Ergänzend oder alternativ dazu können die Nutzerzertifikate auch zur Beglaubigung/Signierung anderer Zertifikate, z.B. der Zugriffs- oder Eigner- Zertifikate, die ein Nutzer für andere Nutzer ausstellt, verwendet werden. Beispielsweise könnte ein privater Signierschlüssel, der dem Nutzer-Zertifikat eines Nutzers zugeordnet ist, eine für einen anderen Nutzer ausgestellte Kopie eines Zugriffs-Zertifikats signieren, sodass diese Signatur als Nachweis dient, dass das entsprechende Zugriffsrecht mit Wissen und Wollen des vorigen Eigentümers auf einen anderen Nutzer übertragen wurde. In den so gebildeten Zertifikatshierarchien innerhalb einer Organisation hängt die Gültigkeitsprüfung der Zertifikate von der Gültigkeit des CEO-Nutzers ab, dessen Nutzer-Zertifikat in der so gebildeten Hierarchie ganz oben steht. Sofern dieses Zertifikat und sein privater Schlüssel gesperrt werden muss (z.B. nach einem Ausscheiden des CEO, wenn dieser beim neuen Geschäftsführer kein Vertrauen be- sitzt) muss ein neues CEO-Zertifikat einschließlich eines neuen privaten Schlüssels des Zertifikats ausgestellt und an die Teilnehmer der Organisation verteilt werden. Da damit alle von dem CEO-Zertifikat abgeleiteten Zertifikate invalide werden, ist diese Situation für das technische Funktionieren der IT Infrastruktur der Organisation unter Umständen sehr problematisch. Es kann dabei zu erheblichen Problemen im laufende Betrieb der Organisation kommen.

Um einen sicheren Austausch des Zertifikats des CEO einer Organisation einschließlich des dem CEO-Zertifikat zugeordneten privaten Schlüssels zu ermöglichen, wird das Nutzer-Zertifikat des CEOs (oder einer anderen Person an der Spitze der Organisationshierarchie) durch eine spezielle Routine des Zugriffs- Verwaltungssystems 100, die z.B. in einem I D-Management Modul 702 implementiert sein kann, erstellt. Hierzu wird der private Schlüssel des CEO-Nutzers nicht wie die privaten Schlüssel der anderen Nutzer in der ID-Datenbank gespeichert, sondern in zumindest zwei Teile A 704 und B 706 geteilt. Die beiden Schlüsselkomponenten werden von zwei vertrauenswürdigen Personen außerhalb der ID- Datenbank getrennt voneinander und sicher verwahrt. Um diesen privaten CEO Schlüssel samt zugehörigem Zertifikat auszutauschen, müssen beide Personen die jeweiligen Schlüsselkomponenten A und B zur Verfügung stellen um den privaten Schlüssel des CEOs zu rekonstruieren. Die spezielle Routine ermöglicht es im Beisein beider Schlüsselkomponenten einen neuen privaten Schlüssel für das Zertifikat zu erzeugen, der den bisherigen CEO Schlüssel ersetzt. Der neue private Schlüssel wird nun ebenfalls in zwei oder mehr neue Schlüsselkomponenten geteilt, die ge- trennt außerhalb der ID-Datenbank sicher verwahrt werden.

Figur 9 zeigt ein Flussdiagramm einer weiteren Ausführungsform eines erfindungsgemäßen Verfahrens zur Zugriffskontrolle auf Datensätze 106, 108, 1 10, 1 12, 1 14, 1 16 mehrerer Nutzdaten-Datenbanken eines Zugriffs-Verwaltungssystems 100. In einem ersten Schritt 902 des Verfahrens wird ein erstes Eigner-Zertifikats 128, 13), das einer Nutzdaten-Datenbank 102 zugeordnet ist, mit einem ersten Nutzer U1 verknüpft. Ein Eigner-Zertifikat ist ein Zertifikat, das einer oder mehreren Nutzdaten- Datenbanken zugeordnet ist und das jedem Nutzer, mit dem es verknüpft ist, das Recht gewährt, Datensätze in dieser Nutzdaten-Datenbank anzulegen. Die Verknüpfung kann z.B. manuell durch einen menschlichen Nutzer über eine GUI des Zugriffs-Verwaltungssystemsl OO vorgenommen werden, oder automatisch und implizit durch das Zugriffs-Verwaltungssystem 100, z.B. dann, wenn ein Nutzer eine neue Nutzdaten-Datenbank innerhalb des Systems 100 anlegt. In einem weiteren Schritt 904 wird eine erste Schnittstelle 142 bereitgestellt, die es dem ersten Nutzer U1 ermöglicht, ein zweites Eigner-Zertifikat für die Nutzdaten- Datenbank 102 zu erstellen und dieses mit einem zweiten Nutzer U2 zu verknüpfen um diesem zu ermöglichen, Datensätze in der Nutzdaten-Datenbank 102 anzulegen. Die erste Schnittstelle kann z.B. in Form einer GUI implementiert sein, welche Zugriff auf die ID-Datenbank hat und die von dem Nutzer erstellten Zertifikate und/oder die von einem entsprechend berechtigten Nutzer erstellte Zuweisung von Eigner-Zertifikaten an andere Nutzer in Form von Eigner- und Nutzer- Zertifikatszuweisungen in der ID-Datenbank zu speichert.

In einem weiteren Schritt 906 wird eine zweite Schnittstelle 144 bereitgestellt, die es dem zweiten Nutzer U2, der einen Datensatz 106, 108 in der Nutzdaten-Datenbank 102 erstellt hat, ermöglicht, mindestens ein Zugriffs-Zertifikat Z.Zert_U2[W], Z.Zert_U2[R], Z.Zert_U2[S], das eine Art des Datensatzzugriffs auf den von dem zweiten Nutzer erstellten Datensatz spezifiziert, zu erstellen und mit dem Nutzer- Zertifikat eines Nutzers, dem Zugriff auf diesen Datensatz gewährt werden soll, zu verknüpfen. Die zweite Schnittstelle kann z.B. ebenfalls in Form einer GUI oder eines Teils der oben erwähnten GUI implementiert sein, welche die von dem Nutzer erstellten Zertifikate und/oder die von einem entsprechend berechtigten Nutzer erstellte Zuweisung von Zugriffs-Zertifikaten an andere Nutzer in Form von Zugriffs- und Nutzer-Zertifikatszuweisungen in der ID-Datenbank zu speichert. Das Zugriffs-Verwaltungssystem prüft, in Antwort auf eine Zugriffsanfrage des ersten Nutzers bezüglich der in der Nutzdaten-Datenbank 102 gespeicherten Datensätze in Schritt 908, ob der erste Nutzers eine Zugriffsberechtigung auf einen von dem zweiten Nutzer angelegten Datensatz besitzt, ob dem ersten Nutzer also von dem zweiten Nutzer ein entsprechendes Zugriffs-Zertifikat für die von dem zweiten Nutzer erstellten Datensätze zugewiesen wurde. Die Nutzdaten-Datenbank gewährt dem ersten Nutzer den Zugriff auf die von dem zweiten Nutzer angelegte Datensätze nur dann, wenn dem ersten Nutzer in der ID-Datenbank sowohl ein Eigner- Zertifikat für die Nutzdaten-Datenbank 102 als auch ein Zugriffs-Zertifikat für den Zugriff auf den Datensatz zugeordnet ist.

Bezugsze ich en l iste

100 Zugriffs-Verwaltungssystem

102 Nutzdaten-Datenbank DB1

104 Nutzdaten-Datenbank DB2

105 öffentlicher Signaturprüfschlüssel

106 Datensatz

107 privater Signierschlüssel

108 Datensatz

110 Datensatz

111 Signatur

112 Datensatz

113 Signatur

114 Datensatz

115 Signatur

116 Datensatz

118 Delegierter-Parameter

122 Berechtigungsnachweis

123 Modul zur Zertifikatskettenprüfung

124 drittes Nutzer-Zertifikat

125 Log

126 Nutzer

128 Eigner-Zertifikat für Datenbank DB1

132 zweites Nutzer-Zertifikat

134 erstes Nutzer-Zertifikat

136 ID-Datenbank

137 Zugriffs-und Eignerschafts-Ermächtigungskettenobjekte

138 Zertifikatskette

139 Eignerschaftsermächtigungskettenobjekt

140 Zertifizierungsstelle

141 Eignerschaftsermächtigungskettenobjekt

142 erste Schnittstelle 143 Zugriffsermächtigungskettenobjekt

144 zweite Schnittstelle

202 Nutzer/Datenbank Nutzer

204 Nutzer-Zertifikate

206 Konnektivitäts-Berechtigungsnachweis für best. Nutzer und DB

208 Signatur eines privaten Schlüssels einer Zertifizierungsstelle

210 öffentlicher Signaturprüfschlüssel einer Zertifizierungsstelle

212 privater Signaturschlüssel der Zertifizierungsstelle

214 Trust-Center

216 IDs von Nutzdaten-Datenbanken

220 Berechtigungsnachweis für Nutzer U2

222 Berechtigungsnachweis für Nutzer U3

225 Zugriffs-Berechtigungsnachweis für best. Nutzer und Datensatz

226 Zugriffs-Berechtigungsnachweis für best. Nutzer und Datensatz 227 Konnektivitäts-Berechtigungsnachweis für best. Nutzer und DB

228 Fehlen des [S] Zugriffsrechts für Nutzer U2 bzgl. Daten, die von

Nutzer U1 erstellt wurden

229 Fehlen des [W] Zugriffsrechts für Nutzer U3 bzgl. Daten, die von

Nutzer U1 erstellt wurden

230 Fehlen des [R] Zugriffsrechts für Nutzer U3 bzgl. Daten, die von

Nutzer U1 erstellt wurden

232 [W] und [R] Zugriffsrechte des Nutzers U2 auf Daten, die von

Nutzer U1 erstellt wurden

234 Zugriffsrechte des Nutzers U3 auf Daten, die von Nutzer U1 und

U2 erstellt wurden

236 Signatur von Berechtigungsnachweis 225

237 Signatur von Berechtigungsnachweis 206

238 Signatur von Berechtigungsnachweis 226

239 Signatur von Berechtigungsnachweis 227

240 Signatur von Berechtigungsnachweis 242

242 Zugriffs-Berechtigungsnachweis für best. Nutzer und Datensatz

302 Geschäftsführer

304 Bereichsleiter Finanzen Leitung IT-Sicherheit

Leitung IT- Infrastruktur

Leitung IT-Applikation Entwicklung

Administrator

Administrator

Administrator

Nutzer H

-408 Zugriffs-Zertifikate für von H erstellte Daten Datensatz

Nutzer-Zertifikat für Nutzer H

Nutzer B

-428 Zugriffs-Zertifikate für von B erstellte Daten Nutzer-Zertifikat für Nutzer B

Nutzer P

-434 Zugriffs-Zertifikate für von P erstellte Daten Nutzer-Zertifikat für Nutzer P

Nutzer D

-444 Zugriffs-Zertifikate für von D erstellte Daten Nutzer-Zertifikat für Nutzer D

Nutzdaten

ID-Management-Modul

Schlüsselkomponente A

Schlüsselkomponente B

-908 Schritte