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)