Home

Molitorisz - Institute for Program Structures and Data Organization

1. 88 Procedure Model Development Introduction zuersesssersnersneesnnesnnesneenn 92 Procedure Model Development Role Analysis u ursuersnersneesneesnnesnneenn 96 Procedure Model Development Role Design uursersersnersnersnnesnnesnneenn 99 Procedure Model Development Role Implementation 102 Procedure Model Development Role Operations 00 0 0 cee ceeeeeeeeeeeeeeees 105 Analysis of Role Management Solutions Evaluation Criteria 110 Analysis of Role Management Solutions Evaluation of OIM 113 Forschungsgruppe C amp M 152 Information 53 Information 54 Information 55 Information 56 Information 57 Information 58 Information 59 Information 60 Information 61 Information 62 Information 63 Information 64 Information 65 Information 66 Anhang Analysis of Role Management Solutions Evaluation of SRM 117 Case Study Introduction to IST scenario eeceeceeceseceeeeeeeeeeeeeeeeeeenees 122 Case Study Introduction to System Roles 22 0222022200220n sense 124 Case Study Role Mapping with Simple System Roles u e 127 Case Study Role Mapping with Complex System Roles 129 Case Study Role Operation in Sun Role Manager eene 130 Appendix Tiers in Omada Identi
2. NET Framework 2 0 Microsoft Windows 2000 Server Microsoft Windows Server 2003 Information 59 Appendix Tiers in Omada Identity Manager Information 59 zeigt die drei Schichten in OIM und die Aufteilung der Komponenten darin Al le drei Schichten k nnen auf unterschiedlichen Rechnern betrieben werden was aus Skalierbar Forschungsgruppe C amp M 140 Anhang keitsgr nden durchaus sinnvoll ist Wie bereits erw hnt wurde basieren alle drei Schichten auf einem Microsoft Betriebssystem mit einer Installation des NET Framework in der Version 2 0 Als Datenbankserver kommt entweder Microsoft SQL Server 2000 oder Microsoft SQL Server 2005 zum Einsatz Dieser wird von OIM f r dessen interne Datenhaltung ben tigt und von ILM f r die Speicherung dessen Verbindungsdaten zu den Endsystemen einerseits sowie der Mana gementagenten andererseits Diese konkretisieren die Kommunikationsbeziehung zu den End systemen und spezifizieren welche Daten von dort bezogen werden sollen Zwar ist OIM ledig lich eine Erweiterung zu Omada Enterprise allerdings wird im Folgenden zur Vereinheitlichung lediglich von OIM gesprochen und nicht explizit unterschieden welche Funktion OE bereitstellt und welche durch OIM hinzukommen da dies durch die fehlende Dokumentation teilweise nicht m glich ist OIMO07a Im Folgenden wird nun auf die Installation des OIM eingegangen Installation Process of Omada Identity Manager Pre
3. File system Information 55 Case Study Introduction to System Roles Der zentrale Verzeichnisdienst Active Directory den c amp m einsetzt bietet zur Zusammenfas sung von Benutzern folgende drei Systemrollen an Die Systemrolle Dom nenbenutzer engl domain user repr sentiert Benutzer mit eingeschr nktem Rechteumfang innerhalb der technischen Infrastruktur von c amp m Do m nenbenutzern ist es gestattet sich innerhalb der Client Infrastruktur von c amp m anzu melden wobei an dieser Stelle die Anmeldung nicht auf spezielle Client Rechner ein geschr nkt wird Die Systemrolle Dom nenadministrator engl domain administrator gew hrt neben dem uneingeschr nkten Zugriff auf die Arbeitsplatzrechner auch den Zugriff auf die Serverbetriebssysteme von c amp m Diese Systemrolle hat daher insbesondere die Berech tigungen zur client und serverseitigen Konfiguration der Betriebssysteme In diesem Zusammenhang ist es m glich Benutzerkonten zu verwalten die im Verzeichnisdienst abgelegt sind Die Systemrolle des Unternehmensadministrators engl enterprise administrator baut auf der Systemrolle Dom nenadministrator auf und erweitert dessen Kompetenzen um die M glichkeit Schemadefinitionen innerhalb von c amp m zu ndern wie es etwa bei der Integration zus tzlicher technischer Endsysteme der Fall sein kann Diese System rolle verk rpert somit den gr ten Berechtigungsumfang innerhalb der Zugriffskontrol
4. Sun08b Ta02 Anhang Microsoft Developer Network Web Part http msdn microsoft com en us library bb8 15365 aspx Microsoft Corporation Webseite Stand 07 11 2008 Omada A S Omada Enterprise amp Omada Identity Manager 6 0 Installation Guide Omada A S Version 3 07 12 2007 Omada A S Omada Identity Manager Extensible Management Agent Omada A S Version 2 12 12 2007 Omada A S Omada Transport System Administrator Guide Omada A S Version 2 01 02 2008 Object Management Group OMG Unified Modeling Language OMG UML Superstructure Object Management Group Version 2 1 2 Novem ber 2007 Dongwan Shin Gail Joon Ahn A Role Administration System in Role based Authorization Infrastructures Design and Implementation Proceed ings of the 2003 ACM symposium on Applied computing Melbourne Flor ida USA 2003 Dongwan Shin Gail Joon Ahn Sangrae Cho Seunghun Jin A role based infrastructure management system design and implementation John Wiley amp Sons Ltd 2004 Ravi S Sandhu Venkata Bhamidipati Quamar Munawer The ARBAC97 model for role based administration of roles ACM Transactions on Infor mation and System Security Kapitel 2 1 Seiten 105 135 1999 Ravi S Sandhu Venkata Bhamidipati The ASCAA Principles for Next Generation Role Based Access Control International Symposium on Col laborative Technologies and Systems 2008 Seite 532 19 23 Mai 2008 Ravi S Sandhu Edward J Coynek
5. 1 1 Joker Joker Policy Policy E GroupID Integer Eu GroupID Integer Information 44 Development of the BRBAC Role Model Automatic Roles Wenn ein Benutzer an unterschiedlichen Standorten gleicherma en arbeitet bedeutet das f r die Zugriffsrechte dass seine Gesch ftsrolle ber eine gro e Zahl an Systemrollen verf gt die ja gerade den Zugriff auf die Endsysteme verk rpern Dies wird in Information 44 durch System Role A und System Role B ausgedr ckt Die Verwaltung dieser Rolle kann nun dadurch de zentralisiert werden dass die einzelnen Abteilungen die atomaren Zugriffsrechte auf ihren eige nen Endsystemen selbst definieren und an eigene Systemrollen kn pfen An dieser Stelle wird klar wieso generische Rollen f r dieses Szenario nicht verwendet werden k nnen Diese Rol lentypen dienen einer Zusammenfassung gleicher Rechte in unterschiedlichen Systemen hier jedoch handelt es sich um unterschiedliche Rechte in unterschiedlichen Systemen Es ist eine realistische Annahme dass Gruppenzugeh rigkeiten in technischen Endsystemen in Relation stehen zur Abteilungszugeh rigkeit Daraus kann man schlie en dass sich die Zugeh rigkeit zu Gruppen die in Endsystemen vorhanden sind automatisch bzw automatisiert aus der Abtei lungszugeh rigkeit ableiten l sst Es besteht demnach eine Relation zwischen Abteilungs und Systemzugeh rigkeit Dies Kann durch eine Regel automatisiert werden So wie bei Policy
6. 23 August 2007 Axel Kern Advanced Features for Enterprise Wide Role Based Access Control Proceedings of the 18th Annual Computer Security Applications Conference Seite 333 2002 Kevin Kampman Gerry Gebel Roles Burton Group http www burtongroup com Client Research Document aspx cid 63 1 2007 Axel Kern Martin Kuhlmann Observations on the Role life Cycle in the Context of Enterprise Security Management Proceedings of the seventh ACM symposium on Access control models and technologies Monterey Kalifornien USA Seiten 43 51 03 04 Juni 2002 Martin Kuhlmann Dalia Shohat Gerhard Schimpf Role Mining Reveal ing Business Roles for Security Administration using Data Mining Technol ogy Proceedings of the eighth ACM symposium on Access control models and technologies Como Italy Seiten 179 186 2003 B W Lampson Dynamic protection structures Berkley Computer Corpo ration 1969 Microsoft TechNet Install from the product discs http technet2 microsoft com WindowsServer en library 4ec66e57 1146 499f 9072 0dal 9eea2dee1033 mspx pf true Microsoft Corporation Web seite Stand 01 07 2008 Microsoft TechNet Policy inheritance http technet microsoft com en us library cc778096 aspx Microsoft Corporation Webseite Stand 08 10 2008 Forschungsgruppe C amp M 168 Mic08 OIMO7a OIMO7b OIMOS8 OMG07 SA 03 SA 04 SB 99 SB08 SC 96 Sen02 Sun08a
7. Set User Selection by Business Unit Set Users Set Properties Validate Rule Results Information 34 State of the Art Sun Role Manager Rule Discovery Forschungsgruppe C amp M 62 Stand der Technik Der dritte Prozess rule discovery hat zum Ziel die Einteilung von Benutzern in Rollen auf der Basis von vordefinierten Benutzerattributen in SRM durch das Definieren von Regeln einzu schr nken Dazu werden Klassifizierungsregeln fiir Rolle verwendet die durch die Anwendung von role mining Algorithmen erstellt werden Dieser Prozess der in Information 34 dargestellt ist beginnt mit der Auswahl von Benutzern als Eingabeparameter fiir den Algorithmus Im An schluss daran k nnen sowohl die zur Verf gung stehenden Benutzerattribute als auch die Pa rameter des Algorithmus selbst spezifiziert werden um den Suchlauf zu verfeinern Im an schlie enden Suchlauf wird versucht gemeinsame Attributwerte bei den ausgew hlten Benutzern zu entdecken um diese als Klassifizierungsregeln im identity warehouse abzulegen und mit den Rollen zu verkn pfen Um in die Rolle aufgenommen werden zu k nnen die mit der Klassifizierungsregel belegt ist muss ein Benutzer daher ber die in der Regel festgelegte Bedingung verf gen Hier zeigt sich der Zusammenhang zwischen Policys und Regeln Beide Prinzipien arbeiten auf Attributebene aber Policys schr nken die Zugriffsrechte der Rollenmitg lieder ein w hrend Regeln die Rollenmitgliedscha
8. Forschungsgruppe C amp M 138 Anhang ANHANG Forschungsgruppe C amp M Anhang 139 A Installation und Konfiguration des Omada Identity Manager In diesem Kapitel wird der Prozess zur Installation und Konfiguration des Omada Identity Ma nager OIM besprochen der in Kapitel 3 2 detailliert vorgestellt und in Kapitel 6 2 anhand ei nes Kriterienkatalogs bewertet wurde Die Informationen hierf r sind den Installationshandb chern des Omada Identity Manager und Omada Enterprise entnommen OIM07a OIMOTb OIM08 Dabei wird zun chst die Installation der Basissysteme besprochen und anschlie end die Installation und Konfiguration des Omada Identity Manager die sich in die beiden Bereiche Omada Enterprise und Omada Identity Manager unterteilt A 1 Installation der Basissysteme Der Identity Manager OIM ist ein kommerzielles Produkt der Firma Omada zur Verwaltung von Rollen Es basiert auf Omada Enterprise OE einer Intranetz L sung zur Identit tsverwal tung Der Identity Manager erweitert den Funktionsumfang von OE speziell um die F higkeit zur Verwaltung von Rollen OIM ist eine klassische 3 Schichten Architektur engl three tier architecture bestehend aus Pr sentationsschicht engl presentation tier Logikschicht engl business logic tier und Datenhaltungsschicht engl data tier und basiert auf einer reinen Mic rosoft Serverumgebung Jede dieser Schichten ben tigt Microsoft Windows Server als Basisbe triebssystem Da
9. Wie aus der Abbildung hervorgeht besteht der NIST RBAC Standard aus den vier Modellen core RBAC hierarchical RBAC constrained RBAC und hierarchical RBAC with constraints die aufeinander aufbauen und vier unterschiedlich komplexe Modelle darstellen In den folgen den Teilkapiteln wird jedes dieser vier Modelle vorgestellt Dabei wird zun chst das jeweilige Modell selbst spezifiziert und anschlie end auf dessen Funktionen eingegangen An dieser Stel le sei erw hnt dass der NIST RBAC Standard seinerseits stark von RBAC96 gepr gt ist und wesentliche Konzepte daraus verwendet In dieser Arbeit werden das Zusammenspiel Gemein samkeiten oder Gegens tze dieser beider Rahmenwerke allerdings nicht explizit diskutiert da sie selbst lediglich die Basis f r diese Arbeit darstellen Eine derartige Diskussion w rde am Kern dieser Arbeit nichts ndern und deshalb wird hier lediglich verwiesen auf SBO8 2 2 1 RBAC Kernmodell Wie aus Information 7 hervorgeht stellt das core RBAC Modell das Basismodell im NIST RBAC Standard dar Es spezifiziert einerseits die grundlegenden Modellelemente f r RBAC und andererseits die daf r ben tigten Funktionen Im Folgenden wird nun zun chst auf die Mo dellelemente und anschlie end auf die funktionale Spezifikation eingegangen Modellspezifikation Das core RBAC Modell besteht aus f nf Elementen zur Modellierung von RBAC Dies sind Benutzer engl users Rollen engl roles Objekte engl obejcts Ope
10. Dabei verk rpert eine Rol le einerseits gesch ftsnahe Aspekte wie etwa eine gesch ftsnahe Funktion Somit ist bisher weder eine klare Trennung dieser Aspekte gegeben noch wird die Verbindung zwischen ihnen modelliert Als Beispiele f r gesch ftsnahe Aspekte einer Rolle seien etwa ein Jobtitel eine Anwendungsdom ne etwa eine Zweigstelle oder ein Verweis auf einen Vorgesetzten genannt Andererseits verk rpert der Rollenbegriff technische Zugriffsrechte die in den vielf ltigen Endsystemen auf ganz unterschiedliche Weise dargestellt werden Die Forderung nach der expliziten Trennung von gesch ftlichen und technischen Belangen die sich in unterschiedlichen Auffassungen des Begriffs Rolle manifestiert stellt die zentrale Anforderung zur Realisierung von Z in BRBAC dar Die Anforderung A soll diesen Unterschied formal fassen und somit die Mehrdeutigkeit des Begriffs Rolle beseitigen Anforderung A Unterst tzung von generischen Rollen Als Erg nzung zur An forderung A und in bereinstimmung zum ERBAC Modell soll das hier entwickelte Rollenmodell generische Rollen als Mechanismus zur Zusammenfassung hnlicher Rol len unterst tzen Im Gegensatz zur Generik wie sie im ERBAC Modell verwendet wird soll im BRBAC Modell zus tzlich das technische Wissen gesenkt werden das zur Verwaltung des Rollenmodells im Wirkbetrieb vorhanden sein muss Nach der Formu lierung der Anforderung und der Abgrenzung zu bisherigen Modelle
11. Durch die Einf hrung eines abstrakt gehaltenen Systemrollenbegriffs aus dem nicht explizit die darin Forschungsgruppe C amp M Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen 75 enthaltenen Systemberechtigungen hervorgehen wird das technische Wissen welches zur Ver waltung einer Rollenmanagementl sung ben tigt wird nochmals gesenkt was die Akzeptanz des Modells in Unternehmen potentiell erh ht Organizational Layer Technical Layer User User Assignment 1 Role Mapping Business Role System Role eh 1 Ls 1 Policy Assignment Policy Assignment Policy Policy Information 39 Development of the BRBAC Role Model Business and System Roles Die Verkn pfung zwischen den beiden Rollenbegriffen ist so definiert dass eine Gesch ftsrolle eine beliebige Menge an Systemrollen enthalten kann und eine Systemrolle zu einer beliebigen Anzahl von Gesch ftsrollen geh rt Im praktischen Einsatz sollten beide Rollen allerdings min destens eine Referenz auf eine jeweils andere Rolle besitzen Insbesondere an dieser Stelle kommt die Komplexit t von RBAC im Unternehmenseinsatz zum Tragen weil es hier eine sehr gro e Zahl an Systemrollen geben kann Eine manuelle Pflege dieser Relation verursacht einen gro en Aufwand wie schon Information 1 aufgezeigt hat Die Anwendung von Algorithmen zum Entdecken von Rollen engl role mining Kapitel 3 1 1 sowie die Unterst tzung von ad
12. Im Anschluss an die Installation des Betriebssystems wird der Datenbankserver installiert In dieser Arbeit wird der Microsoft SQL Server 2005 verwendet Zur Installation sind administrative Rechte auf dem Betriebssystem n tig Das Verzeichnis in dem der SRM installiert werden soll muss vor dem Starten der Installation bereits angelegt werden da es sonst w hrend der Installa tion Fehler auftreten Die Installationsprozedur des SRM wird durch eine grafische Oberfl che unterst tzt und erfasst neben dem Installationsverzeichnis die Verbindung zum Datenbankserver sowie dem Anwendungsserver Damit SRM im sp teren Betrieb mit der Datenbank kommuni zieren kann wird ein f r die Datenbank spezifischer Treiber ben tigt Da bereits bei der Instal Forschungsgruppe C amp M Anhang 145 lation des Role Manager eine Verbindung zum Datenbankserver hergestellt wird um dort die vom SRM verwendete Datenbank anzulegen muss bereits vor der Installation der hierf r ben tigte JDBC Treiber vorhanden und der Installationsprozedur mitgeteilt werden Daher wird der Klassenpfad f r die Installationsprozedur mit folgendem Kommandozeilenbefehl um den Pfad des Treibers erweitert set CLASSPATH lt SRM DR VER gt lt file name gt Da Apache Tomcat Teil des Installationspakets ist erfordert der Anwendungs und Webserver keine separate Installation sondern geschieht zusammen mit SRM selbst Es muss an dieser Stelle lediglich die Verbindungsk
13. Omada Identity Manager Data Exchange Beim Anlegen von zu importierenden oder exportierenden Daten beginnt man damit die Quelle und das Ziel der Daten zu spezifizieren Der Omada Identity Manager bietet hierf r drei m gli che Verbindungspartner an Eine direkte Kommunikation mit einem LDAP konformen Ver zeichnisdienst einer SAP Tabelle und einer manuell zu pflegenden CSV Datei Anschlie end wird in der Aktivit t select import export angegeben ob es sich bei dieser Datenkommunikation um einen Import in OIM oder einen Export aus OIM handelt Man kann im folgenden Schritt zus tzliche Parameter angeben wie etwa einen Zeitplan wann die Aktion auszuf hren ist und ob sie regelm ig wiederholt werden soll Auch kann hier spezifiziert werden ob eine vollst n dige bertragung aller Daten im Sinne eines kompletten Datenaustauschs oder nur bisher nicht vorhandener Daten gew nscht ist Des Weiteren muss angegeben werden wie damit umgegan gen werden soll wenn Inkonsistenzen zwischen beiden Datenbest nden erkannt werden Ab schlie end m ssen die zu bertragenen Attribute ausgew hlt und in Relation zu den entspre chenden Attributen im Zielsystem gesetzt werden Die zweite Art der Kommunikation verwendet den Microsoft Identity Lifecycle Manager ILM als Provisionierungsplattform Hierf r sind Managementagenten n tig die bei Aktualisierungen des Metaverzeichnisses des ILM aktiviert werden und dem Omada Identity Manager die ge n derten
14. Siehe Java EE Java Platform Enterprise Edition fr her J2EE Java Database Connectivity Gesetzt zur Kontrolle und Transparenz im Unternehmensbereich Forschungsgruppe C amp M 150 LDAP MOSS NIST NIST RBAC OE OIM OMG Op PA PIP RBAC RBAC96 RBACx RH SoD SOX SP SR SRM sSod TS UA UML Anhang Lightweight directory access protocol Microsoft Office SharePoint Server National Institute of Standards and Technology Von NIST zertifiziertes RBAC Standardrahmenwerk Omada Enterprise Omada Identity Manager Object Management Group Operation Permission assignment Policy Information Point Role based access control dt rollenbasierte Zugriffskontrolle Role based access control model 1996 Rollenmanagementwerkzeug der Firma Vaau Incorporated Role hierarchy Separation of Duty Sarbanes Oxley Act Service Pack System role dt Systemrolle Sun Role Manager Statisches SoD Technical system User assignment Unified Modeling Language Forschungsgruppe C amp M Anhang 151 E Abbildungsverzeichnis Information 2 Information 3 Information 4 Information 5 Information 6 Information 7 Information 8 Information 9 Information 10 Information 11 Information 12 Information 13 Information 14 Information 15 Information 16 Information 17 Information 18 Information 19 Information 20 Information 21 Information 22 Information 23 Information 24 Information 25 Info
15. ber einen Internet Browser bedienbar zu sein Dieses System verf gt ber ein Modul zur bersicht ber die angebotenen Schulungen Auch k nnen sich Schulungsteilnehmer direkt ber dieses Portal zu Schulungen an bzw abmelden und Best tigungen ber die Schu lungen ausdrucken an denen sie bislang teilgenommen haben Als dritte Komponente bietet ed tec ein Forum in dem sich registrierte Benutzer austauschen und Administratoren Neuigkei ten bekanntgeben k nnen Ein drittes Unternehmenssystem stellt ein Dateiserver dar ber den Schulungsteilnehmer zus tzliche Schulungsmaterialien auch nach der Durchf hrung einer Schu lung beziehen k nnen Der Zugriff auf dieses System wird ber Zugriffskontrolllisten verwaltet Forschungsgruppe C amp M 124 Fallstudie zur Anwendung der Modelle in einem kommerziellen Produkt die direkt mit den Identit ten der Benutzer verkn pft sind Information 55 stellt die Endsysteme in Bezug zu exemplarischen Berechtigungen dar auf die im Folgenden n her eingegangen wird Technical Layer Server side c amp m Infrastructure Administrator 5 Domain User List Folder Content Contributer Reader Domain Administrator E Enterprise Administrator Write Access E Read Access component _ component JCourse Management Server Network Drive ed tec Portal Server File server J Access Control Table Identity Store J Access Control List SQL Server Active Directory
16. c amp m Infrastruktur verf gt ber ein Identit tsmanagementsystem einen Anwendungsserver f r die angebotenen Schulungen sowie einen zentralen Informationsspeicher zum Ablegen von Do kumenten Jedes dieser Systeme verf gt ber eigene Systemrollen die f r unterschiedliche Be rechtigungsgrade innerhalb dieser Systeme stehen Nachdem ein berblick ber das Szenario gegeben wurde folgt nun die kurze Vorstellung des Rollenmodells sowie des Vorgehensmodells zum planm igen Vorgehen beim Aufbau einer rollenbasierten Unternehmensstruktur F r die Nachvollziehbarkeit auf Seiten des Lesers wird das Vorgehen anhand des eben eingef hrten Szenarios anskizziert und ist in Information 5 dar gestellt Wie in Kapitel 1 2 bereits angedeutet wurde stellt die Unterscheidung zwischen Ge sch fts und Systemrollen den zentralen Inhalt der Modellspezifikation des Rollenmodells dar Auf dieser Grundlage werden funktionale Spezifikationen festgelegt die durch die explizite Trennung der Rollenbegriffe erm glicht werden Um einen groben berblick ber das Rollen modell zu geben skizziert Information 4 diese explizite Trennung an Organizational Layer Technical Layer System Role _ System Role Roje Mapping 1 1 iit User Assignment Policy Assignment _ Policy Information 4 Introduction Role Model Das Vorgehensmodell orientiert sich am klassischen Software Entwicklungszyklus und ist un terteilt in die Analysepha
17. die an dieser Stelle zum Verst ndnis kurz beschrieben werden Die top down Variante geht dabei von einem sehr allgemeinen und abstrakt gehaltenen Bild einer Organisation aus und verfeinert dieses schrittweise um zu geeigneten Rollen zu ge langen wohingegen beim bottom up Vorgehen zun chst auf sehr feingranularerer Ebene be gonnen wird und die dabei gefundenen Berechtigungen anschlie end durch geeignete Zusam menfassungen in Rollen subsumiert werden Der letztgenannten Ansatz beginnt bei der Definition von Rollen und versucht diese Definition in Verbindung zur Organisation und tech nischen Berechtigungen zu bringen SA 04 Vorgehen in der Analysephase Zu Beginn der Analysephase ist es zun chst n tig im direkten Gespr ch mit dem Kunden die Anforderungen an das entstehende Rollenmodell zu erfassen engl requirement engineering Im Gegensatz zum Vorgehen bei klassischer Software Entwicklung hat die Einbeziehung des Kunden in diesem Vorgehensmodell eine zus tzliche Bedeutung Bei der Umsetzung von BRBAC sind die Anforderungen an das Resultat des Prozesses bereits klarer definiert als bei Software Aus diesem Grund scheint es zun chst weniger wichtig im Rahmen einer Anforde rungsanalyse die qualitativen und quantitativen Eigenschaften zu spezifizieren Allerdings ist es m glich dass aufgrund von Budgetbeschr nkungen oder anderen Gr nden zu diesem Zeitpunkt nicht unternehmensweit auf BRBAC umgestellt wird sondern nur f r einen Teil
18. e Authorized permissions r roles gt BET Abbildung einer Rolle r auf eine Menge von Berechtigungen ber die die Rolle entweder direkt oder durch die Vererbung entlang der Hierarchie verf gt Authorized permissions r p permissions Ir gt r p r PA e Role hierarchy RH RH c roles x roles Dabei beschreibt RH eine partielle Ordnung auf Rollen Dabei gilt tr lt authorized_permissions z authorized_permissions t A authorized_users r lt authorized_users r2 Im Fall von beschr nkten Hierarchien wo pro Rolle maximal ein Nachfolger m glich ist gilt zus tzlich folgende Einschr nkung Yr ri r eroles gt ri r gt n gt r r Funktionale Spezifikation Nachdem das hierarchische RBAC Modell spezifiziert ist folgt nun eine Auflistung der vor handenen funktionalen Spezifikation aufgeteilt in die drei Bereiche administrativer Funktionen Funktionen zur Systemunterst tzung und Uberarbeitungsfunktionen e Hierarchische administrative Funktionen Zus tzlich zu den administrativen Funk tionen die in core RBAC festgelegt wurden muss die M glichkeit gegeben werden auf die Hierarchiebildung einzugehen Im administrativen Kontext sind dies Funktionen die nderungen an der Hierarchie vornehmen An dieser Stelle muss erw hnt werden dass die aus core RBAC bekannten Funktionen zur Administration assignUser deassignUser assignPermission und deassignPermission abge ndert werden m ssen damit sie auc
19. erm glicht dass gewisse Rechte genau f r den Zeitraum bei einem Benutzer vorhanden sind in der er im selben Kontext auftritt nicht jedoch dar ber hinaus Dieses Prinzip Forschungsgruppe C amp M Grundlagen 21 ist bekannt als timely revocation of trust Fiir eine vertiefende Betrachtung verschiedener SoD Typen sei an dieser Stelle verwiesen auf FK 07 Kapitel 5 1 An dieser Stelle ist es wichtig festzustellen dass durch sSoD erreicht wird dass ein Benutzer tiber keine Rechte verfiigt die sich aufgrund interner Policys oder rechtlicher Vorgaben ausschlie en Dynamisches SoD hin gegen erm glicht die Definition von Rollen die sich nicht prinzipiell wechselseitig ausschlie en sondern lediglich wenn sie im gleichen Kontext zur Ausf hrung gebracht werden e dSoDc 2 xn ne N n22 dSoD ist eine Menge von Tupeln rs n mitrs lt roles so dass kein Benutzer mehr als n Rollen aus rs in jedem Element rs aktivieren Kann dSoD n rs n Y rsi rs 2 Y se session n N n gt 2 A Isl gt n A IS YS PS C session_roles s Irs lt n Verfiigt das Rollenmodell neben constraints auch noch tiber Hierarchien miissen die eben er wahnten Definitionen fiir ssoD und dSoD angepasst werden Fiir ssoD wird demnach die Men ge an Rollen substituiert durch diejenigen Rollen die einerseits direkt vorhanden sind wie bis her sowie diejenigen Rollen die durch die Vererbung entlang der Hierarchie hinzukommen Die wird durch
20. ftsprozessen zeigt Der Begriff Rolle steht hier als Ausdruck f r die han delnde bzw aktive Einheit innerhalb von Gesch ftsprozessen Um diesen Unterschied klar zu machen wird im Folgenden von Systemrollen engl system roles SR und Gesch ftsrollen engl business roles BR gesprochen Die steigende Komplexit t zeigt sich auf diesen Ebenen in unterschiedlicher Weise Auf der technischen Ebene stellt man fest dass die IT Landschaft in Unternehmen aus einer Vielzahl unterschiedlicher Systeme besteht und demnach sehr heterogen ist WW07 Einerseits befinden sich Systeme unterschiedlicher Technologien und Hersteller im Einsatz und andererseits gibt es pro System eine Vielzahl unterschiedlicher Berechtigungsgrade Dies f hrt zu einer gro en Zahl an Systemrollen die manuell nicht mehr effektiv verwaltet werden kann und den Ruf nach kla ren Strukturen lauter werden l sst Aus Unternehmenssicht stellt sich die Komplexit t anders dar Hier hat man es mit gewachsenen Unternehmensstrukturen mit mehreren Abteilungen und Gesch ftsfunktionen zu tun Zwar k nnen die Abteilungen etwa in Form eines Organisations diagramms in eine klare Struktur gebracht werden jedoch sind die Gesch ftsfunktionen in der Praxis oft nicht in logischer oder hierarchischer Weise sondern beliebig ber das ganze Unter nehmen verteilt Demgegen ber stehen gesetzliche Regularien wie beispielsweise der Sarbanes Oxley Act SOX Sen02 oder das Gesetz zur Kontroll
21. ftsrolle zu anderen zu erfassen Das organization and business role modeling stellt Mechanismen zur Verf gung die es erm glichen diese Unternehmenseigenschaften Forschungsgruppe C amp M Grundlagen 25 festzuhalten und den Zusammenhang zwischen den Gesch ftsrollen herzustellen Vaau07b e Fin Unternehmen ist st ndigen Ver nderungen ausgesetzt Dies umfasst beispielsweise die Einstellung neuer Mitarbeiter den Zukauf weiterer Firmen oder etwa nderungen der Befugnisse von Mitarbeitern F r ein Unternehmen ist es essentiell sowohl nde rungen zur ckverfolgen zu k nnen als auch Auswirkungen von nderungen in der Zu kunft messbar machen zu k nnen Rollenmanagementwerkzeuge erm glichen es im temporal modeling and state management nderungen zur ckverfolgbar oder vorher sagbar zu machen So sollte es zur ckverfolgbar sein k nnen ber welche Rollen ein Angestellter zu einem bestimmten Zeitpunkt verf gt hat und von wem diese Rollen er teilt wurden Die Vorhersagbarkeit hingegen dient der Planung von nderungen an Rol lenzuweisungen oder Rollenstrukturen und misst deren Auswirkungen auf das Rollen modell e Aus der Gesch ftssicht repr sentiert eine Gesch ftsrolle eine Menge an Aufgaben die ein Angestellter in seiner Position im Unternehmen ausf hrt Je nach Aufgabe kann der Umfang einer Gesch ftsrolle sehr limitiert aber auch sehr gro sein Das Ziel eines gu ten Rollenkonzepts ist es den Umfang einer Rolle so
22. hnten Attributen block policy inheritance oder no override versehen sind Durch das Attribut block policy inheritance wird die Policy explizit von der Vererbung ausge nommen Bei der Implementierung des Rollenmodells muss demnach darauf geachtet werden dass diese Policys nicht an die hierarchisch tiefer liegenden Rollen weitergegeben werden Falls das Attribut no override in der Policy einer Rolle vergeben wurde und zus tzlich ein SoD constraint zwischen dieser Rolle und einer hierarchisch tiefer liegenden Rolle definiert wurde kommt die h herwertige Policy trotz des no override Attributs nicht zur Anwendung weil die Rolle die diese Policy enth lt eine Policy Verletzung verursacht somit wegen des SoD constraint nicht verteilt wird Aus dieser Betrachtung erkennt man dass die hier eingef hrten Definitionen die Konsistenz wahren und zu keinen Komplikationen f hren Diese beiden Mechanismen finden sich bislang weder in Modellen noch in RBAC Umgebungen wieder erm glichen aber eine sehr feine Steuerung der Rechtevererbung Durch diese Vererbung wird das Ziel Z unterst tzt Sie ist in Information 43 am Beispiel einer Policy illustriert Forschungsgruppe C amp M 84 Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen component Policy 0 1 Attribute Inheritance Property Value Eg Name Eu Value E Name Information 43 Development of the BRBAC Role Model Policy Inheritance Auch an dieser
23. hrt dazu dass es sowohl m glich ist dass eine Rolle ber genau einen Vorg nger und beliebig viele Nachfolgerrollen verf gen kann Ebenso ist es m glich genau einen Nachfolger und beliebig viele Vorg nger zu modellieren In der Hierarchie kann demnach eine Rolle beliebig viele Vorg nger und Nachfol ger besitzen Veranschaulichen kann man diese Rollenhierarchien durch B ume zur Modellie rung genau eines Vorg ngers mit mehreren Nachfolgern invertierte B ume zur Modellierung genau eines Nachfolgers mit beliebigen Vorg ngern oder als Gitter zur Modellierung einer Kombination aus beidem Diese differenzierte Betrachtung unterschiedlicher Hierarchieformen wird nicht n her beleuchtet Forschungsgruppe C amp M Grundlagen 17 Role Hierarchy Permissions User Assignment Permission Assignment Operations Objects user_session session_roles Sessions Adapted from FS 01 Figure 2 Information 9 Basics NIST RBAC hierarchical RBAC Diese Abbildung zeigt das Rollenmodell mit Hierarchien die auf der Basis von Rollen model liert werden Zus tzlich zu den Spezifikationen f r das core RBAC Modell definiert hierarchi sches RBAC folgende Elemente und Relationen e Authorized users r roles gt 2 Abbildung einer Rolle r auf eine Menge von Benutzern die entweder direkt in die Rolle eingeteilt sind oder durch die Rollenhierarchie enthalten sind Authorized users r u users r gt r u r UA
24. igen Abst nden in Form von vorher exportierten CSV Dateien manuell in den Sun Role Manager importiert wer den Dabei gilt es zus tzlich zu beachten dass die Namenskonvention der Attribute im identity warehouse mit der Konvention in der zu importierenden CSV Datei bereinstimmen muss die von dem technischen Endsystem vorgegeben wird Durch diesen mauellen Zwischenschritt ist es f r SRM nicht m glich zu berpr fen ob die im identity warehouse etablierten Rechte in den Rollen mit den tats chlichen Rechten im Endsystem bereinstimmen Dies ist ein Sachver halt der sehr ung nstig ist weil durch den Einsatz eines Rollenmanagementwerkzeugs der Aufwand verringert und nicht auf andere Verwaltungsaufgaben umgeschichtet werden sollte so dass der resultierende Gesamtaufwand auf Seiten der technischen Administration letztlich in etwa gleichhoch ist Ein teilautomatisiertes Zur ckf hren der in SRM etablierten Rollen ist ak tuell nur mit dem Sun Identity Manager m glich was in dieser Arbeit aber ausgeklammert wur de Serviceorientierung Das letzte Kriterium der Serviceorientierung wird vom Sun Role Manager nicht adressiert Es ist aktuell nicht m glich ber eine Webservice Schnittstelle mit dem System zu interagieren Dadurch ist es ber das Ma an manuellem Export etwa ber CSV Dateien nicht m glich von Au en mit dem Rollenmanagementwerkzeug zu kommunizieren 6 4 Res mee In diesem Kapitel wurde ein Kriterienkatalog entwickelt
25. le von c amp m Das zentrale Portal ed tec das das Unternehmen c amp m einsetzt verf gt ber eine eigene Berech tigungsstruktur die in einer Datenbank abgelegt ist Aufgrund des Zugriffsmusters auf ein CMS System werden folgende drei Systemrollen definiert Die Systemrolle Leser engl reader gew hrt die M glichkeit den Inhalt innerhalb von ed tec aufzulisten Dabei wird an dieser Stelle von der Komplexit t abstrahiert dass sich der gesamte Inhalt von ed tec in sehr viele verschiedene Seiten gliedert und der Forschungsgruppe C amp M Fallstudie zur Anwendung der Modelle in einem kommerziellen Produkt 125 Zugriff auf jede dieser Seiten individuell vorgegeben werden muss Im Gegensatz zum klassischen lesenden Zugriff wie er bei Dateisystemen vorkommt verf gt die System rolle Leser zus tzlich ber die M glichkeit bestehende Inhalte zu erg nzen Jedoch sind nderungen am Aufbau einer Seite oder das L schen von Inhalten die nicht vom betreffenden Benutzer selbst erzeugt wurden explizit ausgeschlossen Dadurch wird realisiert dass sich Benutzer die diese Systemrolle besitzen eigenst ndig zu Schulun gen an und abmelden k nnen Eintr ge im Forum vornehmen oder eigene Eintr ge selbst ndig widerrufen k nnen e Mit der Systemrolle Gestalter engl contributer wird eine aktive Gestaltung einer Seite in ed tec bezeichnet Damit ist insbesondere gemeint dass alte Inhalte gel scht neue hinzugef gt oder
26. und Systemrollen zun chst zwei Rollen modelliert die gesch ftsnahe und technische Aspekte strikt voneinander trennen Beide Rollen verf gen ihrerseits ber eine Hierarchie so dass voneinander unabh ngige Organisati onsstrukturen modelliert werden k nnen Zus tzlich zu den beiden Rollenbegriffen wurden ge nerische Rollen als ein Mechanismus eingef hrt gleiche Rechte zusammenzufassen und von den konkreten Anwendungsf llen zu abstrahieren Dadurch wird gleichzeitig das zur Verwal tung des Rollenmodells ben tigte technische Wissen gesenkt was die Akzeptanz des Modells potentiell erh ht Eines der wichtigsten constraints in der rollenbasierten Zugriffskontrolle stellt separation of duty SoD dar Im BRBAC Modell wurde einerseits statischen SoD modelliert mit dessen Hilfe definiert werden kann dass sich Rollen wechselseitig ausschlie en und ande rerseits dynamisches SoD das den wechselseitigen Ausschluss lediglich in gewissen Kontexten anwendet Nach diesen Modellierungen wurden Mechanismen eingef hrt die sich mit den Poli cys besch ftigen die in Rollen enthalten sind und die Zugriffsrechte spezifizieren Durch Poli cys mit Platzhaltern wurde ein Prinzip vorgestellt das die Zahl an Rollen verringert Dies wird dadurch umgesetzt dass die konkreten Attributwerte von Policys durch Platzhalter offen gelas sen und erst durch ein Benutzerattribut festgelegt werden Im Zuge der strikten Trennung der beiden Sichtweisen ist es im Bezug auf
27. vorbereitende Ma nahmen vor der Installation engl pre installation zusammengefasst In dieser ersten Phase muss der Systemarchitekt somit die resul tierende Architektur planen und die Systemanforderung von OIM analysieren Als Artefakte entstehen dabei konkrete Installationspl ne oder auch Migrationspl ne auf die hier nicht n her eingegangen wird Anschlie end kann damit begonnen werden das Basissystem zu installieren engl basic server system In dieser Phase werden alle Komponenten installiert und konfiguriert die die Installati on von OIM voraussetzt Nach der Installation des Windows Server Betriebssystems wird der Forschungsgruppe C amp M Anhang 141 Microsoft SQL Server als relationale Datenbank aufgesetzt Sobald dies geschehen ist wird das NET Framework installiert falls dies durch die automatischen Updates des Windows Servers nicht bereits durchgef hrt wurde weil die Omada Webanwendung speziell die ASP NET Kom ponente dieses Rahmenwerk f r den korrekten Aufbau der Benutzeroberfl che ben tigt Ferner werden die Office Web Components nachinstalliert die ebenfalls auf der Oberfl che verwendet werden Im Anschluss daran werden die Internet Information Services aufgesetzt die Omada als Webserver voraussetzt Sobald dies abgeschlossen ist Kann mit der eigentlichen Installation des Omada Identity Manager begonnen werden A 2 Installation und Konfiguration von Omada Enterprise Wie bereits erw hnt wurde muss
28. 03 22 Information 26 State of the Art Omada Identity Manager Compliance Module In diesem Prozess wird zun chst eine separation of duty Beschr nkung f r zwei Rollen defi niert Anschlie end wird berpr ft ob von ihr aktuell Benutzer betroffen sind und gegebenen falls die Rollen aufgef hrt die die SoD Verletzung verursachen Den identifizierten Benutzern wird daraufhin sofort die Mitgliedschaft in den konfliktbehafteten Rollen entzogen und der Rol lenverantwortliche dar ber in Kenntnis gesetzt Im n chsten Schritt ist in Information 26 die Ansicht eines Benutzers dargestellt der die Historie seiner Rollenzuteilungen einsieht Dies er h ht die Transparenz der Gesamtumgebung Daraufhin k nnen die Rechte des Benutzers analy siert und gegebenenfalls angepasst werden Sollte dieser Schritt au erhalb von OIM vorge nommen werden wird dies einem Verantwortlichen signalisiert Im letzten Prozessschritt sind die Prozessindikatoren f r zwei workflows dargestellt aus denen die Leistung der workflows abgelesen werden kann Diese Kennzahlen werden zur Messung der Dienstg te und der daraus abgeleiteten Qualit tsgarantie engl service level agreement herangezogen Im Beispiel sind dies etwa die Anzahl der Ausf hrungen oder die durchschnittliche Bearbeitungszeit Forschungsgruppe C amp M Stand der Technik 53 3 2 5 Automatische Ablaufe und werkzeugunterstutzte Bewilligun gen OIM bietet eine eigene grafische Bedienoberfl che
29. 2 1 Die Subjekt Objekt Relation 220022002200nsnensnensneesnnesnnesnnesnnennnnnnnnnnsnensnnnsn esse ennnon 11 2 2 Das NIST RBAC Standardrahmenwerk cccccccccesssceesscceceesecececseaececseaaeeecseaeeeeneaaes 12 2 2 1 RBAC Kernmodell u aesesielisachliiiieieilasiinalihailiikeuhtenn 13 2 2 2 RBAC Modell mit Hierarchien uu000200sessssnseessnsnneenensnnnnnsnnnnnnnnnnnsn nennen 16 2 2 3 RBAC Modell mit Beschr nkungen uususccssennseessnsessnnennsnnnenn esse ennnnnn 19 2 3 Aufgaben von Rollenmanagementwerkzeugen ucsnsecssseesseneensnessnnennnnnennn essen 23 3 Stand der Technik 29 3 1 Modelle f r die rollenbasierte Zugriffskontrolle eee ee eee eeeeeereeereeeeeceecnseseseseaeenaeee 29 3 1 1 Modell zur Entwicklung von Rollen cece eeceeeceseeeeeeeeeeeseeeseeeaecsaecsaecnseeeaeens 29 3 1 2 Rollenmodell f r unternehmensweite Zugriffskontrolle ERBAC 32 3 1 3 Das erweiterte ERBAC Modell cccccccccssssecesssceceesecceceeseseecesseeaeeseseeeeeseeeeaeens 33 3 1 4 Modell f r den Lebenszyklus von Rollen uusssssssessssenssnenensennsnnennnnn 37 3 2 Rollenbasierte Zugriffskontrolle im Omada Identity Manager ensse 40 3 2 1 Architektur und Datentypen des Omada Identity Manager 41 3 2 2 Der Arbeitsbereich connectivity eeseeesseessssessnsennenensnnennsnnnnnnnnnnensnsnnnnnnennnnn 45 3 2 3 D
30. Applications AWA Basics of AWA Course Uni of the Lecture Advances Web Applications http www cm tm uka de Universitat Karlsruhe TH C amp M Prof Abeck 2008 Cooperation amp Management Advanced Web Applications AWA Identity management Course Unit of the Lecture Advances Web Applications http www cm tm uka de Universit t Karlsruhe TH C amp M Prof Abeck 2008 Aleksander Dikanski Integration eines bestehenden Sicherheitsprodukts in eine bestehende Zugriffskontroll Architektur Diplomarbeit Forschungs gruppe C amp M Universitat Karlsruhe TH 2008 Aleksander Dikanski Korbinian Molitorisz Autorisierungspriifung f r Webservices mit IBM Werkzeuge Team Studienarbeit Forschungsgruppe C amp M Universitat Karlsruhe TH 2008 Dudenredaktion Die deutsche Rechtschreibung Das umfassende Stan dardwerk auf der Grundlage der neuen amtlichen Regeln Band 1 Bibliog raphisches Institut Mannheim 24 Auflage Juli 2006 Christian Emig Frank Brandt Sebastian Abeck Jiirgen Biermann Heiko Klarl An Access Control Metamodel for Web Service Oriented Architec tures International Conference on Software Engineering Advances 2007 Claudia Eckert IT Sicherheit Oldenbourg 2005 Christian Emig Zugriffskontrolle in dienstorientierten Architekturen Uni versit t Karlsruhe 2008 David F Ferraiolo D Richard Kuhn Ramaswamy Chandramouli Role Based Access Control Second Edition Artech House 2007
31. Art unterworfen ist bietet SRM neben automati schen Erinnerungen f r Rollenzuweisungen die M glichkeit an Berechtigungs nderungen auf einen bestimmten Zeitpunkt in der Zukunft zu verlegen um den Arbeitsprozess erst zu diesem Zeitpunkt automatisch anzusto en Dadurch ist es zum Beispiel m glich nderungen in regel m igen Abst nden zu planen oder etwa berpr fungen an Berechtigungen vorzunehmen Ka07b Sun08a Da sich diese Aufgaben alle mit dem berpr fen von Rollenzuweisungen von einer Menge an Mitarbeitern besch ftigt werden sie im Unternehmenskontext eher von einer Person mit Personalverantwortung durchgef hrt Deswegen ist dieser zweite Arbeitsbereich des Role Manager auch eher der Gesch ftsebene zuzuordnen Die Funktion identity certification be findet sich in Information 11 in der Schnittmenge aus attestation and compliance policy mana gement und role reconciliation Um die Sichtweise der Gesch ftsebene zu unterst tzen bietet der Role Manager ber die Benutzeroberfl che die M glichkeit die Zuweisungen namentlich zu ver ndern was die Lesbarkeit im Wirkbetrieb wesentlich erh ht und somit den Verantwortli chen den Umgang mit diesem Werkzeug erleichtert Weil die Benutzer wie hier beschrieben durch selbst gew hlte Bezeichner von technischen Details abstrahieren k nnen wird die Be dienbarkeit des Werkzeugs erleichtert Der dritte Bereich des Sun Role Manager besch ftigt sich mit der Erkennung und Behebung von Aus
32. David F Ferraiolo Ravi Sandhu Serban Gavrila D Richard Kuhn Ramaswamy Chandramouli Proposed NIST Standard for Role Based Ac cess Control ACM Transactions on Information and System Security TIS SEC Band 4 Ausgabe 3 Seiten 224 274 August 2001 Jay R Galbraith Designing Organisations An Executive Guide to Stratgy Structure and Process John Wiley amp Sons Inc 2002 Forschungsgruppe C amp M Anhang Ge04 GRO2 Ka07a Ka07b Ka07c Ke02 KG07 KK 02 KS 03 La69 MicO5a MicO5b 167 Gerry Gebel Managed Authorization Services Implementing Roles Rules and Policys Burton Group Version 1 0 http www burtongroup com Client Research Document aspx cid 633 14 Dezember 2004 Johannes Grabmeyer Andreas Rudolph Techniques of Cluster Algorithms in Data Mining Springer Netherlands Band 6 Ausgabe 4 Seiten 303 360 http www springerlink com content d6ekxxcu0d2ngamj Oktober 2002 Kevin Kampman Role Management Taking Shape Burton Group http www burtongroup com Client Research Download aspx cid 1 106 03 April 2007 Kevin Kampman Understanding Role Management Applications No Pain No Gain Burton Group Version 1 http www burtongroup com Client Research Document aspx cid 1114 17 Mai 2007 Kevin Kampman Role Management in the Enterprise Street Scenes Bur ton Group Version 1 http www burtongroup com Client Research Download aspx cid 1126
33. E Certified Revoked 732 3 45 a H 2 2 Total number of Accounts Aen ome BE 4 Total number of Namespaces On en tt N lata of Endpoints incomplete 88 73 men u New E In Progress Complete Revoked 19 Incomplete 488 Certified 43 Notifications issued in last week Statistics User Roles Certification Status Average Certified Revoked certifications i 5 00 0 00 per business unit Notification Type Average roles per user a dS S First Reminder to manager Average m Second Reminder to manager accounts per Incomplete user 95 00 m First Reminder to manager s manager a a Average users Second Reminder to manager s manager in business unit m Reminder to IT security department Revoked 0 Incomplete 19 Certified 1 Information 36 State of the Art Sun Role Manager Identity Certification Dashboard Information 36 zeigt die grafische Benutzeroberfl che f r einen Rollenverantwortlichen Eine Rolle kann in SRM unterschiedlichen Arten von Zuweisungen besitzen Zum Einen gibt es die Zuweisung von Benutzern zu Gesch ftseinheiten etwa einer Abteilung zum Zweiten die Zu weisung von Benutzern zu Gesch ftsrollen und zum Dritten die Zuweisung von Systemrollen zu Gesch ftsrollen Diese Aufteilung erm glicht es die Arbeitsprozesse sehr feingranular zu ge stalten Genauso ist es aber m gl
34. Em08 DMO 8 so dass das letzte Kriterium bewertet ob die Rollenmanagementwerkzeuge diesem Paradigma folgen Criteria 1 Roles 1 1 Business Roles 1 2 System Roles 2 Hierarchies 2 1 Business Role Hierarchies 2 2 System Role Hierarchies 3 Role Mining 4 Workflow capability 4 1 Process 4 2 Monitoring 5 Usability 6 Support of Feedback 7 Service oriented approach Information 51 Analysis of Role Management Solutions Evaluation Criteria Forschungsgruppe C amp M Analyse aktueller Rollenmanagementwerkzeuge 111 6 1 2 Spezifikation der Kriterien Die in Information 51 aufgef hrten Kriterien werden im Folgenden detailliert beschrieben Wie bereits angesprochen wurde sind die genannten Kriterien disjunkt zueinander Daher ist es nicht m glich eine Metrik zu definieren die f r jedes Kriterium sowohl g ltig als auch aussagekr f tig ist Aus diesem Grund wird jedes Kriterium f r sich in zwei Qualit tsauspr gungen einge teilt und innerhalb dieser in zwei G teklassen Die erste Unterscheidung gibt dabei an ob das Werkzeug das Kriterium berhaupt erf llt oder nicht Dies wird symbolisiert durch ein Plus bzw ein Minussymbol Wird eine Unterst tzung eines Kriteriums durch das Werkzeug angebo ten wird dann die Qualit t der Unterst tzung dieses Kriteriums durch ein weiteres Plus bzw Minuszeichen verdeutlicht Diese Werkzeugbeurteilungen wird dabei unabh ngig vom
35. Flexibilit t und Effizienz um wettbewerbsf hig bleiben zu k nnen Dies trifft sowohl f r die Gesch ftsprozesse als auch f r die darunterliegenden technischen Systeme zu Ein Defizit stellen hierbei die Verf gbarkeit und Verl sslichkeit von Informationen in Systemen dar da die zugrunde liegende Sicherheits Architektur nicht mit der gleichen Geschwindigkeit wie die Informationstechnologie selbst gewachsen ist D2 Die Komplexit t und Kosten wachsen durch immer vielf ltigere Anforderungen und An wendungen Der Autor nennt daf r viele Beispiele unter Anderem dass Anwendungen auf im mer mehr Plattformen eingesetzt werden die Organisationsstrukturen von Unternehmen durch Zuk ufe immer komplexer werden und die Erteilung von spezifischen Zugriffsberechtigungen eines Benutzers sich immer schwieriger gestaltet Auf Seiten der technischen Administration wird dadurch immer mehr Spezialwissen ben tigt D3 Die Erfahrung aus Industrieprojekten zeigt dass das ERBAC Modell selbst zu viele Rol len bedingt wof r der Autor zwei haupts chliche Gr nde nennt Vielen Faktoren wie etwa die Zugeh rigkeit zu einer Organisationseinheit Jobfunktion oder Ort im Sinne einer Zweigstelle bestimmen die individuellen Zugriffsrechte Anstatt unterschiedlicher Rollenhierarchien m sste f r jede Kombination eine eigene Rolle erstellt werden Als zweiten Grund nennt der Autor den Bedarf an feingranularer Kontrolle auf Anwendungsebene die pro Granularit t eine
36. Gesch ftsrol len Systemrollen Relation aus Kapitel 7 2 Sie beziehen sich dabei auf Information 56 und In formation 57 Dort wurde zum besseren Verst ndnis und f r eine vereinfachte Darstellung le diglich ein Ausschnitt dargestellt i System Roles i Business Roles with single System Policy Business Roles Identity Store E3 Domain Administrator Security Consultant ed consult General Manager c amp m Enterprise Administrator E Domain User component Course Management Server administrator Marketing Assistent c amp m E Contributer If Accounting Assistent c amp m Service Manager ed serv General Manager i2s component Network Drive N Trainer c amp m write Access 7 List Folder Content N Read Access Course Participant i2s IT Administration c amp m Information 65 Appendix Role Mapping with Simple System Roles Forschungsgruppe C amp M Anhang 148 Pe Business Roles stem Roles a 2 lt 5 a v gt N 2 2 03 7p 3 E lt Business Roles E c amp m Default Access E Domain User General Manager c amp m Read Access General Manager i2s E c amp m Extended Access E Contnbuter Marketing Assistent c amp m Eu write Access Course Participant i2s E c amp m External Admin E Domain Administrator Trainer c amp m IT Administration c amp m Accounting Assistent c amp m E ed tec Full Access Admini
37. Hal L Feinsteink Charles E You mank Role Based Access Control Models EEE Computer Band 29 Number 2 Seiten 38 47 Februar 1996 The Senate and House of Representatives of the United States of America in Congress Sarbanes Oxley Act Washington D C 23 Januar 2002 http frwebgate access gpo gov cgi bin getdoc cgi dbname 107_cong_bills amp docid f h3763enr tst pdf Web seite Stand 25 Mai 2008 Sun Microsystems Sun Welcomes Vaau http www sun com software vaau index xml Sun Microsystems Web seite Stand 25 Mai 2008 Sun Microsystems Product line Identity Management http www sun com software index jsp cat Identity 20Management amp tab 3 Sun Microsystems Webseite Stand 29 Mai 2008 06 01 Andrew S Tanenbaum Moderne Betriebssysteme 2 berarbeitete Aufla ge Pearson Studium 2003 Forschungsgruppe C amp M Anhang 169 Vaau07a Vaau Incorporated RBACx Install Guide 4 0 Vaau Incorporated 2007 Vaau07b Vaau Incorporated RBACx User Guide 4 0 Vaau Incorporated 2006 WWO07 Felix Wortmann Robert Winter Vorgehensmodelle f r die rollenbasierte Autorisierung in heterogenen Systemlandschaften Wirtschaftsinformatik Band 49 Nummer 6 Seiten 439 447 Dezember 2007 Die angegebenen Webseiten wurden am 14 Oktober 2008 auf G ltigkeit berpr ft Forschungsgruppe C amp M
38. In SRM wird der wechselseitige Ausschluss von Rollen im Gegensatz zu OIM nicht zentral vorgehalten sondern in den betref fenden Rollen selbst festgehalten Somit kann in einer Rolle direkt eingesehen werden mit wel chen anderen Rollen sie im Konflikt steht Eine Rolle kann in SRM explizit aktiviert und deak tiviert werden sowie ein zeitliches Intervall angegeben werden f r das sie aktiv ist Daher ist es m glich zeitliche Beschr nkungen zu definieren die automatisch umgesetzt werden Hierarchien SRM unterst tzt eine Hierarchie bei Gesch ftsrollen und dar ber hinaus beliebig viele vonei nander unabh ngige Hierarchien bei den Gesch ftseinheiten zu denen die Rollen zugeteilt sind Leider beschr nkt sich die Hierarchiebildung bei Rollen lediglich auf organisatorische Aspekte wie etwa strukturelle Hierarchien auf Gesch ftsebene so dass gemeinsame Rechte oder Eigen schaften im Allgemeinen nicht vererbt werden k nnen Eine Hierarchie auf Ebene der Policys wird daher in der vorliegenden Version nicht unterst tzt Daher k nnen gemeinsame Rechte Forschungsgruppe C amp M 118 Analyse aktueller Rollenmanagementwerkzeuge nicht modularisiert werden und m ssen in allen ber dieses Recht verf gende Rollen eingetra gen werden Dies sorgt fiir einen gewissen Pflegeaufwand innerhalb des Systems und verursacht dar ber hinaus mehrfache Datenhaltung Daraus ergeben sich Mehraufw nde in den Bereichen Datenkonsistenz und Datenadministr
39. Kontext im Benutzerobjekt selbst verankert ist Jede Aktion die ein Benutzer ausf hrt wird in einem Kontextfeld seines Benutzerkontos hinterlegt was ne benbei den Effekt hat dass s mtliche Aktionen dieses Benutzers protokolliert und somit auch noch zu einem sp teren Zeitpunkt nachvollzogen werden k nnen Damit kommt dieses Modell rechtlichen Vorgaben nach nach denen Benutzeraktionen l ckenlos protokolliert werden m s sen An dieser Stelle sei verwiesen auf den Sarbanes Oxley Act SOX Sen02 und das Gesetzt zur Kontrolle und Transparenz im Unternehmensbereich KonTraG Bun98 Das Ergebnis dieses Ansatzes ist eine erh hte Sicherheit bei vertraulichen Arbeitsg ngen unter Beachtung des jeweiligen Kontexts Das betrifft sowohl gesch ftliche Vorg ngen wie etwa berweisun gen Kreditbewilligung als auch tiefgreifende Eingriffe ins System wie etwa dem L schen eines Benutzerkontos Forschungsgruppe C amp M 80 Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen 4 3 Modellierung von Policy Erweiterungen In den vorangegangenen drei Teilkapiteln lag der Fokus auf der Modellierung der Anforderun gen f r das Ziel Z Dabei standen die Unterteilung von Gesch fts und Systemrollen im Vor dergrund sowie der Zusammenhang zwischen diesen beiden Begriffen Die eingehende Betrach tung der beiden Rollenbegriffe stellt den Teil der Modellspezifikation von BRBAC dar wohingegen in den verbleibenden drei Teilkapitel
40. Konzepte Subjekt engl subject und Objekt engl object eingef hrt und die Zugriffskontrolle ber eine Zugriffsmatrix engl access matrix vor genommen die Subjekt und Objekt direkt miteinander verkn pft Dieses Modell war sehr ab strakt gehalten und wurde in den Jahren ab 1970 mathematisch spezifiziert worauf sich ein all Forschungsgruppe C amp M 2 Einleitung gemeines Verst ndnis einer aktiven Einheit subject und einer passiven Einheit object zur Be schreibung von Zugriffsversuchen herausbildete Die Zugriffsmatrix ist in Form einer Relation zwischen Subjekt und Objekt realisiert die die Zugriffsrechte spezifiziert und so den Berechti gungsgrad definiert Technisch wird dieser Sachverhalt oft in Form von Zugriffskontrollliste engl access control list ACL realisiert ber die jede Ressource selbst verf gt Dieses Modell ist heute bekannt als identit tsbasierte Zugriffskontrolle engl identity based access control IBAC C amp M A ID weil die Zugriffsrechte direkt f r die Identit t des zugreifenden Subjekts definiert sind EB 07 Zwar ist dieser Architekturstil leicht verst ndlich und durch die Relation zwischen Subjekt und Objekt leicht implementierbar jedoch weist er zwei wesentliche Nachtei le gerade in vernetzten Unternehmenslandschaften auf Erstens skaliert IBAC f r steigende Be nutzerzahlen und Ressourcen sehr schlecht was daran liegt dass jede Ressource ber eine eige ne Zugriffskontrollliste verf gt
41. Operationen werden definiert o createSSoDSet Erzeugen einer benannten Instanz eines statischen SoD constraint o deleteSSoDSet L schen einer existierenden statischen SoD Relation o addSSoDRoleMember Hinzuf gen einer Rolle zu einer bestehenden sSoD Instanz o deleteSSoDRoleMember Entfernen einer Rolle aus einer statischen SoD constraint Instanz o setSSoDCardinality ndern der Kardinalit t dieser Instanz e Systemunterst tzende Funktionen Die Funktionen zur Unterst tzung von Systemen sind identisch mit denen aus core RBAC e Funktionen zur berarbeitung F r die Implementierung des statischen SoD Modells sind alle Funktionen zur berarbeitung aus core RBAC n tig In Anlehnung an die zu Forschungsgruppe C amp M 22 Grundlagen s tzlichen administrativen Funktionen sind an dieser Stelle ebenfalls weitere Funktio nen notig die die Ergebnisse der administrativen Funktionen fiir die Uberarbeitung des Rollenmodells sichtbar machen Dies beinhaltet eine Funktion zur Auflistung der er zeugten sSoD Instanzen eine Funktion zur R ckgabe der mit einer Instanz verkn pften Rollen sowie eine Funktion zur R ckgabe der Kardinalit t o sSoDRoleSets Liefert die Menge der definierten Instanzen einer sSoD Relation zur ck o sSoDRoleSetRoles Liefert die Menge an Rollen einer sSoD Instanz zu r ck o sSoDRoleSetCardinality Liefert die Kardinalit t einer Instanz zur ck Funktionale Spezifikation f r die
42. Rollen ben tigt wird findet sich in verteilten Datenban ken und da Rollen Objekte darstellen die gemeinsame Zugriffsmuster subsumieren liegt die Idee nahe den gerade erw hnten Mechanismus auf Zugriffskontrolldaten zu bertragen Der ro le mining Ansatz wendet diesen Mechanismus an um aus den vorliegenden Daten Rollen abzu leiten Dabei werden zwei unterschiedliche Auspr gungen des Begriffs Rolle unterschieden die organizational role und die functional role Da im weiteren Verlauf dieser Arbeit ebenfalls zwischen zwei Rollentypen unterschieden wird sei hier erw hnt dass die beiden Unterschei dungen nicht gleichgesetzt werden d rfen obwohl sie durchaus gewisse Gemeinsamkeiten ha ben Beide Unterscheidungen definieren eine Rolle einerseits als Beh lter f r gesch ftsnahe Funktionen engl organizational role und andererseits f r Zugriffsrechte engl functional ro le Die Unterschiede zu den beiden zentralen Rollentypen dieser Arbeit werden im Fortgang dieses Kapitels noch genauer betrachtet Functional roles verf gen ber eine Menge an Attribu ten die allen Benutzern zuteil werden die in diese Rolle eingetragen sind Der Anwendung der role mining Algorithmen geht eine Auswahl der Benutzer und Endsysteme voraus weil hier durch der Datenbestand auf einen geeigneten Ausschnitt eingeschr nkt wird F r das Entwi ckeln von Rollen sind die Benutzerkonten selbst mit einzubeziehen sowie deren Attribute und alle technischen Endsys
43. Stelle sei abschlie end ein Beispiel angegeben Man gehe von einem Unterneh men aus mit drei Hierachieebenen Der Gesch ftsleitung den einzelnen Abteilungen mit Abtei lungsleitern sowie den Bediensteten in den Abteilungen Die Gesch ftsleitung habe bei der An meldung an einem System die Startseite des Internet Browsers auf die externe Firmen Homepage gesetzt Da dies eine technische Einstellung mit Bezug zu einem technischen End system darstellt w rde das Beispiel als System Policy realisiert die sich entsprechend an alle Hierarchiestufen weitervererbt Die Abteilungsleiter jedoch besitzen eine interne Kollaborati onsplattform die als Startseite verwendet werden solle Dazu m sste man eine zweite Policy de finieren die als Wert statt der Firmen Homepage nun die Kollaborationsplattform hat Man h t te demnach zwei System Policys die unterschiedliche Werte f r dasselbe Attribut definieren Ginge man davon aus dass die zweite Policy die erste berschreibt werden sowohl die Abtei lungsleiter als auch die Mitarbeiter der Gesch ftsleitung korrekt umgeleitet Allerdings h tte man dann das Problem dass die Angestellten der Abteilung ebenfalls auf das Portal umgeleitet werden weil diese in der Hierarchie unter den Abteilungsleitern angeordnet sind In dem hier vorgestellten Modell kann man nun die entsprechende Policy auf Abteilungsebene durch das Attribut block policy inheritance versehen so dass die Einstellung f r das Kollaborationspor
44. Stelle sei erg nzend erw hnt dass sich im Kontext der rol lenbasierten Zugriffskontrolle verschiedene Bezeichnungen f r ein und denselben Sachverhalt durchgesetzt haben Um Missverst ndnisse zu vermeiden werden diese Begriffe nun zueinan der in Bezug gesetzt Ein wichtiger Aspekt bei Zugriffskontrollarchitekturen stellt die Spezifika tion des Zugriffs dar Hierf r haben sich die Begriffe permission oder Policy durchgesetzt Sowohl in RBAC wie auch in ERBAC wird eine Berechtigung allgemein als permission be zeichnet wie aus den Kapiteln 2 2 und 3 1 2 hervorgeht Diese Bezeichnung unterstreicht die N he zu technischen Systemen in denen Berechtigungen auch als permission definiert sind Auf der Gesch ftsebene hat sich zur Formulierung von Berechtigungen hingegen der Begriff Policy etabliert Diese Arbeit verwendet hingegen in Anlehnung an Em08 den Begriff Po licy als Bezeichnung f r Berechtigungen und unterscheidet dabei durch ein geeignetes Pr fix ob sie aus Gesch ftszielen abgeleitet wurden oder zur Unterst tzung von technischen Zugriffs rechten in Systemen dienen Im Folgenden wird zur Unterscheidung dieser beider Bereiche bereinstimmend von Gesch fts oder System Policys gesprochen Aktuell l sst sich feststellen dass die Forschung im Bereich RBAC schon sehr weit vorange schritten ist jedoch stets von einem sehr allgemeinen Rollenbegriff ausgehen Die Umsetzungen dieser Modelle in der Industrie weisen jedoc
45. Verantwortlichen am Entwurf ist sichergestellt dass die ge plante Umsetzung auch in deren Sinne erfolgt Durch die finale Abnahme durch den Kunden wird sichergestellt dass das bisher erarbeitete in seinem Interesse umgesetzt wird engl design verification An diesem Gespr ch m ssen Consultants und Analysten nicht unbedingt anwe send sein da dies die M glichkeit einr umt dass die Verantwortlichen des Unternehmens im direkten Gespr ch miteinander eventuell als kritisch erachtete Punkte des Entwurfs entdeckt und diskutiert Ein abschlie endes Interview mit Consultants und Analysten in dem der Kunde die Ergebnisse der Verifikation vortr gt ist angedacht und beschlie t damit das Ende der Entwurfs phase Alle Aktionen und Zust ndigkeiten sind in Information 48 dargestellt Am Ende der Entwurfsphase sind die unterschiedlichen Rollen samt Berechtigungen und Benutzern hinrei chend spezifiziert und k nnen nach der finalen Abnahmen durch den Kunden in einem Rollen managementwerkzeug implementiert werden Dies ist Bestandteil der Implementierungsphase Zust ndigkeit Die Entwurfsphase selbst ist durch die Komplexit t des Gesamtsystems sowie die unterschiedli chen Kompetenzen sehr arbeitsteilig und erfordert eine ebenso aktive Kommunikation zwischen allen Beteiligten Der top down Entwurf auf Ebene der Gesch ftsleitung wird dabei ma geblich gepr gt von den Analysten die in der Analysephase durch die Gespr che mit dem Kunden in die Organi
46. Wahr scheinlichkeit dass durch einen R cksprung in die Entwurfs oder gar die Analysephase nach gebessert werden muss In Absprache mit dem Kunden kann es somit an dieser Stelle zur ber arbeitung einer vorhandenen Anforderung oder gar einen R cksprung in die Entwurfs oder Analysephase kommen In diesem Fall muss der Zeitplan f r die Umsetzung berarbeitet wer den weil durch R ckkopplungen der urspr nglich anvisierte Zeitplan unter Umst nden nicht eingehalten werden kann Bei der Ausweitung des Parallelbetriebs auf das gesamte Unterneh men werden zwei Ziele verfolgt die ihrerseits zu R ckkopplungen f hren k nnen Einerseits k nnen bei der Ausweitung neue Erkenntnisse hinzukommen die eine Nachbesserung des Mo dells nach sich ziehen Andererseits kann Nachbesserungsbedarf seitens der Benutzer bestehen der auf Bedienschwierigkeiten zur ckgef hrt und somit unmittelbarer behoben werden kann als es bei tiefgreifenden Vers umnissen im Rollenmodell der Fall ist Durch den Parallelbetrieb je doch wird ja insbesondere das Ziel verfolgt dass sich die Benutzer an die neue Zugriffskontrol le gew hnen Die Liste der Nachbesserungsw nsche gilt gleicherma en als Pr fstein f r das umgesetzte Rollenmodell Kommt es zu vielen Problemen oder Engp ssen bei den Leistungsin dikatoren ist dies ein deutliches Indiz daf r dass in der Entwurfsphase nicht sorgf ltig genug modelliert wurde und somit in die Entwurfsphase zur ckgekehrt werden sol
47. Werkzeugs Beispielswei se ndern sich Zugriffsrechte neue Rollen kommen hinzu oder die Mitgliedschaft von Benut zern in Rollen ndert sich Information 51 zeigt den Bewertungskatalog an dem die Werkzeuge gemessen werden Das f nfte Kriterium versucht eine Bewertung der Benutzerfreundlichkeit zu geben obwohl dies objektiv nicht gegeben werden kann weil dies stets von subjektiven Eindr cken beeinflusst wird Jedoch wird hierbei versucht den n tigen Arbeitsaufwand zu verglei chen der n tig ist um mit dem Werkzeug zu interagieren was durchaus objektiv festgestellt werden kann Das sechste Kriterium befasst sich mit der Art und Weise wie die Daten des Rol lenmanagementwerkzeugs in die Endsysteme zur ckgef hrt werden und somit mit den Kom munikationsbeziehungen zwischen den Systemen Im Rahmen dieser Arbeit ist es eine grundle gende Voraussetzung dass die rollenbasierte Zugriffskontrolle nicht f r ein einzelnes Endsystem sondern system bergreifend eingesetzt wird Aus diesem Grund macht es Sinn die Kommunikationsbeziehung zu technischen Endsystemen zu analysieren Beim Vorhaben eine Zugriffskontrollarchitektur in eine bestehende Umgebung zu integrieren die f r diese autorita tiv sein soll stellt sich die Frage ob sie im Sinne eines Dienstgeber Dienstnehmer Verh ltnisses auch ber Webservice Schnittstellen erreichbar ist oder nicht Heutzutage ist eine Tendenz hin zu dienstorientierten Zugriffskontrollarchitekturen erkennbar
48. Werkzeugs vorgestellt sowie dessen Datentypen Es soll hier zun chst ein berblick ber das Produkt gegeben werden ehe im Anschluss daran eine ge naue Betrachtung der beiden Arbeitsbereiche role management und compliance folgt sowie den jeweils enthaltenen Komponenten Diese Betrachtung wird in Form eines Prozesses geschildert um die Anschaulichkeit zu unterst tzen Um ein detailliertes Gesamtbild dieses Werkzeugs zu pr sentieren werden alle Komponenten die f r das Rollenmanagement von Belang sind objek tiv dargestellt Auf der Basis dieser Produkteinsicht wird in Kapitel 6 dieser Arbeit die Qualit t des Omada Identity Manager anhand eines Kriterienkatalogs bewertet 3 2 1 Architektur und Datentypen des Omada Identity Manager Der Omada Identity Manager besteht aus mehreren Einzelmodulen bzw Komponenten die in nerhalb des Gesamtkontextes des Rollenmanagements unterschiedliche Funktionen realisieren Die Datenbasis auf die sich die Module st tzen und operieren ist eine OIM interne Datenbank Diese synchronisiert sich ber die Komponente connectivity regelm ig mit dem Metaverzeich nis des Microsoft Identity Lifecylce Manager ILM das als Provisionierungsplattform verwen det wird und die Schnittstelle zu den zugrundeliegenden Endsystemen darstellt Aus dem Blickwinkel von OIM stellt dieses Metaverzeichnis somit den Gesamtdatenbestand des Unter nehmens dar Der Administrator des Omada Identity Manager Kann nun genau spezifizieren
49. Zugang zu diesen Informationen haben oder mit diesen Informationen nicht versorgt werden Im Falle von Policys w rde die Rollenmanagementl sung dadurch zu einem Policy Infor mation Point PIP f r die gesamte Umgebung Eine bestehende Zugriffskontrollarchi tektur k nnte direkt mit einem PIP kommunizieren und w rde somit von einer Kompo nente die Policy Informationen zentral kapselt und verwaltet direkt profitieren Diese Information ber einen Dienstzugangspunkt mit Standardschnittstellen anzubieten w re besonders beim Umstieg auf eine Rolleninfrastruktur n tzlich wo oftmals Altsysteme engl legacy systems vorhanden sind Die Prinzipien role publishing sowie policy pub lishing steuern somit einen wertvollen Beitrag hin zu einer wohldurchdachten Infrast ruktur bei Neben dem passiven Anbieten von Rollen und Policy Informationen ist der Arbeitsbereich role integration aktiv an einer Integration mit anderen L sungen betei ligt Dabei werden nderungen an Rollen oder Policys an andere Zugriffskontrollsys teme weitergereicht Die Anforderungen an die angebotenen Schnittstellen sind in die sem Fall wesentlich h her So wie Gesch ftsrollen ben tigen auch Systemrollen einen Mechanismus zur Definiti on Verwaltung und Suche um erfolgreich eingesetzt werden zu k nnen Dies wird un ter dem Begriff IT role management verstanden Das aktive berwachen der Zugriffe von Benutzern auf Ressourcen ist Bestandteil des activity monitoring
50. Zugriffskontrollarchitektur umsteigen m chte Um dies zu realisie ren wird das Vorgehensmodell aus Kapitel 5 angewandt welches das Rollenmodell aus Kapitel 4 in den Wirkbetrieb berf hrt Anschlie end wird auf der Basis der Werkzeugbewertung aus Kapitel 6 ein Rollenmanagementwerkzeug f r dieses Szenario ausgew hlt und Kernaspekte der technischen Umsetzung beleuchtet 7 1 Vorstellung des Beispielszenarios internet supported trai ning In diesem Kapitel wird das Beispielszenario internet supported training IST vorgestellt wel ches der Umsetzung der Modelle zugrunde liegt die in dieser Arbeit entwickelt wurden Dabei werden zun chst die an diesem Szenario beteiligten Unternehmen pr sentiert und anschlie end die Gesch fts und Systemrollen definiert Dieses Szenario handelt von einem Anbieter IT gest tzter Fortbildungskurse cooperation amp more c amp m Die Kernkompetenz des Unternehmens c amp m stellt das Angebot von Fortbildungskursen ber das Schulungsportal education technology ed tec dar welches von der Software Firma education software ed soft vertrieben wird Ein exemplarischer Kunde von c amp m ist das Unternehmen intelligent internet solutions i2s das seine Mitarbeiter durch das Schulungsangebot von c amp m fortbilden l sst Dabei kann die Teil nahme an Fortbildungskursen sowohl per Fernzugriff aus dem internen Netz von i2s erfolgen aber auch per direktem Zugriff aus der technischen Infrastruktur von c amp m F r di
51. and correlation und ist eine weitere Hilfe beim Erstellen von Rol len weil so Zugriffsmuster entdeckt werden k nnen und die Granularit t der Rollen passgenau an das Zugriffsverhalten der Benutzer angeglichen werden kann Werden Ressourcen ber einen gewissen Zeitraum hinweg berwacht k nnen geh uft auftre tende Zugriffsversuche aufgezeichnet und dadurch unangemessene Zugriffsberechti gung von Benutzern entdeckt werden Auf technischer Ebene ist eines der Hauptziele des Rollenmanagements die Zugriffs kontrolle auf Ressourcen so einfach wie m glich zu gestalten Es wird daher versucht m glichst allgemeine Zugriffsrechte zu konzipieren die bei Zuweisungen zu Gesch fts rollen m glichst oft wiederverwendet werden k nnen Das Rollenmanagement sollte im IT role modelling M glichkeiten zur Verf gung stellen diese Zugriffsrechte in System rollen zu kapseln Dar ber hinaus sollte eine Zuordnung von Gesch fts und Systemrol len m glich sein Auf unterster technischer Abstraktionsebene ist es n tig Benutzer und Autorisierungs informationen aus einer Menge unterschiedlicher Systeme beziehen zu k nnen Diese Aufgabe wird als role discovery bezeichnet und stellt im Allgemeinen den ersten Schritt bei der Umstellung einer Struktur auf Rollen dar Im laufenden Betrieb befasst sie sich in einem iterativen Prozess mit der schrittweisen Verfeinerung der herausgearbeiteten Rollen und den Beziehungen zwischen ihnen was unter dem Begriff role
52. beiden Aktivit ten wird im Folgenden n her eingegangen e Abbildung von Rollen Um ein Rollenmodell in geeigneter Form abbilden zu k nnen m ssen die organisationsbezogenen Strukturen wie etwa Abteilungsstufen im Rollen modell abgebildet werden k nnen Dazu werden die Strukturen in Relation gesetzt zu den Modellen in den Endsystemen Im Allgemeinen kann die Gesamtstruktur eines Un ternehmens als direkter azyklischer Graph angesehen werden In diesem Fall kann die Aktivit t zur Abbildung von Rollen in die im Folgenden beschriebenen Teile unterteilt werden o Identifikation der Organisationsstrukturen welche sich im Rollenmodell wider spiegeln sollen Die dazu notwendigen Artefakte entstammen direkt der Rollen analysephase o Definition einer injektiven Abbildung die sowohl die Rollen als auch die Strukturen auf das Rollenmodell bertr gt o Definition einer Benutzer Rolle Relation realisiert auf der Basis von Benutzer attributen Diese Relation kann als Regel modelliert werden die auf der Basis von Benutzerattributen ber die Rolleneinteilung eines Benutzers entscheidet Die Benutzerattribute dienen somit dazu Beschr nkungen engl constraints zu erfassen Wenn beispielsweise die Zweigstelle in der ein Benutzer angestellt ist eines dieser Attribute ist kann eine Regel zur automatischen Einteilung in Rollen auf der Basis dieser Attribute formuliert werden Durch diese Regeln kann die Einteilung in Rollen automatisiert werden
53. definieren oder explizit zu unterbinden Eine Rolle kann somit neben anderen Attributen insbesondere ber eine Menge weiterer Rollen ver f gen wodurch die Hierarchiebildung auf Rollenebene technisch realisiert wird Aufgrund der Mehrdeutigkeit des Rollenbegriffs ist in OIM eine Hierarchie sowohl auf gesch ftlicher als auch auf technischer Ebene m glich Die Verkn pfung zwischen diesen beiden Ebenen wird dadurch hergestellt dass eine Gesch ftsrolle mit einer Menge von Systemrollen in Bezug ge setzt wird Durch die Synchronisation mit dem Metaverzeichnis des ILM k nnen bereits beste hende Rollen aus Endsystemen importiert und verwendet werden falls diese bereits ber Rollen verf gen Die Festlegung der technischen Berechtigungen die eine Systemrolle verk rpert ge schieht allerdings au erhalb von OIM so dass Systemrollen lediglich als abstraktes Objekt vor gehalten werden Hierarchien sind in OIM ein sehr weitgefasster Begriff So gibt es zun chst eine Hierarchie auf Ebene der Organisation Dadurch wird eine Unterteilung der gesamten Or ganisation in Abteilungen oder Zweigstellen erm glicht Davon unabh ngig existiert wie be reits angedeutet wurde eine Hierarchie auf Rollenebene was aufgrund des Rollenmodells in Forschungsgruppe C amp M Stand der Technik 49 OIM sowohl eine Hierarchie von Gesch ftsrollen Systemrollen und sogar eine Mischung von beidem erm glicht In OIM wird jede Rolle in Rollenordner eingeteilt wie au
54. der Omada Identity Ma nager seine Funktionen im Rollenmanagement erbringen kann m ssen ihm die dazu ben tigten Daten initial zugef hrt werden und ber die Lebenszeit der Rollen aktuell gehalten werden Dies umfasst die Aufgaben des Arbeitsbereichs connectivity In diesem Teilkapitel werden die beiden Komponenten des OIM die diese Aufgaben erf llen einer genauen Betrachtung unter zogen Der Omada Identity Manager verf gt ber zwei unterschiedliche Mechanismen zur Interaktion mit den Unternehmenssystemen Dies sind zum Einen ein Datenaustausch in Form eines Imports in OIM und eines anschlie enden Exports der die verarbeiteten Daten in die Un ternehmenssysteme zur ckf hrt und zum Anderen die Kommunikation ber ein Provisionie rungswerkzeug was ber Managementagenten realisiert wird Zun chst wird der Prozess zum Forschungsgruppe C amp M 46 Stand der Technik Import Export verbildlicht dargestellt in Information 21 und anschlie end die Kommunikation in Form von Managementagenten in Information 22 3S 0IM Conectivity Data Import Export Select Source Destination LDAP Import or export data fr C Text file Import data from a CSV SAP table Import data from a data Select Import Export Select Parameters Go Select Mapping System Field External Field IT Username _sAMAccountName Firstname _givenName FT Lastname sn PF Email mail IP Object GUID objectGUID Information 21 State of the Art
55. der Syntax der ef fektiven Berechtigungen entsprechen muss Um dies zu verdeutlichen k nnte man sich hier beispielsweise vorstellen dass alle Standorte durch eine eindeutige Zahl repr sentiert w rden Dann existierten unterschiedliche Gruppen GroupX f r den Standort mit der Nummer X Die Regel der Joker Berechtigung w rde das Benutzerkonto dann entsprechend in die Gruppe X einteilen EEE a Static Separation of Duty Rule Evaluation Role Hierarchy Organizational Layer JUser User Assignment TRole Permission Assignment Joker Permission Ggattribute 1 T 1 ae Technical Layer Account in TS _JAttribute dependant Permission in TS Adapted from Ke02 Figure 7 Information 15 State of the Art Enterprise RBAC Model with Joker Permissions Benutzerspezifische Beschrankungen Die bisherigen Erweiterungen zum ERBAC Standard betreffen generische Rollen und die Ein teilung zu technischen Berechtigungsgruppen auf der Basis von Attributwerten des Benutzers Diese letzte Erweiterung besch ftigt sich mit der Anpassung von Berechtigungen auf dynami sche Weise d h auf Basis von Benutzerattributen Innerhalb eines Unternehmens mag es Job funktionen geben die dieselben Aufgaben erf llen aber dennoch in einem Parameter unter schiedlich sind Ein Beispiel soll dies verdeutlichen In einer Bank g be es Angestellte die Kredite bewilligen d rfen Je nach Stellung des Mitarbeiters sei dessen Bewillig
56. des Ist Zustands auf technischer Ebene engl system analysis die unab h ngig von der gesch ftlichen Bestandsaufnahme geschieht hat zum Ziel die techni schen Berechtigungen zu erfassen die bereits vorhanden sind Durch die Vielzahl an technischen Berechtigungen ist es im Allgemeinen sehr zeitintensiv diese in ihrer Ge samtheit zu erfassen Gerade im Hinblick auf system bergreifende Rollen ist es wichtig auf Berechtigungen zu achten die in verschiedenen Endsystemen gleicherma en vor handen sind wie etwa Systemadministratorrechte da diese dem bottom up V orgehen folgend in der n chsten Phase zu Systemrollen zusammengefasst werden K nnen Auch an dieser Stelle steht keine syntaktisch komplexe Erfassung im Vordergrund sondern viel eher die konsistente Erfassung des gesamten Zustands in den technischen Endsystemen sowie der Endsysteme selbst Dies wird in der Entwurfsphase dazu ben tigt um Systemrollen zu entwickeln Die erfassten Endsysteme kommen dann erst in der Implementierungsphase zum Tragen weil dort die technische Umsetzung durchge f hrt wird Nach der Erfassung des Ist Zustands sind die Anforderungen hinreichend spezifiziert so dass mit der Evaluierung der Rollenmanagementwerkzeuge begonnen werden kann In der Praxis schr nken die technischen Endsysteme die in die Implementierung des Rollenmodells aufge nommen werden sollen die Auswahl bei den Rollenmanagementwerkzeugen bereits stark ein weil diese nur mit bes
57. die Zuweisung von Rollen aus Hiermit sind Attribute gemeint wie etwa individuelle Eigenschaften des Jobprofils die Zugeh rigkeit zu einer Abteilung oder hnliches Da die in Attributen vorhandenen Informationen ber die Rolleneinteilung entscheidet bieten sich diese Attribute zur Automatisierung der Rollenzuweisung an Generische Rollen In vielen Unternehmen herrscht eine Koexistenz verschiedener lokaler Endsysteme wie etwa technisch identischer Endsysteme die in mehreren Standorten unabh ngig voneinander einge setzt werden und ber eine eigene Benutzer sowie Rechteverwaltung verf gen Zur Abstraktion von der spezifischen Verwaltung etwa von Berechtigungen werden daher spezielle Rollentypen eingef hrt die auch zur Abstraktion von der systemspezifischen Benutzerverwaltung dienen Ein Unternehmensbenutzer der an mehreren Standorten arbeitet verf gt in der Folge der Koe Forschungsgruppe C amp M Stand der Technik 35 xistenz verschiedener Endsysteme tiber Benutzerkonten in allen diesen Systemen die ihrer De finition nach technisch allerdings identisch sind Dies f hrt insgesamt betrachtet zu einer Koe xistenz von Benutzern und Rollenstrukturen in diesen Endsystemen Um diese Rollentypen zu sammenzufassen werden generische Rollen definiert die im Gegensatz zu den im ERBAC Modell definierten Rollen keine systemspezifischen Berechtigungen zu Endsystemen mehr enthalten sondern generische Berechtigungen Diese zeichnen sich da
58. diesen Rollen hergestellt werden Diese bei den Aktivit ten stehen in Bezug zu den in Kapitel 1 2 erw hnten Begriffen role discovery und role reconciliation Abschlie end kann die Implementierungsphase in Form einer pilotierten Umsetzung und Tests zur Evaluierung des entwickelten Rollenmodells beginnen Besondere Beachtung wird im Vorgehensmodell der Phase des Rollenbetriebs engl role operation ge schenkt da sich hierdurch der Lebenszyklus eines Rollenmodells im Wirkbetrieb ausdr ckt 1 4 Gliederung der Arbeit Bisher wurde das Interesse des Lesers auf den Forschungsbereich Rollenmanagement gelenkt und die zentralen Problemstellungen dieser Arbeit formuliert In diesem Kapitel soll nun eine bersicht ber den Aufbau der vorliegenden Arbeit und eine kurze Beschreibung der einzelnen Kapitel gegeben werden Im ersten Teil werden die theoretischen Grundlagen f r eine n here Betrachtung des Rollenmanagements gelegt und die beiden Rollenmanagementwerkzeuge Omada Identity Manager und Sun Role Manager vorgestellt Der zweite Teil befasst sich mit der Entwicklung der Rollenmodelle und nimmt eine Evaluation der Werkzeuge vor Im letzten Teil dieser Arbeit werden die Modelle im bereits kurz angesprochenen Szenario in einem Rol lenmanagementwerkzeug umgesetzt Abschlie end werden die Ergebnisse der Arbeit zentral zusammengefasst und Ankn pfungspunkte f r weitere Arbeiten aufgezeigt Die Zusammenfas Forschungsgruppe C amp M Einleitung
59. dieses Ansatzes ist dass Ver nderungen an der Zugriffskontrollarchitektur sehr schnell abgebildet werden k nnen weil diese nderungen lediglich nderungen der Rollen nicht aber jedes einzelnen Benutzers nach sich ziehen Da Rollen mehrere Benutzer gleichzeitig verk rpern existieren im Allgemeinen wesentlich weniger Rollen als Benutzerkonten Da die Rechte die in einem System vergeben werden im Allgemeinen diskrete Mengen darstellen und nicht f r jeden Benutzer individuell verschieden sind kann das rollenbasierte Paradigma als we sentliche Verbesserung f r Zugriffskontrollarchitekturen angesehen werden Durch RBAC wird es m glich Zugriffsrechte in diskreten Mengen und in konsistenter Form zu vergeben was die Effizienz in der Rollenverwaltung potentiell erh ht Auf dieser Basis wird im folgenden Kapitel mit NIST RBAC ein Standardrahmenwerk f r rol lenbasierte Zugriffskontrollarchitekturen eingef hrt welches das RBAC Paradigma in Model len spezifiziert die aufeinander aufbauen und sich im Funktionsumfang voneinander unter scheiden Dieser Standard bildet die Grundlage f r das ERBAC Rollenmodell welches in Kapitel 3 1 2 eingef hrt wird Diese beiden Modelle bilden gleicherma en das Fundament f r die Entwicklung des Rollenmodells in Kapitel 4 2 2 Das NIST RBAC Standardrahmenwerk In diesem Teilkapitel wird der NIST RBAC Standard vorgestellt und die in diesem Rahmen werk definierten Begriffe und Konzepte eingef hrt NIST RBAC
60. dynamische SoD Relation Administrative Funktionen mit constraints Die Semantik der Erzeugung einer dSoD Relation stimmt mit der Semantik bei einer sSoD Relation berein W hrend die cons traints bei sSoD angewandt werden sobald sich nderungen an einer user assignment ergeben greifen dSoD constraints typischerweise nur zu dem Zeitpunkt an dem Rollen f r einen Kontext aktiviert werden Folgende Funktionen werden in diesem Modell spe zifiziert o CreateDSoDSet Erzeugt eine Instanz eines dynamischen SoD constraint o DeleteDSoDSet L scht die Instanz eines dynamischen constraint o AddDSoDRoleMember F gt eine Rolle zu einem bestehenden dSoD constraint hinzu o DeleteDSoDRoleMember L scht eine Rolle aus einer Instanz eines dSoD constraint o SetDSoDCardinality ndert die Kardinalit t f r einen dynamischen constraint was dar ber entscheidet ber wie viele der Rollen ein Benutzer im gleichen Kontext verf gen darf Systemunterst tzende Funktionen In constrained RBAC ohne Hierarchien sollen die Systemfunktionen in gleicher Weise gelten wie in core RBAC F r die zus tzliche Funktionalit t der constraints sind an dieser Stelle Funktionen n tig die dSoD constraints durchsetzen Das f hrt dazu dass die Funktionen CreateSession sowie AddActiveRole erweitert werden m ssen Im Falle von CreateSession muss w hrend des Aufrufs dieser Funktion sichergestellt werden dass die f r die Sitzung er rechneten Rollen in keine
61. engineering gegeben Im top down Ansatz wird von Rollen ausgegangen und die dazu ben tigten Systembe rechtigungen verfeinert Im bottom up Verfahren werden technische Zugriffsberechtigungen zu Berechtigungsgruppen zusammengefasst um so Rollen und Rollenhierarchien zu etablieren Der middle out Ansatz versucht diese beiden Prinzipien zu verkn pfen 16 Role administration Zum Abschluss der T tigkeiten des role engineerings steht ein Grund ger st der RBAC Umgebung mit Rollen oder anderen RBAC Komponenten Hieran schlie en sich nun Verwaltungsaufgaben an Wie die Autoren schildern l sst sich die Rollenadministrati on in die beiden Module Policy Verwaltung engl policy management und Policy Anwendung engl policy enforcement aufteilen wobei sich policy management mit dem Vorhalten von Zu griffskontroll Policys befasst und policy enforcement diese dann mit den RBAC Komponenten verkn pft Diese Aufgabe ist sehr gewissenhaft auszuf hren um die Richtlinien im Unterneh men korrekt in Policys abzubilden und nicht davon abzuweichen Auch hier wird der Bezug zu aktuellen Forschungsbeitr gen geschaffen 17 In der Publikation wird anhand eines LDAP Verzeichnisses gezeigt dass RolePartner naht los in eine bestehende Umgebung integriert werden kann die nicht rollenbasiert arbeitet Defizite Welche Defizite bestehender Arbeiten und L sungen werden als Motivation der eigenen L sun gen genannt D1 Viele Implementierungen erm glic
62. explizit zu fassen Durch diese Tren nung ergeben sich M glichkeiten zur Reduktion von Komplexit t im produktiven Ein satz um gesetzlichen Vorgaben entsprechen zu k nnen Die funktionale Spezifikation des Modells beinhaltet Methoden zur Komplexit tsreduktion e Entwicklung eines Vorgehensmodells welches zur Entwicklung von Gesch fts und Systemrollen beitr gt Zus tzlich dazu modelliert das Vorgehensmodell eine explizite Betriebsphase wodurch der Tatsache Beachtung geschenkt wird dass ein instanziiertes Rollenmodell im produktiven Einsatz fortw hrend nderungen unterliegt e Bewertung aktueller Rollenmanagementwerkzeuge anhand eines in dieser Arbeit entwi ckelten Kriterienkatalogs Diese Bewertung findet auf der Basis eines in der For schungsgruppe C amp M entwickelten Evaluierungsszenarios statt Forschungsgruppe C amp M 6 Einleitung 1 3 Beschreibung des Demonstrators In diesem Teilkapitel wird zun chst ein kurzer berblick ber die Modelle gegeben die in die ser Arbeit erstellt werden sowie das Szenario f r den Tragf higkeitsnachweis beschrieben In dem Szenario soll ein vereinfachtes Bild eines Unternehmens skizziert werden welches im Rahmen einer Fallstudie sowohl den Rollenmodellen aber auch der Werkzeugevaluation glei cherma en als Basis dient Um eine sinnvolle Vergleichbarkeit f r beide Rollenwerkzeuge zu erm glichen liegt es beiden Betrachtungen zugrunde Es verf gt ber mehrere Gesch fts und Syst
63. f hrt verschiedene Konzeptio nelle Komponentenmodelle ein die f r die Betrachtung in dieser Arbeit elementar sind Zu n chst wird ein berblick ber das gesamte Rahmenwerk gegeben und anschlie end auf die darin definierten Komponenten separat eingegangen Jede Komponente des RBAC Standards ist in die zwei Spezifikationsklassen Referenzmodellspezifikation und funktionale Spezifika tion aufgeteilt Im Referenzmodell werden die Modellelemente und Relationen spezifiziert engl model specification w hrend die funktionale Spezifikation engl functional specificati on administrative und systematische Funktionen im Bezug auf die Modellelemente betrachtet FK 07 FS 01 Information 7 gibt einen berblick ber die vier Komponentenmodelle die im RBAC Standard enthalten sind und stellt f r jedes Modell die beiden Spezifikationsklassen dar Forschungsgruppe C amp M Grundlagen 13 Hierarchical RBAC with constraints Model specification Element set Relation set Constraint set Role Hierarchies Functional specification Hierarchical RBAC Constrained RBAC Model specification Model specification Element set Element set Relation set Relation set Role Hierarchies Constraint set Functional specification Functional specification Core RBAC Model specification Element set Relation set Functional specification Adapted from FK 07 Figure 1 6 Information 7 Basics NIST RBAC Reference Models
64. glich aber die Benutzer sind immer genau einer Gesch ftseinheit zugeordnet und nur in dieser sichtbar Auf der Ebene der n chsth heren Gesch ftseinheit kann damit nicht auf einen Blick eingesehen werden welche Benutzer in den tiefer liegenden Einhei ten vorhanden sind was es deutlich erschwert einen Gesamt berblick zu gewinnen Automatische Arbeitsabl ufe SRM erm glicht durch die eingebaute workflow engine Arbeitsabl ufe zu teilautomatisieren wodurch gerade im Fall verteilter Abteilungen eine Verbesserung bei Koordinierungsaufgaben zu erkennen ist Auch lassen sich die Arbeitsabl ufe selbst automatisiert berwachen was dazu f hrt dass auf Frist berschreitungen innerhalb des Prozesses regiert werden kann Beispiels weise kann nach Ablauf einer Frist ein Verantwortlicher dar ber in Kenntnis gesetzt werden Diese Fristen lassen sich systemweit einmalig definieren was bei Unternehmen mit unter schiedlichen Prozessen ebenfalls sehr starr ist Die drei vordefinierten Arbeitsabl ufe orientieren sich sehr stark am Rollenmanagement und lassen sich durch einen grafischen Editor erweitern Neue Abl ufe lassen sich hier allerdings nicht definieren Die berwachung der Rolleneintei lungen bzw Zertifizierungen lassen sich teilautomatisieren in dem sie zu einem beliebigen Zeitpunkt in der Zukunft gestartet werden Diese automatischen Abl ufe sind f r Arbeiten ge dacht die in regelm igen Zeitr umen wiederkehren aber leider bietet d
65. ihre Attribute auf Endsysteme festgelegt sind Will man eine Rolle definieren die system bergreifende tech nische Rechte verk rpert so hat man dazu prinzipiell zwei M glichkeiten Entweder definiert man mehrere Policys zu einer Systemrolle die ihrerseits die technischen Rechte auf ein Endsys tem festlegt oder man definiert mehrere Systemrollen die ber die Policys f r ein konkretes Endsystem verf gen Durch den letztgenannten Ansatz wird die Grenze zwischen den Systeme hervorgehoben weil sie sich in den Systemrollen ausdr ckt An dieser Stelle muss klar zwischen generischen Rollen aus Kapitel 4 2 2 und Joker Policys un terschieden werden beide Prinzipien abstrahieren von systemspezifischen Details jedoch mit unterschiedlicher Auspr gung Verf gen die erw hnten Endsysteme ber dieselben Rechte be dient man sich generischer Rollen um vom konkreten System zu abstrahieren Der Anwen Forschungsgruppe C amp M 86 Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen dungsfall wird dann erst durch die in der generischen Rolle aufgef hrten Systeme festgelegt Die Platzhalter bei Policys aus Kapitel 4 3 1 erg nzen diesen Ansatz weil hierdurch von den konkreten Attributbelegungen abstrahiert wird Was hiermit allerdings nicht m glich ist ist das Zusammenfassen von Endsystemen fiir die unterschiedliche Rechte definiert sind 1 Business Role 1 1 System Role A System Role B Ey OU yOu
66. in die resultierende Ergebnismenge von Gesch ftsrollen einge teilt Durch den Algorithmus zur Einteilung in eine generische Rolle und die Festlegung des Anwendungsfalls wird somit sichergestellt dass ein Benutzerkonto nur ber nicht generische Rollen verf gen kann und generische Rollen in dieser Auslegung als virtuelles Rollenaggregat unterschiedlicher Anwendungsf lle im Rollenmodell enthalten sind Im Bezug auf die techni sche Implementierung dieses Rollenmodells muss erw hnt werden dass der Anwendungsfall einer generischen Gesch ftsrolle erst zum Zeitpunkt der Einteilung eines Benutzerkontos ange geben wird und dadurch auf nicht generische Gesch ftsrollen festgelegt wird F r Systemrollen stellen sich generische Rollen in anderer Weise dar Der erw hnte Anwen dungsfall steht hier f r Endsysteme die gleiche Zugriffsberechtigungen aufweisen Gem der Definition einer Systemrolle subsumiert sie technische Zugriffsrechte in Endsystemen Diese k nnen in Form von Policys festgelegt werden Dabei kann es vorkommen dass ein und diesel be Policy f r unterschiedliche Systeme definiert wird Das passiert genau dann wenn in einem Unternehmen dasselbe technische System mehrfach verwendet wird Dies f hrt zu einer Dupli zierung von Endsystems mit der gleichen Berechtigungsstruktur die allerdings durch ihren ein deutigen Bezeichner im Unternehmen nicht als technologisch identisch zu einem weiteren Sys tem erkannt werden k nnen Gerade in g
67. jeweils anderen Werkzeug vorgenommen um so den Bezug zur Idealanforderung der Kriterien herzus tellen Es entstehen demnach drei m gliche Beurteilungen f r ein Kriterium von zwei Plus symbolen f r eine ausgezeichnete Unterst tzung des Kriteriums bis zu einem Minussymbol f r keinerlei Unterst tzung hierf r e Kriterium 1 Rollen Wie bereits angesprochen wurde haben Mitarbeiter in unter schiedlichen Abteilungen innerhalb eines Unternehmens unterschiedliche Sichtweisen auf die Gesamtstruktur des Unternehmens gepr gt durch deren technisches oder kauf m nnisches Verst ndnis Um zu einer erfolgreichen Umsetzung von RBAC zu gelan gen muss das System an diese Sichtweisen angepasst werden k nnen Dazu ist es n tig dass sie auf geeignetem Abstraktionsniveau kombiniert werden k nnen Dies manifes tiert sich in einer differenzierten Auffassung des Rollenbegriffs Daher stellt die Unter scheidung zwischen gesch ftsprozessnahen Gesch ftsrollen und technikbezogenen Sys temrollen einen sehr wichtigen Aspekt dar Das erste Bewertungskriterium steht deshalb daf r ob bzw in welchem Ma e die vorliegenden Werkzeuge diesen Sachverhalt un terst tzen e Kriterium 2 Hierarchien In den meisten Unternehmen existieren mehrere voneinan der unabh ngige Hierarchien die sich nur schwer formal korrekt und konsistent erfas sen lassen Auf Gesch ftsebene stellt sich dieser Sachverhalt folgenderma en dar Hier existieren Abteilungen die aufei
68. mining and discovery zusammengefasst wird Diese Komponenten spiegeln sich ganz oder zum Teil in den Rollenmanagementwerkzeugen wider Zus tzlich zu diesen elf Komponenten bildet die Konformit t zum RBAC Standard FS 01 die Grundlage f r eine rollenbasierte Infrastruktur Hier werden die Beziehungen im Umgang mit Benutzern Rollen und Ressourcen beschrieben sowie Hierarchien in Rollenbezie hungen und SoD spezifiziert Ka07b In diesem Kapitel sind die Grundlagen f r die Entwicklung von Rollenmodellen f r die Zu griffskontrolle gelegt worden Dabei wurde zun chst auf das Prinzip der rollenbasierten Zu griffskontrolle im Bezug zur Subjekt Objekt Relation eingegangen und im Anschluss daran der NIST RBAC Standard mit den darin enthaltenen vier Rollenmodellen vorgestellt Zum Ab Forschungsgruppe C amp M Grundlagen 27 schluss wurden typischen Aufgabenbereiche von Rollenmanagementwerkzeugen aufgeftihrt und in Bezug gesetzt zu den zwei unterschiedlichen Gesch ftsebenen Auf der gesch ftsnahen Ebe ne hat man es in erster Linie mit organisatorischen Aspekten des Unternehmens den Gesch fts zielen oder Gesch ftsprozessen zu tun wohingegen auf technischer Ebene die Endsysteme so wie die Verwaltung und Pflege von technischen Berechtigungen bzw Policys im Vordergrund stehen Im folgenden Kapitel ber den Stand der Technik werden nun aufbauend auf diesen Grundlagen aktuelle Forschungsergebnisse und Bet tigungen zusammengetragen die
69. ministrativen Prozessen f r den Wirkbetrieb engl role management role maintenance Kapitel 3 1 4 greifen insbesondere an dieser Stelle an Speziell das role mining als vielversprechender Ansatz f r das analytische Entdecken von Zugriffsmustern wird durch die hier eingef hrten Rollenbegriffe und der Gesch ftsrolle Systemrolle Relation unterst tzt In Anlehnung an Infor mation 39 werden folgende Elemente in BRBAC definiert e Benutzerkonten engl user U ieN e Berechtigungen engl policy P ieN e Rollen R gt BRUSR e Geschiaftsrollen engl business role BR ieN e Systemrollen engl system role SR ieN e Benutzer Gesch ftsrolle Relation engl user assignment Ousr CG UXxBR e Geschiaftsrolle Systemrolle Relation engl role mapping O grsr GC BRXSR e Systemrolle Berechtigung Relation engl policy assignment Osrp C SRxP 4 2 2 Modellierung von generischen Rollen Wie in den Anforderungen bereits angeklungen ist versuchen generische Rollen in BRBAC ei nerseits hnliche Rollen zusammenzufassen um die Anzahl an Rollen zu verringern sowie den technischen Wissensstand zu senken der notwendig ist das implementierte Rollenmodell zu verwalten Generische Rollen stellen eine Verallgemeinerung dar weil hier von technischen Forschungsgruppe C amp M 76 Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen oder konkreten Informationen abstrahiert wird Durch die zentrale Forderung n
70. ndi ge Sicherheitsprodukte gew hrleistet Die darin enthaltenen Konzepte unterscheiden sich teil weise jedoch signifikant oder sind dem Wesen nach unvereinbar Ein Benutzer der Zugriff auf diese unterschiedlichen Systeme erhalten soll muss somit in allen Systemen separat angelegt und gepflegt werden Aufgrund dieser Unterschiede und der erw hnten Anforderungen im Ge sch ftsumfeld ben tigt ein Unternehmen heutzutage eine durchg ngige sowie verst ndliche L sung zur unternehmensweiten Zugriffskontrolle In diesem Kapitel wird ein Rollenmodell vorgestellt das sich insbesondere an den Anforderun gen von Unternehmen orientiert Wie Ke02 in Kapitel 3 2 darlegt ist dazu eine Modellerwei terung des NIST RBAC Standards n tig Dieser wurden in Kapitel 2 2 eingef hrt In dem hier vorgestellten Modell wird als Erweiterung eine Unternehmensrolle eingef hrt die sich der He terogenit t in den verteilten Systemen von heute stellt Das Modell ist in der folgenden Abbil dung dargestellt Static Separation of Duty Organizational Layer Role Hierarchy User Assignment Role Permission Assignment permission z 1 1 1 1 Technical Layer Account in TS Permission in TS Adapted from Ke02 Figure 5 Information 13 State of the Art Enterprise RBAC Model Der Rollenbegriff in diesem Modell subsumiert eine Menge an technischen Zugriffsrechten engl permissions die n tig sind um eine Rolle auszu be
71. of the Art Sun Role Manager Component Architecture 55 State of the Art Sun Role Manager Component Relationship 57 State of the Art Sun Role Manager GUl 2200220022002s0ensnensneesnnenneenn 58 State of the Art Sun Role Manager Identity Warehouse u seen 59 State of the Art Sun Role Manager Role Discovery u 2ursnersnersneesnneenn 60 State of the Art Sun Role Manager Role Entitlement Discovery 61 State of the Art Sun Role Manager Rule Discovery u 20220r seen 61 State of the Art Sun Role Manager Role Management uu een 62 State of the Art Sun Role Manager Identity Certification Dashboard 64 State of the Art Sun Role Manager Identity Certification 65 State of the Art Sun Role Manager Identity Audit usersserssersnesnneenn 66 Development ofthe BRBAC Role Model Business and System Roles 75 Development of the BRBAC Role Model Generic Roles 77 Development of the BRBAC Role Model Separation of Duties 79 Development of the BRBAC Role Model Wildcard Attributes 81 Development of the BRBAC Role Model Policy Inheritance 84 Development of the BRBAC Role Model Automatic Roles 86 Development of the BRBAC Role Model Complete Model
72. r jeden Benutzer individuell eine andere Grenze verwendet werden die zur Laufzeit bestimmbar ist was das Rollenmodell an dieser Stelle sehr dynamisch macht S mtliche Rollen die ber identi sche Zugriffsmuster verf gen sich jedoch nur im Zugriffsumfang unterscheiden k nnen nun als eine einzelne Rolle dargestellt werden 4 3 2 Modellierung der Rechtevererbung Nach einer Betrachtung von Policys als Modellelement zur Kapselung von Zugriffsrechten wird nun auf die M glichkeit eingegangen diese Rechte in Hierarchien anzuordnen und darauf aufbauend eine explizite Vererbung von Rechten zu modellieren Der heutige Stand bei der Vererbung von Rechten basiert auf Hierarchien und bedeutet dass die Policys in Rollen entlang der Hierarchie weitervererbt werden Dieser Mechanismus wurde bisher im RBAC Kontext keiner differenzierteren Betrachtung unterzogen In vielen RBAC Umsetzungen wird die Rol lenmitgliedschaft statisch weitergegeben es sei denn die vererbten Rechte w rden in Konflikt stehen zu einem SoD constraint der die Kombination dieser Rechte ausschlie t Wie in Kapitel 6 3 gezeigt wird gibt es sogar aktuelle technische Umsetzungen die die Vererbung innerhalb der Hierarchien nur zum Teil umsetzen Aus IBAC basierten Umgebungen sind jedoch feinere Steuerungsmechanismen bekannt die auf RBAC bertragen werden vgl MicO5b Zur Trag f higkeit werden im Folgenden die zwei Prinzipien block policy inheritance und no override er
73. role management steht f r alle Aufgaben die in OIM im Bereich des Rol lenmanagements anfallen Im Sinne von Information 11 steht dieser Arbeitsbereich f r die Auf gaben organization and business role modeling temporal modeling business role management IT role management und IT role modeling Die darin enthaltene Komponente enhanced RBAC erweitert das zugrunde liegende RBAC Modell um system bergreifende Gesch ftsrollen die in der Namensgebung von OIM Jobprofile engl job profiles genannt werden Die Komponente role maintenance befasst sich mit der Aufgabe nderungen an Rollenzuweisungen vorzuneh men Dies ist insbesondere bei der Pflege der rollenbasierten Struktur im Wirkbetrieb wichtig Nachdem Rollen definiert worden sind k nnen abschlie end Benutzer in Relation zu diesen Rollen gesetzt werden Diese Aufgabe kann je nach Gr e und Struktur des Unternehmens sehr Forschungsgruppe C amp M Stand der Technik 43 zeitintensiv sein Die role mapping Komponente bietet f r diesen Prozess Unterst tzung in Form von Regeln an die bei Rollen nderungen automatisch ausgewertet werden Neben der manuellen Zuteilung von Benutzern zu Rollen bietet OIM auch eine automatisierte Zuteilung zu den Rollen an was mittels Benutzerattributen realisiert ist OIM bietet die M glichkeit die Administration des Gesamtsystems zu dezentralisieren bzw administrative Aufgaben von je dem Benutzer selbst initiieren zu lassen Um dies zu realisieren
74. selbst im Unternehmen verteilt werden um an schlie end das Rollenmodell auf dieses bertragen zu k nnen Auf diese beiden Ziele wird im Folgenden eingegangen und erl utert wer an diesen Phasen beteiligt ist und was gegebenenfalls zu R ckkopplungen in die Entwurfs oder Analysephase f hren Kann Forschungsgruppe C amp M Entwicklung eines Vorgehensmodells fiir die rollenbasierte Zugriffskontrolle 101 Vorgehen in der Implementierungsphase Zu Beginn der Implementierungsphase ist es zun chst n tig das Rollenmanagementwerkzeug im Unternehmen zu implementieren und die Verbindung zu den beteiligten Endsystemen her zustellen engl tool implementation Diese T tigkeit hat noch keinen expliziten Bezug zu den Artefakten aus der Entwurfsphase da es dort vorrangig um den Entwurf des Rollenmodells geht Jedoch wurde bereits in der Analysephase im Rahmen der Bestandsaufnahme auch der Ist Zustand auf technischer Ebene erfasst Hieraus geht nun unter anderem hervor welche Endsys teme im Unternehmen vorhanden und dementsprechend in die Zugriffskontrollarchitektur ein gebunden werden m ssen Zum Teil kann dies bereits umgesetzt worden sein wenn role mi ning Algorithmen vgl Kap 3 1 1 von dem Werkzeug angeboten werden und diese zum Rollenentwurf herangezogen wurden Zur vollst ndigen Einbindung werden Verbindungen zwi schen dem Rollenmanagementwerkzeug und den erw hnten Endsystemen hergestellt aus denen die in der Entwurfsphase spezifizi
75. tzlich zum aktuellen Status kann ein Zeitintervall angegeben werden f r den eine Rolle aktiv ist um sie am Ende ihres Lebenszyklus durch einen automatisch initiierten workflow deprovisionieren zu lassen Dies stellt sicher dass keine Unternehmensbenutzer l n ger Zugriff auf die internen Ressourcen der Abteilung oder des gesamten Unternehmens hat als n tig Dieser Status dr ckt den momentanen Zustand der Rolle im Rollenmanagement des SRM aus So ist eine neu definierte Rolle die im Zuge eines workflows angelegt wurde erst zu dem Zeitpunkt aktiv zu dem sie durch den Rollenverantwortlichen freigeschaltet wurde oder diese Aufgabe nach Ablauf einer Frist an jemand anderen weitergeleitet wurde der die Freischaltung durchf hrt SRM bietet hierf r eine Integration in die grafische Bedienoberfl che an so dass je de Rolle ber die von ihr bereits erledigten oder noch nicht vervollst ndigten Arbeitsaufgaben informiert ist Ein letzter Aspekt bez glich des Lebenszyklus stellt ein Protokollmechanismus f r nderungen an Rollen dar Durch diesen Mechanismus werden im Rahmen des Rollenmanagements Planun gen in der Zukunft sowie Analysen von vergangenen nderungen erm glicht Dazu stellt SRM Historientabellen f r Rollen in unterschiedlichen Auspr gungen bereit Einerseits protokolliert der Role Manager wann welcher Benutzer zu einer Rolle hinzugef gt oder aus ihr entfernt wurde sowie wer diesen Schritt durchf hrte Eine andere Sicht auf den Zu
76. um Rollenmanagementwerkzeuge vergleichbar zu machen Dieser Kriterienkatalog orientiert sich dabei an typischen Aufgaben von Rollenmanagementwerkzeugen und definiert Kriterien die sich m glichst nicht ber schneiden um das gesamte Spektrum eines derartigen Werkzeugs qualitativ zu erfassen Die beiden wichtigsten Punkte dabei waren die Unterst tzung von Gesch fts und Systemrollen ei nerseits und die Auspr gung von Hierarchien f r diese Rollentypen andererseits Es l sst sich feststellen dass aktuelle Werkzeuge aus dem Rollenmanagement grundlegende Aufgaben reali sieren die bei der Umsetzung einer rollenbasierten Zugriffskontrolle ben tigt werden Die Au tomatisierung von Aufgaben in Form von workflows wirkt sich dabei im produktiven Einsatz ebenso positiv aus wie die Sicherstellung dass Policy Vorgaben eingehalten werden Die tech nischen Umsetzungen verursachen jedoch zum jetzigen Zeitpunkt eine sehr hohe Arbeitsbelas tung im Wirkbetrieb was auch an der fehlenden expliziten Unterscheidung von gesch ftlichen und technischen Aspekten liegt Nach der Entwicklung des Kriterienkatalogs wurden die beiden Werkzeuge Omada Identity Manager OIM und Sun Role Manager SRM an ihm bewertet Vergleicht man nun die Er gebnisse beider Werkzeuge so kann festgehalten werden dass OIM klare Vorteile bei Hierar chien und der Vererbung von Rechten besitzt Beides unterst tzt die Arbeitsprozesse in der Rol lenverwaltung da die Rechte teils automat
77. und auf andere Systeme ausgeweitet werden Diese Projekte verf gen ber eine Vielzahl unter schiedlicher Systeme aus denen auf Basis system bergreifender Rollen unterschiedliche Be rechtigungen integriert wurden Offene Fragen Welche Fragen sind noch ungel st geblieben bzw stellen sich dem Leser O1 Die Handlungsanweisungen in den Aktivit ten sind nicht spezifiziert O2 Das Vorgehensmodell beleuchtet nur die Phasen bis zur Implementierung Es existiert kei ne Ankn pfm glichkeit f r ein Prozessmodell was Verwaltungsaufgaben oder Pflege beachtet 03 Das Vorgehensmodell basiert sehr stark auf den Fallstudien aus den Unternehmen Die Einbeziehung theoretischer Modelle wie ERBAC geht aus dem Vorgehensmodell nicht hervor 04 Die Autoren nehmen hnliche Ergebnisartefakte einzelner Phasen in den Fallstudien als Indikator daf r diese Phasen in ihrem eigenen Vorgehensmodell in einer einzelnen Phase zu sammenzufassen Diese neue Phase besteht aus allen Aktivit ten aus den Fallstudien Ist diese Annahme g tig bzw was ist der Vorteil dieser Zusammenfassung F 3 Role Mining Revealing Business Roles using Data Mining Technology KS 03 Martin Kuhlmann Dalia Shohat Gerhard Schimpf Role Mining Revealing Business Roles for Security Administration using Data Mining Technology ACM 2003 Inhalte Was sind die zentralen Inhalte die in der Arbeit behandelt werden I1 Die Autoren verwenden klassische data mining Tec
78. und deren Qualit t Kriterium 5 Benutzerfreundlichkeit Das f nfte Kriterium bewertet die Benutzer freundlichkeit des Werkzeugs Dabei soll dediziert nicht auf den Bereich von Benutzer freundlichkeitsuntersuchungen eingegangen werden sondern lediglich eine subjektive Einsch tzung der Benutzerf hrung der Werkzeuge gegeben werden Das Hauptziel ei ner rollenbasierten Architektur ist es eine Struktur zu schaffen die die Komplexit t des Gesamtsystems verringert und so einerseits Kosten spart aber auch f r mehr Konsis tenz in der Umgebung sorgt Ein deshalb nicht zu untersch tzender Faktor bei der Marktdurchdringung solcher Werkzeuge stellt die Bedienbarkeit dar Da dies ein sehr individueller und subjektiver Aspekt ist kann die Metrik dieses Kriteriums nicht objek tiv gew hlt werden st tzt sich aber auf Erfahrungswerte die sich bei der Umsetzung des IST Szenarios ergeben haben welches beiden Werkzeuguntersuchungen gleichsam zugrunde liegt Im Hinblick auf die Akzeptanz einer Rollenmanagementanwendung sind deren klare Strukturierung und eing ngige Bedienbarkeit deshalb unerl ssliche Merkmale Kriterium 6 Unterst tzung von R ckmeldungen Zum jetzigen Zeitpunkt werden Rollenmanagementwerkzeuge in erster Linie als Verwaltungsplattform verwendet Die Kommunikation zu den technischen Endsystemen stellt einen wichtigen Aspekt bei der Implementierung eines Rollenmanagementwerkzeugs dar Die zu erteilenden Rollen mitgliedschaften und Be
79. und diesem hier vorgestellten bottom up Vorgehen 03 Was w rde es bringen wenn man vom vollst ndigen RBAC Modell ausgeht mit Hierar chien statt flacher Rollenstrukturen Die Autoren schlagen einen zus tzlichen mining Schritt nach dem Identifizieren der Rollen zum Etablieren von Hierarchien vor O4 Wie wirkt sich das entstehende Rollenmodell aus wenn man nicht von Benutzer Rolle Paaren sondern in einem vor gelagerten Schritt zun chst von Anwendung Berechtigungs Paaren ausgeht W rde man hier Aggregatobjekte f r Zugriffsrechte innerhalb von Anwendun gen schaffen K nnte dies dem SoD Prinzip zweckdienlich sein O5 Hilft eine Parametrisierung zur weiteren Verfeinerung des role mining Prozesses Forschungsgruppe C amp M Anhang 159 06 Wie lassen sich Gesch fts Policys besser mit einbeziehen damit Hierarchien SoD oder constraints unmittelbarer ersichtlich werden 07 Wie kann die hier vorgestellte L sung um statische constraints SoD Hierarchien und Pa rametrisierung Kann erg nzt werden O8 Es ist immer noch ein gro er manueller Aufwand n tig um den Cluster auf eine ge sch ftsartige Sicht hin zuzuschneiden Deshalb werden mit diesem Ansatz weniger als 80 Automatisierungsgrad bei der Rollenidentifikation erreicht 09 Eine Voraussetzung ist dass ein Benutzer pro Endsystem ber maximal ein Benutzerkonto verf gt Dies ist laut eigener Aussage eine realistische Annahme Jedoch wird in den heute vor h
80. und zweitens stehen die Identit ten der Benutzer nicht in Beziehung zu deren gesch ftlichen Funktion Wenn ein Benutzer innerhalb eines Unternehmens die Position wechselt und somit andere Aufgaben erf llt m ssen die Zugriffskontrolllisten aller Systeme einzeln ge ndert werden was sehr ineffizient ist C amp M A ID Zus tzlich ist hierbei nicht gew hrleistet dass ein Benutzer nur ber das Ma an Rechten verf gt das er zur Durch f hrung seiner Aufgaben ben tigt was zu Inkonsistenzen zwischen den erteilten und den ben tigten Rechten f hrt In der Realit t werden Zugriffsrechte somit oftmals inkorrekt zugeteilt und die Gesamtstruktur weist Inkonsistenzen auf In den Jahren um 1990 etablierte sich ein verbessertes Modell zur Zugriffskontrolle Hierbei wurde das Konzept der Rolle als Indirektionsstufe zwischen subject und object eingef hrt Dieser Architekturstil der die Skalierungsprobleme von IBAC beheben will ist die rollenba sierte Zugriffskontrolle engl role based access control RBAC C amp M A ID Anders als beim IBAC Modell in dem die Zugriffskontrolle direkt zwischen Identit ten und Berechtigungen umgesetzt ist spiegeln die Zugriffskontrolllisten bei RBAC die Relation zwischen Rollen und Berechtigungen wider Die Beziehung zwischen Identit t und Rolle wird durch eine zus tzliche Relation dargestellt Semantisch gesehen entspricht eine Rolle somit einer Gesch ftsfunktion die ber eine Menge an Berechtigungen i
81. von RBAC F r die verbleibende Menge existieren die administrativen Operationen addUser und deleteUser im Falle von Benutzern und addRole und deleteRole f r Rollen Zur Verwaltung der beiden wichtigsten Rela tionen user assignment UA und permission assignment PA existieren Folgende ad ministrative Funktionen F r UA werden assignUser und deassignUser defi niert und f r PA existieren grantPermission und revokePermission e Systemunterst tzende Funktionen Diese Spezifikation richtet sich an das Verwalten von Sitzungskontexten sowie der Entscheidungsfindung zur Beantwortung von Zu griffskontrollanfragen Um Aussagen ber den Zugriff auf ein Objekt machen zu k n nen wird eine im aktuellen Sitzungskontext aktive Rolle ben tigt die ihrerseits ber Benutzer verf gt Diejenige Funktion die einen Sitzungskontext er ffnet stellt einem Benutzer gleichzeitig die Teilmenge an Rollen zur Verf gung die in diesem Kontext g ltig sind Diese Menge kann dann w hrend der Sitzung durch den Benutzer selbst ge ndert werden indem Rollen hinzugenommen oder entfernt werden Folgende Funktio nen stehen an dieser Stelle zur Verf gung o createSession Erzeugt eine Benutzersitzung und berechnet die Menge an zur Verf gung stehenden Rollen o addActiveRole F gt eine Rolle als aktive Rolle f r diesen Kontext hinzu o dropActiveRole Entfernt eine Rolle aus dem f r diese Sitzung aktiven Rollenvorrat o checkAccess Liefert einen Wahrheitsw
82. von Rollen an Berechtigungen wird soweit m glich im Zielsystem vermieden indem dort Gruppen ange legt werden auf die Berechtigungen erteilt werden Als letzten Schritt werden Benutzer zu Rol len zugewiesen L5 Ein Vorteil dieser Vorgehensweise ist das Profitieren von bisherigen Daten Die von den Autoren vorgestellte L sung erlaubt das berpr fen des Ergebnisses des role mining an der Ge samtstruktur und somit das schrittweise Verfeinern Dieser iterative Prozess nutzt die Lernkurve beim role mining aus Nachweise Welche Nachweise werden hinsichtlich der Tragf higkeit der eigenen L sungen geliefert N1 Als Nachweis wird auf Industrieprojekte und die Implementierung des kommerziellen Produkts SAM Role Miner verwiesen und durch zwei Fallstudien belegt N2 930 SAM Modelle wurden in zeitintensiver Arbeit vorab identifiziert Innerhalb weniger Stunden konnten alle 930 Modelle als Rollen identifiziert werden Dadurch verringert sich die Arbeitslast um zwei Gr enordnungen N3 Die Autoren sch tzen eine Ersparnis von bis zu 60 f r den initialen Aufwand zur Rol lenerstellung und von bis zu 50 im laufenden Betrieb Offene Fragen Welche Fragen sind noch ungel st geblieben bzw stellen sich dem Leser O1 Welcher Grad an Automatismus lie e sich mit role mining in Kombination mit einem top down Vorgehen bei Unternehmen mit guten Gesch ftsprozessbeschreibungen erreichen O2 Wie gut w re eine Kombination aus top down
83. von Rollenmanagementwerkzeugen gebracht werden In der als strategy bezeichneten Kategorie werden die zentralen Ziele eines Unterneh mens definiert dessen produzierte G ter bzw Dienstleistungen sowie dessen Philosophie Die strategy gibt somit die Ausrichtung des Unternehmens an und wirkt sich damit unmittelbar auf die sp tere Organisationsform aus Ausgehend von der in der Kategorie strategy definierten Ausrichtung befasst man sich in der zweiten Kategorie structure and authority mit der Auftei lung von Verantwortlichkeiten Hier wird dem Unternehmen somit eine Struktur gegeben und Verantwortlichkeiten definiert und verteilt Processes and information f llt die definierte Struk tur nun mit konkreten Gesch ftsprozessen und Arbeitsaufgaben Die Kategorie rewards befasst sich mit der Einf hrung von Boni um die Ziele eines Unternehmens mit den individuellen Zie len der Angestellten in Einklang zu bringen Diese Boni sind nicht ausschlie lich monet rer Na tur m ssen aber in Einklang mit der bislang definierten Unternehemsausrichtung dessen Struk Forschungsgruppe C amp M 24 Grundlagen tur und Arbeitsprozessen stehen Die fiinfte Kategorie people and resources oder identities be sch ftigt sich mit der Akquise und Einf hrung von neuem Personal sowie dessen Rotation und pers nlicher Entwicklung im Unternehmen Ga02 Kapitel 2 Die Kategorien strategy und structure and authority geben dem Unternehmen das strukturelle R ckgrad und en
84. von c amp m nicht jedoch ber Rechte auf das Schu lungsportal ed tec Wenn ed consult im Rahmen einer geplanten System nderung an ed tec aktiv eingebunden werden soll ist es n tig dass dieser Rolle die entsprechenden Zugriffsrechte erteilt werden Um dies zu bewerkstelligen muss die Gesch ftsrolle Se curity Consultant ed consult zus tzlich in die Systemrolle Full Ac cess ed tec eingeteilt werden Prozess berwachung Dieser Arbeitsbereich befasst sich mit den Prozessen die in nerhalb des Sun Role Manager definierbar sind Im Rahmen der automatischen work flows ist es beispielsweise m glich einen Prozess zu definieren der die IT Administra tion von c amp m dar ber in Kenntnis setzt dass eine Gesch ftsrolle zus tzliche Rechte ben tigt Dazu verf gt der Sun Role Manager ber eine grafische bersicht mit ausste henden und bereits erledigten Anfragen engl pending requests completed requests Auch werden f r die erteilten Policys zwei eigene Ansichten angeboten engl my certi fications certify revoke statistics Policy Verletzungen Dieser letzte hier beleuchtete Arbeitsbereich befasst sich mit Rechteiiberschreitungen eines Benutzers die daraus resultieren dass dieser Benutzer in der Aus bung seiner Gesch ftsrolle den darin spezifizierten Berechtigungsumfang berschreiten Im Beispiel k nnte der Zugriffsversuch des Sicherheits Consultant auf das ed tec Portal erkannt werden und in der Ansicht f r die Policy Ver
85. welche Daten aus dem gesamten Unternehmensdatenbestand im Metaverzeichnisses aufge nommen und mit der OIM internen Datenbank synchronisiert werden sollen Die Architektur dieses Werkzeugs ist in der folgenden Abbildung dargestellt Dabei werden die einzelnen Kom ponenten des OIM in der vorliegenden Version 6 0 in Relation zu seinen Hauptaufgaben ge stellt Um den Bezug zwischen der Architektur und der zentralen Abbildung Information 1 her zustellen ist die technische Ebene engl technical layer in der Abbildung ersichtlich Forschungsgruppe C amp M 42 Stand der Technik specification Omada Identity Manager subsystem subsystem subsystem 4 Role Management Workflow Designer Compliance Enhanced RBAC Attestation Role Maintenance Identity subsystem subsystem Reconciliation 4 Authentication Approvals Role Mapping Separation of Single Sign On Duties Self Service Audit Trails Workflow Password Manager Delegated Audit Reports Administration use Automation subsystem Security Connectivity Administration Data Exchange Service Level Agreements subsystem Multi Language Management Agent Fa Key Performance Indicators use subsystem Microsoft Identity Lifecycle Manager _ Management Agent 6 Technical Layer Platforms Databases App
86. werden d rfen Dies wird in der Praxis dadurch verwendet um gewisse Standards vorzugeben die f r die gesamte Hierarchie g ltig sind Durch den Mechanismus block policy inheritance ist es beispielsweise m g lich dass gewisse Rechte in Rollen nicht weitervererbt werden um zu erm glichen dass Rollen ber individuelle Rechte verf gen die nicht Teil der Vererbungshierarchie werden Der Ansatz des hier vorgestellten Rollenmodells unterscheidet wie bereits er w hnt zwischen der Gesch fts und Systemebene was im Hinblick auf die Vererbung einen gezielten Eingriff bei der Rechtevererbung erm glicht und das Modell insgesamt dynamischer macht und feingranulare Einstellungen im Wirkbetrieb erlaubt Ein As pekt der in bisherigen Modellen bei der Vererbung von Rechten zum Tragen kommt ist die Steuerung von sich gegenseitig ausschlie enden Rechten die einem Benutzer zuteil werden Die Modelle und Implementierungen sehen daf r separation of duty SoD als Mechanismus vor auf sich gegenseitig ausschlie ende Rechte einzuwirken Da dieser Mechanismus nicht unmittelbar mit der Vererbung zu tun hat wie er in BRBAC ver wendet wird damit aber in Verbindung steht sei an dieser Stelle darauf hingewiesen dass SoD in diesem Modell auch Beachtung findet Anforderung A22 Unterst tzung von wildcard Attributwerten Wie technische Um setzungen von RBAC zeigen entstehen im Laufe des Lebenszyklus eines Rollenmo Forschungsgruppe C amp M Entwickl
87. werden k nnen Wie in Kapitel 3 1 1 bereits angesprochen wurde muss vor dem Anwenden dieser Algorithmen das Gesamtsystem auf einen geeigneten Ausschnitt re duziert werden Dazu dient die Formalisierung des Ist Zustands auf technischer Ebene aus dem Lastenheft die unter Einbeziehung der Fachabteilungen entstanden ist Aufgrund der Verifika tion dieser Formalisierung durch den Kunden am Ende der Analysephase kann man davon aus gehen dass der erfasste Ausschnitt f r das zu implementierende Rollenmodell angemessen spe zifiziert wurde Durch schrittweises Verfeinern des Datenbestands k nnen die Systemberechtigungen nun iterativ zusammengefasst werden um daraus Rollen abzuleiten die f r den jeweiligen Einsatz im Unternehmen angemessen sind Durch diese T tigkeit werden die Formalisierungen aus der Analysephase somit einerseits zu Rollen weiterentwickelt und ande rerseits der Berechtigungsumfang f r diese Rollen definiert Am Ende der Spezifikation beider Rollentypen muss f r jede Rolle ein Besitzer engl owner definiert werden der sich in der sp teren Betriebsphase f r diese Rolle verantwortlich zeigt Hierbei ist insbesondere wichtig dass dieser Verantwortliche auch die Struktur der Systemrol len kennt weil er in der Rollenbetriebsphase neben der Pflege und der Einteilung von Benutzern insbesondere auch die Einteilung zu Systemrollen durchf hren wird In der Regel kann es einen Verantwortlichen auf Gesch ftsebene geben der einen Rolle
88. wird in BRBAC um gangen Somit kommt diese Anforderung A23 dem Ziel Z nach Die zweite Schwachstelle der Joker Berechtigungen ist dass die Auswertung der Regeln zu dem Zeitpunkt geschieht zu dem ein Benutzer in eine Rolle eingeteilt wird Wenn sich an dem Benutzerattribut nderungen ergeben zieht das keine Neuauswertung der Regel nach sich was potentiell zu Inkonsistenzen f hrt wenn diese nderung nicht manuell auch in den Rollenzuweisungen beachtet werden In dem hier verfolgten Ansatz soll die Einschr nkung allerdings nicht statisch g ltig sein sondern die M glichkeit bieten dass sie nur f r eine bestimmte Zeit g ltig ist und automatisch r ckg n gig gemacht werden Daher sollte die Einteilung in diese systemspezifische Rolle nicht bei einer nderung der Rollenmitgliedschaften geschehen sondern jedes mal wenn sich ein Benutzer anmeldet da an dieser Stelle sein Kontext festlegt wird Nachdem der Mechanismus erkl rt wurde soll er nun in BRBAC modelliert werden Es wurde bereits erw hnt dass es sich hier um rein technische Spezifika handelt weswegen hier lediglich von Systemrollen und System Policys die Rede ist und nicht von Gesch ftsrollen und deren Po licys Eine Joker Policy unterscheidet sich von einer gew hnlichen Policy dadurch dass sie mit einer Regel versehen ist die bei jeder Autorisierungsanfrage berpr ft und ausgewertet wird Jede Systemrolle besteht aus einer Menge an System Policys die ihrerseits durch
89. zu definieren dass sie in m g lichst vielen Kontexten wiederverwendet werden kann Ein Rollenmanagementwerk zeug erm glicht es im Rahmen des business role management Rollen zu definieren sie zu verwalten und zu analysieren um die Granularit t des Umfangs anzupassen e Prim r besteht eine Rolle aus Attributen wie eine Liste von Benutzern im Fall von Ge sch ftsrollen oder eine Liste von Zugriffsrechten bei Systemrollen Dar ber hinaus kann sie ber Einschr nkungen engl constraints verf gen die in Form einer Policy realisiert werden ber diese Einschr nkungen ist es etwa m glich ihren G ltigkeitsbe reich zeitlich oder rtlich zu beschr nken Separation of duty SoD wird ebenfalls auf diese Weise realisiert Eine Rollenmanagementl sung stellt im Aufgabenbereich policy definition and management M glichkeiten bereit um Policys zu erstellen und sie zu verwalten Auch gibt es Werkzeuge die dar ber hinaus das automatisierte Herausarbei ten von Policys und das Zuweisen zu Rollen anbieten e F r das Personal das sich um die Zuweisungen der Rollen k mmert beginnen berwa chungst tigkeiten sobald die Zuweisung von Rollen an Benutzer erfolgt ist Aufgaben f r diesen Bereich versteht man unter attestation and compliance collection and repor ting Dies umfasst eine regelm ige berpr fung die feststellt ob die erteilten Zuwei sungen noch wirksam sind Auch muss sichergestellt werden k nnen dass mit Verst Ben g
90. zun chst Omada Enterprise als Serverkomponente installiert werden ehe das Erweiterungspaket Omada Identity Manager aufgesetzt werden kann OE stellt die grundlegende Funktionalit t zur Identit tsverwaltung bereit w hrend der Omada Identity Manager diese durch eine Anpassung des Datenbankschemas um Rollenkomponenten erweitert In diesem Zusammenhang erweitert OIM die bisherige Webanwendung um die M glichkeit Organisationseinheiten mit Hierarchien abzubilden sowie rollenbedingte Prozesse wie etwa das Delegieren von Arbeitsaufgaben an andere Rollen Bei der Installation von OE wird das Instal lationsverzeichnis angegeben welches nach der Installation als virtuelles Verzeichnis in den IIS eingebunden werden muss um es ber einen Web Browser aufrufen zu k nnen Dazu wird ber die Verwaltungskonsole des IIS eine neue Webanwendung hinzugef gt mit dem Installations verzeichnis von OE verkn pft und ASP NET 2 0 als ausf hrendes Framework angegeben An dieser Stelle kann auch der Authentifizierungsgrad f r die Webanwendung angegeben werden Hierbei wird unterschieden zwischen nicht authentifiziertem Zugriff und der Authentifizierung gegen den zentralen Verzeichnisdienst Zusammen mit OE wird die Provisionierungsplattform Microsoft Identity Lifecycle Manager ILM installiert die f r OIM die Kommunikation zu den Endsystemen realisiert Die Verbindung zur Datenbank geschieht ber ADO NET und wird ber die Configuration von Omada Enterprise vorgenom
91. zustellen werden folgende Funktionen definiert o authorizedUser Liefert die Menge der direkt und indirekt in einer Rolle vorhandenen Benutzer zur ck o authorizedRoles Liefert die Menge an Rollen zur ck die direkt oder in direkt in einem Benutzerobjekt vorhanden sind Neben den nderungen die die Relation Benutzer Rolle betreffen m ssen auch dieje nigen Funktionen angepasst werden die auf den bereits erteilten Berechtigungen f r Rollen operieren Durch die Rollenhierarchie unterliegen auch die Berechtigungen dem Vererbungsmechanismus Wie die berarbeitungsfunktionen in core RBAC bereits er w hnen gelten folgende vier Funktionen als optional weil sie nicht in allen RBAC Umsetzungen vorhanden sind o rolePermissions Liefert die Menge an Berechtigungen zur ck die direkt oder indirekt an eine Role vergeben wurden o userPermissions Liefert die Menge an Berechtigungen eines gegebenen Benutzers zur ck die er durch direkte und indirekte Rollenmitgliedschaften er h lt Forschungsgruppe C amp M Grundlagen 19 o roleOperationsOnObject Liefert die Menge an Operationen zur ck die eine Rolle durch explizite oder implizite Berechtigungen an einem Objekt aus f hren darf o userOperationsOnObject Liefert die Menge an Operationen zur ck die ein Benutzer an einem gegebenen Objekt ausf hren darf unter Beachtung des sen direkten und indirekten Rollenmitgliedschaften 2 2 3 RBAC Modell mit Beschr nkungen Das con
92. 34 Zusammenfassung und Ausblick die Forderung an ein Rollenmodell nach einer m glichst effizienten Verwendung von Rollen sowie gleicherma en nach einer Reduktion von Komplexit t Anders als ERBAC sieht diese Arbeit die explizite Trennung von gesch ftsnahen und technischen Rollen als zentrale Anforde rung Eine Rolle weist dabei eine Menge an Policys auf die ihren Zugriffsumfang spezifiziert und diesen auf ein Zugriffsziel festlegt Zus tzlich zur Spezifikation von Gesch fts und Sys temrollen wurden generische Rollen als zweite Modellspezifikation eingef hrt Diese Spezial form von Gesch fts und Systemrollen abstrahiert vom konkreten Zugriffsziel und somit l sst sich ein Berechtigungsumfang spezifizieren der in unterschiedlichen Kontexten gleicherma en angewandt werden kann Im Folgenden wurde auf die Modellierung von wechselseitigem Aus schluss engl separation of duty SoD eingegangen und eine M glichkeit aufgezeigt wie ne ben statischem SoD insbesondere dynamisches SoD modelliert werden kann was in bisherigen Rollenmodellen f r den Einsatz in Unternehmen nicht beachtet wurde Das BRBAC Modell verfolgt dabei den Ansatz dass der f r dynamisches SoD notwendige Kontext im Benutzerob jekt als eindeutigem Identifikator enthalten sein Kann Nach der Spezifikation von Rollen wurde anschlie end auf die Modellierung von Policy Erweiterungen eingegangen Auch hierbei war das Ziel ein m glichst kompaktes und effizientes Rollenmodell zu e
93. 9 sung dient somit als bersicht ber die gesamte Arbeit und ihrer entwickelter Konzepte Auf diese drei Teile wird nun kurz eingegangen In Kapitel 2 werden zun chst die Grundlagen f r eine detaillierte Betrachtung des Rollenmana gements gelegt Dazu werden Grundbegriffe erkl rt sowie eine Einf hrung in grundlegende Konzepte Architekturen und Modelle gegeben Im Vordergrund steht hierbei eine Vorstellung der im wissenschaftlichen Kontext etablierten Rollenmodelle die sich unter Anderem mit sys tem bergreifenden Rollen besch ftigen In diesem Kapitel wird somit das als gesichert geltende Wissen im Bereich der rollenbasierten Zugriffskontrolle vorgestellt In Kapitel 3 wird dann ein berblick ber den aktuellen Stand der Technik im Rollenmanagement gegeben und die beiden in dieser Arbeit verwendeten Werkzeuge Omada Identity Manager und Sun Role Manager vor gestellt Hierbei sind die Ziele den Marktansatz die Architekturen sowie den Funktionsumfang beider L sungen darzustellen Dieses Kapitel stellt somit aktuelle Ergebnisse aus Wissenschaft und Technik dar die den zentralen Aspekten dieser Arbeit unmittelbar zugrunde liegen In Kapitel 4 wird dann das Rollenmodell BRBAC engl business role based access control aufgestellt Dazu werden zun chst die zentralen Ziele und Anforderungen erhoben und diese an schlie end einzeln umgesetzt Den Abschluss bildet ein Res mee welches das Gesamtbild von BRBAC gibt und Ankn pfungspunkte f r
94. Attribut implizit in den Rollen selbst mitgef hrt werden Dies jedoch f hrt dazu dass eine Rolle tendenziell ber sehr viele Attribute verf gt Auch hierbei gilt dass bei einer Unterscheidung in nur einem der Attributwerte bereits eine neue Rolle definiert werden muss Daher w chst die Zahl der Rollen im ERBAC Modell im praktischen Einsatz sehr stark an und zieht eine komplexe Rollenstruktur nach sich e Man m chte eine m glichst feingranulare Kontrolle ber die Zugriffsrechte in den End systemen haben In typischen Gesch ftsanwendungen ist diese feingranulare Kontrolle oftmals deshalb vonn ten weil die Zugriffsrechte f r unterschiedliche Prozesse eben falls sehr unterschiedlich sein K nnen Hierbei werden die Rechte durch unterschiedli che Wertebelegungen in den definierten Attributen ausgedr ckt Beispielsweise haben Bankangestellte unterschiedlich hohe Bewilligungsgrenzen f r das Attribut Kredit rahmen Selbst wenn der Wert f r das Attribut Kreditrahmenbeschr nkung vielleicht der einzige Unterschied in den Zugriffsrechten zweier Bankangestellter ist manifestiert sich dieser Sachverhalt im ERBAC Modell in zwei eigenst ndigen Rollen weil dies nicht anders zu modellieren ist vgl Information 13 Um diese Probleme zu l sen wird eine Parametrisierung der Rollen als Erweiterung zum ERBAC Modell in Ke02 vorgeschlagen Dies kommt durch die Verwendung von Attributen und Regeln zum Ausdruck Dabei k nnen folgende Mod
95. Automatisierte Rollenmitgliedschaften auf der Basis von Poli cys Bisher wurde zun chst die Aufteilung von Gesch fts und Systemrollen betrachtet und im An schluss daran auf die Auswirkungen auf Policys eingegangen In diesem abschlie enden Teil kapitel soll nun ein Aspekt betrachtet werden der insbesondere die Verwaltung des Rollenmo Forschungsgruppe C amp M Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen 85 dells im Wirkbetrieb unterst tzt Dabei handelt es sich um eine Automatisierung von Policy Definitionen In dynamischen Unternehmen wie man sie heute vorfindet kommt es h ufig vor dass ein Angestellter in unterschiedlichen Dienststellen arbeitet In diesem Zusammenhang muss es m glich sein dass er in der Aus bung seiner gesch ftlichen Rolle in den unterschiedli chen Dienststellen ber dieselben Rechte verf gt Da die Dienststellen durch die intensive Nut zung des Internet heutzutage zu einem gemeinsamen Netzwerk verbunden sind ist die Grundla ge f r diese Betrachtung faktisch schon gegeben Die unterschiedlichen gesch ftsnahen Strukturen wie etwa Gesch ftsrollen sind dadurch bereits im gesamten Unternehmen abrufbar Anders stellt sich diese Situation jedoch dar wenn man nicht die gesch ftliche Ebene betrachtet sondern die Ebene der Zugriffsrechte Da in den unterschiedlichen Abteilungen an unterschied lichen technischen Systemen gearbeitet wird kann es passieren dass in diesen Abtei
96. BR uE UN O uBr U X A 4 O ss0p X Y A O asp Y 5 e Systemrollenfunktion systemroles U SR ieN systemroles u x x y E SR 1 JeBR ueU A pgr sk 1 X A O uBRr U 1 NO ssoD 1 NO asop 1 j e Berechtigungsfunktion permissions U gt P ieN Zum Abschluss dieses Kapitels sollen die in den vorangegangenen Kapiteln separat vorgestell ten Anforderungen im Querschnitt betrachtet werden Betrachtet man nun diese Mechanismen in Kombination zueinander entstehen daraus Einsatzm glichkeiten die im Folgenden kurz auf gezeigt werden sollen Es sollen an dieser Stelle lediglich Ankn pfungspunkte f r weitere Un tersuchungen aufgezeigt werden Ein interessanter Aspekt etwa ist die Kombination generischer Rollen und der wildcard Attribute Generische Rollen abstrahieren bekanntlich vom Konkreten Anwendungsfall oder Einsatzziel Kombiniert man diese Rollen mit wildcards l sst sich der Kontext der im Normalfall zum Zeitpunkt der Einteilung eines Benutzers in die Rollen festge legt werden muss im Benutzer selbst verankern Dies hat zur Folge dass der Kontext nicht zum Zeitpunkt der Einteilung festgelegt wird sondern explizit im Benutzerkonto selbst vorhanden ist Dadurch ist es m glich den Kontext im Wirkbetrieb bei jeder Autorisierungsanfrage zu be stimmen und daraus zur Laufzeit die f r diesen Kontext g ltigen Rollen zu bestimmen Dies entlastet verst ndlicherweise insbesondere die Administration da diese Aufgabe sons
97. C Modell Wie aus Ke02 hervorgeht stellt ERBAC ein gutes Modell f r verteilte Informationssysteme dar wie man sie heutzutage typischerweise in Unternehmen vorfindet Das liegt in erster Linie an der Spezifikation von Unternehmensrollen die von konkreten Endsystemen abstrahieren In der praktischen Umsetzung weist es jedoch einige Schwachstellen auf die im Speziellen zu ei nem h heren Administrationsaufwand f hren Aus diesem Grund wurden Erweiterungen dazu definiert die in diesem Teilkapitel vorgestellt werden sollen Die Erweiterungen beziehen sich auf Ke02 wo sie anschaulich dargelegt und begr ndet werden Diese Betrachtung bildet die Grundlage f r die Entwicklung eines Rollenmodells in Kapitel 4 Der hohe Administrationsaufwand in der praktischen Umsetzung des ERBAC Modells wird laut Ke02 Kapitel 4 dadurch hervorgerufen dass es zu einer gro en Anzahl an Rollen f hrt Daf r werden zwei Gr nde angegeben e Es gibt viele Faktoren die eine Rolle klar definieren und man hat bei der Umsetzung von ERBAC prinzipiell zwei M glichkeiten diese Faktoren im Rollenmodell abzubil den Einerseits k nnen Informationen in Form von Hierarchien dargestellt werden und andererseits k nnen sie durch Attribute in der Rolle selbst festgehalten werden Eine Rolle ist demnach durch die Menge an Attributen und den daf r definierten Attribut werte eindeutig definiert Jede Konfiguration dieser Attribute definiert somit eine Rolle eindeutig Beispi
98. Daten ber eine Webservice Schnittstelle zuf hren OIM unterst tzt die grafische Erstel lung von Managementagenten was in Information 22 dargestellt wird Forschungsgruppe C amp M Stand der Technik 47 58 0IM Connectivity Management Agents setup Data Type Objects No Name Type Data Type Direction Transfer 20 Name Value property Text 16 Description Value property Text 56 RoleID Value property Text 59 System Reference property IDs x Generate Management Agent Configuration Name Active Directory Management Agent Name of the MA as it should appear in MIIS Description This agent connects to Active Directory Description of the MA as it should appear in MIIS Data object types User group 5 Data object types to be synchronized Export Management Agent amp Import gt Properties Connect to Active Directory Forest Configure Directory Partitions Select Object Types Select Attributes Configure Connector Filter Configure Join and Projection Rules Configure Attribute Flow Configure Deprovisioning Configure Extensions Information 22 State of the Art Omada Identity Manager Management Agents Der Prozess zur Verwendung von Managementagenten gestaltet sich etwas anders als beim Im port Export von Daten Die Datenbasis fiir Agenten stellen die Datenobjekte von OIM dar Die se bestehen aus einer Menge von Attributen wobei fiir jedes Attribut separat spezifiziert werden kann in welche Rich
99. Doku mente zu ffnen e Die zweite Systemrolle Leser engl reader bef higt einen Benutzer die Elemente eines Ordners zu ffnen Diese Rolle beinhaltet somit das Recht den Inhalt eines Ord ners aufzulisten und die angezeigten Dokumente auch zu ffnen e Die dritte Systemrolle Schreiber engl writer erm glicht das aktive ndern vorhan dener Inhalte ebenso wie das Hinzuf gen oder das L schen von Daten aus den betref fenden Ordnern Abschlie end soll eine kurze Zusammenfassung dieses Teilkapitels gegeben werden Zun chst wurde das Beispielszenario IST eingef hrt und die darin beteiligten Unternehmen vorgestellt Anschlie end wurden die vorhandenen Gesch fts und Systemrollen betrachtet Auf dieser Grundlage wird nun im Folgenden die Tragf higkeit des BRBAC Modells gezeigt welches durch das Vorgehensmodell aufgebaut wird 7 2 Instanziierung von BRBAC in einem kommerziellen Rol lenmanagementwerkzeug 7 2 1 Auswahl des Rollenmanagementwerkzeugs In Kapitel 6 wurde die Bewertung zweier aktueller Rollenmanagementwerkzeuge vorgenom men und die wesentlichen Unterschiede zwischen ihnen herausgestellt In diesem Teilkapitel Forschungsgruppe C amp M 126 Fallstudie zur Anwendung der Modelle in einem kommerziellen Produkt wird nun dasjenige der beiden ausgew hlt welche das Vorgehensmodell und das Rollenmodell BRBAC im vorgegebenen Szenario besser unterst tzt Die Auswahl wird im Folgenden be gr ndet Da
100. In dieser Arbeit wird die Version 4 0 von SRM eingesetzt Der Funktionsumfang von SRM kann in drei wesentliche Aufgabenbereiche aufgeteilt werden die alle auf einer zentralen Da tenbank innerhalb des Role Manager operieren Im folgenden Teilkapitel wird zun chst die Architektur des SRM sowie die von ihm verwendeten Datentypen erkl rt Die Datenbank und die drei Arbeitsbereiche werden kurz erkl rt durch ein Schaubild illustriert und jeweils in Be zug gesetzt zu den Aufgabenbereichen von Rollenmanagementwerkzeugen aus Kapitel 2 3 In den folgenden Teilkapiteln wird ein genauerer Einblick in diese Arbeitsbereiche gegeben der die darin enthaltenen Funktionen anhand eines Prozesses illustriert Auf Basis der daraus ge wonnen Erkenntnisse wird das Produkt in Kapitel 6 3 anhand eines dort entwickelten Kriterien katalogs bewertet Das Ziel dieser Aufteilung ist es zun chst einen abstrakten berblick ber das Produkt Sun Role Manager zu geben und anschlie end die einzelnen Aufgabenbereiche im Detail zu beleuchten Dabei soll der Funktionsumfang von SRM wertungsfrei dargestellt wer den 3 3 1 Architektur Aufgabenbereiche und Datentypen des Sun Role Manager Die drei Aufgabenbereiche des Role Manager operieren auf einer zentralen SRM internen Da tenbankkomponente dem sogenannten identity warehouse Bei den drei Bereichen handelt es sich um die Verwaltung von Rollen engl role engineering role management die Zuweisung von Rollen engl identit
101. Policys nun m glich auf die Vererbung von Rechten einzuwirken Dies kennt man bisher nur aus IBAC basierten Zugriffskontrollarchitekturen BRBAC erlaubt einerseits die Vererbung von Rechten f r eine gewisse Hierarchiestufe zu un terbinden und andererseits die Spezifikation von Rechten die in der Hierarchie weiter unten nicht berschrieben werden d rfen Zum Abschluss wurde durch die Modellierung von Joker Berechtigungen ein Mehrwert dieses Rollenmodells geliefert der automatische Rollen auf der Basis von Policys erm glicht Dieser Mehrwert zeigt sich speziell in der Entwurfsphase des Vorgehensmodells welches in Kapitel 5 entwickelt wird Forschungsgruppe C amp M 88 Inheritance Property Business Policy System Policy Ea Value 0 1 1 Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen Organizational Layer x ddadda Technical Layer Generic Business Role onalik of Generic System Role Dynamic sop consist of consist of Role Hierarchy Role Hierarchy 1 it 1 1 consist of Business Role ie u 1 System Role gt a a 1 4 1 consist of Subject attribute conical has Business Role a has System Role el ER Joker consist of 7 7 1 1 User Inheritance Property 0 1 5 Value 1 1 Static SoD Business Policy Attribute define Policy Business Policy Value 7 System Policy Value define Policy System Policy Attribute Ea Name 1 ES Value Ea Value 1 1 GgName wi
102. RM der Unter schied einer Gesch ftsrolle zu einer Systemrolle nicht explizit vorgenommen obwohl das Werkzeug beide Prinzipien kennt In der Nomenklatur des SRM steht der Begriff Rolle f r eine gesch ftliche Aufgabe wohingegen die Einheit zum Kapseln von technischen Zugriffs rechten Policy genannt wird Dennoch entsprechen diese Einheiten ihrer Konzeption nach den Gesch fts und Systemrollen Der Role Manager bietet sowohl bei Gesch ftseinheiten als auch bei Rollen eine Hierarchiebildung an nicht aber bei den Systemrollen Ein Unternehmensbenut zer kann ber beliebig viele Rollen verf gen die ihrerseits eine beliebige Anzahl von Policys aufweisen Mit dem Benutzerverzeichnis engl user store ist diejenige Datenquelle einer oder mehrerer Anwendungen engl applications gemeint aus der das identity warehouse die Benut zer in sein Metaverzeichnis importiert Dort sind demnach die konkreten Benutzerobjekte abge legt Die Assoziation mit einer oder mehrerer Policys definiert die technischen Zugriffsrechte eines Benutzers SRM versteht die technischen Endsysteme die unter seiner Verwaltung stehen allgemein als Anwendungen Betrachtet man die Komponente Anwendung engl application so legt das Komponentenmodell des SRM fest dass sie einen Besitzer engl owner oder Ver antwortlichen engl approver haben kann der seinerseits dargestellt ist als Unternehmensbe nutzer im eigentlichen Sinne also als Gesch ftsrolle Jede Anwendu
103. Rollen sowie die Beziehungen untereinander eingegangen und abschlie end ein Einblick in die grafische Bedienoberfl che des Omada Identity Manager gegeben component component 0 2 1 component Constraint JIdentity User belongs to 1 1 Constraint has Role Role has Identity component 1 1 component 1 belongs to component JRole Folder Role is in 1 Z Role Organizational unit 4 1 1 belongs to belongs to 1 belongs to Role has Role Type Role has Role Category 1 1 component component Se Role Type Role Category 1 Role Type is System Role Role Type is Job Profile 1 1 component Job Profile has System Role component System Role Pe a Job Profile 1 redizes Salze Job Profile realizes Business Role 1 component component component System Application Business Role Information 19 State of the Art Omada Identity Manager Data Type Relationship Information 19 stellt die Datentypen des OIM im Hinblick auf die rollenbasierte Zugriffskont rolle dar An dieser Stelle sei erw hnt dass an dieser Stelle lediglich diejenigen Datentypen aufgef hrt wurden die im Zusammenhang mit Rollen stehen Der zentrale Datentyp Rolle engl role wird im Omada Identity Manager in unterschiedlichen Kontexten verwendet und hat demnach unterschiedliche semantische Bedeutungen Dieser Bedeutungsunterschied dr ckt
104. Rollenmanagementwerkzeugs selbst So wird etwa bei der Einteilung eines Benutzers in ei ne Organisationseinheit in Abh ngigkeit von der Gesch ftsrolle und SoD constraints die Menge an Rollen gesammelt und in der Summe automatisch an den Benutzer verteilt F r die berpr fung von workflows oder etwa die Planung von Umstrukturierungen bietet OIM keinerlei Un terst tzung an Bei geplanten nderungen kann nicht berpr ft werden wie sich diese auf das aktuelle Rollenmodell auswirken w rden weil die Datentypen in OIM aktiv sind sobald sie de finiert wurden Dies trifft somit auch auf Beschr nkungen wie etwa SoD constraints zu wo durch eine Planung somit auch hier nicht gew hrleistet ist Benutzerfreundlichkeit OIM bietet eine einheitliche grafische Benutzeroberfl che an die sehr intuitiv zu bedienen ist Durch die Flexibilit t des Rollenmodells ist es jedoch n tig dass das Personal eingehend ge schult wird Ein zentrales Konzept bei OIM sind die rollenspezifischen Ansichten engl views durch die die Interaktionsm glichkeiten eines Benutzers in der Aus bung seiner Rolle mit OIM kanalisiert werden nderungen an diesen Ansichten sind jedoch sehr zeitintensiv weil es daf r keine zentrale Arbeitsoberfl che gibt OIM unterst tzt sehr stark die dezentrale Administration so dass ein Benutzer nderungen an seinen Rollenzugeh rigkeiten selbst initiieren kann Dabei werden workflows aktiviert und diese zum darin definierten Verant
105. SQL Server indem das Script zun chst ber die Konsole ge ffnet und anschlie end die Datenbank rbacx selektiert wird auf die das Schema Script angewandt werden soll Am Ende dieser Konfiguration existiert die Datenbank zusam men mit dem von SRM ben tigten Datenbank Schema Nach der Konfiguration der Datenbank muss nun noch der Anwendungs und Webserver ange passt werden Apache Tomcat integriert sich als Windows Dienst in das Betriebssystem und ist standardm ig nicht gestartet Der Sicherheitskontext unter dem der Dienst l uft ist standard m ig auf Lokales System gesetzt Dadurch verf gt er ber administrative Rechte auf dem Zielsystem Aus Sicherheitsgr nden wird empfohlen hierf r ein dediziertes Benutzerkonto mit eingeschr nkten Rechten zu erstellen Um Tomcat und somit auch die darauf installierte An wendung SRM zu starten muss nun lediglich der Dienst in der Dienst Konsole des Windows Servers gestartet werden Die Bedienoberfl che des SRM erreicht man ab diesem Zeitpunkt ber http lt Adresse des_Servers gt lt Port gt rbacx Laut Vaau07a liegt der empfohlene Speicherbedarf fiir den Role Manager bei 512 MB was durch folgenden Kommandozeilenbefehl gesetzt und im Falle von Leistungsengp ssen ange passt werden kann Set JAVA_OPTS Xmx512mb Xms512m Forschungsgruppe C amp M 146 Anhang Nach der Konfiguration der Verbindungen zu Datenbank Anwendungs und Webserver kann nun die Bedie
106. Zip Postal Code ten Da cu Information 31 State of the Art Sun Role Manager Identity Warehouse Diese Abbildung verdeutlicht den Informationsbestand des identity warehouse das den zentra len Datenspeicher im Sun Role Manager darstellt Wie zun chst ersichtlich ist sind die Daten die in dieser Datenbank abgelegt sind unterteilt in Gesch ftsstrukturen engl business structu res Benutzer engl users Rollen engl roles Policys engl policys sowie Systemschnitt stellen engl end points Diese Datentypen zusammen mit den Beziehungen untereinander wurden im Komponentenmodell in Information 29 beschrieben In Information 31 ist als Bei spiel speziell die Unterkomponente business structures innerhalb des Gesamtdatenbestandes abgebildet Diese Struktur vereint beliebig viele voneinander unabh ngige Gesch ftseinheiten unter einem gemeinsamen Wurzelknoten Jede Gesch ftseinheit verf gt ber eine Menge an Ei genschaften wie etwa einem Manager einer f r diese Einheit verantwortlichen Person oder ei nem Administrator Zus tzlich k nnen Informationen wie die n chsth here Hierarchiestufe oder zentrale Adressdaten hinterlegt werden ber die anderen Reiter auf der Navigationsleiste er reicht man das Benutzerverzeichnis das Rollenverzeichnis den Datenbestand an Policys sowie alle auf dem System vorhandenen Systemschnittstellen In den folgenden Teilkapiteln wird auf diese Bereiche separat eingega
107. ach Trennung von Gesch fts und Systemrollen muss der Begriff der generischen Rollen f r diese beiden Rol lenbegriffe differenziert betrachtet werden Im Folgenden wird daher zun chst auf die Generik bei Gesch ftsrollen und im Anschluss daran bei Systemrollen eingegangen Dabei wird im Fol genden das Zielobjekt des Zugriffs einer Rolle als Anwendungsfall bezeichnet Da Gesch ftsrollen wie sie bisher verwendet wurden von sich aus bereits von technischen De tails abstrahieren stellen sich generische Rollen auf Gesch ftsebene anders dar als bei System rollen Generische Rollen verringern in erster Linie die Anzahl an konkreten Rollen dadurch dass die in ihnen enthaltenen Policys unabh ngig vom Anwendungsfall definiert und durch zu s tzliche Parameter erst zu einem sp teren Zeitpunkt auf diesen festgelegt werden bertr gt man dieses Prinzip auf Gesch ftsrollen so kann man sagen dass in ihnen gesch ftliche Vorga ben in Form von Gesch fts Policys die Rechte der Rolle definieren und erst durch die Verkn p fung mit der Organisationsstruktur konkretisiert werden Hierbei zeigt sich die N he von Ge sch ftsrollen zur Gesch ftsprozessmodellierung Ein Beispiel soll dies verdeutlichen Man betrachte eine Gesch ftsrolle namens Verwaltungsangestellter in der durch Policys festgelegt ist welche organisatorischen Aufgaben ein Verwaltungsangestellter aus bt Dies kann bei spielsweise umfassen dass er befugt ist Rechnungen zu unte
108. ase im Vorgehensmodell enthalten sein In dieser Arbeit schlie t sich an die erfolgreiche Umsetzung des Modells somit eine Phase an die als Rollenverwal tungsphase bezeichnet wird 5 Procedure Model Role Analysis Role Design Role Implementation amp Role Operations Information 46 Procedure Model Development Introduction Das Vorgehensmodell ist in Information 46 dargestellt und unterteilt sich in die Phasen Rol lenanalyse engl role analysis Rollenentwurf engl role design Rollenimplementierung Forschungsgruppe C amp M Entwicklung eines Vorgehensmodells fiir die rollenbasierte Zugriffskontrolle 93 engl role implementation und Rollenbetrieb engl role operations Fiir jede dieser vier Phasen wird in den folgenden Kapiteln er rtert e Was in dem Prozessschritt zu tun ist e was dessen Ziel ist bzw welche Zielartefakte dabei entstehen e wer an der Phase beteiligt ist und das Voranschreiten kontrolliert und steuert und e welche Gr nde fiir eine R ckkopplung in einer fr here Phase sprechen k nnten Diese Aufteilung der Kapitel wird im Folgenden konsequent verfolgt Die in jeder Phase er zeugten Artefakte sowie m gliche Anzeichen f r Riickkopplungen zu fr heren Phasen bilden dabei den Abschluss jedes Teilkapitels weil dadurch klar definiert ist wann der Prozess in die jeweils n chste Phase eintritt oder aufgrund von R ckkopplungen zur ckgesprungen werden muss Das E
109. asst und modelliert Die Vorstellung des IST Szenarios sowie die Formulierung der Gesch fts und Systemrollen im Bezug zu den technischen Systemen in denen sie definiert wurden kann somit als Ergebnis der Analysephase angesehen werden und die Abbildungen aus Kapitel 7 1 als grobe Spezifikation die Teil der Ar tefakte sind die in die Entwurfsphase bergeben werden Wie aus der verbalen Formulierung aus Kapitel 7 1 auch hervorgeht verf gen die Gesch ftsrollen ber unterschiedliche Rechte in nerhalb der technischen Infrastruktur von c amp m was im Folgenden konkretisiert werden soll Erg nzt werden nun die Systemrollen die die erw hnten Gesch ftsrollen im IST Szenario auf weisen Business Roles IT Administration c amp m Trainer c amp m Marketing Assistent c amp m General Manager c amp m Accounting Assistent c amp m System Roles with single System Policy component component Course Management Server Network Drive E Administrator Contributer Reader ator i ccess List Folder Content C Read Access Information 56 Case Study Role Mapping with Simple System Roles In Information 56 sind die erteilten Systemrollen in Bezug zu den Gesch ftsrollen dargestellt Durch die farbliche Markierung wird deutlich welche Gesch ftsrollen mit den Systemrollen verkn pft sind Diese Verkn pfungen werden im Folgenden begr ndet Der Sicherheits Consultant steht in direktem Kontakt mit der technischen Fachabtei
110. ation was gerade in gr eren Einrichtungen m glichst zu vermeiden ist Da im Gegensatz zu Gesch ftsrollen bei Systemrollen keine Hierarchie unters t tzt wird ist es nicht m glich ist eine Vererbungsstruktur bei Systemzugriffsberechtigungen zu etablieren Das identity warehouse als zentraler Datenspeicher erm glicht es nicht Ge sch ftsrollenattribute im Sinne von Referenzen auf miteinander zu verbinden weil die Attribut felder reine Textfelder anstatt Verweisen sind Somit muss die Hierarchie auf Ebene der Ge sch ftsrollen manuell administriert werden was wiederum sowohl zu Inkonsistenzen aber auch zu h herem Wartungsaufwand f hrt Algorithmische Entwicklung von Rollen SRM bietet eine Unterst tzung f r den Bereich role engineering an und hierbei insbesondere Algorithmen zur automatisierten Entwicklung von Rollen engl role mining an Die role mi ning Funktionalit t kann durch Parameter angepasst werden jedoch sind diese hierf r weder dokumentiert noch intuitiv verst ndlich so dass hierf r Detailwissen aus dem data mining vor handen sein muss Die Benutzerobjekte auf denen die role mining Algorithmen arbeiten sind an maximal eine Gesch ftseinheit gebunden Dies ist f r den arbeitsteiligen Aufbau gerade von gro en Unternehmen sehr unflexibel in der Rollen gleichzeitig in mehreren Abteilungen be sch ftigt sind Auch hier macht sich die fehlende Hierarchie bemerkbar So ist eine Hierarchie f r ein Unternehmen zwar m
111. bei im engen Zusammenhang zu den Kapiteln 3 3 2 und 3 3 3 in denen die Bereiche Rollenmanagement und die Persistenz der Daten in SRM genau betrachtet werden Die Bewertung der role mining Funktionalit t bezieht sich auf den Bereich role engineering aus Kapitel 3 3 3 in dem prozesshaft die automatisierte Entwick lung von Rollen aufgezeigt wird Die Kapitel 3 3 4 sowie 3 3 5 befassen sich eher mit der War tung des Rollenmodells im Wirkbetrieb und damit einhergehend mit dem gesamten Lebenszyk lus von Rollen Diese Erkenntnisse flie en in das Kriterium workflow capability ein In Analogie zur Bewertung des Omada Identity Manager sind die abschlie enden drei Kriterien querschnittlich ber das gesamte Werkzeug zu verstehen Die Benutzerfreundlichkeit ist dabei wiederum subjektiv gepr gt da jedoch beiden Werkzeugumsetzungen dasselbe Szenario zu grunde liegen das in Kapitel 1 3 kurz vorgestellt wurde kann der relative Vergleich zwischen beiden Werkzeugen durchaus als repr sentativ angesehen werden Das Ziel dieser Aufteilung ist es auch hier einen quantitativen Einblick in dieses Werkzeug zu geben Forschungsgruppe C amp M Analyse aktueller Rollenmanagementwerkzeuge 117 Criteria Sun Role Manager Support Quality 1 Roles 1 1 Business Roles 1 2 System Roles 2 Hierarchies 2 1 Business Role Hierarchies 2 2 System Role Hierarchies 3 Role Mining 4 Workflow capability 4 1 Process 4 2 Monitoring 5 U
112. bei k nnen die Versionen Microsoft 2000 Server oder Microsoft Server 2003 verwendet werden F r die Datenhaltung unterst tzt OIM Microsoft SQL 2000 und Microsoft SQL 2005 als relationalen Datenbankserver In der Logikschicht werden die Internet Informati on Services IIS mit dem NET Framework in der Version 2 f r ASP NET 2 0 ben tigt um darauf Omada Enterprise und Omada Identity Manager zu betreiben Da die Funktionen des NET Framework auch in den anderen beiden Schichten ben tigt werden und im Zuge der au tomatischen Updates des Betriebssystems automatisch mitinstalliert werden ist diese Kompo nente in Information 59 in der Komponente Betriebssystem engl operating system darges tellt Der Zugriff auf die Datenbest nde der einzelnen Endsysteme geschieht in Form des Microsoft Identity Lifecycle Manager ILM der ebenfalls auf der Logikebene vorhanden sein muss Tiers in OIM Data Tier Business Logic Tier Presentation A component component component _ Database Server Application Server Web Server Omada Identity Manager Omada Enterprise use Microsoft Office Web Components Microsoft SQL Server 2000 Microsoft Identity Lifecycle Manager 2007 Windows SharePoint Services Microsoft SQL Server 2005 Internet Information Services Internet Information Services base on base on base on component Operating System
113. bestehende ge ndert werden k nnen Dies bezieht sich vor Allem auf die Verwaltung des Schulungsangebots von c amp m Anders als die Systemrolle Leser kann die Systemrolle Gestalter einen berblick ber alle Teilnehmer einer Schulung halten und diese selbst ndig nachtr glich ein oder austragen e Die dritte Systemrolle in ed tec wird mit Administrator bezeichnet und bef higt einen in dieser Rolle t tigen Mitarbeiter systematische Einstellungen von ed tec vorzuneh men wie etwa die Benutzerverwaltung einhergehend mit der nderung von Benutzer rechten Nur dieser Rolle ist es gestattet komplette Seiten zusammen mit dem Inhalt der darauf publiziert ist zu l schen Wie Information 55 aufzeigt stellt c amp m ein drittes Unternehmenssystem zur Verf gung wel ches als unternehmensweite Datenablage verwendet wird Hier befinden sich einerseits zus tzli che Materialien zu denjenigen Schulungen die ber ed tec angeboten werden aber auch c amp m interne Dokumente wie etwa Vertr ge Rechnungen oder Marketing Material Auch an dieser Stelle wird von der internen Struktur des Dateiservers abstrahiert und lediglich die Systemrollen eingef hrt die den Zugriff kanalisieren e Die Systemrolle Ordnerinhalte anzeigen engl list folder content steht f r das Recht den Inhalt eines Ordners anzuzeigen Dies wird etwa ben tigt um einen berblick ber den Inhalt zu geben ohne explizit das Recht zu gew hren die darin abgelegten
114. ch mit der Tatsache dass eine Rolle mehrere Phasen durchl uft von der initialen Definition dem Hinzuf gen von Systemrollen den nderungen im Laufe der Zeit sowie den Bewilligungen hierf r Der Lebenszyklus einer Rolle endet mit Ma nahmen zu ihrer planm i gen Deprovisionierung Dieser Lebenszyklus wird technisch durch die Komponente unterst tzt die die internen workflows ausf hrt engl workflow engine Hierbei existieren drei vordefinierte Arbeitsabl ufe im Zusammenhang mit dem Lebenszyklus Zun chst gibt es einen workflow der Forschungsgruppe C amp M Stand der Technik 63 sich mit der Bewilligung von nderungen an Rollenmitgliedschaften besch ftigt Ein zweiter steuert den Ablauf bei der Erzeugung einer Rolle sowie den darin enthaltenen Policys und ein dritter regelt nderungen an den Rollen sowie den Policys selbst Alle Aufgaben des Rollenma nagements verwenden diese drei Arbeitsabl ufe wobei sie an gewissen Stellen angepasst wer den k nnen So ist es etwa m glich Teilaufgaben an die daf r verantwortliche Rolle weiterlei ten zu lassen oder automatische Emails auf der Basis vorgefertigter Vorlagen zu verschicken Diese Abl ufe gew hrleisten ein geplantes und zielorientiertes Arbeiten im Umgang mit Rollen Ein zweiter Aspekt der unmittelbar mit den workflows zur Realisierung des Lebenszyklus zu tun hat ist der Status einer Rolle Hierbei gibt es f nf vordefinierte Stati in der sich eine Rolle befinden kann Zus
115. chern der Ereignisse in der Datenbank ist es m glich einen Blick in die Vergangenheit Forschungsgruppe C amp M Stand der Technik 57 zu werfen um Fehler im Nachhinein ausgiebig zu analysieren Hier kommt SRM gesetzlichen Verpflichtungen nach denen Unternehmen unterworfen sind vgl SOX KonTraG Im Gegen satz zur Analyse der Vergangenheit werden fiir die Echtzeitanalyse Uberwachungsrichtlinien engl audit policy ben tigt die aus Filterbedingungen engl rule zusammengesetzt sind Die se berwachungsrichtlinien besitzen einen Verantwortlichen dessen Aufgabe es ist sich Ver letzungen dieser speziellen berwachungsrichtlinie anzunehmen Ebenso kann hier eine Zeit spanne spezifiziert werden nach deren Ablauf eine Erinnerungsnachricht verschickt wird um sicherzustellen dass die aufgetretene Verletzung behandelt wird Am Ende des Lebenszyklus einer berwachungsrichtlinie steht dann entweder das Weiterleiten an eine andere Person die die Verletzung behandelt oder das Abschlie en der Verletzung wenn die Ursache gefunden und behoben wurde Ka07b Sun08a Im Bezug auf die Aufgabenbereiche von Rollenmanage mentwerkzeugen aus Information 11 spiegelt dieser Bereich durch das aktive berwachen die Aufgabe activity monitoring wider Da die Ergebnisse dieser Analysen unmittelbar in die Um gebung zur ckflie en und sich dadurch das Rollenmodell anpasst beinhaltet dieser Bereich zu s tzlich dazu auch Aufgaben aus dem Bereich role recon
116. cherzustellen Im hier beschriebe nen NIST RBAC Rollenmodell wird statisches SoD als globales Element zusammen mit Kardi nalit ten definiert Durch die Angabe einer Kardinalit t n f r ein SoD constraint wird definiert ber wie viele Rollen aus dieser Menge ein Benutzer verf gen kann ehe eine Policy Verletzung vorliegt Das Rollenmodell hierarchical RBAC with constraints definiert statisches SoD sSoD folgenderma en e sSoDc 2 xn ne N n gt 2 sSoD ist demnach eine Menge von Tupeln rs n mitrs lt roles so dass kein Benutzer ber mehr als n Rollen aus rs verf gt sSoD n rs n V rs n V t c rs gt n gt N assigned _users r Modellspezifikation von dynamischem separation of duty Durch Relationen mit statischen SoD constraints verringert sich die Anzahl potentiell zur Ver f gung stehender Rollen in die ein Benutzer eingeteilt werden kann Auch dynamisches SoD verfolgt das Ziel die Anzahl der zur Verf gung stehenden Rollen zu verringern jedoch wird durch dynamische SoD constraints zus tzlich zur rein statischen Betrachtung der Kontext als zus tzlich beschr nkender Parameter hinzugenommen Statisches SoD beschr nkt die Dimensi on der zur Verf gung stehenden Berechtigungen durch eine Beschr nkung aller potentiell zur Verf gung stehenden Rollen wohingegen dynamisches SoD diese Beschr nkung auf der Rol lenteilmenge im aktuellen Kontext vornimmt Die Art und Weise wie der RBAC Standard dSoD modelliert
117. ciliation Zusammengefasst versteht der Sun Role Manager den Begriff Rollenmanagement als eine Kombination aus discovery design engineering optimization und lifecycle management sowie den dazugeh rigen Regeln in Form von Policys Ka07b Er wendet data mining Algorithmen auf sein Metaverzeichnis an um dadurch Zugriffsrechte herauszuarbeiten und schl gt potentiel le Gesch fts und Systemrollen sowie konkrete Policys zur Steuerung und Kontrolle vor Nach dem nun ein berblick ber die Architektur des Sun Role Manager gegeben wurde illustriert Information 29 die verwendeten Datentypen sowie deren Beziehungen zueinander Sun Role Manager Component Relationship component realizes component User Store has Policy component JEndPoint User Store 1 1 Policy Policy is assigned to Role pete a Role 1 1 1 1 1 4 Ol belongs t i i longs to Namespace has EndPoint Application has User Store Role is Assigned to User 19 1 1 1 component meras component Application has Owner Approver Namespace Application sia pp is 1 E User is assigned to Business Unit EHER Business User Le 1 Business Unit 1 amp EndPoint has Attribute a 0 1 0 1 Namespace has Attribute Category belongs to belongs to 10 component component Attribute Attribute Category has Attribute Attribute Category Adapted from Vaau06a page 1 Information 29 State of the Art Sun Role Manager Component Relati
118. d re Identit ten engl secondary identities verf gt um es einem Benutzer zu erm glichen ber das durch seine Rollenmitgliedschaften definierte Ma hinaus zus tzliche Berechtigungen zu erhalten Dies widerspricht allerdings dem RBAC Paradigma wonach die Berechtigungen eines Benutzers an dessen Rollen und nicht direkt an dessen Identit t gekn pft werden Zur De finition von wechselseitigem Ausschluss engl separation of duty SoD bietet OIM constraints auf zentraler Ebene an Dabei ist es m glich eine Menge an Rollen auszuw hlen die sich wechselseitig ausschlie en Hierarchien In OIM wird eine Vielzahl unterschiedlicher Hierarchien erm glicht Zun chst existiert eine Hierarchie auf der Ebene von Rollen so dass sich Hierarchien bei Gesch fts und Systemrollen definieren lassen Durch die fehlende Unterscheidung dieser beider Rollentypen vermischen sich allerdings gesch ftsnahe und technikspezifische Hierarchien Eine davon unabh ngige Hie rarchie ordnet die Rollen in Organisationseinheiten engl organizational unit an die frei w hl bar sind Hierdurch werden die Strukturen der Organisation wie etwa Abteilungen abgebildet Eine Rolle ist dabei stets an genau eine Organisationseinheit gekn pft was zwar die Rollen ver allgemeinert die alle Benutzer in dieser Organisationseinheit besitzen aber eine Wiederver wendung dieser Rollen in anderen Abteilungen ausschlie t Eine weitere hierarchische Struktur ist durch die soge
119. d beschr nk ten Ausschnitt aus dem Gesamtkontext eines Unternehmens Dabei wurden insgesamt neun Ge sch ftsrollen sowie drei Unternehmenssysteme eingef hrt die jeweils ber drei technische Be rechtigungen oder System Policys verf gen wobei im hier gew hlten Ausschnitt lediglich f nf dargestellt wurden Eine g ltige Umsetzung von BRBAC wurde im vorangegangen Kapitel auf gezeigt in dem f r jede System Policy eine eigene Systemrolle konzipiert wurde die die darin enthaltene Berechtigung in sich kapselt Bereits dadurch wird die direkte Bindung an das tech nische Endsystem aufgehoben was der Forderung von BRBAC nach einer Abstraktion in den Systemrollen von den technischen Endsysteme nachkommt Diese Abstraktion kann sogar noch klarer gezeigt werden Hierf r werden Algorithmen zum role mining auf den Datenbestand der Systemrollen angewandt und der bottom up Ansatz weiterhin verfolgt Es wird nunmehr ver sucht Zugriffsmuster in den bisherigen Systemrollen zu erkennen und die System Policys in den bisherigen Systemrollen zu allgemeinen Systemrollen zusammengefasst An dieser Stelle sei verweisen auf die Modellierungsaspekte generische Rollen und Policy Erweiterungen wie etwa die Verwendung von Platzhaltern oder die Rechtevererbung von Policys Diese Aspekte kommen insbesondere in gro en Szenarien zum Tragen und werden im Rahmen des IST Szenarios nicht n her betrachtet weil es hierf r nicht komplex genug ist Die Verwendung von statische
120. den Bearbeiter weiterleitet ist das automatic tracking Sie identifiziert das Per sonal welches f r die nderungen autorisiert ist und informiert sie ber die nderungsw n sche Somit wird sichergestellt dass die dezentral initiierten nderungen an den daf r verant wortlichen Mitarbeiter delegiert und von ihm angenommen oder abgewiesen werden k nnen Dieser zweite Teil des dargestellten Arbeitsablaufs ist in Information 25 dargestellt und be schlie t den Arbeitsbereich role management 5S 0IM Role Management Automatic Tracking amp Assign User to Business Role amp User Requests Additional Role Role request Delegate Administration Identity Einstein Albert Identity that the ral Role delegation Delegate roles MYROO1 cem CEO Add Remove Show Roles you want to delegate IT Add Remove show Identities you want to delegate them to SAP Client client P client I Client I client aon 100 200 300 Information 25 State of the Art Omada Identity Manager Role Management 2 3 2 4 Der Arbeitsbereich compliance Nachdem im vorangegangenen Kapitel derjenige Bereich des Omada Identity Manager betrach tet wurde der sich mit dem Rollenmodell und dessen Wartung im Wirkbetrieb befasst folgt nun ein detaillierter Einblick in den Arbeitsbereich compliance Dieser zweite Arbeitsbereich von OIM befasst sich insgesamt betrachtet mit der Einhaltung von Policys sowie der Messung der workflows Damit k nne
121. den Wert nun nicht mit der Policy selbst sondern mit dem Benutzerkonto Wie in der Modellierung von Anforderung A wird auch hier der Kontext der in diesem Fall durch den Wert des Autorisierungsattributs festgelegt ist von der Policy getrennt Erst durch die Verkn pfung von Policy und Benutzer wird somit das spezifizierte Zugriffsrecht klar Der Vorteil der durch diesen Ansatz entsteht liegt klar auf der Hand Durch die Trennung des Wertes ist es m glich in einer Policy ein Auto risierungsattribut zu definieren dessen konkreter Wert von den individuellen Benutzern ab h ngt Der Nachteil davon ist dass die Verwaltung dieses Modells mit gro er Sorgfalt erledigt werden muss da Platzhalter nicht in jedem Szenario gleicherma en angewandt werden k nnen Mit diesem Ansatz wird das Ziel Z zur Komplexit tsreduktion auf Policy Basis erreicht denn es werden Rollen zusammengefasst deren Policys sich nur in den Attributwerten unterscheiden Abschlie end wird auch hier ein Beispiel zur Verdeutlichung gegeben In einer Bank verf gen Angestellte in der Rolle Schalterangestellter ber unterschiedlich hohe Bewilligungsgrenzen f r Kredite Normalerweise f hrt dies zu zwei eigenst ndigen Rollen die jeweils ber eine Poli cy verf gen die die unterschiedlichen Bewilligungsgrenzen dieser T tigkeit definieren Durch den hier vorgestellten Ansatz ist es m glich lediglich das Recht zur Bewilligung von Krediten f r die Rolle Schalterangest
122. des Unterneh mens Wenn zu einem sp teren Zeitpunkt die rollenbasierte Zugriffskontrolle unternehmensweit fortgef hrt und integriert wird ist diese Analyse eine wichtige Voraussetzung Nichtsdestotrotz ist die direkte Kommunikation mit dem Kunden auch bei der Entwicklung von Rollen elemen tar weil es in der Analysephase wichtig ist das Gesch ftsmodell und die Organisationsstruktu ren zu erfassen Wird BRBAC erfolgreich umgesetzt ist davon im sp teren Gesch ftsablauf wenig zu sp ren weil eine Zugriffskontrollarchitektur stets im Hintergrund agiert Durch die in BRBAC eingef hrte Trennung von Gesch fts und Systemrollen sollen gesch ftliche und tech nische Aspekte auf einem f r dieses Personal passenden Abstraktionsniveau dargestellt werden was die Bedeutung der Anforderungsanalyse unterstreicht Insbesondere aber die Administrati on also dasjenige Personal das am Ende des Vorgehensmodells mit dem implementierten Rol lenmodell arbeitet wird von einer klaren und strukturierten Umsetzung profitieren was ja auch eines der Hauptziele von BRBAC ist Nach der Erfassung der Anforderungen folgt die Erfassung des Ist Zustands auf gesch ftlicher und technischer Ebene In Analogie zu Ba96 und WWO7 steht auch in diesem Vorgehens modell die Erfassung des Ist Zustands im Rahmen einer Bestandsaufnahme im Vordergrund Im Gegensatz zum Vorgehen aus WWO7 das auf dem ERBAC Modell und dessen Erweiterun gen basiert sollen hier jedoch explizit
123. die sen beiden Phasen das Rollenmodell erzeugt wird Modellierung des Vorgehens als dynamischer Lebenszyklus Anforderung A R ckkopplung bei den Vorgehensphasen Die Forderung nach Dynamik im Vorgehensmodell bedeutet dass mit m glichst geringer Reaktionszeit auf sich ndernde Bedingungen eingegangen werden Kann Dies Kann bei einem Vorge hensmodell entweder in den einzelnen Phasen selbst oder ber Phasengrenzen hinweg geschehen Da das hier entwickelte Vorgehen sowohl die Entstehung des Modells mit dessen berf hrung in den Wirkbetrieb als auch die anschlie enden nderungen be trachtet gilt es zu definieren was zu einer R ckkopplung in eine fr here Phase f hrt bzw welche Auswirkungen eine R ckkopplung auf das weitere Vorgehen nach sich zieht Anforderung A Explizite Modellierung eines Lebenszyklus f r Rollen Bei der Begr ndung des Ziels Z wurde bereits angedeutet dass viele Vorgehensmodelle bei der berf hrung eines Modells in den Wirkbetrieb enden und somit nderungen im Wirkbetrieb nicht n her betrachten Da Unternehmen st ndig nderungen unterliegen ist es f r ein akzeptables Vorgehensmodell n tig dass es sich diesen nderungen wid met und sich daran anpassen kann sobald es sich im Wirkbetrieb befindet Will man das Vorgehen nicht als einen Prozess betrachten der klar endet sondern als Lebenszyk lus der erst dann endet wenn das Rollenmodell deprovisioniert wird muss dies als ex plizite Prozessph
124. die Funktion authorized users zum Ausdruck gebracht e sSoD n rs n V rs n V t c rs lel gt n gt authorized _users r Da nun die Modellspezifikation fiir RBAC mit SoD constraints sowie Hierarchien definiert wurde folgt nun die funktionale Spezifikation f r sSoD und dSoD Funktionale Spezifikation f r die statische SoD Relation e Administrative Funktionen mit constraints Im Falle von constrained RBAC ohne Hierarchien beinhalten die administrativen Funktionen alle in core RBAC definierten Funktionen Da jedoch die Definition von sSoD auf Benutzermitgliedschaften operiert deren Rollen sich wechselseitig ausschlie en muss die Funktion assignUser inso fern erweitert werden als dass sie berpr ft und sicherstellt dass eine Benutzerzuwei sung keine Policy Verletzung verursacht In diesem Referenzmodell wird ein SoD constraint als 3 Tupel aufgefasst das aus einer Referenz auf einen Gesch ftsprozess be steht f r den die Beschr nkung gelten soll einer Menge an Rollen die dabei zueinan der in Konflikt stehen und der Kardinalit t die dar ber Aussagen macht ber wie viele Rollen aus der Menge ein Benutzer gleichzeitig verf gen darf ehe eine Policy Verletzung auftritt Aus diesem Grund sind administrative Funktionen f r die Erzeu gung bzw L schung von SoD constraints solche Operationen die eine derartige In stanz anlegen bzw l schen oder nderungen an den drei beschriebenen Parametern vornehmen Folgende
125. dungen gleichzeitig auf einem Rechner arbeiten zu lassen Ta02 Durch das starke Engagement des amerikanischen Verteidi gungsministeriums etablierte sich der Schutzbedarf von Systemen zu einem wichtigen Aspekt und wurde mit dem Aufkommen vernetzter Systeme und des Internet zu einem inh renten Ent wurfsziel in der IT Landschaft FK 07 Dieser Sicherheitsbegriff ist sehr facettenreich und wird bereinstimmend in die Klassen Funktionssicherheit Informationssicherheit sowie Datensicherheit unterteilt Ein System gilt als funktionssicher wenn die Ist Funktionalit t mit der Soll Funktionalit t bereinstimmt Die Sicherheit von Informationen und Daten setzt ein funktionssicheres System voraus und gew hrleistet dass nur in autorisierter Weise auf Informa tionen und Daten zugegriffen werden Kann Eine wesentliche Folgerung der Sicherheit von In formationen und Daten ist dass es sich bei der Aufrechterhaltung eines bestimmten Sicherheits niveaus um einen fortlaufenden Prozess handelt da sich die Eigenschaften von Systemen im Laufe der Zeit ndern Ec05 Ad quate Verwaltungsmechanismen und die Kontrolle von Zu griffsberechtigungen sind zur Erhaltung dieses Sicherheitsniveaus fundamental WWO7 Zu griffskontrollarchitekturen stellen somit einen wesentlichen Baustein heutiger Computersyste men dar Zur Umsetzung der Zugriffskontrolle stellte La69 im Jahr 1969 ein formales Beschreibungs modell vor In diesem Rahmen wurden die
126. durch aus dass sie f r eine Menge von technischen Systemen definiert worden sind Erh lt ein Benutzer eine gene rische Rolle m ssen ein oder mehrere Endsysteme explizit angegeben werden zu denen der Benutzer Zugang erhalten soll Im Anschluss an diese Auswahl erh lt er dann die technischen Berechtigungen dieser ausgew hlten Systeme Generische Rollen sind in Information 14 darges tellt Static Separation of Duty Organizational Layer 9 y Role Hierarchy User User Assignment JRole Permission Assignment ie A Bd 1 1 Generic Permission Technical Layer Account in TS 1 Permission in TS 1 Account in TS 2 Permission in TS 2 Adapted from Ke02 Figure 6 Information 14 State of the Art Enterprise RBAC Model with Generic Roles Der hier verwendete Rollenbegriff verk rpert eine generische Rolle die ihrerseits ber eine Menge an generischen Berechtigungen verf gt Diese generischen Berechtigungen stehen nun f r mehrere Endsysteme mit hnlichen Berechtigungsstrukturen Wird ein Benutzer in eine Rol le eingeteilt und wie in der Abbildung dargestellt zwei Endsysteme ausgew hlt erh lt der Benutzer zwei Benutzerkonten engl accounts mit den f r die Rolle definierten Berechtigun gen in diesen Endsystemen Ke02 Joker Berechtigungen Wie bereits angesprochen wurde wird eine Rolle durch die Vereinigung aus Informationen ver schiedener Strukturen definiert Zur Veranschaulichung desse
127. e define Policy System Policy Attribute 1 1 define Policy 1 1 wildcard constraint wildcard constraint Information 42 Development of the BRBAC Role Model Wildcard Attributes Durch das 2 Tupel ist ein Zugriffsrecht formal spezifiziert Im RBAC Umfeld werden jedem Benutzer Zugriffsrechte durch seine Rollenmitgliedschaften zugeteilt die in den Policys defi niert sind Diese Trennung von Benutzern und Rechten stellt das grundlegende Ziel von RBAC dar Dadurch wird erreicht dass Rechte nur in konsistenter und nicht in individueller Form ver geben werden Auch werden dadurch Policy Vorgaben effektiv umgesetzt Dies f hrt allerdings in Situationen in denen individuelle Attributwerte vergeben werden unausweichlich dazu dass hierf r eigene Policys erzeugt werden m ssen Betrachtet man diese Policys genauer so stellt man fest dass sie sich oftmals nicht in den enthaltenen Attributen unterscheiden sondern ledig lich in den Attributwerten Wie in den Erweiterungen zum ERBAC Modell belegt wird f hrt dieser Ansatz genau in solchen F llen zu einer Vervielfachung von Rollen wo sich die Zu griffsmuster nicht im Attribut sondern nur in dessen Wert unterscheiden Es stellt sich die Frage ob sich dieses Problem vereinfachen l sst denn offenbar sind diese Rol len bis auf den konkreten Attributwert identisch oder zumindest sehr hnlich Das hier vorges tellte Modell BRBAC verkn pft den zum Autorisierungsattribut geh ren
128. e Ansprechpartner besitzen die technische Kompetenz zur Pflege dieser Serversysteme e Das IT Consulting Unternehmen ed consult Als Beratungsunternehmen im IT Bereich stellt ed consult seinem Kunden c amp m eine Menge an Mitarbeitern zur Verf gung die c amp m bei der geplanten nderung der Zugriffskontrolle in der technischen In frastruktur unterst tzen Aus diesem Grund kennt ed consult in der Rolle des Sicher heits Consultant engl security consultant die Software L sung ed tec der Firma ed soft und verf gt ber die technische Kompetenz beim Aufbau einer rollenbasierten Zugriffskontrollarchitektur Die Consultants stellen somit neben der Unterst tzung von c amp m auch den Vermittler zwischen c amp m und ed soft dar um Erfahrungswerte im Um gang mit ed tec an den Software Hersteller weiterzuleiten e Der Software Hersteller ed soft Der Software Hersteller ed soft wird in diesem Sze nario durch die Gesch ftsrolle Software Entwickler engl software developer vertre ten die ma geblich an der Entwicklung und Verbesserung von ed tec beteiligt ist Dazu stehen Entwickler in dieser Rolle in direktem Kontakt mit den Sicherheits Consultants von ed consult 7 1 2 Vorstellung der Systemrollen An dieser Stelle werden die Systemrollen eingef hrt die in diesem Szenario auftreten Es muss erw hnt werden dass es sich dabei zun chst um atomare technische Berechtigungen handelt was in BRBAC als System Policy definiert wurd
129. e C amp M Entwicklung eines Vorgehensmodells fiir die rollenbasierte Zugriffskontrolle 97 komplett von technischen Details und wird vom Kunden zusammen mit dem Analysten tiber nommen Die hier formalisierten Anforderungen flie en gleicherma en in das Lastenheft ein Gr nde f r R ckkopplungen In Information 47 werden die verbal beschriebenen Teilprozesse der Aktivi t Rollenanalyse engl role analysis grafisch verdeutlicht Man erkennt hieraus welche Schritte in dieser Phase n tig sind wer an dem Prozess beteiligt ist und welche Artefakte dabei entstehen Aus Informa tion 46 sind die R ckkopplungen zwischen den Phasen aufgezeigt Zu R ckkopplungen kann es an dieser Stelle nicht kommen weil die Analysephase den Beginn des Vorgehens symbolisiert 5 3 Entwurfsphase Nach der Analyse des Ist Zustands sowie der Spezifikation der Anforderungen in Form eines Lastenhefts werden diese Artefakte in der Entwurfsphase aufgegriffen und zu einer umsetzungs f higen Version verfeinert Die Durchf hrbarkeit wurde neben der formalisierten organisatori schen und funktionalen Struktur festgelegt und zusammen mit einzuhaltenden Fristen sowie im Prozess verantwortlichem Personal definiert Das Ziel der Entwurfsphase ist diese grobe Spezi fikation zu pr zisieren so dass das Rollenmodell instanziiert werden kann Dazu ist es n tig das hybride Vorgehen fortzusetzen um daraus Rollen abzuleiten In analoger Weise zur Analy sephase kann die Spezifizi
130. e Konsistenz der Unter nehmensdaten nicht sicherstellen kann und dar ber hinaus u erst zeitaufw ndig ist Als letzter Aspekt l sst sich feststellen dass beide analysierten Werkzeuge in den vorliegenden Versionen das Paradigma der dienstorientierten Architekturen nicht hinreichend unterst tzen Mit dem Rollenmodell BRBAC aus Kapitel 4 wird eine explizite Trennung von Gesch fts und System rollen gefordert und Erweiterungen dazu modelliert die auf dieser expliziten Trennung basie ren Die in BRBAC geforderte Trennung l sst sich in den analysierten Werkzeugen nicht nativ umsetzen weil das Rollenmodell NIST RBAC auf welchem diese basieren die Unterscheidung nur implizit in Form von Rollenattributen vornimmt Im n chsten Kapitel wird auf der Basis der hier vorgenommenen Analyse der Werkzeuge dasje nige ausgew hlt das im vorgegebenen Szenario als vorteilhaft erachtet wird und BRBAC im Vorgehensmodell aus Kapitel 5 in den produktiven Einsatz zu berf hren Forschungsgruppe C amp M Fallstudie zur Anwendung der Modelle in einem kommerziellen Produkt 121 7 FALLSTUDIE ZUR ANWENDUNG DER MODELLE IN EINEM KOMMERZIELLEN PRODUKT In diesem Kapitel soll die Tragf higkeit der Rollenmodelle gezeigt werden die in dieser Arbeit entwickelt wurden Dazu wird zun chst ein Szenario gew hlt welches der Fallstudie zugrunde liegt Dazu wird zun chst das Gesch ftsmodell eines gedachten Unternehmens vorgestellt wel ches auf eine rollenbasierte
131. e Obergrenze zur Bewilligung von Krediten was wiederum ein Benutzerattribut ist und somit durch Anwendung einer Regel berpr ft werden kann L5 SAM Jupiter implementiert Basiert auf ERBAC In Deployment Projekten Erfahrung ge sammelt und daraus wiederum ERBAC Modell erweitert um Parametrisierung Nachweise Welche Nachweise werden hinsichtlich der Tragf higkeit der eigenen L sungen geliefert N1 Das ERBAC Modell ist im kommerziellen Sicherheitsprodukt SAM Jupiter implementiert Der Autor belegt durch Erfahrungen aus Industrieprojekten dass die Umsetzung dieses Modells praktikabel ist N2 Der Autor erw hnt dass durch die Erweiterung des ERBAC Modells um die Parametrisie rung die Anzahl an Rollen nachweislich gesenkt werden kann Offene Fragen Welche Fragen sind noch ungel st geblieben bzw stellen sich dem Leser Forschungsgruppe C amp M Anhang 155 O1 Gibt es einen Beleg dass sich die Verringerung der Rollenzahl sowie die Vereinfachung der Rollenstruktur auch in der Praxis bew hren O2 Welcher zeitliche sowie geldwerte Aufwand entsteht bei der Migration einer bestehenden Unternehmensstruktur auf SAM Jupiter O3 In wie weit beg nstigt ein durchdachter role engineering Prozess das ERBAC Modell O4 Wie steht dieser Ansatz zum hybriden Vorgehen bei Aufsp hren von Rollen Wo gibt es Ankn pfungspunkte F 2 Vorgehensmodelle fur RBAC in heterogenen Systemland schaften WWO7 Felix Wortmann Robert Win
132. e und Transparenz im Unternehmensbe reich KonTraG Bun98 die unter Anderem auch eine Erh hung der Transparenz bei Struktu ren Befugnissen und Kompetenzen fordern Dies erh ht auch hier den Anreiz nach einer klaren Organisation Insgesamt betrachtet nimmt also die Komplexit t sowohl auf Gesch ftsebene als auch auf technischer Ebene sehr stark zu so dass ein Ansatzpunkt f r diese Arbeit die Komple xit t darstellt der man sich heute durch den intensiven Gebrauch von Computersystemen und damit einhergehenden gesetzlichen Regularien ausgesetzt sieht Es wird versucht die Reduktion von Komplexit t einerseits durch die explizite Trennung gesch ftlicher und technischer Aspek te im Rollenmodell zu erm glichen sowie andererseits durch Mechanismen die durch die expli zite Trennung erst m glich werden Information 1 veranschaulicht die Komplexit t auf diesen beiden Ebenen und st tzt sich dabei auf Erfahrungswerte der Firma iC Consult Forschungsgruppe C amp M 4 Einleitung Organizational Layer Technical Layer SR 1 1 SR1 2 SR 1 k SR 2 1 SR 2 2 SR 2 p SR m 1 SR m 2 SR m l Enterprise System S 1 JEnterprise System S 2 Enterprise System S m Bi ws Information 1 Introduction Clarification of the Problem Information 1 zeigt den Sachverhalt wie er sich heute in einem mittelst ndischen aber auch ei nem Gro unternehmen darstellt Die Erfahrung aus Industrieprojekten zeigt dass die Anzahl der eingesetzten Sy
133. eOperationsOnObject Liefert die Menge an Operationen zur ck ber die eine bestimmte Rolle beim Zugriff auf ein bestimmtes Objekt verf gt O o userOperationsOnObject Liefert die Menge an Operationen zur ck ber die ein bestimmter Benutzer beim Zugriff auf ein bestimmtest Objekt ver f gt O 2 2 2 RBAC Modell mit Hierarchien Das Modell hierarchical RBAC erweitert core RBAC um Hierarchien auf der Basis von Rollen Alle in core RBAC definierten Spezifikation sind gleicherma en g ltig m ssen jedoch durch die Einf hrung von Hierarchien gegebenenfalls abge ndert werden Im Folgenden wird nun wieder zun chst auf die Modellspezifikation und im Anschluss daran auf die funktionale Spezi fikation eingegangen Modellspezifikation Zur Modellierung von Hierarchien wird eine zus tzliche Relation role hierarchy eingef hrt die auf Rollen definiert ist Hierarchien sind im Zusammenhang von RBAC ein wichtiger Aspekt so dass weiterf hrende Arbeiten wie etwa Implementierungen von Rollenmodellen in kommer ziellen Produkten meist auf diesem Modell oder auf hierarchical RBAC with constraints auf bauen welches im n chsten Teilkapitel besprochen wird Hierarchien beschreiben eine Verer bungsrelation die auf Rollen beschr nkt ist Dabei erbt eine Rolle r von einer Rolle r alle in ihr aufgef hrten Berechtigungen engl permissions Im RBAC Standard werden f r Hierar chien sowohl partielle als auch strenge Ordnungen definiert Das f
134. egangen wird Die drei wesentlichen Eigen schaften einer Gesch ftsrolle sind allerdings die Benutzermenge die Menge der Gesch fts Policys und die Systemrollenmenge In der Benutzermenge sind alle Benutzerkonten aufgef hrt die die Gesch ftsfunktion aus ben Die Gesch fts Policys definieren die gesch ftlichen Rechte dieser Rolle und in der Menge der Systemrollen stehen alle technischen Zugriffsrechte die die Gesch ftsrolle zur Erbringung dieser Funktion ben tigt Gesch fts Policys stellen demnach Be rechtigungen dar die nicht auf technischen Endsystemen angewandt werden sondern die Be fugnisse innerhalb von Gesch ftsprozessen definieren Eine Systemrolle im Gegensatz dazu verk rpert technische Zugriffsrechte in einem oder mehre ren Endsystemen Ihr kann hierbei durch eine geeignete Namensgebung semantische Bedeutung verliehen werden um das zur Verwaltung n tige technische Verst ndnis zu verringern Durch die Kapselung von Gesch ftsaufgaben in einem eigenen Rollentyp subsumiert die Systemrolle rein technisches Wissen was in einem intuitiveren Rollenmodell resultiert Die beiden wesentli chen Eigenschaften von Systemrollen sind die Gesch ftsrollenmenge und die Menge an techni schen Zugriffsrechten in den angeschlossenen Endsystemen Durch die hier eingef hrte explizi te Trennung von gesch ftlichen und technischen Funktionen wird es m glich eine Rechtevererbung zu unterst tzen auf die in Kapitel 4 3 2 vertieft eingegangen wird
135. egen Gesch ftsregeln oder fristen engl compliance issues effektiv umgegangen wird Zus tzlich dazu sollte bei Verst en gegen das SoD Prinzip das verantwortliche Personal automatisch gewarnt und entsprechende Schritte eingeleitet werden e Zwar bieten Rollenmanagementwerkzeuge das Erzeugen abstrakter Gesch fts und Sys temrollen an es ist aber ebenso wichtig die Beziehung zwischen Gesch ftsrollen und Benutzern sowie Systemrollen und Zugriffsrechten zu betrachten Aufgrund der Viel zahl unterschiedlicher Rollen ist es wichtig dass ein Rollenmanagementwerkzeug im Aufgabenbereich role reconciliation unterschiedliche Filter und Sichtweisen anbietet Entscheidend ist dabei sehen zu k nnen ber welche Rolle oder Rollen ein einzelner Benutzer verf gt von wem und wann die Zuteilungen erfolgt sind und zu welchem Zeitpunkt sie im Zuge einer routinem igen Verwaltungsaufgabe berpr ft werden soll te Dies sollte sowohl f r Gesch fts als auch f r Systemrollen m glich sein e Da Rollen und Policys in Rollenmanagementwerkzeugen aus verschiedenen Quellen akquiriert und analysiert werden haben diese Werkzeuge einen berblick ber das gan ze Unternehmen Daher macht es Sinn sie auch als autorative Quelle f r diese Informa Forschungsgruppe C amp M 26 Grundlagen tionen zu verwenden So k nnten Eigenschaften von Rollen wie etwa Einschr nkun gen oder Mitgliedschaften interessant sein f r Systeme die selbst keinen
136. egen von Abteilungen oder ganzer Firmen ergeben Im RBAC Kontext bedeutet das dass sich nderungen an den Zuweisungen von den Organisationsstrukturen auf das Rollenmo dell ergeben oder auch an den Relationen Benutzer Rolle und Rolle Berechtigung selbst Der grundlegende Vorteil rollenbasierter Zugriffskontrollarchitekturen zeigt sich hier in besonderem Ma e RBAC Modelle bieten bei strukturellen nderungen ein hohes Ma an Flexibilit t kom biniert mit der M glichkeit sehr schnell auf nderungen reagieren zu k nnen Nun setzt man sich in dieser Phase unter Anderem mit der Abbildung organisatorischer Strukturen auf ein m gliches Rollenmodell auseinander wie es ebenso in der Analysephase geschieht jedoch m ssen Rollen in der Rollenwartungsphase nicht grundlegend neu konzipiert sondern lediglich an die nderungen angepasst werden Dies unterscheidet sich demnach klar von der initialen Analyse Ferner k nnen diejenigen Teile des existierenden Konzepts die von den organisatori schen nderungen nicht betroffen sind unver ndert bernommen werden F r eine tiefgreifendere Analyse des Lebenszyklus von Rollen sei verwiesen auf die Beitr ge KK 02 und SA 04 Das Kapitel ber den Lebenszyklus von Rollen beschie t die Betrach tung aktueller wissenschaftlicher Bet tigungen im Bereich der rollenbasierten Zugriffskontrolle f r verteilte Informationssysteme Im Folgenden werden nun zwei kommerzielle Implementie rungen von Rollenmanagementw
137. ehandelt im Wesentlichen die Modellierung eines Rollen sowie eines Vorge hensmodells fiir die rollenbasierte Zugriffskontrolle engl role based access control RBAC Aus diesem Grund ist es zun chst wichtig grundlegende Begriffe aus diesem Bereich zum all gemeinen Verst ndnis einzuf hren Aus diesem Grund wird hier zun chst das grundlegende Konzept der rollenbasierten Zugriffskontrolle vorgestellt das als alternatives Architekturprinzip zur klassischen Zugriffskontrolle auf der Basis von Identit ten gesehen werden kann engl identity based access control IBAC Dabei wird RBAC in Bezug gesetzt zur Subjekt Objekt Relation die im Bereich des Identit tsmanagements als abstraktes Modell zur Beschreibung von Zugriffsversuchen verwendet wird Em08 Im Anschluss daran wird das RBAC Standardrahmenwerk eingef hrt welches vier Modelle f r die rollenbasierte Zugriffskontrolle mit unterschiedlichem Funktionsumfang definiert Neben der Entwicklung von Modellen wer den in dieser Arbeit sogenannte Rollenmanagementwerkzeuge untersucht und verwendet Diese verwenden Rollen f r die Zugriffskontrolle und beschr nken sich dabei nicht auf ein einzelnes technisches Endsystem sondern weiten die Zugriffskontrolle auf mehrere Systeme aus Das ab schlie ende Kapitel 2 3 befasst sich daher mit einer Einf hrung in typische Aufgabenbereiche von Rollenmanagementwerkzeugen 2 1 Die Subjekt Objekt Relation Die rollenbasierte Zugriffskontrolle stellt ein Mode
138. ehr hoher Wahrscheinlichkeit ein gro e Zahl an Rollen unn tig macht was darauf zur ckzuf hren ist dass viele Zugriffsmuster in Unternehmen bis auf die konkreten Attributwerte identisch sind An dieser Stelle sei nochmals das Beispiel aufgef hrt in dem zwei Bankangestellte das Recht haben Kredite zu bewilligen Ohne die Verwendung von Platzhaltern muss f r jeden Kreditbe willigungsrahmen eine eigene Policy definiert werden was in RBAC zur Entwicklung einer ei genen Rolle f hrt Durch Platzhalter Attribute w rde dieser Sachverhalt in einer einzigen Sys tem Policy formuliert werden k nnen da der Kreditbewilligungsrahmen im Benutzerobjekt selbst enthalten ist Ein weiterer Ankn pfungspunkt f r Forschungsarbeiten stellt die Vererbung von Rechten dar die erst durch die explizite Trennung von Gesch fts und Systemrollen Vorteile aufweist Es wurden mit block policy inheritance und no override zwei Prinzipien erw hnt die zu einer Re duktion redundanter Policys einerseits und der Sicherstellung von Policy Vorgaben andererseits f hren Dies k nnte in einem BRBAC konformen Rollenmanagementwerkzeug Beachtung fin det Es stellt sich demnach die Frage ob zus tzliche Steuerungsmechanismen bei der Rechte vererbung als sinnvoll erachtet werden k nnen Abschlie end bietet BRBAC eine breite Palette an M glichkeiten f r Performance Analysen an um die Leistung dieses Rollenmodells unter verschiedenen Voraussetzungen zu messen Die Er fahr
139. ei wesentliche Kriterien zur Werkzeugauswahl zugrunde e Die M glichkeit Gesch ftsrollen und Systemrollen zu definieren und zumindest impli zit zu unterscheiden e Die Unterst tzung eines hybriden Vorgehens bei der Entwicklung von Rollen e Die algorithmische Unterst tzung bei der Systemrollenentwicklung e Die Unterst tzung administrativer Aufgaben in Form von workflows f r die Betriebs phase Diese Kriterien werden in der vorliegenden Version vom Sun Role Manager besser unterst tzt so dass im Folgenden dieses Werkzeug zur Umsetzung von BRBAC im IST Szenario verwen det wird Forschungsgruppe C amp M Fallstudie zur Anwendung der Modelle in einem kommerziellen Produkt 127 7 2 2 Rollenanalyse und Rollenentwurf Nachdem im vorangegangenen Kapitel ein Rollenmanagementwerkzeug fiir die Umsetzung von BRBAC ausgew hlt wurde werden die im IST Szenario definierten Rollen nun im Sun Role Manager umgesetzt Dabei werden die Gesch fts und Systemrollen aus Kapitel 7 1 aufgegrif fen und miteinander in Beziehung gesetzt Das Ergebnis dieses Entwurfs ist in Information 56 dargestellt F r eine vereinfachte Darstellung ist an dieser Stelle lediglich ein Ausschnitt ge w hlt worden der die Gesch ftsrollen von c amp m enth lt Das Gesamtbild ist unter Anhang C in Information 65 aufgef hrt Wie das Vorgehensmodell spezifiziert wird in der Analysephase im Hinblick auf die entstehen den Rollen zun chst die Ist Situation im Unternehmen erf
140. eigene Rol le ben tigen w rde Pr missen Welche Einschr nkungen und Vorgaben werden hinsichtlich der eigenen L sungen gemacht P1 Anders als im klassischen RBAC Modell verf gt das hier vorgestellte ERBAC Modell nicht ber den Mechanismus der session um unterschiedliche Benutzerkontexte zu unterst t zen Dies ist aufgrund der system bergreifenden Natur des hier eingef hrten Rollenbegriffs nicht zu realisieren Stattdessen werden die erteilten Berechtigungen an die beteiligten Endsys teme weitergereicht Forschungsgruppe C amp M 154 Anhang P2 Durch das Fehlen des Benutzerkontextes ist dynamisches SoD nur durch einen Umweg zu realisieren Falls das zugrundeliegende Endsystem nicht selbst ber die dynamische Aufgaben trennung verf gt wird der Benutzerkontext durch unterschiedliche Benutzerkonten pro Aufgabe realisiert L sungen Was sind die eigenen L sungen L1 Die Anzahl an resultierenden Rollen sowie die resultierende Rollenstruktur werden durch Parametrisierung wesentlich vereinfacht Diese Parametrisierung ist in Form von Attributen und Regeln realisiert L2 Das Benutzerobjekt verf gt im hier erweiterten ERBAC Modell ber allgemeine oder spe zifische Benutzerattribute die ihn genauer spezifizieren Diese Informationen werden zur auto matischen Einteilung in Rollen oder Benutzeradministration herangezogen L3 Generische Rollen erlauben das Erteilen generischer Zugriffsrechte falls mehrere Endsys
141. ein Kriterium f r den Ansatz der Autoren D4 Die Autoren versprechen sich durch ihren Ansatz eine weitere Zunahme bei der Akzeptanz von RBAC konformen Zugriffskontrollsystemen weil der von ihnen propagierte Lebenszyklus eine nat rliche Auffassung eines Lebenszyklus widerspiegelt Er sorgt f r ein besseres Ver st ndnis des Rollenbegriffs als das bisherige Verst ndnis einer Rolle als eine Mittelschicht zwischen Benutzern und Berechtigungen D5 Die Motivation der Autoren eine Diskussion ber den Lebenszyklus von Rollen anzure gen umfasst in erster Linie folgende vier Punkte Der Lebenszyklus stellt Schnittstellen zur Ei nordnung existierender und zuk nftiger Arbeiten im Bereich von Rollen dar Zweitens bietet ein Lebenszyklus einen strukturierten Prozess zur Entwicklung eines rollenbasierten Gesamtsys tems dar Drittens stellt der Lebenszyklus eine effiziente Anwendung von Rollen in Anbetracht von nderungen im Unternehmen dar und viertens ist ein Rollenlebenszyklus die Basis f r ei nen geordneten Umgang mit Rollen engl role engineering Pr missen Welche Einschr nkungen und Vorgaben werden hinsichtlich der eigenen L sungen gemacht P1 Der Lebenszklus ist die Basis der Arbeit P2 Die Motivation basiert auf den folgenden beiden Pr missen Der Lebenszyklus von Rollen muss hinreichend abstrakt gehalten sein um damit in unterschiedlichen Szenarien umgehen zu k nnen zumal eine Rolle ein kontext abh ngiges Konstrukt
142. einzelne Benutzeroberfl che und l st somit das Komplexit tsproblem in heterogenen System landschaften Neben den Kosten die durch die Konsistenzhaltung unterschiedlicher Systeme entsteht stellt die manuelle Administration einen zweiten Kostenfaktor dar der durch SAM au tomatisiert werden kann SAM bietet hierf r automatische Provisionierungs und Deprovisio nierungsprozesse zur Verf gung Offene Fragen Welche Fragen sind noch ungel st geblieben bzw stellen sich dem Leser Ol Der hier aufgezeigte Ansatz ist zwar nachvollziehbar und durch Praxiserfahrung belegt jedoch an wesentlichen Stellen auf einfache Sachverhalte reduziert So ist etwa das in dieser Publikation verwendete Rollemodell als Repr sentation der Organisationsstruktur sehr einfach gehalten Wie verh lt sich ein derartiger Ansatz jedoch in gro en Unternehmen O2 Innerhalb des Rollenzyklus sind die Phasen sehr klar voneinander zu trennen Welche Ar tefakte jedoch entstehen innerhalb dieser Phasen 03 Grundlegend wichtig an einem RBAC Ansatz f r heterogene Systemlandschaften ist dass die Rollenmanagementl sung mit einer m glichst gro en Zahl an Endsystemen kommunizieren kann Darauf wird jedoch nicht eingegangen F 5 A role based infrastructure management system SA 04 Dongwan Shin Gail Joon Ahn Sangrae Cho Seunghun Jin A role based in frastructure management system design and implementation John Wiley amp Sons Ltd 2004 Inhalte Was sind die ze
143. eisen kombiniert SA 04 Das Ziel des Vorgehensmodells ist dass es sich bei der Identifikation von Rollen bes ser an die Gegebenheiten von Unternehmen anpasst als bisherige Modelle sich dabei auf den hybriden Ansatz st tzt und so die L cke zwischen Theorie und Praxis schlie t Der dritte Schwerpunkt dieser Arbeit liegt in einer kriteriengest tzten Untersuchung ausgew hl ter Werkzeuge die die Arbeitsprozesse zum Verwalten und Verkn pfen von Rollen unterst t zen Speziell die Aufgabe der Herausarbeitung von Rollen aus einer bestehenden Unterneh mensstruktur bekannt als role discovery oder role mining gilt aktuell als sehr schwierig umzusetzen Da die Berechtigungen auf technischer und organisatorischer Ebene im Zuge der Komplexit t in Unternehmensstrukturen weder konsistent noch korrekt sind fehlt eine ordentli che Datenbasis f r das automatisierte Erzeugen von Rollen Daran schlie t sich das Verkn pfen dieser Rollen bekannt als role reconciliation an Ka07b Das erste Kriterium zur Auswahl der in dieser Arbeit verwendeten Werkzeuge ist dass sie ein hybrides Vorgehensmodell unterst t zen und nicht f r einen spezifischen Einsatzzweck hin konzipiert wurden Das zweite Kriterium ist die technologische Reife der Werkzeuge was daran gemessen wird wie lange sie schon auf dem Markt angeboten werden Dabei soll in dieser Arbeit ein bereits seit l ngerer Zeit verf gba res und somit etabliertes Werkzeug und ein relativ junges Werkzeug
144. eits f hren sie zu komplexen technischen Implementie rungen in der praktischen Umsetzung Auf der Basis der in diesem Kapitel dargestellten Erkenntnisse wird im nun folgenden Kapitel ein Rollenmodell entwickelt welches sich diesen beiden Schwachstellen widmet Forschungsgruppe C amp M Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen 69 4 ENTWICKLUNG EINES ROLLENMODELLS ZUR AB BILDUNG VON GESCHAFTS UND SYSTEMROLLEN 4 1 Anforderungen an das Rollenmodell Dieses Kapitel stellt den ersten zentralen Aspekt dieser Arbeit dar Es wird ein Modell f r die rollenbasierte Zugriffskontrolle entwickelt das auf dem RBAC Standardrahmenwerk basiert welches in Kapitel 2 2 bereits beschrieben wurde Dieses Modell unterteilt das Element Rolle in die zwei Auspr gungen Gesch ftsrolle engl business role BR und Systemrolle engl system role SR und richtet sich mit dieser Unterscheidung speziell an Unternehmen Im Fol genden wird dieses Modell daher auch als BRBAC engl business role based access control bezeichnet Dazu werden in diesem Unterkapitel zun chst zwei Ziele Z und Z f r das Rollen modell definiert und Anforderungen erhoben um diese Ziele umzusetzen In den Kapiteln 4 2 und 4 3 werden die erhobenen Anforderungen im Bezug zu dem Ziel modelliert welches sie er f llen und detailliert beschrieben Kapitel 4 4 stellt dann das resultierende Gesamtbild des Rol lenmodells BRBAC vor An dieser
145. ele f r Attribute sind etwa die Zugeh rigkeit zu einer Organisations einheit wie etwa einer Abteilung das Arbeitsprofil der Rolle den Ort des Arbeitsplatzes oder hnliches Jede Rolle verf gt nun in diesen Attributen ber eine eindeutige Wert belegung Da eine Rolle genau dieser eindeutigen Wertbelegung ihrer Attribute ent spricht f hren nderungen der Werte somit automatisch zur Entwicklung zus tzlicher Rollen Um die Anzahl der Attribute pro Rolle zu verringern l sst sich der Hierarchie mechanismus verwenden Hierbei werden gleiche Attribute mehrerer Rollen aus diesen extrahiert und eine bergeordnete Rolle daf r definiert Dadurch erreicht man eine Hierarchiebildung auf der Basis dieses speziellen Attributs Da es aber in der Regel sehr viele unterschiedliche Hierarchien gibt w rde das Rollenmodell auch sehr viele vonei nander unabh ngige Rollenhierarchien aufweisen Beispielsweise hat die Hierarchie der Angestellten einer Firma nicht unmittelbar etwas mit der Organisationsstruktur der Fir ma zu tun Das Pflegen von mehreren unabh ngigen Hierarchien verursacht eine sehr Forschungsgruppe C amp M 34 Stand der Technik hohe Komplexit t in der Umsetzung was bei einem Rollenmodell als sehr kritisch ein gestuft werden muss weil die Verringerung der Komplexit t ja gerade eines der Haupt ziele von RBAC darstellt Wie gerade angesprochen wurde kann diese Information als Alternative zur intensiven Nutzung von Hierarchien als
146. ellelemente des ERBAC Modells das in Information 13 dargestellt ist parametrisiert werden Benutzer engl user Rolle engl role die Benutzer Rolle Relation engl user assignment die Rolle Berechtigung Relation engl permission assignment sowie die Rollenhierarchie engl role hierarchy Dabei steuern Re geln welche Schritte zu ergreifen sind wenn Attribute oder Zuteilungen engl assignments ge ndert werden In den folgenden Unterkapiteln wird nun auf die vier Erweiterungen einge gangen die die Anzahl der implementierten Rollen und damit auch den administrativen Auf wand sehr stark verringern Diese vier Erweiterungen basieren auf Erfahrungswerten aus dem Umgang mit dem ERBAC Modell und haben sich in der Praxis bereits bew hrt wie Ke02 be legt Benutzerattribute Eine erste Erweiterung des ERBAC Modells aus Kapitel 3 1 2 stellen die Benutzerattribute dar Das Modellelement user aus Information 13 verfiigt bereits tiber Standard sowie benutzerspezi fische Attribute Standardattribute sind Eigenschaften die alle Benutzer besitzen wie bei spielsweise der Name des Benutzers seine Anrede oder seine Emailadresse Diese Informatio nen k nnen in einem automatisierten Provisionierungsprozess an die Endsysteme weitergereicht werden wenn dort ein Benutzerkonto f r diesen Benutzer angelegt wurde und dieses Benutzer konto ebenfalls diese Attribute aufweist Die benutzerspezifischen Attribute wirken sich in einer RBAC Umgebung auf
147. ellen Ressourcen als auch die zeitlichen Fristen die f r das Vorgehensmodell veranschlagt wurden berarbeitet werden Ein zweites Indiz f r R ckkopplung stellt der Sys temrollen Entwurf dar Sollten bei der Anwendung der role mining Algorithmen keine geeigne ten Systemrollen gefunden werden k nnen ist der zugrundeliegende Datenbestand m glicher weise nicht umfassend genug und deutet somit auf einen Fehler in der Analysephase hin da der Datenbestand dort definiert wurde Ein drittes Indiz f r eine R ckkopplung ist wenn der Kunde zum Abschluss des Entwurfs mit hierbei festgelegten Entwurfsentscheidungen nicht einverstan den ist Diese Bedenken k nnen im erw hnten Interview mit Analysten und Consultants entwe der ausger umt oder unmittelbar nachgebessert werden Bei gr eren Nachbesserungen sollte allerdings auch hier explizit in die Analysephase zur ckgekehrt werden um das Gew nschte nachzumodellieren 5 4 Implementierungsphase In bereinstimmung mit dem Vorgehensmodell aus WW07 beschreibt die Implementierungs phase fiir Rollen denjenigen Teilprozess in dem das spezifizierte Rollenmodell in den Wirkbe trieb berf hrt wird und die entworfenen Rollen in der Gesamtheit technisch umgesetzt werden Die Grundlage hierf r bilden die Artefakte aus der Entwurfsphase nachdem sie durch den Kun den abgenommen und f r gut befunden wurden Dieser Teilprozess ist in zwei Phasen unterteilt Zun chst muss das Rollenmanagementwerkzeug
148. ellter in einer Policy festzulegen und durch einen wildcard Wert im Autorisierungsattribut den entsprechenden Wert vom Benutzerkonto zu beziehen was un mittelbar zur Laufzeit geschehen kann Wie bereits erw hnt wurde stellt dieser Ansatz Anfor derungen an die Sorgfalt mit der das resultierende Rollenmodell gepflegt wird Die Verwen dung von Policys mit Platzhaltern stellt keine prinzipielle Vorgehensweise dar sondern lediglich eine M glichkeit die unter gewissen Umst nden als sinnvoll erachtet werden kann Forschungsgruppe C amp M 82 Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen Diese Umst nde gilt es individuell zu diskutieren In diesem Beispiel f hrt der vorgestellte An satz zur Entwicklung von lediglich einer Rolle Schalterangestellter mit der Policy Kreditbe willigung Anders als in den Erweiterungen zum ERBAC Modell aus Ke02 wo dieser Me chanismus auch verwendet wird bleiben die konkreten Werte im Benutzerobjekt erhalten In Ke02 werden diese Werte zu dem Zeitpunkt zu dem ein Benutzer in die Rolle eingetragen wird in die Policy fest eingetragen und bei einer nderung des Wertes durch einen vorher defi nierten Algorithmus angepasst Dadurch dass der Attributwert selbst im Benutzerkonto enthal ten ist hat eine nderung der Rollen ber deren Lebensdauer keinerlei Auswirkung auf die Po licys au er nat rlich die Policys werden selbst ge ndert Auch kann hierdurch f
149. elnen Bereiche anzus teuern Hier wird unmittelbar der Zusammenhang zur Gesamtarchitektur aus Information 28 deutlich Die Anwendung wird ber einen Internet Browser aufgerufen und bietet eine einheitli Forschungsgruppe C amp M Stand der Technik 59 che Oberfl che fiir alle Aufgaben im Umgang mit Rollen an Nachdem nun ein Einblick in das Architektur und Komponentenmodell des SRM gegeben wurde folgt eine n here Betrachtung der Funktionen innerhalb der drei Arbeitsbereiche Da die Basis aller Bereiche die zentrale Da tenbank ist wird im n chsten Teilkapitel zun chst das identity warehouse dargestellt 3 3 2 Die Komponente identity warehouse Identity Warehouse My Settings sts Identity Warehouse ECEN a MLC later ie ie CRCELEC Cal me CCH me OTs Administration w gt Business Structures ers Roles Policies EndPoints GB New Business Structure Delete Business Structures J Refresh Business Structures c amp m Management Department c amp m Business Structures p Policies Relationship Map Business Management Department c amp m Unit Name Bine un Business Unit Unit C Ps Business Unit Code Division Owner Albert Einstein Administrator Bill Gates Public Relations Department i2s Training Participants i2s Managers Albert Einstein Description dress Main Phone Other Phone Fax Mail Code E mail d Web Site Streeti State Province Street2
150. em bergreifender Rollen im ERBAC Standard als Enterprise Rollen bezeichnet P3 Es wurden Beitr ge aus der Forschung ausgew hlt die sich im Hinblick auf die Entwick lung eines entsprechenden Vorgehensmodells verwerten lassen Dadurch weisen sie erstens ei nen expliziten Bezug zur system bergreifenden Autorisierung auf zweitens enthalten oder the matisieren sie ein Vorgehensmodell drittens erlauben sie bez glich ihres Abstraktionsgrads eine hinreichend konkrete Diskussion und viertens sind sie umsetzungsorientiert oder bereits in der Praxis umgesetzt worden Forschungsgruppe C amp M 156 Anhang P4 Die Autoren stellen in ihrer Arbeit Praxisprojekte in Form von Fallstudien vor und nehmen dies als Ausgangspunkt fiir die Ableitung eines Vorgehensmodells Inhalt dieser Fallstudien sind Vorgehensmodelle bestehend aus mehreren Phasen und darin enthaltenen Aktivit ten L sungen Was sind die eigenen L sungen L1 Die Autoren konsolidieren Ans tze aus Forschung und Praxis zu einem daraus abgeleiteten Vorgehensmodell welches zugleich transparent aus der Praxis als auch theoriebasiert sein will L2 Hierzu wird ausgehend von den Fallstudien ein induziertes Modell erstellt welches Akti vit ten beider Studien in berdeckung bringt Nachweise Welche Nachweise werden hinsichtlich der Tragf higkeit der eigenen L sungen geliefert N1 Das Vorgehensmodell leitet sich von Projekten ab die seit mehreren Jahren produktiv sind
151. em bestimmten Kontext g l tig sein soll Dadurch dass der Kontext nun im Benutzerobjekt selbst verankert ist kann bei ei ner Autorisierungsanfrage zur Laufzeit ermittelt werden ob eine dynamische Einschr nkung vorliegt oder nicht Diese beiden Konzepte werden in Information 41 grafisch dargestellt Forschungsgruppe C amp M Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen 79 Dynamic SoD User Assignment User Assignment 1 1 Role Mapping System Role Business Role 1 C a 1 Policy Assignment Policy Assignment 1af 1 Business Policy Static SoD System Policy Information 41 Development of the BRBAC Role Model Separation of Duties Der hier eingefiihrte Ansatz sei durch ein Beispiel verdeutlicht das dem Bankenwesen entliehen ist wo klassischerweise sehr starke Einschr nkungen vorherrschen Dazu nehme man an dass die Rolle Schalterangestellter sowohl Kredite bewilligen als auch die Auszahlung von Kredi ten anweisen darf Zus tzlich sei eine Beschr nkung definiert um zu verhindern dass ein An gestellter in dieser Rolle einen Kredit bewilligt und die Auszahlungsanweisung selbst vor nimmt Damit solle etwa verhindert werden dass Kredite voreilig vergeben werden oder ein Angestellter sich selbst einen Kredit bewilligt Um diesen Sachverhalt formal zu fassen werden zun chst zwei Policys modelliert die diese beiden Rechte verk rpern und mit der Rolle Schal te
152. em hat Sie wird in ein PMI mit X 509 Zertifikaten implementiert und hinter die Schnittstelle zum Zertifikatsserver f r Attribute der f r X 509 ben tigt wird versteckt N2 RolePartner stellt die Hierarchie in den Mittelpunkt und kann mit den Prinzipen der Ein schr nkungen engl constraints und SoD umgehen Offene Fragen Welche Fragen sind noch ungel st geblieben bzw stellen sich dem Leser Ol Es bleibt unklar ob RolePartner alle drei Arten des role engineering top down bottom up middle out unterst tzt Forschungsgruppe C amp M Anhang 165 O2 Wie bringt RolePartner die Sicherheitsadministration und die Systemadministration zu sammen wo einerseits Sicherheits Policys und andererseits die Verwaltung von Informations systemen im Vordergrund stehen 03 Wieso genau vier Admin Rollen 04 Wieso verwendet RolePartner trotz der Aufteilung in vier diskrete Administratorrollen dann zus tzlich noch einen Super Admin O5 Was genau versteht RolePartner unter dem Begriff Hierachie Ist damit lediglich eine hierarchische Struktur gemeint oder auch eine explizite Vererbung von Rechten innerhalb der Hierarchie K nnen Benutzerrechte vererbt werden 06 Insgesamt bietet RolePartner nur vier Funktionen Das Verwalten von Benutzer Rollen Relationen und Rollen Berechtigung Relationen Existiert die M glichkeit von Berichten engl reports 07 RolePartner ist durch seinen Fokus auf eine zentralisierte Verwaltun
153. emrollen sowie mehrere Systeme und steht somit in direktem Zusammenhang zur Problem beschreibung und der Skizze aus Kapitel 1 2 Organizational Layer FJed consult Jed serv Security Consultant ed consult Service Manager ed serv General Manager c amp m Remote Course Participant i2s ed tec Software IT Management Infrastructure Jed soft Trainer c amp m Course Participant i2s Server side Client side Infrastructure Web Client Infrastructure Software Developer ed soft Internet ed tec Software Adapted from C amp M A BA page 10 Information 2 Introduction Business Model in the IST Scenario Das Szenario Internet Supported Training IST wird in Information 2 dargestellt Es schildert die Situation eines Anbieters computergest tzter Schulungen cooperation amp more c amp m Bei c amp m k nnen Kursteilnehmer sowohl per Fernzugriff aber auch vor Ort an Schulungen teilneh men Die Netzwerkinfrastruktur von c amp m ist dabei aufgeteilt in Arbeitsrechner innerhalb der eigenen Infrastruktur und Serversysteme die extern verwaltet werden Das Szenario besteht aus f nf Unternehmen mit unterschiedlichen Gesch ftsrollen die ihrerseits mehrere Mitarbeiter rep r sentieren Die Kompetenz des Unternehmens c amp m stellt das Angebot von Schulungen dar und so werden die Anwendungsserver vom IT Dienstleister ed serv education services zur Verf gung gestellt Die Pflege dieser S
154. en Wie Information 39 verdeutlicht besteht eine Systemrolle aus mindestens einer System Policy als inh rentem Bestandteil so dass die Begriffe System Policy und Systemrolle an dieser Stelle quivalent verwendet werden k nnen Die Vorteile die in BRBAC aus der expliziten Trennung der Rollenbegriffe entsteht wird in den Kapiteln 7 2 2 und 7 2 3 anhand des IST Szenarios belegt Da die Systemrollen mit den technischen Endsystemen in unmittelbarer Beziehung stehen wird im Folgenden jeweils ein Endsystem und dessen Zweck im IST Szenario eingef hrt und anschlie end die darin enthalte nen Systemrollen beschrieben Das Unternehmen c amp m verf gt ber einen Verzeichnisdienst in dem alle Benutzerkonten ange legt sind die innerhalb von c amp m Zugriff auf die Endsysteme ben tigen Als Technologie wird in diesem Szenario Microsoft Active Directory eingesetzt ein LDAP konformer Verzeichnis dienst auf Basis des Windows Server 2003 Betriebssystems In diesem Verzeichnis sind neben den Benutzerkonten der Mitarbeiter von c amp m auch Benutzerkonten f r das Unternehmen 12s ed consult und ed serv angelegt um den Beteiligten den Zugriff zu erm glichen der von ihnen ben tigt wird Die computergest tzten Schulungen von c amp m werden in Form der Intranet L sung ed tec angeboten einem Content Management System f r Schulungen engl course management system welches ber eine eigene Berechtigungsstruktur verf gt und in Seiten an geordnet ist um
155. en Zugriffskontrollarchitektur hervorhebt Im constrained RBAC Modell werden zwei unterschied lichen Auspr gungen von SoD modelliert auf die im Folgenden detailliert eingegangen wird Dabei handelt es sich um statisches SoD zur Definition des wechselseitigen Ausschlusses von Rollen und dynamisches SoD das diesen Ausschluss im gleichen Kontext betrachtet Der NIST RBAC Standard definiert zur Spezifikation von constraints zwei eigene Rollenmo delle Das constrained RBAC Modell schlie t die Verwendung von Hierarchien explizit aus w hrend hierarchical RBAC with constraints beide Erweiterungen in einem Rollenmodell spe zifiziert Der Zusammenhang zwischen diesen vier Rollenmodellen aus NIST RBAC ist in In formation 7 aufgezeigt Da RBAC Modelle die keine Hierarchien aufweisen sowohl in der Praxis als auch bei den weiteren Betrachtungen in dieser Arbeit nicht von Bedeutung sind wird das Modell constrained RBAC nicht explizit betrachtet Stattdessen soll der Fokus auf dem m chtigsten dieser vier Modelle liegen dem Modell hierarchical RBAC with constraints Im Folgenden werden nun zun chst die beiden Typen von SoD eingef hrt wie sie in diesem Mo dell definiert sind und anschlie end auf die funktionale Spezifikation dieses Modells eingegan gen Forschungsgruppe C amp M 20 Grundlagen lisson D Role Hierarchy Permissions User Assignment Permission Assignment Operations Objects user_session session_roles Session
156. en Prozess zur Herausarbeitung von Rollen aus den bestehenden Daten des Unternehmens an Hierbei werden Zusammenh nge zwischen Zugriffsberechtigun gen unterschiedlicher Benutzer hergestellt und analysiert um eine m glichst gro e Schnittmen ge zu generieren und daraus schlie lich Rollen abzuleiten Die gemeinsamen Berechtigungen werden in den Rollen dabei in Form von Policys gekapselt was dem Begriff der Systemrolle in dieser Arbeit entspricht Dieser gesamte Prozess basiert in SRM auf der Anwendung von role mining Algorithmen wie bereits in Kapitel 3 1 1 erw hnt wurde Die Daten auf denen sie ope rieren werden vorab in Einzelschritten vom Anwender ausgew hlt Der gesamte Prozess ist in Information 32 dargestellt und zeigt die einzelnen Aktivit ten vom initialen Ausw hlen der At tribute bis zur Speicherung neuer Rollen Um bei der Anwendung der role mining Algorithmen ein m glichst gutes Ergebnis zu erhalten ist es wichtig den Datenbestand des identity warehouse vor dem Suchlauf des Algorithmus auf den jeweils wesentlichen Ausschnitt einzu schr nken Dazu w hlt man f r jedes einzelne Unternehmenssystem das im speziellen Fall von Interesse ist eine Menge von Attributen aus auf denen der Algorithmus operieren soll An schlie end sollte die Menge der zu untersuchenden Benutzer eingeschr nkt werden Hier bietet SRM die M glichkeit Benutzer nach der Zugeh rigkeit zu einer Gesch ftseinheit zu einem Unternehmenssystem zu einer berei
157. en definierten Teilziele ist notwendig um Abweichungen vom Vorgehen oder geplante nderungen m glichst zeitnah zu erkennen Wie bereits erw hnt wur de kommt es in dieser Phase praktisch fortlaufend zu nderungen weil sich am Unterneh mensdatenbestand wie etwa der Rollenzuordnungen den Benutzern oder den technischen Be rechtigungen sehr h ufig nderungen ergeben Das k nnen etwa neue Mitarbeiter sein die in das Unternehmen eintreten oder durch eine nderung ihrer Position ber andere Rechte verf Forschungsgruppe C amp M 106 Entwicklung eines Vorgehensmodells fiir die rollenbasierte Zugriffskontrolle gen Die gemischte Riickkopplung die f r einen R cksprung in die Analyse aber auch die Entwurfsphase steht beschreibt eine besondere Form der Riickkopplung und tritt auf wenn sich an den zugrundeliegenden technischen Systemen Anderungen ergeben Hierbei muss analysiert werden welche nderungen auf gesch ftlicher insbesondere aber auf technischer Ebene anfal len Da dies ein sehr relevanter Aspekt f r die Praxis darstellt bietet er sich f r weitere Unter suchungen im BRBAC Kontext an 5 6 Res mee In diesem Kapitel wurde ein Vorgehensmodell entwickelt welches sich auf das Rollenmodell BRBAC st tzt was in Kapitel 4 entwickelt wurde Dazu wurden vier Prozessphasen definiert die vom klassischen Software Entwicklungszyklus entliehen sind Das Vorgehen kombiniert das top down und bottom up V orgehen zu einem hybride
158. en kann Forschungsgruppe C amp M AA Stand der Technik welche Bereiche in ihnen dargestellt werden Am Ende dieses Uberblickskapitels wird in Infor mation 20 die Liste der vordefinierten Ansicht dargestellt Die letzten beiden Komponenten ser vice level agreements und key performance indicators dienen zur Messung der workflows Hier bei k nnen klare Zeitgrenzen f r die Durchf hrung einzelner Prozessschritte aber auch Ma nahmen definiert werden die im Fall von berschreitungen der Indikatorwerte ergriffen werden sollen In der vorliegenden Version des Omada Identity Manager wird ein Authentifizierungsmodul f r die Produkte SiteMinder der Firma CA und Tivoli Access Manager der Firma IBM angeboten Beides sind kommerzielle Zugriffskontrollsysteme die durch das Modul authentication des zur integrierten Authentifizierung verwendet werden k nnen Zus tzlich dazu kann die Bedienober fl che des Omada Identity Manager durch die Komponente multi language sehr leicht lokali siert und somit an die Sprachen der Benutzer des Systems angepasst werden Authentication und multi lanuguage sind der Vollst ndigkeit halber in Information 18 aufgef hrt werden im Fort gang dieses Kapitels aber nicht weiter betrachtet weil sie au erhalb des Kerns dieser Arbeit lie gen Dies beendet die bersicht ber die Aufgabenbereiche und Komponenten des OIM Um das berblickskapitel zu vervollst ndigen wird nun zun chst auf die Datentypen im Kontext der
159. enario ueneennnnen 128 1 2 4 Betriebsphase von BRBAC im Sun Role Manager ur2u2s0esnneenneennernnnnnnn 129 TES Res mee e ee aa eee Roe NER Ee aC vandoeetdseamaasusdecevsceeveauiaas 131 8 Zusammenfassung und Ausblick 133 8 1 Eigebnissedieser Arbeit 22 u 20 200 2 1 08ER alla len 133 8 2 Ausblick auf zuk nftige Forschungsarbeiten 2u 2220222002200200ensennensnensnensnennnennneenn 135 Anhang 138 A Installation und Konfiguration des Omada Identity Manager u 224 139 A l Installation der Basissysteme 22u02224220002000nsennnennensnennnnennnennnesnnernennnnnenn 139 A 2 Installation und Konfiguration von Omada Enterprise 141 A 3 Installation und Konfiguration von Omada Identity Manager 141 B Installation und Konfiguration des Sun Role Manager u2200220ursnesnnesnnesnneennennnn 143 Forschungsgruppe C amp M Inhaltsverzeichnis Vil mon B 1 Installation sisi 2a ea aha mantis ented laa be 143 B 2 K nfieur tion essen ici ea ee he oe a oe 145 Abbildungen aus dem IST Szenario 2u 2220022002000200ensennensnesnnesnnesnnesnnennennnnnnnnn 147 Abk rzungen 22 2 es ma HB Bi ene 149 Abbildungsverzeichnis 2 2 creme E 151 Literat rahalysen senoir e T A E EE GE E E a E E 153 F 1 Advanced Features for Enterprise Wide RBAC usuuessnessnesnnesnnennnennennnn 153 F 2 Vorgehen
160. ennung engl port angegeben werden unter der der Webser ver erreichbar sein soll Zum Abschluss der Installation ist es m glich ein automatisiertes In stallationsscript exportieren zu lassen um SRM mit dieser Konfiguration auf einem anderen Rechner zu installieren oder die Installation erst zu einem sp teren Zeitpunkt zu beginnen Der Installationsprozess endet mit der Generierung eines Datenbank Scripts das das Schema wel ches von SRM verwendet wird im SQL Server anlegt Damit ist die Installation des Rollenma nagementwerkzeugs Sun Role Manager zusammen mit den Serversystemen abgeschlossen auf denen es basiert B 2 Konfiguration Am Ende der Installationsphase wurde ein Datenbank Script generiert welches in der Server konsole des SQL Servers nun manuell ausgef hrt werden muss Innerhalb dieses Codest cks ist der Name der Datenbank sowie der f r den Zugriff zu verwendende Benutzer bereits explizit aufgef hrt Dabei ist zu beachten dass der Sun Role Manager in der vorliegenden Version nach einer Datenbank mit dem Namen rbacx und einem Benutzerkonto rbacxservice als Besitzer der Datenbank verlangt Die Datenbank wurde bereits bei der Installation angelegt der Benutzer muss jedoch manuell angelegt werden ehe die weiteren Konfigurationsschritte initiiert werden k nnen Das Datenbank Script wurde in folgendem Verzeichnis abgelegt lt SRM Installationsordner gt db Die Ausf hrung des Scripts geschieht direkt im
161. enord ner eingeordnet Anschlie end muss eine Verkn pfung zwischen diesen beiden Rollen herges tellt werden Dies geschieht dadurch dass die Systemrolle in die Liste der mit der Gesch ftsrol le verkn pften Rolle aufgenommen wird Dieser Teil des Arbeitsablaufs ist in Information 24 dargestellt 55 0IM Role Management Define Business Role Define System Role Define Mapping Child roles C amp M_SR_001 C amp M AD Group Ri Information 24 State of the Art Omada Identity Manager Role Management 1 Nachdem die Rollenstruktur aufgebaut wurde folgt die Einteilung der Benutzer in Gesch ftsrol len Dies geschieht im Allgemeinen nicht mehr in der Verantwortung des Rollenverantwortli chen sondern ist eher die Aufgabe eines Abteilungsleiters Es wird davon ausgegangen dass die entsprechenden Benutzerkonten zu diesem Zeitpunkt bereits im Verzeichnisdienst angelegt und OIM ber die Komponente connectivity zugef hrt wurden Ferner ist die Abteilungszuge h rigkeit des Benutzers beispielsweise durch die Personalabteilung bereits vorgegeben Der f r die Abteilung Verantwortliche bestimmt im Ansatz den OIM verfolgt die Einteilung des Be nutzers in Rollen und eine Organisationseinheit In der view des Abteilungsleiters wird der neue Benutzer daraufhin aufgef hrt Dies geschieht durch einen automatischen Arbeitsablauf engl workflow der in regelm igen Abst nden nach neuen oder ge nderten Daten in den Unterneh menssys
162. eparate Phasen vorgeschlagen die sich mit admi nistrativen Aufgaben eines Rollenmodells im produktiven Einsatz besch ftigen Die beiden letztgenannten Forschungsbeitr ge bildeten die Basis des in dieser Arbeit entwickelten Vorge hensmodells Nach der Betrachtung aktueller wissenschaftlicher Forschungsergebnisse wurden zwei Rollenmanagementwerkzeuge vorgestellt als Beleg aktueller Bet tigungen in der Industrie In analoger Weise wurde f r den Identity Manager der Firma Omada und den Role Manager der Firma Sun zun chst deren Architekturen und Datentypen vorgestellt und die Komponenten ge nannt ber die diese Werkzeuge verf gen Auf diese Weise wurde der Bezug hergestellt zu den typischen Aufgaben von Rollenmanagementwerkzeugen aus dem Grundlagenkapitel Nach die sem berblick folgte f r beide Werkzeuge dann eine detaillierte Vorstellung der einzelnen Ar beitsbereiche Den ersten zentralen Aspekt der vorliegenden Arbeit stellte die Entwicklung des Rollenmodells BRBAC engl business role based access control dar Durch diese Namensgebung kommt der Bezug zu praktischen Umsetzungen rollenbasierter Zugriffskontrollarchitekturen im Unterneh menskontext unmittelbar zum Ausdruck Wie Ke02 bereits belegt existieren gerade durch den starken Einsatz unterschiedlicher Technologien auf technischer Ebene in Unternehmen eine Vielzahl an Rollen und zumindest implizit unterschiedliche Rollentypen Diese Tatsache stellte Forschungsgruppe C amp M 1
163. er 3 4 Res mee In diesem Kapitel wurde der aktuelle Stand bei Rollenmodellen aus der Forschung und Rollen managementans tze aus dem Bereich der Technik beschrieben Forschungsgruppe C amp M Stand der Technik 67 Bei den wissenschaftlichen Arbeiten wurde zun chst ein Modell zur automatischen Entwick lung von Rollen vorgestellt welches Mechanismen aus dem data mining auf Rollen bertr gt Dieser Ansatz bietet sich an weil die Informationen die zu Rollen und Berechtigungen f hren in Datenbest nden vorhanden sind Wie aus Implementierungen hervorgeht l sst sich dadurch eine betr chtliche Verringerung der Zeit erreichen die zur Entwicklung von Rollen ben tigt wird Danach wurde ein Rollenmodell vorgestellt das Rollen f r die unternehmensweite Zu griffskontrolle modelliert Technische Umsetzungen dieses Rollenmodells f r Unternehmen ERBAC haben allerdings gezeigt dass dieses Modell zu einer Vielzahl von Rollen f hrt so dass Erweiterungen vorgeschlagen wurde um die Komplexit t von ERBAC in technischen Um setzungen zu verringern Diese Erweiterungen wurden ebenso dargestellt wie der Mehrwert der sich potentiell aus ihnen ergibt Ein weiteres Modell befasste sich mit dem Lebenszyklus von Rollen und definierte das Rollenmanagement als einen ganzheitlichen Prozess der Ver n derungen beachtet denen ein implementiertes Rollenmodell im Wirkbetrieb unterliegt Dazu wurde in Anlehnung an die klassische Software Entwicklung e
164. er Arbeitsbereich role management unsesesseseesensneenensneennnnnnennnnsnneenennnnennenn 47 3 2 4 Der Arbeitsbereich compliance 20000220sssseensnnennnensnnnnnsnnnnnnensnnnennnnennnn 50 3 2 5 Automatische Abl ufe und werkzeugunterst tzte Bewilligungen 53 3 3 Rollenbasierte Zugriffskontrolle im Sun Role Manager uennnennsensnnnen 53 3 3 1 Architektur Aufgabenbereiche und Datentypen des Sun Role Manager 54 3 3 2 Die Komponente identity Warehouse ueeuneenneesneennesnnnennnensnensnensnennnensonsne nennen 59 3 3 3 Die Arbeitsbereiche role engineering und role management een 59 3 3 4 Der Arbeitsbereich identity certification unucsenseeeerenseneenennnneennnnnnennennnneennnnnnnnnenn 63 3 3 5 Der Arbeitsbereich identity audit 0u022200222sssenesnseensnnnensnnennnnensnsnonnnnnnnnn 65 3 4 Res mee u n2 2m ernennen a A NTO ENTS BAS EEE 66 4 Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen 69 4 1 Anforderungen an das Rollenmodell 22 0220022002000nsennensneesnnesnnesnnesnnennennnnnnnnn 69 4 2 Trennung von Gesch fts und Systemsicht 2 2220022002s0ensennnensneesnnennnesnnesnnennnennnnnnnn 74 4 2 1 Modellierung von Gesch fts und Systemrollen 22222200200n sense 74 4 2 2 Modellierung von generischen Rollen 20 0 0 cece ecscceeececeeeceenaeceeaeeceeeeeeneeeeneeeene
165. er SRM in der vorlie genden Version nicht die M glichkeit diese Abl ufe regelm ig laufen zu lassen sondern nur einmalig Benutzerfreundlichkeit Die Bedienbarkeit die zwar sehr individuell und somit subjektiv ist stellt trotzdem einen sehr wichtigen Aspekt eines Rollenmanagementwerkzeugs dar Es l sst sich feststellen dass die Ei narbeitungszeit f r den Role Manager sehr hoch ist Einerseits liegt das an der Struktur der gra fischen Bedienoberfl che die nur auf der ersten Ebene sehr klar gegliedert ist Hier wird klar unterschieden zwischen den Komponenten die der SRM bereitstellt Innerhalb dieser Kompo nenten ist die Aufteilung der Arbeiten nicht so bersichtlich gegliedert Andererseits liegt das an den missverst ndlichen Begrifflichkeiten So existieren etwa in den verschiedenen Aufgabenbe reichen unterschiedliche Auffassungen des Begriffs Policy Im Allgemeinen ist damit eine Systemrolle gemeint Im Falle von Zertifizierungen beschreibt eine Policy hingegen eine Attri butmenge die als Muster f r Zugriffsverletzungen dient um so Regelverletzungen zu erkennen Forschungsgruppe C amp M Analyse aktueller Rollenmanagementwerkzeuge 119 Kommunikation zu den Endsystemen SRM ist in der Standardinstallation ein nicht invasives Rollenmanagementwerkzeug Das be deutet dass es keine direkte Integration mit den bestehenden Unternehmenssystemen gibt Stattdessen m ssen die Daten aus den Unternehmenssystemen in regelm
166. eren Verlauf dieser Arbeit wird dann eines dieser Werkzeuge ausgew hlt und darin die in den Kapitel 4 und 5 entwickelten Modelle zur Forschungsgruppe C amp M Entwicklung eines Vorgehensmodells fiir die rollenbasierte Zugriffskontrolle 107 Ausf hrung gebracht Die Bewertung sowie die Entwicklung eines Bewertungskatalogs sind Bestandteil des folgenden Kapitels Forschungsgruppe C amp M Analyse aktueller Rollenmanagementwerkzeuge 109 6 ANALYSE AKTUELLER ROLLENMANAGEMENT WERKZEUGE Nachdem in Kapitel 4 mit BRBAC ein Rollenmodell fiir die rollenbasierte Zugriffskontrolle vorgestellt wurde die den Anforderungen aus der Gesch ftswelt sowie der Wissenschaft glei cherma en gerecht werden soll und in Kapitel 5 ein Vorgehensmodell definiert wurde um BRBAC im Wirkbetrieb erfolgreich umzusetzen wird in diesem Kapitel nun eine Bewertung aktueller kommerzieller Werkzeuge aus dem Bereich des Rollenmanagements vorgenommen Im Bezug auf das Vorgehensmodell findet diese T tigkeit engl product selection w hrend der Analysephase statt mit dem Ziel ein Werkzeug auszuw hlen was im gegebenen Kontext am Besten geeignet ist Dies wird in Information 47 grafisch verdeutlicht Zur Produktauswahl wird nun zun chst ein Kriterienkatalog entwickelt und dieser im weiteren Verlauf des Kapitels auf zwei kommerzielle Werkzeuge angewandt In einem Industrieprojekt welches BRBAC auf der Basis des Vorgehensmodells in einem Unternehmen umsetzt k men mit S
167. erhaft einzuhalten Aus diesem Grund gibt es kein klar definierbares En de dieser Phase Die Bezeichnung Lebenszyklus die in Anforderung A angesprochen wird soll symbolisieren dass das Ende dieser Phase genau dann erreicht wird wenn das Rollenmo dell aus dem Wirkbetrieb entfernt wird oder durch eine planm ige nderung des Modells in eine der davor liegenden Phasen zur ckgesprungen wird Die Konsistenz der Daten soll dabei stets gewahrt bleiben Das Ende eines Rollenmodells kann etwa dann erreicht sein wenn eine andere Architektur als autorative Quelle f r die Zugriffskontrolle eingesetzt werden soll Das am Rollenbetrieb beteiligte Personal sowie die hierbei zu erledigenden Teilprozesse sind in In formation 50 dargestellt Gr nde f r R ckkopplungen Um nderung im Vorgehen m glichst direkt zu unterst tzen kann in den einzelnen Phasen in alle zeitlich davorliegenden Phasen zur ckgesprungen werden sobald die Fehlerquelle oder der Ansatzpunkt der nderung identifiziert wurde Dabei wird stets in die Phase zur ckgesprungen die vor der Phase liegt in der die nderung hervorgerufen wurde Die einzige Phase die eine R ckkopplung auf sich selbst aufweist ist die hier definierte Wartungsphase wodurch ausged r ckt werden soll dass sie einen fortw hrenden Prozess beschreibt der nur bei geplanten nde rungen am Rollenmodell oder dessen Terminierung verlassen wird Eine kurze Taktung bei der berpr fung der in den Phas
168. erkzeugen vorgestellt Beide L sungen befassen sich mit der rollenbasierten Zugriffskontrolle und sind speziell f r den Einsatz in verteilten Informationssys temen konzipiert worden 3 2 Rollenbasierte Zugriffskontrolle im Omada Identity Mana ger Der Identity Manager der Firma Omada OIM ist ein relativ junges Produkt im Rollenmana gement Die Firma Omada wurde 1999 gegr ndet und gibt einige erfolgreiche Projektumset zungen auf Basis des OIM seit dem Jahre 2006 an OIM basiert auf einer Provisionierungsplatt form der Firma Microsoft und dient als Verwaltungswerkzeug f r die rollenbasierte Zugriffskontrolle in Umgebungen die komplett auf Technologien der Firmen Microsoft und Forschungsgruppe C amp M Stand der Technik 41 SAP aufbauen Omada verweist auf ber 50 Kunden unterschiedlicher Gr e die die rollenba sierte Zugriffskontrolle engl role based access control RBAC mithilfe des Omada Identity Manager produktiv einsetzen Ka07b Der Fokus von OIM in der aktuellen Version 6 0 innerhalb des Rollenmanagements liegt auf den Bereichen role management und compliance und besch ftigt sich somit mit der Verwaltung von Rollen auf der einen Seite und der Sicherstellung dass Policy Vorgaben eingehalten wer den auf der anderen Seite vgl Kapitel 2 3 Dabei protokolliert OIM nderungen an Rollenzu weisungen und bietet eine Oberfl che zur zentralen Verwaltung von Rollen an In diesem Kapi tel wird zun chst die Architektur des
169. ern das Entfernen oder ndern ber das gesamte Unternehmen betrach tet sehr h ufig passieren Dies sind administrative T tigkeiten die vom eingesetzten Rollenma nagementwerkzeug in automatischer Weise bzw von den technischen Fachabteilungen oder den Rollenverantwortlichen in manueller Weise durchgef hrt werden Die starke Einbeziehung und aktive Beteiligung dieses Personals in der Entwurfsphase stellt jedoch sicher dass sie ber die n tigen F higkeiten zur Erledigung dieser Aufgaben verf gen Rollenmodellanpassungen engl role model changes hingegen betreffen das Schema des Rollenmodells dessen Strukturen oder die darin definierte Abbildungen nderungen etwa an der Rollenstruktur oder den Hierarchien sind tiefgreifendere nderungen wie sie etwa beim Zusammenlegen von Abteilungen oder Zu k ufen von Firmen der Fall sind Es wird empfohlen an dieser Stelle die technischen Berater engl consultants einzubeziehen weil diese einerseits den bisherigen Prozess begleitet haben und dar ber hinaus ber das notwenige technische Wissen verf gen Der zweite Fall betrifft nderungen an den technischen Endsystemen selbst engl technical sys tem change etwa wenn Systeme aus der Verwaltung durch das Rollenmanagementwerkzeug ausgegliedert werden oder hinzukommen In diesem Fall der f r die Praxis auch sehr relevant ist ist es zun chst wichtig die nderungen zu formalisieren die sich aus einer Hinzunahme oder einem Entfernen von tec
170. ernals Code method assigns the manager to the approve activity Information 27 State of the Art Omada Identity Manager Workflow Designer Dies beendet den Einblick in das Rollenmanagementwerkzeug Omada Identity Manager Im folgenden Kapitel wird mit dem Role Manager der Firma Sun ein zweites Werkzeug pr sentiert welches im Gegensatz zum Omada Identity Manager schon l nger auf dem Markt pr sent ist und ber eine Komponente zur Entwicklung von Rollen verf gt Der role engineering Ansatz der im Sun Role Manager verfolgt wird ist das role mining welches in den Kapiteln 2 3 als ty pische Aufgabe von Rollenmanagementwerkzeugen und in Kapitel 3 1 1 als formales Modell bereits vorgestellt wurde 3 3 Rollenbasierte Zugriffskontrolle im Sun Role Manager Das Produkt Sun Role Manager SRM basiert auf dem Rollenmanagementwerkzeug RBACx der Firma Vaau Incorporated Sie wurde am 15 Februar 2008 von der Firma Sun Microsystems aufgekauft und RBACx wurde in Role Manager umbenannt um es in die Produktlinie Identity Management von Sun zu integrieren SunO8a Zu diesem Zeitpunkt geh rte die Firma Vaau Forschungsgruppe C amp M 54 Stand der Technik mit seinen 60 Angestellten bereits zu den f hrenden Anbietern von Rollenmanagementwerk zeugen Dies kann dadurch belegt werden dass Vaau ber eine langj hrige Erfahrung mit Kun den aus unterschiedlichen Branchen verf gt die RBACx produktiv einsetzen Ka07b
171. errschenden identit tsbasierten Zugriffskontrollarchitekturen der unterschiedliche Rechteum fang eines Benutzers gerade durch Identit ten voneinander getrennt Ein Benutzer hat somit bei der Ausf hrung unterschiedlicher Aufgaben heutzutage mehrere Benutzerkonten im selben Endsystem Dies l sst sich im identit tsbasierten Paradigma nicht anders l sen F 4 Observations on the Role Life Cycle KK 02 Axel Kern Martin Kuhlmann Observations on the Role Life Cycle in the Context of Enterprise Security Management Proceedings of the seventh ACM symposium on Access control models and technologies Monterey Ka lifornien USA Seiten 43 51 03 04 Juni 2002 Inhalte Was sind die zentralen Inhalte die in der Arbeit behandelt werden 11 In dieser Arbeit wird ein Lebenszyklus von Rollen vorgestellt angelehnt an den klassischen Software Entwicklungsprozess I Dabei wird untersucht wie sich diese Zyklen in ein theoretisches Rahmenwerk eingef gt werden k nnen um es Neueinsteigern leichter zu machen rollenbasierte Anwendungen zu ent wickeln 13 Die Autoren sind berzeugt dass der Lebenszyklus einer Rolle als Basis f r ein RBAC Rahmenwerk angesehen werden kann Sie liefern eine initiale Diskussion zu diesem Thema ba sierend auf den Erfahrungen aus dem Sicherheitsmanagement 14 Die Autoren stellen ein Lebenszyklus Modell vor das sich auf einen inkrementell iterativen Prozess st tzt bestehend aus den Phasen Analyse Entwu
172. ert werden dass der Prozess an einem vorher fest definierten Tag automatisch startet und den Verantwortlichen an die berpr fung erinnert Der zweite Zer tifizierungstyp role entitlement richtet sich an den Rollenverantwortlichen innerhalb des Unter nehmens Seine Aufgabe ist es den Umfang einer Rolle abzu ndern Dazu w hlt er zun chst ei ne Gesch ftseinheit aus und selektiert die zu betrachtenden Rollen Im Anschluss daran k nnen die Policys die in den Rollen gekapselt sind sowie alle Attribute innerhalb der Policys einzeln zertifiziert werden Der dritte Zertifizierungstyp application owner richtet sich an das Personal welches sich um die technische Pflege der Unternehmenssysteme k mmert und in diesem Sinne als Besitzer der Anwendungen angesehen werden kann Sie k nnen die konkreten Attributwerte f r die in den Policys definierten Attribute festlegen Insgesamt betrachtet zeigt sich hier wie SRM den technischen Wissenstand unterschiedlichen Personals unterst tzt W hrend sich user access certification mit der Verwaltung der Mitglieder von Gesch ftsrollen befasst verlangt ro le entitlement certification bereits technisches Detailwissen da hier die Verkn pfung von Ge sch fts und Systemrolle zum Tragen kommt Dies dr ckt sich in SRM in Form von Policys aus was als Systemrolle verstanden werden muss Diese kapseln technische Spezifika der Unter nehmenssysteme in sich als Attribut Application owner certification schlie lich definie
173. ert zur ck der dar ber Aussagen macht ob das zugreifende Subjekt im aktiven Kontext die gew nschte Operati on auf einem Objekt ausf hren darf oder nicht e Funktionen zur berarbeitung Diese Funktionen richten sich nicht an einen Benut zer der seine im aktiven Kontext vorhandenen Rollen beeinflussen will sondern an ei nen Administrator dem es m glich sein sollte alle aktuellen Zuweisungen zu berpr fen Diese Funktionen richten sich insbesondere an die Relationen UA und PA Da dies nicht von allen RBAC Implementierungen unterst tzt wird unterteilt der RBAC Standard diese Funktionen in zwingend ben tigte und optionale Funktionen Zwingend Z bzw optional O vorhanden sind folgende Funktionen o assignedUser Liefert die Menge an Benutzern zur ck die in eine be stimmte Rolle eingeteilt sind Z Forschungsgruppe C amp M 16 Grundlagen o assignedRoles Liefert die Menge an Rollen zur ck ber die ein bestimm ter Benutzer verfiigt Z o rolePermissions Liefert die Menge an Berechtigungen f r eine bestimm te Rolle zur ck O o userPermissions Liefert die Menge an Berechtigungen zur ck ber die ein Benutzer durch seine Rollenmitgliedschaften direkt oder transitiv verf gt O o sessionRoles Liefert die Teilmenge der in einem Sitzungskontext aktiven Rollen eines Benutzers zur ck O o sessionPermissions Liefert die Teilmenge der in einem Sitzungskontext aktiven Berechtigungen zur ck O o rol
174. erten Daten f r die rollenbasierte Zugriffskontrolle bezogen werden sollen An dieser Stelle sei erw hnt dass zun chst ein Testbetrieb des Werkzeugs f r eine ausgew hlte Abteilung angestrebt wird was bei der Spezifizierung der Verbindung zu den Endsystemen beachtet werden muss um den Gesamtdatenbestand durch den Testbetrieb nicht zu kompromittieren oder ungewollt zu ver ndern engl test implementation F r die Dauer der Testphase bleibt die bisher eingesetzte Zugriffskontrolle autoritativ w hrend BRBAC im Test betrieb lediglich Daten von dort bezieht und redundant vorh lt Auch ist ein Szenario denkbar in dem keine unternehmensweite Umstellung auf BRBAC sondern ein Parallelbetrieb mehrerer Zugriffskontrollarchitekturen angestrebt wird Nachdem das Werkzeug erfolgreich implementiert und die Kommunikationsbeziehung zu den Endsystemen umgesetzt wurde wird das Rollenmodell gem der Spezifikationen aus der Ent wurfsphase nun in den Wirkbetrieb berf hrt In der Entwurfsphase kamen bereits role mining Algorithmen zum Einsatz um die Spezifikation von Rollen zu unterst tzen Eine planm ige Einf hrung von Gesch fts und Systemrollen findet allerdings erst jetzt in der Implementie rungsphase statt was damit begr ndet werden kann dass erst nach Vervollst ndigung der Arte fakte das Gesamtbild des Unternehmens spezifiziert ist Zur vollst ndigen Einf hrung von BRBAC werden die Artefakte der Entwurfsphase mit den bisher erzeugten R
175. erten Modell aufgegriffen wird Dabei werden die Zugriffsrechte in Form von Attributen parametri siert Diese Erweiterung erm glicht die Verwendung sogenannter Platzhalter engl wildcards f r die Werte der Zugriffsberechtigungen in Attribut Wert Paaren Im Ge gensatz zu Ke02 bietet die hier vorgestellte L sung aber eine zus tzliche Vereinfa chung weil sie bei einer nderungen des Wertes keine nderung der Rollen oder deren Aktualisierung nach sich zieht Die Forderung nach wildcard Attributen kommt somit dem Ziel Z dieses Rollenmodells nach eine in der Implementierung m glichst effizien te Verwendung von Rolle zu erm glichen und logisch zusammenh ngende Aufgaben die sich lediglich im Berechtigungsumfang unterscheiden nicht explizit trennen zu m ssen e Anforderung A Automatisierte Rollenmitgliedschaften In Anlehnung an die Jo ker Berechtigungen aus Kapitel 3 1 3 werden in dem hier vorgestellten Rollenmodell BRBAC dynamische Rollenmitgliedschaften eingef hrt Im Gegensatz zu den Joker Berechtigungen wird mit den automatisierten Rollenmitgliedschaften keine Beschr n kung auf den Relationen Benutzer Rolle und Rolle Joker Berechtigung bezeichnet son dern lediglich auf der Relation Benutzer Rolle Auch wird bei Joker Berechtigungen vorausgesetzt dass die Syntax des Joker Attributs im Benutzerobjekt der Namenskon vention entspricht und mit der Syntax in den zugrundeliegenden technischen Systemen bereinstimmt Dies stel
176. erung von Gesch fts und Systemrollen gleichzeitig geschehen Im Folgenden wird nun zun chst auf die Aktionen in der Entwurfsphase eingegangen anschlie end auf das Ziel der Entwurfsphase und abschlie end auf die Verantwortlichkeiten sowie m gliche Gr nde f r R ckkopplung in die Analysephase Vorgehen in der Entwurfsphase Zun chst wird die Anforderungsspezifikation die im Lastenheft formalisiert ist auf gesch ftli cher und technischer Ebene verfeinert Diese Aufteilung verringert die Komplexit t in diesen beiden Bereichen und fokussiert f r jeden Bereich auf den hierf r wesentlichen Ausschnitt des Unternehmens Auf gesch ftlicher Ebene steht somit im Mittelpunkt f r die bisher formalisier ten Abteilungen und Gesch ftsprozesse Gesch ftsrollen zu definieren und eine Hierarchie zu erfassen engl business role design Dieser Teil des hybriden Vorgehens setzt die in der Ana lysephase begonnene top down Modellierung fort da ausgehend von den allgemein gehaltenen Strukturen schrittweise verfeinert wird In der technischen Spezifikation wird hingegen das bor tom up Vorgehen aus der ersten Phase fortgef hrt weil die in der Analysephase vorhandenen technischen Berechtigungen nun zu Systemrollen zusammengefasst werden sollen engl system role design An dieser Stelle ist eine Werkzeugunterst tzung in Form von role mining Algorithmen von Vorteil da mit deren Hilfe aus dem Datenbestand des Unternehmens Rollen automatisiert abgeleitet
177. erw hnten Regeln engl rules die aus einer Menge von Attribut Wert Paaren bestehen und somit konkrete Bedingungen darstellen Mehrere Regeln k nnen in einer berwachungs Policy zusammengefasst und durch logische Operatoren in Beziehung zueinan der gesetzt werden Anschlie end wird eine Person bestimmt die im Falle eines Versto es ge gen die definierte Bedingung informiert wird Zu diesem Zeitpunkt ist die Policy korrekt defi niert und aktiv Sie reagiert im Falle einer Verletzung und wendet sich in diesem Fall an die in der Policy definierte verantwortliche Person Dar ber hinaus l sst sich in einer Policy ein be stimmter Zeitpunkt angeben an dem sie aktiv werden soll um auf das identity warehouse zuzug reifen und den Datenbestand bzw die spezifizierte Gesch ftseinheit zu analysieren Die berwachung beginnt dabei bei der initialen Definition setzt sich mit der berpr fung nach Verletzungen fort und endet mit dem Auftreten der Verletzung und deren Behandlung Bei der Behandlung hat man in SRM durch einen menschlichen Akteur die M glichkeit die Verlet zung zu ignorieren sie zu behandeln oder an einen anderen Verantwortlichen weiterzuleiten Dabei werden alle Vorkommnisse protokolliert so dass die erfolgten Behandlungen zu einem sp teren Zeitpunkt nochmals eingesehen und ausgewertet werden k nnen Die dabei protokol lierten Daten umfassen sowohl das Datum der Verletzung also auch das Datum der Fehlerbe handlung und den Bearbeit
178. es 75 4 2 3 Modellierung von wechselseitigem Ausschluss bei Rollen uue 78 4 3 Modellierung von Policy Erweiterungen 22u022susssuensensnnsnennensnoennnennnennnesnnennnennnnnen 80 4 3 1 Modellierung von Policys mit Platzhaltern u0220022002 seen enneenneenennnn 80 Forschungsgruppe C amp M vi Inhaltsverzeichnis 4 3 2 Modellierung der Rechtevererbung 0 0 eee eeeeeeceseeeeeeeeneeeseeeseecaeeceaeceaecnaeenaeens 82 4 3 3 Automatisierte Rollenmitgliedschaften auf der Basis von Policys 84 ATA Gesamtmodell a ten tert stetebescedhe veh KEON EEES AOTER e eel AEE E Tenan eaaet 87 5 Entwicklung eines Vorgehensmodells f r die rollenbasierte Zugriffskontrolle 91 5 1 Zieldefinition und Festlegung der Anforderungen 0 ee eeeeceeeseeeseeeneeeeeeaecnaeenseenaeens 91 5 2 Analyseph se u u 2 2 22 ek Ma EE eats Se teal 94 9 3 AENLWULISPHASE een eea see sale ae dea E lute ERE O RE cele Cacia Modes 97 3 4 Implementierungsphase 32 2 222 282220 bodes i a ERRLEHT en 100 3 9 Beiriebsphase n nu Ra Renee 103 DO lS E A A AT 106 Analyse aktueller Rollenmanagementwerkzeuge 109 6 1 Entwicklung eines Kriterienkatalog seeeeeseeeeeseereesesreesesressesrrsseesirstesresteserreeseseresrentesee 109 6 1 1 Motivation d s Katalog8 nn a aa a ee Ea E E EEEE k 109 6 1 2 Spezifikation der Kriterien 0r20ussseesnsessnsnnn
179. es als Nebeneffekt an dieser Stelle m glich Inkonsistenzen des Datenbestands zu erkennen und zu beheben die bei verteilten Daten vorhanden sein k nnen wie KS 03 belegt Nachdem die Auswahl und Sondierung des Datenbestands abgeschlossen ist folgt in Stufe zwei die Vorbereitung der Daten engl data preparation Nachdem ein als passend erachteter Aus schnitt des Datenbestands gew hlt und eventuell anfallende Korrekturen bew ltigt sind m ssen diese Daten in ein Format transformiert werden welches von der zum role mining verwendeten Software lesbar ist Die Autoren aus KS 03 verwenden hierf r den IBM Intelligent Miner for Data und im Speziellen die Funktion demographic clustering F r ein vertiefendes Studium von clustering Algorithmen sei verwiesen auf GRO2 In der dritten Phase liegt der Fokus auf einer berpr fung der Datenauswahl ehe sie den bereits erw hnten Prozessen Assoziation und Clus terbildung bergeben wird Dies ist der Inhalt der n chsten Phase Ziel bei dieser berpr fung ist es ein Gef hl f r die Daten sowie das zu erwartende Rollenschema zu bekommen engl ex ploration and learning Initial Kann dabei ganz ohne eine Attributauswahl begonnen werden um aus dem ersten Analyselauf ein Verst ndnis f r die Attribute zu bekommen die miteinbezo gen werden sollen und diese danach ausgew hlt werden Im Anschluss an die Attributauswahl kann der Fokus auf die Attributwerte gelegt werden da diese zur Clusterbildung anal
180. esen Fall ver f gen die Mitarbeiter von i2s ber Benutzerkonten in der Umgebung von c amp m um sich an dort zur Verf gung gestellten Rechnerarbeitspl tzen anmelden zu k nnen Die IT Infrastruktur von c amp m ist dabei unterteilt in Client Rechner die von c amp m selbst verwaltet werden und Serversys teme die vom IT Dienstleister education services ed serv gepflegt werden Da die Pflege der IT Landschaft weder die Kernkompetenz von c amp m noch von ed serv ist ist c amp m seinerseits Kunde des Consulting Unternehmens education consulting ed consult das c amp m bei der Kon solidierung seiner Unternehmens IT unterst tzt Information 54 zeigt eine bersicht ber die am IST Szenario beteiligten Unternehmen Forschungsgruppe C amp M 122 Fallstudie zur Anwendung der Modelle in einem kommerziellen Produkt Organizational Layer Jed consult Jed serv EJ c amp m Security Consultant ed consult Service Manager ed serv General Manager c amp m Remote Course Participant i2s IT Management ed tec Software f Infrastructure CJed soft Trainer c amp m Course Participant i2s Server side Client side Infrastructure Web Client Infrastructure Software Developer ed soft Internet ed tec Software Adapted from C amp M A BA page 10 Information 54 Case Study Introduction to IST scenario 7 1 1 Vorstellung der Geschaftsrollen In diesem Teilkapitel werden die Gesch
181. esentliche Voraussetzung bei der Einhaltung von Policys ist dass die zugrunde liegende Datenstruktur konsistent ist Wird auf einem inkonsistenten Da tenbestand operiert macht die Frage nach der Einhaltung von Policy Vorgaben kein Sinn weil die Vorgaben aufgrund von Inkonsistenzen nicht gew hrleistet werden k nnen Aus diesem Grund muss sichergestellt werden k nnen dass das Rollenmanagementwerkzeug ein Konsisten tes Gesamtbild des Unternehmens besitzt und beibeh lt Werden nun nderungen in einem der Endsystemen direkt vorgenommen anstatt im Omada Identity Manager werden diese nde rungen erkannt und entsprechende Mechanismen eingeleitet wie etwa das R ckg ngigmachen dieser nderungen und das Informieren eines Systemverantwortlichen ber die unbefugte n derung Hierbei m ssen dem Omada Identity Manager allerdings die zu berwachenden Attri bute bekannt sein was in den Aufgabenbereich connectivity f llt da das Werkzeug die Ande rungen sonst nicht erkennen und entsprechende Ma nahmen ergreifen Kann Eine weitere Komponente in OIM befasst sich mit nderungen von Zugriffsrechten bei Benutzern und ber wacht dabei speziell die Eigenschaften der Benutzer im Verzeichnisdienst Sie wird aus diesem Grund als identity reconciliation bezeichnet Durch diese Komponente wird die Konsistenz der Benutzerprofile gew hrleistet die sowohl im Unternehmensverzeichnisdienst als auch im Me taverzeichnis des OIM vorgehalten werden Das Prinzi
182. et die Einf hrung in die vier Komponenten des NIST RBAC Standards In den ver gangenen beiden Kapiteln 2 1 und 2 2 wurden die Grundlagen f r die rollenbasierte Zugriffs kontrolle RBAC gelegt Dies bildet die Basis f r die Entwicklung eines eigenen Rollenmo dells in Kapitel 4 Da ein wesentlicher Teil dieser Arbeit den Bezug zu technischen Umsetzungen von RBAC in Form von kommerziellen Sicherheitsprodukten herstellt ist es an dieser Stelle n tig die Grundlagen f r diese sogenannten Rollenmanagementwerkzeuge zu legen Im letzten Teilkapitel werden daher nun typische Arbeitsaufgaben und Funktionen dieser Werkzeuge betrachtet 2 3 Aufgaben von Rollenmanagementwerkzeugen Die zentralen Aufgaben des Rollenmanagements sind das Definieren Zuweisen und Pflegen der Beziehungen von Benutzern und Gesch ftsrollen Gesch fts und Systemrollen sowie System rollen und Ressourcen Insbesondere zwei dieser drei Beziehungen sind dabei problematisch Wie bereits in Kapitel 1 angesprochen wurde ist die Beziehung zwischen Benutzern und Ge sch ftsrollen deshalb schwierig umzusetzen weil hierzu sowohl die Struktur des Unternehmens als auch dessen operative Gesch ftsprozesse bekannt sein m ssen Bei der Beziehung von Ge sch fts und Systemrollen besteht die Problematik in der gro en Zahl an Systemrollen Diese Komplexit t soll werkzeuggest tzt reduziert werden In den letzten Jahren haben sich daher Werkzeuge zur Verwaltung von Rollen auf dem Mark
183. etails My Requests My Certifications User Id rbackadmin First Name admin s Last Name admin eo 3 Email admin rbacx com 40 2 My Settings m A TF oa o y Proxy Assignments Workflow Requests App Owner User Role Pending Requests m Completed Requests New In Progress Complete o to Pending 0 Completed 75 h Go to New 6 In Progress 0 Completed 3 Business Unit Users Certify Revoke Statistics Identity Audit Policy Violations m Training Participants i2s m Training Participants c amp m c amp m i2s 30 m Accounting Department c amp m e m Management Department c amp m 2 m Marketing Department c amp m 10 IT Department ed sery oles 08 o m IT Department c amp m m Certified Roles m Revoked Roles pen Closed Clos m Public Relations Department i2s m Certified Accounts Revoked Accounts High m Medium Low Clos Open 36 Closed 0 Fixed 0 Risk Accepted 28 Information 58 Case Study Role Operation in Sun Role Manager Rollenverwaltung Dieser Arbeitsbereich umfasst s mtliche Aufgaben die im Zusam menhang mit Rollen auftreten Dies beginnt mit der Einteilung von Benutzern in Ge sch ftsrollen der Einteilung von System Policys in Systemrollen sowie der Zuweisung von Gesch fts zu Systemrollen In der bisherigen Schilderung der Fallstudie verf gt die Rolle Security Consultant ed consult ber administrative Rechte auf die Server und Client Systeme
184. f den role mining Prozess selbst Um diesen Ansatz einordnen zu k nnen werden zum Abschluss Erfahrungswerte genannt die aus dem praktischen Einsatz von role mining stammen Will man Daten aufbereiten um daraus Rollen ableiten zu k nnen muss dieser teilweise sehr umfangreiche Gesamtdatenbestand zun chst auf einen der individuellen Situation angemesse nen Ausschnitt beschr nkt werden Weil die Daten aus unterschiedlichen Quellen stammen k nnen ist es ist somit zun chst n tig eine Vereinigungsmenge aus diesen Daten zu erstellen und diese anschlie end einzugrenzen Die data mining Techniken die als Basis des role mining eingesetzt werden lauten Assoziation engl association und Clusterbildung engl clustering KS 03 Mit Hilfe der Assoziationsalgorithmen ist es m glich Muster in den Datenbest nden zu erkennen wie etwa welche Elemente oftmals in Kombination auftreten Zus tzlich zu den hieraus gebildeten Mengen k nnen Regeln abgeleitet werden die Aussagen ber die Wahr scheinlichkeit des gemeinsamen Auftretens machen Die zweite Technik der Clusterbildung operiert nun auf diesen Objekten und versucht Elemente zu gruppieren die ber die gleichen Attribute verf gen Durch ein iteratives Anwenden dieser Algorithmen mit unterschiedlichen Datens tzen und variierenden Parameterwerten wird der Ergebnisdatensatz schrittweise verfei nert Forschungsgruppe C amp M 30 Stand der Technik Die Information die zur Definition von
185. figure Views Forschungsgruppe C amp M Anhang 143 B Installation und Konfiguration des Sun Role Manager Dieses Kapitel beschreibt die Installation und Konfiguration des Sun Role Manager SRM Dieses Rollenmanagementwerkzeug wurde in Kapitel 3 3 detailliert beschrieben und in Kapitel 6 3 anhand eines Kriterienkatalogs bewertet Die Informationen stammen dabei aus dem Instal lationshandbuch und dem Benutzerhandbuch Vaau07a Vaau07b B 1 Installation SRM ist eine J2EE Anwendung und ben tigt neben einem Datenbankserver f r die Datenhal tung einen Anwendungsserver f r die Fachfunktionalit t der Anwendung sowie einen Webser ver um diese bedienbar zu machen Diese drei Schichten sind in Information 62 veranschaulicht Tiers in SRM Fer Presentation Tier component Web Server Business Logic Tier component Application Server component Sun Role a Manager Data Tier component Database Server component Z Operating System Information 62 Appendix Tiers in Sun Role Manager Im Folgenden wird auf die drei Schichten eingegangen SRM unterstiitz hierbei eine Vielzahl unterschiedlicher Datenbank Anwendungs und Webserver In der vorliegenden Version 4 0 unterst tzt SRM folgende Datenbankserver e Microsoft SQL Server 2000 SP4 2005 e IBM DB2 8 2 9 x e Oracle 9i 10g 11 x Die unterstiitzten Anwendungsserver sind e Apache Tomcat 5 5 IBM WebSphere 5 x 6 x Weblogic JBo
186. ft auf ehe in den Kapiteln 3 2 und 3 3 auf kommerzielle Implementierungen eingegangen wird Bei diesen beiden Rollenmanagementwerkzeugen handelt es sich um den Identity Manager der Firma Omada und den Role Manager der Firma Sun Die beiden Kapitel sind in analoger Weise so aufgebaut dass zun chst ein Gesamtbild der Architekturen und Einzelkomponenten gegeben wird Daran schlie t sich eine genauere Betrachtung jedes dieser Komponenten an wobei auch darauf geachtet wird eine Verbindung zu den typischen Aufgaben von Rollenmanagement werkzeugen aus Kapitel 2 3 herzustellen Das Ziel der beider Kapitel 3 2 und 3 3 ist es einen wertungsfreien berblick ber den aktuellen Stand in der Technik zu geben 3 1 Modelle f r die rollenbasierte Zugriffskontrolle 3 1 1 Modell zur Entwicklung von Rollen Ein Ansatz der mittlerweile sowohl in der Forschung als auch in der Technik an Beachtung gewinnt ist das role mining Dieser Kunstbegriff bezeichnet das Anwenden von Algorithmen zur Datengewinnung engl data mining um zu geeigneten Repr sentanten von Rollen zu ge langen Dieses Kapitel bezieht sich auf KS 03 in dem der role mining Ansatz n her beschrie ben wird Dabei wird in diesem Kapitel zun chst auf zwei allgemeine data mining Techniken eingegangen und diese anschlie end auf das role mining bertragen Beim role mining wird dann zun chst auf Aspekte bez glich des Datenbestands eingegangen die beachtet werden m ssen und anschlie end au
187. ft selbst einschr nken Policys werden dem nach f r Attribute der Unternehmenssysteme effektiv wohingegen Regeln die Benutzerattribute in SRM einschr nken die notwendig sind um einer Rolle zugewiesen werden zu k nnen Diese drei geschilderten Prozesse stehen im Sun Role Manager zur Verf gung um Gesch fts und Systemrollen zu definieren abzu ndern und miteinander in Verbindung zu bringen engl role engineering Im Folgenden werden die Aufgaben im Zusammenhang mit der Verwaltung von Rollen engl role management beschrieben Information 35 zeigt diese Aufgabenbereiche schematisch und setzt sie zueinander in Bezug Damit soll der Zusammenhang zur Komponen tenarchitektur aus Information 28 noch einmal verdeutlicht werden subsystem Role Management Role Versioning JRole Status CEO Versions Status Start Date val End Date Decomissioned Role Certifications Role Approvals _ Temporary Roles Temporary enhance Assignments enhance Role Lifecycle use realize enhance Role History _ Workflow Engine Created Certification Certified Certification By Status Name F rbacxadmin CERTIFIED Role Membership Workflow Role Creation Workflow Member Added Role Modification Workflow 03 14 2008 16 18 14 Information 35 State of the Art Sun Role Manager Role Management Ein zentraler Begriff im Rollenmanagement des SRM ist der Lebenszyklus von Rollen Dieser besch ftigt si
188. ftsrollen beschrieben die im IST Szenario vorkommen und die Beziehungen erl utert die zwischen Ihnen existieren Ausgehend von den Gesch ftsrol len des Unternehmens c amp m werden die Gesch ftsrollen der anderen am IST Szenario beteilig ten Unternehmen vorgestellt Information 54 zeigt bereits einige der Rollen auf jedoch werden f r diese Fallstudie zus tzliche Rollen definiert die in der Abbildung der bersichtlichkeit hal ber nicht aufgef hrt wurden e Der Schulungsanbieter c amp m Das Unternehmen c amp m wird vertreten durch die Unter nehmensleitung welche f r die Koordination der unterschiedlichen Abteilungen von c amp m zust ndig ist Dabei gibt es erstens die Abteilung Marketing mit der Gesch fts rolle Marketing Assistent die f r die Akquise neuer Kunden zust ndig ist Die zweite Abteilung Buchhaltung wird vertreten durch die Rolle Buchhaltungsassistent und k mmert sich um die Vertr ge mit den Kunden von c amp m und die Rechnungen an die Partner von c amp m Eine dritte Kompetenz der Buchhaltung ist die Verwaltung s mtli cher c amp m interner Vertr ge und Zahlungen Die dritte Abteilung IT Administration k mmert sich um die Pflege der Server und Client Computersysteme die sich in der Infrastruktur von c amp m befinden Die Administration verf gt ber die Gesch ftsrolle System Administrator und stehen in direktem Kontakt zu den Firmen ed serv sowie ed consult Eine vierte Abteilu
189. g von Sicherheits Policys eher f r Autorisierungsumgebungen mit starkem Bezug zu Sicherheits Policys geeignet Eine Dezentralisierung f r gro e Unternehmen w re daher w nschenswert was aber durch Ro lePartner nur in beschr nktem Ma e unterst tzt wird Einen m glichen Ansatz hierf r bietet Sandhu in SB 99 Auch w re es im Bezug auf zuk nftige RBAC Komponenten w nschens wert klar verst ndliche Einschr nkungen anzubieten Beispielsweise unterst tzt RolePartner statisches SoD und kann mit dynamischem SoD nicht umgehen 08 Kann man Begriffe wie Rolle in ein semantisch und syntaktisch so steifes Kost m zw ngen wie es RolePartner tut Ist es dann nicht schon zu steif um in unterschiedlichen Um gebungen individuell angepasst werden zu k nnen Forschungsgruppe C amp M 166 G Literatur Ba96 Ba98 Bun98 C amp M A BA C amp M A ID Di08 DMO8 Du06 EB 07 Ec05 Em08 FK 07 FS 01 Ga02 Anhang Helmut Balzert Lehrbuch der Software Technik Software Entwicklung Spektrum Akademischer Verlag 1996 Helmut Balzert Lehrbuch der Software Technik Software Management Software Qualitdtssicherung Unternehmensmodellierung Spektrum Aka demischer Verlag 1998 Deutscher Bundestag Gesetz zur Kontrolle und Transparenz im Unterneh mensbereich http www beckmannundnorda de kontrag html Webseite Stand 25 Mai 2008 Cooperation amp Management Advanced Web
190. ge messen ist und ausgeweitet werden muss Auch kann durch den Bericht analysiert werden wie sich geplante nderungen im Wirkbetrieb auswirken w rden und welche Verletzungen diese nderungen nach sich ziehen Da der Omada Identity Manager alle Ereignisse intern abspeichert bietet er f r jeden Benutzer die M glichkeit sich alle mit ihm verkn pften Ereignisse anzeigen zu lassen Somit k nnen die Benutzer auf dem aktuellen Stand gehalten werden was die Prozesse im Rollenmanagement angeht Diese Komponente kann sowohl den aktuellen Bearbeitungsstand anzeigen als auch Berichte aus der Vergangenheit darzustellen Dies erm glicht Verletzungen oder ge nderte Zu griffsmuster von Benutzern auch in der Vergangenheit aufzusp ren um die Rollenstruktur an die ge nderten Gegebenheiten anzupassen Um sich hier auch auf spezielle Ereignisse Zeitr u me oder andere Eigenschaften zu beschr nken l sst sich der Datenbestand vor der Berichters tellung filtern Forschungsgruppe C amp M 52 Stand der Technik Die Bedienoberfl che dieses Arbeitsbereichs als security administration console bezeichnet kombiniert die Statistiken zur Einhaltung von Policys mit Metriken zur Messung der Prozesse auf die zum Schluss eingegangen wird Sie stellt die zentrale Bedienoberfl che des OIM im Be zug auf compliance dar Neben den Statistiken zur Einhaltung von Policys bietet der Omada Identity Manager die M g lichkeit Zeitgrenzen bei der Durchf hrung
191. gen Da in technischen Implementierungen aufgrund ihrer system bergreifenden Architektur vom Sitzungskontext abstrahiert wird wird dieser heutzutage praktisch Forschungsgruppe C amp M 72 Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen nicht beachtet wie aus dem ERBAC Modell und seiner Erweiterung hervorgeht vgl Kapitel 3 1 2 und Kapitel 3 1 3 Es gibt hier also eine Diskrepanz zwischen Modellen aus der Wissenschaft und praktischen Umsetzungen in der Industrie Diese Arbeit schl gt eine M glichkeit vor dynamisches SoD ohne einen expliziten Sitzungskontext zu modellieren Ziel Z2 Policy bezogene Verringerung der Komplexit t von Rollen Anforderung A Vererbung von Rechten F r die hierarchischen Strukturen in de nen gr ere Einrichtungen heutzutage organisiert sind ist es wichtig dass sie in einem Rollenmodell geeignet abgebildet werden k nnen Dies ist heute sowohl in Modellen als auch in kommerziellen Produkten in angemessener Weise vorhanden wie die Kapi tel 2 und 3 belegen In BRBAC soll die Vererbung von Rechten modelliert werden was ber die Hierarchiebildung hinausgeht die sich in RBAC und ERBAC widerspiegelt Durch den hier verfolgten Ansatz werden auch feinere Steuerungsmechanismen f r die Vererbung von Rechten erm glicht Im Folgenden Absatz wird diese Anforderung mo tiviert Der Mechanismus der Vererbung geht ber die blo e Hierarchiebildung hinaus und er m glicht ei
192. gs damit eine Strategie zur Attributauswahl zu bestimmen Der Sun Role Manager bietet als Stra tegie einerseits die Auswertung aller Attribute in den Policys der selektierten Rollen an womit erreicht werden kann dass system bergreifende Policys entwickelt werden k nnen Anderer seits verfolgt die zweite Strategie bei der nur gewisse SRM internen Attribute zur Rolleneintei lung engl entitlement attributes ausgew hlt werden k nnen das Ziel Rollen zu konsolidieren Die Konsolidierung der bereits definierten Rollen wird dadurch erzielt dass lediglich die Attri bute der SRM eigenen Datentypen analysiert werden nicht aber diejenigen der technischen Endsysteme Im n chsten Schritt k nnen die Benutzer aus allen bekannten Rollen bestimmt werden f r die die Analyse vorgenommen werden soll Durch dieses Vorgehen k nnen alle Benutzer in die Analyse mit einbegriffen werden die ber mindestens eine Rolle verf gen Die Ergebnisliste schlie lich l sst sich so filtern dass von allen gefundenen Attributen nur noch die jenigen enthalten sind ber die mindestens ein gewisser Prozentsatz aller Benutzer verf gt Somit wird gew hrleistet dass die beste berdeckung f r die ausgew hlten Benutzer erfasst wird In einem letzten Schritt Kann diese Zusammenstellung in Form einer oder mehrerer Poli cys im identity warehouse abgelegt werden die dann ihrerseits automatisch mit den ausgew hl ten Rollen verkn pft werden 55 SRM Rule Discovery
193. h auch aufgrund der fehlenden Unterscheidung un terschiedlicher Rollenbegriffe Schwachstellen auf die gerade in heterogenen Systemumgebun gen zum Tragen kommen wie Kapitel 3 1 3 bereits aufzeigt Die beiden Ziele des in diesem Kapitel entwickelten Rollenmodells BRBAC sind sich einerseits einer differenzierten Betrach tung von Rollen und andererseits der gestiegenen Komplexit t zu widmen die durch die Ver wendung verteilter Informationssysteme entsteht Dabei werden in der Folge Mechanismen im Bezug auf Policys modelliert die in Rollen subsumiert sind Ziel Z Trennung von Gesch fts und Systemsicht e Anforderung A Modellierung von Gesch fts und Systemrollen Diese Anforde rung spezifiziert eine explizite Trennung von gesch ftlichen und technischen Aspekten was sich in zwei unterschiedlichen Rollenbegriffen manifestiert Weder in Rollenmo dellen wie NIST RBAC oder ERBAC noch in technischen Umsetzungen wird dieser Sachverhalt bisher explizit betrachtet Auf die Motivation f r diese Unterscheidung wird im Folgenden eingegangen Gerade in komplexen Systemumgebungen wie man sie in Unternehmen typischerweise antrifft basieren nahezu alle gesch ftlichen Prozesse auf Computersystemen oder wer den durch sie unterst tzt Diese starke Zunahme an computergest tzter Arbeitsweise f hrte in den letzten Jahren zu einer ebenso starken Zunahme an Heterogenit t des Un ternehmensnetzwerks was sich auch auf die verwendeten Zugriffskontrol
194. h auf Hierarchien operieren nderungen an der Benut zer Rolle Relation und Rolle Berechtigung Relation wirken sich nun nicht mehr nur auf die angegebene Rolle selbst aus sondern zus tzlich dazu auf die vererbten Rollen Wird etwa ein Benutzer in eine Rolle r eingetragen erh lt er zus tzlich zu r alle Rollen die r selbst erbt Die administrativen Funktionen die auf Hierarchien operieren sind Forschungsgruppe C amp M 18 Grundlagen o addInheritance Erzeugt eine direkte Vererbungsbeziehung zwischen zwei existierenden Rollen o deleteInheritance Hebt eine Vererbungsbeziehung zwischen zwei Rol len auf o addAscendent Erzeugt eine neue Rolle und f gt diese in die Hierarchie struktur als unmittelbarer Vorg nger zu einer existierenden Rolle ein o addDescendent Erzeugt eine neue Rolle und f gt diese in die Hierarchie struktur als unmittelbarer Nachfolger zu einer existierenden Rolle ein An dieser Stelle sei erg nzend erw hnt dass die spezifizierte Hierarchiestruktur bei der Implementierung dieser Funktionen beachtet werden muss Sollte eine Hierarchie mo delliert worden sein die nur einen unmittelbaren Vorg nger erlaubt wie es etwa durch einem Baum dargestellt werden kann Kann eine Rolle ber die Funktion addAscen dent nur dann eine Vorg ngerrolle erhalten wenn sie bisher ber keine verf gt oder aber der bisherige Vorg nger berschrieben wird Systemunterst tzende Funktionen Die Funktionen z
195. hasen Analyse Ent wurf Implementierung Test und berpr fung wird ausf hrlich erkl rt und ber den iterativen Prozesscharakter der Bezug zum Lebenszyklus von Rollen hergestellt Auch auf Nachteile bei der Ubertragung des klassischen Software Entwicklungsprozesses auf Rollen wird hingewiesen Diese haben mit der fehlenden R ckkopplung zu tun und f hren dazu dass die Entwicklungs zeit bis zum fertigen Produkt unter Umst nden l nger dauert als anvisiert Dies hat laut den Au toren drei haupts chliche Gr nde Der Ansatz spiegelt nicht die Situation auf dem freien Markt wieder wo die Pr misse herrscht Produkte schnell liefern zu k nnen Ferner wird oftmals erst beim Einsatz des fertigen Produktes festgestellt dass vorab festgelegte Produkteigenschaften nicht abgedeckt sind Drittens ndern sich Produktanforderungen im Laufe des Entwicklungs prozesses so dass man von einem vollst ndigen Pflichtenheft nicht ausgehen kann Moderne Software bedient sich daher eines iterativen inkrementellen Entwicklungsprozess mit R ck kopplung um fr her in die Produktion zu gehen und Nachbesserungsw nsche seitens des Kun den rechtzeitig entsprechen zu k nnen L5 Die Autoren setzen sich mit dem Begriff der enterprise role auseinander einer Definition f r system bergreifende Rollen und f hren ein Modell f r unternehmensweite Rolle ein In der Tat haben die unterschiedlichen Unternehmenssysteme meist ein eigenes Verst ndnis des Rol lenbegriff
196. hen Rollen lediglich auf einer ad hoc Basis D2 Die drei Vorgehensweisen werden vorgestellt und die Schw chen daran an ausgew hlten Beispielen anderer Autoren aufgezeigt So sind Ans tze die den top down Ansatz verfolgen klar in Modellen definiert was den Ansatz wenig dynamisch erscheinen l sst Beim bottom up Vorgehen wird Bezug genommen auf ein Werkzeug dessen Schw che es ist dass es nur f r Webanwendungen funktioniert Im middle out Verfahren wird ein Beispiel gew hlt dass theo retisch sehr pr zise formuliert ist aber viele Fragen im Bezug auf die konkrete technische Um setzung offen l sst D3 Schwachstellen von aktuellen role administration Ans tzen Hierbei handelt es sich um einen Beitrag der sich mit Rolle Hierachie Tupeln sowie Rolle Rolle Tupeln befasst und diese in einer RBAC Datenbank vorh lt Die aufgezeigte Schwachstelle liegt hier daran dass dieses System nur f r Webanwendungen verwendet werden kann Ein zweiter Beitrag befasst sich mit der Entwicklung flexibler RBAC Dienste ber die Sprache xoRBAC vernachl ssigt aber in den Augen der Autoren die Aspekte Rollen und Policy Verwaltung Pr missen Welche Einschr nkungen und Vorgaben werden hinsichtlich der eigenen L sungen gemacht P1 Ihre L sung ist speziell f r Unternehmen mit einer Vielzahl unterschiedlicher Unterneh menssysteme gedacht Sie baut auf einer rollenbasierten Infrastruktur auf und schlie t insbeson dere die beiden Module role engineer
197. hen zu k nnen Das Rollenmodell sollte dieser Tatsache Rechnung tragen und versuchen von Forschungsgruppe C amp M Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen 71 technischen Details soweit zu abstrahieren wie im gegebenen Kontext n tig Um dies leisten zu k nnen wird der in A geforderte Rollenbegriff m glichst allgemein oder generisch formuliert um in unterschiedlichen technischen Kontexten gleicherma en angewandt werden k nnen Dazu bedient sich das Modell generischer Rollen wie sie auch in den Erweiterungen zum ERBAC Modell Ke02 vorgeschlagen werden Im Ge gensatz zu dem dort verfolgten Ansatz steht hier aber nicht nur die Zusammenfassung hnlicher Rollen in Endsystemen im Vordergrund sondern zus tzlich auch die Senkung des n tigen technischen Wissens Um dies durch ein Beispiel zu verdeutlichen sei ein RBAC f higes Content Management System CMS in mehreren Abteilungen eines Unternehmens eingesetzt Da diesen Systemen dasselbe Rollenmodell zugrunde liegt werde eine generische Rolle namens Webseiten Administrator erzeugt und die Zu griffsrechte systemunabh ngig definiert Bei der Einteilung eines Benutzers in diese Rolle k nnen nun diejenigen CMS ausgew hlt werden auf die der Benutzer zugreifen k nnen solle Dazu ist es nicht n tig konkret zu wissen welche Zugriffsrechte vorher f r die Rolle definiert wurden e Anforderung A 3 Statischer und dynamischer wechselseit
198. hnischen Endsystemen ergeben Beim Hinzuf gen muss zumin dest auf technischer Ebene erneut in die Analysephase zur ckgesprungen werden um die in diesen Systemen vorhandenen Berechtigungen zu erfassen und diese im Anschluss daran zu Systemrollen zusammenzufassen Durch die Trennung von Gesch fts und Systemrollen kann es allerdings verhindert werden dass das Vorgehen auch f r die gesch ftliche Ebene in der Analysephase startet weil in BRBAC die technischen Systeme von der Gesch ftslogik entkop pelt sind Beim Entfernen eines oder mehrerer Endsysteme muss erfasst werden welche Sys temrollen den Zugriff auf diese steuern um diese in planvoller Weise deprovisionieren zu k n nen Auch hierbei kann die gesch ftliche Ebene in gleicher Weise bernommen werden In diesem Fall kann man somit von einer gemischten R ckkopplung sprechen Forschungsgruppe C amp M Entwicklung eines Vorgehensmodells fiir die rollenbasierte Zugriffskontrolle 105 5 Role Operations Customer Consultant Customer Role Engineering Technical System Change Role Entitlement Management Policy Management Role Model Change Change Implementation Information 50 Procedure Model Development Role Operations Ziel der Betriebsphase Diese stark zyklische Phase hat als Ziel die Sicherung des Wirkbetriebs die Erhaltung der Kon sistenz des Rollenmodells sowie damit einhergehend die gesetzlichen und technischen Policys des Unternehmens dau
199. hnologien zum Aufbau einer zentralen Rollendatenbank Sie stellen einen Prozess zur Erkennung von Mustern in einer zentralen Zu griffsdatenbank vor der daraus sowohl Unternehmens als auch technische Rollen ableitet Forschungsgruppe C amp M Anhang 157 12 Als Motivation dieses Ansatzes stellen sie Gemeinsamkeiten klassischer Technologien aus dem data mining Umfeld mit dem Identifizieren von Rollen heraus Ziel des data mining stellt das Generieren von Wissen aus Informationen die ihrerseits aus Daten gewonnen werden dar Dieses Prinzip l sst sich auch auf Unternehmen anwenden wo unterschiedliche Systeme im Einsatz sind die einen Ausschnitt der Gesamtzugriffsinformation eines Benutzers repr sentie ren 13 Die Autoren begr nden die Auseinandersetzung mit dem Rollenmanagement damit dass Unternehmen die Vorteile Kostenreduktion und compliance einer rollenbasierten Gesamtstruk tur erkennen und davon profitieren wollen Defizite Welche Defizite bestehender Arbeiten und L sungen werden als Motivation der eigenen L sun gen genannt D1 Die Vergabe von Zugriffsrechten und deren Kontrolle ist von zentraler Bedeutung In Um gebungen die nicht auf dem Rollenkonzept aufsetzen senkt das die Produktivit t und steigert die Kosten Das Herausarbeiten von Rollen ist daher wichtig Die Autoren sehen RBAC als Ba sis des Provisionierungsprozesses Ein Defizit bei Unternehmen stellt die Scheu vor dem initia len Aufwand dar Ein systemati
200. ich dass ein und dieselbe Person alle Aufgaben selbst erledigt Die Arbeitsabl ufe die diese drei verschiedenen Zertifizierungen als Prozess realisieren basie ren dabei auf einer workflow engine zusammen mit einer Entwicklungskomponente f r work flows die ber eine grafische Bedienoberfl che verf gt mit der workflows gestaltet und ange passt werden k nnen Forschungsgruppe C amp M Stand der Technik 65 55 SRM Identity Certification Select Certification Type Select Business Unit Select Business Unit Select Business Unit Select End Points amp User Access Role Entitlement Application Owner Attributes Works For Me C CEO Group Membership Does Not Work For Me C Training Participants Certify Revoke Attribute Value CMSUsers Information 37 State of the Art Sun Role Manager Identity Certification Information 37 stellt die drei verschiedenen Zertifizierungstypen grafisch dar Eine wichtige Aufgabe im Rollenmanagement ist es regelm ig zu berpr fen ob die Benutzer noch aktiv sind die Abteilung gewechselt haben oder auch aus der Firma ausgeschieden sind SRM stellt hierf r den Zertifizierungstyp user access bereit Dieser arbeitet auf Basis von Gesch ftseinhei ten und richtet sich an den Verantwortlichen dieser Gesch ftseinheit F r jeden Benutzer muss vom Verantwortlichen angegeben werden ob er der Abteilung noch angeh rt oder nicht Dieser Schritt kann dadurch teilautomatisi
201. icherheit mehr als zwei Werkzeuge in Betracht jedoch w rde dies den Rahmen dieser Arbeit sprengen Dieser Kriterienkatalog kann aber zur Evaluierung weiterer Werkzeuge herangezogen werden Auf der Grundlage der Kriterien die im Katalog spezifiziert werden wird insbesondere die M chtigkeit des Rollenmodells gemessen das in den zwei zur Auswahl stehenden Werkzeugen implemen tiert ist Beide Werkzeuge zusammen mit ihren Software Architekturen und Komponenten sind in den Kapiteln 3 2 und 3 3 bereits angesprochen und wertungsfrei vorgestellt worden Um eine Vergleichbarkeit dieser teils sehr unterschiedlichen Werkzeuge zu erm glichen wird die Metrik der jeweiligen Kriterien in Kapitel 6 1 so gew hlt dass sie eine Vergleichbarkeit unterschiedli cher Werkzeuge im Allgemeinen erm glichen Aus diesem Grund kann der Kriterienkatalog in weiteren Forschungsarbeiten auch auf andere Werkzeuge angewandt werden Nach der Ent wicklung des Katalogs folgt in den Kapiteln 6 2 und 6 3 dann schlie lich dessen Anwendung auf die beiden Werkzeuge 6 1 Entwicklung eines Kriterienkatalog 6 1 1 Motivation des Katalogs In diesem Unterkapitel soll ein Kriterienkatalog entwickelt werden mit dessen Hilfe Rollenma nagementwerkzeuge bewertet werden k nnen Die Kriterien orientieren sich dabei an typischen Aufgabenbereichen von Rollenmanagement im Wirkbetrieb und sind m glichst disjunkt zuei nander gew hlt um eine breite Bewertungsgrundlage zu schaffen Diese typi
202. iedliche Sichten auf die Organisation in der das Rollenmodell zu implementieren ist Es ist eine realistische Annahme davon auszugehen dass diese Kompetenzen nicht nur auf verschie dene Personen aufgeteilt sind sondern sogar auf unterschiedliche Dienstleister die der Organi sation zur Verf gung stehen Aus diesem Grund wird die Organisation im Folgenden auch als Kunde bezeichnet e Die Analysten Die Analysten verf gen ber methodische Kompetenzen und grobes technisches Wissen ber das bzw die einzusetzenden Systeme In diesem Sinne unter teilen sich die Analysten in Business Analyst und Sicherheits Analyst Sie bilden die Schnittstelle zwischen dem Kunden und den technischen Kompetenzen Der Business Analyst arbeitet mit der Gesch ftsleitung zusammen und formalisiert deren Anforde rungen an das entstehende Rollenmodell Der Sicherheits Analyst hat eher Kompeten zen im technischen Endsystembereich und arbeitet daher neben der Gesch ftsleitung auch direkt mit den Consultants zusammen e Verantwortliche Mitarbeiter beim Kunden Der Kunde ist in diesem Fall das Unter nehmen welches eine rollenbasierte Zugriffskontrollarchitektur einsetzen will und die explizit und implizit existierenden Gesch ftsprozesse und Verantwortlichen kennt Auch hier werden zwei Abstraktionsschichten definiert Einerseits wird ein Zust ndiger f r organisatorische Strukturen ben tigt und andererseits eine technische Kompetenz der die Sichtweise der Unte
203. ierarchien erkennen Nach der Erfassung von gesch ftlichen Aspekten werden diese nun zueinander in Bezug gesetzt um daraus m gliche Hierarchien zu entwickeln Die entstehende Rollenhierarchie soll dabei m glichst nat rlich gew hlt sein und den Zu stand des Unternehmens m glichst gut repr sentieren Hierf r kann es auch vonn ten sein mehrere unterschiedliche Hierarchien aufzubauen Die in dieser ersten Phase erzeugten Artefakte sind eher deskriptiver Natur und sollen auf ge eignetem Abstraktionsniveau ein Gesamtbild des Unternehmens geben Diese Artefakte bilden das Unternehmen im Idealfall in sehr anschaulicher Weise ab Wie KK 02 erw hnt sollte in die Analyse hinreichend viel Zeit investiert werden da ein schlecht erfasstes Gesamtbild zu ei nem sp teren Zeitpunkt mit hoher Wahrscheinlichkeit nachgebessert werden muss was deutlich mehr Zeit in Anspruch nimmt Die Analyse bildet die Basis f r den Entwurf des Rollenmodells so dass Nachl ssigkeiten in der Analyse zu Rollenmodellen f hren die ihrerseits ebenfalls Schwachstellen aufweisen Rollenentwurf In der Entwurfsphase f r Rollen engl role design befasst man sich mit dem Entwurf von Rol len auf der Basis der Analyseergebnisse Ziel dieser Phase ist es zu einem der Situation ent sprechendem Rollenmodell zu gelangen was robust und praktisch anwendbar ist Dies beinhal tet die Abbildung von Rollen und den Entwurf des Rollenmodells f r die technische Umsetzung Auf diese
204. iger Ausschluss Einer der Vorteile einer rollenbasierten Zugriffskontrollarchitektur ist dass sich wechselseiti ger Ausschluss von Kompetenzen sehr intuitiv darstellen l sst Bei diesem als separati on of duty SoD bekannten Prinzip unterscheidet man zwischen statischem und dyna mischem Ausschluss wie bereits in Kapitel 2 2 3 beschrieben wurde Ebenfalls geht hieraus hervor dass statisches SoD eine Beschr nkung engl constraint bei der Benut zer Rolle Relation darstellt und wechselseitigen Ausschluss f r Rollen definiert die nicht zusammen an einen einzelnen Benutzer vergeben werden d rfen Dynamisches SoD dagegen stellt eine Beschr nkung der Sitzung Rolle Relation dar und definiert die sen Ausschluss f r Rollen die innerhalb desselben Sitzungskontextes nicht gemeinsam aktiviert werden d rfen Das BRBAC Modell in dieser Arbeit soll eine Implementie rung von dynamischem sowie statischem SoD erm glichen ohne dabei den Sitzungs kontext als explizites Modellelement zu ben tigen weil dieser implizit bereits vorhan den ist Ein Beispiel f r dynamisches SoD ist dem Bankensektor entliehen in welchem durch gesetzliche Rahmenbedingungen sehr hohe Anforderungen an die Zugriffskont rolle vorherrschen In der Gesch ftsfunktion eines Bankangestellten sei es beispielswei se m glich Kredite zu bewilligen und Auszahlungen auszuf hren Zus tzlich solle aber die Restriktion gelten dass dies beides f r einen einzelnen Kredit nicht vom selbe
205. igneten Ausschnitts als Vorbedingung f r den Rollenentwurf verwendet werden Forschungsgruppe C amp M 96 Entwicklung eines Vorgehensmodells fiir die rollenbasierte Zugriffskontrolle S5 Role Analysis Analyst Customer Analyst Consultant Customer Consultant Customer structured Requirement Engineering Interviews structured structured Business Analysis System Analysis Organisation Analysis ee Technical Analysis requirement specification Permission Analysis Job Analysis Product Selection Feasabilty Study Information 47 Procedure Model Development Role Analysis Ziel der Analysephase Das Ziel dieser Phase ist einerseits die Formalisierung des Gesamtzustands auf geeigneter Ab straktionsebene und andererseits die Erfassung des vom Kunden gew nschten Verhaltens Zum Abschluss der Analysephase konzipieren die Analysten zusammen mit den Consultants einen Zeitplan sowie ein finales Lastenheft engl requirement specification was zur Abnahme dem Kunden vorgelegt wird Vorab wird jedoch von den Consultants zusammen mit den Analysten die Durchf hrbarkeit anhand des aufgestellten Zeitplans diskutiert um ber den weiteren Vor gehensverlauf zu entscheiden Auch ist diesem Artefakt die personelle Planung beizuf gen um im Falle der Aufnahme des Projekts die n chsten Schritte und Verantwortlichkeiten zu definie ren Wie Ba96 belegt wird in der klassischen Software Entwicklu
206. im Zusammenhang mit Forschungsgruppe C amp M 48 Stand der Technik Rollen anbietet vorgestellt Dieser Prozess stellt den Bezug zwischen den Komponenten role maintenance role mapping self service workflow automation und delegated administration aus Information 18 her die zu Beginn dieses Kapitels vorgestellt wurden Der workflow ist in fol gender Abbildung dargestellt 58 0IM Role Management Define Business Role Define System Role Define Mapping Assign User to Business Role User Requests Additional Role Automatic Tracking Delegate Administration Information 23 State of the Art Omada Identity Manager Role Management Im Vergleich zum zugrundeliegenden RBAC Standard aus FS 01 interpretiert der Omada Identity Manager den Rollenbegriff deutlich freier und so kann eine Rolle neben einer Kapse lung gesch ftlicher oder technischer Rechte auch f r einen Benutzer selbst stehen Der semanti sche Unterschied zwischen diesen drei Rollenbegriffen wird durch ein entsprechendes Attribut innerhalb der Rolle festgelegt Die Rollen die im Omada Identity Manager verwendet werden sind in mehrere unterschiedliche Rollentypen engl role types unterteilt deren Eigenschaften und Schemata sich jeweils von einer Vorlage ableiten wie aus Information 19 ersichtlich ist Durch die Vorlagen wird erm glicht gewisse Attribute oder Eigenschaften wie etwa die Verer bung von Rollen f r die einzelnen Rollentypen zu
207. im un mittelbaren Zusammenhang zur Entwicklung eines Rollen sowie Vorgehensmodells f r den Unternehmenskontext stehen sowie eine detaillierte Einf hrung in zwei ausgew hlte Rollenma nagementwerkzeuge gegeben Forschungsgruppe C amp M Stand der Technik 29 3 STAND DER TECHNIK In diesem Kapitel wird ein Uberblick iiber den aktuellen Stand bei der rollenbasierten Zugriffs kontrolle innerhalb von Wissenschaft und Technik gegeben Das Kapitel ist dabei folgenderma Ben gegliedert Kapitel 3 1 betrachtet zun chst aktuelle Modelle zur rollenbasierten Zugriffs kontrolle die speziell f r den Einsatz in Unternehmen konzipiert wurden und unterschiedliche Aspekte beleuchten Dies stellt die Verkn pfung zum vorangegangen Kapitel her in dem die Grundlagen f r diese spezialisierte Betrachtungsweise gelegt wurden Zun chst wird dabei ein Modell zum automatisierten Entwickeln von Rollen vorgestellt an das sich die Betrachtung ei nes speziellen Rollenmodells f r den Unternehmenskontext anschlie t Abschlie end wird auf den Lebenszyklus von Rollen im Wirkbetrieb eingegangen Mit dem Begriff Lebenszyklus wird ein Vorgehensmodell bezeichnet welches an den klassischen Software Entwicklungszyklus angelehnt ist diesen auf die Entwicklung von Rollen bertr gt und dabei administrative Aufgaben im Wirkbetrieb eines instanziierten Modells explizit beachtet Kapitel 3 1 zeigt somit aktuelle Forschungsergebnisse im Bereich RBAC aus der Wissenscha
208. in L2 L3 und L4 geschildert werden L2 Um eine zentrale unternehmensweite Informationsdatenbank zu erhalten m ssen system spezifische Benutzer Attribute und Gruppenmitgliedschaften aus unterschiedlichen Systemen identifiziert werden und diese dann in eine Gesamtdatenbank importiert werden Ziel hiervon ist eine organisierte Migration mit zentraler Administration Forschungsgruppe C amp M 158 Anhang L3 Auf diesen Informationsstamm werden die Methoden association und clustering des IBM Intelligent Minder for Data f r statistische und semantische Informationen als Schl ssel zum Finden von Rollen angewandt Dieser erlaubt das Ausw hlen von Datenportionen und das Ite rieren mit unterschiedlichen statistischen Grenzwerten Hieraus wachsen Rollendefinitionen Assoziationen erzeugen Regeln die angeben wie oft Ereignisse in Objekten zusammen auftau chen mit dem Ziel funktionale Rollen zu identifizieren Clustering gruppiert Eintr g mit hnli chen Attributwerten zum Auffinden von Unternehmensrollen LA Auf das Ergebnis dieses iterativen Prozesses wird der SAM Role Miner zum Erzeugen ei nes Rollenschemas angewandt welcher zwischen Gesch ftsrollen und funktionalen Rollen un terscheidet Der Begriff Rolle ist hierbei nicht zielsystemspezifisch Als Administrationsplatt form wird SAM eingesetzt SAM ist ein system bergreifendes Verwaltungswerkzeug zur automatisierten Datenbeschaffung und Rollenimplementierung Die direkte Bindung
209. in Lebenszyklus f r Rollen ein gef hrt Der Vorteil davon ist dass das Entwickeln von Rollen als ganzheitlicher Prozess be trachtet wird der nicht mit dem entwickelten Rollenmodell endet sondern die Pflege und Nachbesserung der Rollen mit einbezieht Im Bereich der Industrie sind in den letzten Jahren Rollenmanagementwerkzeuge entwickelt worden die als zentrale Steuereinheit f r die Zugriffskontrolle angesehen werden k nnen Mit dem Omada Identity Manager und dem Sun Role Manager wurden zwei aktuelle Werkzeuge be trachtet und dabei zun chst ein berblick ber deren Gesamtarchitekturen und verwendeten Da tentypen gegeben Im Anschluss daran folgte jeweils ein detaillierter Einblick in die Aufgaben bereiche die die beiden Werkzeuge im Bereich des Rollenmanagements erf llen Dabei wurden diese Bereiche jeweils in Bezug gesetzt zu den typischen Aufgaben von Rollenmanagement werkzeugen aus Kapitel 2 3 Dabei wurde das Ziel verfolgt die Vorstellung der Produkte wer tungsfrei zu halten um einen objektiven berblick zu gew hrleisten Auf die Bewertung wird in Kapitel 6 dieser Arbeit dediziert eingegangen und daf r zun chst ein Kriterienkatalog entwi ckelt der anschlie end auf beide Werkzeuge angewandt wird Wie in diesem Kapitel dargestellt ist weisen aktuelle Rollenmodelle die f r den Einsatz in Un ternehmen konzipiert wurden zwei Schwachstellen auf Einerseits vermischen sich gesch ftli che und technische Aspekte und anderers
210. in Mailserver angegeben werden der von OIM verwendet wird um Benachrichtigungen etwa bei Frist berschreitungen von Prozessindi katoren zu verschicken Eine weitere grundlegende administrative Aufgabe ist das Anlegen von Forschungsgruppe C amp M 142 Benutzerkonten die auf OIM zugreifen Dies lasst sich in OIM mit dem zentralen Verzeichnis dienst integrieren so dass die Benutzerkonten automatisch in OIM importiert werden Auch ist es innerhalb der Spezifikation von Gesch ftsprozessen m glich dass automatische Emails ver strative Aufgabe ist das Erstellen von Managementagenten f r den ILM F r ein tiefgreifenderes Verst ndnis dieser Komponenten sei an dieser Stelle ver wiesen auf OIMO7b Ein drittes Beispiel einer administrativen Aufgabe ist das Definieren der rollenspezifischen Ansichten engl views Der gesamte Konfigurationsprozess ist abschlie end schickt werden Eine weitere admini dargestellt in Information 61 Configuration Process of Omada Identity Manager structured 3 OE Configuration Configure Database Connection Configure Web Application in IIS amp Configure Authorization Roles No D 2 DA Name Description User role Description for user role Administrator role Description for administrator role Configure Management Agents Management Agen Information 61 Appendix Configuration Process of Omada Identity Manager structured 5 OIM Configuration amp Con
211. in vier Phasen unterteilt F r jede Phase wurden definiert was in dieser Phase zu erledigen ist was das Ziel der Phase darstellt bzw welche Zielartefakte erzeugt werden wer an der Phase beteiligt ist und welche Gr nde f r R ckkopp lungen zu fr heren Phasen sprechen Das Ziel der Analyse und Entwurfsphase ist der Entwurf von Gesch fts und Systemrollen was durch das hybride Vorgehen parallel geschehen kann Den Abschluss der Entwurfsphase bildet die Spezifikation dieser beiden Rollentypen zusammen Forschungsgruppe C amp M Zusammenfassung und Ausblick 135 mit der Gesch ftsrollen Systemrollen Relation die diese beiden Rollentypen verbindet Zu sammen mit diesen Spezifikationen dient ein Pflichtenheft als Zielartefakt dieser Phase Zur Implementierung in der Implementierungsphase muss zun chst das Rollenmanagementwerk zeug selbst im Unternehmen installiert und konfiguriert werden ehe das spezifizierte Rollen modell in diesem Werkzeug umgesetzt werden kann Das Vorgehen legt gerade f r gr ere Ein richtungen eine schrittweise Implementierung nahe begleitet von einem Testbetrieb um Erfahrungswerte im Umgang mit der neuen Zugriffskontrollarchitektur ins Rollenmodell zu r ckf hren zu k nnen Durch die Sammlung von Erfahrungswerten wird auch sichergestellt dass die in der Analyse und Entwurfsphase konzipierte Rollenmodellinstanz den Gegebenhei ten des Unternehmens entspricht was die Akzeptanz der Modells im Wirkbetrieb erh h
212. ine gewachsene Struktur mit ver teilten Systemen verf gen Ka07c Bei der Integration eines Rollenmanagementwerk zeugs wird somit initial ein gewisser Aufwand verursacht der von der Migration der existierenden Unternehmensdaten herr hrt Der Erfolg von Rollenmanagementwerk zeugen h ngt somit ma geblich davon ab ob diese das Herausarbeiten von Rollen aus einer bestehenden Unternehmensstruktur unterst tzen Das Anwenden von Algorithmen Forschungsgruppe C amp M 112 Analyse aktueller Rollenmanagementwerkzeuge zur analytischen und automatisierten Entwicklung allgemeiner Rollen engl role mi ning stellt mittlerweile einen bew hrten Ansatz in diese Richtung dar Dieses Krite rium bewertet nun ob das Werkzeug Algorithmen hierf r bereitstellt Kriterium 4 Unterst tzung von Arbeitsabl ufen Da an den Prozessen zum Aufbau einer rollenbasierten Struktur unterschiedliche Abteilungen beteiligt sind ist es wichtig diese Abl ufe im eingesetzten Werkzeug zun chst abbilden und anschlie end berwa chen zu k nnen Die Abbildung gew hrleistet eine zielgerichtete Durchf hrung der Ab l ufe im Querschnitt ber alle Beteiligten wohingegen die berwachung sicherstellt dass die an der Umsetzung beteiligten Personen die Fristen und Ziele bei den unter schiedlichen Abl ufen einhalten Das Werkzeug muss demnach prozessorientierte Ar beitsabl ufe erm glichen Das vierte Kriterium bewertet die Unterst tzung des Umset zungsprozesses
213. ing und role administration mit ein P2 Speziell die aus P1 resultierende gro e Zahl an Rollen macht eine Betrachtung von role engineering und role administration unausweichlich In dieser Ver ffentlichung liegt der Fokus klar auf dem Punkt role administration P3 Die speziellen Anforderungen eines solchen Systems sind Das Vorhandensein in m g lichst vielen Unternehmenssystemen engl availability die Anwendbarkeit in m glichst vielen Policy Umgebungen die auf RBAC aufbauen engl applicability die Benutzerfreundlichkeit Forschungsgruppe C amp M 164 Anhang so dass ein Rollenadministrator intuitiv damit umgehen kann engl ease of use und die Kon formit t zu RBAC Standardrahmenwerken engl standardization P4 Um die theoretischen RBAC Referenzmodelle anwendbar zu machen werden die in ihnen aufgef hrten Komponenten in drei Bereiche einsortiert Die Autoren definieren strukturelle funktionale sowie informative Komponenten und basieren auf RBAC96 Strukturelle Kompo nenten sind die statischen Teile des Referenzmodells namentlich sind das Benutzer Rollen Be rechtigungen Rollenhierarchien Objekte Operationen und Einschr nkungen und beziehen sich einerseits auf deren Semantik die im Referenzmodell bereits klar definiert ist aber auch deren Syntax Funktionale Komponenten stellen Verkn pfungen zwischen den erstgenannten Kompo nenten her was namentlich Benutzerzuweisungen und Berechtigungszuweisungen zu Rollen si
214. installation Basic server system Omada Identity Manager Installation prerequisites Installation of Windows Server 2003 Operating System Installation of Microsoft SQL Server Post installation Configuration Installation of Internet Information Services Installation of Omada Enterprise Post installation Configuration G Installation of Omada Identity Manager Post installation Configuration Information 60 Appendix Installation Process of Omada Identity Manager Die Installation des Omada Identity Manager ist in Information 60 als Aktivit tsdiagramm dar gestellt Hierbei wird implizit davon ausgegangen dass die Gesamtarchitektur von OIM auf ei ner einzigen Maschine betrieben wird Dies ist allerdings keine starke Einschr nkung da die Schichten von OIM aufgrund dessen Software Architektur auf mehrere Systeme verteilt werden k nnen Zur Einhaltung eines gewissen Sicherheitsstandards sollte die Pr senationsschicht auf der Benutzer mit dem System interagieren von der Gesch ftslogik und der Datenhaltung losge l st sein Um eine m glichst hohe Skalierbarkeit der L sung zu gew hrleisten sollten alle drei Schichten auf dedizierte Computersysteme verteilt werden Dieses Szenario verwendet jedoch der Einfachheit halber nur ein einzelnes Computersysteme In einer realen Umgebung muss die Aufteilung der Komponenten auf die zur Verf gung stehenden Rechner allerdings wohl berlegt sein Dies ist in der Abbildung als
215. isch neu berechnet werden sobald sich an den Rolleneinteilungen eines Benutzers nderungen ergeben Auch die dezentrale Administration ist als Vorteil von OIM gegen ber SRM hervorzuheben da dies die Effektivit t einer rollenba sierten Zugriffskontrolle erh ht Die grafische Formulierung von Arbeitsabl ufen und die be nutzerspezifischen Ansichten f hren potentiell zu einer hohen Akzeptanz des Werkzeugs im produktiven Einsatz was sich in SRM so nicht wiederfindet SRM hingegen bietet eine sehr ausgepr gte Unterst tzung f r das automatische Entwickeln von Rollen und die Wartung des Rollenmanagementwerkzeugs im Wirkbetrieb Bezugnehmend auf das Vorgehensmodell aus Kapitel 5 kommen diese Komponenten in allen vier Phasen zum Tragen und unterst tzen somit den Gesamtprozess zur Umsetzung einer rollenbasierten Zugriffskontrolle sehr stark Die auto matische R ckf hrung in die Endsysteme ist in beiden Werkzeugen durch eine eigene Provisio nierungsl sung gegeben Der OIM verwendet den Identity Lifecycle Manager der Firma Micro Forschungsgruppe C amp M 120 Analyse aktueller Rollenmanagementwerkzeuge soft und auch f r den SRM existiert die M glichkeit der Integration mit dem Identity Manager der Firma Sun was in dieser Arbeit aber nicht betrachtet wurde Diese Funktionalit t ist ele mentar bei der Integration von Rollenmanagementwerkzeugen in einer gewachsenen Unterneh mensstruktur weil der manuelle Datenaustausch zu den Endsystemen di
216. ist es in OIM jedem Mitarbeiter m glich einerseits nderungen an seinen eigenen Rollenzuweisungen vorzunehmen sowie an dererseits f r diejenigen Mitarbeiter f r die er verantwortlich ist ber die Komponente self service workflow ist es jedem Mitarbeiter m glich eigene Rollen zu entfernen oder die Mitg liedschaft in zus tzlichen Rollen anzufordern Ferner ist es jedem Benutzer m glich die in Ge sch fts sowie Systemrollen gekapselten Befugnisse zu einem frei w hlbaren Zeitpunkt an eine andere Person zu delegieren was unter der Komponente delegated administration zu verstehen ist Die letzte Komponente automation steht f r die OIM eigenen automatischen Arbeitsabl ufe engl workflows die eine Automatisierung im gesamten Zugriffskontrollprozess in vielerlei Hinsicht erm glichen Im Zusammenhang mit dem role management ist ein automatisches R ckf hren von nderungen des Datenbestandes aus OIM in die Unternehmenssysteme m g lich Dies geschieht durch die Einbeziehung der Provisionierungsplattform Ein zweites Beispiel f r die erw hnten workflows sind die Arbeitsbereiche approvals und workflow designer Sie stehen f r die Bewilligung von nderungen an der Rollenstruktur sowie f r die Modellierung und den Entwurf eigener workflows Der zweite gro e Arbeitsbereich compliance module befasst sich mit der Einhaltung von Policy Vorgaben auf unterschiedlichen Stufen des Lebenszyklus einer Rolle Gemessen an den Aufga ben von Rollen
217. ities 220020002s0ennersnensneesnnesnnesneenn 24 State of the Art The Role Mining Process 2202220022002s0ensensnersnnesnnenneenn 30 State of the Art Enterprise RBAC Model 220022002200nsnensnersneesnnennnnenn 32 State of the Art Enterprise RBAC Model with Generic Roles 35 State of the Art Enterprise RBAC Model with Joker Permissions 36 State of the Art Enterprise RBAC Model User specific Constraints 37 State of the Art The Role Life Cycle 0 ee eeeceseeseseeeseeeeeeneecnseceaeenaeee 37 State of the Art Omada Identity Manager Component Architecture 42 State of the Art Omada Identity Manager Data Type Relationship 44 State of the Art Omada Identity Manager GUl u 2ucsnrsnesnesnneenn 45 State of the Art Omada Identity Manager Data Exchange 46 State of the Art Omada Identity Manager Management Agents 47 State of the Art Omada Identity Manager Role Management 48 State of the Art Omada Identity Manager Role Management 49 State of the Art Omada Identity Manager Role Management 50 State of the Art Omada Identity Manager Compliance Module 52 State of the Art Omada Identity Manager Workflow Designer 53 State
218. itzt Dabei besteht eine permission selbst aus einer Menge an Operation die systemspezifisch sind und den Zugriff auf ein Objekt festlegen Im Allgemeinen stellt die Menge an Operationen demnach ausf hrbare Programmeinheiten dar welche im Kontext des Benutzers gewisse Funktionen ausf hren Diese Operationen h ngen dabei von dem System ab in dem sie definiert sind und k nnen daher sehr unterschiedlich sein Permissions User Assignment Permission Assignment Operations Objects user_session session_role Sessions Adapted from FS 01 Figure 1 Information 8 Basics NIST RBAC core RBAC Information 8 stellt die Modellspezifikation von core RBAC grafisch dar Die Elemente und Re lationen sind hierbei folgenderma en definiert e Modellelementmengen users roles operations objects sessions permissions permissions 2Petations X objects Menge an Berechtigungen e UA C users x roles m zu n Beziehung zwischen Benutzern und Rollen e PA C permissions X roles m zu n Beziehung zwischen Rollen und Berechtigun gen e Op p permissions gt op operations Abbildung von Berechtigungen auf Operationen dient zur R ckgabe der Operationen f r die die Berechtigung definiert ist e Ob p permissions gt ob C objects Abbildung von Berechtigungen auf Ob jekte dient zur Rtickgabe der Objekte die mit der permission belegt sind e user_sessions u user gt 2 Abbildung eines Benutzers auf dessen Sit
219. kzeug in den Testbetrieb berf hrt wurde und das Rollenmodell f r die ausgew hlte Testabteilung implementiert wurde Vor dem Beginn dieser Testphase m ssen Testf lle aufgestellt und den Mitarbeitern vorgestellt werden die sich aus den Anforderungen aus dem Pflichtenheft ableiten lassen Dieses Vorgehen liegt in sofern nahe als dass das Pflich tenheft die Testf lle bereits in formaler Weise enth lt In dieser Phase ist es wichtig die Leis tung der Pilotierung zu berpr fen etwa um fr hzeitig Schwachstellen oder Leistungsengp sse zu erkennen Am Ende dieser Testf lle und der Erfassung von Schw chen werden die Testbe nutzer intensiv interviewt um Erfahrungswerte in der Benutzung zu erfassen Das Ergebnis die Forschungsgruppe C amp M 102 Entwicklung eines Vorgehensmodells fiir die rollenbasierte Zugriffskontrolle ser direkten Gespr che ist eine Liste mit offenen Punkten die vor einem Ausrollen des Rollen modells auf das Unternehmen abgearbeitet werden m ssen 8 Role Implementation Consultant Consultant Customer Customer datastore functional specification structured Tool Implementation Role Management Tool Implementation structured Test Implementation Binding to Syst mph t Role Model inding to Systems Implement Role Model ee Test Phase Define Use Cases Use Case Verification datastore Interviews Use Cases lt lt no gt gt datastore Result Accepted Res
220. l utert die anschlie end in BRBAC modelliert werden e Umegehen der Policy Vererbung Die zentrale Trennung von gesch ftlichen und tech nischen Aspekten kommt auch an dieser Stelle zum Tragen so dass explizit zwischen gesch ftsnahen und technischen Policys unterschieden wird was zu einer Klaren Struk tur f hrt Der Ansatz der hier verfolgt wird ist dass gewisse Policys vom Verer bungsmechanismus explizit ausgenommen sind Dazu wird auf die Vererbung in sofern eingewirkt als dass gesteuert werden kann ob gewisse Rechte vererbt werden oder nicht Dazu ist es in diesem Modell m glich in einer Policy zu definieren ob das darin spezifizierte Recht weitergegeben wird oder nicht Dazu erh lt eine Policy ein zus tzli ches Attribut block policy inheritance welches den geschilderten Sachverhalt spezifi ziert Dieses Attribut ist hierbei direkt in der Policy und nicht in der Rolle selbst veran kert um eine feingranulare Steuerung zu erm glichen Da SoD constraints auf der Ebene von Rollen operieren muss dies bei der Implementierung des Rollenmodells be achtet werden Durch diesen Mechanismus ist es nunmehr m glich gewisse Policys ex plizit von der Vererbung auszuschlie en w hrend die Rollen die diese Policys enthal ten weitervererbt werden k nnen Der Vorteil hiervon ist dass eine Rolle innerhalb der Hierarchie individuelle Rechte zugewiesen bekommen kann die nur f r diese Rolle ge lten nicht aber f r die Rollen in tiefer
221. l werden die wichtigsten Erkenntnisse zu sammengefasst ehe im abschlie enden Kapitel 8 der Fokus auf die gesamte Arbeit gerichtet wird und die Ergebnisse der gesamten Arbeit zusammengefasst und Ankn pfungspunkte f r weitere Arbeiten im Rollenmanagement gegeben werden Im Anhang befinden sich zus tzliche Informationen die den Ausf hrungen der Arbeit zugrunde liegen den Schwerpunkt aber nicht direkt betreffen 1 5 Rechtschreibung und Typografie In dieser Arbeit wird zur Hervorhebung im Text folgendes Schema verwendet e Kursive Schrift bezeichnet Worte der englischen Sprache die auch im Flie text ver wendet werden e Schreibmaschinenschrift wird zur Verwendung von Modellelementen bzw von Quellcode verwendet e Eigennamen sowie Produktnamen werden in dieser Arbeit nicht eigens hervorgehoben da dies sonst zu einer Verschlechterung des Leseflusses f hren w rde Zus tzlich dazu wird in dieser Arbeit das Wort Policy h ufig verwendet Da dieser Begriff in der Informatik bereits eine klare Bedeutung tr gt und die damit einhergehenden Assoziationen Forschungsgruppe C amp M 10 Einleitung durch die Verwendung der sinngem en bersetzung Richtlinie verloren gingen wird dieses englische Wort als deutscher Begriff im Flie text verwendet Als Grundlage zur Rechtschreibung in dieser Diplomarbeit wird der aktuelle Duden verwendet Du06 Forschungsgruppe C amp M Grundlagen 11 2 GRUNDLAGEN Diese Arbeit b
222. larchitekturen Forschungsgruppe C amp M 70 Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen auswirkte Auf Ebene der technischen Endsysteme existiert ebenfalls ein Rollenbegriff der sich von der gesch ftlichen Sichtweise jedoch stark unterscheidet Wie bereits an gesprochen wurde ist eine klare Tendenz hin zu rollenbasierten Zugriffskontrollans t zen zu erkennen In vielen heutigen Rollenmodellen wie etwa dem ERBAC Modell vgl Kapitel 3 1 2 findet sich ein Rollenbegriff der sehr stark an Gesch ftsfunktionen ausgerichtet ist Die Auffassung im ERBAC Modell ist allerdings nicht hinreichend spezifiziert f r die Situation in heterogenen Systemlandschaften da die Komplexit t ja insbesondere durch die Vielzahl an technischen Systemen entsteht Information 1 ver deutlicht diesen Sachverhalt Diese Schwachstelle wurde im Kreis der Wissenschaft be reits erkannt und insofern nachgebessert dass eine Rolle neben gesch ftlichen Funktio nen ebenso technische Zugriffskontrollinformationen verinnerlicht Diese Modellierung f hrt jedoch zu einer Mehrdeutigkeit beim Rollenbegriff der nunmehr nicht klar zwi schen diesen beiden Rollendefinitionen unterscheidet siehe dazu Kapitel 3 1 3 In he terogenen Systemumgebungen wie man sie heutzutage in Unternehmensnetzwerken findet existieren diese beiden unterschiedliche Auffassungen des Begriffs Rolle wenn nicht in expliziter dann zumindest in impliziter Form
223. ldcard constraint wildcard constraint Information 45 Development of the BRBAC Role Model Complete Model Information 45 zeigt das resultierende BRBAC Gesamtmodell Es definiert folgende Modell elemente und Relationen Modellelemente e Benutzerkonten engl user U ieN e Berechtigungen engl policy P ieN e Rollen R gt BRU SR e Kontext C eU ieN e Gesch ftsrollen engl business roles BR ieN e Generische Gesch ftsrollen engl generic business role BR Cc BR e Systemrollen engl system roles SR ieN e Generische Systemrollen engl generic system role SR Cc SR e Policy engl policy Crm C ATTRIBUTE x VALUE Relationen e Benutzer Geschiaftsrolle Relation Ousr CZ UXBR e Gesch ftsrolle Systemrolle Relation O grsr lt BRXSR e Geschaftsrolle generische Gesch ftsrolle Relation engl business role assignment O BRg BR c BR x BR e Geschaftsrolle Systemrolle Relation generisch engl generic role mapping O Bre SRe c BR xSR e Systemrolle Berechtigung Relation Osrp CG SRxP e Systemrolle generische Systemrolle Relation engl system role assignment O SRg SR G SR x SR e Statische SoD Relation O so RXR e Dynamische SoD Relation O asp RXRxC Forschungsgruppe C amp M Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen 89 Funktionen e Gsesch ftsrollenfunktion businessroles U gt BR ieN businessroles u x x y E
224. le Manager In Information 63 wird der Prozess zur Installation der Werkzeugumgebung als Aktivit tsdiag ramm dargestellt In der Vorabphase engl pre installation wird damit begonnen die System anforderungen zu analysieren Dies umfasst die Systemanforderungen fiir die Systeme die SRM zugrunde liegen und des Sun Role Manager selbst Neben der Analyse der Systemanforderun gen muss eine geeignete Netzwerkstruktur fiir die eingesetzten Systeme definiert werden Da SRM auf einem 3 Schichten Modell aufbaut ist es m glich dass die ben tigten Server auf un terschiedliche Rechner verteilt werden und die Kommunikation zwischen den Serversystemen ber das Netzwerk stattfindet Dies gew hrleistet eine Skalierbarkeit des Gesamtsystems da die Last ber das Netzwerk auf mehrere Rechner verteilt wird In dieser Arbeit wird der Einfachheit halber nur ein einzelner Rechner f r alle drei Schichten der Software Architektur verwendet Diese Entwurfsentscheidung ist allerdings f r den produktiven Einsatz nicht zu empfehlen und wurde lediglich zur Vereinfachung des Installationsprozesses gef llt Nach den grundlegenden Entwurfsentscheidungen zum Systementwurf wird bei der Installation der Basissysteme engl basic server systems damit begonnen ein Betriebssystem zu installie ren In dieser Arbeit wird Windows Server 2003 R2 Enterprise Edition verwendet Die Installa tion l uft men getrieben und h lt sich an das empfohlenen Standardvorgehen aus MicO5a
225. lemente Subjekt und Rolle eingef hrt wodurch die effektive Berechtigung eines Subjekts auf ein Objekt nun insgesamt betrachtet durch zwei Relationen festgelegt wird Die folgende Abbildung Information 6 stellt den Zusammenhang zwischen der Subjekt Objekt Relation und der rollenbasierten Zugriffskontrolle mit dem zus tzlichen Modellelement Rolle her Forschungsgruppe C amp M 12 Grundlagen Access Origin Access Goal Subject Access Control Definition Object User Assignment Policy Assignment Policy Adapted from Em08 Information 6 Basics Subject Object Relation and RBAC Ein zentraler Aspekt von RBAC sind neben dem Modellelement Rolle die Relationen Benut zerzuweisung engl user assignment und Berechtigungszuweisung engl policy assignment durch die eine Rolle einerseits aufgefasst werden kann als semantisches Konstrukt um Berechti gungen bzw Policys zu aggregieren und andererseits als Beh lter f r eine Menge an Subjekten Durch die explizite Trennung von zugreifenden Subjekten und zugriffsbeschr nkten Objekten k nnen Zugriffsrechte engl policies nun in Konsistenter Form definiert und f r eine Menge an Benutzern spezifiziert werden weil diese mit dem Objekt nun nicht mehr direkt verkn pft sind sondern in Form der Rolle nur noch indirekt Ein Benutzer erh lt die in einer Rolle definierten Zugriffsrechte indem er ber die Relation user assignment in diese Rolle eingeteilt wird Ein zweiter Vorteil
226. lenbegriffs gibt In der Literatur existieren Rollen als Einheit f r technische Berechtigungen ebenso wie als Einheit f r die Be schreibung von Aufgaben innerhalb einer Organisation An dieser Stelle ist oftmals die Rede von Unternehmensrollen engl enterprise roles oder Gesch ftsrollen engl business roles w hrend bei technischen Berechtigungen von IT Rollen engl T roles oder technischen Rollen engl technical roles gesprochen wird Um diesen Sachverhalt zu vereinheitlichen wird in die ser Arbeit durchg ngig von Gesch ftsrollen und Systemrollen gesprochen Die vorliegende Arbeit kn pft mit der Forderung einer expliziten Trennung des Rollenbegriffs auf Modellebene genau an dieser Stelle an und entwickelt ein Rollenmodell welches diesen Unterschied explizit formalisiert Dieses Ziel orientiert sich daran dass es prinzipiell zwei unterschiedliche Sichten auf ein Unternehmen gibt was sich in diesen beiden Auffassungen des Rollenbegriffs aus dr ckt Die eine Sicht ist sehr technisch orientiert betrachtet die eingesetzten Systeme sowie die darin enthaltenen Zugriffsrechte Hier stellt eine Rolle eine Menge von Zugriffsrechten auf ein oder mehrere Systeme dar was ohne Beschr nkung der Allgemeinheit als Systemrolle bezeich net wird Im Gegensatz dazu abstrahiert die zweite Sicht von technischen Details und betrachtet die Organisationsstrukturen innerhalb des Unternehmens und dessen Gesch ftsfunktionen was sich etwa in Gesch
227. letzungen ange zeigt werden engl identity audit policy violation Auf diese Weise w rde die IT Administration von c amp m direkt dar ber informiert dass der Policy Umfang der Rolle nicht ausreicht und f r die Dauer der geplanten System nderung von ed tec erweitert werden muss Forschungsgruppe C amp M Fallstudie zur Anwendung der Modelle in einem kommerziellen Produkt 131 7 3 Res mee In diesem Kapitel wurden die Rollenmodelle die in dieser Arbeit entwickelt wurden in einem Beispielszenario angewandt Dadurch wurde die Tragf higkeit sowie die Relevanz dieser Arbeit demonstriert Die wesentlichen Inhalte dieses Kapitels sollen nun kurz zusammengefasst wer den Zun chst wurde ein Beispielszenario eingef hrt welches mehrere Unternehmen aufweist die miteinander in Beziehung stehen Neben der Erw hnung der Gesch ftsmodelle dieser Unter nehmen wurde ein Ausschnitt der existierenden Gesch ftsrollen gegeben sowie eine Menge an technischen Systemen zusammen mit darin definierten Berechtigungen vorgestellt Auf dieser Grundlage wurde in Kapitel 7 2 1 mit dem Sun Role Manager ein Rollenmanagementwerkzeug bestimmt in welchem BRBAC gem dem daf r definierten Vergehen umgesetzt werden sollte Insbesondere die M glichkeit Gesch fts und Systemrollen wenn auch nur eingeschr nkt formalisieren zu k nnen die Unterst tzung eines hybriden Vorgehens zusammen mit role mining Algorithmen im Rollenentwurf und die Unterst tzu
228. liance Detective Controls Z Rule Discovery Temporary Assignments 5 Direct Management Continuous Monitoring Involvement Role vs Actual Risk Metrices Adapted from Ka07b page 36 Information 28 State of the Art Sun Role Manager Component Architecture Information 28 schildert welche Bereiche des Rollenmanagements von SRM abgedeckt wer den Dabei sind die Gesch fts und die technische Ebene eingetragen um den Bezug zu dem f r diese Arbeit grundlegenden Schaubild in Information 1 herzustellen Wie bereits angedeutet ist die zentrale Komponente des SRM das identity warehouse ein Metaverzeichnis welches den Komponenten von SRM zugrunde liegt und die Schnittstelle zu den unterschiedlichen Unter nehmenssystemen darstellt Sun08a Diese Datenbank wird somit von den drei Arbeitsberei chen role engineering role management identity certification und identity audit gleicherma en verwendet In den folgenden Unterkapiteln werden die in ihnen enthaltenen Funktionen pro zessorientiert veranschaulicht SRM kann in zwei unterschiedlichen Varianten in einer Unter nehmensstruktur eingesetzt werden Zum Einen kann es als alleinstehende Variante engl stand alone betrieben werden so dass die Daten der Endsysteme dem identity warehouse ma nuell zugef hrt werden m ssen und zum Anderen als integrierte L sung mit einer Identit tsma nagementanwendung in der beispielsweise eine Provisionierungsplattform die Kommunikation zu den E
229. lications Information 18 State of the Art Omada Identity Manager Component Architecture Information 18 pr sentiert die Software Architektur des Omada Identity Manager Hier sind die Arbeitsbereiche des OIM mit den darin enthaltenen Komponenten dargestellt und in Bezug ge setzt zur eben angesprochenen technischen Ebene engl technical layer Diese Ebene bein haltet alle im Unternehmen eingesetzten Systeme aus denen OIM die technischen Informatio nen wie etwa Zugriffsberechtigungen Identit ten der Benutzer oder auch Rollen beziehen kann falls eines der Endsysteme dieses Konzept bereits unterst tzt OIM kommuniziert mit die sen Systemen ber eine Provisionierungsplattform als Middleware somit nur indirekt Die Komponente connectivity realisiert die Datenkommunikation zu den Endsystemen Dazu verf gt sie ber Managementagenten engl management agents ber die OIM mit der Provi sionierungsplattform kommuniziert Diese ist daf r verantwortlich die Daten der angeschlosse nen Unternehmenssysteme in einem Metaverzeichnis zu aggregieren und diesen Datenbestand f r OIM zug nglich zu machen Eine zweite M glichkeit der Interaktion mit den Unterneh menssystemen erfolgt ohne explizite Indirektion durch eine Provisionierungsplattform Hierbei importiert der Omada Identity Manager aus einer kleinen Auswahl an Datenquellen direkt oder exportiert dorthin was in der Abbildung als data exchange bezeichnet wird Der Arbeitsbereich
230. licher und technischer Aspekte Auch bei der technischen Umsetzung dieses Modells muss dieses Ziel aufgegriffen werden da in den vier Phasen Mitarbeiter beteiligt sind die ber unterschiedliche Sichten auf das Unternehmen verf gen und innerhalb der Phasen unterschiedliche Teilziele realisieren Dies f hrt zur Formulierung des Ziels Z nach einer Differenzierung bei der Informationsakquise die zur Umsetzung von Rollen ben tigt werden Viele Vorgehensmodelle betrachten den Entwicklungsprozess in An lehnung an die klassische Software Entwicklung als iterativ der mit der finalen Abnahme durch den Kunden endet Ba96 Anders als klassische Software unterliegen Zugriffskontrollarchitek turen jedoch st ndigen nderungen was Anpassungen des Rollenmodells nach sich zieht und bei dem hier entwickelten Vorgehensmodell explizit beachtet werden soll Dies resultiert in der Definition des Ziels Z welches den Lebenszyklus einer Rolle auch nach der berf hrung in den Wirkbetrieb in einer eigenen Phase Kapselt Die Basis hierf r stellen Beitr ge aus KK 02 SA 04 und WW07 dar in denen die Implementierung von Rollenmodellen als zyklischer Prozess dargestellt wird der konzeptionelle Verwaltungsaufgaben modelliert die nach der fina len Abnahme eines Rollenmodells auftreten Auch werden mit top down bottom up und midd le out drei unterschiedliche Vorgehensweisen beim Entwurf unterschieden die sich in diesem Vorgehensmodell wiederfinden werden Im F
231. liegenden Hierarchiestufen e Uberschreiben bei gleichen Zugriffsrechten verbieten Ein zweiter Steuerungsme chanismus wird als no override bezeichnet Durch die Vererbung von Rechten ist es m glich dass gewisse Rechte mehrfach vergeben werden und sich im Zugriffsumfang unterscheiden Als Beispiel hierf r sei ein Szenario gegeben in dem der Zugriff auf ein spezielles Endsystem in zwei Rollen definiert sei In der in Kapitel 4 3 1 gew hlten Ab straktion einer Policy als Attribut Wert Paar entspr che dieser Sacherverhalt zwei Poli cys die sich nicht im Autorisierungsattribut sondern im Attributwert unterscheiden Forschungsgruppe C amp M Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen 83 Erhielte ein Benutzer diese beiden Rollen verf gte er somit ber zwei Policys die f r dasselbe Recht einen unterschiedlichen Rechteumfang definieren Falls dieser Konflikt erkannt w rde k nnte damit in unterschiedlicher Weise umgegangen werden Durch die Bildung von Vereinigungs oder Schnittmengen w rde dem Benutzer entweder die restriktivere oder die umfangreichere Rechtemenge zuteil Eine dritte M glichkeit mit diesem Konflikt umzugehen ist einen Verantwortlichen zu informieren und bis dahin beide Rechte zu gestatten oder zu unterbinden Da die Vergabe von widerspr chlichen Rechten im Allgemeinen nicht beabsichtigt geschieht f hren alle diese geschilderten Ans tze zumindest potentiell zu Missverst ndnisse
232. ll dar in dem die Zugriffsberechtigungen die den Zugriff eines Benutzers auf ein Ziel spezifizieren explizit vom Benutzerkonto getrennt sind Um diesen Ansatz zu motivieren wird hier auf die Subjekt Objekt Relation eingegangen und diese in Beziehung gesetzt zum Paradigma der rollenbasierten Zugriffskontrolle Die Subjekt Objekt Relation kann im Bereich des Identit tsmanagements als Basis f r Zugriffs kontrollmodelle angesehen werden wie Em08 belegt In Anlehnung daran werden hier die Konzepte Subjekt und Objekt eingef hrt Dabei repr sentiert das Element Subjekt stets ein anfragendes Element beim Zugriff auf ein gewisses Ziel Das Zugriffsziel wird als Objekt bezeichnet und steht allgemein f r jedes vor unbefugtem Zugriff zu sch tzendes Element Durch die Verkn pfung zwischen diesen beiden Elementen die in Form einer Relation ausged r ckt werden kann wird die Zugriffsberechtigung spezifiziert die das zugreifende Subjekt auf das zu sch tzende Objekt besitzt In der rollenbasierten Zugriffskontrolle wird an diesem Prin zip festgehalten jedoch wird zwischen Subjekt und Objekt eine Indirektionsstufe eingef hrt die Rolle genannt wird Durch die Trennung von Subjekt und Objekt wird die Zugriffsberechti gung nun nicht mehr zwischen diesen beiden Elementen definiert sondern stattdessen zwischen dem neu eingef hrten Element Rolle und dem Objekt Eine zus tzliche Relation wird f r die Verkn pfung der E
233. lt eine Vermischung von gesch ftlichen und technischen In Forschungsgruppe C amp M 74 Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen formationen dar was in diesem Modell ja explizit vermieden werden soll indem beide Sichtweisen differenziert werden Zudem f hrt die Forderung nach einer konformen Syntax auf Gesch fts und Systemebene zu einer Komplexit t beim Implementieren ei nes Rollenmodells da nicht davon ausgegangen werden kann dass gewachsene Struk turen dieser Namenskonvention entsprechen Diese Konformit t m sste demnach erst hergestellt werden was eine nderung der vorhandenen Strukturen n tig macht Das Ziel dieser Anforderung ist aber gerade die Komplexit t des resultierenden Rollenmo dells zu verringern 4 2 Trennung von Gesch fts und Systemsicht 4 2 1 Modellierung von Gesch fts und Systemrollen Wie in den Anforderung A zur Modellerweiterung bereits begr ndet wurde besteht Nachbes serungsbedarf bei der Definition dessen was unter einer Rolle verstanden werden kann Im Kontext heterogener Systeme mit dem Ziel die Zugriffskontrolle zu homogenisieren muss zwi schen einem gesch ftsorientierten und einem technisch gepr gten Rollenverst ndnis unterschie den werden Diese Unterscheidung hat zur Folge dass Zugriffsrechte nunmehr danach unterteilt werden ob sie f r gesch ftliche Rechte im Sinne von Aufgaben oder Jobprofilen oder f r tech nische Rechte im Sinne von Zug
234. lte 5 5 Betriebsphase Der zentrale Aspekt dieser Phase ist die Pflege des Rollenmodells im Wirkbetrieb Anders als bei klassischer Software unterliegt die Facharchitektur bzw die zugrundeliegende Zugriffskont rollarchitektur fortw hrend nderungen Wie aus Information 46 bereits hervorgeht weist diese Phase als einzige eine R ckkopplung auf sich selbst auf womit ausgedr ckt werden soll dass die Betriebsphase eine fortlaufende Phase im Lebenszyklus des Rollenmodells darstellt wie in A gefordert wurde Forschungsgruppe C amp M 104 Entwicklung eines Vorgehensmodells fiir die rollenbasierte Zugriffskontrolle Vorgehen in der Betriebsphase Diese Phase richtet sich an die technische Fachabteilung in gleichem Ma e wie an die Rollen verantwortlichen im Unternehmen Diese arbeiten nun an dem Rollenmanagementwerkzeug zur Verwaltung von Rollen Berechtigungen und Policys auf unterschiedlichen Ebenen und mit un terschiedlichem Detailverst ndnis Die nderungen die sich in dieser Phase ergeben k nnen dabei grob in zwei Arten unterteilt werden nderungen die das Rollenmodell selbst betreffen sowie nderungen der technischen Endsysteme Der erstgenannte Fall beschreibt nderungen an den Zuweisungen von Rollen Benutzern oder Policys und nderungen am Rollenmodell engl role engineering role entitlement manage ment policy management Zuweisungsanpassungen treten dabei wesentlich h ufiger auf da das Hinzuf gen von Benutz
235. lung von c amp m und unterst tzt diese bei technischen nderungen Aus diesem Grund ben tigt diese Rolle administrativen Zugriff auf die c amp m Infrastruktur Dies betrifft einerseits den Verzeichnis dienst aber auch das CMS System ed tec Der dritte Dienst der Netzwerkfreigaben erm glicht ist f r den Consultant nicht von Belang so dass hierf r keinerlei Rechte vergeben werden m s sen Der Service Manager der Firma ed serv k mmert sich um die Pflege der Serversysteme von c amp m ben tigt also das Recht sich an diesen Systemen anmelden zu k nnen Ihm soll es aller dings nicht gestattet sein die Dienste von c amp m zu nutzen oder Einblick erhalten zu K nnen Forschungsgruppe C amp M 128 Fallstudie zur Anwendung der Modelle in einem kommerziellen Produkt weswegen ihm weder Rechte auf ed tec noch auf den Dateiserver einger umt werden Den Ge sch ftsrollen von i2s General Manager 12s sowie Course participant i2s wird die M glichkeit einger umt am Schulungsangebot von c amp m teilzunehmen Dies bedeutet dass sie Zugriff auf ed tec sowie den Dateiserver ben tigen wo zus tzliche Daten zu den ange botenen Schulungen abgelegt sind Aus diesem Grund ben tigen beide Gesch ftsrollen auch Benutzerkonten in der c amp m Infrastruktur Gleiches gilt f r die Gesch ftsrolle General Ma nager c amp m Es sei an dieser Stelle angemerkt dass diese Rolle in der c amp m Infrastruktur weit mehr Rechte besitzt da dies allerdings a
236. lungen in dividuelle constraints bei technischen Berechtigungen vorhanden sind Die technischen Rechte h ngen dann nicht nur von der Rolle selbst ab die ein Benutzer aus bt sondern auch von ande ren Einschr nkungen wie etwa dem Standort Diese Arbeit greift dabei den Mechanismus der Joker Berechtigungen aus dem ERBAC Modell aus Ke02 auf Diese Form der Berechtigung verf gt ber constraints die als Bedingung aufgefasst werden k nnen Ein Benutzer kann in die mit der Joker Berechtigung verkn pfen Rolle nur eingeteilt werden wenn die Bedingung er f llt ist Der interessante Unterschied zu gew hnlichen constraints besteht darin dass die Be dingung nicht statisch festgelegt ist sondern von einem Attributwert im Benutzerkonto abh ngt In Ke02 wird dies dadurch modelliert dass die Bedingung von einem Attribut im Benutzer konto abh ngt und der Wert dieses Attributs syntaktisch der Nomenklatur eines speziellen End systems entspricht In Abh ngigkeit vom Attributwert wird der Benutzer dann in eine entspre chende Gruppe eingeteilt Das bedeutet insbesondere dass diejenigen Mitarbeiter des Unternehmens die die Benutzerkonten konfigurieren die Architektur des Endsystems kennen und verstehen m ssen um den Attributwert an die Namensgebung des Endsystems anpassen zu k nnen wovon in der Regel nicht ausgegangen werden kann Dadurch vermischen sich Spezifi ka aus der gesch ftlichen und der technischen Ebene Diese Schwachstelle
237. m SoD ist durch die Verwendung von expliziten Gesch fts und Systemrollen die sich wechselseitig ausschlie en k nnen trivial Es werden hierf r Rollen definiert die sich gegensei tig ausschlie en Dabei Kann nun explizit zwischen sich wechselseitig ausschlie enden Ge sch fts und Systemrollen unterschieden werden Auch dieser Aspekt wird nicht n her betrach tet Wie dieses Kapitel zeigen wird f hrt BRBAC alleine durch die Trennung von Rollen bereits zu einer deutlichen Komplexit tsreduktion Durch Information 56 wird die Komplexit t bei der Verkn pfung von Rollen bereits deutlich obwohl in diesem Szenario lediglich neun Gesch fts und neun Systemrollen vorkommen Ohne die farbliche Markierung der Beziehungen w rde bereits dieser kleine Teilausschnitt eines Un ternehmens undeutlich werden Es soll nun das Potential des Systemrollenkonzepts von BRBAC verdeutlicht werden Dazu werden Muster in den Zugriffen analysiert und Systemrol Forschungsgruppe C amp M Fallstudie zur Anwendung der Modelle in einem kommerziellen Produkt 129 len konzipiert die System Policys aggregieren Im hier gew hlten Beispiel l sst sich etwa er kennen dass sich ein eingeschr nkter Zugriff auf die c amp m Infrastruktur dadurch auszeichnet dass er die System Policys Domain User Reader ed tec und Read Access auf den Dateiserver besitzt F hrt man eine exemplarische Zusammenfassung der System Policys konsequent fort f hrt dies zur Bildung von f
238. m Universit t Karlsruhe TH _ m Fakult t f r Informatik Forschungsuniversit t gegr ndet 1825 z Institut f r Telematik Cooperation amp Management Prof Dr Sebastian Abeck Rollenmodelle f r die Zugriffskontrolle in Unternehmen Diplomarbeit von Korbinian Molitorisz Verantwortlicher Betreuer Prof Dr Sebastian Abeck Betreuender Mitarbeiter Dr Ing Christian Emig Bearbeitungszeit 01 Juni 2008 21 November 2008 Universit t Karlsruhe TH Institut f r Telematik Geb 20 20 Zirkel 2 76131 Karlsruhe Ehrenw rtliche Erkl rung iii Ehrenwortliche Erklarung Ich erkl re hiermit die vorliegende Arbeit selbstst ndig verfasst und keine anderen als die an gegebenen Quellen und Hilfsmittel verwendet zu haben Karlsruhe den 21 November 2008 Korbinian Molitorisz Forschungsgruppe C amp M Inhaltsverzeichnis v Inhaltsverzeichnis 1 Einleitung 1 1 1 Einf hrung in das Themengebiet uusscnsssnsssesssssnssnsnnsnnnsnnnnnsnnennnnsnnnnnnns nn 1 1 2 Inder Arbeit behandelte Fragestellungen ussscsssssnesensessnnnnennnnnnnnnn essen 3 1 3 Beschreibung des Demonstrators 0 ceeceesseceesceceeeeeesaeceeaceceeeeecsaeeeeaaeceeaeeceeeeesaecseaaeceeees 6 1 4 Gliederung der Arbeit 822 aa RN ck cane cobs E aer nae Ea iee taa a anegia 8 1 5 Rechtschreibung und Typografie 00s00ussssesssneesnsessnnnnnnnensnneensnnennsnnnnnnnnsn essen 9 2 Grundlagen 11
239. m Widerspruch zu einem constraint stehen Im Fall von AddActiveRole muss ein bestehendes constraint erkannt werden sobald durch das Aktivieren einer Rolle eine Verletzung eines dynamischen SoD constraint verursacht w rde Die Semantik im Falle von constrained RBAC with hierarchies entspricht derje nigen von hierarchischem RBAC o CreateSession Erzeugt eine Benutzersitzung und stellt die aktiven Rollen f r den gew hlten Kontext unter Beachtung dynamischer SoD Beschr nkungen zusammen o AddActiveRole F gt eine Rolle in die Menge aktiver Rollen f r diese Sit zung ein falls keine dynamischen SoD Verletzungen hervorgerufen werden o DropActiveRole Entfernt eine Rolle aus der Menge der aktiven Rollen f r die Sitzung Funktionen zur berarbeitung Zur Implementierung von hierarchischem RBAC mit dynamischen constraints sind alle berarbeitungsfunktionen aus core RBAC g ltig So wie f r die berarbeitungsfunktionen im statischen Fall sind auch hier zus tzliche Funktionen n tig um die drei Parameter zu bearbeiten die durch das 3 Tupel einge f hrt wurden Gesch ftsprozess Rollen Kardinalit t Forschungsgruppe C amp M Grundlagen 23 o dSoDRoleSets Liefert fiir eine dSoD Relation die Menge definierter Instan zen zur ck o dSoDRoleSetRoles Liefert die Menge an Rollen zur ck f r die eine dSoD Instanz definiert wurde o dSoDRoleSetCardinality Liefert die Kardinalit t der Instanz zur ck Dies beend
240. managementwerkzeugen aus Information 11 werden hier die Funktionen policy management attestation and compliance role reconciliation und activity monitoring realisiert Durch die Komponente attestation wird der Prozess realisiert der die Zuweisung von Zugriffs rechten berpr ft Dies kann in OIM teilautomatisiert werden indem dieser Prozess zu regel m igen oder wiederkehrenden Zeitpunkten ausgef hrt wird Durch die Komponente identity reconciliation die einen Abgleich der Identit ten in den Endsystemen vornimmt wird erm g licht dass OIM als zentrale Stelle f r die Zugriffskontrolle verwendet werden kann Hierf r ist es insbesondere notwendig dass OIM ber nderungen informiert wird die sich au erhalb der Verwaltung von OIM ergeben Dies ist zum Beispiel dann der Fall wenn Zugriffsberechtigun gen in einzelnen Unternehmenssystemen selbst ver ndert werden Ist dies der Fall kann das ein Anzeichen daf r sein dass ein Verantwortlicher aufgrund von Unkenntnis die Zugriffsrechte in diesem Unternehmenssystem vorgenommen hat statt dies ber OIM zu erledigen Es stellt sich bei nderungen au erhalb von OIM generell die Frage ob es sich dabei um geplante nderun gen der Zugriffsrechte handelt oder um eine Policy Verletzung OIM sieht beim Auftreten einer solchen Situation seine eigene Datenbank als privilegiert an und macht die vorgenommenen nderungen r ckg ngig um so die Konsistenz wiederherzustellen Durch die Komponente Iden
241. men Hierbei sind der Datenbankserver die konkrete Datenbank sowie der Sicherheitskontext in folgender Syntax anzugegeben User D lt Benutzername gt Password lt Passwort gt Initial Catalog lt Datenbankname gt Data Source lt Datenbankserver gt Zu diesem Zeitpunkt ist Omada Enterprise tiber folgende Adresse erreichbar http lt Adresse des Servers gt lt Name der Webanwendung gt Bei der Installation wurde ein Administrator in OE angelegt mit dem Benutzernamen Admi nistrator und einem leerem Passwort Es wird empfohlen zu diesem Zeitpunkt noch keine Sys temkonfigurationen vorzunehmen weil im n chsten Schritt die Erweiterung OIM installiert wird die eine Schemaerweiterung der Datenbank vornimmt A 3 Installation und Konfiguration von Omada Identity Manager Die Erweiterungen von OIM werden in das Verzeichnis von OE installiert und automatisch in IIS erg nzt OIM verf gt ber ein SQL Script welches in der Verwaltungskonsole des SQL Servers ausgef hrt werden muss Dieses liegt in folgendem Ordner bereit lt OIM Installationsordner gt bin scripts Die Ausf hrung des Scripts dber oim X sql erweitert das Datenbankschema und beendet die Installation des Omada Identity Manager Nachdem die Installation von OIM abgeschlossen ist kann dieser ber die bereits erw hnte Adresse aufgerufen werden um zus tzliche administrative Konfigurationen vorzunehmen Beispielsweise kann e
242. mit wechselnder Semantik ist Zweitens muss man sich bewusst sein dass man sich bei der Verwendung eines Rollenlebens zyklus Techniken zur Wiederverwendung bekannt aus der Software Entwicklung eingehen befasst hat L sungen Was sind die eigenen L sungen L1 Es wird ein life cycle Modell vorgestellt basierend auf einem iterativen aufeinander auf bauenden Prozess in Anlehnung an den klassischen Software Entwicklungszyklus L2 In der Analysephase engl analysis wird die Organisationsform des Unternehmens und Rollen auf einer sehr abstrakten Ebene formalisiert und der Entwurfsphase engl design in Form von Artefakten bergeben Hier werden die Rollen technisch verfeinert und auf die Struk turen der Unternehmenssysteme transformiert Sobald dies geschehen ist beginnen in der Ver waltungsphase engl management administrative Aufgaben Da Rollen wie jede systematische Information nderungen unterlegen ist muss in der berpr fungsphase engl maintenance si chergestellt werden dass sich die Rollen sowie das implementierte Rollenmodell an diese n derungen anpassen L3 Die Autoren pr sentieren ein Prozessmodell und weisen daraufhin dass ein solches Modell immer nur eine gewisse Perspektive eines Entwicklungsprozesses darstellen kann Auch in die ser Publikation wird nur ein Teilausschnitt vorgestellt Forschungsgruppe C amp M Anhang 161 L4 Der klassische Software Entwicklungsprozess bestehend aus den P
243. n Benutzer werden dazu diesen Rol len zugeordnet um die darin definierten technischen Zugriffsrechte zu erhalten Der Unter schied zwischen dem Enterprise RBAC Modell ERBAC und dem zugrundeliegenden NIST RBAC Standardrahmenwerk liegt neben dem Rollenbegriff im Modellelement Sitzung engl session welches in ERBAC nicht vorhanden ist Unternehmensweite Rollen wie sie hier ver wendet werden abstrahieren von den technischen Endsystemen und verlieren somit den direk ten Bezug zu diesen In ERBAC wird der Kontext der ja gerade die Sitzung symbolisiert im plizit durch die Verkn pfung eines Benutzers mit einem oder mehreren technischen Benutzerkonten ausgedr ckt statt ihn explizit zu definieren Rollen ihrerseits bestehend aus ei ner Menge an Benutzern haben daher keinen direkten Bezug zu einem Kontext Wie Informa tion 13 zeigt werden die Berechtigungen die ein Benutzer durch die Zuweisung zu Rollen er h lt zum entsprechenden Endsystem engl technical system TS durchgereicht was zu der Erzeugung eines Benutzerkontos engl account in diesem System f hrt Eine Berechtigung Forschungsgruppe C amp M Stand der Technik 33 steht in diesem Modell f r eine Operation aus dem RBAC Standard und kann jede Art der Autorisierung darstellen die in dem entsprechenden Endsystem formuliert werden kann In An lehnung an das hierarchical RBAC Modell wird auch in diesem Rollenmodell eine Rollenhie rarchie eingefiihrt was durch eine
244. n In diesem Modell wird durch das Attribut no override eine M glichkeit gegeben mit mehrfach definierten Rechten effi zient umzugehen Dazu wird davon ausgegangen dass in der Hierarchie weiter oben de finierte Rechte mehr Gewicht haben und von tiefer liegenden Policys nicht berschrie ben werden k nnen Dies l st die Mehrdeutigkeit bei der Vererbung auf und erm glicht es dar ber hinaus gewisse Rechte f r den gesamten Hierarchiebaum vorzugeben und durchzusetzen Es dient daher sowohl der feingranularen Steuerung von Rechteverer bungen als auch zur Verringerung von Komplexit t Durch dieses Attribut Kann festge legt werden dass gewisse Rechte von hierarchisch tieferliegenden Rollen nicht ber schrieben werden k nnen Nachdem diese beiden Mechanismen eingef hrt wurden soll nun auf das Zusammenspiel von Policy Vererbung und SoD constraints eingegangen werden um aufzuzeigen was bei techni schen Umsetzungen beachtet werden muss Bisher wurden mit SoD und der Rechtevererbung zwei Techniken vorgestellt die dem Rollenmodell Dynamik verleihen Dadurch m ssen ver schiedene Szenarien betrachtet werden in denen diese Techniken zusammentreffen um daraus abzuleiten ob es hierbei zu Komplikationen kommen kann Wie bereits beschrieben wurde operiert SoD auf der Basis von Rollen und die Rechtevererbung auf der Basis von Policys Es kann demnach passieren dass eine Rolle aus einer Menge von Policys besteht die ihrerseits mit den beiden erw
245. n An gestellten ausgef hrt werden darf weil es dadurch m glich w re dass ein und dieselbe Person einen Kredit gew hrt und auszahlt Ohne dynamisches SoD m ssten daf r nun zun chst zwei Rollen definiert werden die sich durch statisches SoD gegenseitig aus schlie en Dann w re es allerdings auch nicht mehr m glich dass ein Bankangestellter sowohl Kredite bewilligen als auch auszahlen darf Will man den geschilderten Sach verhalt ohne dynamisches SoD modellieren ist das nur durch eine explizite Trennung des Kontextes m glich Rollenmanagementl sungen wie sie in den Kapiteln 3 2 und 3 3 vorgestellt wurden verfolgen auch das Ziel von den Endsystemen zu abstrahieren um so die Komplexit t zu verringern die aus der Verwendung von unterschiedlichen Technologien entsteht Um dies zu erreichen wird eine zentrale Benutzeroberfl che angeboten um die Kom munikation zu diesen Systemen durch die Rollenmanagementl sung zu automatisieren Mit dieser zentralen Forderung abstrahiert man allerdings vom Kontext was die Ver wendung von dynamischem SoD ausschlie t Die technischen Implementierungen von rollenbasierter Zugriffskontrolle basieren auf den NIST RBAC Modellen hierarchi sches RBAC siehe Kapitel 2 2 2 bzw hierarchischem RBAC mit constraints vgl Kapitel 2 2 3 welche in bereinstimmung mit dem RBAC Kernmodell engl core RBAC Kapitel 2 2 1 ebenfalls ber ein Modellelement f r eine Sitzung engl session verf
246. n Information 52 ist die Bewertung des Omada Identity Manager aufgef hrt Die sieben Krite rien werden im Folgenden nun einzeln bewertet Rollen Der Omada Identity Manager OIM bietet ein Rollenmodell welches sehr individuell anpass bar und somit sehr flexibel ist Dies f hrt jedoch auch dazu dass abweichend vom RBAC Standard Objekte als Rolle definierbar sind die es der Definition nach nicht sind So kann in OIM etwa ein Benutzer selbst eine Rolle darstellen Die Unterscheidung unterschiedlicher Rol lentypen geschieht in OIM ber frei w hlbare Rollenkategorien engl role categories Es exis tieren beispielsweise die Kategorien Systemrollen und Jobprofile wodurch Gesch fts von Systemrollen unterschieden werden k nnen Rollenkategorien werden als Attribute von Rollen dargestellt so dass die Unterscheidung zwar vorhanden ist wenn auch nur implizit Eine Er schwernis im Umgang mit OIM stellt ein weiteres Attribut von Rollen dar das ebenfalls ver wendet wird Jede Rolle verf gt ber einen Rollentyp engl role type wodurch die Unter scheidung von Gesch fts und Systemrollen redundant vorgenommen wird An dieser Stelle wird von OIM keine Konsistenz berpr fung vorgenommen so dass eine Rolle vom Typ Ge sch ftsrolle auch gleichzeitig in die Rollenkategorie Systemrolle eingeteilt werden kann Der Identity Manager erm glicht es im Rahmen von Rollen dass ein Benutzer ber sogenannte se kun
247. n Schwachstellen im Prozess erkannt oder zeitliche Verz gerungen identifiziert werden Wie im berblickskapitel 3 2 1 erw hnt wurde bietet OIM f r die Bereit stellung dieser Funktionen mehrere Komponenten an die im Folgenden einzeln betrachtet wer den Die Komponente attestation befasst sich mit den Berechtigungen die eine Rolle im Laufe ihrer Existenz besitzen kann Dabei werden mehrere M glichkeiten angeboten die Zuweisung von Berechtigungen zu berpr fen Wie schon im ersten Arbeitsbereich role management erleich tern auch hier die workflows diese Arbeiten So ist es etwa m glich dass ein Rollenverantwort licher die Berechtigungen seiner Benutzer in regelm igen Abst nden berpr ft verifiziert und Forschungsgruppe C amp M Stand der Technik 51 gegebenenfalls anpasst An dieser Stelle wird das zentrale Konzept der individuellen views deut lich Je nach Befugnis des Verantwortlichen wird individuell festgelegt welche Eigenschaften von ihm eingesehen und dadurch auch aktiv analysiert werden k nnen Der Besitzer einer Rolle kann beispielsweise s mtliche Ver nderungen dieser Rolle f r das gesamte Unternehmen einse hen und vornehmen ein Manager hingegen nur diejenigen Rolleneigenschaften die in seinem Verantwortungsbereich liegen Im Gegensatz zum Rollenbesitzer kann der Manager diese Ei genschaften aber von allen Rollen beeinflussen die die Angestellten seiner Abteilung besitzen und nicht nur von einer Rolle Eine w
248. n Vorgehensmodell was zur Entwick lung von Gesch fts und Systemrollen f hrt was sich insbesondere in den ersten beiden Phasen zeigt In der Analysephase steht im Vordergrund den aktuellen Datenbestand zu erfassen und die An forderungen des Kunden an den Einsatz von BRBAC zu formalisieren Dazu wird die direkte Kommunikation und Interviews als Methodik verwendet Die Erfassung des Ist Zustands unter teilt sich in zwei voneinander unterschiedliche Bereiche den Gesch fts und den Systembe reich Es entsteht somit ein Lastenheft das neben den Anforderungen des Kunden gesch ftliche und technische Aspekte auf geeignetem Abstraktionsniveau formal erfasst Die Verifikation die ser Artefakte durch den Kunden beschlie t die Analysephase In der Entwurfsphase werden diese Artefakte dann spezifiziert und dabei verfeinert Aus dem gesch ftsnahen Ist Zustand werden unter Beachtung der formalisierten Kundenanforderungen per top down Vorgehen Gesch ftsrollen entwickelt die ber Verantwortliche und Abteilungen verf gen Auf technischer Ebene hingegen entstehen per bottom up V orgehen Systemrollen als Zusammenfassung unterschiedlicher Policys Das Lastenheft wird insgesamt zu einem Pflich tenheft konkretisiert in dem die Ergebnisse der Rollenspezifikation Einzug erhalten Auch diese Phase wird durch die Abnahme durch den Kunden beendet Die Implementierungsphase selbst besteht aus zwei Teilen der Installation des Rollenmanage mentwerkzeugs im Un
249. n als Attribut Wert Paare modelliert werden und sich die festgelegten Rechte innerhalb einer Rolle dadurch nicht unterscheiden k nnen Das Attribut steht hierbei f r den eigentlichen Zugriff und der Wert f r den Umfang des Zugriffsrechts Daher m ssen zwei Attribut Wert Paare mit unterschiedlichen Wertbelegungen als zwei separate Zugriffsrechte angesehen wer den Wie Ke02 belegt unterscheiden sich Rollen oftmals nicht in den Zugriffen selbst sondern nur im Umfang dieser Zugriffe was in der hier gew hlten Abstraktion von Zu griffsrechten als Attribut Wert Paare als unterschiedliche Werte f r dieselben Attribute steht Existieren nun zwei Benutzer die sich nur in der Belegung dieser Werte unter scheiden kann dies nicht mehr in einer einzelnen Rolle abgebildet werden W rde man die beiden Zugriffsrechte in Form von Policys definieren und gemeinsam an eine ein zelne Rolle vergeben h tte sie f r einen Zugriff zwei unterschiedliche Zugriffsrechte Bei einer Autorisierungsanfrage dieser Rolle w rde nun entweder stets eines der beiden Recht angewandt oder die Anfrage k nnte nicht bedient werden weil sie mehrere Er gebnisse zur ckliefert Wollte man den Sachverhalt zweier unterschiedlicher Zugriffs rechte f r ein und dasselbe Zugriffsziel formalisieren m ssten demnach zwei eigene Rollen definiert werden In Ke02 wird in Form der benutzerspezifischen Berechti gungen eine Erweiterung dazu vorgeschlagen die in dem hier pr senti
250. n auf Mechanismen eingegangen wird die zu einer effizienten Verwendung dieser Rollen ausgehend von Policys f hrt was sich an das Ziel Z wendet Dieses Kapitel befasst sich nun mit der Modellierung der drei Anforderungen A A22 und A23 wie im Einf hrungskapitel vorgestellt wurde im Speziellen geht es dabei um die Policys die in den Rollen enthalten sind und die den Grad an Zugriffsrechten spezifizieren 4 3 1 Modellierung von Policys mit Platzhaltern Em08 bezeichnet eine Policy als Inbegriff von Statuten Richtlinien oder Verhaltensregeln f r die Benutzung von Systemen Netzwerken oder Diensten In diesem Zusammenhang steht eine Policy f r eine Abbildung von einer Menge an Attributen auf einen Wahrheitswert der dar ber Aussagen trifft ob der Zugriff gew hrt wird oder nicht In Anlehnung an diese Definition stellt eine Policy hier eine Relation zwischen verschiedenen Attributen und deren Werten her e Policy engl policy Opi T U ATTRIBUTE x VALUE Das Ziel was in diesem Teilkapitel verfolgt wird ist eine m glichst effiziente Verwendung von Rollen zu erm glichen Es stellt sich dabei die Frage inwieweit Modellierungsaspekte bei Poli cys hierf r herangezogen werden k nnen oder sollen Gesch fts und System Rollen bestehen gleicherma en aus Policys die im jeweiligen Anwendungsfall konkrete Zugriffsrechte auf ato marer Ebene darstellen Diese Arbeit will kein explizites Policy Modell entwickeln aber durch aus Anforderu
251. n azyklischen Graph dargestellt wird Ziel der Hierarchien ist einerseits das Abbilden von Organisationsstrukturen auf das Rollenmodell und andererseits das Vererben von Rechten so dass Rollen alle Berechtigungen an diejenigen Rollen weitergeben die im Hierarchiebaum unter ihnen angesiedelt sind Der RBAC Standard definiert im constrai ned RBAC Modell Beschr nkungen engl constraints Dieser Mechanismus wird in Ubereins timmung mit dem Standardmodell in dem hier vorgestellten Modell dazu verwendet um den statischen wechselseitigen Ausschluss von Rechten engl static separation of duties sSoD durchzusetzen Realisiert wird sSoD in Form von Regeln die eine Relation zwischen sich wechselseitig ausschlieBende Rollen herstellen und ausgewertet werden sobald sich an einer Rolleneinteilung etwas ndert Das statische SoD gew hrleistet eine konsistente Rollenstruktur und verhindert Einteilungen die allgemein nicht erlaubt sind Da das ERBAC Modell keine Sit zungen definiert ist es hier nicht m glich dynamisches SoD direkt zu formulieren Stattdessen muss es sich darauf verlassen dass entsprechende Mechanismen in den Endsystemen existieren Die Autoren des ERBAC Modells geben die Aufgabentrennung durch die Verwendung dedi zierter Benutzerkonten als M glichkeit dynamisches SoD zu modellieren Ein Benutzer legt somit seinen Kontext dadurch selbst fest dass er jeweils unterschiedliche Benutzerkonten ver wendet Ke02 3 1 3 Das erweiterte ERBA
252. n bietet OIM keine Unterstiitzung fiir das algorithmische Entwickeln von Rollen engl role mining an Dies f hrt dazu dass der initiale Aufwand sehr hoch ist der n tig ist um eine gewachsene Struktur auf eine rollenbasierte Zugriffskontrollarchitektur um zustellen Es kann weder vorab analysiert werden welche technischen Berechtigungen im Un ternehmen vorhanden sind um diese zu Systemrollen zusammenzufassen noch existiert eine algorithmische Unterst tzung f r das Entwickeln von Gesch ftsrollen Dadurch dass OIM auf dem Identity Lifecycle Manager ILM basiert einem Provisionierungswerkzeug der Firma Microsoft k nnen allerdings Daten aus dem Gesamtdatenbestand der Einrichtung als Basis der Entwicklung bezogen werden Sollten die hier ber bezogenen Daten bereits Rollen aufweisen k nnen diese als Grundlage des Rollenmodells in OIM verwendet werden Automatische Arbeitsabl ufe OIM bietet neben einer eigenen Ausf hrungseinheit f r automatische Arbeitsabl ufe engl workflow engine auch eine in die grafische Benutzeroberfl che integrierte Entwurfskomponen te engl workflow designer an Diese l sst eine sehr individuelle Anpassung von Gesch ftspro zessen zu wobei an dieser Stelle auch Verantwortlichkeiten im Prozess definiert werden k n nen Es werden auch bereits vorkonfigurierte Prozesse mitgeliefert allerdings sind dies keine Gesch ftsprozesse im eigentlichen Sinne sondern automatische Abl ufe f r den Wirkbetrieb des
253. n erkennt hier dass die generischen Rollentypen aus einer Menge von nicht generischen Rollen bestehen Dies wird auch durch die Teilmengenbeziehung von BR und SR deutlich Da eine generische Rolle aus mindestens einer nicht generischen Rolle bestehen im Gegenzug dazu eine nicht generische Rolle aber nicht unbedingt in einer generischen Rolle enthalten sein muss sind die Mengen BR und SR echte Teilmengen von BR und SR e Generische Gesch ftsrollen engl generic business role BR c BR e Generische Systemrollen engl generic system role SR Cc SR e Systemrolle generische Systemrolle Relation engl system role assignment O SRg SR lt SR xSR e Geschaftsrolle generische Gesch ftsrolle Relation engl business role assignment O BRg BR c BR xBR e Gesch ftsrolle Systemrolle Relation generisch engl generic role mapping O BRg SRg lt BR xSR Durch die Kompositionsbeziehung von BR mit BR und SR mit SR sowie die Relation O BRg BR ist eine transitive Assoziation von generischen Gesch ftsrollen und generischen Systemrollen gegeben die im praktischen Einsatz allerdings nicht von Belang ist und nur der mathematischen Korrektheit wegen aufgef hrt ist Im Sinne einer Ontologie stellt diese Assoziation eine Ver kn pfung zwischen den kontext unabh ngigen Rollenbegriffen zwischen der Gesch fts und der Systemdom ne dar Forschungsgruppe C amp M 78 Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemr
254. n gezeigt werden wie res sourcenintensiv dieses Vorgehen tats chlich ist zumal die Passgenauigkeit des Rollenmodells durch die intensive Einbindung des Unternehmens in den Entwicklungsprozess bereits unters t tzt wird Forschungsgruppe C amp M Zusammenfassung und Ausblick 137 Rollenmanagementwerkzeuge verk rpern integrative Zugriffskontrollarchitekturen Aus der Be trachtung bestehender Werkzeuge in Kapitel 6 geht hervor dass beide Werkzeuge keine native Unterstiitzung dienstorientierter Architekturen anbietet Einerseits wird die Kommunikation der Werkzeuge mit den technischen Endsystemen entweder direkt oder unter Zuhilfenahme eines Provisionierungswerkzeug erm glicht und andererseits kann keines der Werkzeuge nativ als Dienstgeber f r parallele Zugriffskontrollsysteme dienen Ein Ansatz der sich in der Zukunft durchsetzen k nnte ist dass jedes der technischen Endsysteme f r die Integration mit Zugriffs kontrollarchitekturen ber Standardschnittstellen abgefragt werden kann und die das Zugriffs kontrollsystem selbst ebenfalls in einem Dienstgeber Dienstnehmer Verh ltnis auftreten kann Das Vorhandensein einer Standardschnittstelle etwa in Form von Webservice Schnittstellen w rde die Verbreitung integrativer Architekturen f r die Zugriffskontrolle stark vorantreiben An dieser Stelle sei verwiesen auf Em08 und Di08 die sich mit der Thematik der Dienst orientierung von Zugriffskontrollarchitekturen genauer befassen
255. n verschiedenen Systemen verf gt Das Zusammenfas sen von Berechtigungen zu Rollen erleichtert zum Einen das Hinzuf gen oder Entfernen von Berechtigungen an Identit ten und zum Anderen das Sicherstellen dass ein angemessener Be rechtigungsumfang zugewiesen wurde C amp M A ID Forschungseinrichtungen erkannten die sen Mehrwert von Rollen als Abstraktionseinheit f r Zugriffsrechte in Computersystemen ge gen ber der direkten Kopplung von Berechtigungen und Benutzern FK 07 In den letzten Jahren entstand daher eine lebhafte Diskussion innerhalb der Forschung mit dem Ziel der For mulierung theoretischer Standardrahmenwerke f r die rollenbasierte Zugriffskontrolle Ka07a Im Bereich der Technik l sst sich heute feststellen dass Rollenmodelle mit einer differenzierten Betrachtung des Rollenbegriffs n tig sind um die unterschiedlichen Rollentypen die faktisch in Unternehmen vorhanden sind bereits auf Modellebene darstellbar zu machen So entstanden in j ngster Zeit mehrere Rollenmodelle f r die rollenbasierte Zugriffskontrolle mit unterschiedli chen Zielsetzungen Das NIST RBAC Standardrahmenwerk definiert vier Rollenmodelle mit unterschiedlicher funktionaler Spezifikation l sst dabei jedoch eine differenzierte Betrachtung des Rollenbegriffs vermissen Das ERBAC Rollenmodell hingegen welches durch praktische Erfahrungen im Umgang mit Rollen inspiriert wurde bertr gt den Rollenbegriff auf die techni sche Umsetzung in Unternehmen und in
256. n wechselseitigen Ausschluss zwei Rollen ohne Beschr nkungen als unvereinbar angesehen werden die im dynamischen Fall nur dann unve reinbar sind wenn im gleichen Kontext agiert wird Dies beendete die Betrachtung der theoreti schen Grundlagen Den Abschluss bildete die Vorstellung typischer Aufgaben von Rollenmana gementwerkzeugen was die Grundlage f r eine eingehende Auseinandersetzung mit zwei Vertretern dieser Werkzeugkategorie darstellte Auf dieser Grundlage wurde dann in Kapitel 3 der aktuelle Stand in Wissenschaft und Technik in den Bereichen der rollenbasierten Zugriffskontrolle und des Rollenmanagements dargelegt Im Bereich der Wissenschaft wurde mit dem ERBAC Modell sowie den Erweiterungen dazu ein aktuelles Rollenmodell vorgestellt welches sich mit den Problemen befasst die aus prakti schen Umsetzungen von NIST RBAC im Unternehmenskontext resultieren Das ERBAC Modell stellt unmittelbar die Grundlage des Rollenmodells BRBAC dar welches in dieser Ar beit entwickelt wurde Des Weiteren wurde ein Modell zur algorithmengest tzten Entwicklung von Rollen vorgestellt das Techniken aus dem Bereich data mining auf den Datenbestand eines Unternehmens anwendet Diese Herangehensweise wird mittlerweile auch in kommerziellen Rollenmanagementwerkzeugen verwendet Den Abschluss aktueller wissenschaftlicher For schungsergebnisse stellte ein Prozessmodell dar welches sich mit dem Lebenszyklus von Rol len befasst In diesem Modell werden zwei s
257. n werde etwa definiert dass die Zugriffsrechte eines Benutzerkontos vom Standort und der Jobfunktion abh ngen Das Ergebnis hiervon ist eine komplexe Rollenstruktur einerseits und eine Vielzahl von Rollen andererseits Die resultierende Rollenstruktur ist deshalb sehr komplex weil f r jede dieser Eigenschaften ein eigener Vererbungsbaum definiert werden muss und f r jede g ltige Kombination dieser Eigen schaften eine eigene Rolle definiert werden muss Im Beispiel w rde jedes Benutzerkonto dem nach schon ber mindestens zwei Rollen verf gen Um diesen Sachverhalt zu simplifizieren wird nur eine einzelne Rollenstruktur in Form einer einzelnen Hierarchie aufgebaut und die an dere Eigenschaft in Form von Attributen parametrisiert Sie ist somit lediglich implizit vorhan den Diese Einschr nkung wird als Attribut der Relation Benutzer Rolle modelliert Durch eine Joker Berechtigung ist es nun m glich lediglich die Attribute zu spezifizieren deren konkrete Werte allerdings zun chst offen gelassen werden Bei der Einteilung eines Benutzers in eine Rolle die ber eine Joker Berechtigung verf gt wird die effektive Zugriffsberechtigung in Form einer Regel berechnet und somit dynamisch vergeben Dabei wird der Attributwert aus dem Benutzerobjekt ausgelesen anstatt ihn manuell vergeben zu m ssen Realisiert wird dies Forschungsgruppe C amp M 36 Stand der Technik durch eine Namenskonvention die vorgibt dass die Syntax der Attributwerte
258. n wird diese An forderung nun motiviert Aktuell zeigt sich ein reges Interesse an rollenbasierten Zugriffskontrollarchitekturen in Wissenschaft und Technik was anhand der Publikationszahlen f r RBAC ersichtlich ist Rollenmodelle die aktuell im Entstehen begriffen sind sollten somit Anforderungen aus beiden Bet tigungsfeldern gerecht werden Hieraus ergibt sich die Forderung nach einer formalen Spezifikation von Rollenmodellen f r den Bereich der Wissenschaft und der Praxisrelevanz f r die Technik Gerade der letztgenannten Forderung wurde bisher nicht in ausreichendem Ma e entsprochen wie Kapitel 3 1 3 bereits belegt In diesem Kapitel wurde eine Erweiterung des ERBAC Modells aus Kapitel 3 1 2 vorgestellt das sich damit auseinandersetzt dass ERBAC in der praktischen Umsetzung zu einer gro en Zahl von Rollen f hrt und somit der urspr nglichen Forderung nach Verringerung von Komplexit t entgegenwirkt Der daraus resultierenden Unzufriedenheit mit Rolle modellen in der praktischen Umsetzung soll sich das hier vorgestellte Rollenmodell stellen Gerade im Hinblick auf die Akzeptanz einer Rollenmanagementl sung im Wirkbetrieb wurde das Rollenmodell BRBAC so entworfen dass es sich positiv auf die Akzeptanz im Unternehmen auswirkt An einer Rollenmanagementl sung arbeiten f r gew hnlich Mitarbeiter unterschiedlicher technischer Qualifikation Der Gro teil davon ist technisch nicht versiert genug um das System in seiner Gesamtheit verste
259. nahmen und Policy Verletzungen SRM verwendet Policys engl policies als Mechanis mus zur Steuerung und berwachung von Rollen So wie bei den anderen beiden Bereichen stellt das identity warehouse auch hier sowohl die Datenquelle aber auch den Speicherort der Ergebnisse dar In diesem dritten Bereich sind das im Speziellen die im Wirkbetrieb aufge zeichneten Ausnahmen und Verletzungen Dadurch bietet sich hier die M glichkeit diese Ereignisse in Echtzeit zu berwachen aber ebenso im Nachhinein Sicherheitsrisiken oder Zu griffsmuster zu entdecken und dadurch die Umgebung dynamisch an die nderungen anzupas sen Das Ziel der identity audit Komponente ist das Sicherstellen dass ein Benutzer nur ber die Gesch fts und Systemrollen verf gt die f r die Erledigung seiner Aufgaben ben tigt wer den Dazu z hlt auch dass die Granularit t der definierten Rechte die durch das Rollenmodell vorgegeben ist an die jeweils aktuellen Richtlinien im Unternehmen angepasst werden kann Die identity audit Komponente erm glicht es dazu einerseits einzelne Benutzer zu analysieren um Verletzungen engl violations etwa des SoD Prinzips aufzudecken und andererseits bietet sie eine Verwaltungsseite an um die Verletzungen und Ausnahmen engl exception am Ge samtsystem in Echtzeit darzustellen Hierzu werden die einzelne Verletzungen in unterschiedli che Kategorien oder H ufigkeitsklassen eingeteilt und aufsummiert angezeigt Durch das sp te re Spei
260. nander aufbauen und klar voneinander abgegrenzt sind Im Allgemeinen existieren auch innerhalb von Abteilungen eine oder mehrere klare Hierarchien Somit kann die Gesch ftshierarchie klar definiert werden Anders verh lt es sich allerdings wenn man statt der Strukturen nun die Berechtigungen auf gesch ftli cher und technischer Ebene betrachtet Hier sind individuell sehr unterschiedliche Rech te vergeben was den Einsatz von RBAC deutlich erschwert Im Gegensatz dazu lassen sich Rechte auf Gesch ftsebene oft nicht formal erfasst sondern sind lediglich implizit vorhanden Ein Hauptziel einer rollenbasierten Struktur ist es die Komplexit t des Ge samtsystems zu verringern Dies f hrt dazu dass der Funktionsumfang von Rollen so konzipiert wird dass diese m glichst effizient wiederverwendet werden k nnen Da die Aufgabenfelder der Abteilungen aber sehr unterschiedlich sind ist es nicht trivial m g lichst generische Rollen zu konzipieren die unterschiedlichen Kontexten gleicherma en gerecht werden Die Auspr gung einer Hierarchie in der Berechtigungen vererbt wer den f llt somit sehr schwer Das zweite Kriterium bewertet ob die eingesetzten Werk zeuge eine Hierarchie auf Gesch ftsebene sowie auf technischer Ebene unterst tzen Dazu z hlt auch in welchem Ma e Berechtigungsvererbung erm glicht wird e Kriterium 3 Automatisiertes Entwickeln von Rollen Es ist eine realistische An nahme davon auszugehen dass Unternehmen ber e
261. nannten Rollenordner engl role folders gegeben die eine Einteilung der Rollen in Gesch ftsrollen und Systemrollen erlaubt wobei die Systemrollen selbst nach der Zu geh rigkeit zu technischen Endsystemen unterteilt sind Auch an dieser Stelle zeigt sich die Flexibilit t von OIM weil hierbei eigene Rollenordner angelegt werden k nnen die eine logi sche Gruppierung unterschiedlicher Rollentypen zul sst Eine Wahrung der Konsistenz ist auch hierbei nicht gegeben da eine Rolle ungeachtet des Typs oder der Kategorie in Ordner eingeteilt werden Kann Auch dieses Attribut l sst lediglich eine eindeutige Zuordnung zu Rollenordnern zu was eine mehrfache Verwendung der definierten Rolle verhindert OIM erm glicht durch die eingebauten workflows dass die Rollenzuweisungen und somit auch die darin definierten Rechte in Abh ngigkeit der Zugeh rigkeit zu Organisationseinheiten automatisch vergeben werden So werden etwa die effektiven Rollen eines Benutzers automatisch aktualisiert sobald dieser Benutzer in eine andere Organisationseinheit eingeteilt wird Von dieser automatischen Einteilung profitieren insbesondere Systemrollen da diese zentral f r eine Organisationseinheit definiert werden k nnen und dadurch die Policy Konformit t f r alle Benutzer dieser Organisa tionseinheit sicherstellen Forschungsgruppe C amp M Analyse aktueller Rollenmanagementwerkzeuge 115 Algorithmische Entwicklung von Rollen In der vorliegenden Versio
262. nd Zus tzlich werden zwei Funktionen eingef hrt die erstens auf Benutzern und zweitens auf Rollen operieren und als Ergebnis die mit ihnen verbundenen strukturellen Objekte zur cklie fern Informationskomponenten spiegeln relationale Datenbanken bzw Verzeichnisdienste als Datenhaltung f r die erstgenannten Komponenten und den Beziehungen zwischen ihnen wieder L sungen Was sind die eigenen L sungen L1 RolePartner stellt ein Technologiewerkzeug dar welches das Definieren von Rollen zu sammen mit Hierarchien und Benutzern erm glicht und orientiert sich damit am erweiterten RBAC Modell Es verfolgt eine 3 Tier Architektur bestehend aus UI Diensten und dem Netz werkinterface als Schnittstelle zur Datenbankschicht L2 Der eigene Ansatz teilt die Verwaltung in die beiden diskreten Bereiche role engineering und role administration L3 Ein zentraler Aspekt des RolePartners ist das logische Trennen der Datenhaltung der RBAC Policy von dem Ort der Anwendung Durch diese Trennung wird die Interoperabilit t gew hrleistet LA Java basierte Anwendung Nachweise Welche Nachweise werden hinsichtlich der Tragf higkeit der eigenen L sungen geliefert N1 Der beschrieben Ansatz resultiert in einer Java basierten Anwendung namens RolePartner mit vier vordefinierten Administratorenrollen und klar voneinander abgegrenzten Befugnissen innerhalb des Rollenmanagements Es gibt allerdings auch eine Rolle die Vollzugriff auf das Gesamtsyst
263. ndsystemen realisiert Ka07b Um den Gegensatz zum Omada Identity Manager zu unterstreichen wird hier die alleinstehende der integrierten Variante vorgezogen Wie man aus der Grafik erkennen kann bezieht SRM die Daten aus unterschiedlichen Datenquellen kann die daraus abgeleitete Rollenstruktur und Policys aber nur im Falle einer integrierten L sung unter Zuhilfenahme einer Provisionierungsplattform automatisiert in die Endsysteme zur ckf hren Im stand alone Betrieb m ssen diese Daten aus SRM durch einen manuellen Export an diese Systeme zur ckgef hrt werden In der integrierten Variante mit Identit tsmanagementsystem wie beispielsweise dem Sun Identity Manager als Provisionierungsplattform ist der Prozess des R ckf hrens von Rollen und Policys somit Komplett automatisierbar Der erste Arbeitsbereich umfasst Prozesse die sich mit dem Definieren und der anschlie enden Verwaltung der Rollen im produktiven Einsatz besch ftigen engl role engineering role mana gement Zum Definieren von Rollen bietet SRM data mining Algorithmen an die auf der Basis von Benutzerberechtigungen arbeiten Neben diesem automatisierten Ansatz ist es auch m g Forschungsgruppe C amp M 56 Stand der Technik lich die Definition manuell vorzunehmen SRM verfolgt hierbei ein hybrides Vorgehen und be zieht damit sowohl Gesch fts als auch Systemrollen in den Prozess mit ein Die Verwaltung dieser Rollen geschieht ber die einheitliche Web Oberfl che de
264. ne weitaus effizientere Verwendung von Rollen sowohl auf gesch ftlicher als auch auf Systemebene Die Vererbung von Rollen ist bereits in Modellen und tech nischen Implementierungen vorhanden jedoch vermischen sich gesch ftliche und tech nische Spezifika durch die fehlende Unterscheidung auf Rollenebene Eine explizite Trennung wie sie hier modelliert wird erm glicht feinere Steuerungsmechanismen bei der Vererbung Es l sst sich somit festhalten dass die Vererbung in Modellen zwar formal spezifiziert und korrekt ist jedoch den Anforderungen von Unternehmen nach eing ngigen Modellen nicht in ausreichendem Ma e gerecht wird In identit tsbasierten Implementierungen existieren Steuerungsmechanismen bei der Vererbung von Rechten mit denen etwa die Vererbung f r spezielle Objekte im Hierarchiebaum umgangen wer den kann engl block policy inheritance so dass Policys nur f r dieses Objekt nicht aber f r die hierarchisch darunterliegenden Objekte angewandt werden MicO5b Ein zweites Beispiel eines feingranularen Steuerungsmechanismus ist das explizite Verbot dass gewisse Attribute umgangen oder mit anderen Attributwerten belegt werden d rfen engl no override MicO5b In einem anschaulichen Beispiel k nnte man in einer bergeordneten Rolle fordern dass gewisse Zugriffsrechte repr sentiert durch Attri but Wert Paare in hierarchisch darunterliegenden Rollen durch einen abweichenden Werte f r dasselbe Attribut nicht berschrieben
265. nf Systemrollen Das resultierende Rollenmodell BRBAC ist in Information 57 dargestellt wobei hier derselbe Ausschnitt gew hlt wurde wie in der vorherigen Abbildung Der Gesamtausschnitt ist in Information 66 in Anhang C dargestellt Business Roles Marketing Assistent c amp m Accounting Assistent c amp m System Roles with multiple System Policies y E ed tec Full Access S E c amp m Default Access E FileShare Full Access E Domain User E Domain User Information 57 Case Study Role Mapping with Complex System Roles Vergleicht man nunmehr Information 56 und Information 57 so stellt man fest dass BRBAC durch die Aggregation von System Policys deutlich klarer strukturiert ist Im Gegensatz zu neun Systemrollen im Gesamtbild der direkten Konvertierung von System Policys existieren nun mehr lediglich f nf Systemrollen In dieser Abbidung sind davon lediglich vier dargestellt Dies bedeutet eine Verringerung bei den Systemrollen um etwa 44 Zwar ist dies in Anbetracht von lediglich neun System Policys kein statistisch aussagekr ftiger Wert jedoch stellt das IST Szenario eine durchaus realistische Fallstudie aus einem unternehmerischen Kontext dar Da die einzelnen Policys stets diskrete Zugriffsberechtigungen in sich Kapseln kann davon ausgegan gen werden dass sich die Vorteile von BRBAC insbesondere in gro en Einrichtungen potenzie ren Eine weitere Sichtweise stellt die Betrachtung der Zuweisungen statt der R
266. ng der Betriebsphase von BRBAC haben zur Auswahl des Sun Role Manager gef hrt Im Anschluss daran folgte in Kapitel 7 2 2 eine genauere Betrachtung der Gesch fts und Systemrollen Durch die explizite Modellierung von Systemrollen und eine exemplarische Anwendung von role mining Prinzipien konnten sich die Systemrollen sogar noch zusammenfassen lassen und somit die Verringerung der Komplexi t t von BRBAC belegt werden Die explizite Trennung von Gesch fts und Systemrollen stellt die prim re Stufe der Komplexit tsreduktion und die Konzeption von Systemrollen die mehr als nur eine System Policy beinhalten die sekund re Stufe der Komplexit tsreduktion dar Bei des konnte in Kapitel 7 2 3 belegt werden Abschlie end wurde die hohe Relevanz einer eigens modellierten Betriebsphase verdeutlicht was durch ein Beispiel belegt werden konnte Um die in dieser Arbeit entwickelten Modelle und Konzepte anschaulich beschreiben zu k n nen ist das gew hlte Szenario auf einen spezifischen Aspekt beschr nkt Es d rfte daher h chst interessant sein wie sich BRBAC in der wirtschaftlichen Umsetzung in einem gro en Szenario verh lt insbesondere wie sich die hier entwickelten Prinzipien zu SoD generischen Rollen und Policy Erweiterungen auswirken Es kann zu diesem Zeitpunkt lediglich ein Indizienbeweis ge liefert werden dass all diese Prinzipien den zentralen Zielen von BRBAC entsprechen wie aus Kapitel 7 2 3 hervorgeht Als zus tzlicher Beleg wird a
267. ng die Aufwandssch tzung durch die function point Methode unterst tzt die auf Erfahrungswerten aus fr heren Projektum setzungen aufbaut Hierf r gibt es im Rollenmanagement bisher keine erkennbaren Ans tze An dieser Stelle sei diese Methode jedoch f r weitere Forschungen erw hnt Die Abnahme durch den Kunden beschlie t die Analysephase und leitet zur n chsten Phase ber dem Rollenent wurf Zust ndigkeiten In der Analysephase ist die Kommunikation ein elementarer Bestandteil Da die definierten Rol len alle ber eine unterschiedliche Sicht auf das Gesamtunternehmen verf gen sollen diese As pekte in dieser Phase alle mit eingebracht werden und das Gesamtbild erg nzen Um den Pro zess voranzutreiben werden in der Analysephase die Zust ndigkeiten hierf r definiert Der bzw die Zust ndigen im weiteren Verlauf des Vorgehensmodells m ssen f r die Einhaltung eventuell abgesteckter zeitlicher Fristen sowie die berg nge zwischen den Phasen sorgen Die Erfassung des Ist Zustands bernimmt die Fachabteilung zusammen mit den Beratern engl consultants die ber die Methodenkompetenz zur Erfassung des Ist Zustands auf technischer Seite verf gen Da die Berater direkt mit den Fachabteilungen sprechen die ihrerseits die Ver waltung der L sung bernehmen werden m ssen hier die gew nschten Funktionen der L sung im Sinne eines Lastenhefts definiert werden Die Erfassung auf gesch ftlicher Ebene abstrahiert Forschungsgrupp
268. ng von c amp m k mmert sich um die Erzeugung und Pflege der Inhalte die den Kunden von c amp m zur Verf gung gestellt werden Daf r existiert die Gesch ftsrolle Autor die mit der unternehmenseigenen IT Abteilung den Kunden von c amp m und der Marketing Abteilung kommuniziert F r die Kunden von c amp m exis tiert eine eigene Gesch ftsrolle Kunde e Der Schulungskunde i2s Das Unternehmen i2s besteht zum Einen aus der Unterneh mensleitung die in direktem Kontakt zur Unternehmensleitung von c amp m steht Auch die Marketing Abteilung von c amp m steht mit der Unternehmensleitung von i2s in direk tem Kontakt um ber neue Kursangebote zu informieren Zum Anderen verf gt das Unternehmen i2s ber eine Menge an Kursteilnehmern die in der Gesch ftsrolle Kurs teilnehmer an Schulungen von c amp m teilnehmen Die Teilnahme kann wie bereits er w hnt wurde sowohl aus der technischen Infrastruktur von i2s erfolgen aber auch von Forschungsgruppe C amp M Fallstudie zur Anwendung der Modelle in einem kommerziellen Produkt 123 c amp m aus erfolgen was bei der Betrachtung der Systemrollen von Bedeutung sein wird wie im n chsten Kapitel gezeigt wird e Der IT Dienstleister ed serv Das Unternehmen ed serv wird in diesem Szenario ver treten durch die Ansprechpartner die die Pflege der Serversysteme von c amp m tiberneh men Hierf r existiert die Gesch ftsrolle des Service Managers auf Seiten von ed serv Dies
269. ng wird in SRM als eigener Namensraum engl namespace definiert Da es zu einer Anwendung aber mehrere Verbindun gen geben kann wie beispielsweise dem Zugriff auf unterschiedliche Datenbanken innerhalb eines Datenbankservers unterst tzt der Role Manager mehrere Verbindungsinstanzen engl end point die ihrerseits aus einer Menge von Attributen engl attribute bestehen Attribute be zeichnen in diesem Zusammenhang systemspezifische Eigenschaften wie etwa den Anmelde namen eines Benutzers oder dessen Gruppenmitgliedschaften in einem dieser Systeme F r eine vereinfachte Darstellung ist es m glich diese Attribute zu Attributkategorien engl attribute category zu gruppieren RBA X AO erreti Identity Warehouse Identity My Certifications Certification agin n z eo Identity Audit Ja 3 7 settings 20 Role Engineering Role Management Statisti Identity Audit Policy Violat tions o m High m Medium Low nu Information 30 State of the Art Sun Role Manager GUI Abschlie end soll hier ein kurzer Einblick in die grafische Bedienoberfl che des Sun Role Ma nager gegeben werden weil in den folgenden Kapiteln die einzelnen Funktionen in Bezug zu dieser grafischen Oberfl che vorgestellt werden Information 30 zeigt die Startseite nach der Benutzeranmeldung in der aktuellen Version 4 0 Sie bietet eine bersicht ber die einzelnen Arbeitsbereiche des Role Manager ber die Men leiste sind die einz
270. ngen so dass sie an dieser Stelle nicht explizit erw hnt werden 3 3 3 Die Arbeitsbereiche role engineering und role management Bei der konkreten Umsetzung von RBAC in einem Unternehmen beginnt man typischerweise damit ein an das Unternehmen angepasstes Rollenkonzept auf der Basis eines Rollenmodells zu entwickeln ehe Verwaltungsaufgaben im Bezug darauf anfallen Deshalb wird zun chst auf die Komponenten role engineering und anschlie end auf role management eingegangen SRM un terteilt den role engineering Bereich in drei voneinander unabh ngige Prozessschritte Dies sind das Zusammenfassen von Berechtigungen zu Rollen engl role discovery das Analysieren von Forschungsgruppe C amp M 60 Stand der Technik bestehenden Rollen Berechtigungen oder Zugriffsmustern engl role entitlement discovery und das Erstellen von Regeln mit deren Hilfe das Eintragen von Benutzern in Rollen einge schr nkt werden kann engl rule discovery Diese drei Teilprozesse werden nun beispielhaft gezeigt 35 SRM Role Discovery Set Minable Attributes Set of Users Set Role Mining Parameters Run Role Mining Algorithm Validate Role Mining Results Information 32 State of the Art Sun Role Manager Role Discovery Hauptaufgabe der Komponente role discovery ist es Rollen als logische Einheiten f r Zugriffs berechtigungen zu finden Neben dem manuellen Anlegen von Rollen bietet der Sun Role Ma nager einen teilautomatisiert
271. ngen an Policys stellen die zu einem kompakten Rollenmodell und dadurch zum Erreichen von Ziel Z f hren Dazu werden Policys nur soweit betrachtet wie in diesem Kon text n tig da die Policy Modellierung au erhalb des Fokus dieser Arbeit steht Verallgemei nernd und in bereinstimmung mit der Definition der Relation oO poa wird eine Policy als 2 Tupel definiert bestehend aus einem Autorisierungsattribut und dessen Wert Diese Abstraktion ist hinreichend weil mindestens diese beiden Informationen erfasst werden m ssen um eine Zugriffskontrollaussage treffen zu k nnen In diesem Kapitel wird nun gem der Anforderung Ao speziell auf den Wert eines Autorisierungsattributs eingegangen und dieser Sachverhalt modelliert Da sowohl Gesch fts als auch System Policys als 2 Tupel gesehen werden k nnen ist das in diesem Teilkapitel vorgestellte Prinzip der Autorisierungsattribute mit Platzhaltern f r beide Rollenbegriffe gleicherma en g ltig Information 42 stellt Policys als Attribut Wert Paare mit Platzhaltern engl wildcards dar Forschungsgruppe C amp M Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen 81 Organizational Layer Technical Layer ist of Business Role consist o System Role 1 Le fi 1 1 1 consist of consist of has Business Role has System Role 1 m 1 Business Policy System Policy 1 1 Business Policy Attribute Business Policy Value System Policy Valu
272. niger komplexen Umsetzungen zu gelangen Es stellt sich nunmehr die Frage wie bei der berf h rung dieses Rollenmodells in den Wirkbetrieb vorgegangen werden sollte Mit genau dieser Fragestellung besch ftigt sich das vorliegende Kapitel welches den zweiten Hauptteil dieser Arbeit darstellt Es wird ein Vorgehensmodell entwickelt welches sich an den klassischen Ent wicklungszyklus f r Software anlehnt und auf Rollen bertr gt Dazu werden in diesem Einf h rungskapitel zun chst zwei Ziele definiert und daraus die Anforderungen f r das Vorgehensmo dell abgeleitet Abschlie end werden die an diesem Prozess beteiligten Rollen eingef hrt In den anschlie enden Kapiteln wird dann explizit auf die unterschiedlichen Phasen eingegangen und die hier erhobenen Anforderungen umgesetzt Den Abschluss bildet auch in diesem Kapitel ein Res mee welches das Modell im Gesamtkontext darstellt und die wesentlichen Punkte kurz zusammenfasst Das Vorgehensmodell ist in vier diskrete Phasen unterteilt die jeweils unterschiedliche Aspekte modellieren die bei der Umsetzung betrachtet werden m ssen Jede Phase verfolgt dabei unter schiedliche Teilziele und weist Zielartefakte auf die in die jeweils n chste Phase bergeben werden Da sich das Vorgehen auf das Rollenmodell aus Kapitel 4 st tzt spiegeln sich die dort definierten Ziele auch in der Vorgehensmodellierung wider Das Ziel Z des Rollenmodells BRBAC etwa erw hnt die explizite Trennung gesch ft
273. noberfl che des SRM konfiguriert werden Im Rahmen der Installation wurde ein administrativer Benutzer rbacxadmin mit dem initialen Passwort password angelegt Das Passwort sollte unmittelbar ge ndert werden Um anderen Benutzern den Zugriff auf SRM zu erm glichen k nnen ber die Bedienoberfl che Benutzer manuell angelegt und in SRM eigene Rollen eingeteilt werden Diese Rollen dienen lediglich der Steuerung des Rechteumfangs in nerhalb von SRM Neben der Konfiguration von Benutzern kann ein Mailserver spezifiziert werden der zur Zusendung von Benutzerstatistiken verwendet werden kann Diese beiden Kon figurationsschritte sind in Information 64 dargestellt Damit endet die Konfiguration des SRM der nun Einsatzbereit ist Configuration Process of Sun Role Manager Database Configuration Application amp Web Server Configuration structured SRM Configuration 2 System Configuration Configuration gt System Security Configuration Rbacx Roles Role Name SMTP Port SMTP Us SMTP Pas SMTP Aut T RBACK Server settings system Email SRMAdminGcm tm uka de RBACx URL http localhost 8080 rbacx Ce Pcs 1 2 of 2 Records Display 10 Information 64 Appendix Configuration Process of Sun Role Manager Forschungsgruppe C amp M Anhang 147 C Abbildungen aus dem IST Szenario Die beiden hier aufgef hrten Abbildungen zeigen das Gesamtbild der
274. nternehmenssysteme wie etwa Datenban ken hergestellt werden Die n chste Phase des Ausrollens befasst sich mit dem geplanten Einbetten der rollenbasierten Infrastruktur in die Gesamtlandschaft sowie dem Einsatz eventuell weiterer Werkzeuge die in diesem Zusammenhang von nutzen sein k nnten wie etwa ein Sing le Sign On System SSO oder ein workflow System f r die Rollenadministration Die letzte Phase befasst sich mit den anschlie end anfallenden Verwaltungsaufgaben wie etwa der Pflege der Rollen engl role management maintenance Nachweise Welche Nachweise werden hinsichtlich der Tragf higkeit der eigenen L sungen geliefert N1 Nachweise f r den Lebenszyklus kommen aus Theorie und Praxis und werden von den Autoren ausf hrlich geschildert und durch Quellen belegt N2 Als Nachweis aus der Praxis kommt der Security Administration Manager SAM zum Einsatz SAM stellt ein unternehmensweites Benutzeradministrationswerkzeug dar welches ber einen zentralen Datenstamm f r Benutzer und Ressourcenverwaltungen verf gt Allge meines Ziel des SAM ist die zentrale Verwaltung mehrerer Systeme Aufgrund der zunehmen den Komplexit t von Unternehmenssystemen steigt auch der Bedarf an plattformspezifischem Forschungsgruppe C amp M 162 Anhang Wissen dieser Systeme um mit diesen in einem integrierten Ansatz kommunizieren zu k nnen Durch das Integrieren dieser Systeme in SAM verwendet die technische Administration nur eine
275. ntralen Inhalte die in der Arbeit behandelt werden 11 Die Autoren sehen einen deutlichen Zuwachs an RBAC Aktivit ten in Theorie und Praxis Sie sehen hierdurch insbesondere einen Vorteil f r die IT Verwaltung da die Kopplung von Be rechtigungen an Rollen fehlerresistenter und kostenreduktiver ist als die Kopplung an einzelne Benutzer Da die Verwaltung von Rollen in vielen Implementierungen auf einer ad hoc Basis geschieht wird hier ein System vorgestellt das g ltige Rollen Benutzer und Berechtigungen erm glichen soll 12 Das Produkt namens RolePartner soll es Administratoren erm glichen gewisse Kompo nenten eines RBAC Modells abzubilden um Zugriffskontroll Policys darzustellen Somit bildet RolePartner eine solide Grundlage f r den Betrieb einer rollenbasierten Infrastruktur Dazu ge h rt das Etablieren von g ltigen Rollen und Hierarchien samt Benutzern und Berechtigungen Insbesondere m ssen Rollen durch Beschr nkungen engl constraints wie etwa Zugriffskont roll Policys klar voneinander abgegrenzt werden 13 Dazu werden drei Methoden vorgestellt und Entwurfs sowie Implemetierungsprobleme er rtert 14 Zun chst folgt aber eine Einf hrung in den Bereich role engineering and anschlie end in role administration Dazu wird jeweils der Bezug zu aktuellen Forschungsarbeiten aufgezeigt Forschungsgruppe C amp M Anhang 163 15 Role engineering Es wird ein berblick ber die drei Vorgehensarten im role
276. ntwerfen Die erste Erwei terung betraf die Verwendung von Platzhalterwerten f r Attribute in Policys Dadurch wird es m glich Policys f r konkrete Zielsysteme zu definieren die den Berechtigungsumfang offen lassen Dieser wird erst durch ein Attribut des Benutzerobjekts zum Zeitpunkt des Zugriffs fest gelegt Eine zweite Erweiterung greift an der Hierarchie von Rollen an und spezifiziert M g lichkeiten die Vererbung von Policys die mit der Hierarchiebildung einhergeht zu steuern Diese Prinzipien sind in identit tsbasierten Verzeichnisdiensten bereits vorhanden und wurden auf BRBAC angewandt Durch das Attribut block policy inheritance in einer Policy wird er reicht dass sie explizit von der Vererbung ausgeschlossen wird um eine spezifische Berechti gung nicht an tieferliegende Hierarchiestufen weiterzugeben w hrend das Attribut no override angibt dass der in der Policy definierte Berechtigungsumfang durch zus tzliche Policys in der Hierarchie nicht berschrieben werden Kann Eine dritte Erweiterung auf Policy Ebene stellen Joker Policys dar Diese stehen ausschlie lich f r Systemrollen zur Verf gung weil diese Er weiterungen im direkten Bezug zu technischen Endsystemen stehen Durch die Joker Policy wird ausgedr ckt dass das Vorhandensein von Systemrollen in einer Gesch ftsrolle davon ab h ngen kann in welchem Kontext sich die Gesch ftsrolle gerade befindet Befindet sie sich ak tuell in einem Kontext der die Bedingung nich
277. ntwurfsphase dem Kunden zur gewissenhaften berpr fung vorgelegt Dies sollte ohne Ein beziehung der Analysten oder Consultants geschehen damit sich die Verantwortlichen ohne Einfl sse von Au en mit dem zu implementierenden Modell auseinandersetzen und es diskutie ren K nnen Forschungsgruppe C amp M Entwicklung eines Vorgehensmodells fiir die rollenbasierte Zugriffskontrolle 99 55 Role Design Analyst Customer Analyst Consultant Customer Consultant Customer datastore requirement specification structured structured f Business Role Design amp System Role Design Role Specification Define Data Basis Policy Specification Role Mining Policy Specification Role Owner Role Specification datastore functional specification n Role Owner Role Mapping Design Verification Role Mapping Information 48 Procedure Model Development Role Design Ziel der Entwurfsphase Das Ziel der Entwurfsphase ist es zu einem ausspezifizierten Rollenmodell zu gelangen wel ches in der Implementierungsphase umgesetzt werden kann Dazu geh ren ausspezifizierte Mo delle der beteiligten Rollen Gesch fts und Systemrollen und den Berechtigungen in den End systemen engl functional specification Durch die Definition von Rollenverantwortlichen ist f r die Implementierungsphase auch schon ein Teil der Umsetzungsverantwortung dezentral de finiert Durch die Beteiligung der
278. nverantwortlichen anweist die er Forschungsgruppe C amp M 98 Entwicklung eines Vorgehensmodells fiir die rollenbasierte Zugriffskontrolle w hnten nderungen durchzuf hren Diese explizite Unterscheidung ist an dieser Stelle aller dings von untergeordneter Bedeutung Die Einbeziehung der Fachabteilungen und das hohe Ma an interner Kommunikation erweist sich hierbei als elementarer Bestandteil des Gesamt prozesses Da die bisherigen Definitionen der System und Gesch ftsrollen unabh ngig vonei nander geschehen ist es im der Folge notwendig den Bezug zwischen den Rollentypen zu defi nieren und die Rollenverantwortlichen in die gew hlte Spezifikation einzuf hren Diese T tigkeit ist daher mit gro er Sorgfalt durchzuf hren und Kann erst dann vorgenommen werden wenn die Verantwortlichkeiten gekl rt sind An dieser Stelle zeigt sich ein Vorteil der Trennung von gesch ftlichen und technischen Belangen weil ein Gesch ftsrollenverantwortli cher keine Kenntnis ber technische Details sondern lediglich ber die Bedeutung einer Sys temrolle kennen und verstehen muss Ein Systemrollenverantwortlicher auf der anderen Seite ben tigt keine detaillierten Kenntnisse ber die Struktur von Gesch ftsrollen und kann sich auf die Pflege von systemabh ngigen Berechtigungen und Policys Konzentrieren Im Folgenden muss nun von den Rollenverantwortlichen die Verkn pfung von Gesch fts und Systemrollen bewerkstelligt werden Obwohl dieses Pe
279. odellen und praktischen Umsetzungen von RBAC geschlossen werden kann Ei ne zentrale Forderung hierbei ist die explizite Trennung unterschiedlicher Rollentypen Dies kommt sowohl in der Modellspezifikation als auch in der funktionalen Spezifikation des Rol lenmodells zum Tragen Zus tzlich zur Entwicklung des Rollenmodells wird ein Vorgehensmo dell entwickelt das zur technischen Umsetzung des Rollenmodells herangezogen wird Die zentralen Aspekte des Vorgehens sind dabei die Unterst tzung der Entwicklung unterschiedli cher Rollentypen einerseits und die explizite Modellierung einer Phase f r den produktiven Ein satz des instanziierten Rollenmodells andererseits Zum Tragf higkeitsnachweis wird ein Bei spielszenario vorgestellt in dem das Rollenmodell gem der Vorgaben des Vorgehensmodells in einem Werkzeug f r den Bereich des Rollenmanagements realisiert wird Diese Arbeit ent stand in Kooperation mit der Firma iC Consult Gesellschaft f r Systemintegration und Kom munikation mbH die sich an dieser Arbeit durch ihre Erfahrungswerte aus der Praxis aktiv be teiligt hat 1 1 Einf hrung in das Themengebiet Der Bedarf an Mechanismen zur Wahrung der Sicherheit besteht seitdem es zu sch tzende In formationen gibt FK 07 Der Ruf nach Prinzipien zur Sicherheit von Computersystemen ent wickelte sich im Einklang mit dem Aufkommen von Time sharing Systemen ab dem Jahr 1960 die es erstmals erlaubten mehrere Benutzer ber Terminal Verbin
280. olgenden werden nun Anforderungen definiert und im Bezug gesetzt zu den Zielen die sie realisieren Ziel Z Trennung von gesch ftlichen und technischen Aspekten im Vorgehen e Anforderung A Hybrides Vorgehen Wie bereits angesprochen wurde sind an dem Prozess zur Umsetzung des Rollenmodells mehrere Mitarbeiter beteiligt die ihrerseits teils sehr unterschiedliche Sichtweisen auf das Unternehmen haben Das liegt daran dass die Sichtweise auf ein Unternehmen immer durch die Beziehung gepr gt ist die man zu diesem Unternehmen hat Ein Mitarbeiter der technischen Administration hat demnach ein radikal anderes Bild des Unternehmens als etwa ein externer Partner oder ein Angestellter auf Gesch ftsebene Diesem Sachverhalt wurde im Rollenmodell be reits durch die Einf hrung von Gesch fts und Systemrollen Ausdruck verliehen und auch bei der technischen Umsetzung in muss dieser Tatsache Beachtung geschenkt Forschungsgruppe C amp M 92 Ziel Z gt Entwicklung eines Vorgehensmodells fiir die rollenbasierte Zugriffskontrolle werden In Anlehnung daran wird in dieser Arbeit bei der Entwicklung von Rollen auf gesch ftlicher Ebene top down vorgegangen und auf technischer Ebene bottom up was parallel geschieht und im Folgenden als hybrides Vorgehen bezeichnet wird Das Re sultat hiervon sind die beiden in BRBAC definierten Rollentypen Insbesondere in der Analyse und der Entwurfsphase kommt das hybride Vorgehen zum Tragen da in
281. ollen 4 2 3 Modellierung von wechselseitigem Ausschluss bei Rollen Als wechselseitigen Ausschluss engl separation of duty SoD wird ein Prinzip bezeichnet bei dem definiert werden kann dass sich T tigkeitsfelder gegenseitig ausschlie en und nicht gleichzeitig an dieselbe Person vergeben werden d rfen In rollenbasierten Umgebungen sind diese T tigkeitsfelder als Rollen zu interpretieren da in ihnen die zur Aus bung der T tigkeit n tigen Rechte gekapselt sind Um dies pr ziser zu formulieren dr cken sich diese Rechte durch Policys aus die in einer Rolle zusammengefasst sind Wie schon in Kapitel 2 2 3 gezeigt wurde ist SoD in rollenbasierten Umgebungen sehr leicht umzusetzen da hier lediglich Rollen definiert werden m ssen die sich gegenseitig ausschlie en Wie SC 96 bereits feststellt ist der wechselseitige Ausschluss die am meisten erw hnte Einschr nkung engl constraint im Bereich RBAC SoD bezeichnet dabei ein constraint bei der Benutzer Rolle Relation Durch die Auftrennung des Rollenbegriffs gem der Anforderung A werden in BRBAC explizit mehre re Relationen im Bezug auf die Rollentypen definiert was unterschiedliche constraints zur Mo dellierung von SoD m glich macht Dar ber hinaus wird sowohl statisches als auch dynami sches SoD modelliert was sich durch constraints auf den Relationen Benutzer Gesch ftsrolle usr Gesch ftsrolle Systemrolle O grsr sowie der transitiven Beziehung Systemrol le Benu
282. ollenanzahl dar Die Zahl der Systemrollenzuweisungen sinkt in diesem Fall von 24 auf 13 gemessen am Gesamt bild Hierdurch wird die Verringerung der Komplexit t ebenfalls deutlich Die Verringerung der Systemrollenzuweisungen sinkt um etwa 54 Dies ist in etwa in der Gr enordnung der Ver ringerung an Rollen weswegen davon ausgegangen werden kann dass BRBAC durch die ex plizite Rollentrennung zu einer deutlichen Komplexit tsreduktion im Wirkbetrieb f hrt 7 2 4 Betriebsphase von BRBAC im Sun Role Manager Nach der Betrachtung der Gesch fts und Systemrollen aus BRBAC sowie deren Umsetzung im Sun Role Manager soll nun zum Abschluss der Fallstudie ein Einblick in die Betriebsphase des Vorgehensmodells gegeben werden Wie in Kapitel 5 5 definiert wurde betrachtet diese Phase administrative Aufgaben die beim Betrieb von BRBAC vorhanden sind Dies soll nun im IST Szenario beleuchtet werden Zur Veranschaulichung zeigt Information 58 die grafische Benut Forschungsgruppe C amp M 130 Fallstudie zur Anwendung der Modelle in einem kommerziellen Produkt zeroberfl che im Sun Role Manager fiir die Rolle IT Administration c amp m Die admi nistrativen Aufgaben im Wirkbetrieb von BRBAC k nnen unterteilt werden in die Aufgabenbe reiche Rollenverwaltung Prozess berwachung und Policy Verletzungen Diese drei Be reiche werden anhand eines Beispiels erl utert und in Bezug gesetzt zu Information 58 Login D
283. ollenh lsen zu sammengef hrt und technisch in der Rollenmanagementl sung umgesetzt F r den Fall dass das eingesetzte Werkzeug Kompetenzen aus dem role engineering wie etwa role mining Techniken verf gt kann die Umsetzung der modellierten Rollen auf das Werkzeug stark verein facht werden Andernfalls m ssen die Rollenimplementierungen manuell vorgenommen wer den Da wie bereits erw hnt zun chst ein eingeschr nkter Testbetrieb angestrebt wird h lt sich der zeitliche Aufwand hierf r jedoch auch f r gr ere Einrichtungen in einem berschaubaren Rahmen wie auch WW07 belegt Nachdem das Rollenmodell f r die ausgew hlte Abteilung berf hrt wurde ist es wichtig diese Benutzer entsprechend einzuf hren Der Sinn davon ist dass die Benutzer zun chst ber den Testbetrieb selbst und anschlie end ber die in diesem Rahmen von ihnen zu erledigenden Aufgaben informiert sind Wie A fordert sollen Erfahrungswerte im Vorgehensmodell m glichst direkt verarbeitet wer den k nnen Aus diesem Grund macht es Sinn in einer ausgew hlten Abteilung zun chst einen Parallelbetrieb zu erm glichen und erst nach der Beendigung dieser Testphase auf das gesamte Unternehmen auszuweiten engl test phase Die w hrend der Testphase gesammelten Erfah rungswerte im Umgang mit dem implementierten Rollenmodell k nnen dann zur Nachbesse rung in dieses zur ckgef hrt werden Allerdings kann dies erst dann geschehen wenn das Rol lenmanagementwer
284. onship Dieses Diagramm zeigt die Datentypen business unit business user role policy user store und application end point namespace attribute category und attribute sowie die Beziehungen zwischen diesen Typen Eine Gesch ftseinheit engl business unit stellt eine organisatorische Struktur in einem Unternehmen wie etwa eine Abteilung oder ein Team dar Gesch ftseinheiten sind in der Regel ineinander geschachtelt um die Hierarchie der Gesch ftsstruktur zu repr sen tieren Zugleich ist diese Einheit von zentraler Bedeutung weil s mtliche Operationen in den drei Aufgabenbereichen von SRM auf Gesch ftseinheiten arbeiten Ein Unternehmensbenutzer engl business user ist eine diskrete Einheit innerhalb eines Unternehmens die bei der Aus bung ihrer Rechte den Informationsbestand des Unternehmens bearbeiten und ver ndern kann In der Regel ist dies ein menschlicher Benutzer es kann sich dabei aber auch um einen Dienst oder ein Programm handeln Forschungsgruppe C amp M 58 Stand der Technik Ein Unternehmensbenutzer kann in diesem Komponentenmodell zu einer oder beliebig vielen Gesch ftseinheiten geh ren soweit dies seine Rechte erm glichen Im Sinne der Hierarchiebil dung verf gt er ber genau einen weiteren Unternehmensbenutzer der ber ihm angeordnet ist und der ber die Rechte verf gt seine Rollenzuweisungen zu verwalten und zu berpr fen Vaau07a Vaau07b Anders als in der Definition in dieser Arbeit wird beim S
285. onstraints werden systemweit einmalig definiert womit erreicht wird dass sie sich auf das ganze Unternehmen auswirken und nicht umgangen werden k nnen Role Management B Role report 1 Identities i gt Secondary IDs iH Helpdesk Views i Role Owner views Bi Role report 2 My roles Identities gt Org units gt Roles gt Secondary IDs Sys Admin Views iH Data Admin Views HR Views Identities Compliance a a E 833 Identities w SoD confli Identities i gt Secondary IDs i Information 20 State of the Art Omada Identity Manager GUI Abschlie end soll ein kurzer Einblick in die grafische Bedienoberfl che gegeben werden In In formation 20 wird das Konzept der view dargestellt welches im Omada Identity Manager ver wendet wird um die Bedienoberfl che f r die unterschiedlichen Mitarbeiter anzupassen und ih nen den f r ihre Rollen ben tigten Ausschnitt des Gesamtsystems darzustellen Diese Ansichten orientieren sich an den Aufgaben der Mitarbeiter im Umgang mit dem Rollenmanagementwerk zeug Im oberen Bereich sind einige Sichten aufgezeigt die im Zusammenhang zum ersten Ar beitsbereich role management stehen Der untere Bereich stellt den Bezug zum zweiten Ar beitsbereich compliance her 3 2 2 Der Arbeitsbereich connectivity Nachdem der Arbeitsbereich connectivity im berblickskapitel 3 2 1 bereits verbal erkl rt wur de soll nun eine prozessorientierte Einf hrung gegeben werden Damit
286. p M 116 Analyse aktueller Rollenmanagementwerkzeuge falls verwirft Dies geschieht ber die Managementagenten die f r jedes Endsystem erstellt werden m ssen Die Erstellung geschieht direkt in der Benutzeroberfl che indem die in den zu grundeliegenden Endsystemen zu synchronisierenden Attribute und Daten selektiert werden Serviceorientierung OIM unterst tzt das serviceorientierte Paradigma allerdings nur in eingeschr nktem Umfang Die erw hnten Agenten die die Schnittstelle zwischen OIM und dem Gesamtdatenbestand des Unternehmens angesehen werden verf gen ber eine Webservice Schnittstelle so dass die in OIM verarbeiteten Daten im Sinne eines Dienstgeber Dienstnehmer Verh ltnisses von OIM als autoritativer Quelle bezogen werden k nnen Dies ist insbesondere bei der Integration von RBAC mit anderen Zugriffskontroll Architekturen von Vorteil 6 3 Bewertung des Sun Role Manager 6 3 1 Bezug der Kriterien zum Stand der Technik In diesem Teilkapitel wird der Sun Role Manager SRM anhand des definierten Kriterienkata logs eingeordnet und bewertet Die Grundlage hierf r stellt die Auseinandersetzung mit diesem Produkt aus den Kapiteln 3 3 1 bis 3 3 5 sowie die daraus gewonnen Erkenntnisse dar Auch hier soll zun chst ein Bezug hergestellt werden zwischen den einzelnen Bewertungskriterien und den Unterkapiteln von Kapitel 3 3 ehe die Bewertung vorgenommen wird Die Erfah rungswerte bez glich der Rollen und Hierarchien steht da
287. p separation of duties SoD verk rpert Regeln wonach es Rechte gibt die sich ge genseitig ausschlie en und die demnach nicht an ein und dieselbe Rolle vergeben werden k n nen In OIM wird dieses Prinzip in Form von Einschr nkungen engl constraints realisiert die ber eine Menge an Rollen verf gen die sich gegenseitig ausschlie en wie in Information 19 dargestellt ist Sobald in OIM eine nderung an den Rollenzuweisungen erkannt wird werden die bestehenden constraints in einem Hintergrundprozess gesammelt und berpr ft ob sich durch die ge nderten Rollenzuweisungen Policy Verletzungen ergeben Die nderung ist nur dann erfolgreich wenn keine Policy Verletzungen vorhanden sind Dabei wirken sich Ein schr nkungen auch auf die bisher erteilten Recht aus Denjenigen Benutzern die von einer neu angelegten Einschr nkung betroffen sind werden die Rollen entzogen und vermerkt dass dies aufgrund einer Einschr nkung der Fall ist Fordert ein Benutzer eigenst ndig eine Rolle an wird er beim Auftreten eines constraint darauf hingewiesen und die Rolleneinteilung wird nicht durchgef hrt Ein Bericht ber aktuelle Verletzungen dient dazu die Verletzungen f r die tech nische Administration sichtbar zu machen Auch dient dies zur Planung einer Umstellung der Rechtestruktur Es kann einerseits beobachtet werden welche Rechteverletzungen geh uft auf treten was ein Indiz daf r sein Kann dass der Rechteumfang von gewissen Rollen nicht an
288. r eren Unternehmen mit mehreren unabh ngigen Abteilungen ist dies eine durchaus realistische Annahme Durch die Verwendung generischer Rollen ist es nun m glich Systemrollen mit Policys zu de finieren die f r alle Instanzen derselben Technologie in gleicher Weise gelten Au er in der Forschungsgruppe C amp M Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen 77 Verbindung zum konkreten Endsystem unterscheiden sich diese Systemrollen somit nicht und werden in einer einzigen generischen Rolle zusammengefasst Wird diese generische Systemrol le nun einer Gesch ftsrolle zugewiesen muss die Menge an Endsystemen als zus tzlicher Pa rameter angegeben werden Auch hier wird ber die Schnittmengenbildung diejenige Teilmenge nicht generischer Systemrollen errechnet die in den angegebenen Endsystemen definiert sind und diese dann der Gesch ftsrolle direkt zugewiesen Organizational Layer Technical Layer A p consist of 5 Generic Business Role Generic System Role consist of consist of Role Hierarchy Role Hierarchy 1 1 consist of Business Role System Role 1 1 consist of i iS Lele 1 Subject attribute consist of has Business Role 1 has System Role consist of consist of 1 t 1 User Business Policy System Policy Information 40 Development of the BRBAC Role Model Generic Roles Information 40 illustriert die Modellierung von generischen Rollen Ma
289. r Form in die Zielsysteme zur ckgef hrt werden k nnen und steht somit im Zusammenhang mit dem Arbeitsbereich connectivity aus Kapitel 3 2 2 Das Bewertungskriterium Benutzerfreund lichkeit engl usability ist querschnittlich ber das gesamte Produkt zu verstehen Hier wird die G te des gesamten Produkts bewertet anstatt eines einzelnen Arbeitsbereichs oder einer einzelnen Komponente Es ergibt sich daher nicht aus einem einzelnen Teilkapitel Das letzte Kriterium Serviceorientierter Ansatz engl service oriented approach bewertet ob das Pro dukt im Sinne einer dienstorientierten Architektur auch als Dienstgeber fungieren kann was elementar ist um als zentrale Zugriffskontrollarchitektur angesehen werden zu k nnen Es muss somit auch als ganzheitliches Kriterium gesehen werden Auch hier entstammt die Bewertung aus der gesamten Betrachtung vom OIM als aus einem einzelnen Teilkapitel Criteria Omada Identity Manager Quality 1 Roles 1 1 Business Roles 1 2 System Roles 2 Hierarchies 2 1 Business Role Hierarchies 2 2 System Role Hierarchies 3 Role Mining 4 Workflow capability 4 1 Process 4 2 Monitoring 5 Usability 6 Support of Feedback 7 Service oriented approach Information 52 Analysis of Role Management Solutions Evaluation of OIM Forschungsgruppe C amp M 114 Analyse aktueller Rollenmanagementwerkzeuge 6 2 2 Anwendung des Kriterienkatalogs I
290. rangestellter verkn pft Unter Zuhilfenahme eines statischen constraint k nnte man nun de finieren dass sich diese beiden Rechte gegenseitig ausschlie en was jedoch in dem gew hlten Beispiel dazu f hrt dass die Rolle Schalterangestellter Kredite entweder bewilligen oder aus zahlen darf Er verf gt dann nur ber eines der beiden Rechte niemals aber ber beide Durch eine dynamische Einschr nkung hingegen K nnte man definieren dass sich diese beiden Rechte nicht prinzipiell ausschlie en sondern nur dann wenn der Kontext f r beide bereinstimmt In diesem Zusammenhang wird nun bei der Autorisierungspr fung der Kontext der Kreditanwei sung berpr ft um festzustellen ob die Bewilligung des Kredits von derselben Person vorge nommen wurde die ihn nun auch auszahlen m chte Der mathematischen Korrektheit halber sei an dieser Stelle erw hnt dass die Relationen ssop und asop auf Rollen operieren und nicht auf Policys wie in diesem Beispiel vorausgesetzt Da eine Rolle aber eine Menge an Policys subsumiert lassen sich die Definitionsmengen beider Relationen auf die Policy Teilmenge der Rollen einschr nken Zur Umsetzung von dynamischem SoD wird nun ein constraint f r zwei Rollen zusammen mit der Bedingung definiert f r die diese Rollen oder die darin enthaltenen Policys nicht bereins timmen d rfen wie im erw hnten Beispiel etwa das Benutzerkonto Dies dr ckt sich formal in der Relation asop aus wobei der
291. rationen engl operati ons und Berechtigungen engl permissions Durch das Modellelement roles werden Benutzer und Objekte in eine m zu n Beziehung zueinander gestellt wie in Kapitel 2 1 ber die Sub jekt Objekt Relation f r RBAC bereits angedeutet wurde Dabei stellen m und n die Kardinali t ten dieser beider Elemente dar Mit dem Modellelement Sitzung engl session wird der ak tuelle Kontext festgelegt in dem gearbeitet wird Mit der Hilfe von Sitzungen werden Rollen Forschungsgruppe C amp M 14 Grundlagen kontextsensitiv und eine Teilmenge an Rollen selektiert die nur im vorliegenden Kontext akti viert werden k nnen Modelliert wird dieser Sachverhalt durch die Relation session_role Ein Benutzer bezeichnet in diesem Zusammenhang immer einen menschlichen Benutzer obwohl ein Benutzerkonto im Allgemeinen ja auch f r computersystemeigene Benutzerkonten stehen kann Der NIST RBAC Standard definiert einen Benutzer jedoch stets als menschlichen Benut zer Unter einer Rolle versteht das Standardrahmenwerk nunmehr eine Jobfunktion innerhalb einer Organisation oder Einrichtung Semantisch gesehen steht eine Rolle somit f r eine Ar beitsaufgabe die einem Benutzer ber die Relation user assignment UA zuteil wird wenn er in die entsprechende Rolle eingeteilt wird Unter einer permission wird die Berechtigung ver standen die zu dieser Arbeitsaufgabe geh rt und die das Subjekt in Form seiner Rolle beim Zu griff auf ein Objekt bes
292. rde folgt nun eine Bewertung dieses Werkzeugs anhand des soeben vorgestellten Kriterienkatalogs mit dem Ziel die G te dieses Werkzeugs festzustellen Das Ergebnis der Bewertung ist dargestellt in Information 52 Die Kriterien in dieser Abbildung stehen dabei im unmittelbaren Bezug zu den Unterkapiteln von Rollenbasierte Zugriffskontrolle im Omada Identity Manager aus Kapitel 3 2 Im Folgenden soll kurz der Bezug zu diesen Kapiteln her gestellt werden Die Bewertung des Kriteriums Rollen engl roles bezieht sich auf die Kapi tel 3 2 1 sowie 3 2 3 in denen das in OIM verwendete Rollenmodell und die differenzierte Be trachtung von Gesch fts und Systemrolle dargestellt wird An dieser Stelle wird auch das Konzept der Rollenhierarchien erl utert was in das Bewertungskriterium Hierarchien engl hierarchies einflie t Da OIM in der vorliegenden Version keine Mechanismen zur automati schen Herausbildung von Rollen engl role mining anbietet steht dieses Kriterium im Katalog in keinem Zusammenhang zu einer der aufgef hrten Unterkapitel Die Unterst tzung von auto matischen Arbeitsabl ufen engl workflows kommt insbesondere in den Teilkapiteln 3 2 3 und 3 2 4 zum Tragen Diese sind in OIM in den Arbeitsbereichen role management und compliance enthalten Das Bewertungskriterium Unterst tzung von R ckmeldung engl support of feed back bewertet ob die in OIM gemachten nderungen in automatischer oder automatisierbare
293. rechtigungen werden von den Verantwortlichen zum Teil ma nuell umgesetzt Jede manuelle Aktion birgt aber die Gefahr entweder berhaupt nicht oder nicht korrekt umgesetzt zu werden das f hrt aber zu Inkonsistenzen zwischen der Verwaltungsplattform und den Endsystemen Somit stellt sich neben der Frage nach der Kommunikationsbeziehung berdies die Frage ob damit umgegangen werden kann dass die erteilten Berechtigungen in den dahinterliegenden Endsystemen nicht mit den erteilten Berechtigungen bereinstimmen die im Verzeichnis des Rollenmanagement werkzeugs vorgehalten werden Kriterium 7 Serviceorientierter Ansatz Da Rollenmanagementwerkzeuge als integ rative L sung f r den Einsatz in Unternehmen bestimmt sind bewertet das siebte Krite rium ob es eine Unterst tzung f r serviceorientierte Architekturen im Bereich des Iden tit tsmanagements bereitstellt Identity as a service verk rpert das Architekturprinzip der Serviceorientierung bertragen auf den Bereich des Identit tsmanagements Em08 Es bietet die M glichkeit einer einfacheren Integration und Interaktion von identit tsbe zogenen Anwendungen im Vergleich zu traditionellen Software Architekturen Forschungsgruppe C amp M Analyse aktueller Rollenmanagementwerkzeuge 113 6 2 Bewertung des Omada Identity Manager 6 2 1 Verkn pfung zum Stand der Technik Nachdem der Omada Identity Manager OIM in Kapitel 3 2 bereits detailliert eingef hrt und betrachtet wu
294. ren Seite ist das auch deshalb notwendig weil die Consultants ohne das Feedback der Kunden das Unternehmen nicht in geeignetem Ma e auf das Rollenmodell abbilden k nnen weil ihnen zumindest das implizite Wissen ber Abl ufe im Unternehmen fehlt Durch diesen Ansatz werden kleinere Schwachstellen die in der Analysephase zu unpr zise oder gar nicht beachtet wurden umgehend behoben Bei gr eren Vers umnissen die zu gro en nderungen des bisherigen Modells f hren w rden ist es ratsam in die Analysephase zur ckzukehren weil dies ein Indiz f r eine unzureichende Analyse ist Darauf wird im Folgen den noch n her eingegangen Am Ende dieser Phase wird das resultierende Rollenmodell zu sammen mit Gesch fts und Systemrollen sowie den darin enthaltenen Berechtigungen und Be nutzern und dem Pflichtenheft dem Kunden bergeben der dieses dann zu verifizieren hat Gr nde f r R ckkopplungen Zu R ckkopplungen kann es in dieser Phase dann kommen wenn bei der finalen Abnahme durch den Kunden festgestellt wird dass gewisse Charakteristika der zu implementierenden L sung im Pflichtenheft nicht vorhanden sind Zwar ist die Auftretenswahrscheinlichkeit f r Feh ler im Pflichtenheft durch die Anforderung A nach einem hybriden Vorgehen mit starker Ein beziehung der Fachabteilungen sehr gering aber Fehler k nnen dennoch nie ganz ausgeschlossen werden In diesem Fall muss in die Analysephase zur ckgekehrt werden und sowohl die person
295. rf Verwaltung und Pflege Defizite Welche Defizite bestehender Arbeiten und L sungen werden als Motivation der eigenen L sun gen genannt D1 Rollen als Paradigma im Sicherheitsmanagement etabliert sich bald als Standard und es gibt bereits einige Erweiterungen zu den Modellen aber diese Ans tze fokussieren sich nur auf eine statische Sicht mit dem Ziel Rollen zu definieren Der dynamische Ansatz eines Lebens zyklus wird nicht betrachtet D2 In den letzten Jahren haben gro e Unternehmen einen Rollenbegriff gepr gt der auf die Unternehmensebene beschr nkt ist Diese Auffassung geht von der in DI beschriebenen stati schen Sichtweise aus weil sich Rollen auf Unternehmensebene und damit einhergehend ge sch ftliche Funktionen selten ndern Sowohl die praktische Erfahrung der Autoren als auch Forschungsgruppe C amp M 160 Anhang j ngste Forschungsergebnisse zeigen jedoch dass sich Rollen im Laufe der Zeit entwickeln was den Ansatz von Prozessen hnlich dem in der klassischen Software Entwicklung rechtfer tigt D3 Die steigende Komplexit t stellt ein weiteres Defizit g ngiger Ans tze dar Im Bereich all gemeiner rollenbasierter Zugriffskontrolle hat sich in den letzten Jahren sehr viel ge ndert Der Aspekt eines Lebenszyklus von Rollen blieb dabei sowohl in der Theorie als auch in der Praxis weitestgehend unbehelligt Dies ist insbesondere in Anbetracht stets zunehmender Komplexit t in Unternehmenssystemen
296. riffsrechten auf Endsysteme stehen Dies resultiert in der Spezi fikation von Gesch fts oder System Policys die mit dem entsprechenden Rollentyp verkn pft sind Im Folgenden wird nun zun chst auf diese beiden Begriffe eingegangen und anschlie end auf die Verkn pfung zwischen ihnen Es werden auch Informationen im Hinblick auf m gliche Instanziierungen des Modells gegeben Information 39 stellt dabei den hierf r ben tigten Aus schnitt des Gesamtmodells BRBAC dar Unter einer Gesch ftsrolle definiert diese Arbeit ein Modellelement welches eine Gesch fts funktion in einem Unternehmen repr sentiert Dazu geh ren s mtliche Eigenschaften die n tig sind um die gesch ftliche Funktion zu erfassen Beispiele hierf r sind neben dem Titel der Rol le Angaben zu deren Arbeitsplatz wie etwa die Abteilungszugeh rigkeit Eine Gesch ftsrolle kann einer oder mehreren Abteilungen zugeordnet sein was zur Folge hat dass Gesch ftsfunk tionen die in mehreren Abteilungen gleicherma en vorkommen in einer einzigen Gesch ftsrol le dargestellt werden k nnen Dies f hrt zu kompakten Rollenmodellen auf Gesch ftsebene Auch weist das Modellelement Gesch ftsrolle eine Hierarchie auf etwa f r einen Verweis auf die Gesch ftsrolle des Vorgesetzten was im Bezug auf Gesch ftsprozesse durchaus relevant ist Damit einhergehend wird eine explizite Rechtevererbung modelliert auf die im Unterkapitel 4 3 2 Modellierung der Rechtevererbung eing
297. rmation 26 Information 27 Information 28 Information 29 Information 30 Information 31 Information 32 Information 33 Information 34 Information 35 Information 36 Information 37 Information 38 Information 39 Information 40 Information 41 Information 42 Information 43 Information 44 Information 45 Information 46 Information 47 Information 48 Information 49 Information 50 Information 51 Information 52 Information 1 Introduction Clarification of the Problem u rsessessersnersneesnnesnneenn 4 Introduction Business Model in the IST Scenario uursuersnersneesneesnnesnneenn 6 Introduction System Model in the IST Scenario uursuesssersnersneesnnesnnesnneenn 7 Introduction Role Model 0 cescesceseceseceseeeseesseeeeneesseeeaeesaaecsaecsaecaeesaeenaeens 7 Introduction Procedure Model 0 00 ceecesecesseeseeeeeeeeeceeseeeaeecaeecsaeceaeceaecnseenaeees 8 Basics Subject Object Relation and RBAC ursseesseesnnesnnesnnesnnennnnnnnn 12 Basics NIST RBAC Reference Models 2022402200ssnnesnnesnesnneenneennnnnn 13 Basics NIST RBAC core RBAC uuenseessuessensnensensersnnesnnennnennnesnnernnennnnnan 14 Basics NIST RBAC hierarchical RBAC ceseessensnnennnneesnneennnnn 17 Basics NIST RBAC constrained RBAC with hierarchies cnn 20 Basics Role Management Capabil
298. rnehmens IT darstellen kann e Die Consultants Die Berater verf gen ber die Kompetenzen zur technischen Umset zung des Rollenmodells In diesem Zusammenhang stehen die Consultants f r die Schnittstelle zwischen den Analysten und den technischen Fachabteilungen des Unter Forschungsgruppe C amp M 94 Entwicklung eines Vorgehensmodells fiir die rollenbasierte Zugriffskontrolle nehmens Sie greifen das durch die Analysten formalisierte Wissen auf und setzen es unter Einbeziehung der Fachabteilungen im Zielsystem um In diesem Teilkapitel wurde das Vorgehensmodell vorgestellt und dabei zun chst der Bezug zum Rollenmodell BRBAC aus Kapitel 4 vorgestellt Anschlie end wurden Ziele und Anforde rungen definiert sowie die am Vorgehen beteiligten Kompetenzen vorgestellt Im Folgenden werden die vier Phasen des Vorgehensmodells einzeln vorgestellt 5 2 Analysephase Die Rollenanalyse stellt den Beginn des Vorgehensmodells zur Umsetzung des Rollenmodells auf Kapitel 4 dar In dieser Phase m ssen deshalb grundlegende Fragen diskutiert werden sowie ein solides Fundament f r die folgenden Phasen gelegt werden Aus diesem Grund werden die Beteiligten an der Analyse entsprechend ihrer individuellen Sicht auf das Unternehmen unter teilt um zu einem insgesamt geschlossenen Gesamtbild zu gelangen Wie bereits angesprochen wurde existieren mit fop down bottom up und middle out drei unterschiedliche Vorgehensan s tz bei der Modellierung von Rollen
299. rschreiben und die berweisung f r diese Rechnung bei der Buchhaltung in Auftrag zu geben Die Festlegung f r welche Rech nungen er autorisiert ist Kann nun entweder in Form von Gesch fts Policys erfolgen oder aber auch implizit durch seine Abteilungszugeh rigkeit die in der Gesch ftsrolle ja angegeben wird In diesem Fall verf gt der Verwaltungsangestellte durch seine Abteilungszugeh rigkeit ber die erforderliche Berechtigung zur Auszahlungsanforderung Generische Gesch ftsrollen greifen genau an diesem Punkt an Dabei wird die vorher allgemein als Anwendungsfall bezeichnete Abteilungszugeh rigkeit aus der Rolle entfernt wodurch sie allgemeinen Charakter erh lt und somit zu einer generischen Rolle wird Sie besteht aus einer Menge nicht generischer Gesch fts rollen die ihrerseits Berechtigungen f r konkrete Anwendungsf lle definieren Dadurch wird deutlich dass eine generische Gesch ftsrolle unterschiedliche Berechtigungsgrade f r mehrere Anwendungsf lle repr sentiert Die Festlegung auf einen konkreten Anwendungsfall geschieht erst bei der Einteilung eines Benutzers in die generische Rolle Dabei werden aus der Liste zur Verf gung stehender Anwendungsf lle diejenigen ausgew hlt f r die der Benutzer Zugriff er halten soll Aus dieser Auswahl wird dann die Schnittmenge gebildet aus den Gesch ftsrollen die in der generischen Rolle enthalten sind und den spezifizierten Anwendungsf llen Das Be nutzerkonto wird anschlie end
300. rsonal erst in der Rollenbetriebsphase mit dem Rol lenmanagementwerkzeug in Kontakt kommen wird ist es aus den genannten Gr nden von Vor teil sie in dieser Phase ebenfalls mit einzubeziehen weil sie so aktiv an der Gestaltung beteiligt sind und ihre individuelle Sichtweise des Gesamtsystems in den Entwurf mit einbringen k n nen Im Zuge des Rollenentwurfs wird das Lastenheft zu einem Pflichtenheft spezifiziert Diese Spe zifizierung hat das Ziel die formal definierten Anforderungen und Modellierungsaspekte in eine Form zu bertragen die in der Implementierungsphase f r das dort zust ndige Personal unmit telbar verstanden werden kann Dazu ist es beispielsweise n tig die bisher sehr abstrakt forma lisierten Sachverhalte durch geeignete Modelle zu konkretisieren Dies umfasst die Spezifikati on des einzusetzenden Rollenmodells aber auch die funktionale Spezifikation Letztere etwa beinhaltet unter anderem s mtliche administrative Funktionen die f r den Wirkbetrieb des Rol lenmodells ben tigt werden oder Leistungsindikatoren an denen die Qualit t der technischen Umsetzung gemessen werden kann Das Pflichtenheft erf llt insbesondere f r den Kunden noch eine zus tzliche Aufgabe In Projekten dienen die Spezifikationen im Pflichtenheft als rechtli che Grundlage f r die Umsetzung des Modells in den Wirkbetrieb und legen daher das Ende der Implementierungsphase fest Aus diesem Grund wird das Pflichtenheft als Artefakt am Ende der E
301. rt die konkreten Variablenwerte f r die eben erw hnten Attributwerte und richtet sich damit klar an technisch sehr versiertes Personal 3 3 5 Der Arbeitsbereich identity audit Die berwachung von Ausnahmen und Regelverletzungen ist Hauptbestandteil des Arbeitsbe reichs identity auditing and management Der Role Manager bietet einen einheitlichen Prozess an mit dessen Hilfe die vielf ltigen Ursachen f r Verletzungen erkannt und in organisierter Weise behandelt werden k nnen Dieser Sachverhalt ist in Information 38 dargestellt Forschungsgruppe C amp M 66 Stand der Technik SoD Analysis Preventative Controls _ Detective Controls Continuous Monitoring Risk Metrices 55 SRM Identity Audit Set Minable Attributes Define Rule Define Policy Set Remediator Information 38 State of the Art Sun Role Manager Identity Audit Die erfassbaren Regelverletzungen operieren in SRM auf Attributebene Dadurch ist es m g lich sowohl auf Attribute von Gesch ftsrollen aber auch auf die von Systemrollen zuzugreifen In diesem Zusammenhang werden Verletzungen definiert und diese anschlie end berwacht Durch die Attribute der Gesch ftsrollen ist es m glich SoD Verletzungen zu erkennen Um feingranulare Regelverletzungen auf Systemebene erkennen zu k nnen werden die Attribute der Unternehmenssysteme und deren Wertebelegung zur berwachung hinzugef gt Dies ge schieht ber die bereits
302. rt und die Erzeugung von Systemrollen kann unabh ngig davon automatisiert geschehen 4 4 Gesamtmodell In diesem Kapitel wurde mit BRBAC ein Rollenmodell f r den Einsatz in heterogenen Umge bungen entwickelt wie man sie typischerweise in Unternehmen vorfindet Es soll abschlie end in seiner Gesamtheit dargestellt wird Hierf r werden die Hauptziele und die daraus abgeleiteten Anforderungen nochmals zusammengefasst und auf M glichkeiten eingegangen die sich aus der Kombination der hier pr sentierten Modellierungen ergeben Das zentrale Ziel des BRBAC Modells ist die Trennung der gesch ftsnahen von den techni schen Rollen Den bisherigen Rollenmodellen fehlt diese klare Trennung was zu Modellen f hrt die in der praktischen Umsetzung schlecht zu handhaben sind Der Rollenbegriff der in diesen Modellen verwendet wird ist zu allgemein gefasst und passt sich somit nicht in ausrei chendem Ma e an die Bed rfnisse von technischen Implementierungen wie etwa in Unterneh men an Technische Umsetzungen unterschiedlicher Rollenmodelle wie etwa des ERBAC Modells aus Kapitel 3 1 2 zeigen dass sich in der praktischen Umsetzung eine Vielzahl von Rollen ergibt was die Komplexit t des eingesetzten Rollenmodells deutlich steigert Eine expli zite Trennung dieser beiden Sichtweisen bietet in vielfacher Hinsicht Ansatzpunkte um ein Rol lenmodell zu entwerfen das m glichst effizient ist Um dieses Ziel durchzusetzen wurden in Form der Gesch fts
303. rweisen die Autoren auf Erfahrungswerte im Umgang mit dem Lebenszyklus von Rollen durch die Implementierung eines kommerziellen Produktes fiir den Einsatz in Unternehmen Wie Information 17 darstellt bestehet der Lebens zyklus aus vier Phasen auf die im Folgenden eingegangen wird Dabei wird beschrieben wel che Aktivit ten in den Phasen enthalten sind _ Role Analysis _JRole Maintenance _JRole Design _ Role Management Adapted from KK 02 Figure 6 Information 17 State of the Art The Role Life Cycle Rollenanalyse Die erste Phase befasst sich mit der Analyse von Rollen engl role analysis und hat die Aufga be geeignete Rollen zu identifizieren die innerhalb eines Systems verwendet werden Um die Forschungsgruppe C amp M 38 Stand der Technik ses Ziel zu erreichen ist es n tig sowohl explizit vorhandene Strukturen als auch implizit vor handenes Wissen zu aggregieren um eine geeignete Basis f r die Entwicklung eines Rollenmo dells zu schaffen Hierzu sind folgende Schritte n tig e Eine Basis f r die Gesch ftsrollen schaffen Das Identifizieren von Gesch ftsrollen beginnt bei der Deduktion von gesch ftlichen Funktionen aus der Organisation sowie deren Formalisierung und endet bei den Zugriffsrechten auf technischen Systemen Dies stellt eine rein formale und keine technische Aktivit t dar obwohl an dieser Stelle auch technische Spezifika wie technische Zugriffsrechte betrachtet werden e H
304. rzeugen von Artefakten ist auch deshalb von Bedeutung weil mit dem Beginn einer neuen Phase unterschiedliche Rollen beteiligt sind und diese durch die Artefakte ein m glichst genaues Bild der bisherigen Prozessschritte erhalten sollen Wie aus der Information 46 hervor geht weist das Vorgehen R ckkopplungen zu allen bereits erledigten Phasen auf wie sie auch in aktuellen Vorgehensmodellen wie dem V Modell oder dem Spiralmodell vorhanden sind Ba98 Dies macht dann Sinn wenn in den Artefakten Schwachstellen oder Ungenauigkeiten festgestellt werden oder evolution re nderungen an der Rollenstruktur n tig sind was etwa bei der Einf hrung neuer Rollen passiert Durch die direkte R ckkopplung in alle Phasen die bis zu diesem Zeitpunkt bereits durchlaufen wurden ist es m glich sehr direkt in diejenige Pha se zur ckzuspringen in der die Schwachstelle hervorgerufen oder die nderung erfasst wurde Um dies in den folgenden Kapiteln zu verdeutlichen wird in jeder Phase zun chst ihr Ziel defi niert anschlie end wer an der Phase beteiligt ist und wie das Ziel zu erreichen ist Die Definiti on des Zielartefakts bildet den Abschluss jedes Teilkapitels An dieser Stelle wird auch auf m gliche Schw chen eingegangen die zu einem R cksprung f hren K nnen Zum Abschluss dieses Einf hrungskapitels wird nun auf die Rollen eingegangen die an dem Prozess beteiligt sind Die Rollen stehen dabei f r unterschiedliche Kompetenzen bzw unter sch
305. s dSoD Adapted from FS 01 Chapter 3 3 Information 10 Basics NIST RBAC constrained RBAC with hierarchies Modellspezifikation von statischem separation of duty Konflikte im Zusammenhang mit Rechten tiber die ein Benutzer verfiigt werden in einer rol lenbasierten Zugriffskontrollarchitektur dadurch verursacht dass ein Benutzer in Rollen einge teilt ist die ihrerseits Rechte subsumieren die sich gegenseitig ausschlie en Eine M glichkeit diesen Sachverhalt zu vermeiden ist die Definition von statischen SoD constraints Der RBAC Standard sieht dazu die Definition von Beschr nkungen f r die Relation Benutzer Rolle vor Das bedeutet dass bei der Einteilung eines Benutzers in eine Rolle r berpr ft werden muss ob eine Beschr nkung f r r definiert wurde Sollte der Benutzer bereits ber eine Rolle r verf gen die sich mit r wechselseitig ausschlie t kann die Einteilung nicht durchgef hrt werden Im Allgemeinen stellt ein SoD constraint somit eine Menge an Rollen dar von denen ein Benutzer maximal eine besitzen darf Der NIST RBAC Standard nennt zwei Arten wie statisches SoD technisch umgesetzt werden Kann Entweder verf gt jede Rolle ber eine eigene Liste oder es existiert eine global vorgehaltene Liste mit den Rollen die sich wechselseitig ausschlie en Wenn sich die Mitglieder einer Rolle ndern muss nun jedes Mal gepr ft werden ob ein stati sches SoD constraint vorliegt um die Policy Konformit t si
306. s durch Platzhalter Attribute ein Verweis auf individuelle Benutzerattribute realisiert wird die zur Laufzeit ausgewertet werden wird bei Policys durch Joker Werte der Bezug zur Organisation angegeben Obwohl sich die Prinzipien hier hneln ist die Zielsetzung dabei jedoch eine ganz andere W hrend bei Platzhalten die Dynamik im Wirkbetrieb unterst tzt wird k nnen durch Joker Attribute Rollen auf der Basis von Regeln automatisch erzeugt werden Dies f llt somit in den Bereich der Rollenmodellierung und nicht des Rollenmanagements Zum Abschluss soll auch dieser Sacherverhalt durch ein Beispiel verdeutlicht werden Ein Un ternehmen habe mehrere Abteilungen die technische Systeme eigenst ndig betreiben Ein Mi tarbeiter in der Rolle Administrator arbeite in allen diesen Abteilungen gleicherma en Dazu ben tige er die Systemrollen SR_AbteilungA SR_AbteilungB und SR_AbteilungC wo bei f r die Verwaltung dieser Rollen jede Abteilung selbst zust ndig ist Dabei subsumieren diese drei Systemrollen die Rechte die in der Aus bung der Rolle Administrator in den drei Abteilungen ben tigt werden Ohne Joker Berechtigungen verf gt die Rolle Administrator ber drei Systemrollen mit den darin definierten Policys Verwendet man die hier modellierten Forschungsgruppe C amp M Entwicklung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen 87 Joker Policys werden lediglich die Policys definie
307. s Information 19 hervorgeht Dadurch ist eine weitere Strukturierung unabh ngig von der Organisation oder Rol lenhierarchien m glich Diese dient dazu die unterschiedlichen Auspr gungen von Rollen zu unterteilen etwa in Gesch ftsrollen und Systemrollen die ihrerseits nochmals nach der Zugeh rigkeit zu unterschiedlichen Endsystemen angeordnet sind Die Verkn pfung von Gesch fts und Systemrollen ist in OIM unmittelbar m glich da jede Rolle mit beliebig vielen weiteren Rollen direkt verkn pft sein kann In OIM verf gen die Datenobjekte Rolle und Organisations einheit ber einen Besitzer womit die Administration dieser Objekte delegiert und die Verant wortlichkeit f r diese Objekte dezentralisiert werden kann OIM passt sich den Bed rfnissen der Benutzer durch unterschiedliche Ansichten engl views an was im berblickskapitel bereits angesprochen wurde Diese Sichten richten sich an die un terschiedlichen Benutzergruppen die bei der Verwaltung von Rollen unterschiedliche Arbeiten ausf hren Der Arbeitsprozess zum Anlegen einer Rolle erstreckt sich somit ber mehrere Be fugnisgrenzen was in OIM dadurch zum Ausdruck kommt dass die einzelnen Arbeitsschritte in unterschiedlichen Sichten aufgef hrt werden Zun chst beginnt der Rollenverantwortliche die Gesch fts und Systemrollen in OIM anzulegen Dabei werden sie bereits einer Abteilung oder allgemein einer Gesch ftseinheit zugeordnet Auch werden hier die Rollen in einen Roll
308. s SRM Ka07b Somit deckt dieser erste Bereich des Role Manager die Bereiche business role modeling business role ma nagement IT role modeling IT role management und role modeling and discovery aus Informa tion 11 ab Im zweiten Bereich befinden sich Prozesse die sicherstellen dass die zugewiesenen Berechti gungen und Mitgliedschaften eines Benutzers korrekt sind engl attestation Der SRM erm g licht es einem Rollenverantwortlichen wie etwa einem Abteilungsleiter oder Manager diese Zuweisungen f r seine Mitarbeiter auf feingranularer Ebene zu kontrollieren Realisiert wird dies in zwei Schritten Zun chst kann f r jede Verbindung zu einer Datenquelle explizit ange geben werden welche Attribute von dort in das identity warehouse importiert werden An schlie end kann f r jedes Attribut angegeben werden ob es als zertifizierbares Attribut in SRM verwendet werden kann wodurch ausgedr ckt wird dass es an Rollen zugewiesen werden kann Die M glichkeit der attributbasierten Zuweisung ist insbesondere beim Einsatz von Sys temen wichtig die ein sehr umfangreiches und feingranulares Autorisierungsmodell besitzen Zus tzlich bietet das System die M glichkeit zum Weiterleiten einer Zuweisungsaufgabe an ei ne andere Person die nach Ablauf einer Frist automatisch an die ausstehende Arbeit erinnert wird Dies stellt sicher dass die Anfrage nicht vergessen wird Da ein Unternehmen fortlaufend nderungen personeller oder organisatorischer
309. s Vorgehensmodell aus Kapitel 5 modelliert die Entwicklung von Rollen als hybriden Pro zess der den top down Ansatz mit dem bottom up Ansatz kombiniert und so zur Entwicklung von Gesch fts und Systemrollen f hrt Diese explizite Unterscheidung des Rollenbegriffs stellt einen wesentlichen Beitrag von BRBAC dar Aus diesem Grund sollte das ausgew hlte Werk zeug sowohl ein hybrides Vorgehen als auch eine Unterscheidung beim Rollenbegriff zulassen Wie die Analyse in den Kapiteln 6 2 und 6 3 zeigt wird momentan weder im Omada Identity Manager OIM noch im Sun Role Manager SRM explizit zwischen Gesch fts und System rollen unterschieden obwohl eine implizite Unterscheidung in beiden Werkzeugen dennoch m glich ist Obwohl die konkrete Auslegung des Rollenbegriffs in beiden Werkzeugen durch aus unterschiedlich ist bietet keines der Werkzeuge einen klaren Vorteil bei der technischen Umsetzung von BRBAC im Bezug auf den Rollenbegriff Im Hinblick auf die Rechtevererbung entlang der Rollenhierarchien die BRBAC modelliert weist der Omada Identity Manager zwar eine bessere Unterst tzung auf jedoch ist dies f r das Beispielszenario eher von untergeordne ter Bedeutung Bereits aus Information 1 geht hervor dass die Anzahl von Systemrollen in Unternehmen um bis zu zwei Gr enordnungen gr er ist als die Zahl der Gesch ftsrollen In Anbetracht dieser Tatsache stellt vor allem die Modellierung von Berechtigungen bzw daraus abgeleiteter Sys
310. s und durch die Unterschiedlichkeit der Technologien unterscheidet sich dieser Rol lenbegriff teilweise sehr stark Ein typischer Unternehmensbenutzer muss ber Zugriffsrechte in unterschiedlichen Systemen verf gen nur ist oftmals eine Rolle ein auf ein einzelnes System eingeschr nkter Begriff f r Zugriffsrechte Die Autoren halten es f r unrealistisch davon aus zugehen dass diese Rollenbegriffe eines Tages auf einen gemeinsamen Nenner gebracht wer den k nnen und ziehen den Ansatz von Unternehmensrollen als Beh lter f r die Menge an un terschiedlichen Auffassungen f r Rollen vor Das von den Autoren vorgestellte Produkt SAM dient daher nicht als Autorisierungsplattform sondern als Plattform auf einer h heren Abstraktionsebene die sich quer ber alle Systeme erstreckt und die unterschiedlichen Systeme unter einer Plattform vereint L6 F r die Implementierung von unternehmensweiten Rollen pr sentieren die Autoren ein vierstufiges Prozessmodell an bestehend aus der Konsolidierungsphase in der unter anderem der Bestand an Rollen aufgenommen und analysiert wird engl role analysis Gleichzeitig wird die Rollen Software implementiert und die Unternehmenssysteme daran angeschlossen Die zweite Phase befasst sich mit der Automatisierung was den Entwurf von Automatismen inner halb des Rollenentwurfs engl role design betrifft Parallel kann in dieser Phase die Verbin dung zu den einzelnen Informationsbest nden der U
311. sability 6 Support of Feedback 7 Service oriented approach Information 53 Analysis of Role Management Solutions Evaluation of SRM 6 3 2 Anwendung des Kriterienkatalogs Information 53 zeigt die Bewertung des Sun Role Manager am Kriterienkatalog Im Folgenden wird nun einzeln auf die sieben Kriterien eingegangen und die Bewertung begriindet Rollen Der Sun Role Manager fasst eine Rolle generell als Gesch ftsrollen auf bietet aber auch eine native Unterst tzung von Systemrollen an Dazu werden Rollen mit einem Rollentyp versehen der diesen Unterschied festlegt Diese Festlegung ist allerdings lediglich eine semantische Spe zifikation die in SRM in der vorliegenden Version nicht beachtet wird Mit den Policys wird ein Mechanismus angeboten um technische Berechtigungen mit Gesch ftsrollen direkt zu ver kn pfen Rollen verf gen neben einer Menge an Policys und einen Rollenverantwortlichen so wie Organisationseinheiten in denen sie verf gbar ist insbesondere ber eine Menge an Benut zern die mit ihr verkn pft sind Somit kann eine Gesch ftsrolle mit den darin definierten Policys in unterschiedlichen Kontexten wiederverwendet werden Benutzer in unterschiedlichen Abteilungen erhalten somit durch die Einteilung in eine Rolle alle der darin definierten Berech tigungen in den technischen Endsystemen Gesch ftsrollen werden versioniert so dass nde rungen zur ckverfolgt und wiederhergestellt werden k nnen
312. sation sowie die formalisierten Aufgaben innerhalb des Unternehmens eingef hrt wurden Aus diesem Grund verf gen Sie ber den angemessen Ausschnitt der Unternehmens struktur und k nnen die Gesch ftsrollen sowie deren Hierarchie zusammen mit gesch ftlichen Aufgaben in Form von Gesch fts Policys definieren Forschungsgruppe C amp M 100 Entwicklung eines Vorgehensmodells fiir die rollenbasierte Zugriffskontrolle Der bottom up Ansatz der auf der Ebene der technischen Systemen verfolgt wird entsteht unter Beteiligung der Consultants die zusammen mit den Fachabteilungen in einem iterativen Vorge hen die technischen Berechtigungen aus der Analysephase nach Zugriffsmustern durchsuchen und zu Systemrollen kapseln Wie bereits angesprochen wurde kann dieser Prozess durch ge eignete Werkzeuge zum automatisierten Entwickeln von Rollen aus dem Datenbestand des Un ternehmens engl role mining unterst tzt werden Andernfalls gestaltet sich diese Phase als sehr arbeitsintensiv weil es im Allgemeinen sehr viele Einzelberechtigungen gibt die indivi duell konsolidiert werden m ssen um eine konsistente Implementierung dieser Rollen in der n chsten Phase zu gew hrleisten Durch die Einbeziehung der Gesch ftsleitung sowie der Fach abteilungen wird das Verst ndnis des entstehenden Rollenmodells stark gef rdert weil sie sich selbst intensiv einbringen k nnen und das implementierte Rollenmodell dadurch stark beeinf lussen k nnen Auf der ande
313. schen Aufgabenbe reiche wurden bereits in Kapitel 2 3 vorgestellt Da die Kriterien unterschiedliche Werkzeuge und deren Architekturen vergleichen sollen kann eine einheitliche Metrik f r die gew hlten Kriterien nicht gegeben werden Stattdessen werden die Werkzeuge f r jedes Kriterium indivi duell eingestuft und miteinander in Bezug gesetzt Es wurde darauf geachtet die typischen Funktionen einer Rollenmanagementanwendung ganzheitlich zu erfassen wie etwa die Identifi kation von Rollen als initialer Ausgangspunkt beim Einsatz einer derartigen L sung oder die M glichkeiten zur Implementierung des Rollenmodells sowie die Wartung der L sung im pro duktiven Einsatz Insgesamt betrachtet sind die unterschiedlichen Kriterien so gew hlt dass hie raus ersichtlich wird ob ein Werkzeug eine angemessene Unterst tzung beim Einsatz von BRBAC anbietet oder nicht Nachdem der Aufbau des Kriterienkatalogs und dessen Bedeutung f r diese Arbeit erl utert wurden folgt nun eine detaillierte Vorstellung der einzelnen Kriterien Das erste Kriterium befasst sich mit der Konzeption von Rollen in einem Rollenmanagement werkzeug Damit ist gemeint was ein derartiges Werkzeug unter einer Rolle versteht und wel che Granularit t die implementierten Rollen besitzen Es erfasst zu welchem Grad Rollen als allgemeine Einheiten zur Kapselung von Benutzern und Policys unterst tzt werden Im Kontext dieser Arbeit ist es elementar dass ein entsprechendes Werk
314. schen R ckf h rung von Rollen und Rolleninformationen in die technischen Endsysteme des Unternehmens bewertet und abschlie end eine subjektive Einsch tzung der Benutzerfreundlichkeit gegeben Es lie sich feststellen dass der Omada Identity Manager Vorteile bei der Unterst tzung von workflows besitzt sowie bei denjenigen Kriterien die nicht in unmittelbarem Bezug zu den Rol lenmodellen dieser Arbeit stehen und der Sun Role Manager durch die role mining Komponente sowie dessen Rollenmodell Vorteile aufweist Dies wurde in einem abschlie en den Fazit herausgestellt Abschlie end wurde in Kapitel 7 die technische Umsetzung von BRBAC gem dem Vorge hensmodell in einem der beiden Werkzeuge durchgef hrt Dazu wurde zun chst ein Beispiel szenario und die darin definierten Gesch fts und Systemrollen vorgestellt Anschlie end wurde mit dem Sun Role Manager dasjenige Werkzeug ausgew hlt das in diesem Szenario f r die Umsetzung besser geeignet ist und anschlie end auf die Implementierung der Rollen aus BRBAC eingegangen Auch wurden die Vorteile der expliziten Trennung anhand des Szenari ons belegt und illustriert Den Abschluss dieses Kapitels bildete eine Betrachtung der Rollenbe triebsphase sowie die vom Sun Role Manager hierf r zur Verf gung gestellten Komponenten 8 2 Ausblick auf zuk nftige Forschungsarbeiten In diesem abschlie enden Kapitel sollen Ankn pfungspunkte f r weitere Forschungen aufge zeigt werden Mit BRBAC w
315. scher und werkzeugunterst tzer Prozess muss gefunden werden D2 Mit einer top down Vorgehensweise die Rollenfindung zu initiieren ist aufgrund der ge wachsenen Strukturen w nschenswert allerdings sehr schwierig Die gewachsenen Strukturen sind zumindest teilweise inkorrekt und inkonsistent Die Analyse von Benutzern in hnlichen Gesch ftsrollen liefert oftmals unterschiedliche Berechtigung Der Ansatz der Autoren ist hier data mining Technologien auf einen aggregierten Informationsstamm anzuwenden Pr missen Welche Einschr nkungen und Vorgaben werden hinsichtlich der eigenen L sungen gemacht Pl Das Vorgehen der Autoren basiert auf dem ERBAC Standard welcher ber keine Hierar chien constraints und SoD verf gt P2 Das Vorgehensmodell ist bottom up mit dem Ergebnis einer flachen Rollenstruktur anstatt einer Hierarchie aus Zugriffskontrollsystemen und Gesch ftsrollen P3 Der Ansatz der Autoren geht von einer zentralen Datenbank aus die ber Informationen aus allen im Einsatz befindlichen Anwendungssystemen mit eigener Zugriffskontrolle verf gt P4 Die IT Abteilung muss im vorgestellten Prozess mit eingebunden sein um das Resultat des role mining zu verifizieren Dies geschieht vor der Implementierung P5 Das Ausrollen der Rollenstruktur auf das Unternehmen geschieht Schritt f r Schritt L sungen Was sind die eigenen L sungen L1 Das Vorgehensmodell der Autoren kann in drei Phasen eingeteilt werden die
316. se Entwurfsphase Implementierungsphase und die abschlieBende Be Forschungsgruppe C amp M 8 Einleitung triebsphase Da ed consult als Beratungsunternehmen sowohl tiber technisches Wissen verfiigt als auch die Unternehmensstrukturen von c amp m kennt ist es an dem gesamten Prozess federfiih rend beteiligt In einem ersten Schritt zur Einf hrung einer rollenbasierten Unternehmensstruk tur ist es n tig eine Bestandsaufnahme der technischen und organisatorischen Strukturen vor zunehmen Hier spiegelt sich das eingangs erw hnte hybride Vorgehen wider 55 Overview of procedure model Phase ed serv ed consult ed consult ed consult c amp m Top down p Bottom up Analysis Analysis of Technical Permissions Definition of Organisation Concept Analysis of Tools Design Definition of System Gq Definition of Business Roles Roles and Role Owners Specification of Mapping Implementation Deployment of Roles Operation Role Operation and Role Management Information 5 Introduction Procedure Model In der Aktivit t Analysis of Tools werden bestehende Werkzeuge aus dem Rollenmanagement analysiert Diese Arbeit besch ftigt sich in Kapitel 6 mit eben dieser Analyse und greift dabei auf die beiden Werkzeuge Omada Identity Manager und Sun Role Manager zur ck Anschlie Bend werden Gesch fts und Systemrollen werkzeugunterst tzt modelliert In der abschlie en den Phase muss nun ein Zusammenhang zwischen
317. sich in Form des Rollentyps engl role type aus So kann eine Rolle sowohl als Einheit f r ge sch ftliche Funktionen dienen was der in dieser Arbeit verwendeten Gesch ftsrolle entspricht als auch technische Details kapseln Dies steht in Bezug zu dem hier definierten Begriff System rolle Dar ber hinaus kann in OIM ein einzelnes Benutzerobjekt ebenfalls eine Rolle darstellen was im Folgenden aber nicht weiter beleuchtet oder differenziert wird In OIM existiert eine Vielzahl unterschiedlicher Hierarchien So gibt es zun chst eine Hierarchie auf Ebene der Ge sch ftsstruktur womit sich Niederlassungen Zweigstellen oder Abteilungen abbilden lassen Davon losgel st existiert eine Rollenhierarchie bei Systemrollen OIM unterst tzt dabei nicht Forschungsgruppe C amp M Stand der Technik 45 nur den Aufbau einer Hierarchie sondern auch die Vererbung von Rechten Dies wird dadurch realisiert dass Mitgliedschaften in Systemrollen an hierarchisch untergeordnete Systemrollen weitergegeben werden Auf einer dritten davon unabh ngigen Abstraktionsebene wird jede Rolle eindeutig in einem Rollenordner engl role folder abgelegt der seinerseits ebenfalls in eine Hierarchie eingebunden ist OIM bietet Einschr nkungen engl constraints f r Rollen an wodurch etwa das SoD Prinzip umgesetzt wird Erm glicht wird diese Form der Einschr nkung dadurch dass explizit definiert werden kann welche Rollen sich wechselseitig ausschlie en Diese c
318. smodelle fiir RBAC in heterogenen Systemlandschaften 155 F 3 Role Mining Revealing Business Roles using Data Mining Technology 156 F 4 Observations on the Role Life Cycle 220022002sensnersneesnnesnnesnnesnennnennnnnnnn 159 F 5 A role based infrastructure management system unnerssessnessesnnesnnesnnennnnnne nen 162 Eiter t r 1 Ge E A lcetnts eebes fetes 166 Forschungsgruppe C amp M Einleitung 1 1 EINLEITUNG In den letzten Jahren wurde im Bereich der Zugriffskontrolle der Begriff Rolle sowohl in der Forschung aber auch in der Industrie sehr stark diskutiert und untersucht W hrend die For schung prim r daran interessiert war theoretische Modelle zu entwickeln orientierte sich die Industrie sehr stark an den konkreten Bed rfnissen von Unternehmen Ka07b Diese verspra chen sich von einer rollenbasierten Zugriffskontrolle angesichts immer komplexerer Infrastruk turen zeitliche Einsparungen und effizienteres Arbeiten in Verwaltungst tigkeiten aber auch ei ne bessere Einhaltung gesetzlicher Vorgaben Die Zielsetzung der Untersuchungen war somit sehr unterschiedlich was dazu f hrte dass zwischen den beiden Herangehensweisen an diese Thematik eine gro e L cke entstand In dieser Arbeit werden Rollenmodelle f r die rollenbasierte Zugriffskontrolle entwickelt die sich besser an die Gegebenheiten in Unternehmen anpassen und so die L cke zwischen theoreti schen Rollenm
319. snnnnnnnensnnnennnnnnsnnnnnsnennnsennen 111 6 2 Bewertung des Omada Identity Manager u220022002snursnnesnnesnnesnnennnnennnnnnnennnennnennnen 113 6 2 1 Verkn pfung zum Stand der Technik eee ceesceceseceeeeeceeaceceeeeeesaeeeeaeeeeneeees 113 6 2 2 Anwendung des Kriterienkatalogs ur2uu0s0220nesnneennesnnnennnennnennennnennnen 114 6 3 Bewertung des Sun Role Manager u 22002200220rsnersneesnnennnesnnennnennnnnnsnnnnnensn essen 116 6 3 1 Bezug der Kriterien zum Stand der Technik 222022200220n nennen 116 6 3 2 Anwendung des Kriterienkatalogs ee eeeceesseceenceceeeeeeaeceeaeeceeeeeesaeeeeaaeceeaeeees 117 6 4 Res mee eis E E E EE Ss adea NE E EEE TE EN 119 7 Fallstudie zur Anwendung der Modelle in einem kommerziellen Produkt 121 7 1 Vorstellung des Beispielszenarios internet supported training ssessseeeeeeeereeeee 121 7 1 1 Vorstellung der Gesch ftsrollen 0 ee eeeeesceeneeeseeeeecaecnseceseceseeeeeeseeeseeees 122 7 1 2 Vorstellung der Systemrollen sseeesseeeeeseeeeesesressesrresessrsstesresresresessesrrssresssreee 123 7 2 Instanziierung von BRBAC in einem kommerziellen Rollenmanagementwerkzeug 125 7 2 1 Auswahl des Rollenmanagementwerkzeugs esenereeereereereeresrresrrrreereeresreee 125 7 2 2 Rollenanalyse und Rollenentwurf 220022002200nsnersneesnnesnnesnnesnnennneennnnnn 127 7 2 3 Das Rollenmodell BRBAC im Beispielsz
320. ss Sun Java Application Server Die unterstiitzten Betriebssysteme sind e Microsoft Windows Server 2000 SP3 Microsoft Windows Server 2003 Solaris 8 9 10 Red Hat Linux 4 5 Novel SuSE Linux Enterprise 9 10 Die aktuelle Version des Sun Role Manager beinhaltet Apache Tomcat 5 5 16 welcher sowohl als Anwendungs als auch als Webserver dient Diese Arbeit verwendet die Variante mit dem Apache Tomcat 5 5 16 als Anwendungs und Webserver und Microsoft SQL Server 2005 als Forschungsgruppe C amp M 144 Anhang Datenbankserver Als Basisbetriebssystem wird Microsoft Windows Server 2003 R2 eingesetzt Im Folgenden wird nun zun chst die Installation des Apache Tomcat sowie des Microsoft SQL Servers demonstriert AnschlieBend wird SRM installiert und fiir den Einsatz des Szenarios in Kapitel 7 dieser Arbeit konfiguriert Es wird von einer bestehenden Installation des Windows Servers 2003 R2 ausgegangen auf die hier nicht eingegangen wird Eine schrittweise Anleitung zur Installation des Betriebssystems findet sich unter Mic05a Installation Process of Sun Role Manager Pre installation Basic Server Systems Sun Role Manager Installation prerequisites Installation of Windows Server 2003 R2 Installation of Microsoft SQL Server 2005 Post installation configuration Installation of Apache Tomcat Installation of Sun Role Manager Post installation Configuration Information 63 Appendix Installation Process of Sun Ro
321. stand einer Rolle bringt die Versionierung mit sich Hierbei werden nderungen an Rollen nicht berschrieben sondern stattdessen eine neue Version der Rolle erzeugt und der bisherige Stand zus tzlich in der Rolle mitgef hrt Dies geschieht bei jeder nderung an Rolleneigenschaften um eine l ckenlose Historie zu gew hrleisten 3 3 4 Der Arbeitsbereich identity certification Der Arbeitsbereich identity certification verk rpert das Verwalten von Zuweisungen jeglicher Auspr gung im Sun Role Manager Hierbei ist es durch die integrierten Arbeitsabl ufe engl workflows m glich den Verwaltungsprozess aufzuteilen und so die Zuweisungen an das je weils daf r verantwortliche Personal zu delegieren Diese Aufteilung unterst tzt somit das De zentralisieren von Arbeiten innerhalb eines Unternehmens Der gesamte Bereich umfasst zwei Teilaufgaben Einerseits das berwachen des aktuellen Standes der Zuweisungen im Unter nehmen und andererseits das Durchf hren dieser Zuweisungen engl certifications Abgeleitet von der bersetzung aus dem Englischen wird daf r auch der Begriff Zertifizierungen zur Bezeichnung von Zuweisungen verwendet Forschungsgruppe C amp M 64 Stand der Technik Identity Certification B elit nec il MGC EERE Cea mec eas ae tT is Administration gt Dashboard My Certifications Certification Jobs Certifications By Status Summary User Accounts Certification Status Total number Count of users
322. steme S in der Gr enordnung von etwa 10 liegt Jedes System S verf gt ber k eigene Systemrollen SR SRi2 SR was in der Summe aller Systemrollen der Gr Benordnung 10 000 entspricht Eine Gesch ftsrolle BR von denen meist um die 100 verschie denen Rollen existieren akkumuliert eine Teilmenge dieser Systemrollen Ka07c Der ent scheidende Punkt ist nun dass das Zuordnen von Gesch fts und Systemrollen in Anbetracht der Zahlen manuell nicht mehr in korrekter und konsistenter Weise erledigt werden kann Dies verdeutlicht die Notwendigkeit nach Ma nahmen die diese Zuordnung unterst tzen wie etwa Rollenmanagementwerkzeuge Diese stellen in Aussicht den Aufbau einer rollenbasierten Ge samtstruktur zu unterst tzen Leider gibt es bisher kein standardisiertes Vorgehen um unter nehmensweit Gesch fts und Systemrollen zu identifizieren weil das hierf r ben tigte Wissen ber verschiedene Abteilungen verteilt ist Zum Einen kann das technische Personal entschei den ber welche Rechte ein Benutzer verf gen muss da es die technische Seite des oder der Systeme kennt Die Sichtweise dieses Personals ist oftmals sogar beschr nkt auf nur ein einzel nes System das es selbst verantwortet Zum Anderen hat die Personalabteilung den berblick ber die Gesch ftsfunktion dieses Benutzers jedoch fehlt hier der technische Einblick in die vorhandenen Systeme Somit erstreckt sich der Prozess sowohl ber eine Verantwortlichkeits ket
323. strained RBAC Modell erweitert den NIST RBAC Standard um die M glichkeit Be schr nkungen engl constraints f r Relationen zu definieren Wie aus Information 7 hervor geht stellt constrained RBAC keine Erweiterung des in Kapitel 2 2 2 eingef hrten hierarchi schen RBAC Modells dar sondern basiert in gleicher Weise auf core RBAC Im Gegensatz zu Hierarchien f hrt dieses Modell Beschr nkungen als Erweiterung ein um zu erm glichen dass die Modellelemente nur unter gewissen Umst nden zueinander in Relation gestellt werden k n nen Dies wird etwa dazu verwendet separation of duty SoD zu modellieren Dieses Prinzip verk rpert den wechselseitigen Ausschluss f r Berechtigungen etwa um es Benutzern unm g lich zu machen das in ihrer Jobfunktion definierte Ma an Rechten zu berschreiten Da Be rechtigungen in Rollen gekapselt sind operieren separation of duty Beschr nkungen nicht auf einzelnen Berechtigungen sondern auf Rollen Dieser Ansatz f hrt somit dazu dass eine ber schreitung von Berechtigungen innerhalb einer Organisation durch die Zugriffskontrollarchitek tur vermieden wird und lediglich au erhalb dessen Einflussbereichs auftreten Kann Ein Beispiel hierf r sind Verst e die zwischen Mitarbeitern direkt kommuniziert werden Die Policy Konformit t stellt einen wichtigen Aspekt in Zugriffskontrollarchitekturen dar wie unter ande rem SB08 belegt was die Bedeutung von SoD constraints beim Einsatz einer rollenbasiert
324. strator E lleShare Full Access E Domain User E Write Access Security Consultant ed consult Service Manager ed serv th Complex System Roles ing wi Role Mapp ix Append Information 66 Forschungsgruppe C amp M Anhang 149 D Abk rzungen Abk rzung ACL ACM ADO NET ASP NET BR BRBAC C amp M c amp m CMS CSV dSod ed consult ed serv ed soft ed tec ERBAC 12s IBAC ILM IST IT J2EE Java EE JDBC KonTraG Langbezeichnung und oder Begriffserkl rung Access control list dt Zugriffskontrollliste Association for Computing Machinery ActiveX Data Objects auf NET Technologie Active Server Pages auf NET Technologie Business role dt Gesch ftsrolle Business focused role based access control Cooperation and Management cooperation amp more Organisation innerhalb des IST Szenarios Content Management System Comma separated values Dynamisches SoD education consulting Organisation innerhalb des IST Szenarios education services Organisation innerhalb des IST Szenarios education software Organisation innerhalb des IST Szenarios education technology Schulungsportal aus dem IST Szenario Enterprise role based access control Organisation innerhalb des IST Szenarios Identity based Access Control dt identit tsbasierte Zugriffskontrolle Microsoft Identity Lifecycle Manager Internet supported training Szenario Information technology
325. suchung dieser Entwurfsmuster sei an dieser Stelle verwiesen auf KK 02 Es kann Situationen geben in denen einige Teile des Rollenmodells manuell und andere automatisch verwaltet werden sollen Dazu kann man mehrere parallele Rollengraphen verwenden von denen einige Teile der manuellen Verwaltung unterliegen und andere automatisiert verwaltet werden In diesem Fall existieren mehrere voneinander unab h ngige Hierarchien wobei insbesondere die Schnittstellen zwischen ihnen bzw die Beziehungen zueinander interessant sind und besonders beachtet werden m ssen Um auch manuelle Aufgaben in der Administration zu erm glichen ist es wichtig dass n derungen in den manuellen Teilen keine der erw hnten Algorithmen ausf hren und so mit au erhalb des Einflussbereichs der Algorithmen liegen Ein zweites Muster modelliert nur ein einzelnes Rollenmodell Dieses besteht aus unter schiedlichen Hierarchien und fasst somit semantisch unterschiedliche Begriffen zu sammen Dieser Ansatz vereint demnach unterschiedliche Aspekte in einem einzigen Baum Dies k nnen beispielsweise organisatorische Aspekte wie etwa der Ort oder die Abteilung sein kombiniert mit technischen Aspekten wie etwa den Benutzern oder Job profilen Durch die Vereinigung unterschiedlicher Organisationstypen f r die unter schiedliche Arbeitsprozesse notwendig sind zieht dieser Ansatz f r jeden Teilbaum un terschiedliche Automatisierungsprozesse nach sich In einem dritten Ansa
326. t Die letzte Phase des Vorgehensmodells befasst sich zentral mit der Pflege des Rollenmodells im Wirkbetrieb und kommt somit der Forderung nach dass das Vorgehensmodell als Lebenszyklus aufgefasst werden kann Auch in diesem Kapitel wurden die zentralen Aspekte kurz zusammen gefasst Das Ziel von Kapitel 6 war die Bewertung der Rollenmanagementwerkzeuge die in Kapitel 3 bereits eingef hrt wurden Dazu wurde zun chst ein Kriterienkatalog entwickelt und eine Met rik f r die Kriterien bestimmt Dabei wurden solche Kriterien die f r den Einsatz von BRBAC wichtig waren ebenso ausgew hlt wie solche die das Werkzeug in seiner Gesamtheit bewerten sollten Das erste Kriterium Rollen befasste sich mit der Unterst tzung von Gesch fts und Systemrollen im vorliegenden Werkzeug Das zweite Kriterium Hierarchien bewertete den Unterst tzungsgrad f r Hierarchien wobei auch hier die beiden Rollentypen differenziert be trachtet wurden Das dritte Kriterium bewertete die Unterst tzung von role mining Algorithmen zur Entwicklung von Rollen Mit der Bewertung von automatischen Arbeitsabl ufen engl workflows wurde die Unterst tzung f r administrative Aufgaben im produktiven Einsatz be wertet Diese Kriterien standen in unmittelbarer Relation zu den Rollenmodellen die in den Ka piteln 4 und 5 entwickelt wurden Zur querschnittlichen Bewertung der Werkzeuge wurden noch die Unterst tzung von dienstorientierten Architekturen und der automati
327. t erf llt die durch die Joker Policy festgelegt ist wird dem Benutzer diese Systemrolle im vorliegenden Kontext entzogen Diese Betrachtung beendete die Entwicklung des Rollenmodells BRBAC welches zum Schluss in seiner Gesam theit dargestellt wurde und die bisher einzeln betrachteten Aspekte in Kombination beleuchtet wurden Nach der Entwicklung des Rollenmodells wurde in Kapitel 5 ein Vorgehensmodell entwickelt welches das Rollenmodell BRBAC in den Wirkbetrieb berf hrt Ein zentrales Ziel war es da her dass sich die in BRBAC geforderte Trennung von Gesch fts und Systemrollen auch im Vorgehen widerspiegelt Eine zweite Forderung stellte die explizite Beachtung des Lebenszyk lus von Rollen dar Um dieses Ziel zu erreichen wurde ein hybrides Vorgehen entwickelt dass bei der Entwicklung von Gesch ftsrollen anders vorgeht als bei Systemrollen Bei der Entwick lung von Gesch ftsrollen wird gem dem top down Vorgehen von einer abstrakten Sicht auf ein Unternehmen ausgegangen und diese Sicht konkretisiert um daraus gesch ftliche Aufgaben zu identifizieren die in Gesch ftsrollen m nden Beim Entwurf von Systemrollen wird gem dem bottom up V orgehen bei der Analyse der existierenden technischen Einzelberechtigungen in den Endsystemen des Unternehmens begonnen und diese durch role mining Algorithmen zur Mustererkenung in Systemrollen zusammengefasst Das Vorgehen orientiert sich am klassi schen Entwicklungszyklus von Software und ist
328. t etabliert Dabei haben sich typische Aufgabenbereiche herauskristallisiert die in diesem Kapitel grundlegend eingef hrt werden ehe im folgenden Kapitel 3 Konkrete Werkzeuge aus dieser Sparte vorgestellt werden Die in diesem Kapitel vorgestellten Aufgaben werden im Fortgang dieser Arbeit f r die Entwicklung eines hybriden Vorgehensmodells in Kapitel 5 ebenso herangezogen wie f r die Entwicklung eines Bewertungskatalogs f r Rollenmanagementwerkzeuge in Kapitel 6 Im Folgenden wird zun chst ein berblick gegeben ber f nf verschiedene Kategorien bei der Unternehmensge staltung und diese anschlie end in Bezug gesetzt zu Aufgabenbereichen von Rollenmanage mentwerkzeugen Da die Aufgabenbereiche sehr unterschiedlich sind und innerhalb eines Un ternehmens von unterschiedlichem Personal ausgef hrt werden soll diese Unterteilung verdeutlichen an welcher Stelle im Unternehmen sie im Allgemeinen durchgef hrt werden Hierdurch wird erneut der Bezug hergestellt zu der aus Information 1 bekannten gesch ftlichen und technischen Ebene Jay R Galbraith besch ftigte sich in Ga02 mit der Unternehmensgestaltung und hatte dabei in sbesondere das Ziel eine f r die unterschiedlichen Ausrichtungen von Unternehmen m glichst effiziente Organisationsstruktur aufzubauen Dazu f hrte er in seinem Star Model f nf Katego rien ein die unterschiedliche Aspekte eines Unternehmens betrachten und von denen vier in ei nen direkten Zusammenhang zu den Aufgaben
329. t manuell vorgenommen werden muss Ein zweiter Vorteil entsteht aus einer Kombination von Gesch fts und Systemrollen dem wechselseitigen Ausschluss von Rollen und der Rechtevererbung Erst durch die explizite Trennung der Rollen ist es m glich auch technische und gesch ftliche Rech te Konsequent zu trennen und zwei unterschiedlichen Hierarchien zu pflegen Dadurch ist es nun m glich sehr feingranular auf die Rechte einzugehen und beispielsweise die Vererbung f r spe zielle Teilb ume zu unterbinden oder bei gewissen Rechten die berschreibung auszuschlie en Insbesondere bieten sich die Einsatzm glichkeiten die aus einer Kombination der hier vorges tellten Prinzipien f r weitere Forschungen an Hier wurden zwei m gliche Vorteile skizziert so dass an dieser Stelle durch weitere Arbeiten vertieft eingegangen werden kann Da in diesem Kapitel ein Rollenmodell entwickelt wurde stellt sich nunmehr die Frage wie vorgegangen werden sollte um dieses Modell technisch umzusetzen Dies wird im folgenden Kapitel n her betrachtet Forschungsgruppe C amp M Entwicklung eines Vorgehensmodells fiir die rollenbasierte Zugriffskontrolle 91 5 ENTWICKLUNG EINES VORGEHENSMODELLS FUR DIE ROLLENBASIERTE ZUGRIFFSKONTROLLE 5 1 Zieldefinition und Festlegung der Anforderungen In Kapitel 4 wurde mit BRBAC ein Rollenmodell mit der Zielsetzung entwickelt gesch ftliche und technische Aspekte von Rollen explizit voneinander zu trennen und dabei zu we
330. tal nur f r diese Hierarchiestufe angewandt und nicht an die Angestellten weitervererbt wird Als Beispiel f r das Attribut no override gehe man davon aus dass dieses Unternehmen im Sinne einer gemeinsamen Unternehmensidentit t engl corporate identity erreichen m chte dass alle Benutzer auf die Startseite der Firma umgeleitet werden ungeachtet dessen was in den einzel nen Hierarchiestufen definiert ist Dazu gen gt es in diesem Modell die Policy auf oberster Ebene mit dem Vererbungsattribut no override zu versehen um diese Einstellung uneinge schr nkt zu vererben Ohne die Verwendung der Vererbungsmechanismen w rde dieses Bei spiel als drei eigenen Systemrollen mit jeweils einer Policy umgesetzt St nden diese System rollen in einer hierarchischen Beziehung zueinander w re das skizzierte Beispiel bereits nicht mehr modellierbar oder man arbeitet mit damit dass sich Berechtigungen gegenseitig ber schreiben k nnen Dies w rde der Intuitivit t des Rollenmodells sowie seiner klaren Strukturie rung jedoch entgegenwirken Das Ergebnis dieses Ansatzes ist die Modellierung der Rechtevererbung die sehr klar struktu riert ist Zus tzlich dazu kann die Vererbung durch die Attribute gesteuert werden Die Auswer tung der effektiven Rechte eines Benutzerkontos findet hierbei dadurch statt dass die Vereini gungsmenge aus den einzelnen Policys unter Ber cksichtigung von constraints und den Vererbungsattributen gebildet wird 4 3 3
331. tants und der technischen Fachabteilung durchgef hrt werden Durch diese Interviews sollen Erfahrungen erfasst werden die sich aus den reinen Leistungsindikatoren nicht ablesen lassen Dies k nnen etwa Schwachstellen in den abgebildeten Prozessen oder subjektive Ein dr cke bei der Durchf hrung typischer Aufgaben sein Ziel der Implementierungsphase Das klare Ziel dieser Phase ist das entworfene Rollenmodell in den Wirkbetrieb zu berf hren und dabei zun chst eine Testphase zu pilotieren Zu diesem Zeitpunkt ist die bisher im Einsatz Forschungsgruppe C amp M Entwicklung eines Vorgehensmodells fiir die rollenbasierte Zugriffskontrolle 103 befindliche Zugriffskontrollarchitektur weiterhin autoritativ und die rollenbasierte Architektur lediglich Dienstnehmer Nach erfolgreichem Testbetrieb wird BRBAC dann Schritt fiir Schritt auf das gesamte Unternehmen ausgeweitet wobei immer noch ein Parallelbetrieb verfolgt wird Durch dieses Vorgehen k nnen schrittweise weitere Erfahrungen aus unterschiedlichen Abtei lungen gesammelt werden die eine falsche Benutzung der Rollenmanagementl sung oder eine inkorrekte Modellierung der Rollen sehr unwahrscheinlich werden l sst Nachdem der Parallel betrieb von BRBAC auf das gesamten Unternehmen ausgeweitet wurde und einer finalen ber pr fung der Erfahrungswerte aus der bisherigen Umsetzung stand h lt kann BRBAC zur autori tativen Zugriffskontrollarchitektur im Unternehmen werden und das Altsys
332. te dieses Ansatzes genannt werden die Aufschluss ber die Effektivit t des role mining Ansatzes geben In KS 03 wird auf zwei Fallstudien eingegan gen wobei im ersten Fall die Zeit zum Entwickeln von Rollen im Gegensatz zum Klassischen Implementieren von Rollen n her betrachtet wird Der zeitliche Aufwand im Vergleich zum Entwickeln ohne Algorithmenunterst tzung konnte um zwei Gr enordnungen verringert wer den im Speziellen Konnte die Entwicklungszeit von einigen Monaten auf einige Stunden ver ringert werden Im zweiten Fall lag der Fokus eher auf den Vorteilen im laufenden Betrieb Die ser Modellrechnung lag die Voraussetzung zugrunde dass die Anzahl der Mitarbeiter j hrlich um 10 zunehmen w rde und die Anzahl der Rollen im gleichen Zeitraum um 5 In diesem Fall konnte eine Kostenreduktion bei der Rollenerzeugung von 60 und im Betrieb von 50 erreicht werden Forschungsgruppe C amp M 32 Stand der Technik 3 1 2 Rollenmodell fur unternehmensweite Zugriffskontrolle ER BAC Untenehmen sehen sich heutzutage 6konomischen und technischen Anderungen ausgesetzt die eine h here Flexibilit t und eine h here Effektivit t bei Zugriffskontrollarchitekturen fordern Eine typische Unternehmenslandschaft besteht heutzutage aus einer Menge unterschiedlicher technischer Systeme wie etwa Betriebssystemen Datenbanken und Anwendungen Der Zugriff auf diese Endsysteme wird durch eigene Sicherheitskomponenten oder sogar durch eigenst
333. te und damit einhergehend auch ber einen langen Zeitraum Der zweite Schwerpunkt dieser Arbeit liegt darin ein Vorgehensmodell zu entwickeln das die Verkn pfung von Gesch fts und Systemrollen im Unternehmenskontext unterst tzt sowie die Entwicklung von Rollen als ganzheitliche Aufgabe im Sinne eines Lebenszyklus modelliert Es basiert auf dem entwickelten Rollenmodell unterscheidet bei der Entwicklung von Gesch fts und Systemrollen zwischen zwei unterschiedlichen Vorgehensweisen und erm glicht somit eine strukturierte und klare Entwicklung dieser beider Rollentypen Bei der Identifikation von Rollen in einer gewachsenen Unternehmensstruktur existieren drei unterschiedliche Vorgehensweisen die als Grundlage f r die Instanziierung des Rollenmodells verwendet werden Beim top down Vorgehen wird von den Unternehmensstrukturen und Gesch ftsfunktionen ausgegangen und versucht diese Funktionen in wohldefinierte Gesch ftsrollen darzustellen und schrittweise zu verfeinern Beim bottom up Vorgehen versucht man hingegen Berechtigungen ausgehend von technischen Zugriffsrechten schrittweise zusammenzufassen und somit allgemeine Sys Forschungsgruppe C amp M Einleitung 5 temrollen zu konzipieren Die Frage die sich hier stellt ist in welchen Situationen diese Vorge hen Vorteile aufweisen und wie sie sich entsprechend kombinieren lassen Das dritte Vorgehen middle out V orgehen steht f r einen hybriden Ansatz der beide Vorgehensw
334. technische und gesch ftsnahe Aspekte der Rollenmodel lierung unterschieden werden weil diese Unterscheidung durch das zugrundeliegende Rollen modell BRBAC ja explizit erm glicht wird Der Teilprozess zur Erfassung des Ist Zustands ist Forschungsgruppe C amp M Entwicklung eines Vorgehensmodells fiir die rollenbasierte Zugriffskontrolle 95 somit zweigeteilt und kann unabh ngig voneinander geschehen Hierdurch wird die Anforde rung A umgesetzt die ein hybrides Vorgehen fordert e Auf der Gesch ftsebene ist es zu diesem Zeitpunkt erforderlich den Aufbau der Orga nisation und der Abteilungen zu erfassen die im Unternehmen vorhanden sind engl business analysis Zu dieser Besch ftigung geh rt einerseits die Erfassung der ver schiedenen hierarchischen Strukturen wie etwa Abteilungen oder Niederlassungen aber auch die Erfassung der gesch ftlichen Aufgaben die im Allgemeinen bisher weni ger in formaler und eher in informeller Art definiert sind Diese Strukturen k nnen durch Abh ngigkeitsgraphen oder die Strukturdiagramme der Modellierungssprache UML formalisiert werden OMG07 Zu diesem Zeitpunkt im Vorgehensmodell ist es wichtig ein geschlossenes Gesamtbild des Unternehmens auf einer Abstraktionsstufe zu erzeugen die f r die Beteiligten intuitiv verst ndlich ist Diese Erfassung beginnt somit top down und die Verfeinerung sowohl syntaktisch als auch technisch ist erst Bestandteil der n chsten Phase e Die Erfassung
335. tel 4 bei denen die explizite Trennung von gesch ftlichen und technischen Sichtweisen im Vordergrund steht Choice of information source _ Data preparation _ Exploration and Learning Mining Role Creation Check Approve and Implement Roles User Assignment Adapted from KS 03 Chapter 5 Information 12 State of the Art The Role Mining Process Forschungsgruppe C amp M Stand der Technik 31 In Information 12 ist der gesamte role mining Prozess dargestellt Er ist aufgeteilt in sieben diskrete Prozessschritte die im Folgenden erl utert werden Man erkennt anhand der Abbil dung dass es sich um einen Prozess mit R ckkopplungen handelt wobei in jeder Stufe auf je den der davorliegenden Prozessschritte zur ckgesprungen werden kann Auf die Auswahl einer geeigneten Datenbasis ist bereits eingegangen worden Das Entscheidende hierbei ist den ge samten zur Verf gung stehenden Datenbestand auf einen geeigneten Ausschnitt einzugrenzen um daraus hinreichend geeignete Rollen herauskristallisieren zu k nnen Dies betrifft sowohl die Benutzerauswahl als auch die Attributauswahl f r eine semantisch hinreichende Untermen ge An dieser Stelle sei darauf hingewiesen dass die Datenbasis wenig frequentierten nderun gen unterlegen sein sollte da h ufige nderungen der Datenbasis h ufige Anpassungen des Rollenmodells nach sich ziehen KS 03 Da bei der Datenauswahl inkorrekte Daten erkannt werden ist
336. tem ersetzt werden Das Ende der Implementierungsphase wird durch die Abnahme durch den Kunden signalisiert Anhand des Pflichtenhefts sowie der Leistungsindikatorergebnisse aus dem Testbetrieb wird diese Abnahme durchgef hrt Dieses Vorgehen erm glicht einen sehr sanften Umstieg f r die einzelnen Abteilungen und einen effektiven Umgang mit der neuen Technologie f r das gesam te Unternehmen Speziell der sich schrittweise ausweitende Testbetrieb ist allerdings gerade f r gr ere Einrichtungen ressourcenintensiv Einerseits ist es personal und zeitintensiv aber auch die technischen Ressourcen f r den Parallelbetrieb m ssen zur Verf gung stehen Es ist daher auch m glich das Ausrollen des Rollenmodells nach einem pilotierten Testbetrieb direkt auf das gesamte Unternehmen auszudehnen jedoch leidet darunter m glicherweise die Akzeptanz des Rollenmodells bei den Angestellten Der gesamte Implementierungsprozess ist in Informa tion 49 grafisch dargestellt Gr nde f r R ckkopplungen Wie aus der Abbildung erkennbar ist ist die Implementierungsphase unterteilt in einen Imple mentierungsteil und einen Testbetrieb In der Testbetriebphase zeigt sich wie sorgf ltig in der Rollenentwurfsphase modelliert wurde da durch die Testf lle sowie die anschlie enden Inter views mit den Testkandidaten die Resonanz bei den Angestellten erfasst wird Je konzentrierter die finalen Artefakte in der Entwurfsphase spezifiziert wurden umso geringer ist die
337. teme ber eine hnliche Struktur von Gruppen und Rechten verf gen F r die Menge dieser Systeme wird eine generische Berechtigung definiert und einer Rolle zugewiesen Bei der Zu weisung dieser Rolle an einen Benutzer kann eine Teilmenge angegeben werden was dazu f hrt dass der Benutzer die generische Berechtigung nur auf dieser Teilmenge von Systemen erh lt L4 Jokerberechtigungen dienen dazu um eine Rolleneinteilung in Endsystemen vorzunehmen Der Autor nennt als Beispiel einen Verzeichnisdienst mit mehreren Gruppen deren Namen mit dem Pr fix ACCT beginnen gefolgt von einer vierstelligen Zahl Diese Zahl stellt eine orga nisatorische Einheit dar und existiert somit auch als Benutzerattribut F r dieses Pr fix wird ei ne Jokerberechtigung erstellt und einer Rolle zugewiesen Zum Zeitpunkt der Zuweisung einer Rolle an einen Benutzer greift eine Regel die das Benutzerattribut ausliest es mit der Jokerbe rechtigung konkateniert und den Benutzer somit in die korrekte Gruppe im Zielsystem einf gt L5 Da sich die Kompetenzen zweier Angestellter in der gleichen Gesch ftsrolle nur in Befug nisgrenzen unterscheiden k nnen f hrt der Autor benutzerspezifische Beschr nkungen ein Als Beispiel verwendet er zwei Bankangestellte die ber unterschiedliche Bewilligungsgrenzen f r Kredite verf gen Die Beschr nkungen greifen bei der Zuweisung von Berechtigung an Rolle sowie von Rolle an Benutzer und beziehen sich im Beispiel auf di
338. teme auf die der Zugriff in Form von Rollen gesteuert werden soll Die se Attribute zusammen mit den spezifischen Attributen eines Benutzers wie etwa seine Grup penmitgliedschaften oder systemspezifische Eigenschaften stellen demnach den Datenbestand des role mining dar Das Ergebnis der Anwendung der role mining Algorithmen ist die Spezifikation der eben er w hnten Rollentypen Sie sind folgenderma en charakterisiert Die gesch ftsnahe Rolle be schreibt den Benutzer im Unternehmen Laut KS 03 verf gt ein Benutzer ber genau eine solche Rolle und durch sie erwirbt er die Benutzerkonten und die Zugriffsrechte in den Endsys temen Die Rolle subsumiert s mtliche globale und systemspezifische Informationen ber die ein Benutzer verf gen muss wenn er in der Rolle t tig wird Sie ist verkn pft mit denjenigen Komponenten in den Endsystemen die dort zur Autorisierung eingesetzt werden Diese k nnen je nach System Benutzergruppen oder auch nur einzelne Benutzerkonten sein Functional roles dagegen verk rpern weder globale noch systemspezifische Attribute sondern stehen f r Funk tionen innerhalb von Gesch ftsprozessen oder der Organisationseinheit in der sie sich befindet wobei auch dieser Rollentyp mit Endsystemen verkn pft sein kann Diese Rollen repr sentieren demnach Funktionen die ber das normale Ma an Zugriffsrechten hinausgehen An dieser Stelle liegt ein grundlegender Unterschied dieser Rollentypen zu den Rollen aus Kapi
339. temen sucht Der Rollenverantwortliche wird von OIM daraufhin ber einen neuen Mi tarbeiter in seiner Abteilung informiert so dass er diesen in eine Gesch ftsrolle einteilen kann Forschungsgruppe C amp M 50 Stand der Technik Im Zuge dieser Einteilung werden vom Omada Identity Manager alle Systemrollen sowie weite re Gesch ftsrollen ermittelt die sie durch die Rollenhierarchie erbt Schlie lich werden diejeni gen Rollen ermittelt die mit der Organisationseinheit verkn pft sind in der der Benutzer einge teilt wurde Der neue Mitarbeiter wird dann durch OIM automatisch in alle diese Rollen eingetragen An dieser Stelle sei erw hnt dass das Prinzip separation of duties hierbei auch be achtet wird Erhielte der Mitarbeiter der durch den Abteilungsleiter einer Organisationseinheit sowie einer Gesch ftsrolle zugeordnet wird mehrere Rollen die sich wechselseitig ausschlie en werden diese Rollen konsequenterweise nicht zugewiesen Da diese Komponente zum Ar beitsbereich compliance module geh rt wird sie im folgenden Kapitel n her beleuchtet Eine Komponente des OIM erm glicht es jedem einzelnen Benutzer selbst ndig nderungen an der Rolleneinteilung zu initiieren was im Wirkbetrieb sehr viel Zeit spart Dies betrifft die dauer hafte nderung aktuell zugewiesener Rollen sowie eine zeitlich befristete Weitergabe von Rol len an eine andere Person Die Komponente die dabei nderungsw nsche mitverfolgt und an die entsprechen
340. temrollen eine sehr komplexe Aufgabe im bottom up Vorgehen dar Im Vorgehensmodell wur de daher die Notwendigkeit nach Algorithmen zur Unterst tzung bei dieser Aufgabe zum Aus druck gebracht Von einer derartigen Unterst tzung profitieren somit insbesondere die Analyse und Entwurfsphase des Vorgehensmodells Der Omada Identity Manager bietet zum aktuellen Zeitpunkt keine Komponente f r das role engineering an Der Sun Role Manager hingegen ver f gt f r den Bereich role engineering ber Algorithmen zur Entwicklung von Rollen Diese Al gorithmen werden in SRM insbesondere f r Rollen mit technischen Details angewandt was als Systemrolle aufgefasst werden kann Das Vorgehensmodell weist eine Phase mit R ckkopplung auf sich selbst auf wodurch ein zir kul rer Porzess modelliert werden soll Durch diese Phase kommen administrative Aufgaben eines Rollenmodells im Wirkbetrieb zum Ausdruck Durch die explizite Modellierung des Rol lenbetriebs wird nunmehr beachtet dass Rollen im Wirkbetrieb laufend nderungen unterlie gen mit denen in angemessener Weise umgegangen werden muss Ein Rollenmanagement werkzeug sollte daher administrative Aufgaben unterst tzen die im Wirkbetrieb entstehen Hierbei bieten beide Werkzeuge in gleicher Weise Prozesse an obwohl automatische Arbeitsab l ufe in OIM genauer spezifiziert werden k nnen Im Rahmen dieser Fallstudie bietet aber kei nes der Werkzeuge einen wesentlichen Vorteil Zusammengefasst liegen dr
341. ter Vorgehensmodelle f r die rollenbasierte Autorisierung in heterogenen Systemlandschaften Wirtschaftsinformatik 49 2007 Inhalte Was sind die zentralen Inhalte die in der Arbeit behandelt werden I1 Ziel der Autoren ist es Vorgehensmodelle zur Integration der Autorisierung in heterogenen Systemlandschaften sowohl in der Forschung als auch in der Praxis darzustellen I2 Dabei werden zun chst Grundlagen zur Autorisierung erl utert und anschlie end der ak tuelle Stand der Integration in der Forschung aufgezeigt Die Situation in der Praxis wird durch Fallstudien aus Gro unternehmen belegt 13 Die Betrachtung dieser beider Bereiche f hrt zu einer Weiterentwicklung eines Vorge hensmodells f r die Definition und die Implementierung von system bergreifenden Rollen Defizite Welche Defizite bestehender Arbeiten und L sungen werden als Motivation der eigenen L sun gen genannt D1 Aktuelle Forschungsbeitr ge verf gen ber ausf hrliche theoretische Modelle wie Objekt und Metamodelle F r eine umfassende und verbesserte Methode zur Integration der Autorisie rung muss auf Erkenntnisse aus der Theorie in Kombination mit Erkenntnissen aus der Praxis eingegangen werden Pr missen Welche Einschr nkungen und Vorgaben werden hinsichtlich der eigenen L sungen gemacht Pl Der ERBAC Standard bildet die Basis des zu entwickelnden Vorgehensmodells P2 Im Mittelpunkt dieser Vorgehensweise steht die Implementierung syst
342. ternehmen zusammen mit einer Pilotphase f r ausgew hlte Benutzer ei nerseits und dem Testbetrieb im Unternehmen und der R ckf hrung der daraus gewonnenen Ergebnisse ins Rollenmodell andererseits Am Ende dieser Phase wird der Testbetrieb auf das gesamte Unternehmen ausgeweitet und abschlie end durch den Kunden abgenommen was an hand der Leistungsindikatoren und dem Pflichtenheft geschieht Die vierte Phase des Rollenbetriebs ist in das Vorgehen explizit eingeflossen um zu signalisie ren dass es sich bei der Implementierung eines Rollenmodells um einen Lebenszyklus handelt BRBAC muss fortw hrend gewartet werden um das Unternehmen als Ganzes stets in konsis tenter Weise zu repr sentieren Diese Phase ist daher eher als zyklisch denn als iterativ zu be zeichnen und endet erst mit der Deprovisionierung der rollenbasierten Zugriffskontrolle oder einer geplanten nderung was eine R ckkopplung in eine der davor liegenden Phasen nach sich zieht Dies beschlie t die Entwicklung eines Vorgehensmodells zur berf hrung von BRBAC in den Wirkbetrieb Nachdem in den Kapiteln 3 2 und 3 3 aktuelle Rollenmanagementwerkzeuge be reits detailliert eingef hrt wurden folgt im n chsten Kapitel eine Bewertung dieser beiden Werkzeuge Dazu wird zun chst ein Kriterienkatalog entwickelt an dem die Werkzeuge bewer ten werden Diese T tigkeit steht somit in Bezug zur Entwurfsphase in der die Auswahl eines geeigneten Werkzeugs vorgenommen wird Im weit
343. terpretiert eine Rolle als system bergreifende Einheit zur Kapselung von Berechtigungen Auch hier findet sich keine explizite Unterscheidung des Rollenbegriffs vor Die bisherigen Rollenmodelle befassen sich lediglich mit der reinen Kon zeption und funktionalen Spezifikation nicht jedoch mit der Entwicklung eines f r dieses Mo dell angemessene Vorgehensmodell zur Instanziierung und berf hrung in den Wirkbetrieb Die Aktualit t dieses Themas die breite Akzeptanz von RBAC innerhalb von Forschung und Industrie sowie der bisher sehr wenig beachtete Zusammenhang von Rollen und Vorgehens modellen stellen die Motivation f r diese Forschungsarbeit dar Forschungsgruppe C amp M Einleitung 3 1 2 In der Arbeit behandelte Fragestellungen In den letzten Jahren ist ein deutlicher Zuwachs an rollenbasierten Zugriffskontrollarchitekturen zu beobachten welche ein Architekturprinzip verk rpern das sich der wachsenden Heterogeni t t in IT Landschaften stellt und L sungswege f r die damit einhergehende Komplexit t anbie tet Ka07a Aus diesem Grund sind rollenbasierte Zugriffskontrollarchitekturen sehr attraktiv f r gro e Einrichtungen wie beispielsweise Unternehmen geworden Obwohl RBAC ein viel versprechender Ansatz f r Unternehmen darstellt ist die technische Realisierung von RBAC im Unternehmenskontext allerdings nicht trivial Dies wird klar wenn man sich verdeutlicht dass es heutzutage mehrere unterschiedliche Auffassungen des Rol
344. timmten technischen Endsystemen kommunizieren k nnen Die Auswahl des Produktes kann an dieser Stelle dadurch eingeschr nkt werden ob die Folgenden Schritte bereits durch das Werkzeug unterst tzt werden Insbesondere die Herausarbeitung von techni schen Zugriffsberechtigungen kann davon profitieren Role mining vgl Kap 3 1 1 stellt einen praktikablen Ansatz dar um erste Rollenh lsen aus der bestehenden Struktur herauszukristalli sieren Zu diesem Zeitpunkt steht allerdings nicht das Entwerfen von Rollen im Vordergrund sondern die Erfassung des Ist Zustands bei vorhandenen Berechtigungen Dies kann die Erfas sung des Ist Zustands sowohl auf gesch ftlicher als insbesondere auch auf technischer Ebene unterst tzen Jedes Rollenmanagementwerkzeug verf gt ber ein eigenes Rollenmodell das meist auf NIST RBAC basiert Da dieses Modell nicht zwischen Gesch fts und Systemrollen unterscheidet muss die hier eingef hrte explizite Unterscheidung von Gesch fts und System rollen in Form einer Abbildung formalisiert werden Die explizite Anwendung von role mining Algorithmen zum Entwurf von Rollen kommt jedoch erst in der n chsten Phase zum Tragen weil den role mining Algorithmen ein gefilterter Ausschnitt des Gesamtsystems zugef hrt wer den muss auf welchem sie ausgef hrt werden Das Erfassen des Ist Zustands stellt das Ziel die ses Teils der Analysephase dar und kann in der darauf folgenden Entwurfsphase unmittelbar zur Definition eines gee
345. tit tsabgleich engl identity reconciliation wird OIM dar ber informiert wenn sich ein zelne Daten oder Attribute in den zugrundeliegenden Unternehmenssystemen ndern und kann somit in geeigneter Weise darauf reagieren Die n chste Komponente zeigt einen deutlichen Vorteil einer rollenbasierten Zugriffskontrolle auf Die einfache Spezifikation von wechselseiti gem Ausschluss Ein wesentlicher Vorteil einer rollenbasierten Zugriffskontrollarchitektur ist wechselseitigen Ausschluss von Rechten in konsistenter Form realisieren zu k nnen Dies wird in OIM in der Komponente separation of duties dadurch erm glicht dass sich Rollen definieren lassen die sich gegenseitig ausschlie en Zur berwachung ob Policy Vorgaben eingehalten werden bietet der Omada Identity Manager durch die Komponenten audit trail und audit report die M glichkeit den aktuellen Bearbeitungsstand der verschiedenen Prozesse im Lebenszyklus der Rollen einsehen zu k nnen Dies schlie t eine Betrachtung fr herer Rollenzuweisungen auf feingranularer Ebene ebenso mit ein wie eine Analyse wie sich zuk nftige nderungen an der Rollen und Rechtestruktur auf das bestehende Rollenmodell auswirken w rden Die Kompo nente security administration console repr sentiert die grafische Bedienoberfl che f r alle Komponenten dieses Arbeitsbereichs Sie ist individuell an die Anforderungen der OIM Benutzer anpassbar Dazu f hrt OIM Ansichten engl views ein f r die definiert werd
346. ts bestehenden Rolle oder global auszuw hlen In der n chsten Aktion lassen sich die Parameter des Algorithmus spezifizieren um das Ergebnis des Suchlaufs zu steuern Zu diesem Zeitpunkt verf gt SRM ber alle Daten die zur Berechnung n tig sind Nach Beendigung der Berechnung werden die Ergebnisse ausgegeben die anschlie Bend noch verfeinert werden k nnen Der gesamte Prozess ist iterativ und kann somit schritt weise an die gew nschte Granularit t angepasst und individuell optimiert werden Das Ergebnis kann dann in einem abschlie enden Schritt als Rolle die ihrerseits ber Policys verf gt im identity warehouse des SRM abgelegt werden Forschungsgruppe C amp M Stand der Technik 61 55 SRM Role Entitlement Discovery Set Attribute Type Strategy Set Users Validate Entitlement Result Information 33 State of the Art Sun Role Manager Role Entitlement Discovery Nachdem im ersten Teilprozess neue Rollen und Policys definiert wurden besch ftigt sich role entitlement discovery mit der berarbeitung bereits definierter Rollen zu einem sp teren Zeit punkt im Lebenszyklus wobei auch hier role mining Algorithmen zum Einsatz kommen In formation 33 stellt diesen Prozess als Aktivit tsdiagramm dar Im Gegensatz zu role discovery sind hier Rollen bereits definiert so dass die Berechnung hier nicht mehr auf der Basis von Be nutzern sondern bereits auf der Basis von Rollen stattfindet Zun chst beginnt man allerdin
347. tsprechen somit der in dieser Arbeit verwendeten Gesch ftsebene wohingegen people and resources und processes and information eher technische Spezifika betrachten und somit der technischen Ebe ne anzugliedern sind Ka07b Die Kategorie reward steht in keinem konkreten Zusammenhang zum Rollenmanagement und wird deshalb im Folgenden nicht weiter betrachtet Ka07b page 20 Information 11 Basics Role Management Capabilities In Information 11 werden die Aufgaben von Rollenmanagementwerkzeugen grafisch darges tellt Dabei sind die Aufgaben die eher im Bereich der Gesch ftsebene angesiedelt sind in der oberen H lfte und die Aufgaben der technischen Eben in der unteren H lfte angeordnet Zus tz lich teilt die vertikale Hilfslinie diese Aufgaben in die vier angesprochenen Kategorien Die elf verschiedenen Aufgaben des Rollenmanagements stammen aus Ka07b und werden hier von der Gesch ftsebene aus nach unten erkl rt e Um die Funktionen eines einzelnen Angestellten korrekt zu erfassen ist es n tig ihn im Zusammenhang zur gesamten Unternehmensstruktur und dem Gesch ftsziel des Unter nehmens zu betrachten Auch die Abgrenzungen an den Schnittstellen zu anderen Ver antwortlichkeiten sind hierf r wichtig Eine Gesch ftsrolle stellt eine Repr sentation dieser angesprochenen Funktionen dar und so m ssen sich in ihr die Charakteristika des Unternehmens widerspiegeln Insbesondere ist es wichtig die Beziehungen dieser Ge sch
348. tung es synchronisiert werden soll Das Ergebnis dieses Ansatzes ist dass die Datenobjekte mit einer Teilmenge ihrer Attribute komplett im Metaverzeichnis des ILM ab gelegt werden Fiir jedes zu synchronisierende Datenobjekt samt der soeben spezifizierten At tribute liefert OIM daraufhin einen eigenen Managementagenten zur ck der in den ILM impor tiert werden muss damit die Synchronisation in beide Richtungen gew hrleistet ist Die Konsequenz dieses Ansatzes ist dass beim Import des Agenten im Identity Lifecycle Manager ein Konfigurationsaufwand entsteht da f r jedes der Datenobjekte und dessen Attribute eine ei gene Relation zu den Attributen der unterschiedlichen Unternehmenssysteme hergestellt werden muss 3 2 3 Der Arbeitsbereich role management Nachdem die Kommunikationsbeziehungen zwischen OIM und den Endsystemen beschrieben wurde werden in diesem Teilkapitel die Komponenten des Arbeitsbereichs role management genau betrachtet Um dies zu veranschaulichen werden sie in einem Prozess dargestellt Dazu wird zun chst die Relation zwischen Gesch fts und Systemrollen im Omada Identity Manager betrachtet und anschlie end ein Arbeitsablauf engl workflow aufgezeigt In diesem workflow wird initial eine Gesch ftsrolle und eine Systemrolle definiert Anschlie end werden diese bei den Rollen in Relation zueinander gesetzt und ein Benutzer in die Rollenstruktur eingepflegt Anhand dieses Benutzers werden die Verwaltungsaufgaben die OIM
349. ty Manage cee ceeeeeeeeeeeeereeereeeeeenees 139 Appendix Installation Process of Omada Identity Manager 140 Appendix Configuration Process of Omada Identity Manager 142 Appendix Tiers in Sun Role Manager eceecesceseceseceseeeeeeeeseeeeeeseeenaes 143 Appendix Installation Process of Sun Role Manager uenene 144 Appendix Configuration Process of Sun Role Manager nene 146 Appendix Role Mapping with Simple System Roles ene 147 Appendix Role Mapping with Complex System Roles e 148 Forschungsgruppe C amp M Anhang 153 F Literaturanalysen F 1 Advanced Features for Enterprise Wide RBAC Ke02 Axel Kern Advanced Features for Enterprise Wide Role Based Access Con trol ACSAC 2002 Inhalte Was sind die zentralen Inhalte die in der Arbeit behandelt werden I1 Der Autor beschreibt das Konzept der enterprise roles welches Rollen verk rpert die sich ber mehrere IT Systeme erstrecken k nnen Dazu wird das ERBAC Modell eingef hrt I2 Ferner wird beschrieben wie sich das ERBAC Modell auf das RBAC Modell aus FS 01 st tzt und welche Komponenten es erweitert wird Defizite Welche Defizite bestehender Arbeiten und L sungen werden als Motivation der eigenen L sun gen genannt D1 Unternehmen verlangen aufgrund wirtschaftlicher und technologischer Ver nderungen nach immer mehr
350. tz wird der Graph nicht explizit definiert sondern durch die An wendung von Algorithmen aus der Graphentheorie dynamisch zur Laufzeit erzeugt Hierbei werden unterschiedliche Hierarchien durch die Analyse zusammengefasst Wie KK 02 aufzeigt hat es sich in der Praxis bew hrt nur einen Graphen zu verwenden und die logisch unabh ngigen Hierarchien in Form von Attributen implizit darzustellen und mit dem Graph in berdeckung zu bringen Dies geschieht durch Parametrisierung von Relationen wie etwa der Benutzer Rolle Relation Dadurch legt man sich auf eine Hierarchie fest und lagert die anderen Hierarchien in die Attribute der im Graphen enthaltenen Knotenobjekte aus Der Vorteil dieses Ansatzes ist dass dadurch die struk turelle Komplexit t verringert wird allerdings existieren hierbei auch Nachteile Durch die implizite Formulierung von Hierarchien in Form von Attributen ist es nicht mehr m glich Zugriffsrechte auf diejenigen Elemente zu vergeben die zu Attributen gewor denen sind Auch gehen durch die Attributierung die Relationen bzw Hierarchien f r diese Elemente verloren Forschungsgruppe C amp M 40 Stand der Technik Rollenverwaltung Am Ende dieser Phase wurde ein Rollenmodell entworfen welches ber Rollen und Hierarchien verf gt die der jeweiligen Situation angepasst ist so dass man sich nun mit der Pflege des Mo dells befassen kann Die n chste Phase role management befasst sich laut KK 02 mit admi nistrativen A
351. tzer ausdr ckt Wie FS 01 definiert unterscheidet man dynamische und statische Aspekte bei SoD Stati sches SoD beschreibt hierbei die Einschr nkung dass gewisse Rollen zur gleichen Zeit nicht an denselben Benutzer vergeben werden k nnen wohingegen dynamisches SoD zus tzlich dazu den Kontext des Zugriffs betrachtet und der gegenseitige Ausschluss nicht allgemein sondern nur f r bestimmte Kontexte g ltig ist In den g ngigen Modellen sind diese beiden Prinzipien bereits formuliert vgl hierzu Kapitel 2 2 in den technischen Umsetzungen hingegen fehlt dy namisches SoD bislang g nzlich Dies liegt daran dass gerade bei system bergreifenden Rol len wie man sie in heterogenen Umgebungen vorfindet der Kontext verloren geht Anders als die bisherigen Rollenmodelle f r unternehmensweite Zugriffskontrolle erm glicht BRBAC ne ben statischen SoD Aspekten auch dynamisches SoD F r dynamisches SoD muss der Kontext somit zentral erfasst werden k nnen Dazu wird dieser im Benutzerobjekt selbst verankert weil gerade das Benutzerobjekt einen eindeutigen Identifikator eines Benutzers darstellt F r die Modellierung definiert BRBAC einen Kontext C und zwei Relationen f r SoD e Kontext C e U ieN e Statisches SoD Relation O sop GC RXR e Dynamisches SoD Relation O asp GC RXRXC Wie bereits verbal ausgedr ckt wurde stellt statisches SoD einen constraint zwischen zwei Rol len dar und dynamisches SoD zwischen zwei Rollen die nur in ein
352. u erhalb des betrachteten IST Szenarios liegt werden diese Rechte nicht explizit aufgef hrt Die Gesch ftsrolle Accounting Assistent c amp m verwendet den Dateiserver zur Ablage von buchhalterischen Dokumenten wie etwa Vertr ge mit den Kunden oder Rechnungen von ed serv bzw ed consult Die Marketing Abteilung von c amp m vertreten durch die Gesch ftsrolle Marketing Assistent c amp m befasst sich damit das Schulungsangebot an die Kundenw nsche anzupassen In diesem Sinne ben tigt sie Zugriff auf ed tec und den Dateiserver um die Einteilungen zu Schulungen zu berwachen und das Interesse an zus tzlichen Schulungsmaterialien zu erkennen Die Ge sch ftsrolle Trainer c amp m die Schulungen durchf hrt muss dazu berechtigt sein Inhalte auf ed tec zur Verf gung zu stellen und neue Schulungen einzutragen um Teilnehmer dar ber in Kenntnis zu setzen Aus diesem Grund wird diese Rolle mit der Systemrolle Contributer verkn pft Zur Ablage von erg nzendem Material bereits abgehaltener Schulungen ist es daher n tig schreibend auf den Dateiserver zugreifen zu k nnen Die Gesch ftsrolle IT Admi nistration c amp m verf gt ber den Vollzugriff auf die gesamte technische Infrastruktur von c amp m da sie neben der Administration der Benutzerkonten auch die Administration der Serversysteme verantwortet 7 2 3 Das Rollenmodell BRBAC im Beispielszenario Bei dem hier gew hlten Szenario IST handelt es sich lediglich um einen kleinen un
353. uf Ke02 verwiesen wo hnliche Ver einfachungen eingef hrt und die Tragf higkeit durch Berichte aus praktischen Umsetzungen be legt wurden Forschungsgruppe C amp M Zusammenfassung und Ausblick 133 8 ZUSAMMENFASSUNG UND AUSBLICK 8 1 Ergebnisse dieser Arbeit In diesem Kapitel sollen die zentralen Ergebnisse der vorliegenden Arbeit zusammengefasst und miteinander in Bezug gestellt werden Zun chst wurden in Kapitel 2 die Grundlagen f r eine detaillierte Diskussion von Modellen f r die rollenbasierte Zugriffskontrolle gelegt ausgehend von einer Betrachtung der Sub jekt Objekt Relation die als Basis von Zugriffskontroll Architekturen angesehen werden kann Diese Relation wurde in Bezug gesetzt zum Paradigma der rollenbasierten Zugriffskontrolle die das Konzept Rolle als Indirektionsstufe zwischen dem zugreifendem Subjekt und Objekt als Ziel des Zugriffs einf hrt In der Folge wurden die vier Modelle des NIST RBAC Standardrahmenwerks vorgestellt und jeweils die Modellspezifikation sowie die funktionale Spezifikation erl utert Ein wichtiges Merkmal von Zugriffskontrollarchitekturen ist die M g lichkeit wechselseitigen Ausschluss von Rechten spezifizieren zu k nnen Dieses als separati on of duty bekannte Prinzip wird in der rollenbasierten Zugriffskontrolle durch Rollen realisiert die sich wechselseitig ausschlie en Hierbei wird zwischen statischem und dynamischem Aus schluss unterschieden wobei durch den statische
354. ufgaben im Wirkbetrieb Dies sind Routinearbeiten innerhalb des Unternehmens Die Voraussetzung ist ein robustes Rollenmodell und setzt somit die Analyse und Entwurfs phase voraus Die Aufgaben des role management umfassen folgende Schritte e Die Durchf hrung von nderungen am Rollenmodell was sich mithilfe der bereits de finierten Algorithmen in nderungen der organisatorischen Strukturen auswirkt e Das Erzeugen oder L schen eines Benutzers oder einer Berechtigung e Das Zuteilen oder Entziehen von Rollen f r Benutzer entsprechend der Benutzer Rolle Relation e Das Zuteilen oder Entziehen von Berechtigungen f r Rollen entsprechend der Rol le Berechtigung Relation e Das Auftrennen oder Zusammenf hren von Rollen selbst was von besonderer Bedeu tung ist Dies kann entweder dann vonn ten sein wenn eine komplexe Aufgabe auf un terschiedliche Rollen aufgeteilt werden soll oder wenn Aufgaben aus mehreren Rollen in einer Rolle zusammengef hrt werden sollen Rollenwartung Neben den nderungen von Rollen und deren Umfang ergeben sich im Laufe der Zeit aber auch nderungen an den organisatorischen Strukturen selbst die in der Analyse und Entwurfsphase ja gerade die Grundlage des zu entwickelnden Rollenmodells bildeten Auch hier ist der starke Bezug zum klassischen Software Entwicklungszyklus erkennbar Die Rollenwartung engl role maintenance besch ftigt sich nun mit strukturellen nderungen wie sie sich etwa beim Zu sammenl
355. ult Discussion Test Results lt lt yes gt gt Product Deployment Verification Information 49 Procedure Model Development Role Implementation Zustandigkeiten Die Implementierungsphase ist stark getrieben durch die Consultants die zun chst daf r ver antwortlich sind das Rollenmanagementwerkzeug im Unternehmen einzusetzen und im An schluss daran die Verbindung zum Unternehmensdatenbestand herzustellen Die berf hrung des Rollenmodells in den Wirkbetrieb ist ebenfalls Aufgabe der Consultants Es kann durchaus Sinn machen die technische Kompetenz im Unternehmen vertreten durch die Fachabteilun gen an diesem Prozess aktiv zu beteiligen da so der Wissenstransfer unterst tzt wird was in der Folge zu einer guten Verwaltung des Rollenmodells durch die Fachabteilungen f hrt und somit der n chsten Phase zugute kommt Nachdem sich das Rollenmodell im Testbetrieb befin det beginnt ein Teilprozess an dem wiederum die Consultants zusammen mit der technischen Kompetenz beteiligt sind und Testf lle auf der Basis des Pflichtenhefts definieren Zus tzlich dazu werden die Testf lle mit Leistungsindikatoren versehen die w hrend des Testbetriebs berwacht werden k nnen Die berwachung selbst kann dann bereits ohne explizite Einbezie hung der Consultants vom Kunden selbst durchgef hrt werden Am Ende der Testphase werden wie bereits angesprochen wurde Interviews mit den Testbenutzern durchgef hrt die von den Consul
356. ung eines Rollenmodells zur Abbildung von Gesch fts und Systemrollen 73 dells eine Vielzahl von Rollen was unter anderem daran liegt dass Rollen immer eine Zusammenfassung von identischen Rechten darstellen und sich in der Praxis aber die Zugriffsrechte der Benutzer unterscheiden Diese Hypothese stellt die Verringerung von Komplexit t was eines der der Ziele von RBAC ist als ein Prinzip heraus das in der praktischen Umsetzung zu mehr Komplexit t f hrt Dies wirft die Frage auf ob es M glichkeiten gibt dem RBAC Paradigma treu zu bleiben und dieses Dilemma den noch zu l sen BRBAC unterst tzt die Verwendung von Platzhaltern f r Attributwerte wie sich auch in den Erweiterungen zum ERBAC Modell in Form der benutzerspezifi schen Berechtigungen erw hnt werden Die Schwachstelle bei dem dort verfolgten Ansatz ist dass sich die Werte als constraint auf der Relation Benutzer Rolle ausdr cken Eine nderung der benutzerspezifischen Berechtigungen zieht somit eine nde rung der Rollenmitgliedschaften nach sich Im BRBAC Modell wird diese Schwach stelle umgangen Nachdem die Anforderung nun spezifiziert und zu anderen Modellen in Bezug gesetzt wurde wird sie im Folgenden nun genauer betrachtet Zun chst wird die Hypothese etwas genauer beleuchtet Wenn sich die Rechte in einer Rolle lediglich in Nuancen unterscheiden f hrt dies im Entwurf zu einer zus tzlichen Rolle was daran liegt dass die Zugriffsrechte einer Rolle allgemei
357. ungsrahmen un terschiedlich hoch Im ERBAC Modell aus Ke02 w rde das zu einer Rolle pro Attribut Wert Paar f hren Dies kann nun durch benutzerspezifische Beschr nkungen parametrisiert werden Dazu verf gt jeder Benutzer ber ein Attribut welches seine individuelle Grenze festlegt wie in der folgenden Abbildung verdeutlicht wird Forschungsgruppe C amp M Stand der Technik 37 Static Separation of Duty j Permission Constraint Organizational Layer Role Hierarchy User Assignment Business Role Role Mapping system Role _ User Ggattribute 1 1 i 1 Assignment Constr aint Technical Layer Account in TS Permission in TS attribute Adapted from Ke02 Figure 8 Information 16 State of the Art Enterprise RBAC Model User specific Constraints 3 1 4 Modell fur den Lebenszyklus von Rollen In Anlehnung an den klassischen Entwicklungszyklus von Software wie er ist Ba96 Abbil dung 15 beschrieben ist fiihrt KK 02 einen Entwicklungszyklus von Rollen ein Das Beson dere an diesem Ansatz ist dass ein Rollenmodell nicht mit der technischen Realisierung beendet ist sondern fiir dessen Verwaltung und Anderungen die sich aus dessen produktivem Einsatz ergeben explizite Phasen modelliert Es ist in diesem Zusammenhang auch vom Lebenszyk lus von Rollen die Rede Es stellt sich nun die Frage wie relevant die Betrachtung eines Le benszyklus beim Einsatz von Rollen ist Dabei ve
358. ungswerte die aus diesen T tigkeiten entstehen k nnten auch dazu f hren diese in Form von Erweiterungen in das BRBAC Modell zur ckflie en zu lassen Das Vorgehensmodell unterst tzt den Entwurf der beiden Rollentypen aus BRBAC durch den hybriden Vorgehensansatz Es stellt sich an dieser Stelle die Frage ob dieser Ansatz im indust riellen Einsatz als angemessen erachtet werden kann da die Anzahl der Gesch ftsrollen in etwa um zwei Gr enordnungen kleiner ist als die Anzahl an Systemrollen Zwar wird die Entwick lung von Systemrollen durch die Anwendung von role mining Algorithmen unterst tzt was die Entwicklungsdauer tendenziell verringert jedoch bleibt zu untersuchen ob dieser Ansatz auch f r gro e Einrichtungen praktikabel ist Zwar ist dieses Vorgehen intuitiv verst ndlich und er scheint sinnvoll aber Erfahrungswerte aus dem praktischen Einsatz die die Angemessenheit des Vorgehens belegen sind noch zu sammeln In der Implementierungsphase des Vorgehensmodell wird eine schrittweise Implementierung des Rollenmodells im Parallelbetrieb empfohlen um Erfahrungswerte direkt in das Rollenmo dell zur ckf hren zu k nnen Es wurde auch bereits erw hnt dass dieses Vorgehen gerade in gro en Einrichtungen ressourcenintensiv ist sowohl auf personeller als auch auf technischer Ebene Zweifelsohne f hrt dieses Vorgehen zu einem passgenauen Rollenmodell f r ein Unter nehmen jedoch muss etwa durch prototypische Projektumsetzunge
359. ur Unterst tzung der Systeme sind identisch mit den Funktionen aus core RBAC jedoch wirkt sich die Hierarchie auf die Funktionsweise von createSession und addActiveRole aus Durch crea teSession wird die Menge an aktiven Rollen in einem vorgegebenen Kontext be rechnet w hrend durch addActiveRole der Benutzer einer Rolle f r den aktuellen Kontext aktiviert werden Kann Es stellt sich die Frage ob hierdurch nur die explizit an gegebenen Rollen aktiviert werden sollen oder auch diejenigen Rollen die sich aus der Vererbungsbeziehung ergeben Der NIST RBAC Standard sieht hierf r vor dass bei der initialen Bestimmung der f r einen speziellen Kontext g ltigen Rollen durch createSession sowohl die direkten als auch die vererben Rollen aktiviert werden Bei der zus tzlichen Aktivierung weiterer Rollen durch addActiveRole hingegen werden nur die Rollen die der Benutzer selbst ausw hlt beachtet ohne dabei die Ver erbungen mit einzubeziehen Funktionen zur berarbeitung Die berarbeitungsfunktionen aus core RBAC sind auch hier weiterhin g ltig Durch die Definition von Hierarchien enth lt die Menge der Benutzer in einer Rolle nun neben den direkt mit der Rolle verkn pften Benutzern zu s tzlich noch diejenigen Benutzer die durch die Hierarchie vererbt werden Ebenso be steht die Rollenmitgliedschaft im Benutzerobjekt nun nicht mehr nur aus den explizit vergebenen Rollen sondern dar ber hinaus auch aus vererbten Rollen Um dies sicher
360. urde ein Rollenmodell entwickelt das sich durch die explizite Trennung der Rollentypen bislang nicht eindeutig in einem bestehenden Werkzeug abbilden l sst Aus diesem Grund liefert dieses Modell viel Spielraum f r weitere Arbeiten in diesem h chst aktuellen Forschungsgebiet Mit BRBAC wurde ein Rollenmodell entwickelt das explizit zwischen zwei Rollentypen unter scheidet Wie die Werkzeugbewertung aus Kapitel 6 aufgezeigt hat ist diese Unterscheidung Forschungsgruppe C amp M 136 Zusammenfassung und Ausblick zum aktuellen Zeitpunkt lediglich implizit m glich Es d rfte daher h chst interessant sein welche M glichkeiten eine technische Implementierung eines Rollenmanagementwerkzeugs bietet das auf BRBAC basiert Durch das Fehlen einer expliziten Rollentrennung ist es nicht m glich gewesen viele der in BRBAC definierten Mechanismen einer Bewertung zu unterziehen Insbesondere f r die Policy Mechanismen kann erst in einem BRBAC konformen Rollenmanagementwerkzeug das Aus ma der Komplexit tsreduktion gezeigt werden Zwar ist der Vorteil dieser Mechanismen intui tiv verst ndlich aber Untersuchungen stehen bislang noch aus So d rfte insbesondere f r Un ternehmen mit hohen gesetzlichen Bestimmungen interessant sein wie es etwa bei Banken der Fall ist welchen Mehrwert die M glichkeit der Formulierung dynamischer SoD constraints bie tet Des weiteren wurde mit den Platzhalter Attributen ein Prinzip vorgestellt das mit s
361. verwendet werden um die unterschiedlichen Architekturen aufzuzeigen Die behandelten Werkzeuge sind der Role Mana ger der Firma Sun sowie der Identity Manager der Firma Omada Beide entstammen dem Marktsegment der Universalwerkzeuge die sich mit allen Prozessen besch ftigen die im Le benszyklus einer Rolle anfallen Alle L sungen in diesem Marktsegment verbindet dass sie Rollen system bergreifend definieren und verwalten k nnen und auf keinen speziellen Einsatz zweck hin entwickelt wurden Dar ber hinaus k nnen sie Rolleninformationen an Anwendun gen weiterreichen die ihrerseits zwar mit Rollen als Einheit nicht aber mit system bergreifen den Rollen operieren Ka07b Um eine Vergleichbarkeit dieser beider Werkzeuge zu erm glichen stellt diese Arbeit ein Szenario vor und bewertet anhand eines in dieser Arbeit entwickelten Kriterienkatalogs wie gut sie in diesem Szenario das Ausarbeiten anhand des Vorgehensmodells unterst tzen Das dritte Ziel ist demnach eine Untersuchung der ausgew hl ten Werkzeuge bei der initialen Umstellung eines Unternehmens auf eine rollenbasierte Struk tur Es stellt sich die Frage nach der Qualit t der Unterst tzung bei dieser speziellen Aufgabe innerhalb des gesamten Bereichs des Rollenmanagements Zusammengefasst besch ftigt sich diese Arbeit mit folgenden Aspekten e Entwicklung eines Rollemodells f r die rollenbasierte Zugriffskontrolle mit dem Ziel den Unterschied von Gesch fts und Systemrollen
362. von Prozessen zu definieren sowie eine berpr fung des aktuellen Stands von Prozessen die sich gerade in der Ausf hrung befinden Dadurch ist es f r das verantwortliche Personal m glich die Leistungsindikatoren von Prozessen auf feingra nularer Ebene zu berwachen Schwachstellen oder Engp sse zu entdecken und Garantien f r diese Prozesse zu gew hren Im verbleibenden Teilkapitel werden diese Komponenten anhand eines Prozesses erkl rt der sich an den Prozess aus dem letzten Teilkapitel anschlie t und die Komponenten prozessbezogen darstellt Er ist dargestellt in Information 26 55 0IM Compliance Module Define Separation of Duties Constraint Name Requestor cannot also be approver Role combination SRO11_MM_UK_001_01 Purchase Order Request Add SR012_MM_UK_001_01 Purchase Order Approval Rave Show Violation Management and Identity Reconciliation Type Created Identities Roles ADG_MM_DE_001_03_MISC Misc Audit Trails amp Reports 8 7 2008 3 20 13 PM Revoked SYSTEM KMOOI SR008_MM_UK_001_02 SAPOO1 8 7 2008 3 19 09 PM Revoked KUPODOOAS KMOO1 SRO04_MM_UK_O01_02 SAPOD1 8 7 2008 3 14 09 PM Revoked KUPOO0045 KMOO1 SROO8_MM_UK_O01_01 SAPOO1 8 7 2008 3 14 17 PM Assigned KUP000045 KMO01 ADG _MM_UK_001_02_ WINDOWSO004 Attestation SLA Name Avg Time Best Time Worst Time X Extend validity period 4 00 01 38 00 00 10 00 05 46 amp Validity period of Identity has expired 4 00 01 26 00 00 09 00
363. was speziell in der n chste Phase role management die Arbeit erleichtert Forschungsgruppe C amp M Stand der Technik 39 o Definition einer Rolle Berechtigung Relation die in analoger Weise zur Benut zer Rolle Relation eine Zuweisung von technischen Berechtigungen aufgrund vordefinierter Benutzerattribute vornimmt und die Verwaltung der Rollen engl role management vereinfacht o Definition eines Algorithmus mit dessen Hilfe nderungen an organisatori schen Strukturen auf das Rollenmodell bertragen werden wobei die bisherigen Zuweisungen engl mappings invariant bleiben m ssen um die Konsistenz weiterhin zu gew hrleisten Dieser Schritt ist insbesondere f r die Administra tion der Rollenstruktur im Wirkbetrieb von Nutzen Im Allgemeinen existieren mehrere voneinander unabh ngige organisatorische Strukturen in denen sich nderungen in unterschiedlicher Weise auf das Rollenmodell auswirken Der Grad an Automatismus und somit der Nutzen des RBAC Modells h ngt stark davon ab f r wie viele organisatorische Strukturen Algorithmen gefunden wer den k nnen die die nderungen auf das Modell bertragen Kann f r eine spe zielle nderung kein Algorithmus implementiert werden kann dieser Bereich auch nicht automatisiert werden e Entwurf des Rollenmodells Im Hinblick auf die sp tere Administration k nnen beim Entwurf von Rollen Entwurfsmuster unterschieden werden die hier vorgestellt werden F r eine eingehende Unter
364. weitere Forschungsarbeiten nennt In Kapitel 5 folgt die Entwicklung des Vorgehensmodells f r BRBAC Auch hier werden in analoger Weise zu Kapitel 4 zun chst die Ziele und Anforderungen festgelegt die dann im Folgenden in den ein zelnen Phasen umgesetzt werden Auf die in den Phasen zu erledigenden Arbeiten wird ebenso eingegangen wie die erzeugten Artefakte jeder Phase um die Grenze zwischen den Phasen klar zu definieren Abschlie end wird ein Res mee gegeben welches die zentralen Punkte des Vor gehensmodells zusammenfasst Kapitel 6 befasst sich mit der Bewertung von Werkzeugen aus dem Rollenmanagement Diese wurden im ersten Teil der Arbeit bereits wertungsfrei vorgestellt und sollen an dieser Stelle bewertet werden Dazu wird zun chst ein Kriterienkatalog definiert und die Auswahl der einzelnen Kriterien begr ndet Diese stehen unter Anderem in unmittelba rem Zusammenhang zu den beiden in den vorangegangenen Kapiteln entwickelten Modellen Im letzten Teil wird zun chst die Tragf higkeit der Modelle im IST Szenario belegt und an schlie end die gesamte Arbeit zusammengefasst Zur Demonstration der Tragf higkeit wird das Szenario in Kapitel 7 zun chst detailliert vorgestellt und eine Auswahl des Rollenmanagement werkzeugs getroffen Anschlie end wird die Modellinstanziierung von BRBAC gem dem entwickelten Vorgehen illustriert und die Trennung der Rollen genauer beleuchtet sowie zum Abschluss die Betriebsphase Auch f r dieses Kapite
365. wortlichen delegiert Dies erh ht die Benutzerfreundlichkeit und somit potentiell die Akzeptanz des Werkzeugs im Wirk betrieb Zus tzlich dazu erh ht sich durch die dezentrale Administration die Effizienz im Unter nehmen weil nderungen nicht mehr nur davon abh ngig sind wann sie von der technischen Administration initiiert und bearbeitet werden sondern davon wann diese bereits initiierte n derungsw nsche evaluiert OIM bietet auch eine Integration seiner grafischen Benutzeroberfl che in das Intranet Portal Office SharePoint Server MOSS der Firma Microsoft an indem die Komponenten des OIM als Web Module engl web part Mic08 angeboten werden Ein letz ter Aspekt zur Bedienbarkeit ist der Aspekt der Sprachanpassung OIM ist ein multi language Werkzeug das in mehreren Sprachen betrieben werden kann Dies unterst tzt in vielen F llen den intuitiven Umgang f r Benutzer An dieser Stelle soll lediglich eine Grobeinsch tzung der Benutzerfreundlichkeit gegeben werden da f r eine intensiven Bewertung dedizierte Studien anzustellen sind Insgesamt betrachtet wird die Benutzerfreundlichkeit von OIM durch die workflows die anpassbaren Ansichten sowie die dezentrale Administration als gut bewertet Kommunikation zu den Endsystemen OIM basiert auf dem Provisionierungswerkzeug ILM welches nderungen in die Endsysteme zur ckf hrt und au erhalb von OIM gemachte Anderungen r ckg ngig macht und gegebenen Forschungsgruppe C am
366. y certification und das berwachen der Zuweisungen engl identity audit Der Role Manager verf gt ber einen Mechanismus der dem identity warehouse regel m ig Daten aus den angeschlossenen Endsystemen zuf hrt Die Daten k nnen dabei sowohl technische Informationen wie etwa Zugriffsrechte Gruppenmitgliedschaften oder hnliches enthalten als auch Gesch ftsinformationen wie etwa eine Gesch ftsstruktur oder Gesch ftshie rarchien Dadurch dass die zu importierenden Daten selbst ndig spezifiziert und einzelne Attri bute und Eigenschaften selektieren werden k nnen dient das identity warehouse als Metaver zeichnis f r die Komponenten des SRM Es stellt den zentralen Konsolidierungspunkt der Unternehmensdaten dar die f r RBAC relevant sind Ka07b Sun08a Forschungsgruppe C amp M Stand der Technik 55 PEPA p Z Provisioning Systems Organizational Layer Technical Layer Employee Contractor Info 1 Platforms Databases Applications use use specification Sun Role Manager subsystem Identity Warehouse subsystem subsystem subsystem subsystem Role Engineering Role Management Identity Certification Identity Audit Hybrid Approach Role Certifications Role and Exception SoD Analysis Certification fa Role Discovery Role Role Approvals Data Cleanup Preventative Controls Mining Entitlement Discovery Temporary Roles Comp
367. ysiert wer den Als Artefakte dieser Phase entstehen somit Attributmengen die organisatorische und funk tionale Aufgaben repr sentieren sowie davon unabh ngige Eingabeparameter f r die Algorith men selbst Nachdem diese Phase abgeschlossen ist und durch schrittweises Verfeinern ein geeigneter Datenstamm f r die Rollenbildung definiert wurde erfolgt die eigentliche Anwen dung der Algorithmen Auch in der Phase der Rollenerzeugung engl role creation kann das Ergebnis durch Verfeinern der Parameter schrittweise verbessert werden Aus den verfeinerten Daten werden dann organisatorische und funktionale Rollen erzeugt sowie deren Verbindungen zu den Endsystemen Basierend auf den Attributwerten sowie den erzeugten Attributclustern werden die globalen bzw systemspezifischen Attribute erzeugt die ihrerseits dann zu Attribu ten von organisatorischen Rollen werden Nach dieser Entwurfsphase werden die Ergebnisse abschlie end evaluiert Das entstandene Rollenger st wird auf Plausibilit t und Korrektheit berpr ft und im Anschluss daran implementiert engl check approve and implement resulting roles Die Implementierung bezeichnet hierbei den Prozess zum Abbilden der Rollen in eine lauff hige Version Nach Beendigung der Implementierung des Rollenmodells ist der letzte Schritt in diesem Prozess das Zuweisen von Benutzern zu diesen Rollen engl user assign ment was laut KS 03 manuell erledigt werden muss Abschlie end sollen Erfahrungswer
368. ysteme wird ebenfalls von ed serv bernommen Der Schu lungsanbieter c amp m besitzt den Kunden intelligent internet solutions i2s dessen Mitarbeiter entweder ber die Arbeitspl tze bei c amp m oder ber das Internet per Fernzugriff an Schulungen teilnehmen k nnen Die Firma ed consult education consulting tritt in diesem Szenario als IT Beratungsfirma auf und integriert die Software Komponenten der Firma ed soft education software in die bestehende Infrastruktur von c amp m Das in diesem Szenario verwendete Schu lungsportal von c amp m wird als ed tec education technology bezeichnet Diese Partner sowie de ren Gesch ftsrollen stehen demnach f r die Gesch ftsebene die in Information 1 dargestellt wurde und verf gen ber unterschiedliche Systemrollen auf technischer Ebene Forschungsgruppe C amp M Einleitung 7 Technical Layer Server side c amp m Infrastructure Administrator Domain User E List Folder Content E Contributer E Reader Domain Administrator Enterprise Administrator write Access Read Access component component Course Management Server Network Drive l J Access Control Table Elldentity Store E Access Control List Information 3 Introduction System Model in the IST Scenario Information 3 verdeutlicht die technische Ebene aus Information 1 und zeigt das Gesamtbild der c amp m Serverinfrastruktur Dargestellt sind die Systeme die von ed serv verwaltet werden Die
369. zeug Rollen in differenzierter Form anbietet Es sollte insbesondere zwischen gesch ftsprozessnahen Gesch ftsrollen und endsys temnahen Systemrollen unterscheiden k nnen Das zweite Kriterium setzt sich mit der M g Forschungsgruppe C amp M 110 Analyse aktueller Rollenmanagementwerkzeuge lichkeit auseinander Hierarchien aufzubauen Hierarchien sollten unterstiitzt werden weil da durch die Unternehmensstrukturen in angemessener Weise abgebildet und Berechtigungen strukturiert werden K nnen Durch die M glichkeit der Vererbung kann so innerhalb von Ge sch ftshierarchien die Anzahl der Rollen auf einem berschaubaren Niveau gehalten werden Dies ist wichtig weil rollenbasierte Zugriffskontrollarchitekturen einerseits eine konsistente Struktur erm glichen und andererseits die Komplexit t bei der Verwaltung verringern m chten Eine zweite Komplexit t die durch den Einsatz von RBAC erst entsteht ist der zeitliche und personelle Aufwand eine rollenbasierte Zugriffskontrollarchitektur zu implementieren Das dritte Kriterium befasst sich daher mit dieser Komplexit t und bewertet ob eine Automatisie rung beim Entwickeln von Rollen angeboten wird Ein weiteres Kriterium ist die Unterst tzung von Arbeitsprozessen bei der Wartung des Rollenmanagementwerkzeugs weil sich Rollen im Laufe der Zeit entwickeln und sowohl die Rollen als auch die Rollenstruktur angepasst werden m ssen Dieses Kriterium richtet sich demnach an die Akzeptanz des
370. zungen e assigned_users r roles gt 2 Abbildung einer Rolle auf die darin de finierten Benutzer assigned_users r u users u r E UA e assigned_permissions r roles gt 2 Abbildung einer Rolle auf eine Teil menge der Berechtigungen assigned_permissions r p permissions p r PA Forschungsgruppe C amp M Grundlagen 15 e session_roles s session gt goles Abbildung einer Sitzung auf die darin definierten Rollen session_roles si C r roles session_users si r UA e avail_session_perms s sessions gt 2P ssi s Berechtigungen f r eine spezielle Sitzung Abbildung eines Benutzers auf avail_session_perms s Jassigned _ permissions r y resession_roles s Funktionale Spezifikation Nachdem das Referenzmodell core RBAC beschrieben wurde wird im Folgenden auf dessen funktionale Spezifikation eingegangen Diese Spezifikation befasst sich mit Funktionen im RBAC Kontext die in administrative Funktionen systemunterstiitzende Funktionen und Funk tionen zur Uberarbeitung der Rollen unterteilt werden e Administrative Funktionen Diese befassen sich mit dem Erzeugen und Verwalten der Modellelemente und Relationen aus der Modellspezifikation von core RBAC Die grundlegenden Mengen zur Administration in RBAC sind users roles operations und objects Da die Mengen operations und objects technische Endsysteme darstellen liegt deren Administration au erhalb
371. zur Erstellung von Arbeitsabl ufen engl workflows Diese Arbeitsabl ufe wurden schon vereinzelt erw hnt denn sie sind ein elementa rer Bestandteil von OIM Durch sie werden alle Automatismen in OIM realisiert Aus diesem Grund soll der Designer zum Ende des Einf hrungskapitels zum Omada Identity Manager exemplarisch pr sentiert werden Hierbei bietet OIM eine eigene grafische Modellierungsspra che an um die workflows zu spezifizieren In Information 27 ist ein Beispielprozess abgebildet der das Hinzuf gen eines neuen Mitarbeiters in OIM teilautomatisiert Angesteuert wird dieser Prozess sobald im Verzeichnisdienst ein neuer Mitarbeiter erkannt wird Anschlie end wird ei ne neue Identit t erzeugt die die Eigenschaften zugewiesen bekommt die das Mitarbeiterobjekt im Verzeichnisdienst aufweist Dies sind neben dem Namen auch Eigenschaften wie etwa die Abteilungszugeh rigkeit Anschlie end wird der Prozess an den Abteilungsleiter derjenigen Abteilung delegiert in der der neue Mitarbeiter arbeiten wird Er muss dem neuen Mitarbeiter eine Rolle im Sinne des OIM zuweisen oder ihn abweisen Im ersten Fall wird der Prozess an die IT Abteilung weitergereicht die dem Mitarbeiter ein Gesch ftsmobiltelefon ausstellt Schlie lich wird ein automatisches Passwort erzeugt welches dem Abteilungsleiter zugestellt wird Im zweiten Fall wird der Prozess mit einer Begr ndung f r die Abweisung an die Perso nalabteilung zur ckgeleitet Joiner Ext

Molitorisz - Institute for Program Structures and Data Organization

Contents

Download Pdf Manuals

Related Search

Related Contents