Seit einigen Jahren sind diverse etablierte Lösungen, darunter BMCs Control-SA oder SUNs Identity Manager, aus unterschiedlichen Gründen nicht mehr am Markt präsent. Für Bestandskunden solcher Systeme zählt vorrangig, die eingestellte Lösung durch ein neues System abzulösen. Zahlreiche Anbieter versprechen hier eine reibungslose Migration von der installierten Altlösung auf ihre Plattform.
Foto: andrey_I - shutterstock.com
Häufig werben Unternehmen mit speziellen Tools, mit denen sich die aktuellen Datenkonfigurationen einfach und ohne großen Aufwand automatisch konvertieren und in die neue Umgebung übertragen lassen. Erfahrungsgemäß ist eine IAM-Systemmigration jedoch vom zeitlichen Rahmen mit dem Umzug in eine neue Wohnung vergleichbar. Um bei diesem Beispiel zu bleiben: Wäre es tatsächlich empfehlenswert, dass die Umzugsfirma die Möbel ohne vorherige Absprache und ohne Anweisungen im neuen Zuhause aufstellt - ausgehend vom Grundriss der alten Wohnung?
Auf Veranstaltungen wie der European Identity & Cloud Conference (EIC), dem Gartner Identity & Access Management Summit (IAM) in London sowie ähnlichen Konferenzen sprechen sich zahlreiche Experten dagegen aus, ein altes IAM-System auf Grundlage einer neuen Technologie schlicht 1:1 abzubilden.
Es ist davon auszugehen, dass das Altsystem - daher auch der Name - voraussichtlich vor zehn Jahren oder noch früher entwickelt wurde. Für IAM-Projekte dieser Art ist typisch, dass diesen eine funktionale Spezifikation zum damaligen Stand der Technik zu Grunde liegt.
Meist handelte es sich außerdem um das allererste IAM-System im Unternehmen, so dass vermutlich zum damaligen Zeitpunkt die IAM-Erfahrung im Unternehmen sehr begrenzt war. Berücksichtigt man diese Aspekte so wird deutlich, dass vor einer Migration unbedingt eine Analyse und darauf basierend eine Neugestaltung des IAM-Systems - wo nötig - stehen sollte. Denn in der Regel führt eine fundierte Analyse der unterschiedlichen IAM-Aspekte zu dem Ergebnis, dass es praktisch keinen Bereich gibt, der sich im Laufe der Jahre nicht verändert hat.
Datenmodell
Auf den ersten Blick sind die vielen Veränderungen seit der letzten (sprich ersten) IAM-Generation schwer auszumachen: Identitäten, Rollen, Gruppen und Systeme. Die Datenstruktur der bisherigen IAM-Lösung scheint noch korrekt zu sein, was den Anschein fördert, die vorhandene Datenbasis automatisch extrahieren und ins neue System übertragen zu können. Grundsätzlich ist dieser Ansatz der Migration nicht völlig falsch.
Allerdings sollte im Detail betrachtet werden, wie und in welchem Umfang Access Governance seine Spuren im Datenmodell hinterlassen hat.
Seit IAM auch verstärkt Einzug in die Abteilungsebene hält, sollte ein IAM-System diverse zusätzliche Informationen speichern und verarbeiten. Daher ist es umso wichtiger, die unterschiedlichen Identitätsarten sauber zu trennen: Mitarbeiter, Freischaffende, Kunden, technische Identitäten und so weiter. Zu der Zeit, als die erste IAM-Generation entwickelt wurde, gab es praktisch nur betriebsinterne Benutzer.
Heute ist das sogenannte IAM-Universum um Trends wie Cloud Computing oder IoT erweitert, so dass gänzlich neue Identitäten entstehen, die das alte Modell nicht berücksichtigt. Vor diesem Hintergrund sollten Unternehmen, die auf ein neues IAM-System aufrüsten möchten, genau prüfen, ob das gewählte System alle derzeit relevanten Identitätsarten abbilden und entsprechend ihrer individuellen Profile verarbeiten kann.
Darüber hinaus haben die Daten- und Reportingpfade der Unternehmensorganisation im letzten Jahrzehnt beständig an Bedeutung gewonnen.
Während sich die ersten IAM-Systeme noch darauf beschränkten, simple Organisationsstrukturen in Form eines Verzeichnisbaums zu verwalten, müssen moderne IAM-Systeme zwischenzeitlich in der Lage sein, zwischen verschiedenen Verantwortlichen je nach Anwendungsfall zu differenzieren.
Die Vergabe von Zugriffsrechten findet zudem immer mehr auf Projektebene statt und nicht nur, wie früher, rein auf Grundlage der organisatorischen Zugehörigkeit.
Aufgrund dieser veränderten Datenstruktur sollten Unternehmen, bei denen ein IAM-Systemwechsel ansteht, zunächst das eigene IAM-Konzept einer genauen Analyse unterziehen. Viele Anbieter verfügen über das technische Know-how, um die Migration des vorhandenen Datenbestands in eine neue Systemumgebung automatisch oder teilautomatisiert durchzuführen. Wenn Unternehmen vor der Migration ihre Anforderungen aber nicht neu bewerten und prüfen, erweist sich die neue IAM-Lösung allzu leicht als ebenso sperrig und eingeschränkt wie das Altsystem, wenn auch auf einem technologisch modernem Fundament.
Daher müssen Unternehmen sich darüber im Klaren sein, dass ein Migrationsprojekt eine gründliche Neubetrachtung des Ist- und Sollstands erfordert. Positiv betrachtet stellt dies eine gute Gelegenheit dar, sinnvolle und nötige Strukturen einzuführen. Hierzu zählen klassische Fragen wie "von wo werden die (neuen) Daten bezogen" oder "wie ist der Prozess/Reportingpfad in der Organisation für einen konkreten Ablauf gestaltet"? Unter Berücksichtigung eines derart erweiterten Datenmodells verschwinden die Grenzen zwischen einem IAM-Upgrade und der kompletten Neueinführung eines IAM-Systems.
Unterstützte Zielsysteme
IAM-Systeme haben traditionell die Aufgabe, Zugriffsrechte auf IT-Systeme und Plattformen im Unternehmen zu verwalten. Daher ist der Ansatz richtig, bei der Auswahl einer Lösung sehr genau auf die gebotenen Bereitstellungsfunktionen zu achten. Kriterien wie die Verfügbarkeit von Standardschnittstellen zu allen relevanten Plattformen sind ein guter Indikator für ein sauberes und reibungsloses Update.
Bei der Ablösung eines alten Systems durch ein neues sind jedoch auch weitere Faktoren zu beachten. In diesem Kontext wird das Thema Datenabgleich gerne unterschätzt. Dabei hängt jedes IAM-Konzept von der Fähigkeit des Systems ab, Daten in den Zielsystemen und dem IAM-Repository regelmäßig synchronisieren zu können. Die damit einhergehende Frage, welches System führend sein soll - das IAM-System oder das Zielsystem -, lässt sich nur im konkreten Anwendungsfall beantworten. Somit ist eine IAM-Lösung gefragt, mit der sich im Detail konfigurieren lässt, welche Datenfelder von welchem System führend verwaltet werden. Und nicht zu vergessen die Möglichkeit der bidirektionalen Kommunikation über alle Konnektoren.
Workflows
In kaum einem anderen IAM-Bereich klaffen die ursprüngliche Erwartung eines Unternehmens an eine automatisierte Migration und die tatsächliche Realität so weit auseinander wie hier. Häufig sind auf der Suche nach einer passenden IAM-Lösung Produkte gefragt, die Workflow-Notationen wie BPMN unterstützen. Hinter dieser Frage steht die Erwartung, dass die Unterstützung solcher Standards die Migration der bestehenden Workflowlösung deutlich vereinfacht.
Aber zunächst einmal muss bei Workflow-Lösungen zwischen dem Prozess und der Benutzerschnittstelle unterschieden werden. Der allgemeine Prozess ließe sich unter Zuhilfenahme dieser Standards zwar migrieren, auf die Benutzerschnittstelle ist dies jedoch nicht anwendbar. Selbst prozessseitig gibt es viele Workflow-Aspekte, welche die Prozessbeschreibung nicht abdeckt.
Führungsstrukturen, Vertretungen, Delegierungen oder Eskalationen lassen sich in Standardnotationen nur schwer oder gar nicht ausdrücken. Außerdem müssen häufig Prozesse in BPMN-ähnlicher Notation präzise definiert und manuell implementiert werden. Zweifelsohne erleichtert solch ein abstraktes Prozessmodell die Migration vorhandener Workflows, aber es ist ein Irrglaube, dass sich dieser Vorgang ohne weiteren Aufwand automatisieren lässt.
Was die Migration von Benutzerschnittstellen betrifft, so ist es noch unwahrscheinlicher, dass das neue System auf einer vorhandenen Implementierung aufsetzen kann. Die Erfahrung zeigt: Der Ansatz "wir bilden mit den neuen Workflows einfach die bestehenden Strukturen ab" entpuppt sich als kostspielige Strategie. Unternehmen sind darauf angewiesen, dass die Anwender die neuen Schnittstellen und Prozesse auch annehmen. Aus diesem Grund möchten sie häufig das bisherige Look & Feel 1:1 umzusetzen.
Hier stellt sich erneut die Frage, ob dies tatsächlich ein erfolgsversprechender Ansatz ist. Wenn die Anschaffung eines neuen Mobiltelefons ansteht, möchte man dann wirklich die gleiche Benutzeroberfläche wie beim alten Gerät, obwohl das alte Gerät vermutlich gerade einmal drei Jahre alt ist? Bei IAM-Systemen reden wir sogar über einen Zeitraum von etwa 10 Jahren zwischen alter und neuer Lösung. Auf den Punkt gebracht: Die GUI des Altsystems stammt vermutlich aus der Zeit von Windows XP und der ersten Blackberry-Generation. Ist es tatsächlich empfehlenswert, die Bedienkonzepte dieser Zeit zu übernehmen? Wie nehmen dies letztendlich die Benutzer auf?
Compliance
Ein weiterer wichtiger Workflowaspekt, der heute bei der Einführung eines neuen IAM-Systems berücksichtigt werden muss, ist das Thema Compliance. Im Jahr 2005 waren die zentralen Anforderungen an ein IAM-System wenig auf Compliance ausgerichtet; vielmehr standen Effizienz und Produktivität im Vordergrund. Fraglos haben sich die Bedürfnisse in den letzten Jahren immer mehr in Richtung Compliance und Revisionssicherheit von IAM-Prozessen verlagert. Anwendungen/Workflows wie Benutzer-Rezertifizierung oder Policy-Management zählen derzeit zu den gefragtesten Funktionen einer IAM-Lösung.
Eventuell wurde das alte IAM-System bereits hinsichtlich dieser Forderungen aufgerüstet. Die meisten Altsysteme stoßen jedoch irgendwann an ihre Grenzen, sei es aus designtechnischen Gründen oder weil der technische Support mittlerweile eingestellt wurde. In jedem Fall sollten Unternehmen die eigenen Compliance-Anforderungen definieren, damit die Wahl schlussendlich auf ein Neusystem fällt, das die entsprechenden Funktionen auch unterstützt.
Fazit
Die obigen Beispiele zeigen die größte Schwäche einer schnellen und automatisierten Migration von IAM-Systemen auf: der mehr-dimensionale technische Fortschritt, der sich seit Einführung des Altsystems in allen Bereichen vollzogen hat, wird ausgeklammert. Die Unternehmensorganisation ist gegenüber früher offener geworden und damit nicht mehr ausschließlich auf das eigentliche Unternehmen begrenzt.
Ebenso hat sich die IT-Landschaft der verwalteten Zielsysteme wesentlich geändert. So sind Mobiltelefone und Tablets heute aus der Kommunikation nicht mehr wegzudenken; folglich sind die nutzerseitigen Anforderungen an Software-Tools wesentlich höher als noch vor wenigen Jahren. Die wenigsten alten IAM-Systeme können mit dieser veränderten Realität Schritt halten; auch dann nicht, wenn sie nach und nach aufgerüstet wurden. Aus diesem Grund sollte der Wechsel auf ein neues IAM-System als Gelegenheit begriffen werden, eine neue Lösung einzuführen, die heutigen und künftigen Ansprüchen entspricht. Dies setzt fraglos eine Bewertung und Neuausrichtung des IAM-Konzepts voraus. Wer ganz auf eine automatisierte und schnelle Migration setzt, steht am Ende im besten Fall mit einer lediglich "akzeptablen" Lösung da. (bw)