Richtungswechsel bei Identity Management

In der Vergangenheit übernahmen die traditionellen Identity-Management-Systeme (IdM) vor allem IT-lastige Administrationsaufgaben. Dabei stand der Ansatz des Single-Point-of-Administration im Fokus und überwiegend steuerten die Daten aus der Personalabteilung die Pflege von Identitäten und Berechtigungen. Die Rede war vom sogenannten HR-driven Provisioning. Gleichzeitig kam das Konzept der rollenbasierten Zugriffskontrolle (Role Based Access Control, RBAC) als effektive Kapselung von Berechtigungen auf.

Getrieben durch eine Vielzahl von regulatorischen beziehungsweise Compliance-Anforderungen ersetzt heute zunehmend die Business-orientierte Verwaltung von Berechtigungen das klassische IT-lastige Modell. Dieser Richtungswechsel des IdM lässt sich unter den Begriffen Access Governance und Access Intelligence zusammenfassen. Hierbei gilt es, mit geeigneten Maßnahmen, verstärkt die Fachabteilung in die Berechtigungsvergabe einzubinden und Business-verständliche Informationen in vielfältiger Form bereitzustellen.

In diesem veränderten Szenario stellt sich die Frage, welche Funktion die Rollenverwaltung einnehmen soll. Sind die Rollen hier nur noch ein technisches Relikt oder haben sie eine entscheidende Relevanz für das Business? Der folgende Beitrag beleuchtet diese Aspekte und beschreibt die Rollenverwaltung innerhalb von Access Governance und Intelligence.

Der Wandel zum Community-getriebenen IdM 2.0

Rollen sind seit langem bekannte und wichtige Kernkomponenten beim Identity Management. Im Rahmen von Access Governance und Intelligence verändert sich jedoch deren Aufgabe und Stellenwert. Die traditionelle Rollenverwaltung, das heißt die reine administrative Bündelung von Zugriffsrechten, ist nicht mehr ausreichend. Rollen müssen neue Business-orientierte Funktionen unterstützen und unterliegen beispielsweise einem Antrags- und Genehmigungsverfahren.

Aber gehen wir nochmals einen Schritt zurück und betrachten näher den Wandel im Bereich Identity Management. Wie alle IT-Themen ist auch der IdM-Markt in starker Bewegung. So sprechen wir heute von IdM 2.0, da der Community-getriebene Ansatz des Web 2.0, Inhalte zu erzeugen, sich auch auf das IdM-Umfeld übertragen lässt.

IdM 1.0 war IT-lastig, Administrator-orientiert und stellte den Single-Point-of-Administration, das HR-driven Provisioning sowie RBAC in den Vordergrund. Im Fokus standen nicht nur die Identitäten und deren Verwaltung, sondern vielmehr die Berechtigungen und deren Handhabung – besser ausgedrückt auch als Identity und Access Management (IAM) anstelle von IdM. Im folgenden Text verwenden wir jedoch weiterhin den Sammelbegriff IdM.

IdM 2.0 baut mit seinen Business-orientierten Funktionalitäten darauf auf. Bei den heutigen Systemen handelt es sich kurz gesagt um eine Business-Kollaboration-Plattform für die Zugriffsverwaltung. Die Systeme werden seitens der User verändert wahrgenommen und genutzt, beziehen die Fachabteilung in Entscheidungsprozesse ein und sind mit umfangreichen Self-Service-Funktionen ausgestattet, um nur einiges zu nennen. Letztlich ist der einzelne Anwender mehr denn je verantwortungsvoll in die sichere und regelkonforme Verwaltung der Zugriffsrechte mit einbezogen. Damit hat sich auch die Zielsetzung eines IdM-Systems gewandelt. Standen früher Faktoren wie Kostensenkung und effizientes User Management im Vordergrund, suchen Unternehmen heute nach einem System, mit dem sie zusätzlich Regularien und Gesetze sowie das Risikomanagement bewältigen.

Rolle als Business-verständliche Darstellung der Berechtigungen

Grundsätzlich haben die Benutzer konkrete Aufgaben im Unternehmen, für deren Ausführung diverse IT-Systeme zur Verfügung stehen. Sie müssen daher entsprechende Konten und Berechtigungen in den einzelnen Systemen besitzen. Man spricht vom sogenannten Berechtigungsdreieck: Wer (User) erhält was (Permissions) warum (Job). Aus dieser grundsätzlichen Dreiecksstruktur lässt sich das allgemeine Rollenmodell ableiten. Dabei tritt an Stelle der Job Function die Rolle, die alle Berechtigungen in dieser abstrakten Form kapselt. Die Semantik der Rolle soll dann den Job-Aufgaben entsprechen und somit Business-verständlich die technischen Berechtigungen aufbereiten beziehungsweise darstellen.

RBAC – Role based Access Control

Das RBAC-Modell, in dem erstmals Berechtigungen gekapselt wurden, um sie verständlicher für das Business darzustellen, prägte maßgeblich die Vorstellung von Rollen. Es wurde 1992 von Ferraiolo und Kuhn vom National Institute of Standards and Technology (NIST) in den USA beschrieben. Das sogenannte NIST-Model wurde damals bereits als (Semi-) Standard anerkannt und 2004 als ANSI-Norm (359-2004) übernommen. Es beinhaltet unter anderem die Definition von Rollenhierarchien für die Abbildung von komplexen Strukturen. Die Rollenhierarchien wurden aber sehr schnell zu umfassend hinsichtlich Design, Verständnis und Pflege und der RBAC-Standard hatte nur unzureichende praxisrelevante Use Cases. Die Erfahrung zeigte, dass sich die rein theoretische Betrachtung von Rollenmodellen in der Umsetzung eher als ungeeignet erwies.

Best-Practice in der Rollenverwaltung

War RBAC mehr auf die Zugriffskontrolle in den Zielsystemen fokussiert, so spiegeln heutige Rollenmodelle in einem IdM-System eher eine Enterprise-Sicht wieder, die die zielsystemspezifischen Berechtigungsstrukturen versteckt. Anstelle von akademischen Rollenhierarchien hat sich die Aufteilung in Business- und IT-Rollen in der Praxis etabliert, beziehungsweise als adäquat erwiesen. Ziel ist es, komplexe Rollenhierarchien zu vermeiden, die auf Dauer nicht verwaltbar sind. IT-Rollen definieren dabei den technischen Bezug der zugewiesenen Berechtigungen, die Business-Rollen hingegen den funktionalen Aspekt und/oder die Position des Benutzers innerhalb der Organisation. Das Rollenmanagement schlägt somit die Brücke zwischen Business und IT.

Bei der Erstellung eines Rollenmodells übernimmt die IT in der Praxis leider immer noch die führende Position, da die Zuweisung der Rollen nebst Antragsverfahren größtenteils in deren Verantwortung liegt. Oftmals scheint es sogar so, als ob die Rollen in einem modernen, automatisierten IdM-System nur das Leben der IT erleichtern, nicht aber das der Fachabteilung. Es gilt, Wege zu finden, das Business stärker in den Role-Lifecycle einzubinden, um beispielsweise Genehmigungsprozeduren zu vereinfachen und mehr Transparenz zu schaffen. Letztlich ist die Business-Ebene bei der Berechtigungsvergabe mehr in die Verantwortung zu nehmen und zwar nicht nur bei der Rollenerstellung, sondern auch bei deren Zuweisung, Pflege und Re-Zertifizierung. Dies lässt sich mit dem Begriff Identity und Access Governance (IAG) beschreiben. IAG bezeichnet ein ’neues’ IdM, in dem die Zugriffsverwaltung grundsätzlich vom Management gesteuert und verantwortet werden kann und muss – Governance dabei ganz im Sinne von Ownership. Hier sind wir wieder beim IdM 2.0 als Business-Kollaboration-Plattform, die von den einzelnen Akteuren getragen wird. Ziel ist es, IT-spezifische Ressourcen in Business-verständliche Bezeichnungen beziehungsweise Inhalte zu übersetzen und eine Business-Perspektive auf die darunterliegende IT-zentrische IdM-Infrastruktur zu entwerfen.

Neben Access Governance ist auch das Thema Access Intelligence derzeit ein treibender Faktor im IdM-Markt. Da allgemein statt der Identitäten heute die Berechtigungen im Zentrum stehen, lassen wir im Folgenden den Begriff Identity entfallen.

Die 2 Säulen Governance & Intelligence bei IdM

Access Governance beinhaltet, dass das IdM zur Steuerung, Verwaltung und Attestierung der Zugriffsrechte das Business involviert, Self-Service-Funktionen bereitstellt und Workflow-gesteuert ist. Access Intelligence als zweite Säule liefert dem Business wiederum Informationen und Wissen, um die richtigen Entscheidungen mit Blick auf die Kontrolle bestehender Berechtigungen, die Risikobewertung oder den Umgang mit privilegierten Benutzern treffen zu können. Die strukturierten und unstrukturierten Daten werden dabei aus unterschiedlichen Quellen generiert und bereitgestellt. Informationsbausteine sind Analysen, offline Reports sowie online Dashboards mit Drilldown-Funktion, auf die das Business leicht zugreifen kann. Aber wie gelangt man von den Daten über die Informationen zur Intelligence? Was bedeutet hier Intelligence? Im Deutschen übersetzen wir es im Zusammenhang mit IdM mit ’Nachrichtendienst’. Es geht um das Sammeln sowie Aufbereiten von Informationen und Erkenntnissen, um daraus Entscheidungen und Business-relevante Aktionen ableiten zu können. Die Daten werden dabei verdichtet und in kleine Portionen aufgeteilt, damit sie das Business in intuitiven Informationsportalen, ohne großen Trainingsaufwand, besser ’konsumieren’ kann. Soll- und Schwellenwerte werden vordefiniert und das Business über kritische Zustände automatisch benachrichtigt.

Welche Grundprinzipien für die Business-Orientierung stellen Access Governance und Access Intelligence also bereit? Die Fachabteilung wird durch Workflow-basierte Antragsverfahren und durch die Zusammenarbeit mit der IT bei der Rollenerstellung eingebunden. Zudem erteilt sie Zugriffsgenehmigungen und übernimmt Rollenverantwortung auf Fachabteilungsebene. Sie erhält darüber hinaus einen vollständig transparenten Einblick in die Berechtigungen mittels Business-freundlicher Reports und Dashboards sowie Drilldown-Funktionalitäten. Durch die sogenannte Re-Zertifizierung, im Rahmen derer Berechtigungen regelmäßig zu bestätigen sind, werden Risiken verringert und eine möglicherweise unzulässige Anhäufung von Rechten vermieden.

Antrags- und Genehmigungsverfahren

Typischerweise ist das Antrags- und Genehmigungsverfahren ein Workflow-gestützter Prozess. Dabei ist es wichtig, ein leistungsfähiges und flexibles Workflow-System zu implementieren, das unternehmensspezifische Ausprägungen umsetzen kann. Wie aber sind der Access Request und Access Approval Workflow konzipiert? Und wo liegt die zentrale Business-Verantwortung?

Die Workflows selbst bestehen aus einzelnen Prozessschritten und den dazugehörigen Akteuren. Jede Aktivität wirft dabei zahlreiche grundsätzliche Fragen auf. So stellt zunächst der Antragsteller beispielsweise für die Zuweisung einer Rolle einen Antrag. Schon kommt die Frage auf, ob er den Antrag auch für sich selbst ausführen (Self-Request) darf. Oder kann er nur für andere Benutzer einen Antrag stellen (Managed-Request)? Im nächsten Schritt wählt der Antragsteller eine oder mehrere Rollen aus. Welche darf er auswählen? Darf er grundsätzliche alle Rollen auswählen und erst im Genehmigungsschritt wird die Zulässigkeit geprüft oder darf er nur die eigene Rolle aussuchen? Nach der Antragstellung erfolgt die Prüfung durch den Genehmiger. Ganz klar ergibt sich hier die Frage, wer den Antrag überhaupt genehmigen darf und wie viele Genehmigungen, das heißt wie viele verschiedene Genehmiger eigentlich erforderlich sind? Nach der Genehmigung erfolgt schließlich die Umsetzung des Antrags. Zwei grundsätzliche Varianten sind hier möglich: die automatisch Vergabe der Benutzerrechte durch das IdM-System, das aus dem Workflow heraus angesteuert wird, oder die manuelle Ausführung durch einen Administrator, der die entsprechenden Einstellungen vornimmt. Schließlich werden am Ende des gesamten Workflow bei Bedarf Beteiligte oder auch Betroffene informiert.

Das Genehmigungsverfahren ist der Dreh- und Angelpunkt im gesamten Prozess. Abhängig von den Verantwortungsbereichen, aber auch mit Blick auf das Risikomanagement müssen in der Regel mehrere Personen einem Antrag zustimmen. Und hier liegt die eigentliche Übernahme der Verantwortung durch das Business. Bei einem Antrag für die Zuweisung einer Rolle sind beispielsweise folgende Akteure und Genehmigungsstufen betroffen: der Vorgesetzte, der wissen muss, welche Aufgaben seine Mitarbeiter haben und was sie beantragen; der Role Owner, der die Verantwortung für die Rolle trägt, ihre Semantik kennt und darüber in Kenntnis sein muss, wer ’seine’ Rolle nutzt; der Scope Approver, der Gruppen von besonders kritischen Berechtigungen überwacht; der Application Owner, der die Berechtigungsvergabe aus der Sicht der Anwendung kontrolliert und beispielsweise prüft, ob aufgrund begrenzter Lizenzen genügend Accounts vorhanden sind.

Am Beispiel des Antrags- und Genehmigungsverfahren ist deutlich erkennbar, dass die Business-Orientierung mit zahlreichen Fragestellungen verbunden ist, die entsprechende Antworten verlangen. Diese müssen mit neuen Datenstrukturen und -beziehungen abgebildet werden. Die Rolle spielt dabei stets die zentrale Entität.

Weiterte Eigenschaften von Rollen für bestes Access Governance

Die Risikobewertung, Re-Zertifizierung und Funktionstrennung (Segregation of Duties, SoD) gelten als weitere wichtige Eigenschaften von Rollen zur Business-orientierten Unterstützung im Rahmen von Access Governance. Abhängig von den gekapselten Berechtigungen und den damit geschützten Informationen beziehungsweise Aktionen können die Rollen bezüglich des Risikos bewertet werden. Zudem kann eine Risikobeschreibung erfolgen, die mit den Berechtigungen innerhalb einer Rolle verbunden ist. Die Risikobewertung dient unter anderem für eine bevorzugte Behandlung oder für ein spezielles Reporting. Für die regelmäßige Bestätigung einer Rolle, die Re-Zertifizierung, und die damit verbundene Frage, ob die Rolle noch notwendig ist oder ungewünschte Rechteanhäufungen vorliegen, müssen der Rolle bestätigende Personen zugeordnet werden. Zudem sind die Bestätigungszyklen pro Rolle zu definieren, was wiederum von der Risikobewertung abhängen kann. Bei der Funktionstrennung geht es darum, mittels einer SoD-Matrix Rollen festzulegen, die im Sinne des Policy Managements nicht gleichzeitig von einer Person wahrgenommen werden dürfen. Dies ist beispielsweise für Kreditinstitute wichtig, die eine Funktionstrennung bezüglich Vertrieb und Marktfolge bei einer Kreditentscheidung benötigen, das heißt der Mitarbeiter, der den Kredit vergibt, kann ihn nicht gleichzeitig genehmigen.

Bisher dienten Rollen vorwiegend der Kapselung von Berechtigungen und damit der Autorisierung. Sie förderten so eine effiziente Benutzeradministration (RBAC-Ansatz). Im Rahmen von Access Governance übernehmen die Rollen weitere Aufgaben, um diverse Business-orientierte Funktionen bedienen zu können. Daraus ergibt sich ein neuer Governance Layer, der durch eine Vielzahl von Beziehungen zu anderen Datenobjekten geprägt ist. Zudem werden diese Business-orientierte Funktionen zukünftig Einfluss auf die Granularität und auf das ’Schneiden’ der Rollen haben.

Rollenmanagement als Verbindung zwischen IdM 1.0 und IdM 2.0

Das Thema Access Governance und Intelligence wird weiterhin große Bedeutung haben. Die Rollenverwaltung und die Unterstützung des kompletten Role Lifecycle stellt bei den IdM-Lösungen die wichtige und relevante verbindende Datenstruktur zwischen dem IT-zentrierten IdM 1.0 und dem Business-orientierten IdM 2.0 dar. Rollen sind auch heute kein technisches Relikt, sondern entscheidende Faktoren in einem IdM-System, das den aktuellen Anforderungen gerecht werden muss. Die Trennung von Business- und IT-Rollen ermöglicht eine Business-verständliche Ansicht auf die IT-zentrischen Berechtigungen. (ph)