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
Sergius Schneider 2005 2
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Inhaltsverzeichnis
Sergius Schneider 2005 3
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
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Inhaltsverzeichnis
Sergius Schneider 2005 4
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
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Einführung
Sergius Schneider 2005 5
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]
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
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.
Sergius Schneider 2005 6
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Begriffsdefinitionen.
Sergius Schneider 2005 7
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).
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Begriffsdefinitionen.
Sergius Schneider 2005 8
- 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].
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Begriffsdefinitionen.
Sergius Schneider 2005 9
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
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Begriffsdefinitionen.
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.
Sergius Schneider 2005 10
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Begriffsdefinitionen.
Sergius Schneider 2005 11
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).
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Begriffsdefinitionen.
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).
Sergius Schneider 2005 12
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Begriffsdefinitionen.
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
Sergius Schneider 2005 13
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Begriffsdefinitionen.
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.
Sergius Schneider 2005 14
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Begriffsdefinitionen.
Sergius Schneider 2005 15
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].
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Begriffsdefinitionen.
Sergius Schneider 2005 16
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Anforderungen an eine Autorisierungskomponente
Sergius Schneider 2005 17
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.
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Anforderungen an eine Autorisierungskomponente
Sergius Schneider 2005 18
- 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.
In den Sicherheitsanforderungen der Autorisierungskomponente soll festgelegt werden:
- 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.
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Anforderungen an eine Autorisierungskomponente
Sergius Schneider 2005 19
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.
In den Sicherheitsanforderungen der Autorisierungskomponente soll festgelegt 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.
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Anforderungen an eine Autorisierungskomponente
Sergius Schneider 2005 20
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.
In den Sicherheitsanforderungen der Autorisierungskomponente soll festgelegt werden:
- 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.
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Anforderungen an eine Autorisierungskomponente
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).
Sergius Schneider 2005 21
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank
Sergius Schneider 2005 22
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank
Sergius Schneider 2005 23
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
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
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, …).
Sergius Schneider 2005 24
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
Sergius Schneider 2005 25
- 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.
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
Sergius Schneider 2005 26
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
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
*
*
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
-ist_Azubi: bool-ist_Springer: bool
1
0..1
1..**
KundeKundeKunde
1..**
Statische Autorisierung
-Funktion_ID
-Berechtigung[ ]
Statische Autorisierung
-Funktion_ID
-Berechtigung[ ]
Statische Autorisierung
-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
Sergius Schneider 2005 27
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
Sergius Schneider 2005 28
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.
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
Sergius Schneider 2005 29
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.
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
Sergius Schneider 2005 30
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
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
RolleRolle
GruppenbetreuerGruppenbetreuerGruppenbetreuer
SpezialistSpezialistSpezialist
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
Sergius Schneider 2005 31
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
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*
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
-ist_Azubi: bool-ist_Springer: bool
1
0..1
1..**
KundeKundeKunde
1..**
Statische Autorisierung
-Funktion_ID
-Berechtigung[ ]
Statische Autorisierung
-Funktion_ID
-Berechtigung[ ]
Statische Autorisierung
-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.
Sergius Schneider 2005 32
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
Sergius Schneider 2005 33
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.
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
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) ,
bzw. sein Vertreteroder Vorgesetzter
Partnerbetreuer,bzw. sein Vertreteroder Vorgesetzter
Partnerbetreuer,bzw. sein Vertreteroder Vorgesetzter
Generalist /Spezialist ,
bzw. sein Vertreteroder Vorgesetzter
Generalist /Spezialist ,
bzw. sein Vertreteroder Vorgesetzter
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,
Sergius Schneider 2005 34
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
Sergius Schneider 2005 35
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
Beschränkungen - Informationsobjekt gehört nicht dem Mitarbeiter (z.B. kein eigenes Konto)
- 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
Anwendbare Zugriffsprinzipien
- Lokationsprinzip - Betreuerprinzip - Gesamtbankrechtprinzip - Sonderrechtprinzip - VIP Prinzip
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
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
Sergius Schneider 2005 36
Beschränkungen - Informationsobjekt gehört nicht dem Mitarbeiter (z.B. kein eigenes Konto)
- 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
Anwendbare Zugriffsprinzipien
- Lokationsprinzip - Betreuerprinzip - Gesamtbankrechtprinzip - Sonderrechtprinzip - VIP Prinzip
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
Beschränkungen - Informationsobjekt gehört nicht dem Mitarbeiter (z.B. kein eigenes Konto)
- Erfüllung des VIP Prinzips Informationsobjekte Dem Konto zugeordnete Informationsobjekte Enthält Anwendungsfälle
------
Spezialfall der Anwendungsfälle
- Zugriff auf IO des OB Partnerverbund - Zugriff auf IO des OB Partner - Zugriff auf IO des OB Kunde
Anwendbare Zugriffsprinzipien
- Lokationsprinzip - Betreuerprinzip - Gesamtbankrechtprinzip - Sonderrechtprinzip - VIP Prinzip
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
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
Sergius Schneider 2005 37
- Spezialist - Bankangestellte - Zur selben Organisationseinheit (bzw. übergeordneter OE) wie
Konto 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 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
Spezialfall der 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
Anwendbare Zugriffsprinzipien
- Lokationsprinzip - Betreuerprinzip - Gesamtbankrechtprinzip - Sonderrechtprinzip - VIP Prinzip
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.
Spezialfall der 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.
Anwendbare Zugriffsprinzipien
- 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 ------
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
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
Spezialfall der Anwendungsfälle
-----
Anwendbare Zugriffsprinzipien
- 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).
Sergius Schneider 2005 38
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
Sergius Schneider 2005 39
- 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),
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
Sergius Schneider 2005 40
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),
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
Sergius Schneider 2005 41
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
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Fachliches Lösungsmodell für eine Großbank
Sergius Schneider 2005 42
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.
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank
Sergius Schneider 2005 43
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.
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
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
Schnittstelle der Zugriffssteuerung- von nutzender Anwendung übergebene
Informationen- von Querschnittfunktion gelieferte
Information
Regeln der Zugriffssteuerung-Verwaltung der Regeln- Auswertung der Regeln- Steuerung des Zugriffs
Regeln der Zugriffssteuerung-Verwaltung der Regeln- Auswertung der Regeln- Steuerung des Zugriffs
Regeln der Zugriffssteuerung-Verwaltung der Regeln- Auswertung der Regeln- Steuerung des Zugriffs
Regeln der Zugriffssteuerung-Verwaltung der Regeln- Auswertung der Regeln- Steuerung des Zugriffs
Informationsbasis der Zugriffssteuerung- Informationen verwalten- Information zur Verfügung stellen
Informationsbasis der Zugriffssteuerung- Informationen verwalten- Information zur Verfügung stellen
Schnittstelle der Zugriffssteuerung- von nutzender Anwendung übergebene
Informationen- von Querschnittfunktion gelieferte
Information
Schnittstelle der Zugriffssteuerung- von nutzender Anwendung übergebene
Informationen- von Querschnittfunktion gelieferte
Information
Informationsbasis der Zugriffssteuerung- Informationen verwalten- Information zur Verfügung stellen
Informationsbasis der Zugriffssteuerung- Informationen verwalten- Information zur Verfügung stellen
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.
Sergius Schneider 2005 44
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
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.
Sergius Schneider 2005 45
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
Sergius Schneider 2005 46
- 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.
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
Module Module Module
Module Module Module
Module Module Module
Module Module Module
Shared ServiceShared Service Shared Service Shared ServiceShared Service Shared Service
Shared ServiceShared Service Shared Service Shared ServiceShared Service Shared Service
Anwendungen
Module Module Module
Module Module Module
Module Module Module
Module Module Module
Shared ServiceShared Service Shared Service Shared ServiceShared Service Shared Service
Shared ServiceShared Service Shared Service Shared ServiceShared Service Shared Service
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
Sergius Schneider 2005 47
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
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.
Sergius Schneider 2005 48
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
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.
Sergius Schneider 2005 49
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
Anwendungen
ZS Kern ZS Datenpflege
DatenbankenDB 1 DB 2 DB 3 DB 4 DB 5 DB …
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.
Sergius Schneider 2005 50
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
Service
Zugriffssteuerung
DatenbankenDB 1 DB 2 DB 3 DB 4 DB 5 DB …
DatenbankenDB 1 DB 2 DB 3 DB 4 DB 5 DB …
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
ServiceInformationsbereitstellung
DatenbankenDB 1 DB 2 DB 3 DB 4 DB 5 DB …
DatenbankenDB 1 DB 2 DB 3 DB 4 DB 5 DB …
ServiceDatenzugriff
ServiceSchicht
FachlicheIntegration
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).
Sergius Schneider 2005 51
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
Sergius Schneider 2005 52
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.
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
ServiceZugriffssteuerung
ServiceDatenzugriff
ServiceInformationsbereitstellung
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.
Sergius Schneider 2005 53
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
4.4.1.3 Service Zugriffsprüfung
ServiceZugriffsprüfung
DatenbankenDB 1 DB 2 DB 3 DB 4 DB 5 DB …
DatenbankenDB 1 DB 2 DB 3 DB 4 DB 5 DB …
ServiceDatenzugriff
ServiceSchicht
FachlicheIntegration
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.
Sergius Schneider 2005 54
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
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
ServiceZugriffsprüfung
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.
Sergius Schneider 2005 55
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
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
ServiceZugriffsprüfung
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.
Erläuterung des Ablaufs:
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.
Sergius Schneider 2005 56
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
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.
DatenbankenDB 1 DB 2 DB 3 DB 4 DB 5 DB …
DatenbankenDB 1 DB 2 DB 3 DB 4 DB 5 DB …
Direktzugriff
Datenmanager
Adapter Adapter
ServiceSchicht
FachlicheIntegration
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
Sergius Schneider 2005 57
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
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
DatenbankenDB 1 DB 2 DB 3 DB 4 DB 5 DB …
DatenbankenDB 1 DB 2 DB 3 DB 4 DB 5 DB …
Direktzugriff
Datenimport
3 57
6
InformationsbasisInformationsbasis4
9
82
Abbildung 31. Nutzung von Service Datenzugriff
Erläuterung des Ablaufs:
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.
Sergius Schneider 2005 58
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
Sergius Schneider 2005 59
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.
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
Sergius Schneider 2005 60
Die Funktionalität der Komponente wird über die Komponente „Datenintegration“, bzw. über den Service „Datenpflege“ dem Administrator zur Verfügung gestellt.
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.
Die Funktionalität der Komponente wird über die Komponente „Datenintegration“, bzw. über den Service „Datenpflege“ dem Administrator zur Verfügung gestellt.
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.
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
Sergius Schneider 2005 61
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
Nachbedingungen und Ergebnis
− 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
Nachbedingungen und Ergebnis
− 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
Nachbedingungen und Ergebnis
− 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.
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Architektur der Zugriffssteuerung
Sergius Schneider 2005 62
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.
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Zusammenfassung und Ausblick
Sergius Schneider 2005 63
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
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Zusammenfassung und Ausblick
Sergius Schneider 2005 64
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.
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Literatur
Sergius Schneider 2005 65
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
Bachelor – Arbeit Entwurf eines fachlichen Lösungskonzepts und eines Architekturmodells für das unternehmensweite
Berechtigungsmanagement in einer Großbank Literatur
Sergius Schneider 2005 66
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.