Yes, I AM – Die Einführung von Identity & Access Management
Gerade in historisch gewachsenen Konzernen ist die IT-Landschaft häufig zerklüftet – uneinheitlich wie die verschiedenen Firmen, die zum Konzern gehören. Da werden Prozesse in den nordamerikanischen Niederlassungen vollkommen unterschiedlich zu denen der Chinesischen Kollegen interpretiert und gelebt. Auch innerhalb eines Landes begegnen die einzelnen Konzernbestandteile den gleichen Aufgabenstellungen teils auf völlig unterschiedliche Weise.
Vor dieser Herausforderung stand auch die schweizerische Franke Gruppe, als im Jahr 2012 der Entschluss gefasst wurde, sich dem Thema Prozess-Standardisierung und Sicherheit mittels Identity & Access Management zu nähern. Grundlegend sollten damit die Prozesse während des Mitarbeiter-Lebenszyklus zum einen global einheitlich und zum anderen transparent und historisierbar gestaltet werden. Darüber hinaus stellte sich Identity & Access Management als die Antwort auf die drängend gewordene Frage dar, wie der wachsenden Zahl von Cloud-, und damit dem direkten Zugriff der konzerneigenen IT entzogenen, Systemen zu begegnen sei. Dieser Artikel fasst die Entstehungsgeschichte der ersten Iteration von Identity and Access Management innerhalb der Franke zusammen und soll aufzeigen, welche Hürden im Verlauf auftauchen können.
Vorüberlegungen – das Projekt vor dem Projekt
Identity & Access Management ist ein häufig genutztes Schlagwort – laut IT Trends seit Jahren eines der Top-IT-Themen auf der Roadmap großer und mittlerer Unternehmen. Doch was verbirgt sich tatsächlich dahinter? Der Begriff erweist sich bei näherer Betrachtung als sehr vielschichtig und lädt zu höchst unterschiedlichen Interpretationen ein. Bei der Beantwortung der Frage, was Franke darunter versteht und wie eine Implementierung aussehen kann, wurde in einem Vorprojekt das Thema ausführlich auseinandergenommen und für die Firma passend wieder zusammengesetzt. Im Ergebnis stand ein Grobkonzept und ein deutlich gesteigertes Verständnis von IAM bei den unmittelbar beteiligten Projektmitgliedern.
Mittels des Grobkonzepts wurden folgende Definitionen für das anschließende Implementierungsprojekt getroffen:
- In der ersten Ausbaustufe sollten die zentralen Systeme, welche von Corporate IS angeboten werden, an den Identity Manager angebunden werden:
- Active Directory
- Lotus Notes
- Google Apps for Business, welches parallel in einem zweiten Projekt zur Einführung kam - Die einzuführende Lösung sollte den kompletten Mitarbeiter-Lebenszyklus abdecken sowie die Stammdaten für die Nutzeraccounts zentral bereithalten:
- Eintritt
- Unternehmenswechsel
- Austritt - Berechtigungen sollten zu etwa 80% automatisch aus der Organisationsstruktur oder Funktionen innerhalb des Unternehmens resultieren.
Für die langfristige Planung wurden SAP und andere innerhalb des Konzerns im Einsatz befindliche ERP-Systeme sowie das globale Talent Management System zur Anbindung identifiziert.
Mithilfe der neu einzuführenden Lösung sollte zusätzlich ein zehn Jahre altes, eigenentwickeltes System zum Management der Active Directory abgelöst werden sowie für manuelle Aufgaben das im Einsatz befindliche ITSM-Tool Service-Now genutzt werden.
Dies waren die Startbedingungen, womit eine dreimonatige Phase der Lieferantenauswahl begann. Schlussendlich fiel die Entscheidung für den Quest One Identity Manager von Quest Software, mittlerweile Dell.
Implementierung
Entsprechend der Projektplanung begann im August der erste Anlauf mit Blick darauf, zunächst Google Apps anzubinden. Da hier zeitliche Abhängigkeiten zum parallel verlaufenden Projekt bestanden, genoss Google die höchste Priorität. Leider wurde zu dieser Zeit seitens Google die API grundlegend geändert, wobei die vom Identity Manager genutzte Provisioning API abgekündigt und komplett durch das neue Admin SDK abgelöst werden sollte. Auch mit viel Anstrengung gelang es nicht, den bestehenden Connector auf die Gegebenheiten anzupassen. So war es mit der alten API beispielsweise nicht möglich, unterschiedliche Domains zu verwalten und als zusammengehörig zu behandeln. Diese und weitere Unzulänglichkeiten führten schließlich zu einer grundlegenden Neuentwicklung des Connectors mit dem Admin SDK seitens Dell.
Während der Neuentwicklung des Connectors erlebte die Projektumsetzung einen vollständigen Neustart Ende Oktober, dessen Ziel es war, die Anbindung von Active Directory und Lotus Notes bis Ende Dezember zu implementieren.
Erkenntnis I: Fachbereiche verknüpfen
Die erste wichtige Erkenntnis auf dem Weg zum Ziel beinhaltet die immense Wichtigkeit, fachbereichsübergreifend zu denken und die notwendigen Fachgebiete auf einen gemeinsamen Nenner zu bringen. Was zunächst klingt wie eine Binsenweisheit – natürlich muss man in einem Projekt, welches die unterschiedlichen Zielsysteme unter einem Dach vereinen soll, die Fachbereiche berücksichtigen – stellte sich schnell als ungeheuer bedeutend heraus. Jedes Zielsystem für sich betrachtet ist in seiner Komplexität noch überschaubar. Natürlich gibt es lokale Besonderheiten, die es aufzulösen gilt, wenn beispielsweise die Europäischen Kollegen einen Account so schnell wie möglich deaktiviert haben wollen, die Amerikaner hingegen noch einige Zeit einen aktiven, jedoch für den verlassenden Mitarbeiter unzugänglichen Account benötigen, um Homedrives und ähnliches zu sichern und zu verschieben. Die Komplexität steigt jedoch rasant, wenn diese Abstimmungen systemübergreifend betrachtet werden.
Dabei ist es notwendig, nicht nur die fachlichen Anforderungen der Fachbereiche zu verstehen und zu implementieren, sondern ebenso, den Mind Change zu vermitteln, der mit der Einführung von Identity & Access Management einhergeht. Im Falle der Franke Gruppe war dieser Mind Change gravierend: bislang waren es die lokalen Service Desks gewohnt, sich innerhalb des von Corporate abgesteckten Rahmens relativ frei entfalten zu können. Die Einführung des Identity Managers bedeutete jedoch, einige dieser Freiheiten aufgeben und über eine neue Struktur generell nachdenken zu müssen. Wurden bislang Accounts in einem Zielsystem angelegt, bearbeitet und mit Berechtigungen ausgestattet, so war nun ein Umdenken notwendig: Künftig findet die Account-Anlage, -Manipulation sowie die Berechtigungsvergabe zentralisiert in einer übergeordneten Schicht statt. An einem zentralen Personen-Objekt werden dabei die Einstellungen vorgenommen, welche sich dann auf die zugehörigen Accounts niederschlagen. Auf Berechtigungsseite wurde im Active Directory bislang innerhalb lokaler Container gearbeitet, wobei Gruppenmitgliedschaften nahezu frei, auch Container-übergreifend, vergeben werden konnten. Nun ist es notwendig, den Bestellprozess zu verstehen, der lokal zwar nach wie vor ermöglicht, alle Mitarbeiter zu behandeln, die im eigenen Verantwortungsbereich liegen, der es jedoch notwendig macht, das Sortiment des Shops, also die zur Verfügung stehenden Berechtigungen, durch die Brille dessen zu betrachten, für den eine Berechtigung bestellt oder abbestellt werden soll. Damit steht naturgemäß nicht mehr jede Möglichkeit zur Verfügung, die bislang zur Verfügung gestanden hat.
Besonders komplex wurde die Einführung von Identity & Access Management durch das erklärte Ziel, von Beginn an Human Ressources und Information Services in die Kernprozesse einzubinden. Diese Anordnung führte zu einer grundlegenden Änderung der Abläufe: bislang konnten HR und IS relativ autark arbeiten, in einigen Firmen stärker, in anderen weniger stark vernetzt. Nun führt die Einführung des Identity Managers dazu, dass die maßgeblichen Prozesse zwangsläufig beide Seiten einbeziehen. Nur so konnte erreicht werden, die Verantwortlichkeiten an die richtigen Stellen zu verschieben, statt wie bisher die IT-Seite nur IS und die Personalseite nur HR zu überlassen. Künftig gibt es global einheitliche Prozesse, die in aller Regel von HR ausgelöst werden (Major Changes auf Seiten des Personenobjektes wie bspw. Namensänderung, vorübergehende Deaktivierung oder Firmenwechsel) und IS zur weiteren Bearbeitung übergeben werden. IS hingegen kümmert sich um die Berechtigungsseite, wobei die notwendigen Prozesse angestoßen und die Approval Workflows ausgelöst werden, sowie die Verantwortung über die Entscheidung, welcher Mitarbeiter welche Berechtigungen tatsächlich erhalten sollte, vermehrt auf die tatsächlichen Entscheider verlagert wird.
Erkenntnis II: Neutraler Blick notwendig
Die Einführung von Identity & Access Management führte – auf der ersten Erkenntnis basierend – zur zweiten wichtigen Erkenntnis: in diesem Themengebiet ist es von großem Vorteil, einen weitestgehend neutralen, fast schon externen, Blickwinkel beizubehalten. Bei der Arbeit in einem solchen Projekt hat das Projektteam es mit einer sehr heterogenen, großen Gruppe an Stakeholdern zu tun. Dabei hat jeder Stakeholder oder jede Gruppe von Stakeholdern ihre eigenen Erwartungen und Vorstellungen von einem Identity Manager. Noch gravierender stellt sich der Umstand dar, dass mit der Einführung des Identity Manager bereits bestehende und genutzte Prozesse abgelöst und standardisiert werden. Damit geht häufig eine teilweise grundlegende Änderung der Arbeitsweise für die Key User einher, welche sich dementsprechend in ihrem Verhalten anpassen und umstellen müssen.
Grundlegend läßt sich festhalten, dass es unmöglich sein wird, allen Erwartungen der Stakeholder entsprechen zu können. Dabei erweist es sich als nützlich, wenn nicht gar unabdingbar, in der Rolle des neutralen Vermittlers den besten Mittelweg zu finden. Immer unbedingt notwendig ist dann natürlich die entsprechende Kommunikation in Richtung der Stakeholder und Key User. Daher wurde in diesem Projekt großer Wert darauf gelegt, bereits während der abschließenden Tests die künftigen Key User auf die Einführung des Identity Managers einzustimmen. Aufgrund der begrenzten Projektkapazitäten geschah dies in insgesamt 31 Web Sessions für 160 Key User weltweit noch vor dem Go-Live. In weiteren 28 Trainings und Hands-On Sessions wurden die Key User auch nach dem Go-Live bestmöglich unterstützt. Insgesamt zeigte sich jedoch auch hier, dass das persönliche Training zu bevorzugen ist.
Neutralität erweist sich ebenso als hilfreich bei der Konzentration auf das Wesentliche: so wurde bei der Einführung des Identity Manager bei der Franke Gruppe Wert darauf gelegt, vor allem funktional und prozessseitig die Anforderungen zu erfüllen. In diesem schlanken Projekt-Setup wurde bewusst darauf verzichtet, besondere Designs für das Web-Frontend zu entwerfen oder jeden wünschenswerten, jedoch nicht zwingend erforderlichen Prozess ins letzte Detail auszugestalten und zu implementieren. Vielmehr wird ausgehend von der Basisfunktionalität in enger Zusammenarbeit mit den täglichen Nutzern des Systems die weitere Entwicklung vorangetrieben, sodass schnellstmöglich neue Iterationen eingeführt werden können und das System sich mit seinen Nutzern und entsprechend deren Vorstellungen weiter entwickeln kann.
Erkenntnis III: Kenne Dein Tool
Im Bereich des Identity & Access Management gibt es eine Vielzahl an Software-Anbietern sowie eine mindestens ebenso große Zahl an Partnern und Consultants, die Hilfe und Unterstützung bei der Implementierung versprechen. Diese Hilfe wird auch dringend benötigt, denn in einem solchen IAM Projekt ist relativ schnell ein Punkt erreicht, an dem die Komplexität nahezu überwältigend erscheinen kann. An diesem Punkt kann nur ein erfahrener Consultant weiterhelfen, der die richtigen Fragen stellt und hilft, das Wesentliche im Auge zu behalten. In diesem Punkt wurde Franke vom Dell-Partner Devoteam GmbH hervorragend unterstützt.
Ungeachtet dieser wertvollen Unterstützung ist es unabdingbar, auch internes Know-How zum Tool aufzubauen. Letztendlich geht es bei der Einführung von Identity & Access Management, so wie sie bei Franke angegangen wurde, doch darum, für eine Vielzahl von unterschiedlichen Systemen, jedes davon wiederum mit einer Vielzahl unterschiedlicher Prozesse, einen einheitlichen Umgang zu finden, der global standardisiert werden kann, die System-spezifischen Erfordernisse berücksichtigt und die Key User nicht vollständig überfordert. Dafür ist selbstverständlich die Kenntnis der genutzten Systeme (siehe Erkenntnis I) notwendig, sowie die Fähigkeit, weitgehend neutral Prozesse zu vereinheitlichen und zu standardisieren (siehe Erkenntnis II). Darüber hinaus hat es sich als besonders hilfreich erwiesen, innerhalb des Projektteams ein eigenes Verständnis für den Identity Manager aufzubauen. Nur so konnten die praktischen Anforderungen, die sich aus den Zielsystemen ergaben und von den Stakeholdern des Projekts formuliert wurden, mit den Möglichkeiten des Systems in Einklang gebracht werden. Vor allem hilft das interne Know-How ungemein, den effizienten Mittelweg zu erkennen, beispielsweise einen neuen Standard mithilfe der vom System angebotenen Funktionalitäten lieber nur zu 90% abzubilden und die fehlenden 10% in die Trainingsmaßnahmen aufzunehmen, als die 100%-Lösung aufwendig und von Grund auf neu zu implementieren.
Selbstverständlich liegt die Hauptlast der Implementierung, vor allem in den ersten Projektphasen, beim Partner bzw. Anbieter, jedoch schützt der Aufbau zusätzlichen eigenen Know-Hows zuverlässig davor, sich in diesem wichtigen Thema vollständig von externer Hilfe abhängig zu machen. Immerhin ist ein Identity & Access Management-System mittel- und langfristig in der Lage, die komplette IT-Infrastruktur eines Unternehmens zu steuern – die vollständige Abhängigkeit von Systempartnern sollte daher unbedingt vermieden werden.
Drei Erkenntnisse bei der Implementierung
- Fachbereiche verknüpfen
- Neutraler Blick notwendig
- Kenne Dein Tool
Fazit
Zusammenfassend lässt sich sagen, dass die vorgenannten drei Erkenntnisse natürlich nur ein Bruchteil der insgesamt gesammelten Erfahrungen darstellt, sozusagen einen Blick durchs Schlüsselloch bei der Einführung des Identity Managers in der Franke Gruppe. Nichtsdestotrotz haben auch und gerade diese Erkenntnisse dazu beigetragen, dass nach einer Entwicklungszeit von gerade einmal zweieinhalb Monaten sowie einer anschließenden einmonatigen Vorbereitung auf den Livegang bereits dreieinhalb Monate nach dem Neustart des Projektes Anfang Oktober der Betrieb aufgenommen werden konnte. Zum Start wurden bereits 85% aller Active Directory und Lotus Notes User Accounts vollständig vom Identity Manager verwaltet.
Dabei hat die Einführung des neuen Tools selbstverständlich nicht nur Begeisterungsstürme bei den Key Usern entfacht: es war und ist nach wie vor immens wichtig, eng mit diesen zusammenzuarbeiten und Kritik als wichtiges Feedback für die kontinuierliche Weiterentwicklung zu verstehen. Die drei wichtigsten Erkenntnisse, welche hier aufgeführt werden, lassen sich für künftige Projekte in folgende Empfehlungen übersetzen:
Fachbereiche verknüpfen
Achten Sie unbedingt darauf, von Beginn des Projektes an alle wichtigen Stakeholder identifiziert und an Bord geholt zu haben. Machen Sie jederzeit deutlich, dass ein grundlegender Wandel stattfinden wird, der bisher gelebte Prozesse ablösen und ergänzen wird. Gehen Sie so früh wie möglich mit den einzelnen Fachbereichen in die Praxis über. Detailkonzepte sind wertvoll bei der Entwicklung von Ideen sowie hilfreich zur Dokumentation, doch häufig werden Sie die wahren Fallstricke erst beim praktischen Gang durch den Prozess erkennen.
Neutraler Blick notwendig
Sie werden es nicht allen Stakeholdern und schon gar nicht allen Usern recht machen können. Gehen Sie damit pragmatisch und lösungsorientiert um. Sorgen Sie dafür, dass Sie auf dem Weg zu neuen Standards und Abläufen niemanden zurücklassen. Dafür werden Sie viel Zeit und Energie in die Kommunikation und Trainings stecken müssen. Sichern Sie sich dafür rechtzeitig die notwendigen Ressourcen.
Kenne Dein Tool
Trainieren Sie frühzeitig Ihr Projektteam auf das einzuführende System. Schalten Sie sich aktiv in die Implementierung ein, um das praktische Know-How zu erhalten. Lernen Sie die Fachbegriffe, um mit Consultants auf Augenhöhe die beste Lösung zu entwickeln, nicht die schönste oder umfangreichste.
