Technische Universität München - TUM · Berechtigungsvergabe." [PH05] In dieser Bachelorarbeit...

Technische Universität M ü n c h e n

Fakultät für Informatik

Bachelor – Arbeit

Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite Berechtigungsmanagement in einer Großbank

Bearbeiter: Sergius Schneider Aufgabensteller: Prof. Dr. Florian Matthes Betreuerin: Dipl.-Inf. Kathrin Lehmann Abgabedatum: 15.10.2005

Erklärung Ich versichere, dass ich diese Bachelor – Arbeit selbstständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe.

München, den 14.10.05

Sergius Schneider _______________

Bachelor - Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite

Berechtigungsmanagement in einer Großbank Zusammenfassung

Sergius Schneider 2005 1

Zusammenfassung

Diese Bachelorarbeit entstand im Rahmen der Studie "Zugriffssteuerung Neu" die von HVB Systems (Mitglied der Hypo- und Vereinsbank AG) durchgeführt wurde. Ziele der Studie waren:

• "Neukonzeption der Zugriffssteuerung unter Berücksichtigung der fachlichen und gesetzlichen Anforderungen,

• Schaffung einer tragfähigen, flexiblen und zukunftsorientierten technischen Lösung mit Verringerung der Prozesskomplexität bei der Berechtigungsvergabe,

• Eliminieren der bestehenden konzeptionellen und systemtechnischen Schwachstellen durch Verwendung von Standardschnittstellen,

• Bereitstellen von Basisfunktionalitäten einer "Zugriffsteuerung" zur anforderungsgerechten Umsetzung in den Anwendungssystemen." [PH05]

Diese Bachelorarbeit basiert auf den Ergebnissen der oben erwähnten Studie "Zugriffssteuerung Neu", ist aber auch als eine Erweiterung der Ergebnisse der Studie anzusehen. Es werden einige weiterführende Konzepte eingeführt, wie z.B. Konzept der Capabilities, XML-basierte Datenübertragung zwischen den nutzenden Anwendungen und der Zugriffssteuerung, XML-basierte Regelspeicherung, Zusammenführung der Zugriffsregeln zu Policies und Policies zu Policy Sets, Einführung mehrerer Regelauswertungsalgorithmen usw.

In diesem Dokument werden unter anderem die aktuellen Standards für die Gestaltung der Architektur der Zugriffssteuerung (ISO/IEC 10181-3), Anforderungen an die Querschnittskomponente „Zugriffssteuerung“, das Datenmodell einer (Beispiel-)Großbank, das Architekturmodell der Komponente „Zugriffssteuerung“ einer Großbank, mehrere Anwendungsfälle, die die Verwendung der Zugriffssteuerung verdeutlichen, einige Beispielregeln und Regelpolicies beschrieben.

Ziel des Dokumentes ist eine möglichst detaillierte und vielseitige Beschreibung der Querschnittskomponente „Zugriffssteuerung“ einer allgemeinen Großbank zu erstellen.

Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite

Berechtigungsmanagement in einer Großbank Zusammenfassung



Berechtigungsmanagement in einer Großbank Inhaltsverzeichnis


Inhaltsverzeichnis

Zusammenfassung ..................................................................................................... 1 Inhaltsverzeichnis ....................................................................................................... 3 Einführung .................................................................................................................. 5 1 Begriffsdefinitionen. ............................................................................................. 5

1.1 Authentifikation............................................................................................. 7 1.2 Autorisierung ................................................................................................ 8

1.2.1 Zugriffskontrolllisten – Access Control Lists (ACL)................................ 8 1.2.2 Zugriffsausweise. .................................................................................. 9 1.2.3 Chinese-Wall-Modell. .......................................................................... 10 1.2.4 Bell-La-Padula-Modell. ........................................................................ 11 1.2.5 Rollenbasiertes Modell ........................................................................ 12

1.3 Administration der Benutzer- und Berechtigungsinformationen ................. 15 2 Anforderungen an eine Autorisierungskomponente .......................................... 17

2.1 Rechteverwaltung....................................................................................... 17 2.2 Rechteprüfung............................................................................................ 18 2.3 Beweissicherung ........................................................................................ 19 2.4 Fehlerüberbrückung ................................................................................... 20 2.5 Leistungsanforderungen............................................................................. 20

3 Fachliches Lösungsmodell für eine Großbank .................................................. 23 3.1 Generisches Datenmodell einer Großbank (Meta-Modell) ......................... 23 3.2 Datenmodell einer Beispielgroßbank.......................................................... 26 3.3 Anforderungen an die Informationsbasis der Zugriffssteuerung................. 30 3.4 Definition der Zugriffsregeln für die Zugriffssteuerung................................ 30

3.4.1 Rollenhierarchie .................................................................................. 30 3.4.2 Zugriffsprinzipien................................................................................. 31 3.4.3 Anwendungsfälle................................................................................. 33 3.4.4 Zugriffsregeln ...................................................................................... 38

4 Architektur der Zugriffssteuerung ...................................................................... 43 4.1 Standard für das Architekturmodell der Zugriffssteuerung ......................... 44 4.2 Service-Oriented Architecture (SOA) ......................................................... 46 4.3 Services der Zugriffssteuerung .................................................................. 48 4.4 Architekturmodell........................................................................................ 49

4.4.1 Kernkomponente der Zugriffssteuerung.............................................. 50 4.4.1.1 Service Zugriffssteuerung ............................................................ 50 4.4.1.2 Service Informationsbereitstellung ............................................... 51

4.4.1.2.1 Komponente Informationsmanager........................................... 52 4.4.1.2.2 Nutzung des Service Informationsbereitstellung....................... 52

4.4.1.3 Service Zugriffsprüfung................................................................ 54 4.4.1.3.1 Komponente Zugriffsentscheidung ........................................... 55 4.4.1.3.2 Nutzung des Service Zugriffsprüfung........................................ 55

4.4.1.4 Service Datenzugriff..................................................................... 57 4.4.1.4.1 Komponente Datenmanager..................................................... 57 4.4.1.4.2 Komponente Informationsbasis ................................................ 57 4.4.1.4.3 Komponente Datenimport ......................................................... 58 4.4.1.4.4 Komponente Direktzugriff ......................................................... 58 4.4.1.4.5 Nutzung von Service Datenzugriff ............................................ 58

4.4.2 Komponente Datenpflege der Zugriffssteuerung................................. 59


Berechtigungsmanagement in einer Großbank Inhaltsverzeichnis


4.4.2.1 Komponente Policyverwaltung..................................................... 59 4.4.2.2 Komponente Regelverwaltung ..................................................... 59 4.4.2.3 Komponente Rechteverwaltung ................................................... 60 4.4.2.4 Komponente Datenintegration ..................................................... 60 4.4.2.5 Service Datenpflege..................................................................... 60

4.5 Use Cases.................................................................................................. 60 5 Zusammenfassung und Ausblick....................................................................... 63 Literatur .................................................................................................................... 65


Berechtigungsmanagement in einer Großbank Einführung


Einführung

Im Rahmen des Projektes "Zugriffssteuerung Neu" sollte ein neues Konzept für die Zugriffssteuerung bei der HVB entwickelt werden, weil:

1. Anforderungen auf Grund geänderter Geschäftsmodelle mit der aktuellen Zugriffssteuerung nicht, bzw. nur mit hohem Aufwand erfüllt werden können.

2. Aufbauorganisatorische Änderungen über die aktuelle Zugriffsteuerung nicht ausreichend nachvollzogen werden können.

3. Der administrative Aufwand zur Steuerung der notwendigen Prozesse der Zugriffssteuerung sehr hoch und fehleranfällig ist.

4. Anforderungen an Revision und Datenschutz an den Zugriffsschutz bei vielen fachlichen Prozessen nicht im vollen Umfang EDV-technisch umgesetzt werden können.

Zudem prägt die technische Umsetzung der Zugriffssteuerung fachliche Abläufe teilweise so, dass ein inkonsistentes Zusammenspiel der SW-Komponenten der Zugriffssteuerung die Fehlerrate erhöht. Die Fehleranalyse ist dadurch schwierig und zeitintensiv [PH05].

Hauptziel ist die "Neukonzeption der Zugriffssteuerung unter Berücksichtigung der fachlichen und der rechtlichen Anforderungen und die Schaffung einer tragfähigen, flexiblen und zukunftsorientierten technischen Lösung mit Verringerung der Prozesskomplexität bei der Berechtigungsvergabe." [PH05]

In dieser Bachelorarbeit werden die Lösungen der oben erwähnten Probleme vorgestellt, allerdings nicht gebunden an die Situation der Hypo- und Vereinsbank AG (im folgenden HVB genannt), sondern im Hinblick auf eine verallgemeinerte "Großbank". Die Ergebnisse der Studie "Zugriffssteuerung Neu" werden durch einige weitere Konzepte erweitert.

1 Begriffsdefinitionen.

In diesem Kapitel werden einige Begriffe und Definitionen eingeführt, die bei der Modellierung eines IT-Systems eine grundlegende Rolle spielen. Zunächst wird der Begriff IT-System präzisiert.

„Ein IT-System ist ein geschlossenes oder offenes, dynamisches technisches System mit der Fähigkeit zur Speicherung und Verarbeitung von Informationen“ [ECK05]

Bei der Modellierung eines IT- Systems soll ein besonderer Wert auf die Sicherheit des Systems gelegt werden. Der Begriff IT-Sicherheit wird in vier folgende Bereiche unterteilt: Funktionssicherheit, Informationssicherheit, Datensicherheit und Datenschutz.

„Unter Funktionssicherheit (engl. safety) eines Systems verstehen wir die Eigenschaft, dass die realisierte Ist-Funktionalität der Komponenten mit der spezifizierten Soll-Funktionalität übereinstimmt. Ein funktionssicheres System nimmt keine funktional unzulässigen Zustände an. Anders formuliert verstehen wir unter Funktionssicherheit eines Systems, dass es unter allen (normalen) Betriebsbedingungen funktioniert.“ [ECK05]

„Die Informationssicherheit (engl. security) ist die Eigenschaft eines funktionssicheren Systems, nur solche Systemzustände anzunehmen, die zu keiner unautorisierten Informationsveränderung oder –gewinnung führen“[ECK05]

„Die Datensicherheit (engl. protection) ist die Eigenschaft eines funktionssicheren Systems, nur solche Systemzustände anzunehmen, die zu keinem unautorisierten Zugriff auf Systemressourcen und insbesondere auf Daten führen“[ECK05]


Berechtigungsmanagement in einer Großbank Begriffsdefinitionen.

„Unter dem Begriff Datenschutz im engeren Sinn (engl. privacy), … versteht man die Fähigkeit einer natürlichen Person, die Weitergabe von Informationen, die sie persönlich betreffen, zu kontrollieren.“[ECK05]

Bei der Definition der Sicherheitsanforderungen an ein IT-System muss immer von den Bedrohungen, denen dieses System ausgesetzt ist, ausgegangen werden. Hauptbedrohungen, denen ein IT-System ausgesetzt ist, sind:

- unbefugter Informationsverlust (Verlust der Vertraulichkeit) - unbefugte Modifikation von Informationen (Verlust der Integrität) - unbefugte Beeinträchtigung der Funktionalität (Verlust der Verfügbarkeit)

Diese Bedrohungen können für verschiedene IT-Systeme unterschiedlich relevant sein. Für manche Systeme (z.B. öffentliche Datenbanken) stellt der unbefugte Informationsgewinn keine, oder nur eine sehr gering gewichtete Bedrohung dar, während dies für andere Systeme (z.B. militärische Führungsinformationssysteme oder Banksysteme) eine extrem große Bedrohung darstellt.

Jedes betriebliche Informationssystem (IT-System) sollte eine gekapselte Berechtigungskomponente enthalten. In der Tat ist die Implementierung von Anforderungen an die Sicherheit eines Informationssystems häufig über jede Software- und Hardwarekomponenten und Programme verteilt, so dass es keine einheitliche Sicht auf die realisierte Berechtigungsstruktur besteht. Da sich die Berechtigungen über das gesamte System erstrecken, handelt es sich bei einer Komponente, die Zugriffsberechtigung realisiert um eine Querschnittskomponente.

Ziel einer Berechtigungskomponente besteht im Schutz von Ressourcen. Diese Schutzfunktionalität kann in drei Teile aufgeteilt werden:

- Authentifikation - Autorisierung - Administration der Benutzer- und Berechtigungsinformationen

Mithilfe der nachfolgenden Abbildung (Abbildung 1) kann man sich die Situation besser veranschaulichen. Ein Informationssystem sei hier als geschlossenes System dargestellt (weißer Kasten in der Mitte der Abbildung).

Prozesse

Daten

Authentifikation

Autorisierung

System

Abbildung 1. Berechtigungskomponenten eines IT-Systems [ECK05]. Ziel, welches bei der Authentifikation verfolgt wird, bei einem Zugriff von außen die Identität des Benutzers, der auf das System zugreift festzustellen. Die Verfahren, die für die Authentifikation eingesetzt werden können, werden in dem Kapitel 1.1 kurz vorgestellt.

Falls nach der Authentifikation dem Benutzer den Zugriff auf das System erlaubt wird, kann er im Weiteren mehrere Programme, bzw. Programmfunktionen (allg. Prozesse) innerhalb des Systems ausführen. Dabei wird von der Autorisierungskomponente geprüft, ob der Benutzer für die Ausführung dieser Prozesse autorisiert ist.





Sobald im Laufe der Programmausführung einer der Prozesse Zugriff auf irgendwelche Ressourcen (Dateien, Datenbanktabellen, bzw. –einträge) des Systems benötigt, wird ebenfalls von der Autorisierungskomponente überprüft, ob dieser bestimmte Benutzer für den Zugriff auf diese bestimmte Ressource innerhalb des Systems berechtigt ist (Begriff: Zugriffskontrolle). Dabei ist es auch wichtig festzustellen, welche Rechte der Benutzer bezüglich dieser Ressource hat. Mögliche Rechte sind: lesen, schreiben, neu anlegen, löschen, freigeben, usw. Es existieren mehrere Sicherheitsmodelle für die Modellierung der Zugriffskontrolle, einige davon werden in dem Kapitel 1.2 vorgestellt.

Außerdem ist es wichtig, die Informationen, die für die Authentifikation und Autorisierung notwendig sind, zu verwalten. Diese Informationen werden Informationsbasis genannt. Unter dem Begriff Informationsbasis sind folgende Daten gemeint:

- Die Informationen über Benutzer, Ressourcen und ihre Beziehungen untereinander, die für die Autorisierung und Authentifikation relevant sind

- Die Regeln der Zugriffssteuerung (bzw. Zugriffskontrolle) - Andere Daten, wie z.B. Kontextinformationen

Die Verwaltung dieser Daten soll entsprechend gestaltet werden, so dass es z.B. keine Konflikte zwischen einzelnen Regeln gibt, oder dass die für die Zugriffsentscheidung notwendigen Beziehungen und Daten jederzeit zur Verfügung stehen und aktuell sind (s. Kapitel 1.3).

1.1 Authentifikation

„Unter der Authentizität eines Objekts bzw. Subjekts (engl. authenticity) verstehen wir die Echtheit und Glaubwürdigkeit des Objekts bzw. Subjekts, die anhand einer eindeutigen Identität und charakteristischen Eigenschaften überprüfbar ist.“ [ECK05].

„Die Authentizität eines Subjekts, bzw. Objekts wird durch Maßnahmen zur Authentifikation (engl. authentication) überprüft. Dazu muss nachgewiesen werden, dass eine behauptete Identität eines Objektes oder Subjekts mit dessen charakteristischen Eigenschaften übereinstimmt.“ [ECK05].

Ziel der Authentifikation ist also eine Überprüfung der tatsächlichen Identität des Benutzers. Dafür sollen die Anmeldeinformationen des Benutzers mit den im System gespeicherten verglichen werden. Falls die Anmeldeinformationen übereinstimmen, wird der Benutzer authentisiert, andernfalls nicht. Es existieren mehrere Verfahren, für die Realisierung der Authentifikation:

- Passwort-Verfahren. Der Benutzer authentisiert sich beim System, indem er die Kenntnis eines mit dem System vereinbarten Geheimnisses nachweist. Dabei können folgende Verfahren eingesetzt werden:

- Symmetrisches Verfahren. In diesem Fall verwaltet das System die Authentisierungsinformationen in einer speziellen Tabelle, wo jedem bekannten Benutzer ein Passwort zugeordnet wird. Bei einer Authentifikationsanfrage überprüft das System anhand der vom Benutzer übergebenen Informationen (Benutzername und Passwort), ob ein entsprechender Eintrag in der Passworttabelle existiert. Falls ein Eintrag vorhanden ist und die Informationen übereinstimmen, wird der Benutzer authentifiziert.

- Einmal-Passworte. Es wird ein Verfahren zur automatischen Erzeugung der Einmal-Passworte auf der Client-Seite verwendet (z.B. S/Key – Verfahren). Solche Passworte werden nur einmalig zur Authentifikation verwendet, was einen Maskierungsangriff nur mit Kenntnis des letzten Einmal-Passwortes unmöglich macht (im Gegensatz zum symmetrischen Verfahren).




- Biometrie-Verfahren. Bei diesem Verfahren werden personenbezogene biometrische Merkmale, wie Tippverhalten, Fingerabdruck, Iris-Scan usw. zur Authentifikation eines Benutzers verwendet.

Weitere Authentifikationsverfahren sind z.B. Challenge-Response-Verfahren, Zero-Knowledge-Verfahren oder auch Authentifikation durch Zertifikate und Signaturen. (Weitere Informationen zu oben erwähnten Authentifikationsverfahren s. [ECK05]).

1.2 Autorisierung

Bei der Autorisierung handelt es sich um eine Überprüfung der Zugriffsrechten auf Daten und Funktionalität eines Systems. Es wird zwischen einer statischen (vom aktuellen Systemzustand unabhängigen) Autorisierung und einer dynamischen (vom Systemzustand abhängigen) Autorisierung unterschieden:

- Statische Autorisierung. Autorisierung für die Ausführung einer bestimmten Funktionalität (z.B. Kontoattribute eines Kontos ändern).

- Dynamische Autorisierung. Autorisierung für die Ausführung der nach der statischen Autorisierung erlaubten Funktionalität auf bestimmten Informationsobjekten. Ein Benutzer darf z.B. Kontoattribute bestimmter Konten nicht ändern, falls er für den Zugriff auf diese konkrete Konten nicht berechtigt ist (z.B. weil die Konten einer anderen Filiale zugeordnet sind).

Bemerkung. Ein Benutzer kann zwar für die Ausführung einer bestimmten Funktionalität berechtigt werden (statische Autorisierung), es kann ihm aber verweigert werden, diese Funktionalität auf einem bestimmten Informationsobjekt auszuführen (dynamische Autorisierung).

In dieser Bachelorarbeit wird die Fokussierung auf die dynamische Autorisierung gelegt (auch Zugriffssteuerung oder Zugriffskontrolle genannt), deswegen wird im gesamten Dokument der Begriff „Zugriffsteuerung“ (bzw. Zugriffskontrolle) mit dem Begriff „Dynamische Autorisierung“ gleichgesetzt.

Als Zugriffssteuerung (Zugriffskontrolle) wird das Autorisieren von Benutzern für den Zugriff auf geschützte Objekte im System bezeichnet. Bei der Modellierung der Zugriffssteuerung können mehrere Konzepte eingesetzt werden, die am stärksten verbreitete Konzepte sind:

• Zugriffskontrolllisten (Access Control Lists - ACL) • Zugriffsausweise (Capabilities) • Chinese-Wall-Modell (auch als Brewer-Nash Modell bekannt) • Bell-La-Padula-Modell • Rollenbasierte Modelle

Im Folgenden werden diese Verfahren einzeln vorgestellt und auf Vor- Nachteile und ihre Eignung für das Einsetzen für die Modellierung der Zugriffssteuerung einer Großbank untersucht.

1.2.1 Zugriffskontrolllisten – Access Control Lists (ACL).

Objekte Subjekte

(Benutzer) Datei 1 Datei 2 … …

Bill owner, r, w, x -

Joe r, x w

Anne - owner, r, w, x

… Abbildung 2. Zugriffsmatrix [ECK05].




Eine Zugriffskontrollliste ist „… eine listenartig organisierte Datenstruktur, die einem zu schützenden Objekt zugeordnet wird“ [ECK05]. Zugriffskontrolllisten realisieren eine objektbezogene Sichtweise auf die Zugriffsmatrix (s. Abbildung 2).

Dabei ist eine Zugriffsmatrix eine zweidimensionale Matrix M, deren Spalten durch die Menge der Objekte O und Zeilen durch die Menge der Subjekte (Benutzer) S definiert werden (vgl. Definition in [ECK05]). Ein Eintrag in der Zugriffsmatrix Mt(s, o) = {r1, r2, …, rn} beschreibt die Rechte die ein Subjekt s aus der Menge S der Subjekte auf ein Objekt o aus der Menge O der Objekte zum Zeitpunkt t besitzt.

Ein Listeneintrag „Bill, owner, r, w, x“ (s. Abbildung 2) besagt, dass Benutzer Bill Besitzer der Datei 1 ist und Lese-, Schreib- und Ausführungsrechte für diese Datei besitzt.

Für jedes zu schützende Objekt (z.B. Datei, Konto, Vertrag usw.) wird in einer Zugriffskontrollliste definiert, welchen Subjekten (Benutzer oder Benutzergruppen) welche Rechte an dem Objekt eingeräumt werden.

Ein großer Vorteil der Zugriffskontrolllisten ist die einfache Verwaltung der Zugriffsrechte und einfache und effiziente Realisierung einer Rechterücknahme.

Der Nachteil ist eine schlechte Skalierbarkeit, weswegen die Zugriffskontrolllisten für die Modellierung der Zugriffssteuerung einer Bank eher ungeeignet sind.

1.2.2 Zugriffsausweise. Ein weiteres Konzept, das für die Modellierung der Zugriffssteuerung verwendet werden kann ist das Konzept der Zugriffsausweise [ECK05].

Objekte Subjekte

(Benutzer) Datei 1 Datei 2 … …

Bill owner, r, w, x -

Joe r, x W

Anne - owner, r, w, x

… Abbildung 3. Zugriffsmatrix [ECK05].

Im Gegensatz zu den Zugriffskontrolllisten realisiert das Konzept der Zugriffsausweise eine subjektbezogene Sichtweise auf die Zugriffsmatrix (s. Abbildung 3).

Zugriffsausweise (Capabilities) sind unverfälschbare (in der Regel verschlüsselte) Tickets, die ihren Besitzer zum Zugriff auf das in dem Ticket benannte Objekt berechtigen. In dem Zugriffsausweis sind Objektnamen und die Berechtigungen, die dem Besitzer des Ausweises an dem Objekt eingeräumt werden enthalten.

Ein Benutzer bekommt Zugriff auf ein Informationsobjekt nur, falls er einen gültigen (Zugriffsausweise haben gewisse Lebensdauer) Zugriffsausweis vorweisen kann.

Klare Vorteile des Konzepts der Zugriffsausweise sind Flexibilität, Effizienz, dezentrale Verwaltung der Zugriffsausweise und die Möglichkeit der Delegation der Zugriffsausweise (Ausweisweitergabe).

Die Einsetzung der Zugriffsausweise ermöglicht die Optimierung der Zugriffskontrolle, denn in diesem Fall braucht die Berechtigungsprüfung nur bei der ersten Berechtigungsanfrage durchgeführt werden. Bei den weiteren Anfragen wird nur die Gültigkeit des Zugriffsausweises geprüft, wodurch mehrere Datenbankzugriffe, die für die Feststellung der Zugriffsberechtigung notwendig sind, überflüssig werden.

Ein Nachteil dagegen, ist z.B. das Rechterücknahmeproblem. Da die Zugriffsausweise dezentral verwaltet werden (in der Regel werden sie im Laufe einer Sitzung lokal beim Client



gespeichert), kann es vorkommen, dass ein Benutzer einen gültigen Ausweis besitzt, obwohl ihm inzwischen das Zugriffsrecht entzogen wurde. Dieses Problem lässt sich durch die Begrenzung der Gültigkeit der Capabilities minimieren. Eine weitere Lösung wäre das Anlegen einer Liste ungültiger Zugriffsausweise, die von der Zugriffssteuerungskomponente verwaltet wird. Allerdings wird eine solche Liste bei einer großen Anzahl von Subjekten (Benutzern) ziemlich groß, was zu Performanzproblemen bei der Suche der entsprechenden Einträge in der Liste und bei der Listenverwaltung führen kann.

1.2.3 Chinese-Wall-Modell. Das Chinese-Wall Modell [BRNA89], [ECK05], auch als Brewer-Nash Modell bekannt, „…wurde entwickelt, um die unzulässige Ausnutzung von Insiderwissen bei der Abwicklung von Bank- oder Börsentransaktionen oder bei der Beratung unterschiedlichen Unternehmen zu verhindern. … Die grundlegende Idee des Chinese-Wall-Modells basiert darauf, dass die zukünftigen Zugriffsmöglichkeiten eines Subjekts durch die Zugriffe, die es in der Vergangenheit bereits durchgeführt hat, beschränkt werden. Das heißt, dass die Zulässigkeit von Zugriffen auch von der Zugriffshistorie abhängt.“ [ECK05].

Im Chinese-Wall-Modell werden explizit drei universelle Rechte festgelegt: read, write und execute. Die zu schützenden Objekte des Systems werden in Form eines Baums strukturiert. Die Blätter des Baums sind Objekte die zu den Unternehmen in der zweiten Ebene des Baums gehören. Konkurrierende Unternehmen, werden in Interessenkonfliktklassen unterteilt und bilden die dritte Ebene des Baums.

Grundprinzipien und Aufbau des Chinese-Wall-Modells lassen sich am besten mithilfe eines Beispiels (vgl. [ECK05]) erklären.

Gegeben sind zwei Interessenkonfliktklassen Ölgesellschaften und Banken. Als Unternehmen werden die Firmen Aral, Schell, Deutsche Bank und Dresdner Bank betrachtet. Das Objekt o1 gehört zur Firma Aral und liegt in der Interessenkonfliktklasse aller Ölgesellschaften in der auch das zu Firma Shell gehörige Objekt o3 liegt. Das Objekt o3 gehört Deutscher Bank und liegt in der Interessenkonfliktklasse der Banken.

Ölgesellschaft Bank Interessenkonfliktklassen

Aral Shell Deutsche Bank Dresdner Bank Unternehmen

Objekteo1 o3 o2 Abbildung 4. Objektbaum im Chinese-Wall-Modell [ECK05].

Im Chinese-Wall-Modell werden zwei Grundregeln definiert, die der Zugriff auf Objekte regeln: Leseregel und Schreibregel. Beide Regeln werden formal bewiesen (s. [ECK05]).

Leseregel besagt, dass nach einem Zugriff mit Rechten read und execute auf ein Objekt eines Unternehmens, es dem Subjekt nicht mehr möglich ist auf weitere Objekte anderen Unternehmen der gleichen Interessenkonfliktklasse zuzugreifen. D.h. konkret, dass nachdem der Benutzer s auf das Objekt o1 der Firma Aral zugegriffen hat, darf er nicht mehr auf Objekte der Firma Schell zugreifen (s. Abbildung 4). Allerdings kann er weiterhin auf Objekte der Interessenkonfliktklasse Bank zugreifen.

Schreibregel besagt, dass ein Schreibzugriff für einen Subjekt s auf ein Objekt o nur dann möglich ist, falls s bisher Lesezugriffe nur auf die Objekte des gleichen Unternehmens hatte.





Schreibregel verhindert somit den Informationsfluss zwischen den Unternehmen die einer Interessenkonfliktklasse gehören.

Chinese-Wall-Modell definiert ein Berechtigungsmodell, welches einem Mitarbeiter (Spezialisten) mit umfassenden Brachenkenntnissen die Einsetzung dieser Kenntnisse nur bei einer konkreten Firma (bzw. nur bei einem konkreten Kunden) erlaubt. Es ist, allerdings, in einer Bank nicht möglich, denn in einer Bank existieren mehrere (hunderte, tausende) Kunden und Partnerfirmen und ein Mitarbeiter (Berater) der Bank soll seine Kenntnisse Firmen- und Kundenübergreifend anwenden können, deswegen ist das Chinese-Wall-Modell für die Modellierung der Autorisierungskomponente einer Großbank eher ungeeignet.

1.2.4 Bell-La-Padula-Modell. Das Bell-La-Padula-Modell wurde 1973 von David E. Bell und Leonard J. La Padula entwickelt. Es ist ein mathematisches Modell einer mehrschichtigen Sicherheitspolitik (vgl. [BLP76]). Das Modell definiert eine geordnete Menge von Sicherheitsklassen (SK) wobei jedes Informationsobjekt und jeder Benutzer (Subjekt) einer Sicherheitsklasse zugeordnet wird. Außerdem wird eine Menge universellen Rechten vorgeschrieben (read, append, write, execute, control).

Zugriff auf ein Informationsobjekt wird durch zwei Regeln, no-read-up und no-write-down beschränkt.

- Die No-read-up Regel besagt, dass ein Lese- oder Ausführungszugriff auf ein Objekt nur dann zulässig ist, wenn Benutzer-SK >= Objekt-SK gilt. D.h. ein Benutzer dem z.B. eine niedrigere Sicherheitsklasse nach der Sicherheitsklassenhierarchie zugeordnet wird, darf nicht lesend auf die Informationsobjekte höheren Sicherheitsklassen zugreifen (Beispiel s. unten). Hiermit wird verhindert, dass vertrauliche Information für nicht vertrauenswürdige Benutzer zugängig wird.

- Die No-write-down Regel besagt, dass es ein Anfügen eines neuen Informationsobjekts nur dann möglich ist, wenn Objekt-SK >= Benutzer-SK gilt, und ein Schreibzugriff ist nur dann möglich, falls Objekt-SK = Benutzer-SK. D.h. ein Benutzer dem z.B. eine höhere Sicherheitsklasse zugeordnet ist, darf nicht schreibend auf die Informationsobjekte einer niedrigren Sicherheitsklasse zugreifen (Beispiel s. unten). Hiermit wird verhindert, dass ein Benutzer, der über vertrauliche Informationen verfügt, diese in nicht vertrauenswürdigen Informationsobjekten speichert.

In der Abbildung 5 werden die zulässigen Informationsflüsse für ein System mit linear geordneten Sicherheitsklassen unklassifiziert ≤ vertraulich ≤ geheim ≤ streng geheim veranschaulicht [ECK05]. Wie aus der Abbildung ersichtlich, verläuft der Informationsfluss von unten nach oben (unklassifiziert vertraulich geheim streng geheim). Umgekehrter Informationsflussverlauf wird allerdings durch die Regeln no-read-up und no-write-down verboten.

Subjekt (Benutzer) S2 darf z.B. auf dem Informationsobjekt D4 keine read-write Operation (unzulässiger Informationsfluss vertraulich unklassifiziert), und auf dem Informationsobjekt D3 keine read Operation (unzulässiger Informationsfluss vertraulich unklassifiziert) durchführen, denn dass würde die no-read-up Regel verletzten. Dem Subjekt S1 ist durch die no-write-down Regel verboten mit Operationen append und read-write auf Informationsobjekt D4 zugreifen (unzulässiger Informationsfluss geheim vertraulich). Allerdings ist es dem Subjekt S2 erlaubt mit beliebigen Operationen auf das Informationsobjekt D5 zuzugreifen (zulässiger Informationsfluss unklassifiziert unklassifiziert), genauso wie ein neues Informationsobjekt D2 in der Sicherheitsklasse geheim anzulegen (zulässiger Informationsfluss unklassifiziert geheim).



Legende

unzulässiger Zugriff

zulassiger Zugriff

klassifiziertes Subjekt

klassifiziertes Objekt

D1

D2

D3D4

D5

S1

S2

zulässiger Informationsfluß

append

read-write

read, execute

append, read-write

read-writeread

append

streng geheim

geheim

vertraulich

unklassifiziert

Abbildung 5. Zulässige Informationsflüsse im Bell-La-Padula-Modell [ECK05]. Ein großer Vorteil des Bell-La-Padula-Modells ist die Tatsache, dass es ein vollständig formalisiertes mathematisches Modell ist. Ein Nachteil dagegen ist, z.B. das Problem vom „blindem Schreiben“, denn es ist möglich, dass ein Benutzer schreibenden Zugriff auf ein höher eingestuftes Objekt bekommt, darf aber anschließend die von ihm durchgeführte Änderungen nicht lesen, denn sonst die no-read-up Regel verletzt wird (s. Abbildung 5: Subjekt S2 legt Inforationsobjekt D2 an, hat aber anschließend kein Lesezugriff auf D2). Ein weiteres Problem stellen in dem Modell festgelegte (vorgeschriebene) Zugriffsrechte und einfache Zugriffsbeschränkungsregeln dar, weswegen das Modell eher ungeeignet für die Modellierung der Zugriffssteuerung einer Großbank ist.

1.2.5 Rollenbasiertes Modell Als Basis für Zugriffskontrollmodell eignet sich hervorragend ein rollenbasiertes Zugriffsmodell - role-based access control (RBAC) [ECK05], [NIST05], [FESA01].

Rollenbasierte Zugriffskontrollmodelle wurden 1996 von R.S.Sandhu eingeführt. Die Berechtigungen zur Nutzung geschützter Komponenten werden im RBAC-Modell direkt mit den Rollen verknüpft. Eine Rolle beschreibt eine Aufgabe und definiert die Berechtigungen der Rollenmitglieder. In dem Sicherheitsmodell wird festgelegt, welche Benutzer welche Aufgaben durchführen, also in welchen Rollen agieren dürfen. Während einer Sitzung kann ein Benutzer mehrere Rollen annehmen und bekommt die Berechtigungen der entsprechenden Rollen zugeordnet (s. Abbildung 6).




Benutzer Rollen Zugriffsrechte

Sitzungen mit aktiven Rollen

Zugriffsrecht

Rolle

BenutzerRollenmitgliedschaft

Berechtigungsvergabe

Sitzungen

Abbildung 6. Rollenbasiertes Zugriffskontrollmodell [ECK05]. In manchen Unternehmen werden Aufgaben und Zuständigkeiten innerhalb von Abteilungen oder Projekten häufig hierarchisch geordnet. Um solche Situationen auch im rollenbasierten Zugriffskontrollmodell zu erfassen, wird das RBAC – Modell um eine partielle Ordnung ≤ auf den Rollen erweitert (hierarchisches RBAC-Modell s. [NIST05]). Dadurch lassen sich auch hierarchische Berechtigungsstrukturen durch RBAC – Modelle abbilden und die Rollenvererbung realisieren [ECK05], [NIST05].

Beispiel.

Zweigstellenleiter

Kassenprüfer

Kassierer Kundenbetreuer

Angestellter

Rolle

R1 R2, R2 besitztauch R1 Rechte

Abbildung 7. Rollenvererbung [ECK05].

Wie in der Abbildung 7 dargestellt, erbt ein Kassenprüfer einer Bank die Rechte eines Angestellten, Kassierer und Kundenbetreuer zusätzlich zu den ihm zugeordneten Rechten, hat aber weniger Rechte als ein Zweigstellenleiter, dem in seiner Organisationseinheit (Zweigstelle) die Ausübung nahezu aller möglichen Rechten erlaubt ist. (Z.B. weil ein Leiter




einer Organisationseinheit stets die Arbeit (Ergebnisse), bzw. Mitarbeiter seiner Organisationseinheit überwachen (kontrollieren) darf.)

Formal ausgerückt: Seien R1 und R2 Rollen mit R1 ≤ R2 (gemäß der Rollenhierarchie), dann besitzen die Mitglieder der Rolle R2 zumindest auch alle Rechte der Mitglieder der Rolle R1.

In der Abbildung 8 wird das Konzept des hierarchischen rollenbasierten Zugriffskontrollmodells in einem UML - Klassendiagramm dargestellt [BASIN02].

User AtomicAction CompositeAction

*

Permission

**

*

Subject*

*

Group

*

Role*

*

*

1..*

AuthorizatonConstraint

0..1

Action

*

*

*

1..*

0..1

Ressource

* 0..1

1UAPA

AA RA

CAUserHierarchy

RoleHierarchy

ActionHierarchy

ResourceDerivationActionDerivation

UserUser AtomicActionAtomicAction CompositeAction

*

CompositeActionCompositeActionCompositeAction

*

Permission

**

*

PermissionPermission

**

*

Subject*

*

SubjectSubjectSubject*

*

Group

*

GroupGroupGroup

*

Role*

*

*

1..*RoleRoleRole*

*

*

1..*

AuthorizatonConstraint

0..1

AuthorizatonConstraintAuthorizatonConstraint

0..1

Action

*

*

*

1..*

0..1

ActionActionActionAction

*

*

*

1..*

0..1

Ressource

* 0..1

1 Ressource

* 0..1

RessourceRessourceRessource

* 0..1

1UAPA

AA RA

CAUserHierarchy

RoleHierarchy

ActionHierarchy

ResourceDerivationActionDerivation

Abbildung 8. Hierarchisches rollenbasiertes Zugriffskontrollmodell. Ein Subject kann entweder ein Benutzer (User) oder eine Benutzergruppe (Group) sein, wobei über UserHierarchy die Darstellung der Subjekthierarchie ermöglicht wird. Einem Subject, sei es ein einzelner Benutzer oder eine Benutzergruppe, wird über UA (UserAssignment) eine oder mehrere Rollen zugeordnet. Über die Relation RoleHierarchy wird die Rollenhierarchie definiert. Jeder Rolle wird über PA (Permission Assignment) eine Menge an Berechtigungen (Permission) zugeordnet. Über AA (Action Assignment) passiert die Zuordnung von Operationen (Action) zu Berechtigungen. RA (RessourceAssignment) ermöglicht die Zuordnung von durchführbaren Operationen zu den Ressourcen.

Oft erweist es sich in einem RBAC-Modell als notwendig eine statische Beschränkung der Rollenmitgliedschaft zu definieren. Es ist manchmal sinnvoll, einem Benutzer die gleichzeitige Mitgliedschaft in zwei sich wechselseitig ausschließenden Rollen zu verbieten. Ein Beispiel für solche Situation wären die Rollen eines Kassenprüfers und Kassierers einer Bankfiliale, die sich gegenseitig ausschließen, denn es nicht sinnvoll ist dass ein Kassierer gleichzeitig auch sein eigener Kasseprüfer ist. Solche Situationen können durch Einsatz vom Konzept der statischen Aufgabentrennung [ECK05], [NIST05], [FESA01] verhindert.

Statische Aufgabentrennungen werden unabhängig von aktiven Sitzungen festgelegt. Es reicht manchmal aber auch, wenn die gleichzeitige Aktivität in unterschiedlichen Rollen während einer Sitzung nicht erlaubt wird (dynamische Aufgabentrennung [ECK05], [NIST05], [FESA01]).

Ein Systembenutzer darf nur die Rechte bekommen, die er zur Erfüllung seiner betrieblichen Aufgaben benötigt. Dieses Prinzip (Prinzip der geringsten Berechtigung, auch Need-to-Know Prinzip genannt) kann bei der Rollenvererbung verletzt werden, denn ein Benutzer erhält unter Umständen mehr Rechte, als er zur Erfüllung seiner Aufgaben benötigt, weil diese Rechte über die Rollenvererbung von einer anderen Rolle vererbt wurden. Deswegen sollen solche Fälle bei der Definition der Rollenhierarchie berücksichtigt und vermieden werden.

Hierarchisches RBAC-Modell erweist sich wegen seiner guten Skalierbarkeit als ein geeignetes Modell für die Zugriffssteuerung einer Bank. Die Möglichkeit der Modellierung der Rollenhierarchie lässt sich unmittelbar auf existierende Organisations- und Verwaltungsstrukturen einer Bank übertragen.





1.3 Administration der Benutzer- und Berechtigungsinformationen

Die Berechtigungsinformationen werden von dem Systemadministrator gepflegt und verwaltet. Zu den Aufgaben eines Administrators gehören unter anderem das Anlegen und die Verwaltung von Benutzern, sowie die Definition und Verwaltung von Berechtigungen.

Wichtige Anforderungen an die Administration der Benutzer- und Berechtigungsinformationen sind:

- Übersichtlichkeit der Benutzerinformationen, Benutzerhierarchie und Berechtigungsinformationen

- Einfache Wartbarkeit der Benutzer und Berechtigungsinformationen (z.B. durch Einsatz verschiedenen Tools mit geeigneten, übersichtlichen Eingabemasken und Dialogen).

- Es soll eine klare Definition des Prozesses für die Berechtigungsvergabe, bzw. –änderung existieren. Die Umsetzung der Berechtigungsvergabe und –änderung soll vom Administrator kontinuierlich überwacht werden.

- Erfüllung des „Prinzips der minimalen Rechte“ (Need-to-Know-Prinzip) soll garantiert werden. Nach diesem Prinzip darf jeder Mitarbeiter nur Zugriff aus die Funktionen / Daten haben, die er zur Ausübung seiner Tätigkeiten benötigt.

- Besonders zu berücksichtigen ist die Vollständigkeit der Berechtigungsverwaltung. Alle Subjekte und Objekte, die nach den Sicherheitsanforderungen der Berechtigungsverwaltung unterliegen sollen, sollen auch wirklich erfasst werden.

Im Weiteren besteht die Aufgabe eines Administrators (bzw. eines Sicherheitsverantwortlichen) in der Überwachung während des laufenden Betriebs ob die verwendeten Sicherheitsmaßnahmen ausreichend sind und eingehalten werden. Dafür ist durch Einsatz verschiedenen Tools ein Monitoring und Kontrolle der Systemaktivitäten notwendig um schnell auf neue Bedrohungen und Sicherheitslucken reagieren zu können [ECK05].


Berechtigungsmanagement in einer Großbank Anforderungen an eine Autorisierungskomponente


2 Anforderungen an eine Autorisierungskomponente

In diesem Kapitel werden die Anforderungen an die Autorisierungskomponente einer Großbank mit einem auf dem hierarchischen RBAC-Modell basierendem Berechtigungsmodell (vgl. Kapitel 1.2.5) beschrieben.

Ein Teil der hier aufgelisteten Anforderungen stammt aus [DITSEC] (Deutsche IT–Sicherheitskriterien) vom Bundesamt für Sicherheit in der Informationstechnik. Die deutschen IT – Sicherheitskriterien und deren Methodologie wurden zwischen 1989 und 1990 von der damaligen Zentralstelle für Sicherheit in der Informationstechnik (ZSI) entwickelt und veröffentlicht.

Ein weiterer Teil der Anforderungen stammt aus [PH05] – dem Pflichtenheft des Projektes „Zugriffssteuerung Neu“ der HVB. Bei der Durchführung des Projektes wurden die Systemverantwortlichen und die Verantwortlichen aus dem Fachbereich befragt, mit dem Ziel, die Anforderungen an die Zugriffssteuerung zu ermitteln.

Die Anforderungen an eine Autorisierungskomponente lassen sich (im Wesentlichen) nach folgenden Merkmalen strukturieren:

- Rechteverwaltung - Rechteprüfung - Beweissicherung - Fehlerüberbrückung - Leistungsanforderungen

2.1 Rechteverwaltung

In den Sicherheitsanforderungen der Autorisierungskomponente soll festgelegt werden:

- welche Subjekte bzw. welche Subjektklassen und welche Objekte bzw. Objektklassen der Rechteverwaltung unterliegen,

- welche Arten von Rechten zwischen den Subjekten und Objekten existieren können,

- wer die Rechte vergeben bzw. ändern darf,

- welche Regeln bei der Vergabe bzw. Änderung von Rechten eingehalten werden müssen,

- welche Voraussetzungen vor einer Vergabe oder Änderung von Rechten erfüllt sein müssen,

- welche Rollen durch die Rechteverwaltung definiert werden müssen,

- welche Rechte an spezielle Rollen gebunden sind,

- welche Rollen miteinander unvereinbar sind,

- welche Methoden für die Erfüllung des Minimal Prinzips, oder Need-to-Know-Prinzips eingesetzt werden. Nach diesem Prinzip darf jeder Mitarbeiter nur Zugriff aus die Funktionen / Daten haben, die er zur Ausübung seiner Tätigkeiten benötigt bekommen.

- welches Vorgehen bei der Vergabe der Sonderrechte eingesetzt wird. Wer darf solche Rechte vergeben, bzw. freigeben.




- Ein Prozess für die Beantragung von Rechten soll definiert werden (einheitliches Formular, eine Zentrale Stelle)

- Bei Ausübung verschiedenen Tätigkeiten an einem Arbeitsplatz durch eine Person (sog. Mischarbeitsplätze) soll Konzept des dynamischen Rollenwechsels definiert werden.

- Bei einem Stellenwechsel eines Benutzers soll der Benutzer entsprechend über seine Rechteänderungen informiert werden. Außerdem soll eine Meldung über die Notwendigkeit der Beantragung neuer Rechten, bzw. Hinweis über die automatische Löschung der alten Rechten nach bestimmter Zeit (z.B. 4 Wochen) dem Benutzer bzw. seinem Vorgesetzten übermittelt werden.

- Bei der Änderung / Ergänzung der Berechtigungen eines Benutzers soll eine Meldung an den Benutzer erstellt werden.

- Bei Vergabe zeitlich befristeter Sonderrechte ist folgende Funktion vorzusehen:

- Information des Benutzers vor Löschtermin durch automatisches Anschreiben mit Fristsetzung bzgl. Verlängerung des Sonderrechts und Termin der Löschung, wenn keine Verlängerung beantragt.

Besonders zu berücksichtigen ist die Vollständigkeit der Rechteverwaltung. Sind alle Subjekte und Objekte, die nach den Sicherheitsanforderungen der Rechteverwaltung unterliegen sollen, auch wirklich erfasst worden?

Weitere Anforderungen:

- Die Widerspruchsfreiheit der Rechtestruktur.

- Die Überschaubarkeit der Rechtestruktur.

- Der Schutz vor verdeckten Rechteänderungen, d. h. Änderungen von Rechten, die durch nicht vertrauenswürdige Programme vorgenommen werden können, ohne dass der Benutzer dieser Programme unmittelbar davon informiert wird.

- Der Schutz vor der Entstehung nicht mehr änderbarer Rechtebeziehungen. Dies sind Rechtebeziehungen, die von keinem Subjekt mehr rückgängig gemacht werden können (z.B. der Systemverwalter, der sich selbst das Systemverwalterkennzeichen löscht).

- Die Verwaltung der zugehörigen Rechte beim Löschen oder Umbenennen von Subjekten bzw. Objekten. Werden z. B. beim Löschen eines Subjektes nicht auch alle Rechte gelöscht, die dieses Subjekt besitzt, so kann es zu ungewollten Rechtebeziehungen kommen, wenn später einmal ein neues Subjekt mit dem gleichen Namen eingerichtet wird (vorausgesetzt, die Rechteverwaltung identifiziert Subjekte über ihren Namen).

2.2 Rechteprüfung

Bei jedem Versuch eines identifizierbaren Subjekts, Rechte bezüglich eines anderen Subjekts oder Objekts ausüben, ist es Aufgabe der Rechteprüfung, nur solche Aktionen zu erlauben, die das identifizierbare Subjekt aufgrund seiner vorhandener Rechte ausüben darf.


- bei welchen Aktionen eine Rechteprüfung erfolgen soll,

- welche Aktionen ergriffen werden sollen, wenn versucht wird, eine Aktion ohne das zugehörige Recht auszuführen,

- welche Ausnahmen es bei der Rechteprüfung geben soll und unter welchen Umständen diese Ausnahmen gültig sein sollen.




Bei den zur Rechteprüfung eingesetzten Mechanismen sind folgende Aspekte besonders zu untersuchen:

- Vollständigkeit der Rechteprüfung. Dies bedeutet, dass vor jedem Versuch, ein Recht auszuüben, überprüft wird, ob das Recht vorhanden ist. Falls dies nicht geschieht, gibt es Wege, die Rechteprüfung zu umgehen.

- Zeitpunkt der Rechteprüfung. Dies bedeutet, dass zwischen Prüfung und Ausübung eines Rechtes keine Aktionen erfolgen können, die einen Entzug des Rechtes zur Folge haben.

- Verfügbarkeit der Entscheidungsdaten. Dies bedeutet, dass sichergestellt ist, dass alle zur Prüfung benötigten Daten jederzeit verfügbar sind. Dies kann insbesondere in Netzwerken oder verteilten Systemen ein Problem sein. Stehen nicht alle Entscheidungsdaten zur Verfügung, so gibt es zwei Alternativen für die Rechteprüfung: Entweder sie lässt die Ausübung des Rechtes zu, mit der Gefahr, dass ein Subjekt ein Recht ausübt, welches ihm nicht zugestanden wurde, oder sie verhindert die Ausübung des Rechtes mit der Gefahr, dass ein Subjekt ein gegebenes Recht nicht ausüben und dadurch unter Umständen seine Aufgabe nicht erfüllen kann.

- Integrität der Entscheidungsdaten. Dies bedeutet, dass sichergestellt ist, dass die zum Treffen einer Entscheidung über die Erlaubnis eines Zugriffs verwendeten Daten nicht in unzulässiger Weise verändert werden können. Dazu zählen auch Veränderungen, die durch Hardwarefehler oder Übertragungsfehler entstehen können.

2.3 Beweissicherung

Die Beweissicherung protokolliert Informationen über erfolgte oder versuchte Ausübung von Rechten. Dadurch kann nachträglich überprüft werden, ob ein Missbrauch von Rechten erfolgte oder versucht wurde.

Die Beweissicherung kann auf zwei Wegen geschehen: zentral (durch eine zentrale Berechtigungskomponente des Systems), oder dezentral (durch die Anwendungen, die Zugriffe auf Ressourcen ausführen). Beide Methoden haben ihre Vorteile und Nachteile. Die zentrale Beweissicherung hat den Vorteil, dass die Beweisdaten für den Administrator zur Analyse jederzeit verfügbar sind. Nachteil ist, dagegen die Tatsache, dass es um eine große Datenmenge handelt, die schwer wartbar ist, und schnell unübersichtlich wird. Vorteil einer dezentralen Beweissicherung ist die reduzierte Datenmenge, die leichter verwaltbar ist, da eine Anwendung meist nur einige bestimmte Zugriffsarten durchführt. Die dezentrale Speicherung der Beweisdaten wird, allerdings, zum Nachteil, sobald diese Daten vom Administrator zur Analyse des Systemverhaltens benötigt werden.


- welche Ereignisse protokolliert werden sollen,

- welche Informationen dabei aufgezeichnet werden sollen,

- wo diese Informationen aufgezeichnet werden sollen,

- wer, wie und wann auf diese Informationen zugreifen darf,

- nach welchen Kriterien diese Informationen ausgewertet werden sollen.




Besonders zu berücksichtigen ist:

- Untäuschbarkeit der Beweissicherung. Dies bedeutet, es muss sorgfältig geprüft werden, ob Wege existieren, durch die es möglich ist, die Beweissicherung zur Aufzeichnung von fehlerhaften Daten zu veranlassen. Dazu zählt auch die Protokollierung von Ereignissen, die in Wirklichkeit nicht stattgefunden haben.

- Vollständigkeit der Beweissicherung. Dies bedeutet, es muss sorgfältig geprüft werden, ob es möglich ist, dass Ereignisse entgegen den Sicherheitsanforderungen nicht protokolliert werden. Ein solcher Fall kann zum Beispiel dann eintreten, wenn der Mechanismus keine Vorkehrungen beim Überlaufen der Protokollierungsdateien vorsieht.

2.4 Fehlerüberbrückung

Aufgabe der Fehlerüberbrückung ist es, die Auswirkungen von Fehlverhalten des Systems zu begrenzen und so einen möglichst verlustfreien Ablauf zu gewährleisten.


- Fehlerklassifizierung, mögliche Fehler sollen in Fehlerklassen aufgeteilt werden, z.B. nach Schwere der verursachten Systembeeinträchtigung in:

- kritischer Fehler – „Fehler, von dem anzunehmen oder bekannt ist, dass er voraussichtlich für Personen, die die betreffende Einheit benutzen, instand halten oder auf sie angewiesen sind, gefährliche oder unsichere Situationen schafft; oder ein Fehler, von dem anzunehmen oder bekannt ist, dass er voraussichtlich die Erfüllung der Funktion einer größeren Anlage, wie z.B. eines Schiffes, eines Flugzeuges, einer Rechneranlage, einer medizinischen Einrichtung oder eines Nachrichtensatelliten verhindert.“ [DIN85]

- Hauptfehler – „Nicht kritischer Fehler, der voraussichtlich zu einem Ausfall führt oder die Brauchbarkeit für den vorgesehenen Verwendungszweck wesentlich herabsetzt.“ [DIN85]

- Nebenfehler – „Fehler, der voraussichtlich die Brauchbarkeit für den vorgesehenen Verwendungszweck nicht wesentlich herabsetzt, oder ein Abweichen von den geltenden Festlegungen, das den Gebrauch oder Betrieb der Einheit nur geringfügig beeinflusst.“ [DIN85]

- welche Fehlerklassen überbrückt werden sollen,

- in welcher Form (kontrollierter Abbruch, Fixpunkt und Wiederanlauf, automatische Fehlerkorrektur etc.) die Fehlerüberbrückung erfolgen soll,

- welche Beeinträchtigungen (z.B. Daten-, Funktions-, oder Zeitverlust) in Kauf genommen werden können.

2.5 Leistungsanforderungen

Autorisierungskomponente einer Großbank als zentrale querschnittliche Komponente muss höchstverfügbar sein soll und sein ein hohes Transaktionsvolumen verarbeiten soll. Die Antwortzeit für die einzelnen Anfragen soll sehr niedrig sein. Im Falle eines kompletten Ausfalls der Funktionalität sollen entsprechende Maßnahmen ergriffen werden, um die reibungslose Funktionalität des Gesamtsystems nicht beeinträchtigen. Zum Beispiel könnten bei dem Ausfall der Zugriffsteuerungskomponente alle Zugriffsanfragen an eine Ersatzkomponente weitergeleitet werden, oder (im schlimmsten Fall) so konfiguriert werden, dass es unabhängig von der eingehenden Anfrage immer eine positive Antwort zurückliefert wird.



Im Folgenden werden Beispieldaten für Leistungsanforderungen an die Autorisierungskomponente (in diesem Fall konkret die Zugriffssteuerungskomponente) der HVB dargestellt [PH05].

34Anzahl Zugriffsprüfungen pro Sekunde

846.273Anzahl Zugriffsprüfungen pro Tag

25%Anteil Transaktionen mit Zugriffsprüfung

3.385.092Anzahl Transaktionen pro Tag

34Anzahl Zugriffsprüfungen pro Sekunde

846.273Anzahl Zugriffsprüfungen pro Tag

25%Anteil Transaktionen mit Zugriffsprüfung

3.385.092Anzahl Transaktionen pro Tag

Abbildung 9. Leistungsanforderungen an die Zugriffssteuerung der HVB. Wie aus der Abbildung ersichtlich, soll die Querschnittskomponente „Zugriffssteuerung“ pro Sekunde ca. 34 Zugriffsprüfungen durchführen können. Dies bedeutet, dass die Zugriffssteuerung einer extremen Belastung ausgesetzt wird. Es kann demnach leicht ein „bottleneck“ Problem entstehen, denn sehr viele Anwendungen in ihrer Funktionalität und Performance beeinträchtigt werden, wenn sie auf die Antwort auf ihre Zugriffsanfragen lange warten müssen. Deswegen sollen bei der Erstellung des Architekturmodells der Zugriffssteuerung entsprechende Entscheidungen getroffen werden, um die Entstehung des „bottleneck“ Problems verhindern zu können (vgl. dazu Bemerkungen am Ende des Kapitels 4.1).



Berechtigungsmanagement in einer Großbank





3 Fachliches Lösungsmodell für eine Großbank

In diesem Kapitel wird das fachliche Datenmodell einer Großbank beschrieben. Erster Schritt dabei ist die Definition eines generischen Datenmodells (alternative Bezeichnung – Meta-Modell) einer Großbank (s. Kapitel 3.1). Das generische Datenmodell ist ein Datenmodell einer abstrakten Großbank, welches die Merkmale der Datenmodelle verschiedener Großbanken in sich vereint und somit eine Verallgemeinerung darstellt, aus welcher ein konkretes Datenmodell einer beliebigen Großbank ableitbar sein soll (s. dazu Bemerkungen am Anfang des Kapitels 3.1).

Der zweite Schritt bei der Beschreibung des fachlichen Modells einer Großbank ist die Definition eines konkreten Datenmodells einer Beispielgroßbank (s. Kapitel 3.2). Das konkrete Datenmodell wird aus dem Meta-Modell abgeleitet, indem konkrete Subjekte und Objekte einer Großbank in das Meta-Modell eingesetzt werden. Das Ziel, welches bei der Definition des konkreten Datenmodells einer Großbank verfolgt wird, ist die Einführung eines Beispiels, welches in weiteren Kapiteln für die Definition der Mitarbeiterrollen (s. Kapitel 3.4.1), zu schützenden Ressourcen (auch Informationsobjekte genannt), Zugriffsprinzipien (s. Kapitel 3.4.2) und schließlich der Zugriffsregeln (s. Kapitel 3.4.4) benutzt werden kann.

3.1 Generisches Datenmodell einer Großbank (Meta-Modell)

Das Datenmodell einer Großbank soll im Hinblick auf die zukunftsorientierte Lösung für die Zugriffssteuerung flexibel und generisch gestaltet werden. Dadurch wird es möglich sein, zukünftige Anforderungen zu erfüllen, ohne Änderungen an dem Modul „Zugriffssteuerung“ vornehmen zu müssen.

Es gestaltet allerdings als schwierig ein allgemeines Meta-Modell einer Großbank zu erstellen, denn es existieren viele verschiedene Großbanken und jede Bank besitzt ein eigenes Datenmodell. Außerdem liegt dem Autor leider keine weitere Information über die Datenmodelle verschiedenen Großbanken außer der Information über das Datenmodell der HVB vor.

Aus Mangel an den Informationen über die Datenmodelle anderer Großbanken, wird in dieser Bachelorarbeit ein verallgemeinertes Datenmodell der HVB als Beispieldatenmodell (Meta-Modell) einer Großbank betrachtet. Der Autor erhebt damit keinen Anspruch auf die Allgemeinheit des hier vorgestellten Datenmodells im Hinblick auf die gesamte Großbankenlandschaft. Allerdings kann stillschweigend angenommen werden, dass dieses Meta-Modell nahe am gewünschten „allgemeinen generischen Datenmodell einer Großbank“ liegt.

In der Abbildung 10 wird ein Meta-Modell einer Großbank dargestellt. Wie man aus der Abbildung entnehmen kann, existieren im generischen Datenmodell folgende Entitäten:

- Mitarbeiter. Unter diesem Begriff sind alle Mitarbeiter, bzw. Benutzer der Softwareprodukte einer Großbank vereint. Ein Mitarbeiter wird über UserID identifiziert. Die Beziehungen zwischen einzelnen Mitarbeiter (z.B. MA1 ist Vorgesetzte von MA2) werden mithilfe der Beziehung MA-MA ausgedrückt (s. unten).

- Rolle. Ein Mitarbeiter kann in einer (mehreren) Rolle agieren. Eine Rolle beschreibt eine Aufgabe im Unternehmen und definiert Berechtigungen der


Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank

Rollenmitglieder. Die Rollenhierarchie wird mithilfe der Relation RollenHierarchie abgebildet.

Ordnungsbegriff-Typ-ID

Ordnungsbegriff-Typ-ID

Zugriffsrecht

-Funktion

Zugriffsrecht

-Funktion

Mitarbeiter

-UserID

Mitarbeiter

-UserID

MA-MA

-Beziehungstyp

MA-MA

-Beziehungstyp

MA-OE

-Beziehungstyp

MA-OE

-Beziehungstyp

OB-OE

-Beziehungstyp

OB-OE

-Beziehungstyp

OE

-Standort

OE

-Standort

AttributlisteAttributliste

OB-Zugriffrecht-Mitarbeiter

-Beziehungstyp

OB-Zugriffrecht-Mitarbeiter

-Beziehungstyp

OB-OB

-Beziehungstyp

OB-OB

-Beziehungstyp

1

1

*

*

* * *

*

*

*

1 * *

*

0..1

0..1

0..10..1

*

*

*

*

0..1

11

*

*

*

*

1

11

* * 1

*Rolle

-Bezeichnung

Rolle

-Bezeichnung

* *

RollenHierarchie

1..*

1

Informationsobjekt

-ID

Informationsobjekt

-ID

*

*

0..1

OE-OE

-Beziehungstyp

OE-OE

-Beziehungstyp*

*

1

1

0..1

*

Attribut-Wert-Paar-Attribut-Attributwert

Attribut-Wert-Paar-Attribut-Attributwert

*

Abbildung 10. Generisches Datenmodell einer Großbank [PH05].

- OE. Organisationseinheit ist ein Verallgemeinerungsbegriff für die Filialen und Niederlassungen einer Bank. Mithilfe der Beziehung OE-OE wird die Organisationseinheitenhierarchie abgebildet (s. unten).

- Informationsobjekt. Unter diesem Begriff sind Elemente (allg. Ressourcen) einer Bank gemeint, die dem Zugriffsschutz unterliegen. Sie entsprechen fachlichen Beständen (Konto, Vertrag, Kredit usw.) und sind über Identifizierer (ID) eindeutig gekennzeichnet. Jedes Informationsobjekt wird einem oder mehreren Ordnungsbegriffen zugeordnet.

- Ordnungsbegriff. Klasse Ordnungsbegriff dient zur Klassifikation der Informationsobjekte, d.h. alle Informationsobjekte werden klassifiziert, abhängig davon, zu welchem Ordnungsbegriff sie gehören. So kann, z.B. das Informationsobjekt Konto den Ordnungsbegriffen Konto, Kunde (Kontobesitzer) und Geschäftspartner (z.B. eine Tochterbank) zugeordnet werden. Das Informationsobjekt Partnervertrag (z.B. Vertrag der bei der Fusion zweier Banken abgeschlossen wird) kann dagegen nur zu den Ordnungsbegriffen Geschäftspartner und Geschäftspartnerverbund zugeordnet werden.

- Zugriffsrecht. Dieser Begriff vereint alle möglichen Zugriffrechte auf die einem Ordnungsbegriff zugeordnete Informationsobjekte einer Bank im Sinne des Konzepts der dynamischen Autorisierung (vgl. Kapitel 1.2). Das Attribut Funktion bezieht sich auf die Funktion, die vom Mitarbeiter ausgeübt wird (z.B. Konto oder Vertrag anlegen, auflösen, ändern, …).





- Attributliste. Sie ermöglicht Beziehungen und Entitätstypen mit beliebig vielen Parametern zu versehen. Die Attributliste der Beziehung OB-Zugriffsrecht-Mitarbeiter (s. unten) könnte z.B. folgende Attribute enthalten:

- gültig_ab - ab wann ist die Ausübung des Zugriffsrechts möglich

- gültig_bis - bis wann ist die Ausübung des Zugriffsrechts möglich

- Zeitliche Beschränkung – zeitliche Beschränkung der Ausübung des Zugriffsrechts, (z.B. Zugriff nur während der Geschäftszeiten)

- Beschränkung der Zugriffsart - Beschränkung der Ausübung der für den Ordnungsbegriff spezifischen Zugriffsrechte, z.B. Vertragsdaten bearbeiten, aber nicht den Vertrag freigeben.

- ID eines Ordnungsbegriffs oder Informationsobjektes und entweder erlaubte Zugriffart (read, write, usw.) auf dieses Objekt oder Rolle in der Mitarbeiter auf dieses Objekt zugreifen darf (falls die Beziehung OB-Zugriffsrecht-Mitarbeiter zur Definition eines Sonderrechtes dient).

Zwischen oben erwähnten Entitäten existieren folgende Beziehungen:

- Ordnungsbegriff (OB) – Zugriffsrecht – Mitarbeiter (MA) ist eine zentrale Beziehung zur Festlegung von Sonderrechten eines MA auf ein OB (bzw. dem Ordnungsbegriff zugeordnete Informationsobjekte), oder allgemeinen Beziehungen zwischen MA und Ordnungsbegriff (bzw. dem Ordnungsbegriff zugeordnete Informationsobjekte). Die Beziehung lässt sich über die Attributliste beschreiben, Beispiel s. oben.

- MA-MA Beziehung. Vertretungs- und Vorgesetztenbeziehungen werden über die MA-MA-Beziehung ausgedrückt, die genaue Beschreibung der Beziehung kann in der Attributliste festgehalten werden.

- OB – OB Beziehung. Stellt die Beziehungen zwischen einzelnen Ordnungsbegriffen dar. Mithilfe dieser Beziehung kann zum Beispiel die Beziehung „Konto-gehört-zu-Kunde“ oder „Kunde-gehört-zu-Geschäftspartner“ ausgedrückt werden.

- MA-OE-Beziehung. Mithilfe dieser Beziehung können die Beziehungen von Mitarbeiter zu Organisationseinheiten ausgedrückt werden (z.B. arbeitet_für, oder ist_Leiter_von usw.).

- OE – OE Beziehung. Ist für die Abbildung der Hierarchie der Organisationseinheiten und möglichen weiteren Beziehungen zwischen den Organisationseinheiten vorgesehen (z.B. OE1 gehört_zu OE2, usw.).

- OB-OE Beziehung. Hier wird die Zugehörigkeit eines Ordnungsbegriffs (bzw. ihm zugeordneten Informationsobjekte) zur Organisationseinheit abgebildet.

Das Meta-Modell hat sehr viele Gemeinsamkeiten mit dem im Kapitel 1.2.5 vorgestellten hierarchischen RBAC-Modell (s. Tabelle 1).Wie aus der Tabelle ersichtlich wird das Meta-Modell einer Großbank im Wesentlichen auf Basis des hierarchischen RBAC-Modells aufgebaut bis auf einige wenige bankspezifische Ausnahmen. Diese Tatsache bekräftigt noch mal die Entscheidung das hierarchische RBAC-Modell bei der Modellierung der Zugriffssteuerung einer Großbank einzusetzen.




Generisches Datenmodell (Meta-Modell)

Hierarchisches RBAC-Modell

Informationsobjekt Ressource

Ordnungsbegriff Ressource, bzw. Ressourcenattribut

Mitarbeiter Subject

Rolle Role

RollenHierarchie RoleHierarchy

Zugriffsrecht Permission + Action

OB-OB Beziehung RessourceDerivation

OB-OE Beziehung Ressourcenattribut

MA-OE Beziehung Subjektattribut

MA-MA Beziehung UserHierarchy

OE Ressourcen-, bzw. Mitarbeiterattribut

OE-OE Beziehung Nicht vorhanden

OB-Zugriffsrecht-Mitarbeiter Beziehung

Permission + Action

Attributliste Nicht dargestellt Tabelle 1. Meta-Modell vs. RBAC Modell.

Auf der Basis des Meta-Modells aufbauend, wird im nächsten Kapitel ein Beispiel für das Datenmodell einer Großbank vorgestellt. Der Übergang vom Meta-Modell einer Bank zu einem Beispielmodell ist in diesem Dokument notwendig, um konkrete Mitarbeiterrollen und Zugriffsregeln der Zugriffssteuerung beschreiben zu können.

3.2 Datenmodell einer Beispielgroßbank

In der Abbildung 11 wird ein Datenmodell einer Beispielgroßbank dargestellt. Wie aus der Abbildung ersichtlich, sind im Datenmodell folgende Klassen enthalten:

- Klasse Informationsobjekt im Datenmodell entspricht der Klasse Informationsobjekt aus dem Meta-Modell (s. Abbildung 10) bzw. der Klasse Ressource aus dem hierarchischen RBAC-Modell (s. Abbildung 8).

- Klasse Ordnungsbegriff und alle von davon abgeleitete Klassen (Partnerverbund, Partner, Kunde, Konto, usw.) im Datenmodell entspricht der Klasse Ordnungsbegriff aus dem Meta-Modell (s. Abbildung 10) bzw. einem Attribut der Klasse Ressource aus dem hierarchischen RBAC-Modell (s. Abbildung 8).

Die wichtigsten Ordnungsbegriffe einer Bank sind nach dem Datenmodell:

- Konto: Ein Sammelbegriff für alle Kontoprodukte einer Bank. Unter dem Begriff Konto können beispielsweise folgende Informationsobjekte aus dem Bankwesen zusammengefasst werden:

- Einlage - Hypothek - Kredit - Girokonto



*

*

1..*

Standort

Vorgesetzte**

1..* Leiter

arbeitet_an

Mitarbeiter

-ID

Mitarbeiter

-ID

gehört_zu

**

0..1

gehört_zu

*

**

OE

*Gruppenbetreuer

*GruppenbetreuerGruppenbetreuerGruppenbetreuer

Terminal*

TerminalTerminalTerminal*

gehört_zu**

gehört_zu

Ordnungsbegriff

-Typ

-ID

Ordnungsbegriff

-Typ

-ID

Ordnungsbegriff

-Typ

-ID

1..*PartnerverbundPartnerverbundPartnerverbund

*

PartnerPartnerPartner*

Generalist*

GeneralistGeneralistGeneralist*

SpezialistSpezialistSpezialist

*

Partnerbetreuer*

PartnerbetreuerPartnerbetreuerPartnerbetreuer*1..*

*

*

*KontoKontoKonto

Informationsobjekt

-ID

-Typ

-ist_VIP: bool

Informationsobjekt

-ID

-Typ

-ist_VIP: bool

Informationsobjekt

-ID

-Typ

-ist_VIP: bool

*

*

stellv. Betreuer

Betreuer

-ist_VIP: bool

Betreuer

-ist_VIP: bool

1

*

*

Arbeitsplatzprofil

-ist_Azubi: bool-ist_Springer: bool

Arbeitsplatzprofil


1

0..1

1..**

KundeKundeKunde

1..**

Statische Autorisierung

-Funktion_ID

-Berechtigung[ ]


-Funktion_ID

-Berechtigung[ ]


-Funktion_ID

-Berechtigung[ ]

*

Abbildung 11: Datenmodell einer Großbank - Kunde: Unter dem Begriff Kunde wird entweder ein Kunde der Bank selbst (z.B. ein

Kontoinhaber), oder Kunde eines Partners, oder ein Geschäftspartner o.ä. gemeint. Informationsobjekt eines Kunden kann beispielsweise ein Kontovertrag sein.

- Partner: Bezeichnung für einen Geschäftspartner einer Bank. Es kann z.B. ein weiteres Kreditinstitut wie eine Partnerbank, Tochterbank oder eine Versicherung o.ä. sein.

- Partnerverbund: Verbund mehrerer Geschäftspartner. Informationsobjekt eines Partnerverbunds kann beispielsweise ein Geschäftspartnervertrag sein.

Manche Kunden (z.B. prominente Personen) legen einen großen Wert auf exklusive Behandlung ihrer Daten, was zu der Einführung des VIP Konzepts bei einigen Banken geführt hat. Nach dem VIP Konzept können Kunden verlangen, dass ihre Daten nur von einem bestimmten (vertrauenswürdigen) Personenkreis der Mitarbeiter der Bank bearbeitet werden können. Im Datenmodell wird dieser Sachverhalt mithilfe des Attributs is_VIP: bool bei der Klasse Informationsobjekt festgehalten. Ebenso wird bei der Klasse Betreuer (s. unten) ein solches Attribut eingeführt. Zugriff auf ein VIP Informationsobjekt wird demnach nur für VIP Betreuer zulässig.

Ein weiterer wichtiger Begriff aus dem Datenmodell ist Mitarbeiter der Bank. Die Klasse Mitarbeiter des Datenmodells entspricht der Klasse Mitarbeiter aus dem Meta-Modell (s. Abbildung 10) bzw. der Klasse Subjekt (User) aus dem hierarchischen RBAC-Modell (s. Abbildung 8). Mitarbeiterhierarchie wird mithilfe der Beziehung Vorgesetzte abgebildet (vgl. MA-MA Beziehung im Meta-Modell). Ein Mitarbeiter wird über Beziehung gehört_zu einer bzw. mehreren Organisationseinheiten (über die Hierarchie der Organisationseinheiten) zugeordnet (vgl. MA-OE Beziehung im Meta-Modell). Die Zuordnung des Mitarbeiters zu dem aktuellen Einsatzort (Standort) erfolgt über die Beziehung arbeitet_an.

Jedem Mitarbeiter der Bank werden statisch eine, bzw. nach Notwendigkeit mehrere Rollen zugeordnet. Eine Rolle beschreibt eine Aufgabe im Unternehmen und definiert Berechtigungen der Rollenmitglieder (Mitarbeiter). Die Rollenmitgliedschaft eines Mitarbeiters wird im Datenmodell mithilfe zweier Klassen definiert: Klasse Arbeitsplatzprofil und Klasse Betreuer. Über die Attribute des Arbeitsplatzprofils und Unterklassen von der Klasse Betreuern kann einem Mitarbeiter der Bank eine Rolle (vgl. Kapitel 3.4.1) zugeordnet





werden. Diese Rolle entspricht der Klasse Rolle aus dem Meta-Modell (s. Abbildung 10) bzw. der Klasse Role aus dem hierarchischen RBAC-Modell (s. Abbildung 8).

Die Klasse Arbeitsplatzprofil dient zur Definition der Berechtigungen eines Mitarbeiters gemäß statischen Autorisierung. Das Arbeitsplatzprofil eines Mitarbeiters enthält Einträge, die die für den Mitarbeiter erlaubten Funktionen und Berechtigungen innerhalb dieser Funktionen definieren, z.B. allgemeine Erlaubnis für einen Mitarbeiter Funktionalität „Partnerdaten bearbeiten“ auszuführen (vgl. statische Autorisierung, Kapitel 1.2) und Berechtigungen des Mitarbeiters bei Ausführung dieser Funktion (z.B. Erlaubnis Partneradresse ändern, oder Verbot einen neuen Partner anlegen zu können). Konkrete Kunden, auf deren Daten der Mitarbeiter zugreifen darf, werden im Rahmen der dynamischen Autorisierung ermittelt, abhängig davon, ob der Mitarbeiter als Betreuer dieser Kunden definiert ist, oder nicht (s. unten: Klasse Betreuer).

Außerdem wird im Arbeitsplatzprofil festgehalten, ob Mitarbeiter ein Auszubildender oder ein Springer ist (vgl. Rollendefinition im Kapitel 3.4.1).

Klasse Betreuer ermöglicht die Zuordnung eines Mitarbeiters zu bestimmten Ordnungsbegriffen, bzw. Informationsobjekten, was für die Durchführung der dynamischen Autorisierung notwendig ist. Dabei wird für einen Mitarbeiter mithilfe der Klasse Betreuer (bzw. Unterklassen von Betreuer: Gruppenbetreuer, Partnerbetreuer, Generalist und Spezialist) definiert, auf welchen konkreten Ordnungsbegriffen, bzw. Informationsobjekten der Mitarbeiter die ihm durch die statische Autorisierung erlaubte Funktionalität ausführen darf. Allgemein ist ein Betreuer (bzw. ein Mitarbeiter in der Betreuerrolle) für die Betreuung der Informationsobjekten, bzw. Daten eines Partnerverbunds, Partner und Kunden zuständig. Die Rolle Betreuer (vgl. Kapitel 3.4.1) ist eine Verallgemeinerungsrolle gemäß dem Betreuerkonzept (vgl. Kapitel 3.4.2).

Unterklassen der Klasse Betreuer sind:

- Spezialist: Ein Mitarbeiter (Betreuer), der über umfangreiches Wissen auf einem, bzw. einigen wenigen bestimmten Fachgebieten im Bankwesen verfügt. Sein Einsatzgebiet umfasst demnach einen, bzw. einige wenige Fachgebiete. Ein Spezialist kann z.B. folgende Aufgaben erfüllen:

- Kredite betreuen - Aktiengeschäfte führen

Ein Spezialist darf auf die den Kunden und Konten zugeordnete Informationsobjekte zugreifen.

- Generalist: Im Gegenteil zu einem Spezialist hat Generalist umfangreiches Wissen auf mehreren bestimmten Fachgebieten im Bankwesen. Sein Einsatzgebiet umfasst demnach mehrere Fachgebiete. Er darf auf die den Kunden und Konten zugeordnete Informationsobjekte zugreifen.

- Partnerbetreuer betreut Partner. Ein Partnerbetreuer kann auf die Informationsobjekte der ihm zugeordneten Partner zugreifen.

- Gruppenbetreuer betreut Partnergruppen. Ein Gruppenbetreuer hat Zugriff auf die Informationsobjekte der Partnergruppe.

Das in diesem Kapitel vorgestellte Datenmodell wurde auf Basis des Meta-Modells einer Großbank, bzw. des hierarchischen RBAC-Modells aufgebaut. In der nachfolgenden Tabelle wird die Zuordnung der Klassen des Datenmodells zu den Klassen des Meta-Modells und des hierarchischen RBAC-Modells dargestellt.




Datenmodell Generisches Datenmodell (Meta-Modell)

Hierarchisches RBAC-Modell

Informationsobjekt Informationsobjekt Ressource

Ordnungsbegriff Ordnungsbegriff Ressource, bzw.

Ressourcenattribut

Partnerverbund Ordnungsbegriff Ressource, bzw.

Ressourcenattribut

Partner Ordnungsbegriff Ressource, bzw.

Ressourcenattribut

Kunde Ordnungsbegriff Ressource, bzw.

Ressourcenattribut

Konto Ordnungsbegriff Ressource, bzw.

Ressourcenattribut

Mitarbeiter Mitarbeiter Subject

Rolle Rolle Role

Betreuer Rolle Role

Gruppenbetreuer Rolle Role

Partnerbetreuer Rolle Role

Generalist Rolle Role

Spezialist Rolle Role

Nicht dargestellt RollenHierarchie RoleHierarhy

Nicht dargestellt Zugriffsrecht Permission + Action

OE OE Nicht vorhanden

Nicht dargestellt OB-OB Beziehung RessourceDerivation

gehört_zu(IO, OB) OB-OE Beziehung Ressourcenattribut

gehört_zu(MA, OE),

Leiter(MA, OE),

arbeitet_an(Standort)

MA-OE Beziehung Subjektattribut

Vorgesetzte(MA, MA) MA-MA Beziehung UserHierarhy

gehört_zu(OE, OE) OE-OE Beziehung Nicht vorhanden

Nicht dargestellt Attributliste Nicht vorhanden

Standort Attribut von OE Nicht vorhanden

Terminal Attribut von OE Nicht vorhanden Tabelle 2. Datenmodell vs. Meta-Modell und RBAC Modell.




3.3 Anforderungen an die Informationsbasis der Zugriffssteuerung

Unter der Informationsbasis der Zugriffssteuerung sind die Informationen aus mehreren Datenbanken der gesamten Datenbankenlandschaft einer Großbank gemeint, die für die Entscheidung über eine Zugriffsanfrage von der Zugriffssteuerung benutzt werden. Um die an sie gestellten Anforderungen zu erfüllen, soll die Informationsbasis der Zugriffssteuerung so strukturiert werden, dass die notwendigen Beziehungen mit möglichst wenigen Datenbankzugriffen feststellbar sind. Dies kann geschehen, indem entsprechende Datenstrukturen eingeführt werden um diese Beziehungen in einer für den Zugriff optimierten Form zu speichern. Diese Datenstrukturen sollen in regelmäßigen Abständen aktualisiert werden, damit sich die Zugriffssteuerung bei ihren Entscheidungen über die Gewährung eines Zugriffs nicht auf veraltete (womöglich nicht mehr existierende) Beziehungen beziehen kann.

Außerdem soll das Problem der mehrfachen Datenhaltung gelöst werden, z.B. durch Reorganisation der Datenbankenlandschaft der Bank, oder entsprechende Synchronisierungsverfahren zwischen den Datenbanken der Großbank.

Falls die für den real-time Zugriff der Zugriffssteuerung notwendigen Daten auf mehreren Datenbanken verteilt sind (was normalerweise der Fall ist), dann soll speziell für die Zugriffssteuerung eine Datenstruktur eingeführt werden, in der die Integration mehrerer Datenbestände in einen Bestand realisiert wird.

Die Informationsbasis der Zugriffssteuerung soll (abgesehen von den oben erwähnten technischen Gegebenheiten) im Folgenden aufgelistete Anforderungen erfüllen können. Es sollen folgende Beziehungen feststellbar sein:

- Zugehörigkeit von Mitarbeitern zu Organisationseinheiten - Zugehörigkeit von Mitarbeitern zu deren Vorgesetzten - Zugehörigkeit von Informationsobjekten zu den Organisationseinheiten - Zugehörigkeit von Informationsobjekten zu den Ordnungsbegriffen - Zugehörigkeit von Ordnungsbegriffen zu den Betreuern - Zugehörigkeit von Stellvertretern zu Betreuern - Wer Leiter einer Organisationseinheit ist - Hierarchie der Organisationseinheiten - Hierarchie der Ordnungsbegriffe

3.4 Definition der Zugriffsregeln für die Zugriffssteuerung

Um die Zugriffsregeln definieren zu können, müssen die Rollen, die ein Mitarbeiter annehmen kann, definiert werden. Außerdem ist es hilfsreich die Anwendungsfälle zu definieren, denn aus diesen Anwendungsfällen können die Zugriffsprinzipien und konkrete Zugriffsregeln abgeleiten werden.

3.4.1 Rollenhierarchie In diesem Kapitel werden die wichtigsten Akteure (bzw. Rollen, die ein Bankmitarbeiter annehmen kann) definiert. Jeder Akteur hat bestimmte Zugriffsrechte auf bestimmte Informationsobjekte innerhalb der Bank. Aus dem Datenmodell (s. Abbildung 11) folgt, dass ein Mitarbeiter folgende Rollen annehmen kann:

- Betreuer - Spezialist - Generalist - Partnerbetreuer - Gruppenbetreuer - Springer - Azubi



RolleRolle

GruppenbetreuerGruppenbetreuerGruppenbetreuer


GeneralistGeneralistGeneralist

SpringerSpringerSpringerPartnerbetreuerPartnerbetreuerPartnerbetreuer

AzubiAzubiAzubi BetreuerBetreuer

Abbildung 12. Rollenhierarchie.

Wie aus der Abbildung 12 ersichtlich, ist die Rolle eines Auszubildenden (Azubi) eine Rolle, die mit wenigsten Berechtigungen ausgestattet ist. Ein Auszubildender kann aufgrund der Erfahrungsmangel keine verantwortungsvollen Aufgaben durchführen, besitzt also meistens nur beschränkte Rechte auf die Informationsobjekte. Außerdem hat ein Azubi kein bestimmtes Fachgebiet im Bankwesenbereich, sondern erledigt seine Aufgaben bereichsübergreifend. Ein Azubi darf nur auf die Informationsobjekte, die derselben Organisationseinheit wie er selbst zugeordnet sind zugreifen (vgl. Kapitel 3.4.2: Zugriff nach dem Lokationsprinzip). Die Tatsache, dass ein Mitarbeiter in der Rolle Azubi agiert, wird im Datenmodell in einem Attribut der Klasse Arbeitsplatzprofil ist_Azubi: bool festgehalten.

Die Rolle Betreuer erbt alle Berechtigungen der Rolle Azubi und als eine Verallgemeinerungsrolle (abstrakte Rolle) aller restlichen Rollen gedacht. Allgemein ist ein Betreuer ein Mitarbeiter der Bank, der über eine Qualifikation verfügt dem Kunden in komplexeren Situationen zur Verfügung zu stehen, wie z.B. Möglichkeiten der Geldanlage und Kreditverwaltung. Außerdem kann ein Betreuer auch Geschäftspartner wie Firmen, Großkonzerne und Partnerbanken in ihren Angelegenheiten betreuen. Die Rolle Betreuer wird weiter unterteilt in Springer, Generalist, Spezialist, Partnerbetreuer und Gruppenbetreuer. Da die Definition von Begriffen Generalist, Spezialist, Partnerbetreuer und Gruppenbetreuer bereits im Kapitel 3.2 erfolgte, wird an dieser Stelle des Dokuments zusätzlich nur noch eine Definition der Rolle Springer gegeben.

Ein Springer ist ein Arbeitnehmer der zur ständigen Vertretung von Mitarbeitern eingestellt ist. Ein Springer kann im Falle der Krankheit bzw. Abwesenheit eines Mitarbeiters seine Aufgaben übernehmen (professionelle Kenntnisse und Qualifikation des Springers sollen natürlich der Qualifikation des zu vertretendes Mitarbeiters entsprechen.) Eine wichtige Eigenschaft eines Springers ist keine explizite Zuordnung zu einem Standort, d.h. ein Springer wechselt (manchmal täglich) seinen Standort, wird also dort eingesetzt, wo gerade ein Mitarbeiter ausgefallen ist. Die Tatsache, dass ein Mitarbeiter in der Rolle Springer agiert, wird im Datenmodell in einem Attribut der Klasse Arbeitsplatzprofil ist_Springer: bool festgehalten.

3.4.2 Zugriffsprinzipien Bei der Zugriffsteuerung handelt sich um die Steuerung des Zugriffs auf die Informationsobjekte unter Ausnutzung bestimmten Zugriffsprinzipien. Die Zugriffsprinzipien lassen sich im Wesentlichen in fünf Fälle unterteilen:

1. Zugriff auf Informationsobjekte gemäß dem Lokationsprinzip. Ein Mitarbeiter darf auf die Informationsobjekte, die derselben OE wie er selbst zugeordnet sind, zugreifen (s. Abbildung 13). Zuordnung der Informationsobjekte zu




Organisationseinheiten erfolgt über Ordnungsbegriffe. (Ein Ordnungsbegriff ist über die Relation gehört_zu einer Organisationseinheit zugeordnet).

2. Zugriff auf Informationsobjekte gemäß dem Betreuerprinzip. Ein Mitarbeiter darf auf die Informationsobjekte des Ordnungsbegriffs zu dem er explizit als Betreuer zugeordnet ist, zugreifen (s. Abbildung 13).

3. Zugriff auf die Informationsobjekte gemäß dem Gesamtbankrechtprinzip. Ein Mitarbeiter hat unbeschränkten Zugriff auf die Informationsobjekte der Bank.

4. Zugriff auf die Informationsobjekte gemäß dem VIP Prinzip. Ein Mitarbeiter darf auf ein Informationsobjekt das explizit als VIP Objekt markiert ist nur dann zugreifen, wenn er explizit als VIP Betreuer definiert ist (d.h. falls ihm Zugriff auf Informationsobjekt gemäß Prinzipien 1 und 2 erlaubt ist und zusätzlich Erlaubnis „VIP Informationsobjekte bearbeiten“ vorliegt).

5. Zugriff auf die Informationsobjekte gemäß dem Sonderrechtprinzip. Für einige Mitarbeiter können vom Administrator der Zugriffssteuerung Sonderrechte definiert werden.

Ein Mitarbeiter, dem gemäß anderen Zugriffsprinzipien kein Zugriff auf das Informationsobjekt erlaubt ist (z.B. wegen anderer Position des Mitarbeiters in der Betreuerhierarchie, als es für den Zugriff gemäß dem Betreuerprinzip notwendig ist, oder wegen Zugehörigkeit des Mitarbeiters zu einer anderen Organisationseinheit als das Informationsobjekt) kann (falls er einen entsprechenden Sonderrecht dafür besitzt) auf bestimmte Informationsobjekte zugreifen, ohne dass ihm die Gesamtbankrechte erteilt werden müssen.

In der Abbildung 13 werden das Lokationszugriffsprinzip und das Betreuerzugriffsprinzip anhand eines Beispiels dargestellt (Notation: vgl. [LEMA05]).

*

*

1..*

Standort

Vorgesetzte**

1..* Leiter

arbeitet_an

Mitarbeiter

-ID

Mitarbeiter

-ID

gehört_zu

**

0..1

gehört_zu

*

**

OE

*Gruppenbetreuer

*GruppenbetreuerGruppenbetreuerGruppenbetreuer

Terminal*

TerminalTerminalTerminal*

gehört_zu**

gehört_zu

Ordnungsbegriff

-Typ

-ID

Ordnungsbegriff

-Typ

-ID

Ordnungsbegriff

-Typ

-ID

1..*PartnerverbundPartnerverbundPartnerverbund

*

PartnerPartnerPartner*

Generalist*

GeneralistGeneralistGeneralist*


*

Partnerbetreuer*

PartnerbetreuerPartnerbetreuerPartnerbetreuer*1..*

*

*

*KontoKontoKonto

Informationsobjekt

-ID

-Typ

-ist_VIP: bool

Informationsobjekt

-ID

-Typ

-ist_VIP: bool

Informationsobjekt

-ID

-Typ

-ist_VIP: bool

*

*

stellv. Betreuer

Betreuer

-ist_VIP: bool

Betreuer

-ist_VIP: bool

1

*

*

Arbeitsplatzprofil


Arbeitsplatzprofil


1

0..1

1..**

KundeKundeKunde

1..**


-Funktion_ID

-Berechtigung[ ]


-Funktion_ID

-Berechtigung[ ]


-Funktion_ID

-Berechtigung[ ]

*

Abbildung 13. Beispiel für Lokations- und Betreuerzugriffsprinzipien. Vorgesetzten und Vertreter eines Mitarbeiters, bei dem gemäß des Lokationsprinzips und/oder Beraterprinzips und/oder Gesamtbankrechtprinzips Zugriff erlaubt ist, dürfen auch auf die entsprechenden Informationsobjekte zugreifen.





Der Leiter einer Organisationseinheit darf auf alle Informationsobjekte die seiner OE zugeordnet sind zugreifen (Ausnutzung des Lokationsprinzips und der Tatsache, dass Leiter einer OE ein Vorgesetzte aller Mitarbeiter der OE ist).

Ein Auszubildender darf auf die Informationsobjekte gemäß Lokationsprinzip zugreifen.

3.4.3 Anwendungsfälle Aus dem Datenmodell und den im Kapitel 3.4.2 beschriebenen Zugriffsprinzipien können nun die Anwendungsfälle abgeleitet werden. Unter dem Begriff Anwendungsfall ist eine Beschreibung des Verhaltens gemeint, welches die Zugriffssteuerung für die Akteure (Mitarbeiter in bestimmten Rollen) anbietet.

Alle Anwendungsfälle können hierarchisch angeordnet werden. Relation „Anwendungsfall A enthält Anwendungsfall B“ bedeutet dabei, dass Anwendungsfall B ein Spezialfall des Anwendungsfalls A ist. Die Hierarchie der Anwendungsfälle lässt sich am besten anhand eines Diagramms darstellen (s. Abbildung 14).

Anwendungsfall „Zugriff auf ein IO mit Gesamtbankrechten“ enthält alle anderen Anwendungsfälle. Falls ein Mitarbeiter Gesamtbankrechte besitzt kann er unbeschränkt auf alle Informationsobjekte der Bank zugreifen. Dieser Anwendungsfall enthält zwei weitere Spezialfälle, die sich in der Art des angewendeten Zugriffsprinzips unterscheiden:

- Zugriff nach dem Betreuerprinzip. In diesem Fall tritt ein Mitarbeiter der Bank in der Rolle eines Betreuers auf. Dabei gibt es, abhängig davon, welche Rolle dem Mitarbeiter nach der Betreuerhierarchie zugeordnet ist, folgende Spezialfälle:

- Gruppenbetreuer: Anwendungsfall „Zugriff auf IO des OB Partnerverbund“. Ein Gruppenbetreuer darf laut Datenmodell (s. Abbildung 11) auf die Informationsobjekte eines Partnerverbunds zugreifen. Unter diesen Informationsobjekten sind auch die Informationsobjekte des dem Partnerverbund zugeordneten Partners (Zugriff im Anwendungsfall „Zugriff auf IO des OB Partner“), die Informationsobjekte des diesen Partnern zugeordneten Kunden (Zugriff im Anwendungsfall „Zugriff auf IO des OB Kunde“) und die Informationsobjekte der diesen Kunden zugeordneten Konten (Zugriff im Anwendungsfall „Zugriff auf IO des OB Konto“) gemeint.

- Partnerbetreuer: Anwendungsfall „Zugriff auf IO des OB Partner“. Ein Partnerbetreuer darf auf die Informationsobjekte eines Partners zugreifen. Unter diesen Informationsobjekten sind auch die Informationsobjekte des diesem Partner zugeordneten Kunden (Zugriff im Anwendungsfall „Zugriff auf IO des OB Kunde“) und die Informationsobjekte der diesen Kunden zugeordneten Konten (Zugriff im Anwendungsfall „Zugriff auf IO des OB Konto“) gemeint.

- Generalist / Spezialist: Anwendungsfall „Zugriff auf IO des OB Kunde“. Ein Generalist (bzw. Spezialist) darf auf die Informationsobjekte eines Kunden zugreifen. Unter diesen Informationsobjekten sind auch die Informationsobjekte der diesem Kunden zugeordneten Konten (Zugriff im Anwendungsfall „Zugriff auf IO des OB Konto“) gemeint.

- Zugriff nach dem Lokationsprinzip: Anwendungsfall „Zugriff auf IO der OE des Mitarbeiters“. In diesem Anwendungsfall kann ein Mitarbeiter auf Informationsobjekte, die derselben Organisationseinheit wie er selbst zugeordnet sind zugreifen.

Ein weiterer Anwendungsfall, der nicht in der Abbildung dargestellt ist, ist „Zugriff auf ein Informationsobjekt nach dem Sonderrechtprinzip“. Konkrete Informationsobjekte oder Ordnungsbegriffe, auf die Zugriff erlaubt ist, werden als Attribute des Sonderrechts definiert.



Gruppenbetreuer ,bzw. sein Vertreteroder Vorgesetzter

Gruppenbetreuer ,bzw. sein Vertreteroder Vorgesetzter

Zugriff auf IO des OBPartner

Zugriff auf IO des OBPartner

Zugriff auf IOdes OBKunde

Zugriff auf IOdes OBKunde

Zugriff aufIO des OB

Konto

Zugriff aufIO des OB

KontoBankangestellte(am Schalter) ,

bzw. sein Vertreteroder Vorgesetzter

Bankangestellte(am Schalter) ,


Partnerbetreuer,bzw. sein Vertreteroder Vorgesetzter

Partnerbetreuer,bzw. sein Vertreteroder Vorgesetzter

Generalist /Spezialist ,


Generalist /Spezialist ,


Legende

Anwendungsfall

Akteur (Rolle)

hat Zugriff

Anwendungsfall A enthältden Anwendungsfall B

MA MitarbeiterIO InformationsobjektOB OrdnungsbegriffOE Organisationseinheit

AA BBAA BB

Zugriff aufIO der OE des Mitarbeiters

Zugriff aufIO der OE des Mitarbeiters

Zugriff nach demLokationsprinzip

Zugriff nach dem Betreuerprinzip

Zugriff auf IO des OBPartnerverbund

Zugriff auf ein IO mitGesamtbankrechten

Abbildung 14. Graphische Darstellung der Zugriffsprinzipien. Bemerkung. Für alle Anwendungsfälle und Zugriffsprinzipien (außer dem Gesamtbankrechtprinzip und Sonderrechtprinzip) gelten folgende zwei Einschränkungen:

- Ein Mitarbeiter darf nicht auf die Informationsobjekte, die ihm persönlich zugeordnet sind schreibend zugreifen (z.B. Kontodaten seines eigenen Kontos ändern).

- Auf VIP-Informationsobjekte dürfen nur Mitarbeiter zugreifen, bei denen VIP-Attribut gesetzt ist.

Im Folgenden werden Anwendungsfälle detailliert beschrieben:

Anwendungsfall 1: Zugriff auf IO des OB Partnerverbund. Beschreibung Partnerverbunddaten sollen geändert werden. Unter anderem kann es

sich hier um das Anlegen / Löschen eines Partnerverbunds handeln, oder allgemein um die Änderung der Verträge, Konditionen, Bezeichnungen und weiteren dem Partnerverbund zugeordneten Informationsobjekte.

Akteur(e) - Gruppenbetreuer - Zur selben Organisationseinheit (bzw. übergeordneter OE) wie

Partnerverbund zugeordneter Mitarbeiter - Mitarbeiter mit Gesamtbankzugriffsrechten - Mitarbeiter mit entsprechendem Sonderrecht

Beschränkungen - Informationsobjekt gehört nicht dem Mitarbeiter (z.B. kein eigenes Konto)

- Erfüllung des VIP Prinzips Informationsobjekte Dem Partnerverbund zugeordnete Informationsobjekte und die den

gemäß der Ordnungsbegriffhierarchie (s. Abbildung 11) dem Partnerverbund zugeordneten Ordnungsbegriffen (Partner, Kunde,





Konto) zugeordnete Informationsobjekte. Enthält Anwendungsfälle

- Zugriff auf IO des OB Partner - Zugriff auf IO des OB Kunde - Zugriff auf IO des OB Konto

Spezialfall des Anwendungsfalls

------

Anwendbare Zugriffsprinzipien

- Lokationsprinzip - Betreuerprinzip - Gesamtbankrechtprinzip - Sonderrechtprinzip - VIP Prinzip

Anwendungsfall 2: Zugriff auf IO des OB Partner. Beschreibung Partnerdaten sollen geändert werden. Unter anderem kann es sich um

das Anlegen / Löschen eines Partners handeln, oder allgemein um die Änderung der Verträge, Konditionen, Bezeichnungen und weiteren dem Partner zugeordneten Informationsobjekte.

Akteur(e) - Gruppenbetreuer - Partnerbetreuer - Zur selben Organisationseinheit (bzw. übergeordneter OE) wie

Partner zugeordneter Mitarbeiter - Mitarbeiter mit Gesamtbankzugriffsrechten - Mitarbeiter mit entsprechendem Sonderrecht


- Erfüllung des VIP Prinzips Informationsobjekte Dem Partner zugeordnete Informationsobjekte und die den gemäß der

Ordnungsbegriffhierarchie (s. Abbildung 11) dem Partner zugeordneten Ordnungsbegriffen (Kunde und Konto) zugeordnete Informationsobjekte.

Enthält Anwendungsfälle

- Zugriff auf IO des OB Kunde - Zugriff auf IO des OB Konto

Spezialfall des Anwendungsfalls

- Zugriff auf IO des OB Partnerverbund



Anwendungsfall 3: Zugriff auf IO des OB Kunde. Beschreibung Kundendaten sollen geändert werden. Unter anderem kann es sich um

das Anlegen / Löschen eines Kunden handeln, oder allgemein um die Änderung der Verträge, Konditionen, Bezeichnungen und weiteren dem Kunde zugeordneten Informationsobjekte.

Akteur(e) - Gruppenbetreuer - Partnerbetreuer - Generalist - Spezialist - Zur selben Organisationseinheit (bzw. übergeordneter OE) wie

Kunde zugeordneter Mitarbeiter - Mitarbeiter mit Gesamtbankzugriffsrechten - Mitarbeiter mit entsprechendem Sonderrecht





- Erfüllung des VIP Prinzips Informationsobjekte Dem Kunden zugeordnete Informationsobjekte und die den gemäß der

Ordnungsbegriffhierarchie (s. Abbildung 11) dem Kunden zugeordneten Konten zugeordnete Informationsobjekte.

Enthält Anwendungsfälle

- Zugriff auf IO des OB Konto

Spezialfall der Anwendungsfälle

- Zugriff auf IO des OB Partnerverbund - Zugriff auf IO des OB Partner



Anwendungsfall 4: Zugriff auf IO des OB Konto. Beschreibung Kontodaten sollen geändert werden. Unter anderem kann es sich um

das Anlegen / Löschen eines Kontos handeln, oder allgemein um die Änderung der Verträge, Konditionen, Bezeichnungen und weiteren dem Konto zugeordneten Informationsobjekte.

Akteur(e) - Gruppenbetreuer - Partnerbetreuer - Generalist - Spezialist - Bankangestellte - Zur selben Organisationseinheit (bzw. übergeordneter OE) wie

Konto zugeordneter Mitarbeiter - Mitarbeiter mit Gesamtbankzugriffsrechten - Mitarbeiter mit entsprechendem Sonderrecht


- Erfüllung des VIP Prinzips Informationsobjekte Dem Konto zugeordnete Informationsobjekte Enthält Anwendungsfälle

------


- Zugriff auf IO des OB Partnerverbund - Zugriff auf IO des OB Partner - Zugriff auf IO des OB Kunde



Anwendungsfall 5: Zugriff auf ein VIP Informationsobjekt. Beschreibung Ein Mitarbeiter braucht Zugriff auf ein VIP Informationsobjekt. Zugriff

wird gewährt, falls der Mitarbeiter nach einem der Zugriffsprinzipien zugriffsberechtigt ist und auf VIP Informationsobjekte zugreifen darf (VIP Mitarbeiter).

Akteur(e) VIP-Bankmitarbeiter: - Gruppenbetreuer - Partnerbetreuer - Generalist




- Spezialist - Bankangestellte - Zur selben Organisationseinheit (bzw. übergeordneter OE) wie

Konto zugeordneter Mitarbeiter - Mitarbeiter mit Gesamtbankzugriffsrechten - Mitarbeiter mit entsprechendem Sonderrecht


- Erfüllung des VIP Prinzips Informationsobjekte Allgemein Informationsobjekt Enthält Anwendungsfälle

- Zugriff auf IO des OB Partnerverbund - Zugriff auf IO des OB Partner - Zugriff auf IO des OB Kunde - Zugriff auf IO des OB Konto





Anwendungsfall 6: Zugriff auf ein Informationsobjekt nach dem Sonderrechtprinzip. Beschreibung Ein Mitarbeiter braucht Zugriff auf ein Informationsobjekt, auf den er

gemäß dem Betreuerprinzip und Lokationsprinzip kein Zugriff bekommt. Da die Erteilung der Gesamtbankrechte Need-to-Know-Prinzip (s. Kapitel 1.3) verletzt, wird dem Mitarbeiter ein Sonderrecht für den Zugriff auf ein Informationsobjekt, bzw. Informationsobjektgruppe vom Administrator der Zugriffssteuerung statisch zugeteilt.

Akteur(e) Allgemeiner Bankmitarbeiter Beschränkungen -------- Informationsobjekte Allgemeines Informationsobjekt Enthält Anwendungsfälle

- Zugriff auf IO des OB Partnerverbund - Zugriff auf IO des OB Partner - Zugriff auf IO des OB Kunde - Zugriff auf IO des OB Konto - Zugriff auf ein VIP Informationsobjekt.


- Zugriff auf IO des OB Partnerverbund - Zugriff auf IO des OB Partner - Zugriff auf IO des OB Kunde - Zugriff auf IO des OB Konto - Zugriff auf ein VIP Informationsobjekt.


- Sonderrechtprinzip

Anwendungsfall 7: Zugriff auf ein Informationsobjekt mit Gesamtbankrechten. Beschreibung Ein Mitarbeiter mit Gesamtbankrechten braucht Zugriff auf ein IO

Informationsobjekt. Akteur(e) Allgemeiner Bankmitarbeiter Beschränkungen ------



Informationsobjekte Allgemeines Informationsobjekt Enthält Anwendungsfälle



-----


- Gesamtbankrechtprinzip

3.4.4 Zugriffsregeln In diesem Kapitel werden die Regeln, die von der Zugriffssteuerung beim Treffen einer Entscheidung über die Ablehnung oder Gewährung eines Zugriffs auf ein Informationsobjekt benutzt werden vorgestellt. Um an dieser Stelle die Lesbarkeit der Regeln zu gewährleisten werden die Regeln im Datalog [KEMP01], [PH05] Format dargestellt. Außerdem werden die Regeln so konfiguriert, dass die zusammengesetzten Regeln mithilfe der „und“-Verknüpfung verknüpft werden können. Bei der späteren Implementierung (s. Kapitel 4, Architekturmodell) werden die Regeln allerdings in XACML Format (s. Anhang) überführt, denn die Regeln in XACML Format sind besser maschinenlesbar.

Die Syntax von Datalog lässt sich am einfachsten mithilfe eines Beispiels erklären.

Beispiel. Die Regel Nicht_eigenes_Konto(MA, KTO) ist erfüllt, falls ein Konto (KTO) nicht dem Mitarbeiter (MA) selbst gehört.

Nicht_eigenes_Konto(MA, KTO) :-

Mitarbeiter_nicht_Kunde(MA, KUNDE) ,

Konto_gehoert_Kunde(KUNDE, KTO).

In Worten formuliert bedeutet das:Ein Konto gehört nicht dem Mitarbeiter, wenn

Bedingung1 erfüllt ist UND

Bedingung2 erfüllt ist. Abbildung 15. Datalog Syntax [PH05].

Wörter in Großbuchstaben kennzeichnen dabei die von der Zugriffssteuerung benutzten Variablen oder übergebenen Parameter. Anstelle des Operators UND kann auch Operator ODER eingesetzt werden.

Die hier definierten Regeln werden in zwei Klassen aufgeteilt, atomare und zusammengesetzte Regeln. Auf der Basis der in dem Kapitel 3.4.2 definierten Zugriffsprinzipien kann man folgende Zugriffsregeln ableiten:

1. Atomare Regeln.

- MA_ist_zuständig_für_OE(MA, OE). Die Regel ist erfüllt, falls eine Relation gehört_zu (s. Abbildung 11) zwischen dem Mitarbeiter (MA) und der Organisationseinheit (OE) existiert.

- OB_gehört_zu_OE(OB, OE). Die Regel ist erfüllt, falls eine Relation gehört_zu (s. Abbildung 11) zwischen dem Ordnungsbegriff (OB) und der Organisationseinheit (OE) existiert (auch über die Organisationseinheitenhierarchie).





- Ordnungsbegriff_für_IO(OB, IO). Die Regel ist erfüllt, falls eine Relation (s. Abbildung 11) zwischen dem Informationsobjekt (IO) und dem Ordnungsbegriff (OB) existiert. (Informationsobjekt ist dem Ordnungsbegriff zugeordnet).

- Betreuer_betreut_Partnerverbund(MA, PV). Die Regel ist erfüllt, falls der Mitarbeiter (MA) ein Gruppenbetreuer des Partnerverbunds (PV) ist.

- Betreuer_betreut_Partner (MA, PA). Die Regel ist erfüllt, falls der Mitarbeiter (MA) ein Partnerbetreuer des Partners (PA) ist.

- Betreuer_betreut_Kunde(MA, KD). Die Regel ist erfüllt, falls der Mitarbeiter (MA) ein Spezialist oder Generalist des Kundes (KD) ist.

- Mitarbeiter_nicht_Kunde(MA, IO). Die Regel ist erfüllt, falls der Mitarbeiter (MA) nicht der Kunde ist, dem dieses Informationsobjekt (IO) zugeordnet ist. (z.B. falls der Mitarbeiter nicht der Kontoinhaber des Kontos ist, dem IO zugeordnet ist)

- Betreuer_ist_Stellvertreter_von_Betreuer(B1, B2). Die Regel ist erfüllt, falls Betreuer B1 Stellvertreter des Betreuers B2 ist.

- MA_ist_Vorgesetzte_MA(MA1, MA2). Die Regel ist erfüllt, falls Mitarbeiter MA1 Vorgesetzte des Mitarbeiters MA2 ist.

- MA_ist_Leiter_von_OE(MA, OE). Die Regel ist erfüllt, falls Mitarbeiter MA Leiter der Organisationseinheit OE ist.

- OB_Kunde(OB). Die Regel ist erfüllt falls das Ordnungsbegriff (OB) vom Typ Kunde ist.

- OB_Konto(OB). Die Regel ist erfüllt falls das Ordnungsbegriff (OB) vom Typ Konto ist.

- Mitarbeiter_hat_Gesamtbankrechte(MA). Die Regel ist erfüllt, falls Mitarbeiter (MA) Gesamtbankrechte besitzt.

- VIP_oder_NOT_VIP_MA_und_IO(MA, IO). Die Regel ist erfüllt, entweder falls das Informationsobjekt (IO) und Mitarbeiter (MA) beide VIP Attribut haben, oder falls das Informationsobjekt (IO) und Mitarbeiter (MA) beide NICHT_VIP Attribut haben, oder falls nur der Mitarbeiter (MA) VIP Attribut besitzt.

- Sonderrechtzugriff(MA, OB). Die Regel ist erfüllt, falls Mitarbeiter (MA) ein Sonderzugriffsrecht auf den Ordnungsbegriff (OB) besitzt.

- Sonderrechtzugriff(MA, IO). Die Regel ist erfüllt, falls Mitarbeiter (MA) ein Sonderzugriffsrecht auf das Informationsobjekt (IO) besitzt.

2. Zusammengesetzte Regeln. - Betreuerzugriff.

Ein Gruppenbetreuer darf auf die Informationsobjekte eines ihm zugeordneten Partnerverbunds zugreifen. Betreuer_Zugriff(GRUPPENBETREUER, IO) :-

Betreuer_betreut_Partnerverbund (GRUPPENBETREUER, VERBUND),

Ordnungsbegriff_für_IO(VERBUND, IO), VIP_oder_NOT_VIP_MA_und_IO(GRUPPENBETREUER, IO),




Mitarbeiter_nicht_Kunde(GRUPPENBETREUER, IO).

Ein Partnerbetreuer darf auf die Informationsobjekte eines ihm zugeordneten Partners zugreifen. Betreuer_Zugriff(PARTNERBETREUER, IO) :-

Betreuer_betreut_Partner(PARTNERBETREUER, PARTNER), Ordnungsbegriff_für_IO(PARTNER, IO), VIP_oder_NOT_VIP_MA_und_IO(PARTNERBETREUER, IO), Mitarbeiter_nicht_Kunde(PARTNERBETREUER, IO).

Ein Kundenbetreuer darf auf die Informationsobjekte eines ihm zugeordneten Kunden zugreifen. Betreuer_Zugriff(KUNDENBETREUER, IO) :-

Betreuer_betreut_Kunde(KUNDENBETREUER, KUNDE), Ordnungsbegriff_für_IO(KUNDE, IO), Mitarbeiter_nicht_Kunde(MA, KUNDE), VIP_oder_NOT_VIP_MA_und_IO(KUNDENBETREUER, IO), Mitarbeiter_nicht_Kunde(KUNDENBETREUER, IO).

Ein Generalist darf auf die Informationsobjekte eines ihm zugeordneten Kunden zugreifen. Betreuer_Zugriff(GENERALIST, IO):-

Betreuer_betreut_Kunde(GENERALIST, KUNDE), Ordnungsbegriff_für_IO(KUNDE, IO), VIP_oder_NOT_VIP_MA_und_IO(GENERALIST, IO), Mitarbeiter_nicht_Kunde(GENERALIST, IO).

Ein Spezialist darf auf die Informationsobjekte eines ihm zugeordneten Kunden zugreifen. Betreuer_Zugriff(SPEZIALIST, IO):-

Betreuer_betreut_Kunde(SPEZIALIST, KUNDE), Ordnungsbegriff_für_IO(KUNDE, IO), VIP_oder_NOT_VIP_MA_und_IO(SPEZIALIST, IO), Mitarbeiter_nicht_Kunde(SPEZIALIST, IO).

- Stellvertreterzugriff. Stellvertreter eines Mitarbeiters darf auf die Informationsobjekte, auf die der Mitarbeiter selbst zugreifen darf, ebenfalls zugreifen. Stellvertreter_Zugriff(STELLVERTRETER, IO):-

Betreuer_ist_Stellvertreter_von_Betreuer(STELLVERTRETER, BETREUER), Betreuer_Zugriff(BETREUER, IO).

- Vorgesetztenzugriff. Vorgesetzte eines Mitarbeiters darf auf die Informationsobjekte, auf die der Mitarbeiter selbst zugreifen darf, ebenfalls zugreifen. Vorgesetzten_Zugriff(VORGESETZTE, IO):-

MA_ist_Vorgesetzte_MA(VORGESETZTE, BETREUER), Betreuer_Zugriff(BETREUER, IO), VIP_oder_NOT_VIP_MA_und_IO(VORGESETZTE, IO).

- Organisationseinheitsleiterzugriff. Leiter einer Organisationseinheit darf auf alle Informationsobjekte, die der Organisationseinheit zugeordnet sind, zugreifen. OE_Leiter_Zugriff(LEITER, IO):-

MA_ist_Leiter_von_OE(LEITER, OE), OB_gehört_zu_OE(OB, OE),




Ordnungsbegriff_fur_IO(OB, IO). VIP_oder_NOT_VIP_MA_und_IO(LEITER, IO), Mitarbeiter_nicht_Kunde(LEITER, IO).

- Springerzugriff. s. Betreuerzugriff.

- Azubizugriff. s. Lokationszugriff.

- Lokationszugriff. Mitarbeiter einer Organisationseinheit darf auf die der Organisationseinheit zugeordneten Informationsobjekte zugreifen. Lokationszugriff(MA, IO):- Mitarbeiter_ist_zuständig_für_OE(MA, OE), Ordnungsbegriff_für_IO(OB, IO), OB_gehört_zu_OE(OB, OE),

VIP_oder_NOT_VIP_MA_und_IO(MA, IO), Mitarbeiter_nicht_Kunde(MA, IO).

- Gesamtbankrechtzugriff. Ein Mitarbeiter mit den Gesamtbankrechten hat unbeschränkten Zugriff auf alle Informationsobjekte der Bank. Gesamtbankrecht_Zugriff(MA, IO):-

Mitarbeiter_hat_Gesamtbankrechte(MA). - Sonderrechtzugriff.

Ein Mitarbeiter mit einem Sonderrecht darf auf die Informationsobjekte, bzw. Ordnungsbegriffe die in Sonderrecht definiert sind, zugreifen s. atomare Regeln: Sonderrechtzugriff(MA, OB), bzw. Sonderrechtzugriff(MA, IO).

Um die konkreten Zugriffsanfragen beantworten zu können, werden zusätzlich die Regelpolicies definiert. Eine Regelpolicy ist eine Zusammenfassung der Regeln die zur Auswertung einer konkreten Zugriffsanfrage notwendig sind. (In diesem Sinne sind die oben definierten zusammengesetzten Regeln bereits Regelpolicies). Im Folgenden wird eine Beispielpolicy definiert.

Beispiele für eine Regelpolicy: Sonderrechtzugriff(MA, OB):- Sonderrechtzugriff(MA, OB) ODER Sonderrechtzugriff(MA, IO).

Die Regelpolicies können in PolicySets zusammengefasst werden. PolicySet ist eine Zusammenfassung der Regelpolicies die zur Auswertung einer konkreten Zugriffsanfrage notwendig sind.

Beispiel für PolicySet:

Betreuer_Zugriff_auf_ein_Informationsobjekt(BETREUER, IO):- Betreuer_Zugriff(GRUPPENBETREUER, IO) ODER Betreuer_Zugriff(PARTNERBETREUER, IO) ODER Betreuer_Zugriff(KUNDENBETREUER, IO) ODER Betreuer_Zugriff(GENERALIST, IO) ODER

Betreuer_Zugriff(SPEZIALIST, IO).

Zum Zweck der besseren Lesbarkeit wurden die hier vorgestellten zusammengesetzten Regeln, Regelpolicies und PolicySets nicht im Hinblick auf die Optimierung der Auswertung konfiguriert. Es muss, allerdings, an dieser Stelle noch erwähnt werden, dass eine




entsprechende Reihenfolge der Zusammensetzung (bzw. Auswertung) eine positive Auswirkung auf Performanz der Zugriffssteuerung haben kann. Deswegen muss bei der Implementierung des Regelwerks, bzw. bei der Definition der zusammengesetzten Regeln, Regelpolicies und PolicySets auf die Reihenfolge der Auswertung geachtet werden. Beispielsweise könnte die Verwendung der Policy Betreuer_Zugriff(SPEZIALIST, IO) an erster Stelle im PolicySet Betreuer_Zugriff_auf_ein_Informationsobjekt(BETREUER, IO) eine Performanzsteigerung der Zugriffssteuerung in einer Bank gewährleisten, denn es ist vorstellbar, dass es in einer Bank im Schnitt mehr Spezialisten auf ein Informationsobjekt zugreifen, als Gruppenbetreuer.

Außerdem sind die hier dargestellten Regeln so konfiguriert, dass sie immer eine Antwort JA / NEIN / NICHT_ANWENDBAR / FEHLER liefern. Es stellt sich aber eine gerechte Frage: Wie können die Anwendungen die konkrete Zugriffsart (read, write, append, usw.) des Mitarbeiters auf ein Informationsobjekt feststellen? Die Information über die Zugriffsart, welche der Mitarbeiter auf einem Informationsobjekt ausüben darf wird im Arbeitsplatzprofil (genauer: in der Klasse Statische Autorisierung) festgehalten. In dem Attribut Funktion der Klasse Statische Autorisierung wird die Funktionalität, die ein Mitarbeiter ausüben darf festgehalten, z.B. Funktionalität „Partnerdaten bearbeiten“ (also in der Rolle Partnerbetreuer agieren) und Berechtigungen des Mitarbeiters bei der Ausführung dieser Funktion (z.B. Erlaubnis Partneradresse ändern, oder Verbot einen neuen Partner anlegen zu können) definiert.

In diesem Kapitel wurden ein fachliches Modell und Berechtigungsstruktur einer Beispielgroßbank definiert. In einer realen Großbank gibt es, natürlich, abweichende Berechtigungsstrukturen. Außerdem ist in einer realen Großbank das Datenmodell viel komplizierter aufgebaut, denn das hier vorgestellte Datenmodell ist zum Zweck der besseren Verständlichkeit vereinfacht dargestellt.

Nächstes Kapitel beschäftigt sich mit der Architektur der Zugriffssteuerung. Ausgehend von einem Internationalen Standard (ISO/IEC 10181-3) für den Aufbau der Zugriffssteuerung wird dort eine mögliche Architektur der Zugriffssteuerung dargestellt.




4 Architektur der Zugriffssteuerung

In diesem Kapitel wird ein Entwurf des Architekturmodells der Zugriffssteuerung beschrieben. Bei der Architekturlösungsermittlung haben sich einige Tatsachen herausgestellt, die einen wesentlichen Einfluss auf die zukünftige Architektur haben:

- In der Softwarelandschaft einer Großbank (z.B. HVB) existieren mehrere hunderte von Anwendungen, die die Funktionalität der Zugriffssteuerung verwenden werden.

- Die einheitliche Zugriffssteuerung soll die reibungslose Funktionalität sowohl der Anwendungen die nach den standardisierten Zugriffsprinzipien Zugriffsprüfung brauchen, als auch der Anwendungen, die eigene von den standardisierten Zugriffsprinzipien abweichende Zugriffsprinzipien benutzen, gewährleisten.

Aus diesen Gründen wäre es wünschenswert zwei Varianten der Zugriffssteuerung einzuführen:

1. Für die Anwendungen, die nach den standardisierten Zugriffsprinzipien Zugriffsprüfung brauchen, wird die Variante der Zugriffssteuerung relevant sein, in der die Pflege der Zugriffsregeln und Zugriffsentscheidung von der Zugriffssteuerungskomponente durchgeführt wird. Den betroffenen Anwendungen bleibt nur die Durchsetzung der Entscheidungen der Zugriffsteuerung durchzuführen (s. Abbildung 16: Variante 1 - Ausgelagerte Zugriffsprüfung).

2. Für die Anwendungen die eigene von den standardisierten Zugriffsprinzipien abweichende Zugriffsprinzipien benutzen wird die Zugriffssteuerung nur im Hinblick auf die Bereitstellung der optimierten Informationsbasis erweitert. Die Zugriffsentscheidungs- und Zugriffsdurchsetzungsfunktionalität werden von den Anwendungen ausgeübt. Genauso bleibt die Pflege des Regelwerks und der Zugriffsregeln in dem Verantwortungsbereich der betroffenen Anwendungen (s. Abbildung 16: Variante 2 - Zugriffsprüfung in der Anwendung).

In der Abbildung 16 werden diese beiden Lösungsmöglichkeiten dargestellt. Wie man aus der Abbildung entnehmen kann, übernimmt die Zugriffssteuerungskomponente bei der Variante 1 folgende Aufgaben:

- Bereitstellung einer einheitlichen standardisierten Schnittstelle für die Zugriffsanfragen, bzw. -antworten.

- Zentralisierte Verwaltung der Regeln der Zugriffssteuerung.

- Auswertung der Zugriffsanfragen, bzw. Zugriffsregeln.

- Bereitstellung einer Informationsbasis der Zugriffssteuerung für die performanzoptimierte Informationsbereitstellung.

Die Variante 2 ist konzipiert mit dem Ziel den nutzenden Anwendungen die optimierte Informationsbasis bereitzustellen, wobei die Zugriffsentscheidung und Verwaltung der Zugriffsregeln in dem Aufgabenbereich der nutzenden Anwendungen liegt. Wie bereits erwähnt können in der Anwendungslandschaft einer Großbank mehrere hunderte von Anwendungen existieren, wobei jede Anwendung die Zugriffsregeln, bzw. Zugriffssteuerung auf eigene Art und Weise implementiert.


Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung

Variante 1: Ausgelagerte Zugriffprüfung Variante 2: Zugriffprüfung in der Anwendung

Anwendung Anwendung

Zugriffssteuerung

Zugriffssteuerung

Schnittstelle der Zugriffssteuerung- von nutzender Anwendung übergebene

Informationen- von Querschnittfunktion gelieferte

Information



Information

Regeln der Zugriffssteuerung-Verwaltung der Regeln- Auswertung der Regeln- Steuerung des Zugriffs




Informationsbasis der Zugriffssteuerung- Informationen verwalten- Information zur Verfügung stellen




Information



Information



Abbildung 16. Architekturmodell [PH05]. Deswegen könnte die Vereinheitlichung der Zugriffsregeln, bzw. der Zugriffssteuerung solcher Anwendungen einen für die Bank unvertretbaren Kostenaufwand mit sich bringen. Die Anwendungen, die Variante 2 nutzen, sollen daher nur im Hinblick auf die Nutzung der Schnittstelle der Zugriffssteuerung für den Zugriff auf die optimierte Informationsbasis angepasst werden.

4.1 Standard für das Architekturmodell der Zugriffssteuerung

Die Zugriffskontrolle sollte gemäß dem Internationalen Standard ISO/IEC 10181-3 [ISO96], [BIBU04] gestaltet werden. In diesem Kapitel werden die Anforderungen an die Architektur der Zugriffssteuerungskomponente gemäß diesem Standard beschrieben.

Der Standard definiert folgende Komponenten eines Autorisierungssystems:

1. Initiator – die Entität, z.B. eine Person oder eine Anwendung, die den Zugriff auf eine Ressource verlangt.

2. Target – Die IT – Ressource, auf die zugegriffen werden soll.

3. Access Enforcement Function (AEF) - Die Funktion, die sicherstellt, dass nur berechtigte Zugriffe auf die Ressourcen erlaubt sind (Durchsetzungsfunktion).

4. Access Desision Function (ADF) - Die Funktion, die entscheidet, ob eine Zugriffsanfrage berechtigt ist, oder nicht (Entscheidungsfunktion).

5. Access Control Information (ACI) – Jede Information, die für die Zugriffskontrolle relevant ist, d.h. statische Attribute des Initiators und Ressource, Zugriffsregeln sowie jede kontextabhängige Information über die Zugriffsanfrage. Statische Attribute des Initiators und Ressource sind z.B. am Beispiel Bank die Zugehörigkeit des Benutzers bzw. eines Kontos zu einer Abteilung einem Standort oder Organisationseinheit usw.

6. Access Control Decision Information (ADI) – Alle ACI, die von der ADF zur Auswertung einer spezifischen Zugriffsanfrage berücksichtigt werden.




InitiatorDurchsetzungs-

funktion(AEF)

Entscheidungs-Funktion

(ADF)

GespeicherteACI

EntscheidungEntscheidungs-anfrage

Zugriffsanfrage BerechtigteZugriffsanfrage

Ressource

Abbildung 17: Autorisierungsmodell [ISO96].

Entscheidungsfunktion (ADF) bezieht sich bei der für ihre Entscheidung benötigten Informationen (ADI) auf die Initiator-ACI, Ressource-ACI und Zugriffsanfrage-ACI. Außerdem nutzt die Entscheidungsfunktion die Regelpolicies (Access Control Policy Rules) und kontextuelle Informationen, z.B. Zeit und Ursprung der Zugriffsanfrage aus (s. Abbildung 20).

Die folgende Abbildung veranschaulicht die Informationen, welche die ADF bei ihrer Entscheidung berücksichtigen kann:

ADF

Kontext-Informationen

Target ADI

EntscheidungEntscheidungs-Anfrage

Initiator ADI

ZugriffsanfrageADI

AutorisierungPolicy Regeln

GespeicherteADIs

Abbildung 18: Entscheidungsfunktion (ADF) und Informationen (ADI) [ISO96].

Wie in der Abbildung dargestellt kann die Entscheidungsfunktion bei ihrer Entscheidung folgende Informationen berücksichtigen:

- Initiator ADI. Informationen über den Benutzer (Person), oder eine Anwendung, die den Zugriff auf eine bestimmte Ressource anfordert.

- Target ADI. Informationen über die Ressource, auf die zugegriffen werden soll. Das können bestimmte Attribute der Ressource sein, die für die Auswertung der Zugriffsanfrage relevant sind.

- Zugriffsanfrage ADI. Informationen über die Zugriffsanfrage, z.B. Uhrzeit, ID und Netzwerklokation der anfragenden Maschine usw.





- Kontextinformationen. Informationen über den Kontext, in dem die Zugriffsanfrage ausgelöst wurde. Dass können z.B. Informationen über die Historie der Zugriffsanfrage (wie diese Zugriffsanfrage zustande gekommen ist), oder Informationen über den aktuellen Status des Systems sein.

- Policy - Regeln, bzw. Regeln der Zugriffssteuerung, die für die Auswertung dieser konkreten Anfrage relevant sind.

Eine Berechtigungspolicy (Access Control Policy) ist eine Sammlung von Regeln, auf deren Basis die ADF ihre Entscheidungen trifft. Berechtigungspolicies können regel- oder identitätsbasiert sein. Regelbasierte Policies sind allgemein in dem System gültig, identitätsbasierte Policies dagegen enthalten Regeln, die für spezifische Initiatoren oder Gruppen von Initiatoren definiert sind. Gemäß dieser Unterteilung gehören gruppen- und rollenbasierte Autorisierungspolicies zu den identitätsbasierten Policies.

Bemerkung. Das oben beschriebene ISO/IEC 10181-3 Standard definiert den Aufbau einer allgemeinen Querschnittskomponente für die Autorisierung, wie sie in Informationssystemen eingesetzt werden kann. Es stellt sich, allerdings, die Frage, ob es in großen Systemen ausreichend ist, nur eine solche Komponente zu verwenden, denn bei einer relativ hohen Anfragemenge kann es zu einem „bottleneck“ Problem kommen, was zu Performanzeinbußen führen kann. Eine Lösung wäre z.B. das Einsetzen der SOA (Service-Oriented-Architekture (vgl. Kapitel 4.2) bei der Modellierung der Autorisierungskomponente. In diesem Fall wird es möglich hinter der Service-Schnittstelle mehrere Kopien der Autorisierungskomponente zu verbergen. Die hohe Anfragelast wird dann auf mehrere Komponenten verteilt, was die Auswirkungen des „bottleneck“-Problems minimiert.

Für die Zugriffssteuerung ist eine plattformunabhängige Implementierung erforderlich, die in hohem Maße wieder verwendbar ist. Es ist daher eine Kapselung der geforderten Funktionalität erforderlich. Mit der Implementierung der Zugriffssteuerung als Service - Oriented Architecture (SOA) kann die Zugriffssteuerung als ein Service realisiert werden, was die oben beschriebenen Anforderungen erfüllt.

4.2 Service-Oriented Architecture (SOA)

„Grundlegendes Prinzip einer SOA ist es, Funktionalität als modulare und wieder verwendbare Services zur Verfügung zu stellen. Neue Anwendungen können dann aus bereits existierenden Services „zusammengesetzt“ werden. Man spricht dabei auch von einer losen Koppelung, da es keine starken logischen oder physischen Abhängigkeiten gibt, und zwar weder zwischen den Services untereinander, noch zwischen den Services und den Anwendungen, in denen sie genutzt werden. Somit ist es auch leicht möglich, laufende Anwendungen durch Austausch einzelner Services zu modifizieren, zu erweitern oder zu optimieren.“ [SCHM05]

Service-Oriented-Architectur ist ein Architekturstil, der Vorgaben darüber macht, wie die geforderte Funktionalität implementiert wird (vgl. PH05). Ein Service repräsentiert im Allgemeinen einen Dienst oder Dienstleistung, die von verschiedenen Anwendungen (bzw. anderen Services) benutzt werden kann.

„Dienste (engl. Services) sind selbstbeschreibende, offene Komponenten, die eine schnelle, kostengünstige Implementierung verteilten Anwendungen ermöglichen sollen“.[BICH05]

Servicebeschreibungen dienen dazu, Schnittstellen, Verhalten, Attribute usw. eines Services zu beschreiben und sind dazu gedacht dem Benutzer, bzw. den Anwendungen Suche, Auswahl und Integration eines Services zu ermöglichen.

In einer Service-Oriented-Architektur werden Services als grundlegende Bausteine eines Systems eingesetzt.



Module Module Module




Shared ServiceShared Service Shared Service Shared ServiceShared Service Shared Service


Anwendungen







Anwendungen Abbildung 19. Service-Oriented-Architecture (SOA).

In der Abbildung 19 ist ein Beispiel für den Aufbau eines Systems mit dem Einsatz der Service-Oriented-Architectur dargestellt. Dabei werden Services in die systeminterne Services und Shared Services aufgeteilt. Systeminterne Services implementieren die Funktionalität des Systems, die nach außen durch die shared Services den anderen Anwendungen (bzw. Services) zur Verfügung gestellt wird. Module des Systems sind ebenfalls als eigenständige Services implementiert. Graue Umrandung eines Moduls repräsentiert dabei die Service-Schicht (s. unten) eines Modulservices.

Ein Service wird in verschiedene aufeinander aufbauende Schichten aufgeteilt. In der folgenden Abbildung 20 sind die einzelnen Schichten eines Service dargestellt.

Service-Nehmer

Kommunikationsschicht

SOA

Service-Schicht

Integration

Abstraktion

Connectivity

Ressourcen

Que

rsch

nitt

baus

tein

e

Abbildung 20. Schichtenmodel eines Services [PH05].

Ein Servicenehmer (Anwendung oder ein anderer Service) kann auf ein Service über die Kommunikationsschicht zugreifen. Für die Kommunikation zwischen dem Service und




Servicenehmer werden verschiedene XML-basierte Kommunikationssprachen (z.B. SOAP – Simple Objekt Access Protokoll, [BICH05]) eingesetzt.

Ein Service wird in Service-, Integration-, Abstraktion- und Connectivityschicht unterteilt [PH05].

- In der Service-Schicht wird der Service mit den angebotenen Schnittstellen definiert. Hier werden Serviceattribute wie Serviceparameter, Datentypen Methodennamen und -parameter definiert, die für einen Zugriff auf den Service und für die Nutzung der Funktionalität des Service notwendig sind.

- In der Integrationsschicht wird eigentliche die Funktionalität (Logik) des Service implementiert.

- Transformation des Datenmodells der Ressourcen in eine interne Repräsentation geschieht in der Abstraktionsschicht. Hiermit wird eine Abkoppelung des Service von den Ressourcen gewährleistet.

- In der Connectivity-Schicht wird die Funktionalität für die Durchführung des technischen Zugriffs auf Ressourcen realisiert (vgl. [PH05]).

Einsatz von SOA ermöglicht monolithische Systeme durch lose gekoppelte Architekturen zu ersetzen. Dies geschieht mit dem Ziel geringere Beschaffungs- und Wartungskosten zu erreichen (z.B. durch Unabhängigkeit von bestimmten Herstellern, Plattformen und eingesetzten Technologien). Außerdem werden die Module für die Gewährleistung der Funktionalität problemlos austauschbar und erweiterbar sein, was bei einer Festimplementierung nicht gewährleistet werden kann. Ein weiterer wichtiger Aspekt ist die Wiederverwendbarkeit einzelnen Systembausteinen (Services).

Außerdem bringt die Implementierung der Zugriffssteuerung als Service keinen Mehraufwand im Vergleich zur klassischen Realisierung [PH05].

4.3 Services der Zugriffssteuerung

Es hat sich als zweckmäßig bezüglich der Anforderungen an die Zugriffssteuerung herausgestellt, die Zugriffssteuerungskomponente in mehrere Services aufzuteilen. Diese Aufteilung wird in der Abbildung 21 veranschaulicht.

ZugriffsprüfungInformationsbereitstellung

Service Zugriffssteuerung

Pflege Zugriffsregeln,Zugriffspolicies und

Einzelrechte

Service

ServiceFunktionen

Service Datenpflege

Datenzugriff

Service Datenzugriff

ZugriffsprüfungInformationsbereitstellung

Service Zugriffssteuerung

Pflege Zugriffsregeln,Zugriffspolicies und

Einzelrechte

Service

ServiceFunktionen

Service Datenpflege

Datenzugriff

Service Datenzugriff

Abbildung 21. Services der Zugriffssteuerung. Wie in der Abbildung dargestellt wird die Funktionalität der Zugriffsteuerung durch Einsatz folgenden Services realisiert:

- Service "Zugriffssteuerung". Funktionalität, bzw. Service-Funktionen der „Zugriffssteuerung“, wie "Informationsbereitstellung" und "Zugriffsprüfung" werden jeweils als eigenständige Services implementiert (s. Abbildung 21). Die Implementierung als eigenständige Services bringt den Vorteil, dass die Funktionalität, die an den Schnittstellen der Services angeboten wird, unabhängig von den konkreten Implementierung, Plattformen, Realisierungstechnologien und Herstellern wird. So kann z.B. bei der Änderung des Regelwerks das gesamte Modul „Service Zugriffsprüfung“ leicht durch einen anderen ersetzt werden, ohne, dass die Änderung am Gesamtsystem notwendig wird.




Informationsanfrage bearbeiten

Service Informationsbereitstellung

Zugriffsanfrage bearbeiten

Service ZugriffsprüfungService

ServiceFunktionen Informationsanfrage bearbeiten

Service Informationsbereitstellung

Zugriffsanfrage bearbeiten

Service ZugriffsprüfungService

ServiceFunktionen

Abbildung 22. Services Informationsbereitstellung und Zugriffsprüfung. Service „Zugriffsprüfung“ wird für die Gewährleistung der Funktionalität der Zugriffssteuerung gemäß Variante 1 – ausgelagerte Zugriffssteuerung (s. Kapitel 4, Abbildung 16) eingesetzt. Hier wird die Funktionalität „Zugriffsanfrage bearbeiten“ realisiert.

Service „Informationsbereitstellung“ wird dagegen für die Gewährleistung der Funktionalität der Zugriffssteuerung gemäß Variante 2 - Zugriffsprüfung in der Anwendung (s. Kapitel 4, Abbildung 16) eingesetzt. Von diesem Service wird die Funktionalität „Informationsanfrage bearbeiten“ angeboten.

- Service „Datenpflege“. Dieses Service stellt dem Administrator der Zugriffsteuerung die Funktionalität „Pflege Zugriffsregeln, Zugriffspolicies und Sonderrechte“ zur Verfügung.

- Service "Datenzugriff ". Die Implementierung als eigenständiger Service ergibt sich aus der Tatsache, dass in der Datenbanklandschaft einer Bank kann sich im Laufe der Zeit vieles ändern, weswegen das Modul Datenzugriff erweiterbar und austauschbar sein soll.

4.4 Architekturmodell

Im Folgenden wird das Architekturmodell der Zugriffssteuerung beschrieben. Dabei wird die Zugriffssteuerungskomponente als ZS (Zugriffssteuerung) bezeichnet.

Das System Zugriffssteuerung besteht aus zwei Teilsystemen (s. Abbildung 23)

• ZS Kern. Hier wird die eigentliche Funktionalität der Zugriffssteuerung implementiert. Unter anderem wird hier vom Service „Zugriffsprüfung“ die Zugriffsprüfung durchgeführt (Variante 1, s. Abbildung 16) und vom Service „Informationsbereitstellung“ die angeforderten Informationen (Beziehungen usw.) für die aufrufende Anwendung ermittelt und an die Anwendung zurückgeliefert (Variante 2, s. Abbildung 16). Außerdem enthält ZS Kern den Service „Datenzugriff“ dessen Aufgabe ist die für die Services „Informationsbereitstellung“ und „Zugriffsprüfung“ notwendigen Informationen aus den Datenbanken der Großbank zu beschaffen, bzw. im Cache in einer optimierten Form zwischenspeichern und an die Services in einer standardisierten Form zu übergeben.

• ZS Datenpflege. Dient der Verwaltung der Regeln, Regelpolicies und Sonderrechte. (s. Kapitel 4.4.2). ZS Datenpflegekomponente wird von dem Administrator der Zugriffssteuerung benutzt um die Zugriffssteuerungsregeln, Regelpolicies und Sonderrechte der Mitarbeiter über die Schnittstelle des Service „Datenpflege“ zu verwalten. Dafür werden vom Administrator entsprechende Tools eingesetzt die vom Service „Datenpflege“ erhaltene Daten über die graphische Oberfläche darstellen können. Außerdem bietet die Komponente eine Schnittstelle für die Komponente Zugriffsentscheidung für den Zugriff auf die für die Zugriffsentscheidung notwendigen Regeln, Regelpolicies und Sonderrechte.




Anwendungen

ZS Kern ZS Datenpflege

DatenbankenDB 1 DB 2 DB 3 DB 4 DB 5 DB …


Datenimport

Direktzugriff

ServiceDatenzugriff

DatenintegrationInformationsbasisInformationsbasis

Daten-ManagerService

ZugriffsprüfungService

Informationsbereitstellung

InformationsmanagerZugriffsentscheidung

Regel_DB

Sonderrechte_DB

Regelverwaltung Rechteverwaltung

ZS Administrator

Policy_DB

Policyverwaltung

Service Datenpflege

Abbildung 23. Architekturmodell Zugriffssteuerung.

4.4.1 Kernkomponente der Zugriffssteuerung Wie bereits erwähnt übernimmt die ZS Kern Komponente folgende zwei Aufgaben:

- Zugriffsanfrage bearbeiten. Dabei wird die über die Schnittstelle des Service Zugriffssteuerung empfangene Zugriffsanfrage an Service „Zugriffsprüfung“ weitergeleitet, wo sie bearbeitet wird, bzw. die Entscheidung über die Gewährung oder Ablehnung einer Zugriffsanfrage getroffen wird. Die Entscheidung wird schließlich an die aufrufende Anwendung zurückgeliefert.

- Informationsanfrage bearbeiten. Die über die Schnittstelle des Service „Zugriffssteuerung“ empfangene Informationsanfrage wird an Service „Informationsbereitstellung“ weitergeleitet, wo sie bearbeitet wird, bzw. die angeforderten Informationen gesammelt werden. Die gesammelten Informationen werden dann an die aufrufende Anwendung zurückgeliefert.

4.4.1.1 Service Zugriffssteuerung In der Abbildung 24 ist die Struktur des Service "Zugriffssteuerung" mit den Service-Funktionen "Zugriffsprüfung" und "Informationsbereitstellung" dargestellt.

In der Service-Schicht der Service „Zugriffssteuerung“ werden die Serviceattributen (Servicebeschreibung) und die angebotenen Schnittstellen definiert. Es sind zwei Schnittstellen:

- Schnittstelle für eine Zugriffsanfrage. Über diese Schnittstelle wird eine Zugriffsanfrage angenommen. Nachdem die Antwort auf die Zugriffsanfrage berechnet wird, wird diese an die anfragende Anwendung zurückgeliefert.




Service

Zugriffssteuerung



ServiceDatenzugriff

ServiceZugriffsprüfung

ServiceInformationsbereitstellung

ServiceSchicht

FachlicheIntegration

Abstraktion

Connectivity

Ressourcen

Abbildung 24. Service Zugriffssteuerung.

- Schnittstelle für eine Informationsanfrage. Hier wird die Informationsanfrage angenommen und die ermittelten Informationen an die anfragende Anwendung zurückgeliefert.

In der Integrationsschicht befindet sich die Logik der Services „Zugriffssteuerung“. Hier sind die Komponenten Service „Informationsbereitstellung“ und Service „Zugriffsprüfung“ angeordnet.

Abstraktionsschicht und Connectivity-Schicht beinhalten die Komponente „Service Datenzugriff“.

Ressourcen umfassen alle Datenbanken der Bank, in denen sich für die Zugriffssteuerung relevante Daten befinden.

4.4.1.2 Service Informationsbereitstellung




ServiceDatenzugriff

ServiceSchicht


Abstraktion

Connectivity

Ressourcen

Informationsmanager

Abbildung 25. Service Informationsbereitstellung.

In der Service-Schicht des Service Informationsbereitstellung wird die Schnittstelle definiert, die vom Service Zugriffssteuerung benutzt wird, um die Informationsanfrage von der Anwendung an den Service Informationsbereitstellung weiterzuleiten bzw. die ermittelten Informationen und Beziehungen an die aufrufende Anwendung zurückzuliefern.

Logik des Service befindet sich in der Service-Schicht „Integration“ in der Komponente „Informationsmanager“ (s. Kapitel 4.4.1.2.1).





Inhalt und Aufbau der Abstraktions-, Connectivity- und Ressourcenschicht unterscheidet sich nicht von dem Inhalt und Aufbau der entsprechenden Schichten des Service „Zugriffssteuerung“ (s. Kapitel 4.4.1.1).

Die aufrufende Anwendung soll anhand der von diesem Service zurückgelieferten Informationen und Beziehungen selber über die Gewährung / Ablehnung des Zugriffs entscheiden.

Dieses Service wird von den Anwendungen benutzt,

- deren Zugriffsprüfung nicht nach den Standardprinzipien erfolgt, deswegen nicht von dem Service Zugriffsprüfung durchgeführt werden kann,

- die für die eigene Entscheidung über die Gewährung / Ablehnung der Zugriffsanfrage weiteren Informationen über die Beziehungen der betroffenen Objekte (Benutzer, Informationsobjekt, Organisationseinheit usw.) brauchen.

Schnittstellenbeschreibung: - Name: Informationsbereitstellung

- Eingabeparameter: - UserID des Benutzers - ID des betroffenen Informationsobjekten, bzw. des Ordnungsbegriffs - ID der aufrufenden Anwendung - ID der ausführenden Funktion - weitere Informationen über die Art der angeforderten Informationen (z.B.

Beziehungen vom Benutzer zum Informationsobjekt usw.) - Kontext Informationen (optional)

- Rückgabewert: Eine standardisierte Datenstruktur, deren Form (Struktur) im System eindeutig definiert ist.

Die aufrufende Anwendung soll in der Lage sein, die vom Service „Informationsbereitstellung“ zurückgelieferten Informationen richtig zu interpretieren, bzw. aufgrund dieser Informationen selber die Entscheidung über die Gewährung / Ablehnung der Zugriffsanfrage zu fällen.

Im System soll festgelegt werden, für welche Anwendungen bzw. Funktionen innerhalb dieser Anwendungen welche Rückgabestrukturen vorgesehen sind. Es soll eine einheitliche Klassifizierung solcher Rückgabestrukturen existieren.

Der Service „Informationsbereitstellung“ bedient sich der Funktionalität der Komponente Informationsmanager, um die an ihn gestellten Anforderungen zu erfüllen.

4.4.1.2.1 Komponente Informationsmanager Aufgabe dieser Komponente ist die Informationen für den Service Informationsbereitstellung vorzubereiten. Dafür soll diese Komponente in der Lage sein, die Anfragen vom Service Informationsbereitstellung richtig zu interpretieren und in Datenzugriffe umsetzen. Außerdem sollen die Informationen strukturiert und in richtiger Form an das Service zurückgeliefert werden.

4.4.1.2.2 Nutzung des Service Informationsbereitstellung Beispiel. Eine Anwendung braucht Informationen dazu, zu welchen Organisationseinheiten ein Benutzer zugeordnet ist.



ServiceZugriffssteuerung

ServiceDatenzugriff


Informationsmanager

Anwendungen1

2

3

4 5

6

7

8

Abbildung 26. Nutzung des Service Informationsbereitstellung

Erläuterung des Ablaufs:

1. Die Anwendung AW ruft den „Service Zugriffssteuerung“ mit Angabe der Parameter UserID, Funktionsnummer, und ID der Informationsanfrage IA-ID auf mit dem Ziel zu ermitteln, zu welchen Organisationseinheiten der User zugeordnet ist.

2. Die über die Schnittstelle vom „Service Zugriffssteuerung“ übernommene Anfrage wird an „Service Informationsbereitstellung“ weitergeleitet.

3. „Service Informationsbereitstellung“ leitet die Anfrage an die Komponente „Informationsmanager“.

4. Komponente „Informationsmanager“ bearbeitet die Anfrage, indem sie die Anfrage dekodiert, ermittelt, welche Daten angefordert sind und die notwendigen Daten vom „Service Datenzugriff“ anfordert.

5. Die gesammelten Daten werden vom „Service Datenzugriff“ an „Informationsmanager“ übergeben.

6. „Informationsmanager“ bringt die gesammelten Daten in eine standardisierte Form (Es soll für jede Anwendung, bzw. Anwendungsfunktion die die Funktionalität des „Service Informationsbereitstellung“ nutzt definiert werden, in welcher Form, bzw. wie strukturiert die Daten zurückgeliefert werden sollen). Die so entstandene Datenstruktur wird an „Informationsbereitstellung“ weitergeleitet.

7. „Informationsbereitstellung“ leitet die Ergebnisse an „Service Zugriffssteuerung“.

8. „Service Zugriffssteuerung“ übergibt die Ergebnisse der Anfrage an die aufrufende Anwendung.




4.4.1.3 Service Zugriffsprüfung




ServiceDatenzugriff

ServiceSchicht


Abstraktion

Connectivity

Ressourcen

Zugriffsentscheidung

Abbildung 27. Service Zugriffsprüfung.

Der Service „Zugriffsprüfung“ bietet in der Service-Schicht eine Schnittstelle für den Service „Zugriffssteuerung“, über die eine Zugriffsanfrage angenommen wird und die Entscheidung über die Ablehnung oder Gewährung der Zugriffsanfrage zurückgegeben wird.

Die gesamte Logik des Service wird in der Komponente Zugriffsentscheidung (s. Kapitel 4.4.1.3.1) implementiert (in der Integrationsschicht).

Inhalt und Aufbau der Abstraktions-, Connectivity- und Ressourcenschicht unterscheidet sich nicht von dem Inhalt und Aufbau der entsprechenden Schichten des Service Zugriffssteuerung (s. Kapitel 4.4.1.1).

Der Service „Zugriffsprüfung“ soll aufgrund der von der aufrufenden Anwendung übergebenen Informationen und der in der internen Datenbank der Zugriffssteuerung enthaltenen Regeln, Regelpolicies und Sonderrechte, eine Entscheidung über die Gewährung / Ablehnung einer Zugriffsanfrage fällen.

Service „Zugriffsprüfung“ wird von den Anwendungen benutzt,

- deren Zugriffsprüfung nach den Standardprinzipien erfolgt, - für die eine Antwort JA / NEIN / FEHLER ausreicht.

Bemerkung. In dem Kapitel 3.4.4 ist als Ergebnis einer Regel-, bzw. Policyauswertung die Antwort JA / NEIN / NICHT_ANWENDBAR / FEHLER definiert, hier wird, allerdings, davon ausgegangen, dass die Antwort NICHT_ANWENDBAR mit der Antwort NEIN gleichgesetzt werden kann.

Schnittstellenbeschreibung: - Name: Zugriffsprüfung

- Eingabeparameter: o UserID des Benutzers o ID des betroffenen Informationsobjektes, bzw. des Ordnungsbegriffs o ID der aufrufenden Anwendung o ID der ausführenden Funktion o Kontext Informationen (optional)

- Rückgabewert: JA / NEIN / FEHLER Service Zugriffsprüfung benutzt die Funktionalität der Komponente Zugriffsentscheidung, um seine Aufgaben durchzuführen.




4.4.1.3.1 Komponente Zugriffsentscheidung Die Komponente Zugriffsentscheidung beschäftigt sich mit der Steuerung der Regelauswertungsreihenfolge, Koordination des gesamten Prozesses Regelauswertung, Beschaffung der für die Regelauswertung notwendigen Informationen und liefert diese an Service „Zugriffsprüfung“ zurück.

Aufbau der Komponente entspricht dem Standard ISO/IEC 10181-3 (s. Kapitel 4.1).

In der Abbildung 28 ist ein Ausschnitt aus dem Gesamtsystem „Zugriffssteuerung“ dargestellt.

ZS Datenpflege

Zugriffssteuerung

Zugriffsentscheidung

Zugriffsanfrage Antwort (Ja/Nein/Undefiniert/Fehler)

Durchsetzungsfunktion

Zugriffsprüfungget_Policy

Policy

get_Regel(ID)

Regel

liefere_Attri

bute(…)

Attribute

Zugriffsanfrage

Entscheidung

Daten-Manager

Regel_DB

Sonderrechte_DB

Policy_DB

Datenzugriff

Anwendungen


Capability Prüfung

Cap

abili

tygü

ltig(

…)

Ents

chei

dung

exist_Sonderrecht(…)

true / false

Abbildung 28. Zugriffsentscheidung.

Der graue Kasten in der Mitte der Abbildung stellt die Komponente „Zugriffsentscheidung“ dar. Zugriffsentscheidung enthält drei weitere Unterkomponenten:

- Durchsetzungsfunktion: Komponente, die zuständig für die Annahme der Zugriffsanfragen und Steuerung des Ablaufs der Zugriffsprüfung ist. Diese Komponente entspricht der im Standard ISO/IEC 10181-3 definierten Komponente „Durchsetzungsfunktion (AEF)“.

- Capability Prüfung: Komponente, die zuständig für die Überprüfung der Gültigkeit einer in der Zugriffsanfrage übergebenen Capability ist.

- Zugriffsprüfung: Komponente, die anhand der Zugriffsanfrageart, der Regelpolicy, bzw. einzelner Regeln der Zugriffssteuerung und Attributen der Zugriffsanfrage über die Gewährung oder Ablehnung des Zugriffs entscheidet.

Komponenten „Capability Prüfung“ und „Zugriffsprüfung“ zusammengefasst entsprechen der in dem ISO/IEC Standard 10181-3 definierten Komponente „Entscheidungsfunktion“.

4.4.1.3.2 Nutzung des Service Zugriffsprüfung Beispiel: Benutzer A3322 ist ein Spezialist für Kunde KdNr.1234 und möchte mit Anwendung AW2211 auf den aktuellen Kontostand (Funktion F1122) des Kontos Nr. K1234 zugreifen. In der Abbildung 29 ist der Ablauf der Zugriffsprüfung schematisch dargestellt.




ZS Datenpflege

Zugriffssteuerung

Zugriffentscheidung

Zugriffsanfrage Antwort (Ja/Nein/Undefiniert/Fehler)

Durchsetzungsfunktion

Zugriffsprüfungget_Policy

Policy

get_Regel(ID)

Regel

liefere_Attri

bute(…)

Attribute

Zugriffsanfrage

Entscheidung

Daten-Manager

Regel_DB

Sonderrechte_DB

Policy_DB

Datenzugriff

Anwendungen


Capability Prüfung

Cap

abili

tygü

ltig(

…)

Ents

chei

dung

1

2

3 4

5

8

9

10

1112

13

14

15

16

exist_Sonderrecht(…)

true / false

6

7

Abbildung 29. Nutzung des Service Zugriffsprüfung.


1. Die Anwendung AW2211 ruft den Service Zugriffsprüfung mit den Parametern: UserID A3322, Funktion F1122, Capability des Benutzers CAP A3322 und IO_NR K1234 auf.

2. Service Zugriffsprüfung leitet die Zugriffsanfrage an die Durchsetzungsfunktion der Zugriffsentscheidung.

3. Die Durchsetzungsfunktion erkennt das Vorhandensein einer Capability in der Parameterliste und leitet alle Parameter in der Anfrage: bool capability_gültig(Capability c, UserID uid, FunktionsID fid, IObjektID ioid) an "Capability Prüfung" weiter.

4. "Capability Prüfung" entscheidet über die Gültigkeit der Capability im Zusammenhang mit den übergebenen Parametern und liefert die Antwort an "Durchsetzungsfunktion" zurück.

Falls "Capability Prüfung" positive Entscheidung liefert, wird Schritt 15 ausgeführt mit dem Antwort "JA" (s. unten).

Falls die Entscheidung der "Capability Prüfung" negativ ausfällt:

5. "Durchsetzungsfunktion" leitet die Anfrage mit allen Parametern an "Zugriffsprüfung" weiter.

6. "Zugriffsprüfung" sendet eine Anfrage exist_Sonderrecht an "ZS Datenpflege" mit allen Parametern.

7. „ZS Datenpflege“ überprüft, ob es womöglich in der Sonderrechte_DB ein entsprechendes Sonderrecht existiert. Falls ja, dann wird Zugriffsanfrage positiv ausgewertet und weiter mit Schritt 14.

8. "Zugriffsprüfung" sendet eine Anfrage get_Policy an "ZS Datenpflege" mit allen Parametern.

9. Entsprechende Policy wird an "Zugriffsprüfung" zurückgeliefert.




10. Die "Zugriffsprüfung" fordert über get_Regel(ID) alle in der Policy eingetragenen Regeln von "ZS Datenpflege".

11. "ZS Datenpflege liefert die angeforderten Regeln an "Zugriffsprüfung" zurück.

12. Die für die Auswertung der Regeln notwendigen Attribute werden über liefere_Attribute(…) von der Komponente "Datenzugriff" gefordert.

13. "Datenzugriff" liefert alle angeforderten Attribute zurück an "Zugriffsprüfung".

14. Anhand der in der Policy definierten Algorithmen und unter Ausnutzung der bekannten Attribute entscheidet "Zugriffsprüfung" über die Gewährung / Ablehnung des Zugriffs und leitet die Entscheidung an "Durchsetzungsfunktion" weiter.

15. "Durchsetzungsfunktion" leitet die Entscheidung an "Service Zugriffsprüfung" weiter.

16. "Service Zugriffsprüfung" generiert neue Capability, bzw. vervollständigt die bereits vorhandene und leitet die Entscheidung zusammen mit der Capability an die aufrufende Anwendung weiter.

4.4.1.4 Service Datenzugriff Komponente „Datenzugriff“ wird als eigenständiger Service implementiert. Gründe dafür sind im Kapitel 4.3 beschrieben.



Direktzugriff

Datenmanager

Adapter Adapter

ServiceSchicht


Abstraktion

Connectivity

Ressourcen

InformationsbasisInformationsbasis

Datenimport

Datenzugriff

Abbildung 30. Service Datenzugriff.

Vom Service „Datenzugriff“ wird eine Vielzahl von Schnittstellen angeboten, um alle möglichen Datenanfragen annehmen und bearbeiten zu können. Die Schnittstellen die vom Service „Datenzugriff“ angeboten werden, befinden sich in der Service-Schicht.

Die eigentliche Logik des Service wird in der Schicht Integration in der Komponente „Datenmanager“ implementiert.

4.4.1.4.1 Komponente Datenmanager Diese Komponente beschäftigt sich mit der Durchführung der Datenzugriffe, wobei das Ziel ist, die Datenzugriffe möglichst leistungsfähig umzusetzen. Dabei soll von dem Nutzer der Komponente verbergt werden, ob die Informationen aus der Zugriffssteuerung - eigenen Informationsbasis oder direkt aus dem Datenbankensystem der Bank stammen.

4.4.1.4.2 Komponente Informationsbasis Aufgabe der Komponente Informationsbasis ist, einen Teil der für die Zugriffssteuerung notwendigen Informationen in einer geeigneter Form lokal zu speichern, um einerseits die




optimierte Datenzugriffe zu ermöglichen und andererseits die Informationen, die nicht direkt in den Datenbanken der Großbank enthalten sind festzuhalten (z.B. einige Beziehungen, die in keiner anderen Datenbank zu finden sind, oder nur mit mehreren Datenbankzugriffen über komplizierte Pfade feststellbar sind).

4.4.1.4.3 Komponente Datenimport Aufgabe dieser Komponente ist, die Informationsbasis in regelmäßigen Abständen mit Daten zu versorgen. Unter anderem soll diese Komponente die Datenkonsistenz in der Informationsbasis gewährleisten, Aktualisierungsvorgänge steuern und für die die Tatsache sorgen, dass die Daten für die Informationskomponente in eine für den Zugriff optimierte Form transformiert werden.

4.4.1.4.4 Komponente Direktzugriff Diese Komponente beschäftigt sich mit der Durchführung der Zugriffe auf die Nachbarsysteme und Datenbanken der Bank mit dem Ziel die für die Zugriffssteuerung notwendigen Informationen zu beschaffen. Es handelt sich dabei um die Online-Zugriffe. Aufgabe der Komponente ist die Datenzugriffe für aufrufende Komponenten und Services zu kapseln (d.h. es soll von den Aufrufern verbergt werden, aus welchen Quellen die Daten beschafft worden sind).

4.4.1.4.5 Nutzung von Service Datenzugriff In der folgender Abbildung wird die Nutzung von Service „Datenzugriff“ dargestellt.

Datenmanager

Datenzugriff

1



Direktzugriff

Datenimport

3 57

6

InformationsbasisInformationsbasis4

9

82

Abbildung 31. Nutzung von Service Datenzugriff


1. Eine Anwendung (in diesem Fall eine Komponente oder ein Service der Zugriffssteuerung) ruft den Service „Datenzugriff“ über eine der Schnittstellen des Service mit Übergabe der notwendigen Parameter.

2. Service „Datenzugriff“ leitet die Anfrage mit allen Parametern an die Service-Komponente „Datenmanager“.

Abhängig von der Art des Aufrufs, bzw. der übergebenen Parameter entscheidet „Datenmanager“ woher die Daten entnommen werden können.

Hier existieren zwei Alternativen (3-4) und (5, 6, 7):

3. Die angeforderten Daten liegen in der „Informationsbasis“ und werden vom „Datenmanager“ von der „Informationsbasis“ angefordert.





4. „Informationsbasis“ liefert die Daten an „Datenmanager“ zurück. Weiter mit Schritt 8.

5. Die angeforderten Daten können über die Komponente „Direktzugriff“ ermittelt werden. „Datenmanager“ fordert die Daten von „Direktzugriff“ Komponente.

6. „Direktzugriff“ Komponente erkennt anhand der übergebenen Parameter, aus welchen Datenbanken, bzw. Anwendungen die Daten entnommen werden können und führt direkte Datenbankzugriffe, bzw. Anwendunsgaufrufe um diese Daten zu bekommen.

7. Die ermittelten Daten werden an „Datenmanager“ weitergeleitet.

8. „Datenmanager“ strukturiert die ermittelten Daten, bzw. bringt sie in eine Standardisierte Form und liefert die so gewonnene Datenstruktur an „Datenzugriff“ weiter.

9. „Datenzugriff“ leitet die Rückgabedatenstruktur an den Aufrufer weiter.

4.4.2 Komponente Datenpflege der Zugriffssteuerung Das Teilsystem "ZS Datenpflege" beschäftigt sich mit der Speicherung der für die Entscheidung der Zugriffssteuerung notwendigen Daten, wie Regeln, RegelPolicies und Sonderrechte. Außerdem stellt dieses Teilsystem über die Schnittstelle des Service „Datenpflege“ dem Administrator der Zugriffssteuerung folgende Funktionalität zur Verfügung:

- Policyverwaltung, (bzw. Verwaltung der PolicySets) - Regelverwaltung, - Rechteverwaltung.

4.4.2.1 Komponente Policyverwaltung Wie bereits oben erwähnt, werden die einzelnen Regeln zu einer Regelpolicy zusammengefasst. Dies erfolgt mit dem Ziel für jeweilige Nutzungsmöglichkeit einen Regelsatz zur Verfügung zu stellen. Außerdem können auch die einzelnen Policies zu PolicySets zusammengefasst werden. In einer Regelpolicy ist demnach folgende Information gespeichert:

- PolicyID. Jeder Anwendung, bzw. Anwedungsfunktion wird eine Policy über PolicyID zugeordnet, mit dem Ziel, dass bei Aufrufen des Service "Zugriffsprüfung" die Komponente Zugriffsprüfung die für die Anwendung, bzw. Anwendungsfunktion relevante Regelpolicy leicht findet. Die Zuordnung von Policies zu den Anwendungen, bzw. Anwendungsfunktionen wird in einer internen Datenbank von "ZS Datenpflege" gespeichert.

- Policyregeln. Eine Menge der ZugriffsregelnID's, die für diese Policy relevant sind.

- Policyauswertungsalgorithmus. Algorithmus, der bei der Auswertung der Policyelementen verwendet wird (vgl. Auswertungsalgorithmen in XACML [XACML]).

PolicySet wird analog zu Regelpolicy aufgebaut, mit dem Unterschied, dass im PolicySet anstatt Regeln andere Policies enthalten sind.

Die Funktionalität der Komponente wird über die Komponente „Datenintegration“, bzw. über den Service „Datenpflege“ dem Administrator zur Verfügung gestellt.

4.4.2.2 Komponente Regelverwaltung Diese Komponente stellt die Funktionalität zur Verfügung, die für das Erstellen / Ändern / Löschen einer Regel notwendig ist.





4.4.2.3 Komponente Rechteverwaltung Die Aufgabe der Komponente ist die Verwaltung, bzw. Konfiguration der Sonderrechte zu ermöglichen. Die Sonderrechte werden in einer internen Datenbank der "ZS Datenpflege" gespeichert.


4.4.2.4 Komponente Datenintegration Die Aufgabe der Komponente „Datenintegration“ ist, die Kommunikation der Komponenten „Policyverwaltung“, „Regelverwaltung“ und „Rechteverwaltung“ mit dem Service „Datenpflege“ zu ermöglichen. Dafür soll die Komponente sowohl die vom Service „Datenpflege“ im XML-Format erhaltenen Informationen dekodieren und in entsprechende Funktionsaufrufe für die Verwaltungskomponenten umzusetzen, als auch die von Verwaltungskomponenten erhaltene Ergebnisse in XML-Form kodieren zu können.

4.4.2.5 Service Datenpflege Schnittstelle des Service „Datenpflege“ wird von dem Administrator der Zugriffssteuerung benutzt um die Zugriffssteuerungsregeln, Regelpolicies und Sonderrechte der Mitarbeiter zu verwalten. Dafür werden vom Administrator entsprechende Tools eingesetzt die vom Service „Datenpflege“ erhaltene Daten über die graphische Oberfläche darstellen können.

4.5 Use Cases

Ablauf der für die Zugriffssteuerung relevanten Geschäftsprozesse innerhalb einer Bank lässt sich sehr gut mithilfe der Use-Case's beschreiben. Für die Zugriffssteuerung lassen sich im Wesentlichen folgende vier Anwendungsfälle definieren:

- Zugriffsprüfung durchführen - Zugriffsregeln pflegen - Information für die Zugriffssteuerung pflegen - Information für die Zugriffssteuerung übernehmen

Bezeichnung Anwendungsfall 1. Zugriffsprüfung durchführen Kurzbeschreibung Es soll überprüft werden, ob der Benutzer für die Ausführung der

Funktion an dem Informationsobjekt berechtigt ist. Akteur(e) Die Anwendung, die der Benutzer nutzt, ruft diesen Use Case

der Querschnittsfunktion Zugriffssteuerung auf. Benutzte Objekte − Identifikation von Benutzer und Informationsobjekt

− Informationsbasis der Zugriffssteuerung − Regeln und Policies der Zugriffssteuerung

Vorbedingungen und auslösendes Ereignis

Auslöser: Benutzer will Funktion einer Anwendung nutzen Vorbedingung: Benutzer ist bereits authentifiziert und für die Ausführung der Funktion autorisiert. D.h. es ist bereits festgestellt: Der Benutzer ist bereits angemeldet und darf die Funktion ausführen.

Nachbedingungen und Ergebnis

Zwei Fälle: − Prüfungsergebnis: Anwendung der Funktion auf das Objekt

ist erlaubt / nicht erlaubt − für die Prüfung relevante Informationen aus der

Informationsbasis werden an die aufrufende Anwendung geliefert.




Bezeichnung Anwendungsfall 2. Zugriffsregeln pflegen Kurzbeschreibung Pflege der Regeln, Regelpolicies oder PolicySets die das

Ergebnis der Zugriffsprüfung steuern. Außerdem Pflege der Regelkonfiguration, die bestimmt, in welcher Reihenfolge Regeln für die Prüfung eines Zugriffs ausgeführt werden und welcher Regelauswertungsalgorithmus dafür verwendet wird. Die Konfiguration erfolgt je Anwendung / Funktion.

Akteur(e) Administrator der Zugriffssteuerung Benutzte Objekte − Regeln, Policies oder PolicySets der Zugriffssteuerung Vorbedingungen und auslösendes Ereignis

Auslöser: Eine Regel, Policy oder PolicySet der Zugriffssteuerung soll geändert werden


− modifizierte Regelbasis der Zugriffssteuerung

Bezeichnung Anwendungsfall 3. Sonderrechte pflegen Kurzbeschreibung Pflege eines Sonderrechtes, der einem Benutzer den Zugriff auf

ein Informationsobjekt erlaubt. Akteur(e) Administrator der Zugriffssteuerung Benutzte Objekte − Sonderrechte_DB der Zugriffssteuerung Vorbedingungen und auslösendes Ereignis

Auslöser: Zugriffsberechtigung eines Benutzers soll geändert werden


− modifizierte Sonderrechte_DB der Zugriffssteuerung

Bezeichnung Anwendungsfall 4. Informationen für die Zugriffssteuerung

übernehmen Kurzbeschreibung Übernahme von Informationen, mit denen die Zugriffssteuerung

arbeitet und die nicht direkt von der Querschnittfunktion verwaltet werden (z.B. Informationen zu Organisationseinheiten, usw.).

Akteur(e) − Querschnitt-Funktion Zugriffssteuerung

− Anwendung oder Datenbank von der Daten übernommen werden.

Benutzte Objekte − Informationsbasis der Zugriffssteuerung Vorbedingungen und auslösendes Ereignis

periodische Übernahme von Daten oder Realtime-Zugriff


− modifizierte Informationsbasis der Zugriffssteuerung

In diesem Kapitel wurde ein Architekturmodell der Zugriffssteuerungskomponente einer Großbank beschrieben, ausgehend von einem internationalen Standard ISO/IEC 10181-3.

Das Architekturmodell der Zugriffssteuerung ist auf Basis einer Service-Oriented-Architektur (SOA) aufgebaut und hat somit die Vorteile, die Einsetzung einer SOA mit sich bringt:

- geringere Beschaffungs- und Wartungskosten (z.B. durch Unabhängigkeit von bestimmten Herstellern, Plattformen und eingesetzten Technologien)

- die Module für die Gewährleistung der Funktionalität der Zugriffssteuerung sind problemlos austauschbar und erweiterbar

- Wiederverwendbarkeit einzelnen Services

Alle Services sind detailliert beschrieben, mit Angabe der Schnittstellenparameter und der Beschreibung des Ablaufs der Servicenutzung.




Das hier beschriebene Architekturmodell der Zugriffssteuerung ist ein flexibles, nach aktuellem Stand der Technik aufgebautes Modell, welches in einer allgemeinen Großbank problemlos einsetzbar ist und auf die Erfüllung der fachlichen Anforderungen, die an eine Querschnittskomponente Zugriffssteuerung einer Großbank gestellt werden, orientiert ist.


Berechtigungsmanagement in einer Großbank Zusammenfassung und Ausblick


5 Zusammenfassung und Ausblick

In dieser Bachelorarbeit wurden ein fachliches Lösungskonzept und ein Architekturmodell für das unternehmensweite Berechtigungsmanagement in einer Großbank vorgestellt.

Im ersten Kapitel wurden die Begriffsdefinitionen, wie Definition eines IT-Systems, Definition der Begriffe Authentifikation und Autorisierung eingeführt. Im Weiteren wurden die gängigen Verfahren für die Authentifizierung und Autorisierung vorgestellt. Da die Fokussierung dieser Bachelorarbeit besonders auf die Autorisierung im Sinne der Zugriffssteuerung gelegt wird, wurden die möglichen Einsätze für die Modellierung der Zugriffssteuerung detailliert dargestellt. Es wurden die am meisten verbreitete Verfahren für die Modellierung der Zugriffssteuerung wie:

- Zugriffskontrolllisten (ACL), - Konzept der Zugriffsausweise, - Chinese-Wall-Modell, - Bell-La-Padula Modell, - hierarchisches rollenbasiertes Zugriffskontrollmodell (RBAC)

beschrieben und auf Vor- und Nachteile, bzw. ihre Eignung für Einsatz im konkreten Fall der Modellierung der Zugriffssteuerung einer Großbank untersucht.

Außerdem wurden die Anforderungen an die Administration der Benutzer- und Berechtigungsinformationen definiert.

Im zweiten Kapitel sind die Anforderungen an eine Autorisierungskomponente einer Großbank, basierend auf dem Anforderungskatalog des Bundesamtes für Sicherheit in der Informationstechnik definiert. Unter anderem sind die Anforderungen an die Rechteverwaltung, Rechteprüfung, Beweissicherung, Fehlerüberbrückung und Leistungsanforderungen beschrieben.

Im Kapitel 3 wurde ein fachliches Modell einer Großbank eingeführt. Dafür wurde zuerst ein Meta-Modell einer allgemeinen Großbank, basierend auf dem hierarchischen RBAC-Modell, definiert und die wichtigsten Entitäten des Meta-Modells beschrieben. Basierend auf dem Meta-Modell erfolgte die Einführung eines Beispieldatenmodells einer Großbank, mit dem Ziel, ein Beispiel zu beschaffen, welches für die Definition der konkreten Mitarbeiterrollen, Anwendungsfälle, Zugriffsprinzipien und schließlich der Zugriffsregeln einer querschnittlichen Zugriffssteuerungskomponente einer Großbank dienen soll.

Anschließend wurden die wichtigsten Mitarbeiterrollen und die Rollenhierarchie aus dem Datenmodell abgeleitet und die Anwendungsfälle, welche die Zugriffsprinzipien für den Zugriff auf die Ressourcen einer Großbank verdeutlichen eingeführt.

Auf Basis der Anwendungsfälle wurden schließlich die Regeln, die von der Zugriffssteuerung beim Treffen einer Entscheidung über die Ablehnung oder Gewährung des Zugriffs auf ein Informationsobjekt einer Bank definiert. Um die konkreten Zugriffsanfragen zu bearbeiten, werden die Regeln, allerdings, zu Regelpolicies zusammengefasst. Die Regelpolicies können dann später auch zu PolicySets zusammengefasst werden. Am Ende des Kapitels 3 wurden Beispiele für die Regelpolicies und PolicySets gegeben.

Im Kapitel 4 wurde ein mögliches Architekturmodell der Zugriffssteuerung einer Großbank definiert. Dieses Architekturmodell basiert auf den im Standard ISO/IEC 10181-3 definierten Prinzipien für den Aufbau eines Architekturmodells der Zugriffsteuerung. Außerdem wird das Architekturmodell auf Basis der Service-Oriented-Architectur (SOA) aufgebaut. Die


Berechtigungsmanagement in einer Großbank Zusammenfassung und Ausblick


Zugriffssteuerung besteht demnach aus mehreren Services, die detailliert beschrieben wurden. Vorteile der SOA sind unter anderem (vgl. Ende des Kapitels 4):

- geringere Beschaffungs- und Wartungskosten (z.B. durch Unabhängigkeit von bestimmten Herstellern, Plattformen und eingesetzten Technologien)

- die Module für die Gewährleistung der Funktionalität der Zugriffssteuerung sind problemlos austauschbar und erweiterbar

- Wiederverwendbarkeit einzelnen Services

Das Architekturmodell erfüllt die Anforderungen an die Zugriffssteuerung, die im zweiten Kapitel dieses Dokuments beschrieben sind, und ist demnach in einer allgemeinen Großbank einsetzbar.

Es gibt sicherlich noch andere Probleme bei der Modellierung der Zugriffssteuerungskomponente einer allgemeinen Großbank, die in dieser Bachelorarbeit nicht erwähnt sind. Zum Beispiel könnte von der Zugriffssteuerung Caching von Berechtigungsanfragen betrieben werden. Im Weiteren sollen die Probleme der mehrfachen Datenhaltung und der Integration mehreren Datenbestände in einen Bestand und das Problem der Synchronisation der für die Zugriffssteuerung relevanten Daten gelöst werden. Allerdings sind das die Probleme, die bei der Implementierung der Zugriffssteuerung einer konkreten Großbank entstehen und bei der Beschreibung eines Architekturmodells einer allgemeinen Großbank nicht berücksichtigt werden müssen.


Berechtigungsmanagement in einer Großbank Literatur


Literatur

[BASIN02] Torsten Lodderstedt, David A. Basin, and Jurgen Doser. Secureuml: A uml-based modeling language for model-driven security. In Jean-Marc Jezequel, Heinrich Hussmann, and Stephen Cook, editors, UML 2002 - The Unified Modeling Language. Model Engineering, Languages, Concepts, and Tools. 5th International Conference, Dresden, Germany, September/October 2002, Proceedings, volume 2460 of Lecture Notes in Computer Science, pages 426–441, 2002.

[BIBU04] P.Biltzinger, H.Bunz. Erarbeitung einer Strategie zur Einführung der Gesundheitskarte, Kapitel 4.4.1 ISO OSI Access Control Framework, http://www.dimdi.de/static/de/ehealth/karte/download/b4hSichArch.pdf. Stand: 13.10.05

[BICH05] M.Bichler. Vorlesung – Internetbasierte Geschäftssysteme, Architektur, Standards, Techniken. Technische Universität München, Wintersemester 04/05. http://ibis.in.tum.de/teaching/ws04_05/VO-IBIS.htm. Stand: 13.10.05.

[BLP76] D.E.Bell, L.J. La Padula. Secure Computer System: Unified Exposition and Multics Interpretation. Deputy for Command and Management Systems Electronic Systems Division, 1976. http://csrc.nist.gov/publications/history/bell76.pdf, Stand 13.10.05.

[BRNA89] Dr. David F.C. Brewer, Dr. Michael J. Nash. The Chinese Wall Security Policy. Gamma Secure Systems Limited, 1989. http://www.gammassl.co.uk/topics/chwall.pdf, Stand 13.10.05.

[DIN85] Begriffe der Qualitätssicherung und Statistik, Begriffe der Annahmestichprobenprüfung, Standard DIN 55350-31, Deutsches Institut für Normung e. V. ,1985.

[DITSEC] Deutsche IT – Sicherheitskriterien (Grünbuch), Bundesamt für Sicherheit in der Informationstechnik, www.bsi.bund.de.

[ECK05] Claudia Eckert. IT – Sicherheit, Konzepte – Verfahren – Protokolle. Oldenbourg Verlag München Wien. 2005.

[FESA01] David F. Ferraiolo, Ravi Sandhu, Serban Gavrila, D. Richard Kuhn, Ramaswamy Chandramouli. Proposed NIST Standard for Role-Based Access Control. National Institute of Standards and Technology, http://csrc.nist.gov/rbac/rbacSTD-ACM.pdf, Stand 13.10.05.

[ISO96] Standard ISO/IEC 10181-3, Information technology - Open Systems Interconnection - Security frameworks for open systems: Access control framework. International Organization for Standardization, 1996.

[KEMP01] A.Kemper, A.Eickler. Datenbanksysteme. Oldenbourg Verlag München Wien, 2001.

[LEMA05] Kathrin Lehmann, and Florian Matthes. Meta Model Based Integration of Role- Based and Discretionary Access Control Using Path Expressions. In7th


Berechtigungsmanagement in einer Großbank Literatur


International IEEE Conference on E-Commerce Technology 2005., Munich, Germany, July 19th- 22th, 2005, pages 443–446. IEEE Computer Society.

[NIST05] Homepage von National Institute of Standards and Technology. Informationen zu Role Based Access Control (RBAC) Standard. http://csrc.nist.gov/rbac/, Stand 13.10.05.

[PH05] Hupfauf Franz. Pflichtenheft der Studie „Zugriffssteuerung Neu“, HVB Systems GmbH, Abteilung SYS30SW, 2005.

[SCHM05] Prof. Dr. A.Schmietendorf. Vorlesung – Web Services, Sommersemester 2005, Otto-von-Guericke-Universität Magdeburg. http://ivs.cs.uni-magdeburg.de/~schmiete/lehre/vorlesung/ss_05_md.html, Stand: 13.10.05.

[XACML] Beschreibung der eXtensible Access Control Markup Language (XACML). Organization for the Advancement of Structured Information Standards (OASIS). http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml. Stand: 13.10.05.

Technische Universität München - TUM · Berechtigungsvergabe." [PH05] In dieser Bachelorarbeit...

Documents

Transcript of Technische Universität München - TUM · Berechtigungsvergabe." [PH05] In dieser Bachelorarbeit...