Eine ausufernde Anzahl von Rollen, wenn eine prozessbezogene Parametrisierung fehlt

Transkript

1 1 Aktuelle Situation Viele am Markt angebotene Rollenmodelle repräsentieren einen statischen Ansatz, der recht schnell an die Grenzen eines realistischen Einsatzes stößt. Solche Grenzen sind: Eine ausufernde Anzahl von Rollen, wenn eine prozessbezogene Parametrisierung fehlt Keine Trennung zwischen Fach- und Systemrollen und somit keine fachliche und technische Trennung in der Administration Keine Möglichkeit der Berücksichtigung dynamischer Strukturen (Team- oder Projektorganisation) kein oder nur ein rudimentäres Regelwerk zur Steuerung der Prozesse keine geordnete Koexistenz zwischen rollenbasierter und direkter Zuordnung von Berechtigungen kein mehrdimensionales Rechte Management (Kompetenzen, Organisations-Sichten, Daten- Sichten, Security Classification) Diese Beschränkungen auf Grund der Architektur oder der Funktionalität erlauben einem Anwender nur einen eingeschränkten bzw. wenig nachhaltigen Nutzen einer solchen Lösung. Dies ist insbesondere in der Problematik der Rollen- und Prozess-Steuerung begründet. Die einzelnen am Markt befindlichen Produkte ermöglichen es deshalb dem Anwender ein unterschiedlich hohes Niveau in der Qualität der IPM 1 -Prozesse zu erreichen. Unabhängig davon sind in der Architektur der jeweiligen Lösung Möglichkeiten zum Erreichen einer hohen Niveaustufe enthalten oder eben auch nicht gegeben. Letzteres ist vielfach bei Produkten zu finden, die vom konzeptuellen Ansatz nicht ursächlich für Provisioning-Prozesse entworfen worden sind. Von den meisten Herstellern wurde diese Problematik erkannt und durch den Zukauf separater Komponenten versucht zu lösen (z.b. den Sun Role Manager von der Firma VAAU, Oracle Role Manager usw.) Problematisch bei diesen beigestellten Komponenten ist immer der Fakt, dass sie unabhängig voneinander und oft abweichende Architekturansätze verfolgen. Dadurch sind die Vorteile eines einheitlichen und konsistenten Daten- und Funktionsmodells nicht bzw. nur schwer nutzbar zu machen. 1 IPM = Im Folgenden als erweiterter Begriff für Identity- und Prozess-Management genutzt info@secu-sys.de Web:

2 IdM Stufe Merkmale Chancen IDM-Ergebnis 5 Dissipativ 4 Gesteuert 3 Standardisiert 2 Geordnet 1 Ad hoc Situation Integriertes Rollen- und Prozessmodell, Routineeinsatz von Standardprozessen, zunehmende Automatisierung, Trennung von Modellierung und Administration IKS - Selbstüberwachung Einsatz eines zentralen Provisioning-Tools Einfaches Gruppenkonzept auf der Basis des konventionellen Provisionings Zentrale manuelle Organisation und Dokumentation, Einzelne Bereiche teilautomatisiert z.b. über das AD Systematisierung aber unterschiedliche Entwicklungsstufen und isolierte Einzelprozesse Improvisation, Berechtigungen auf Zuruf, keine Dokumentation Kontinuierliche Evolution und automatische Adaption Frühwarnfunktion, Qualifizierung des Regelsystems Integrierte technologische Basis, Problemvermeidung, Integration weiterer Komponenten Qualitative und strukturelle Darstellung der Prozesse, Problemerkennung Prüfungen, Tests, Standards; Erkennen von Risiken und Potentialen Einführung operativer Tools, Controlling; Qualifizierung der Datenbasis für Reports Hohe Produktivität, Motivation und Qualität Hohes Risiko, Reibungsverluste Abbildung 1: Niveaustufen der Prozessentwicklung von IPM-Systemen Die Auswahlkriterien für Produkte sind jedoch auch abhängig von den auslösenden Motivationen und Zielen eines IPM-Projektes. Die Lösung eines punktuellen Problems (z.b. mit einem Directory-System) bewirkt ganz andere Kriterien als ein strategischer Ansatz, der ein möglichst hohes Niveau in der Prozessqualität erreichen möchte. Wenn ein strategischer Ansatz verfolgt wird, sind an die Produkte gewisse Anforderungen zu stellen, damit sie dieses Ziel funktionell und aus Sicht der Architektur überhaupt ermöglichen. info@secu-sys.de Web:

3 2 Rollen- und Prozessmodell als einheitliches Konzept Der Autor ist im Rahmen seiner Projektarbeit (ca. 10 Jahre) genau auf diese Problembereiche gestoßen und hat entsprechende Verfahren entwickelt, um hier eine deutlich höhere Qualität der Rollenmodellierung zu erreichen. Im Laufe der Zeit wurde hierfür eine Reihe von Konzepten und Methoden entwickelt und diese exemplarisch in dem IPM - System (bi-cube ) umgesetzt, um die Praktikabilität der jeweiligen Implementation zu verbessern: 1. Integration von Rollen-Modell und Prozesssteuerung 2. Adaptives Rollenmodell 3. Definitorische Regeln und Prädikatenlogik 4. Generische Prozessmodelle 5. Security Classification 6. Referenzierte Rollen In einem iterativen Prozess (Verfahrensentwicklung < > Validierung im realen Einsatz) mussten die jeweiligen Lösungen jedoch ständig verfeinert und verbessert werden. 2.1 Integration von Rollen-Modell und Prozess-Steuerung Die Fach-Rollen definieren für sich ausschließlich aufgabenbezogene Rechteprofile, die sich unter Prozess-Sicht jedoch deutlich unterscheiden. Deshalb müssen an der Rolle bereits Prozess-Controls definiert werden, um die sachlich gegebenen Zusammenhänge im Modell hinreichend darstellen zu können. Hierzu gehören folgende Prozess-Controls: 1. Zuweisungsart (automatisch oder mit Freigabe) 2. Antragsart (jeder User, nur sein Leiter,...) 3. Sonderbehandlung bei Eigenantrag eines Freigebers 4. Freigabeverfahren (mehrstufig, Vier-Augen-Prinzip, zufällige Weiterleitung) 5. min - max Control 6. Kritikalität (geschäftskritisch oder nicht) 7. Security Classification Alle diese so genannten PX - Controls an der Rolle beeinflussen maßgeblich den Prozessmanager in der aktuell-kontextbezogenen Konfiguration des Prozesses. Dieses Verfahren macht schon hinreichend deutlich, welche Vorteile ein einheitliches und zentrales Datenmodell gegenüber zugekauften Komponenten z.b. einer externen Workflow-Engine hat. 2.2 Adaptives Rollenmodell Ein logisch separater Entwurf des Rollenmodells ohne Berücksichtigung der Prozess-Steuerung führt zu einem statischen Modell und damit zu einer Explosion der Anzahl der Rollen, wenn trotzdem versucht wird, die Vielfalt der Realität zu berücksichtigen. In dem System bi-cube wurde deshalb eine Differenzierung der System-Attribute in Berechtigungsattribute und technische Attribute vorgesehen. Die Berechtigungsattribute eines Zielsystems sind in der Rolle zwangsweise festzulegen. Eventuell spezifische aber erforderliche Ausprägungen (Datenbestand, Server, besondere Skills des Users, wie z.b. Freigabegrenzen...) von Systemattributen sind deshalb als technische Attribute klassifiziert und müssen während der Vergabe (Antragsverfahren) durch die jeweiligen Owner beigebracht werden. Dieser Freigabeprozess kann auch mehrstufig sein (Daten-Owner, Lizenz-Verwaltung, Kostenverantwortlicher, System-Techniker, info@secu-sys.de Web:

4 etc.), wobei jeder Aktor zugeordnete Attribute beibringen muss. Auf diesem Wege wird das Rollenmodell durch die Parametrisierung der Rollen maßgeblich entlastet und die Rollen auf eine überschaubare Zahl gebracht. 2.3 Trennung von Fach- und System-Rollen Fach-Rollen beschreiben ausschließlich die Aufgabe / fachliche Tätigkeit des Rolleninhabers. Wogegen die System-Rollen die Zuordnungen der Berechtigungen zu einer Rolle festlegen. Diese Trennung hat sich aus folgenden Gründen als unverzichtbar erwiesen: 1. Die Systemrollen enthalten die konkreten Systemberechtigungen und werden zentral definiert 2. Die Fachrollen werden in den Fachbereichen definiert und auch zugeordnet Somit wird das Ziel der zentralen Modellierung und der dezentralen Administration ganz eindeutig gesichert. Gegenstand des Prozessmanagements sind ausschließlich die Fachrollen. 2.4 Team- und Projektorganisation Formal ist ein projektbezogenes Rollenmodell wenigstens 2-dimensional (funktionelle Rechte, Datensichten). Mit einem statischen Rollenmodell würde diese m*n Matrix zu einem ebenfalls m*n Rollenmodell führen, was letztlich zu einer nicht mehr beherrschbaren und vor allem unsinnigen Zahl von Rollen führen würde. Wenn auf dieses Problem das adaptive Rollenmodell angewendet wird, reduziert sich die Anzahl der Rollen auf die Zahl der funktionellen Rechtekombinationen (Projektleiter, -mitarbeiter, Controller, Konstrukteur,...). Die jeweiligen Sichten auf die Projektdaten (Projekt-Dokumente, - Laufwerk, - Mailgruppe,...) werden während der Rollenzuordnung im Prozess beigebracht. Ganz nebenbei lässt sich hier auch die Frage der zulässigen (bzw. unzulässigen) Kombinationen von Datenbereichen (verschiedene Projektunterlagen) lösen. Ein besonders wichtiger Aspekt bei der Modellierung von Team- bzw. Projektrollen ist die weitgehende Integration in das Prozessmanagement und damit der Automatisierung wesentlicher Standardaufgaben. Sowohl der Start als auch das geordnete Ende eines Projektes werden weitgehend automatisch abgewickelt und reduzieren den IT-Aufwand in der Projektorganisation ganz erheblich. Zur Modellierung der Business-Prozesse gehört auch die logische Verwaltung der Rechte abgeschlossener Teilprojekte. Wenn in der Abbildung 2 unten im Projekt AUVA die Phase 1 aktiv ist, haben alle Teammitglieder den lesenden Zugriff auf die Daten der Vorstufe. Differenzen im Zugriff z.b. von Internen und Externen werden über die Security Classification geregelt. info@secu-sys.de Web:

5 Abbildung 2: Projektmanagement in bi-cube (fiktives Beispiel) 2.5 Separation of Duties (SoD) Die sichere Trennung von unzulässigen Kompetenzen erfolgt ebenfalls am einfachsten auf der Ebene der Fachrollen durch die Definition von Rollen, die nicht in Kombination bei einem User auftreten dürfen. Wobei hier zwischen statischer und dynamischer SoD zu unterscheiden ist. Statische SoD liegt im Bereich der Fachrollen vor. Hier dürfen generell bestimmte Rechte sich nicht auf einen User vereinigen Dynamische SoD ist bei den Team-Rollen erforderlich. Ein Team-Leiter kann in demselben Projekt nicht Controller sein. In einem anderen Projekt hingegen schon. Die SoD-Regeln müssen auch in den Prozessen Berücksichtigung finden. Im Normalfall können sich Rollen während eines OE-Wechsels (OE= Organisationseinheit) durchaus eine gewisse Zeit überlagern. Der neue Leiter kann schon vor dem Wechsel neue Rechte beantragen und der bisherige Leiter kann für die Rollen noch eine individuelle Nachlaufzeit festlegen. Falls hier die SoD-Prüfung positiv ist, dann wird eine solche Überlagerung verhindert und der Wechsel der Rollen erfolgt genau zum Stichtag (OE-Wechsel-Datum). Auch dieses Beispiel belegt die enge Kopplung zwischen Rollenmodell und Prozess-Steuerung. Web:

6 2.6 Referenzierte Rollen (Objekt-Referenzen) Eine weitere Möglichkeit zur Verschlankung des Rollenmodells sind die Objektreferenzen, die sich auf Rollen- und Systemebene definieren lassen. Objektreferenzen werden als so genannte vorgelagerte shared resources (VSR) definiert. Dies sind Programme, die als Voraussetzung für andere Programme notwendig sind (z.b. CICS- oder DB-Client). Diese werden als VSR bereits auf Systemebene an die jeweilige Anwendung gebunden, womit sie im Rollenmodell nicht mehr zu berücksichtigen sind. Analog lassen sich Rollen definieren, die über Objekt-Referenzen mehrfach an Fachrollen gebunden werden können und in den eigentlichen Fachrollen somit nicht mehr definiert werden müssen. Ganz nebenbei werden damit Änderungen an den Basisrollen deutlich einfacher und sicherer. Web:

7 3 Rollen-Referenz-Modell (RRM) Um den in der Regel langwierigen Entwicklungs-Prozess eines Rollenmodells im Unternehmen zu verkürzen werden vom ism ein allgemeines Rollenmodell und darauf aufbauend für einige Branchen (u.a. für die Versicherungswirtschaft) spezielle Rollen-Referenz-Modelle entwickelt. Dieses Rollen- Referenz-Modelle ist vor allem im Einsatz eines Rollenmodells in heterogenen IPM-Umgebungen sinnvoll. Eine deutliche Reduzierung der Einführungszeit eines IPM-Systems ist erreichbar durch: Die Nutzung des etablierten Vorgehensmodells (Rapid IPM) Durch den Einsatz eines weitgehend vordefinierten Rollenmodells und Die Nutzung der generischen Prozess-Modelle in bi-cube, die ein hohes Maß an Automatisierung in der IT-Administration ermöglichen Das RRM liegt in vier Stufen vor: 1. Stufe / Rollentypen und -Eigenschaften 2. Stufe / allgemeine Rollen in Unternehmen 3. Stufe / Fach-Rollen-Modell für spezielle Branchen 4. Stufe / Spartenausprägungen im Rollenmodell Abbildung 3: Rollenreferenzmodell einer Versicherung (fiktives Beispiel) Am Beispiel des RRM für Versicherungen würden die Stufen 1-3 weitgehend aus dem RRM übernommen und die Stufe 4 den aktuellen Sparten und deren Ausprägung einer konkreten Versicherung entsprechend angepasst. info@secu-sys.de Web:

8 4 Generische Prozess-Modelle (GPM) Für diverse Prozesse im Provisioning lassen sich Templates definieren, die dieses Teilprojekt in Aufwand und Zeitdauer um 70% bis 80% reduzieren. Diese Templates sind in allen Parametern getestet und können umgehend produktiv gesetzt werden. In dem GPM - Projekt des ism wurde ein Standard-Set von GPM definiert und realisiert. Diese Palette wird ständig durch neue Anregungen aus den Projekten erweitert. 1. Antrag für Rollenzuteilung 2. Automatische Berechtigungsvergabe für neue Mitarbeiter (Mitarbeitereintritt) 3. Richtlinien-Bestätigung und Richtlinien-Verwaltung (separat und integriert in den Antragsprozess) 4. Automatisches Mitarbeiteraustrittsverfahren 5. Sofortiges Usersperren 6. Berücksichtigung gleitender Übergänge / Wechselprozesse im Unternehmen 7. Wiedereintritt in Konzernstrukturen 8. Allgemeiner dokumentenbasierter Antrags-Prozess 9. Antrag für allgemeine Applikationen ohne Strukturierung der Berechtigungen 10. Supportanfrage an NBV (Nutzer- u Berechtigungsverwaltung) 11. Re-Lizenzierung (regelmäßige Bestätigung einer bereits erteilten Lizenz) 12. Re-Zertifizierung (regelmäßige Bestätigung eines bereits erteilten Nutzungsrechts) 13. Re-Validierung (regelmäßige Bestätigung der Existenz eines Users) 14. Password Self-Service Nebengelagerte Prozesse Antrag auf Arbeitsplatz für einen Mitarbeiter inkl. Ausstattungsvarianten Abwesenheits- / Urlaubsverwaltung (zur Steuerung des Task-Manager) Antrag auf Zutrittsberechtigung Aus diesen Beispielen wurde folgende Klassifikation der IPM - Prozesse abgeleitet: Prozess-Gruppen Wechselprozesse des Users Antragsverfahren Wiederholungsfreigaben Nebengelagerte Prozesse Serviceprozesse info@secu-sys.de Web:

9 5 Leistungsfähiges Regelwerk in bi-cube bi-cube stellt ein umfassendes Regelwerk zur Verfügung, das sowohl einfache logische Zusammenhänge erfassen als auch über eine integrierte Prolog-Engine komplexe und kontextabhängige Steuerungen der Prozesse realisieren kann. Weiterhin enthält bi-cube diverse implizite Regeln, die im Folgenden ebenfalls kurz beschrieben werden. 5.1 Definitorische Regeln und Prädikatenlogik Die Integration von Rollen und Prozessen erfordert eine leistungsfähige Regelverarbeitung. Eine Form der Regeln ist ein Komplex von definitorischen Regeln, die zu den Objekten, Attributen und den einfachen Beziehungen zwischen diesen, direkt in der GUI definiert werden. Eine etwas komplexere Regeldefinition mit einer booleschen Logik findet sich bereits in der (User-) Attribut - Indizierung von Rollen. Hierdurch wird die Gesamtheit der definierten Rollen sachlich derart eingeschränkt, dass den Usern nur wirklich zutreffende bzw. sinnvolle Kompetenzen über Rollen zuzuordnen sind. Es macht wenig Sinn, jedem User alle Rollen vom Vorstand bis zum Pförtner anbieten zu wollen. Abbildung 4: Attribut-Indizierung in bi-cube (fiktives Beispiel) Eine weitere Möglichkeit besteht darin, Konsequenzen zu definieren, die auf das interne Message - Protokoll von bi-cube aufsetzen. Hier wird für jede Message geprüft, ob eine Regel (Konsequenz) gibt. Hierbei sind neben diversen Sonderprüfungen vier generelle Kombinationen möglich: Wenn Attribut 4711 Wert xy hat Dann Attribut 3332 Setze Wert auf abc Wenn Attribut 4711 Wert xy hat Dann starte Operation 1234 Wenn Operation xyz Dann starte auch Operation 1234 Wenn Operation xyz Dann Attribut 3332 Setze Wert auf abc info@secu-sys.de Web:

10 5.2 Prolog-Engine Mit der weiteren Qualifizierung der Prozesse werden komplexere Regeln erforderlich, die sich nicht mehr mit den vorhandenen definitorischen Regeln steuern lassen, vor allem nicht, wenn die Abläufe vom gesamten Kontext abhängig sind. So stellt sich der Mitarbeitereintritt für externe User komplett anders dar als bei einem internen Mitarbeiter. Weitere Bedingungen (z.b. Standort- oder Mandanten-Abhängigkeiten) erhöhen die Komplexität des Prozesses zusätzlich. Um auch diese komplexen Business Modelle abbilden zu können, wurde eine Regelmaschine zur Verarbeitung einer Prädikatenlogik entwickelt und integriert. Diese Komponenten (bi-cube LOGI) verarbeitet einfache, komplexe und auch rekursive Prolog-Notationen in der Prolog-Engine. Die gewählte Syntax ist nahezu natürlich sprachlich entworfen worden und stellt ein deutliches Alleinstellungsmerkmal für bi-cube dar. Damit können alle vorkommenden logischen Kombinationen zur Prozess-Steuerung in entsprechenden Regeln abgefangen und nach einer gewissen Übung auch vom Anwender definiert werden. 5.3 Funktionsintegrierte Regeln Im Funktionsmodell von bi-cube waren ebenfalls logische Entscheidungen zu treffen, die den Charakter von Regeln haben und in gewissen sinnvollen Grenzen auch konfigurierbar sind Koexistenz von Rollen- und Systemberechtigungen Es ist ein zu akzeptierender Fakt, dass das Erreichen einer komplett rollenbasierten Berechtigungs- Vergabe ein evolutionärer Prozess ist, der früher oder später oder auch nie erreicht wird. Deshalb muss es auch für die Koexistenz zwischen direkter und rollenbasierter Berechtigungsvergabe eine Regel geben, wenn beide Verfahren aufeinander treffen. Dies ist dann der Fall, wenn eine bestehende direkte Systemberechtigung (evtl. durch die Migration) mit einer rollenbasierten zusammentrifft. Dann gilt die allgemeine Regel, dass die rollenbasierte Berechtigung die bestehende direkte komplett überschreibt und u. U. damit auch Rechte entzieht. Rollenhierarchie Mit den Clustern als Anker bilden die Rollen eine Objekthierarchie, wobei die Systemrollen jeweils die Blätter des Baumes bilden. Um den weitgehenden allgemeinen Fall zu berücksichtigen, müssen einer Fachrolle nicht notwendig Berechtigungen in Form einer Systemrolle zugeordnet sein. D.h. es können auch Fachrollen ohne spezifische Berechtigungen definiert werden, die aber eine spezifische Tätigkeit oder Verantwortlichkeit darlegt (z.b. Datenschutz-Beauftragter) woraus sich u.a. aber SoD-Regeln ableiten können. Beispielsweise sollte ein IT-Leiter sicher nicht gleichzeitig Datenschutz-Beauftragter sein. Duale Vererbung von Rollen In bi-cube kann Vererbung von Rollen in zwei Dimensionen definiert werden: 1. in der Hierarchie der Fachrollen 2. in der Organisationsstruktur Fachrollen können hierarchisch strukturiert werden und einzelne Tätigkeiten (Fachrollen) zu einer gemeinsamen Fachrolle zusammengefasst werden. Wobei die Fachrollen in der untersten Ebene weiterhin direkt zugeordnet werden können. Web:

11 In bestimmten stark strukturierten Organisationen (z.b. diverse Geschäftsstellen, für die gleiche Rollen gelten) sollen in der OE-Struktur Fachrollen vererbt werden. Wenn z.b. alle 150 Geschäftsstellen unter einer OE liegen, dann können die Rollen dieser Geschäftsstellen einmal mit der übergeordneten OE indiziert und gleichzeitig eine Vererbung (mit definierter Vererbungstiefe) eingestellt werden. Rollenkonflikte An dieser Stelle werden Rollenkonflikte als das Zusammentreffen von unterschiedlichen Berechtigungsprofilen eines Systems aus zwei (oder mehreren) Rollen verstanden. Auch für diesen Fall muss es je System eine Regel zur automatischen Auflösung des Konfliktes geben. Die beiden typischen Regeln sind dann: Vereinigung beider Profile auf einem Account Anlegen eines weiteren Accounts mit dem abweichenden Profil Diese Regel muss auch bei mehrfachem Auftreten eines solchen Konfliktes und vor allem beim Entzug einer Rolle sauber verarbeitet werden. Security Classification Es hat sich als sinnvoll erwiesen, dass alle Objekte und Attribute mit einer Security Classification (SC) versehen werden können. Diese SC wird als eine weitere Rechtedimension innerhalb des IdM- Regelwerks angesehen. Dieser Regelapparat kann zur Vorselektion von Zuordnungen genutzt werden: Ein User muss wenigstens die gleiche (oder eine höhere) Security Classification haben wie die gewünschte Rolle. Außerdem können bestimmte Aktionen von der SC der Rolle oder des Users abhängig gemacht werden: Beispielsweise wird ab einer definierten SC-Stufe eine weitere Freigabe oder eine Information an bestimmte Personen (z.b. Security-Team) generiert. Außerdem ist die SC ein wichtiges Kriterium innerhalb des Internen Kontrollsystems (IKS) und des Reportings. Web:

12 6 Zusammenfassung In diesem Manuskript wurden diverse Steuermöglichkeiten innerhalb des Rollen- und Prozess- Managers dargestellt, die alle zu einer besseren Modellierbarkeit der realen Anforderungen beitragen. Je nach der Leistungsfähigkeit des Regelwerks ist ein Produkt in der Lage, ein hohes IPM- Prozessniveau zu erreichen. Generelle Erkenntnis aller Arbeiten war: Rollen-Modell und Prozessmanagement müssen eine enge Integration miteinander realisieren, wozu ein leistungsfähiges Regelsystem unabdingbar ist. Web:

13 7 Rollentypen in bi-cube 7.1 Standard-Typen Als Ergebnis der realisierten Projekte, den vorliegenden Anforderungskatalogen aus Ausschreibungen und als kleinster gemeinsamer Nenner der Produkte ergibt eine Typisierung von Rollen in: Fachrollen und Systemrollen Es hat sich zur besseren Übersicht und differenzierter Rechtegestaltung als sinnvoll erwiesen, die Fachrollen zu gruppieren. Clusterrollen (CR) Diese hier als Cluster-Rollen (CR) bezeichneten Gruppen werden mitunter auch synonym als Organisationsrollen bezeichnet. Die Cluster-Rollen (CR) bilden die Wurzeln des Rollenbaumes. Sie dienen im Wesentlichen einer groben Strukturierung der Rollen und werden dem User nicht direkt zugeteilt. Fachrollen (FR) Unterhalb der Clusterrollen werden die Fachrollen definiert. Sie beschreiben Tätigkeiten und Aufgaben der Nutzer und können auch hierarchisch modelliert werden. Die hierarchische Struktur gestattet eine Vererbung der Rollen und deren Rechte. Systemrollen (SR) Die eigentlichen Berechtigungen werden grundsätzlich in den System-Rollen (SR) festgelegt. Diese wiederum bilden die Blätter des Rollenbaumes. Durch diese Modellierungs-Methodik lassen sich komplexe Zusammenhänge trotzdem übersichtlich darstellen. CR / OR Clusterrollen / Organisationsrolle FR Fachrolle 1 FR Fachrolle 1.2 SR Systemrolle 1.2 Abbildung 5: Aufbau der Rollenstruktur info@secu-sys.de Web:

14 Team-Rollen (TR) Team-Rollen sind eine spezielle Ausprägung der FR. Sie werden zur Projektorganisation genutzt und können damit unternehmensweit zugeordnet werden. Im Unterschied zu den anderen Rollen, können TR einem User auch mehrfach zugeordnet werden, da ein Mitarbeiter ja auch in mehreren Projekten als Projekt-Leiter fungieren kann. Die TR haben jedoch eine entscheidende Eigenschaft, die maßgeblich zur Reduzierung der Rollenanzahl beiträgt. Die in den TR modellierten Systeme enthalten Technische Attribute, die in der Rolle nicht wertmäßig vorbelegt sein müssen (im Gegensatz zu Berechtigungs-Attributen). Dieser Technischen Attribute beschreiben spezifische Projekte (z.b. den Zugang zu einer Notes-Projekt-DB, die die Dokumente zu dem Projekt enthält) und werden erst während des Antragsprozesses der TR durch den Antragsteller oder Genehmiger beigebracht. Dynamische System-Rollen (DSR nach RBAC) Dynamische System-Rollen sind eine spezielle Ausprägung der Systemrolle. Sie stehen der Anwendungsentwicklung zur Verfügung. Durch die DSR erübrigt sich in Eigenentwicklungen die Programmierung einer applikationsbezogenen User- und Berechtigungsverwaltung. Der Entwickler braucht in seiner Anwendung nur die entsprechenden Access-Controls (AC) definieren und in einem entsprechenden Tool in einer vorgegebenen Syntax hinterlegen. Aus diesem Tool werden die AC in das Zentralsystem automatisch übernommen und können dann in den DSR als spezifische Rechtestrukturen im Rollenmodell den Usern zur Verfügung gestellt werden. Restriktions-Rollen (RR) Eine Restriktions-Rolle (RR) beschränkt die Verfügungsberechtigung eines Administrators derart ein, dass hier Systeme und deren Attribute definiert werden, die ein Administrator sehen und damit am User verwalten kann. Damit wird der Realität Rechnung getragen, dass ein SAP-Admin in der Regel kein AD administrieren kann und darf und umgekehrt. Die Festlegung bis auf Attributebene erlaubt eine weitere Granularitätsebene für die Rechte der Administratoren. In bi-cube vordefinierte Rollen Dies sind Fach- und evtl. auch darunter angeordnete Systemrollen, die in dem System vordefiniert sind, da sie z.b. als Aktoren in der Prozess-Steuerung festgelegt worden sind. Sie befinden sich unterhalb einer speziellen Cluster-Rolle und können durch den Anwender nicht verändert werden. Web: