So gelingt Ihr IGA-Projekt: Beginnen Sie mit Personas

Warum IGA-Projekte häufiger scheitern, als sie sollten

Identity Governance and Administration (IGA) gibt es schon lange genug, dass man eine niedrige Fehlerquote erwarten würde. Die Konzepte sind gut etabliert, die führenden Plattformen sind ausgereift, und es mangelt nicht an Menschen, die sie bereits implementiert haben. Und dennoch überschreiten Projekte weiterhin Zeitpläne, verfehlen ihren ursprünglichen Umfang oder liefern eine Lösung, die zwar funktioniert, aber nicht ganz zu dieser Organisation passt.

Die Gründe häufen sich meist um ein vertrautes Set an Themen.

Das Commitment der Führungsebene wird oft angeführt, und es spielt tatsächlich eine Rolle. Ohne Rückhalt von oben sind Projekte anfällig dafür, zurückgefahren zu werden, sobald sich Budgets verengen oder Prioritäten verschieben.

Programmziele sind ein weiterer häufiger Übeltäter: Entweder wurden die Ziele zu ambitioniert gesetzt, gemessen an dem, was die Technologie realistisch leisten kann, oder sie waren von Anfang an nie präzise genug, um messbar zu sein.

Liefertermine geraten ins Wanken, wenn die Planung zugunsten einer schnellen Präsentation vor den Stakeholdern verkürzt wird. Technologieentscheidungen scheitern, wenn die Bewertung von Anbieterdemos statt von dokumentierten Anforderungen bestimmt wird. Es ist leicht, sich von einer funktionsreichen Plattform verführen zu lassen und später festzustellen, dass ausgerechnet die tatsächlich benötigten Funktionen diejenigen waren, die die meiste Anpassung erfordern. Kosten laufen aus dem Ruder, wenn sich Anforderungen mitten in der Implementierung ändern oder wenn der Aufwand für Konfiguration und Integration von Anfang an unterschätzt wird.

All das sind reale Probleme, und über alle wurde bereits ausführlich geschrieben. Aber es gibt einen Fehlermodus, der sich still hinter mehreren der anderen verbirgt und dabei deutlich weniger Beachtung findet: Das Projekt hat nie richtig festgelegt, für wen es eigentlich gebaut wurde.

Bei den meisten IGA-Projekten, die ins Stocken geraten, lässt sich zumindest ein Teil des Problems auf Annahmen zurückführen, die früh im Projekt über die Arten von Nutzern, Identitäten und Zugriffsszenarien getroffen wurden, die die Lösung würde bewältigen müssen – Annahmen, die sich als falsch herausstellten.

Die Lösung ist nicht kompliziert, erfordert aber Disziplin. Sie bedeutet, das Projekt damit zu beginnen, ein vollständiges Bild Ihrer Identitätslandschaft zu erstellen – nicht der Technologie, nicht der Integrationen, nicht der Workflows. Nur der Menschen und Identitäten, die Ihr Governance-Programm abdecken muss. Alles Weitere ergibt sich daraus.

Der Rest dieses Artikels erklärt, wie Sie dieses Bild Ihrer Landschaft erstellen und warum dies einen größeren Unterschied macht, als die meisten Organisationen erwarten.

Sie beschäftigen sich also mit Identity Governance

Die Technologie selbst ist selten der Grund, warum IGA-Projekte ins Straucheln geraten: Die eigentliche Ursache ist fast immer, mit einem Produkt zu beginnen, statt die eigenen Mitarbeiter zu verstehen.

Egal, ob Sie gebeten wurden, eine IGA-Plattform zu bewerten, oder bereits mitten im Projekt stecken und die Dinge komplizierter werden – Sie haben wahrscheinlich bemerkt, dass die Technologie meist nicht der schwierige Teil ist.

IGA-Plattformen (die Software, die steuert, wer worauf Zugriff erhält, Onboarding und Offboarding automatisiert und sicherstellt, dass jemand diese Zugriffsrechte regelmäßig überprüft) sind ausgereift, gut verstanden und breit einsetzbar. Die meisten führenden Plattformen bewältigen die Kernanwendungsfälle ohne größere Probleme.

Warum also überschreiten so viele IGA-Projekte ihr Budget, dauern länger als erwartet oder enden mit einer Lösung, die nicht ganz passt?

Unserer Erfahrung nach liegt es fast immer an derselben Ursache: Die Organisation hat damit begonnen, ein Produkt auszuwählen, statt ihre Mitarbeiter zu verstehen.

Das Wertvollste, was Sie tun können, bevor Sie auch nur einen einzigen Anbieter bewerten, ist zu verstehen, wer tatsächlich in Ihrer Organisation arbeitet und wie deren Beziehung zur Identität aussieht.

Es ist nicht so einfach wie „Mitarbeiter rein, Mitarbeiter raus"

An der Oberfläche klingt IGA unkompliziert. Jemand tritt dem Unternehmen bei und erhält Konten. Jemand verlässt es, und diese Konten werden deaktiviert. Dazwischen prüft jemand regelmäßig, ob die Personen das, was sie besitzen, noch benötigen.

Die Realität in den meisten Organisationen ist erheblich unübersichtlicher. Betrachten Sie einige der Fragen, die typischerweise auftauchen, sobald ein Projekt läuft:

Was geschieht mit Auftragnehmern und Zeitarbeitskräften – tauchen sie in Ihrem HR-System auf? Falls nicht, woher bezieht die IGA-Plattform ihre Daten?

Was ist mit Drittanbietern, die Zugriff auf bestimmte Systeme benötigen – wie werden sie onboardet, und wer verwaltet ihren Lebenszyklus?

Gibt es Mitarbeiter, die über mehrere Rechtsträger oder Regionen hinweg arbeiten und dabei in jedem möglicherweise andere Rollen innehaben?

Gibt es Service-Konten, gemeinsam genutzte Konten oder Maschinenidentitäten, die zusammen mit menschlichen Nutzern verwaltet werden müssen?

Was ist mit Nutzern in sensiblen Rollen – Führungskräften, Finanzteams, IT-Administratoren –, die möglicherweise strengere Kontrollen oder andere Genehmigungsprozesse benötigen?

Trägt eine Ihrer Personas Zugriffsrechte, nach denen ein Regulator oder Prüfer gezielt fragen wird, und ändert das, wie ihre Berechtigungen überprüft oder dokumentiert werden müssen?

Sollten Berechtigungen für immer bestehen bleiben, oder sollten manche Berechtigungen, insbesondere sensible, nur zeitlich befristet gelten?

Keiner dieser Fälle ist ein Randfall. In jeder Organisation mit mehr als ein paar hundert Mitarbeitern sind sie die Norm. Und wenn Ihre gewählte IGA-Plattform nicht anhand dieser Fragen bewertet wurde, werden Sie es auf die harte Tour herausfinden – meist während der Implementierung, wenn eine Kurskorrektur teuer wird.

Hier kommt die Persona ins Spiel

Im Sinne der Identity Governance ist eine Persona ein eigenständiger Nutzertyp, dessen Identitätslebenszyklus, Zugriffsanforderungen oder Datenquellen sich signifikant von anderen unterscheiden: nicht einzelne Personen, sondern Typen von Personen.

Es gibt eine Technik, die seit Jahrzehnten Teil der strukturierten Systemanalyse ist und ursprünglich aus dem Software-Engineering stammt, die perfekt geeignet ist, dieses Problem zu lösen. Sie trägt verschiedene Namen – Nutzer-Personas, Akteure, Identitätsarchetypen –, doch die Idee ist einfach.

Bevor Sie definieren, was ein System tun muss, definieren Sie zunächst alle verschiedenen Arten von Personen (und Nicht-Personen), denen das System dienen muss.

Unserer Erfahrung nach identifiziert eine mittelgroße Organisation typischerweise zwischen dreißig und fünfzig unterschiedliche Identitäts-Personas. Bei Organisationen im Gesundheitswesen, im Bildungsbereich oder im Einzelhandel kann sich diese Zahl leicht verdoppeln.

Ein paar Beispiele, um das greifbar zu machen:

Ein fest angestellter Mitarbeiter, der über Ihr HR-System eintritt, mit einem standardmäßigen Onboarding-Prozess, der Genehmigung durch die Führungskraft und einem festgelegten Satz an voreingestellten Basiszugriffsrechten.

Ein über eine Agentur vermittelter Auftragnehmer, dessen Datensatz statt im HR-System in einer Tabelle oder einem Lieferantenportal geführt wird, und der möglicherweise gleichzeitig für mehrere Kunden arbeitet.

Ein Student oder Praktikant mit befristetem Engagement und einem Zugriff, der zum Ende des Praktikums sauber ablaufen muss.

Ein privilegierter IT-Nutzer, der administrative Konten innehat, die erhöhte Kontrolle, Trennungsmaßnahmen und möglicherweise Just-in-Time-Zugriff statt dauerhafter Berechtigungen benötigen.

Eine nichtmenschliche Identität, etwa ein Anwendungsdienstkonto oder eine API-Integration, die Berechtigungen besitzt, verwaltet werden muss und definitiv kein Self-Service-Zugriffsantragsformular ausfüllen wird.

Jede dieser Personas wird anders mit Ihrer IGA-Plattform interagieren. Manche werden automatisch aus einem Quellsystem onboardet. Andere benötigen manuelle Prozesse oder alternative Datenquellen. Manche benötigen spezialisierte Genehmigungsketten, andere benötigen einen planmäßig ablaufenden Zugriff.

Warum das für die Plattformauswahl wichtig ist

Sobald Sie Ihre Personas-Liste haben, schreiben sich Ihre Anforderungen fast von selbst.

Sie hören auf zu fragen: „Unterstützt diese Plattform Joiner/Mover/Leaver?" (alle sagen Ja) und beginnen, viel gezieltere Fragen zu stellen:

Kann sie Identitätsdaten aus mehreren Quellen wie HRIS, Tabellen, LDAP und SCIM-Endpunkten aufnehmen und zu einem einzigen Identitätsdatensatz zusammenführen?

Kann sie Identitäten handhaben, die überhaupt keinen HR-Datensatz haben, über einen separaten Onboarding-Workflow?

Kann sie unterschiedlichen Nutzertypen unterschiedliche Governance-Richtlinien zuweisen, sodass Ihre Auftragnehmer einen 90-tägigen Zugriffsüberprüfungszyklus erhalten, während Ihre privilegierten Nutzer monatlich überprüft werden?

Kann sie, wenn jemand die Rolle wechselt, das Delta berechnen und die richtigen Dinge bereitstellen oder entziehen, ohne menschliches Eingreifen und ohne verwaiste Berechtigungen zu erzeugen?

Kann sie melden, wenn jemand eine Kombination von Zugriffsrechten anhäuft, die ein Risiko darstellt, selbst wenn jedes einzelne Recht bei der Vergabe harmlos erschien? Kann sie einem Prüfer zeigen, warum der Zugriff jeder Persona genehmigt wurde und von wem, in einem Überprüfungsrhythmus, der dem Risiko dieser Persona entspricht?

Eine gut konzipierte IGA-Plattform sollte all dies leisten können. Die Persona-Übung zeigt Ihnen, welche dieser Fähigkeiten für Ihre Organisation wirklich entscheidend sind und welche nur „nice-to-have" sind.

Sie zeigt Ihnen auch, was Sie sich bei der Anbieterbewertung vorführen lassen sollten. Statt sich eine generische Produktvorführung anzusehen, können Sie dem Anbieter einen Satz von Personas an die Hand geben und ihn bitten, Ihnen konkret zu zeigen, wie seine Plattform jede einzelne davon handhabt.

Die Persona-Übung verwandelt eine Anbieterbewertung von einem Funktionsvergleich in einen echten Fähigkeitstest. Es ist deutlich schwerer, eine Lücke zu verbergen, wenn Sie nach einem konkreten Szenario statt nach einer allgemeinen Fähigkeit gefragt haben.

Wie sich das in der Praxis zeigt

Bei einer gut konfigurierten IGA-Implementierung ist das Persona-Denken in der Architektur sichtbar. Verschiedene Identitätstypen durchlaufen unterschiedliche Onboarding-Pfade. Zugriff wird anhand von Rolle und Kontext zugewiesen, nicht anhand manuell gepflegter Listen. Wenn sich die Umstände einer Person ändern (eine Beförderung, eine Versetzung, eine Vertragsverlängerung), reagiert die Plattform automatisch.

Zugriffsüberprüfungen sind intelligent abgegrenzt: Die richtigen Personen überprüfen die richtigen Berechtigungen, in einem dem Risikoniveau angemessenen Rhythmus. Entdeckt ein Prüfer etwas, das dort nicht sein sollte, erfolgt die Entfernung automatisch und nachvollziehbar. Wird dringend Zugriff benötigt, gibt es einen Anfrage-und-Genehmigungs-Workflow, der eine klare Spur hinterlässt.

Sensible Zugriffskombinationen (etwa die Fähigkeit, eine Bestellung sowohl auszulösen als auch zu genehmigen) werden proaktiv identifiziert, nicht erst bei einem Audit entdeckt. Ausnahmen werden mit Aufsicht verwaltet, statt sich still anzuhäufen.

Nichts davon erfordert eine besonders exotische Plattform. Was es erfordert, ist, dass sich jemand früh im Projekt die Zeit genommen hat zu verstehen, welche Arten von Menschen und Identitäten die Organisation tatsächlich hat, und die Lösung um sie herum konzipiert hat.

Der Nutzen zeigt sich überall dort, wo Zugriff das Geschäft berührt: Berechtigungen bewegen sich schneller, weil sie kein manuelles Eingreifen benötigen, sie sind präziser, weil sie an Kontext statt an statische Listen gebunden sind, und Compliance hört auf, eine Hetzjagd zu sein, weil die Nachweise während der Arbeit erfasst wurden und nicht nachträglich rekonstruiert werden mussten.

Der praktische Zusatznutzen

Abgesehen davon, dass sie den Erfolg Ihres IGA-Projekts wahrscheinlicher macht, hat die Persona-Übung ein paar nützliche Nebeneffekte.

Sie nützt auch anderen Projekten. Identität betrifft in einer Organisation praktisch alles. Ihre Personas-Liste wird ebenso nützlich sein, wenn Sie Privileged Account Management (PAM)-Lösungen, Endpoint-Management-Tools oder alles andere bewerten, das wissen muss, wer Ihre Nutzer sind und was sie tun.

Sie erleichtert Gespräche mit Stakeholdern. Wenn Sie auf „die Auftragnehmer-Persona" oder „die Persona des privilegierten Administrators" verweisen können, statt eine abstrakte technische Anforderung zu beschreiben, wird das Gespräch konkreter. Business-Stakeholder verstehen Personas auf eine Weise, wie sie Berechtigungsschemata nicht immer verstehen.

Sie liefert einen natürlichen Input für die Projektgovernance. Wenn Sie eine RACI-Matrix (Responsible, Accountable, Consulted, Informed) zur Steuerung der Projektverantwortlichkeiten nutzen, liefert Ihnen Ihre Personas-Liste das Rohmaterial. Hinter jeder Persona stehen ein fachlicher Eigentümer, ein technischer Verantwortlicher und eine Reihe von Stakeholdern, die alle konsultiert, informiert oder direkt einbezogen werden müssen.

Wo eine Plattform wie Netwrix Identity Manager ins Bild passt

Nichts davon ist ein Grund, die Auswahl einer Plattform hinauszuzögern. Es ist ein Grund, eine zu wählen, die so konzipiert ist, dass sie im Sinne Ihrer Personas-Liste arbeitet, nicht gegen sie.

Netwrix Identity Manager verwaltet interne, externe, Gast-, technische, IoT- und KI-Agenten-Identitäten nach demselben Modell, sodass ein über eine Tabelle bezogener Auftragnehmer, ein Dienstkonto, von dem niemand in der HR-Abteilung je gehört hat, ein KI-Agent, der seinen eigenen Zugriff bereitstellt, und ein fest angestellter Mitarbeiter, der über Ihren HR-Feed eintritt, alle dieselbe Lebenszyklus-Disziplin erhalten, statt vier unterschiedlicher Behelfslösungen. Identitäten von Drittanbietern und nichtmenschliche Identitäten erhalten ihren eigenen Lebenszyklus-Pfad, einschließlich zeitlich befristeten Zugriffs, der planmäßig abläuft, statt nach Ende eines Vertrags oder Einsatzes fortzubestehen. Auch das Onboarding neuer Systeme erfordert kein maßgeschneidertes Integrationsprojekt: Standard-Konnektoren decken AD, LDAP, SQL, CSV und SCIM von Haus aus ab, mit erweiterten Konnektoren und generischen APIs für alles, was spezifischer für Ihre Umgebung ist.

Das Rollenmanagement funktioniert nach demselben Prinzip. Sie definieren Rollen- und Richtlinienmodelle pro Persona statt einer einzigen Richtlinie für alle, und Role Mining nutzt maschinelles Lernen, um tatsächliche Zugriffsmuster zu analysieren, Rollenstrukturen zu entdecken und das Modell aktuell zu halten, während sich die Nutzung ändert – sodass es nicht nur das Organigramm vom Tag seiner Erstellung widerspiegelt.

Die Risikoseite ist für dieselbe Realität konzipiert. Eine Richtlinien-Engine erkennt und verhindert Konflikte bei der Funktionstrennung, und laufendes Monitoring meldet verwaiste Konten und Ausreißer, bevor sie in einem Audit auftauchen, statt danach.

Nichts davon ersetzt die Persona-Übung. Sie ist es, was einen schnellen Übergang von der Konzeption zur Implementierung überhaupt möglich macht: Jede Identität wird nach ihren eigenen Bedingungen definiert und verwaltet, statt durch eine einzige Leitung gezwungen und mit Ausnahmen passend gemacht zu werden. Das Ergebnis ist geringeres Risiko, schnellere Implementierung und geringere Kosten.

Zusammenfassung

Identity-Governance-Plattformen sind ausgereift und leistungsfähig. Die Technologie ist normalerweise nicht das, was Projekte ins Straucheln bringt. Was Projekte ins Straucheln bringt, ist, mit einem Produkt zu beginnen und zu versuchen, die Realität der Organisation im Nachhinein hineinzupassen.

Die Alternative (zunächst die eigenen Identitäts-Personas zu bestimmen, sie zur Definition der Anforderungen zu nutzen und dann Plattformen anhand dieser Anforderungen zu bewerten) klingt selbstverständlich, wenn man sie beschreibt. Doch sie ist in der Praxis überraschend selten, und die Lücke, die sie schließt, ist erheblich.

Sie erfordert keine spezialisierten Tools oder tiefes technisches Wissen. Sie erfordert Zeit, gute Fragen und die Bereitschaft, die richtigen Personen aus dem gesamten Unternehmen frühzeitig in den Prozess einzubeziehen.

Bringen Sie die Personas richtig hin, und der Rest des Projekts wird erheblich unkomplizierter. Bringen Sie sie durcheinander oder lassen Sie sie ganz aus, und Sie könnten sich dabei wiederfinden, eine Lösung nachträglich an ein Problem anzupassen, das Sie beim Kauf nicht vollständig verstanden hatten.

Haben Sie Probleme mit Ihrem Identitätsprogramm? Wir helfen Ihnen, Ihre Personas zu verstehen und wie Netwrix Identity Manager Ihr Projekt zum Erfolg führen kann. Demo anfordern.