Warum binden Passwort-Reset und Rechteanträge so viel Zeit im Helpdesk?

Ein Mitarbeiter ruft im Helpdesk an, weil er sich nicht mehr in sein Konto einloggen kann. Ein First-Level-Kollege nimmt den Anruf entgegen, prüft die Identität nach Gehör, setzt das Passwort manuell zurück und dokumentiert den Vorgang im Ticketsystem. Genau dieser Ablauf wiederholt sich in vielen Unternehmen mehrfach täglich, und automatisierte Zugriffsanfragen setzen genau an dieser Wiederholung an, weil sie Standardfälle vom Telefon in einen geprüften Ablauf verlagern.

Der Anteil dieser Anfragen an der gesamten Helpdesk-Last ist erheblich. Nach Angaben von ManageEngine entfallen laut Schätzungen von Gartner und Forrester zwischen 20 und 50 Prozent aller IT-Support-Tickets auf Passwort-Rücksetzungen, und HDI-Erhebungen beziffern die durchschnittlichen Kosten je Support-Ticket auf 20 bis 70 US-Dollar Angaben von ManageEngine zu Kosten und Häufigkeit von Passwort-Resets. Diese Zahlen stammen aus internationalen Erhebungen und lassen sich nicht eins zu eins auf jedes deutsche Unternehmen übertragen, sie zeigen aber die Größenordnung des Problems.

Für die Fachbereiche bedeutet das Wartezeit: Ein Vertriebsmitarbeiter kommt am Montagmorgen nicht an seine Kundendaten, eine Sachbearbeiterin wartet auf die Freigabe eines Softwarezugriffs, bevor sie eine Rechnung buchen kann. Der First-Level-Support wiederum bearbeitet diese Fälle nach Schema, ohne dass ein Genehmigungsschritt oder eine Identitätsprüfung wirklich neue Information liefert. Genau diese wiederkehrenden, regelbasierten Fälle sind der Ansatzpunkt für einen automatisierten Genehmigungsworkflow, der Identität prüft, Regeln anwendet und nur bei Bedarf einen Menschen einbindet.

Welche Fälle deckt der Genehmigungsworkflow für automatisierte Zugriffsanfragen ab?

Der Genehmigungsworkflow deckt vier wiederkehrende Fallgruppen ab: Passwort-Reset, Kontoentsperrung, Softwarezugriff und Rechteerweiterung. In jedem Fall stellt die betroffene Person oder eine Führungskraft die Anfrage, das System prüft Identität und Regelwerk, und erst danach setzt das Zielsystem die Änderung um. Automatisierte Zugriffsanfragen ersetzen damit den Anruf im Helpdesk durch einen nachvollziehbaren, protokollierten Ablauf.

Beim Passwort-Reset stellt die Mitarbeiterin selbst die Anfrage über ein Portal oder einen Chat, das System verifiziert sie über einen zweiten Faktor und setzt das Passwort in Microsoft Active Directory oder Microsoft Entra ID zurück. Bei der Kontoentsperrung, etwa nach zu vielen Fehlversuchen, läuft der Vorgang ähnlich, nur dass zusätzlich geprüft wird, ob die Sperrung durch einen ungewöhnlichen Anmeldeversuch ausgelöst wurde.

Softwarezugriffe werden meist vom Fachbereich beantragt, etwa wenn eine neue Mitarbeiterin Zugang zu einem Fachverfahren oder einem SAP-Modul benötigt. Hier prüft das System, ob die beantragte Rolle zur bestehenden Funktion passt, und meldet den Fall an ein ITSM-System wie ServiceNow, Matrix42 oder Jira Service Management zur Umsetzung. Rechteerweiterungen, etwa der Zugriff auf zusätzliche Datenbereiche oder erweiterte Freigabestufen, durchlaufen dieselbe Prüfung, benötigen aber häufig eine zusätzliche Freigabe durch die Führungskraft, weil sie über den ursprünglichen Rollenrahmen hinausgehen.

Allen vier Fällen ist gemeinsam, dass die Anfrage strukturiert erfasst, gegen ein Regelwerk geprüft und erst nach Freigabe im Zielsystem umgesetzt wird. Wie sich solche Abläufe technisch mit bestehenden Systemen verbinden lassen, beschreibt der Bereich IT Service Management im Detail.

Wie läuft eine Anfrage von der Meldung bis zur Umsetzung?

Eine Anfrage durchläuft sieben Schritte: Eingang über Portal, Chat oder Ticket, Identitätsprüfung, Regelprüfung, Freigabe, Umsetzung im Zielsystem, Rückmeldung an die anfragende Person und Protokollierung. Jeder Schritt ist einzeln nachvollziehbar, sodass sich automatisierte Zugriffsanfragen jederzeit im Audit-Trail nachverfolgen lassen.

Am Anfang steht die Meldung: Ein Mitarbeiter stellt die Anfrage über ein Self-Service-Portal, einen Chat-Kanal oder ein klassisches Ticket. Das System prüft die Identität, meist über ein registriertes Gerät oder einen zweiten Faktor, bevor irgendeine Aktion ausgelöst wird. Erst danach folgt die Regelprüfung: Passt die Anfrage zur hinterlegten Rolle, gibt es einen Funktionstrennungskonflikt, liegt der Fall innerhalb der Grenzen, die für automatische Bearbeitung vorgesehen sind?

Fällt die Anfrage in den automatisierbaren Bereich, erfolgt die Freigabe durch das Regelwerk selbst, protokolliert mit Zeitstempel und angewendeter Regel. Liegt ein Sonderfall vor, geht die Anfrage an eine Führungskraft oder an die Datenverantwortlichen, die sie manuell freigeben oder ablehnen. Erst nach dieser Freigabe setzt das Zielsystem, etwa Active Directory, SAP GRC Access Control oder ein Fachverfahren, die Änderung tatsächlich um.

Am Ende steht die Rückmeldung an die anfragende Person, üblicherweise über denselben Kanal, über den die Anfrage einging. Parallel dazu wird der gesamte Vorgang protokolliert: Wer hat was beantragt, wer hat geprüft, wer hat freigegeben, wann wurde umgesetzt. Diese Protokollierung ist keine Nebensache, sie ist die Grundlage für Rezertifizierungen und für den Nachweis gegenüber Prüfern nach ISO/IEC 27001 oder BSI IT-Grundschutz.

Welche Zugriffsanfragen lassen sich automatisieren und welche nicht?

Automatisierbar sind standardisierte, rollenbasierte und reversible Fälle, etwa ein Passwort-Reset nach verifizierter Identität oder ein Softwarezugriff, der exakt der hinterlegten Rolle entspricht. Nicht automatisierbar sind privilegierte Zugriffe, Fälle mit Funktionstrennungskonflikt und Ausnahmen, für die kein Regelwerk existiert. Die Trennlinie verläuft entlang der Frage, ob eine Regel die Entscheidung tatsächlich abbildet oder nur eine Vermutung ersetzt.

Ein Beispiel für den automatisierbaren Bereich ist die Kontoentsperrung nach einem plausiblen Fehlversuch oder die Vergabe von Lesezugriff auf ein Standardverzeichnis, das zur Abteilung der anfragenden Person passt. Diese Fälle sind reversibel, gut dokumentiert und lassen sich im Zweifel schnell zurücknehmen. Anders sieht es bei privilegierten Konten aus, etwa Administratorrechten in SAP oder Active Directory: Hier reicht eine automatische Regelprüfung nicht aus, weil die Tragweite eines Fehlers deutlich größer ist.

Funktionstrennungskonflikte, also Fälle, in denen eine Person durch die neue Berechtigung zwei Rollen vereinen würde, die laut interner Kontrollrichtlinie getrennt bleiben müssen, gehören ebenfalls in die manuelle Prüfung. Gleiches gilt für jede Anfrage, für die es schlicht keine hinterlegte Regel gibt, weil sie im bestehenden Rollenmodell nicht vorgesehen ist. Solche Ausnahmen werden nicht automatisiert übergangen, sondern gezielt eskaliert.

Wie sicher ist ein automatisiertes Passwort-Reset gegen Social Engineering?

Ein automatisiertes Passwort-Reset ist gegen Social Engineering tendenziell sicherer als ein telefonischer Reset durch den Helpdesk, sofern es konsequent an Multi-Faktor-Authentifizierung gebunden ist. Ohne verifizierten zweiten Faktor über ein registriertes Gerät wird keine Zurücksetzung ausgelöst, unabhängig davon, wie überzeugend die anfragende Person am Telefon oder im Chat auftritt. Automatisierte Zugriffsanfragen entziehen dem klassischen Trick, sich als Kollege auszugeben, damit die Grundlage.

Das klassische Angriffsbild sieht so aus: Ein Angreifer ruft den Helpdesk an, gibt sich als Mitarbeiter aus, der dringend sein Passwort zurücksetzen lassen möchte, und nutzt Druck oder Dringlichkeit, um die First-Level-Person zu einer schnellen, unsauberen Prüfung zu bewegen. Genau diese menschliche Schwachstelle wird durch feste technische Regeln geschlossen, statt sie einer Einzelentscheidung am Telefon zu überlassen.

Im automatisierten Ablauf erfolgt die Identitätsprüfung ausschließlich über einen zweiten Faktor, etwa eine Authenticator-App auf einem bereits registrierten Gerät oder einen Sicherheitsschlüssel. Fällt diese Prüfung nicht eindeutig aus, wird keine Zurücksetzung vorgenommen, sondern der Fall an einen Menschen eskaliert. Auffällige Muster, etwa mehrere Reset-Versuche aus unterschiedlichen Netzwerken oder zu ungewöhnlichen Zeiten, führen zu einer automatischen Sperrung statt zu einer Zurücksetzung.

Diese Regeln ersetzen keine Sicherheitskultur, sie ergänzen sie. Ein Unternehmen, das Multi-Faktor-Authentifizierung nicht flächendeckend eingeführt hat, kann ein automatisiertes Passwort-Reset nicht mit derselben Verlässlichkeit betreiben wie eines mit vollständiger MFA-Abdeckung. Die technische Bestandsaufnahme vor der Einführung prüft deshalb immer zuerst, wie weit Multi-Faktor-Authentifizierung im Unternehmen bereits verankert ist.

Wo endet die Automatisierung und wo entscheidet ein Mensch?

Die Automatisierung endet dort, wo eine Entscheidung Tragweite hat, die eine Regel nicht vollständig abbilden kann: bei privilegierten Zugriffen, bei Funktionstrennungskonflikten und bei jeder Anfrage, die von der hinterlegten Rolle abweicht. In diesen Fällen entscheidet immer ein Mensch, nach dem Vier-Augen-Prinzip und mit protokollierter Freigabe.

Konkret bedeutet das: Eine Führungskraft gibt Rechteerweiterungen frei, die über den ursprünglichen Rollenrahmen ihrer Mitarbeiterin hinausgehen. Die Datenverantwortlichen entscheiden über Zugriffe auf besonders geschützte Datenbereiche, etwa Personaldaten oder Finanzsysteme. Jede dieser Freigaben wird mit Zeitstempel, Name und angewendeter Begründung protokolliert, damit sie bei einer Rezertifizierung oder einem Audit nachvollzogen werden kann.

Bei Unklarheit eskaliert das System den Fall, statt eine eigene Annahme zu treffen. Ein Agent liest die Anfrage, prüft die vorhandenen Regeln und schlägt eine Einordnung vor. Entscheiden darf er nicht, wenn die Regel nicht eindeutig zutrifft. Diese Grenze ist kein technisches Detail, sondern die Voraussetzung dafür, dass ein Unternehmen die Verantwortung für seine Zugriffsrechte behält, während es Routinefälle spürbar entlastet. Wie sich solche Freigabeprozesse mit vorhandenen Abläufen verbinden lassen, zeigt der Bereich Bpm.

Wie fügen sich automatisierte Zugriffsanfragen in den Joiner-Mover-Leaver-Prozess ein?

Automatisierte Zugriffsanfragen übernehmen im Joiner-Mover-Leaver-Prozess die Rechtevergabe beim Eintritt, die Anpassung beim Wechsel und den Entzug beim Austritt, jeweils auf Basis hinterlegter Rollenprofile. Der Mensch bleibt Genehmiger bei kritischen Fällen, das System schlägt vor, prüft ab und protokolliert. Damit entsteht ein durchgängiger Prozess statt drei getrennter Abläufe in Personalabteilung, IT und Fachbereich.

Beim Eintritt legt das Rollenprofil fest, welche Systeme, Gruppen und Anwendungen eine neue Mitarbeiterin oder ein neuer Mitarbeiter standardmäßig benötigt. Der Agent stellt die Anfrage, ordnet sie der Stelle zu und leitet sie an die zuständige Führungskraft weiter. Abweichungen vom Standardprofil, etwa ein zusätzlicher Zugriff auf ein Finanzsystem, werden gesondert markiert und benötigen eine ausdrückliche Freigabe.

Der Mover-Fall ist in der Praxis der schwierigste, weil sich Rechte über Jahre ansammeln, ohne dass jemand die alten wieder entzieht. Ein Wechsel der Abteilung oder Position löst deshalb nicht nur eine neue Zugriffsanfrage aus, sondern auch eine automatische Gegenüberstellung mit dem bisherigen Berechtigungsstand. Rechte, die zur neuen Rolle nicht mehr passen, werden zur Prüfung vorgeschlagen, nicht automatisch gelöscht.

Beim Austritt entzieht das System die Zugriffsrechte terminiert zum vereinbarten Stichtag und meldet den Vollzug an die Personalabteilung zurück. Diese Rückmeldung ist Teil der Dokumentation und wird bei einer Rezertifizierung herangezogen. Wer die Ausgangslage für Rollenprofile und Genehmigungslogik systematisch erfassen will, findet in unseren Lösungen Ansatzpunkte für die technische Bestandsaufnahme.

Wie werden Active Directory, Entra ID und SAP angebunden?

Automatisierte Zugriffsanfragen setzen auf vorhandene Verzeichnisdienste und Berechtigungssysteme auf, statt sie zu ersetzen. Der Agent liest Gruppen und Attribute aus Active Directory oder Microsoft Entra ID, stößt Rechteänderungen über die vorhandenen Schnittstellen an und meldet Ergebnisse an SAP GRC Access Control zurück, wenn dort die eigentliche Berechtigungsprüfung liegt.

Bei Active Directory und Entra ID beschränkt sich die Automatisierung auf das Anlegen, Ändern und Entfernen von Gruppenmitgliedschaften nach festgelegten Regeln. Die Rechtestruktur selbst, also welche Gruppe welche Berechtigung trägt, bleibt beim Kunden gepflegt. Das System liefert lediglich den Vorschlag, wer wann welcher Gruppe zugeordnet werden soll, und dokumentiert die Entscheidung.

In SAP-Landschaften mit SAP GRC Access Control übernimmt der Agent die Vorprüfung: Er erkennt, ob eine angefragte Kombination von Berechtigungen einen Funktionstrennungskonflikt auslöst, und markiert diesen Fall zur besonderen Freigabe. Die endgültige Vergabe bleibt im GRC-Regelwerk verankert, ANCUD IT baut keine parallele Berechtigungslogik auf.

Für die Vorgangsverwaltung wird das bestehende ITSM-System weiterverwendet, etwa ServiceNow, Matrix42 oder Jira Service Management. Die Integration erfolgt über die jeweiligen Schnittstellen, sodass ein Ticket automatisch angelegt, kategorisiert und mit dem Freigabestatus versehen wird. Wie sich solche Anbindungen im laufenden Betrieb absichern lassen, beschreiben wir auch im Zusammenhang mit IT Service Management, wo ähnliche Integrationsfragen für Vorgangssysteme auftreten.

Welche Rolle spielt Ihr Ticketsystem bei automatisierten Zugriffsanfragen?

Das Ticketsystem bleibt bei automatisierten Zugriffsanfragen die verbindliche Vorgangsakte. Der Agent legt kein eigenes Protokoll parallel an, sondern schreibt Kategorisierung, Prüfergebnis und Freigabestatus in das vorhandene Ticket zurück. So bleibt jede Anfrage dort nachvollziehbar, wo Support und Audit ohnehin nachsehen.

Bei Eingang einer Anfrage ordnet das System sie automatisch einer Kategorie zu, etwa Passwort-Reset, Rechteänderung oder Neuanlage eines Kontos, und ergänzt das Ticket um die relevanten Angaben aus Verzeichnisdienst oder Rollenprofil. Die Kategorisierung entscheidet auch, welcher Genehmigungsweg greift und wie dringend der Fall behandelt wird.

Während der Bearbeitung meldet der Agent Statusänderungen in das Ticket zurück: angefragt, in Prüfung, freigegeben oder abgelehnt, jeweils mit Zeitstempel. Diese Statusrückmeldung ersetzt keine Kommunikation mit der antragstellenden Person, sie ergänzt sie um einen technisch belastbaren Nachweis.

Der eigentliche Freigabenachweis, also wer wann welche Entscheidung getroffen hat, wird mit dem Ticket verknüpft und bleibt dort auffindbar, auch wenn die Genehmigung in einem separaten Freigabesystem erfolgte. Damit entsteht keine zweite Wahrheit neben dem Ticketsystem, sondern eine ergänzte.

Welche Normen und Rechtsgrundlagen gelten für automatisierte Zugriffsanfragen?

Automatisierte Zugriffsanfragen berühren vier zentrale Regelwerke: ISO/IEC 27001 mit Anlage A zur Zugriffskontrolle, den BSI-Baustein ORP.4 zum Identitäts- und Berechtigungsmanagement, Artikel 32 der DSGVO zur Sicherheit der Verarbeitung sowie die NIS2-Richtlinie für Unternehmen, die als wichtige Einrichtung gelten. Jede dieser Grundlagen verlangt eine nachvollziehbare, dokumentierte Vergabe von Rechten statt informeller Absprachen.

ISO/IEC 27001, insbesondere Anlage A, fordert ein geregeltes Verfahren für die Zuweisung, Änderung und den Entzug von Zugriffsrechten sowie regelmäßige Überprüfungen. Für automatisierte Zugriffsanfragen bedeutet das: Regeln müssen dokumentiert, Ausnahmen begründet und Prüfintervalle festgelegt sein, bevor ein System überhaupt Vorschläge machen darf.

Der BSI-Baustein ORP.4 aus dem IT-Grundschutz-Kompendium konkretisiert das für deutsche Behörden und Unternehmen mit Grundschutzbezug: Er verlangt ein dokumentiertes Berechtigungskonzept, klare Verantwortlichkeiten für Vergabe und Entzug sowie eine Trennung zwischen Antragstellung und Genehmigung. Diese Trennung ist der Kern jedes Genehmigungsworkflows, den ANCUD IT umsetzt.

Artikel 32 DSGVO verpflichtet zu geeigneten technischen und organisatorischen Maßnahmen, wenn Zugriffsrechte automatisiert vergeben werden und personenbezogene Daten betroffen sind. Ein Passwort-Reset ohne menschliche Prüfung gilt vielen Anbietern als reine Komfortfunktion Self-Service Password Reset On-Premises, rechtlich verlangt er aber eine sichere Identitätsprüfung und eine Protokollierung, wer wann welchen Reset ausgelöst hat Passwort-Reset ohne IT-Aufwand. Für Unternehmen, die unter die NIS2-Richtlinie als wichtige Einrichtung fallen, kommt die Pflicht hinzu, Zugriffssteuerung als Teil des Risikomanagements nachweisbar zu betreiben, nicht als isoliertes IT-Feature.

Wie werden Freigaben und Zugriffsentscheidungen auditfähig dokumentiert?

Jede Zugriffsentscheidung wird mit Zeitpunkt, Antragstellung, Prüfergebnis und Freigabeperson im Ticket sowie im angebundenen Freigabesystem protokolliert. Der Freigabenachweis liegt damit an einer Stelle, die sowohl für den laufenden Betrieb als auch für ein Audit zugänglich ist, nicht verteilt über E-Mails oder Chatverläufe.

Protokolliert wird nicht nur das Ergebnis, sondern auch die Grundlage der Entscheidung: welches Rollenprofil herangezogen wurde, ob ein Funktionstrennungskonflikt geprüft wurde, und ob die Genehmigung durch eine Führungskraft oder im Vier-Augen-Prinzip erfolgte. Diese Detailtiefe unterscheidet einen belastbaren Nachweis von einer reinen Statusmeldung.

Die Aufbewahrungsdauer richtet sich nach den jeweils geltenden Vorgaben, etwa den Löschfristen aus dem Berechtigungskonzept oder branchenspezifischen Vorgaben, und wird gemeinsam mit der Kundschaft im Rahmen der Bestandsaufnahme festgelegt. Automatisierte Zugriffsanfragen ändern daran nichts, sie sorgen lediglich dafür, dass die Protokolle vollständig und maschinenlesbar vorliegen, statt lückenhaft in Einzeltickets verstreut zu sein.

Für die Rezertifizierung bereitet das System periodisch eine Liste aller aktiven Berechtigungen je Rolle oder Person auf und markiert Abweichungen vom Rollenprofil sowie länger nicht genutzte Zugriffe. Die Führungskraft bestätigt oder widerruft diese Rechte, das Ergebnis fließt zurück in den Freigabenachweis und schließt den Prüfzyklus ab.

Wie unterscheiden sich automatisierte Zugriffsanfragen von einem klassischen IAM-Projekt?

Automatisierte Zugriffsanfragen sind kein Ersatz für ein IAM- oder IGA-Projekt, sondern schließen die Prozesslücke zwischen vorhandenen Systemen. Ein klassisches Identity-and-Access-Management-Projekt baut die Identitätslandschaft neu auf oder konsolidiert sie, während der hier beschriebene Ansatz bestehende Verzeichnisse, Rollenprofile und Freigabewege nutzt und lediglich die Antragstellung, Vorprüfung und Dokumentation automatisiert.

Ein IAM- oder IGA-Einführungsprojekt dauert typischerweise Monate bis Jahre, verändert Datenmodelle und Governance-Strukturen und bindet erhebliche interne Ressourcen. Wer bereits ein funktionierendes Active Directory, ein SAP-Berechtigungskonzept oder ein etabliertes ITSM-System betreibt, braucht in vielen Fällen keinen solchen Neubau, sondern eine bessere Verbindung zwischen den vorhandenen Teilen.

Automatisierte Zugriffsanfragen setzen genau dort an: Sie übernehmen wiederkehrende, gut beschreibbare Fälle wie Standard-Rechtevergabe beim Eintritt oder Passwort-Reset nach Identitätsprüfung, und leiten alles Ungewöhnliche an einen menschlichen Genehmiger weiter. Das ist ein prozessorientierter, risikoarmer Einstieg, der sich mit einer technischen Bestandsaufnahme beginnen lässt, statt ein mehrjähriges Governance-Projekt vorauszusetzen.

Wo im Unternehmen bereits Vorgänge über Prozessmodelle gesteuert werden, lässt sich der Genehmigungsworkflow für Zugriffsanfragen häufig an bestehende Abläufe anschließen, etwa über die im Bereich Bpm beschriebenen Automatisierungsmuster, statt eine eigenständige IAM-Infrastruktur aufzubauen.

Was passiert bei Kontosperrungen außerhalb der Geschäftszeiten?

Ein Passwort-Reset ohne privilegierte Rechte darf auch nachts automatisch laufen, sofern die Identität über Multi-Faktor-Authentifizierung bestätigt wird. Automatisierte Zugriffsanfragen mit erhöhtem Risiko, etwa für Finanzsysteme oder Admin-Konten, warten dagegen auf eine Freigabe durch die Rufbereitschaft. Diese Trennung wird vorab festgelegt, nicht im Einzelfall entschieden.

Im Schichtbetrieb und am Wochenende ist die IT-Abteilung oft nicht durchgehend besetzt. Wer trotzdem sofort wieder arbeiten muss, braucht einen Weg, der nicht an ein Ticket im Postfach der Frühschicht gebunden ist. Ein Self-Service-Reset mit sauberer Identitätsprüfung schließt genau diese Lücke, ohne dass jemand nachts telefonisch erreichbar sein muss.

Für alle Fälle, die eine Freigabe erfordern, definieren wir eine Eskalationskette: Zuerst die zuständige Führungskraft, danach eine benannte Vertretung, zuletzt die Rufbereitschaft der IT. Jede Stufe hat eine Reaktionsfrist, nach deren Ablauf automatisch weitergereicht wird. So bleibt auch außerhalb der Geschäftszeiten nachvollziehbar, wer wann entschieden hat.

Kritisch bleiben Konten mit weitreichenden Rechten oder Zugriff auf besonders schützenswerte Daten. Hier verzichten wir bewusst auf eine vollautomatische Freigabe, selbst wenn das technisch möglich wäre. Der Agent bereitet die Entscheidung vor, prüft Identität und Kontext, die eigentliche Freigabe bleibt jedoch bei einem Menschen, protokolliert im Audit-Trail.

Welche Voraussetzungen müssen im Unternehmen erfüllt sein?

Voraussetzung sind ein gepflegtes Active Directory oder Entra ID mit korrekten Gruppenzuordnungen, dokumentierte Rollenprofile, benannte Verantwortliche für Freigaben je Systembereich und ein Verzeichnis aller angebundenen Anwendungen. Fehlen diese Grundlagen, automatisiert das System fehlerhafte Zustände nur schneller. Zusätzlich braucht es eine Betriebsvereinbarung, wenn der Betriebsrat bei automatisierten Personalentscheidungen mitbestimmt.

Die Datenqualität im Verzeichnisdienst entscheidet über den Erfolg. Verwaiste Konten, doppelte Einträge oder Gruppen ohne erkennbaren Zweck führen dazu, dass automatisierte Zugriffsanfragen falsche Berechtigungen vorschlagen. Eine Bereinigung vor dem Start ist deshalb keine Nebensache, sondern Teil der Bestandsaufnahme, die wir jedem Projekt voranstellen.

Rollenprofile nach dem Prinzip Role-Based Access Control müssen tatsächlich der Arbeitsrealität entsprechen, nicht nur dem Organigramm. Wenn eine Abteilung historisch gewachsene Sonderrechte trägt, die niemand mehr erklären kann, lohnt sich vor der Automatisierung eine Rezertifizierung. Sonst schreibt das System bestehende Unschärfen einfach fest.

Organisatorisch braucht es benannte Freigebende je Anwendung, ein aktuelles Verzeichnis der Zielsysteme und, bei Mitbestimmung im Betrieb, eine Betriebsvereinbarung, die Umfang und Grenzen der Automatisierung festlegt. Wer im Bereich Berechtigungsmanagement bereits mit definierten Prozessen arbeitet, kann auf unserer Seite zu IT Service Management nachlesen, wie sich solche Abläufe strukturieren lassen.

Was kostet die Einführung automatisierter Zugriffsanfragen?

Die Kosten hängen von vier Faktoren ab: der Zahl der anzubindenden Zielsysteme, dem Zustand der bestehenden Rollenmodelle, der Zahl der benötigten Freigabestufen und dem gewählten Betriebsmodell. Konkrete Beträge nennen wir erst nach einer technischen Bestandsaufnahme, weil pauschale Preise die tatsächliche Komplexität einer gewachsenen IT-Landschaft nicht abbilden.

Ein Unternehmen mit sauber gepflegtem Active Directory und drei angebundenen Anwendungen braucht einen deutlich kleineren Aufwand als eines mit gewachsenen Rechtestrukturen über zehn Systeme hinweg. Auch die Frage, ob privilegierte Konten mit strenger Funktionstrennung einbezogen werden, verändert den Umfang spürbar.

Der wirtschaftliche Hintergrund lässt sich grob einordnen: Ein einzelnes IT-Support-Ticket kostet ein Unternehmen schätzungsweise zwischen 50 und 70 Euro, ein erheblicher Anteil davon entfällt allein auf Passwort-Rücksetzungen Vorteile des Self-Service Password Reset. Diese laufenden Kosten helfen bei der Abwägung, welcher Automatisierungsgrad wirtschaftlich sinnvoll ist.

Wir empfehlen daher immer den gleichen Einstieg: eine Bestandsaufnahme der Zielsysteme, Rollenmodelle und bestehenden Freigabewege, bevor ein Angebot erstellt wird. So bleibt der Preisrahmen an die tatsächliche Ausgangslage gekoppelt, nicht an ein Standardpaket.

Wie lange dauert die Einführung automatisierter Zugriffsanfragen?

Ein realistischer Zeitrahmen umfasst vier Phasen: Bestandsaufnahme, Pilot mit einer einzelnen Fallgruppe, schrittweise Ausweitung und laufender Betrieb. Für ein mittelständisches Unternehmen mit überschaubarer Systemlandschaft lässt sich der Pilot oft innerhalb weniger Wochen aufsetzen, die vollständige Ausweitung nimmt je nach Zielsystemen deutlich länger in Anspruch.

In der Bestandsaufnahme prüfen wir Verzeichnisdienst, Rollenprofile und vorhandene Ticket- oder Freigabesysteme. Danach wählen wir gemeinsam eine überschaubare Fallgruppe für den Pilot, meist den einfachen Passwort-Reset ohne privilegierte Rechte, weil sich hier Nutzen und Risiko am schnellsten bewerten lassen.

Nach erfolgreichem Pilot folgt die Ausweitung auf weitere Fallgruppen wie Standardzugriffe auf Fachanwendungen oder den Joiner-Mover-Leaver-Prozess bei Neueinstellungen und Abteilungswechseln. Jede neue Fallgruppe durchläuft dieselbe Prüfung: Welche Fälle laufen automatisch vor, welche brauchen weiterhin eine menschliche Freigabe.

Verlängert wird der Zeitplan vor allem durch unklare Datenlage im Verzeichnisdienst, fehlende Verantwortliche für einzelne Anwendungen oder eine Mitbestimmung, die erst noch verhandelt werden muss. Diese Punkte lassen sich kaum überspringen, ohne die spätere Akzeptanz zu gefährden.

Welche Risiken bestehen und wie begrenzen wir sie?

Die zentralen Risiken sind Übervergabe von Rechten durch fehlerhafte Rollenmodelle, Abhängigkeit von einem einzelnen Werkzeug, Ausfall des Verzeichnisdienstes und mangelnde Akzeptanz in der Belegschaft. Wir begrenzen sie durch enge Freigabestufen, den Einbau von Fallback-Wegen, den Erhalt bestehender Systeme statt einer Insellösung und frühe Beteiligung der betroffenen Fachbereiche.

Automatisierte Zugriffsanfragen übernehmen nur, was vorher als Regel definiert wurde. Ist ein Rollenmodell fehlerhaft, vergibt das System Rechte konsequent falsch, statt Einzelfälle wie bisher manuell abzufangen. Deshalb prüfen wir Rollenprofile vor der Aktivierung und legen für kritische Bereiche zusätzlich das Vier-Augen-Prinzip fest.

Eine Abhängigkeit von einem einzelnen Anbieter entsteht, wenn Geschäftslogik ausschließlich im Zusatzwerkzeug liegt und nicht im bestehenden Verzeichnisdienst oder ITSM-System dokumentiert ist. Wir bauen deshalb auf vorhandene Systeme wie Active Directory oder Entra ID auf und vermeiden proprietäre Datenmodelle, die einen späteren Wechsel erschweren.

Fällt der Verzeichnisdienst aus, muss ein manueller Notweg funktionieren, den die IT-Abteilung regelmäßig übt. Und weil Belegschaft und Führungskräfte dem System vertrauen müssen, kommunizieren wir von Anfang an offen, welche Fälle automatisch laufen und welche eine Freigabe erfordern. Wer diesen Prozess in ein bestehendes Vorgehen zum Änderungsmanagement einbetten will, findet dazu Anknüpfungspunkte auf unserer Seite zu Change Management.

Wie beginnen Sie mit automatisierten Zugriffsanfragen?

Der Einstieg beginnt mit einer technischen Bestandsaufnahme von Verzeichnisdienst, Rollenmodellen und bestehenden Freigabewegen, gefolgt von der Auswahl einer einzelnen Fallgruppe für einen Pilotbetrieb mit klaren Messpunkten. Erst nach Auswertung dieses Piloten entscheiden Sie, ob und wie automatisierte Zugriffsanfragen auf weitere Bereiche ausgeweitet werden.

In der Bestandsaufnahme dokumentieren wir gemeinsam, welche Systeme angebunden werden müssen, wo Freigaben heute liegen und welche Daten im Active Directory bereinigt werden sollten. Dieser Schritt ist bewusst risikoarm, es wird nichts verändert, bevor die Ausgangslage geklärt ist.

Für den Pilot wählen wir eine Fallgruppe mit überschaubarem Risiko, häufig den einfachen Passwort-Reset. Messpunkte sind zum Beispiel die Zahl der bearbeiteten Anfragen, die durchschnittliche Bearbeitungszeit und die Zahl der Fälle, die zu Recht an eine menschliche Freigabe weitergeleitet wurden.

Auf Basis dieser Zahlen entscheiden Sie mit uns gemeinsam, welche weiteren Fallgruppen folgen und welches Betriebsmodell dauerhaft passt. Diese Vorgehensweise lässt sich auch in eine breitere Digitalisierung von Serviceprozessen einordnen, etwa im Zusammenspiel mit Bpm.