Von der Middleware zum Erfolgsgaranten – IAM Systeme im Wandel

Die Domänen Identity and Access Management (IAM) und Identity and Access Governance (IAG) in modernen Unternehmen unterliegen einem stetigen Wandel. 

IAM/IAG-Systeme werden klassischerweise hauptsächlich als Middleware eingesetzt, die eine technische Synchronisation von Identitäts- und  Berechtigungsdaten aller relevanten Systeme erlauben und eine zentrale Administrationsoberfläche für die Verwaltung bieten.

Jedoch steigen im heutigen agilen Geschäftsumfeld die Anforderungen an solche Systeme. IAM wird von Unternehmen nicht mehr nur als Disziplin wahrgenommen, mithilfe derer klassische Joiner-/Mover-/Leaver Prozesse realisiert und Richtlinien und Regeln ohne große Nutzerinteraktion umgesetzt. Vielmehr wird IAM als One-Stop-Shop für alle Anwender einer Organisation verstanden, um Ihnen verschiedenste Möglichkeiten zu bieten in den Prozessen mitzuwirken. Die technische Basis ist weiterhin die Grundvoraussetzung für erfolgreiches IAM. Die Weiterentwicklung von Governance-Strukturen innerhalb der Unternehmen, die Verankerung der Verantwortlichkeit über Daten innerhalb von Fachbereichen und die stärker geforderte aktive Mitarbeit der Business Units an der Berechtigungsvergabe stellen aber neue und andere Anforderungen an das IAM.

Während der Anwenderkreis des IAMs sich früher hauptsächlich auf IT und IT-affine Anwender fokussierte, sind heute fast alle Mitarbeiter eines Unternehmens zur aktiven Beteiligung und Verantwortungsübernahme im Identitäts- und  Berechtigungsmanagement gefordert. Abteilungsleiter sollen neue externe Kollegen über das IAM onboarden, Geschäftsrollenverantwortliche ihre Rollenzusammenstellungen prüfen und Anwendungssystemverantwortliche die Zuweisung von kritischen Berechtigungen ihres Systems genehmigen. Meist kommt erschwerend hinzu, dass IAM als Disziplin wahrgenommen wird, die nur von einer zentralen und meist monolithischen Lösung zu meistern ist. Insbesondere bei größeren Unternehmen treten Performance- und Flexibilitätsprobleme zusammen mit hohen Kosten auf, wenn neue Anforderungen innerhalb dieses Kosmos realisiert werden sollen. In den letzten Jahren zeigt sich aber, dass IAM als Gesamtheit eher aus einzelnen, zielgerichteten und leicht anpassbaren Modulen besteht, die möglichst flexibel und dynamisch zusammenarbeiten müssen, um das Portfolio an Diensten schnell und einfach bereitzustellen. 

IAM-Self-Services – Development  Kit als Voraussetzung

Insbesondere die Bereitstellung von Self-Services für Fachbereiche und Endanwender gewinnt an stetiger Bedeutung und wird als Aushängeschild eines modernen IAM wahrgenommen. Einen Self-Service charakterisiert hierbei, dass er eine isolierte und reduzierte IAM-Funktionalität für einen gewissen Personenkreis zur Verfügung stellt. Beispiele solcher Services sind u.a. Berechtigungs- und Geschäftsrollenanträge durch den Empfänger, Rollenveränderungsanträge innerhalb des bestehenden Geschäftsrollenmodells oder die selbst-initiierte Rezertifizierung durch Verantwortliche. Neben den Services bedingt die immer stärker notwendige Mitarbeit des Fachbereichs auch deutlich gestiegene Herausforderungen an die Transparenz der im IAM verankerten Informationen, um dem Endanwender immer die individuell korrekten und notwendigen Daten anzuzeigen.

Um diesen Anforderungen agile Lösungen für einzelne solcher Endbenutzer und  deren Interaktionswünsche zu präsentieren, bieten IAM-Tools verschiedene Lösungsansätze. Der erfolgversprechendste Lösungsansatz zeigt sich in der Einführung und Bereitstellung eines IAM Development Kits, das verschiedenste Werkzeuge für den schnellen Aufbau und Einsatz von IAM- Services bietet. Ein solches Development Kit, wie es beispielsweise die Identity Analytics & Governance Platt form NEXIS 4 bietet, besteht typischerweise aus den folgenden Komponenten: 

1. Konfigurierbare UI/UX:

Das Frontend als wichtigste Interaktionskomponente für die Zielgruppe muss schnell und leicht anpassbar sein.  Klassische Ansätze, die Interfaces per HTML oder webbasierten Entwicklungsmethoden zu erstellen, erweisen sich als zu langsam, um mit den erforderlichen  Fachbereichsanforderungen Schritt zu  halten. Ein Baukastensystem, das eine individuelle, schnelle und rein konfigurative Aufbereitung des Interfaces für den Fachbereich erlaubt, ist hier unabdingbar. Ein modernes Development Kit bringt eine Vielzahl an konfigurierbaren UI-Elementen mit, die trotzdem Best-Practices folgen und standardisiert einzusetzen sind. 

2. Dynamisches Formularmanagement: 

Formulare und Anträge stellen eine bedeutende Basis für viele Self-Services  dar. Anwender müssen Formulare mit Informationen aus bestehenden Live-Daten in ihrem jeweiligen Kontext bestücken können. So muss beispielsweise ein Rollenverantwortlicher, der die Stammdaten seiner Rolle editieren möchte, ein Formular zu seiner Rolle einsehen dürfen das nur für ihn relevante Daten enthält und eine fehlerfreie Bearbeitung zulässt. Gültige Wertelisten für Attribute der Rolle so wie Referenzen auf andere Objekte, etwa um Genehmiger festzulegen, müssen schnell und einfach in der Formularkonfiguration zur Verfügung gestellt werden können. Über die Formulare werden wichtige Kontextinformationen für alle weiteren Work-flow-Schritte erhoben, die von verschiedenen Stakeholdern durchlaufen werden  müssen.

3. Moderne IAM-Workflow-Engine: 

Eine template-basierte Workflow-Engine,  die eine Vielzahl typischer IAM-relevanter Konfigurationen erlaubt, ist unabdingbar für den schnellen Einsatz von IAM-Services. Beispielsweise darf keine aufwändige Programmierung notwendig sein, um das 4-Augen-Prinzip in einem Workflow zu erzwingen, um SOD-Prüfungen bei Anträgen vollautomatisiert im Hintergrund durchzuführen, oder um Best-Practice-Delegationsketten (an den Vorgesetzten oder den Dateneigentümer) zu realisieren. Traditionelle IAM-Work-flow-Engines erfordern meist tiefes technisches Verständnis und Programmierarbeit, so dass meist nur ein recht kleiner Personenkreis Änderungsanforderungen umsetzen kann.  

4. Individuelle Stakeholder Konfiguration: 

Services für Endanwender müssen den verschiedenen Stakeholdern individuell präsentiert werden. Innerhalb der Services müssen Daten dynamisch und kontextbasiert geladen und angezeigt werden. Rollenverantwortliche dürfen beispielsweise nur die von ihnen verantworteten Rollen einsehen und Änderungsanträge für diese Rollen starten. Die Individualisierung von Services bedingt bei klassischen IAM-Systemen schwerfällige und oft programmatische Anpassungsarbeiten. Ein IAM-Service Development Kit stellt im Auslieferungszustand bereits Templates nach dem Baukastenprinzip und leicht konfigurierbare Möglichkeiten zur Verfügung.

Rapid Prototyping von IAM-Services

Die Projekterfahrung zeigt, dass insbesondere die Bereitstellung der genannten Self-Services im IAM durch Unterstützung von agilen Entwicklungsmethoden gut umzusetzen ist. Unter Zuhilfenahme eines template-basierten und leicht bedienbaren Development Kits, können gemeinsam mit dem Fachbereich in iterativen  Entwicklungszyklen und ohne viel IT Know-how neue IAM-Services angeboten werden. Ein typischer Entwicklungsprozess eines solchen IAM-Services sieht wie in Bild 1 aus. 

Zunächst formuliert der Fachbereich beziehungsweise Adressat des Services seine Anforderung in Form von User Stories, die gemeinsam mit dem IAM-Team diskutiert und konkretisiert werden. Das  IAM-Team erstellt auf dieser Basis innerhalb kürzester Zeit einen Prototypen des Services anhand dessen die Anforderungsumsetzung erprobt werden kann. Im Falle kleiner Änderungen können diese live und gemeinsam mit dem Fachbereich in Workshops umgesetzt werden.  Der Service kann dann als isolierte Komponente über das klassische IAM-Staging in die Produktion übernommen werden. Die zugrundeliegende Prämisse des Entwicklungsprozesses ist es, dass Anpassungen gemeinsam mit den Fachexperten und ohne Wechselwirkungen auf bestehende IAM-Funktionalitäten erfolgen. Dies gewährleistet einerseits die erwartete Funktionalität, erlaubt es aber auch, weiche Faktoren (wie die Usability oder die Endbenutzer-Akzeptanz) schon durch die Ausgestaltung des Entwicklungsprozesses zu beachten.

Bild 1: Prozess zur Entwicklung von IAM-Services. Quelle: Nexis

Beispiel Rollenerstellung 

In einem vollwertigen IAM stellen Geschäftsrollen einen integralen Bestandteil der Berechtigungsvergabe dar. Die Bündelung von Berechtigungen in anwendungsunabhängige Geschäftsrollen erlaubt die flexible und (teil-)automatisierte Vergabe von Berechtigungen an Mitarbeiter. Während der Aufbau eines Geschäftsrollenmodells mittlerweile bereits von vielen Unternehmen realisiert ist, ist die operative Administration des Rollenmodells weiterhin ein oft manueller und ad-hoc getriebener Prozess. Der Fachbereich stellt häufig die Anforderung an die  Funktionalität von Geschäftsrollen, während sich die IAM-Zentrale oder Rollenkoordinationsstelle darum kümmert, dass neue oder veränderte Geschäftsrollen dem unternehmensweiten Rollenmodell folgen. Im Markt ist eine Verlagerung dieses Prozesses zur individuell gewünschten Rollenerstellung durch Fachbereiche beobachtbar. Da jedoch häufig das Know-how im Fachbereich fehlt, stellt dieser Schritt eine Herausforderung dar. Ein strukturierter IAM-Service, der vordefinierten Rahmenbedingungen unterliegt, schafft hier Abhilfe. Im folgenden Beispiel wird die Zielsetzung und der Erstellungsprozess eines solchen IAM-Services illustriert:

Typischerweise entsteht der Bedarf für die selbstständige Anlage neuer Geschäftsrollen aus dem Umstand, dass Fachbereiche neue Applikationen einführen, Tätigkeitsfelder sich verändern, oder bisher ungenutzte Funktionalitäten von bestehenden Anwendungssystemen verwendet werden sollen. Klassischerweise kommuniziert der Fachbereich eine textuelle Beschreibung der neuen Anforderung an das IAM-Team und in aufwändiger und intensiver Zusammenarbeit erstellt das Rollenmodellierungsteam eine neue, für den Fachbereich passende, Geschäftsrolle. Anhand eines von den Modellierungsteams in der IT für den Fachbereich maßgeschneiderten Rollenerstellungs-Self-Service, kann dieser Prozess signifikant verschlankt und beschleunigt werden.  

Die Erstellung eines solchen Services mithilfe eines modernen Development Kits wie NEXIS 4 läuft typischerweise wie folgt ab: 

• Das IAM-Team definiert für den Fachbereich ein Formular, das die verständliche Erstellung einer neuen Geschäftsrolle ermöglicht. Dabei kann das IAM-Team bei der Konfiguration schon sicherstellen, dass Richtlinien des Geschäftsrollenmodells eingehalten werden, etwa der Rollenname und die Beschreibung vorgegebenen Konventionen folgen, und dass Pflichtattribute ausgefüllt werden.  
• Eine Selektionskomponente für Berechtigungen der Geschäftsrollen wird so vorkonfiguriert, dass nur genau die Berechtigungen zur Verfügung gestellt werden, die tatsächlich für die Rollenaufnahme in Frage kommen. Von Unternehmen wird vor allem als Vereinfachung wahrgenommen, dass nicht aus einer sehr großen Menge an schwer verständlichen Berechtigungen ausgewählt werden muss, sondern dass dem Endanwender fachlich verständliche Gruppierungen von Berechtigungen samt Zusatzinformationen bereitgestellt werden.
• Nach der Definition des Formulars und der Funktionen zur Berechtigungsergänzung, wird der gewünschte nachgelagerte Workflow konfiguriert. In einem interaktiven und grafischen Work-flow-Editor kann für den Fachbereich transparent das 4-Augen-Prinzip zur Erstellung und Genehmigung des Antrags durch Verantwortliche konfiguriert werden. Ein qualitätssichernder Schritt durch die Rollenkoordinationsstelle ist empfehlenswert und kann über weitere Knoten im Workflow realisiert werden. Eskalationsschritte, die den Prozess bei Nichtbearbeitung durch Stakeholder vorantreiben sollen, können ebenfalls hinterlegt werden. 
• Abschließend wird der Service in einem benutzerfreundlichen Dashboard für den Fachbereich eingebettet und bereitgestellt. 

  Während in klassischen Systemen die Schritte der Formularerstellung, Work-flow-Konfiguration und Anwenderkonfiguration zeitintensive und isolierte Tätigkeiten sind, kann – durch moderne IAM Development Kits wie NEXIS4 – die Erstellung eines solchen Services interaktiv, gemeinsam und für den Fachbereich verständlich vollzogen werden. Dies sichert einerseits die Integration von Stakeholder-Anforderungen und andererseits schafft es Verständnis für die Funktionsweise des produktiven Service. Nach dem der Service durch Pilot-Anwender  getestet wurde, kann er auf der Produktiv-Umgebung aktiviert werden.

  Bild 2: IAM-Service in der Workflow-Ansicht des Development Kits von NEXIS 4. Quelle: Nexis

Bild 3: Dashboard in NEXIS 4 mit publiziertem IAM-Service zur Rollenerstellung. Quelle: Nexis

Trend zur De-Zentralisierung des IAM

Viele Compliance-Anforderungen verlangen die klare Verankerung der Verantwortlichkeit und damit die Mitwirkung von verantwortlichen Personen in den verschiedensten Berechtigungsprozessen. Weiterhin wird der Trend, außenwirksam und endanwenderfreundlich Teilfunktionen in die Fachbereiche zu verlagern,  durch das größere Einsatzspektrum und die Bedeutungszunahme von IAM-Systemen verstärkt. Dies drängt IAM-Teams dazu, immer schneller auf sich wechselnde Anforderungen zu reagieren, was mithilfe der klassischerweise zur Verfügung stehenden Techniken kaum möglich ist. Es zeigt sich, dass schnell einsetzbare und leicht konfigurierbare IAM Tools eingesetzt werden müssen, um mit diesen Entwicklungen Schritt zu halten. NEXIS 4 als IAG-Plattform wird entwickelt, um diese Dezentralisierung von IAM-Funktionalitäten innerhalb von Unternehmen erfolgreich weiterzutreiben.  

Neben der technischen Umsetzung ist der organisatorische Wandel und die Ausrichtung des IAM-Teams ein wichtiger Erfolgsfaktor, um von den Benefits einer dezentralen IAM-Struktur zu profitieren. Klassische Tätigkeiten wie die operative Vergabe und die Administration von Berechtigungsstrukturen sowie die Umsetzung von Hintergrundprozessen werden zukünftig eine untergeordnete Rolle für IAM-Teams spielen. Vielmehr müssen sie sich selbst als Dienstleister für den Fachbereich verstehen, der flexibel  und dynamisch auf neue Anforderungen  reagieren kann.